Development Status nALFS2

James Robertson jwrober at
Thu Jul 7 08:35:55 PDT 2005

Mark Ellis wrote:
> On Tue, 2005-07-05 at 21:39 -0500, James Robertson wrote:
>>Matthias Berndt wrote:
>>>some time ago the development of nALFS2 was mentioned on this list, but
>>>it's silent since these days. Even the wiki semms to be lonly now.
>>>I want to know what's going on with this idea?
>>>	Matthias Berndt
>>Thanks for your interest in alfs (was nALFS2).  I read yours and 
>>Jeremy's posts.  The SRS is not designed to answer your questions.  It 
>>is designed to provide a framework for making those decisions. 
>>Actually, the communications subsystem is an area we need to work on 
>>first IMO.  We need a modular system that can support a variety of 
>>communication mechanisms.  I was think of unix sockets for 
>>localhost/single box client/server comm and then maybe a daemon of some 
>>kind listening on a tcp port or something for simple secured network 
>>comm (like a company intranet).  We also need a secure remote comm 
>>protocol for Internet based comm.  I don't know anything about d-bus and 
>>so cannot make a statement there.  I just know that I want to be able to 
>>run the alfs daemon on a minimal system to build a box out - like the 
>>livecd.  So the backend daemon needs as little add-on software as 
>>possible.  This is why Jeremy wants it in C.
>>If you want to plug in and "waste" some time as you put it, we could use 
>>some help fleshing this out and getting the team to agree on it.  We can 
>>use the wiki for a lot of it and this list.  I don't really think it 
>>would take long.  At the least we need a spec for the modules and then a 
>>spec for how a unix sockets module would work and be implemented.  Once 
>>that is done, code away.
>>Mark - I saw you are back - want to help?
> I agree that the communication system needs to be specified first in
> something like this. One of my longest standing TODO items for perl alfs
> is to rewrite the comms protocols. It's a lot trickier in an existing
> system, so getting it right to start with is vital.
> The details of how comms are performed are, I believe, not as important
> a question as what you want to say and do. Having said that, the
> protocol is tricky while the 'medium' is easier, so I'd start with the
> latter :) Since the backend should be as lightweight as possible, a
> straightforward socket connection would seem the way to go, then it's
> easy to upgrade from there eg. with ssl or ssh for encrytion etc.
> As for the protocol, start thinking about the different kind of messages
> we'll need, appropriate responses etc. I'll make some attempt at
> documenting my current protocol (gulp) but off the top of my head...
> 1) hello, i'm a new frontend
> 2) heres a profile, execute it please [ from step n ]
> 3) this is the current command and it's output (info from backend)
> 4) I have a problem, what shall i do ? (question from backend)
> 5) abort/pause/resume the profile (as response to 4 or not)
> 6) i've finished the profile, its exit status is....
> Then how do you cope with lost connections, and stuff like that.
> More mechanically, do you want xml coded comms packets (which is how
> perl alfs works, not my decision, it's how i found it), simple text
> commands as used in SMTP, FTP et al., numeric codes or something else ?
> Does a profile get sent over the control connection or a separate data
> connection ? If a separate connection, does the front or backend assign
> it some kind of id so both sides know what they are referring to ?
> I'm starting to ramble.....
> Mark
This is all good stuff Mark.  Thanks for the info.  So, it looks like we 
need to start a wiki page or soemthing to get this all down in a 
coherent manner.  IIUC you are think we need to get what a comm module 
has to support as a basis for any actual programming of one.  That seems 
quite logical.  I was thinking of a control and data seperation. 
Control is used to send commands to the backend from the front end and 
data is used to recieve information to and from and to send profiles to 
the backend.  That could help a proken connection.  If a front end sends 
a control message to a backend and says "start this prfile at step foo" 
and then disconnects after it has begun, that is ok.  The back end is 
still sending data messages out on what it is doing, but no one is 
listening.  At some point, the client would come back and connect and 
see the next data message that says "hey i am now at step bar".

The comm module would also need some kind of authentication subsystem or 
mechanism.  I just don't want any person connecting to a backend 
willy-nilly.  I would imaging that PAM could be used or only support 
local passwords in /etc/passwd or /etc/shadow or something.


James Robertson -- jwrober at linuxfromscratch dot org
Reg. Linux User -- #160424 --
Reg. LFS User   -- #6981   --
LFS Bugzilla Maintainer    -- http://{blfs-}

More information about the alfs-discuss mailing list