nALFS2 Daemon and Front Split
uriah-lfs at tempestnetworks.net
Tue Aug 10 21:05:28 PDT 2004
On Tue, 10 Aug 2004, James Robertson wrote:
> I wanted to noodle some more on the split between the two pieces. Sorry
> Kevin - I may still be confused :-)
> Kevin and I posted some notes on the wiki at:
> Kevin mentions that we are using the word "daemon" in a backwards sense,
> since we are having the workhorse be the daemon on the target machine
> and the client being a lightweight piece to "watch remotely" what the
> target machine is up to. That is OK. I was still kinda confused on
> this until I finished writing the feature list below.
> Following this then, here is a list of features for the back-end:
> * Engine for the build
> * Runs on the target machine only (from a boot-cd, or floppy or
> whatever, just meant to be the piece that does the work on the new LFS box)
> * Contains all the handlers for all the xml dtd syntax/schema functions
> (make, move, unpack, download, [put your favorite here], etc)
> * Handles the features of xml parsing and validation
> * Runs on a documented unix socket/IP port for remote connection by the
> client. Remote in this sense can be the same machine, hence the socket
> pair provided. Remote can also be another box with the client on it
> over a network of some kind.
> * Provides no GUI, it is a daemon after all.
> * Provides a remote client with the ability to control its actions and
> also handle information/control messages/commands to and from the client
> and itself. The daemon will need to have a documented control mechanism
> for every possible client scenario. Any client that then take and use
> only what it needs (a CLI would want different info than a GUI)
> * Handles all logging state information on the host it is building on
> (in /var/nALFS/...) using the logging dtd or schema
> * must be compilable into binary machine code, should not be implemented
> as/in a scripting engine or interpreted language
> This is a list of features for the client:
> * Display and control tool for the build engine
<snipped for berevity>
> This is what I got so far.
Sorry for cutting a lot of the previous post out, but is the idea that
when installing to a new machine, you will need to carry over (floppy,
cdrom, nfs, etc..) the daemon, profile, and packages? Sounds like a lot
to lug around. Can I suggest adding a third layer, mayhaps a worker
Idea here being that the Client does not need to be changed. Use whatever
you want, CLI, Gui, Curses, etc. Multiple Connect/Disconnect so that you
can migrate between daemons or terminals. Yada, yada, yada...
Daemon processes the profiles, holds our tar balls, understandes the XML,
and does all the heavy work. With one exception, it is just a taskmaster.
Simple atomic actions are done in the worker thread.
Worker thread only knows a handfull of commands. Probably no more than
PUT File, GET File, DELete File, STAtus File, and EXEcute File. This
should make it small enough that it and a bootable kernel could fit on one
floppy. Uncompressing, regex, and various controlles would be handled by
Why do such a thing? If the Daemon machine holds all the packages and
profiles, and the worker can run off of just a floppy, one wont have to
keep reburning CDs with profiles, or wondering which stab of your NFS tree
to use. Nor do you need a working OS in your target machine.
Side effect is that on a complete system, the worker thread becomes a very
light weight client for a package management system, ala Red-Carpet.
Just my two cents, or that rather funny tasting lasagna I had for
More information about the alfs-discuss