Local "howto" information

Home : Linux resources : "Howto"

This page contains "howto" information for random bits of hardware and software. Some of it is general, but much is very specific to my configuration, so it may break for yours; use caution when trying any of this stuff.

Table of contents

Related pages:

Contents of this page:

  1. Local "howto" information
    1. Table of contents
      1. Terminology
    2. Networking
      1. Ethernet
      2. General IP networking
      3. DNS tricks using perl
    3. Linux guts
      1. Server logs
      2. Memory management
      3. rpm
    4. Hardware
      1. Zip drive
      2. Floppy disk


In what follows, I've tried to use the following words consistently:



See my Ethernet Cheat Sheet for Ethernet pinouts and wire color code conventions. (This is on a page of its own for easy printing.)

General IP networking

DNS tricks using perl

Reverse DNS in perl:

    rgr> perl -e 'use Socket; $iaddr = inet_aton(""); print join(" ", gethostbyaddr($iaddr, AF_INET)), "\n";'
    darwin.bu.edu  2 4 \200\3056^T
Reverse DNS from a shell (using perl to trim just the host name out of the nslookup output):
    % nslookup -q=PTR | perl -ne 'print "$1\n" if /in-addr.arpa\s+name = (.*)$/;'

Linux guts

Server logs

[this does not cover the "modern" logrotate package. -- rgr, 7-Jul-13.] [or systemd-logger. -- rgr, 7-Feb-21.]

The various servers I run keep their log files in the following places:

What Where
dhcpd Uses syslog (/var/log/messages).
ntpd Writes to /var/log/ntp via syslog in the default configuration, but this is controlled by the "logfile" directive in /etc/ntpd.conf. (The default tarball installation uses /var/log/messages).
Apache Under openSUSE, the Apache log files are under /var/log/apache2. These are called access_log and error_log. If you run an HTTPS server, there will also be an ssl_request_log file. [The current log files are sometimes dated; I'm not sure why this happens. -- rgr, 7-Feb-21.]
Subversion Subversion runs within Apache, so will need to look in your Apache logs (particularly ssl_request_log).

Memory management

Doing "cat /proc/meminfo" generates a report of current usage. See "man vmstat" for a tool to keep an eye on memory usage.


rpm -ivh *.rpm
Query a single package
rpm -qi tripwire
List package files
rpm -ql tripwire
Recently installed packages
rpm -qa --last | head


Yes, this is about hardware that is pretty thorougly obsolete, but all the more reason to keep the "how-to" information around, in case some day I find old media lying around that I really, really want to read. Use a large grain of salt when trying these recipes out, since I haven't tested them in a while.

See also the Burning DVDs and CDs page (which is about hardware that is not so obsolete).

Zip drive

Use "mount /mnt/zip". If this fails with an error message that looks like this
       mount: the kernel does not recognize /dev/sda4 as a block device
              (maybe `insmod driver'?)
then this is probably because the machine was booted with the Zip drive off. If that's the case, then
       modprobe imm
will probably be sufficient to get /dev/sda4 recognized, after which the drive can be power cycled without needing to repeat the modprobe. (The boot-time modprobe is done in the
/etc/rc.d/rc.modules script. -- rgr, 28-Dec-99.)

If /var/log/messages says

       modprobe: can't locate module block-major-8
and lsmod shows imm already loaded, then do
       rmmod imm; modprobe imm
to force reloading. -- rgr, 2-Jul-00.

"umount /mnt/zip", and then hit the button to eject. Doing "eject /mnt/zip" seems to work, but only for root.
mke2fs /dev/sda4

You can add the "-c" option to check for bad blocks, but I haven't found a bad block yet, and this is what takes most of the time (about 4.5 minutes), as it has to read the entire drive. (My guess is that bad blocks are detected and "repaired" by the drive, so it's no surprise that I never found one. -- rgr, 7-Aug-01.)

Checking for bad blocks:
When doing badblocks on Zip, use 98288 for number of blocks -- this is (- (/ (* 2048 96) 2) 16), for 96 cyl, 2048 blocks/cyl, 0.5k/block, minus some magic factor. If there is some reason to suspect the existence of a bad block, one can also use the "-c" option to e2fsck when checking disk integrity (but see the comment under "Formatting" above).
Checking file system integrity:
Periodically, when mounting Zip disks, the following warning will appear in /var/log/messages:
       EXT2-fs warning: maximal mount count reached, running e2fsck is recommended
To address this, before mounting the disk, do
       e2fsck -f /dev/sda4
The "-f" option will "Force checking even if the file system seems clean" (from the man page); without it, e2fsck does a quick check, so "-f" is more thorough. You can also add the "-c" option to request bad block checking (but see the comment under "Formatting" above).
To erase a Zip disk thoroughly (or any other disk device or partition for that matter), you can do a "write" test to check for bad blocks:
       badblocks -w /dev/sda4 98288

This takes a while, as it writes a number of patterns across the whole disk, and then rereads them. Each read/write pass takes about nine minutes; the whole process is more than half an hour.

[Note that the shred program does this exactly this job, but more thorougly. -- rgr, 7-Feb-21.]

Note the existence of the mzip command.

[The "Zip drive backup" section that was here has been renamed and given its own page. -- rgr, 7-Aug-01.]

Floppy disk

For a 1.44MB floppy, use:
       fdformat /dev/fd0H1440
Other densities use different magical device names.
Building an ext2 file system:
mkfs.ext2 -c /dev/fd0H1440
Making a boot image:
dd if=/mnt/cdrom/images/boot.img of=/dev/fd0 bs=1440k

Bob Rogers <rogers@rgrjr.dyndns.org>