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 */
--
http://linuxfromscratch.org/mailman/listinfo/alfs-discuss
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
