[lug] DNS and init

[D. Stimits]

rm at fabula.de wrote:
> 
> On Wed, Feb 06, 2002 at 01:00:35PM -0700, D. Stimits wrote:
> > rm at fabula.de wrote:
> > > [...]
> > > As a side note: i think it's time for a better init system. Something
> > > that can do backtracking and try several alternative ways to start up
> > > a system (Prolog? LISP?).
> >
> > I think at the moment the problem isn't that the init scripts hand off
> > the way they do, but that they have so much stupidity in the case of
> > errors and exceptions. The current init system would work great even in
> > bad circumstances if the scripts themselves had some sort of
> > intelligence. The bash scripts themselves could be made to do more if
> > someone really wanted to; then there are the programs that the bash
> > scripts run, intelligent/advanced wrappers could be built to do what you
> > are suggesting (it would be a good idea, but considering most people
> > believe in setting things up correctly the effort of figuring out how to
> > handle strange cases and failures isn't high on the priority list).
> 
> Yes, and that's exactly what i did whenever i wrote init scripts. But
> there are a few reasons why i'm not satisfied with this any more:
> 
>  - Sometimes it's hard for a script to detect the state of the overal
>    system. Take DNS services as an example: i know at least one popular
>    daemon that used to lookup a 'welllknown' hostname to find out whether
>    DNS resolution is working. Of course this is _not_ a proper test.
> 
>  - Often, a whole subset of services depend on the availability of some
>    service. It seems strange that the test code should be duplicated in
>    the init scripts for all dependant services.
> 
>  - Multiple strategies: the current setup knowns only 'works' or 'failed'.
>    I often encountered setups where some services a _really_ important.
>    It would be nice to have alternative strategies to guaranty that these
>    services work. As an example: Apache won't start unless it can detect
>    a proper hostname (i once worked on a firewall product that had (shudders!)
>    a web administration interface. The admin could change the firewalls
>    domain name with the web interface  -- unfortunately quite a lot of our
>    customers entered their MS SMB domains which often had an underscore in
>    the name, which isn't a valid DNS name. As a result after this operation
>    the admin server wouldn't come up :-/
>    Now, it's very easy to create an 'emergency apache' script that gets
>    executed _iff_ the first choice apache script fails.
>    This is just a pretty simple example. In real life backtracking might
>    involve actually shutting down services as well (sound'S more and more
>    like a Prolog task :-) Or maybe Guile with a Schelog module ....)
> 

There is actually a "token effort" at this via some of the functions
(bash) made available on RH systems (and without a doubt, also on other
distros). Some of them internally do try to distinguish beyond
pass/fail, but nothing is really all that great at providing an overall
system state picture.

So it seems that what might be interesting is a centralized system state
publisher. Init scripts could, during bootup, register service names and
fine-grained information about that service; the centralized system
could do more than just record data from service startups and shutdowns,
it could offer a state-sensitive response, via registering rules about
how to determine a response. Add to this an audit trail (state machines
seem to be easy to audit if you add a tracking system). Then instead of
scripts simply doing their thing solo, they could do their thing and
post results to the central state tracker; anything wanting to do
something more interesting could consult that tracker. Adding rules for
testing various states could exist to eitehr verify what a script has
told it, or to answer questions about states that nothing has updated or
told the tracker about. Something like that? It could be complicated
overkill. But the gist seems to be a pseudo-intelligent means of testing
system service availability in a standardized way.

D. Stimits, stimits at idcomm.com

>    Ralf
> 
> > D. Stimits, stimits at idcomm.com
> >
> > >
> > >     Ralf
> > >
> > > >
> > > > I remember reading this in Essential Unix System Administration by
> > > > Frisch.
> > > >
> > > > One thing I did notice is that in Linux the labels in /etc/inittab is
> > > > limited to four characters.
> > > >
> > > > Hugh
> > > >
> > > >
> > > > On Sun, 2002-02-03 at 23:34, Chip Atkinson wrote:
> > > > > Greetings,
> > > > >
> > > > > Is there a good reason to not put named and some other daemons into
> > > > > /etc/inittab?  It seems like a good idea on the surface but I haven't seen
> > > > > it done much.  It seems to be a pretty obvious idea so there must be some
> > > > > reason for it not being done.  Can anyone shed some light on this?
> > > > >
> > > > > Thanks.
> > > > > Chip
> > > > >
...snip...