Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
There is less than 12 hours left to vote in the 2015 LinuxQuestions.org Members Choice Awards. Click here to go to the polls. Vote now and make sure your voice is heard!
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
By lukeprog at 2006-06-08 11:19
Version 2 (18/06/2006)
This tutorial assumes some basic Linux knowledge.
I wanted to ditch expensive, proprietary, vulnerable, resource-hogging Windows XP for Linux in my library system. After investigating dozens of distros, I found that openSUSE was best for my needs because it is free, easy to install, compatible with most hardware, and easy for patrons to use. Xandros OC3 was a good choice for lower-end machines; it runs fine on 450Mhz PCs.
I used the KDE Kiosk Tool to lock down the desktop environment for my "all" user account. However, I still needed a solution like DeepFreeze, which reverts a PC to a backup image of the disk upon reboot so that no changes made by the public will stick. I wanted to be able to tell location staff, "If something looks weird or isn't working, just reboot."
DeepFreeze is not available for Linux, but Linux has the tools to do that sort of thing built-in.
I tried using LiveCDs, which run a Linux OS completely off a CD (which is, of course, read-only). But I wanted more customization power than LiveCDs can offer. I tried mounting /home/all to a temporary filesystem (tmpfs) at boot, but that interfered with the KDE Kiosk Tool.
Finally, a more experienced friend helped me write some scripts that achieve a DeepFreeze-like effect for a single user account. This is actually better than DeepFreeze - assuming you don't give out your root account password! With DeepFreeze, you have to "thaw" a computer with the password, reboot, make changes, "freeze" the computer again, and reboot. With this Linux solution, you can just login as root, make changes, refresh the backup image, and log back in as "all" (or whatever account(s) you want the public to use).
Here are the basic steps:
1. Install your distro of choice and create the account(s) for public use.
2. Customize and lock down the public user account(s).
3. Write a script that creates the backup image(s) of the public user account(s).
4. Write a boot script that restores the backup image(s) of the public user account(s).
I'll assume you can handle (1) and (2). I recommend KDE and the KDE Kiosk Tool for easy interface lockdown. Now for the DeepFreeze-esque stuff:
Create a new text file on root's Desktop, make_backup.sh:
rm -f /root/Desktop/clean_all.tar
tar -cpPf /root/Desktop/clean_all.tar /home/all
Give root execute permissions for it and add it to $PATH if necessary (I prefer to just execute it directly by going to its directory and typing ./make_backup.sh).
This is a very simple bash script. The third line removes the backup image (clean_all.tar) if it exists, without prompting for confirmation. The fourth line creates a tarball of the all user account directory (/home/all), which contains personal files and settings for the all user account. We use a tarball because it preserves permissions. We could compress the tarball, too, but here I'm more concerned with restoring the user account from backup quickly every time the computer boots than I am with conserving disk space.
I've stored the backup image in /root/Desktop. It doesn't matter where you store the backup or the scripts, as long as it's not in the home directory of a non-root user account or a temporary directory.
We should only run this script when the all user account exists exactly as we want it. So we'll run it once when we've set up the public user account (I've named it all). Then, we only run it after we make wanted changes to the all user account and verify it is working.
The second script will restore the all user account from the backup we just created. I'll call it restore_backup.sh:
rm -fR /home/all
tar -xpPf /root/Desktop/clean_all.tar
Again, give root execute permissions for the file. This bash script removes the /home/all directory, which deletes all account files and settings without deleting the account. It then restores /home/all from the backup we created, preserving permissions. The tarball automatically unpacks to the directory from which it was created: /home/all.
Now we need to have the restore_backup.sh script run at boot. Linux boot scripts are located in the /etc/init.d directory. In openSUSE, I just made a copy of an existing script in /etc/init.d/rc3.d and cleared everything but the last line: rc_exit. In Xandros, the recommended boot script to modify for this sort of thing is bootmisc.sh.
Open the proper boot script for editing. First, we'll add a line so that we can easily enable or disable the code we're going to add. Near the top of the script, add the line
This creates a variable called RESTORE and gives it the value "yes". So if we don't want restore_backup to run on startup, we can simply change "yes" to "no". Now, add this code later in the boot script:
if [ "$RESTORE" == yes ]
If RESTORE is equal to "yes", the restore_backup.sh script will be executed at boot. Otherwise, it won't.
Save the file, reboot, and you're done! Naturally, if you want the backup tarball or scripts stored somewhere else or named something else, just modify the scripts to indicate the correct directories and filenames. The scripts can also be easily modified to accomodate backup and restore of multiple public user accounts.
Now I hope more experienced Linux users will provide feedback, corrections, suggestions for improvement or clarification, additions for getting this to work on other distributions, etc. Questions are also welcome!