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

[Michael Scherer]

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