Linux Directory Trees
Important to solving many problems in Linux is understanding where files are located in the directory structure. There is, however, no “absolute” or “perfect” directory structure; since Linux is so configurable, the same files can be put in literally any place and everything will still work. The home directory for the user joebob will customarily be /home/joebob, but can be set to be /.joebob. In order to prevent everyone from being constantly confused, however, a general standard was formed.
Unlike some other operating systems, Linux does not have all of its files in one enormous, messy directory. The files are distributed neatly, and once you have a basic understanding, it is easy to find and modify any file you wish. This article will go through the directory tree in alphabetical order by directory name with references to other directories.
The first directory is /bin which is short for binary, the file format of most executables. Basic executables for commands, such as ls, sync, rm and cat, are contained in /bin. Other directories containing binary files are /usr/bin/, /usr/X11R6/bin, /usr/local/bin and ~/bin.
The next directory is /boot. Not all distributions have this directory. If present, it usually contains kernels and boot maps for booting. I keep kernels in the / directory.
Next is /cdrom, where the CD-ROM drive is mounted in some distributions. Others may mount it in /mnt/cdrom.
Next is the /dev directory, which contains many files (ls shows 1041 on my machine). These files are device files (and sometimes FIFOs and other files, such as the text /dev/sndstat) which allow you to access devices. These are not actual drivers; they are just interfaces to the devices. Important files such as /dev/mixer and /dev/fd0 are stored here.
Next is the directory /etc, a very important directory indeed. It contains data files for many programs, including the configuration files for LILO. The kernel may save sound device configuration to /etc/soundconf. Scripts run when Linux starts up are usually kept in /etc/rc.d. The way files are set up in rc.d changes in different distributions. Another important file is /etc/inittab which contains some system settings, such as run levels and what happens when ctrl+alt+del is pressed. To keep anyone from rebooting my machine, I set ctrl+alt+del to run amp and play an mp3 file. Many servers have commented out that line to prevent the machine from being rebooted by unauthorized users. Another important place is /etc/X11, which can contain your XF86Config file; however, this file may be in many other locations. Also in this directory is the subdirectory /etc/xdm, in which you can customize your XDM login for some amazing looks. (Refer to http://torment.ntr.net/xdm/ for more information.)
Next is the directory /home. This directory contains home directories for users. The subdirectories /home/ftp and home/http may be here for use by their respective daemons connect.
The directory /lib, like /bin, contains basic executables and the basic libraries. The directories /usr/X11R6/lib, /usr/lib and /usr/local/lib are other repositories of libraries.
Sometimes you will see the directory /lost+found. This directory may contain inodes which were somehow “lost” in the file system with no other location in which to be placed. An inode is the data structure on disk in which a description of a file's attributes is stored.
Some block devices, such as floppy and CD-ROM drives, are mounted in the /mnt directory. Some distributions use /cdrom for CD-ROMs and /mnt for floppies, while still others use /mnt/cdrom for CD-ROMs and /mnt/floppy for floppies.
Next is /proc, quite a curious directory. Notice that as root you cannot edit any of its files. (If you can, it is a bad thing.) This directory contains kernel data and has its own file system (/proc) and strangely enough, typing du in /proc returns the value 0. The kernel stores all sorts of data in this directory, which is why you shouldn't edit it.
The /root directory is the home of root. Often, in /root, you will find programs or scripts written by root that perform some task for the machine.
The /sbin directory contains binaries that normal users generally don't need—binaries meant for superusers. Other sbin directories are /usr/sbin, /usr/local/sbin, etc., which contain ldconfig, mke2fs, quotaon and other programs not needed by regular users.
The /tmp directory is unique in that it has write permissions set for everyone. This directory contains temporary files and FIFOs for many programs.
Now we come to /usr, probably the largest directory on your computer. /usr contains many files for users (as the name implies) and their programs. It has subdirectories similar to those in the root directory. The directory /usr/X11R6 contains files for X. Here you will find man pages, executables, libraries and include files for X. (As a side note, the X include files in /usr/include are linked to /usr/X11R6/include/X11.) In /usr/bin there are many more executables such as passwd, nice and zgrep. The directory /usr/doc may hold help files for the system. The /usr/lib directory contains more libraries, and directories for different programs that don't contain libraries for those programs but rather data files. The next subdirectory is the all-powerful /usr/local. If you compile and install a program, it will most likely be installed in /usr/local. Those who did not upgrade distributions and wanted to install glibc by hand (me), found that glibc was installed in /usr/local/include instead of /usr/include as it is on newly installed systems. Many programs, including our favorite the GIMP, will install some data files in /usr/local/share. Since it contains programs you install, /usr/local will probably become your favorite directory. /usr/src is where the kernel source should be kept.
Finally, there is the /var directory in which you will find e-mail spools, printer spools, files containing scores for games and nothing else of much interest.
Clearly, the directory tree in Linux isn't all that complex. One of the best features of Linux is that if things go wrong, you can fix them. Rebooting and reinstalling your OS isn't your only option. To tell the truth, I have never had to do so. With an understanding of where files are located in Linux, system maintenance becomes easier.
Matus Telgarsky is a high school student who has been happily running Linux and using it for all computer-related tasks for many years now. He wishes to give everyone the experience of Linux, enjoys playing violin and waits for Enlightenment .14 to come out. Send him e-mail at firstname.lastname@example.org.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
- Tech Tip: Really Simple HTTP Server with Python
- SuperTuxKart 0.9.2 Released
- Parsing an RSS News Feed with a Bash Script
- Google's SwiftShader Released
- Doing for User Space What We Did for Kernel Space
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide