[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