nALFS2 Daemon and Front Split

Uriah uriah-lfs at tempestnetworks.net
Tue Aug 10 21:05:28 PDT 2004


On Tue, 10 Aug 2004, James Robertson wrote:

> All,
> 
> 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:
> 
> http://wiki.linuxfromscratch.org/index.php?pagename=SplitnALFS
> 
> 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.
> 
> James
> 

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 
thread?


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 
the Daemon.

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.

-uriah

Just my two cents, or that rather funny tasting lasagna I had for 
dinner....




More information about the alfs-discuss mailing list