UNIX System Administration Notes Creating accounts: This and other common system administration tasks may be handled by some interactive system admin program. For example, HP has sam (system administration manager) on its HP-UX systems. However, some of these menu-based systems do not give you sufficient room to customize things the way you would like. For account creation see if your system has a useradd, adduser, newuser, or similarly named script or program for adding new accounts. You may then be able to write your own script that repeatedly calls the adduser program or whatever it is named. Try something like: man useradd There may also be a userdel to remove an old account. Daemons: A daemon is a background process that runs as long as the system is up. An example is cron. This process runs constantly in the background on most UNIX systems. Every minute it checks to see if there are any automatic jobs to run at this time, then it puts itself to sleep for another minute. System administrators commonly use cron to schedule automatic jobs at certain times and/or days. For example, on our Linux there is a crontab entry that specifies that the /tmp directory should be cleaned out every Wed at 3:30 am. You can see what daemons (and other processes) are currently running by using commands such as: ps -aef Show list of processes now running. top Shows which processes are using the CPU the most, etc. Use q to quit. The command to list one's crontab entries is: crontab -l The fields that you see for each entry are: minutes, hour, day, month, dayofweek, and the command to execute at that time. Output is usually redirected to /dev/null to throw away any error messages or other output (unless the sys admin would want error messages send via email). Often only root (the system administrator's account) can run crontab. The command to edit the crontab entries is: crontab -e This edits these entries using vi, the standard (and clumsy) UNIX editor. Most everyone hates vi, but some system tasks have to be done using it, so anyone who runs a UNIX system has to know how to use vi to some extent. Whenever possible, though, most people use another editor. Setuid: The setuid bit (sometimes called suid) is one of the protection bits for a program file. If this bit is on (in the file owner position among the permissions), then when a user executes the program, the program runs with the privileges of the owner of the program (not those of the user). This enables an ordinary user to run a program (such as passwd) that accesses critical system information, but in a way that doesn't let the user get at more than s/he should. (The alternative of allowing every user to directly access the areas where password information is held would make it easier for a determined user to break passwords, even though they are encrypted. The method is well-known and is called a dictionary attack. Common words from the dictionary, variants of peoples' names, slang, Star Trek terms, etc. are encoded using the public encryption algorithm to see if any of the results match what is in the file of encrypted passwords. If a match is found, the associated text password and user ID are then known to the cracker, who can then log in as that user. This is why many UNIX systems now use a shadow password file that hides the encrypted passwords away where users cannot directly access them.) Use the following to examine the ordinary password file: more /etc/passwd Note that the fields on each line are separated by colons. The second field, the password field, merely contains an x, indicating that the real encoded password is stored elsewhere. The third and fourth fields are numbers: the numeric user ID (UID) and numeric group ID (GID) respectively. I used whereis passwd to find the location of the passwd program. It is found in /usr/bin. I used the following to see the program's permissions: cd /usr/bin ll passwd The results of the long listing of the file are: -rwsr-xr-x 1 root root 27848 Feb 2 10:42 passwd The rws are the permissions for the owner, the next three are for the group members, and the final three for anyone else. Note the s (for setuid) instead of x (executable) for the owner. Thus when a user runs the passwd program, the program can access any areas of the system that root (the system administrator) can. This means that a poorly written setuid program is a potential security flaw for a cracker to try to exploit. If the cracker can get the setuid program to run his/her own program or script with root access, then the cracker has access to everything! Permissions are typically set by using the chmod command as in the following examples: chmod 644 myfile (gives rw-r--r-- permissions) chmod 755 mydir (gives rwxr-xr-x permissions) chmod 4755 myfile (gives rwsr-xr-x permissions) chmod 2755 myfile (gives rwxr-sr-x permissions) chmod 6755 myfile (gives rwsr-sr-x permissions) Note that the second command above is useful to set up a directory that allows others to look at and read your files, but no write access. The third one turns the setuid bit on, the fourth turns the setguid bit on (the group uid), and the last turns both setuid and setguid on. Note that a setguid runs with all of the access rights of members of the file's group. Some other common setuid programs include the following. Use whereis to find them and then use ll to check for that telltale s permission. ping Used to see if another computer on the network is reachable by sending packets to it and waiting for replies. lpq Show what print jobs are queued up. Use man lpq for more details. lpr Used to print files on the printer attached to the UNIX machine. Basic syntax: lpr filename(s) lprm Used to remove a print job from the queue. You need to first use lpq to find the job number. Then use: lprm number(s) sendmail The underlying UNIX daemon for sending and receiving email. Programs like pine and elm are just helpful interfaces to sendmail. A security flaw in an early version of sendmail was used by the infamous Internet WORM that was launched about a decade ago by a grad student at Cornell, Robert Morris, Jr. The WORM spread rapidly to UNIX computers via the Internet and stopped them or slowed them to a crawl by filling up memory. Morris was later convicted and sentenced to a $10,000 fine, probation, and community service. Sticky bit: This used to be used on ordinary files to tell UNIX to keep the program in memory after it completed. This was done on often-used programs so that they would start quickly. Many versions of UNIX now ignore the stick bit for ordinary files as RAM is much faster these days. The sticky bit is still used on directories, such as /tmp. Use the following to see the permissions on /tmp: ls -ld /tmp The d option is used to tell ls to show the permissions on the directory itself, not on the contents of the directory. The permissions show up as the following: drwxrwxrwt The t on the end indicates that the sticky bit is turned on. The /tmp directory could be given these permissions in the first place by using: chmod 1777 /tmp Here the leading 1 says to turn on the sticky bit. The meaning of the sticky bit for a directory is that users who have write access to this directory can write their own files, but cannot write to, remove, or rename others' files. To be precise, only the following people can remove or rename a file in a directory like /tmp: the owner of the file, the system administrator, the owner of the directory, anyone who has been given write access to the file. Some file system details: In a typical UNIX file system, block 0 is the boot block containing info about booting the system. Block 1 is the superblock, which has info about the file system (such as the number of inodes, number of disk blocks, a pointer to the start of the free list of disk blocks, etc.). After block 1 comes a sequence of inodes (index nodes) and then the data blocks. Each inode contains information about a file including the permissions, time stamp, user id, group id, size, the list of the addresses of the first 10 data blocks, the address of the single index block (if needed), the address of the double index block (if needed), and the address of the triple index block (if needed). An index block simply contains a list of addresses of data blocks. (If it is a double or triple index block, it contains a list of addresses for further index blocks.) When you access a file by name, UNIX checks in the directory for a file by that name. The directory simply contains a list of names and inode numbers. Thus UNIX can find the inode number for the desired file. UNIX then retrieves the inode information from the inode with that number. Other Commands of use to a UNIX system administrator: who Show the IDs of users currently logged in. su - root su root Allows someone already logged in to get logged in as root (the superuser or system administrator). The version with the - gives you the environment (environment variables) of the root account while the second leaves your environment in place while logged in as root. Thus the first method is usually the one you want. shutdown Used to shut down a UNIX system. Do NOT just turn off a UNIX machine unless you have no other choice. It is quite possible to damage the file system by doing so! The command to use is something like: shutdown -h now Of course, the command can only be executed by the system administrator. man hier Gives you info about the UNIX hierarchy of directories. grep Used to search for a pattern or string. Typical examples: grep queue *.html grep -i queue *.html The first example looks for the string "queue" in all files ending in .html that are in the current directory. The second one is similar, but uses a case-insensitive search for the word queue. See the ps command below for how grep might be used in a pipeline. find This command helps the system administrator to locate files. It is more general and more powerful that the whereis command. For example, to find the location of core dumps (which are created when a program crashes due to a run-time error), the administrator might use: find / -name core This starts at /, the root of the directory tree, and finds all files named core (with matching lower case). The next likely step would be to check each such file to see if it is a core dump by using: file core If it is a core dump, it could be removed. This is one way to free up some disk space. One needs to be careful as there are likely to be files or directories named core that are NOT core dumps and that need to remain on the system. To find all html files starting at the current directory (indicated by a .), one might use: find . -iname "*.html" Here the iname option means to do a case insensitive find for matching names. If one is looking for all html files on the system, the above command might generate a lot of output, so the output could be redirected into a file: find . -iname "*.html" > WebFiles If the number of such files is really large, this command might take a while to run. Typically such commands would be run in the background so that one gets the UNIX prompt back and can do other work. The way to run a program in the background is to use an & at the end of the command: find . -iname "*.html" > WebFiles & You should only run programs in the background that don't require interactive input and that don't have output (or error output) to the screen. When you enter such a background command, the system will print a job number (probably 1) and the job's process ID number on the screen, in case you should need to kill the job off or make other changes to it. See below on how to kill a process. To check on the status of background processes, use the command: jobs kill Used to kill off a process. For example: kill -TERM 2345 kill -KILL 2345 kill -9 2345 The first sends a terminate signal to process 2345. If that doesn't work, the second one probably will as it is a "sure kill". The second is not as desirable in that it may not clean up everything properly; it just makes sure that process 2345 is wiped out immediately. The process ID numbers can be found using ps -aef, as shown below. The -9 option is the same as -KILL. You can only kill your own processes. The system administrator can kill off any process (including ones that the system cannot run without, which means that working as root is dangerous as it is all too easy to crash the system with one mistyped command). If you are logged in and your session somehow locks up, you can log in a second time, find the process ID number for your shell for your other login, and kill it off. The commands to use are something like this: ps kill -KILL If you get the process ID for your current login instead of the other one, it will just log you out. last This shows the users who have recently logged in, starting with the most recent. Commonly you only want to see a few lines of this and so might use: last -22 Some systems have a lastb command which allows the system administrator to see the last bad login attempts. This is useful to see if someone is trying to guess passwords in order to break in. mount Used to mount a removable file system (such as a CD-ROM, hard disk, or floppy disk) at some point in the directory structure. Note that a disk must be mounted in order to use it. umount Used to unmount a disk. NEVER remove a disk without unmounting it. UNIX is not forgiving about this like some other operating systems. (You are likely to corrupt the file system on the disk.) Note that you cannot unmount a disk if it is in use. sync Used to flush buffers. Several of these in a row are often used before shutting down the system (in order to be sure that all data has been written to disk). mkfs Used to make a new file system. fsck File system consistency check and repair. df bdf Report on disk usage. du Shows directory usage of disk space. file * Shows filenames and their types. head Used to show the first 10 lines of a text file (or files). Can also take a numeric option to give a different number of lines. Examples include: head .cshrc .logout head -22 /etc/passwd The first one shows you the first 10 lines of the 2 files. The last one shows the first 22 lines of the passwd file in /etc. tail This is similar to head, but shows the last so many lines of a text file (or files). finger ID Shows if person with this ID is logged on, the person's name, and if their account has been idle for a time. id Shows your user ID and your group ID. ps Shows what processes you are running. For example, here are some useful variations: ps -aef (shows all system processes) ps -aef | grep smith (shows smith's processes) Note the use of the pipe, |, in the last example. It sends the output of the ps command into the grep command, as the input to the grep command. Such pipelines can be very useful. It is a prime example of how simple UNIX commands can be combined to provide a helpful solution. You can have longer pipelines such as: ps -aef | grep smith | wc -l This one sends the lines of info on smith's processes to the word count program. The -l option tells wc to count the number of lines. In effect, then, this pipeline prints out the number of processes that smith has. (Be careful, though, since another user with ID smithr would also be counted as grep matches any line containing the letters smith right in a row.) mkdir mydir Create a subdirectory called mydir. rmdir mydir Remove the directory. Only works if the directory is empty. rm -R mydir A recursive remove. This removes the directory mydir and everything in it. alias This displays the aliases that are available to you. This is a feature of the C shell. Other shells may not have this. (The original Bourne shell did not have aliases, for example.) An example of what is displayed might be: h history l ls -lA !* | more sub ls -lA | grep ^d The first alias is h. It is an alias for the history command, which shows you the commands that you have entered most recently. The next one is my alias l to give a convenient long listing, piped into more so that I can read the output. The last one, sub, does a long listing and pipes the output into grep, where we look for lines that start with a d, that is, directory lines. Thus, my sub alias prints out the names and other listing info on subdirectories. When using the C shell, one can set up his/her own aliases by adding them to the .cshrc initialization files in the account's home directory. For example, mine contains: alias h history alias sub 'ls -lA | grep ^d' alias l 'ls -lA \!* | more' Other than some use of quotes, this is essentially what we saw above. UNIX quoting can be tricky. Consult a good UNIX reference for more on double quotes, single quotes, backquotes, and the backslash. Shell variables The C shell lets you create variables to hold useful data. In fact, it has a number of shell variables already there for you. Use the following to see the list of shell variables and their values: set You can create a new shell variable and give it a value as in: set files=/usr/bin This creates a shell variable called files and gives it the value /usr/bin. You can see its value by using: echo $files You might use the variable to do something like this: ls -l $files/g* This would list all files that start with g in the /usr/bin directory. You can change the value in the variable by using set again as in: set files=/usr/include/g++ You can put the empty string into a shell variable as follows: set files You can also totally remove the variable from existence with: unset files Environment variables These are like shell variables, but use all upper case for the variable names. There is also a difference if a UNIX script tries to access these variables. Inside the script, the old environment variables are available; the shell variables aren't. To see your environment variables and their values use: env To create an environment variable and give it a value use something like this: setenv DATA /users/carlson/public_html/data_dir You can use this variable, either at the command line or in a script, by doing something like: cd $DATA This would change the current working directory to that given by the value of the DATA variable. To give the variable a new value, just use setenv again as in: setenv DATA /users/carlson/mydata To remove the variable from existence use: unsetenv DATA References: Modern Operating Systems, by Andrew S. Tanenbaum. Prentice-Hall (1992). Chapter 7 is a case study on UNIX. Modern UNIX, by Alan Southerton. Wiley (1993). Operating System Concepts, fifth ed., by Silberschatz and Galvin. Addison-Wesley (1998). Chapter 21 is a case study on UNIX and chapter 22 is a case study on Linux. If you are interested in the internals of these operating systems, this is for you. "Understanding Filesystems", by Emmett Dulaney, in Sys Admin, a journal for UNIX system administrators. See pages 40 - 51. I've lost track of which issue this article was in. In fact, I've lost all of the old issues. UNIX System Administration Handbook, second ed., by Nemeth, Snyder, Seebass, and Hein. Prentice-Hall (1995). Linux: The Complete Reference, second ed., by Richard Peterson. Osborne McGraw-Hill (1998). See the links on our CS 330 Web page for more UNIX information.