Mark Ellis wrote:
On Tue, 2005-07-05 at 21:39 -0500, James Robertson wrote:
Matthias Berndt wrote:
Greetings,
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?
Regards
Matthias Berndt
Matthias,
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?
Thought?
James
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
--
James Robertson -- jwrober at linuxfromscratch dot org
Reg. Linux User -- #160424 -- http://counter.li.org
Reg. LFS User -- #6981 -- http://www.linuxfromscratch.org
LFS Bugzilla Maintainer -- http://{blfs-}bugs.linuxfromscratch.org
--
http://linuxfromscratch.org/mailman/listinfo/alfs-discuss
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
