Linux has proven itself to be extremely reliable during the over four years I have had it in service as an Internet server and requires very little hands-on administration to keep it running. Where possible, many repetitive or tedious administrative tasks can and should be automated through crontab entries and script files. However, to ensure that Linux continues to operate in a trouble-free manner, various quick checks can be done from time to time. These include:
It is important to check from time to time that adequate free space remains on the storage devices. Use the “df” command to get a report of available space. It will look as follows (information shown is from the Internet server at my place of employment):
Filesystem 1024-blocks Used Available Capacity Mounted on /dev/sda1 1888052 135908 1654551 8% / /dev/sdd1 4299828 100084 3977246 2% /archive /dev/hda2 3048303 897858 1992794 31% /archive2 /dev/hda1 11677 1380 9694 12% /boot /dev/sdc1 4299828 350310 3727020 9% /home /dev/sdb1 4299828 598504 3478826 15% /usr /dev/sda2 1888083 700414 1090075 39% /var /dev/scd0 593958 593958 0 100% /cdrom |
These file-systems are pretty stable in that they have a fairly slow growth pattern.
The “/” (aka root) file-system, mounted on /dev/hda1, contains the Linux kernel, device drivers, and other directories. It also is where user mail messages are stored (/var/spool/mail/) as well as log files (/var/adm/) but as mail messages are received and log files are recycled, the available capacity stays fairly stable (an estimated growth of about 1% per month). Log files are rotated and purged automatically on a weekly basis, so you'll always have about a month's worth of log information available to you.
Tip: If this file-system is growing rapidly, concentrate your efforts in the /var/spool/mail directory -- look for huge mailboxes (something like ``find /var/spool/mail -size +1000k'' would display a list of mailboxes larger than 1Mb in size). If you find a file much larger than 1,000,000 bytes in size, the user probably isn't retrieving their mail, is on a high-volume mailing list, or their e-mail package isn't configured to remove the mail from the server. Contact the user and/or clear the mail file, using “> mailbox”, (eg. ``>smithj'' to clear Joe Smith's mail box). Also check the ``/tmp/'' directory, which may need to be cleaned out on an occasional basis (usually old tin* files left over from aborted newsreader sessions, old print files, etc). |
The “/usr/” (aka user) file-system, mounted on /dev/hda2, contains user-installable (user meaning user-installed by system administrator) software, things like your web site pages, etc. This is the largest file-system, and is also fairly slow-growth. The log files for the web pages may also be stored here, and grow in size; check and trim them periodically as needed. On my machines, at the beginning of each month the current web log files are moved to month summary logs (eg. access_log.11 for November's log entries). At the end of the year these logs are all deleted and the cycle starts again (which means each January 1st should see a fair improvement in available space).
Tip: If this file-system is growing rapidly, check the ``/usr/local/etc/httpd/logs'' and the ``/usr/local/squid/logs/'' directories (if you have them). There may be log file(s) that are getting too large (if, perhaps, the web site received a high number of visits). If, however, the logs are purged automatically on a regular basis as I have them, you shouldn't run into any problems with space here (indeed, as the logs are used for statistical analysis of my site's traffic I'd rather not have to delete them if possible). Another place to check for potentially deletable files is in ``/usr/tmp/''. |
The “/home/” (aka user's personal home) file-system, mounted on /dev/hda3, contains all the user directories and personal files. Unless you are giving out shell accounts, most of these will be useless and inaccessible to the user (these directories are created when each users' accounts are created, and can later be used to forward the user's mail, etc.). However shell account users, as well as any non-shell accounts which have web pages (eg. personal web pages) will probably have them stored here. In addition, main server pages are stored here in the /home/httpd directory under Red Hat, while other distributions usually place them in the /usr file system (see the section called Web Server and HTTP Caching Proxy Administration in Chapter 7 for more information).
This file-system is probably the slowest growth unless you are offering a lot of shell accounts.
Tip: If this file-system suddenly grows in size, it is probably because one of your users is adding web pages or binary files in his/her personal space. Check the ``/var/adm/xferlog.*'' log files for recent activity, which should show you which user has added to their web pages. |
I also have an “/archive/” (aka archive files) file-system, mounted on /dev/hdb1, which is a spare 1.02 Gb hard drive that can be used for any purpose (eg. data files, software kits, etc.) I am using a good portion (approximately 70%) of this drive for disk-to-disk full current backups of the system). Generally speaking you can add your own devices and mount them as you wish.
I also have a CD-ROM drive, mounted as “/mnt/cdrom/” on /dev/scd0, which is a 24X-speed SCSI CD-ROM device that can read any ISO9660 formatted CD. It is used primarily for software installation, but DOS/Windows CD's can be mounted and then accessed from Windows 3.x/95/NT network shares as needed via a Samba service (see the section called Windows-style File and Print Services with Samba in Chapter 7 for details).
The “rm” command will delete a file. Usage is ``rm filename''. If you want confirmation of deletion, use the “-i” option (eg. ``rm -i *''). You would then be asked to confirm each file before it is deleted.
(Note: This is the default for normal shell users, but beware -- the root account will not confirm before deleting files unless you specify the “-i” option!) |
Be careful you don't make a silly typo with this command -- particularly when logged in as “root” -- because you may end up regretting deleting the wrong file.