[lug] DNS and init
rm at fabula.de
rm at fabula.de
Thu Feb 7 04:42:19 MST 2002
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 ....)
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
> > > >
> > > > _______________________________________________
> > > > Web Page: http://lug.boulder.co.us
> > > > Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
> > > --
> > > ------------------------------------
> > > System Administrator/Unix Consultant
> > > hugh at vecna.com
> > > Vecna Technologies, Inc
> > > 6525 Belcrest Rd, Suite 612
> > > Hyattsville MD, 20782
> > > 301.864.7253
> > > http://www.vecna.com
> > > ------------------------------------
> > > Linux Professional Institute Certified - Level 1
> > > Sair Linux and GNU Certified Administrator
> > > AIX Certified Specialist - System Support
> > > ------------------------------------
> > >
> > > _______________________________________________
> > > Web Page: http://lug.boulder.co.us
> > > Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
> > _______________________________________________
> > Web Page: http://lug.boulder.co.us
> > Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
> _______________________________________________
> Web Page: http://lug.boulder.co.us
> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
More information about the LUG
mailing list