This feature of the SLUG website is just getting started. We're not going to answer all the question you have (there's a whole internet out there; go look!) However, we can answer some of the more common questions, or direct you to where they are best answered:

Do you have other questions you'd like to see answered? Let us know. We can't guarantee we'll answer them, but you'll never know unless you ask!

Question

What is autofs/automount, and how do I make it work?

Answer

Normally in Linux, things like floppy disks, CD-ROMs and such have to be manually "mounted". This means that you associate a directory on your hard drive with that device, and you can then read and/or write to the device. (Note I did not say that you copy the contents to the directory; this isn't necessary, and it's not what you do.)

With automount/autofs, Linux does the mounting work for you. For instance, if properly configured, you can just pop a floppy in and read it, like in DOS or Windows.

The first step in using autofs is picking a directory to mount to. You could make a directory off of the root directory, called auto if you like. But more common practice is to find the /mnt directory and make a directory off of that. If you're mounting a floppy, it could be something like /mnt/floppy.

Here's a table of devices for a typical system:

Media Device Filesystem Mount Point
Hard Drive /dev/hda1 FAT32 /mnt/win
CD-ROM /dev/cdrom iso9660 /mnt/cdrom
Floppy /dev/fd0 EXT2 /mnt/floppy
Floppy /dev/fd0 FAT /mnt/dos

Notice how, for the single floppy drive, I have created two theoretical mount points. This is because I want to mount it differently based on whether it's a native floppy or a DOS floppy.

Okay, now comes the configuration files. The first is /etc/auto.master which describes which empty directory I am using, a pointer to the configuration file for that directory, and any options. In my case the only option is a timeout of 5 seconds: 

	/mnt /etc/auto.mnt --timeout 5

Here's how the timeout works: When I cd into /mnt/cdrom the system will check to see if something is mounted there. If not, autofs will take over and attempt a mount. If it failes, cd fails. If it is successful, cd is successful and the CD-ROM is mounted. Now, as long as I am in /mnt/cdrom somewhere the device is being used. Once I am done I can cd back out and autofs will wait 5 seconds to see if anything else needs to access the mount point before unmounting it.

With that said, here's the last configuration file, /etc/auto.mnt: 

	cdrom     -fstype=iso9660,rw    :/dev/cdrom
	floppy    -fstype=ext2,rw       :/dev/fd0
	dos       -fstype=msdos,rw      :/dev/fd0
	win       -fstype=vfat,rw       :/def/hda1

You can now enable autofs at boot time and things will be running great. As quickly as I've said that, though, you'll end up running into trouble. It's inescapable. Remember, you don't have to have support compiled in for all these filesystem types, but you should have them as loadable modules. Do, however, compile in all those codepage things in the filesystems area of the kernel config. You need two of them to be able to work with iso9660 and vfat, but I've forgotten which ones. ;)

If all of that still fails, go and edit your /etc/syslog.conf and add a line: 

	*.debug                      /var/log/debug

which autofs uses-- among other programs-- to output its debugging information. You can attempt to use autofs a few times, look in that file, and see what's going on. (Remember to delete this entry once you are done, though.) As root, just 

	killall -HUP syslogd
for the changes to take affect.

Well, that's about it. My primer on autofs based on my experiences. Hope this helps. :)

Paul Braman

Question

How do I get from the console to an X-Window session?
How do I get from an X-Window session to a console?

Answer

Assuming you have X-Window running....

When switching between text-mode consoles (VC or "virtual console"), you merely need to use the ALT modifier (ALT-F1 through ALT-F7).

While running an X server, you use the CTRL-ALT modifer to get out of X and back to a text-mode VC (CTRL-ALT-F1 through CTRL-ALT-F6). Also, CTRL-ALT-BACKSPACE will kill X altogether, and CTRL-ALT-KEYPAD+ and CTRL-ALT-KEYPAD- will switch between available resolutions.

Ian C. Blenke

Question

Can I get more consoles? How?

Answer

As XFree86 allocates your "last available VC", and VCs 1 through 6 are in use by most distributions, VC 7 is typically allocated by X when it starts (thus F7). If you start multiple X servers, each one will take a progressive VC (F8, F9, etc.)

Here are a few quick tricks that I've used for quite some time:

Trick #1:

One trick I find useful is to open up a master syslog on VC 12, and use ALT-F12 to get to it. I've been using it so long, it's the first thing I do to a Linux install when I'm finished. To do this, merely do this: 

	echo '*.*	/dev/tty12' >> /etc/syslog.conf

Or, add "*.*" followed by whitespace (tabs and spaces), followed by "/dev/tty12" to /etc/syslog.conf

If you start/stop syslog (or even, egads, reboot), you should have a VC #12 that keeps up with all of your latest syslog events. 

	/etc/rc.d/init.d/syslog stop
	/etc/rc.d/init.d/syslog start

or, for newer distributions with the improved SYSV init scripts: 

	/etc/rc.d/init.d/syslog restart

Also, on older distributions, VCs /dev's past tty8 are typically "missing". To create the /dev device files, do the following: 

	cd /dev
	./MAKEDEV tty12

If you wish, you can repeat this for any number of tty's. Take a look at the source to /dev/MAKEDEV - it's a wonderfully simple shell script.

Trick #2:

After you've created all of these extra VCs, wouldn't it be nice to actually use them? If you a CLI purist like me, occasionally the overhead of X really grinds on your nerves. Just because most distributions only offer VC logins from tty1 through tty6 doesn't mean you can't add a few more.

The key to adding more VCs is /etc/inittab. This is the config file for /sbin/init (pid #1!), so be very careful when editing this file, or you might accidentally render your machine either unusable or even unbootable. Caveat emptor! You have been warned!

Seriously, however, it really is quite safe and easy if you are careful. Typically, you will find the following VC handlers in /etc/inittab: 

	1:2345:respawn:/sbin/mingetty tty1
	2:2345:respawn:/sbin/mingetty tty2
	3:2345:respawn:/sbin/mingetty tty3
	4:2345:respawn:/sbin/mingetty tty4
	5:2345:respawn:/sbin/mingetty tty5
	6:2345:respawn:/sbin/mingetty tty6

To extend available consoles to tty7 (F7) through tty10 (F10), merely add the following lines to your inittab: 

	7:2345:respawn:/sbin/mingetty tty7
	8:2345:respawn:/sbin/mingetty tty8
	9:2345:respawn:/sbin/mingetty tty9
	10:2345:respawn:/sbin/mingetty tty10

Make sure that /dev/tty7 through /dev/tty10 exist (using the MAKEDEV fix above if they are missing), and you're almost there! If you signal to init to reread /etc/inittab (or, ack, even reboot), the changes will take effect and the logins will appear on those VCs: 

	/sbin/init q

This forces init to check /etc/inittab and make appropriate changes. WHATEVER YOU DO, DO NOT KILL PROCESS #1 DIRECTLY. :)

Tip: If you still decide to use X, you can still switch back, just remember your last assigned VC in /etc/inittab - and switch back to the NEXT VC. For example, if you have gettys running on tty1 through tty10, tty11 will be your X session and can be reached by using ALT-F11.

Trick #3:

The VCs don't end at F12. In fact, there are 63 available virtual consoles (no longer a compile time parameter like the older kernels used :) You can use F13 through F24 and still directly access them by using the right-ALT key modifier (RIGHTALT) instead of the left-ALT key along with one of the function keys! What would be F13 is now RIGHTALT-F1, and so on.

For example, add the following line to your inittab: 

	13:2345:respawn:/sbin/mingetty tty13

To switch to that VC, use RIGHTALT-F1. Neat stuff, that.

But the wonder doesn't stop there. You can cycle through VCs by using the arrow keys as well. Give ALT-LEFTARROW and ALT-RIGHTARROW a try at a textmode VC and you will walk back and forth along the available VC sessions.

Looking through the FAQs, it looks like they have all of this covered in the Keyboard-and-Console-HOWTO (check /usr/doc/HOWTO/Keyboard-and-Console-HOWTO). They give examples of how to implement truely dynamic gettys that preclude the use of inittab to statically spawn sessions that you may never use.

I hope that the above examples help some of the beginners give a few new things a try.

Ian C. Blenke

Question

How do I swap the Caps Lock and Control keys?

Answer

Note: this only works in the console, not in X Windows. First, understand that when init runs, it defines and loads the keyboard layout by looking in setup files or its own init scripts. Since init scripts vary from distribution to distribution, you'll have to do some detective work to find out how it works on your system.

Log in or su as root. (Otherwise you won't have access to the directories and files you need.)

For Red Hat systems, the keyboard layout files are in the /usr/lib/kbd/keymaps/i386/qwerty directory (assuming you're on a PC and using a standard keyboard). These are tarballs, which you will have to unzip, edit and rezip. To find which keymap is being used, look at the /etc/sysconfig/keyboard file. In it, you will see a line that looks like: 

KEYTABLE="us"

This tells you there is a file in /usr/lib/kbd/keymaps/i386/qwerty called us.kmap.gz. This is the file you have to edit. Do the following 

cd /usr/lib/kbd/keymaps/i386/qwerty
gunzip us.kmap.gz
vi us.kmap

(Use whatever editor you like.) Find the line that says something about keycode 29. It probably says "Control" in it. Change this to "CapsLock". Now find the line that says something about keycode 58. This probably says "CapsLock". Change that to "Control". Save the file.

Recompress the file: 

gzip us.kmap

At this point, you can reboot and the change will take effect. However, if you don't want to go that far, you can run the following command in every console where you want the change to take effect: 

loadkeys us

For SuSE 6.1 systems, the keymap files are in the same place, but editing that keymap may not do the trick. If it doesn't, look for a file named /usr/src/linux/drivers/char/defkeymap.map and edit that file as well.

Paul M. Foster

Question

How do I set up PPP on my computer? The other program I tried didn't work.

Answer

There are a myriad of programs out there to make ppp work on your system. The answer below is just one way.

PPP requires several things to work properly. Two of them are the programs pppd and chat. You can find out if you have these by running 

which pppd
which chat

If you get a response on both items, then the programs exist on your system. Most likely, they will be in the /usr/sbin directory.

First, you must create a script to get you online, which we'll call pon. The script may be anywhere in your path, but best location is probably /usr/local/bin. This will be the program you run to get you one the internet. The script should look something like this: 

#!/bin/sh
# This is a shell script to call Concentric (my isp).
# It requires some other files to work properly:
# /etc/ppp/peers/concentric
# /etc/ppp/options-concentric
# /etc/ppp/chat-concentric
# set up ppp connection in the background
/usr/sbin/pppd call concentric &
# tell the user when ppp is set up
echo Checking PPP connection...
while ! [ -e /var/run/ppp0.pid ]
do
sleep 1s
done
echo PPP connection is now set up!

Next you need an peer file. This one will be called /etc/ppp/peers/concentric. 

/dev/modem
57600
crtscts
lock
name "myloginname"
noipdefault
defaultroute
debug
noauth
connect '/usr/sbin/chat -v -f /etc/ppp/chat-concentric'
file /etc/ppp/options-concentric

Of course, you can see that you will have to edit this file to put your login name where "myloginname" is. If you want to enable dial on demand, you can insert the word demand anywhere above, and ppp will not start immediately when you call poff; instead, it will wait until you ping or try to surf before it actually starts.

Next you need a /etc/ppp/chat-concentric file. (Again, you can change the filename, so long as you make the change in the pon script as well.) 

TIMEOUT 60
ABORT "NO CARRIER"
ABORT BUSY
ABORT "NO DIALTONE"
ABORT ERROR
"" +++ATZ
OK ATDT5551212
CONNECT ""
You'll have to edit the phone number to match the dialup number of your ISP in the above file.

Next, you need a /etc/ppp/options-concentric file: 

/dev/modem
57600
crtscts
lock
name "myloginname"
noipdefault
defaultroute
debug
And you'll have to edit myloginname as before.

And you'll need a file called /etc/ppp/pap-secrets. This assumes that your ISP uses PAP authentication. 

myloginname	*	mypassword
You will need to edit the login name and password in this file.

Lastly, you need a file called poff. You run this program when you're done surfing or getting your email, and you want to log off. The script looks like this: 

#!/bin/sh
#
# terminate a ppp connection
#
if [ "$1" = "" ]; then
   DEVICE=ppp0
else
   DEVICE=$1
fi
if [ -r /var/run/$DEVICE.pid ]; then
   kill -INT `cat /var/run/$DEVICE.pid`
   if [ ! "$?" = "0" ]; then
      rm -f /var/run/$DEVICE.pid
      echo "ERROR: Removed stale pid file"
      exit 1
   fi
   echo "PPP link to $DEVICE terminated."
   exit 0
fi
#
# The ppp process is not running for ppp0
#
echo "ERROR: PPP link is not active on $DEVICE"
exit 1
That's about as simple as I can make it.

Paul M. Foster

Question

How do I set up RoadRunner?

Answer

There are various ways to do this. The following seems to be the most trouble-free. (Your machine will have to be running ipchains or ipfwadm, depending on your distribution, and a dhcp client, such as dhcpcd.

Step 1

Find your /etc/resolv.conf file, make sure you have the following line in it (assuming 24.92.0.68 is your nameserver; contact RoadRunner to find the exact address): 

  search tampabay.rr.com
  nameserver 24.92.0.68

Step 2

The following is a script you can run at boot time. Note that you will need to edit this script before using it. 

# change eth1 to be whatever your ethernet
# interface is...
# if you only have one ethernet card in the machine,
# it will probably be eth0
dhcpcd eth1
sleep 20
/sbin/ipfwadm -F -p deny
# the 192.168.1.0 is a mask for the local network
# change it to your local net quad
# and put a zero in the last section
/sbin/ipfwadm -F -a m -S 192.168.1.0/24 -D 0.0.0.0/0
If you have ipchains instead of ipfwadm, use the following instead of the ipfwadm commands above. Likewise, be sure to edit them for your particular local internet addresses. 
ipchains -F forward
ipchains -P forward DENY
ipchains -A forward -s 192.168.0.0/16 -j MASQ

Ed Centanni

Question

Can I set up a network where RoadRunner runs on one machine, but the other machines can access the internet through RoadRunner as well?

Answer

  1. Build yourself a machine with two NICs.
  2. Install Linux.
    • Configure one interface (eth0) with an internal "private" static IP (use something like 10.0.0.1, 172.16.0.1, 192.168.0.1, etc).
    • Configure the other interface (eth1) to use DHCP.
  3. Make sure you have ipfwadm or ipchains installed from your distribution.
    • ipfwadm for 2.0.x kernels
    • ipchains for 2.2.x kernels
  4. Build a kernel with IP Masquerading support (if your kernel doesn't already support it).
  5. Turn on your system's IP Forwarding at boot time.
    • Redhat servers: /etc/sysconfig/network - FORWARD_IPV4="yes"
    • others add: echo 1 > /proc/sys/net/ipv4/ip_forward
  6. Turn on masquerading.
    • ipchains (you only need one of the three MASQ lines below)
      • ipchains -F forward
      • ipchains -P forward DENY
      • ipchains -A forward -s 10.0.0.0/8 -j MASQ
      • ipchains -A forward -s 172.16.0.0/12 -j MASQ
      • ipchains -A forward -s 192.168.0.0/16 -j MASQ
    • ipfwadm (you only need one of the three masquerade lines below)
      • ipfwadm -F -p deny
      • ipfwadm -F -a masquerade -S 10.0.0.0/8 -D 0/0
      • ipfwadm -F -a masquerade -S 172.16.0.0/12 -D 0/0
      • ipfwadm -F -a masquerade -S 192.168.0.0/16 -D 0/0
    • Configure your other PCs with IP addresses.
      • On same subnet as the private (eth0) interface on your Linux server.
      • Pointing their default gateways at the Linux server.

Troubleshooting

  • If you can ping things on the 'net by IP but can't resolve:
    • Your DNS is broken. Work on /etc/resolv.conf and /etc/nsswitch.conf.
    • If your DNS is broken, your DHCP client is probably broken as well
  • If you can't ping things on the internet by IP address
    • Make sure your DHCP client is working right.
  • RedHat 5.x uses DHCPD
    • If you have a 2.2 kernel, you need DHCPD 1.3+
    • RedHat 6.0 uses PUMP.
    • Be sure to "update" your dist to the latest version of pump.
  • If you run a named (bind) server on your Linux server, you can point your other clients at it.
  • If you don't, merely point your client PCs at the roadrunner DNS server (seems typically to be 24.92.0.58, but you can use any DNS server on the internet).

Ian C. Blenke

Question

How do I print to a Windows printer from my Linux box?

Answer

In your /etc/printcap file, you'll need to ensure you have the following lines: 
remote|remote-smbprinter:\
  :lp=/dev/null:sh:\
  :sd=/var/spool/lpd/stcolor-letter-ascii-mono-360:\
  :if=/usr/local/samba/smbprint2:

The line that starts with :sd above is the spool directory for your particular printer. You will need to find that directory and substitute that for what is above.

You'll also notice the :if line above. This specifies an input filter file for your printer. Here you specify the file smbprint2. Below is that file (note: you may need to edit it): 

#!/bin/sh -x
# This script is an input filter for printcap printing
# on a unix machine. It uses the smbclient program to
# print the file to the specified smb-based server and
# service. For example you could have a printcap entry
# like this
#
# smb:lp=/dev/null:\
#     sd=/usr/spool/smb:\
#     sh:if=/usr/local/samba/smbprint
#
# which would create a unix printer called "smb" that
# will print via this script. You will need to create
# the spool directory /usr/spool/smb with
# appropriate permissions and ownerships for your system.
# Set these to the server and service you wish to print
# to. In this example I have a WfWg PC called "lapland"
# that has a printer exported called "printer" with no
# password.
#
# Script further altered by hamiltom@ecnz.co.nz
# (Michael Hamilton) so that the server, service, and
# password can be read from a
# /usr/var/spool/lpd/PRINTNAME/.config file.
#
# In order for this to work the /etc/printcap entry
# must include an
# accounting file (af=...):
#
#   cdcolour:\
#	:cm=CD IBM Colorjet on 6th:\
#	:sd=/var/spool/lpd/cdcolour:\
#	:af=/var/spool/lpd/cdcolour/acct:\
#	:if=/usr/local/etc/smbprint:\
#	:mx=0:\
#	:lp=/dev/null:
#
# The /usr/var/spool/lpd/PRINTNAME/.config file
# should contain:
#   server=PC_SERVER
#   service=PR_SHARENAME
#   password="password"
#
# E.g.
#   server=PAULS_PC
#   service=CJET_371
#   password=""
#
# Debugging log file, change to /dev/null if you like.
#
logfile=/tmp/smb-print.log
# logfile=/dev/null
#
# The last parameter to the filter is the accounting
#   file name.
#   Extract the directory name from the file name.
#   Concat this with /.config to get the config file.
#
eval acct_file=\${$#}
spool_dir=`dirname $acct_file`
config_file=$spool_dir/.config
# Should read the following variables set in the
# config file:
#   server
#   service
#   password
eval `cat `
#
# Some debugging help, change the >> to > if you
# want to save space.
#
echo "server $server, service $service" >> $logfile
#	smbprint $@
(
# NOTE You may wish to add the line `echo translate'
# if you want automatic CR/LF translation when
# printing.
#   echo translate
	echo 'print -'
	cat
) | /usr/bin/smbclient "\\$server\$service" \
$password -U $server -N -P >> $logfile

Ed Centanni

Question

What are the differences between Linux and DOS commands?

Answer

If you're familiar with DOS, it shouldn't take too long to become familiar with Linux. Many of the commands are the same or similar. Here's a table of commands that are correspond to each other in DOS and Linux:

DOS Version Linux Version Meaning
; : separate directories in path
/ - indicates command line parameters
\ / separates subdirectories in file names
| | send output of one command to input of another ("pipe")
%PATH% $PATH your path statement
attrib chmod change attributes (ownership) of a file
cd cd change directories
chdir chdir change directories
cls clear clear the screen
copy cp copy file(s)
date date change or show the date
del rm delete/remove a file
dir ls list the files in a directory
fc diff compare two files
find find find a file
md mkdir make a new directory
mkdir mkdir make a new directory
more more show a screenful at a time
rd rmdir remove a directory
rem # remark in a batch file (script)
ren mv rename a file
rmdir rmdir remove a directory
sort sort sort a file
set set show/change/create environment variables
type cat type a file to the screen

Obviously, a great many commands are similar. It should be noted, however, that the parameters for these commands and precisely how they behave may be slightly different in Linux than DOS. To find out more about any command, simply type man <command>.

Paul M. Foster

Question

I can't mount/copy files to my floppy unless I'm root. How do I get around this?

Answer

Take a look at your /etc/fstab file. Fstab stands for file system table and tells you what file systems are mountable or mounted on your system. This will include things like your various hard drive partitions, floppy drive, CD-ROM drive, Zip drive, etc. A typical entry for a floppy drive might look like this: 

/dev/fd0  /mnt/floppy  auto  noauto,user  0  0

You can do man 5 fstab to find out more about this file. Briefly, each of the items on this line is a field. The first field is the device itself (/dev/fd0). The second is the point where the system wants to mount it (/mnt/floppy). The third field is the type of filesystem. Your Linux hard drive is probably an EXT2 filesystem, while your CD-ROM is probably iso9660. You see auto for this field above, which means that it will be determined by the system before mounting. You could change this to msdos if you always use MSDOS floppies in your floppy drive.

The next field (noauto,user) is the options that will be used by the mount command to mount this filesystem. In this case, the first option is noauto. That means that if you want to mount this filesystem, you will have to tell the system to specifically mount it. You can't have it automatically mounted.

The next part of the mount options field is user. You probably don't see this in your /etc/fstab file. Adding this keyword to the file here tells mount that the average user can mount this filesystem. This is what you need to be able to mount your floppy as a regular user (as opposed to root).

The other fields in this line are not important here. You can issue a man 5 fstab to learn more about them.

If you have this user keyword in your mount options in the fstab entry for your floppy, then you can issue the command 

mount /mnt/floppy
and your floppy will mount in that directory. If you want to mount the floppy in some other directory, then the entry in the /etc/fstab file makes no difference, and you'll have to be root to mount the floppy.

If you (as a regular user) want to be able to write to the floppy, you can add another parameter to the mount parameters in /etc/fstab. That parameter would be umask=0. So the revised line might look like this: 

/dev/fd0  /mnt/floppy  auto  noauto,user,umask=0  0  0
Paul M. Foster

Question

What are links? And what's the difference between a hard link and a soft link?

Answer

Files are stored on a Linux disk in various places, and each has something called an inode number associated with it. It's like an address for that file. But Linux files don't actually have to have names at all. As long as you know a file's address (inode number) you can manipulate the file. As a matter of fact, because of this, if a program opens a file, you can generally rename the file while it's open, and the program will still be able to find it, because it uses the inode number of the file instead of the name.

A link is essentially a name associated with the file. In Linux, a file can have more than one name. Each name could be called a link.

A hard link is a file name that's attached to the file. The curious part about a hard link is that if you delete it, the file may still exist.

Remember before, I said a file may have many names under Linux. So let's say be have a file called config. Now, we can make several other hard links to the file, so that now we have not only config, but configuration, myconfig, theconfig and allconfig. All these names (or hard links) point to the same file. The thing that distiguishes hard links is that you would have to delete them all before your file would actually be gone.

Soft links are similar to hard links, except that when you delete them, the file still remains. Soft links are also known as symbolic links or symlinks.

You may ask yourself why anyone would want to have such a scheme with files that have multiple names. There are various reasons, but one of the main ones is this: Let's say that your word processor wants a certain configuration file in a certain directory. But let's say that the people who built your Linux distribution don't want to put that file there. No problem. The distribution makers can put it wherever they want, so long as there is a symlink to it in the spot where the word processor wants it. Symlinks are kind of like bread crumbs that show the way to your files, and Linux will follow them down until it finds the file you asked for.

Paul M. Foster

Question

My Linux system says I didn't mount my filesystem cleanly. What do I do?
What does this maximum mount count mean?

Answer

Linux is very sensitive to the condition of the files on its hard drives (filesystems). So it performs periodic checks on the filesystems to maintain their integrity. In order to do this, Linux keeps track of two things:

  • Whether the user shut down the machine properly.
  • How many times the machine has been shut down since the filesystems were last checked.

You've probably heard of caching before. This is where the most frequently used parts of the hard drive are stored in memory (which makes access time faster). This system works well, except that occasionally the system, for the sake of safety, must write what's in memory back to the hard drive. This is called flushing the cache. Linux will periodically do this. If given a chance, it will do this before you turn your machine off. If it doesn't get this chance, then all those changes you made to your spreadsheet don't get back onto the hard drive, for instance. And the next time you try to edit the spreadsheet, you'll have to do a lot of work over.

In addition to tracking the cache and flushing it periodically, when Linux starts up, it sets a flag on your hard drive that tells it whether Linux was properly shut down or not. If you shut down Linux properly, then it will reset this flag before it terminates, and all should be well. If you don't allow Linux to shut down properly, this flag never gets reset. The result is that the next time you start Linux, it knows you didn't halt Linux the right way, and it will perform lengthy checks on the filesystem to ensure it is still okay. This is sort of like a DOS chkdsk or a Windows scandisk.

Lastly, Linux keeps track of the length of time since a filesystem check was done, and how many times the system had been rebooted since the last filesystem check. If it's been too long since the last check, or the system has been rebooted more than a certain number of times, then the next time you reboot, Linux will also perform this filesystem check. In this case, you did nothing wrong. It's just that Linux wants to make sure everything is still alright.

Now, how do you shut your system off properly so Linux doesn't get too excited? First let me tell you how not to do it. Don't just turn your system off. This is guaranteed to cause the kind of problems mentioned above. There are actually quite a few correct ways to shut your system down. If you want to shut your computer down completely (not a reboot), then you can issue the following command: 

shutdown -h now

On the other hand, if you just want to reboot your system, you can issue this command: 

shutdown -r now

That's all there is to it.

Paul M. Foster

Question

How do init scripts work and what are they?

Answer

There are two prototypical approaches to startup scripts -- the BSD way and the System V way.

The BSD way has /etc/rc.local for starting up a bunch of daemons; originally it was supposed to be basically empty when the system was installed, and each site would add to it as needed. Eventually vendors started shipping their systems with rc.local full of stuff like sendmail and X. The BSD way was adopted by the Slackware Linux distribution (except I think they might put rc.local in /etc/rc.d/), and it is preferred (major understatement) by a lot of people who like its simplicity when adding new daemons. In my opinion those people don't understand the advantages of the other way....

The System V way, adopted in some form by most of the mainstream Linux distributions (except Slackware), starts with the concept of multiple runlevels, with different daemons running in different runlevels; e.g. runlevel 1 might be non-networked, runlevel 2 might be networked, and runlevel 3 might be networked and serving other machines. Runlevel 0 is shutdown, runlevel 6 is reboot, and runlevel "S" is single-user. When switching runlevels, the system must start or stop daemons as appropriate to the new runlevel; when moving from runlevel 3 to 2, you might want to stop the NFS daemons, and when moving in the opposite direction you want to start them.

The System V scheme involves directories init.d and rc[0-6S].d where "[0-6S]" is the letter S or any digit from 0 to 6. Traditionally these directories are in the /etc/ directory, but some Linux distributions put them under /etc/rc.d/, and some Unices put them under /sbin/. The init.d directory (NOT to be confused with inetd) is full of the actual scripts that are used to start and stop the daemons or subsystems. The scripts are called with either "start" or "stop" as arguments, to start or stop the daemon or subsystem associated with that script. Sometimes a script will also allow "restart" or even "status".

The rc[0-6S].d directories (rc0.d, rc1.d, rc2.d, rc3.d, and so on) are the ones actually used on bootup. They are full of links to the scripts in init.d. Each "active" link begins with either an S or a K (for start or kill), then a two-digit number (for ordering), then the name of the init.d script it's linked to (or a close variant of it). When going into a runlevel, first the K scripts are run with the "stop" argument, then the S scripts are run with the "start" argument. The best way to disable something in aparticular runlevel is to rename its link in that runlevel so that it doesn't start with a capital S. (The various Linux runlevel editors I've seen don't do that, so I don't use them.)

The downside of this scheme is complexity when adding a daemon or subsystem. You need to put a new script in init.d that understands both "start" (the easy one) and "stop" (the hard one). Often you can just adapt one of the existing scripts. Then you need to make the right links in the right rc[0-6S].d directories so that it is started and stopped at the appropriate times. For example: 

  cd /etc/rc.d/rc3.d
  ln -s ../init.d/sshd S75sshd
  cd ../rc0.d
  ln -s ../init.d/sshd K25sshd

You also need to look at the existing order to see what numbers would be most appropriate to use; you don't want sshd starting before networking is set up, but you probably want it before you start serving disks to other machines.

The major advantage of this scheme is that you only need to figure out how to stop something once (when you write the script), maybe less (if someone else wrote the script). After that, if you need to stop the sshd daemon, you just do "/etc/rc.d/init.d/sshd stop" or "/etc/init.d/sshd stop" (depending on where your distribution puts everything). To start it again, you do the same with "start" instead of "stop". This is incredibly useful, especially with more complicated subsystems like databases, or daemons with associated kernel modules. This scheme also makes life easier when dealing with daemons that must be restarted after changing their config files -- sendmail and inetd are biggies. Unfortunately inetd is often put in the same script as other network setup, making the script less useful.

Rob Funk

Member, Central Ohio Linux Users Group

Question

When I hit "Reply" to an email list I'm on, it replies to the person who wrote the email, not the list. How do I fix this?
On some email lists, I can't tell from the subject line that the mail is coming from a list. Is there any way to handle this?

Answer

The answer is a program called procmail which should be installed on your system and comes with all Linux distributions. Procmail is a program that diverts and pre-processes your mail for you. With procmail, you can automatically modify messages, forward email to someone else, or refile email in special folders.

Assuming procmail is installed and running on your system, you simply have to configure it to process your mail the way you want. There is one file in your home directory to edit: .procmailrc

Some preparatory remarks....

Emails consist of three basic things. First, there is the envelope. This is just like the envelope on a letter you mail at the post office. This is what actually tells mail transfer agents (MTAs) like sendmail where the email goes. And it is mostly out of your control, once your mail subsystem is configured and running. Second, there is a header, which usually consists of lines like "To: somebody@isp.com" and "From: somebody-else@another-isp.com". These are administrative pieces of information that tell you and your email programs things about the email and assist in routing it properly. After the header information, there is a blank line. This is what separates the header from the body of the email (i.e. your message text). Then after the blank line is the body of your email.

.procmailrc files contain "recipes", which tell procmail what kinds of mail you're looking for, and what to do with it when it sees them. A .procmailrc file may contain any number of recipes. When asked to handle incoming mail, procmail takes each message in turn and tests it against each of the recipes in the file in turn. If it finds a recipe that fits the email it's given, it will do some action, depending on what you tell it to do with that kind of email. Typically, if it finds a matching recipe, it will do the action and then move on to the next email, though there are ways around this. If no recipe matches the email, then it is simply delivered back to the main spool file for you to look at in your email client.

Also note that the .procmailrc file can contain comments. These are indicated by a hash mark (#) at the beginning of the line.

Here are some variables you should place in the beginning of your .procmailrc. The first is where your email is ultimately going to end up (the directory where you store your mail folders): 

MAILDIR=$HOME/Mail

This is where your email originally comes in to: 

DEFAULT=/var/spool/mail/$LOGNAME

If you want to log what procmail is doing, you should include the following variables. But beware, this log is very extensive. 

LOGFILE=$HOME/procmail.log
VERBOSE=yes

Procmail uses what are called "recipes". Basically, you tell procmail to "grep" your email, looking for certain patterns, and then you tell procmail what to do with the mail if it matches the pattern you set.

A typical procmail "recipe" would look like this: 

:0:
* ^To: slug@nks\.net
slugmail
The first line uses ":0" to indicate that this is the start of a recipe. The trailing colon (:) indicates we want procmail to use a local lockfile while processing this recipe. The reason for this is to ensure we have exclusive rights to modify the "slugmail" file, in case some other process may be trying to access the file at the same time.

The second line is the "grep" line that tells procmail what to look for. Grep lines start with a star/asterisk (*). The caret (^) indicates to procmail that the pattern starts at the beginning of a line. In this case, we're looking for a line that starts with "To: ". The "To" in this case is "slug@nks.net". Note that before the last dot/period, we put a backslash (\). Since this is a grep expression, the dot normally equates to any character. But that's not what we want. We want the actual dot. So we have to "escape" it by putting the backslash in front of it. That way, procmail's grep looks for a literal dot.

The last line of the recipe is a mail folder called "slugmail". It's a mail folder because it isn't preceded by anything, just the name. When procmail processes this, it will actuall expand it to: $MAILDIR/slugmail. So this will be an email folder in your private mail subdirectory.

In summary, this recipe takes any mail that has a "To" of slug@nks.net, and files it in a folder called "slugmail" in your private email subdirectory.

Before we go further, I should mention something that will be important later on. Procmail has two kinds of recipes: delivering and non-delivering. Delivering recipes either write the email to a file, forward the email to another address, or pipe the email through another program. Non-delivering recipes are ones that feed the email back through procmail (as in filters) , start a nesting block (start with a { and end with a }; see below), or use the "c" flag to carbon copy an email.

Now, here's another recipe. In this one, the postgresql list email doesn't have a consistent "Reply-To", so when you hit "Reply" it often goes back to the person who sent the email, not back to the list. This is a quirk of the way some lists are set up. (This is not a bad thing necessarily, and there are heated arguments over this point.) We want to insert a "Reply-To" in the email so that replies go back to the list, not the sender. 

:0 w
* ^Sender: pgsql-general-owner@postgresql\.org
| formail -i "Reply-To: pgsql-general@postgresql.org" >> $DEFAULT
In this recipe, notice first that in the first line, there is no colon, meaning no lockfile is needed. This is because we're piping our mail through the formail program, so there's no need to issue a lockfile. There is also a flag, "w", indicates that we want procmail to wait until formail is finished before continuing. The reason for this is that if procmail feeds a large email through procmail and then continues, procmail may be in the middle of dumping the next email into your files at the same time that formail is doing the same thing. The results could be unpleasant, as both processes access the spool file at the same time.

The grep line looks for a header line that starts with "Sender: " and is addressed to the postgresql list.

The "action" line does several things. First, the bar (|) at the beginning tells procmail that we're going to feed this email through another program, in this case the formail program. Formail is a program that's part of the procmail suite of programs. It is capable of rewriting parts of your mail. In this case, we give formail the -i parameter along with the "Reply-To" we want. Formail will insert this "Reply-To" header line into the email and then pass it on. Using the -i flag means that formail will add this reply-to. If we wanted to replace any reply-to's already in the file, we would use the -I flag. The "greater-than" symbols (>>) and $DEFAULT variable tell formail to send the result of its output back to the main spool file.

Here's a similar recipe, except that we're looking for a different header line. In this case, the one line that's common to all mail coming from this list is an "X-BeenThere" line. When dealing with lists, how the headers are set up can vary considerably. That's why, if you're going to filter list email, you've got to check and see exactly what header lines are common to the emails before you start filtering things. 

:0 w
* ^X-BeenThere: openacct@linuxports\.com
| formail -i "Reply-To: openacct@linuxports.com" >> $DEFAULT

Here's a slightly different recipe. In this one, we have two grep lines. The first is like the others; we're looking for a "Delivered-To" line. The second is a "Subject:" line, but in this case, it has an odd "\/.*" construction after it. In this case, we're not really grepping for the subject line, though if the email doesn't have a subject line, this recipe will fail (and procmail will look for the next thing that might match). The "big caret" (\/) tells procmail to save everything beyond it into a variable called "MATCH". In our case, "everything beyond it" is any number of characters (the grep expression .*). So here, we want to save everything beyond "Subject:" on the subject line to the MATCH variable.

The action line is where we use the MATCH variable. In this case, we are piping the mail through formail, as before, but this time, we give it an "-I" parameter. This means that we want to replace the header line with one of our own creation. Here, we're going to replace the original "Subject:" with "Subject: ", the string [LYX] and the contents of the MATCH variable (which is the actual subject of the email). So what we're really doing is inserting the string [LYX] before the actual subject text on the subject line. And of course, as before we're sending it back to the main spoolfile.

The reason to have a recipe like this is because in some cases, list traffic contains nothing in the subject line to indicate it came from this or that list. It could be from anywhere. In some cases, list processing software will put some indicator on the subject line to indicate that the email came from this list. This is called "subject munging", and many people disagree with this practice. The advantage to subject munging is that you can see at a glance what email comes from what list. If your list host doesn't munge the subject for you, then this recipe will act as a substitute. It will munge the subject to include the email's origin. 

:0 w
* ^Delivered-To: mailing list lyx-users@lists\.lyx\.org
* ^Subject:\/.*
| formail -I "Subject: [LYX]$MATCH" >> $DEFAULT

Here is a "compound" recipe, meaning that it does more than one thing with the incoming email.

In this case, we're looking for "New Member Surveys". The open brace ({) says that we're going to do more than one thing with this email. Inside the braces, there are two more recipes, this time with no grep lines. You can omit a grep line with any recipe, in which case it will act on all email sent to it. Here, we have already grepped the header, so we don't need to do that again with the "sub-recipes".

The first sub-recipe just copies the email to a file in our personal mail directory called "newmembers". That's what the "c" flag makes procmail do. We're using the colon (:) here, because we need a local lockfile in order to safely deliver to a local mail folder. Note that this is a non-delivery recipe, meaning that the email continues on through procmail until it gets to a delivery recipe. The second sub-recipe pipes the email through a program called "newmember.pl", which does a variety of other things which aren't important here. After all that, we see the close brace (}), which signifies the end of the recipe. Since procmail piped the email through this newmember program, and since it can't keep track of what happens after that, it assumes that the email has been "delivered". Thus this last recipe is a delivery recipe. 

:0 w
* ^Subject: New Member Survey
{
	:0 c:
	newmembers

	:0
	| $HOME/bin/newmember.pl
}

This recipe looks for email traffic from a certain address, and forwards that email on to another address, and you never see the email. The bang (!) in the action line does this. That address does not have to be on your network. The email is passed off to your local mail transport agent (maybe sendmail), which then determines what to do with it. Note that we do not have the "w" flag here, because procmail doesn't need to wait for anything. 

:0
* ^To: staff@quillandmouse\.com
! nancyf@quillandmouse.com

Last is a slightly more complicated one. We're looking for email from the procmail list, and we're saving off the text of the "Subject" line. We're going to munge the subject by adding "[PROCMAIL]" to the subject line, and we're going to add a "Reply-To" header line. We do this with one formail command by giving it two separate sets of parameters. In the first one, we use an "I" parameter, which says to rewrite that header field and discard the original one. The second set uses the "i" parameter, which doesn't tell procmail to discard any original "Reply-To" fields, but simply to add a new one. 

:0 w
* ^Sender: procmail-admin@lists\.rwth-aachen\.de
* ^Subject:\/.*
| formail -I "Subject: [PROCMAIL]$MATCH" \
-i "Reply-To: procmail@informatik.rwth-aachen.de ">> $DEFAULT

Paul M. Foster

Question

I keep getting all these duplicate emails. While I'm getting the problem fixed, is there a way to turn them off?

Answer

According to man procmailex, you may use the following recipe at the beginning of your ~/.procmailrc file to kill duplicates: 

:0 Wh: msgid.lock
| formail -D 8192 msgid.cache

This creates an 8K cache of message IDs, and checks them each time procmail is run (every message). It kills duplicate messages. If you are paranoid and want to take a look at all the dupes just to make sure, change the above to two recipes, like this: 

:0 Whc: msgid.lock
| formail -D 8192 msgid.cache
:0 a:
duplicates

Paul M. Foster

Question

How do I get my IDE/ATAPI tape drive working?

Answer

Ide ATAPI tape drives work with Linux using scsi-emulation -- forget about using the ide-tape module. Most kernels out of the box do not have scsi-emulation set up since it conflicts with other tape drive support. You have to configure and compile a kernel with a particular group of seemingly un-related things turned on and others turned off. It does work and work well *IF* you get it right.

Thanks to a posting by Timothy Moore (timothymoore@bigfoot.com) that was discovered and brought to my attention by Bob Snibbe and whose web link got permanently lost in my vast underground caverns, I present to you my abbreviated version of Tim's ATAPI tape drive howto:

  1. Kernel configuration: Under BLOCK DEVICES select SCSI emulation support( if you manually edit .config or check it after configuration it will be called CONFIG_BLK_DEV_IDESCSI). Under SCSI support (yes I know it's NOT a SCSI device! The kernel will see it as one though) select SCSI tape support (CONFIG_SCSI, CONFIG_CHR_DEV_ST) and deselect IDE/ATAPI tape support(CONFIG_BLK_DEV_IDETAPE).
  2. 2. rebuild kernel, install, lilo etc....
  3. 3. If successful you'll see at boot up something like: 
    kernel: hdb:  YADA YADA ATAPI Tape drive
...
kernel: SCSI host adapter emulation for IDE ATAPI devices
...
kernel: Detected scsi tape st0 at scsi1, channel 0, id0 lun 0.
    You'll use /dev/st0? and /dev/nst0? . Most people link /dev/tape to the device (ln -s /dev/st0 /dev/tape)
  4. To test, put a tape in and type 
    mt -f /dev/tape status
    or use the tar command save and read back a small file.
  5. To save a file: 
    tar cvf /dev/st0 myfile
  6. To read it back: 
    tar tvf /dev/st0

Ed Centanni

Question

How do I set the time on my computer?

Answer

There are two kinds of time to deal with. First is the system time, second is the CMOS time. The system time is the time that Linux keeps in its memory as it's running. The CMOS time is the time kept by your CMOS (backed up by its battery, and running even when your computer is powered off). You can set the system time, but the next time your computer powers off, the system time will revert to whatever your CMOS says. So in order to make everything work together, you need to set both the system time and the CMOS time.

One additional factor is important-- what you use as a reference for time. The best way to do this is to find an ntp (Network Time Protocol) server on the internet. There are many many of them. You can search for "ntp server" on Google, or go to www.eecis.udel.edu/~mills/ntp/servers.htm for a write-up. Choose a server in your time zone from the list.

Let's assume your time server is tock.usno.navy.mil. Having chosen your time server, issue the following at the command line: 

ntpdate tock.usno.navy.mil

This will set your system clock to the time signal broadcast by this ntp server. Next, you want to ensure your CMOS clock matches your system time. Do this like this: 

hwclock --systohc

Remember, this is a one-time solution. You could set up a cron job to do this periodically, but there is a better way if you're going to do this frequently. That way is to use an ntp daemon. To make this work, you need to set up a config file called /etc/ntp.conf. In it, you would put something like this: 

server tock.usno.navy.mil
driftfile /etc/ntp.drift

Once you've done this, run the ntpd or xntpd command on your system. This will set up the daemon to periodically check and set the time on your system.

To check your system date, you can issue the date command. To see your CMOS time, issue hwclock --show

There is much more to know about this. See man rdate, man ntpd, man ntpdate and/or man xntpd.

Paul M. Foster

Question

What's the deal with IRQ/DMA/IO Addresses?

Answer

IRQs and I/O Addresses, etc. First, get little booklet called "Pocket PCRef". This has everything you ever wanted to know about PC hardware. Standard pinouts for things, ASCII charts, IRQ lists, lists of old DOS commands, specs for every hard drive known to Man, phone numbers for manufacturers, etc. Cost is about $20, I believe, and it fits in a shirt pocket (smaller than a paperback novel).

Now, IRQs. The AT-class PC has two interrupt controllers, chained to each other. Each controls 8 interrupts for a total of 16. (Yes, it's woefully inadequate, which is why we have USB and such now.) A list is below: 

IRQ	Function
0	timer interrupt
1	keyboard interrupt
2	chained to second interrupt controller
        (can be used, but beware)
3	interrupt for second serial port
        (COM2 under DOS, /dev/ttyS1 under Linux)
4	interrupt for first serial port
        (COM1 under DOS, /dev/ttyS0 under Linux)
5	interrupt for second parallel port
        (usually isn't one, so free)
6	floppy disk controller interrupt
7	interrupt for first parallel port
        (LPT1 in DOS)
8	real time clock interrupt
9	chained to first interrupt controller
10	free
11	free
12	free
13	math coprocessor interrupt
        (dunno if used on Pentium class)
14	hard drive controller (IDE)
15	hard drive controller (IDE)

The "free" interrupts above (and IRQ 5) are only "free" if something else isn't using them. Sound cards use interrupts, video controllers use interrupts, NIC cards use interrupts, etc. PnP is designed to circumvent some of this, but IMHO, it sucks badly. With NICs, I _always_ buy NICs that have a setup program that allows me to _set_ the IRQ the way I want, usually IRQ 5.

I/O addresses are another story, and there are one or more for each interrupt used. These are particular areas of memory used to transfer bytes directly back and forth from hardware devices, without a lot of CPU overhead. These are more variable than IRQs, but typically for the more used IRQs, the addresses are: 

IRQ	I/O Address
3	0x2f8-0x2ff
4	0x3f8-0x3ff
5	0x278-0x27f
7	0x378-0x37f
Likewise DMA channels, though there are far fewer of them and not all devices use them. In general, the floppy disk controller typically uses DMA channel 2.

Paul M. Foster

Question

What's the difference between the nice value and the priority value in the top program? When I change the nice value to X to reduce the impact of a process on system performance, the priority goes up to X as well. Should I change the priority to a lesser value or should it do it on its own when I increase the nice value?

Answer

This is a function of the scheduler.

The process priority is dynamic and constantly changing. The nice value of a process is generally static, although you can "renice" a running process as often as you wish.

The lower the priority of a process, the more likely it is to be run.

The nice value is added to the priority of a process to adjust its importance. A positive nice value will make a process less important. A negative nice value will make a process more important.

The nice value is just a basis for the priority. The scheduler changes the priority of a process while it is running. If a process is resource intensive, its priority will drop in the scheduler (the priority number will grow as it is penalized for using resources) to allow other processes with lower priority to run.

Think of the nice value as a "priority baseline". As a process gets more time to run, its priority number will grow to the point where it exceeds the priority of other jobs on the system with lower priorities. Once the lower priority processes have had their chance.

Process priority is based on a number of factors aside from simple aging, however. CPU use, memory use, IO wait time, and dozens of other factors go in to recomputing the constantly changing priorities of processes on your system. This is what the scheduler does. Changing the behavior of the scheduler can change the entire "feel" of your computer (making it more/less interactive, or running long-running compute jobs more/less efficiently).

Giving a positive nice value will penalize a process so that it will always schedule last after everything else has a chance to run.

Giving a negative nice value will give a process preference over other running processes on the system. The more negative the nice value, the less likely other jobs will be given a chance to run.

To answer your question though, yes the system should update the priority to start at the niceness value you set. In fact, it should generally never drop below the nice value - at least with the current scheduler, AFAIK.

- Ian C. Blenke

Question

What's a "super block"? How do you fix it with fsck? Can you?

Answer

The Superblock contains the size, shape, version, and state of the filesystem. Things like block size, first inode, blocks per group, free blocks, free inodes, mount count, maximum mount count, last time mounted, last time written to, and flags that show the state of the filesystem (ie, clean unmount) are stored on the superblock.

When you create an ext2 filesystem many "alternate superblocks" are stored as backups in case the primary superblock is lost, overwritten, corrupt, or otherwise unusable. Usually, only the main Superblock in block group 0 is read when you mount an ext2 filesystem.

For example, everyone can try this one without hurting anything to see these superblocks being written: 

	$ dd if=/dev/zero of=foo.img bs=1M count=500
	$ mke2fs foo.img
	mke2fs 1.18, 11-Nov-1999 for EXT2 FS 0.5b, 95/08/09
	foo.img is not a block special device.
	Proceed anyway? (y,n) y
	Filesystem label=
	OS type: Linux
	Block size=1024 (log=0)
	Fragment size=1024 (log=0)
	128016 inodes, 512000 blocks
	25600 blocks (5.00%) reserved for the super user
	First data block=1
	63 block groups
	8192 blocks per group, 8192 fragments per group
	2032 inodes per group
	Superblock backups stored on blocks:
	8193, 24577, 40961, 57345, 73729, 204801, 221185, 401409
	Writing inode tables: done
	Writing superblocks and filesystem accounting information: done

Those comma separated numbers are the alternate superblocks.

To repair a Unix filesystem, you use "fsck" (FileSystem ChecK). Each type of filesystem (ext2, reiserfs, xfs, etc) have their own independant runtimes that check that specific type of filesystem (fsck itself is not all-knowing). As fsck calls these executables after it identifies what type of filesystem it is (either via /etc/fstab, by the "-t" command line option, or by checking the magic identifier stored in the filesystem), there is a naming convention: "fsck.{filesystem type}", ie: "fsck.ext2", "fsck.xfs", etc. You will find these in /sbin/fsck*

If the primary superblock is lost, fsck.ext2 (aka e2fsck) should be able to read one of the backup superblocks to restore the filesystem.

To try this, do: 

	# losetup /dev/loop0 foo.img
	# dd if=/dev/zero of=/dev/loop0 size=1024 count=2
	# mount -t ext2 /dev/loop0 /mnt
	mount: wrong fs type, bad option, bad superblock on
	/dev/loop0,or too many mounted file systems

oops! :) This is the error you are seeing. Now we will fix it: 

	# fsck.ext2 -f -y /dev/loop0
	Parallelizing fsck version 1.18 (11-Nov-1999)
	e2fsck 1.18, 11-Nov-1999 for EXT2 FS 0.5b, 95/08/09
	Couldn't find ext2 superblock, trying backup blocks...
	Pass 1: Checking inodes, blocks, and sizes
	Pass 2: Checking directory structure
	Pass 3: Checking directory connectivity
	Pass 4: Checking reference counts
	Pass 5: Checking group summary information
	/dev/loop0: ***** FILE SYSTEM WAS MODIFIED *****
	/dev/loop0: 11/128016 files (0.0% non-contiguous),
	16169/512000 blocks

Note the "Couldn't find ext2 superblock, trying backup blocks".

If fsck.ext2 can't automagically find the backup blocks, you can implicitly tell it to use an alternate backup block: 

	# fsck -b 8193 -f -y /dev/loop0

You can find "ESL" (Ext2 Superblock Locator) on the 'net as well, should you not know what alternative superblock backups were used by your filesystem (it looks for the ext2 superblock magic on every block on a selected partition).

(fsck.ext2 needs a block device to check, thus the need for losetup of /dev/loop0.. you can't "fsck foo.img", which is rather irritating. I'd much rather use "mount -o loop foo.img /mnt")

Ian C. Blenke

Question

How do I turn off screen blanking at the console?

Answer

Some people are annoyed by the fact that Linux blanks the console after a certain time by default. You can fix this by issuing this command: 

setterm -blank 0
You can, of course, change the 0 on the end to something else. It is the interval, in minutes (up to 60) after which the console will blank.

Paul M. Foster

Question

Where's that dang IPTABLES script by Derek I keep hearing about?

Answer

Here the famous iptables script created by Derek Glidden. Substitute the appropriate values with your own in the top of the files. I've made some documentation changes for clarity. 

#!/bin/sh
# Change these to suit your installation
INTERNAL_NET="192.168.1.0/24"
INTERNAL_IFACE="eth1"
EXTERNAL_IFACE="eth0"
## Disable routing while we update tables
echo 0 > /proc/sys/net/ipv4/ip_forward
## Insert connection-tracking modules
## (not needed if built into kernel).
modprobe ip_conntrack
modprobe ip_conntrack_ftp
modprobe ip_nat_ftp
## Flush all existing rules
iptables -F
iptables -X
iptables -t nat -F
iptables -t nat -X
## Set up IP Masquerading for internal network
iptables -t nat -A POSTROUTING -o $EXTERNAL_IFACE -s \
$INTERNAL_NET -j MASQUERADE
## Set up FORWARD rules for internal network
## Allow related connections, new connections from
## the inside network, drop everything else
iptables -A FORWARD -m state --state RELATED,ESTABLISHED \
      -j ACCEPT
iptables -A FORWARD -i $INTERNAL_IFACE -m state \
     --state NEW -j LOG --log-level info \
     --log-prefix "NEW FORWARD: "
iptables -A FORWARD -i $INTERNAL_IFACE -s $INTERNAL_NET \
     -j ACCEPT
iptables -A FORWARD -j LOG --log-level info \
     --log-prefix "DROP FORWARD: "
iptables -A FORWARD -j DROP
## Set up INPUT rules to allow traffic directly to the box
## Only allow SSH from the outside world
## Allow anything from the internal network
iptables -A INPUT -m state --state ESTABLISHED,RELATED \
      -j ACCEPT
iptables -A INPUT -i $EXTERNAL_IFACE -p tcp --dport 22 \
-m state --state NEW -j LOG \
      --log-level info --log-prefix "NEW SSH INPUT: "
iptables -A INPUT -i $EXTERNAL_IFACE -p tcp \
      --dport 22 -j ACCEPT
iptables -A INPUT -i $INTERNAL_IFACE -s $INTERNAL_NET \
      -j LOG --log-level info --log-prefix "NEW INPUT: "
iptables -A INPUT -i $INTERNAL_IFACE -s $INTERNAL_NET \
      -j ACCEPT
iptables -A INPUT -j LOG --log-level info \
      --log-prefix "DROP INPUT: "
iptables -A INPUT -j DROP
## Log new "OUPUT" connections to keep an eye
## on what our firewall is up to
iptables -A OUTPUT -m state --state ESTABLISHED,RELATED \
      -j ACCEPT
iptables -A OUTPUT -m state --state NEW -j LOG \
     --log-level info --log-prefix "NEW OUTPUT: "
iptables -A OUTPUT -m state --state NEW -j ACCEPT
## Re-enable routing now we're done changing things
echo 1 > /proc/sys/net/ipv4/ip_forward

Paul M. Foster (script is Derek's)