Hi all (interested in system config tools;-). We are working on System Configurations Tools Cleanup Project we need Fedora community opinion on this subject.
Some s-c-* tools are now very outdated, some are replaced with better solution, some are only used in Anaconda etc.
This is a short list of application that could be eliminated/replaced/enhanced in short/long term from Fedora.
I've prepared it simple and clean to support further discussion, maybe some other tool is missing...
* system-config-netboot - very outdated - replacements k12linux, cobbler
* system-config-boot - at least it needs facelift and it's not very usable at all
* system-config-display - xrandr should be used for resolution/dualhead configuration, Gnome & KDE have own xrandr based display configuration tool - generates xorg.conf - it's not needed anymore (only if someone needs more expert configuration)
* system-config-network - replacement NetworkManager - missing IPv6? routing?
* system-config-date - Gnome/KDE/XFCE have own datetime configuration tool/module, it's confusing than which one users should use - used in firstboot or anaconda???
* system-config-keyboard - used only in Anaconda, let it be standalone? - very simple tool, Gnome/KDE have better one
* system-config-httpd - old GTK 1 application, should be ported to GTK 2 & PolicyKit
* switchdesk and system-switch-tools? - it's possible to switch desktop in GDM/KDM - one tool for switching all alternatives?
---
Expect more spam from us regarding cleanup project - we already have s-c-* tools reviews, so we will fill bugs soon (with some guidelines on list), nearly all s-c-* tools need to be ported to PolicyKit and so on ;-)
Happy system config tools hacking System Config Cleanup Team
On Tue, Mar 24, 2009 at 11:10 AM, Jaroslav Reznik jreznik@redhat.com wrote:
Hi all (interested in system config tools;-). We are working on System Configurations Tools Cleanup Project we need Fedora community opinion on this subject.
Some s-c-* tools are now very outdated, some are replaced with better solution, some are only used in Anaconda etc.
This is a short list of application that could be eliminated/replaced/enhanced in short/long term from Fedora.
I've prepared it simple and clean to support further discussion, maybe some other tool is missing...
I'm going to assume you want all discussion in this thread.
- system-config-netboot
- very outdated - replacements k12linux, cobbler
Kill it
- system-config-boot
- at least it needs facelift and it's not very usable at all
Think there needs to be some discussion on a UI first and then out it out there as a task that someone could pickup.
- system-config-display
- xrandr should be used for resolution/dualhead configuration, Gnome & KDE have own xrandr based display configuration tool - generates xorg.conf - it's not needed anymore (only if someone needs more expert configuration)
system-config-display hasn't been use other than as an xorg generator for me for quite a few releases now. And even haven't an xorg.conf no longer solves my problems. So might as well kill it.
- system-config-network
- replacement NetworkManager - missing IPv6? routing?
I don't think NetworkManager is ready yet, at least not ready to repalce system-config-network. Just setting up LTSP, i needed system-config-network quite a bit.
- system-config-date
- Gnome/KDE/XFCE have own datetime configuration tool/module, it's confusing than which one users should use - used in firstboot or anaconda???
Assuming it is killed, what happens to firsrtboot?
- system-config-keyboard
- used only in Anaconda, let it be standalone? - very simple tool, Gnome/KDE have better one
No opinion.
- system-config-httpd
- old GTK 1 application, should be ported to GTK 2 & PolicyKit
Think there needs to be some discussion on a UI first and then out it out there as a task that someone could pickup.
- switchdesk and system-switch-tools?
- it's possible to switch desktop in GDM/KDM - one tool for switching all alternatives?
Can anyone confirm that this still actually works? I seem to remember it not really working last time I tried it, but I am not sure.
Jaroslav Reznik schrieb:
- switchdesk and system-switch-tools?
- it's possible to switch desktop in GDM/KDM
- one tool for switching all alternatives?
This tool should be more extensible to allow the usage of other desktop environments. On BZ #488602 I have made an suggestion which allows you to specified DESKTOP=LXDE on /etc/sysconfig/desktop to start LXDE as a desktop environment.
BEst Regards:
Jochen Schmitt
And even haven't an xorg.conf no longer solves my problems. So might as well kill it.
I needed system-config-display because * called by /etc/init.d/livesys-late to provide my livecd with a xdriver= boot option * recover bad hand written xorg.conf * recover bad xorg.conf files generated by older versions of proprietary nvidia drivers
- system-config-network
- replacement NetworkManager
- missing IPv6? routing?
I don't think NetworkManager is ready yet, at least not ready to repalce system-config-network. Just setting up LTSP, i needed system-config-network quite a bit.
+1 NM is not ready yet, for example I could not use it to dial xDSL and pass it my password ..etc. [in F9]
- system-config-keyboard
- used only in Anaconda, let it be standalone?
- very simple tool, Gnome/KDE have better one
hmmm, we need a system-wide default and of course we need to allow users to override
talking about my self, I only rely on system-config-keyboard because I have several problems with other tools here is a screenshot
Muayyad AlSadi (alsadi@gmail.com) said:
And even haven't an xorg.conf no longer solves my problems. So might as well kill it.
I needed system-config-display because
- called by /etc/init.d/livesys-late to provide my livecd with a
xdriver= boot option
Should be fixed - file a bug.
- recover bad hand written xorg.conf
- recover bad xorg.conf files generated by older versions of
proprietary nvidia drivers
Having a separate tool not called anywhere else to solve PEBKAC sounds wrong.
Bill
Bill Nottingham wrote:
Muayyad AlSadi (alsadi@gmail.com) said:
- recover bad hand written xorg.conf
- recover bad xorg.conf files generated by older versions of
proprietary nvidia drivers
Having a separate tool not called anywhere else to solve PEBKAC sounds wrong.
How is having a tool to generate sane xorg.conf's "wrong"? If it can sanitize and correct bad hand-written configs, even better. (We have tools that only do half of that, i.e. only point out the errors... their names tend to end in "lint".)
Bill Nottingham wrote:
Matthew Woehlke (mw_triad@users.sourceforge.net) said:
How is having a tool to generate sane xorg.conf's "wrong"?
Xorg -configure
...which doesn't clean up existing xorg.conf and doesn't have the helpful 'you need to be root' dialog (and doesn't let you make even basic changes in a GUI)? How is that better?
Matthew Woehlke (mw_triad@users.sourceforge.net) said:
Bill Nottingham wrote:
Matthew Woehlke (mw_triad@users.sourceforge.net) said:
How is having a tool to generate sane xorg.conf's "wrong"?
Xorg -configure
...which doesn't clean up existing xorg.conf and doesn't have the helpful 'you need to be root' dialog (and doesn't let you make even basic changes in a GUI)? How is that better?
It's a tool that generates a sane xorg.conf. If that is the goal, I think it's a better place to start than with a large barely-maintained graphical framework.
Bill
----- "Bill Nottingham" notting@redhat.com wrote:
Matthew Woehlke (mw_triad@users.sourceforge.net) said:
Bill Nottingham wrote:
Matthew Woehlke (mw_triad@users.sourceforge.net) said:
How is having a tool to generate sane xorg.conf's "wrong"?
Xorg -configure
...which doesn't clean up existing xorg.conf and doesn't have the helpful 'you need to be root' dialog (and doesn't let you make even
basic changes in a GUI)? How is that better?
It's a tool that generates a sane xorg.conf. If that is the goal, I think it's a better place to start than with a large barely-maintained graphical framework.
Exactly what I think about it. Better to start from clean ground. When someone needs custom xorg.conf, he must know what he's doing so tool that does nothing (only generating template) is useless.
Jaroslav
Bill
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
-------- Original Message -------- Subject: Re: System Config Tools Cleanup Project - tools to eliminate/replace From: Bill Nottingham notting@redhat.com To: Development discussions related to Fedora fedora-devel-list@redhat.com Date: 03/24/2009 03:06 PM
It's a tool that generates a sane xorg.conf. If that is the goal, I think it's a better place to start than with a large barely-maintained graphical framework.
Unfortunately it's not a 100% guarantee to get a "sane" xorg.conf. The default for resolutions in X have been to try the maximum possible by the monitor, but this may not work well with the selected video card driver. Example: mga driver with a G450 and any size LCD monitor will not work above 800x600. I had to switch to the "vesa" driver to get a working X.
There needs to be better configuration keeping. X should first see if there is an xorg.conf. If there is one, it should see if the driver matches the currently installed card. If it does, it tries to start X. If the card and driver do not match, X should ignore the xorg.conf by default with the possiblity of a "Force" option. As for resolutions, without an xorg.conf, X should try the highest available, but fallback to a lower resolution if a user hasn't clicked on an "OK" button, etc. after a set amount of time.
All of this should be exposed to user-space so that X does not have to be run as root and the xorg.conf could be configured by GDM (KDM, etc) and/or the user via PolicyKit. This should also allow for use of GTK+ or QT for configuration widgets. The last thing a new user should see is a raw Xt window.
The "rm -f xorg.conf" policy is a good one in nature, but there will always be a need for static configuration. It seems the same dynamic configuration policy was on the minds of NetworkManager developers at the start, which has caused more trouble than good. Ajax should still continue work on making X hot-pluggable, hot-switchable, and more dynamic, but a static configuration policy should not be forgotten.
tldr;
On Tuesday, March 24 2009, Bill Nottingham said:
Muayyad AlSadi (alsadi@gmail.com) said:
And even haven't an xorg.conf no longer solves my problems. So might as well kill it.
I needed system-config-display because
- called by /etc/init.d/livesys-late to provide my livecd with a
xdriver= boot option
Should be fixed - file a bug.
ajax was talking about having the xserver do this automatically... not sure if he got around to it or not
Jeremy
On 2009-03-24, 17:15 GMT, Muayyad AlSadi wrote:
- recover bad hand written xorg.conf
- recover bad xorg.conf files generated by older versions of
proprietary nvidia drivers
rm -fv /etc/X11/xorg.conf
is pretty good one for both of these (hint: it SHOULD work without any xorg.conf, if not file a bug).
Matěj
Jaroslav Reznik (jreznik@redhat.com) said:
- system-config-netboot
- very outdated
- replacements k12linux, cobbler
Yes, this needs to die.
- system-config-display
- xrandr should be used for resolution/dualhead configuration, Gnome & KDE
have own xrandr based display configuration tool
- generates xorg.conf - it's not needed anymore (only if someone needs more expert configuration)
This is already not in the default install.
- system-config-network
- replacement NetworkManager
- missing IPv6? routing?
Which are you referring to 'missing' features in this case?
- switchdesk and system-switch-tools?
- it's possible to switch desktop in GDM/KDM
- one tool for switching all alternatives?
Yes, I'm not sure why this still is around.
Bill
On Tue, 2009-03-24 at 13:04 -0400, Bill Nottingham wrote:
Jaroslav Reznik (jreznik@redhat.com) said:
- system-config-netboot
- very outdated
- replacements k12linux, cobbler
Yes, this needs to die.
- system-config-display
- xrandr should be used for resolution/dualhead configuration, Gnome & KDE
have own xrandr based display configuration tool
- generates xorg.conf - it's not needed anymore (only if someone needs more expert configuration)
This is already not in the default install.
s-c-d is really only useful for multihead across multiple GPUs. If that _worked_ in X at the moment.
xorg.conf is still useful (and recommended) for configuring the initial login screen.
- ajax
Adam Jackson wrote:
s-c-d is really only useful for multihead across multiple GPUs. If that _worked_ in X at the moment.
It works for me, if by "works" you mean "GLX crashes if it's loaded" ;-). (But I have three monitors on two cards; one PCIe, and one good-old PCI. GL is thoroughly broken, but it's working otherwise.)
On Tue, 2009-03-24 at 13:10 -0500, Matthew Woehlke wrote:
Adam Jackson wrote:
s-c-d is really only useful for multihead across multiple GPUs. If that _worked_ in X at the moment.
It works for me, if by "works" you mean "GLX crashes if it's loaded" ;-). (But I have three monitors on two cards; one PCIe, and one good-old PCI. GL is thoroughly broken, but it's working otherwise.)
You're not using an RandR 1.2 driver, are you?
In my experience, multi-card multi-head just ain't working at all with RandR 1.2 / 1.3. It's not yet capable of handling it. I think that's what ajax was talking about.
Some suggestions:
1. Keep this wiki page up-to-date: http://fedoraproject.org/wiki/SystemConfig/Tools It still mentions "pirut" for example. Add a link to the upstream repositories on fedorahosted.org
2. Consider removing these after loud announcements: system-config-netboot system-config-display
3. Only remove system-config-network when Fedora no longer ships the old network configuration scripts like /etc/sysconfig/network-scripts/ifup and have NetworkManager totally take over. Even then you might want to keep a "System->Administration->Network" menu entry but have it start the NetworkManager connection editor.
On Tuesday 24 March 2009 18:04:52 Scott Tsai wrote:
Some suggestions:
- Keep this wiki page up-to-date:
http://fedoraproject.org/wiki/SystemConfig/Tools It still mentions "pirut" for example. Add a link to the upstream repositories on fedorahosted.org
I'd like to update it according this "questionaire". And yes, all system configs should be hosted on fedorahosted.org.
- Consider removing these after loud announcements:
system-config-netboot system-config-display
- Only remove system-config-network when Fedora no longer ships the old
network configuration scripts like /etc/sysconfig/network-scripts/ifup and have NetworkManager totally take over. Even then you might want to keep a "System->Administration->Network" menu entry but have it start the NetworkManager connection editor.
Seems reasonable to me.
Thanks!
Jaroslav
Am Dienstag, den 24.03.2009, 17:04 +0000 schrieb Scott Tsai:
Some suggestions:
- Keep this wiki page up-to-date:
http://fedoraproject.org/wiki/SystemConfig/Tools It still mentions "pirut" for example. Add a link to the upstream repositories on fedorahosted.org
- Consider removing these after loud announcements:
system-config-netboot system-config-display
- Only remove system-config-network when Fedora no longer ships the old
network configuration scripts like /etc/sysconfig/network-scripts/ifup and have NetworkManager totally take over. Even then you might want to keep a "System->Administration->Network" menu entry but have it start the NetworkManager connection editor.
What is the long term solution for configuring network settings on server systems not using NM?
- fabian
Fabian Deutsch wrote:
What is the long term solution for configuring network settings on server systems not using NM?
The idea is that "server systems not using NM" will not exist in the "long term". Instead, they'll use NM with systemwide configuration. NM actually supports systemwide settings these days, and with those settings it can connect to the network without requiring a user login.
Kevin Kofler
Scott Tsai (scottt.tw@gmail.com) said:
- Only remove system-config-network when Fedora no longer ships the old
network configuration scripts like /etc/sysconfig/network-scripts/ifup and have NetworkManager totally take over.
NetworkManager's connection editor will (soon) be able to write to those files. Even if NM isn't in use, if it's writing the same data, to the same files, while being actually maintained more... I don't see why s-c-network would stay around.
Bill
Bill Nottingham wrote:
Scott Tsai (scottt.tw@gmail.com) said:
- Only remove system-config-network when Fedora no longer ships the old
network configuration scripts like /etc/sysconfig/network-scripts/ifup and have NetworkManager totally take over.
NetworkManager's connection editor will (soon) be able to write to those files. Even if NM isn't in use, if it's writing the same data, to the same files, while being actually maintained more... I don't see why s-c-network would stay around.
Well, I regret having to say so, but unless NetworkManager has seen _very_ substantial improvements since FC10, I feel your rationale is wishful thinking.
Actually, I feel s-c-network should be revived and NetworkManager be made strictly optional.
Ralf Corsepius wrote:
Actually, I feel s-c-network should be revived and NetworkManager be made strictly optional.
I'd actually have to disagree. I *love* NM on my Asus (netbook). It's great for laptops (or other computers that tend to move around and need to deal with "foreign" networks, especially wireless networks), and it's "okay" for desktops. (For one, it handles Verizon CDMA modems out of the box, much better even that on Windoze, which is why I'd much rather use NM when dealing with one of those.) However, it's not yet up-to-snuff (and possibly inferior) for servers or other "complicated" network setups, and it's maybe at "break even" for static setups.
I think we /should/ be pushing NM for "normal" use so it gets exposure and improves, but I agree that s-c-n and the if-scripts toolchains need to be maintained (at least for now) as they are still superior for some situations.
Matthew Woehlke wrote:
Ralf Corsepius wrote:
Actually, I feel s-c-network should be revived and NetworkManager be made strictly optional.
I'd actually have to disagree. I *love* NM on my Asus (netbook).
Congratulations.
For me, - NM doesn't work on any machine w/ WLAN - NM is just bloated ballast on machines w/o WLAN
It's great for laptops (or other computers that tend to move around and need to deal with "foreign" networks,
Seemingly it's sufficiently functional for some people in such situation. I don't have such demands.
especially wireless networks), and it's "okay" for desktops.
Yes, it works "sufficiently" on my desktops, but ... at which price? ... Instability caused by silly "dark magic", ... no cli ... no network profiles ... bloat
(For one, it handles Verizon CDMA modems out of the
box, much better even that on Windoze, which is why I'd much rather use NM when dealing with one of those.) However, it's not yet up-to-snuff (and possibly inferior) for servers or other "complicated" network setups, and it's maybe at "break even" for static setups.
My network isn't compliated (static IPs, static topologic, yp based autofs, DHCP).
It's just that NM can't handle it properly.
Ralf
On Tue, Mar 24, 2009 at 10:00 PM, Ralf Corsepius rc040203@freenet.de wrote:
Matthew Woehlke wrote:
Ralf Corsepius wrote:
Actually, I feel s-c-network should be revived and NetworkManager be made strictly optional.
I'd actually have to disagree. I *love* NM on my Asus (netbook).
Congratulations.
For me,
- NM doesn't work on any machine w/ WLAN
- NM is just bloated ballast on machines w/o WLAN
I believe you are in a very small minority with that view.
It's
great for laptops (or other computers that tend to move around and need to deal with "foreign" networks,
Seemingly it's sufficiently functional for some people in such situation. I don't have such demands.
It's more than functional for most people in most situations.
especially wireless networks), and it's "okay" for desktops.
Yes, it works "sufficiently" on my desktops, but ... at which price? ... Instability caused by silly "dark magic",
Oh please.
... no cli ... no network profiles
Both valid concerns.
... bloat
Made up over used word thrown around as as a subject non specific critic of any software someone doesn't like
My network isn't compliated (static IPs, static topologic, yp based autofs, DHCP). It's just that NM can't handle it properly.
Since I've been told that NM can handle static IPs now, i don't see why any of the above would be a problem.
Arthur Pemberton wrote:
On Tue, Mar 24, 2009 at 10:00 PM, Ralf Corsepius rc040203@freenet.de wrote:
Matthew Woehlke wrote:
Ralf Corsepius wrote:
Actually, I feel s-c-network should be revived and NetworkManager be made strictly optional.
I'd actually have to disagree. I *love* NM on my Asus (netbook).
Congratulations.
For me,
- NM doesn't work on any machine w/ WLAN
- NM is just bloated ballast on machines w/o WLAN
I believe you are in a very small minority with that view.
Please stop using this ole bolshevist argument. Just because you don't see a problem doesn't mean there isn't a problem.
It's
great for laptops (or other computers that tend to move around and need to deal with "foreign" networks,
Seemingly it's sufficiently functional for some people in such situation. I don't have such demands.
It's more than functional for most people in most situations.
especially wireless networks), and it's "okay" for desktops.
Yes, it works "sufficiently" on my desktops, but ... at which price? ... Instability caused by silly "dark magic",
Oh please.
... Yes, NM is responsible for pulling in dozens of unnecessary daemons/services.
... no cli ... no network profiles
Both valid concerns.
IMO, both hard show stoppers, disqualifying NM from being branded a replacement for s-c-networking.
... bloat
Made up over used word thrown around as as a subject non specific critic of any software someone doesn't like
Do yourself a favor and check how much bloat (and potential sources errors and vulnerabilities) NM pulls in.
In case you haven't noticed yet: In comparison to s-c-networking, this list is very long.
My network isn't compliated (static IPs, static topologic, yp based autofs, DHCP). It's just that NM can't handle it properly.
Since I've been told that NM can handle static IPs now, i don't see why any of the above would be a problem.
"told" is the key word ... reality speaks a different language.
The problem with it: Due to NM's black magic and the huge set of services it is trying to interact with, it's very difficult to identify the origin of problems.
One prominent and well-known case many people have complained about: NM's way of dns handling.
Ralf
Arthur Pemberton wrote:
On Tue, Mar 24, 2009 at 10:00 PM, Ralf Corsepius rc040203@freenet.de wrote:
Matthew Woehlke wrote:
Ralf Corsepius wrote:
Actually, I feel s-c-network should be revived and NetworkManager be made strictly optional.
I'd actually have to disagree. I *love* NM on my Asus (netbook).
Congratulations.
For me,
- NM doesn't work on any machine w/ WLAN
- NM is just bloated ballast on machines w/o WLAN
I believe you are in a very small minority with that view.
It's
great for laptops (or other computers that tend to move around and need to deal with "foreign" networks,
Seemingly it's sufficiently functional for some people in such situation. I don't have such demands.
It's more than functional for most people in most situations.
especially wireless networks), and it's "okay" for desktops.
Yes, it works "sufficiently" on my desktops, but ... at which price? ... Instability caused by silly "dark magic",
Oh please.
... no cli ... no network profiles
Both valid concerns.
... bloat
Made up over used word thrown around as as a subject non specific critic of any software someone doesn't like
Come on... :) A full-fledged daemon running all the time sitting on the system bus waking up every few seconds (to eat CPU) which is going to do
ifconfig eth0 111.111.111.111/24 up ip route add default via 111.111.111.222 echo "nameserver 111.111.111.123" > /etc/resolv.conf
And do it only *once* every reboot (which can easily be 30+ days).
This makes sense neither for servers nor for desktops. It's useful for laptops which travel a lot (not even all laptops, cause many of them are used as desktop-replacements).
What I'm asking for is to allow free choice, cause , you know, there is no such thing as "one true way", i.e. what is the only way in one situation may be completely useless and even stupid in another.
My network isn't compliated (static IPs, static topologic, yp based autofs, DHCP). It's just that NM can't handle it properly.
Since I've been told that NM can handle static IPs now, i don't see why any of the above would be a problem.
On Wed, Mar 25, 2009 at 1:37 AM, Suren Karapetyan surenkarapetyan@gmail.com wrote:
Arthur Pemberton wrote: Come on... :) A full-fledged daemon running all the time sitting on the system bus waking up every few seconds (to eat CPU) which is going to do
What exactly is a full-fledged daemon tha makes it bad things for servers or desktops? What amount of your CPU is it using that it is such a bad thing.
ifconfig eth0 111.111.111.111/24 up ip route add default via 111.111.111.222 echo "nameserver 111.111.111.123" > /etc/resolv.conf
And do it only *once* every reboot (which can easily be 30+ days).
This makes sense neither for servers nor for desktops.
Look, if you have a simple setup fine. I am all for everyone having their choice. But taking the tone that it is some bad thing or a waste of time is ridiculous. It makes sense on desktops unless they have a connection that cannot ever be severed, and do not use VPNs.
It's useful for laptops which travel a lot (not even all laptops, cause many of them are used as desktop-replacements).
It's useful for desktops as well.
What I'm asking for is to allow free choice, cause , you know, there is no such thing as "one true way", i.e. what is the only way in one situation may be completely useless and even stupid in another.
What's the point of asking for that when you can already turn NetworkManager off. If NetworkManager fills all the role provided by s-c-network, there's no point in having two ways to do the same thing. I started off by saying that there are several things that NetworkManager doesn't do yet so s-c-network shouldn't be removed yet.
Some of these things bring change and seem to make some people overly nervous, as long you can do things the old way, try not to block change that is useful to everyone else. It's just like PulseAudio, it helps a lot of people, but it works terribly for me, so I just removed it. No need to go complaining about its existence.
On Wednesday 25 March 2009 06:56:08 Arthur Pemberton wrote:
What's the point of asking for that when you can already turn NetworkManager off. If NetworkManager fills all the role provided by s-c-network, there's no point in having two ways to do the same thing. I started off by saying that there are several things that NetworkManager doesn't do yet so s-c-network shouldn't be removed yet.
The worry is that the "NM can replace this" argument is heading towards removal of the "old" way of doing things, and for a few people that's annoying. It is not a true replacement; it does very different things.
Some of these things bring change and seem to make some people overly nervous, as long you can do things the old way, try not to block change that is useful to everyone else. It's just like PulseAudio, it helps a lot of people, but it works terribly for me, so I just removed it. No need to go complaining about its existence.
We're not "complaining about its existence" we are objecting to it being forced as a "replacement" in all situations, even though it a) doesn't really support all those situations, and b) is unnecessary in at least some of them.
No one is "blocking change that is useful to everyone else", some people object to having this change forced on them ...
The "it still works" argument is disingenuous when the NM solution is being touted as a complete replacement for the "old" way, ... we're not stupid, we know the plan is to remove the "old" way of doing things completely. Some of us think this should be postponed until NM can *actually* be a replacement, and I for one would like it if NM would "get out of the way" ... I have a single wired ethernet connection on this machine, and no matter how much RAM I have, using some of it semi-permanently to support NM in the background is a waste.
Not saying you shouldn't have your NM, just want to be sure I won't be forced to use it :o)
On Wed, 2009-03-25 at 12:17 +0000, Bill Crawford wrote:
On Wednesday 25 March 2009 06:56:08 Arthur Pemberton wrote:
What's the point of asking for that when you can already turn NetworkManager off. If NetworkManager fills all the role provided by s-c-network, there's no point in having two ways to do the same thing. I started off by saying that there are several things that NetworkManager doesn't do yet so s-c-network shouldn't be removed yet.
The worry is that the "NM can replace this" argument is heading towards removal of the "old" way of doing things, and for a few people that's annoying. It is not a true replacement; it does very different things.
Some of these things bring change and seem to make some people overly nervous, as long you can do things the old way, try not to block change that is useful to everyone else. It's just like PulseAudio, it helps a lot of people, but it works terribly for me, so I just removed it. No need to go complaining about its existence.
We're not "complaining about its existence" we are objecting to it being forced as a "replacement" in all situations, even though it a) doesn't really support all those situations, and b) is unnecessary in at least some of them.
No one is "blocking change that is useful to everyone else", some people object to having this change forced on them ...
The "it still works" argument is disingenuous when the NM solution is being touted as a complete replacement for the "old" way, ... we're not stupid, we know the plan is to remove the "old" way of doing things completely. Some of us think this should be postponed until NM can *actually* be a replacement, and I for one would like it if NM would "get out of the way" ... I have a single wired ethernet connection on this machine, and no matter how much RAM I have, using some of it semi-permanently to support NM in the background is a waste.
Not saying you shouldn't have your NM, just want to be sure I won't be forced to use it :o)
I think there's some heat being generated here due to the fact that 'NetworkManager' is not a suitably specific term :)
From the discussion it appears that the 'Edit Connections' tool in
NetworkManager (nm-connection-editor) can perform some configuration tasks even if you are not actually using the NetworkManager daemon - i.e. it can configure the 'old school' /etc/sysconfig files. This is the sense in which NetworkManager can 'replace' s-c-n, I believe.
So what's really important is: what can s-c-n configure in the /etc/sysconfig system than nm-connection-editor cannot? All the (useful) functions in s-c-n have to be available in nm-connection-editor before s-c-n can safely be dropped. That's the real issue, I think.
I don't think anyone is proposing dropping the support for the 'network' service and /etc/sysconfig configuration files, so it's not really useful to discuss whether that's a good idea or not, since it isn't happening.
On Wednesday 25 March 2009 10:56:08 Arthur Pemberton wrote:
On Wed, Mar 25, 2009 at 1:37 AM, Suren Karapetyan
surenkarapetyan@gmail.com wrote:
Arthur Pemberton wrote: Come on... :) A full-fledged daemon running all the time sitting on the system bus waking up every few seconds (to eat CPU) which is going to do
What exactly is a full-fledged daemon tha makes it bad things for servers or desktops? What amount of your CPU is it using that it is such a bad thing.
2045 root 20 0 69236 2456 1920 S 0.0 0.1 0:01.98 NetworkManager 2058 root 20 0 74152 3964 3336 S 0.0 0.1 0:00.06 nm-system-setti NetworkManager wakes up every second and does a new poll syscall with 3 second timeout. 6MB of RAM, 15 open fds and 1/3 wakeup/s to do network management on a laptop which travels once it day is O.K. 6MB of RAM, 15 open fds and 1/3 wakeup/s to do absolutely nothing (e.g. server :) ) is bad. Of course it doesn't use much, and I'm sure it can be made to use even less. But there is no point in using any CPU/RAM/HDD at all if it isn't going to do you any good.
ifconfig eth0 111.111.111.111/24 up ip route add default via 111.111.111.222 echo "nameserver 111.111.111.123" > /etc/resolv.conf
And do it only *once* every reboot (which can easily be 30+ days).
This makes sense neither for servers nor for desktops.
Look, if you have a simple setup fine. I am all for everyone having their choice. But taking the tone that it is some bad thing or a waste of time is ridiculous. It makes sense on desktops unless they have a connection that cannot ever be severed, and do not use VPNs.
I'm also for everyone having their free choice and that's my main point. And I'm not saying that it's useless, I'm saying that sometimes it useless.
It's useful for laptops which travel a lot (not even all laptops, cause many of them are used as desktop-replacements).
It's useful for desktops as well.
The main part of it which is useful (and is different from simple script which runs dhclient) for desktop (with single connection) IMO is detecting if there is internet connection. Do I miss something big here.
What I'm asking for is to allow free choice, cause , you know, there is no such thing as "one true way", i.e. what is the only way in one situation may be completely useless and even stupid in another.
What's the point of asking for that when you can already turn NetworkManager off. If NetworkManager fills all the role provided by s-c-network, there's no point in having two ways to do the same thing. I started off by saying that there are several things that NetworkManager doesn't do yet so s-c-network shouldn't be removed yet.
What exactly are we talking about? Is it just NetworkManager/s-c-network, or does /etc/init.d/network have something to do with this too?
I'm almost sure it's the latter. If NM will be able to read /etc/sysconfig/network-scripts/ifcgf-*, do ifcfg/ip route stuff and quit I'll agree that it can replace s-c-network. But I'm sure it won't, cause we already have a program/script which does that... and there is no need to create a new one for the same job.
Some of these things bring change and seem to make some people overly nervous, as long you can do things the old way, try not to block change that is useful to everyone else. It's just like PulseAudio, it helps a lot of people, but it works terribly for me, so I just removed it. No need to go complaining about its existence.
I'm not trying to block changes (and I'm sure I can't) but it looks like others are trying to block the "old way". I use NetworkManager myself on my laptop, but I don't use it on my desktop, cause a) It *never* changes networks b) It bridges eth and wlan together.
And about PulseAudio :) I have the same problems with it as You do. It creates a lot of sound skipping/stopping/hanging and games not playing problems for me. It doesn't work at all on my laptop, but with F10 (and updates :) ) it became bearable on my desktop. So I'm using it (at least trying to) there. But even if it starts to work ideally on every machine I use, I still want to be able to use bare ALSA when I want so.
-- Fedora 9 : sulphur is good for the skin ( www.pembo13.com )
- recover bad hand written xorg.conf
- recover bad xorg.conf files generated by older versions of
proprietary nvidia drivers
rm -fv /etc/X11/xorg.conf
I already did
https://bugzilla.redhat.com/show_bug.cgi?id=465634
another one was with a brother who needed to pass some option to make cursors appear [it was an S3 Chrom VGA card] he needs xorg.conf file to save add this option
another case when I don't like 190000x160000 default resolution and I want a smooth entry from GDM, so I set both to the same resolution
Am Mittwoch, den 25.03.2009, 01:56 -0500 schrieb Arthur Pemberton:
It's useful for laptops which travel a lot (not even all laptops, cause many of them are used as desktop-replacements).
It's useful for desktops as well.
If your desktop is connected to the internet via ethernet, what is the use of NetworkManager? Or if the desktop is not connected to the internet at all, what's it's use?
Regards, Christoph
On Wed, 2009-03-25 at 18:09 +0100, Christoph Wickert wrote:
If your desktop is connected to the internet via ethernet, what is the use of NetworkManager? Or if the desktop is not connected to the internet at all, what's it's use?
Even when using Ethernet, I find it useful for initiating a VPN connection when I need it, or re-initiating a connection when the vpn drops for whatever reason.
Am Mittwoch, den 25.03.2009, 10:32 -0700 schrieb Jesse Keating:
On Wed, 2009-03-25 at 18:09 +0100, Christoph Wickert wrote:
If your desktop is connected to the internet via ethernet, what is the use of NetworkManager? Or if the desktop is not connected to the internet at all, what's it's use?
Even when using Ethernet, I find it useful for initiating a VPN connection when I need it, or re-initiating a connection when the vpn drops for whatever reason.
Agreed, but how many of our users are using VPN? 2%? 5%?
Regards, Christoph
On Wed, Mar 25, 2009 at 12:50 PM, Christoph Wickert christoph.wickert@googlemail.com wrote:
Am Mittwoch, den 25.03.2009, 10:32 -0700 schrieb Jesse Keating:
On Wed, 2009-03-25 at 18:09 +0100, Christoph Wickert wrote:
If your desktop is connected to the internet via ethernet, what is the use of NetworkManager? Or if the desktop is not connected to the internet at all, what's it's use?
Even when using Ethernet, I find it useful for initiating a VPN connection when I need it, or re-initiating a connection when the vpn drops for whatever reason.
Agreed, but how many of our users are using VPN? 2%? 5%?
Regards, Christoph
Possibly, but why make it hard for those 2% plus those that plug/unplug their desktop/routers., plus those with laptop, all because some guys don't want NM tickling their kernels every minute?
On Wednesday 25 March 2009 20:07:45 Arthur Pemberton wrote:
On Wed, Mar 25, 2009 at 12:50 PM, Christoph Wickert
christoph.wickert@googlemail.com wrote:
Am Mittwoch, den 25.03.2009, 10:32 -0700 schrieb Jesse Keating:
On Wed, 2009-03-25 at 18:09 +0100, Christoph Wickert wrote:
If your desktop is connected to the internet via ethernet, what is the use of NetworkManager? Or if the desktop is not connected to the internet at all, what's it's use?
Even when using Ethernet, I find it useful for initiating a VPN connection when I need it, or re-initiating a connection when the vpn drops for whatever reason.
Agreed, but how many of our users are using VPN? 2%? 5%?
Regards, Christoph
Possibly, but why make it hard for those 2% plus those that plug/unplug their desktop/routers., plus those with laptop, all because some guys don't want NM tickling their kernels every minute?
Noone is saying that.
I suspect some people might be thinking "why affect the 98% for the benefit of a handful of people who, if they are using a VPN, could probably manage to click on a button in an applet, or launch a command from a menu, or type something in order to bring up the VPN?" ...
I'd love to see an applet that let you go "hey, please start this interface". Oh, wait, we used to have one ...
Arthur Pemberton wrote:
Possibly, but why make it hard for those 2% plus those that plug/unplug their desktop/routers., plus those with laptop, all because some guys don't want NM tickling their kernels every minute?
Two words: battery life. (Or if you prefer, "power consumption". Useless process eating CPU are *bad*.)
Of course, the irony is that NM is most useful for the same systems where power consumption is of most concern :-).
On Wed, Mar 25, 2009 at 03:28:16PM -0500, Matthew Woehlke wrote:
Of course, the irony is that NM is most useful for the same systems where power consumption is of most concern :-).
Waking up once a minute has an insignificant impact on power consumption. Sure, it'd be nice if it could be avoided, but it's really not that important.
Once upon a time, Matthew Garrett mjg@redhat.com said:
Waking up once a minute has an insignificant impact on power consumption. Sure, it'd be nice if it could be avoided, but it's really not that important.
If it were only once per minute, it wouldn't be so bad. I see a lot more than that (on F10; I keep crashing rawhide anaconda so I haven't checked F11-to-be yet).
On Wed, Mar 25, 2009 at 09:44:46PM -0500, Chris Adams wrote:
Once upon a time, Matthew Garrett mjg@redhat.com said:
Waking up once a minute has an insignificant impact on power consumption. Sure, it'd be nice if it could be avoided, but it's really not that important.
If it were only once per minute, it wouldn't be so bad. I see a lot more than that (on F10; I keep crashing rawhide anaconda so I haven't checked F11-to-be yet).
Once you're down below once a second it's pretty much noise, assuming everything's using g_timeout_add_seconds.
On Wed, Mar 25, 2009 at 12:09 PM, Christoph Wickert christoph.wickert@googlemail.com wrote:
Am Mittwoch, den 25.03.2009, 01:56 -0500 schrieb Arthur Pemberton:
It's useful for laptops which travel a lot (not even all laptops, cause many of them are used as desktop-replacements).
It's useful for desktops as well.
If your desktop is connected to the internet via ethernet, what is the use of NetworkManager? Or if the desktop is not connected to the internet at all, what's it's use?
The same reason I first tried NetworkManager and got thoroughly burned... the base network script don't handle losing and resuming connections. Listen, I've been burned by NM in its early days, and I recognize that it isn't ready yet. I just don't support those who say that NM should be retired.
Arthur Pemberton wrote:
On Wed, Mar 25, 2009 at 12:09 PM, Christoph Wickert christoph.wickert@googlemail.com wrote:
Am Mittwoch, den 25.03.2009, 01:56 -0500 schrieb Arthur Pemberton:
It's useful for laptops which travel a lot (not even all laptops, cause many of them are used as desktop-replacements).
It's useful for desktops as well.
If your desktop is connected to the internet via ethernet, what is the use of NetworkManager? Or if the desktop is not connected to the internet at all, what's it's use?
The same reason I first tried NetworkManager and got thoroughly burned... the base network script don't handle losing and resuming connections. Listen, I've been burned by NM in its early days, and I recognize that it isn't ready yet. I just don't support those who say that NM should be retired.
Look, guys, there is a huge misunderstanding involved in every discussion about NM. Those who "protect" NM try to protect it in every situation. They are sure everyone who wants to use anything except NM want NM dead and buried face down. They always say that every "normal" person's use cases are covered by NM, and if it isn't good for you - you are stupid, you're on your own and you should burn in hell, and also you try to block changes which are good for everyone.
And those who "attack" NM (including me :) ) think (and I hope they are wrong) that "the others" (yep.. the ones from ABC's series :) ) are going to force them use something, which they don't want and it is going to cause them a lot of unbearable pain...
What I think everyone will agree with is that both NM and /etc/init.d/network have cons and pros and that both have their users. It's also clear that NM's features aren't super-set of "service network"'s and the opposite isn't true too. I also think there will be no objections if I say: One should always be able to setup everything he wants with ifconfig/iproute2 If You don't agree with it, think about a completely hosed system... Then do "ldd `which ifconfig`" and "ldd `which NetworkManager`" and guess which one has more chance to die because of a few bad blocks on the HDD.
If we put all this thoughts (which look like facts to me) together we get that it's possible and makes sense to maintain "service network" next to NM *forever*.
I think if we all can agree on the last sentence it will make all the future discussions much more constructive.
On Wednesday 25 March 2009 09:13:56 Matej Cepl wrote:
On 2009-03-25, 06:37 GMT, Suren Karapetyan wrote:
What I'm asking for is to allow free choice, cause , you know, there is no such thing as "one true way",
service NetworkManager stop chkconfig NetworkManager off chkconfig network on service network start
Yes, as long as that continues to be possible :o)
[ in other words, I have no problem with NM existing, although I think it's a big monster of complications that needn't be so ]
Matěj
On Tue, 24 Mar 2009 14:09:56 -0400 Bill Nottingham notting@redhat.com wrote:
Scott Tsai (scottt.tw@gmail.com) said:
- Only remove system-config-network when Fedora no longer ships
the old network configuration scripts like /etc/sysconfig/network-scripts/ifup and have NetworkManager totally take over.
NetworkManager's connection editor will (soon) be able to write to those files. Even if NM isn't in use, if it's writing the same data, to the same files, while being actually maintained more... I don't see why s-c-network would stay around.
Here's my short list of things I would like to see implemented before s-c-network goes away:
- bridging support in NM - command line configuration/management tool for nm (I would think this could just be a management tool and have some config file to change config, I don't care which).
Bill
kevin
"KF" == Kevin Fenzi writes:
[...]
KF> Here's my short list of things I would like to see implemented before KF> s-c-network goes away:
KF> - command line configuration/management tool for nm KF> (I would think this could just be a management tool and have some KF> config file to change config, I don't care which).
Yes, indeed, I agree this is must have before s-c-network goes away. Also a way of specifying wireless connections from the command-line and in text mode (e.g. a server with no GUI).
A way to select from available wireless ones in some kind of text-based modes is really needed, although this is currently not provided by s-c-network.
Alex
Alex Lancaster wrote:
"KF" == Kevin Fenzi writes:
[...]
KF> Here's my short list of things I would like to see implemented before KF> s-c-network goes away:
And support for analog ppp dialup:
https://bugzilla.redhat.com/show_bug.cgi?id=486671
On Tue, 2009-03-24 at 17:04 +0000, Scott Tsai wrote:
- Only remove system-config-network when Fedora no longer ships the old
network configuration scripts like /etc/sysconfig/network-scripts/ifup and have NetworkManager totally take over.
For system-wide configs, those scritps need to stick around; NM integration of those will be addressed by using netcf, which encapsulates all the headaches with what files to change to set up a bond etc.
David
On Tue, 24 Mar 2009 18:53:39 +0000, David Lutterkort wrote:
For system-wide configs, those scritps need to stick around; NM integration of those will be addressed by using netcf, which encapsulates all the headaches with what files to change to set up a bond etc.
This implies that unless the traditional network configuration initscripts are taught to configure WPA and 3G modems those kind of connections could never be system-wide though?
I was hoping that sharing internet connection through a 3G modem "system- wide" (i.e. from a box where I never login locally) would eventually be supported.
On Tue, 2009-03-24 at 17:10 +0100, Jaroslav Reznik wrote:
- system-config-display
- xrandr should be used for resolution/dualhead configuration, Gnome & KDE
have own xrandr based display configuration tool
Only for RandR 1.2-based drivers, note. Although as of F11 we should be shipping RandR 1.2 drivers for the three major card types by default for the first time (radeon, nouveau, intel).
- system-config-network
- replacement NetworkManager
- missing IPv6? routing?
Quite a lot of people still don't want to use NetworkManager. It makes little sense on a system which just sits there connected to a static IP address 24/7.
On Tue, Mar 24, 2009 at 1:16 PM, Adam Williamson awilliam@redhat.com wrote:
Quite a lot of people still don't want to use NetworkManager. It makes little sense on a system which just sits there connected to a static IP address 24/7.
I think it does because it provides a useful networking API for other applications to consume. For example, answering the question "is there an active network link" was effectively impossible for app authors before.
Also, in my opinion on a well-managed network if you want a fixed IP address, the right way to do it is MAC matching on the DHCP server, not client configuration. And NetworkManager works well in such a setup.
On Tue, Mar 24, 2009 at 12:38 PM, Colin Walters walters@verbum.org wrote:
On Tue, Mar 24, 2009 at 1:16 PM, Adam Williamson awilliam@redhat.com wrote:
[ snip ]
Also, in my opinion on a well-managed network if you want a fixed IP address, the right way to do it is MAC matching on the DHCP server, not client configuration. And NetworkManager works well in such a setup.
Sometimes you just want to enter an IP address manually. This shouldn't be considered some extra special case.
On Tuesday 24 March 2009 18:43:55 Arthur Pemberton wrote:
On Tue, Mar 24, 2009 at 12:38 PM, Colin Walters walters@verbum.org wrote:
On Tue, Mar 24, 2009 at 1:16 PM, Adam Williamson awilliam@redhat.com wrote:
[ snip ]
Also, in my opinion on a well-managed network if you want a fixed IP address, the right way to do it is MAC matching on the DHCP server, not client configuration. And NetworkManager works well in such a setup.
Sometimes you just want to enter an IP address manually. This shouldn't be considered some extra special case.
You can enter IP manually in nm-applet too, so it's same (sorry, I've never tried it but is seems to be there).
Jaroslav
-- Fedora 9 : sulphur is good for the skin ( www.pembo13.com )
Arthur Pemberton wrote:
On Tue, Mar 24, 2009 at 12:38 PM, Colin Walters walters@verbum.org wrote:
Sometimes you just want to enter an IP address manually. This shouldn't be considered some extra special case.
(In Gnome) System -> Administration -> Network Select network device -> Edit 'General' tab -> 'Statically Set IP Addresses:'
Worked flawlessly for me when I had to use my laptop as a tftp server to fix my broken openwrt router.
Lyos Gemini Norezel
Lyos Gemini Norezel schrieb:
Arthur Pemberton wrote:
On Tue, Mar 24, 2009 at 12:38 PM, Colin Walters walters@verbum.org wrote: Sometimes you just want to enter an IP address manually. This shouldn't be considered some extra special case.
(In Gnome) System -> Administration -> Network Select network device -> Edit 'General' tab -> 'Statically Set IP Addresses:'
Worked flawlessly for me when I had to use my laptop as a tftp server to fix my broken openwrt router.
Lyos Gemini Norezel
this is in fact system-config-network :-)
On Tuesday 24 March 2009 18:38:40 Colin Walters wrote:
On Tue, Mar 24, 2009 at 1:16 PM, Adam Williamson awilliam@redhat.com
wrote:
Quite a lot of people still don't want to use NetworkManager. It makes little sense on a system which just sits there connected to a static IP address 24/7.
I think it does because it provides a useful networking API for other applications to consume. For example, answering the question "is there an active network link" was effectively impossible for app authors before.
Yes, this make sense and it's really quite useful - applications know current network state. So now we should collect what is still missing in NM and what do we really need to have.
Also, in my opinion on a well-managed network if you want a fixed IP address, the right way to do it is MAC matching on the DHCP server, not client configuration. And NetworkManager works well in such a setup.
+1, but there are still devices that don't allow this (as my ADSL router, I can only have random IP, no MAC binding available).
Jaroslav
Colin Walters wrote:
On Tue, Mar 24, 2009 at 1:16 PM, Adam Williamson awilliam@redhat.com wrote:
Quite a lot of people still don't want to use NetworkManager. It makes little sense on a system which just sits there connected to a static IP address 24/7.
I think it does because it provides a useful networking API for other applications to consume. For example, answering the question "is there an active network link" was effectively impossible for app authors before.
I'm not quite sure squid/httpd/dhcpd/samba/... cares about network link. The programs which check link availability are usually (always?) desktop programs.
Also, in my opinion on a well-managed network if you want a fixed IP address, the right way to do it is MAC matching on the DHCP server, not client configuration. And NetworkManager works well in such a setup.
Yes that makes sense for any 10+ workstations network. But it doesn't make sense for the 2-3 servers which serve that network, cause they usually *never* have their ips changed.
So again this makes sense only for desktops (and of course much more sense for laptops) but is mostly useless for servers. And also /etc/init.d/network with dhclient also works quite well in this setup.
What I wanted to say is "Removing old ifcfg-style network configuration support is wrong".
Colin Walters píše v Út 24. 03. 2009 v 13:38 -0400:
On Tue, Mar 24, 2009 at 1:16 PM, Adam Williamson awilliam@redhat.com wrote:
Quite a lot of people still don't want to use NetworkManager. It makes little sense on a system which just sits there connected to a static IP address 24/7.
I think it does because it provides a useful networking API for other applications to consume. For example, answering the question "is there an active network link" was effectively impossible for app authors before.
There are situations when you don't want any reaction on link up/down events.
Also, in my opinion on a well-managed network if you want a fixed IP address, the right way to do it is MAC matching on the DHCP server, not client configuration. And NetworkManager works well in such a setup.
It really depends on situation, but staticly assigned IPs (without DHCP) are usually prefered in server deployments.
Dan
On Tuesday 24 March 2009 17:38:40 Colin Walters wrote:
Also, in my opinion on a well-managed network if you want a fixed IP address, the right way to do it is MAC matching on the DHCP server, not client configuration. And NetworkManager works well in such a setup.
You're entitled to your opinion, but not everyone wants to have to set up DHCP, and not everyone wants to have to go their sysadmin and request configuration changes to the corporate DHCP server just to change some piece of configuration FOR THEIR LOCAL MACHINE with all the annoyance to the sysadmin, timewasting for me, and so on.
It used to be nice and simple; you put the DNS server(s) in /etc/resolv.conf or in /etc/sysconfig/network-scripts/eth0, you got a network connection when the system booted.
It's not always correct to remove the DNS settings from /etc/resolv.conf when you shut the machine down; I disabled NM on my rawhide test install because I could no longer chroot into it from my older system and run "yum" to update (or a number of other things) due to "host not found" errors.
NetworkManager may "work" well in some setups; it's just annoying to see it touted as a panacæa when it plainly isn't handling a lot of nice simple setups at all well.
On Tuesday 24 March 2009 17:38:40 Colin Walters wrote:
Also, in my opinion on a well-managed network if you want a fixed IP address, the right way to do it is MAC matching on the DHCP server, not client configuration. And NetworkManager works well in such a setup.
What happens when you replace your network card, btw?
On Tue, 2009-03-24 at 18:04 +0000, Bill Crawford wrote:
On Tuesday 24 March 2009 17:38:40 Colin Walters wrote:
Also, in my opinion on a well-managed network if you want a fixed IP address, the right way to do it is MAC matching on the DHCP server, not client configuration. And NetworkManager works well in such a setup.
What happens when you replace your network card, btw?
You reassign the IP address to the new MAC address. I use a script that allows me to set an IP address and hostname to a MAC address with a single command (it updates both bind and dhcpd).
At the school I work at, we used to run our network with static (set on the client side) IP addresses. A couple of years ago, we made the switch over to DHCP with the "static" IP address coming from the server, and it's made life much easier. We've found that we image/update the computers far more than we ever change network cards.
Jonathan
Colin Walters wrote:
Also, in my opinion on a well-managed network if you want a fixed IP address, the right way to do it is MAC matching on the DHCP server, not client configuration.
I disagree. I want to be able to configure boxes to match DNS entries without also having to fiddle with the DHCP configuration. (Besides, what if the NIC goes bad? It's easier to just swap it out and continue running the old config on the new hardware than to have to update DHCP.)
In the instance where the machine admins are also the network admins, I tend to agree (and in fairness that's how I run my home network), but when the machine admins are in a totally separate group (and, for that matter, thousands of miles geographically displaced as well) it doesn't work so well. (In such cases, it sometimes ends up you have to ask people to memorize IP addresses until IT gets around to fixing DNS, never mind trying to get them to manage static DHCP leases as well.)
Colin Walters wrote:
Also, in my opinion on a well-managed network if you want a fixed IP address, the right way to do it is MAC matching on the DHCP server, not client configuration. And NetworkManager works well in such a setup.
Aside from the other reasons I mentioned (which I notice Bill Crawford echoed), I'd point out that you still need to statically assign the IP /for the DHCP server/ ;-).
(Yes I know it was said elsewhere NM is supposed to handle static IP's... just pointing out why it *must* be able to do so if you expect to use it to replace the if* scripts.)
On Tue, 24 Mar 2009, Colin Walters wrote:
On Tue, Mar 24, 2009 at 1:16 PM, Adam Williamson awilliam@redhat.com wrote:
Quite a lot of people still don't want to use NetworkManager. It makes little sense on a system which just sits there connected to a static IP address 24/7.
I think it does because it provides a useful networking API for other applications to consume. For example, answering the question "is there an active network link" was effectively impossible for app authors before.
Also, in my opinion on a well-managed network if you want a fixed IP address, the right way to do it is MAC matching on the DHCP server, not client configuration. And NetworkManager works well in such a setup.
Which I guess is OK if you are not setting up the system with the dhcp server AND the box you are setting up has X installed. Does NM have a command line interface? Not that I have seen but I could have missed it.
Regards,
On Tue, Mar 24, 2009 at 03:31:09PM -0400, Tom Diehl wrote:
On Tue, 24 Mar 2009, Colin Walters wrote:
On Tue, Mar 24, 2009 at 1:16 PM, Adam Williamson awilliam@redhat.com wrote:
Quite a lot of people still don't want to use NetworkManager. It makes little sense on a system which just sits there connected to a static IP address 24/7.
I think it does because it provides a useful networking API for other applications to consume. For example, answering the question "is there an active network link" was effectively impossible for app authors before.
Also, in my opinion on a well-managed network if you want a fixed IP address, the right way to do it is MAC matching on the DHCP server, not client configuration. And NetworkManager works well in such a setup.
Which I guess is OK if you are not setting up the system with the dhcp server AND the box you are setting up has X installed. Does NM have a command line interface? Not that I have seen but I could have missed it.
NM supports static IP addresses configured in /etc/sysconfig/network-scripts/ifcfg-ethX, or you could enable the keyfile plugin to use INI-like files to specify network configuration. If you set ONBOOT=yes, you don't even need to interact with NM in any way--it should just work. If you need to wait for the network before continuing the system boot up, set NETWORKWAIT=yes in /etc/sysconfig/network.
So basically, the no-X argument isn't convincing to me, because you can still do the basic stuff the old non-X way and it works.
However, there is an argument for not getting rid of the old network scripts. The following are supported with network scripts but not NM yet:
1. IPv6 2. bridges 3. interface aliases
..and probably more.
On Tue, 24 Mar 2009, Chuck Anderson wrote:
On Tue, Mar 24, 2009 at 03:31:09PM -0400, Tom Diehl wrote:
On Tue, 24 Mar 2009, Colin Walters wrote:
On Tue, Mar 24, 2009 at 1:16 PM, Adam Williamson awilliam@redhat.com wrote:
Quite a lot of people still don't want to use NetworkManager. It makes little sense on a system which just sits there connected to a static IP address 24/7.
I think it does because it provides a useful networking API for other applications to consume. For example, answering the question "is there an active network link" was effectively impossible for app authors before.
Also, in my opinion on a well-managed network if you want a fixed IP address, the right way to do it is MAC matching on the DHCP server, not client configuration. And NetworkManager works well in such a setup.
Which I guess is OK if you are not setting up the system with the dhcp server AND the box you are setting up has X installed. Does NM have a command line interface? Not that I have seen but I could have missed it.
NM supports static IP addresses configured in /etc/sysconfig/network-scripts/ifcfg-ethX, or you could enable the keyfile plugin to use INI-like files to specify network configuration. If you set ONBOOT=yes, you don't even need to interact with NM in any way--it should just work. If you need to wait for the network before continuing the system boot up, set NETWORKWAIT=yes in /etc/sysconfig/network.
Well maybe I mis-understood then. I thought /etc/sysconfig/network-scripts/ifcfg-ethX was going away. If that is incorrect then I do not understand what all of the complaining is about.
So basically, the no-X argument isn't convincing to me, because you can still do the basic stuff the old non-X way and it works.
However, there is an argument for not getting rid of the old network scripts. The following are supported with network scripts but not NM yet:
- IPv6
- bridges
- interface aliases
But the current scripts in /etc/sysconfig/network-scripts/ do this now If you say they are not going away then rpm -e NM* and you have what you have today when you do not install X. Works for me for the last 15 years or so. I will admit I do like nm on my laptop but NOT on my servers.
Seriously, what am I missing?
Regards,
On Wednesday 25 March 2009 04:08:11 Tom Diehl wrote:
On Tue, 24 Mar 2009, Chuck Anderson wrote:
On Tue, Mar 24, 2009 at 03:31:09PM -0400, Tom Diehl wrote:
On Tue, 24 Mar 2009, Colin Walters wrote:
On Tue, Mar 24, 2009 at 1:16 PM, Adam Williamson awilliam@redhat.com
wrote:
Quite a lot of people still don't want to use NetworkManager. It makes little sense on a system which just sits there connected to a static IP address 24/7.
I think it does because it provides a useful networking API for other applications to consume. For example, answering the question "is there an active network link" was effectively impossible for app authors before.
Also, in my opinion on a well-managed network if you want a fixed IP address, the right way to do it is MAC matching on the DHCP server, not client configuration. And NetworkManager works well in such a setup.
Which I guess is OK if you are not setting up the system with the dhcp server AND the box you are setting up has X installed. Does NM have a command line interface? Not that I have seen but I could have missed it.
NM supports static IP addresses configured in /etc/sysconfig/network-scripts/ifcfg-ethX, or you could enable the keyfile plugin to use INI-like files to specify network configuration. If you set ONBOOT=yes, you don't even need to interact with NM in any way--it should just work. If you need to wait for the network before continuing the system boot up, set NETWORKWAIT=yes in /etc/sysconfig/network.
Well maybe I mis-understood then. I thought /etc/sysconfig/network-scripts/ifcfg-ethX was going away. If that is incorrect then I do not understand what all of the complaining is about.
Network-scripts are part of initscripts, s-c-n is only TUI/GUI configuration tool. So these scripts stays until something better is designed (I'm not sure how netcf - mentioned in this thread - works).
If we have another tool that's able to edit configuration and use network- scripts then it's nonsense to have both doing same. So now the question is what's missing in NM edit connections (not in standalone NM) and if it is worth to add it there or let it alone in s-c-n or only let possibility to do it manually (and for servers it's my preferred way to have control over configuration).
Jaroslav
So basically, the no-X argument isn't convincing to me, because you can still do the basic stuff the old non-X way and it works.
However, there is an argument for not getting rid of the old network scripts. The following are supported with network scripts but not NM yet:
- IPv6
- bridges
- interface aliases
But the current scripts in /etc/sysconfig/network-scripts/ do this now If you say they are not going away then rpm -e NM* and you have what you have today when you do not install X. Works for me for the last 15 years or so. I will admit I do like nm on my laptop but NOT on my servers.
Seriously, what am I missing?
Regards,
-- Tom Diehl tdiehl@rogueind.com Spamtrap address mtd123@rogueind.com
On Tue, 2009-03-24 at 10:16 -0700, Adam Williamson wrote:
On Tue, 2009-03-24 at 17:10 +0100, Jaroslav Reznik wrote:
- system-config-display
- xrandr should be used for resolution/dualhead configuration, Gnome & KDE
have own xrandr based display configuration tool
Only for RandR 1.2-based drivers, note. Although as of F11 we should be shipping RandR 1.2 drivers for the three major card types by default for the first time (radeon, nouveau, intel).
- system-config-network
- replacement NetworkManager
- missing IPv6? routing?
Quite a lot of people still don't want to use NetworkManager. It makes little sense on a system which just sits there connected to a static IP address 24/7.
NM also doesn't write out ifcfg files, which s-c-n is still pretty good at. I hope to land that functionality for F11, but I think s-c-n still has one release left in it, at least. Doesn't hurt to keep both around, as long as the cooperate with each other (something I'll be working on too). Maybe just don't install it by default when NM is installed by default, but keep it available.
Dan
-- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net
Jaroslav Reznik wrote:
- system-config-display
- xrandr should be used for resolution/dualhead configuration, Gnome & KDE
have own xrandr based display configuration tool
- generates xorg.conf - it's not needed anymore (only if someone needs more expert configuration)
At least this machine needs an xorg.conf, I think the one of my home machines does also.
I'd vote to keep this as a tool to generate a decent starting point for an xorg.conf that needs to be hand-edited, as opposed to having to write one from scratch (which, frankly, sucks, especially things like getting monitor refresh rates correct).
Bill pointed out that this is not installed by default, which is fine. I'd say we should keep it that way; available and working for those that need it, but not installed by default.
- system-config-network
- replacement NetworkManager
- missing IPv6? routing?
What about machines not using NM? (Like, again, this one and one of my home machines...) As with s-c-display, it's useful for not having to hand-write configs (or at least to generate good starting points). It should probably not be installed when NM is being used, though, so 'not installed by default' except on non-NM-using spins (if there are any).
For this machine, I'm running custom ifup scripts in order to set up a TUN bridge, so "eth0" is just the hardware with no address and the local processes actually use br0. (tap0 is fed to qemu as a virtual hardware device, so the box has multiple IP's, one of which is "owned" by the VM.) Can NM handle that yet?
- system-config-date
- Gnome/KDE/XFCE have own datetime configuration tool/module, it's confusing
than which one users should use
- used in firstboot or anaconda???
...and s-c-date conflicts with these. What manages the ntp service? I don't think I've had any luck with the KDE date config working correctly at system level, which means if s-c-date went away I'd have to manage the date/time on my machine(s) at CLI level and by editing ntpd.conf by hand.
On Tue, 2009-03-24 at 13:21 -0500, Matthew Woehlke wrote:
For this machine, I'm running custom ifup scripts in order to set up a TUN bridge, so "eth0" is just the hardware with no address and the local processes actually use br0. (tap0 is fed to qemu as a virtual hardware device, so the box has multiple IP's, one of which is "owned" by the VM.) Can NM handle that yet?
No, but that's such a common setup that both libvirt and NM will support it in the near future (via netcf).
David
Matthew Woehlke wrote:
...and s-c-date conflicts with these. What manages the ntp service? I don't think I've had any luck with the KDE date config working correctly at system level, which means if s-c-date went away I'd have to manage the date/time on my machine(s) at CLI level and by editing ntpd.conf by hand.
Uh, the KDE date configuration tool is intended to work at system level (and at system level ONLY), it's one of the few System Settings modules requiring root privileges for a reason.
Kevin Kofler
On Tue, 2009-03-24 at 17:10 +0100, Jaroslav Reznik wrote:
- system-config-netboot
- very outdated
- replacements k12linux, cobbler
Heh, yeah, the shortcomings of this were the inspiration for cobbler.
- system-config-boot
- at least it needs facelift and it's not very usable at all
And should probably use Augeas in the backend.
- system-config-network
- replacement NetworkManager
- missing IPv6? routing?
If a tool like this is needed at all (though NM should really just absorb the functionality), the backend should be based on netcf[1]
David
[1] Currently at http://people.redhat.com/dlutter/netcf, but I'll move it to fedorahosted any day now, and actually make a release. The intent is to have netcf as a distro-agnostic backend for network configuration that can be used by at least libvirt and NM
2009/3/24 Jaroslav Reznik jreznik@redhat.com:
Hi all (interested in system config tools;-). We are working on System Configurations Tools Cleanup Project we need Fedora community opinion on this subject.
Some s-c-* tools are now very outdated, some are replaced with better solution, some are only used in Anaconda etc.
This is a short list of application that could be eliminated/replaced/enhanced in short/long term from Fedora.
I've prepared it simple and clean to support further discussion, maybe some other tool is missing...
- system-config-netboot
- very outdated - replacements k12linux, cobbler
could be removed.
- system-config-boot
- at least it needs facelift and it's not very usable at all
- system-config-display
- xrandr should be used for resolution/dualhead configuration, Gnome & KDE have own xrandr based display configuration tool - generates xorg.conf - it's not needed anymore (only if someone needs more expert configuration)
or someone has issues with the automatic detection or wants to use nvidia binary drivers (which have a file overlay). or needs to switch driver to vesa if drivers are broken or or or or... i wouldnt call that expert stuff. more things you still need to do in some cases.
- system-config-network
- replacement NetworkManager - missing IPv6? routing?
system-config-network has a text user interface. networkmanager is still lacking a proper way to be configured or used from a terminal as it is. still required e.g. for system troubleshooting and system rescue ... e.g. if X doesent start you cant enable or manage your interfaces properly. most endusers cant handle the textfiles and therefore wouldnt even be able to configure an interface manually to get the updates that makes things start again. (not like friends of mine didnt have those issues before)
- system-config-date
- Gnome/KDE/XFCE have own datetime configuration tool/module, it's confusing than which one users should use - used in firstboot or anaconda???
as long as those tool properly configure ntp... in the gnome date applet i cant find any ntp options.
- system-config-keyboard
- used only in Anaconda, let it be standalone? - very simple tool, Gnome/KDE have better one
system wide config tool yet missing?
- system-config-httpd
- old GTK 1 application, should be ported to GTK 2 & PolicyKit
+1
- switchdesk and system-switch-tools?
- it's possible to switch desktop in GDM/KDM - one tool for switching all alternatives?
atleast the nonui script can still be useful to some degree.
there is another one i have to add:
system-config-cluster:
doesent start since 2 years because of a pam error... maintainer doesent respond to bugs at all... is pretty buggy. but doesent have a replacement (ricci is in the true... but lucy still cant go in because of the zope problem since years now)
Expect more spam from us regarding cleanup project - we already have s-c-* tools reviews, so we will fill bugs soon (with some guidelines on list), nearly all s-c-* tools need to be ported to PolicyKit and so on ;-)
Happy system config tools hacking System Config Cleanup Team
-- Jaroslav Řezník jreznik@redhat.com Associate Software Engineer - Base Operating Systems Brno
Office: +420 532 294 275 Mobile: +420 731 455 332 Red Hat, Inc. http://cz.redhat.com/
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Matthias Clasen wrote:
On Tue, 2009-03-24 at 20:03 +0100, Rudolf Kastl wrote:
as long as those tool properly configure ntp... in the gnome date applet i cant find any ntp options.
NTP doesn't need any configuration UI, it just needs to be on by default.
Wrong.
Keywords: Firewall, dedicated local ntpd-servers.
Ralf
On Wed, 2009-03-25 at 18:49 +0100, Ralf Corsepius wrote:
Matthias Clasen wrote:
On Tue, 2009-03-24 at 20:03 +0100, Rudolf Kastl wrote:
as long as those tool properly configure ntp... in the gnome date applet i cant find any ntp options.
NTP doesn't need any configuration UI, it just needs to be on by default.
Wrong.
Keywords: Firewall, dedicated local ntpd-servers.
Statistically speaking, 0% of the endpoints on the internet are ntpd servers.
- ajax
On Thu, Mar 26, 2009 at 10:12:21AM -0400, Adam Jackson wrote:
On Wed, 2009-03-25 at 18:49 +0100, Ralf Corsepius wrote:
Matthias Clasen wrote:
On Tue, 2009-03-24 at 20:03 +0100, Rudolf Kastl wrote:
as long as those tool properly configure ntp... in the gnome date applet i cant find any ntp options.
NTP doesn't need any configuration UI, it just needs to be on by default.
Wrong.
Keywords: Firewall, dedicated local ntpd-servers.
Statistically speaking, 0% of the endpoints on the internet are ntpd servers.
We also need to fix ntpdate so that it waits for the network to be available before attempting to set the clock. Using NetworkManager NETWORKWAIT=yes doesn't help here.
On Wed, 2009-03-25 at 13:40 -0400, Matthias Clasen wrote:
On Tue, 2009-03-24 at 20:03 +0100, Rudolf Kastl wrote:
as long as those tool properly configure ntp... in the gnome date applet i cant find any ntp options.
NTP doesn't need any configuration UI, it just needs to be on by default.
Because NTP servers just love it when you have ten machines updating from one IP. Even Windows XP lets you easily enter in your own NTP server.
... What I really want is an easy "Multicast client" checkbox. Right now to configure multicast I seem to have to manually edit ntp.conf which seems to get clobbered occasionally. I run a local NTP server off my MythTV box, since it needs to have accurate time anyway.
On Thu, 2009-03-26 at 00:51 -0500, Callum Lerwick wrote:
... What I really want is an easy "Multicast client" checkbox. Right now to configure multicast I seem to have to manually edit ntp.conf
Would you please open a bug/RFE for that against s-c-date?
which seems to get clobbered occasionally.
What gets/how does it get clobbered?
I run a local NTP server off my MythTV box, since it needs to have accurate time anyway.
Thanks, Nils
Rudolf Kastl wrote:
2009/3/24 Jaroslav Reznik jreznik@redhat.com:
- system-config-date
- Gnome/KDE/XFCE have own datetime configuration tool/module, it's
confusing than which one users should use
- used in firstboot or anaconda???
as long as those tool properly configure ntp... in the gnome date applet i cant find any ntp options.
KDE's System Settings date/time module supports NTP.
Kevin Kofler
On Tue, 2009-03-24 at 17:10 +0100, Jaroslav Reznik wrote:
- system-config-date
- Gnome/KDE/XFCE have own datetime configuration tool/module, it's confusing
than which one users should use
- as they (should) operate on the same low-level resources (/bin/date, /sbin/hwclock, /etc/localtime) it shouldn't really matter much which is used - the DE specific things should be much more visible than s-c-date (i.e. directly in the panel vs. some levels deep in the menu), I don't see much source for confusion there - AFAIK, none of the tools in the DEs deal with NTP right now (do they at least honor it being used and then block setting the system clock?), so I'm not inclined to drop it
- used in firstboot or anaconda???
yes
Nils
Nils Philippsen wrote:
- AFAIK, none of the tools in the DEs deal with NTP right now (do they
at least honor it being used and then block setting the system clock?), so I'm not inclined to drop it
KDE actually does.
That said, it doesn't detect an NTP setup configured with system-config-date, it shows NTP as not in use. It also only supports selecting a server from a list or entering a server into the combobox, no multiple servers, no advanced options.
Kevin Kofler
2009/3/27 Kevin Kofler kevin.kofler@chello.at:
Nils Philippsen wrote:
- AFAIK, none of the tools in the DEs deal with NTP right now (do they
at least honor it being used and then block setting the system clock?), so I'm not inclined to drop it
KDE actually does.
That said, it doesn't detect an NTP setup configured with system-config-date, it shows NTP as not in use. It also only supports selecting a server from a list or entering a server into the combobox, no multiple servers, no advanced options.
proper ntp setups require atleast 3 servers to be set. (proper tuning various more things.)
regards, Rudolf Kastl
Kevin Kofler
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
On Fri, 2009-03-27 at 23:53 +0100, Kevin Kofler wrote:
Nils Philippsen wrote:
- AFAIK, none of the tools in the DEs deal with NTP right now (do they
at least honor it being used and then block setting the system clock?), so I'm not inclined to drop it
KDE actually does.
That said, it doesn't detect an NTP setup configured with system-config-date, it shows NTP as not in use.
I haven't looked at the tool/applet in question, but to me this seems more problematic than not caring about NTP at all. I guess KDE stores the setting whether NTP is used or not in some KDE configuration place? It's probably a bit more work to operate with the actual OS setting which might be implemented in very different ways on the various OSs where KDE is deployed (Linux distros, other Unixes, ...), but if you want I can try to help out with that so that it can be done properly on the OSs where we know how to do it. I imagine it like this piece of pseudo code:
if system is LSB compliant use LSB functions to check for status/start/stop NTP (/usr/lib/lsb/{install,remove}_initd, calling /etc/init.d scripts directly) else if system has /sbin/chkconfig, /sbin/service use chkconfig, service to check for status/start/stop NTP else if (yet another way to do it) (do it yet another way) else if ... ... else don't bother
Naturally, this would have to take the various names of NTP init scripts into account (e.g. "ntp" vs. "ntpd"). It also shouldn't matter much if the above decisions are made during build- or runtime. The various OS teams would then be responsible to keep their part of this up to date.
Nils
On Tue, 2009-03-24 at 17:10 +0100, Jaroslav Reznik wrote:
- system-config-network
- replacement NetworkManager
- missing IPv6? routing?
Not my turf, but I'll comment anyway. IMO, some things need to happen before NM could be used everywhere from a functionality POV (not addressing bloat here ;-), here's what I think of right now:
- it needs to support an arbitrary number of interfaces up at the same time (i.e. multiple LANs/WLANs/VPNs simultaneously) - it needs to support arbitrarily complicated routing setups, if I'm connected to two VPNs at the same time it better do that right - It should (optionally) not immediately kill off interfaces with dropped links - DNS handling needs to be improved a great deal, e.g. use private DNS server for home LAN, use VPN DNS server for their respective addresses _only_ (e.g. for specific domains/IP ranges)
Nils
Am Dienstag, den 24.03.2009, 17:10 +0100 schrieb Jaroslav Reznik:
- system-config-date
- Gnome/KDE/XFCE have own datetime configuration tool/module, it's confusing
than which one users should use
Xfce does _not_ have a date time configuration tool.
- system-config-keyboard
- used only in Anaconda, let it be standalone?
- very simple tool, Gnome/KDE have better one
So has Xfce, but LXDE and others haven't.
- switchdesk and system-switch-tools?
- it's possible to switch desktop in GDM/KDM
- one tool for switching all alternatives?
Yes please, as not everybody wants to use GDM/KDM. The tool needs to be extensible for new desktops, currently this is hardcoded.
Regards, Christoph
On Tue, Mar 24, 2009 at 12:10 PM, Jaroslav Reznik wrote:
- system-config-keyboard
- used only in Anaconda, let it be standalone? - very simple tool, Gnome/KDE have better one
I'm constantly using this. Something in Fedora changes my Fedora layout to Arabic on each login, for some reason. I couldn't figure out why this is happening but the only solution is to run system-config-keyboard and pick US English for me. KDE's configuration GUI does not help at all.
Orcan
onsdagen den 25 mars 2009 skrev Orcan Ogetbil:
On Tue, Mar 24, 2009 at 12:10 PM, Jaroslav Reznik wrote:
- system-config-keyboard
- used only in Anaconda, let it be standalone? - very simple tool, Gnome/KDE have better one
I'm constantly using this. Something in Fedora changes my Fedora layout to Arabic on each login, for some reason. I couldn't figure out why this is happening but the only solution is to run system-config-keyboard and pick US English for me. KDE's configuration GUI does not help at all.
I had that problem for several weeks, except that the system seemed to think I had a US keyboard and I had to set it to Swedish on each login. The first thing I did was to check if there was a system-config-keyboard. There was, and it did the job, so I never looked for a KDE tool. (It might have been a bit difficult if I hadn't known to press [+] to type "-".)
The problem seems to have gone away about a week ago.
Björn Persson
On Di März 24 2009, Jaroslav Reznik wrote:
- system-config-date
- Gnome/KDE/XFCE have own datetime configuration tool/module, it's
confusing than which one users should use
- used in firstboot or anaconda???
- system-config-keyboard
- used only in Anaconda, let it be standalone?
- very simple tool, Gnome/KDE have better one
Do the Gmone/KDE/Whatever tools really know / configure /etc/sysconfig/keyboard and /etc/sysconfig/clock?
I remember using system-config-keyboard a lot with live media btw.
Regards, Till
devel@lists.stg.fedoraproject.org