Monday, August 17, 2009

processe in Linux

Background Process
Unlike with a foreground process, the shell does not have to waitfor a background process to end before it can run more processes.Within the limit of the amount of memory available, you can enter manybackground commands one after another. To run a command as a backgroundprocess, type the command and add a space and an ampersand to the endof the command. For example:
$ command1 &
Immediately after entering the above command, the shell willexecute the command. While that is running in the background, the shellprompt (% for the C Shell, and $ for the Bourne Shell and the KornShell) will return.
Sponsored Links
Linux Development ToolsEmbedded Linux development tools on the web for your
Run Visio on LinuxNo Windows OS license required. Try free trial of CrossOver Linux!
AIX,SUN,Linux,Useful LinkCollection of unix documents listed based on flavours of unix.www.FantasticUnix.comAt this point, you can enter another command for eitherforeground or background process. Background jobs are run at a lowerpriority to the foreground jobs.
You will see a message on the screen when a background process is finished running.
Foreground Process Work
A foreground process is different from a background process in two ways:
1. Some foreground processes show the user an interface, through which the user can interact with the program.2. The user must wait for one foreground process to complete before running another one.
To start a foreground process, enter a command at the prompt, e.g.,
$ command1
The next prompt will not appear until command1 finishes running.Definition: child process: A process createdby another process (the parent process). Each process may create manychild processes but will have only one parent process, except for thevery first process which has no parent. The first process, called initin Linux, is started by the kernel at boot time and never terminates.From Linux Guide @FirstLinuxDefinition: process (process ID, PID): Allsoftware runs within an operating system concept known as a process.Each program running on a system is assigned its own process ID (PID).Users can easily obtain a process list (using Task Manager on Windowsor ps on UNIX) in order to see what is running. Key point: Trojans,rootkits, and other evil software will attempt to hide themselves fromthe process list, either by providing replacements to the programs thatlist processes (like ps), or by hooking the system calls that enumerateprocesses.Acrontabfile contains instructions to thecron(8)daemon of the general form: ``run this command at this time on this date''.Each user has their own crontab, and commands in any given crontab will beexecuted as the user who owns the crontab. Uucp and News will usually havetheir own crontabs, eliminating the need for explicitly runningsu(1)as part of a cron command.
Blank lines and leading spaces and tabs are ignored. Lines whose firstnon-space character is a pound-sign (#) are comments, and are ignored.Note that comments are not allowed on the same line as cron commands, sincethey will be taken to be part of the command. Similarly, comments are notallowed on the same line as environment variable settings.
An active line in a crontab will be either an environment setting or a croncommand. An environment setting is of the form,
name = value
where the spaces around the equal-sign (=) are optional, and any subsequentnon-leading spaces invaluewill be part of the value assigned toname.Thevaluestring may be placed in quotes (single or double, but matching) to preserveleading or trailing blanks.
Several environment variables are set upautomatically by thecron(8)daemon.SHELL is set to /bin/sh, and LOGNAME and HOME are set from the /etc/passwd line of the crontab's owner.HOME and SHELL may be overridden by settings in the crontab; LOGNAME may not.
(Another note: the LOGNAME variable is sometimes called USER on BSD systems...on these systems, USER will be set also.)
In addition to LOGNAME, HOME, and SHELL,cron(8)will look at MAILTO if it has any reason to send mail as a result of runningcommands in ``this'' crontab. If MAILTO is defined (and non-empty), mail issent to the user so named. If MAILTO is defined but empty (MAILTO=""), nomail will be sent. Otherwise mail is sent to the owner of the crontab. Thisoption is useful if you decide on /bin/mail instead of /usr/lib/sendmail asyour mailer when you install cron -- /bin/mail doesn't do aliasing, and UUCPusually doesn't read its mail.
The format of a cron command is very much the V7 standard, with a number ofupward-compatible extensions. Each line has five time and date fields,followed by a user name if this is the system crontab file,followed by a command. Commands are executed bycron(8)when the minute, hour, and month of year fields match the current time,andwhen at least one of the two day fields (day of month, or day of week)match the current time (see ``Note'' below).Note that this means that non-existant times, such as "missing hours"during daylight savings conversion, will never match, causing jobsscheduled during the "missing times" not to be run. Similarly, timesthat occur more than once (again, during daylight savings conversion)will cause matching jobs to be run twice.
cron(8)examines cron entries once every minute.
The time and date fields are:
field allowed values----- --------------minute 0-59hour 0-23day of month 1-31month 1-12 (or names, see below)day of week 0-7 (0 or 7 is Sun, or use names)
A field may be an asterisk (*), which always stands for ``first-last''.
Ranges of numbers are allowed. Ranges are two numbers separatedwith a hyphen. The specified range is inclusive. For example,8-11 for an ``hours'' entry specifies execution at hours 8, 9, 10and 11.
Lists are allowed. A list is a set of numbers (or ranges)separated by commas. Examples: ``1,2,5,9'', ``0-4,8-12''.
Step values can be used in conjunction with ranges. Followinga range with ``/'' specifies skips of the number's valuethrough the range. For example, ``0-23/2'' can be used in the hoursfield to specify command execution every other hour (the alternativein the V7 standard is ``0,2,4,6,8,10,12,14,16,18,20,22''). Steps arealso permitted after an asterisk, so if you want to say ``every twohours'', just use ``*/2''.
Names can also be used for the ``month'' and ``day of week''fields. Use the first three letters of the particularday or month (case doesn't matter). Ranges orlists of names are not allowed.
The ``sixth'' field (the rest of the line) specifies the command to berun.The entire command portion of the line, up to a newline or %character, will be executed by /bin/sh or by the shellspecified in the SHELL variable of the cronfile.Percent-signs (%) in the command, unless escaped with backslash(\), will be changed into newline characters, and all dataafter the first % will be sent to the command as standardinput.
Note: The day of a command's execution can be specified by twofields --- day of month, and day of week. If both fields arerestricted (ie, aren't *), the command will be run wheneitherfield matches the current time. For example,``30 4 1,15 * 5''would cause a command to be run at 4:30 am on the 1st and 15th of eachmonth, plus every Friday.
EXAMPLE CRON FILE# use /bin/sh to run commands, no matter what /etc/passwd saysSHELL=/bin/sh# mail any output to `paul', no matter whose crontab this isMAILTO=paul## run five minutes after midnight, every day5 0 * * * $HOME/bin/daily.job >> $HOME/tmp/out 2>&1# run at 2:15pm on the first of every month -- output mailed to paul15 14 1 * * $HOME/bin/monthly# run at 10 pm on weekdays, annoy Joe0 22 * * 1-5 mail -s "It's 10pm" joe%Joe,%%Where are your kids?%23 0-23/2 * * * echo "run 23 minutes after midn, 2am, 4am ..., everyday"5 4 * * sun echo "run at 5 after 4 every sunday"

shell commands..

The C shell provides the following built-in commands:
Marks a command.
Displays alias.
Resumes job in the background.
Resumes execution after the loop.
Breaks from a switch command; resumes after the endsw command.
Defines a label in a switch command.
Changes directory.
Changes directory, same as cd.
Continues a loop.
Specifies the default case in a switch.
Displays the directory stack.
Writes arguments to the standard output of the shell.
Evaluates a command.
Executes the command in the current shell.
Exits the shell.
Brings a job in the foreground.
Specifies a looping control statement and execute a sequence of commands until reaching an end command.
Writes arguments to the standard output of the shell, like the echo command, but without the new line.
Continues execution after the specified label.
Displays hash table statistics.
Displays the history list.
Executes a command if condition met.
Lists active jobs.
Sends a signal to a process. term (terminate) is the default signal.
Sets or list system resource limits.
Logs on.
Logs out.
Changes the priority of commands run in the shell.
Ignores the hangup signal.
Notifies the user about changes in job status.
Tells the shell what to do on interrupt.
Pops the top directory off the directory stack and changes to the new top directory.
Exchanges the top two elements of the directory stack.
Re-computes the hash table of the contents of the directories in the path shell variable.
Repeats the execution of a command.
Displays or set the value of a shell variable.
Sets environment variables.
Shifts shell arguments.
Reads commands from a script.
Stops a background job.
Stops the current shell.
Starts a switch.
Displays the time used to execute commands.
Shows or set file permissions.
Removes command alias.
Disables the internal hash table.
Removes limitations on system Resource.
Deletes shell variables.
Deletes environment variables.
Waits for background jobs to complete.
while …end
Executes the commands between the while and matching end statements repeatedly.
Displays or set the values of all the shell variables.
The Linux/Unix shell refers to a special program that allows you to interact with it by entering certain commands from the keyboard; the shell will execute the commands and display its output on the monitor. The environment of interaction is text-based (unlike the GUI-based interaction we have been using in the previous chapters) and since it is command-oriented this type of interface is termed Command Line interface or CLI. Before the advent of GUI-based computing environments, the CLI was the only way that one can interact and access a computer system.
Up until now, there was never a need to type commands into a shell; and with the modernisation and creation of a lot of newer GUI-based tools, the shell is becoming increasingly un-required to perform many tasks. But that said, the shell is a very powerful place, and a lot is achieved through it.

Crontab again

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: 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: 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 Section 7.1 for more information).
This file-system is probably the slowest growth unless you are offering a lot of shell accounts.
Tip: 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 Section 7.4 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: (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.
9.2. Managing Processes
From time to time you may wish to view processes that are running on Linux. To obtain a list of these processes, type ``ps -aux'', which will look similar to the following:
bin 69 0.0 1.0 788 320 ? S Nov 30 0:00 /usr/sbin/rpc.portmapframpton 10273 0.0 2.1 1136 664 p0 S 14:12 0:00 -bashframpton 10744 0.0 1.1 820 360 p0 R 17:25 0:00 ps -aux
frampton 10745 0.0 0.8 788 264 p0 S 17:25 0:00 morenobody 10132 0.0 1.8 1016 588 ? S 13:36 0:00 httpdnobody 10133 0.0 1.8 988 568 ? S 13:36 0:00 httpdnobody 10413 0.0
1.8 1012 580 ? S 14:56 0:00 httpdnobody 10416 0.0 1.8 1012 580 ? S 14:56 0:00 httpdnobody 10418 0.0 1.8 1012 588 ? S 14:57 0:00 httpdnobody 10488 0.0 1.7 976 556 ? S 15:34 0:00 httpd
nobody 10564 0.0 1.8 988 564 ? S 16:06 0:00 httpdnobody 10600 0.0 1.8 988 564 ? S 16:15 0:00 httpdnobody 10670 0.0 1.8 988 568 ? S 16:45 0:00 httpdnobody 10704
0.0 1.7 976 552 ? S 17:03 0:00 httpdroot 1 0.0 1.0 776 312 ? S Nov 30 1:13 init [3]root 2 0.0 0.0 0 0 ? SW Nov 30 0:00 (kflushd)root 3 0.0 0.0 0 0 ? SW Nov 30 0:00 (kswapd)
The list shows you the owner of the process ("nobody" for special services such as web servers), the process identification number, the % of CPU time the process is currently using, the % of memory the process is consuming, and other related information, as well as a description of the task itself.
To get more information on a given process, type ``ps pid'' (where "pid" is the process identification number). Looking at our example above, "ps 10704" would display:
10704 ? S 0:00 /usr/local/etc/httpd/httpd
This would tell you that this particular process is a web server (the Apache web server appears multiple times in the process list; for information on why see Section 7.1).
If you happen to notice a service is not operating, you can use the "kill -HUP pid" (where "pid" is the process identification number as shown in the process list produced with "ps"). For example, if Internet services (a process called inetd, process #123 in our example) are not working as they should, a ``kill -HUP 123'' (or even safer, use the ``killall'' command and specify the process name: ``killall -HUP inetd'') should restart the process. The -HUP option to the kill command means "hang up"; the process knows that it is supposed to reload itself.
Another thing to try if you are unable to resolve the problem would be to shut the system down and reboot it (see Section 6.7 for details).
At times, you may find it necessary to temporarily suspend a process, and then resume its execution at a later time. For example, you may be running a CPU-intensive job and wish to burn an IDE-based CDRecordable. Since IDE-based devices rely on the CPU for much of the work behind input/output, they are prone to buffer starvation if your CPU is too busy, and you end up with a useless coaster instead of a properly prepared CD! The following two commands will suspend a process, and the resume it, respectively:
kill -STOP 945kill -CONT 945
Red Hat provides a better way of starting and stopping some processes, which are covered in Section 9.3 below.
9.3. Starting and Stopping Processes
The Red Hat distribution of Linux provides a slightly more organized way of managing processes. Instead of hunting and killing them by finding their process id in the process table, Red Hat provides a collection of scripts in the ``/etc/rc.d/init.d'' directory which will allow you to start and stop processes as desired.
For example, to shut down the ``httpd'' (Apache web server) service, simply run the httpd script, as follows:
/etc/rc.d/init.d/httpd stop
In much the same manner, you can use the ``start'' option to start a service. Or, if you have made changes to a configuration file and wish to restart a service so those changes are recognized, you can use the ``restart'' option.
Note: (Note: Oddly enough, the ``restart'' option does not seem to be supported for some services.)
9.4. Automating Tasks with Cron and Crontab files
Like most Linux users, you may find it necessary to schedule repetitive tasks to be run at a certain time. Such tasks can occur as frequently as once a minute, to as infrequently as once a year. This scheduling can be done by using the ``cron'' facilities.
The cron facilities as implemented in Linux are fairly similar to those available in other Unix implementations. However, Red Hat has adopted a slightly different way of scheduling tasks than is usually done in other distributions of Linux. Just as in other distributions, scheduling information is placed in the system ``crontab'' file (locating in the ``/etc/'' directory), using the following format:
minute hour day month year command
You can specify each time component as an integer number (eg. 1 through 12 for the months January through December), or specify one or more components as ``*'' characters which will be treated as wildcards (eg. * in the month component means the command will run at the given day and time in every month. Here are some examples:
# Mail the system logs at 4:30pm every June 15th.30 16 15 06 * for x in /var/log/*; do cat ${x} mail postmaster; done
# Inform the administrator, at midnight, of the changing seasons.00 00 20 04 * echo 'Woohoo, spring is here!'00 00 20 06 * echo 'Yeah, summer has arrived, time to hit the beach!'00 00 20 10 * echo 'Fall has arrived. Get those jackets out. :-('
00 00 20 12 * echo 'Time for 5 months of misery. ;-('
Note that commands which produce output to standard out (ie. a terminal) such as the examples above using ``echo'' will have their output mailed to the ``root'' account. If you want to avoid this, simply pipe the output to the null device as follows:
00 06 * * * echo 'I bug the system administrator daily at 6:00am!' >/dev/null
In addition to the standard ``crontab'' entries, Red Hat adds several directories:
As their names suggest, executable files can be placed in any of these directories, and will be executed on an hourly, daily, or weekly basis. This saves a bit of time when setting up frequent tasks; just place the executable script or program (or a symbolic link to one stores elsewhere) in the appropriate directory and forget about it.


NAMEfdisk - Partition table manipulator for Linux
SYNOPSISfdisk [-u] [-b sectorsize][-C cyls] [-H heads] [-S sects] device
fdisk -l [-u] [device ...]
fdisk -s partition ...
fdisk -v
DESCRIPTIONHard disks can be divided into one or more logical disks calledpartitions.This division is described in thepartition tablefound in sector 0 of the disk.
In the BSD world one talks about `disk slices' and a `disklabel'.
Linux needs at least one partition, namely for its root file system.It can use swap files and/or swap partitions, but the latter are moreefficient. So, usually one will want a second Linux partitiondedicated as swap partition.On Intel compatible hardware, the BIOS that boots the systemcan often only access the first 1024 cylinders of the disk.For this reason people with large disks often create a third partition,just a few MB large, typically mounted on/boot,to store the kernel image and a few auxiliary files needed at boot time,so as to make sure that this stuff is accessible to the BIOS.There may be reasons of security, ease of administration and backup,or testing, to use more than the minimum number of partitions.
fdisk(in the first form of invocation)is a menu driven program for creation and manipulation ofpartition tables.It understands DOS type partition tables and BSD or SUN type disklabels.
Thedeviceis usually one of the following:/dev/hda/dev/hdb/dev/sda/dev/sdb(/dev/hd[a-h] for IDE disks, /dev/sd[a-p] for SCSI disks,/dev/ed[a-d] for ESDI disks, /dev/xd[ab] for XT disks).A device name refers to the entire disk.
Thepartitionis adevicename followed by a partition number. For example,/dev/hda1is the first partition on the first IDE hard disk in the system.Disks can have up to 15 partitions.See also/usr/src/linux/Documentation/devices.txt.
A BSD/SUN type disklabel can describe 8 partitions,the third of which should be a `whole disk' partition.Do not start a partition that actually uses its first sector(like a swap partition) at cylinder 0, since that willdestroy the disklabel.
An IRIX/SGI type disklabel can describe 16 partitions,the eleventh of which should be an entire `volume' partition,while the ninth should be labeled `volume header'.The volume header will also cover the partition table, i.e.,it starts at block zero and extends by default over five cylinders.The remaining space in the volume header may be used by headerdirectory entries. No partitions may overlap with the volume header.Also do not change its type and make some file system on it, sinceyou will lose the partition table. Use this type of label only whenworking with Linux on IRIX/SGI machines or IRIX/SGI disks under Linux.
A DOS type partition table can describe an unlimited numberof partitions. In sector 0 there is room for the descriptionof 4 partitions (called `primary'). One of these may be anextended partition; this is a box holding logical partitions,with descriptors found in a linked list of sectors, eachpreceding the corresponding logical partitions.The four primary partitions, present or not, get numbers 1-4.Logical partitions start numbering from 5.
In a DOS type partition table the starting offset and the sizeof each partition is stored in two ways: as an absolute numberof sectors (given in 32 bits) and as a Cylinders/Heads/Sectorstriple (given in 10+8+6 bits). The former is OK - with 512-bytesectors this will work up to 2 TB. The latter has two differentproblems. First of all, these C/H/S fields can be filled onlywhen the number of heads and the number of sectors per trackare known. Secondly, even if we know what these numbers should be,the 24 bits that are available do not suffice.DOS uses C/H/S only, Windows uses both, Linux never uses C/H/S.
If possible,fdiskwill obtain the disk geometry automatically. This is notnecessarily the physical disk geometry (indeed, modern disks do notreally have anything like a physical geometry, certainly not somethingthat can be described in simplistic Cylinders/Heads/Sectors form),but is the disk geometry that MS-DOS uses for the partition table.
Usually all goes well by default, and there are no problems ifLinux is the only system on the disk. However, if the disk hasto be shared with other operating systems, it is often a good ideato let an fdisk from another operating system make at least onepartition. When Linux boots it looks at the partition table, andtries to deduce what (fake) geometry is required for goodcooperation with other systems.
Whenever a partition table is printed out, a consistency check is performedon the partition table entries. This check verifies that the physical andlogical start and end points are identical, and that the partition startsand ends on a cylinder boundary (except for the first partition).
Some versions of MS-DOS create a first partition which does not beginon a cylinder boundary, but on sector 2 of the first cylinder.Partitions beginning in cylinder 1 cannot begin on a cylinder boundary, butthis is unlikely to cause difficulty unless you have OS/2 on your machine.
A sync() and a BLKRRPART ioctl() (reread partition table from disk)are performed before exiting when the partition table has been updated.Long ago it used to be necessary to reboot after the use of fdisk.I do not think this is the case anymore - indeed, rebooting too quicklymight cause loss of not-yet-written data. Note that both the kerneland the disk hardware may buffer data.

The DOS 6.x FORMAT command looks for some information in the firstsector of the data area of the partition, and treats this informationas more reliable than the information in the partition table. DOSFORMAT expects DOS FDISK to clear the first 512 bytes of the data areaof a partition whenever a size change occurs. DOS FORMAT will look atthis extra information even if the /U flag is given -- we considerthis a bug in DOS FORMAT and DOS FDISK.
The bottom line is that if you use cfdisk or fdisk to change the size of aDOS partition table entry, then you must also useddto zero the first 512 bytes of that partition before using DOS FORMAT toformat the partition. For example, if you were using cfdisk to make a DOSpartition table entry for /dev/hda1, then (after exiting fdisk or cfdiskand rebooting Linux so that the partition table information is valid) youwould use the command "dd if=/dev/zero of=/dev/hda1 bs=512 count=1" to zerothe first 512 bytes of the partition.
BE EXTREMELY CAREFULif you use theddcommand, since a small typo can make all of the data on your disk useless.
For best results, you should always use an OS-specific partition tableprogram. For example, you should make DOS partitions with the DOS FDISKprogram and Linux partitions with the Linux fdisk or Linux cfdisk program.

-b sectorsize
Specify the sector size of the disk. Valid values are 512, 1024, or 2048.(Recent kernels know the sector size. Use this only on old kernels orto override the kernel's ideas.)
-C cyls
Specify the number of cylinders of the disk.I have no idea why anybody would want to do so.
-H heads
Specify the number of heads of the disk. (Not the physical number,of course, but the number used for partition tables.)Reasonable values are 255 and 16.
-S sects
Specify the number of sectors per track of the disk.(Not the physical number, of course, but the number used forpartition tables.)A reasonable value is 63.
List the partition tables for the specified devices and then exit.If no devices are given, those mentioned in/proc/partitions(if that exists) are used.
When listing partition tables, give sizes in sectors insteadof cylinders.
-s partition
Thesizeof the partition (in blocks) is printed on the standard output.
Print version number offdiskprogram and exit.

Login Files

/etc/passwd File
Contains basic user attributes.
The /etc/passwd file contains basic user attributes. This is an ASCII file that contains an entry for each user. Each entry defines the basic attributes applied to a user. When you use the mkuser command to add a user to your system, the command updates the /etc/passwd file.
Note: Certain system-defined group and user names are required for proper installation and update of the system software. Use care before replacing this file to ensure that no system-supplied groups or users are removed.
An entry in the /etc/passwd file has the following form:
Name:Password: UserID:PrincipleGroup:Gecos: HomeDirectory:Shell
Attributes in an entry are separated by a : (colon). For this reason, you should not use a : (colon) in any attribute. The attributes are defined as follows:
Specifies the user's login name. The user name must be a unique string of 8 bytes or less. There are a number of restrictions on naming users. See the mkuser command for more information.
Contains an * (asterisk) indicating an invalid password or an ! (exclamation point) indicating that the password is in the /etc/security/passwd file. Under normal conditions, the field contains an !. If the field has an * and a password is required for user authentication, the user cannot log in.
Specifies the user's unique numeric ID. This ID is used for discretionary access control. The value is a unique decimal integer.
Specifies the user's principal group ID. This must be the numeric ID of a group in the user database or a group defined by a network information service. The value is a unique decimal integer.
Specifies general information about the user that is not needed by the system, such as an office or phone number. The value is a character string. The Gecos field cannot contain a colon.
Specifies the full path name of the user's home directory. If the user does not have a defined home directory, the home directory of the guest user is used. The value is a character string.
Specifies the initial program or shell that is executed after a user invokes the login command or su command. If a user does not have a defined shell, /usr/bin/sh, the system shell, is used. The value is a character string that may contain arguments to pass to the initial program.
Users can have additional attributes in other system files. See the "Files" section for additional information.
Changing the User File
You should access the user database files through the system commands and subroutines defined for this purpose. Access through other commands or subroutines may not be supported in future releases. Use the following commands to access user database files:
The mkuser command adds new entries to the /etc/passwd file and fills in the attribute values as defined in the /usr/lib/security/mkuser.default file.
The Password attribute is always initialized to an * (asterisk), an invalid password. You can set the password with the passwd or pwdadm command. When the password is changed, an ! (exclamation point) is added to the /etc/passwd file, indicating that the encrypted password is in the /etc/security/passwd file.
Use the chuser command to change all user attributes except Password. The chfn command and the chsh command change the Gecos attribute and Shell attribute, respectively. To display all the attributes in this file, use the lsuser command. To remove a user and all the user's attributes, use the rmuser command.
To write programs that affect attributes in the /etc/passwd file, use the subroutines listed in Related Information .
Access Control: This file should grant read (r) access to all users and write (w) access only to the root user and members of the security group.
Typical records that show an invalid password for smith and guest follow: smith:*:100:100:8A-74(office):/home/smith:/usr/bin/shguest:*:200:0::/home/guest:/usr/bin/sh The fields are in the following order: user name, password, user ID, primary group, general (gecos) information, home directory, and initial program (login shell). The * (asterisk) in the password field indicates that the password is invalid. Each attribute is separated by a : (colon).
If the password for smith in the previous example is changed to a valid password, the record will change to the following: smith:!:100:100:8A-74(office):/home/smith:/usr/bin/sh The ! (exclamation point) indicates that an encrypted password is stored in the /etc/security/passwd file.
Implementation Specifics
This file is part of Base Operating System (BOS) Runtime.

/etc/group File
Contains basic group attributes.
The /etc/group file contains basic group attributes. This is an ASCII file that contains records for system groups. Each record appears on a single line and is the following format:
You must separate each attribute with a colon. Records are separated by new-line characters. The attributes in a record have the following values:
Specifies a group name that is unique on the system. The name is a string of 8 bytes or less. See the mkgroup command for information on the restrictions for naming groups.
Not used. Group administrators are provided instead of group passwords. See the /etc/security/group file for more information.
Specifies the group ID. The value is a unique decimal integer string.

Identifies a list of one or more users. Separate group member names with commas. Each user must already be defined in the local database configuration files.
Do not use a : (colon) in any of the attribute fields. For an example of a record, see the "Examples " section . Additional attributes are defined in the /etc/security/group file.
Note: Certain system-defined group and user names are required for proper installation and update of the system software. Exercise care before replacing the /etc/group file to ensure that no system-supplied groups or users are removed.
You should access the /etc/group file through the system commands and subroutines defined for this purpose. You can use the following commands to manage groups:
To change the Name parameter, you first use the mkgroup command to add a new entry. Then, you use the rmgroup command to remove the old group. To display all the attributes in the file, use the lsgroup command.
You can use the chgroup, chgrpmem, or chuser command to change all user and group attributes. The mkuser command adds a user whose primary group is defined in the /usr/lib/security/mkuser.default file and the rmuser command removes a user. Although you can change the group ID with the chgroup command, this is not recommended.
Access Control: This file should grant read (r) access to all users and grant write (w) access only to the root user and members of the security group.
A typical record looks like the following example for the staff group:staff:!:1:shadow,cjf
In this example, the GroupID parameter is 1 and the users are defined to be shadow and cjf.
Implementation Specifics
This file is part of Base Operating System (BOS) Runtime.
6.6. Linux Password & Shadow File Formats
Traditional Unix systems keep user account information, including one-way encrypted passwords, in a text file called ``/etc/passwd''. As this file is used by many tools (such as ``ls'') to display file ownerships, etc. by matching user id #'s with the user's names, the file needs to be world-readable. Consequentally, this can be somewhat of a security risk.
Another method of storing account information, one that I always use, is with the shadow password format. As with the traditional method, this method stores account information in the /etc/passwd file in a compatible format. However, the password is stored as a single "x" character (ie. not actually stored in this file). A second file, called ``/etc/shadow'', contains encrypted password as well as other information such as account or password expiration values, etc. The /etc/shadow file is readable only by the root account and is therefore less of a security risk.
While some other Linux distributions forces you to install the Shadow Password Suite in order to use the shadow format, Red Hat makes it simple. To switch between the two formats, type (as root):
/usr/sbin/pwconv To convert to the shadow format /usr/sbin/pwunconv To convert back to the traditional format
With shadow passwords, the ``/etc/passwd'' file contains account information, and looks like this:
smithj:x:561:561:Joe Smith:/home/smithj:/bin/bash
Each field in a passwd entry is separated with ":" colon characters, and are as follows:
Username, up to 8 characters. Case-sensitive, usually all lowercase
An "x" in the password field. Passwords are stored in the ``/etc/shadow'' file.
Numeric user id. This is assigned by the ``adduser'' script. Unix uses this field, plus the following group field, to identify which files belong to the user.
Numeric group id. Red Hat uses group id's in a fairly unique manner for enhanced file security. Usually the group id will match the user id.
Full name of user. I'm not sure what the maximum length for this field is, but try to keep it reasonable (under 30 characters).
User's home directory. Usually /home/username (eg. /home/smithj). All user's personal files, web pages, mail forwarding, etc. will be stored here.
User's "shell account". Often set to ``/bin/bash'' to provide access to the bash shell (my personal favorite shell).
Perhaps you do not wish to provide shell accounts for your users. You could create a script file called ``/bin/sorrysh'', for example, that would display some kind of error message and log the user off, and then set this script as their default shell.
Note: Note: If the account needs to provide "FTP" transfers to update web pages, etc. then the shell account will need to be set to ``/bin/bash'' -- and then special permissions will need to be set up in the user's home directory to prevent shell logins. See Section 7.1 for details on this.
The ``/etc/shadow'' file contains password and account expiration information for users, and looks like this:
As with the passwd file, each field in the shadow file is also separated with ":" colon characters, and are as follows:
Username, up to 8 characters. Case-sensitive, usually all lowercase. A direct match to the username in the /etc/passwd file.
Password, 13 character encrypted. A blank entry (eg. ::) indicates a password is not required to log in (usually a bad idea), and a ``*'' entry (eg. :*:) indicates the account has been disabled.
The number of days (since January 1, 1970) since the password was last changed.
The number of days before password may be changed (0 indicates it may be changed at any time)
The number of days after which password must be changed (99999 indicates user can keep his or her password unchanged for many, many years)
The number of days to warn user of an expiring password (7 for a full week)
The number of days after password expires that account is disabled
The number of days since January 1, 1970 that an account has been disabled
A reserved field for possible future use
Contains basic group attributes.
Contains the extended attributes of groups.
Contains the basic attributes of users.
Contains password information.
Contains the extended attributes of users.
Contains the environment attributes of users.
Contains the process resource limits of users.
Contains audit system configuration information

File, Directory and Device permissions:

Modification of file, directory and device access is achieved with the chmod command.
Grant read permissions to a file which you own so that everyone may read it: chmod ugo+r file-name
Grant read permissions on a directory: chmod ugo+rx directory-name Note that "execute" permission is required in order to read a directory.
Deny read access to a file by everyone except yourself: chmod o-r file-name
Allow everyone in your group to be able to modify the file: chmod 660 file-name See chmod man page for more info.
Permissions may be viewd by issuing the command: ls -l file-name
File can be written by youself and members of the group. Others may only view it. -rw-rw-r-- user group file-size date file-name
Directory is completely open for read/write: drwxrwxrwx user group file-size date directory-name
File can only be accessed by owner (user): -rwx------ user group file-size date file-name
Groups and group members:
Users are members of a default group. Red Hat Linux will add new users to a group of the same group name as the user name. The default group is specified in the file /etc/passwd
user-name:x:user-number:group-number:comment section:/home-directory:default-shelluser1:x:500:500:Greg:/home/user1:/bin/bashThe user id has a user system number associated with it and this is defined in /etc/passwd. The group has a group system number associated with it and this is defined in /etc/group
group-name:x:group-number:user1,user2user1:x:500:user2:x:501:floppy:x:19:user1accounting:x:600:user2apache:x:48:User "user1" is a member of default group "user1" and also a member of group "floppy".
Group Commands:
gpasswd: administer the /etc/group file
groupadd: Create a new group
groupmod: Modify a group
groupdel: Delete a new group
If using NIS, view the groups using the command: ypcat group
Switching your default group:
Use the command newgrp group-name to switch your default used in file creation or directory access. This starts a new shell. Exit to return to the previous group id. Use the ps command to see if more than one shell is active.
For example "user2" would like to create a file in the accounting directory which can be read my members of his group. First switch the default group with the command: newgrp accounting
To return to your default group issue the "exit" command. If confused, issue the "ps" command. There should only be one instance of bash, else you are in the alternate group and not the default group.
Use the command newgrp group-name file-name to change the group associated with a file. You must be a member of the group to execute the command sucessfully. (or be root)
The newgrp command logs a user into a new group by changing a user's real and effective group ID. The user remains logged in and the current directory is unchanged. The execution of newgrp always replaces the current shell with a new shell, even if the command terminates with an error (unknown group).
Any variable that is not exported is reset to null or its default value. Exported variables retain their values. System variables (such as PS1, USER, PATH and HOME), are reset to default values unless they have been exported by the system or the user.
With no operands and options, newgrp changes the user's group IDs (real and effective) back to the group specified in the user's password file entry. This is a way to exit the effect of an earlier newgrp command.
A password is demanded if the group has a password and the user is not listed in /etc/group as being a member of that group. The only way to create a password for a group is to use passwd(1), then cut and paste the password from /etc/shadow to /etc/group. Group passwords are antiquated and not often used.
Gives new login as if logged in as group member: newgrp -
Changing group ownership:
If the user creates a file, the default group association is the group id of user. If he wishes to change it to another group of which he is a member issue the command: chgrp new-group-id file-name
If the user is not a member of the group then a password is required.
Default user groups:
Users are assigned upon user creation, a User Private Group (UPG) which is a unique group ID of the same name as the user ID. This allows for a fine atomic level of group permissions to be assigned for tighter and simpler default security.
Pre-Configured system groups:
The typical Linux installation will come with some exisitng standard groups: (See /etc/group)
Group ID
This is only a partial listing of the default groups. There will also be a default set of member user ID's associated with most of the groups.
Grant use of a device to system users:
The first example will be of granting access to a device, the CD-ROM. This is generally not done for regular users on a server. Server access to a CD-ROM is limited to root by default. (This example may also be applied to the diskette. Group: floppy, first floppy device: /dev/fd0)
Grant mount privileges to system users
Create group cdrom .
Allow use of device by group cdrom .
Add user to group cdrom .
Grant privileges to system users to mount the device:
Manual method: This requires a change to the file /etc/fstab.The fourth column defines mounting options. By default only root may mount the device (option owner ). To grant users the ability to mount the device, change the owner option to user . With the user option only the user who mounted the device can unmount the device. To allow anyone to unmount the device, use the option users .
Linuxconf GUI method: (Note: Linuxconf is no longer included with Red Hat Linux 7.3 and later)
RH 5.2: Start + Programs + Administration + Linuxconf .
RH 6.0: Select Gnome Start icon + System + Linuxconf .
Select Config + File systems + Access local drive .
Select the device /dev/cdrom
Select the tab Options .
Add the option User mountable to allow users to mount the CD-ROM. The user who mounted the CD must also be the one to unmount the CD. OR Select the tab Misc. and add to Other options: users if you want to allow anyone to be able to unmount the CD regardless of who mounted it. For more information see the man pages for mount and fstab.
Create group cdrom :
Manual method:
Add the line cdrom:::root, to the file /etc/group where is the user to be granted use of the CD-ROM. (For example: cdrom::25:root,user1") OR
Add a group with the command: groupadd in this case groupadd cdrom .
Linuxconf GUI method: (Admin tool linuxconf is no longer included with Red Hat 7.3+.)
Start linuxconf.
Select Config + User Accounts + Normal + Group Definitions + Add .
Group Name: cdrom
Alternate Members (opt): root : (Add space delimited user ids here)
Accept For more information see the man pages for groupadd, groupmod and groupdel.
Allow use of device by group cdrom .
Manual method:
Use the command: chown owner:group to assign the device to a user and group. For example: chown root.cdrom /dev/hdd . (Use hdd if cdrom is the slave device on the 2nd IDE controller.)
Allow group access to the device: chmod 660 /dev/hdd
GUI method:
Start the File Manager and right click the file representing the cdrom device. Select Properties . Then select the tab Permissions . Set the Owner to root and the Group to cdrom. Allow Read and Write privileges for the user and group by selecting the appropriate buttons.
Add user to group cdrom : At this point, adding users to the group cdrom will grant them access to the device.
Manual method: The user id s specified in /etc/group is a comma separated list.
Use the command usermod -G . Be sure to list all groups as this is an absolute list and not an addition. To list all groups to which a user is a member use the command groups .
Linuxconf GUI method: Step two allowed you to assign users to the group. If users still need to be assigned use the following method:
After starting Linuxconf, select options Config + User Accounts + Normal + User Accounts .
Next to supplementary groups add the group cdrom. Groups should be delimited by spaces.
OR for a completely different method that steps 1 to 4, use the one step approach:
chmod 664 /dev/hdd : Allow read use to all users of the CD-ROM device (hdd is just the example, your device name can vary). This method is quick, unelegant and can be used for your own desktop system but definitely don t do this on a server.
Using CD-ROM:You must mount and un-mount each CD-ROM individually. Do not switch CDs without un-mounting and re-mounting the new CD. (The GNOME desktop interface has features to do this for you. Covered later)
Command method:
mount -t iso9660 /dev/hdd /mnt/cdrom : This generates amount point for CD-ROM (or mount -t iso9660 /dev/cdrom /mnt/cdrom . The device name /dev/cdrom is a symbolic link to the actual device) Note: Only root user may execute the mount command. Users must use the tool usermount.
Desktop GUI method:
RH 5.2: Start + Programs + Administration + Disk Management .
RH 6.0/6.1: Select Gnome icon (located lower left corner) + System + Disk Management .
The gui tool can also be started using the shell command /usr/bin/usermount.
After mounting the CD-ROM one can view its contents from the directory /mnt/cdrom.
Use the command: cd /mnt/cdrom OR
GNOME toollbar Start icon File manager and select the appropriate folders.
Group Interrogation and Verification:
Check the group membership of a user: groups user-id
This will list all the groups to which user-id is a member.
Verification Commands:
pwck: verify integrity of password files
grpck: verify integrity of group files
User admin and other commands:
useradd: Create a new user or update default new user information
usermod: Modify a user account
userdel: Delete a user account and related files
chage: change user password expiry information
pwconv: convert to and from shadow pass- words and groups.
pwunconv: convert to and from shadow pass- words and groups.
grpconv: creates gshadow from group and an optionally existing gshadow
grpunconv: creates group from group and gshadow and then removes gshadow

SMART Technology

In an effort to help users avoid data loss, drive manufacturers are now incorporating logic into their drives that acts as an "early warning system" for pending drive problems. This system is called Self-Monitoring Analysis and Reporting Technology or SMART. The hard disk's integrated controller works with various sensors to monitor various aspects of the drive's performance, determines from this information if the drive is behaving normally or not, and makes available status information to software that probes the drive and look at it.
The fundamental principle behind SMART is that many problems with hard disks don't occur suddenly. They result from a slow degradation of various mechanical or electronic components. SMART evolved from a technology developed by IBM called Predictive Failure Analysis or PFA. PFA divides failures into two categories: those that can be predicted and those that cannot. Predictable failures occur slowly over time, and often provide clues to their gradual failing that can be detected. An example of such a predictable failure is spindle motor bearing burnout: this will often occur over a long time, and can be detected by paying attention to how long the drive takes to spin up or down, by monitoring the temperature of the bearings, or by keeping track of how much current the spindle motor uses. An example of an unpredictable failure would be the burnout of a chip on the hard disk's logic board: often, this will "just happen" one day. Clearly, these sorts of unpredictable failures cannot be planned for.
The main principle behind failure prediction is that some failures cause gradual changes invarious indicators that can be tracked to detect trends that may indicate overall drive failure.
Image � Quantum CorporationImage used with permission.
The drive manufacturer's reliability engineers analyze failed drives and various mechanical and electronic characteristics of the drive to determine various correlations: relationships between predictable failures, and values and trends in various characteristics of the drive that suggest the possibility of slow degradation of the drive. The exact characteristics monitored depend on the particular manufacturer and model. Here are some that are commonly used:
Head Flying Height: A downward trend in flying height will often presage a head crash.
Number of Remapped Sectors: If the drive is remapping many sectors due to internally-detected errors, this can mean the drive is starting to go.
ECC Use and Error Counts: The number of errors encountered by the drive, even if corrected internally, often signal problems developing with the drive. The trend is in some cases more important than the actual count.
Spin-Up Time: Changes in spin-up time can reflect problems with the spindle motor.
Temperature: Increases in drive temperature often signal spindle motor problems.
Data Throughput: Reduction in the transfer rate of the drive can signal various internal problems.
(Some of the quality and reliability features I am describing in this part of the site are in fact used to feed data into the SMART software.)
Using statistical analysis, the "acceptable" values of the various characteristics are programmed into the drive. If the measurements for the various attributes being monitored fall out of the acceptable range, or if the trend in a characteristic is showing an unacceptable decline, an alert condition is written into the drive's SMART status register to warn that a problem with the drive may be occurring.
SMART requires a hard disk that supports the feature and some sort of software to check the status of the drive. All major drive manufacturers now incorporate the SMART feature into their drives, and most newer PC systems and motherboards have BIOS routines that will check the SMART status of the drive. So do operating systems such as Windows 98. If your PC doesn't have built-in SMART support, some utility software (like Norton Utilities and similar packages) can be set up to check the SMART status of drives. This is an important point to remember: the hard disk doesn't generate SMART alerts, it just makes available status information. That status data must be checked regularly for this feature to be of any value.
Clearly, SMART is a useful tool but not one that is foolproof: it can detect some sorts of problems, but others it has no clue about. A good analogy for this feature would be to consider it like the warning lights on the dashboard of your car: something to pay attention to, but not to rely upon. You should not assume that because SMART generated an alert, there is definitely a drive problem, or conversely, that the lack of an alarm means the drive cannot possibly be having a problem. It certainly is no replacement for proper hard disk care and maintenance, or routine and current backups.
If you experience a SMART alert using your drive, you should immediately stop using it and contact your drive manufacturer's technical support department for instructions. Some companies consider a SMART alert sufficient evidence that the drive is bad, and will immediately issue an RMA for its replacement; others require other steps to be performed, such as running diagnostic software on the drive. In no event should you ignore the alert. Sometimes I see people asking others "how they can turn off those annoying SMART messages" on their PCs. Doing that is, well, like putting electrical tape over your car's oil pressure light so it won't bother you while you're driving!

System Logging

One integral part of any UNIX system are the loggingfacilities. The majority of logging in Linux is provided by twomain programs, sysklogd and klogd, the first providing loggingservices to programs and applications, the second providinglogging capability to the Linux kernel. Klogd actually sends mostmessages to the syslogd facility but will on occasion pop upmessages at the console (i.e. kernel panics). Sysklogd actuallyhandles the task of processing most messages and sending them tothe appropriate file or device, this is configured from within/etc/syslog.conf. By default most logging to files takes place in/var/log/, and generally speaking programs that handle their ownlogging (most httpd servers handle their logging internally) logto /var/log/program-name/, which allows you to centralize the logfiles and makes it easier to place them on a separate partition(some attacks can fill your logs quite quickly, and a full /partition is no fun). Additionally there are programs that handletheir own interval logging, one of the more interesting being thebash command shell. By default bash keeps a history file ofcommands executed in ~username/.bash_history, this file can makefor extremely interesting reading, as oftentimes many admins willaccidentally type their passwords in at the command line. Apachehandles all of its logging internally, configurable fromhttpd.conf and extremely flexible with the release of Apache1.3.6 (it supports conditional logging). Sendmail handles itslogging requirements via syslogd but also has the option (via thecommand line -X switch) of logging all SMTP transactions straightto a file. This is highly inadvisable as the file will growenormous in a short span of time, but is useful for debugging.See the sections in network security on Apache and Sendmail formore information.
General log security
Generally speaking you do not want to allow users to see thelog files of a server, and you especially don't want them tobe able to modify or delete them. Generally speaking most logfiles are owned by the root user and group, and have nopermissions assigned for other, so in most cases the only userable to modify the logs will be the root user (and if someonecracks the root account all bets are off). There are a few extrasecurity precautions you can take however, the simplest being touse the "chattr" (CHange ATTTRibutes command) to setthe log files to append only. This way in the event of a problemlike a /tmp race that allows people to overwrite files on thesystem they cannot significantly damage the log files. To set afile to append only use:chattr +a filename
only the superuser has access to this function of chattr. Ifyou set all your log files to append only you must remember thatlog rotation programs will fail as they will not be able to zerothe log file. Add a line to the script to unset the append onlyattribute:chattr -a filename
and add a line after the log rotation script to reset theappend only flag. If you keep log files on the system you mayalso wish to set them immutable so they cannot be tampered withas easily, to set the file immutable simply:chattr +i filename
and this will prevent any changes (due to /tmp races, etc.) tothe file unless the attacker has root access (in which caseyou're already in a world of hurt).chattr -i filename
only the root user has access to the immutable flag.
System logging
One feature of Linux (and most unices) is the syslog and klogfacilities which allow software to generate log messages that arethen passed to alog daemon and handled (written to a local file,a remote server, given to aprogram, and so on).
sysklogd / klogd
In a nutshell klogd handles kernel messages, depending on yoursetup this can range from almost none to a great deal if forexample you turn on process accounting. It then passes mostmessages to syslogd for actual handling (that is it places thedata in a physical file). The man pages for sysklogd, klogd andsyslog.conf are pretty good with clear examples. One exceedinglypowerful and often overlooked ability of syslog is to logmessages to a remote host running syslog. Since you can definemultiple locations for syslog messages (i.e. send all kernmessages to the /var/log/messages file, and to console, and to aremote host or multiple remote hosts) this allows you tocentralize logging to a single host and easily check log filesfor security violations and other strangeness. There are severalproblems with syslogd and klogd however, the primary ones beingthe ease of which once an attacker has gained root access todeleting/modifying log files, there is no authentication builtinto the standard logging facilities.
The standard log files that are usually defined in syslog.confare:/var/log/messages/var/log/secure/var/log/maillog/var/log/spooler
The first one (messages) gets the majority of informationtypically; user logins, TCP_WRAPPERS dumps information here, IPfirewall packet logging typically dumps information here and soon. The second typically records entries for events like userschanging their UID/GID (via su, sudo, etc.), failed attempts whenpasswords are required and so on. The maillog file typicallyholds entries for every pop/imap connection (user login andlogout), and the header of each piece of email that goes in orout of the system (from whom, to where, msgid, status, and soon). The spooler file is not often used anymore as the number ofpeople running usenet or uucp has plummeted, uucp has beenbasically replaced with ftp and email, and most usenet serversare typically extremely powerful machines to handle a full, oreven partial newsfeed, meaning there aren't many of them(typically one per ISP or more depending on size). Most homeusers and small/medium sized business will not (and should not inmy opinion) run a usenet server, the amount of bandwidth andmachine power required is phenomenal, let alone the securityrisks.
You can also define additional log files, for example youcould add:kern.* /var/log/kernel-log
And you can selectively log to a separate log host:*.emerg @syslog-hostmail.* @mail-log-host
Which would result in all kernel messages being logged to/var/log/kernel-log, this is useful on headless servers since bydefault kernel messages go to /dev/console (i.e. someone loggedin at the machines). In the second case all emergency messageswould be logged to the host "syslog-host", and all themail log files would be sent to the "mail-log-host"server, allowing you to easily maintain centralized log files ofvarious services. The default syslogd that ships with most Linuxdistributions is horribly insecure, log files are easily tamperedwith (or outright destroyed), and logging across the network iscompletely insecure as well as dangerous for the serversinvolved. I do not advise using syslog if you actually have aneed for reliable logging (i.e. the ability to later view logfiles in the event of a break-in).
The default file permissions on the log files are usually read/ write for root, and nothing for anyone else. In addition tothis you can (and should) set the files append only (remember totake logrotate into account though, it needs to zero the files).This will prevent any deletion / modifications to the log filesunless root unsets the append only attribute first.
modular syslog
The major problem with syslog however is that tampering withlog files is trivial (setting the log files append only with"chattr +a" helps, but if an attacker gains root, theycan unset the attribute). There is however a secure version ofsyslogd, available at guys generally make good tools and have a good reputation,in any case it is open source software for those of you who aretruly paranoid). This allows you to cryptographically sign logsto ensure they haven't been tampered with. Ultimately,however, an attacker can still delete the log files so it is agood idea to send them to another host, especially in the case ofa firewall to prevent the hard drive being filled up.
next generation syslog
Another alternative is "syslog-ng" (Next GenerationSyslog), which seems much more customizable then either syslog orsecure-syslog, it supports digital signatures to prevent logtampering, and can filter based on content of the message, notjust the facility it comes from or priority (something that isvery useful for cutting down on volume). Syslog-ng is availableat:
Nsyslogd supports tcp, and SSL for logging to remote systems.It runs on a variety of UNIX platforms and you can download itfrom:
Log monitoring
Log files are not much good unless you actually check themonce in a while, this is an almost impossible task for most of ushowever due to the sheer volume of log files. There are a varietyof tools to automate these tasks however.
Psionic Logcheck
Psionic Logcheck will go through the messages file (andothers) on a regular basis (invoked via crontab usually) andemail out a report of any suspicious activity. It is easilyconfigurable with several 'classes' of items, activepenetration attempts which is screams about immediately, badactivity, and activity to be ignored (for example DNS serverstatistics or SSH rekeying). Psionic Logcheck is available from:
colorlogs will color code log files allowing you to easilyspot suspicious activity. Based on a config file it looks forkeywords and colors the lines (red, cyan, etc.), it takes inputfrom STDIN so you can use it to review log files quickly (byusing "cat", "tail" or other utilities tofeed the log file through the program). You can get it at:
WOTS collects log files from multiple sources and willgenerate reports or take action based on what you tell it to do.WOTS looks for regular expressions you define and then executesthe commands you list (mail a report, sound an alert, etc.). WOTSrequires you have Perl installed and is available from:
swatch is very similar to WOTS, and the log filesconfiguration is very similar. You can download swatch from:
Kernel logging
The lowest level of logging possible is at the kernel level.Generally speaking users cannot disabled of avoid this type oflogging, and also are usually not even aware it exists (adefinite advantage).
Shell logging
A variety of command shells have built in loggingcapabilities.
I will also cover bash since it is the default shell in mostLinux installations, and thus its logging facilities aregenerally used. bash has a large number of variables you canconfigure at run time or during it's use that modify how itbehaves. Everything from the command prompt style to how manylines to keep in the log file.
HISTFILEname of the history file, by default it is~username/.bash_history
HISTFILESIZEmaximum number of commands to keep in the file, it rotates themas needed.
HISTSIZEthe number of commands to remember (i.e. when you use the uparrow key).
The variables are typically set in /etc/profile, whichconfigures bash globally for all users, however, the values canbe over-ridden by users with the ~username/.bash_profile file,and/or by manually using the export command to set variables suchas export EDITOR=emacs. This is one of the reasons that userdirectories should not be world readable; the .bash_history filecan contain a lot of valuable information to a hostile party. Youcan also set the file itself non world readable, set your.bash_profile not to log, set the file non writeable (thusdenying bash the ability to write and log to it) or link it to/dev/null (this is almost always a sure sign of suspicious useractivity, or a paranoid user). For the root account I wouldhighly recommend setting the HISTFILESIZE and HISTSIZE to a lowvalue such as 10. On the other hand if you want to log usersshell history and otherwise tighten up security I would recommendsetting the configuration files in the user's home directoryto immutable using the chattr command, and set the log files(such as .bash_history) to append only. Doing this however opensup some legal issues, so make sure your users are aware they arebeing logged and have agreed to it, otherwise you could get intotrouble. Don't forget to set /hom/username/.bash_history appendonly (chattr +A).

Sysconfig Information

The following information outlines some of the various files in /etc/sysconfig, their function, and their contents. This information is not intended to be complete, as many of these files have a variety of options that are only used in very specific or rare circumstances.
Files in /etc/sysconfig
The following files are normally found in /etc/sysconfig:
It is possible that your system may be missing a few of them if the corresponding program that would need that file is not installed.
Next, we will take a look at each one.
The /etc/sysconfig/amd file contains various parameters used by amd allowing for the automounting and automatic unmounting of filesystems.
The /etc/sysconfig/apmd file is used by apmd as a configuration for what things to start/stop/change on suspend or resume. It is set up to turn on or off apmd during startup, depending on whether your hardware supports Advanced Power Management (APM) or if you choose not to use it. apm is a monitoring daemon that works with power management code within the Linux kernel. It can alert you to a low battery if you are using Red Hat Linux on a laptop, among other things.
The /etc/sysconfig/authconfig file sets the kind of authorization to be used on the host. It contains one or more of the following lines:
USEMD5=, where is one of the following:
yes — MD5 is used for authentication.
no — MD5 is not used for authentication.
USEKERBEROS=, where is one of the following:
yes — Kerberos is used for authentication.
no — Kerberos is not used for authentication.
USELDAPAUTH=, where is one of the following:
yes — LDAP is used for authentication.
no — LDAP is not used for authentication.
The /etc/sysconfig/clock file controls the interpretation of values read from the system clock. Earlier releases of Red Hat Linux used the following values (which are deprecated):
CLOCKMODE=, where is one of the following:
GMT — Indicates that the clock is set to Universal Time (Greenwich Mean Time).
ARC — Indicates the ARC console's 42-year time offset is in effect (for Alpha-based systems only).
Currently, the correct values are:
UTC=, where is one of the following boolean values:
true — Indicates that the clock is set to Universal Time. Any other value indicates that it is set to local time.
ARC=, where is the following:
true — Indicates the ARC console's 42-year time offset is in effect. Any other value indicates that the normal UNIX epoch is assumed (for Alpha-based systems only).
ZONE= — Indicates the timezone file under /usr/share/zoneinfo that /etc/localtime is a copy of, such as:
ZONE="America/New York"
The /etc/sysconfig/desktop file specifies the desktop manager to be run, such as:
The /etc/sysconfig/firewall file contains various firewall settings. By default, this file (if created) is empty.
The /etc/sysconfig/harddisks file allows you to tune your hard drive(s). You can also use /etc/sysconfig/hardiskhd[a-h], to configure parameters for specific drives.


Do not make changes to this file lightly. If you change the default values stored here, you could corrupt all of the data on your hard drive(s).
The /etc/sysconfig/harddisks file may contain the following:
USE_DMA=1, where setting this to 1 enables DMA. However, with some chipsets and hard drive combinations, DMA can cause data corruption. Check with your hard drive documentation or manufacturer before enabling this.
Multiple_IO=16, where a setting of 16 allows for multiple sectors per I/O interrupt. When enabled, this feature reduces operating system overhead by 30-50%. Use with caution.
EIDE_32BIT=3 enables (E)IDE 32-bit I/O support to an interface card.
LOOKAHEAD=1 enables drive read-lookahead.
EXTRA_PARAMS= specifies where extra parameters can be added.
The /etc/sysconfig/hwconf file lists all the hardware that kudzu detected on your system, as well as the drivers used, vendor ID and device ID information. The kudzu program detects and configures new and/or changed hardware on a system. The /etc/sysconfig/hwconf file is not meant to be manually edited. If you do edit it, devices could suddenly show up as being added or removed.
The /etc/sysconfig/i18n file sets the default language, such as:
The /etc/sysconfig/init file controls how the system will appear and function during bootup.
The following values may be used:
BOOTUP=, where is one of the following:
BOOTUP=color means the standard color boot display, where the success or failure of devices and services starting up is shown in different colors.
BOOTUP=verbose means an old style display, which provides more information than purely a message of success or failure.
Anything else means a new display, but without ANSI-formatting.
RES_COL=, where is the number of the column of the screen to start status labels. Defaults to 60.
MOVE_TO_COL=, where moves the cursor to the value in the RES_COL line. Defaults to ANSI sequences output by echo -e.
SETCOLOR_SUCCESS=, where sets the color to a color indicating success. Defaults to ANSI sequences output by echo -e, setting the color to green.
SETCOLOR_FAILURE=, where sets the color to a color indicating failure. Defaults to ANSI sequences output by echo -e, setting the color to red.
SETCOLOR_WARNING=, where sets the color to a color indicating warning. Defaults to ANSI sequences output by echo -e, setting the color to yellow.
SETCOLOR_NORMAL=, where sets the color to 'normal'. Defaults to ANSI sequences output by echo -e.
LOGLEVEL=, where sets the initial console logging level for the kernel. The default is 7; 8 means everything (including debugging); 1 means nothing except kernel panics. syslogd will override this once it starts.
PROMPT=, where is one of the following boolean values:
yes — Enables the key check for interactive mode.
no — Disables the key check for interactive mode.
The /etc/sysconfig/ipchains file contains information used by the kernel to set up ipchains rules regarding packet filtering.
This file is modified by running the service ipchains save command when valid ipchains rules are in place. You should not manually edit this file. Instead, use the ipchains command to configure the necessary packet filtering rules and then save the rules to this file.
Like /etc/sysconfig/ipchains, the /etc/sysconfig/iptables file stores information used by the kernel to provide specialized packet filtering services. However, this file is used by iptables rather than ipchains.
You should not modify this file by hand unless you are familiar with methods used to construct iptables rules. These rules are written to /etc/sysconfig/iptables by the service iptables save command, which stores the current iptables rules by running the /sbin/iptables-save program. Then, when iptables is restarted, such as is the case when the system is booted, the /sbin/iptables-restore program reads the file and reinstitutes the packet filtering rules.
The /etc/sysconfig/irda file controls how infrared devices on your system are configured at startup.
The following values may be used:
IRDA=, where is one of the following boolean values:
yes — irattach will be run, which periodically checks to see if anything is trying to connect to the infrared port, such as another notebook computer trying to make a network connection. For infrared devices to work on your system, this line must be set to yes.
no — irattach will not be run, preventing infrared device communication.
DEVICE=, where is the device (usually a serial port) that handles infrared connections.
DONGLE=, where specifies the type of dongle being used for infrared communication. This setting exists for people who use serial dongles rather than real infrared ports. A dongle is a device that is attached to a traditional serial port to communicate via infrared. This line is commented out by default because notebooks with real infrared ports are far more common than computers with add-on dongles.
DISCOVERY=, where is one of the following boolean values:
yes — Starts irattach in discovery mode, meaning it actively checks for other infrared devices. This needs to be turned on for the machine to be actively looking for an infrared connection (meaning the peer that does not initiate the connection).
no — Does not start irattach in discovery mode.
The /etc/sysconfig/keyboard file controls the behavior of the keyboard. The following values may be used:
KEYBOARDTYPE=sunpc, which is used on SPARCs only. sun means a Sun keyboard is attached on /dev/kbd, and pc means a PS/2 keyboard connected to a PS/2 port.
KEYTABLE=, where is the name of a keytable file. For example: KEYTABLE="us". The files that can be used as keytables start in /usr/lib/kbd/keymaps/i386 and branch into different keyboard layouts from there, all labeled .kmap.gz. The first file found beneath /usr/lib/kbd/keymaps/i386that matches the KEYTABLE setting is used.
The /etc/sysconfig/kuzdu allows you to specify a safe probe of your system's hardware by kudzu at boot time. A safe probe is one that disables serial port probing.
SAFE=, where is one of the following:
yes — kuzdu does a safe probe.
no — kuzdu does a normal probe.
The /etc/sysconfig/mouse file is used to specify information about the available mouse. The following values may be used:
FULLNAME=, where refers to the full name of the kind of mouse being used.
MOUSETYPE=, where is one of the following:
microsoft — A Microsoft™ mouse.
mouseman — A MouseMan™ mouse.
mousesystems — A Mouse Systems™ mouse.
ps/2 — A PS/2 mouse.
msbm — A Microsoft™ bus mouse.
logibm — A Logitech™ bus mouse.
atibm — An ATI™ bus mouse.
logitech — A Logitech™ mouse.
mmseries — An older MouseMan™ mouse.
mmhittab — An mmhittab mouse.
XEMU3=, where is one of the following boolean values:
yes — The mouse only has two buttons, but three mouse buttons should be emulated.
no — The mouse already has three buttons.
XMOUSETYPE=, where refers to the kind of mouse used when X is running. The options here are the same as the MOUSETYPE setting in this same file.
DEVICE=, where is the mouse device.
In addition, /dev/mouse is a symbolic link that points to the actual mouse device.
The /etc/sysconfig/network file is used to specify information about the desired network configuration. The following values may be used:
NETWORKING=, where is one of the following boolean values:
yes — Networking should be configured.
no — Networking should not be configured.
HOSTNAME=, where should be the Fully Qualified Domain Name (FQDN), such as, but can be whatever hostname you want.


For compatibility with older software that people might install (such as trn), the /etc/HOSTNAME file should contain the same value as here.
GATEWAY=, where is the IP address of the network's gateway.
GATEWAYDEV=, where is the gateway device, such as eth0.
NISDOMAIN=, where is the NIS domain name.
The /etc/sysconfig/pcmcia file is used to specify PCMCIA configuration information. The following values may be used:
PCMCIA=, where is one of the following:
yes — PCMCIA support should be enabled.
no — PCMCIA support should not be enabled.
PCIC=, where is one of the following:
i82365 — The computer has an i82365-style PCMCIA socket chipset.
tcic — The computer has a tcic-style PCMCIA socket chipset.
PCIC_OPTS=, where is the socket driver (i82365 or tcic) timing parameters.
CORE_OPTS=, where is the list of pcmcia_core options.
CARDMGR_OPTS=, where is the list of options for the PCMCIA cardmgr (such as -q for quiet mode; -m to look for loadable kernel modules in the specified directory, and so on). Read the cardmgr man page for more information.
The /etc/sysconfig/rawdevices file is used to configure raw device bindings, such as:
/dev/raw/raw1 /dev/sda1/dev/raw/raw2 8 5
The /etc/sysconfig/sendmail file allows messages to be sent to one or more recipients, routing the message over whatever networks are necessary. The file sets the default values for the Sendmail application to run. Its default values are to run as a background daemon, and to check its queue once an hour in case something has backed up.
The following values may be used:
DAEMON=, where is one of the following boolean values:
yes — Sendmail should be configured to listen to port 25 for incoming mail. yes implies the use of Sendmail's -bd options.
no — Sendmail should not be configured to listen to port 25 for incoming mail.
QUEUE=1h which is given to Sendmail as -q$QUEUE. The -q option is not given to Sendmail if /etc/sysconfig/sendmail exists and QUEUE is empty or undefined.
The /etc/sysconfig/soundcard file is generated by sndconfig and should not be modified. The sole use of this file is to determine what card entry in the menu to pop up by default the next time sndconfig is run. Soundcard configuration information is located in the /etc/modules.conf file.
It may contain the following:
CARDTYPE=, where is set to, for example, SB16 for a Soundblaster 16 sound card.
The /etc/sysconfig/ups file is used to specify information about any Uninterruptible Power Supplies (UPS) connected to your system. A UPS can be very valuable for a Red Hat Linux system because it gives you time to correctly shut down the system in the case of power interruption. The following values may be used:
SERVER=, where is one of the following:
yes — A UPS device is connected to your system.
no — A UPS device is not connected to your system.
MODEL=, where must be one of the following or set to NONE if no UPS is connected to the system:
apcsmart — For a APC SmartUPS™ or similar device.
fentonups — For a Fenton UPS™.
optiups — For an OPTI-UPS™ device.
bestups — For a Best Power™ UPS.
genericups — For a generic brand UPS.
ups-trust425+625 — For a Trust™ UPS.
DEVICE=, where specifies where the UPS is connected, such as /dev/ttyS0.
OPTIONS=, where is a special command that needs to be passed to the UPS.
The /etc/sysconfig/vncservers file configures how the Virtual Network Computing (VNC) server starts up. VNC is a remote display system which allows you to view a desktop environment not only on the machine where it is running but across different networks (from a LAN to the Internet) and using a wide variety of machine architectures.
It may contain the following:
VNCSERVERS=, where is set to something like "1:fred", to indicate that a VNC server should be started for user fred on display :1. User fred must have set a VNC password using vncpasswd before attempting to connect to the remote VNC server.
Note that when you use a VNC server, your communication with it is unencrypted, and so it should not be used on an untrusted network. For specific instructions concerning the use of SSH to secure the VNC communication, please read the information found at

You might also like :

Related Posts with Thumbnails