New design, what is the Goal here?

Kendrick alfs at
Tue Nov 29 11:59:52 PST 2005

Mark wrote:

I've been trolling the ALFS threads since September so I might have
missed something or just plain got lost in the communications.  But what
is the overall goal of the new design being suggested?

It sounds like to me a Client/Server system is being purposed that would
allow us to setup LFS installs on a remote computer.  Sounds neat, but

Bruce Dubbs wrote:

> Actually, I have also been trying to understand the rationale for the
>remote build.  When I had several identical systems to build, I built
>one, tarred everything up, scp'ed the tarball, untarred, edited needed
>files (ip address, hostname, etc) and rebooted.  Worked fine.
>Rebuilding for every system seems to be a bit of overkill.  Copying
>seems to be the way to go.
>The only things I can see that would differ on different machines (of
>similar architecture) are a few config files and maybe the kernel.
>  -- Bruce

Heres an example for you.  you are the administrator of a medium sized
business with 7 servers and 150 desktops.  the board has dictated that
there must be X: security measures implimented in all desktops and Y:
security measures in the servers.  After searching no commercial distro
does it in a acceptible manner.  to build those systems by standard lfs
would be near a impossible task for the time allowed by your job.  all 7
servers are different hardware/software,  20 desktops have a specific
hardware/software combo for securly scanning/encoding client records, 
10 for accounting have a specific hardware dongle for security issues. 
etc...   that right there would be 10 different profiles not to mention
department specific software/hardware setups.  once the company gets the
inital install done it would be quite likely that yes they would image
new systems from a prebuilt image.. but that image must be maintained
and the servers would need to be maintained.
that is where this idea realy shines.   you are thinking from the home
install point only.  This idea however could be lfs's equivelent to rpm
to simplify the concept alot.  it would make running a large network of
lfs systems viable from the administrators standpoint.  also the
computer dude who has all his friends begging him to do ... or eving
independant contractors.  This system is being created because not every
one using lfs intends to make 1 system.  This is also being built to
assist in maintaining the system after it is built by allowing the admin
type person to upgrade ssl when a new security patch comes out.  since
ssl is most likely to be on every linux system when you have to fix that
on 150+ machines do you want to have to do it by hand? evin ssh ing to
them would be a pita.  Once mature it would be feasible to have a
"control" computer take care of updating the software on a whole
network.  That may be a bit down the pipe from where alfs is starting
but it is quite acheavible from the goals that are being worked on.  

hope that clears things up for you.  It also is nice for those of us who
are working on several projects at once.  ie 
lfs/hlfs/clfs/lfs_64/uclibc variants ect... to test changes one can
modify the appropriate profiles and then send the build commands to the
different systems intended for those projects. 

More information about the alfs-discuss mailing list