ace3@midway.uchicago.edu
dd if=/dev/hda8 of=/etc/dosswap
gzip -9 /etc/dosswap
mkswap /dev/hda8 XXXXX
swapon -av
swapoff -av
zcat /etc/dosswap.gz | dd of=/dev/hda8 bs=1k count=100
>> What are the pros and cons of doing this?
Pros: you save a substantial amount of disk space.
Cons: if step 5 is not automatic, you have to remember to do it by hand, and it slows the reboot process by a nanosecond :-)
jadestar@rahul.netUse the Immutable Flag
Right after you install and configure your system go through the /bin, /sbin/, /usr/bin, /usr/sbin and /usr/lib (and a few of the other usual suspects and make liberal use of the 'chattr +i command'. Also add that to the the kernel files in root. Now 'mkdir /etc/.dist/' copy everything from /etc/ on down (I do this in two steps using /tmp/etcdist.tar to avoid recursion) into that directory. (Optionally you can just create /etc/.dist.tar.gz) -- and mark that as immutable.
The reason for all of this is to limit the damage that you can do when logged in as root. You won't overwrite files with a stray redirection operator, and you won't make the system unusable with a stray space in an 'rm -fr' command (you might still do alot of damage to your data -- but your libs and bins will be safer.
This also makes a variety of security and denial of service exploits either impossible or more difficult (since many of them rely on overwriting a file through the actions of some SUID program that *isn't providing an arbitrary shell command*).
The only inconvenience of this is when building and doing your 'make install' on various sorts of system binaries. On the other hand it also prevents the 'make install' from over-writing the files. When you forget to read the Makefile and chattr -i the files that are to be overwritten (and the directories to which you want to add files) -- the make fails, you just use the chattr command and rerun it. You can also take that opportunity to move your old bin's, libs, or whatever into a .old/ directory or rename or tar them or whatever.
jadestar@rahul.netAll new stuff starts under /usr/local! or /usr/local/`hostname`
If your distribution is one that leaves /usr/local empty then just create your /usr/local/src, /usr/local/bin etc and use that. If your distribution puts things in the /usr/local tree than you may want to 'mkdir /usr/local/`hostname`' and give the 'wheel' group +w to it (I also make it SUID and SGID to insure that each member of the wheel group can only mess with their own files thereunder, and that all files created will belong to the 'wheel' group.
Now discipline yourself to *ALWAYS! ALWAYS! ALWAYS!* put new packages under /usr/local/src/.from/$WHEREVER_I_GOT_IT/ (for the .tar or whatever files) and build them under /usr/local/src (or .../$HOSTNAME/src). Make sure that it installs under the local hierarchy. If it *absolutely must* be installed back in /bin or /usr/bin or somewhere else -- put a symlink from the local heirarchy to each element that when anywhere else.
The reason for this -- even though it's more work -- is that it helps isolate what has to be backed up and restored or reinstalled in the event of a full re-install from the distribution medio (usually CD these days). By using a /usr/local/.from directory you also keep an informal log of where your sources are coming from -- which helps when you're looking for new updates -- and may be critical when monitoring the security announcement lists.
One of my systems at home (the one I'm calling from) was put together before I adopted these policies for myself. I still don't "know" all the ways that it differs from the stock "as installed" system. This is despite the fact that I've done very little with my home system's configuration and I'm the *only* person who ever uses it.
By contrast the systems I've set up at work (when I was thrust into the role of system administrator there) have all been configured this way -- have been administered by many contractors and other MIS people, and have had a large number of upgrades and package installations. Nonetheless I have a very good idea which precise elements were put in *after* the initial installation and configuration. distribution medio (usually CD these days). By using a /usr/local/.from directory you also keep an informal log of where your sources are coming from -- which helps when you're looking for new updates -- and may be critical when monitoring the security announcement lists.
One of my systems at home (the one I'm calling from) was put together before I adopted these policies for myself. I still don't "know" all the ways that it differs from the stock "as installed" system. This is despite the fact that I've done very little with my home system's configuration and I'm the *only* person who ever uses it.
By contrast the systems I've set up at work (when I was thrust into the role of system administrator there) have all been configured this way -- have been administered by many contractors and other MIS people, and have had a large number of upgrades and package installations. Nonetheless I have a very good idea which precise elements were put in *after* the initial installation and configuration.
jadestar@rahul.netCreate and maintain a /README.`hostname` and/or a
/etc/README.`hostname`
Absolutely, from *day one* of administering a system take notes in an online log file. You might make \vi /README.$(hostname)\ a line in root's /bash_logout. Another way to do this is to write an su or a sudo script that does something like:
function exit \
{ unset exit; exit; \
cat ~/tmp/session.$(date +%y%m%d) \
>> /README.$(hostname) && \
vi /README.$(hostname)
}
script -a ~/tmp/session.$(date +%y%m%d)
/bin/su.org -
(use the typescript command to create a session log and create a function to automate appending and updating the log).
I'll admit that I haven't implemented this automation of policy -- I've just relied on self-discipline so far. However I have been toying with the idea (even to the point of prototyping the scripts and shell functions as you see them). One thing that holds me back on this is the 'script' command itself. I think I'll have to grab the sources and add a couple of command line parameters (to pause/stop the script recording from the command line) before I commit to using this).
My last suggestion (for this round):
Root's path should consist of 'PATH= /bin'
That's it. Nothing else on root's path. Everything root does is provided by a symlink from /bin or by an alias or shell function, or is a script or binary in /bin, or is typed out with an explicit path.
This makes anyone running as root aware (sometimes painfully so) of how he or she is trusting binaries. The wise admin of a multi-user host will periodically look through his or here /bin and /.*history files to look for patterns and loopholes.
The really motivated admin will spot sequences that can be automated, places where sanity checks can be inserted, and tasks for which 'root' privileges should be temporarily eschewed (launching editors, MTA's and other large interactive programs with elaborate scripting features that *might* be embedded in transparent or data files -- like the infamous vi ./.exrc and emacs ./.emacs and the even more insidous $EXINIT and the embedded header/footer macros). Naturally those sorts of commands can be run with something like:
cp $data $some_users_home/tmp
su -c $origcommand $whatever_switches
cp $some_users_home/tmp $data
Mostly these last sorts of precautions are overboard for the home or "single" user workstation -- but they are very good policy the admin of a multi-user -- particular a publicly exposed system (like the one's at netcom).
a.triulzi@ic.ac.uk
/usr/bin/X11/xdm
exec /usr/bin/X11/X -indirect hostname
I add this because when I was, desperately, trying to set it up for my own subnet over here it took me about a week to suss out all the problems.
Caveat: with old SLS (1.1.1) for some reason you can leave a -nodaemon after the xdm line -- this does NOT work for later releases.