[RFC] SRS Section 2
gerard at linuxfromscratch.org
Thu Feb 3 14:08:41 PST 2005
On February 3, 2005 02:59 pm, Jeremy Utley wrote:
> Well, this is what I'd always thought of when we'd talk about a
> client/server model. The idea I had was of a profile stored elsewhere,
> be it on the local network, or perhaps even a public profile server on
> the internet. There would be no need for the machine being built to
> have the full profile at all...it would get it's instructions from the
> profile server, and carry out those instructions locally.
So far that's almost the same as myself and others have proposed. Now one
question remains that I'm unclear on: who selects what profile to use?
The machine being built would fetch the profile from someplace in your model,
for instance http://ipaddress/alfs-profiles/belgarath.xml
Who initiates the download of said profile? Is it a user ssh'ed into Belgarath
who instructs Belgarath's alfs program to "fetch this profile and start
That is certainly not a bad option to have at all and can be very useful. Just
to clear up any confusion that may linger still: in the model I was thinking
about I don't ssh into Belgarath. I open a terminal on my own computer at
home (called Garion). I could select my "apache" profile and tell Garion's ui
program "connect to Belgarath and have it run this apache profile, causing
Apache to be upgraded on Belgarath without me having to ssh into it." The
advantage by extending is when you tell Garion's alfs program "load the
iptables profile and connect to *every* machine you know about and tell all
those machines to upgrade iptables." This saves you having to ssh into
Belgarath and Garion and Eriond and Anduin and other servers, have a dozen
ssh sessions open that are instructing to "fetch iptables profile and build."
I hope this helps clear up the differences in models proposed by myself and by
Jeremy Utley. I'm not saying we only have to support one model. Why not both,
they have their own good sides for different scenarios.
> The main issue I can see with this is system configuration...but that
> could be worked around by writing some additional information into the
> DTD to allow user interaction - the profile instructs the program to ask
> the user what IP address they want, and so on.
I currently get around that by defining such things in entity files. A file
called "config.ent" gets symlinked from a host specific config file. This way
apache's profile would simply load "config.ent." This file could contain the
filename for a httpd.conf file, or a kernel configuration file. Apache's
profile simply runs "cp &httpd-config; /etc/httpd"
In either of our models, the machine where something is built on will be told
to "fetch apache's profile and also fetch your machine's configuration entity
file." In our case it's obtain by yourself, in my case it's wait until I give
it to you explicitly.
/* If Linux doesn't have the solution, you have the wrong problem */
More information about the alfs-discuss