Mailinglist Archive: opensuse-edu (332 mails)
|< Previous||Next >|
Re: [suse-linux-uk-schools] Plans for a Linux distro
- From: "Mark Evans" <mpe@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Fri, 1 Feb 2002 10:03:07 +0000 (UTC)
- Message-id: <20020201100407.966.qmail@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
> It's a long story, but basically I have been increasing annoyed with RM
> recently. Therefore, I would like to create a Linux distribution which works
> in a similair manner to RM connect. What do people think of these proposals?
A lot of people appear to dislike RM, for one
reason or another. Suprisingly they appear to
stay in business :)
> I can't guaranteee that it's going to happen or quickly (I'm busy with school
> and developing KDE), but if some people want to help as well, then it just
> might :)
> Linux distribution plan
> - ------------------------
> Target audience:
> Schools, colleges, universities
> To provide a simple to install and administer networking system, which works
> in a mildly similair manner to RM Connect. Except it actually works (and has
> decent security), and is based on free software (GNU/Linux).
Assuming that RM Connect is the best thing to copy in
the first place. Which is always the problem with
trying to copy an existing software system.
> By simply booting a machine with a boot floppy, it should be easy to install
> Linux on to the macine, after just asking a few questions such as the
How often do people install software on machines,
how often *should* people be doing this. Also
if you are using a bootable floppy how do you
make sure that the machine ends up set not to
boot from floppy?
> hostname to use, and the kind of mouse that the box has.
You can set the hostname via DHCP.
> A Linux distribution based on Red Hat 7.2 would be created. The main reason
> that Red Hat is suggested is because it can be installed based around the
> Kickstart installation system, which enables an administrator to stored the
> installer settings in a configuration file, rather than needing to sit in
> front of the computer and tend to the the installation every time a question
> is asked.
> The distribution will:
> * Be mainly based on KDE, but provide Blackbox for older hardware (486s and
> slow Pentiums). There is a possibility that GNOME could be provided as well,
> but I prefer KDE, and know very little about how GNOME works.
> Stuff like Kylix and Open Office will also be provided.
One thing to remember is that any software must "just
work" you don't want it prompting the user for information
on how to set it up. Including if it should or should not
create files/directories under ~ or asking for anything
like user's name or email address. Also you don't wanti
the end user able to do things like change browser proxy
settings, the "From:" settings in email software, etc.
Quite a bit of software, such as web browsers, GUI email
programs, Open Office, etc currently expects to be
end user configured. In some cases you want sensible
(possibly sitewide) defaults, in other cases you want
settings which can only be changed by the sysadmin.
> On the server side, CUPS would be used for the printing system and all
> machines will have ext3 formatted hard discs.
> * 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
> * On booting up a machine, a system service will check with the server hosting
> the administrative database whether any software has been
> allocated/deallocated. If so, it will be downloaded via apache and installed
> locally, or removed, as appropriate. However, some larger software such as
> Open Office might want to live permanently on the server.
Sounds horribly complex, as well as an attempt to copy
Windows for the sake of it. Unless there is a very good
reason for the application needing to be on local media
why insist that it goes there. (If there are bits which
need to be handled locally that was what /var was invented
for.) The fewer copies you have of software the easier
any updating is.
> 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.
Why should anything in /etc on the workstaions need altering
on a regular basis anyway?
> * A database such as NIS would probably be used for the administrative
> * Upon loggin in (via kdm) the system would map the user's home directory on
> the server to the /home/user directory on the user name. NFS or SMB are
> possibilities here.
Do you mean have some sort of automounter, the description
appears convoluted. KDE uses unix symbolic links for things
like .DCOPserver_<hostname> AFAIK you can't create these
using SMBFS, regardless of it is talking to Samba or Windows
> * There will be some user based administrative tools. This will allow the user
> to change his/her password via a web browser. There will also be an
KDE already includes as standard a GUI version of /etc/passwd,
can't exactly be hard to do the same thing with yppasswd or
the equivalent with something like LDAP.
> information page showing stuff like information about disc/print quotas.
> 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.
> A web based e-mail system could be used to integrate with the IMAP mail
Check out www.courier-mta.org. Which uses a variation of
Maildir allowing access to mail by IMAP, web and file access
to the mailbox. (If needs be at the same time and "NFS
>From a user POV the latter makes sense for desktop
access. Since the user just runs a program and there
is their mail. No need to type in passwords (or worst
> * The server side would consist of the following pieces of software:
> - Samba
> - Apache
> - Squid
> - IMAP e-mail server
> * It will be possible to customise the desktop to default levels. For
> instance, by most KDE configuration files will be held in a globally readable
> directory (perhaps in /usr or /etc). Therefore ~/.kde will be mostly read
> KDE's architecture makes it very easy to provide configuration files based on
> this process
St. Peter's CofE High School
Phone: +44 1392 204764 X109
Fax: +44 1392 204763
|< Previous||Next >|