[Mageia-dev] Proposal: Deprecate draknetcenter+network init scripts after systemd becomes default.

Wed Aug 24 11:46:33 CEST 2011

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. 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?
+
+before, you edited /etc/sysconfig/ file to add the argument to a
+environnement variable that was either added to the command line
+directly, or that was checked in shell to add a argument ( with each
+distribution having its own semantic ), or that was directly interpreted
+by the binary .
+
+after, you edit a file similar to a .ini to add the argument to the
+binary, in the line Exec=, or you just add the env var in a file
+dedicated to get environnement ( and that file could even be
+the /etc/sysconfig/ file that you adjusted before ). 
+
+Most case seems covered, do you have a case where this would not work ?
+
+( and in which case we would have to just use the previous initscript as
+we did before )
+
+> > 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?
+
+Market share on server of mac os is irrelevant to the fact it has a
+better boot system.
+
+We cannot say that people used Unix because shell scripts were so good,
+since that's also what OSX used before 10.4. 
+
+Current shell scripts are error prone, take ressources, and requires
+kludge breaking from time to time. While I do not really care about the
+ressources taken by shell script, I am more concerned about the kludge.
+Just on our servers, we faced :
+- bind, that need to sleep before being restarted, that caused several
+outage on our infrastructure due to puppet ( and us ) not knowing this.
+Puppet use by default stop/start to restart a service, since not all
+initscripts have a restart command, and there is no sane way to know if
+it support it ( at least, not a way to would work reliabiliy with some
+vendor provided crappy scripts ).
+ 
+- sympa, that requires postgresql to be up before it can start or it
+block the boot. ( so my vms were not starting, while it worked by chance
+on real hardware ). While the missing requires in unfortunate and would
+not have been avoided by systemd, the fact it block the boot was rather
+more annoying and would likely have worked better ( not sure why pinit
+didn't work as it should :/ )
+
+- puppet, with stupid error like this one :
+https://qa.mandriva.com/show_bug.cgi?id=40414 . By not requiring to
+write code to do that, a init system like systemd reduce the number of
+potential bugs, since there is less line of code. 
+
+Vincent Danen wanted to push runit on mandriva ( and did so on annvix )
+years ago, for features that systemd also offers ( such as automated
+system restarting ). 
+
+So i think there is place and even a need for something better than
+current initscripts.
+
+> > 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?
+
+>From what I see :
+
+$ ls /etc/NetworkManager/dispatcher.d 
+00-netreport  04-iscsi  05-netfs  10-sendmail  11-dhclient
+
+$ cat  /etc/NetworkManager/dispatcher.d/10-sendmail
+#!/bin/sh
+
+case "$2" in
+	up|down|vpn-up|vpn-down)
+		/sbin/service sendmail reload || :
+		;;
+esac
+
+- squid reloading, others scripts
+If the action for most of them is to be reloaded when a interface
+change, this is also already covered by the dispatcher.d directory.
+For the rest, it will depend on what it need, and nothing forbid us from
+adding compatibility scripts for the migration.
+
+
+- wireless broadband unloading
+While there is lots of efforts to support buggy hardware, I am not sure
+that nm does it by default. yet, this would be trivial to do
+with /etc/NetworkManager/dispatcher.d , where script are run each time a
+interface goes up, or down ( or vpn, or when the hostname change )
+
+
+- pppd to update bind resolver
+I think the current dispatcher do not give you the information about
+resolver directly, so you have to parse /etc/resolv.conf for yourself. 
+However, there is a experimental plugin in nm to use and manage bind as
+a local caching resolver, the goal is to make it do dnssec validation (
+http://fedoraproject.org/wiki/Features/DNSSEC_on_workstations )
+
+
+-- 
+Michael Scherer
+
+