The boot process we're examining here is the process of starting services once the kernel has loaded. These services include launching ttys, web servers, and many more. The work is done by "rc" or "init" scripts. Since nodows would like to be able to build both linux and bsd systems, let's take a look at the boot process of each OS.

FreeBSD

  • rc - though that file mostly remains static these days
  • rc.subr - contains functions which are used by rc scripts, such as set_rcvar, force_depend, etc.
  • rc.d/ - contains service specific rc scripts

Linux

  • runlevels 0-6
  • /etc/init.d/ - contains service specific init scripts
  • /etc/rc.0-6/

Linux has a new init daemon called upstart, which looks really interesting. It listens for various events, including those from udev, and manages the processes of services. I doubt this can work for FreeBSD, but if it could, that would be nice.

NODOWS

Both FreeBSD and linux have a complicated boot process. With respect to NODOWS, for either platform, a generic class is needed to handle each service. At least the following functions would be required, and it would be necessary to extend the class for certain services:

  • check - to see if the service should be started - query the config for this data
  • status - returns current state of sevices - ps command? pid file?
  • load - load service specific functions via include files - build include file and then include it?
  • configure - use XSL to render the output
  • start - call the command
  • stop
  • reload
  • restart

It might be possible to simply loop through each possible service, check to see if it should be started, load the required functions, configure the service, then start it.

In [http://www.nexista.org/ nexista], the action class is interesting. In the sitemap, you use a tag like this:

Then the action builder, the action handler, and the redirect.action.php files take care of the rest. Perhaps something like that could be used for the boot process. For example: 




or

or something like: 

foreach($service as $name) {    
    require_once(NX_PATH_ACTIONS . trim(strtolower($name))."service.php"); // Need one of these for each service.
    $classname = trim(ucfirst($type)) . "Service"; 
    $service = new $classname();
    $service->process($params);
}

These thoughts make me feel like there should be a "build" process at the start of the boot process. It would convert an XML file into a php script to be executed, which would perform all the necessary tasks required for the system operations.

Based upon what I've read about init on both FreeBSD and linux, I think it makes sense to have a "post-init" php daemon to manage service processes. This will support easy portability across platforms. This would be very similar to inetd or xinetd, but not manage the actual sockets or involve any tcp wrappers. It would just be a process manager for services. My feeling is that iptables and pf should manage that aspect of network connectivity. It still makes a lot of sense to review what inetd and xinetd are all about.

Now that I'm thinking about it, it might not be necessary to have a socket server besides a web server. A socket client process could be started by init and respawn if it dies. The socket client would check for service status, start them if necessary, monitor them, etc.

Other ideas:

  • Script types - system, network, service, user, helper
  • Operational modes? - dev, test, production, failover, backup, etc.
  • Use nexista as a backbone for the operating system? .... (Need to figure out how to get phing to build nexista conf and sitemap files!)
  • Read up on upstart - an event based init deamon http://upstart.ubuntu.com/ + https://wiki.ubuntu.com/ReplacementInit + http://www.linux.com/articles/57213
  • Startup script in /etc/rc2.d/ to get base system configuration from an xml file or a sqlite database
  • Get more configuration information from a remote database server
  • Parse all data to a temporary tree in ram, rsync that to the rootfs
  • The above step will potentially include new files for /etc/incron.d/ which will keep watch on specific configuration files, when certain files are modified, their corresponding services will restart
  • It would be difficult to know when information in a remote database is updated, so there are a few options to watch for them - either a cron job to periodically re-render the configuration files in the temporary, ram-based filesystem, and resync them with the rootfs (only if the files are different will they trigger a modification and service restarts), OR add a hook to provide the ability to remotely trigger the re-rendering and re-syncing along with whatever event caused the data to be updated.
  • Basic data model: server id, service name (just use debian package name to stay compatible with their layout), file targets to be output (/etc/apache2/apache.conf), xsl template, keys, values
  • Init / Launchd / Upstart builder - first step of init is to use XML and XSL to generate the next steps of the boot and service management specification?

Old Boot Process Notes

External links:

  • http://gentoo-wiki.com/HOWTO_Make_an_rc_script
  • http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=2&chap=4
  • http://www.netbsd.org/docs/guide/en/chap-rc.html
  • http://www.openbsd.org/cgi-bin/man.cgi?query=rc&sektion=8&manpath=OpenBSD+3.6
  • http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/rc-scripts.html
  • http://www.linux.com/articles/114107
  • http://en.wikipedia.org/wiki/Init
  • http://www.onlamp.com/pub/a/bsd/2000/11/28/FreeBSD_Basics.html
  • http://zwillow.blogspot.com/2006/09/critical-view-on-upstart.html
  • http://www.netsplit.com/blog/articles/2006/08/26/upstart-in-universe
  • http://www.chabotc.nl/phpsocketdaemon/
  • http://nanoserv.si.kz/