Client/Server - please straighten out the terms
jhuntwork at linuxfromscratch.org
Wed Feb 2 11:45:07 PST 2005
Jeremy Utley wrote:
> Randy, what he's talking about is one machine, connecting out to a bunch
> of daemons simultaneously, and directing them, instead of having
> multiple clients connecting in to a central server, grabbing the profile
> from the central server, and acting on their own. It's backwards, if
> you ask me. The machine you're building LFS on, you know you must have
> physical access to it (otherwise, how would you get the ALFS program
> going in the first place?). In the model these guys are describing, you
> have to have physical access to the server as well.
J, what you've described is basically just a file server for profiles.
We've already got that. What we're after is a way to administrate remote
LFS builds or as Gerard brought up, updates of remote machines.
Really, the model we're after is just a separation of the ui from the
parser/validator/builder. They are linked via a communication protocol.
Doing it this way, you can now open up a 'client' or ui for alfs and
connect it to a daemon - it doesn't matter if that alfs daemon is
running locally or remotely.
In a network environment like what Gerard describes, this becomes useful
because an adminstrator can install the alfs daemon as a service on each
of his machines and remotely monitor installations or upgrades on all of
More information about the alfs-discuss