Request status update

Gerard Beekmans gerard at
Mon Nov 21 17:31:57 PST 2005

Jeremy Huntwork wrote:
> Neither are the rest of us, which is why alfs stagnated. We could work 
> on something in C slowly... Otherwise, perhaps we could start working on 
> something in Perl or Python. It's the 'where to start' with this one 
> that flusters me.

Well, in the end we do the best with what we have, resources and 
people's skills alike.

I know nothing about Python. C isn't my strongest suit anymore and I 
could probably manage Perl nicely. Ideally there would be a GUI 
front-end something slapped up with QT Designer or something, who knows. 
That's probably running a little ahead of things, but we should look 
into that too and plan for it.

Let me just rehash as I see how things might work (in case there are new 
people here, or old people with bad memories).

A UI program would interface with a daemon type application that runs in 
the background. This could be a process running on the local machine, or 
on the remote machine. This UI (command line based, or graphic based 
makes no difference) would interface with this background process and 
make things happen.

The way I envision it, the userinterface is configured to know about 
machines it has access to control. You have an update for a program like 
coreutils, you select all the machines you want updated, and the UI 
establishes connections to the servers and sends the commands to 
download, build, and install the new coreutils package.

There are some questions that need answering of course. Do we stick with 
XML like we use in nALFS for profiles or do away with it. Who does the 
parsing: the client or the daemon who is doing the actual installing. 
The daemon could be the dumb app: it receives commands to run to get the 
job done. The client figures out what those commands should be. This 
makes it possible, and easy, for the user (us humans) to make changes 
since you simply cannot install every package the exact same way on 
every machine.

But let me back-up. That's all future talk. If we are to do this, we 
have to decide on the backend mechanisms first. Since remote admin is 
desired, a TCP based interface is necessary. A client logs into IP X on 
Port Y. Then it needs to authenticate itself. That's going to be our 
step one. A password of some sort would probably be the simplest and we 
can worry about security (ie: man-in-the-middle attacks) later I imagine.

So once the connection is established remote alfsd is ready to receive 
instructions. How are those going to be sent and received. That would be 
task number two. SOAP was suggested in the past as a possible good fit 
for this.

We could always make up our own protocol. Send a start-command-list type 
string. Then everything that follows could be a plain old shell script. 
End with an end-command-list string, send an execute-command-list and 
wait for feedback.

Just some food for thought.

We don't have to worry about the programming language yet. Let's figure 
out the lower level issues: logging in to a process running either local 
or remote and authenticate to it.

Gerard Beekmans

/* If Linux doesn't have the solution, you have the wrong problem */

More information about the alfs-discuss mailing list