Securing your Linux lab with resettable user accounts
Let your lab users play, and restore the original settings for the next login.
Scenario one: You're in charge of an open computer lab at a public library. The users in the lab must have the ability to customize the computers over the course of their session, but you want to make sure any modifications they make, whether accidental or intentional, won't become permanent. The changes they make must disappear once the computer reboots so that the next user on the system will receive a "clean" home directory with the default user environment.
Scenario two: You're in charge of an open computer lab at a school. When students come in, they can sign on as either user math or english for a predefined selection of subject-related applications. As with the library scenario, the students don't have individual login names and passwords, and you don't want the students' choice of desktop or downloads to stay on the machine permanently. Every time a math student signs on as user math, the user receives a "clean" default configuration.
This second scenario describes my own work environment. As part of my job at Evergreen Valley College (San Jose, California), I administer a computer classroom with 30 dual-boot computers (Windows XP and Linux). To make sure students using Windows have a uniform experience every time they sign on, the computers have a product named Deep Freeze that makes sure any changes to the computer's configuration, whether accidental or purposeful, disappear when the computer is rebooted.
When I started working in the lab, Deep Freeze did not offer a Linux version. A Linux version is available now, but it's not free (as in either speech or beer), so I decided to make a "poor man's" Deep Freeze for the Linux side of the computer lab.
More Secure Passwords
A two-letter salt encrypts passwords using DES, the least secure form of encryption, which is accepted by all distributions of Linux in the usermod command. Mandriva and Ubuntu will accept encryption in the MD5 format. To produce an MD5-encrypted password, use a salt that begins with $1$, followed by exactly eight characters. Below is the output of the encryption for user math using MD5 and an arbitrary eight-letter salt:
$ perl -e 'print crypt("counting","\$1\$jwyxngms"),"\n"' $1$jwyxngms$2vt6pMlVbZO4l9TTmaYBC0
How It Works
First, create a compressed file containing the image of the home directory of each Linux user you want restored at reboot time. (In the example of the computer lab, there will be two image files, one with the clean desktop for user math and one for user english.)
Then set up a configuration file that gives that user's name, an encrypted password, and the location of the compressed image file. At boot time, an init script calls a Perl program to restore the user.
Creating the Student Image
On one machine, designated the "master copy," adjust the configuration (desktop, menus, applications, etc.) for each student to the state desired. Here's the tricky part: You can't compress the student's home file while signed on as that student. Instead, you want to be alone on the machine. Pressing Ctl+Alt+F1 drops you into a text-only terminal. To go to single-user mode, log in as root and then type:
When in single-user mode, you are the root user, the network isn't running, and you are guaranteed that the user whose files you are compressing isn't online.
Now create images of the user directories you want restored at boot time. If your computer lab has separate accounts for math and english users, use tar to create a compressed image for each:
tar -cvzf math_home.tar.gz /home/math # gzip form tar -cvjf english_home.tar.bz2 /home/english # bzip2 form
Of course, you probably want to use the same archive format for all the users you want to restore, but I wanted to show an example of both forms. The name of the compressed image file must end with .gz or .bz2 or the restore program won't work properly. In my lab, the average size of each user image file is about 2MB.
Local or Remote
Either you place the image files on a server or you copy them to each machine. The advantage of the server is that you need to put the files there only once; the advantage of placing them on each machine is that you do not need to depend on a network connection that might be down or have a slow transfer rate.
In most cases, you will probably place your image files on the server. For my lab, it was more advantageous to copy the files to each of the machines. If you are installing the images on each machine, you probably want to upload the image to a server somewhere and download it to each machine via FTP or wget. Also, you could copy the image files to a USB stick and then copy them to the individual machines.
A major setback for the Linux desktop.
Improved support for GPU in virtualization.
News site for the openSUSE community falls victim to a Wordpress exploit.
The source code is available online.
One out of three virtual machines on Microsoft Azure Cloud run Linux.
The form factor of the board makes it a drop-in replacement for Raspberry Pi.
Makes it easier for customers to move workloads into container-centric applications.
SUSE’s answer to container-centric operating systems.
Linux 4.9 is the biggest release in terms of number of commits.
The latest version of the official RHEL clone is here.