On Tue, 28 Sep 1999, Clint Adams wrote: > > Ok, let's bring this back to implementation. How would you propose we > > handle > > this? Currently daemons install, set themselves up, and begin running. > > > > a) we can prompt. > > b) we leave everything off and let the admin turn it on (not an option for > > obvious reasons) > > c) first come first serve -- first daemon installed does its job, the rest > > install unconfigured > > > > any others? > > d) have something that keeps track of installed services, perhaps with > priorities akin to alternatives. If there weren't an issue of > services being run either in inetd or standalone, this could > be accomplished with a souped-up update-inetd. a) is possible, but I don't really like it. It may be not too bad if 'prompt' means 'ask debconf'. d) is perhaps the right thing, but sounds like a lot of work and changes to dozens of packages. Until this is done, c) could be a possible solution. It would also allow to inhibit automatic start of services at all by providing packages noop-httpd, noop-fingerd, ... (in extra and with appropriate warning in the description) to be installed as 'first ones' by the knowing sysadmin.
The main problem I see with c) is how to determine if we are the first one regarding the standalone/inetd mess without introducing parts of d). c) should the be designed so that it makes later transition to d) easy (in fact c) could be just one of the policies implemented by d)). But then decisions on flexibility (how highly-customized and possibly problematic setups are to be supported: multiple interfaces - some secure and some not, multiple IPs - virtual hosting etc., ...) have to be made early or daemon package maintainers will become badly-behaved daemons themselves. Some basic ideas for c) -> d) : /var/state/servicemgr/daemons: #the supergeneric version, perhaps drop/ignore some fields #package service interface ip port protocol inetd|standalone mtime apache www * * 80 tcp standalone 28 Sep 1999 \ 18:30:16 -0000 interface and ip would have to be * by default or things will badly suck on machines without permanent network connection. interface can be determined by IP most of the time, but not for dial-up connections. fetchmail tries to care for the right (secure) interface if asked to but is no real example for the kind of daemon addressed here because it doesn't listen ports but polls. Are there any? A package providing a daemon would then have to supply a canonically-named script or executable, e.g. <package>.dmconf with canonical options/arguments (including service, because one excutable may provide several at once) to de/configure and register all that stuff with the help of some scripts supplied by 'servicemgr'. <package>.dmconf should be allowed to fail (gracefully) if the setup is more complex than it can handle (which could include, for a start, interface != *, ip != *, moving services into/out of inetd.conf, using non-standard ports or setting up coexistence with another package already providing the same service so we're back to c)). The nicest thing would be to make what I called <package>.dmconf a new kind of maintainer script or include it in one of the existing. To make things even more complex, the default configuration for the first or only daemon providing a service should be taken from debconf if one has been chosen there. This could require that parts of the per-package configuration are in a cononical format, too if settings of the kind 'whatever httpd I use, I want it on port 81!' should be supported. Does this mean a) -> d) is the better way of migration? Bj"orn Brill <[EMAIL PROTECTED]> Frankfurt am Main, Germany
