Managing users and data are two of the most important categories of system administration duties. We will look at what it means to add and remove both people and data.
$ w 06:44:59 up 2 days, 1:45, 6 users, load average: 0.00, 0.00, 0.05 USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT testtest tty2 - 06:41 2:41 0.00s 0.00s -bash testtest tty3 - 06:42 1:57 0.00s 0.00s -bash $ who testtest01 tty2 2008-06-04 06:41 testtest02 tty3 2008-06-04 06:42 [fsucs@acer1 Slides]$
For example:
user1:f9cPz5ilB5N0o:501:501:USER1:/home/faculty/user1:/bin/tcsh langley:$6$k6H7I90O5bOvcUi/$cCYlXCnSkTj6cZnFV35FCpO.xFXqQMVKExjnA qfFi2tO53pxDdx1lKxxd30eFXEYWgaq3x/.M7os3ehrFpL1W0:USER1:/home/fac ulty/user1:/bin/tcsh
root:x:0:root bin:x:1:root,bin,daemon daemon:x:2:root,bin,daemon sys:x:3:root,bin,adm adm:x:4:root,adm,daemon tty:x:5: disk:x:6:root lp:x:7:daemon,lp mem:x:8: kmem:x:9: wheel:x:10:root
mkdir /home/faculty/user1 cp /etc/skel/.[A-Za-z]* /home/faculty/user1 chmod 700 /home/faculty/user1 chown -R user1:user1 /home/faculty/user1 ## OR, IF YOU DON'T HAVE THE ':' SYNTAX ## chown -R user1 /home/faculty/user1 chgrp -R user1 /home/faculty/user1
You can do these steps manually, use a vendor-supplied script/program, or write your own.
Also, there are often GUIs, or you can use webmin.
Most Unix/Linux distributions now use a ``shadow'' password file in addition to the main password file -- a shadow password file moves the encrypted password out of the publicly-readable /etc/passwd file and into a root-accessible-only file. Why is this a good idea? See ``John the Ripper'' or ``LOPHTCRACK'' -- any hacker can try to systematically guess passwords with such programs.
Also allows for creation of new fields to support password rules, password aging, etc. Examples:
Removing Unix/Linux users -- you can just undo the steps above!
However, it can be problematic to find all files owned by the user, if you gave them access to directories outside of their home directory.
Or, find / -user USERNAME -print -- but that only works as long as the username is still in the password file. Otherwise, you need to use find / -uid UID -print
You usually will want to archive (or otherwise preserve) the user data. These days, a memory stick can be one of these ways to give users permanent copies of their user data.
user1:x:501:501:USER1:/home/user1:/sbin/nologin user2:x:502:502:USER2:/home/user2:/bin/false
You can put text into /etc/nologin.txt to modify the message from the nologin program, but it isn't customizable per user.
/etc/shells keeps a list of trusted shells users can change to via ``chsh'' /etc/shells is also consulted by other programs to make sure that a shell is a ``legitimate'' one for that system; in the past, even sendmail used to consult this file.
In general, this file is becoming much less used than it was in the past. Here's a current Fedora /etc/shells, which is very minimalistic:
$ cat /etc/shells /bin/sh /bin/bash /sbin/nologin
On a busy machine, you might create a cron script to make backups, something like:
cp /saved/passwd.1 /saved/passwd.2 cp /saved/passwd.0 /saved/passwd.1 cp /etc/passwd /saved/passwd.0
[root@sophie root]# pwck user adm: directory /var/adm does not exist user gopher: directory /var/gopher does not exist user ident: directory /home/ident does not exist user pcap: directory /var/arpwatch does not exist user vmail: directory /home/vmail does not exist pwck: no changes
You can occasionally run password crackers to see if your users are putting in obvious passwords (notice this is less of a problem if you require them to have good passwords).
Sometimes it is desirable to create limited accounts that serve only a single purpose, such as with the old "sync" user login, or as we saw with the "postgres" account.
Turning to the data management side, we have seen many new filesystems in the last few years: zfs, nilfs, btrfs, ext4 for example, and we have seen neat ideas such as FUSE which give users the ability to handle items structured as a filesystem in user-space, such as sshfs provides.
Traditionally, we have created our device files in /dev. Device files provide a connection between a device and standard UNIX system calls referencing those devices.
For UNIX filesystems, this has been a steady and monotonic weakening of connection between physical disk drive partitions and their eventual mount point(s).
Identified by a ``major'' and a ``minor'' device number, as well as type ``b'' (block) or ``c'' (character, or raw device) -- these examples are from Linux:
root# ls -l /dev/ [ ... ] brw-rw---- 1 root disk 3, 0 Sep 9 2004 hda brw-rw---- 1 root disk 3, 1 Sep 9 2004 hda1 brw-rw---- 1 root disk 3, 10 Sep 9 2004 hda10 brw-rw---- 1 root disk 3, 11 Sep 9 2004 hda11 brw-rw---- 1 root disk 3, 12 Sep 9 2004 hda12 brw-rw---- 1 root disk 3, 13 Sep 9 2004 hda13 brw-rw---- 1 root disk 3, 14 Sep 9 2004 hda14 brw-rw---- 1 root disk 3, 15 Sep 9 2004 hda15 brw-rw---- 1 root disk 3, 16 Sep 9 2004 hda16 brw-rw---- 1 root disk 3, 17 Sep 9 2004 hda17 brw-rw---- 1 root disk 3, 18 Sep 9 2004 hda18 brw-rw---- 1 root disk 3, 19 Sep 9 2004 hda19 brw-rw---- 1 root disk 3, 2 Sep 9 2004 hda2 brw-rw---- 1 root disk 8, 0 2010-09-27 08:58 sda brw-rw---- 1 root disk 8, 1 2010-09-27 08:58 sda1 brw-rw---- 1 root disk 8, 2 2010-09-27 08:58 sda2 brw-rw---- 1 root disk 8, 5 2010-09-27 08:58 sda5 [ ... ]
One task that is important for administrators but rarely to users is that of fsck: file system consistency checking. As a system administrator, running fsck can be one of the more exciting tasks after an unclean shutdown -- use the -y option for fastest runs.
Filesystems have to exist somewhere: they can be in memory, such as a ``RAM'' filesystem, they can be on a hard disk drive, or more exotic venues. But the ones that system administrators generally care the most about are those that are on hard disk drives or SSDs. While there has been quite a bit of movement to add logical layers to the device management process, we still use partitions directly to host filesystems --- just take a look with df on your systems.
/dev/sda1 241116 75549 153119 34% /boot
Today, the most common way for /dev to be populated is via an automated system, such as udev, which enumerates the devices that it finds and creates appropriate entries in /dev.
As to device numbers, the naming conventions and major/minor device numbers are very machine-specific. See text for some specifics on disk and tape device names.
int mknod(const char *pathname, mode_t mode,
dev_t dev);
DESCRIPTION
The system call mknod creates a filesystem node
(file, device special file or named pipe) named
pathname, with attributes specified by mode
and dev.
[ ... ]
The file type must be one of S_IFREG, S_IFCHR,
S_IFBLK, S_IFIFO or S_IFSOCK to specify a normal
file (which will be created empty), character
special file, block special file, FIFO (named
pipe), or Unix domain socket, respectively.
(Zero file type is equivalent to type S_IFREG.)
If the file type is S_IFCHR or S_IFBLK then dev
specifies the major and minor numbers of the newly
created device special file; otherwise it is
ignored.
Note that the naming conventions vary even between different versions of the operating system. Solaris, for example, provides backwards compatibility with the old names via soft links.
Solaris->ls -l /dev/sd0a /dev/rsd0a
lrwxrwxrwx 1 root root 13 May 4 1995 /dev/rsd0a -> rdsk/c0t3d0s0
lrwxrwxrwx 1 root root 12 May 4 1995 /dev/sd0a -> dsk/c0t3d0s0
Solaris->ls -l rdsk/c0t3d0s0 dsk/c0t3d0s0
lrwxrwxrwx 1 root root 86 May 4 1995 dsk/c0t3d0s0 ->
../../devices/iommu@0,10000000/sbus@0,10001000/espdma@4,8400000/
esp@4,8800000/sd@3,0:a
lrwxrwxrwx 1 root root 90 May 4 1995 rdsk/c0t3d0s0 ->
../../devices/iommu@0,10000000/sbus@0,10001000/espdma@4,8400000/
esp@4,8800000/sd@
Solaris->ls -l /dev/sd0a /dev/rsd0a lrwxrwxrwx 1 root root 13 May 4 1995 /dev/rsd0a -> rdsk/c0t3d0s0 lrwxrwxrwx 1 root root 12 May 4 1995 /dev/sd0a -> dsk/c0t3d0s0 Solaris->ls -l rdsk/c0t3d0s0 dsk/c0t3d0s0 lrwxrwxrwx 1 root root 86 May 4 1995 dsk/c0t3d0s0 -> ../../devices/iommu@0,10000000/sbus@0,10001000/espdma@4,8400000/ esp@4,8800000/sd@3,0:a lrwxrwxrwx 1 root root 90 May 4 1995 rdsk/c0t3d0s0 -> ../../devices/iommu@0,10000000/sbus@0,10001000/espdma@4,8400000/ esp@4,8800000/sd@3,0:a,raw
Luckily, the actual naming convention that counts is the one that is used by the various sysadmin tools (fsck, mount, etc.).
As mentioned earlier, UNIX symbolic links are a very useful system administration tool.
As previously mentioned, symbolic links are nothing but a regular file with a bit set to indicate that it is a symbolic link; the contents of the file are the link value itself:
[langley@sophie Slides]$ ln -s /etc/passwd [langley@sophie Slides]$ ls -l passwd lrwxrwxrwx 1 langley langley 11 Jan 24 12:01 passwd -> /etc/passwd
setuid and setgid on executables -- the effective UID and GID of the user executing the program temporarily becomes the UID and GID of the owner of the file, if the suid and guid bits are set (``chmod 4xxx'', ``chmod 2xxx'', ``chmod 6xxx'', ``chmod u+s'', ``chmod g+s'', etc. -- see ``man chmod'' for details).
# ls -l /usr/lib/sendmail -r-s--x--x 1 root sys 397768 Nov 24 1998 /usr/lib/sendmail
Old semantics: On a plain file, the sticky bit indicated that the binary should remain in memory after the last user finishes executing the text segment -- the program ``sticks'' in memory. Typically only settable by root and used to keep commonly-used programs in memory for quicker response.
This older use of the sticky bit has pretty much fallen out of use with quicker machines and kernels with better memory models.
On a directory, the sticky bit still does mean something useful (from ``man -s 2 chmod''):
If a directory is writable and has S_ISVTX (the sticky bit) set, files within that directory can be removed or renamed only if one or more of the following is true (see unlink(2) and rename(2)):
- the user owns the file
- the user owns the directory
- the file is writable by the user
- the user is a privileged user
Example: shared writeable directories - /tmp and /var/spool/mail
drwxrwsrwt 3 bin staff 512 Jan 27 11:40 /tmp
Most Unix kernels and file systems such as those for Linux and OpenSolaris extend the 9-bit ``rwxrwxrwx'' permissions to generalized access control lists (ACLs). You can control file access with more flexibility, using commands like ``aclget'', ``aclput'', ``setfacl'', or ``getfacl''.
UNIX directory permissions:
Filesystems can also be built over logical devices which might reside on hardware that doesn't directly resemble the logical construction.
One approach is that of LVM, logical volume management. The idea here is to press physical volumes into a system of logical drives. We will talk later in the semester in some detail about LVM.