Re: [Computerbank] Linux distribution standardisation

[David Hatton <davidth@melbpc.org.au>]

Hello All,

Apologies for being a little slow off the mark on this one - I've been
somewhat preoccupied with other things for the past few days - and there
were over 35 computerbank emails waiting for me tonight! Good to see the
lists being used!

For (another?) 2c worth regarding Computerbank installs -

Raul made some good points about a high level approach and working out
various configuration details.  Basically, this is what the Vic branch
started out to do.  However, it was found that most of the recipients
wanted a very similar configuration, with the exception of
organisations needing networked machines - still haven't solved that
one satisfactorily yet.  It also happened that cbv had a large stock or
very similar machines, namely Pentium 133's with 32 MB RAM - enough to
allow us to concentrate on a software configuration to suit this type of
machine.

So the approach was to work up a few computerbank specific Debian
packages and put them on the internal cbv debian mirror, which
effectively added our customised install packages to the standard
Debian install package selection list. This list is the list of
packages for particular functions, and is only around 25 items long.
From memory (I'm at home now) the packages were called something like
cbv-barebox, cbv-basicdesktop, cbv-laptop, cbv-officedesktop. These
packages were set up to call in dependencies which would install all
the required software simply by selecting one (or two) of the cbv-*
packages.

With this method the package install proceeds with a few questions to
answer along the way. Then all that is required is what we call the
final configuration, which essentially is a volunteer sitting down at
the newly installed machine and setting up user accounts, checking that
the monitor and floppy work OK, and checking/fine tuning the user
desktop etc.  

There is no reason why this couldn't be extended by creating more
computerbank specific packages with different contents to suit
different types of machines and adding them to the same package
selection list.

Of course, this approach assumes an internal network.

Several others have discussed the choice of distribution, and the
options seem to be narrowing to either RedHat or Debian - from memory
Mandrake is optimised for Pentiums and won't install on 486's (?).

I'd like to put in a plug for Debian.  As outlined above, it lends
itself to customised network installs, and I have found the package
installation management tools way ahead of the rpm based distributions,
even though some people might be put off by the non GUI installation
interface.  As someone else commented, once you have stepped through
the install a couple of times, it all starts to make sense.

Now I'm happy to admit that I'm not a rpm expert, but I have tried to
install software packages on both Mandrake and RedHat after an initial
setup has completed. Maybe I'm unlucky, but I have frequently selected
a package or two only to have the rpm installer come up with a message
to the effect that "I can't install package A because it requires
package B which is not installed" and quits. Sometimes it just gives a
file name, eg/. libsensor.so.1, and I have no idea which rpm package
contains the missing file.

In the same situation with Debian, the installer has enough smarts to
find out if package B is available, and if it is, will duly download
and install package B followed by package A. Otherwise it emits a
generally intelligent error message.  The decrease in frustration
level is significant, especially if you are running against the clock to
complete an installation for a recipient to take home!

Regardless of the distribution, all package managers will have some
gotchas, and while Debian may have other management issues they seem to
be ones which are amenable to a standard fix which then becomes part of
a routine install. Such fixes do need to be documented, however.  I
suppose my pre-occupation with package management is because that is
what I find myself using most frequently to get systems installed.

As to the contents of the software packages, there is generally enough
disk space if the machine meets the current minimum hardware specs to
include a good range of "user oriented" software.  Again from memory, a
typical cbv installation includes the word processors abiword and ted,
with StarOffice if specifically requested - we train only on abiword at
the moment - the gnumeric spreadsheet, the dia diagramming tool, the
gimp, a typing tutor (xterm based but set up as a Gnome panel button),
Netscape communicator, xchat, and the GNOME desktop with its
utilities.  There are probably others that I can't recall off the
cuff. 

There are also a couple of packages that ease the use of Microsoft Word
generated files, but that is a separate topic in itself.

In addition to the above user oriented stuff, cbv also install some
items
which would be useful if any support people need to work with the
machine on site.  As standard, an account called admin is set up for
such an occasion. The tools available are console editors vi and joe,
together with utilities to allow remote access and general
troubleshooting.  These tools, being console based, don't take up much
extra space and can be very useful in an emergency.

Low end machines - generally if a machine meets our current minimum
hardware specs for GUI installs then Gnome will usually be useable -
not quick, but useable. The critical thing here is memory - I have run
GNOME on a 586 with 16MB RAM and then with 48MB RAM and the difference
is significant enough to allow an upgrade from Netscape 3.x to Netscape
4.x. 32MB seems to be the minimum acceptable for useable performance
using GNOME, don't know about KDE (yet). The question then becomes - do
we rigorously enforce our minimum specs for recipient machines ? Also,
there
seem to be a couple of gotchas going forward. 

As with all software, improvements and more features mean greater
computing resources are needed. So we are beginning to see the
emergence of linux apps which are resource hogs when run on typical
computerbank recipient machines.  This seems to apply to both Gnome and
kde specific apps. If the hardware requirements outpace the type of
hardware we have available, we will have to revisit the software load
question, probably with a view to carefully selecting compatible
components and putting them together with an efficient window manager,
eg/. icewm. 

With respect to kickstart etc - I may be on the wrong tram here but my
impression is that these type of mass installers are intended for
machines which are pretty much identical in hardware specs - how would
they go installing two machines, say one with a Pentium 200 and 48MB
RAM, and one a 486DX/100 with 32 MB RAM, each with different video and
network cards ?

Printing - I'd suggest either a short list (ideally one or two only)
of printers for which we can develop a standard setup, or a GUI setup
tool complete with printer drivers to cover the options.  Perhaps we
could migrate a suitable tool to the distribution of choice if needed?

Partitioning Hard disks - cbv have usually used the KISS approach for
single disk installs - one partition mounted on / and one partition for
swap.  If there are two disks, the larger one is usually mounted on
/usr and the other is mounted as / - the swap location would generally
be determined on a case by case basis.  Occasionally the split might be
/ and swap on the larger disk, with /home on the smaller, especially if
there is a significant difference between them.

Hope this helps,

Cheers,

David H.

-- 
--------------------------
David T. Hatton
(davidth@melbpc.org.au)
--------------------------
_______________________________________________
computerbank mailing list
computerbank@lists.linux.org.au
http://lists.linux.org.au/listinfo/computerbank