Uncompress repairlix-<date>.iso.gz:
bash$ gzip -d repairlix-<date>.iso.gz |
Using your favorite CD-burning program, burn repairlix-<date>.iso to recordable CD media. With cdrecord this could be as simple as
bash$ cdrecord repairlix-<date>.iso |
First download and unpack the sources.
bash$ tar xvfz repairlix-<date>.tar.gz bash$ cd repairlix |
Read the Kernel Appendix and follow the instructions for providing a kernel and modules to Repairlix. You must provide a kernel to build from source; Repairlix does not come with one, and it will not attempt to find one on your hard drive.
As root, or better, as a user with the proper permissions, type
bash$ make |
Repairlix will attempt to find programs on your hard drive as it's creating the disk. Most of these programs come with every standard distribution. If you're missing one of them, Repairlix will issue a warning and keep going. You then have 3 options: (1) find the program on the 'Net and install it (optionally from the Repairlix iso image itself); (2) ignore the warning (this might result in a useless disk being produced, but only if the system you're using to build it is missing crucial programs like 'init', 'bash', etc.) (3) edit the shell script in question and remove the offending app from the list.
The output of make is the file repairlix.iso. This file can be burned following the From an ISO instructions.
Tip: Make sure vi is not a symlink to vim. Vim is way too big to fit in the base filesystem.
Tip: It's best not to make any changes to the initrd, as it contains only what's crucial to boot into the base filesystem. It also contains the only copy of libc.
There are several compelling reasons to build Repairlix as a non-root user:
If you're modifying it, and you make a mistake, you could accidentally do drastic things to your real filesystem. Things that Repairlix may not be able to fix. :-) Running as a normal user makes it impossible to do much damage to your real filesystem.
If we, the developers, make a mistake in the shell scripts, we could do drastic things to your real filesystem. This is slightly less likely-- you may be certain that we're testing this on our own machines before we let it get out to yours--but it's still something to be aware of with any software product.
Generally speaking, the less time you can spend as root, the better for the security and integrity of your system.
It's worth noting that these reasons apply to running any software as root, not just building Repairlix.
In the course of developing the non-root system, I was almost convinced it couldn't be done without so much work that you might as well just go ahead and be root. But finally I narrowed down the set of commands, even removing or changing some commands from the shell scripts that required root and turned out to be unnecessary.
All right then, how? Repairlix uses a few commands which require root access:
mount
umount
chown
syslinux
There is also one file that is normally not writable to normal users: /dev/ram1. Because this is such a short list, sudo lends itself very well as a solution to the problem.
First, install sudo (). Once sudo is installed, follow the following procedure to give access to mount:
Select a user to have this permission. Not just anyone - pick a user you trust, such as one only the root user has the password for. For the purposes of this explanation, I'll assume you picked jessica.
| Warning |
Treat this account as if it were root with regard to who gets access to it, because even this short list of commands can trivially be used to get root access. The reason we do any of this is primarily for protecting system INTEGRITY, not SECURITY. |
As root, add the following to /etc/sudoers:
# create a group of commands called 'RLX' Cmnd_Alias RLX=/bin/mount,/bin/umount,/bin/chown,/usr/bin/syslinux # Give the user jessica access to the RLX command group. The NOPASSWD # option is required so that make can run mount non-interactively jessica ALL=NOPASSWD: RLX |
Uncomment the line
# export RLX_SUDO=/usr/bin/sudo |
# export RLX_SUDO= export RLX_SUDO=/usr/bin/sudo |
Normally the /dev/ram* devices are in the disk group. You should add jessica to the disk group by doing:
bash# gpasswd -a jessica disk |
bash# addgroup rlx bash# chgrp rlx /dev/ram1 bash# gpasswd -a jessica rlx |
That's it. User jessica will now be able to use mount and build Repairlix.
Repairlix has additional protection built in. All commands that use sudo are self-checking to make sure they are not accessing the real root filesystem. If a script determines that a line uses sudo and makes changes to a real filesystem instead of a Repairlix filesystem, it won't run. The self-checking is smart enough to be effective at catching the most common mistakes. In short, a lot of effort has been spent making sure Repairlix is as safe as possible when you're building it.
It wouldn't do to put out a repair disk that toasted peoples' computers, now would it?