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.
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 manually 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, there 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) -- 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 usually use some sort of partitioning scheme (MBR and GPT being the two most common) to host filesystems --- just take a look with df on your systems.
/dev/sda1 241116 75549 153119 34% /boot
The naming conventions and major/minor device numbers are very machine-specific. (The good news is that LFS is using the newish and very native devtmpfs scheme.)
Places to look in the kernel sources:
On modern Linux machines, MAKEDEV is a binary or a shell script (Debian, for instance, uses a shell version very similar to the old BSD version), usually located in /sbin (in the old days, this program was often in /dev!) Look at the version from Mint 8.0: MAKEDEV.
As a shell script, typically /sbin/MAKEDEV would call the program mknod, which was a wrapper around calls to the mknod(2):
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.