Distributions/Configurations For Specific Uses?

Page writes "My college (UMPI) is currently reviewing a proposal to collect old hardware from small businesses and assemble machines for those who do not have a PC. The issue came up as to what linux distro to use that will allow us ease of both setup and ability to lock down the machine so once they are out in the field, they cant be tinkered with by accident (thus preventing problems later). These will be used solely for the purpose of web activities (surfing/mail), and word processing and *THATS IT*. Does anyone have suggestions and an idea about how to go about a standardized (or a sort of embedded) configuration across variable hardware?"

Comments

We did this once...

[ites]

(But for a standardized hardware platform)
(and for an industrial application...)
Using DHCP and BOOTP, we loaded the OS and the applications across the network.
The PC had no hard disk, no drives.
The boot server was itself booted from a CDROM.
So there was nothing to break or mess with.
For word processing you'd have to use a network drive but that makes sense for backups anyhow.
Modern Linuxes are pretty good at detecting existing and especially legacy hardware.
So this approach would work for your problem.

LiveCD a-la Gentoo setup?

[Hobart]

You might want to take a look at how Gentoo Linux puts together their "LiveCD" for installation purposes...

Since you don't want these people to be able to change any configurations, just have a web browser and word processor, getting them to where their setup boots off of a read-only CD that has the tools they need may be the solution.

Of course, this is a large amount of work, but perhaps the time you save putting it together will outweigh the time you might loose if they mess with and break their configurations. ;)

FireCast Linux

[wirespring]

My company WireSpring Technologies makes a custom version of Linux called FireCast that's designed specifically for remotely managed terminals like kiosks, public terminals, and the like. We've got some customers in the education industry who are doing exactly what you mention, on hardware that they were set to abandon before they found us. Even if you don't go with our software, you might get some ideas from the interactive demo. Good luck!

Knoppix -- bootable CD with Moz, Open Office, etc.

[Chuck Messenger]

Knoppix sounds like it would be perfect. It's a bootable Linux CD, which includes lots of useful software, including Moz and Open Office. So, users couldn't accidentally screw it up. It did a nice job with the 2 computers I tried it on. It can access an attached hard drive or floppy, for storing files. Not sure how it deals with Moz profiles, for setting up email. But you could always set them up with web mail.

Re:Knoppix -- bootable CD with Moz, Open Office, e

[Unholy_Kingfish]

I think that Knoppix would be a good stating point. Set up accounts for all the users(which most universities already do), and give them XXmb of storage for saving documents. You can ad some scripts that would make their default that space. (moding the Knoppix CD) That CD would be used to boot form on all the systems, you _could_ even skip using a hard drive in the system, but it would be slow without the swap file. Now all systems would have the SAME setup, same menus, everything. Each user would have his/her own name and pw to get into the network and their storage. When it is time to update the software you just send out new CD's to each user and they replace the old one. So lets say as the project continues you can make a more specific install with more or less programs, custom programs whatever. Do a test release to one floor in a dorm and see how it goes... tweak and tweak and tweak.... ________________________________ Michael Alexander

done this - chroot

[Permission Denied]

I've done this. Basically, set up public email/web kiosks.

1. Password-protect the BIOS. People will mess with this.
2. Be careful with the boot manager. Make sure people can't pass kernel arguments (eg "linux init=/bin/sh"). Grub allows you more options than lilo in this direction.
3. Modify all boot scripts to ensure there is no way to get an interactive shell at boot.
4. Use some filesystem that's resilient to reboots. People will reboot the machines (unplug them) all the time, so use ReiserFS or ext3.
5. You'll probably have more than one person managing these machines. Try looking into pam_ldap, or pam_krb5 (whatever is appropriate for your organization) along with pam_listfile, so that only two or three people know the root password.
6. Browsers aren't meant to do this. For instance, you can type in a URL like "file:///" and use the browser as a file manager. Prevent this by running the web browser in a chrooted environment.
7. Disk space may be low on older machines, so don't copy files to the chrooted environment - hard link them instead (hard links work across chrooted environments). Basically, what you do is "ldd browser" and hard link all those libraries into the chrooted environment. Then run the browser, see what files it requires (eg, /etc/resolv.conf, any shared libraries it loads itself using dlopen(3), and so on), hard link those files and continue until you have a working environment.
8. Also on the browser end, you may have difficulties finding a browser that will run quickly enough on older hardware. Mozilla and Konqueror are sluggish on my Athlon XP 1800+, so they are quite out of the question. I also had little success with Opera, and I'll tell you now that Netscape 4.x may be your only viable choice.
9. I wrote my own window manager custom to the task. I would recommend that you run a window manager that you KNOW won't launch any other programs unless you specifically make it do so. Look into wm2, and then modify it (it's very clean code) so that it will never start up xterm and so the root menu shows a list of allowed programs (browser, ssh to read mail, etc).
10. You may also want to allow people to read mail using SSH. Remember to disable the "escape" character for ssh so people can't drop into a shell. I wrote a small front-end to ssh that pops up a GUI asking for username and password (and I modified SSH to take the username and password from the GUI using unix domain sockets). People really appreciated the little GUI, but there are some issues involved in this and you need to be experienced in Unix/C (openssh nowadays comes with its own program that pops a GUI asking for password, but it behaves in such an unfamiliar way (eg, not like Windows or MacOS where you two text boxes asking for username and password at once and the password field shows you how many characters you've typed) that it's completely useless for this situation).
11. I used tar to image the machines. I couldn't use a dedicated IDE drive duplicator since the drives were different sizes and I NEEDED all the space I could get on the drives. It basically goes like this: put src and target drives in machine, boot off src, fdisk/format target, mount target on /mnt, and then do cd /; tar -cf - bin usr var lib etc | (cd /mnt ; tar -xvf -). Make sure you don't specify proc or any other directories you don't need and then remember to create /mnt, /tmp, and so on the target drive. This doesn't take long and you can train a plentiful non-unix person to help you do it.
12. Don't expect great success. Most of your users (especially those that don't have computers) will have never seen anything that's not MacOS or Windows and they won't like the systems simply because they look unfamiliar.

Anyway, I'm a coder, not admin, at heart, so I ended up doing a lot of custom code (custom window manager, SSH front-end, stuff to get netscape to start up chrooted, etc) and it was a big time sink for the little benefit that it provided (people didn't like using the kiosks). Have fun.