insserv + apache2 + bind9 = pain

[Mike Bird]

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.


In order to make Apache startup under insserv in cases where
the Apache config needs DNS information I eventually created
/etc/insserv/overrides/apache2 containing only:

#!/bin/sh
### BEGIN INIT INFO
# Provides: apache2
# Required-Start: $local_fs $remote_fs $network $syslog $named
# Required-Stop: $local_fs $remote_fs $network $syslog $named
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# X-Interactive: true
# Short-Description: Start/stop apache2 web server
### END INIT INFO

... and then ran "insserv" and rebooted.


Is there a simpler solution?


--Mike Bird

[Arthur Machlas]

Post by Mike Bird
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.

[Mike Bird]

Post by Arthur Machlas

Post by Mike Bird
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

[Camaleón]

Post by Mike Bird

Post by Arthur Machlas

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"?) :-?

Post by Mike Bird

Post by Arthur Machlas
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.

Post by Mike Bird
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,

[Mike Bird]

Post by Camaleón

Post by Mike Bird
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
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

[Camaleón]

Post by Mike Bird

Post by Camaleón

Post by Mike Bird
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
http://www.debian.org/releases/squeeze/i386/release-notes/ch-whats-

new.en.h

Post by Mike Bird

Post by Camaleón
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

Post by Mike Bird
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.

Post by Mike Bird
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).

Post by Mike Bird
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,

[Mike Bird]

Post by Camaleón
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

[Camaleón]

Post by Mike Bird

Post by Camaleón
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.

Post by Mike Bird
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.

Post by Mike Bird
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.

Post by Mike Bird
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.

Post by Mike Bird
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/msg00003.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.

Post by Mike Bird
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.

Post by Mike Bird
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.

Post by Mike Bird
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 >:-)

Post by Mike Bird
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,

[Mike Bird]

Post by Camaleón
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

[Camaleón]

Post by Mike Bird

Post by Camaleón
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,

[Mike Bird]

(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

[Camaleón]

(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,

[Mike Bird]

Post by Camaleón

Post by Mike Bird
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

[Camaleón]

Post by Camaleón

Post by Mike Bird
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,

[Mike Bird]

Post by Camaleón

Post by Mike Bird
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

[Camaleón]

Post by Camaleón

Post by Mike Bird
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,

[Mike Bird]

Post by Camaleón

Post by Camaleón

Post by Mike Bird
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

[Camaleón]

Post by Mike Bird

Post by Camaleón

Post by Camaleón

Post by Mike Bird
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.

Post by Mike Bird
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!).

Post by Mike Bird
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,

[Arthur Machlas]

Post by Camaleón
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

[Mike Bird]

Post by Camaleón

Post by Mike Bird
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

[Tom H]

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

[Mike Bird]

Post by Tom H

Your solution is to edit /etc/init.d/apache2.  Your solution requires
manual intervention on every apache2 upgrade.

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

[Tom H]

Post by Tom H

Your solution is to edit /etc/init.d/apache2. Your solution requires
manual intervention on every apache2 upgrade.

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.

[Mike Bird]

Post by Tom H
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 half-@$$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

[Arthur Machlas]

Post by Tom H
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,
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

[Arthur Machlas]

On Fri, Dec 31, 2010 at 12:27 AM, Arthur Machlas

Post by Mike Bird
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?

[Mike Bird]

Post by Arthur Machlas
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

[Tom H]

Post by Mike Bird

Post by Arthur Machlas
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

[Mike Bird]

Post by Tom H
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

[Bob Proulx]

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

[Arthur Machlas]

Post by Bob Proulx

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.

[Mike Bird]

Post by Arthur Machlas
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

[David Jardine]

Post by Mike Bird
[...]
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

[Andrei Popescu]

Post by Mike Bird

Post by Arthur Machlas
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

[Mike Bird]

Post by Andrei Popescu
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

[Andrei Popescu]

Post by Bob Proulx

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

[Bob Proulx]

Post by Andrei Popescu

Post by Bob Proulx

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

[Mike Bird]

Post by Bob Proulx
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

[Andrei Popescu]

Post by Bob Proulx

Post by Andrei Popescu

Post by Bob Proulx

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

[Osamu Aoki]

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.

Post by Andrei Popescu

Post by Bob Proulx

Post by Andrei Popescu

Post by Bob Proulx

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.

Post by Andrei Popescu
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.

Post by Andrei Popescu
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.

Post by Andrei Popescu
In my opinion we have more functionality without completely sacrificing
choice.

I agree.

Osamu

[Mike Bird]

Post by Arthur Machlas
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=608437

Wow, that was fast! Thank you all!

[Osamu Aoki]

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:
...

Post by Tom H
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

[Mihamina Rakotomandimby]

Post by Mike Bird
The issue is that insserv throws away
years of work by Debian Developers,

That is not always bad.
Computers have improved during the last years, why not their OSes?

compiz, upstart, lxc,... are "modern" tools for modern use :-)

[Mike Bird]

Post by Mihamina Rakotomandimby

Post by Mike Bird
The issue is that insserv throws away
years of work by Debian Developers,

That is not always bad.
Computers have improved during the last years, why not their OSes?
compiz, upstart, lxc,... are "modern" tools for modern use :-)

Change can be good or bad.

Hardware and software improvements are generally beneficial.

Throwing away years of DD work and thereby causing innumerable
previously rock-solid Debian servers to fail to boot is not.

--Mike Bird

[Arthur Machlas]

Post by Mike Bird

Post by Mihamina Rakotomandimby

Post by Mike Bird
The issue is that insserv throws away
years of work by Debian Developers,

That is not always bad.
Computers have improved during the last years, why not their OSes?
compiz, upstart, lxc,... are "modern" tools for modern use :-)

Change can be good or bad.
Hardware and software improvements are generally beneficial.
Throwing away years of DD work and thereby causing innumerable
previously rock-solid Debian servers to fail to boot is not.

You keep asserting that 'years of DD work have been thrown away'. You
do realise the ordering is still there, right? It's now in the LSB
headers rather than the scripts numbering scheme.

[Mike Bird]

Post by Arthur Machlas
You keep asserting that 'years of DD work have been thrown away'. You
do realise the ordering is still there, right? It's now in the LSB
headers rather than the scripts numbering scheme.

That is not correct. The LSB header ordering is weaker and
causes many server failures, although it may be adequate for
simple laptop configurations.

The stable ordering is in fact in the postinst scripts.

Undoing the damage done by insserv is possible but non-trivial.

--Mike Bird

[Mihamina Rakotomandimby]

Post by Mike Bird
Undoing the damage done by insserv is possible but non-trivial.

So... let's just "work for some years" and it will be better.

[Mike Bird]

Post by Mihamina Rakotomandimby

Post by Mike Bird
Undoing the damage done by insserv is possible but non-trivial.

So... let's just "work for some years" and it will be better.

Non-trivial as in a few days of work (mostly testing), not years.

--Mike Bird

[Klistvud]

Post by Mike Bird

Post by Mike Bird

Post by Camaleón

Post by Mike Bird
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

Post by Mike Bird
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.

[Camaleón]

Post by Klistvud

Post by Mike Bird

Post by Mike Bird

Post by Camaleón

Post by Mike Bird
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

Post by Mike Bird
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,

[Osamu Aoki]

Hi,

I am not developer of insserve ...
...

Post by Mike Bird
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

[Arthur Machlas]

Post by Osamu Aoki
Hi,
I am not developer of insserve ...
...

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

[Tom H]

Post by Mike Bird

Post by Camaleón

Post by Mike Bird
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
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.)

[Tom H]

Post by Mike Bird

Post by Arthur Machlas

Post by Mike Bird
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.

[Vuki]

Hi Folks!

I have got an old server(debian 4.0) with two hard disks(sda, sdb), 3
raid1 md device (md0:boot, md1:/, md2:home).
I would like to transfer these 3 partitions to a new server(also 2
disks(sda,sdb), also raid1(md0,md1,md2)).

I used dd to copy the data to the new md devices, but the server does
not boot.

How can i make bootable my new disks, md device?

Vuki

[Bob Proulx]

Post by Vuki
I have got an old server(debian 4.0) with two hard disks(sda, sdb),
3 raid1 md device (md0:boot, md1:/, md2:home).

Please do not hijack the discussion thread. You replied to Tom H's
message "insserv + apache2 + bind9 = pain" but are not talking about
that topic but are instead asking a new question.

Please when starting a new topic of discussion just start a new topic
and do not jump into the middle of another discussion. This is to
your advantage as much as it is to ours since anyone who is ignoring
the discussion thread will not see your message.

http://lists.debian.org/debian-user/2010/12/thrd4.html#01609

Post by Vuki
I would like to transfer these 3 partitions to a new server(also 2
disks(sda,sdb), also raid1(md0,md1,md2)).
I used dd to copy the data to the new md devices, but the server
does not boot.
How can i make bootable my new disks, md device?

Please start a new thread with this question.

But without saying why your system is not booting it is impossible to
know if it is because the bootloader (possibly grub) needs to be
installed on the new disks (installed on both new disks) or if because
your partitions tables are incorrect for the new disks or if it is
another problem. Since your old system was 4.0 you need to say if
the new system is also 4.0 or something newer? You would need to use
a compatible match. Otherwise the old 4.0 system might not be able to
boot a newer system. For example 5.0 has a newer LVM system.

Since you are moving from one raid system to a new raid system if I
were doing the upgrade I would split the raid. Manually fail and
remove one disk from the raid on the old system. Put that disk on the
shelf as a backup of the old system. Then install the new disk in the
system and add it into the raid system and let the raid sync between
the disks. Ensure that grub has been installed onto the new disk.
This needs to be done manually since it is not done automatically, at
least not in Debian 4.0. Then remove the new disk from the old system
and install it in the new system. Boot the new system with the cloned
disk. Booting the old image on the new system will probably work but
it is possible that there may be some driver issues that will need to
be worked through manually. I find those fairly easy to deal with and
easier than alternatives and so generally deal with any issues at that
point. Then add in the second new disk to the raid on the new system
and let the raid sync. You will have a new clone of your old system
up and running.

Then since you are running Debian 4.0 you should read the release
notes and upgrade through each major release to the current stable.
Right now that is only Debian 5.0 but soon 6.0 will be released. Do
not upgraded from 4 to 6 directly but only through each major release
in between.

A different alternative but guaranteed working solution would be to
use the standard debian-installer and to install a working system on
the new drives in the disk partition layout that you desire. Use it
to set up raid, lvm, grub, and so forth. Just install the minimum
possible system packages to get the system booting. Then copy the
data from your old system onto your new system.

Bob

[Stefan Fritsch]

Post by Mike Bird
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.

[Mike Bird]

Post by Stefan Fritsch

Post by Mike Bird
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