CSC128: Introduction to UNIX

System Administration 1

System Administration

Unix systems usually have one or more system administrators (sysadmins).  Their main tasks are to maintain the system and ensure the integrity and safety of the data.  If the system goes down, valuable work time is lost and the sysadmin will be fired.  If the data is corrupted or erased, valuable work is lost and the sysadmin will be fired.

On a large UNIX system, consisting of many machines, this can be a full-time job for an entire team of system administrators.  On a personal, home system, the user must perform her own administrative tasks.

The Superuser

The Superuser (also known as root) is the system account that is used for system administration.  Root has special abilities to help maintain the system-- for example, permissions don't apply to the Superuser, who can read or modify any file on the system.  This makes the root account a dangerous one to use.

If you type:
user@machine:~ $ rm -rf /
Only files you have write permissions on will be removed.  You can't easily break the entire system with a misplaced command.

However, if you are root and you type:

root@machine:~ # rm -rf /
You will start removing everything in the entire filesystem.

DO NOT operate in the root (Superuser) account if you don't NEED to for what you're doing.

Usually, one does not log into a machine as root.  In many systems, it is not allowed.  It is almost never allowed from remote connections.  To log in to the root account, log in to your own account and then switch users to the root account:
user@machine:~ $ su

root@machine:/home/students/a/abear/ #

Another way to become root is to set the system to single-user mode .
(More on that later...)

Sysadmin Tools

System administration tools are usually kept in a different place from other files and executables:
system data files


system administration utility programs

The Boot Process

Before a UNIX system is ready to be used, it must first set up a number of things, including the kernel, the filesystem, daemon processes, etc..  This is called booting.  (This term comes from the old phrase, "pull oneself up by one's bootstraps.")

See Slackware Startup Process for an explanation on how Slackware (Our labs distribution of Linux, starts up).  Here is an example boot process, specific to the machines in the Linux Lab:

  • power On Self Test (POST). Performed by the BIOS (Basic Input Output System) once power is supplied. At this time the BIOS looks for the devices such as keyboards, mice, disks etc. that are defined in the BIOS'es EEPROM (Electrically Eraseable Programmable Read Only Memory). An EEPROM can hold configuration settings even with a complete lack of power (such as a dead battery). The BIOS is accessible by a keyboard combination at startup.
  • Upon successful POST system reads Master Boot Record.
    • on Linux systems, this is lilo  (or grub sometimes in newer distributions...)
    • loads the kernel into memory and starts its execution (on Linux systems, this is usually /vmlinuz or /boot/vmlinuz
  • kernel starts the init process
  • init process reads and executes the commands in /etc/inittab , including the appropriate rc scripts in /etc
  • rc (run command) scripts
    • /etc/rc.d/rc called by init, which then calls the scripts in the directory corresponding to the desired runlevel.  (i.e. runlevel 1: /etc/rc.d/rc0.d)
      • runlevel 0: halt 
      • runlevel S: (Not really a runlevel, system initilization script /etc/rc.d/rc.S script is run)
      • runlevel 1: single-user mode, no network
      • runlevel 2 and 3: multi-user mode, with network 
      • runlevel 4multi-user mode, with network and xdm
      • runlevel 6: reboot
    • Start scripts begin with an S ,  Kill scripts begin with a K (IF you have any Sys V scripts) .
  • File system checks:  fsck is usually run on all mounted file systems to ensure their integrity.  If the system was not shut down properly, this may take a very long time.
Note that this is entirely system-dependent.  The runlevels may be defeined differently on different systems, even different Linux systems.  BSD-style systems often don't even use runlevels; they only have single-user mode and multiuser mode.


To properly shut down a UNIX system, issue the shutdown command.  This will warn all logged-in users of the impending shutdown, wait a specified period, and then start executing the shutdown procedure (with the appropriate runlevel scripts).

If the system is not allowed to shut itself down properly, data may be lost;  not just your data, but that of those people who just happen to be logged in at the same time.  Pulling the power on a running UNIX box is a last resort-- if you MUST do it, use the wall (warn all) command to warn users to log out before you pull the plug.

root@machine:~ #  /sbin/shutdown -h now
Start the shutdown process now.  A warning will be sent to all logged-in users, not that it will do them much good.

root@machine:~ #  /sbin/shutdown -h -t 600
Start the shutdown in 600 seconds (10 minutes).  A warning will be sent to all logged-in users, informing them of the impending system halt in 10 minutes.

root@machine:~ #  /sbin/shutdown -h 12:00am
Start the shutdown at midnight.  A warning will be sent to all logged-in users, informing them of the impending system halt at midnight.

root@machine:~ #  /sbin/shutdown -r now
Start the reboot process now.  A warning will be sent to all logged-in users, not that it will do them much good.


System maintenance is often done while in single-user mode.  In single-user mode, only the system console is enabled;  some filesystems may not be mounted.  

The advantage of performing maintenance in single-user mode is simply that no one else can be logged in.  If the filesystem needs to be backed up or fixed, or some new hardware needs to be tested, etc., then single-user mode is a good place to work, knowing that no one else is trying to use resources that the sysadmin needs exclusive access to.

To change to single-user mode use the
telinit command (this /etc/inittab specfies "S" as the single-user mode runlevel):
root@machine:~ #  telinit S

To change back to multiuser mode use the telinit command (3 is the desired runlevel;  it may be different on different systems. (see /etc/inittab ):
root@machine:~ #  telinit 3

Managing Users:
The system administrator is responsible for adding and managing users of the system. The file that (on simple systems) containing the users and information about them is /etc/passwd. More complex systems are available such as PAM (Pluggable Authentication Module) which will handle a wide variety of authentication services. PAM is beyond the scope of this class.

The 7 fields, colon delimited, in the password file are as follows:

login name: encrypted password:UserID:GroupID:GeneralComment:HomeDir:LoginShell

In the above example, notice how the password field is just an x. This means that the system is using shadow passwords. If the system was not using shadow passwords you would be able to see an encrypted password in the /etc/passwd file. The reason that Unix/Linux systems have gone to shadow passwords (stored in /etc/shadow) is that the passwd file must be world readable, to enable an unknown user to authenticate to and login to the system. This creates the problem that if users have weak passwords, anyone having any access to the system can see the password file and could run a password cracking program on the system's encrypted passwords. The /etc/shadow file is not world readable, therefore helping protect users' passwords.

To add a user to a system the administrator can use one of many utilities such as useradd. See the man page for the useradd utility. Notice that there are a lot of switches to the useradd utility. If particular switches are not given then the system's default values are used. When useradd is run, a new home directory will be created for the user. A user must be the member of at least one group, and the group specified using useradd is the initial group that the user belongs to when they login. Here is an example:
useradd -g students student1
This creates a new account with the username student1 and sets the initial group for the student to students. The root user can also use the vipw utility to edit the /etc/passwd file.


The group information on a system is stored in the file /etc/group and if it has been created, group shadow passwords are located in /etc/gshadow . Group information is always read at initialization time by a login shell only, so if your xterm is not a login shell or you have made a change to the group file, you must re-login to a login shell to have your group information re-initialized.

The fields in the /etc/group file are as follows:
Group_Name:Group_Password:GID:User_list(comma delimited)
If there is an x in the group password field that means that there is a corresponding file named /etc/gshadow that is holding a shadow password for that group. If a group has a password and the user is NOT in User_list and the user knows the password they will be challenged and will be allowed to newgrp to the group. If they are in User_list in a group with a password they will not be challenged for a password.

Interestingly, if a user DOES know the password to a group and tries to chgrp a file, they will be denied and will not be offered a chance to enter a password. If they first newgrp to that group, and then pass the password challenge, they will be able to chgrp the file with no password challenge, since they are currently in the group.

The command groupadd will add a new group to the system (only root can do this). The definition of the groups is found in the file /etc/group .

The fields in the file /etc/group are:
group name:password:GID (group ID):user list comma delimited
Note that when you run a command such as newgrp csc128 that you are actually creating a sub shell that is logged into another group. To get out of that group, you type exit to get out of that sub-shell that was opened for you as another group ID.

The command: id will tell you what group you are currently in. It is also common to create a file and see what the group is for a file that you just created. Note that your initial login group is set in /etc/passwd , and that your initial group that is set in /etc/passwd does not have a corresponding entry in /etc/group. In other words, /etc/passwd overrides the /etc/group file to place you in your initial login group.

Group Utilities

id tells you what group you are currently in and what groups you belong to.
groupadd root uses this command to add a group to the system. This command will add an entry to the /etc/group file
chgrp changes the group ownership of a file.
groups tells you what groups you belong to.
newgrp [group] logs you into another group that you belong to. If you just enter the command newgrp with no group name it will make your group membership your initial group.
vigr will edit the group file.
gpasswd provides the system administrator the ability to delegate the administiration of the /etc/group and /etc/gshadowfile. Additionally it allows the administrator to allow other users to administer groups. So, Jason has given me administrative rights to the csc128-class group.

The command that he used to make me the administrator of the group was gpasswd -A smauney csc128-class. Only root can make someone the administrator of a group and after that that user can change the password for the group or add and remove users from that group.

/etc/skel directory:
Typically, in addition to system defaults, you will want to add certain files and/or directories into each of your users' home directories. This is done using the /etc/skel directory. In most systems, by default, anything contained within the /etc/skel directory will be copied into a new users new home directory.

/etc/motd This file contains the message of the day. The system administrator can edit this file and this is what you see when logging on.

/etc/aliases file. This file contains the aliases for the sendmail program. If you edit a new entry into this file and then issue the command newaliases a new 'group' of users can be mailed.

.forward file. If you put a file in your home directory called .forward . All of your mail will be forwarded to the e-mail address specified in the .forward file.

Log files:
Most log files located in /var/log
xferlog This is the FTP transfer Log
cron is the cron proceesses log
httpd subdirectory of web server logs.
lastlog -current system happenings.
As you install more software, it will have logging too.

The file /etc/fstab shows the file system table on each machine. Check out the file system on one of your local machines.

#Device		mountpoint	FStype		Options    dump fsckorder	

/dev/hda2       swap            swap            defaults   0   0
/dev/hda3       /               reiserfs        defaults   1   1
/dev/hda6       /opt            reiserfs        defaults   1   2
/dev/hda7       /usr            reiserfs        defaults   1   2
/dev/hda1       /boot           ext2            defaults   1   2
/dev/hda5       /var/log        reiserfs        defaults   1   2

/dev/hdc        /cdrom          auto            ro,noauto,user,exec 0 0
/dev/hdd4       /Zipdrive       auto            noauto,user 0   0
/dev/fd0        /floppy         auto            noauto,user 0   0

none            /proc           proc            defaults   0   0
# End of YaST-generated fstab lines
helios:/export/staff      /mnt/helios/staff     nfs     defaults 0 0
helios:/export/students   /mnt/helios/students  nfs     defaults 0 0
helios:/export/news       /mnt/helios/news      nfs     defaults 0 0
csc:/export/mail          /mnt/csc/mail         nfs     defaults 0 0
sol:/export               /mnt/sol              nfs     defaults 0 0
helios:/export/Office52   /mnt/helios/office52  nfs     defaults 0 0

su command
You can use the command su to 'switch user' to root or any other user that you happen to be on the system. Once you have used the su command you must then exit.

The file /etc/mtab shows the currently mounted file systems on each machine. Check out the mount table on one of your local machines.

/dev/sda3 / ext3 rw 0 0
/dev/sda1 /boot ext3 rw 0 0
/dev/sda5 /opt ext3 rw 0 0
/dev/sda6 /usr ext3 rw 0 0
/dev/sda7 /var/log ext3 rw 0 0
/dev/sda8 /export/staff ext3 rw 0 0
/dev/sda9 /export/students ext3 rw,usrquota,grpquota 0 0
devpts /dev/pts devpts rw,gid=5,mode=620 0 0
proc /proc proc rw,gid=200 0 0

/proc is the process information pseudo-filesystem this is where many currently running processes 'mount' their processes. Run man proc to see an explanation of what /proc is. Basically is is never written by you, but instead is a method by which processes can interact with the kernel.


located in /dev
regular files
directory files
FIFO Special


join file1 file2
Joins lines of two files on a common field.   (By default, this is the first field.)
user@machine:~ $ cat jfile1
1 d8g
2 dg
3 dig
4 diug
5 dog
6 doog
7 dooog
8 dug
9 duig

user@machine:~ $ cat jfile2
1 a
2 hello
3 is
4 test
5 this
6 world

user@machine:~ $ join jfile1 jfile2
1 d8g a
2 dg hello
3 dig is
4 diug test
5 dog this
6 doog world

user@machine:~ $