Under /etc: A Simple Guide

If you're new to Linux or know someone who is, here's an explanation of what's in the /etc subdirectory.

Newcomers to Linux, especially those coming from a Windows background, often find files in the /etc directory to be difficult to understand. In this article, I provide a brief explanation of some of these files and their uses. Before we dive into the /etc directory however, I would like to point out that changes to some of these files can render your system unstable or in some circumstances unbootable. I cannot emphasize enough that you should make a backup of these files before making any changes.

Let's dive in:

/etc/exports: this file contains the partition configuration to load NFS (network filesystem). It states how partitions are mounted and shared with other Linux/UNIX systems.

/etc/ftpusers: this file contains the login names of users who are not allowed to log in by way of FTP. For security reasons, it is recommended to add the root user to this file.

/etc/fstab: this file automatically mounts filesystems that are spread across multiple drives or separate partitions. This file is checked when the system boots and filesystems are mounted.

/etc/hosts.[allow, deny]: you can control access to your network by using these files. Adds hosts that you want to grant access to your network to the hosts.allow file; add hosts that you want to deny access to hosts.deny.

/etc/inetd.conf or /etc/xinetd.conf: the inetd file can be called the father of networking services. This file is responsible for starting services such as FTP, telnet and the like. Some Linux distributions come with xinetd.conf, which stands for extended Internet services daemon. This file provides all the functionalities and capabilities of inetd but extends them further.

It is advisable to comment out services you do not use.

/etc/inittab: this file describes what takes place or which processes are started at bootup or at different runlevels. A runlevel is defined as the state in which the Linux box currently is in. Linux has seven runlevels, from 0-6.

/etc/motd: motd stands for message of the day. This file is executed and its contents displayed after a successful login.

/etc/passwd: this file contains user information. Whenever a new user is added, an entry is added to this file containing the user's login name, password and so on. This file is readable by everyone on the system. If the password field contains "x", then encrypted passwords are stored in /etc/shadow, a file that is accessible only by the root user.

/etc/profile: when a user logs in, a number of configuration files are executed, including /etc/profile. This file contains settings and global startup information for the bash shell.

/etc/services: this file works in conjunction with /etc/inetd.conf or /etc/xinetd.conf files (see above). This file determines which port a service mentioned in inetd.conf is to use, for example, FTP/21, TELNET/23 and so on.

/etc/securetty: this file lists TTYs from which root is allowed to log in. For security reasons it is recommended to keep only tty1 for root login.

/etc/shells: this file contains the names of all the shells installed on the system, along with their full path names.

I hope you enjoyed this article and hope it helped in your understanding the /etc directory. You might find other subdirectories beneath the /etc directory that are application specific. /etc/httpd and /etc/sendmail, for example, are for Apache and sendmail, respectively.

Copyright (c) 2003, AmirAli Lalji. Originally published in Linux Gazette issue 94. Copyright (c) 2003, Specialized Systems Consultants, Inc.

AmirAli Lalji is a system administrator/DBA who lives and works in the UK and Portugal.

______________________

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

This is why I don't like

Anonymous's picture

This is why I don't like Linux, there are just too many configuration text files placed in a common directory that no one knows what they are for! Configuration files should be bundled in the directory that the software is installed! If I want to configure software Z, I goto Z's directory to lookfor z.config. In DOS you have one autoexec.bat and config.sys to edit, in linux you have 10 dozen.

/etc IS the reason to like Linux

AZrider's picture

I am a Linux newcomer, the /etc is exactly why you should LOVE Linux. Lets update our computer and just to make more it interesting upgrade 32 to a 64 bit too. Install your favorite Linux, install all of your favorite apps from your favorite repository, copy your /home directory from your old box (don't forget your hidden files), then copy the /etc. You have just restored your configuration files, your personal settings and your user data no fuss, no muss.

I am a Ubuntu user and I do reinstall every 6 months, until I ran across this discussion I forgot how much it sucked to update/reinstall Windows and get all of my settings back.

Yes I know that there are more directories that can/should be copied, Google it.

You should try

Amine's picture

You should try GoboLinux.

GoboLinux is an alternative Linux distribution which redefines the entire filesystem hierarchy.
In GoboLinux you don't need a package database because the filesystem is the database: each program resides in its own directory, such as /Programs/Xorg-Lib/7.4 and /Programs/KDE-Libs/4.2.0.

When you install an

Anonymous's picture

When you install an application in linux, all of the application's files, such as its binaries, manual pages, and any libraries, get smushed together into the file system. Binaries go into any of the various bin or sbin folders in your system, manual pages go into any of the man folders, and libraries go into any of the lib folders. Soon enough your file system becomes a smorgasbord! It would be the same as installing every application on a Windows machine to the same folder. And good luck trying to uninstall anything! You don't know which file belongs to which application.

Here's an example. Lets say I have 3 applications I want to install on my computer: mozilla, php, and mysql. Say each application contains binaries, manuals, and libraries. That's 9 categories of files that I need to put on my file system. There are two ways I can organize them. Either I can put each application its own directory, with three sub-directories bin, man, and lib. Or I can sort all of the applications' files in three root directories, /bin, /man, and /lib.

Linux prefers the latter, but it should be using the former! Why is that? One word: uninstalling. Sorting my files by application allows me to easily remove any application by just deleting a single folder, without any need for any package management solution. Simple and easy.

YES, CAN SOMEONE EXPLAIN WHY

Anonymous's picture

YES, CAN SOMEONE EXPLAIN WHY THIS IS SO? Please organize Linux by programs folders!

Why this is so

Anonymous's picture

I think designers of UNIX operating system were well aware of this alternative because it is the first idea that jump into mind "OK, let put every thing related to an application to its own directory".

But in practice, it doesn't work. Because in UNIX, we have strong access control and different roles. For example, only Administrators should be allow to access configuration files but any user may access the executable files.

Then I think this was the main reason behind the Subjective Arrangement of files in UNIX.

As other user said, I am agree that LINUX should start adapting more human readable file names policies. On those days, there was a strong tendency within developers, to use acronyms for almost everything, because UNIX was a command line OS. This tendency (drive by laziness principle) is still there but I think, as more regular people attends to the LINUX world, developers and designers should care about them and use as little as possible system files, hiding OS from regular users. The OS should not be seen, it should be work. It should act as the soul of the system, everybody should feel that it is there. We should go towards a day that whole Operating system can be stored as a high performance database with well defined relationships between its entities.

Askar

Yes I totally agree! If

Anonymous's picture

Yes I totally agree! If /etc/exports deals with NFS, then call it NFS_partition.config. My point is, if people don't even know what the heck ETC stands for, how the heck are they going to figure out what /etc/fstab stands for? Programmers loves to use abbreviations, the problem is that there are way too many abbreviations in Linux for too many folders, files, etc... Please give configuration files more meaningful names!

This is why I don't like

Anonymous's picture

This is why I don't like Linux, there are just too many configuration text files placed in a common directory that no one knows what they are for! Configuration files should be bundled in the directory that the software is installed! If I want to configure software Z, I goto Z's directory to lookfor z.config. In DOS you have one autoexec.bat and config.sys to edit, in linux you have 10 dozen.

Configuration files can't be

Anonymous's picture

Configuration files can't be bundled with the install directory because there are different users. Remember LINUX unlike DOS is a multi-user system!

BUT, I agree, they should name it better. If you have tons of software, under /etc

they should have:

software1.config
software2.config
software3.config

Instead with tons of cryptic names!

This is just one directory,

Anonymous's picture

This is just one directory, imagine how long will it take you to figure out the other directories. When I install stuff in Windows, I know where they go! program_files/program_name; in Linux I have not a clue.

wrong

Anonymous's picture

Actually files from programs you install in windows goes under most of the folders. Not only c:/program files, but also documents and settings local and user, the c:/windows folder in various places.

Its much easier in Linux ;)

the /etc directory

Anonymous's picture

Thank you for writing this page. The information on the /etc directory and files has been very useful. I've learned a great deal about my system..

What does "etc" stand for?

Anonymous's picture

Thanks for the good summary of the use of the /etc directory. But I've always wondered, what does "etc" stand for anyway? And where did it come from? I like to think of it as "Everything That's Configurable", but that's just my own idea. Anyone know?

I want to know too!

Anonymous's picture

Anyone? We're having a tough debate here at work on the subject :)

/etc seems to be comming

Anonymous's picture

/etc seems to be comming from "et cetera" (or "etcetera").
http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard

/usr means Unix System Resources encording to wikipedia, though, I've learnt it's Shared not System - but I guess both are valid.

ETC - what it stands for

Tim's picture

Read in an old Unix book - "Extended Tool Chest" is what /etc/ stands for, not et cetera. In other words, it's the configuration directory for system config files. There is a system /etc/ directory but is also a concept for directories that hold config files.

editable text configuration

Anonymous's picture

isnt that what it stands for?

Good primer for a newbie like me

Peter B's picture

Thanks. :-)
A good primer for a newbie like me. I did some googling and found this page with some info on the etc/ directory as well:
http://www.faqs.org/docs/linux_admin/x399.html

Nice and Useful article

Viveka Nathan K's picture

Its a very good article to know /etc, for all.

hmmm

Anonymous's picture

This article only listed about 1/20 of what is in the /etc directory. Also, check out the FSH, Filesystem Hierarchy. Its for all of linux's directories with much detail.

Excellent tutorial on /etc

Anthony Ettinger's picture

One question, do you pronouce it "ET-SEE" or "Etcetera" or "E-T-C"?

I personally call it "Etcetera" :-)

It's pronounced "ET-SEE".

Anonymous's picture

It's pronounced "ET-SEE".

Only if you are american

Anonymous's picture

"E-T-C"++

I have only ever heard Americans calling it "et-see"

We call it ET-SEE because we

Anonymous's picture

We call it ET-SEE because we invented it and get to call it what we want.

No, you get to call it what

Anonymous's picture

No, you get to call it what the actual developers call it, and they DO NOT call it ETSEE! Do some research and don't claim the work of others as your own.

-anonymous kernel dev.

/etc -- it's not a word, it's a directory

Anonymous's picture

ETSEE ETSEE ETSEE -- I'll call it that if I want to, and I often do. When I'm not saying "E - T - C", that is. It's not all that important. Perhaps you need a rest?

Some more detailed info....

Anonymous's picture

Hi,

I applaud your intentions, but you could be a bit more clear about what each file actually *is* and what it is for.

/etc/exports - This TEXT FILE Is read by the NFS servers on the local machine to make local disk areas usable by remote NFS clients.

/etc/fstab - This TEXT FILE is read by the mount program when it is used to automatically or manually mount file systems. The mount command is run from startup scripts at boot time. mount can mount local as well as remote disks using information from this file.

/etc/hosts.[allow, deny] - These TEXT FILEs are read by services which were compiled with tcp wrappers (tcpd) support to provide access control. You can allow or deny access to services based on host or network.

/etc/inetd.conf or /etc/xinetd.conf - This TEXT FILE is read by the inetd or xinetd program which is started by startup scripts at boot time. This is a "super-server", which binds to many ports and starts specific servers on an as-needed basis.

...and so on...

The basic point is that most of the files in /etc are not PROGRAMS, but rather configuration files which programs read when they are started. There are also SCRIPTS, usually in rc-subdirectories, but
that is not the subject of this article.

On booting, the kernel starts the init PROGRAM, indicating to it the desired run level. init is a program, which reads the inittab file and based on the desired runlevel starts other programs, including startup scripts and tty managers. The scripts mount filesystems, start inetd, nfs services, and the like.

The tty managers start the login PROGRAM, which reads the /etc/password and /etc/shadow files to authenticate users. If network authentication is used, /etc/password and /etc/shadow might only contain information for daemon ids. Login will start a shell PROGRAM, which will read default configs in /etc and in the user's home directory.

Some daemons are started directly by startup scripts, while others are started from (x)inetd. In some cases, a daemon is written so it can be started either way, requiring an argument to indicate the mode.

Lastly, many daemons will typically read their configuration only on startup. Changes to their config files are ignored unless the daemon is restarted, or unless it was written with a method to allow it to be notified to re-read it's config file. Typically a 'kill -HUP ' tells a daemon to re-read it's config file. Most simple daemons follow this tradition. However, complex multi-daemon services like NFS sometimes require a special tool. 'exportfs -ra' on many systems tells the NFS service to re-read it's configs.

Hope this helps to clear any confusion. Damn, I can't believe I wrote all that....

- Pete

Excellent, more please!

John's picture

I was so excited to see this article. I think having an example of a config file with a description of the various entries would be a great second step. Of course, explaining the steps to make a back up first would be a great pre-step. So, right after the "I can not emphasize enough that you should make a back up .." insert:
su This is to switch to the super user or "root" acount then type in the root password.
cp /etc/exports /etc/exports.backup
This creates a copy of the exports file in the same directory. You can repeat this with each file you wish to play with.
Some distro's (like Ubuntu) use sudo, which gives you root access for one command only. In that case the command will be
sudo cp /etc/file /etc/file.backup then you will be asked for the root password.

Two corrections: sudo su

Anonymous's picture

Two corrections:

  • sudo su - gives you root access so you can execute as many commands as desired
  • sudo asks you for your own password, not root's

Cheers,
-Adam

"sudo cp /etc/file /etc/file.

Anonymous's picture

"sudo cp /etc/file /etc/file.backup then you will be asked for the root password."

Aren't you asked for your own password, and not root's?

whose password for sudo?

Chris B's picture

Well, it depends on your distro. Some distros setup sudo to use the user's password, others, look for the root user's password.

Sudo would be a bit pointless

Anonymous's picture

Sudo would be a bit pointless and more difficult to enforce if everbody already knows the root password.

What distro sets up sudo to use the root password?

Some more detailed info....

Anonymous's picture

Hi,

I applaud your intentions, but you could be a bit more clear about what each file actually *is* and what it is for.

/etc/exports - This TEXT FILE Is read by the NFS servers on the local machine to make local disk areas usable by remote NFS clients.

/etc/fstab - This TEXT FILE is read by the mount program when it is used to automatically or manually mount file systems. The mount command is run from startup scripts at boot time. mount can mount local as well as remote disks using information from this file.

/etc/hosts.[allow, deny] - These TEXT FILEs are read by services which were compiled with tcp wrappers (tcpd) support to provide access control. You can allow or deny access to services based on host or network.

/etc/inetd.conf or /etc/xinetd.conf - This TEXT FILE is read by the inetd or xinetd program which is started by startup scripts at boot time. This is a "super-server", which binds to many ports and starts specific servers on an as-needed basis.

...and so on...

The basic point is that most of the files in /etc are not PROGRAMS, but rather configuration files which programs read when they are started. There are also SCRIPTS, usually in rc-subdirectories, but
that is not the subject of this article.

On booting, the kernel starts the init PROGRAM, indicating to it the desired run level. init is a program, which reads the inittab file and based on the desired runlevel starts other programs, including startup scripts and tty managers. The scripts mount filesystems, start inetd, nfs services, and the like.

The tty managers start the login PROGRAM, which reads the /etc/password and /etc/shadow files to authenticate users. If network authentication is used, /etc/password and /etc/shadow might only contain information for daemon ids. Login will start a shell PROGRAM, which will read default configs in /etc and in the user's home directory.

Some daemons are started directly by startup scripts, while others are started from (x)inetd. In some cases, a daemon is written so it can be started either way, requiring an argument to indicate the mode.

Lastly, many daemons will typically read their configuration only on startup. Changes to their config files are ignored unless the daemon is restarted, or unless it was written with a method to allow it to be notified to re-read it's config file. Typically a 'kill -HUP ' tells a daemon to re-read it's config file. Most simple daemons follow this tradition. However, complex multi-daemon services like NFS sometimes require a special tool. 'exportfs -ra' on many systems tells the NFS service to re-read it's configs.

Hope this helps to clear any confusion. Damn, I can't believe I wrote all that....

- Pete

Awesome, More Please!

Anonymous's picture

This is what is needed to push us to wider acceptance!

Thank You, Thank you, thank you !

More, More More !

This page seems to be really

Parth's picture

This page seems to be really good at giving an intro to /etc for the newbies... the author can try explaining in detail certain parts like etc/passwd which the user can alter to add/del users. Such things would be helpfull to newbiew :)

Nice article :) Note: the

Trancelis (verified) or's picture

Nice article :)

Note: the /etc/motd file is not _executed_, it's just printed.

Thanks for the /etc primer -

Mathew Drury's picture

Thanks for the /etc primer - clear, concise. Great article.

I hope you have plans on covering the rest of the filesystem - it's a fantastic starting point for newbies everywhere.

LJ online readers are newbies?

Admir Trakic's picture

I'm supprised that the Lj users find this article THAT nifty!?
The contents of this article are trully basic - and can be easily figured out by exploring the *nix machines file tree, instead using the fancy desktop distros.

What is a next article? - man newbie ?

/admir trakic, Cph. DK

I completely agree with

twocents's picture

I completely agree with you...... Some people are so dense they fail to see the value of a quick start guide. That fact that search engines exist to drive non-LJ users to these type of sites.

Please feel free to continue to share your brilliant thoughts, always taking into account the big picture - the sharing of information for all skill levels.

mv /admir trakic, Cph. DK > NULL

/etc stands for

kan's picture

does /etc stand for: EssenTial Configure files

/etc

D3vi8nt's picture

It stands for exntendable tool chest :)

:P

campuscodi's picture

10x

White Paper
Linux Management with Red Hat Satellite: Measuring Business Impact and ROI

Linux has become a key foundation for supporting today's rapidly growing IT environments. Linux is being used to deploy business applications and databases, trading on its reputation as a low-cost operating environment. For many IT organizations, Linux is a mainstay for deploying Web servers and has evolved from handling basic file, print, and utility workloads to running mission-critical applications and databases, physically, virtually, and in the cloud. As Linux grows in importance in terms of value to the business, managing Linux environments to high standards of service quality — availability, security, and performance — becomes an essential requirement for business success.

Learn More

Sponsored by Red Hat

White Paper
Private PaaS for the Agile Enterprise

If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.

Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.

Learn More

Sponsored by ActiveState