Re: [suse-linux-uk-schools] Plans for a Linux distro
Michael Brown wrote:
Not sure that any of us have the resources to create a distro, even if we
all combine. Our preferred approach is to customise existing distros (in our case, Mandrake, for now).
Yes, perhaps I didn't quite make this clear enough before ;) I certainly don't intend to create a distro from scratch. Just take an existing one (e.g. Red Hat 7.2, which I chose for a few reasons), rip out the irrelevant packages (games, GNOME, etc), hack the bootup floppies a bit, and burn a CD with the new system on. I'm afraid SuSE is out for a few reasons. The main reason is that SuSE do not create freely downloadable/reusable ISOs of the system. Addtionally, I consider SuSEConfig and YaST to be largely a pain in the ar$e. <snip>
maintaining an enterprise-wide network of five thousand computers should be barely noticeable.' A few of the features: o Allows installation of workstations with only a floppy disk and two keypresses (the two keypresses are required only as a safety check). No further manual intervention required. o For all servers other than the first: allows installation of servers with only a floppy disk and about 10 keypresses. No further manual intervention required. <snip>
Although the design document is incomplete beyond the specification, the code has passed proof of concept stage and is nearing alpha release. You might find this tool helpful; it's a lot easier to take a 'standard' distro and reconfigure it than it is to repackage everything with your desired configuration. :-)
Right, this sounds very good :) Have you thought about perhaps taking a standard distro and adding this stuff to this, burning a CD and distributing it? This is pretty much what I want to do. You say that you can install a workstation by only presssing a few keys. Does this work on all distros (or even FreeBSD?)? If so, how?
Kickstart is nowhere near flexible enough to be relied upon as a primary distribution method. Believe me; we have tried this type of method for some time and it is not adequate to the task. Essentially, it comes down to a concept flaw shared by many, many systems (including some that I have written myself): there is a reliance upon a known initial state.
Ah right. Well, I don't really understand what you mean by this. Would you mind explaining a little more?
On the server side, CUPS would be used for the printing system and all machines will have ext3 formatted hard discs. Reiser! ;-) * Have a central administration databases where: - User names and groups are managed - Print and disc quotas are managed - Software can be allocated to a machine/group of machines - The central configuration files are located <snip> If any configuration files (e.g. /etc/host or similair) have been modified, the updated versions would be downloaded. Perhaps CVS could be used here.
* A database such as NIS would probably be used for the administrative database LDAP is more flexible, has many desirable side-benefits and (in theory) interoperable with Win2K. It will also be possible to define the desktop menus (e.g. KMenu) that will appear on the user's desktop. This will be based around .desktop files, and a utility will convert these files to Blackbox menus so that the menu is kept consistent between different desktops. The Debian menu system (also integrated into Mandrake and probably a few other distros) will keep all window manager menus synchronised. Well worth a look.
On Fri, 1 Feb 2002, Chris Howells wrote:
Although the design document is incomplete beyond the specification, the code has passed proof of concept stage and is nearing alpha release. You might find this tool helpful; it's a lot easier to take a 'standard' distro and reconfigure it than it is to repackage everything with your desired configuration. :-) Right, this sounds very good :) Have you thought about perhaps taking a standard distro and adding this stuff to this, burning a CD and distributing it? This is pretty much what I want to do.
Historically we have always used network installs but there is no reason why it couldn't be burnt onto a CD.
You say that you can install a workstation by only presssing a few keys. Does this work on all distros (or even FreeBSD?)? If so, how?
The broad approach is start by doing a bare-minimum install that is fully
automated. Under Mandrake, this is achieved by playing around a little
with the standard boot disk and creating a small auto-install config file
that lists things like the packages to be installed, the default root
password (MD5 hashed, of course!) and specifies that all network settings
should come from DHCP. We can boot from a floppy, press "F", "Enter" and
after 2-5 minutes the system has done the minimal install, rebooted[1] and
is up and running on the network.
At this point, our configuration tool comes in: the workstation (or
server) will locate a source of configuration rules and proceed to install
any necessary additional software and set up any required configuration.
Assuming that all workstations in a school are identical, this means that
you just define the workstation configuration as the default. Servers may
have particular roles, so you would often need to specify their identity.
This is done by typing "fen id=
Kickstart is nowhere near flexible enough to be relied upon as a primary distribution method. Believe me; we have tried this type of method for some time and it is not adequate to the task. Essentially, it comes down to a concept flaw shared by many, many systems (including some that I have written myself): there is a reliance upon a known initial state. Ah right. Well, I don't really understand what you mean by this. Would you mind explaining a little more?
Simplest example is this: suppose you design your workstation configuration and use Kickstart (or similar) to roll it out to half of your 300 workstations. At this point, you realise you made a small mistake in the configuration. There is no easy way to use Kickstart to repair the mistake on the 150 workstations that have already been rolled out, short of rolling them out again (which is time-consuming). Basically, Kickstart is able to perform the transformation "empty machine->installed machine" but is unable to perform the transformation "installed machine->installed machine with slightly different configuration". (Of course, Kickstart and other programs such as Ghost or DrakX were never intended to carry out the latter transformation). The "reliance upon a known initial state" is a more general problem. As an example, consider the following two methods of configuring a new Samba installation: 1. In /etc/smb.conf: Comment out the netlogon share definition In [homes], add the line "user = %S" In [global], add the line "map to guest = Bad User" vs. 2. In /etc/smb.conf: Ensure that the [netlogon] share definition is commented out Ensure that the [homes] share has the setting "user = %S" Ensure that the [global] setting "map to guest" exists and is set to "Bad User" The latter is more flexible; we don't need to worry about what state the smb.conf file is in before we apply the configuration. If we make a mistake in the configuration then we simply change it and reapply it - we probably don't need to do an "undo changes" operation first. We can apply the second method to every machine on a network without worrying that some of them might have already had it applied. If you rely on an initial state then your code will be less robust. Well-written applications will be able to run without requiring any per-user setup first; they will simply create configuration files as necessary. Poorly-written applications (such as most Win32 applications!) will insist on having things like registry entries created by a setup utility before the application is run. Michael
On Fri, 1 Feb 2002, Chris Howells wrote:
Although the design document is incomplete beyond the specification, the code has passed proof of concept stage and is nearing alpha release. You might find this tool helpful; it's a lot easier to take a 'standard' distro and reconfigure it than it is to repackage everything with your desired configuration. :-) Right, this sounds very good :) Have you thought about perhaps taking a standard distro and adding this stuff to this, burning a CD and distributing it? This is pretty much what I want to do.
Historically we have always used network installs but there is no reason why it couldn't be burnt onto a CD.
You also can do network installs without needing to have CD drives in the machines. Also a full distribution of something like SuSE won't fit on a CD, but it will fit nicely on a cheap HDD.
You say that you can install a workstation by only presssing a few keys. Does this work on all distros (or even FreeBSD?)? If so, how?
The broad approach is start by doing a bare-minimum install that is fully automated. Under Mandrake, this is achieved by playing around a little with the standard boot disk and creating a small auto-install config file that lists things like the packages to be installed, the default root password (MD5 hashed, of course!) and specifies that all network settings should come from DHCP. We can boot from a floppy, press "F", "Enter" and after 2-5 minutes the system has done the minimal install, rebooted[1] and is up and running on the network.
At this point, our configuration tool comes in: the workstation (or server) will locate a source of configuration rules and proceed to install any necessary additional software and set up any required configuration. Assuming that all workstations in a school are identical, this means that you just define the workstation configuration as the default. Servers may have particular roles, so you would often need to specify their identity. This is done by typing "fen id=
" instead of just "f" at the boot floppy screen.
If you wanted to be really flash you could probably do this by DHCP options :)
[1] One neat trick we came up with is that you don't need to remove the floppy before rebooting - magic! (Yes, I *am* lazy enough to find the need to remove floppy disks at specified times irritating!)
Pity the PC industry settled on manually ejecting floppies, most other removable media has the ability to eject under software control. -- Mark Evans St. Peter's CofE High School Phone: +44 1392 204764 X109 Fax: +44 1392 204763
On Fri, 1 Feb 2002, Mark Evans wrote:
At this point, our configuration tool comes in: the workstation (or server) will locate a source of configuration rules and proceed to install any necessary additional software and set up any required configuration. Assuming that all workstations in a school are identical, this means that you just define the workstation configuration as the default. Servers may have particular roles, so you would often need to specify their identity. This is done by typing "fen id=
" instead of just "f" at the boot floppy screen. If you wanted to be really flash you could probably do this by DHCP options :)
Am planning to. Only problem is the initial creation of the DHCP reservations: it's extremely tedious to do this by hand and counter-intuitive to have to find out the MAC address on the target machine, then create a reservation, then install the target machine. I'm therefore planning to allow for a method of creating DHCP reservations that is controlled from the target machines. In essence, specifying an "id=" tag at install time will trigger the creation of a DHCP reservation. On a bit of a tangent: I have managed to use DHCP to allocate computer names to Win2000 boxes. Win2K rollouts are now down to around 10 keypresses, although the method is based on Ghost and so is flawed for reasons I have outlined elsewhere. Michael
Am planning to. Only problem is the initial creation of the DHCP reservations: it's extremely tedious to do this by hand
We do it by hand. It is tedious, but not too bad. Boot Rom or PXE machines display their MAC address on the screen, then we scribble it down on an old punch card, sneaker-net it into the other room where dhcpd.conf is almost permanently in vi, copy it in, save, rerun. On some systems the only way we can identify the MAC address is to watch the complaints on the DCHP log file, as we don't allow unregistered clients (and all addresses are fixed). We are trying to control everything through DHCP options, making the DHCP file our central asset register. Once it's in DHCP, the rest is almost completely automatic. Or will be, on the new system we are working on, when (if?) we have worked out why it keeps mis-identifying the drive geometry.
On a bit of a tangent: I have managed to use DHCP to allocate computer names to Win2000 boxes. Win2K rollouts are now down to around 10 keypresses, although the method is based on Ghost and so is flawed for reasons I have outlined elsewhere.
We are about to bite this one. We hope we can do it by executing a .reg file on bootup, because that seems the only way we can edit the registry. We can create the .reg file in a script. We are trying to avoid Ghost, and operate entirely through network downloads (i.e. no CDs). Takes about two hours for an initial install, but a breeze (we hope) thereafter. -- Christopher Dawkins, Felsted School, Dunmow, Essex CM6 3JG 01371-822698/821076 or 07798 636725 cchd@felsted.essex.sch.uk
On Fri, 1 Feb 2002, Mark Evans wrote:
At this point, our configuration tool comes in: the workstation (or server) will locate a source of configuration rules and proceed to install any necessary additional software and set up any required configuration. Assuming that all workstations in a school are identical, this means that you just define the workstation configuration as the default. Servers may have particular roles, so you would often need to specify their identity. This is done by typing "fen id=
" instead of just "f" at the boot floppy screen. If you wanted to be really flash you could probably do this by DHCP options :) Am planning to. Only problem is the initial creation of the DHCP reservations: it's extremely tedious to do this by hand and counter-intuitive to have to find out the MAC address on the target machine, then create a reservation, then install the target machine. I'm
My prefered way is to let one new machine try at once and cut and paste the MAC address from /var/log/messages.
therefore planning to allow for a method of creating DHCP reservations that is controlled from the target machines. In essence, specifying an "id=" tag at install time will trigger the creation of a DHCP reservation.
On a bit of a tangent: I have managed to use DHCP to allocate computer names to Win2000 boxes. Win2K rollouts are now down to around 10
You can do this win Win9x, with some fiddling. But it requires a reboot to set the hostname, silly...
keypresses, although the method is based on Ghost and so is flawed for reasons I have outlined elsewhere.
-- Mark Evans St. Peter's CofE High School Phone: +44 1392 204764 X109 Fax: +44 1392 204763
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday 01 Feb 2002 13:55 pm, Chris Howells wrote:
Michael Brown wrote:
Not sure that any of us have the resources to create a distro, even if we
all combine. Our preferred approach is to customise existing distros (in our case, Mandrake, for now).
Yes, perhaps I didn't quite make this clear enough before ;) I certainly don't intend to create a distro from scratch. Just take an existing one (e.g. Red Hat 7.2, which I chose for a few reasons), rip out the irrelevant packages (games, GNOME, etc), hack the bootup floppies a bit, and burn a CD with the new system on.
Hmmm....I wanted to play around with Linux From Scratch a bit - this seems like a good enough excuse as any to play around with it :-) I'm going to have some free time during the Easter holidays, so I'd be happy to play and see what I can come up with. Dan - -- dankolb@ox.compsoc.net - --I reserve the right to be completely wrong about any comments or opinions expressed; don't trust everything you read above-- -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.8 iQA/AwUBPFqppZdDUnce+EgsEQJ36QCg9eOGTyYSrekBfnp6s/WcznXGw7YAoJxX IJ6bd3jDBRRjgUZA6M1j29Q2 =N8gH -----END PGP SIGNATURE-----
participants (5)
-
Chris Howells -
Christopher Dawkins -
Dan Kolb -
Mark Evans -
Michael Brown