Re: insserv + apache2 + bind9 = pain
Hi, Debian package respects all sysadmin choices. We do not overwrite them. If not, that is a serious bug. Some careful and respectful questining to keep this promise seem to annoy some people who have not found typical work around steps. (Besides, there were some bug on apatch2 package.) On Thu, Dec 30, 2010 at 07:24:19PM -0500, Tom H wrote: ... IIUC, you'll be prompted at every upgrade of /etc/init.d/apache2 to choose between your local copy or the maintainer's or to view a diff (or a fourth option that I can't remember at the moment; shell prompt?). I guess apach2 has some postinst script which alters conffile every time. If so, you may be asked repeated questions. (Most packages are not. If packager use fancy techniques, we can avoid such question. You may request such to the maintainer. See http://packages.debian.org/lenny/ucf) Still, this is an user selectable feature as I understand via apt.conf(5) via Dpkg or /etc/dpkg/dpkg.cfg. As I read dpkg(1), --force-confold is what you want. These feature can be changed. (But doing so will cause some other issues such as not keeping up with upfdated initialization scheme.) This changes applies not just for apatch2 but applies for all. I do not know if I can selectively apply this only for the apatch2 package. That is interesting wishlist bug. If I got into such hussle issue and need to deal for many machines, I will think about using apt.conf(5) via Dpkg::Pre-Invoke, Dpkg::Post-Invoke. There you run your script to save and restore your custom configuration files with your custom santy chacks if it is absolutely needed. Maybe fai etc have fancy method for such high power admin. But it seems small hussle for me to say Use old or run small hack script since I am a small system admin. If you create such script or work around nicely, let us know. Osamu -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110105165048.ga9...@debian.org
Re: insserv + apache2 + bind9 = pain
Hi, On Sat, Jan 01, 2011 at 03:29:21PM +0200, Andrei Popescu wrote: I know you know very well on Debian system but may not be old enough to use dselect with dpkg-ftp etc :-) So some historic comments differ from what I thought. On Vi, 31 dec 10, 12:24:34, Bob Proulx wrote: Andrei Popescu wrote: Bob Proulx wrote: Mike Bird wrote: But then they abuse the Debian packaging system by requiring instead of recommending unnecessary packages so that people are forced to use their silly hacks. The new APT default is that Recommends are the same as Requires and so a lot of unnecessary packages are now installed. Those should now be pushed into Suggests. Feel free to file bugs for every package which abuses Recommends. Beware though, that Recommends, according to Policy, should be installed on all but unusual installations. The question is really one of philosophy. Do you start with a good foundation and then build upward? Or do you start with a large fully filled out structure and then remove the extraneous material? From what I understand, Debian started building upward. The only problem was that apt-get for a long time did not install recommends by default. Debian installation was to install recommends by default as I remember. That was the reason why dselect was the default and apt was not for installation for good long time. This upcoming release note uses apt-get since its behavior is OK now and aptitude is not optimal for non-interactive session. When this was eventually switched on the developers found out they suddenly have too much material and need to trim the dependencies down. The good side was that some dependencies could be degraded to recommends. What happened (as I understand) was while apt-get was widely used by power users, many package maintainers started to abuse recommend when they should have used suggests. That was sloppy and we need to file bug report on such packages. I see some packages use recommends too casually. And where they didn't trim up to your liking you can still use some interactive package manager (like aptitude and synaptic) to weed the recommends one by one, or even more drastic, completely disable automatic install of recommends. Both apt-get and aptitude can chose to install recommends. It is just easier with aptitude etc. In my opinion we have more functionality without completely sacrificing choice. I agree. Osamu -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110104143522.ge13...@debian.org
Re: Re: insserv + apache2 + bind9 = pain
The rcN.d format is an excellent design if we can just keep insserv from mangling it. As I haven't converted one of my systems to dependency based boot yet, there still has to be some way to keep the old way. No idea why there is no documented way to switch that on... It could be that touch /etc/init.d/.legacy-bootordering dpkg-reconfigure -plow sysv-rc does the trick, but I haven't tried it. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201101022259.01710...@sfritsch.de
Re: insserv + apache2 + bind9 = pain
On Sun January 2 2011 13:59:01 Stefan Fritsch wrote: The rcN.d format is an excellent design if we can just keep insserv from mangling it. As I haven't converted one of my systems to dependency based boot yet, there still has to be some way to keep the old way. No idea why there is no documented way to switch that on... You should be able to preserve the old way by correctly answering the question when insserv is installed or sysv-rc is updated. We haven't tested that yet so I can't vouch for it. If you try it please let us know if it's safe. For our first three test upgrades we assumed insserv would not destroy the boot order as there is no warning in the debconf question or the release notes. Our third test upgrade was the first server test upgrade, and that was when we realized that insserv is a disaster. --Mike Bird -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201101021437.26516.mgb-deb...@yosemite.net
Re: insserv + apache2 + bind9 = pain
On Vi, 31 dec 10, 12:24:34, Bob Proulx wrote: Andrei Popescu wrote: Bob Proulx wrote: Mike Bird wrote: But then they abuse the Debian packaging system by requiring instead of recommending unnecessary packages so that people are forced to use their silly hacks. The new APT default is that Recommends are the same as Requires and so a lot of unnecessary packages are now installed. Those should now be pushed into Suggests. Feel free to file bugs for every package which abuses Recommends. Beware though, that Recommends, according to Policy, should be installed on all but unusual installations. The question is really one of philosophy. Do you start with a good foundation and then build upward? Or do you start with a large fully filled out structure and then remove the extraneous material? From what I understand, Debian started building upward. The only problem was that apt-get for a long time did not install recommends by default. When this was eventually switched on the developers found out they suddenly have too much material and need to trim the dependencies down. The good side was that some dependencies could be degraded to recommends. And where they didn't trim up to your liking you can still use some interactive package manager (like aptitude and synaptic) to weed the recommends one by one, or even more drastic, completely disable automatic install of recommends. In my opinion we have more functionality without completely sacrificing choice. Regards, Andrei -- Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic signature.asc Description: Digital signature
Re: insserv + apache2 + bind9 = pain
On Vi, 31 dec 10, 13:13:39, Mike Bird wrote: On Fri December 31 2010 10:51:18 Arthur Machlas wrote: As for all the talk of losing years of wisdom and bug squashing and what-not, I'm not really sure that's the case, but a debate about the worthiness of insserv as a successor to all the Snn Knn links is probably better suited to another thread, perhaps one where more dev's hang out than here on user. In any event, if you hope to convince people of that, I think calling DD's Script kiddies, especially one who just resolved the bug you noted and I reported within about 12 hrs, probably won't leave them too open to taking your position seriously. Nobody has called the Apache2 maintainers script kiddies. Most Debian Developers are excellent and dedicated to Debian rather than their own egos. It is the DD's work in developing the Snn/Knn values over many years that needs to be protected from randomization by the script kiddies. The script kiddies are those who abused the Debian packaging system to make sysv-rc REQUIRE the harmful and unnecessary insserv. I'm sure you are aware that insserv is doing the (re)ordering based on the LSB headers in each initscript. Don't you think your rant is exaggerated? Regards, Andrei -- Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic signature.asc Description: Digital signature
Re: insserv + apache2 + bind9 = pain
On Sat January 1 2011 06:00:54 Andrei Popescu wrote: I'm sure you are aware that insserv is doing the (re)ordering based on the LSB headers in each initscript. Don't you think your rant is exaggerated? Please read the thread. I don't think there is merit in repeating it here. --Mike Bird -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201101011356.27705.mgb-deb...@yosemite.net
Re: insserv + apache2 + bind9 = pain
On Thu December 30 2010 22:27:33 Arthur Machlas wrote: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=608437 Wow, that was fast! Thank you all! -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201012310325.40518.mgb-deb...@yosemite.net
Re: insserv + apache2 + bind9 = pain
On Thu December 30 2010 22:29:00 Arthur Machlas wrote: Have you considered file-rc? file-rc is on our list as a possible fallback but the key seems to be to recover and then retain the combined intelligence that Debian Developers have encoded into those Snn/Knn values over the years. The rcN.d format is an excellent design if we can just keep insserv from mangling it. --Mike Bird -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201012310330.35965.mgb-deb...@yosemite.net
Re: insserv + apache2 + bind9 = pain
On Fri, Dec 31, 2010 at 6:30 AM, Mike Bird mgb-deb...@yosemite.net wrote: On Thu December 30 2010 22:29:00 Arthur Machlas wrote: Have you considered file-rc? file-rc is on our list as a possible fallback but the key seems to be to recover and then retain the combined intelligence that Debian Developers have encoded into those Snn/Knn values over the years. file-rc's moving towards using dependency-based boot: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=573004 -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktinx409uhbjg1zkwrasrsertadcftixqt3_gb...@mail.gmail.com
Re: insserv + apache2 + bind9 = pain
On Fri December 31 2010 06:32:27 Tom H wrote: file-rc's moving towards using dependency-based boot: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=573004 It's bad enough that script kiddies insist on breaking things they don't understand. But then they abuse the Debian packaging system by requiring instead of recommending unnecessary packages so that people are forced to use their silly hacks. Oh well. I'm sure we'll find a way to preserve the many years of work by Debian Developers that is encoded in the Snn/Knn values. The only question is whether it's a clean on-off switch or whether we have to hack the source. Here's to freedom and a great insserv-or-not-insserv new year! --Mike Bird -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201012311029.54026.mgb-deb...@yosemite.net
Re: insserv + apache2 + bind9 = pain
Mike Bird wrote: But then they abuse the Debian packaging system by requiring instead of recommending unnecessary packages so that people are forced to use their silly hacks. The new APT default is that Recommends are the same as Requires and so a lot of unnecessary packages are now installed. Those should now be pushed into Suggests. Bob signature.asc Description: Digital signature
Re: insserv + apache2 + bind9 = pain
On Fri, Dec 31, 2010 at 12:35 PM, Bob Proulx b...@proulx.com wrote: Mike Bird wrote: But then they abuse the Debian packaging system by requiring instead of recommending unnecessary packages so that people are forced to use their silly hacks. The new APT default is that Recommends are the same as Requires and so a lot of unnecessary packages are now installed. Those should now be pushed into Suggests. Bob This post is pretty much entirely OT, but let's not start the New Year with innaccurate information. Recommends are NOT the same as Requires. What's happened - as of Lenny I thought, but perhaps Squeeze - is that the option to install recommends automatically is now turned on by default instead of off by default. You are, of course, free to change it back to off before building up your minimal/customized install. As for all the talk of losing years of wisdom and bug squashing and what-not, I'm not really sure that's the case, but a debate about the worthiness of insserv as a successor to all the Snn Knn links is probably better suited to another thread, perhaps one where more dev's hang out than here on user. In any event, if you hope to convince people of that, I think calling DD's Script kiddies, especially one who just resolved the bug you noted and I reported within about 12 hrs, probably won't leave them too open to taking your position seriously. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktik_gd1fc2npuv2vkl153vbozmixuobrucs=v...@mail.gmail.com
Re: insserv + apache2 + bind9 = pain
On Vi, 31 dec 10, 11:35:26, Bob Proulx wrote: Mike Bird wrote: But then they abuse the Debian packaging system by requiring instead of recommending unnecessary packages so that people are forced to use their silly hacks. The new APT default is that Recommends are the same as Requires and so a lot of unnecessary packages are now installed. Those should now be pushed into Suggests. Feel free to file bugs for every package which abuses Recommends. Beware though, that Recommends, according to Policy, should be installed on all but unusual installations. Kind regards, Andrei -- Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic signature.asc Description: Digital signature
Re: insserv + apache2 + bind9 = pain
Andrei Popescu wrote: Bob Proulx wrote: Mike Bird wrote: But then they abuse the Debian packaging system by requiring instead of recommending unnecessary packages so that people are forced to use their silly hacks. The new APT default is that Recommends are the same as Requires and so a lot of unnecessary packages are now installed. Those should now be pushed into Suggests. Feel free to file bugs for every package which abuses Recommends. Beware though, that Recommends, according to Policy, should be installed on all but unusual installations. The question is really one of philosophy. Do you start with a good foundation and then build upward? Or do you start with a large fully filled out structure and then remove the extraneous material? I am a builder and so desire starting small and then adding on as needed. But if you are a sculptor then you desire to start fully formed and to remove the material you don't want present. I realize that these two ideologies are in opposition. But I think one is more scalable than the other and more suitable for a universal operating system. Bob signature.asc Description: Digital signature
Re: insserv + apache2 + bind9 = pain
On Fri December 31 2010 11:24:34 Bob Proulx wrote: The question is really one of philosophy. Do you start with a good foundation and then build upward? Or do you start with a large fully filled out structure and then remove the extraneous material? Harmful RECOMMENDS can at least be removed or blocked. When unnecessary and harmful packages are REQUIRED in order to satisfy some script kiddy's ego that's abuse of the packaging system. --Mike Bird -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201012311305.02059.mgb-deb...@yosemite.net
Re: insserv + apache2 + bind9 = pain
On Fri December 31 2010 10:51:18 Arthur Machlas wrote: As for all the talk of losing years of wisdom and bug squashing and what-not, I'm not really sure that's the case, but a debate about the worthiness of insserv as a successor to all the Snn Knn links is probably better suited to another thread, perhaps one where more dev's hang out than here on user. In any event, if you hope to convince people of that, I think calling DD's Script kiddies, especially one who just resolved the bug you noted and I reported within about 12 hrs, probably won't leave them too open to taking your position seriously. Nobody has called the Apache2 maintainers script kiddies. Most Debian Developers are excellent and dedicated to Debian rather than their own egos. It is the DD's work in developing the Snn/Knn values over many years that needs to be protected from randomization by the script kiddies. The script kiddies are those who abused the Debian packaging system to make sysv-rc REQUIRE the harmful and unnecessary insserv. --Mike Bird -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201012311313.39902.mgb-deb...@yosemite.net
Re: insserv + apache2 + bind9 = pain
On Fri, Dec 31, 2010 at 01:13:39PM -0800, Mike Bird wrote: [...] The script kiddies are those who abused the Debian packaging system to make sysv-rc REQUIRE the harmful and unnecessary insserv. By the way, apt-cache shows me for sysv-rc: Priority: required Depends: ... insserv ... And yet insserv has: Priority: optional Does that make sense? Not to a layman like me. Cheers, David -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110101000135.ga4...@gennes.augarten
Re: insserv + apache2 + bind9 = pain
On Wed, 29 Dec 2010 21:16:06 +0100, Klistvud wrote: Dne, 29. 12. 2010 20:29:38 je Camaleón napisal(a): On Wed, 29 Dec 2010 10:12:45 -0800, Mike Bird wrote: On Wed December 29 2010 01:43:09 Camaleón wrote: On Wed, 29 Dec 2010 01:37:48 -0800, Mike Bird wrote: The question is not whether the problem can be solved. Then what do you want? Just complain? I STARTED this thread by posting a solution[1]. And I asked if there is a better solution. Sir, please, again... *stop* your foolish monologue. And stop *lying* about my postings :-/ I agree, Camaleón. Sir, Camaleón has gone out of her way to help you, although it was in no way her duty to do so. It's not that we get paid to help you or anything. This is just a volunteer mailing list where users try to help each other to the best of their abilities. A certain level of mutual respect, even courtesy, is expected. (...) Thanks, I really don't know what's got into him to reply the way he did :-/ Greetings, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pan.2010.12.30.09.54...@gmail.com
Re: insserv + apache2 + bind9 = pain
On Wed, 29 Dec 2010 12:08:10 -0800, Mike Bird wrote: On Wed December 29 2010 11:29:38 Camaleón wrote: On Wed, 29 Dec 2010 10:12:45 -0800, Mike Bird wrote: On Wed December 29 2010 01:43:09 Camaleón wrote: On Wed, 29 Dec 2010 01:37:48 -0800, Mike Bird wrote: The question is not whether the problem can be solved. Then what do you want? Just complain? I STARTED this thread by posting a solution[1]. And I asked if there is a better solution. Sir, please, again... *stop* your foolish monologue. And stop *lying* about my postings :-/ Please be quiet Camaleón until you have something positive to contribute. Re-read my messages. If you are in doubt about their meaning, please tell. I have not lied about your postings. I started this thread by posting a solution[1] and by asking if there is a better solution. And I told you another way to get the job done (in fact, if you read the manual, is one of the recommended ways of doing it) and some hints on how to debug the error of the non-booting service (by disabling pararel booting). But you are only complaining about something that -I think- you don't fully understand and not attending to anything else (nor Debian developer's reasons who wanted to make the change to insserv, nor documentation, nor helping in enhance it... nothing!). All of the partipants in this thread other than you are trying to find a better solution to the serious problems created by insserv. You contributed one poor and ill-considered suggestion and since then your SNR has degenerated to zero. This will be the last message I reply on this matter. You look like a child wanting to have things the way you want and not hearing to anyone's else advice (and you even go against who tried to help you!) so I can't do more :-( It's not my fault that you don't know how to debug a non-booting service nor that you don't know how insserv and sys-rc works. It's neither my fault that you don't want to help your distribution to correct the lacks you are finding in documentation. And of course is not my fault that you can't even understand what I wrote. Grow up! Greetings, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pan.2010.12.30.11.42...@gmail.com
Re: insserv + apache2 + bind9 = pain
On Thu, Dec 30, 2010 at 5:42 AM, Camaleón noela...@gmail.com wrote: It's not my fault that you don't know how to debug a non-booting service nor that you don't know how insserv and sys-rc works. It's neither my fault that you don't want to help your distribution to correct the lacks you are finding in documentation. And of course is not my fault that you can't even understand what I wrote. Grow up! Dear Cam, You're delusional about OP and acting like a massive douchebag. Oh, and you're a last-word-troll too. So I highly doubt that will be your last message... on the matter. Kind regards, AM -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlkti=gae+nyoau5j1bkwerwuf+aaetn1g39b3am...@mail.gmail.com
Re: insserv + apache2 + bind9 = pain
On Thu December 30 2010 03:42:45 Camaleón wrote: On Wed, 29 Dec 2010 12:08:10 -0800, Mike Bird wrote: I have not lied about your postings. I started this thread by posting a solution[1] and by asking if there is a better solution. And I told you another way to get the job done (in fact, if you read the manual, is one of the recommended ways of doing it) and some hints on how to debug the error of the non-booting service (by disabling pararel booting). But you are only complaining about something that -I think- you don't fully understand and not attending to anything else (nor Debian developer's reasons who wanted to make the change to insserv, nor documentation, nor helping in enhance it... nothing!). (Sigh). I do a lot of volunteer teaching, but not usually in this subject area. Oh well, here goes ... Parallelism isn't the issue. The issue is that insserv throws away years of work by Debian Developers, causing services to boot in the wrong order, and thus to fail. I found the problem, debugged it, and created a solution before posting. I posted that solution when I started this thread. And I asked if there is a BETTER solution.[1] You replied with a different solution but not a better solution. In fact, within the limits of the appalling documentation, your solution appears to be worse. Understanding why your solution is worse is a small step on your road to becoming a competent sysadmin. My solution is to create a file in /etc/insserv/overrides. My solution at this time handles upgrades perfectly. However the lack of proper documentation means that we don't know if conflicts may arise in future if a Debian package wants to create a file with the same name in that directory. Your solution is to edit /etc/init.d/apache2. Your solution requires manual intervention on every apache2 upgrade. Therefore your solution is worse than mine. However I would still appreciate it if anyone can offer a better solution than mine, or Debian's policy on which of the five or more sources of dependency information are for sysadmins and which are for packagers, or Debian's policy on which of the five or more sources of dependency information will in future automatically migrate to upstart or systemd or launchd, or where the mysterious dependency between openvpn and gdm3 is declared, or advice on reverting this insserv mess and using the reliable Snn/Knn startup sequencing for Squeeze servers. Now if you want to keep arguing who has the largest cojones, please take it elsewhere. Nobody will argue with you. This thread is about insserv problems and solutions. Anything else is off-topic. --Mike Bird [1] http://lists.debian.org/debian-user/2010/12/msg01609.html -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201012301057.39599.mgb-deb...@yosemite.net
Re: insserv + apache2 + bind9 = pain
On Thu, Dec 30, 2010 at 1:57 PM, Mike Bird mgb-deb...@yosemite.net wrote: Your solution is to edit /etc/init.d/apache2. Your solution requires manual intervention on every apache2 upgrade. Apparently not: http://lists.debian.org/debian-user/2010/12/msg00550.html -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/AANLkTikBtYbeCXOqN5JX8yAjq0ShiF;71qpcx8d...@mail.gmail.com
Re: insserv + apache2 + bind9 = pain
On Thu December 30 2010 12:13:03 Tom H wrote: On Thu, Dec 30, 2010 at 1:57 PM, Mike Bird mgb-deb...@yosemite.net wrote: Your solution is to edit /etc/init.d/apache2. Your solution requires manual intervention on every apache2 upgrade. Apparently not: http://lists.debian.org/debian-user/2010/12/msg00550.html I see. So for packages which respect editing /etc/init.d/ files, manual intervention is required every time the packager changes the virgin /etc/init.d/ file, but not necessarily on every upgrade. Thank you, Tom. Nevertheless, this is still more manual intervention than if the override is placed in /etc/insserv/overrides, or some but not all of the many other places where dependencies can be declared. Some of the open questions are which of those many places are reserved for Debian packagers and which are reserved for sysadmins; and which if any will be automatically converted to systemd or launchd or upstart when insserv is thrown out. --Mike Bird -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201012301250.44792.mgb-deb...@yosemite.net
Re: insserv + apache2 + bind9 = pain
On Thu, Dec 30, 2010 at 3:50 PM, Mike Bird mgb-deb...@yosemite.net wrote: On Thu December 30 2010 12:13:03 Tom H wrote: On Thu, Dec 30, 2010 at 1:57 PM, Mike Bird mgb-deb...@yosemite.net wrote: Your solution is to edit /etc/init.d/apache2. Your solution requires manual intervention on every apache2 upgrade. Apparently not: http://lists.debian.org/debian-user/2010/12/msg00550.html I see. So for packages which respect editing /etc/init.d/ files, manual intervention is required every time the packager changes the virgin /etc/init.d/ file, but not necessarily on every upgrade. Thank you, Tom. Nevertheless, this is still more manual intervention than if the override is placed in /etc/insserv/overrides, or some but not all of the many other places where dependencies can be declared. Some of the open questions are which of those many places are reserved for Debian packagers and which are reserved for sysadmins; and which if any will be automatically converted to systemd or launchd or upstart when insserv is thrown out. You're welcome. IIUC, you'll be prompted at every upgrade of /etc/init.d/apache2 to choose between your local copy or the maintainer's or to view a diff (or a fourth option that I can't remember at the moment; shell prompt?). As a sysadmin, I'd choose to use /etc/insserv/overrides or /etc/insserv.conf.d rather than /etc/init.d or /etc/insserv.conf respectively if at all possible. As an aside, you refer to the pre-insserv setup as Snn/Knn startup mechanism but insserv doesn't deviate from that style. insserv creates the Snn/Knn symlinks dynamically in an order determined by a set of dependencies. pre-insserv the symlinks' order was set statically by the maintainers. No comment on the post-insserv setup except to say that I hope that it isn't launchd because I'd rather not have to deal with its xml daemon and agent definitions. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlkti=cdirivoar2akomcxi60qvbgjgsyoaejanx...@mail.gmail.com
Re: insserv + apache2 + bind9 = pain
On Thu December 30 2010 16:24:19 Tom H wrote: As an aside, you refer to the pre-insserv setup as Snn/Knn startup mechanism but insserv doesn't deviate from that style. insserv creates the Snn/Knn symlinks dynamically in an order determined by a set of dependencies. pre-insserv the symlinks' order was set statically by the maintainers. That's a good point Tom. insserv is not even properly parallel, just some kind of ha...@$$ed semi-parallel - starting groups of services in parallel but the groups are run serially. I'd like to call the old mechanism sysv-rc but the insserv developer has abused the Debian package upgrade process to turn sysv-rc into insserv hell. We're trying to figure out the cleanest way to stop insserv from throwing away all the Snn/Knn information that Debian Developers have created over the years. Then we'll attempt to reset the Snn/Knn to those sane values. My first thought was a loop over update-rc.d $script defaults but that no longer seems to work. Still looking for a clean remedy. Hopefully there's a nice on-off switch in there somewhere. I'm mostly working on some other projects now but I hope to be able to work on this full-time in a few days. --Mike Bird -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201012301656.59318.mgb-deb...@yosemite.net
Re: insserv + apache2 + bind9 = pain
On Thu, Dec 30, 2010 at 6:56 PM, Mike Bird mgb-deb...@yosemite.net wrote: On Thu December 30 2010 16:24:19 Tom H wrote: As an aside, you refer to the pre-insserv setup as Snn/Knn startup mechanism but insserv doesn't deviate from that style. insserv creates the Snn/Knn symlinks dynamically in an order determined by a set of dependencies. pre-insserv the symlinks' order was set statically by the maintainers. That's a good point Tom. insserv is not even properly parallel, just some kind of ha...@$$ed semi-parallel - starting groups of services in parallel but the groups are run serially. I'd like to call the old mechanism sysv-rc but the insserv developer has abused the Debian package upgrade process to turn sysv-rc into insserv hell. We're trying to figure out the cleanest way to stop insserv from throwing away all the Snn/Knn information that Debian Developers have created over the years. Then we'll attempt to reset the Snn/Knn to those sane values. My first thought was a loop over update-rc.d $script defaults but that no longer seems to work. Still looking for a clean remedy. Hopefully there's a nice on-off switch in there somewhere. I'm mostly working on some other projects now but I hope to be able to work on this full-time in a few days. --Mike Bird http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=608437 -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktin6sf=utsbbx1ytjrccdgstp79-p2gex=o55...@mail.gmail.com
Re: insserv + apache2 + bind9 = pain
On Fri, Dec 31, 2010 at 12:27 AM, Arthur Machlas arthur.mach...@gmail.com wrote: We're trying to figure out the cleanest way to stop insserv from throwing away all the Snn/Knn information that Debian Developers have created over the years. Then we'll attempt to reset the Snn/Knn to those sane values. Have you considered file-rc? -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktikl2qqexfx+oihj5nzidqcekj2kp8arqvp9v...@mail.gmail.com
Re: insserv + apache2 + bind9 = pain
On Tue, 28 Dec 2010 12:07:30 -0800, Mike Bird wrote: On Tue December 28 2010 10:56:48 Camaleón wrote: JFYI: apache2: fails to start with dependency based boot if DNS is required by configuration http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=606334 Thank you for the link but the bug is not in Apache. Nobody said that. I pointed you to the bug because you are experiencing the same situation. You still don't know (or did not tell) why your apache fails to boot at start up. You can add your comments to the report to help fixing the problem. The bug is the poorly thought out and poorly documented startup mechanism which is being pushed onto previously stable and reliable Debian servers. AFAIK, booting scripts have been rewrited to play with dependency booting and provided this is new for Squeeze, I would expect some glitches, but nothing that cannot be solved. People have also encountered problems with MySQL, Request Tracker, Apache, and Bind. We haven't even started testing LDAP, Samba, Postfix, ClamSMTP, ClamAV, Quagga, YP/NIS, WordPress etc in the various combinations and with the various configurations and various plugins employed on different servers. Then you better report them in BTS. There is no chance to get them fixed is nobody is aware of the problem. If anyone doubts it's a nightmare, take a look at the sysv-rc changelog and see how many special case hacks and weeks of effort went into getting insserv to work with just a virgin Linux system with no significant services running. Again, I've been using for years this booting system (yes, in my racked servers) and nothing terribly happened. Remember that configuring the priorities of N services is O(N), while configuring all their dependencies is O(N*N). It just doesn't scale on real world servers. You're breaking stable Debian servers and pushing all the repair work on Debian users and sysadmins. FOR NO GOOD REASON. Reasons were stated time ago: http://lists.debian.org/debian-devel-announce/2009/09/msg3.html More here: http://wiki.debian.org/LSBInitScripts/DependencyBasedBoot In fact, I guess dependency boot system will be soon replaced by newer methods, like systemd or upstart. Dependency booting can be new in Debian but not in the linux world. What's worse is that the startup sequence is not repeatable. A service required may just happen to be ready in time on most reboots but start up a little slower sometimes and thus cause intermittent failures. Analyzing every piece of code and configuration on a system - some of it written more than ten years ago - is a nightmare. Disable parallel booting and see if you get any gain. It's the Microsoft way to use a separate box for each service but prior to Squeeze it has always been a big selling point for Debian that you could always add another service to a box and it would just work. In the past Debian has worked REALLY WELL for small businesses and schools. Things change, but again, this is not new is only that you are not used to it. There's no VALID reason for FORCING insserv on Debian servers other than someone's desire to see his/her software being used. Open a wishlist report (to express your thoughts and concerns on this matter) or a documentation report (so the new boot method gets well documented) or write an e-mail to Debian devel mailing list. You can complain about the things you don't like and you can also help to get them fixed. Choose your poison... you can even choose both paths: complain and help to fix errors :-) So I will repeat the key question, and with increased desperation: How do we run the old reliable Snn/Knn style startup mechanism in Squeeze? It is still there (sysv-rc and insserv play together) and I already answered to that question. In fact, I remember that months ago I was asked by the installer if I wanted to migrate to the new dependency boot and I choose yes. What have you already tested for getting rid of insserv? Did you try to remove the package (insserv)? Did you try by reconfiguring it? (don't do these things on production servers but in testing machines). If it does not work, please, tell what is exactly failing so anyone can help you with this. Greetings, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pan.2010.12.29.08.13...@gmail.com
Re: insserv + apache2 + bind9 = pain
On Tue, Dec 28, 2010 at 1:06 PM, Mike Bird mgb-deb...@yosemite.net wrote: On Tue December 28 2010 01:31:50 Camaleón wrote: On Tue, 28 Dec 2010 00:10:23 -0800, Mike Bird wrote: Is it possible to go back to the old system? If you mean how to disable dependency booting yes, you can disable it to get the old behaviour, but you will still have to ensure bind9 is started before apache2: http://www.debian.org/releases/squeeze/i386/release-notes/ch-whats-new.en.h tml#dependency-boot Thank you Camaleón. CONCURRENCY=none may help some people with different problems, but it does not solve the problem of unexpressed dependencies. Is there a way to use the old-style reliable init system based on the Snn and Knn values in rcn.d? Real servers have dependencies among numerous server processes. A few of these dependencies relate to Debian packaging but far more relate to configuration, scripting, plugins, and even custom programming. It is simply not worth the effort to spend hours trying to discover and express all the dependencies on a bunch of servers in order to save half a second of boot time once per year. It took me four hours to discover what was wrong in a very simple case. This was not helped by failures to log errors, bootchart2 missing from Squeeze, a near complete lack of documentation, and insserv silently ignoring errors in my early attempts to express missing dependencies. I've read the very thin /usr/share/doc and man documentation and googled extensively. The new system may be great for script kiddies rebooting their Ubuntu laptops twice a day but it is an appalling idea for Debian servers. It not only scales terribly (on the order of N squared dependencies instead of N priorities) but is also very poorly documented. I also found the insserv documentation frustrating when I first tried squeeze about a year ago. It took me a few tries to figure out the correct way of using overrides... When I was googling insserv last year, I landed on a d-devel thread where some posters were arguing that the current init system ought to be kept as an option for those who didn't want to use dependency-based boot. But the decision to make dependency-based boot inescapable seems to have been taken and, like grub2, we're stuck with it - until, it seems, squeeze+1/squeeze+2, when we'll have the immense pleasure of changing yet again to upstart or systemd. (By the way, Ubuntu laptops use upstart to allow script kiddies to boot faster, not insserv.) -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktimcqkt_zxag0r5d=n7brwd6ck-bz_ejyc-3z...@mail.gmail.com
Re: insserv + apache2 + bind9 = pain
On Wed December 29 2010 00:13:04 Camaleón wrote: AFAIK, booting scripts have been rewrited to play with dependency booting and provided this is new for Squeeze, I would expect some glitches, but nothing that cannot be solved. The question is not whether the problem can be solved. People can as a last resort always hack the source. The immediate question is whether the insserv mess can be reasonably maintained. And the big picture question is whether the ego boost for the insserv developer is worth the substantial hit to Debian's reputation. I'll give you just a few examples that we've run into since this thread started a few hours ago. (1) We cannot find any useful documentation as to who controls /etc/init.d/foo, /etc/insserv/overrides/foo, /etc/insserv.conf.d/foo, /usr/share/insserv/overrides/foo, and /etc/insserv.conf. All of these can be used to specify dependencies. Which are intended for Debian packagers, and which for sysadmins? Which are supported properly through upgrades and dist-upgrades? How are conflicts between the five sources of dependencies handled, i.e. which has priority over which others? You recommended that sysadmins edit /etc/init.d/foo. Is that Debian policy or a kludge that will cause pain on the next upgrade? Would it be better to use one of the many other places where overrides can be specified? (2) There are many kinds of connections and tunnels and routes that need to be established on some boxes but not on others. For example, some servers need ethernet interfaces, then openvpn, then quagga. Others need early PPP although we don't have a test box configured for that right now. Debian Stable handles all this correctly out of the box. After insserv wreaks havoc, openvpn can erroneously be brought up last while apache can fail before openvpn, named, quagga, and mysql are started. Any sane dependency boot system would allow me to say start openvpn before services X, Y, and Z but under insserv we're stuck with creating a separate override for each of X, Y, and Z. insserv appears to be a high-school coding experiment, not a professional sysadmin tool. (3) insserv wants to start openvpn before gdm3 on workstations. That's probably a good idea as that's what Debian Stable does. However, although that dependency appears in the generated /etc/init.d/.depend.start we cannot find the source of the dependency. It is not in any of the places listed in (1) above. Are there more special cases hidden somewhere? What if someone needed gdm3 to start before openvpn, how would they override a hidden (possibly hard-coded?) dependency? (4) /etc/init.d/bootlogs describes itself as Various things that don't need to be done particularly early in the boot, just before getty is run. And yet it has no defined relationship to getty, and defines the opposite relationship to gdm3, kdm, etc. Which is correct, the description or the dependencies? Thanks for looking into this. I still fail to see why saving half a second a year on server booting is worth inflecting days of drudgery on tens of thousands of sysadmins. So yet again, why is Debian forcing this horrible change? The old sysv-rc is not hard to support alongside file-rc. Why abuse the power of Debian dependencies to push this bad idea on sysadmins who don't want it? Why can't we keep the excellent debugged working reliable sysv-rc from Lenny? If some people want to use insserv let them, but don't force people to go through this nonsense! insserv simply throws away all the hard work by Debian Developers over many many years that went into tuning the default rc2.d/Snn priorities. --Mike Bird -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201012290137.48863.mgb-deb...@yosemite.net
Re: insserv + apache2 + bind9 = pain
On Wed, 29 Dec 2010 01:37:48 -0800, Mike Bird wrote: On Wed December 29 2010 00:13:04 Camaleón wrote: AFAIK, booting scripts have been rewrited to play with dependency booting and provided this is new for Squeeze, I would expect some glitches, but nothing that cannot be solved. The question is not whether the problem can be solved. Then what do you want? Just complain? BTW, you seem to ignore all but your rants so I think it is not worth to continue with this :-/ Greetings, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pan.2010.12.29.09.43...@gmail.com
Re: insserv + apache2 + bind9 = pain
(Sigh) So you don't know anything about insserv? Why guess? That only makes things worse. People may find your bogus suggestions in the archive and mistakenly act on them. Please let people who understand insserv answer the questions. Thanks, --Mike -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201012290151.34664.mgb-deb...@yosemite.net
Re: insserv + apache2 + bind9 = pain
On Wed, 29 Dec 2010 01:51:34 -0800, Mike Bird wrote: (Sigh) So you don't know anything about insserv? Why guess? That only makes things worse. People may find your bogus suggestions in the archive and mistakenly act on them. No, I know nothing about complains. Please let people who understand insserv answer the questions. Nothing impedes people from replying. Greetings, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pan.2010.12.29.10.03...@gmail.com
Re: insserv + apache2 + bind9 = pain
On Wed December 29 2010 02:03:10 Camaleón wrote: On Wed, 29 Dec 2010 01:51:34 -0800, Mike Bird wrote: Please let people who understand insserv answer the questions. Nothing impedes people from replying. Unfortunately that is true. You can put out a lot of bad information and harm Debian. Please don't. --Mike Bird -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201012290216.20405.mgb-deb...@yosemite.net
Re: insserv + apache2 + bind9 = pain
On Wed, 29 Dec 2010 02:16:20 -0800, Mike Bird wrote: On Wed December 29 2010 02:03:10 Camaleón wrote: On Wed, 29 Dec 2010 01:51:34 -0800, Mike Bird wrote: Please let people who understand insserv answer the questions. Nothing impedes people from replying. Unfortunately that is true. You can put out a lot of bad information and harm Debian. Please don't. Stop this nonsense sir, this is going nowhere. Greetings, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pan.2010.12.29.10.20...@gmail.com
Re: insserv + apache2 + bind9 = pain
Hi, I am not developer of insserve ... On Wed, Dec 29, 2010 at 01:37:48AM -0800, Mike Bird wrote: On Wed December 29 2010 00:13:04 Camaleón wrote: ... Thanks for looking into this. I still fail to see why saving half a second a year on server booting is worth inflecting days of drudgery on tens of thousands of sysadmins. So yet again, why is Debian forcing this horrible change? The old sysv-rc is not hard to support alongside file-rc. Why abuse the power of Debian dependencies to push this bad idea on sysadmins who don't want it? Why can't we keep the excellent debugged working reliable sysv-rc from Lenny? If some people want to use insserv let them, but don't force people to go through this nonsense! insserv simply throws away all the hard work by Debian Developers over many many years that went into tuning the default rc2.d/Snn priorities. As I recall, even with old boot system, boot order default was always hotly disputed topc among package maintainer. This ordering default choice is independent issue from moving to dependancy based boot suystem. Moving such default took good amount of package script. I think dependancy based boot system made this a bit more complicated for some case but made easy for some other case. Quite franky, complaining here does not make situation better. If you find some issue to the package such as Documentation etc., please file bug with constructive proposal. Thank you, Osamu -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101229125353.ge29...@debian.org
Re: insserv + apache2 + bind9 = pain
On Wed, Dec 29, 2010 at 6:53 AM, Osamu Aoki os...@debian.org wrote: Hi, I am not developer of insserve ... On Wed, Dec 29, 2010 at 01:37:48AM -0800, Mike Bird wrote: On Wed December 29 2010 00:13:04 Camaleón wrote: ... Thanks for looking into this. I still fail to see why saving half a second a year on server booting is worth inflecting days of drudgery on tens of thousands of sysadmins. So yet again, why is Debian forcing this horrible change? The old sysv-rc is not hard to support alongside file-rc. Why abuse the power of Debian dependencies to push this bad idea on sysadmins who don't want it? Why can't we keep the excellent debugged working reliable sysv-rc from Lenny? If some people want to use insserv let them, but don't force people to go through this nonsense! insserv simply throws away all the hard work by Debian Developers over many many years that went into tuning the default rc2.d/Snn priorities. As I recall, even with old boot system, boot order default was always hotly disputed topc among package maintainer. This ordering default choice is independent issue from moving to dependancy based boot suystem. Moving such default took good amount of package script. I think dependancy based boot system made this a bit more complicated for some case but made easy for some other case. Quite franky, complaining here does not make situation better. If you find some issue to the package such as Documentation etc., please file bug with constructive proposal. Thank you, I think he has found some issues, and listed them quite clearly a few posts up. I also don't think he wants to get involved in bug squashing the insserv system, he seems to want to go back to Snn Knn which seems like an entirely reasonable request. I'll be interested to see if its possible. AM -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktinoxyfnkszhwzrej_oe97q-c0ppn_icakb4=...@mail.gmail.com
Re: insserv + apache2 + bind9 = pain
On Wed December 29 2010 01:43:09 Camaleón wrote: On Wed, 29 Dec 2010 01:37:48 -0800, Mike Bird wrote: The question is not whether the problem can be solved. Then what do you want? Just complain? I STARTED this thread by posting a solution[1]. And I asked if there is a better solution. Camaleón offered an alternative solution, which appears to everyone who has looked at the issues to be a worse solution. When asked detailed questions so that alternative might be justified, Camaleón resorted to the retort shown above. If anyone has a BETTER solution to offer we would certainly appreciate it. In particular, we would like to know whether the stable and reliable and maintainable Snn/Knn mechanism can be used in Squeeze. Thank you in advance, --Mike Bird [1] http://lists.debian.org/debian-user/2010/12/msg01609.html -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201012291012.45737.mgb-deb...@yosemite.net
Re: insserv + apache2 + bind9 = pain
On Wed, 29 Dec 2010 10:12:45 -0800, Mike Bird wrote: On Wed December 29 2010 01:43:09 Camaleón wrote: On Wed, 29 Dec 2010 01:37:48 -0800, Mike Bird wrote: The question is not whether the problem can be solved. Then what do you want? Just complain? I STARTED this thread by posting a solution[1]. And I asked if there is a better solution. Sir, please, again... *stop* your foolish monologue. And stop *lying* about my postings :-/ Greetings, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pan.2010.12.29.19.29...@gmail.com
Re: insserv + apache2 + bind9 = pain
On Wed December 29 2010 11:29:38 Camaleón wrote: On Wed, 29 Dec 2010 10:12:45 -0800, Mike Bird wrote: On Wed December 29 2010 01:43:09 Camaleón wrote: On Wed, 29 Dec 2010 01:37:48 -0800, Mike Bird wrote: The question is not whether the problem can be solved. Then what do you want? Just complain? I STARTED this thread by posting a solution[1]. And I asked if there is a better solution. Sir, please, again... *stop* your foolish monologue. And stop *lying* about my postings :-/ Please be quiet Camaleón until you have something positive to contribute. I have not lied about your postings. I started this thread by posting a solution[1] and by asking if there is a better solution. All of the partipants in this thread other than you are trying to find a better solution to the serious problems created by insserv. You contributed one poor and ill-considered suggestion and since then your SNR has degenerated to zero. --Mike Bird [1] http://lists.debian.org/debian-user/2010/12/msg01609.html -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201012291208.10852.mgb-deb...@yosemite.net
Re: insserv + apache2 + bind9 = pain
Dne, 29. 12. 2010 20:29:38 je Camaleón napisal(a): On Wed, 29 Dec 2010 10:12:45 -0800, Mike Bird wrote: On Wed December 29 2010 01:43:09 Camaleón wrote: On Wed, 29 Dec 2010 01:37:48 -0800, Mike Bird wrote: The question is not whether the problem can be solved. Then what do you want? Just complain? I STARTED this thread by posting a solution[1]. And I asked if there is a better solution. Sir, please, again... *stop* your foolish monologue. And stop *lying* about my postings :-/ Greetings, -- Camaleón I agree, Camaleón. Sir, Camaleón has gone out of her way to help you, although it was in no way her duty to do so. It's not that we get paid to help you or anything. This is just a volunteer mailing list where users try to help each other to the best of their abilities. A certain level of mutual respect, even courtesy, is expected. P.S. In almost 2 years that I'm subscribed to this list, Camaleón was arguably one of the most helpful members. Judging from her answers, she appears to be a very competent system administrator. If I can somewhat understand your frustration, there's nevertheless no reason to take it out on Camaleón. With some patience, other users will hopefully contribute answers more to your liking. I wish I could. Wish you all the best. -- Cheerio, Klistvud http://bufferoverflow.tiddlyspot.com Certifiable Loonix User #481801 Please reply to the list, not to me. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1293653766.1869...@compax
Re: insserv + apache2 + bind9 = pain
On Mon December 27 2010 23:55:00 Arthur Machlas wrote: On Mon, Dec 27, 2010 at 4:45 PM, Mike Bird mgb-deb...@yosemite.net wrote: If the Apache configuration needs DNS to start, Apache silently and without logging anything fails to start in Squeeze. This used to work correctly under the old startup mechanism in Lenny. Create a new group in /etc/insserv.conf, and name the scripts that are required to start. Then list that group as a required start. Thanks Arthur. It's still the case then that one has to either edit /etc/init.d/apache2 (which impedes future upgrades) or else create a ten line /etc/insserv/overrides/apache2 and then manually keep it in step with future changes to /etc/init.d/apache2? This seems a lot more work and a lot more error prone than the old sysv-rc system. We've already found some servers with apache2-bind9 dependencies, and others with apache2-mysql dependencies. Is it possible to go back to the old system? All this upgrade downtime is not worth the half second saved on a server reboot which may only occur once a year. --Mike Bird -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201012280010.23664.mgb-deb...@yosemite.net
Re: insserv + apache2 + bind9 = pain
On Tue, 28 Dec 2010 00:10:23 -0800, Mike Bird wrote: On Mon December 27 2010 23:55:00 Arthur Machlas wrote: On Mon, Dec 27, 2010 at 4:45 PM, Mike Bird wrote: If the Apache configuration needs DNS to start, Apache silently and without logging anything fails to start in Squeeze. This used to work correctly under the old startup mechanism in Lenny. Dependency of apache2 to bind9 is virtual, I mean, is not required per se (you don't need to run a dns server to launch a web server) so if under some scenarios this is a requirement, you should ensure your dns server (bind9) is up and running before apache. OTOH, any service that is not started at booting should log the error somewhere (maybe /var/log/boot or /var/log/syslog?) :-? Create a new group in /etc/insserv.conf, and name the scripts that are required to start. Then list that group as a required start. Thanks Arthur. It's still the case then that one has to either edit /etc/init.d/apache2 (which impedes future upgrades) or else create a ten line /etc/insserv/overrides/apache2 and then manually keep it in step with future changes to /etc/init.d/apache2? This seems a lot more work and a lot more error prone than the old sysv-rc system. We've already found some servers with apache2-bind9 dependencies, and others with apache2-mysql dependencies. AFAIK (this was discussed in previous threads) manually edititing /etc/ init.d/* scripts headers is a valid option, and in the event you upgrade the package, any change you have done on the file has to be preserved, so editing your /etc/init.d/apache2 and put there: # Required-Start:$local_fs $remote_fs $network $syslog $named # Required-Stop: $local_fs $remote_fs $network $syslog $named Or # Required-Start:$local_fs $remote_fs $network $syslog $mysql # Required-Stop: $local_fs $remote_fs $network $syslog $mysql Should be just fine (if I understood it correctly), just remember that named and mysql boot script dependencies have also to be met. Is it possible to go back to the old system? All this upgrade downtime is not worth the half second saved on a server reboot which may only occur once a year. If you mean how to disable dependency booting yes, you can disable it to get the old behaviour, but you will still have to ensure bind9 is started before apache2: http://www.debian.org/releases/squeeze/i386/release-notes/ch-whats-new.en.html#dependency-boot Greetings, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pan.2010.12.28.09.31...@gmail.com
Re: insserv + apache2 + bind9 = pain
On Tue December 28 2010 01:31:50 Camaleón wrote: On Tue, 28 Dec 2010 00:10:23 -0800, Mike Bird wrote: Is it possible to go back to the old system? If you mean how to disable dependency booting yes, you can disable it to get the old behaviour, but you will still have to ensure bind9 is started before apache2: http://www.debian.org/releases/squeeze/i386/release-notes/ch-whats-new.en.h tml#dependency-boot Thank you Camaleón. CONCURRENCY=none may help some people with different problems, but it does not solve the problem of unexpressed dependencies. Is there a way to use the old-style reliable init system based on the Snn and Knn values in rcn.d? Real servers have dependencies among numerous server processes. A few of these dependencies relate to Debian packaging but far more relate to configuration, scripting, plugins, and even custom programming. It is simply not worth the effort to spend hours trying to discover and express all the dependencies on a bunch of servers in order to save half a second of boot time once per year. It took me four hours to discover what was wrong in a very simple case. This was not helped by failures to log errors, bootchart2 missing from Squeeze, a near complete lack of documentation, and insserv silently ignoring errors in my early attempts to express missing dependencies. I've read the very thin /usr/share/doc and man documentation and googled extensively. The new system may be great for script kiddies rebooting their Ubuntu laptops twice a day but it is an appalling idea for Debian servers. It not only scales terribly (on the order of N squared dependencies instead of N priorities) but is also very poorly documented. --Mike Bird -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201012281006.58377.mgb-deb...@yosemite.net
Re: insserv + apache2 + bind9 = pain
On Tue, 28 Dec 2010 10:06:58 -0800, Mike Bird wrote: On Tue December 28 2010 01:31:50 Camaleón wrote: On Tue, 28 Dec 2010 00:10:23 -0800, Mike Bird wrote: Is it possible to go back to the old system? If you mean how to disable dependency booting yes, you can disable it to get the old behaviour, but you will still have to ensure bind9 is started before apache2: http://www.debian.org/releases/squeeze/i386/release-notes/ch-whats- new.en.h tml#dependency-boot Thank you Camaleón. CONCURRENCY=none may help some people with different problems, but it does not solve the problem of unexpressed dependencies. Old booting style neither, you also have to juggle things to get the desired order ;-) JFYI: apache2: fails to start with dependency based boot if DNS is required by configuration http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=606334 Is there a way to use the old-style reliable init system based on the Snn and Knn values in rcn.d? Real servers have dependencies among numerous server processes. A few of these dependencies relate to Debian packaging but far more relate to configuration, scripting, plugins, and even custom programming. Old booting style has nothing reliable, so before ditching dependency booting at all I would recommend you to first find out what is failing at your side and why. It is simply not worth the effort to spend hours trying to discover and express all the dependencies on a bunch of servers in order to save half a second of boot time once per year. It took me four hours to discover what was wrong in a very simple case. This was not helped by failures to log errors, bootchart2 missing from Squeeze, a near complete lack of documentation, and insserv silently ignoring errors in my early attempts to express missing dependencies. It is somehow documented (man insserv). I've read the very thin /usr/share/doc and man documentation and googled extensively. The new system may be great for script kiddies rebooting their Ubuntu laptops twice a day but it is an appalling idea for Debian servers. It not only scales terribly (on the order of N squared dependencies instead of N priorities) but is also very poorly documented. I've been using insserv (dependecy based booting) with openSUSE since years and this method really works quite well, so no, not intended just for kiddies :-) OTOH, I suppose (although not tested and not sure if disabling at all is nowadays even possible :-?) that by reconfiguring insserv package you could restore the old sysinit booting style... but think it twice before going back to the cavern :-P Greetings, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pan.2010.12.28.18.56...@gmail.com
Re: insserv + apache2 + bind9 = pain
On Tue December 28 2010 10:56:48 Camaleón wrote: JFYI: apache2: fails to start with dependency based boot if DNS is required by configuration http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=606334 Thank you for the link but the bug is not in Apache. The bug is the poorly thought out and poorly documented startup mechanism which is being pushed onto previously stable and reliable Debian servers. People have also encountered problems with MySQL, Request Tracker, Apache, and Bind. We haven't even started testing LDAP, Samba, Postfix, ClamSMTP, ClamAV, Quagga, YP/NIS, WordPress etc in the various combinations and with the various configurations and various plugins employed on different servers. If anyone doubts it's a nightmare, take a look at the sysv-rc changelog and see how many special case hacks and weeks of effort went into getting insserv to work with just a virgin Linux system with no significant services running. Remember that configuring the priorities of N services is O(N), while configuring all their dependencies is O(N*N). It just doesn't scale on real world servers. You're breaking stable Debian servers and pushing all the repair work on Debian users and sysadmins. FOR NO GOOD REASON. What's worse is that the startup sequence is not repeatable. A service required may just happen to be ready in time on most reboots but start up a little slower sometimes and thus cause intermittent failures. Analyzing every piece of code and configuration on a system - some of it written more than ten years ago - is a nightmare. It's the Microsoft way to use a separate box for each service but prior to Squeeze it has always been a big selling point for Debian that you could always add another service to a box and it would just work. In the past Debian has worked REALLY WELL for small businesses and schools. There's no VALID reason for FORCING insserv on Debian servers other than someone's desire to see his/her software being used. So I will repeat the key question, and with increased desperation: How do we run the old reliable Snn/Knn style startup mechanism in Squeeze? --Mike Bird -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201012281207.30589.mgb-deb...@yosemite.net
Re: insserv + apache2 + bind9 = pain
On Tue, Dec 28, 2010 at 3:10 AM, Mike Bird mgb-deb...@yosemite.net wrote: On Mon December 27 2010 23:55:00 Arthur Machlas wrote: On Mon, Dec 27, 2010 at 4:45 PM, Mike Bird mgb-deb...@yosemite.net wrote: If the Apache configuration needs DNS to start, Apache silently and without logging anything fails to start in Squeeze. This used to work correctly under the old startup mechanism in Lenny. Create a new group in /etc/insserv.conf, and name the scripts that are required to start. Then list that group as a required start. It's still the case then that one has to either edit /etc/init.d/apache2 (which impedes future upgrades) or else create a ten line /etc/insserv/overrides/apache2 and then manually keep it in step with future changes to /etc/init.d/apache2? This seems a lot more work and a lot more error prone than the old sysv-rc system. We've already found some servers with apache2-bind9 dependencies, and others with apache2-mysql dependencies. Is it possible to go back to the old system? All this upgrade downtime is not worth the half second saved on a server reboot which may only occur once a year. Since there already is a $named insserv group, there's no need to create another. Your solution of creating an override seems like the best (to me). I presume that since there are more (probably far more, at least from my experience) apache servers without a named dependency than with it, apache2's init script was set up not to depend on named. Why don't you file a bug report to have $named added to apache2's Should-Start section? Since sysv-rc depends on insserv, going back to the previous system isn't possible. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktikxprmhqh5dftdog1frat5euja11-hbdcfpf...@mail.gmail.com
Re: insserv + apache2 + bind9 = pain
On Mon, Dec 27, 2010 at 4:45 PM, Mike Bird mgb-deb...@yosemite.net wrote: If the Apache configuration needs DNS to start, Apache silently and without logging anything fails to start in Squeeze. This used to work correctly under the old startup mechanism in Lenny. Create a new group in /etc/insserv.conf, and name the scripts that are required to start. Then list that group as a required start. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlkti=_6xe9bfwnx47du3r6qqo2mlf_qncbbcf0r...@mail.gmail.com
