Moving on to Objective section 2 in the SCSA Solaris 10 exam I, the exam requires certain knowledge of the file systems.
Explain the Solaris 10 OS directory hierarchy, including root subdirectories, file components, and file types, and create and remove hard and symbolic links.
Daniel Quinlan has a detailed explanation of UNIX directory hierarchies that goes far beyond what will be expected of you in the SCSA exam. If you ever question what a directory is (or should be) for, check that page. For the SCSA exam, knowing the directories in the / root filesystem should be adequate, with a few additions. Sun has a page describing default Solaris file systems, too.
/ — root directory, the top of the.. bottom of the tree (even though we always list it at the top)
/bin — symbolic link (more later) to /usr/bin, where user executables live
/cdrom — optical drives (CDROM/DVD) mount under this directory
/dev — device files (like terminals, disks, mouse, serial ports, etc.). This is where UNIX systems put devices files, but Solaris keeps the real files in /devices and links to them from /dev.
/devices — the real deivces referenced by links in /dev. This seems silly at first, but if you look in the /devices directory you’ll see that, while it is well organized (just a few directories and files), the naming scheme can quickly give you a headache. Solaris hides this complexity from us by masking different architectues (PCI vs SCSI, for example) and IO structures on different types of Sun hardware to simple, consistent naming schemes in /dev. As an example, the device /dev/dsk/c0t0d0s0 is typically the first slice of the first disk in a system. It’s real name is /devices/pci@1e,600000/ide@d/sd@0,0:a on a Sun V210. It is possible (and likely) that this specific path would be different on different boxes, so I know I’d rather keep up with /dev/dsk/c0t0d0s0.
/etc — configuration files for the operating system and some applications.
/export — This is where directories and files to be exported live. In the “typical” situation (whatever that is), user home directories live on an NFS server in /export/home and on a remote system, when a user logs in, their home directory is mounted in /home on that system. In the real world, fewer people use NFS mounted home directories and administrators tend to put home directories on local systems in /export/home.
/home — Target location for automounted home directories for users, if used.
/kernel — Contains the guts of Solaris, the operating system core. Should have a big scary sign on it that says “Do not touch.”
/lib — Link to /usr/lib which holds the dynamically linked libraries for Solaris and other applications. If you are familiar with Windows systems, these are comparable to DLL files.
/lost+found — This directory exists by default on all Solaris filesystems (meaning disk drive slices, created when newfs runs) and is used by fsck to put reclaimed files when checking and repairing the filesystem.
/mnt — Empty directory that can be used as a mount point for a filesystem.
/net — I honestly don’t know what goes in here, if anything. Network devices are in /dev and /devices and the network configuration is contained in /etc. It’s empty on the Solaris 10 systems I’ve checked. It could be a compatibility issue. Searching for the keyword ‘net’ on google is pretty silly, though.
/opt — A place for additional (i.e., optional) software binaries to be installed.
/platform — Each (supported) Sun platform (like a V440 or E10K) has a directory here. In each of those is a platform specific set of files, libraries, kernel tweaks, etc. The boot loader (ufsboot) for each platform is located here.
/proc — A virtual filesystem (doesn’t use hard drive space) that contains a directory tree for every running process. It’s interesting to look around here.
/sbin — Statically linked binaries for some critical system executables. If the system is in trouble and the /lib filesystem cannot be mounted, then the executables in /usr/bin won’t work (they are smaller binaries that depend on dynamically linked libraries). The executables in /sbin are statically linked (they are self contained and will run without any other dependencies). Note in /etc/passwd that root’s login shell is /sbin/sh — this should not be changed there since this can prevent root from logging on in case of an emergency. Look at the difference in size between /sbin/sh and /usr/bin/sh… dynamically linked libraries save tons of space, but at some cost.
/tmp — As the name implies, this is a place for files to live temporarily that will not persist after the system reboots. In recent versions of Solaris, this filesystem is mounted on the swap slice, which means a separate slice is not needed.
/usr — I like Quinlan’s description of the usr tree as containing “sharable, read-only data.” In this sense, it should contain program files (like in /usr/bin) and libraries (/usr/lib). Lots of applications install their files in this tree (/usr/java or /usr/j2se for Java, /usr/apache for the Apache web server, /usr/perl5, and so on). In reality, lots of software packages install themselves into a directory in /usr or /usr/local including log files and other read-write files. It would be cleaner to set things up to make /usr was read-only.
/var — Consistent with Quinlan’s description, /var contains files that vary over time (administrative and log files, user mail, etc.). /var/tmp is a temporary directory that will persist following reboots.
/vol — Related to the volume management daemon (vold). From this document, “To view the media that has been inserted during a workstation session, list /vol/dsk.”
/xfn — Related to the Federated Naming Service and is way, way out of the scope of this exam.
A structure called an inode stores all of the information about a file. A file is owned by one user and is associated with one group. Based on the group and user ownership, file access permissions are used to control who can read, write, or execute a file. This information, plus timestamps and other filesystem innards, are stored in the inode of a file.
There are numerous filetypes possible in a Solaris system. The file command is a great way to determine what a file type is. It is simple to use: file filename — if the file is executable or ascii text, file will let you know. The file command uses the /etc/magic file to determine what a file is and is just an ascii file itself (I just ran file /etc/magic to be sure.. major annoyance when viewing a binary file).
Symbolic links are bread and butter for system administrators. Here is a description symbolic links is and how to make one. Here is the same information for hard links. In my experience, symbolic links are much more commonly used than hard links. Essentially, a hard link is a duplicate inode that points to the same file as another inode. The actual file is not deleted until all of the hard links are deleted. Hard links only work within the same filesystem/slice (they can’t span from one mounted filesystem to another) and a hard link looks just like a file. Symbolic links can span filesystems and show up in a long listing (ls -l) conveniently showing where the link points to.
Deleting either type of link is simple.. just use ‘rm’ like it is a file. In the case of a symbolic link, the original file will never be affected by rm. If all hard links to a file (including the original inode created with the file) are removed, the file will be deleted.
This entry was posted
on Monday, November 14th, 2005 at 3:04 pm and is filed under SCSA I Solaris 10.
You can follow any responses to this entry through the
RSS 2.0 feed.
Both comments and pings are currently closed.
July 6th, 2006 at 6:27 am
The /net mount point can be used to auto mount shared NFS