diff options
Diffstat (limited to 'zarb-ml/mageia-dev/2011-August/007484.html')
| -rw-r--r-- | zarb-ml/mageia-dev/2011-August/007484.html | 301 |
1 files changed, 301 insertions, 0 deletions
diff --git a/zarb-ml/mageia-dev/2011-August/007484.html b/zarb-ml/mageia-dev/2011-August/007484.html new file mode 100644 index 000000000..c443fb365 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007484.html @@ -0,0 +1,301 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> + <TITLE> [Mageia-dev] Proposal: Deprecate draknetcenter+network init scripts after systemd becomes default. + </TITLE> + <LINK REL="Index" HREF="index.html" > + <LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Proposal%3A%20Deprecate%20draknetcenter%2Bnetwork%20init%0A%20scripts%20after%20systemd%20becomes%20default.&In-Reply-To=%3C1314179194.2119.115.camel%40akroma.ephaone.org%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="007481.html"> + <LINK REL="Next" HREF="007510.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] Proposal: Deprecate draknetcenter+network init scripts after systemd becomes default.</H1> + <B>Michael Scherer</B> + <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Proposal%3A%20Deprecate%20draknetcenter%2Bnetwork%20init%0A%20scripts%20after%20systemd%20becomes%20default.&In-Reply-To=%3C1314179194.2119.115.camel%40akroma.ephaone.org%3E" + TITLE="[Mageia-dev] Proposal: Deprecate draknetcenter+network init scripts after systemd becomes default.">misc at zarb.org + </A><BR> + <I>Wed Aug 24 11:46:33 CEST 2011</I> + <P><UL> + <LI>Previous message: <A HREF="007481.html">[Mageia-dev] Proposal: Deprecate draknetcenter+network init scripts after systemd becomes default. +</A></li> + <LI>Next message: <A HREF="007510.html">[Mageia-dev] Proposal: Deprecate draknetcenter+network init scripts after systemd becomes default. +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#7484">[ date ]</a> + <a href="thread.html#7484">[ thread ]</a> + <a href="subject.html#7484">[ subject ]</a> + <a href="author.html#7484">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>Le mercredi 24 août 2011 à 09:19 +0200, Buchan Milne a écrit : +><i> On Tuesday, 23 August 2011 15:30:45 Colin Guthrie wrote: +</I>><i> > 'Twas brillig, and Guillaume Rousse at 23/08/11 12:16 did gyre and gimble: +</I>><i> > > On 23/08/2011 12:26, Colin Guthrie wrote: +</I>><i> > >>> How would removing initscripts support helps enhancing networkmanager +</I>><i> > >>> integration ? +</I>><i> > >> +</I>><i> > >> Because the current philosophy of the Unix legacy is lots of individual +</I>><i> > >> utils from various packages cobbled together with some glue shell +</I>><i> > >> scripting code... and it's dying. +</I>><i> > >> +</I>><i> > >> The things that these individual tools implement are a few relatively +</I>><i> > >> simply commands to the kernel and it doesn't make sense to do all this +</I>><i> > >> in shell. It makes much more sense to do all these jobs in efficient +</I>><i> > >> code that runs *quickly* without forking hundreds of times. The code is +</I>><i> > >> still perfectly visible and easily hackable, but now things are much +</I>><i> > >> more robust and efficient. +</I>><i> > > +</I>><i> > > Booting faster makes sense on desktops, not on servers. +</I>><i> > +</I>><i> > Agreed, but on servers additional capabilities are added that I very +</I>><i> > much care about (much more than I care about boot speed on my laptop if +</I>><i> > I'm honest - with my SSD I'm looking at a 1 or 2 second boots - who +</I>><i> > cares about that!). I'm actually much more excited about systemd on the +</I>><i> > server than I am on a desktop. +</I>><i> > +</I>><i> > The cgroup management +</I>><i> +</I>><i> We don't even have libcgroup or equivalent in the distribution yet ... so I +</I>><i> would say is is a bit premature to show this as an advantage IMHO ... +</I> +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 ) + + +><i> > and the ability to restart network services +</I>><i> > without losing a single connection is a revelation for me. +</I>><i> +</I>><i> Have all the services got support for this yet? +</I> +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> > I think the simplicity argument is bogus. You are (IMO) confusing +</I>><i> > simplicity with ease of readability. Sure you can read through a script, +</I>><i> > but the process of starting and maintaining services now becomes +</I>><i> > *standard*. I don't have to read scripts for every single one of the +</I>><i> > 1000s of init'ed services, +</I>><i> +</I>><i> I really don't read the scripts for every service, but quite often I do need +</I>><i> to adjust some setting catered for in the script, so I read +</I>><i> /etc/sysconfig/foo, and adjust it there. +</I> +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 <A HREF="http://0pointer.de/public/systemd-man/systemd.exec.html">http://0pointer.de/public/systemd-man/systemd.exec.html</A> + +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 ? + +><i> Although I have read a number of the systemd blogs, there are still some +</I>><i> unanswered questions. Such as, what should happen to utility functions in the +</I>><i> init scripts (e.g. 'service apache configtest' or 'service ldap check'), or +</I>><i> other checks that are done in the init script before starting the service +</I>><i> (such as ensuring ownership of files by the ldap user, which is a common trap +</I>><i> users fall into after doing an import, or re-indexing). +</I> +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> > I just need to understand the process of +</I>><i> > services management in general and I can pretty much work with +</I>><i> > everything. +</I>><i> +</I>><i> Surely 'service foo {start|stop|restart|reload}' is also a generic approach to +</I>><i> services management? +</I> +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. + +><i> > When you appreciate that, you'll see that systemd makes +</I>><i> > things much simpler overall. Sure you can't read a script, but that, in +</I>><i> > itself, has nothing to do with simplicity. Individual scripts tweaking +</I>><i> > certain things and adding secret arguments and such like is far, far +</I>><i> > more complex than a unified and defined way of working. +</I>><i> +</I>><i> But, sometimes they are required, and what is the replacement for the +</I>><i> functionality? +</I> +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 ) + +><i> > And yes, if we're honest, MacOS has a far superior boot system in +</I>><i> > launchd and the networking support is also better with it's fast-start +</I>><i> > DHCP and other such nice things. +</I>><i> +</I>><i> And MacOS has good server market share? +</I> +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 : +<A HREF="https://qa.mandriva.com/show_bug.cgi?id=40414">https://qa.mandriva.com/show_bug.cgi?id=40414</A> . 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> > I'm not suggesting network manager on servers here FWIW, but I think +</I>><i> > your reluctance to change should be massively outweighed by the benefits +</I>><i> > these changes bring, both to the server platform and to desktop systems. +</I>><i> +</I>><i> The rest of the discussion in this mail by now was about systemd. For +</I>><i> NetworkManager, I have some more questions. +</I>><i> +</I>><i> At present, a number of my machines have scripts that hook into the network +</I>><i> scripts. For example, one to update the bind forwarders from the DNS IPs +</I>><i> returned by pppd when the interface comes up. On another machine, a script +</I>><i> that unloads the wireless broadband driver when the interface goes down (I +</I>><i> think this modem has buggy firmware). Then, there are the existing scripts +</I>><i> shipped in the distribution (e.g. to reload squid). +</I>><i> +</I>><i> In the NetworkManager world, are all of these taken care of? If not, and I +</I>><i> have to script them myself, now I guess I have to hook in to NM via dbus? +</I> +><i>From what I see : +</I> +$ 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 ( +<A HREF="http://fedoraproject.org/wiki/Features/DNSSEC_on_workstations">http://fedoraproject.org/wiki/Features/DNSSEC_on_workstations</A> ) + + +-- +Michael Scherer + +</PRE> + + + + + + + + + + + + + + + + + + + + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="007481.html">[Mageia-dev] Proposal: Deprecate draknetcenter+network init scripts after systemd becomes default. +</A></li> + <LI>Next message: <A HREF="007510.html">[Mageia-dev] Proposal: Deprecate draknetcenter+network init scripts after systemd becomes default. +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#7484">[ date ]</a> + <a href="thread.html#7484">[ thread ]</a> + <a href="subject.html#7484">[ subject ]</a> + <a href="author.html#7484">[ author ]</a> + </LI> + </UL> + +<hr> +<a href="https://www.mageia.org/mailman/listinfo/mageia-dev">More information about the Mageia-dev +mailing list</a><br> +</body></html> |