Plans for a Linux distro
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, 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? 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 Aim: 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). 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 hostname to use, and the kind of mouse that the box has. Implementation: 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. 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. 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 * 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. * 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 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 server. * 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 only KDE's architecture makes it very easy to provide configuration files based on this process - -- Cheers, Chris Howells -- chris@chrishowells.co.uk, howells@kde.org Web: http://chrishowells.co.uk, PGP key: http://chrishowells.co.uk/pgp.txt KDE: http://www.koffice.org, http://edu.kde.org, http://usability.kde.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8WXfHF8Iu1zN5WiwRAr/MAJ49n+Kg3R8zVZV24NPjlH17VflilQCfRLQO +192PCzfyq91Dl0yJpbPn2k= =sOPz -----END PGP SIGNATURE-----
On Thursday 31 January 2002 16:58, Chris Howells wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hello,
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?
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 :)
Chris, This sounds an interesting plan. I, too, am an RM client and can see where you're coming from in your plan. My policy with our RM connect network is to keep it looking after W98 desktops and that's all. I have a separate Debian box that runs Apache, MySQL, Php, Squid, SquidGuard and Postfix. Blowed if I know how I could help but I don't mind contributing in some way. Nigel -- Nigel Pauli - I.T. Manager St. John's School, Northwood, U.K. http://www.st-johns.org.uk/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 31 Jan 2002 16:58 pm, Chris Howells wrote:
Hello,
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?
Sounds like it could be a good idea :-) For those of us who aren't clued up on RM stuff, though, could you explain what RM Connect does?
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 :)
I'd like to help (well, after finals; so I'll be available in about 5 weeks time).
Linux distribution plan ------------------------ Target audience: Schools, colleges, universities
Aim: 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).
Would it be difficult to make the interface like RM Connect, so it'd be easy to pick up for people used to it? And, presumably, RM Connect would have some sort of support with it, supplied by RM? I think that it would be important to have some sort of support system in place, otherwise schools (I presume) wouldn't really look into it. Also, universities are more likely to have Novell, or some sort of Unix system, rather than RM (in college here, we've got Netware 5, soon to be upgraded to Netware 6). Schools are going to be the most likely target audience.
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 hostname to use, and the kind of mouse that the box has.
You could use a static DHCP system - then you wouldn't need to enter the hostname, and the server will give the same IP address to that particular workstation all the time. (Assuming you're talking about workstation; you could supply a separate floppy disk & CD for the server). Presumably with the workstation, you could just install the system via FTP/HTTP from the main server? (i.e. having a copy of the distribution CDs copied onto the server hard drive)
Implementation: 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.
You could use any distribution, and use GNU cfengine to make custom changes on a per-machine basis. It's very powerful software, and you can undoubtedly do what you want with it.
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.
- From a programming perspective, completely differently. From an end-user perspective, fairly similar :-)
Stuff like Kylix and Open Office will also be provided.
Be careful: you may find it difficult to distribute Kylix because it's non-Free software. You'd have to get permission from Borland. KDevelop is supposed to be nice for C/C++ QT apps, although I've never used it. And provide WINE - if it's in a school setting, they'll undoubtedly have some software that requires Windows (like ecctis).
On the server side, CUPS would be used for the printing system and all machines will have ext3 formatted hard discs.
Sounds reasonable, although ReiserFS is more mature ;-) (start filesystem flamewars here. And end here ;-)
* 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
Sounds like a job for cfengine. I don't really know enough about cfengine to be able to write configuration files (although I could poke around and give it a go, if you're really serious about this project). Print and Disk quotas you'd have to manage on the server-end, not with cfengine (which is used to push information out to clients).
* 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.
<pedant> You don't download via apache, you download via a web browser or wget </pedant>. This shouldn't be too difficult to do - set of shell scripts should suffice.
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.
Possibly. Or cfengine :-) Rsync may be a better option than CVS.
* A database such as NIS would probably be used for the administrative database
NIS is only used for sharing passwords. For the purposes described above, a simple MySQL database (or even some LDAP system, for people who like buzzwords) would probably be better.
* 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.
Or simply have /home NFS mounted automatically at boot time, rather than at login time.
* 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 information page showing stuff like information about disc/print quotas.
Webmin, possibly, may be useful?
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.
Fairly easily done. Same way as doing any other files :)
A web based e-mail system could be used to integrate with the IMAP mail server.
Again, lots of possibilities - check Freshmeat.
* The server side would consist of the following pieces of software: - Samba - Apache - Squid - IMAP e-mail server
NFS, NIS?
* 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 only
Fair enough.
KDE's architecture makes it very easy to provide configuration files based on this process
Sounds like it - if you're a KDE developer, then you'd know far more about it than I do :) 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/AwUBPFmKpZdDUnce+EgsEQIbawCfVNRZKprsae72ytS4S4sz4ndwDFcAoMxN e4wz7TX2cZseSnmOJm5btkbE =e+Qx -----END PGP SIGNATURE-----
On Thursday 31 Jan 2002 16:58 pm, Chris Howells wrote:
On the server side, CUPS would be used for the printing system and all machines will have ext3 formatted hard discs.
Sounds reasonable, although ReiserFS is more mature ;-) (start filesystem flamewars here. And end here ;-)
Or even a printing system flamewar... One relevent factor is that AFAIK, ReiserFS does not support file quotas, since ext2 does presumably ext3 does.
* A database such as NIS would probably be used for the administrative database
NIS is only used for sharing passwords. For the purposes described above, a
NIS also shares information on usernames, GCOS and group membership.
simple MySQL database (or even some LDAP system, for people who like buzzwords) would probably be better.
How easy is it to set up either MySQL or LDAP to have a replicated database and to transparently switch between copies though?
* 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.
Or simply have /home NFS mounted automatically at boot time, rather than at login time.
Which makes quite a few other things easier too.. Hardly an original idea though :)
* 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 information page showing stuff like information about disc/print quotas.
Webmin, possibly, may be useful?
Make more sense for this to be attached to a webmail system, but little point doing this for someone actually sat in front of a workstation. Instead makes far more sense to have GUI versions of (yp)passwd and quota... -- Mark Evans St. Peter's CofE High School Phone: +44 1392 204764 X109 Fax: +44 1392 204763
--- Chris Howells
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hello,
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?
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 :)
Sounds very good. I'm not sure I could help (technically speaking), but I'd be willing. I would like to learn about Kiskstart, and then combine it with a floppy. That'd be good - and easy to do I'd think. For those who don't know, and could give a monkey's... RM Connect sits on top of vanilla NT. They've just released version 3 that put's XP on the desktop. The version people probably actually have is 2.x which puts 98 (and 95) on the desktop. It has these advantages as standard (i.e. it comes like it, you don't have to footle too much): 1) It allows someone with lowish skills to bung in a floppy disk and hit 'build'. It connects to server and does a automatic install of Windows. (Yes, you can do this with NT - I don't have to mention that it can be done easily with linux right?) 2) It has a package manager that allows you to install an app on one workstation, test it, configure it, then export it to any/all others. (Yes, I'm sure this could be done with NT (better alternatives withlinux)) 3) Topics - which allows you to group desktop icons into a topic and then allocate a topic to people/groups. It _SLOWS_ down log ons incrediably - so I did away with them. Just assign a different desktop to a year group, and two sets of staff. I have about 9 desktop configs, and just assign them. Log ons have got much faster. (Yes, this can of course be done in vanilla NT (I haven't got my head round this with Linux yet - I prefer KDE, but I'm not quite sorted on how to sort out menus/dekstops for different groups. I just need to think about it for a bit. I'm trying this at the moment)). I can't think of anything else really. Does it work? Hmm - kinda. Do I like it? Not really, but it doesn't offend me. I wouldn't have chosen it. It was already installed when I arrived at the school. It was bloody expensive. At my last place I installed a Linux server. I know which I prefer. I'm not a member of any RM in UK schools mailing lists! :) As for the WindowBox stuff, I _never_ touch it. Very expensive for very average apps that you can replace with free stuff. -- Matt __________________________________________________ Do You Yahoo!? Great stuff seeking new owners in Yahoo! Auctions! http://auctions.yahoo.com
On Thu, 31 Jan 2002, Matt Johnson wrote:
1) It allows someone with lowish skills to bung in a floppy disk and hit 'build'. It connects to server and does a automatic install of Windows. (Yes, you can do this with NT - I don't have to mention that it can be done easily with linux right?)
Yes -- see SystemImager www.systemimager.org -- it can even do it over an ssh-secured link. Bob G
We're doing roughly the same, if we can get over current problems with recognition of drive geometries. Our differences are ...
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?
We're not starting with Connect. We're starting with Acorn NCs and diskless X/KDE terminals, and are under severe pressure to provide Windows facilities. So we are working on a shellscript that, given a PXE boot machine, formats and installs two partitions (X/KDE/FreeBSD & Windows) from the server, and on subsequent boots updates them.
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 :)
Want to keep in touch. We're not the same but there'll be lots of ideas to exchange.
Linux distribution plan - ------------------------ Target audience: Schools, colleges, universities
Aim: To provide a simple to install and administer networking system, which works in a mildly similar manner to RM Connect. Except it actually works (and has decent security), and is based on free software (GNU/Linux).
The Windows partition is easily eliminated from our system, but is currently necessary. Partly, we're trying to do with a script what we might otherwise have to do with Ghost.
By simply booting a machine with a boot floppy, it should be easy to install Linux on to the machine, after just asking a few questions such as the hostname to use, and the kind of mouse that the box has.
We're currently basing it on PXE booting because the new batch of second-hand machines we have have PXE boot cards. We're trying to arrange to control everything through parameters in the DHCP file.
Implementation: 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.
Based on FreeBSD, but otherwise no difference.
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.
Planning on KDE only.
Stuff like Kylix and Open Office will also be provided.
StarOffice and KOffice. Maybe others.
On the server side, CUPS would be used for the printing system and all machines will have ext3 formatted hard discs.
May look at CUPS.
* 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
We hope this will all be based in the DHCP and plan to write a MySQL database to generate the DHCP config file.
* 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.
We are planning to use "cpdup" to mirror the server filesystem on each remote machine (controlled by exclusion files ".cpignore").
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
All machines are NIS clients to an NIS server.
* 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.
This is one of the tricky bits, but we have a FreeBSD-specific NFS mod to allow it.
* 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 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.
Haven't started on these things yet.
A web based e-mail system could be used to integrate with the IMAP mail server.
We use Squirrelmail occasionally, but we mostly use pine.
* The server side would consist of the following pieces of software: - Samba - Apache - Squid - IMAP e-mail server
Of course.
* 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 only
KDE's architecture makes it very easy to provide configuration files based on this process
Still thinking about these things. Where are the applnk & config fies documented?
- -- Cheers, Chris Howells -- chris@chrishowells.co.uk, howells@kde.org Web: http://chrishowells.co.uk, PGP key: http://chrishowells.co.uk/pgp.txt KDE: http://www.koffice.org, http://edu.kde.org, http://usability.kde.org
-- Christopher Dawkins, Felsted School, Dunmow, Essex CM6 3JG 01371-822698/821076 or 07798 636725 cchd@felsted.essex.sch.uk
On Thu, 31 Jan 2002, Chris Howells wrote:
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?
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). I wasn't going to put this on public release yet, but take a look at http://www.fensystems.co.uk/design.ps.gz - it's the in-progress design document for FenConfig. A brief summary: 'FenConfig is a flexible system configuration tool for enterprise-class networks. It allows you to create "configuration rule sets" which can be applied to any set of configuration files (including application configuration files). Configuration can be hierarchical, so that a configuration rule set could apply to a single computer or an arbitrarily large group of computers. The goal of FenConfig is to ease the administrative burden of maintaining large groups of computers. In an ideal world, the difference between maintaining one computer and 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. o Uses RCS: all configuration files are version-controlled so there is a clear audit trail and it is possible to revert the configuration to any previous point in time. o All configuration is hierarchical and group-based. It will be possible to delegate responsibility for configuration. As a very simple example: you could specify a site-wide browser home page within your configuration rule set but allow department heads to alter the home page for people logging on to computers in their department. You can do this *without* allowing them to alter anything else (e.g. proxy settings!). o Will work alongside almost any existing configuration tools. If you like SWAT then use SWAT to design your configuration and FenConfig to distribute it sensibly around the network. 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. :-) A few answers to some specific points:
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 hostname to use, and the kind of mouse that the box has.
Use DHCP wherever possible. There is, from long experience, a *big* difference between an automation system that requires one user interaction per computer and an automation system that requires zero user interactions per computer.
Implementation: 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.
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.
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. Best of luck! Michael
Hello,
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
Aim: 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.
Implementation: 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 database
* 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 NT.
* 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 server.
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 safe".)
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 store password.)
* 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 only
KDE's architecture makes it very easy to provide configuration files based on this process
-- Mark Evans St. Peter's CofE High School Phone: +44 1392 204764 X109 Fax: +44 1392 204763
participants (8)
-
Chris Howells -
Christopher Dawkins -
Dan Kolb -
Mark Evans -
Matt Johnson -
Michael Brown -
Nigel Pauli -
Robert J Gautier