Date: Sun, 27 Apr 1997 21:06:59 -0500 From: Chris Csanady <ccsanady@nyx.pr.mcs.net> To: patl@Phoenix.volant.org Cc: Robert Withrow <witr@rwwa.com>, hackers@freebsd.org Subject: Re: /etc/netstart bogons.. Message-ID: <199704280206.VAA12224@nyx.pr.mcs.net> In-Reply-To: Your message of Sun, 27 Apr 1997 15:33:53 -0700. <ML-3.3.862180433.7419.patl@asimov>
next in thread | previous in thread | raw e-mail | index | archive | help
[snip] >> 1) I was wondering about this myself.. I really don't see how it would >> change the basic idea if it was a script rather than a function >> though. > >If it's a function, what do you need to do to make that function >avaliable to your shell? And which shells would be supported? >The script-with-start/stop/restart-parameter solution is a clear >win for manual use because it imposes no restrictions on the user's >choice of shell. Or, for that matter, on the shell to be used in >the start-up script itself. In fact, there's nothing that says >that the start-up program needs to be a script - it can be any >executable file. This is a Good Thing. Actually I was trying to say that using arguments is fine. I didn't quite understand why he had proposed using functions. >> 2) Just add a script in the /etc/init.d directory.. >> >> 3) What about having a single configuration file per state? Just a list >> of the services to start included. I think a file is simpler than >> a directory. ;-) > >Oops, that means there's more to 2) than just adding a script. >And unfortunately, it means editing a file. Which is something >that I really don't want automated installation/removal scripts >to have to do. In that regard the directory is -MUCH- easier, >simpler, and safer. Well, essentially, you add the script to the dir.. and it is installed. The rest is changing the default configuration of the system, something that I'm not sure a script should be responsible for. Even so, if the vendor could not write a script to cat one line to the end of a file, I'd hate to have their software on my system.. [snip] >> But this does *not* handle dependancies--only ordering. There is a >> huge difference. If something fails, the outcome is unknown.. > >Right. But how can you handle it in a clean, flexable, simple >manner? If you only needed to worry about those services that >are bundled with the system, it would be manageable. But different >sites will be adding third-party packages and replacing standard >components with external implementations. Look at all of the >sites that replace sendmail with another mail transfer agent. >How do you abstract the dependency from 'sendmail is running' >to 'a mail transfer agent is running'. Ok, now how do you do >that abstraction for EVERY service or combination of services? > >I don't think it can be done. In my opinion, a better approach >would be to make the start-up script for the dependant service >actually test for availability of the dependancies. Using the >sendmail example, don't trust the MTA start-up script's result >code, actually attempt to connect to the SMTP port. I think it can be done. It just has to be done carefully. I think that much of the issues of dependancy are really issues of granularity. Where do we stop here? If we go with a finer granularity than each module (script), perhaps we need to start thinking along the lines of creating some conventions. Otherwise, I was thinking of just depending on each script. (ie. nfs depends on network or something) Third party scripts depending on other third party require only the name of the others script. There is an issue with multiple vendors providing the same service however. This should usually not happen, but if it does, they should use a standard name for the service. Heh.. this has actually given me an idea of how the symlinks can be used productively. :-) Trying to abstract things to your example of sendmail is interesting. How about having a link from /etc/rcx.d/mail to /etc/init.d/sendmail, then depend on mail. (assuming the SysV model) This is where some conventions would need to be created. This would allow the system to be augmented or complete drop in replacements without destroying parts of the base system. Comments? --Chris Csanady
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199704280206.VAA12224>