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