I know I'm supposed to submit to the wiki but I am having a great deal of trouble with it not recognizing my key. Still not sure why. I've exported it. Then created a new one. Anyway I've had this sitting around for a couple weeks now ready and would like to get feedback on it and hopefully get it submitted to the Wiki by somebody with edit writes while I work on getting my account straitened out.  Once I get reamed on a couple of these for mistakes in style I'll have a very good idea of what is and isn't wanted in documentation and can hopefully just submit in a normal fashion by then. 
<br><br><br>Start rough draft<br>----------------------------------------------------------------------------------------------------------------------------------------------------------------<br><br>The Fedora dir structure. 
<br><br>This is meant as a practical guide for novice and mid level Fedora users. The information is based on real life usage rather than what dirs are theoretically supposed to be used for. <br><br>Linux uses the traditional Unix dir structure. It was designed for use on multi-login servers and to facilitate organization as well as segregation of applications and files by intended 
usage.Linux in general and Fedora in specific has varied a little from the traditional usage of these file structures. In this document is both traditional and actual Linux usage.<br><br><br>/bin<br>Used to hold commands used by both users and admins. In general not for crucial commands. In single user mode /bin might not even be mounted if it is on a seperate partition. Non-essential scripts and utilities are often installed here as well. 
<br><br>/boot<br>This is where your kernel and related files are kept. It is also where the boot loader, Grub and or Lilo can be found. The most common reasons to access /boot is to make backup copies of your kernel before upgrading your kernel. It is highly recommended that you do so. Rpm kernel upgrades do not make a backup. If there is a problem and you do not have a copy of an older working kernel you can find your machine is unbootable. See kernel copying for how to make a backup copy of your kernel and what the various kernel files do. 
<br><br>In /boot/grub or /boot/lilo you'll also find the grub menu. This will allow you to modify your boot menu. <br><br>Only kernels and bootloader files should go in this dir. <br><br>/dev<br>This is a dir with virtual links to devices or device files. [Need examples of why anybody would go to /dev]
<br><br>/etc<br><br>This is configuration central for Linux systems. It is here where passwords are kept, network configurations, job schedules, configurations for many applications and a host of other information is stored. The majority of the files in /etc are files you will never edit by hand. They are there for specific applications and you make changes through those applications. To modify some of these files by hand is to risk breaking your system if you do not know what you are doing. 
<br><br>Hosts, hosts.allow, hosts.deny are kept here. If you have a network and do not have a DNS server you will likely want to edit these files.<br><br><a href="http://issue.net">issue.net</a> in Red Hat based systems such as Fedora this will provide the exact version of the Distro you are running. 
<br><br>Resolv.conf will list the dns information you are using. <br><br>fstab lists your mounts. Unfortunately it uses labels by default so df is a better way to see what is mounted where if you want to see what device is physically mapped to a given partition. To add a permanent mount point you add it to the fstab file. 
<br><br>Here are some of the dirs you are more likely to encounter. <br><br><br>/etc/X11<br>This is a dir you hope you never have to enter. X11 configuration files are not for the feint of heart. This is where you go to configure dual head, change monitor refresh rates if you change your monitor and to troubleshoot if X starts acting up. If you do not have a reason to edit these files then don't. 
<br><br><br>/etc/cron.d<br><br>/cron.hourly<br>/cron.daily<br>/cron.weekly<br>/cron.monthly<br>This is where your cron jobs are stored and run from. Usefull in debugging a cron script that is not running as desired or at all. It is also one of the first places to look if you feel you have been hacked. The .timeframe is how often the script in that dir will be run. Hourly for example will be run every hour. 
<br><br><br>/etc/samba<br>Most Samba configuration edits can be handled in the GUI today. Many people still hand edit the Samba configuration files. <br><br>/etc/logrotate.d<br>Where to add and change what logs are rotated and how often. 
<br><br>/etc/yum<br>It is often easier to edit these files using GUI apps such as gnome-yum. This is where information about your yum default behavior is contained. <br><br>/etc/yum.repos.d<br>Location of your yum repository information. 
<br>Repositories may be listed in the yum.conf file or as a seperate file ending with the .repo extension. <br><br>/etc/sysconfig<br>This is the heart and soul of your system configuration files. Most of these files you will never edit by hand. 
<br><br>/etc/sysconfig/network-scripts<br>Networking central. <br><br>/etc/xinetd.d<br>This is where you enable, disable, add and remove services from the xinet.d service. The format is a start up script with the name you wish to appear in the 
xinet.d service. Most scripts will contain a disable line that you change from yes to no if you have to hand edit them. <br><br>/etc/xen<br>Xen virtual machine configurations. <br><br><br>/etc/httpd<br>In rpm installs this is the nerve center of Apache. This is where you will go to create virtual servers, change the document root, create listeners, trouble shoot and other Apache admin functions. Many of these functions are not supported well or at all by GUIs. 
httpd.conf is the file you are most often going to edit. <br><br><br>If you install Apache from a tarball rename this dir to something which clearly shows it is no longer the active Apache configuration file. Apache will put it's configuration files in a different place is you install from a tarball and the frustration of editing files here and confusion generated from having multiple Apache configuration files is just not worth it. You do want to potentially save the information if you were actively using the Apache server before installing the tarball version of it. There are also examples of things done by the rpm version you may want to incorporate into the tarball version even if you never ran Apache up to that point. So it is best to save this dir until you have Apache configured they way you wish. 
<br><br><br>/etc/rc.d<br>This dir contains what files are to be run automatically or as services in a given run level. Init.d being on boot up. Most workstations use runlevel 5 (/rc.d/rc5.d/), so that is where you will be looking most likely if you ever need to delve into this. Utilities such as chkconfig [link to chkconfig doc page] from the command line or the services utility [link to X run level editors] available to root in X are wrappers around these files. They are also far easier to use than hand editing these files. 
<br><br><br>/etc/amanda<br>Amanda is the most commonly used Unix back up client. Here is where you can modify what is backed up by Amanda and how often. <br><br>/etc/snort<br>Here you'll find the snort configuration options. Snort is primarily used as an IDS and it is highly recommended that you run Snort. 
<br><br>/etc/cups<br>It's tempting but just don't do it. Cups is a very tempermental application. Make modifications from the cups GUI not here. <br><br>/etc/apt<br>If you use the apt utilities rather than yum this is where you'll want to modify repositories to obtain apt-get packages. 
<br><br>/etc/logwatch<br>Logwatch is a utility for monitoring and analyzing log files. Here is where you modify your logwatches and actions based on them. <br><br>/etc/ssh<br>SSH is a secure means to replace both telnet and ftp. Unless you have no other choice, always use SSH/SCP.&nbsp; SSH is in general very secure. It is not immune to attacks. If you have no need to ssh into your machine take the service down. In the ssh dir you will find several configuration files. Here are changes that should be made on almost all systems immediately after install to the sshd_config file.
<br><br>#Protocol 2,1<br>Protocol 2<br><br>Make sure that only protocol 2 is supported. Never use protocol 1. It is insecure. You will get hacked if you leave the ssh daemon running and exposed it to the net with protocol 1 enabled. 
<br><br>#PermitRootLogin yes<br>Change this to<br>PermitRootLogin no<br><br>The exception being that sometimes control panel applications and other admin applications require root SSH logins to function. In all other cases turn this off. Instead ssh in as a user and then su to use root privileges. If you use an application which requires the ability to ssh in as root you can limit the ability to log in as root by IP or use keys as authentication to provide better security. 
<br><br><br>X11Forwarding yes<br>This is something you typically want to allow. <br><br>Using this file you can also set up authorized keys, use PAM, Kerbos or other authentication methods, do port forwarding and a number of other options.&nbsp; 
<br><br>If you use authorized keys you'll find your key files in this dir as well. They will be necessary if you want other machines to be able to log in to this machine using authorized keys. <br><br><br>/home<br><br>This is where user specific data except for the root account is stored. It is also often used as a catchall dir for downloads, installs and shared files. The structure will typically be /home/username the username being the only default place a user can store files except for /tmp. The primary purpose is to segregate user files from system files. This is done for security reasons and organizational reasons. It is also done to make it easy to set disk usage quotas on multiple user machines. 
<br><br>The home dir is designed to keep user specific data and meant to be a private dir. Users should NEVER share files in their home dir or allow other users access to files in their home dir. Instead a shared dir or partition should be set up to facilitate sharing of files. 
<br><br>In a user's home dir you will find files such as .bashrc which allows you to modify your Bash shell environment, .gnome and .kde where some gnome applications store logs and configuration information. Applications like instant messengers will store logs in a .appname dir such as .ymessenger .gaim or in places like .kde/shared/ksirc. This is where you will find conversation logs if you save such. These are the dirs to save if you want to keep your customizations to desktop and shell environments in moving to another machine or a new install that wipes out your home dir. This can include files like gnucash documents, bookmarks which are found in .mozilla/firefox/ and pretty much every other important user specific file. 
<br><br>Files and dirs which start with a dot in front of them are hidden files. They are normally configuration files for various applications that you use and will be invisible except using ls -al or enabling the viewing of hidden files in GUI file managers. By default most compression utilities will not include these files in archives they build. So for backups you want to be sure to use switches that do include these files. The specific switches will be listed in that compression programs man page. 
<br><br><br>/lib<br>This is the home of shared libs and some applications. Mozilla for example in the past would install to /lib. Many of the entries in this dir are symbolic links. So to determine exactly what version of a lib is being used you often have to do an ls -al on the file to see where the link is pointing. 
<br><br><br>/lost+found<br>Here is where Fedora puts what it can find of files which get damaged in file system corruption. If your system reports an unclean file system and makes repairs here is where you can potentially recover lost files or pieces of them. There is a lost+found dir at the top dir of every partition. 
<br><br>/media<br>This is where Fedora by default mounts peripherals such as CDs, thumbdrives, floppy drives and such. The first place to look when adding a USB drive or mounting a CD is here unless you specified a different mount point. It is inadvisable to put any other kind of dir here. By default Fedora will not allow you to create dirs here. 
<br><br>/misc<br>Mostly unused dir today. Was in older distros heavily used for certain system files which have since been moved to other dirs. <br><br>/mnt<br>Most Distros still use the /mnt dir for what Fedora uses /media for. Some applications will still mount media here. It is also meant as a handy dir for admins to mount temporary devices. 
<br><br>/net<br>This is the traditional place to mount networked file systems such as shares from Windows machines and NFS mounts from other machines would be located. In practice many will attach them to the / dir or in their home dir. 
<br><br><br>/opt<br>This used to be where many third party applications were installed. Some applications still install here by default. Most have switched to using /usr/share or /usr/local in recent years. <br><br>/proc<br>
Kernel and process virtual file system. These are representations of what is going on in the bowels of your system. A window into what is going on. <br><br>/root<br>This is the home dir of the root account. This is not located in /home so that if /home which should be on a seperate partition fills up the root account can still function. Other than that it is exactly like a user account in /home. 
<br><br><br>/sbin<br>Here are where many of the most crucial binaries in a linux system. Files in /sbin are normally files only used by the system or by for administration of the machine. /sbin also contains the files needed for booting the machine and utilities meant to be used only by in the administration of the machine. 
<br><br><br>/srv<br>Designed as a location for service specific data. <br><br><br>/selinux<br>This is dir for configurations and data related to selinux policies. <br><br>/tmp<br>Home for application specific data and lock files. If an application crashes and will not let you restart it, a good place to start is deleting files with that application name here. 
<br><br>/usr<br>The /usr structure is where user specific applications are installed. Many server applications will install here as well. <br><br>/usr/bin<br>Home for most user related binaries and utilities. <br><br>/usr/include
<br>System wide include dir for use by both user written programs and system compiled applications. <br><br>/usr/lib<br>User based libs and shared objects. Not intended for executables but some wind up here anyway. <br><br>
/usr/share and /usr/local/share often but not always the same dir. In Fedora the default is for these two to be seperate dirs. This is for shared files system wide. For example /usr/share/wallpapers is meant to be a common place for wallpapers for use by all users and all window managers on a system. Most documentation and man pages can be found in the /usr/share or /usr/local/share dirs. Many applications will install to these dirs as well. If what you installed is not a server type app or a utility you will likely find it installed here or in your home dir. Many utilities are also installed here. 
<br><br>/usr/src<br>This is where source rpms live. The structure is devoted to storing and building source rpms. <br><br>/usr/sbin <br>The purpose of this dir is for non-essential Admin utilities and applications. <br><br>
/usr/local<br>This is for applications specific to this machine. Which really has meaning only if other machines share a common dir such as /usr/sbin. Something done very rarely today. So the /usr/local/bin, sbin, lib and other dirs except for shared are typically not used today. 
<br><br>/var<br>This is one of the default places for many applications to install into which are not part of the distro. Databases, webservers, accounting packages and such often wind up here. <br><br>/var/log<br>This is where most system logs wind up. If your / partition is suddenly out of space and /home /var or /var/log are not on seperate partitions or if a seperate /var partition is suddenly out of space check /var/log. All Linux users should get comfortable with some of the files in /var/log. Some important files located here. 
<br><br>dmesg is a crucial file in debugging boot problems. <br><br>/var/log/httpd is where you'll find your Apache logs in an rpm distribution of Apache. <br><br>mailog can be an important file. <br><br>messages is where you find information from applications that don't have a specific log file. It is the catch all log file for your system and one you should check at least periodically to monitor system health and security. 
<br><br>nessus, snort, rootkithunter and other IDS and security software will keep logs here. <br><br>/var/log/samba is where to look for samba related logs. <br><br>secure is if you have it enabled the place to look for attempts to hack into your machine. This is a file you should review often. 
<br><br>/var/lock<br>Designed to hold lock files. So it is another place to look for lock files. Some applications put them here instead of in /tmp. <br><br>/var/crash<br>If you have system dumps enabled you will generally find the results here. 
<br><br>/var/lib<br>Application specific location for libs. Most applications which install to /var will install libs specific to them in /var/lib. The redundancy of multiple lib dirs is a matter of segregation between the intended users of an application and it's related lib files. Many applications are no longer following this layout and putting lib files in /usr/lib or /lib instead. 
<br><br>/var/games<br>Rarely used dir specifically created for games. Most games install<br>to /usr/local or to /var instead. <br><br>/var/mail and /var/spool/mail<br>This is the default home for sendmail and system mail messages. The basic structure is /var/mail/username the file will be the spool containing messages for that user. 
<br><br>/var/spool/lpd<br>Temporary location for spooled print jobs spawned by lpd. <br><br>/var/tmp <br>Location for temp files preserved between reboots. <br><br><a href="http://www.pathname.com/fhs/pub/fhs-2.3.html#PURPOSE3">
http://www.pathname.com/fhs/pub/fhs-2.3.html#PURPOSE3</a><br><br><br>