Date: Sat, 23 Sep 2000 12:15:14 -0700 (PDT) From: Archie Cobbs <archie@whistle.com> To: Kris Kennaway <kris@FreeBSD.ORG> Cc: Neil Blakey-Milner <nbm@mithrandr.moria.org>, Marius Bendiksen <mbendiks@eunet.no>, Warner Losh <imp@village.org>, arch@FreeBSD.ORG, sjr@home.net Subject: Re: Dependency-based rc system (Was Re: sysctl on boot.) Message-ID: <200009231915.MAA06552@bubba.whistle.com> In-Reply-To: <Pine.BSF.4.21.0009211811240.21719-100000@freefall.freebsd.org> "from Kris Kennaway at Sep 21, 2000 06:12:32 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Kris Kennaway writes: > > NetBSD has a nice working example, and I intend to port and reconstruct > > it for FreeBSD, and suggest we cross over. They apparently took a > > little hammering on the mailing lists, and I imagine we will too, but it > > does seem the obvious way forward, and we can sidestep many of the > > issues from what they've learnt and done. > > I also suggest you compare and contrast with Eivind's prototype version to > see if theres anything we can take from both. At Whistle we've thought a lot about this. On the InterJet we implemented this kind of dependency-based mechanism which is not ideal, but works pretty good. FWIW, here are some thoughts.. - Define a "module" as something that has a "start" method that derives its configuration fro the DB, and a "stop" method. Optionally it may have a "restart" that functions as an atomic stop and start (think SIGHUP). More generally a module is something that needs to be configured and may or may not actually "run". Examples: sendmail, named, apache... but also network interfaces, kernel routing table, system hostname. - There is always (either implicitly or explicitly) a database of configuration information from which all "modules" are configured. This DB contains all configuration information for the administration domain, in our case: hostname, IP addresses, routing info, forwarding nameservers, etc. Ideally, there would be an explicit DB and all code would reference it directly.. in the real world, however, every subsystem has its own configuration file format or whatever -- and these all represent redundant copies. Think of how many things you need to reconfigure when you change an IP address, or a hostname, etc.. - Modules may depend on other modules, i.e., module A may require that module B is running before module A will function correctly (think sendmail -> named). In fact, there is a finer distinction: module A can only require that module B is running, or it can additionally require that module B is running *with a consistent configuration* (i.e., B is running based on the same contents of the DB as A is). The latter dependency type is usually but not always the case (e.g., sendmail -> DNS). As an example of the former, consider that an FTP client requires that the IP interfaces be configured.. but it doesn't care what the actual IP addresses are. Also, sometimes A only requires that B is running when A is started: stopping B once A is already going is allowed. - Ideally, the logic that determines when a code module must be stopped, started, or restarted is kept with that module. That is, each module should know which fields of the DB must change before it requires a (reconfiguration and) restart. Part of the start process is copying this data out of the DB and into the module-specific configuration file (or whatever). Also, each module should know what other modules it depends on (rather than the other way around). - Following this idea, when the administrator wants to change something (say, his domain name) then (s)he simply makes the change in the DB.. then, each module (or some representative) independently notices the relevant change(s) and, if necessary, schedules the module to be restarted. A separate restart manager collects all the restart requests, enforces the dependencies, and actually performs all of the stop and start operations. - The DB must be transactional for this to work properly. E.g., the restart managager must know when all of the requests are in. - Any system should allow for dynamic registration of new code modules into the system (e.g., think about ports). This can work if each code module knows what configuration information it depends on and what other modules it depends on. A new module could even add new fields (or whatever) to the database. - Of course, the user interface is a whole separate question. But in any case, its design is completely separate from all of this. All it has to know about is what fields are in the database. Has it ever bothered you that when you change your IP address on a Windows machine you have to reboot?? That's because they don't have this kind of system. Neither does UNIX of course; instead, it's the administrator's problem to do all of the above manually :-) -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200009231915.MAA06552>