[RFC] SRS Section 2

Gerard Beekmans 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.

Gerard Beekmans

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

More information about the alfs-discuss mailing list