CD Actual 13/CDA13.ISO/DOC/HOWTO/OTHER_FO/SGML/TIPS_HOW.GZ/Tips-HOWTO.sgml

SGML Document | 1996-08-18 | 17.1 KB | 439 lines

<!doctype linuxdoc system>

<article>

<title>The Linux Tips HOWTO
<author>Paul Anderson, <tt/[e-mail]/
<date>v2.0, August 1996
<abstract>
This HOWTO contains those hard to find hints and tweekings that make Linux
a bit nicer.
</abstract>

<toc>

<sect>Introduction
<p>
Welcome to the <bf/Linux Tips HOWTO/, a list of neato tricks and optimizations that make Linux more fun.  All I have in here right now are tips off of the top of my head, and tips from the old Tips-HOWTO(Why take out decent tips, right?).  So send all your favorite hints and tips to me so I can put them in the next Tips-HOWTO.

Paul Anderson <em/Maintainer--Linux TIPS HOWTO/

<tt/[e-mail]/
<sect> Short Tips

<sect1> Handy Syslog Trick <it/Paul Anderson, Tips-HOWTO maintainer/

<p>
Edit your /etc/syslog.conf, and put in the following line:
<tscreen><verb>
# Dump everything on tty8
*.*                    /dev/tty8
</verb></tscreen>
One caveat: <it/REMEMBER TO USE TABS!/  syslog doesn't like spaces...

<sect1> Moving directories between filesystems. <it/Alan Cox,/
<tt/[e-mail]/

<p>
Quick way to move an entire tree of files from one disk to another
<tscreen><verb>
(cd /source/directory && tar cf - . ) | (cd /dest/directory && tar xvfp -)
</verb></tscreen>
<it>[ Change from cd /source/directory; tar....etc.  to prevent possibility of trashing directory in case of disaster.  Thanks to Jim Dennis, [e-mail], for letting me know. -Maint. ]</it>

<sect1> Finding out which directories are the largest. <it/Mick Ghazey,/
<tt/[e-mail]/

<p>
Ever wondered which directories are the biggest on your computer?  Here's how to find out.
<tscreen><verb>
du -S | sort -n
</verb></tscreen>

<sect1> The Linux Gazette

<p>
Kudos go to John Fisk, creator of the Linux Gazette.  This is an excellent
e-zine plus, it's <bf/FREE!!!/  Now what more could you ask?  Check it out at:
<tscreen><verb>
http://www.redhat.com/lg
</verb></tscreen>
While you're there, drop John Fisk a note telling him how wonderful an e-zine LG is.

<sect1> Pointer to patch for GNU Make 3.70 to change VPATH behavior.
<it/Ted Stern,/ <tt/[e-mail]/

<p>
I don't know if many people have this problem, but there is a "feature" of GNU
make version 3.70 that I don't like. It is that VPATH acts funny if you give it
an absolute pathname.  There is an extremely solid patch that fixes this, which
you can get from Paul D. Smith <tt><[e-mail]></tt>.  He also posts the
documentation and patch after every revision of GNU make on the newsgroup
`gnu.utils.bug` Generally, I apply this patch and recompile gmake on every
system I have access to.

<sect1> How do I stop my system from fscking on each reboot? <it/Dale Lutz,/
<tt/[e-mail]/

<p>
Q:  How do I stop e2fsck from checking my disk every time I boot up.

A:  When you rebuild the kernel, the filesystem is marked as 'dirty' and
    so your disk will be checked with each boot.  The fix is to run:

        rdev -R /zImage 1

    This fixes the kernel so that it is no longer convinced that the
    filesystem is dirty.

<em/Note: If using lilo, then add /<tt/read-only/ <em>to your linux setup in your lilo config file (Usually /etc/lilo.conf) </em>

<sect1>How to avoid fscks caused by "device busy" at reboot time.
<it/Jon Tombs,/ <tt/[e-mail]/

<p>
If you often get device busy errors on shutdown that leave the filesystem in
need of an fsck upon reboot, here is a simple fix:

To <tt>/etc/brc</tt> or <tt>/sbin/brc</tt>, add the line
<tscreen><verb>
mount -o remount,ro /mount.dir
</verb></tscreen>
for all your mounted filesystems except /, before the call to umount -a. This
means if, for some reason, shutdown fails to kill all processes and umount the
disks they will still be clean on reboot. Saves a lot of time at reboot for
me



<sect1>How to find the biggest files on your hard-drive.
<p><it/Simon Amor,/ <tt/[e-mail]/
<p>
<tscreen><verb>
ls -l | sort +4n
</verb></tscreen>
<p>
Or, for those of you really scrunched for space this takes awhile but works
great:
<p>
<tscreen><verb>
cd /
ls -lR | sort +4n
</verb></tscreen>

<sect1>How to print pages with a margin for hole punching. <it/Mike Dickey,/
<tt/[e-mail]/

<p>
<tscreen><code>
        #!/bin/sh
        # /usr/local/bin/print
        # a simple formatted printout, to enable someone to
        # 3-hole punch the output and put it in a binder

        cat $1 | pr -t -o 5 -w 85 | lpr
</code></tscreen>

<sect1>A way to search through trees of files for a particular regular expression.
<it/Raul Deluth Miller,/ <tt/[e-mail]/

<p>
I call this script 'forall'.  Use it like this:
<tscreen><verb>
forall /usr/include grep -i ioctl
forall /usr/man grep ioctl
</verb></tscreen>
Here's forall:
<tscreen><code>
#!/bin/sh
if [ 1 = `expr 2 \> $#` ]
then
        echo Usage: $0 dir cmd [optargs]
        exit 1
fi
dir=$1
shift
find $dir -type f -print | xargs "$@"
</code></tscreen>

<sect1>A script for cleaning up after programs that creat autosave and backup files.
<it/Barry Tolnas,/ <tt/[e-mail]/
<p>
Here is a simple two-liner which recursively descends a
directory hierarchy removing emacs auto-save (~) and backup (#) files, .o
files, and  TeX .log files. It also compresses .tex files and
README files. I call it 'squeeze' on my system.
<tscreen><code>
#!/bin/sh
#SQUEEZE removes unnecessary files and compresses .tex and README files
#By Barry tolnas, [e-mail]
#
echo squeezing $PWD
find  $PWD \( -name \*~ -or -name \*.o -or -name \*.log -or -name \*\#\) -exec
rm -f {} \;
find $PWD \( -name \*.tex -or -name \*README\* -or -name \*readme\* \) -exec gzip -9 {} \;
</code></tscreen>

<sect1>How to find out what process is eating the most memory. <it/Simon Amor,/
<tt/[e-mail]/
<p>
<tscreen><verb>
ps -aux | sort +4n
</verb></tscreen>
-OR-
<tscreen><verb>
ps -aux | sort +5n
</verb></tscreen>

<sect> Detailed Tips

<sect1>Sharing swap partitions between Linux and Windows. <it/Tony Acero,/
<tt/[e-mail]/

<p><enum>
<item> Format the partition as a dos partition, and create the Windows
swap file on it, but don't run windows yet. (You want to keep the swap
file completely empty for now, so that it compresses well).

<item> Boot linux and save the partition into a file.  For example if the partition was /dev/hda8:
<tscreen><verb>
dd if=/dev/hda8 of=/etc/dosswap
</verb></tscreen>
<item> Compress the dosswap file; since it is virtually all 0's it will compress very well
<tscreen><verb>
gzip -9 /etc/dosswap
</verb></tscreen>
<item> Add the following to the /etc/rc file to prepare and install the swap space under Linux:

<em/XXXXX is the number of blocks in the swap partition/
<tscreen><verb>
mkswap /dev/hda8 XXXXX
swapon -av
</verb></tscreen>
Make sure you add an entry for the swap partition in your /etc/fstab file

<item> If your init/reboot package supports /etc/brc or /sbin/brc add the
following to /etc/brc, else do this by hand when you want to boot to
dos|os/2 and you want to convert the swap partition back to the
dos/windows version:
</enum>
<tscreen><verb>
swapoff -av
zcat /etc/dosswap.gz | dd of=/dev/hda8 bs=1k count=100
</verb></tscreen>
# Note that this only writes the first 100 blocks back to the partition. I've found empirically that this is sufficient

>
>  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 :-)

<sect1>How to use the immutable flag.
<it/Jim Dennis,/ <tt/[e-mail]/

<p>
                Use 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.

<sect1>A suggestion for where to put new stuff.
<it/Jim Dennis,/ <tt/[e-mail]/

<p>
        All 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.

<sect1>Some tips for new sysadmins.
<it/Jim Dennis,/ <tt/[e-mail]/

<p>
        Create and maintain a /README.`hostname` and/or a
        /etc/README.`hostname`
<em>[Or possibly /usr/local/etc/README.`hostname` -Maint. ]</em>

        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:
<tscreen><verb>
                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 -
</verb></tscreen>

        (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:
<tscreen><verb>
                cp $data $some_users_home/tmp
                su -c $origcommand $whatever_switches
                cp $some_users_home/tmp $data
</verb></tscreen>
        (...where the specifics depend on the command).

        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).


<sect1>How to configure xdm's chooser for host selection.
<it/Arrigo Triulzi,/ <tt/[e-mail]/

<p><enum>
<item> Edit the file that launches xdm
most likely /etc/rc/rc.6 or /etc/rc.local) so that it contains the
following lines in the xdm startup section.<tscreen><verb>
/usr/bin/X11/xdm
exec /usr/bin/X11/X -indirect hostname
</verb></tscreen>
<item> Edit /usr/lib/X11/xdm/Xservers and comment out the line which
starts the server on the local machine [i.e. starting 0:]

<item> Reboot the machine and you're home and away.
</enum>
<p>
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 <bf/NOT/ work for later releases.
</article>