Re: [Mageia-dev] Proposal: Deprecate draknetcenter+network init scripts after systemd becomes default.
'Twas brillig, and Olivier Blin at 01/09/11 22:40 did gyre and gimble: - network config is by default user-dependant, and not available in display manager Just on this small point... The latest GDM exposes networking config with network manager in the DM. Not tried playing with it (too busy fighting intel driver issues - quite crashy), but to save e.g. any wifi passwords, you'd have to enter the root password. Col -- Colin Guthrie mageia(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mageia Contributor [http://www.mageia.org/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/]
Re: [Mageia-dev] Proposal: Deprecate draknetcenter+network init scripts after systemd becomes default.
Le 02/09/2011 09:48, Colin Guthrie a écrit : fighting intel driver issues - quite crashy), but to save e.g. any wifi passwords, you'd have to enter the root password. Which seems to be the rule for all shared connections for 0.9 branch. -- BOFH excuse #296: The hardware bus needs a new token.
Re: [Mageia-dev] Proposal: Deprecate draknetcenter+network init scripts after systemd becomes default.
'Twas brillig, and Guillaume Rousse at 02/09/11 09:07 did gyre and gimble: Le 02/09/2011 09:48, Colin Guthrie a écrit : fighting intel driver issues - quite crashy), but to save e.g. any wifi passwords, you'd have to enter the root password. Which seems to be the rule for all shared connections for 0.9 branch. Well, you can just enter your user password generally, but this is just the default policy kit rules. It can be tweaked such that normal users don't have to enter a password if so desired. I've not looked into it in any depth tho' Col -- Colin Guthrie mageia(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mageia Contributor [http://www.mageia.org/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/]
Re: [Mageia-dev] Proposal: Deprecate draknetcenter+network init scripts after systemd becomes default.
Buchan Milne bgmi...@staff.telkomsa.net writes: On Tuesday, 23 August 2011 17:15:44 Michael Scherer wrote: Le mardi 23 août 2011 à 15:28 +0200, Thierry Vignaud a écrit : What's more gaining 20s on a server when the IBM uefi/firmware take *minutes* to setup the machine is worthless. On the server side, we still manage RHEL networking through old style ifcfg* config files Some people do actually use vms, where boot speed could be important if created on demand ( and where the reactivity would warrant something more than shell script, and where a better API to get interface information wuld be nice ). We have netcf in the distribution ... https://fedorahosted.org/netcf (required for network configuration from virt-manager). Having xml is quite readable when used for displaying interface information, but not very practical to set configuration. Is there any other tool to write the configuration? -- Olivier Blin - blino
Re: [Mageia-dev] Proposal: Deprecate draknetcenter+network init scripts after systemd becomes default.
Colin Guthrie mag...@colin.guthr.ie writes: Perhaps, but then a more interesting question is what bits of drakx-net are used in mgaonline and drax-installer? Just stating that they are used there as a reason to keep it isn't really a good argument IMO. About mgaonline, it would probably be possible to use NM to poke for network status. About the drakx-installer, drakx-net code is used to get network status but also configure the connections (ethernet, wireless, xdsl, ...). I don't think the DrakX installer is quite ready yet to have dbus + NM running, just to get the network status. Also, it would probably be quite hard to integrate NM configuration tools into the DrakX installer. Other things I think are still unique in drakx-net: - xDSL network configuration: we put a lot of work into this at Mandriva, it is still working pretty well, and some users still need it (just look at the comments of disappointed users of Mandriva 2011 on the official blog or forums) - automatic package installation: network tools, manufacturer tools, drivers and firmwares are automatically pulled by the tools when configuring an interface (the list of packages mentionned in drakx-net is also used to automatically include hardware support packages when building a live image) Drawbacks of NM that come to my mind: - hard to configure in command line (troubleshooting without X, or server configuration) - network config is by default user-dependant, and not available in display manager -- Olivier Blin - blino
Re: [Mageia-dev] Proposal: Deprecate draknetcenter+network init scripts after systemd becomes default.
On Thu, Sep 1, 2011 at 6:40 PM, Olivier Blin mag...@blino.org wrote: Colin Guthrie mag...@colin.guthr.ie writes: - automatic package installation: network tools, manufacturer tools, drivers and firmwares are automatically pulled by the tools when configuring an interface (the list of packages mentionned in drakx-net is also used to automatically include hardware support packages when building a live image) noob question: couldn't this also be accomplished using packageKit ? -- JLB
Re: [Mageia-dev] Proposal: Deprecate draknetcenter+network init scripts after systemd becomes default.
Juan Luis Baptiste juan.bapti...@gmail.com writes: On Thu, Sep 1, 2011 at 6:40 PM, Olivier Blin mag...@blino.org wrote: Colin Guthrie mag...@colin.guthr.ie writes: - automatic package installation: network tools, manufacturer tools, drivers and firmwares are automatically pulled by the tools when configuring an interface (the list of packages mentionned in drakx-net is also used to automatically include hardware support packages when building a live image) noob question: couldn't this also be accomplished using packageKit ? Probably, but even if using packagekit, the package installation still has to be called from some UI, and if you want the UI to be NM, you would have to rewrite in NM the devices detection code + packages list from drakx-net -- Olivier Blin - blino
Re: [Mageia-dev] Proposal: Deprecate draknetcenter+network init scripts after systemd becomes default.
Le jeudi 25 août 2011 à 12:17 +0100, Colin Guthrie a écrit : 'Twas brillig, and Michael Scherer at 24/08/11 10:46 did gyre and gimble: At present, a number of my machines have scripts that hook into the network scripts. For example, one to update the bind forwarders from the DNS IPs returned by pppd when the interface comes up. On another machine, a script that unloads the wireless broadband driver when the interface goes down (I think this modem has buggy firmware). Then, there are the existing scripts shipped in the distribution (e.g. to reload squid). Just on this point in particular (as Misc has pretty much covered everything I would say and more!), the need to do this will likely go away very soon. I don't know the full ins and outs here but AFAIK, there was/are various uses of dnsmasq in Network Manager to provide caching DNS (which I presume is the basic need with bind+forwarders). That's optional, but yes, you can tell to nm to manage dnsmasq or bind to provides caching for dns. Dnsmasq is also used to share the connection. To enable it, I think you need to set this : [main] dns=dnsmasq ( or bind, even if this is marked experimental in git ) I tested on nm-0.9, my network didn't explose -- Michael Scherer
Re: [Mageia-dev] Proposal: Deprecate draknetcenter+network init scripts after systemd becomes default.
'Twas brillig, and Michael Scherer at 26/08/11 11:19 did gyre and gimble: Le jeudi 25 août 2011 à 12:17 +0100, Colin Guthrie a écrit : 'Twas brillig, and Michael Scherer at 24/08/11 10:46 did gyre and gimble: At present, a number of my machines have scripts that hook into the network scripts. For example, one to update the bind forwarders from the DNS IPs returned by pppd when the interface comes up. On another machine, a script that unloads the wireless broadband driver when the interface goes down (I think this modem has buggy firmware). Then, there are the existing scripts shipped in the distribution (e.g. to reload squid). Just on this point in particular (as Misc has pretty much covered everything I would say and more!), the need to do this will likely go away very soon. I don't know the full ins and outs here but AFAIK, there was/are various uses of dnsmasq in Network Manager to provide caching DNS (which I presume is the basic need with bind+forwarders). That's optional, but yes, you can tell to nm to manage dnsmasq or bind to provides caching for dns. Dnsmasq is also used to share the connection. To enable it, I think you need to set this : [main] dns=dnsmasq ( or bind, even if this is marked experimental in git ) I tested on nm-0.9, my network didn't explose Cool, but regardless, all of this can and will be removed from NM soon enough anyway. The new DNS system backed into nsswitch will be much nicer in this regard and nscd will be able to handle all the caching needs. Not sure about shared connections, but that shouldn't be a problem generally as the client can just be told to use the same upstream DNS servers AFAIK. Col -- Colin Guthrie mageia(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mageia Contributor [http://www.mageia.org/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/]
Re: [Mageia-dev] Proposal: Deprecate draknetcenter+network init scripts after systemd becomes default.
'Twas brillig, and Michael Scherer at 24/08/11 10:46 did gyre and gimble: At present, a number of my machines have scripts that hook into the network scripts. For example, one to update the bind forwarders from the DNS IPs returned by pppd when the interface comes up. On another machine, a script that unloads the wireless broadband driver when the interface goes down (I think this modem has buggy firmware). Then, there are the existing scripts shipped in the distribution (e.g. to reload squid). Just on this point in particular (as Misc has pretty much covered everything I would say and more!), the need to do this will likely go away very soon. I don't know the full ins and outs here but AFAIK, there was/are various uses of dnsmasq in Network Manager to provide caching DNS (which I presume is the basic need with bind+forwarders). In the not too distant future there will be a new resolved that will slot into nsswitch that will handle DNS lookups much more gracefully (i.e. basically replacing dns module). Combine that with appropriate caching from nscd and you should be fine generally for caching DNS lookups and reacting to server changes when moving network around etc. I don't have all the details here, but this kind of infrastructure will be a lot simpler and more robust. Of course there may be need to do the whole bind thing and that, in itself, should still be possible. Col -- Colin Guthrie mageia(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mageia Contributor [http://www.mageia.org/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/]
Re: [Mageia-dev] Proposal: Deprecate draknetcenter+network init scripts after systemd becomes default.
On Tuesday, 23 August 2011 17:15:44 Michael Scherer wrote: Le mardi 23 août 2011 à 15:28 +0200, Thierry Vignaud a écrit : What's more gaining 20s on a server when the IBM uefi/firmware take *minutes* to setup the machine is worthless. On the server side, we still manage RHEL networking through old style ifcfg* config files Some people do actually use vms, where boot speed could be important if created on demand ( and where the reactivity would warrant something more than shell script, and where a better API to get interface information wuld be nice ). We have netcf in the distribution ... https://fedorahosted.org/netcf (required for network configuration from virt-manager). Regards, Buchan
Re: [Mageia-dev] Proposal: Deprecate draknetcenter+network init scripts after systemd becomes default.
On Tuesday, 23 August 2011 15:30:45 Colin Guthrie wrote:
'Twas brillig, and Guillaume Rousse at 23/08/11 12:16 did gyre and gimble:
On 23/08/2011 12:26, Colin Guthrie wrote:
How would removing initscripts support helps enhancing networkmanager
integration ?
Because the current philosophy of the Unix legacy is lots of individual
utils from various packages cobbled together with some glue shell
scripting code... and it's dying.
The things that these individual tools implement are a few relatively
simply commands to the kernel and it doesn't make sense to do all this
in shell. It makes much more sense to do all these jobs in efficient
code that runs *quickly* without forking hundreds of times. The code is
still perfectly visible and easily hackable, but now things are much
more robust and efficient.
Booting faster makes sense on desktops, not on servers.
Agreed, but on servers additional capabilities are added that I very
much care about (much more than I care about boot speed on my laptop if
I'm honest - with my SSD I'm looking at a 1 or 2 second boots - who
cares about that!). I'm actually much more excited about systemd on the
server than I am on a desktop.
The cgroup management
We don't even have libcgroup or equivalent in the distribution yet ... so I
would say is is a bit premature to show this as an advantage IMHO ...
and the ability to restart network services
without losing a single connection is a revelation for me.
Have all the services got support for this yet?
I will no
longer worry about restarting apache because it might mess up a
webservice request or similar. And if I get rooted and find rogue
processes running, I'll be able to know exactly what service actually
started that process which is incredibly useful when dealing with the
mess left by intrusions.
My general
impression in this new trend (systemd, networkmanager, etc...) is the
need to compete with proprietary system (macos, windows) on end-user
segment, at the cost of genericity and simplicity.
I think the simplicity argument is bogus. You are (IMO) confusing
simplicity with ease of readability. Sure you can read through a script,
but the process of starting and maintaining services now becomes
*standard*. I don't have to read scripts for every single one of the
1000s of init'ed services,
I really don't read the scripts for every service, but quite often I do need
to adjust some setting catered for in the script, so I read
/etc/sysconfig/foo, and adjust it there.
Although I have read a number of the systemd blogs, there are still some
unanswered questions. Such as, what should happen to utility functions in the
init scripts (e.g. 'service apache configtest' or 'service ldap check'), or
other checks that are done in the init script before starting the service
(such as ensuring ownership of files by the ldap user, which is a common trap
users fall into after doing an import, or re-indexing).
I just need to understand the process of
services management in general and I can pretty much work with
everything.
Surely 'service foo {start|stop|restart|reload}' is also a generic approach to
services management?
When you appreciate that, you'll see that systemd makes
things much simpler overall. Sure you can't read a script, but that, in
itself, has nothing to do with simplicity. Individual scripts tweaking
certain things and adding secret arguments and such like is far, far
more complex than a unified and defined way of working.
But, sometimes they are required, and what is the replacement for the
functionality?
And yes, if we're honest, MacOS has a far superior boot system in
launchd and the networking support is also better with it's fast-start
DHCP and other such nice things.
And MacOS has good server market share?
I'm not suggesting network manager on servers here FWIW, but I think
your reluctance to change should be massively outweighed by the benefits
these changes bring, both to the server platform and to desktop systems.
The rest of the discussion in this mail by now was about systemd. For
NetworkManager, I have some more questions.
At present, a number of my machines have scripts that hook into the network
scripts. For example, one to update the bind forwarders from the DNS IPs
returned by pppd when the interface comes up. On another machine, a script
that unloads the wireless broadband driver when the interface goes down (I
think this modem has buggy firmware). Then, there are the existing scripts
shipped in the distribution (e.g. to reload squid).
In the NetworkManager world, are all of these taken care of? If not, and I
have to script them myself, now I guess I have to hook in to NM via dbus?
Regards,
Buchan
Re: [Mageia-dev] Proposal: Deprecate draknetcenter+network init scripts after systemd becomes default.
Le mercredi 24 août 2011 à 09:07 +0200, Buchan Milne a écrit : On Tuesday, 23 August 2011 17:15:44 Michael Scherer wrote: Le mardi 23 août 2011 à 15:28 +0200, Thierry Vignaud a écrit : What's more gaining 20s on a server when the IBM uefi/firmware take *minutes* to setup the machine is worthless. On the server side, we still manage RHEL networking through old style ifcfg* config files Some people do actually use vms, where boot speed could be important if created on demand ( and where the reactivity would warrant something more than shell script, and where a better API to get interface information wuld be nice ). We have netcf in the distribution ... look at who imported it :) https://fedorahosted.org/netcf (required for network configuration from virt-manager). We also do have augeas, that could help on the same type of problem. But none of them react to interface change and while libvirt (for example ) can use netcf, there is still cases where it do /proc parsing with all the fragility and code duplication it implies ( like in networkCheckRouteCollision ) -- Michael Scherer
Re: [Mageia-dev] Proposal: Deprecate draknetcenter+network init scripts after systemd becomes default.
Le mercredi 24 août 2011 à 09:19 +0200, Buchan Milne a écrit :
On Tuesday, 23 August 2011 15:30:45 Colin Guthrie wrote:
'Twas brillig, and Guillaume Rousse at 23/08/11 12:16 did gyre and gimble:
On 23/08/2011 12:26, Colin Guthrie wrote:
How would removing initscripts support helps enhancing networkmanager
integration ?
Because the current philosophy of the Unix legacy is lots of individual
utils from various packages cobbled together with some glue shell
scripting code... and it's dying.
The things that these individual tools implement are a few relatively
simply commands to the kernel and it doesn't make sense to do all this
in shell. It makes much more sense to do all these jobs in efficient
code that runs *quickly* without forking hundreds of times. The code is
still perfectly visible and easily hackable, but now things are much
more robust and efficient.
Booting faster makes sense on desktops, not on servers.
Agreed, but on servers additional capabilities are added that I very
much care about (much more than I care about boot speed on my laptop if
I'm honest - with my SSD I'm looking at a 1 or 2 second boots - who
cares about that!). I'm actually much more excited about systemd on the
server than I am on a desktop.
The cgroup management
We don't even have libcgroup or equivalent in the distribution yet ... so I
would say is is a bit premature to show this as an advantage IMHO ...
Well, we now have it :)
( ok almost, I need to fix the initscript, and also need to check if
there is nothing to update, like the /cgroup directory )
and the ability to restart network services
without losing a single connection is a revelation for me.
Have all the services got support for this yet?
While I am not sure how it work, if it use the socket activation system,
only supported services would have it. Fedora/Opensuse is likely pushing
their patch upstream for that, and I think the goal is to convert as
much as possible daemon. So I guess it would be ok in the time frame of
the change ( ie in 1 year or more ) and for the majority of the daemons.
But I think we should check how it work first to see what can support
it.
I think the simplicity argument is bogus. You are (IMO) confusing
simplicity with ease of readability. Sure you can read through a script,
but the process of starting and maintaining services now becomes
*standard*. I don't have to read scripts for every single one of the
1000s of init'ed services,
I really don't read the scripts for every service, but quite often I do need
to adjust some setting catered for in the script, so I read
/etc/sysconfig/foo, and adjust it there.
If the initscript support it, which is usually far from being uniform.
Systemd permit to set regular settings more easily, like environment,
nice level, user, group, chroot, cpu/io/etc scheduling, capability, etc.
See http://0pointer.de/public/systemd-man/systemd.exec.html
What kind of setting do you need to adjust and that you couldn't from a
initscript by passing options to the binary or by setting a environment
interpreted by the daemon ?
Although I have read a number of the systemd blogs, there are still some
unanswered questions. Such as, what should happen to utility functions in the
init scripts (e.g. 'service apache configtest' or 'service ldap check'), or
other checks that are done in the init script before starting the service
(such as ensuring ownership of files by the ldap user, which is a common trap
users fall into after doing an import, or re-indexing).
While I am not sure of the answer ( I know that people have already
asked that on fedora ml, but it seems to become a trolling fest on the
topic from time to time, and it is too depressing for me to read them ),
there is ExecStartPre= to run arbitrary commands before the main
command. This can be used to make sure permission are ok.
I am not sure however this help for the case of the check. I guess then
a wrapper to run the server, and splitting the check in it own binary
would be enough ? That would still work, due to the usage of cgroup.
I didn't found any information on that, so maybe Colin can answer, or
then see on the systemd ml.
I just need to understand the process of
services management in general and I can pretty much work with
everything.
Surely 'service foo {start|stop|restart|reload}' is also a generic approach
to
services management?
When the initscript implement it fully, for a unspecified version of
fully. Having to integrate some of them in puppet showed that not
everybody did ( like some missing restart ), and this caused subtle
issues requiring customisation, and make our life more difficult than it
should be as packagers and as sysadmins.
When you appreciate that, you'll see that systemd makes
things much simpler overall. Sure you can't read a script, but that, in
itself, has nothing to do with simplicity.
Re: [Mageia-dev] Proposal: Deprecate draknetcenter+network init scripts after systemd becomes default.
'Twas brillig, and Michael scherer at 22/08/11 13:14 did gyre and gimble: On Mon, Aug 22, 2011 at 08:44:01AM -0300, Balcaen John wrote: Le Monday 22 August 2011 12:57:23 Guillaume Rousse a écrit : On 22/08/2011 11:57, Colin Guthrie wrote: I also have it on good authority that many of the features lacking in NetworkManager (such as bridging configuration) will be available in the not too distant future and many other more advanced networking features such as fast-start DHCP, per-interface DNS, 4-8's DNS fallback and several other nice features will ultimately be possible too. While I don't care about configuration wizards, I do about initscripts. How are you supposed to configure a server in some automated manner without plain-old configuration files ? If i'm not wrong you can still drop plain text files in /etc/NetworkManager/system-connections/ Provided you want to do nothing fancy like bridge, vlan and others stuff that are used by sysadmins. As I said in my initial email, but was not clear. All of these things will be supported in a much nicer way in the near future. But yes, Fedora will switch and we can follow, but it would be nice to be at the fore front here if possible. Col -- Colin Guthrie mageia(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mageia Contributor [http://www.mageia.org/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/]
Re: [Mageia-dev] Proposal: Deprecate draknetcenter+network init scripts after systemd becomes default.
'Twas brillig, and Thierry Vignaud at 22/08/11 13:32 did gyre and gimble: On 22 August 2011 11:57, Colin Guthrie mag...@colin.guthr.ie wrote: This is just a heads up to suggest that we officially adopt a policy of moving to NetworkManager after systemd becomes our default (and likely only) init system - i.e. likely for mga3. As you may know, GNOME is moving towards a systemd user session and systemd itself is very much aligning itself to be the one true init system on linux. I also have it on good authority that many of the features lacking in NetworkManager (such as bridging configuration) will be available in the not too distant future and many other more advanced networking features such as fast-start DHCP, per-interface DNS, 4-8's DNS fallback and several other nice features will ultimately be possible too. So with all this in mind, I think the writing is very much on the wall with regards to the future integration of NetworkManager into the desktop. I believe we will be able to concentrate our resources better by going along with the rest of the world in this regard. I have personally switched to it now (as I do not need advanced features of draknetcenter et al) as a step towards this. err... drakx-net's code is heavily used by other tools such as: - drakx-installer - mgaonline - ... So I think we still want to keep drakx-net Perhaps, but then a more interesting question is what bits of drakx-net are used in mgaonline and drax-installer? Just stating that they are used there as a reason to keep it isn't really a good argument IMO. Asbestos is used in fire retardant wall insulation, but it's not a good argument to keep it considering the world has moved on and we now know the dangers of working with that material. So what does mgaonline need to work with drakx-net? Does it just need to know if you are online or not? If so why not use NM's dbus service to do that? It could eventually know whether you are on a paid/metered connection (this is not yet supported by NM but there has been some talk about it) or a free connection - a fast vs. slow connection etc. It could make intelligent, informed decisions, not just is the user online - no matter how crappily? Then of course the wider question... should mgaonline be deprecated in favour of more integrated options suck as package-kit? Should we focus resources on that? This is IMO a more open question, even if I do feel the writing is ultimately on the wall here too. I'd very much like to use much more standard things. I think some of the mdv tools were differentiators in the past but those days are pretty much slipping by. Some of the tools are still best of bread, but things like network management and handling updates etc. is perhaps something that has no progressed to the stage that us having independent update mechanisms is a hindrance to users rather than a benefit. It's all too easy to get stuck in a rut and get emotionally attached to such things (I do it all the time in my day job) but sometimes it helps to look at things from a slightly detached view point. Cheers Col -- Colin Guthrie mageia(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mageia Contributor [http://www.mageia.org/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/]
Re: [Mageia-dev] Proposal: Deprecate draknetcenter+network init scripts after systemd becomes default.
Le mardi 23 août 2011 à 09:30 +0100, Colin Guthrie a écrit : 'Twas brillig, and Michael scherer at 22/08/11 13:14 did gyre and gimble: On Mon, Aug 22, 2011 at 08:44:01AM -0300, Balcaen John wrote: Le Monday 22 August 2011 12:57:23 Guillaume Rousse a écrit : On 22/08/2011 11:57, Colin Guthrie wrote: I also have it on good authority that many of the features lacking in NetworkManager (such as bridging configuration) will be available in the not too distant future and many other more advanced networking features such as fast-start DHCP, per-interface DNS, 4-8's DNS fallback and several other nice features will ultimately be possible too. While I don't care about configuration wizards, I do about initscripts. How are you supposed to configure a server in some automated manner without plain-old configuration files ? If i'm not wrong you can still drop plain text files in /etc/NetworkManager/system-connections/ Provided you want to do nothing fancy like bridge, vlan and others stuff that are used by sysadmins. As I said in my initial email, but was not clear. All of these things will be supported in a much nicer way in the near future. But so far, this is not supported. And since we have said we do not remove non systemd from Mageia 2 ( https://www.mageia.org/pipermail/mageia-dev/2011-July/006701.html ) , I think we cannot take systemd for granted before mageia 3. And precisely, because we are not gonna keep only systemd for mageia 2, we cannot depreciate network script. But yes, Fedora will switch and we can follow, but it would be nice to be at the fore front here if possible. Would we have too much ressources, maybe. But so far, there is already enough work on http://check.mageia.org/ to keep people busy, and I do not really see the need to add more breakage and shiny stuff when we are far from being able to take care of what we already have. -- Michael Scherer
Re: [Mageia-dev] Proposal: Deprecate draknetcenter+network init scripts after systemd becomes default.
'Twas brillig, and Michael Scherer at 23/08/11 10:10 did gyre and gimble: Le mardi 23 août 2011 à 09:30 +0100, Colin Guthrie a écrit : 'Twas brillig, and Michael scherer at 22/08/11 13:14 did gyre and gimble: On Mon, Aug 22, 2011 at 08:44:01AM -0300, Balcaen John wrote: Le Monday 22 August 2011 12:57:23 Guillaume Rousse a écrit : On 22/08/2011 11:57, Colin Guthrie wrote: I also have it on good authority that many of the features lacking in NetworkManager (such as bridging configuration) will be available in the not too distant future and many other more advanced networking features such as fast-start DHCP, per-interface DNS, 4-8's DNS fallback and several other nice features will ultimately be possible too. While I don't care about configuration wizards, I do about initscripts. How are you supposed to configure a server in some automated manner without plain-old configuration files ? If i'm not wrong you can still drop plain text files in /etc/NetworkManager/system-connections/ Provided you want to do nothing fancy like bridge, vlan and others stuff that are used by sysadmins. As I said in my initial email, but was not clear. All of these things will be supported in a much nicer way in the near future. But so far, this is not supported. And since we have said we do not remove non systemd from Mageia 2 ( https://www.mageia.org/pipermail/mageia-dev/2011-July/006701.html ) , I think we cannot take systemd for granted before mageia 3. Yup, that's why I mentioned mageia 3 in my initial mail. And precisely, because we are not gonna keep only systemd for mageia 2, we cannot depreciate network script. Oh yeah, I'm not proposing any of this for mga2... But yes, Fedora will switch and we can follow, but it would be nice to be at the fore front here if possible. Would we have too much ressources, maybe. But so far, there is already enough work on http://check.mageia.org/ to keep people busy, and I do not really see the need to add more breakage and shiny stuff when we are far from being able to take care of what we already have. Well, fixing the existing stuff or switching to new shiney things with no doubt (different) breakages, is much of a muchness IMO. Sure it does take some initial work, but also allows us to get fixes from other parties rather than having to fix everything ourselves which is, overall a net positive in terms of resources. Col -- Colin Guthrie mageia(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mageia Contributor [http://www.mageia.org/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/]
Re: [Mageia-dev] Proposal: Deprecate draknetcenter+network init scripts after systemd becomes default.
'Twas brillig, and Guillaume Rousse at 23/08/11 10:33 did gyre and gimble: On 23/08/2011 10:30, Colin Guthrie wrote: 'Twas brillig, and Michael scherer at 22/08/11 13:14 did gyre and gimble: On Mon, Aug 22, 2011 at 08:44:01AM -0300, Balcaen John wrote: Le Monday 22 August 2011 12:57:23 Guillaume Rousse a écrit : On 22/08/2011 11:57, Colin Guthrie wrote: I also have it on good authority that many of the features lacking in NetworkManager (such as bridging configuration) will be available in the not too distant future and many other more advanced networking features such as fast-start DHCP, per-interface DNS, 4-8's DNS fallback and several other nice features will ultimately be possible too. While I don't care about configuration wizards, I do about initscripts. How are you supposed to configure a server in some automated manner without plain-old configuration files ? If i'm not wrong you can still drop plain text files in /etc/NetworkManager/system-connections/ Provided you want to do nothing fancy like bridge, vlan and others stuff that are used by sysadmins. As I said in my initial email, but was not clear. All of these things will be supported in a much nicer way in the near future. Well, even if supported, I do feel much more confident in shell scripts I can read, understand and easily fix if needed to fit my own needs, than in a native binary. This is a endless argument but one which will ultimately not be sustainable I fear. I do sympathise, but by the same token, I also want a modern, fast and efficient system too, so I'm kinda torn. I understand C code pretty well generally and while I can't just less the program on my machine it's not too hard to get the source code and pick through it when I need to (which is very rarely in reality) so I think both my need for curiosity is satisfied and while I accept the on-site hackability does get negatively impacted, the larger number of users using a standard system should result in less problems overall and thus less need to hack in the first place... this won't always be true, but I'm happy with that trade off. How would removing initscripts support helps enhancing networkmanager integration ? Because the current philosophy of the Unix legacy is lots of individual utils from various packages cobbled together with some glue shell scripting code... and it's dying. The things that these individual tools implement are a few relatively simply commands to the kernel and it doesn't make sense to do all this in shell. It makes much more sense to do all these jobs in efficient code that runs *quickly* without forking hundreds of times. The code is still perfectly visible and easily hackable, but now things are much more robust and efficient. It's also the case that people *talk* about doing stuff lots, but very rarely actually *do* it. People have talked about tidying up the init system for years, and they've talked about improving the networking support for years but these just go in circles and never really result in real progress. For the first time in a long time, things are actually being *done* about this and in doing so we can take advantage of a lot of the modern features of Linux. It's exciting and it means that the support in the GUI frontends for network management become much more standardised and less varying over different distros. The fact that distros all tweak things and do homebrew for network management means that for tools like network manager to support all distros they have to do a whole bunch of weird shit to work on RH vs Mandrvia. vs Suse, vs Ubuntu etc. etc. By ripping out the cruft and replacing it with standard binaries, you get consistency at the expense of the all the variations but IMO this is a good thing - everyone benefits from a larger community working on the same thing - more eyes, less bugs, more features. So, removing the variations in different distros init methods and network management tools, is very clearly enabling better network manager integration. Hope that explains it a bit (tho' I'm typing quickly because I'm at work, so sorry if it doesn't read super clearly!) Col -- Colin Guthrie mageia(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mageia Contributor [http://www.mageia.org/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/]
Re: [Mageia-dev] Proposal: Deprecate draknetcenter+network init scripts after systemd becomes default.
On 23/08/2011 12:26, Colin Guthrie wrote: How would removing initscripts support helps enhancing networkmanager integration ? Because the current philosophy of the Unix legacy is lots of individual utils from various packages cobbled together with some glue shell scripting code... and it's dying. The things that these individual tools implement are a few relatively simply commands to the kernel and it doesn't make sense to do all this in shell. It makes much more sense to do all these jobs in efficient code that runs *quickly* without forking hundreds of times. The code is still perfectly visible and easily hackable, but now things are much more robust and efficient. Booting faster makes sense on desktops, not on servers. My general impression in this new trend (systemd, networkmanager, etc...) is the need to compete with proprietary system (macos, windows) on end-user segment, at the cost of genericity and simplicity. -- BOFH excuse #104: backup tape overwritten with copy of system manager's favourite CD
Re: [Mageia-dev] Proposal: Deprecate draknetcenter+network init scripts after systemd becomes default.
On 23 August 2011 13:16, Guillaume Rousse guillomovi...@gmail.com wrote: The things that these individual tools implement are a few relatively simply commands to the kernel and it doesn't make sense to do all this in shell. It makes much more sense to do all these jobs in efficient code that runs *quickly* without forking hundreds of times. The code is still perfectly visible and easily hackable, but now things are much more robust and efficient. Booting faster makes sense on desktops, not on servers. My general impression in this new trend (systemd, networkmanager, etc...) is the need to compete with proprietary system (macos, windows) on end-user segment, at the cost of genericity and simplicity. Indeed. What's more gaining 20s on a server when the IBM uefi/firmware take *minutes* to setup the machine is worthless. On the server side, we still manage RHEL networking through old style ifcfg* config files
Re: [Mageia-dev] Proposal: Deprecate draknetcenter+network init scripts after systemd becomes default.
'Twas brillig, and Guillaume Rousse at 23/08/11 12:16 did gyre and gimble: On 23/08/2011 12:26, Colin Guthrie wrote: How would removing initscripts support helps enhancing networkmanager integration ? Because the current philosophy of the Unix legacy is lots of individual utils from various packages cobbled together with some glue shell scripting code... and it's dying. The things that these individual tools implement are a few relatively simply commands to the kernel and it doesn't make sense to do all this in shell. It makes much more sense to do all these jobs in efficient code that runs *quickly* without forking hundreds of times. The code is still perfectly visible and easily hackable, but now things are much more robust and efficient. Booting faster makes sense on desktops, not on servers. Agreed, but on servers additional capabilities are added that I very much care about (much more than I care about boot speed on my laptop if I'm honest - with my SSD I'm looking at a 1 or 2 second boots - who cares about that!). I'm actually much more excited about systemd on the server than I am on a desktop. The cgroup management and the ability to restart network services without losing a single connection is a revelation for me. I will no longer worry about restarting apache because it might mess up a webservice request or similar. And if I get rooted and find rogue processes running, I'll be able to know exactly what service actually started that process which is incredibly useful when dealing with the mess left by intrusions. My general impression in this new trend (systemd, networkmanager, etc...) is the need to compete with proprietary system (macos, windows) on end-user segment, at the cost of genericity and simplicity. I think the simplicity argument is bogus. You are (IMO) confusing simplicity with ease of readability. Sure you can read through a script, but the process of starting and maintaining services now becomes *standard*. I don't have to read scripts for every single one of the 1000s of init'ed services, I just need to understand the process of services management in general and I can pretty much work with everything. When you appreciate that, you'll see that systemd makes things much simpler overall. Sure you can't read a script, but that, in itself, has nothing to do with simplicity. Individual scripts tweaking certain things and adding secret arguments and such like is far, far more complex than a unified and defined way of working. And yes, if we're honest, MacOS has a far superior boot system in launchd and the networking support is also better with it's fast-start DHCP and other such nice things. I'm not suggesting network manager on servers here FWIW, but I think your reluctance to change should be massively outweighed by the benefits these changes bring, both to the server platform and to desktop systems. Col -- Colin Guthrie mageia(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mageia Contributor [http://www.mageia.org/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/]
Re: [Mageia-dev] Proposal: Deprecate draknetcenter+network init scripts after systemd becomes default.
On 23 August 2011 10:55, Colin Guthrie mag...@colin.guthr.ie wrote: err... drakx-net's code is heavily used by other tools such as: - drakx-installer - mgaonline - ... So I think we still want to keep drakx-net Perhaps, but then a more interesting question is what bits of drakx-net are used in mgaonline and drax-installer? Just stating that they are used there as a reason to keep it isn't really a good argument IMO. drakx-installer uses most of interesting bits of drakx-net (ake network detection set up, ...) Asbestos is used in fire retardant wall insulation, but it's not a good argument to keep it considering the world has moved on and we now know the dangers of working with that material. OK, give me the NM patches for the installer :-) Seriously, without trolling, we just cannot drop drakx-net until we got something else for the installer. Dunno what does anaconda these days btw? So what does mgaonline need to work with drakx-net? Does it just need to know if you are online or not? If so why not use NM's dbus service to do that? It could eventually know whether you are on a paid/metered connection (this is not yet supported by NM but there has been some talk about it) or a free connection - a fast vs. slow connection etc. It could make intelligent, informed decisions, not just is the user online - no matter how crappily? mgaonline has less needs, basically detecting network connectivity but those are shared with the installer, so even if the lower level part would change, there's no readon not to have a common perl layer hiding the low level bits instead of making both interfaces NM
Re: [Mageia-dev] Proposal: Deprecate draknetcenter+network init scripts after systemd becomes default.
'Twas brillig, and Thierry Vignaud at 23/08/11 14:28 did gyre and gimble: What's more gaining 20s on a server when the IBM uefi/firmware take *minutes* to setup the machine is worthless. Agreed, but I've addressed why other features make systemd a *much* more attractive option on the server in my previous reply so I won't repeat it here. People suggesting that systemd is purely about boot speed and ignoring all the other things mean they've either not researched the topic they are discussing or are deliberately using irrelevant benefits for a given area of discussion to suggest that it doesn't help at all in that area. I prefer to talk about things contextually. I also don't really care about boot speed on the server, but that's not the point. On the server side, we still manage RHEL networking through old style ifcfg* config files I suspect something similar will still be the case even in the near future, but said script files will be much simpler and more standard (ultimately ini syntax, rather than shell syntax) and the tools that interpret those static configurations will also become much simpler (no more masses of shell script glueing together a myriad of binaries). I don't know the full details of how this will look yet, but I am at no point suggesting that network manager itself will be used on the server. All I'm saying is that things will be changing in both cases. Col -- Colin Guthrie mageia(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mageia Contributor [http://www.mageia.org/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/]
Re: [Mageia-dev] Proposal: Deprecate draknetcenter+network init scripts after systemd becomes default.
'Twas brillig, and Thomas Backlund at 23/08/11 14:37 did gyre and gimble: Thierry Vignaud skrev 23.8.2011 16:28: On 23 August 2011 13:16, Guillaume Rousseguillomovi...@gmail.com wrote: The things that these individual tools implement are a few relatively simply commands to the kernel and it doesn't make sense to do all this in shell. It makes much more sense to do all these jobs in efficient code that runs *quickly* without forking hundreds of times. The code is still perfectly visible and easily hackable, but now things are much more robust and efficient. Booting faster makes sense on desktops, not on servers. My general impression in this new trend (systemd, networkmanager, etc...) is the need to compete with proprietary system (macos, windows) on end-user segment, at the cost of genericity and simplicity. Indeed. What's more gaining 20s on a server when the IBM uefi/firmware take *minutes* to setup the machine is worthless. Heh, I remember a SGI guy on LKML a while back complaining that it took ~2 hours to boot one of their _big_ servers (4096 cpus, a few TB RAM). After a patch that fixed the bug, it brought the boot time down to 30 minutes and he was happy again :) Wowsers. I bet systemd could get that down to like 29 minutes and 30 seconds :p Col -- Colin Guthrie mageia(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mageia Contributor [http://www.mageia.org/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/]
Re: [Mageia-dev] Proposal: Deprecate draknetcenter+network init scripts after systemd becomes default.
On 23 August 2011 15:37, Thomas Backlund t...@mageia.org wrote: Indeed. What's more gaining 20s on a server when the IBM uefi/firmware take *minutes* to setup the machine is worthless. I remember a SGI guy on LKML a while back complaining that it took ~2 hours to boot one of their _big_ servers (4096 cpus, a few TB RAM). After a patch that fixed the bug, it brought the boot time down to 30 minutes and he was happy again :) I remember that one :-) But no one in the communauty can do anything about IBM's UEFI...
Re: [Mageia-dev] Proposal: Deprecate draknetcenter+network init scripts after systemd becomes default.
'Twas brillig, and Thierry Vignaud at 23/08/11 14:34 did gyre and gimble:
On 23 August 2011 10:55, Colin Guthrie mag...@colin.guthr.ie wrote:
err... drakx-net's code is heavily used by other tools such as:
- drakx-installer
- mgaonline
- ...
So I think we still want to keep drakx-net
Perhaps, but then a more interesting question is what bits of drakx-net
are used in mgaonline and drax-installer? Just stating that they are
used there as a reason to keep it isn't really a good argument IMO.
drakx-installer uses most of interesting bits of drakx-net (ake network
detection set up, ...)
Asbestos is used in fire retardant wall insulation, but it's not a good
argument to keep it considering the world has moved on and we now know
the dangers of working with that material.
OK, give me the NM patches for the installer :-)
If I get time, I think it would be worth looking at. Obviously (just
like in one of my replies) I'm far better at *talking* than *doing* too :D
Seriously, without trolling, we just cannot drop drakx-net until we got
something else for the installer.
Dunno what does anaconda these days btw?
Not sure. I'll have to take a look at that, but it would be interesting
to see if it's more integrated into NM now.
So what does mgaonline need to work with drakx-net? Does it just need to
know if you are online or not? If so why not use NM's dbus service to do
that? It could eventually know whether you are on a paid/metered
connection (this is not yet supported by NM but there has been some talk
about it) or a free connection - a fast vs. slow connection etc. It
could make intelligent, informed decisions, not just is the user online
- no matter how crappily?
mgaonline has less needs, basically detecting network connectivity
but those are shared with the installer, so even if the lower level
part would change, there's no readon not to have a common perl
layer hiding the low level bits instead of making both interfaces NM
Agreed. Perhaps my terminology is incorrect here. I'm not against such
an abstraction layer and even maintaining a if (nm) { new() } else {
old(); } approach for a release or two depending on need.
Col
--
Colin Guthrie
mageia(at)colin.guthr.ie
http://colin.guthr.ie/
Day Job:
Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
Mageia Contributor [http://www.mageia.org/]
PulseAudio Hacker [http://www.pulseaudio.org/]
Trac Hacker [http://trac.edgewall.org/]
Re: [Mageia-dev] Proposal: Deprecate draknetcenter+network init scripts after systemd becomes default.
Le mardi 23 août 2011 à 11:01 +0100, Colin Guthrie a écrit : 'Twas brillig, and Michael Scherer at 23/08/11 10:10 did gyre and gimble: Le mardi 23 août 2011 à 09:30 +0100, Colin Guthrie a écrit : 'Twas brillig, and Michael scherer at 22/08/11 13:14 did gyre and gimble: On Mon, Aug 22, 2011 at 08:44:01AM -0300, Balcaen John wrote: Le Monday 22 August 2011 12:57:23 Guillaume Rousse a écrit : On 22/08/2011 11:57, Colin Guthrie wrote: I also have it on good authority that many of the features lacking in NetworkManager (such as bridging configuration) will be available in the not too distant future and many other more advanced networking features such as fast-start DHCP, per-interface DNS, 4-8's DNS fallback and several other nice features will ultimately be possible too. While I don't care about configuration wizards, I do about initscripts. How are you supposed to configure a server in some automated manner without plain-old configuration files ? If i'm not wrong you can still drop plain text files in /etc/NetworkManager/system-connections/ Provided you want to do nothing fancy like bridge, vlan and others stuff that are used by sysadmins. As I said in my initial email, but was not clear. All of these things will be supported in a much nicer way in the near future. But so far, this is not supported. And since we have said we do not remove non systemd from Mageia 2 ( https://www.mageia.org/pipermail/mageia-dev/2011-July/006701.html ) , I think we cannot take systemd for granted before mageia 3. Yup, that's why I mentioned mageia 3 in my initial mail. Oups, I misread :/ Then my answer is we didn't even released 2, so let's keep discussion about 3 for later ( seriously, it didn't even occurs to me that we would start discussing 3 right now ) Personnaly, I think that would be good to have something better than current initscripts and shell based approach for managing network ( since we already manage the network with ifplugd, having a daemon is not a so big problem, and I am sure we could have a mode where the daemon apply the configuration and then disappear, if that make people less nervous ). But I would really make sure that people agree with the change. I would rather avoid having the same type of discussion than on fedora-devel -- Michael Scherer
Re: [Mageia-dev] Proposal: Deprecate draknetcenter+network init scripts after systemd becomes default.
Le mardi 23 août 2011 à 15:28 +0200, Thierry Vignaud a écrit : What's more gaining 20s on a server when the IBM uefi/firmware take *minutes* to setup the machine is worthless. On the server side, we still manage RHEL networking through old style ifcfg* config files Some people do actually use vms, where boot speed could be important if created on demand ( and where the reactivity would warrant something more than shell script, and where a better API to get interface information wuld be nice ). We can still have configuration in plain text file ( even if I personally think that using shell based configuration is not the best way to do that ), so there is some confusion. -- Michael Scherer
Re: [Mageia-dev] Proposal: Deprecate draknetcenter+network init scripts after systemd becomes default.
Op dinsdag 23 augustus 2011 10:47:18 schreef Colin Guthrie: 'Twas brillig, and Maarten Vanraes at 22/08/11 22:39 did gyre and gimble: imho, the tools that are now available don't really work well together, ie: if you use multiple of those tools, likely they don't show correct status, etc... So combining home-grown solutions with those integrated into the DEs (both GNOME and KDE are integrating with NM in a more complete way these days) is a way to solve this problem? I don't think so personally. I think we should very much embrace what the common consensus on other distros is and stop living in a little bubble. I appreciate the quality of the tools developed in the past but without someone really pushing them they are just going to stagnate. It's a real shame as these tools were best of bread - really easy to use and looked good, but this has changed now. NM is much nicer to use these days and has been properly integrated into the DEs. well, imho, the last time i tried NM it didn't work and net_applet did. personally, i've used net_applet always and i would like to keep this. Sure, if it's patched to integrate into GNOME shell as nicely as NM then I'd say it's an option. If it provides the same DBus interfaces that NM does (or will) support such that applications can tell what type of connection you are on (i.e. to enable features such as not downloading package updates on your expensive, metered 3G connection) then it's certainly possible to continue to support an alternative to NM. Who is actually going to do that work tho'? Considering the bug about breaking your wifi configuration (using WEP rather than the configured WPA2) has not been fixed[1] since before mga1 was out, I'm not confident that anyone is even looking into the actual bugs here let alone adding new features. I feel we have to be some what practical about resources here and if we are going to work on features do it in a way that benefits the wider community - i.e. by contributing to NM, not just playing catch up. i don't care about gnome shell or gnome 3 or whichever. for me net_applet is the best one yet and i don't have this WPA2 bug that you seem to speak of. also, i need the openvpn functionalities of the net_applet. as long as NM doesn't provide everything and is welltested, i'm not sure it should replace something that's been very long working like the net_applet. allthough i'm sure net_applet could be improved, sure. personally i'd like an applet that shows up multiple times for each connection one with a different icon, so it's nicely visible and you can shut down whichever you want. Col 1. https://bugs.mageia.org/show_bug.cgi?id=1263 I had to manually edit wpa_supplicant.conf several times when at the Desktop Summit and WLAN hopping after using the GUI - it's not exactly a shining example of good integration. yes, but i'm using several different WPA2 connections, and i configured them once and now if i'm at that particular location, it works...
[Mageia-dev] Proposal: Deprecate draknetcenter+network init scripts after systemd becomes default.
Hello, This is just a heads up to suggest that we officially adopt a policy of moving to NetworkManager after systemd becomes our default (and likely only) init system - i.e. likely for mga3. As you may know, GNOME is moving towards a systemd user session and systemd itself is very much aligning itself to be the one true init system on linux. I also have it on good authority that many of the features lacking in NetworkManager (such as bridging configuration) will be available in the not too distant future and many other more advanced networking features such as fast-start DHCP, per-interface DNS, 4-8's DNS fallback and several other nice features will ultimately be possible too. So with all this in mind, I think the writing is very much on the wall with regards to the future integration of NetworkManager into the desktop. I believe we will be able to concentrate our resources better by going along with the rest of the world in this regard. I have personally switched to it now (as I do not need advanced features of draknetcenter et al) as a step towards this. It would be nice if other users did this to ensure that integration is suitably up to par. Col -- Colin Guthrie mageia(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mageia Contributor [http://www.mageia.org/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/]
Re: [Mageia-dev] Proposal: Deprecate draknetcenter+network init scripts after systemd becomes default.
On 22/08/2011 11:57, Colin Guthrie wrote: I also have it on good authority that many of the features lacking in NetworkManager (such as bridging configuration) will be available in the not too distant future and many other more advanced networking features such as fast-start DHCP, per-interface DNS, 4-8's DNS fallback and several other nice features will ultimately be possible too. While I don't care about configuration wizards, I do about initscripts. How are you supposed to configure a server in some automated manner without plain-old configuration files ? -- BOFH excuse #161: monitor VLF leakage
Re: [Mageia-dev] Proposal: Deprecate draknetcenter+network init scripts after systemd becomes default.
在 Mon, 22 Aug 2011 17:57:02 +0800, Colin Guthrie mag...@colin.guthr.ie寫道: Hello, I also have it on good authority that many of the features lacking in NetworkManager (such as bridging configuration) will be available in the not too distant future and many other more advanced networking features such as fast-start DHCP, per-interface DNS, 4-8's DNS fallback and several other nice features will ultimately be possible too. So with all this in mind, I think the writing is very much on the wall with regards to the future integration of NetworkManager into the desktop. I believe we will be able to concentrate our resources better by going along with the rest of the world in this regard. I have personally switched to it now (as I do not need advanced features of draknetcenter et al) as a step towards this. So what can draknet do while NM can't? If such a thing exist, I think abandon draknet is not a good idea, since it's much more integrate into MCC. Also, is it possible to combine them up, like using draknet to support manage the connection , letting NM replace the role of net_applet?
Re: [Mageia-dev] Proposal: Deprecate draknetcenter+network init scripts after systemd becomes default.
Le Monday 22 August 2011 12:57:23 Guillaume Rousse a écrit : On 22/08/2011 11:57, Colin Guthrie wrote: I also have it on good authority that many of the features lacking in NetworkManager (such as bridging configuration) will be available in the not too distant future and many other more advanced networking features such as fast-start DHCP, per-interface DNS, 4-8's DNS fallback and several other nice features will ultimately be possible too. While I don't care about configuration wizards, I do about initscripts. How are you supposed to configure a server in some automated manner without plain-old configuration files ? If i'm not wrong you can still drop plain text files in /etc/NetworkManager/system-connections/ -- Balcaen John
Re: [Mageia-dev] Proposal: Deprecate draknetcenter+network init scripts after systemd becomes default.
On Mon, Aug 22, 2011 at 08:44:01AM -0300, Balcaen John wrote: Le Monday 22 August 2011 12:57:23 Guillaume Rousse a écrit : On 22/08/2011 11:57, Colin Guthrie wrote: I also have it on good authority that many of the features lacking in NetworkManager (such as bridging configuration) will be available in the not too distant future and many other more advanced networking features such as fast-start DHCP, per-interface DNS, 4-8's DNS fallback and several other nice features will ultimately be possible too. While I don't care about configuration wizards, I do about initscripts. How are you supposed to configure a server in some automated manner without plain-old configuration files ? If i'm not wrong you can still drop plain text files in /etc/NetworkManager/system-connections/ Provided you want to do nothing fancy like bridge, vlan and others stuff that are used by sysadmins. And provided of course that you do not care about breaking upgrade path. I would personnaly not move until Fedora at least did for some releases. We are not here to experiment on our users, they are not guinea pigs. -- Michael Scherer
Re: [Mageia-dev] Proposal: Deprecate draknetcenter+network init scripts after systemd becomes default.
On 22 August 2011 11:57, Colin Guthrie mag...@colin.guthr.ie wrote: This is just a heads up to suggest that we officially adopt a policy of moving to NetworkManager after systemd becomes our default (and likely only) init system - i.e. likely for mga3. As you may know, GNOME is moving towards a systemd user session and systemd itself is very much aligning itself to be the one true init system on linux. I also have it on good authority that many of the features lacking in NetworkManager (such as bridging configuration) will be available in the not too distant future and many other more advanced networking features such as fast-start DHCP, per-interface DNS, 4-8's DNS fallback and several other nice features will ultimately be possible too. So with all this in mind, I think the writing is very much on the wall with regards to the future integration of NetworkManager into the desktop. I believe we will be able to concentrate our resources better by going along with the rest of the world in this regard. I have personally switched to it now (as I do not need advanced features of draknetcenter et al) as a step towards this. err... drakx-net's code is heavily used by other tools such as: - drakx-installer - mgaonline - ... So I think we still want to keep drakx-net
Re: [Mageia-dev] Proposal: Deprecate draknetcenter+network init scripts after systemd becomes default.
Op maandag 22 augustus 2011 13:08:26 schreef Kira: 在 Mon, 22 Aug 2011 17:57:02 +0800, Colin Guthrie mag...@colin.guthr.ie寫道: Hello, I also have it on good authority that many of the features lacking in NetworkManager (such as bridging configuration) will be available in the not too distant future and many other more advanced networking features such as fast-start DHCP, per-interface DNS, 4-8's DNS fallback and several other nice features will ultimately be possible too. So with all this in mind, I think the writing is very much on the wall with regards to the future integration of NetworkManager into the desktop. I believe we will be able to concentrate our resources better by going along with the rest of the world in this regard. I have personally switched to it now (as I do not need advanced features of draknetcenter et al) as a step towards this. So what can draknet do while NM can't? If such a thing exist, I think abandon draknet is not a good idea, since it's much more integrate into MCC. Also, is it possible to combine them up, like using draknet to support manage the connection , letting NM replace the role of net_applet? imho, the tools that are now available don't really work well together, ie: if you use multiple of those tools, likely they don't show correct status, etc... personally, i've used net_applet always and i would like to keep this.
