lostecho/oldlinux-files
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

add directory ftp-archives

Browse Source
This commit is contained in:
gohigh
2024-02-19 00:24:15 -05:00
parent 9912ec445d
commit 32616db5a4
5750 changed files with 1672296 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

22
ftp-archives/tsx-11.mit.edu/1996-10-07/docs/HOWTO/COPYRIGHT Normal file
View File

@@ -0,0 +1,22 @@
Unless otherwise stated, Linux HOWTO documents are copyrighted by their
respective authors. Linux HOWTO documents may be reproduced and distributed
in whole or in part, in any medium physical or electronic, as long as
this copyright notice is retained on all copies. Commercial redistribution
is allowed and encouraged; however, the author would like to be notified of
any such distributions.
All translations, derivative works, or aggregate works incorporating
any Linux HOWTO documents must be covered under this copyright notice.
That is, you may not produce a derivative work from a HOWTO and impose
additional restrictions on its distribution. Exceptions to these rules
may be granted under certain conditions; please contact the Linux HOWTO
coordinator at the address given below.
In short, we wish to promote dissemination of this information through as
many channels as possible. However, we do wish to retain copyright on the
HOWTO documents, and would like to be notified of any plans to redistribute
the HOWTOs.
If you have questions, please contact Greg Hankins, the Linux HOWTO
coordinator, at gregh@sunsite.unc.edu via email.

22
ftp-archives/tsx-11.mit.edu/1996-10-07/docs/HOWTO/README Normal file
View File

@@ -0,0 +1,22 @@
This directory contains the Linux HOWTO documents.
The HOWTO-INDEX provides an overview and index of the HOWTOs.
Plain text versions of the HOWTOs are located in this directory.
Linux-HOWTOs.tar.gz is a tar file of all the HOWTOs in plain text.
- The other-formats directory contains many other formats of the HOWTOs:
- DVI versions of the HOWTOs are located in other-formats/dvi.
- HTML versions of the HOWTOs are located in other-formats/html.
- PostScript versions of the HOWTOs are located in other-formats/ps.
- SGML sources to the HOWTOs are located in other-formats/sgml.
The mini directory contains mini-HOWTOs - shorter free-form HOWTOs on
specific subjects.
See COPYRIGHT for a description of the HOWTO copyright license.
You can also browse the HOWTOs at the URL:
http://sunsite.unc.edu/mdw/HOWTO/
Please contact Greg Hankins (the HOWTO coordinator) via email at
gregh@sunsite.unc.edu, with any questions or comments.

53
ftp-archives/tsx-11.mit.edu/1996-10-07/docs/HOWTO/mini/Linux+DOS+Win95 Normal file
View File

@@ -0,0 +1,53 @@
The Linux Linux+DOS+Win95 mini-HOWTO
by Alan L. Wendt, alan@ez0.ezlink.com
v1.0, 10 September 1996
How To Boot Linux, DOS, and Windows 95 from one Hard Drive using Lilo.
The problem:
W95 and DOS get confused if more than one partition is marked active,
so it's necessary for the boot manager to activate their partition
before booting them, and to unmark any others. W95 and DOS also for
some reason relabel partitions on the booted device so that the OS
always appears to be located on drive C. So for example, even if
you install DOS into partition E on your main drive, it will appear
as partition C when it's booted.
1. Use Linux fdisk or Partition Magic to create three partitions on
your drive. Install W95 on one partition, DOS on one with
(for example) format /s c:, and Linux on the third. If you have
only one (DOS) partition on your drive to start with, Partition
Magic is the easy way to break it up into three. FIPS does the
same thing for free, but it's a little trickier to run.
2. Get a copy of lilo.17.tar.gz, which as of August 1996 was the only
revision with the ability to update the active flag at boot time.
There's a copy at ftp://ftp.ezlink.com/pub/lilo.17.tar.gz.
Compile and install it with REWRITE_TABLE defined in the Makefile.
Install something like the following in /etc/lilo.conf and run /sbin/lilo
to update the MBR record on your drive:
boot = /dev/sda
compact
delay = 5 # optional, for systems that boot very quickly
vga = normal # force sane state
ramdisk = 0 # paranoia setting
root = current # use "current" root
image = /vmlinuz.1.3.97
append = "aha1542=0x230 ro"
label = linux
other = /dev/sda1
table = /dev/sda
rewrite-table
label = dos
other = /dev/sda2
table = /dev/sda
rewrite-table
label = w95

13
ftp-archives/tsx-11.mit.edu/1996-10-07/docs/HOWTO/mini/README Normal file
View File

@@ -0,0 +1,13 @@
The mini directory contains mini-HOWTOs - shorter free-form HOWTOs on
specific subjects.
Linux-mini-HOWTOs.tar.gz is a tar file of all the mini-HOWTOs.
The HOWTO-INDEX provides an overview and index of the HOWTOs.
See COPYRIGHT for a description of the HOWTO copyright license.
You can also browse the HOWTOs at the URL:
http://sunsite.unc.edu/mdw/HOWTO/
Please contact Greg Hankins (the HOWTO coordinator) via email at
gregh@sunsite.unc.edu, with any questions or comments.

16
ftp-archives/tsx-11.mit.edu/1996-10-07/docs/HOWTO/other-formats/INDEX Normal file
View File

@@ -0,0 +1,16 @@
Index of /pub/Linux/docs/HOWTO/other-formats
-------------------------------------------------------------------------------
o README
README file
o dvi
Directory containing DVI versions of the HOWTOs
o html
Directory containing HTML versions of the HOWTOs
o ps
Directory containing PostScript versions of the HOWTOs
o sgml
Directory containing SGML versions of the HOWTOs

22
ftp-archives/tsx-11.mit.edu/1996-10-07/docs/HOWTO/other-formats/INDEX.html Normal file
View File

@@ -0,0 +1,22 @@
<HTML>
<TITLE>Index of /pub/Linux/docs/HOWTO/other-formats</TITLE>
<H1>Index of /pub/Linux/docs/HOWTO/other-formats</H1>
<HR>
<DL>
<DT><A HREF="../INDEX.html">Parent directory</A>
<DD>Parent directory
<DT><A HREF=README">README</A>
<DD>README file
<DT><A HREF="dvi">dvi</A>
<DD>Directory containing DVI versions of the HOWTOs
<DT><A HREF="html">html</A>
<DD>Directory containing HTML versions of the HOWTOs
<DT><A HREF="ps">ps</A>
<DD>Directory containing PostScript versions of the HOWTOs
<DT><A HREF="sgml">sgml</A>
<DD>Directory containing SGML versions of the HOWTOs
</DL>
<HR>
<ADDRESS><A HREF="http://www.cc.gatech.edu/staff/h/Greg.Hankins/">Greg Hankins</A>, <A HREF="mailto:gregh@sunsite.unc.edu">gregh@sunsite.unc.edu</A>
</ADDRESS>
</HTML>

14
ftp-archives/tsx-11.mit.edu/1996-10-07/docs/HOWTO/other-formats/README Normal file
View File

@@ -0,0 +1,14 @@
This directory contains many other formats of the HOWTOs:
DVI versions of the HOWTOs are located in the dvi directory.
HTML versions of the HOWTOs are located in the html directory.
PostScript versions of the HOWTOs are located in the ps directory.
SGML sources to the HOWTOs are located in the sgml directory.
The HOWTO-INDEX provides an overview and index of the HOWTOs.
See COPYRIGHT for a description of the HOWTO copyright license.
You can also browse the HOWTOs at the URL:
http://sunsite.unc.edu/mdw/HOWTO/
Please contact Greg Hankins (the HOWTO coordinator) via email at
gregh@sunsite.unc.edu, with any questions or comments.

10
ftp-archives/tsx-11.mit.edu/1996-10-07/docs/HOWTO/other-formats/dvi/README Normal file
View File

@@ -0,0 +1,10 @@
This directory has DVI versions of the HOWTOs.
The HOWTO-INDEX provides an overview and index of the HOWTOs.
See COPYRIGHT for a description of the HOWTO copyright license.
You can also browse the HOWTOs at the URL:
http://sunsite.unc.edu/mdw/HOWTO/
Please contact Greg Hankins (the HOWTO coordinator) via email at
gregh@sunsite.unc.edu, with any questions or comments.

10
ftp-archives/tsx-11.mit.edu/1996-10-07/docs/HOWTO/other-formats/ps/README Normal file
View File

@@ -0,0 +1,10 @@
This directory has PostScript versions of the HOWTOs.
The HOWTO-INDEX provides an overview and index of the HOWTOs.
See COPYRIGHT for a description of the HOWTO copyright license.
You can also browse the HOWTOs at the URL:
http://sunsite.unc.edu/mdw/HOWTO/
Please contact Greg Hankins (the HOWTO coordinator) via email at
gregh@sunsite.unc.edu, with any questions or comments.

13
ftp-archives/tsx-11.mit.edu/1996-10-07/docs/HOWTO/other-formats/sgml/README Normal file
View File

@@ -0,0 +1,13 @@
This directory has the SGML source for the HOWTOs. Unless you really
need the SGML source, it is highly recommended that you use the
preformatted versions of the HOWTOs. The SGML tools can be found
in /pub/Linux/utils/text.
The HOWTO-INDEX provides an overview and index of the HOWTOs.
See COPYRIGHT for a description of the HOWTO copyright license.
You can also browse the HOWTOs at the URL:
http://sunsite.unc.edu/mdw/HOWTO/
Please contact Greg Hankins (the HOWTO coordinator) via email at
gregh@sunsite.unc.edu, with any questions or comments.

13
ftp-archives/tsx-11.mit.edu/1996-10-07/docs/HOWTO/other-formats/sgml/mini/README Normal file
View File

@@ -0,0 +1,13 @@
This directory has the SGML source for a few mini-HOWTOs that were written
using the SGML tools. Unless you really need the SGML source, it is highly
recommended that you use the preformatted versions of the HOWTOs. The SGML
tools can be found in /pub/Linux/utils/text.
The HOWTO-INDEX provides an overview and index of the HOWTOs.
See COPYRIGHT for a description of the HOWTO copyright license.
You can also browse the HOWTOs at the URL:
http://sunsite.unc.edu/mdw/HOWTO/
Please contact Greg Hankins (the HOWTO coordinator) via email at
gregh@sunsite.unc.edu, with any questions or comments.

35
ftp-archives/tsx-11.mit.edu/1996-10-07/docs/Read_me.sounds Normal file
View File

@@ -0,0 +1,35 @@
Welcome to:
//// // ////// ////// ///// //// / /
/ / / / / / / / / // /
//// / / ///// ///// / / / / / / /
/ ////// / / ///// / / / / /
/ / / / / / / / / / / //
//// / / / / / / //// / /
//// //// / / / / /////
/ / / / / // / / / The Anonymous-FTP
//// / / / / / / / / / SOUND Archive
/ / / / / / / / / / at
/ / / / / / / // / / saffron.inset.com
//// //// //// / / ///// 192.94.75.2
** The archive is open Mon-Fri 18:30-08:30 EST/EDT, and all weekend **
This archive contains the Rogue sound archive, as well as some useful
MSDOS utilities. There is a small collection of hi-resolution games
with sound effects. Most software is for the PC, with AdLib or
SoundBlaster sound card; there's also some Roland card stuff, as well
as Amiga and MAC stuff.
The archive is on a 9600 bps line. It is slow. Find something else
enjoyable to do while you wait for your files. Don't complain at us!
You can suppress logon and chdir messages by prefixing your user@site
password with a `-'. I.e., use -user@site as your password.
Enjoy!
Comments/Suggestions: sound@saffron.inset.com
** The archive is open Mon-Fri 18:30-08:30 EST/EDT, and all weekend **

BIN
ftp-archives/tsx-11.mit.edu/1996-10-07/docs/X-Docs-v2.tar Normal file
View File

Binary file not shown.

BIN
ftp-archives/tsx-11.mit.edu/1996-10-07/docs/bash-man.dvi.tar.gz Normal file
View File

Binary file not shown.

766
ftp-archives/tsx-11.mit.edu/1996-10-07/docs/bbs.list Normal file
View File

@@ -0,0 +1,766 @@
To: Linux-Announce@senator-bedfellow.MIT.EDU
From: " (Matthias Gmelch)" <rasca@marie.physik.tu-berlin.d400.de>
Subject: linux BBS list #44
Date: 14 Nov 1994 13:36:23 +0200
Here is the latest list of Public access BBS's, and FTP Sites that
carry Linux files. This list was last modified Sun Nov 13 21:28:54 1994
The list is available - i hope at least :) - at:
ftp.cs.tu-berlin.de:/pub/linux/Local/docs/linuxbbs.44.gz
linuxNet nodes (file-net in europe) FREQ: linuxbbs.44z
PLEASE UPLOAD FILES TO BBS'S:
In posting this list I would like to point out that a large number
enthusiasts don't have FTP access. In fact it is possible that by now
most of the Linux fans don't. So I would like to suggest that those of
us that do, find at least one BBS to post the Linux files to. I, for
one post every file that I get to at least one of the local BBS's, and
from there they the files tend to find there way to other local BBS's.
I've seen posts about the future of Linux etc., well here is a way to
help guarentee it. I think it's safe to assume that most people with
FTP access also have a modem. So how about doing other Linux fans a
favor and finding a BBS to upload the Linux files to.
FORMAT:
State YYY BBS Name Phone Number Modem Speed, Online time
Rating City Other data
RATING SYSTEM:
1 -- Only enough the most basic of files
2 -- The basic's and a little more
3 -- So, so
4 -- A respectable amount
5 -- Pretty much everything you need
ADDITIONAL INFO:
YYY -- Either a Yes/No/? answer to the question
|||
||Free access to Linux files
|Allow file requests (FidoNet)
First time D/L of Linux related files
File Requests:
FidoNet BBS's with the right type of front-end mailers can call other
Fido BBS's and request their mailer to send them files that they want.
All this can be done automatically. File Requests (FREQS) are basically
the FidoNet equivallent to UUCP.
USA:
CA NNY Citrus Grove Public Access 916-381-5822 ZyXEL 16.8/14.4
3 Sacramento citrus.sac.ca.us
CA YNY Hip-Hop BBS +1-408-773-0768 14.4K V.32bis
3 Sunnyvale hh.sbay.org, -720-0835 USR DS, -749-1473 V.FC
CA YYY The Programmer's Corner 707-765-1431 14.4 V.32bis
4 Petaluma USENET
CA YNY Southland BBS +1-818-793-9108 14.4k
2 Pasadena UUCP, Slackware
CA -YY The Rogue's Guild 818-347-4291 HST16.8 V32b 24h online
- Woodland Hills Fido 1:102/812, Slackware, SLS
CA YNY Beacons Beach BBS 619-632-2486 14.4k
3 Encinitas Internet (email, Usenet), Slackware
CA YNY Station Zebra 408-730-1092 14.4k V32bis
3 Sunnyvale Usenet (ftp.saigon.com)
CO YNY The Roman Catacombs 303-429-8914 14.4k, ZyX19.2k 24h online
- Denver Internet, USENET
DC YNY When Gravity Fails 202-686-9086 14.4k
5 Washington -
DC YYY Powderhorn BBS +1-202-562-8239 14.4k
3 Washington Fido 1:109/195, SurvNet
FL NYY Slut Club 813-975-2603 USR/DS 16.8K HST/14.4K
5 Tampa Fido 1:377/42
FL YNY Amaranth BBS +1-904-456-2003 V32bis/V42bis
5 Pensacola Internet amaranth.com
FL YYY Acquired Knowledge BBS 305-720-3669 14.4k v.32bis
5 Fort Lauderdale Internet (UUCP)
FL YYY The Computer Mechanic 813-546-0977 14.4k v.32bis
3 St. Petersburg FIDONET
FL Y?Y Southeastern DataLink +1-813-572-6817 28.8kbps
5 Tampa Bay Fidonet, UUCP
GA YYY Information Overload 404-471-1549 USR V32b V32t Vfc
5 Riverdale Fido 1:133/308
GA --- Atlanta Radio Club 404-850-0546 9600
- Atlanta -
ID --- Rebel BBS 208-887-3937 9600
5 Boise -
ID YYY Rocky Mountain HUB BBS 208-232-3405 38.4k
4 Pocatello Fido,SLNet,CinemaNet,etc
IL YNY UNIX USER 708-208-5980 14.4k
4 Batavia USENET, Internet mail
IL --- Third World 217-356-9512 9600 v.32
3-4 - -
IL --- Gagme Public Access Unix 312-282-8606 v.32bis
5 Chicago Internet/USENET
IL YNY The World Trade Center II 708-481-3946 14.4k DS/HST
4 Chicago wires@gnu.ai.mit.edu /Linux99.13
IN NNY Digital Underground 812-941-9427 14.4k v.32bis
5 - USENET News Feed
IN YNY The Point 812-246-8032 28.8k Hayes
4 Sellersberg Internet
MA YNY VWIS Linux Support BBS 508-793-1570 9600
4 Worcester -
MA YYY WayStar BBS +1-508-481-7147 V.32bis/V.FC/USR/HST 16.8K
5 Marlborough Fido 1:333/14..16, other lines: -7293, -8371
MD N-N Programmer's Corner 301-596-1180 9600
5 Columbia RIME
MD --- Brodmann's Place 301-843-5732 14.4k
5 Waldorf RIME->BRODMANN, Fido, 5 msg areas for Linux/*IX
MD --- Main Frame 301-654-2554 9600
4 Gaithersburg RIME ->MAINFRAM
MD YYY Outpost23 301-475-8721 14.4k
3 Morganza UUCP, open to any unix system
MD YNY WaterDeep BBS 410-614-2190 9600 v.32
5 Baltimore -
ME YNY Harbor Heights BBS 207-663-0931 14.4k
5 Boothbay Harbor -
MN YNY Part-Time BBS 612-544-5552 14.4k v.32bis
- Plymouth tgales@empros.com
MO NNY The Sole Survivor 314-846-2702 14.4k v.32bis
5 St. Louis WWIVnet, WWIVlink, +more
NC --- MAC's Place 919-891-1111 16.8k, DS modem
5 Dunn RIME ->MAC
NC YNY Digital Designs 919-423-4216 14.4k,23k
4 Hope Mills -
NE --- Flite Line 402-421-2434 DS modem
2 Lincoln RIME ->FLITE
NE --- Legend 402-438-2433 DS modem
2 Lincoln -
NE --- MegaByte Mansion 402-551-8681 14.4 V,32bis
- Omaha -
NJ YNY Steve Leon's 201-886-8041 14.4k
3 Cliffside Park -
NJ YYY Dwight-Englewood BBS 201-569-3543 9600 v.42
3 Englewood, NJ USENET
NJ YNY WEFUNK, The Mothership Connection 908-940-1012 38.4k
4 Franklin Park, NJ -
NJ YNY Dan's Domain 201-301-0499 14.4k
4 Madison Internet via UUCP
NY YYY The Laboratory 212-927-4980 16.8k HST, 14.4k v.32bis
3-4 - Fido 1:278/707
NY YYY hpacv.com 212-924-9681 14.4k
- New York Internet
NY YNY The Vector Board 716-544-1863/2645 14.4k - 24h
1 - sysop: Jim Lill, jpll@vectorbd.com
NY YYY Manhatten College BBS 718-796-9531 14.4k V32bis
- New York Fido 1:2603/508
NY NYY Prism BBS +1-914-344-0350 14.4k
5 Middletown Fido 1:272/38, Sysop: Janis Kracht
NY YYY Valhalla 516-321-6819 14.4k HST v.32
- Babylon Fido (1:107/255), UseNet (die.linet.org)
NY N-Y ShadowGuard 516-244-7064 9600
4-5 - -
NY YNY The Wizzard's Cave 516-483-5841 14.4k V32/V42
5 East Meadow Usenet
OR YYY Intermittent Connection 503-344-9838 14.4k HST v.32bis
5 Eugene, Ore 1:152/35 f'req LINUX for a list
OR YYY the void 503-251-3808 v.32bis
4 Portland Fido 1:105/366, Usenet altreal.egg.com, Slackware
OH Y-- Horizon Systems 216-899-1086|1293 USR v.32|2400
- Westlake -
OH NNY Akademia Pana Kleksa 216-481-1960 WorldBlazer
3 Cleveland Internet: wariat.org
OK YYY Hermit Hideout 918-342-3410 16.8HST V32t V32bis
4 Claremore Fido 1:170/300
PA NNY Centre Programmers Unit 814-353-0566 14.4k V.32bis/HST
5 Bellefonte, PA -
PA YNY Allentown Technical 215-432-5699 14.4k v.32/v.42bis
4 Allentown WWIVNet 2578
TX YYY CyberVille 817-249-6261 9600
3 - Fido 1:130/78
TX YNY alaree 512-575-5554 14.4k v32b/v42b/LAPM
5 Victoria USENET, Slackware 1.1.1, BSD
TX YNY Solor Soyuz Zaibatsu 512-458-6084 -
- Austin home of 'The Wired Society', guest account
-- YNY Ronin BBS 404-436-5676 14.4 HST/DS
2 - RIME ,Intelec, Smartnet, and more!
TX YNY uss.lonestar.org 214-424-9705 14.4k
5 Plano USENET, UUCP, tsx-11.mit.edu mirror
TX YYY tIME sTARTS nOW 817-332-5336 V32b/V.FC (24h)
- Fort Worth Fido 1:130/908, djh@netcom.com
TX YYY Chrysalis 214-690-9296 14.4k
4 Dallas Usenet
VA --- NOVA 703-323-3321 9600bps
4 Annandale Fido 1:109/305
VA --- Rem-Jem 703-503-9410 9600
2 Fairfax -
VA --- Enlightend 703-370-9528 14.4k
3 Alexandria Fido 1:109/615
VA YN? Georgia Peach BBS 804-727-0399 14.4k
1 Newport News -
VT YNY Relax 802-453-4458 V.FC 28.8k
4 Bristol USENET
VT YYY Socialism_OnLine! +1-802-626-4103 28.8k V.FC
5 Sheffield Fido 1:325/806
WA YYY Top Hat BBS 206-244-9661 14.4k
2 - Fido 1:343/40
WA YNY quark 206-748-9878 V.Fast (Supra)
4 BBS running Linux/SysAdmin quark!enyaw@efn.org
WI YYY Sevenex PubAcc. Linux 414-843-4169 9600 v32
5 Paddock Lake Fido 1:154/12, InterNet sevenex.sol.net, CDs
WI NNY Exec PC 414-789-4360 14.4k
2 Milwaukee Slackware 1.0.3, 140 phone lines
CANADA:
AB NNN Magic BBS 403-569-2882 14.4k HST/Telebit/MNP
3 Calgary, AB, Canada Internet/Usenet
AB Y-Y Logical Solutions 2400 bps lines: 299-9900 to 9911
5 - 14.4 K lines: 299-9912 to 9913,
16.8k USR v32bis: 299-9914 to 9917
AB NNN WorldGate/VALIS 403-444-7685 14.4k v.32bis 24 Hours
5 Edmonton Internet, other Lines: 481-8584, 489-4064
AB YYY Cameo Gateway 403-249-6008 14.4k HST v.42
- Calgary Fidonet 1:134/63 & Emergnet 31:31/10
AB NYN Cameo Gateway 2 403-242-7527 19.2k
- Calgary Fidonet 1:134/500 & Emergnet 31:4331/50
AB YYY Calgary Message Line 403-249-6560 14.4k
- Calgary Fidonet 1:134/66
BC YYY Serendipity 604-599-3820 14.4k v.32b
5 Richmond Fidonet 1:153/916, SLS, Slackware
ON --- The Windsor Download (519)-973-9330 v32bis 14.4
- - -
ON YNY The Void 613-731-4909 1200-16.8k
4 Ottawa Fidonet: 1:163/273.5, SLS
ON YNY Mark's Linux BBS 613-829-1941 V.Fast 24k bps
5 Ottawa Internet, UUCP, second line: 829-4553
QC --- Synapse 819-246-2344 819-561-5268
4 Gatineau RIME -> SYNAPSE
QC YNY Radio Free Nyongwa 514-524-0829 v.32bis (ZyXEL)
2 Montreal USENET, Fido
QC YNY Smegheads BBS 514-457-0093 14.4k V32b, V42b
2 Montreal USENET, UUCP, Yggdrasil v99.5, login: guest
RUSSIA:
- YNY sci +7-831-234-3045 ZyX16.8 (24h)
- Nizhny Novgorod Fido 2:5015/13, anonymous SLIP, GDX BBS
SOUTH AFRICA:
- NYY Pats System +27-12-333-2049 14.4k v.32bis/HST
3 Pretoria Fidonet 5:71-1/36
NETHERLANDS:
- YNY DownTown BBS Lelystad +31-3200-48852 14.4k
5 Lelystad Fido 2:512/155, UUCP
- YYY MUGNET Intl-Openworld BBS +31-1720-42580 V-fast 115k
4-5 Alphen a/d Rijn UUCP, -30979 Worldblazer, -19339 V-fast 115k
- YNY Koos z'n Doos +31-3402-36647 -
- - -
- YYY Filosoft/PROGRAMMERS BBS +31-50-412288 14.4k v.32bis
5 Groningen +31-50-426071 2400 bps, Fidonet 2:282/517
BELGIUM:
- YYY In Limbo +32-2-582-66-50 ZyX19.2 V.32bis
3-4 Lennik Fidonet 2:291/702, 2. line +32-2-582-71-77
FRANCE:
- NNY Modula BBS +33-1 4043 0124, +33-1 4530 1248 HST 14.4 V.32bis
5 Paris Michel Parlebas (no fee for Linux files)
- YNY Brasil +33-1-44670844 V32bis
2 Paris, Laurent Chemla BBS under Linux (xbbs)
- NNN Libernet BBS 33-1-402-290-93 V32b
5 Paris Usenet (info@remcomp.fdn.org)
- ?NY BBS-FDN +33-1-48-89-58-59 V32bis,V42bis
4 Paris Internet
69 NYY Stdin +33-72345437 (UUCP) V32bis
5 Lyon, Rhone FidoNet 134:323/8, fido: +33-72345072
- NNY Zenux +33-78361001 V32b 24.4k Zoom
3 Lyon Internet Mail/News
- NYY Le Lien +33-72089879 HST 14.4/V32bis
- Lyon, Pascal Valette FidoNet 2:323/5
- YYY Cafard Naum +33-51701632 V.Fast 28.8k 24h online
2 Nantes, Yann Dupont Gdx BBS under Linux, second line: 5170163
- NNY Alias BBS +33-1-3070-8794 VFC 28.8k
3 - Fr-Link
IRELAND:
- NNN DUBBS +353-1-6789000 19.2 ZyXEL
1 Dublin, Ireland Fidonet 2:263/167
- NNY Ireland On-Line +353-91-92722 19.2 ZyX
5 Galway +353-1-671-5185, Usenet, Inet @iol.ie
- N-Y Nemesis' Dungeon +353-1-324755 or 326900 14.4k v32bis
3 Dublin Fidonet 2:263/150
FINLAND:
- YNY Dream World BBS +358 21 4389 843 9600/ARQ 24 hour
4 Raisio USENET, dream.nullnet.fi
- YNY Valhalla +358-(9)52-181-299 14.4k
4 Kotka Finland UseNet, valhall.nullnet.fi, no time limits
ITALY (contact: mau@beatles.cselt.stet.it)
- NYY OneWay BBS +39 2 4491062 V32bis/V42bis
4 Milano Fidonet 2:331/333, Virnet (Jul 93)
- NYY DOC! +39 41 5905472 V32bis/V42bis
4 Mogliano Veneto Fidonet 2:333/503 (Jul 93)
- NYY nonsolosoftware +39 51 6140772 V32bis,V42bis
5 Bologna Fidonet 2:332/407
- NYY nonsolopoint +39 51 432904 ZyX19.2k
5 Bologna Fidonet 2:332/417
- YYY Sierra BBS +39 6 39721568 ZyX19.2k
2 Roma Fidonet 2:335/336 (Oct 93)
- YYY Nixnet +39-862-316-950 V.FC,V32bis,V42bis
5 L'Aquila Fidonet 2:335/613, Linuxnet (Aug 94)
SWITZERLAND (contact: pingu@satu.baboon.ch)
- YYY Baboon BBS +41-62-511726 28.8k
5 Strengelback Fido 2:301/520 /521 /551
- YYY Gonisoft BBS +41-22-7576185 19.2k
2 Bernex Fido 2:301/320 /321
- NYY Baerengraben +41-31-9340131 28.8k
4 Stettlen Fido 2:301/502 /552
- YYY ALPHANET +41-38-41-40-81 V32bis
- Colombier UUCP: login with "nuucp" (~/ls-laR.gz)
- YYY Eulen Bbs +41-1-4319649 19.2k
4 Zuerich Fido 2:301/710
- YYY The Best Bbs! +41-1-2915606 19.2k
4 Zuerich Fido 2:301/714
- YYY Zuerich Live BBS +41-1-4312321 19.2k
4 Zuerich Fido 2:301/801 /850
CZECH REPUBLIC:
- YNY Super 7 +42-2421-8007 USR COURIER V32bis /w ASL
5 Prague Internet vseedu.vse.cz
AUSTRIA:
W YYY Galaktische Archive +43.222.830-38-04 16.8 ZYX (19:00-7:00)
4 Wien fido 2:310/77
UNITED KINGDOM:
- NYN The Purple Tentacle +44-1734-266974 HST/V32bis
4 Reading Fidonet 2:252/305
- --- A6 BBS +44-1582-460273 14.4k
- Herts Fidonet 2:440/111
- YYY On The Beach +44-1273-600996 14.4k/16.8k
4 Brighton Fidonet 2:441/122
- NYY Pale Kat +44-1291-650567 V32bis
4 Gwent Morse Winter 94 CD
- YYY DarcWorld +44-1865-377724 V32b/V42b
3 Oxford Fidonet
ESU YNY POLUX Meridian BBS +44-1273-588-924 14.4k V32bis
4 Peacehaven -
SWEDEN
- YYY Gunship BBS +46-31-693306 28.8k HST DS
- Gothenburg Fidonet 2:203/117
NORWAY:
- --- Thunderball Cave 472567018 -
- - RIME ->CAVE
GERMANY:
HH YNY umibox +49-4152-824-93 16.8k
- Geesthacht USENET
HH YNY troehl +49-40-792-99-61 ZYX 19.2k
5 Hamburg BBS login: gast
UUCP: machine troehl, login nuucp, password nuucp, files /pub/Index.gz
HB YYY oytix.north.de +49-421-396-57-62 V.fast
4 Bremen mike@oytix.north.de, login "gast" (ZyX: AT&N17)
SHL YYY FORMEL-Box +49-4191-2846 ZyX 16.8k 5:30-03:30
5 Kaltenkirchen Fido 2:240/4005, LinuxNet
NDS --- DataComm 1+2 +49-531-132-16/17 HST 14.4k
- Braunschweig Fido 2:240/550|1, LinuxNet
NDS YYY Linux Server/A. Braukmann +49-441-592-963 ZyX 16.8k
5 Oldenburg Fido 2:2426/2120, LinuxNet
NDS YYY OtE Bremen/R. Roeber +49-421-557-97-05..8 ZyX 14.4k
3 Bremen Fido 2:2426/3020..3, LinuxNet
NDS YYY MM's Spielebox +49-5323-3515 ZyX 16.8k V32b
5 Clausthal-Zfd. Fido 2:241/630, SLS 1.03, SLT
NDS YYY MM's Spielebox +49-5323-3540 9.6k
5 Clausthal-Zfd. Fido 2:241/632, new file list magic: NEWLINUX
NDS YNY Harry's Box +49-5132-825-928 ZyX 16.8k (24h)
5 Lehrte sunsite mirror, BBS login: gast, password: gast
UUCP: machine seneca, login nuucp, password nuucp, files /pub/find.ALL.z
NDS YNY LinuxBox Northeim +49-5551-952-202 14.4k (0-23 MET)
3 Northeim Internet: peges.werries.de, LinuxNet, login: mbox
NRW YYY hippo.fido.de +49-241-875-090 14.4k 4:30-18:00,19-24:00
5 Aachen Fido 2:2452/110, Slackware 1.2.0
NRW YYY hippo-isdn.fido.de +49-241-879-04-20 ISDN 64k X.75/38.4k V.110
5 Aachen Fido 2:2452/111, Slackware 1.2.0
NRW YYY UB-HOFF /A. Hoffmann +49-203-584-155 ZyX+ 19.2k
3 Duisburg Fido 2:242/37, SLS1.0
NRW YNY Needful Things +49-231-656-783 ZyX 16.8k
5 Dortmund (soon: Fido and FREQ's)
NRW YYY POLLUX /N. Szepanowski +49-2842-551-40 14.4k
3 Kamp-Lintfort Fido 2:243/2007, SLS1.03, C/C++ stuff
NRW YYY Zaphods BBS/C.Lueders +49-228-262-894 HST V32b
5 Bonn Fido 2:2453/30, Slackware 1.1.2
NRW YYY Zaphods BBS +49-228-229-147 HST V32b
5 Bonn Fido 2:2453/30, Slackware 1.1.2
NRW YYY Zaphods BBS ISDN +49-228-911-10-41 64.0k BPS V110/X75
5 Bonn Fido 2:2453/30, Slackware 1.1.2
NRW NNY MITROPA +49-203-482-319 ZyX+ 19.2k
5 Duisburg Internet, BBS under Linux (login: bbs)
NRW NYY asgard +49-271-317-40-28 16.8k
- Siegen Usenet asgard.rni.sub.org
NRW YNY IUS +49-203-871-666 (5 Leitungen) 14.4k
- Duisburg Internet, ISDN line: 8780222 - X.75 64k
NRW YNY Bigcomm Linux-Box +49-211-398-52-58 ZyX+ 19.2k
5 Duesseldorf Usenet, LinuxNet, Slackware Mirror
--- NYY IRD-BBS Schoeningen +49-5352-58200 14.4k
4 Schoeningen Fido 2:241/560, UseNet
HES YNY BHT-BOX +49-6648-3553 19.2k ZyX (24h)
4 Wartenburg Usenet, bht-box.zer.de, 2. Line: 37333
ISDN: +49-6648-91-00-50 or +49-6648-91-00-55
HES NYY Radio Bornheim +49-69-493-08-30 ZyX19.2k
2 Frankfurt/Main Fido 2:2461/332, LinuxNet, Slackware 1.2.0
BLN YYY lupo /Rasca Gmelch +49-30-335-63-28 ZyX 16.8k V32b 16-23:00 MET
4 Berlin Fido 2:2410/305.4, LinuxNet, login: guest/guest
BLN NYY INTERWORLD +49-30-251-37-71 14.4k
5 Berlin Internet (prepared)
BRG YYY xffo +49-335-528-441 ZyX19.2k
- Frankfurt (Oder) Fido 2:2410/904, USENET xffo.sh.sub.de, Z-Netz
UUCP: login "nuucp", passwd "nuucp", Fileliste: index
BW NYY Fractal Zone BBS /Maass +49-721-863-066 ZyX 16.8k (24h)
5 Karlsruhe Fido 2:2476/462, LinuxNet (magic: LINUX)
BW YYY CRYSTAL BBS +49-7152-240-86 HST 14.4k
5 Leonberg Fido 2:2407/3, LinuxNet
BW YYY Echoblaster BBS #2 +49-7142-212-35 V32b 8-20:00,23-2:00
5 Bietigheim Fido 2:2407/40, LinuxNet
BW NYN LinuxServer/P. Berger +49-711-756-275 HST 16.8k 8:30-17:50,19-2:00
5 Stuttgart (no BBS!) Fido 2:2407/34, LinuxNet, Slackware
BW NYY Rising Sun BBS +49-7147-3845 ZyX 16.8k V32b 05:30-02:30
4 Sachsenheim Fido 2:2407/41, LinuxNet
BW NYY Rising Sun BBS +49-7147-143-47 HST DS 14.4k
4 Sachsenheim Fido 2:2407/410, LinuxNet, max. 90min
THU YNY AS-Node Jena +49-3641-33-14-96 ZyX16.8 (24h)
2 Jena ring, hangup, wait 10s, call again
BAY NYN Fiffis Inn BBS Munich +49-89-570-13-53 ZyX+ 19.2k
5 Munich Fido 2:246/69, LinuxNet, magic: LINUX
BAY --- BOX/2 +49-89-601-96-77 ZyX 16.8k 22-24,0:30-2,5-8:00
- Muenchen Fido 2:246/147, info magic: LINUX
BAY YNY The Bingo BBS +49-89-637-84-29 ZYX 19.2k
- Munich Fido 2:2480/180.12
BAY YYY Die Box Passau 1+2 +49-851-555-96 19.2k V32terbo 8:00-NMH MET
4 Passau Fido 2:2494/21
BAY YYY Die Box Passau 3 +49-851-950-468 ISDN V.110/X.75
4 Passau Fido 2:2494/23, online 8:00-NMH MET
BAY YYY Die Box Passau 4 +49-851-950-462 V32b ZyX
4 Passau Fido 2:2494/22, online 8:00-NMH MET
BAY YNY Greenie +49-89-324-33-28 ZyX 16.8 24 hrs
4 Munich freq soon, gert@greenie.muc.de
UUCP: machine greenie, login: nuucp, ~/green.files.Z
BAY NNY incubus +49-931-781464 V.32bis V.terbo 24 hour
- Wuerzburg Usenet, Z-Netz
BAY YYY BMS +49-951-952-00-51 ZyX 19.2bps + ISDN
5 Bamberg LinuxNet, Fido 2:2490/3001, 2. Line 952-00-31
BRAZIL:
SP YNY Wintech BBS +55-011-5238883 V32bis/V42bis (24h)
2 Sao Paulo -
AUSTRALIA:
NSW YYN Linux-Support-Oz +61-2-418-8750 v.32bis 14.4k
5 Sydney Internet/Usenet, Mail/News/FTP/Telnet/Gopher/IRC
NSW NYY 500cc Formula 1 BBS +61-2-550-4317 V.32bis
4 Sydney -
NSW NNY Krikkit One PAU +61.49.423565 2400 11:00-19:00 AET
2 Newcastle APANA, slackware soon :)
VIC NNY Suburbia Multiline +61-3-596-8366 14.4k
2 Melbourne suburbia.apana.org.au
- YNY Desire BBS +61-7-371-1190 14.4k V32bis
4 Brisbane APANA (desire.apana.org.au)
ACT YNY posgate.apana.org.au +61-(06)-285-1701 V32bis
3 Canberra Internet (APANA)
NEW ZEALAND:
- YYY mserve.kiwi.gen.nz +64-9-366-44-62 ZyX16.8k Zoom28.8
5 Auckland usenet (login as linux)
- NYY BugBoard +64-4-526-4840 ZyX16.8 V32bis
3 Wellington FidoNet 3:771/375
SINGAPORE:
- YYY The Controversy (65)560-6040 14.4k V.32bis/HST
2-4 - Fidonet 6:600/201
- YNY linuxpub (65)583-6023 14.4k V42
5 - UUCP, Usenet, no download limits
ROS YNY temasek +65-270-4552 14.4k
? Gillman Heights FidoNet, Rime, UUCP, Usenet
HONG KONG:
- NNY OLISC UNIX BBS +852-429-6157 ZyX19.2
2-3 Hong Kong UUCP, Inetnet (Email & Usenet), Uniboard BBS
MAJOR FTP SITES FOR LINUX:
textual name numeric addr Linux directory
===================================== ============== ===============
tsx-11.mit.edu 18.172.1.2 /pub/linux
sunsite.unc.edu 152.2.22.81 /pub/Linux
nic.funet.fi 128.214.6.100 /pub/OS/Linux
wuarchive.wustl.edu 128.252.135.4 /mirrors/linux
ftp.mcc.ac.uk 130.88.203.12 /pub/linux
ftp.win.tue.nl 131.155.70.100 /pub/linux
ftp.sun.ac.za 146.232.213.2 /pub/linux
ftp.ibp.fr 132.227.60.2 /pub/linux
nic.switch.ch 130.59.1.40 /mirror/linux/
ftp.lysator.liu.se 130.236.254.1 /pub/linux
ftp.luth.se 130.240.18.2 /pub/linux
ftp.ibr.cs.tu-bs.de 134.169.34.15 /pub/os/linux
ftp.dfv.rwth-aachen.de 137.226.4.111 /pub/linux
ftp.cs.tu-berlin.de 130.149.17.7 /pub/os/linux
ftp.informatik.rwth-aachen.de 137.226.225.3 /pub/Linux
ftp.informatik.hu-berlin.de 141.20.20.38 /pub/os/linux
ftp.informatik.tu-muenchen.de 131.159.0.198 /pub/comp/os/linux
ftp.rz.uni-karlsruhe.de 129.13.96.2 /pub/linux
ftp.uni-erlangen.de 131.188.34.43 /pub/Linux
nwg.nectec.or.th 192.150.251.31 /pub/mirrors/linux
swdsrv.edvz.univie.ac.at 131.130.1.4 /unix/systems/linux
Bond.edu.au 131.244.1.1 /pub/OS/Linux
carnegie.bf.rmit.oz.au 131.170.51.170 /pub/linux
ftp.fdn.org (mirror of ftp.ibp.fr + tsx-11.mit.edu) /pub/Linux
pub.vse.cz ? /pub/386-unix/linux
Name Linux directory
===================================== ===============
ftpmail@sunsite.unc.edu /pub/Linux
info-server@Germany.EU.net comp/i386/Linux
ftp-mailer@ftp.informatik.tu-muenchen.de /pub/comp/os/linux
ftpmail@doc.ic.ac.uk packages/Linux
Addition FTP Info:
For people accessing German FTP Sites there exhists a 'Linux-FTP-Roadmap'.
It can be found on several German sites, one in particular is:
ftp.uni-erlangen.de:/pub/Linux/LOCAL/private/Linux-FTP-Roadmap.gz
It includes some very comprehensive data on the German FTP sites.
(corrections to rfflaxa@informatik.uni-erlangen.de)
If you have any additions/corrections to this list please send
them to one of the following:
interNet -- rasca@marie.physik.tu-berlin.de
fidoNet -- Rasca Gmelch, 2:2410/305.4
/************* NEEDED INFO FOR BBS ENTRIES: ******************/
BBS Name:
Phone Number:
Modem Speed (CCITT):
City / Country / State:
Whatever Network it's on (i.e. FidoNet, RIME, etc.):
First Time access to D/L Linux Files (Y/N):
Allow File Requests - Fido-style (Y/N):
Free Access to Linux Files (Y/N):
BBS Rating (1-5):
I would apprieciate it if when you send me info on a BBS that you
send me ALL the info that you see in the entries, thanks.
--
Send submissions for comp.os.linux.announce to: linux-announce@tc.cornell.edu
PLEASE remember Keywords: and a short description of the software.

35
ftp-archives/tsx-11.mit.edu/1996-10-07/docs/drdos-partition-fix.txt Normal file
View File

@@ -0,0 +1,35 @@
There is another solution that was posted on the comp.os.minix topic.
Using any disk or file editor (I used Norton Utility), search for the
following hex sequence in the DRDOS system files::
24 7f and al,7fh ;clear top (secure) bit
3c 01 cmp al, DOS20_ID ;is this a DOS2.x partition?
(The assembly code is courtesy of Rob Huehn of Geac Computer
Corporation, who fixed the bug for DRDOS 5.0) (huehn@geac.com on
internet).
Simply replace the 7f with ff, and DRDOS will no longer try to strip
the high bit off the MINIX partition type (which turns an 81h for
MINIX into a 01h for DOS).
I appears that the default for Linux is also 81h or 129 decimal.
I had MINIX and DRDOS 5.0 on my system together for one year and DRDOS
6.0 by itself for almost another year with the above modifications
with no problems, so I believe it works fine.
I informed Digital Research of the problem, but heard nothing of it.
Hope this helps someone,
Jason

BIN
ftp-archives/tsx-11.mit.edu/1996-10-07/docs/info/bash-info.tar.gz Normal file
View File

Binary file not shown.

11
ftp-archives/tsx-11.mit.edu/1996-10-07/docs/ioctl-list-1.3.35.lsm Normal file
View File

@@ -0,0 +1,11 @@
Begin3
Title: Ioctl List
Version: 1.3.35
Entered-date: Sun 22 Oct 1995
Description: Documentation: list of ioctl calls in Linux kernel
Keywords: ioctl documentation
Author: <mec@duracef.shout.net> (Michael Elizabeth Chastain)
Primary-site: tsx-11.mit.edu /pub/linux/docs
Platform: Linux 1.3.35
Copying-policy: GPL
End

16
ftp-archives/tsx-11.mit.edu/1996-10-07/docs/linus/linus.README Normal file
View File

@@ -0,0 +1,16 @@
I finally got these made, and even managed to persuade Linus into
allowing me to publish three pictures instead of only the first one.
(He still vetoes the one with the toy moose... :-)
linus1.gif, linus2.gif, linus3.gif
Three pictures of Linus Torvalds, showing what a despicable
figure he is in real life. The beer is from the pre-Linux
era, so it's not virtual.
In nic.funet.fi: pub/OS/Linux/doc/PEOPLE.
--
Lars.Wirzenius@helsinki.fi (finger wirzeniu@klaava.helsinki.fi)
MS-DOS, you can't live with it, you can live without it.

146
ftp-archives/tsx-11.mit.edu/1996-10-07/docs/linux-doc-project/install-guide-2.2.2.README Normal file
View File

@@ -0,0 +1,146 @@
The Linux Documentation Project proudly presents...
Linux Installation and Getting Started
by Matt Welsh <mdw@sunsite.unc.edu>
v2.2.2, 12 February 1994
Linux Installation and Getting Started is a book for anyone wishing to
dive into the Linux world. It covers what Linux is, how to get it, and how
to install it on your machine. Also included is an introductory tutorial to
using Linux for UNIX novices, and chapters on Linux system administration and
advanced features of Linux, such as the X Window System, TCP/IP networking,
and more.
This book is freely distributable under certain conditions (see below).
This license allows anyone to print and distribute verbatim copies of
the book. I encourage publishing companies and printing houses to do so.
In particular, I encourage distributors of Linux software to use this book
as an installation guide. (After all, that's why I wrote it!) If you don't
find the instructions contained therein specific enough, you can provide
your own short "installation supplement" to go along with the book.
Changes in version 2.2.2: Many typo corrections, added information on
installing the Slackware distribution, and a complete section on installing
and configuring XFree86 3.1.
The book has been uploaded to sunsite.unc.edu in the directory
/pub/Linux/docs/LDP/install-guide
Other sites, such as tsx-11.mit.edu, should mirror this soon. The book is
also available in printed form via mail order from SSC, Inc. See below for
more information.
The files below ending in the .gz extension have been compressed with
gzip. Gzip is available from many FTP sites, including prep.ai.mit.edu
in /pub/gnu. An MS-DOS version of Gzip can be found on sunsite.unc.edu
in /pub/Linux/distributions/slackware/GZIP.EXE.
The files without the .gz extension are plain, uncompressed
files. Many readers were having trouble getting Gzip for MS-DOS and
other platforms, so I am providing both gzipped and ungzipped versions
of the files on the FTP sites.
The gzipped files are identical to their non-gzipped counterparts.
You only need to get one or the other, not both.
The files are:
install-guide-2.2.2.ps
install-guide-2.2.2.ps.gz
PostScript output, ready to print, 236 pages.
Should print fine on US letter or A4 paper. You can
also view this with Ghostview.
parts/chapter0.ps.gz, parts/chapter1.ps.gz, ...
The "parts" subdirectory contains individual PostScript
files for each chapter of the book, as some people have
had problems printing the single PostScript file above. In
addition, the file appendix.ps.gz contains the appendices
and index. Each of these files should be printed separately.
install-guide-2.2.2.dvi
install-guide-2.2.2.dvi.gz
.dvi (device independent) TeX output. 236 pages.
ou can view this with xdvi or convert to another format with
the various DVI tools if you wish. For example, dvips will
generate PostScript from this file, dvilj2p will produce HP
LaserJet IIP output, etc. See the comp.text.tex FAQ for details.
install-guide-2.1.1.txt
install-guide-2.1.1.txt.gz
Plain ASCII output. This is made available mostly for previewing
purposes---it is rather ugly. I DO NOT recommend reading the
plain ASCII if you can help it---the PostScript and .dvi versions
look very nice in comparison. It's also for the previous
version of the book, v2.1.1.
install-guide-2.2.2.tar.gz
Complete LaTeX source, including formatting macros
and style file. You need this only if you want to
format the book from scratch. (For example, for printing
two-sided.) Otherewise one of the above files will do.
This is a gzipped UNIX tar file.
Linux Installation and Getting Started may be reproduced and distributed
in whole or in part, subject to the following conditions:
Linux Installation and Getting Started is Copyright (c)1992-1994 by Matt
Welsh, mdw@sunsite.unc.edu.
* The copyright notice above and this permission notice must be
preserved complete on all complete or partial copies.
* Any translation or derivative work of Linux Installation and
Getting Started must be approved by the author in writing before
distribution.
* If you distribute Linux Installation and Getting Started in
part, instructions for obtaining the complete version of this
manual must be included, and a means for obtaining a complete
version provided.
* Small portions may be reproduced as illustrations for reviews or
quotes in other works without this permission notice if proper
citation is given.
* The GNU General Public License referenced below may be
reproduced under the conditions given within it.
Exceptions to these rules may be granted for academic purposes: Write
to Matt Welsh, at the above address, or email mdw@sunsite.unc.edu,
and ask. These restrictions are here to protect us as authors, not to
restrict you as educators and learners.
In short, you don't need my permission to copy, print, or distribute the
complete book, verbatim, but you do need my permission to translate
the book or to produce a derivative work from it. Just get in touch with
me if you have questions.
All source code in Linux Installation and Getting Started
is placed under the GNU General Public License, available via anonymous
FTP from prep.ai.mit.edu:/pub/gnu/COPYING.
This book is available from SSC, Inc. via mail order. Belinda Frazier
writes,
SSC has printed the Linux Installation and Getting Started
manual, Version 2.2.1 to make it available for those who do not
have the capability to print it themself and to support our
customers who buy Linux (Yggdrasil) from us. It is printed
double-sided, perfect bound, with a cover. SSC also intends to
make comb bound versions of the other LDP manuals available.
Linux Installation and Getting Started, Version 2.2.1 is available
for $12.95 plus shipping ($3 in the U.S.). We can accept credit
card orders (Visa, MasterCard or AmEx). Orders can be phoned in
(206-FOR-UNIX/206-527-3385), FAXed (206-527-2806) or mailed to
SSC, P.O. Box 55549, Seattle, WA 98155.
Mail sales@ssc.com for more information.
Please send me any comments or suggestions. I usually appreciate
general comments, instead of cdiffs, because they allow me to make
corrections by hand.
Share and enjoy,
M. Welsh, mdw@sunsite.unc.edu

BIN
ftp-archives/tsx-11.mit.edu/1996-10-07/docs/linux-doc-project/install-guide-2.2.2.dvi.gz Normal file
View File

Binary file not shown.

BIN
ftp-archives/tsx-11.mit.edu/1996-10-07/docs/linux-doc-project/install-guide-2.2.2.ps.gz Normal file
View File

Binary file not shown.

BIN
ftp-archives/tsx-11.mit.edu/1996-10-07/docs/linux-doc-project/install-guide-2.2.2.tar.gz Normal file
View File

Binary file not shown.

7
ftp-archives/tsx-11.mit.edu/1996-10-07/docs/linux-doc-project/khg-0.7.README Normal file
View File

@@ -0,0 +1,7 @@
After a long hiatus, the KHG has come back to life. However, it
will no longer be available as a paper document, and will not
(at least for the forseeable future) be available as postscript,
DVI, or any other easily printable format. This is because it
is now interactive, on the web. Point your browser at
http://www.redhat.com:8080/HyperNews/get/khg.html
and start interacting.

18
ftp-archives/tsx-11.mit.edu/1996-10-07/docs/linux-doc-project/lpg.lsm Normal file
View File

@@ -0,0 +1,18 @@
Begin
Title = Linux Programmer's Guide
Version = 0.4
Desc1 = Some words about writing C programs on linux
Author = Linux Documentation Project
AuthorEmail = DOC channel
Maintainer = Sven Goldt
MaintEmail = goldt@math.tu-berlin.de
Site1 = sunsite.unc.edu
Path1 = /pub/Linux/docs/?
Site2 = tsx-11.mit.edu
Path2 = /pub/linux/docs/?
CopyPolicy1 = otherwise freely copyable
Keywords = program system porting ldp
Entered = April 1995
EnteredBy = Sven Goldt
CheckedEmail = goldt@math.tu-berlin.de
End

14
ftp-archives/tsx-11.mit.edu/1996-10-07/docs/linux-doc-project/man-pages-1.12.lsm Normal file
View File

@@ -0,0 +1,14 @@
Begin3
Title: Section 2, 3, 4, 5 and 7 man pages for Linux
Version: 1.12
Entered-date: 1996-07-22
Description: Over 660 man pages for Linux
Keywords: man pages
Author: several
Maintained-by: Andries E. Brouwer (aeb@cwi.nl)
Primary-site: ftp.win.tue.nl:/pub/linux/man
362k man-pages-1.12.tar.gz
Alternate-site: tsx-11.mit.edu /pub/linux/docs/LDP
Alternate-site: sunsite.unc.edu /pub/Linux/docs/linux-doc-project/man-pages
Copying-policy: several; all freely distributable if nroff source included
End

BIN
ftp-archives/tsx-11.mit.edu/1996-10-07/docs/linux-doc-project/man-pages-1.12.tar.gz Normal file
View File

Binary file not shown.

15
ftp-archives/tsx-11.mit.edu/1996-10-07/docs/linux-doc-project/man-pages-de-0.1.lsm Normal file
View File

@@ -0,0 +1,15 @@
Begin3
Title: German man pages for Linux
Version: 0.1
Entered-date: 960413
Description: 179 German man pages for Linux
Keywords: man pages
Author: several
Maintained-by: Andries E. Brouwer (aeb@cwi.nl)
Martin Schulze (joey@infodrom.north.de)
Primary-site: ftp.win.tue.nl:/pub/linux/man/de
157k man-pages-de-0.1.tar.gz
Alternate-site: tsx-11.mit.edu /pub/linux/docs/LDP
Alternate-site: sunsite.unc.edu /pub/Linux/docs/linux-doc-project/man-pages
Copying-policy: several; all freely distributable if nroff source included
End

BIN
ftp-archives/tsx-11.mit.edu/1996-10-07/docs/linux-doc-project/man-pages-de-0.1.tar.gz Normal file
View File

Binary file not shown.

BIN
ftp-archives/tsx-11.mit.edu/1996-10-07/docs/linux-doc-project/nag-1.0.ascii.tar.gz Normal file
View File

Binary file not shown.

BIN
ftp-archives/tsx-11.mit.edu/1996-10-07/docs/linux-doc-project/nag-1.0.dvi.tar.gz Normal file
View File

Binary file not shown.

BIN
ftp-archives/tsx-11.mit.edu/1996-10-07/docs/linux-doc-project/nag-1.0.ps.tar.gz Normal file
View File

Binary file not shown.

BIN
ftp-archives/tsx-11.mit.edu/1996-10-07/docs/linux-doc-project/nag-1.0.src.tar.gz Normal file
View File

Binary file not shown.

60
ftp-archives/tsx-11.mit.edu/1996-10-07/docs/linux-doc-project/sag-0.3.ANNOUNCE Normal file
View File

@@ -0,0 +1,60 @@
`Lasu' Releases SAG 0.3 -- Freeware Book Takes Paves For New World Order
by staff writers
Helsinki, Finland, August 6, 1995 -- In a surprise movement, Lars
``Lasu'' Wirzenius today released the 0.3 edition of the ``Linux System
Administrators' Guide''. Already an industry non-classic, the new
version sports such overwhelming features as an overview of a Linux
system, a completely new climbing session in a tree, and a list of
acknowledgements in the introduction.
The SAG, as the book is affectionately called, is one of the
corner stones of the Linux Documentation Project. ``We at the LDP feel
that we wouldn't be able to produce anything at all, that all our work
would be futile, if it weren't for the SAG,'' says Matt Welsh, director
of LDP, Inc.
The new version is still distributed freely, now even with a
copyright that allows modification. ``More dough,'' explains the author.
Despite insistent rumors about blatant commercialization, the SAG will
probably remain free. ``Even more dough,'' promises the author.
The author refuses to comment on Windows NT and Windows 96
versions, claiming not to understand what the question is about.
Industry gossip, however, tells that Bill Gates, co-founder and CEO of
Microsoft, producer of the Windows series of video games, has visited
Helsinki several times this year. Despite of this, Linus Torvalds,
author of the word processor Linux with which the SAG was written, is
not worried. ``We'll have world domination real soon now, anyway,'' he
explains, ``for 1.4 at the lastest.''
The SAG is one of the major products developed via the Information
Superhighway, the brain child of Al Gore, US Vice President. The ISHW
is being developed with massive govenment funding, since studies show
that it already has more than four hundred users, three years before
the first prototypes are ready. Asked whether he was worried about the
foreign influence in an expensive American Dream, the vice president
said, ``Finland? Oh, we've already bought them, but we haven't told
anyone yet. They're great at building model airplanes as well. And _I_
can spell potato.'' House representatives are not mollified, however,
wanting to see the terms of the deal first, fearing another Alaska.
Rumors about the SAG release have imbalanced the American stock
market for weeks. Several major publishing houses reached an all time
low in the New York Stock Exchange, while publicly competing for the
publishing agreement with Mr. Wirzenius. The negotiations did not work
out, tough. ``Not enough dough,'' says the author, although spokesmen
at both Prentice-Hall and Playboy, Inc., claim the author was incapable
of expressing his wishes in a coherent form during face to face talks,
preferring to communicate via e-mail. ``He kept muttering something
about jiffies and pegs,'' they say.
The central Superhighway site called ``sunsite.unc.edu''
collapsed in the morning before the release. News about the release had
been leaked by a German hacker group, Harmonious Hardware Hackers, who
had cracked into the author's computer earlier in the week. They had
got the release date wrong by one day, and caused dozens of eager fans
to connect to the sunsite computer at the wrong time. ``No computer can
handle that kind of stress,'' explained the mourning sunsite manager,
Erik Troan. ``The spinning disks made the whole computer jump, and
finally it crashed through the floor to the basement.'' Luckily,
repairs were swift and the computer was working again the same evening.
``Thank God we were able to buy enough needles and thread and patch it
together without major problems.'' The site has also installed a new
throttle on the network pipe, allowing at most four clients at the same
time, thus making a new crash less likely. ``The book is now in our
Incoming folder'', says Troan, ``and you're all welcome to come and get it.''

BIN
ftp-archives/tsx-11.mit.edu/1996-10-07/docs/linux-doc-project/sag-0.3.dvi.gz Normal file
View File

Binary file not shown.

BIN
ftp-archives/tsx-11.mit.edu/1996-10-07/docs/linux-doc-project/sag-0.3.ps.gz Normal file
View File

Binary file not shown.

BIN
ftp-archives/tsx-11.mit.edu/1996-10-07/docs/linux-doc-project/sag-0.3.tar.gz Normal file
View File

Binary file not shown.

44
ftp-archives/tsx-11.mit.edu/1996-10-07/docs/linux-faq/linux-faq.README Normal file
View File

@@ -0,0 +1,44 @@
This is the new Frequently Asked Questions with Answers list for
comp.os.linux.help; please read it for more information about Linux
and before posting any questions you may have.
It is available in this directory in the following formats:
linux-faq.ascii 7-bit ASCII text
linux-faq.info Emacs Info hypertext document
linux-faq.ps PostScript, generated by the Lout text formatter
It is also available on the World Wide Web at:
http://www.cl.cam.ac.uk/users/iwj10/linux-faq/index.html
The PostScript conforms to the Adobe Document Structuring Conventions,
and can therefore be run through programs like the psutils. I
recommend that you use psnup, from the psutils[*] package, to print it
2 pages to a printed page.
Also available is
linux-faq.source.tar.gz source files and scripts
This contains the Bizarre Format with No Name source for the FAQ, and
the Perl scripts which convert this to ASCII, Emacs Info and input for
Jeffrey Kingston's Lout typesetter, and the sh scripts which do the
posting and archiving for me. Please be careful not to post a copy of
FAQ with these - don't disable the user/hostname safety check !
[*] Psutils was posted to comp.sources.misc. You should
be able to find the source at any c.s.m archive site.
- Ian Jackson <ijackson@nyx.cs.du.edu> 17th September 1993
Here follows my PGP2 digital signature of the source file
linux-faq.source.tar (note that you must gunzip the file before
attempting to verify the signature):
-----BEGIN PGP MESSAGE-----
Version: 2.6.2i
iQCVAwUAMT4ZscMWjroj9a3bAQH50wP+LLoBc1f+ZHKv5/fvlG7WiecivyM9pJuQ
KY724cbsX+vdKLlguY0AN/pXwJkO04sRrOn/6FSBtS5zY8J+DxbdZbmOs5IpjlzE
djgsOdc8XJqDLrPPc7pqM3xvefhM+ZZJhkolTcANwGYC2319YThF5KOUGznNiWNS
xBHCTFMItGo=
=ag4b
-----END PGP MESSAGE-----

39
ftp-archives/tsx-11.mit.edu/1996-10-07/docs/linux-standards/fsstnd/ChangeLog-1.1-to-1.2 Normal file
View File

@@ -0,0 +1,39 @@
Here is a list of the major specification changes from FSSTND 1.1 to
FSSTND 1.2. Since this is a simplification, it's a good idea to check
out the standard document itself if one of these changes concerns you or
your software.
* /bin: tcsh may be in /bin/tcsh or /usr/bin/tcsh. (It was
previously implied that /bin/tcsh was not compliant.)
* /dev: the Linux device registrar is now H. Peter Anvin
<Peter.Anvin@linux.org>, see the up-to-date device list at
ftp.yggdrasil.com in /pub/device-list.
* /etc: subdirectories of /etc/X11 for each window manager are no
longer required.
* /lib: /lib may contain miscellaneous shared libraries for binaries
required in /bin or /sbin. (As was the case before, but it's
spelled-out now.)
* /lib: /lib/modules is included, but not fully specified.
* /sbin: `ctrlaltdel' is optional.
* /usr: clarify that /usr/X386 is X11R5 on i386, /usr/X11R6 is X11R6
on any Linux system.
* /usr/include: /usr/include/g++ is now required.
* /var/adm is obsolete. lastlog is now in /var/log/lastlog. wtmp
is now in /var/log/utmp. utmp is now in /var/run/utmp.
Transitional symbolic links: /var/adm to /var/log, /var/log/utmp to
/var/run/utmp.
* /var/catman: /usr/man/cat[1-9] is for preformatted (i.e., on a
CD-ROM) manual pages. /var/catman remains a writable cache of
formatted manual pages.
* /var/named has been clarified, especially in relationship to
/etc/named.boot.

21
ftp-archives/tsx-11.mit.edu/1996-10-07/docs/linux-standards/old/000-README Normal file
View File

@@ -0,0 +1,21 @@
alt.os.linux #309 [1]
From: abc@banjo.concert.net (Alan B Clegg)
[1] Announcing: linux-standards mailing list.
Organization: Concert Network -- Internet Operations Group
Date: Tue Jan 28 10:42:51 EST 1992
I am happy to announce the creation of the Linux Standards (linux-standards)
mailing list. The list is chartered as follows:
linux-standards: Discussion of distribution and directory standards for
the Linux Operating System, including directory structure,
file location, and release disk format.
Requests to be added to the mailing list should be sent to:
linux-standards-request@banjo.concert.net
-abc
--
abc@concert.net Alan Clegg - Network Programmer
KD4JML (just my luck!) MCNC -- Center for Communications

254
ftp-archives/tsx-11.mit.edu/1996-10-07/docs/linux-standards/old/File_System_Standard Normal file
View File

@@ -0,0 +1,254 @@
The following is being submitted by Alan Clegg [abc@concert.net] on behalf of
the linux-standards group as the recommended standard for directory file
structure under Linux.
Complete implementation of this file structure is completely voluntary,
and will not be enforced, but will be recommended. This specification
is released as guidelines for people porting and writing software for
the Linux Operating System to allow easy software installation, upgrade, and
tailoring on already installed systems.
Root Directory:
Files:
{none defined by spec}
Directories:
bin dev etc home lib mnt usr
Rationale:
The root directory should not be cluttered with files or
directories, and should contain no user programs.
/bin Directory:
Files:
sh init mount umount dd cat ls fsck mkfs {and as needed}
Directories:
{none defined by spec}
Rationale:
The /bin directory should contain programs that are vital
to the restoration of other file systems in the case of
a corrupting crash. No executable in /bin should require
any other file system to be mounted to execute correctly.
/dev Directory:
Files:
{device files}
Directories:
{none define by spec}
Rationale:
Standard UNIX device files. This directory should contain
device entries for all devices that are supported in the
standard kernel, even if the hardware device does not exist
on the system. Note that the distribution will have all
device files, but they may be removed by the user upon
system installation.
/etc Directory:
Files:
mtab passwd rc ttytab {and as needed}
Directories:
{none defined by spec}
Rationale:
Standard location of files required during system boot. Files
in this directory are usually system specific. Most will
require human intervention during system upgrade.
/home Directory:
Files:
NONE
Directories:
{one per user excepting root}
Rationale:
Standard location of users home directories. Will most likely
be a mounted file system once the system is up. root's home
directory should be /.
/lib Directory:
Files:
{libraries required for system initialization}
Directories:
{none defined by spec}
Rationale:
To keep the size of the root partition small (if separate from
/usr), the files in this directory should only be ones required
by files in the root partition.
/mnt Directory:
Files:
NONE
Directories:
NONE
Rationale:
Standard mount point for external (transient) file systems.
Must be available for sub-system installation. Should remain
as an empty directory.
/tmp Directory:
Files:
NONE
Directories:
NONE
Rationale:
Temporary file space available for general program use. May
become a mounted partition upon system boot.
/usr Directory:
Files:
{none defined by spec}
Directories:
adm bin spool local lib etc man include src tmp
Rationale:
/usr is the mount point for the second major (after root)
hierarchy of file structure and is discussed in the next
section.
/usr/adm Directory:
Files:
{none defined in spec}
Directories:
{none defined in spec}
Rationale:
Location of log files and accounting information.
/usr/bin Directory:
Files:
{all executable files from standard distribution not contined
in /bin}
Directories:
{none defined in spec}
Rationale:
contains 'drop-in' executables that are considered to be
standard to the UNIX system. These files should NOT be
Linux specific, but should have the same function as their
UNIX equivalents.
/usr/etc Directory:
Files:
{none defined in spec}
Directories:
{none defined in spec}
Rationale:
contains configuration files for any files in /usr/bin. helps
to keep /etc clean and small.
/usr/spool Directory:
Files:
{none defined in spec}
Directories:
uucp mail
Rationale:
containes spool files for mail, printing, uucp transfer, etc.
May be a mount point for another volume.
/usr/local Directory:
Files:
NONE
Directories:
bin lib etc man src
Rationale:
contains files local to the specific system. will not be
modified by upgrade process.
/usr/lib Directory:
Files:
libc.a crt0.s {and as needed}
Directories:
{none defined in spec}
Rationale:
location for library files required for multi-user system
operation. This is the directory where program libraries
should reside.
/usr/man Directory:
Files:
NONE
Directories:
man1 man2 man3 man4 man5 man6 man7 man8
cat1 cat2 cat3 cat4 cat5 cat6 cat7 cat8
Rationale:
Contains manual pages for programs that are standard with
Linux.
/usr/include Directory:
Files:
{programmers include files}
Directories:
{as needed}
Rationale:
Standard place for system include files.
/usr/src Directory:
Files:
NONE
Directories:
bin lib linux usr.bin usr.lib
Rationale:
Contains source code for all applications in the release.
/usr/src/linux contains directories required for kernel builds.
/usr/tmp Directory:
Files:
NONE
Directories:
NONE
Rationale:
Used as additional scratch space for programs. If /tmp is
a mounted file system, /usr/tmp may be a symbolic link to
/tmp.

62
ftp-archives/tsx-11.mit.edu/1996-10-07/docs/linux-standards/old/Package_Draft Normal file
View File

@@ -0,0 +1,62 @@
Please comment on the following document.
[available as /pub/Linux/linux-standards/draft]
Tommy Thorn (tthorn@daimi.aau.dk) writes (with my comments in [* ... *]):
We need to make installation REAL SIMPLE AND FAST. I suggest the
following standard for distributing ported programs.
Everything should be contained in a [compressed] tar file with a:
- README, a short explanations of how this version differs from
the original, if it does, and how it was compiled.
- PREREQUIST, again which kernel, but also which version of the
original.
[* Let's call this PREREQ so we can all spell it *]
- Makefile, not for compilation, but for installation!! After having
checked that you agree with paths and so, you just type 'make install'
perhaps as root.
- Patches, context diff against the original.
- Binaries
- Optionally, manual pages, also with full path.
Kernel patches should also be a [compressed] tar file containing:
- README, describing what the patch does/is.
- PREREQUIST, a precise statement of which version of the
kernel the patches applies, and which, if any, patches that
was already applied.
[* Begin Soap Box:
I don't think we should distribute kernel patches in the standard
release trees, unless there is a DEFINITE (fatal) bug fixed by the
patch. Most people are looking for an easy-to-build system with
binaries and sources that they can get up-and-running without much
trouble. Yes, we have to put together kernel patch kits, but we
need to have them coordinated (all patches in one common patchfile).
End Soap Box *]
Sources belong in /usr/src, linux sources in /usr/src/linux, etc.
Maybe we should split patches and binaries, but I don't like that, as you
would properbly end up having only one of either.
[* It is my feeling that we should not distribute patches without the source
that the patches apply to. Often, someone will grab the wrong
"official" source, and the patches won't take. Then they make noises
about the patch not working. I feel that we should provide FULL
SOURCE to all programs, *WITH PATCHES APPLIED*. Leave the patches
in a _common_ directory under each source tree, ie:
/usr/src/gcc/LINPAT/*
^^^^^^ name subject to discussion
to allow someone to see exactly what was changed, but also allow them
to compile without applying the patches themselves. *]

10041
ftp-archives/tsx-11.mit.edu/1996-10-07/docs/linux-standards/old/mail-archives Normal file
View File

File diff suppressed because it is too large Load Diff

BIN
ftp-archives/tsx-11.mit.edu/1996-10-07/docs/linux-standards/private/fsstnd/draft9.tar.gz Normal file
View File

Binary file not shown.

BIN
ftp-archives/tsx-11.mit.edu/1996-10-07/docs/linux-standards/private/fsstnd/fhs-drafts/draft1-95.07.24.tar.gz Normal file
View File

Binary file not shown.

BIN
ftp-archives/tsx-11.mit.edu/1996-10-07/docs/linux-standards/private/fsstnd/fhs-drafts/draft1-95.07.24.txt.gz Normal file
View File

Binary file not shown.

BIN
ftp-archives/tsx-11.mit.edu/1996-10-07/docs/linux-standards/private/fsstnd/fhs-drafts/draft2-95.11.04.tar.gz Normal file
View File

Binary file not shown.

BIN
ftp-archives/tsx-11.mit.edu/1996-10-07/docs/linux-standards/private/fsstnd/fhs-drafts/draft2-95.11.04.txt.gz Normal file
View File

Binary file not shown.

BIN
ftp-archives/tsx-11.mit.edu/1996-10-07/docs/linux-standards/private/fsstnd/fhs-drafts/draft3.tar.gz Normal file
View File

Binary file not shown.

BIN
ftp-archives/tsx-11.mit.edu/1996-10-07/docs/linux-standards/private/fsstnd/fhs-drafts/draft3.txt.gz Normal file
View File

Binary file not shown.

BIN
ftp-archives/tsx-11.mit.edu/1996-10-07/docs/linux-standards/private/fsstnd/fhs-drafts/draft4.tar.gz Normal file
View File

Binary file not shown.

BIN
ftp-archives/tsx-11.mit.edu/1996-10-07/docs/linux-standards/private/fsstnd/fhs-drafts/draft4.txt.gz Normal file
View File

Binary file not shown.

BIN
ftp-archives/tsx-11.mit.edu/1996-10-07/docs/linux-standards/private/fsstnd/fhs-drafts/draft5.tar.gz Normal file
View File

Binary file not shown.

BIN
ftp-archives/tsx-11.mit.edu/1996-10-07/docs/linux-standards/private/fsstnd/fhs-drafts/draft5.txt.gz Normal file
View File

Binary file not shown.

BIN
ftp-archives/tsx-11.mit.edu/1996-10-07/docs/linux-standards/private/fsstnd/fhs-drafts/draft6.tar.gz Normal file
View File

Binary file not shown.

BIN
ftp-archives/tsx-11.mit.edu/1996-10-07/docs/linux-standards/private/fsstnd/fhs-drafts/draft6.txt.gz Normal file
View File

Binary file not shown.

BIN
ftp-archives/tsx-11.mit.edu/1996-10-07/docs/linux-standards/private/fsstnd/fhs-drafts/draft7.tar.gz Normal file
View File

Binary file not shown.

BIN
ftp-archives/tsx-11.mit.edu/1996-10-07/docs/linux-standards/private/fsstnd/fhs-drafts/draft7.txt.gz Normal file
View File

Binary file not shown.

BIN
ftp-archives/tsx-11.mit.edu/1996-10-07/docs/linux-standards/private/fsstnd/fhs-drafts/draft8.tar.gz Normal file
View File

Binary file not shown.

BIN
ftp-archives/tsx-11.mit.edu/1996-10-07/docs/linux-standards/private/fsstnd/fhs-drafts/draft9.txt.gz Normal file
View File

Binary file not shown.

BIN
ftp-archives/tsx-11.mit.edu/1996-10-07/docs/linux-standards/private/fsstnd/fhs.dvi.gz Normal file
View File

Binary file not shown.

BIN
ftp-archives/tsx-11.mit.edu/1996-10-07/docs/linux-standards/private/fsstnd/fhs.ps.gz Normal file
View File

Binary file not shown.

BIN
ftp-archives/tsx-11.mit.edu/1996-10-07/docs/linux-standards/private/fsstnd/fhs.txt.gz Normal file
View File

Binary file not shown.

2904
ftp-archives/tsx-11.mit.edu/1996-10-07/docs/linux-standards/private/fsstnd/post-interim/fsstnd-94.10.21 Normal file
View File

File diff suppressed because it is too large Load Diff

2904
ftp-archives/tsx-11.mit.edu/1996-10-07/docs/linux-standards/private/fsstnd/post-interim/fsstnd-95.02.23 Normal file
View File

File diff suppressed because it is too large Load Diff

2904
ftp-archives/tsx-11.mit.edu/1996-10-07/docs/linux-standards/private/fsstnd/post-interim/fsstnd-95.03.04 Normal file
View File

File diff suppressed because it is too large Load Diff

2970
ftp-archives/tsx-11.mit.edu/1996-10-07/docs/linux-standards/private/fsstnd/post-interim/fsstnd-95.03.23 Normal file
View File

File diff suppressed because it is too large Load Diff

2574
ftp-archives/tsx-11.mit.edu/1996-10-07/docs/linux-standards/private/fsstnd/post-release/fsstnd-94.03.07 Normal file
View File

File diff suppressed because it is too large Load Diff

2640
ftp-archives/tsx-11.mit.edu/1996-10-07/docs/linux-standards/private/fsstnd/post-release/fsstnd-94.03.18 Normal file
View File

File diff suppressed because it is too large Load Diff

2772
ftp-archives/tsx-11.mit.edu/1996-10-07/docs/linux-standards/private/fsstnd/post-release/fsstnd-94.04.13 Normal file
View File

File diff suppressed because it is too large Load Diff

2772
ftp-archives/tsx-11.mit.edu/1996-10-07/docs/linux-standards/private/fsstnd/post-release/fsstnd-94.04.14 Normal file
View File

File diff suppressed because it is too large Load Diff

2772
ftp-archives/tsx-11.mit.edu/1996-10-07/docs/linux-standards/private/fsstnd/post-release/fsstnd-94.04.25 Normal file
View File

File diff suppressed because it is too large Load Diff

2772
ftp-archives/tsx-11.mit.edu/1996-10-07/docs/linux-standards/private/fsstnd/post-release/fsstnd-94.05.03 Normal file
View File

File diff suppressed because it is too large Load Diff

2772
ftp-archives/tsx-11.mit.edu/1996-10-07/docs/linux-standards/private/fsstnd/post-release/fsstnd-94.07.12 Normal file
View File

File diff suppressed because it is too large Load Diff

2838
ftp-archives/tsx-11.mit.edu/1996-10-07/docs/linux-standards/private/fsstnd/post-release/fsstnd-94.07.20 Normal file
View File

File diff suppressed because it is too large Load Diff

2904
ftp-archives/tsx-11.mit.edu/1996-10-07/docs/linux-standards/private/fsstnd/post-release/fsstnd-94.10.07 Normal file
View File

File diff suppressed because it is too large Load Diff

709
ftp-archives/tsx-11.mit.edu/1996-10-07/docs/linux-standards/private/fsstnd/pre-release/draft-93.09.18 Normal file
View File

@@ -0,0 +1,709 @@
The New Linux Filesystem Standard [ draft 93 09 18 ] -*- text -*-
Compiled and written by Daniel Quinlan <quinlan@spectrum.cs.bucknell.edu>.
This draft is a product of the FSSTND channel of the linux-activists
mailing list. Many users, developers, and system administrators gave
input into this standard at all points during its development. In
addition, many other people quietly monitored the proceedings or
privately gave their encouragement and comments. Credit for making
this draft a reality goes to the people who did not turn the channel
into a flame war and allowed discussion to continue at a rational
level throughout the writing and formation of this, a consensus
standard.
------------------------------------------------------------------------
Introduction
This is the first draft of the new Linux filesystem standard. The new
standard is an extensive attempt to correct current problems with the
de-facto (and broken) filesystem standard that is used by developers
of Linux installations packages. Our aim is to produce a standard of
exceptional quality that developers will voluntarily adopt to solve
these well acknowledged problems:
o The directories are not well structured and differ
gratuitously from more modern standards.
o The current organization is known to be confusing to the new
user and equally frustrating (different reasons, same cause)
in nature for the experienced Unix user.
o There are incompatibilities between installation packages
and other releases that are usually solved by methods of
a less than appealing nature.
o Overall, symbolic links are used too often within the
filesystem to fix problems. However, there are times when
symbolic links need to be used to ensure backward
compatibility.
o Linux is not well prepared for a network installation
including the possibility of a read-only /usr partition
and disk-less (or small local disk) workstations.
------------------------------------------------------------------------
History (how we got started)
The original post that motivated this effort to restructure the Linux
filesystem was written by: Olaf Kirsh <okir@monad.swb.de> on August 2,
1993 in the NORMAL channel of the Linux activists mailing list.
Soon thereafter, it was decided that the best way to accomplish such a
restructuring of the Linux filesystem would be to create a mailing
list for the purpose of trying to develop a consensus standard.
After a comprehensive discussion, with surprisingly few flames, a
preliminary draft was written. Then, with the help of several
dedicated people, the draft was finished and that resulting draft
submitted to the FSSTND channel for more discussion.
This is that draft.
------------------------------------------------------------------------
Some specific (and common) problems
o There is no one well-accepted Linux directory structure.
Instead, there are many, each incompatible with each other,
and this alone is enough of a problem to justify this effort.
o The primary binary directories, /bin and /usr/bin, do not
have well defined divisions. The binaries that are in
each path change in the different Linux installation packages.
o The legacy of /etc
configuration files that are not essential appear in /etc
non-essential binaries, such as networking binaries
are often "dumped" into /etc and symbolic links applied
to fix compatibility problems
including both binaries and configuration files makes
/etc more confusing and harder to maintain especially for
inexperienced users or administrators with especially
large systems
o The current implementation of /usr cannot be mounted
read-only because it contains variable files and
directories that need to be written to.
o In a networked environment, certain filesystems contain
information specific to a single machine. Therefore these
filesystems cannot be shared (with NFS).
o More than one temporary mount point is needed on the
multiple disk systems of today.
------------------------------------------------------------------------
Objectives
In trying to solve the above problems, however, we saw several
objectives that must be accomplished in addition to technical
matters. These goals comprise the correction of outstanding problems
as well as the validation of our discussion and work.
o Solve the above problems while also creating as few possible
problems with the past de-facto standards.
o Gain approval of distributors, developers, and other
important people in the Linux movement, as well as their
suggestions.
o Provide a standard that all of the Linux community wishes
to follow because it will solve the above problems as well
as provide the most elegant structure for Linux's filesystem.
o While conformance to this or any other standard in Linux is
obviously completely voluntary, we wish to impress upon
developers that this standard is the best way to organize a
Linux filesystem. If you, as a developer, wish to suggest any
improvements, I am eager to listen.
========================================================================
The Filesystem Standard
This is the root directory structure. In general, enough should be
contained in root partition to boot, restore, recover, and/or repair
the system.
Our primary concern was to keep root as small as reasonably possible
in terms of number of directories, files, and disk space. You might
ask, "Why is this desirable?"
* The root is often mounted from very small media. For example, most
people using Linux install and do recovery by mounting root off of a
RAM disk which is copied from a single 1.44M or 1.2M floppy disk.
* Root has many system unique configuration files in it, a kernel that
may be specific to the system, a different hostname, etc. This means
that root isn't usually shareable between networked systems. Keeping
root small on networked systems minimizes the amount of space lost on
servers to non-shareable files. It also allows workstations with
smaller local hard drives.
* While you may have a large root partition, and may be able to fill
it to your heart's content, there will be people with smaller
partitions. If you have more files installed, you may find
incompatibilities with other systems using limited root partitions.
If you are a developer then the problem is no longer just a personal
one.
No single package should have its own specific root directory. This
structure provides more than enough flexibility for any package. Any
package which does occupy a directory under root suffers from sheer
arrogance.
/ : the root directory
|
|- bin : Command directory with essential binaries
|- dev : Device files
|- etc : Miscellaneous essential system administration files
|- home : User home directories
|- lib : Shared libaries (libc and libm)
|- lost+found : Files and directories found by 'fsck'
|- mnt : Mount points of temporary partitions
|- proc : Proc based process system (procps)
|- root : Home directory for 'root'
|- sbin : System binaries (those binaries once contained in /etc)
|- tmp : Temporary files
|- usr : Second major mount point (permanent)
|- var : Directories of all files that vary with time
\- {kernel image}
The root directory typically contains the kernel image. The kernel
image name is user configurable, but my personal feeling is that Linus
Torvalds has and always should have the say in what the recommended
names for kernels will be. Currently, I believe that his preference
is 'vmlinux' and 'vmlinuz' for uncompressed and compressed kernels,
respectively.
------------------------------------------------------------------------
/bin : Essential binaries only (for use by all users)
There should be no subdirectories within /bin.
The /bin directory should not contain binaries that are only for use
by root only. All root-only binaries such as standard daemons, init,
getty, et al (usually found in /etc), shall now be placed in /sbin or
/usr/sbin (depending on the necessity of the command).
However, there are some considerations you should make before deciding
what belongs in /bin and what doesn't. For instance, if users are
allowed to mount floppies (as I feel the should be), then you would
want to make certain that fsck and the mount utilities are placed in
/bin.
The specific recommendations below assume that users will have access
to floppy drives and therefore places the mount and file system
utilities in /bin. If you wish to be a fascist, you can change this
without too much effort (changing your setup is probably easier than
giving up fascism, but that doesn't mean it is the best way).
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
REQUIRED files for /bin:
general commands:
The following commands have been added because of their
essential nature in the system. A few have been added
because of their traditional placement in /bin.
{ cat, chgrp, chmod, chown, cmp, compress, cp, date, dd, df
du, ed, expr, false, free, grep, hostname, kill, killall, ln,
login, ls, mkdir, mknod, mv, nm, od, ps, pwd, rm, rmdir,
sh, stty, su, sync, test, touch, true, uncompress, uptime, zcat }
note: For compatibility reasons we might want a symbolic link for
mail to /usr/bin/mail where it _probably_ should belong.
/* moved down to "optional": basename, dirname -- I have never
seen any shell scripts that rely on basename and dirname
being placed in /bin. */
filesystem commands:
{ fsck, fsck.*, tunefs, mkfs, mkfs.*, mount, umount }
Normal users should be allowed to mount devices
- provided the mount device is readable
- they own the mount point
- suid programs are disallowed on the mounted filesystem
networking:
These are deemed the only necessary networking binaries that
both root and users will want or need to execute other than
the ones in /usr/bin, obviously.
{ ftp, netstat, ping, telnet }
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
RECOMMENDED files for /bin:
These files should appear in /bin if space is not at a premium
{ more/less, passwd, write, wall }
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
OPTIONAL files for /bin:
These may appear in /bin at the discretion of system
administrators, but are in no way required.
{ basename, bash, csh, dirname, head, tcsh, pstree, tload, top }
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ones we still aren't sure about
// awk sed
// expr
------------------------------------------------------------------------
/dev : Device files
There are no subdirectories within /dev.
/dev usually also contains a file, MAKEDEV, a shell script designed to
create devices as needed. It also often contains a MAKEDEV.local for
any local-only devices.
Symbolic links within /dev "to make it easier to understand" are
dangerous and not a good idea. The largest problem with symlinks in
/dev is that they are often not updated when other devices are. If
you feel you absolutely MUST create links in /dev then use hard links,
and not symbolic ones.
A good standard already exists for Linux devices. We believe that the
current standard should by followed in all cases (although certain
people still wonder about the serial device naming scheme). The
device list is maintained by Rick Miller, the Linux Device Registrar,
<rick@ee.uwm.edu>.
------------------------------------------------------------------------
/etc : Miscellaneous system administration files (including net configuration)
|- lilo : LILO boot sector utilities and configuration
\- {essential system configuration files}
No binaries should go directly into /etc. Commands which would have
in the past been found in /etc should now be placed in /sbin. This
includes such commands as init, getty, and update. Binaries such as
hostname which are used by users as well as root should not be placed
in /sbin, but in /bin.
------------------------------------------------------------------------
/home : User home directories
Administrators of larger systems may wish to subdivide users into
seperate directories such as 'staff', 'faculty', 'students', or
'guests'.
/home is a fairly standard concept, but it is clearly a local
filesystem. The setup will likely differ from machine to machine.
Many people prefer to place user accounts in a variety of places and
because of this reason, no programming should rely on this location.
If you want to find out a user's home directory, you should use the
field in /etc/passwd or another reliable method (I know of no other
reliable methods).
------------------------------------------------------------------------
/lib : Shared libraries (needed to run dynamically linked binaries)
Only the shared library images necessary to boot the system should be
placed in /lib. The shared library images are "/lib/libc.so.*" and
"/lib/libm.so.*" and not the actual ".a" files.
Xfree86 libaries do not belong in /lib. Gcc belongs in /usr/bin.
Essentially, only the dynamic shared libraries needed to run programs
in /bin and /sbin need to be here.
A symbolic link should be added for gcc in /lib pointing to
/usr/bin/gcc. Many Linux programs (such as xrdb) have hardcoded gcc
to be in this, the wrong directory.
------------------------------------------------------------------------
/mnt : Major mount points for temporary partitions from local devices
This directory should contain all temporary mount points. The naming
convention that we recommend using is naming the mount point
(subdirectories of /mnt) after the device that it is being mounted
from. Examples are /mnt/fd0 are /mnt/hda2. It solves the problem of
wanting to temporarily mount two drives at once as well as making the
entire temporary mount business more logical and less confusing.
Although DOS drives can be easily temporarily handled within this
arrangement, some people may wish to have a permanent mounting point
for their DOS drives. I do not use DOS, but the most sensible
proposals that have been put forth is to place DOS in a directory tree
named '/dos' with subdirectores named according to traditional DOS
schemes, i.e. '/dos/a', '/dos/b', and '/dos/c'. This however, is NOT
an offical part of the filesystem standard.
------------------------------------------------------------------------
/proc : Proc based process system
The procps filesystem is becoming the standard Linux method for
containing process information rather than /dev/kmem and other nasty
methods. This is only recommended, but should in time, become the
standard for the storage and retrieval of process information as well
as other kernel and memory information.
------------------------------------------------------------------------
/sbin : System binaries (binaries once kept in /etc)
This is simple. If a user will need to run it, then it should go
somewhere else. If it will only be run by root (i.e. system
administration, networking daemons, system startup), then it should go
in /sbin or in /usr/sbin if the item is not essential. Files such as
'chfn' and 'rlogin' which users only occasionally use should be placed
in /usr/bin. 'ping', although it is absolutely necessary for root
(network recovery and diagnosis) is often used by users and should
live in /bin for that reason.
Also, any local-only system administration stuff should probably go
into /usr/local/sbin.
Let me say it one more time, if there is any chance at all that a user
should need to run it, do not put it here! Users should never have to
place /sbin (or any of the 'sbin' directories) in their path.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
REQUIRED files for /sbin:
general:
{ getty, init, update, mkswap, swapon, swapoff }
networking:
{ ifconfig, routed, inetd, named, syslogd }
/* reasonable arguments exist to reduce this to just 'ifconfig' */
/* route is needed and probably belongs in /sbin. A method is needed
to add static routes. */
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
/sbin is traditionally known for statically linked files although as
you can see we have not even mentioned linking anything statically
yet. This is because we feel that the need for statically linked
files is not great except in several cases:
RECOMMENDED to be linked statically: ln, sync
Yes, neither 'ln' or 'sync' are normally in /sbin, but we feel that
static versions (if they exist) belong in /sbin as well as dynamically
linked versions in /bin
========================================================================
/usr : Second major mount point (permanent)
|
|- X11 : The X windows directory version 11
|- bin : Most user commands
|- dict : Spelling dictionaries
|- doc : Miscellaneous documentation
|- emacs : GNU Emacs installation directory
|- etc : Other configuration files (for programs in /usr/bin)
|- g++-include : GNU C++ include files
|- games : Games and educational binaries
|- include : Header files included by C programs
|- info : The GNU info documentation system's primary directory
|- lib : Libraries
|- local : Local directory (empty after main installation)
|- man : Online manuals
|- sbin : Non-essential system administration binaries
\- src : Source code
Unfortunately, at least the following symbolic links need to be added
to preserve compatibility unless it can be assumed:
/usr/X386 -> /usr/X11
/usr/adm -> /var/adm
/usr/emacs/lock -> /var/emacs/lock
/usr/preserve -> /var/preserve
/usr/spool -> /var/spool
/usr/tmp -> /var/tmp
------------------------------------------------------------------------
/usr/X11 : X386 X11 installation directory
|- bin
|- doc
|- include
|- lib
\- man
This hierarchy is reserved for the use of the X386 release.
The name "X386" is out of date and should really be replaced with the
more accepted, X11, but in order to simplify matters and make X386
more compatible with other X11 packages from XFree86, our
recommendation is to place a symbolic link, /usr/X386 pointing to
/usr/X11.
------------------------------------------------------------------------
/usr/emacs : GNU Emacs installation directory
|- {version-number} : Emacs files for current version
|- lock : Lock directory for Emacs
\- site-lisp : Site specific Emacs-Lisp files
/usr/emacs/{version-number} : Emacs files pertaining to current version only
|- etc
|- i386-linux
\- lisp
Note that info files should be placed in /usr/info, and not in
/usr/emacs/info. A symlink may be needed to link /usr/emacs/info to
/usr/info.
In order to have Emacs on /usr and allow for the possibility of a
read-only /usr partition it is necessary to link /usr/emacs/lock to
/var/emacs/lock.
------------------------------------------------------------------------
/usr/etc
This will ultimately depend on what goes into /usr/sbin, for instance,
if inetd lives in /usr/sbin, then inetd.conf goes here, if syslogd is
in /usr/sbin, then syslog.conf goes here, etc.
/* should programs be looking in ../etc rather than /etc or /usr/etc
specifically? */
------------------------------------------------------------------------
/usr/lib : Libraries for programming (and administative commands?)
|- groff : Libaries/directories for the GNU groff system
|- gcc-lib : System specific files/directories for GNU C compiler
|- terminfo : Directories for terminfo database
|- uucp : Commands for uucp
\- zoneinfo : Timezone information and configuration
The word, library, includes static data files and some internal
binaries as well.
------------------------------------------------------------------------
/usr/local : Local directory
|- bin : Local only binaries
|- etc : Configuration for local only binaries
|- games : Locally installed games
|- lib : Libraries for /usr/local
|- info : Local info pages
|- man : Man page hierarchy for /usr/local
|- sbin : Local only system administration
\- src : Local source codea
This should be 100% empty after installing Linux, no exceptions other
than the listed _empty_ directories.
Let me spell it out for the concept impaired, " E M P T Y ".
It should also be untouched during system upgrades.
------------------------------------------------------------------------
/usr/sbin : Non-essential standard system binaries
Any non-essential system administration binaries, non-essential
networking daemons (most other than those mentioned to be in /sbin),
large system administration tools, interface programs, or anything
used only by the sysadmin that isn't essential.
Local system binaries and shell scripts belong in /usr/local/sbin.
------------------------------------------------------------------------
/usr/src : Source code
|
\- linux : Source code for Linus' kernel
Any non-local source code should be placed in this subdirectory, the
only thing in /usr/src that should always be placed in a certain
location is the kernel source (when present or linked in part to the
/usr/include structure). Also, if you have any taste, you'll learn to
use subdirectories.
The source code for the kernel should always be in place or at least
the include files from the kernel source. Those files are located in
these directories:
/usr/src/linux/include/asm
/usr/src/linux/include/linux
/usr/include usually contains links to 'asm' and 'linux' in the source
directory, therefore, at least those include files should always be
distributed with installations. They should also be distributed in
the /usr/src/linux directory so there are no problems when system
adminstrators upgrade their kernel version.
------------------------------------------------------------------------
/var : Directories of files that vary on different systems and machines
|- adm : System logging and accounting files
|- locks : Lock files // David H. Silber is working on this
|- preserve : Used to save text edited by 'vi' after crash or hangup
|- spool : Directories for queuing work to be performed later
\- tmp : Second temporary directory
This directory contains the directories of all files that vary with
time and is usually a local directory. These include logging files,
accounting files, backup files for editors and other programs, and
spool directories.
The reason for a /var is to make it possible to mount /usr read-only.
Everything that once went into /usr that is written to on a temporary
basis, now goes into /var. Symbolic links, mentioned below, should be
added to /usr for compatibility. This is very helpful if you are
mounting /usr through NFS or if you just want a read-only /usr.
/* /var/domain should be included in the standard (with forward and
reverse subdirectories) */
------------------------------------------------------------------------
/var/spool : Spooling directories (queue work, work to be done later)
|- at : at jobs
|- cron : Cron jobs
|- lpd : Printer spool directory
|- mail : Directory for user mailboxes
|- mqueue : Outgoing mail queue
\- uucp : Spool directory for uucp
/var/spool/lpd : Printer spool directory
|- lpd/{printer device name} : Spools for a given printer
\- {lpd lock files}
------------------------------------------------------------------------
ISSUES:
What is Essential?
The answer is: essential to clean, create, prepare, check, find and
mount other filesystems (possibly on remote machines). There are
other definitions, but this is a general definition that most peple
will at least incorporate into their own.
------------------------------------------------------------------------
Networking
Networking presented an interesting dilemma. Many people like to
place networking binaries and configuration seperate from other
binaries and configuration. However, we disagree. We feel that
networking is not a "package" in the way of Emacs or X386, but an
integral part of most Unix machines. Networking files are certainly
not required on a system, but once they do appear on a system, it is
rare that they will need to be deinstalled or upgraded in the same
manner than one upgrades Emacs or Gcc.
/bin : anything a user will want to use that is also
considered essential (telnet, ping, ftp)
/sbin : anything only root needs and is considered essential
(ifconfig)
/usr/bin : any binaries a user will want to use, that are not
essential (rcp, rlogin, ...)
/usr/sbin : any root only networking binaries that are not
essential (networking daemons, lpd, et al.)
While this may seem confusing at first (and it does take a moment to
digest) it makes good sense. If you can only mount root for some
reason and you need access to networking to repair your system, you
don't need the files to be off in /usr/etc (as they often are). Files
that are needed to mount /usr in normal (and emergency situations) are
placed on the root subtree and any others are placed in /usr in order
to keep the size of root small.
Configuration files for networking similarly go into /etc and /usr/etc
dependent on how they are deemed, essential, or non-essential. This
should coincide with any respective binaries in /sbin or /usr/sbin.
------------------------------------------------------------------------
Symbolic Links
The possibilities for using symbolic links on your system is
practically endless. While symlinks are not encouraged for default
setup (found after installing Linux) in a standard such as this, they
are often used with good purpose on different systems. The point is
that symlinks should be there to keep everything where everyone ELSE
expects it, but you don't want it.
Be prepared to accept that certain directories, even those contained
on the root directory, are still going to be symlinks. For instance,
on some systems /home will not be on the root, but symlinked to a /var
directory, or to somewhere else. /home could also have its own
physical partition, of course, and be mounted on its own.
Similarly, because /usr might be on a central fileserver mounted via
NFS, /usr/local could be symlinked to /var/local. Like
/usr/emacs/lock, this change can be justified by recalling the
definition of /var: "directories of files that vary on different
systems and machines".
Sometimes systems will also link /tmp to /var/tmp if the root
partition becomes too small (or starts out too small). There are more
examples of "good" uses of symbolic links, but the entire issue boils
down to two things: packages should be able to find things where they
expect them (within reason) and symbolic links can be used to solve
the problem in many cases, but problems also can arise from using too
many symbolic links. Problems include getting psychosomatic illments
while typing "ls -al" in symlink-populated areas and being plain old
confused by too many.
------------------------------------------------------------------------
Statically linked binaries
Linux is currently running on a wide variety of systems, some single
user with small disks, some as servers in large networked
environments. Because of this variety, this standard sets no rule
regarding what binaries are static or dynamic with the following two
exceptions. Both 'ln' and 'sync' should have static versions in /sbin
in addition to dynamic versions in /bin since everyday users may wish
to run these too. Large Linux systems may wish to include other
statically linked binaries (sh, init, mkfs, fsck, tunefs, mount,
umount, swapon, swapoff, getty, login, et al). The developers and/or
system administrators are free to statically/dynamically link these
and other binaries as they see fit, as long as the location of the
binaries doesn't change.
Networked systems (especially those of the future which may lack
floppy drives), may want to make ifconfig, route, hostname, and ftp
(meaning an additional static copy in /sbin) static as well.
------------------------------------------------------------------------
CONTRIBUTORS:
Drew Eckhardt <drew@kinglear.cs.Colorado.EDU>
Ian Jackson <ijackson@nyx.cs.du.edu>
Ian McCloghrie <ian@ucsd.edu>
Daniel Quinlan <quinlan@spectrum.cs.bucknell.edu>
Mike Sangrey <mike@sojurn.lns.pa.us>
David H. Silber <dhs@glowworm.firefly.com>
Theodore Ts'o <tytso@ATHENA.MIT.EDU>
Stephen Tweedie <sct@dcs.ed.ac.uk>
------------------------------------------------------------------------

717
ftp-archives/tsx-11.mit.edu/1996-10-07/docs/linux-standards/private/fsstnd/pre-release/draft-93.09.19 Normal file
View File

@@ -0,0 +1,717 @@
The New Linux Filesystem Standard [ draft 93 09 18 ] -*- text -*-
Compiled and written by Daniel Quinlan <quinlan@spectrum.cs.bucknell.edu>.
This draft is a product of the FSSTND channel of the linux-activists
mailing list. Many users, developers, and system administrators gave
input into this standard at all points during its development. In
addition, many other people quietly monitored the proceedings or
privately gave their encouragement and comments. Credit for making
this draft a reality goes to the people who did not turn the channel
into a flame war and allowed discussion to continue at a rational
level throughout the writing and formation of this, a consensus
standard.
------------------------------------------------------------------------
Introduction
This is the first draft of the new Linux filesystem standard. The new
standard is an extensive attempt to correct current problems with the
de-facto (and broken) filesystem standard that is used by developers
of Linux installations packages. Our aim is to produce a standard of
exceptional quality that developers will voluntarily adopt to solve
these well acknowledged problems:
o The directories are not well structured and differ
gratuitously from more modern standards.
o The current organization is known to be confusing to the new
user and equally frustrating (different reasons, same cause)
in nature for the experienced Unix user.
o There are incompatibilities between installation packages
and other releases that are usually solved by methods of
a less than appealing nature.
o Overall, symbolic links are used too often within the
filesystem to fix problems. However, there are times when
symbolic links need to be used to ensure backward
compatibility.
o Linux is not well prepared for a network installation
including the possibility of a read-only /usr partition
and diskless (or small local disk) workstations.
------------------------------------------------------------------------
History (how we got started)
The original post that motivated this effort to restructure the Linux
filesystem was written by: Olaf Kirsh <okir@monad.swb.de> on August 2,
1993 in the NORMAL channel of the Linux activists mailing list.
Soon thereafter, it was decided that the best way to accomplish such a
restructuring of the Linux filesystem would be to create a mailing
list for the purpose of trying to develop a consensus standard.
After a comprehensive discussion, with surprisingly few flames, a
preliminary draft was written. Then, with the help of several
dedicated people, the draft was finished and that resulting draft
submitted to the FSSTND channel for more discussion.
This is that draft.
------------------------------------------------------------------------
Some specific (and common) problems
o There is no single well-accepted Linux directory structure.
Instead, there are many, each incompatible with each other,
and this alone is enough of a problem to justify this effort.
o The primary binary directories, /bin and /usr/bin, do not
have well defined divisions. The binaries that are in
each path change in the different Linux installation packages.
o The legacy of /etc
configuration files that are not essential appear in /etc
non-essential binaries, such as networking binaries
are often "dumped" into /etc and symbolic links applied
to fix compatibility problems
including both binaries and configuration files makes
/etc more confusing and harder to maintain especially for
inexperienced users or administrators with especially
large systems
o The current implementation of /usr cannot be mounted
read-only because it contains variable files and
directories that need to be written to.
o In a networked environment, certain filesystems contain
information specific to a single machine. Therefore these
filesystems cannot be shared (with NFS).
o More than one temporary mount point is needed on the
multiple disk systems of today.
------------------------------------------------------------------------
Objectives
In trying to solve the above problems, however, we saw several
objectives that must be accomplished in addition to technical
matters. These goals comprise the correction of outstanding problems
as well as the validation of our discussion and work.
o Solve the above problems while also creating as few possible
problems with the past de-facto standards.
o Gain approval of distributors, developers, and other
important people in the Linux movement, as well as their
suggestions.
o Provide a standard that all of the Linux community wishes
to follow because it will solve the above problems as well
as provide the most elegant structure for Linux's filesystem.
o While conformance to this or any other standard in Linux is
obviously completely voluntary, we wish to impress upon
developers that this standard is the best way to organize a
Linux filesystem. If you, as a developer, wish to suggest any
improvements, I am eager to listen.
========================================================================
The Filesystem Standard
This is the root directory structure. In general, enough should be
contained in root partition to boot, restore, recover, and/or repair
the system.
Our primary concern was to keep root as small as reasonably possible
in terms of number of directories, files, and disk space. You might
ask, "Why is this desirable?"
* The root is often mounted from very small media. For example, most
people using Linux install and do recovery by mounting root off of a
RAM disk which is copied from a single 1.44M or 1.2M floppy disk.
* Root has many system unique configuration files in it, a kernel that
may be specific to the system, a different hostname, etc. This means
that root isn't usually shareable between networked systems. Keeping
root small on networked systems minimizes the amount of space lost on
servers to non-shareable files. It also allows workstations with
smaller local hard drives.
* While you may have a large root partition, and may be able to fill
it to your heart's content, there will be people with smaller
partitions. If you have more files installed, you may find
incompatibilities with other systems using limited root partitions.
If you are a developer then the problem is no longer just a personal
one.
No single package should have its own specific root directory. This
structure provides more than enough flexibility for any package. Any
package which does occupy a directory under root suffers from sheer
arrogance.
/ : the root directory
|
|- bin : Command directory with essential binaries
|- dev : Device files
|- etc : Miscellaneous essential system administration files
|- home : User home directories
|- lib : Shared libaries (libc and libm)
|- lost+found : Files and directories found by 'fsck'
|- mnt : Mount points of temporary partitions
|- proc : Proc based process system (procps)
|- root : Home directory for 'root'
|- sbin : System binaries (those binaries once contained in /etc)
|- tmp : Temporary files
|- usr : Second major mount point (permanent)
|- var : Directories of all files that vary with time
\- {kernel image}
The root directory typically contains the kernel image. The kernel
image name is user configurable, but my personal feeling is that Linus
Torvalds has and always should have the say in what the recommended
names for kernels will be. Currently, I believe that his preference
is 'vmlinux' and 'vmlinuz' for uncompressed and compressed kernels,
respectively.
------------------------------------------------------------------------
/bin : Essential binaries only (for use by all users)
There should be no subdirectories within /bin.
The /bin directory should not contain binaries that are only for use
by root only. All root-only binaries such as standard daemons, init,
getty, et al (usually found in /etc), shall now be placed in /sbin or
/usr/sbin (depending on the necessity of the command).
However, there are some considerations you should make before deciding
what belongs in /bin and what doesn't. For instance, if users are
allowed to mount floppies (as I feel they should be), then you would
want to make certain that fsck and the mount utilities are placed in
/bin.
The specific recommendations below assume that users will have access
to floppy drives and therefore places the mount and file system
utilities in /bin. If you wish to be a fascist, you can change this
without too much effort (changing your setup is probably easier than
giving up fascism, but that doesn't mean it is the best way).
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
REQUIRED files for /bin:
general commands:
The following commands have been added because of their
essential nature in the system. A few have been added
because of their traditional placement in /bin.
{ cat, chgrp, chmod, chown, cmp, compress, cp, date, dd, df
du, ed, expr, false, free, grep, hostname, kill, killall, ln,
login, ls, mkdir, mknod, mv, nm, od, ps, pwd, rm, rmdir,
sh, stty, su, sync, test, touch, true, uncompress, uptime, zcat }
note: For compatibility reasons we might want a symbolic link for
mail to /usr/bin/mail where it _probably_ should belong.
/* moved down to "optional": basename, dirname -- I have never
seen any shell scripts that rely on basename and dirname
being placed in /bin. */
filesystem commands:
{ fsck, fsck.*, tunefs, mkfs, mkfs.*, mount, umount }
Normal users should be allowed to mount devices
- provided the mount device is readable
- they own the mount point
- suid programs are disallowed on the mounted filesystem
networking:
These are deemed the only necessary networking binaries that
both root and users will want or need to execute other than
the ones in /usr/bin, obviously.
{ ftp, netstat, ping, telnet }
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
RECOMMENDED files for /bin:
These files should appear in /bin if space is not at a premium
{ more/less, passwd, write, wall }
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
OPTIONAL files for /bin:
These may appear in /bin at the discretion of system
administrators, but are in no way required.
{ basename, bash, csh, dirname, head, tcsh, pstree, tload, top }
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ONES WE AREN'T SURE ABOUT:
awk, sed : these are often referenced by shell scripts
expr : many installations stick this in /bin
------------------------------------------------------------------------
/dev : Device files
There are no subdirectories within /dev.
/dev usually also contains a file, MAKEDEV, a shell script designed to
create devices as needed. It also often contains a MAKEDEV.local for
any local-only devices.
Symbolic links within /dev "to make it easier to understand" are
dangerous and not a good idea. The largest problem with symlinks in
/dev is that they are often not updated when other devices are. If
you feel you absolutely MUST create links in /dev then use hard links,
and not symbolic ones.
A good standard already exists for Linux devices. We believe that the
current standard should by followed in all cases (although certain
people still wonder about the serial device naming scheme). The
device list is maintained by Rick Miller, the Linux Device Registrar,
<rick@ee.uwm.edu>.
------------------------------------------------------------------------
/etc : Miscellaneous system administration files (including net configuration)
|- lilo : LILO boot sector utilities and configuration
\- {essential system configuration files}
No binaries should go directly into /etc. Commands which would have
in the past been found in /etc should now be placed in /sbin. This
includes such commands as init, getty, and update. Binaries such as
hostname which are used by users as well as root should not be placed
in /sbin, but in /bin.
------------------------------------------------------------------------
/home : User home directories
Administrators of larger systems may wish to subdivide users into
seperate directories such as 'staff', 'faculty', 'students', or
'guests'.
/home is a fairly standard concept, but it is clearly a local
filesystem. The setup will likely differ from machine to machine.
Many people prefer to place user accounts in a variety of places and
because of this reason, no programming should rely on this location.
If you want to find out a user's home directory, you should use the
field in /etc/passwd or another reliable method (I know of no other
reliable methods).
------------------------------------------------------------------------
/lib : Shared libraries (needed to run dynamically linked binaries)
Only the shared library images necessary to boot the system should be
placed in /lib. The shared library images are "/lib/libc.so.*" and
"/lib/libm.so.*" and not the actual ".a" files.
Xfree86 libaries do not belong in /lib. Gcc belongs in /usr/bin.
Essentially, only the dynamic shared libraries needed to run programs
in /bin and /sbin need to be here.
A symbolic link should be added for gcc in /lib pointing to
/usr/bin/gcc. Many Linux programs (such as xrdb) have hardcoded gcc
to be in this, the wrong directory.
/* note: the debate rages on */
------------------------------------------------------------------------
/mnt : Major mount points for temporary partitions from local devices
This directory should contain all temporary mount points. The naming
convention that we recommend using is naming the mount point
(subdirectories of /mnt) after the device that it is being mounted
from. Examples are /mnt/fd0 and /mnt/hda2. It solves the problem of
wanting to temporarily mount two drives at once as well as making the
entire temporary mount business more logical and less confusing.
Although DOS drives can be easily temporarily handled within this
arrangement, some people may wish to have a permanent mounting point
for their DOS drives. I do not use DOS, but the most sensible
proposals that have been put forth is to place DOS in a directory tree
named '/dos' with subdirectores named according to traditional DOS
schemes, i.e. '/dos/a', '/dos/b', and '/dos/c'. This however, is NOT
an offical part of the filesystem standard.
------------------------------------------------------------------------
/proc : Proc based process system
The procps filesystem is becoming the standard Linux method for
containing process information rather than /dev/kmem and other nasty
methods. This is only recommended, but should in time become the
standard for the storage and retrieval of process information as well
as other kernel and memory information.
------------------------------------------------------------------------
/sbin : System binaries (binaries once kept in /etc)
This is simple. If a user will need to run it, then it should go
somewhere else. If it will only be run by root (i.e. system
administration, networking daemons, system startup), then it should go
in /sbin or in /usr/sbin if the item is not essential. Files such as
'chfn' and 'rlogin' which users only occasionally use should be placed
in /usr/bin. 'ping', although it is absolutely necessary for root
(network recovery and diagnosis) is often used by users and should
live in /bin for that reason.
Also, any local-only system administration stuff should probably go
into /usr/local/sbin.
Let me say it one more time, if there is any chance at all that a user
should need to run it, do not put it here! Users should never have to
place /sbin (or any of the 'sbin' directories) in their path.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
REQUIRED files for /sbin:
general:
{ getty, init, update, mkswap, swapon, swapoff }
networking:
{ ifconfig, routed, inetd, named, syslogd }
/* reasonable arguments exist to reduce this to just 'ifconfig' */
/* route is needed and probably belongs in /sbin. A method is needed
to add static routes. */
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
/sbin is traditionally known for statically linked files although as
you can see we have not even mentioned linking anything statically
yet. This is because we feel that the need for statically linked
files is not great except in several cases:
RECOMMENDED to be linked statically: ln, sync
Yes, neither 'ln' or 'sync' are normally in /sbin, but we feel that
static versions (if they are included) belong in /sbin as well as
dynamically linked versions in /bin
========================================================================
/usr : Second major mount point (permanent)
|
|- X11 : The X windows directory version 11
|- bin : Most user commands
|- dict : Spelling dictionaries
|- doc : Miscellaneous documentation
|- emacs : GNU Emacs installation directory
|- etc : Other configuration files (for programs in /usr/bin)
|- g++-include : GNU C++ include files
|- games : Games and educational binaries
|- include : Header files included by C programs
|- info : The GNU info documentation system's primary directory
|- lib : Libraries
|- local : Local directory (empty after main installation)
|- man : Online manuals
|- sbin : Non-essential system administration binaries
\- src : Source code
Unfortunately, at least the following symbolic links need to be added
to preserve compatibility unless it can be assumed:
/usr/X386 -> /usr/X11
/usr/adm -> /var/adm
/usr/emacs/lock -> /var/emacs/lock
/usr/preserve -> /var/preserve
/usr/spool -> /var/spool
/usr/tmp -> /var/tmp
------------------------------------------------------------------------
/usr/X11 : X386 X11 installation directory
|- bin
|- doc
|- include
|- lib
\- man
This hierarchy is reserved for the use of the X386 release.
The name "X386" is out of date and should really be replaced with the
more accepted, X11, but in order to simplify matters and make X386
more compatible with other X11 packages from XFree86, our
recommendation is to place a symbolic link, /usr/X386 pointing to
/usr/X11.
------------------------------------------------------------------------
/usr/emacs : GNU Emacs installation directory
|- {version-number} : Emacs files for current version
|- lock : Lock directory for Emacs
\- site-lisp : Site specific Emacs-Lisp files
/usr/emacs/{version-number} : Emacs files pertaining to current version only
|- etc
|- i386-linux
\- lisp
Note that info files should be placed in /usr/info, and not in
/usr/emacs/info. A symlink may be needed to link /usr/emacs/info to
/usr/info.
In order to have Emacs on /usr and allow for the possibility of a
read-only /usr partition it is necessary to link /usr/emacs/lock to
/var/emacs/lock.
/* I think this should be /var/lock/emacs rather than
/var/emacs/lock */
------------------------------------------------------------------------
/usr/etc
This will ultimately depend on what goes into /usr/sbin, for instance,
if inetd lives in /usr/sbin, then inetd.conf goes here, if syslogd is
in /usr/sbin, then syslog.conf goes here, etc.
/* should programs be looking in both /etc and /usr/etc rather than
one specifically? */
------------------------------------------------------------------------
/usr/lib : Libraries for programming (and administative commands?)
|- groff : Libaries/directories for the GNU groff system
|- gcc-lib : System specific files/directories for GNU C compiler
|- terminfo : Directories for terminfo database
|- uucp : Commands for uucp
\- zoneinfo : Timezone information and configuration
The word, library, includes static data files and some internal
binaries as well.
------------------------------------------------------------------------
/usr/local : Local directory
|- bin : Local only binaries
|- etc : Configuration for local only binaries
|- games : Locally installed games
|- lib : Libraries for /usr/local
|- info : Local info pages
|- man : Man page hierarchy for /usr/local
|- sbin : Local only system administration
\- src : Local source code
This should be 100% empty after installing Linux, no exceptions other
than the listed _empty_ directories.
Let me spell it out for the concept impaired, " E M P T Y ".
It should also be untouched during system upgrades.
------------------------------------------------------------------------
/usr/sbin : Non-essential standard system binaries
Any non-essential system administration binaries, non-essential
networking daemons (most other than those mentioned to be in /sbin),
large system administration tools, interface programs, or anything
used only by the sysadmin that isn't essential.
Local system binaries and shell scripts belong in /usr/local/sbin.
------------------------------------------------------------------------
/usr/src : Source code
|
\- linux : Source code for Linus' kernel
Any non-local source code should be placed in this subdirectory, the
only thing in /usr/src that should always be placed in a certain
location is the kernel source (when present or linked in part to the
/usr/include structure). Also, if you have any taste, you'll learn to
use subdirectories.
The source code for the kernel should always be in place or at least
the include files from the kernel source. Those files are located in
these directories:
/usr/src/linux/include/asm
/usr/src/linux/include/linux
/usr/include usually contains links to 'asm' and 'linux' in the source
directory, therefore, at least those include files should always be
distributed with installations. They should also be distributed in
the /usr/src/linux directory so there are no problems when system
adminstrators upgrade their kernel version.
------------------------------------------------------------------------
/var : Directories of files that vary on different systems and machines
|- adm : System logging and accounting files
|- locks : Lock files // David H. Silber is working on this
|- preserve : Used to save text edited by 'vi' after crash or hangup
|- spool : Directories for queuing work to be performed later
\- tmp : Second temporary directory
This directory contains the directories of all files that vary with
time and is usually a local directory. These include logging files,
accounting files, backup files for editors and other programs, and
spool directories.
The reason for a /var is to make it possible to mount /usr read-only.
Everything that once went into /usr that is written to on a temporary
basis, now goes into /var. Symbolic links, mentioned below, should be
added to /usr for compatibility. This is very helpful if you are
mounting /usr through NFS or if you just want a read-only /usr.
/* /var/domain should be included in the standard (with forward and
reverse subdirectories) */
------------------------------------------------------------------------
/var/spool : Spooling directories (queue work, work to be done later)
|- at : at jobs
|- cron : Cron jobs
|- lpd : Printer spool directory
|- mail : Directory for user mailboxes
|- mqueue : Outgoing mail queue
\- uucp : Spool directory for uucp
/var/spool/lpd : Printer spool directory
|- lpd/{printer device name} : Spools for a given printer
\- {lpd lock files}
/* I think all lock files belong in /var/locks */
------------------------------------------------------------------------
ISSUES:
What is Essential?
The answer is: essential to clean, create, prepare, check, find and
mount other filesystems (possibly on remote machines). There are
other definitions, but this is a general definition that most peple
will at least incorporate into their own.
------------------------------------------------------------------------
Networking
Networking presented an interesting dilemma. Many people like to
place networking binaries and configuration seperate from other
binaries and configuration. However, we disagree. We feel that
networking is not a "package" in the way of Emacs or X386, but an
integral part of most Unix machines. Networking files are certainly
not required on a system, but once they do appear on a system, it is
rare that they will need to be deinstalled or upgraded in the same
manner than one upgrades Emacs or Gcc.
/bin : anything a user will want to use that is also
considered essential (telnet, ping, ftp)
/sbin : anything only root needs and is considered essential
(ifconfig)
/usr/bin : any binaries a user will want to use, that are not
essential (rcp, rlogin, ...)
/usr/sbin : any root only networking binaries that are not
essential (networking daemons, lpd, et al.)
While this may seem confusing at first (and it does take a moment to
digest) it makes good sense. If you can only mount root for some
reason and you need access to networking to repair your system, you
don't need the files to be off in /usr/etc (as they often are). Files
that are needed to mount /usr in normal (and emergency situations) are
placed on the root subtree and any others are placed in /usr in order
to keep the size of root small.
Configuration files for networking similarly go into /etc and /usr/etc
dependent on how they are deemed, essential, or non-essential. This
should coincide with any respective binaries in /sbin or /usr/sbin.
------------------------------------------------------------------------
Symbolic Links
The possibilities for using symbolic links on your system is
practically endless. While symlinks are not encouraged for default
setup (found after installing Linux) in a standard such as this, they
are often used with good purpose on different systems. The point is
that symlinks should be there to keep everything where everyone ELSE
expects it, but you don't want it.
Be prepared to accept that certain directories, even those contained
on the root directory, are still going to be symlinks. For instance,
on some systems /home will not be on the root, but symlinked to a /var
directory, or to somewhere else. /home could also have its own
physical partition, of course, and be mounted on its own.
Similarly, because /usr might be on a central fileserver mounted via
NFS, /usr/local could be symlinked to /var/local. Like
/usr/emacs/lock, this change can be justified by recalling the
definition of /var: "directories of files that vary on different
systems and machines".
Sometimes systems will also link /tmp to /var/tmp if the root
partition becomes too small (or starts out too small). There are more
examples of "good" uses of symbolic links, but the entire issue boils
down to two things: packages should be able to find things where they
expect them (within reason) and symbolic links can be used to solve
the problem in many cases, but problems also can arise from using too
many symbolic links. Problems include getting psychosomatic ailments
while typing "ls -al" in symlink-populated areas and being plain old
confused by too many.
------------------------------------------------------------------------
Statically linked binaries
Linux is currently running on a wide variety of systems, some single
user with small disks, some as servers in large networked
environments. Because of this variety, this standard sets no rule
regarding what binaries are static or dynamic with the following two
exceptions. Both 'ln' and 'sync' should have static versions in /sbin
in addition to dynamic versions in /bin since everyday users may wish
to run these too. Large Linux systems may wish to include other
statically linked binaries (sh, init, mkfs, fsck, tunefs, mount,
umount, swapon, swapoff, getty, login, et al). The developers and/or
system administrators are free to statically/dynamically link these
and other binaries as they see fit, as long as the location of the
binaries doesn't change.
Networked systems (especially those of the future which may lack
floppy drives), may want to make ifconfig, route, hostname, and ftp
(meaning an additional static copy in /sbin) static as well.
------------------------------------------------------------------------
CONTRIBUTORS:
Drew Eckhardt <drew@kinglear.cs.Colorado.EDU>
Ian Jackson <ijackson@nyx.cs.du.edu>
Ian McCloghrie <ian@ucsd.edu>
Daniel Quinlan <quinlan@spectrum.cs.bucknell.edu>
Mike Sangrey <mike@sojurn.lns.pa.us>
David H. Silber <dhs@glowworm.firefly.com>
Theodore Ts'o <tytso@ATHENA.MIT.EDU>
Stephen Tweedie <sct@dcs.ed.ac.uk>
------------------------------------------------------------------------

835
ftp-archives/tsx-11.mit.edu/1996-10-07/docs/linux-standards/private/fsstnd/pre-release/draft-93.10.01 Normal file
View File

@@ -0,0 +1,835 @@
-*- text -*-
Filesystem Standard Group Daniel Quinlan
draft submitted: 93/10/01 quinlan@bucknell.edu
A Linux Filesystem Structure
Status of this draft
This draft is being distributed to the members of the Linux
community in order to solicit their reaction to the proposals
contained in it. While the issues and solutions discussed may not
meet everyone's specific approval, they may be a good beginning to
solving many problems.
This draft is a product of the Filesystem Standard (FSSTND) section
of the linux-activists@niksula.hut.fi mailing list. This draft is a
working document of the Filesystem Standard channel, the author, and
all other groups collaborating to help create this draft. The
distribution of this draft is limited at this time to those directly
involved in its creation.
------------------------------------------------------------------------
ABSTRACT
This document is an extensive attempt to correct outstanding
problems with the de-facto filesystem standard in use by developers,
programmers, administrators, and users. Our purpose and goal is to
produce a draft of exceptional quality that developers and others will
voluntarily adopt to solve well acknowledged problems.
[ Author's note: My personal hope is that this draft will be
eventually adopted as a better standard than the de-facto standard
produced by the current disarray of ideas. ]
We felt it desirable to first call attention to some fundamental
problems with the current filesystem situation:
(1) There is no single well-accepted Linux directory structure. There
are many different ones, each incompatible with each other, and this
alone is enough of a problem to justify this effort.
(2) In the most common filesystem hierarchies, the directories are not
well structured and differ gratuitously from more modern standards.
(3) The current is known to be confusing to the new user and equally
frustrating (different reasons, same cause) in nature for the
experienced Unix user.
(4) There are incompatibilities between installation packages and
other releases that are usually solved by methods of a less than
appealing nature.
(5) Overall, symbolic links are used too often within the filesystem
to fix problems. However, there are times when symbolic links
need to be used to ensure backward compatibility or to allow
specific systems to have an individual filesystem structure.
The FSSTND group seeks to correct these problems by proposing a good
filesystem structure that the Linux community may voluntarily follow.
While developing this draft, approval and input was received from a
number of Linux developers, noted Linux programmers, many system
administrators, and both experienced and novice users. For this
reason, I feel that following our recommendations is a good thing. If
you feel that there is a problem with this effort or the substance of
the draft, please contact me, Daniel Quinlan <quinlan@bucknell.edu>,
with your comments.
/* I think it may be of benefit to have a "This standard is supported
by foo, bar, and blah" section here or elsewhere in the document,
perhaps at then end. */
------------------------------------------------------------------------
SPECIFIC PROBLEMS
Naturally, while defining a Linux filesystem structure, there were
some specific problems that we sought to correct. Here are some of
the major and well-accepted ones:
o Linux is not well prepared for a network installation including
the possibility of a read-only /usr partition and diskless (or
small local disk) workstations.
o The primary binary directories, /bin and /usr/bin, do not have
well defined divisions between them. The binaries that are in
each path greatly differ between the various Linux installation
packages.
o Problems concerning /etc
- Many configuration files that aren't essential appear in /etc.
- Non-essential binaries, such as networking binaries, are often
dumped into /etc and symbolic links applied to fix any
compatibility problems
- Including both binaries and configuration files in /etc makes
it more confusing and harder to maintain for inexperienced
users or system administrators with especially large systems.
o The current implementation of /usr cannot be mounted read-only
because it contains variable files and directories that need to
be written to.
o In a networked environment, certain filesystems contain
information specific to a single machine. Therefore these
filesystems cannot be shared (with NFS).
o More than one temporary mount point is needed on the multiple
disk systems of today's computers.
------------------------------------------------------------------------
OBJECTIVES
In trying to solve the above problems, we saw several objectives that
needed to be accomplished in addition to the more technical matters.
These goals comprise the correction of outstanding problems as well as
the validation of our discussion and work.
o Solve the above problems while also creating as few possible
problems with the past de-facto standards.
o Gain approval of distributors, developers, and other important
people in the Linux movement, as well as their suggestions.
o Provide a standard that all of the Linux community would choose
to follow because it will solve the above problems as well
as provide the most elegant structure for Linux's filesystem.
o While conformance to this or any other standard in Linux is
obviously completely voluntary, we wish to impress upon
developers that this organization is a very sensible way to
lay out a Linux filesystem. If you, as a developer, wish
to suggest any improvements, I am very eager to listen.
========================================================================
THE FILESYSTEM STRUCTURE
This is the root directory structure. In general, enough should be
contained in root partition to boot, restore, recover, and/or repair
the system.
Our primary concern was to keep root as small as reasonably possible
in terms of number of directories, files, and disk space. You might
ask, "Why is this desirable?"
o The root is often mounted from very small media. For example,
most people using Linux install and do recovery by mounting root
off of a RAM disk which is copied from a single 1.44M or 1.2M
floppy disk.
o Root has many system unique configuration files in it, a kernel
that may be specific to the system, a different hostname, etc.
This means that root isn't usually shareable between networked
systems. Keeping root small on networked systems minimizes the
amount of space lost on servers to non-shareable files. It also
allows workstations with smaller local hard drives.
o While you may have a large root partition, and may be able to
fill it to your heart's content, there will be people with
smaller partitions. If you have more files installed, you may
find incompatibilities with other systems using limited root
partitions. If you are a developer then the problem is no longer
just a personal one.
No single package should have its own specific root directory. This
structure provides more than enough flexibility for any package. Any
package which does occupy a directory under root suffers from sheer
arrogance.
/ : the root directory
|
|- bin : essential command binaries
|- boot : static files of the boot loader
|- dev : device files
|- etc : essential system configuration
|- home : user home directories
|- lib : shared libraries (libc and libm)
|- lost+found : files and directories found by 'fsck'
|- mnt : mount points of temporary partitions
|- proc : process information pseudo-filesystem
|- root : home directory for 'root'
|- sbin : essential system binaries
|- tmp : temporary files
|- usr : second major permanent mount point
|- var : files that vary with time or by machine (non-configuration)
\- {kernel image}
Following this section, each directory is explained in full.
The root directory always contains the current kernel image. The
kernel image name is user configurable, but the name suggested by the
current Linux kernel sources (by Linus Torvalds) is "vmlinux". I am
one that agrees with Linus in this case.
------------------------------------------------------------------------
/boot : static files of the boot loader
This directory contains everything for boot except configuration files
and the map installer. This includes saved master boot sectors,
sector map files, and anything else that is not directly edited by
hand. The boot loader program should be placed into /sbin and
configuration files for boot loaders into /etc.
For LILO:
Old location New location
------------------------ -----------------
/etc/lilo/config.defines /etc/lilo.defines
/etc/lilo/config /etc/lilo.conf
/etc/lilo/disktab /etc/disktab
/etc/lilo/lilo /sbin/lilo
/etc/lilo/boot.NNNN /boot/boot.NNNN
/etc/lilo/part.NNNN /boot/part.NNNN
/etc/lilo/map /boot/map
/etc/lilo/*.b /boot/*.b
*.b are the first and second stage boot loader, plus all those chain
loaders. QuickInst should probably be placed into /usr/sbin and
activate is left out of this scheme because its future is uncertain at
this time. (The LILO distribution itself just puts them into the
current directory.)
------------------------------------------------------------------------
/bin : essential binaries only (for use by all users)
There should be no subdirectories within /bin.
The /bin directory should not contain binaries that are only for use
by root. All root-only binaries such as standard daemons, init,
getty, mkfs, et al (previously found in /etc), shall now be placed in
/sbin or /usr/sbin depending on the necessity of the command. For
discussion and our definition of essential (necessity and related
concepts) please read the "ISSUES" section towards the end of this
draft.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
REQUIRED files for /bin:
general commands:
The following commands have been added because of their
essential nature in the system. A few have been added
because of their traditional placement in /bin.
{ cat, chgrp, chmod, chown, cmp, compress, cp, date, dd, df, du,
ed, false, free, grep, hostname, kill, killall, ln, login, ls,
mkdir, mknod, mv, od, ps, pwd, rm, rmdir, sh, stty, su, sync,
test, touch, true, uncompress, uptime, zcat }
networking:
These are deemed the only necessary networking binaries that
both root and users will want or need to execute other than
the ones in /usr/bin, obviously.
{ ftp, netstat, ping, telnet }
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
RECOMMENDED files for /bin:
These files should appear in /bin if space is not at a premium
{ more (or less), passwd, wall, write }
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
OPTIONAL files for /bin:
These may appear in /bin at the discretion of system
administrators, but are in no way required and may be better
placed in /usr/bin.
{ awk, basename, dirname, expr, head, pstree, tload, top, sed, "any
login shells deemed necessary (bash, tcsh, zsh, et cetera)" }
------------------------------------------------------------------------
/dev : Device files
There are no subdirectories within /dev.
/dev usually also contains a file, MAKEDEV, a shell script designed to
create devices as needed. It also often contains a MAKEDEV.local for
any local-only devices.
Symbolic links within /dev "to make it easier to understand" are
dangerous and not a good idea. The largest problem with symlinks in
/dev is that they are often not updated when other devices are. If
you feel you absolutely MUST create links in /dev then use hard links,
and not symbolic ones.
A good standard already exists for Linux devices. We believe that the
current standard should by followed in all cases. The device list is
maintained by Rick Miller <rick@ee.uwm.edu>, the Linux Device
Registrar.
------------------------------------------------------------------------
/etc : Essential system configuration files
No binaries or subdirectories should go directly into /etc. Commands
which would have in the past been found in /etc should now be placed
in /sbin. This includes such commands as init, getty, and update.
Binaries such as hostname which are used by users as well as root
should not be placed in /sbin, but in /bin.
REQUIRED files for /etc:
{ adjtime, fdprm, fstab, group, initttab, issue, magic, motd, mtab,
mtools, passwd, printcap, profile, protocols, rc*, securetty,
services, shells, termcap, utmp }
networking REQUIRED files (if networking is installed):
{ ftpusers, host, host.conf, hosts.equiv, networks }
shadow REQUIRED files (if the shadow password suite is used):
{ shadow }
Of course, there may be more configuration files than just these, but
some that are not essential should be placed in /usr/etc rather than
/etc.
------------------------------------------------------------------------
/home : User home directories
Each user's directory is typically one of the many subdirectories of
/home.
/home is a fairly standard concept, but it is clearly a local
filesystem. The setup will likely differ from machine to machine.
For instance, administrators of larger systems may wish to subdivide
users into separate directories such as 'staff', 'faculty',
'students', or 'guests'.
Many people prefer to place user accounts in a variety of places and
because of this reason, no programming should rely on this location.
If you want to find out a user's home directory, you should use the
field in /etc/passwd or another reliable method (I know of no other
reliable methods).
------------------------------------------------------------------------
/lib : Shared libraries (needed to run dynamically linked binaries)
Only the shared library images necessary to boot the system should be
placed in /lib. The shared library images are "/lib/libc.so.*" and
"/lib/libm.so.*" and not the actual ".a" files.
Xfree86 libraries do not belong in /lib. Essentially, only the
dynamic shared libraries needed to run programs in /bin and /sbin
should be here.
A single symbolic link for gcc currently exists in /lib pointing
"/lib/gcc -> /usr/lib/gcc-lib/i-?86-linux/2.4.?/gcc". No binaries
should be added to /lib in addition to gcc.
------------------------------------------------------------------------
/mnt : Major mount points for temporary partitions from local devices
This directory should contain all temporary mount points. The naming
convention that we recommend using is naming the mount point
(subdirectories of /mnt) after the device that it is being mounted
from. Examples are /mnt/fd0 and /mnt/hda2. It solves the problem of
wanting to temporarily mount two drives at once as well as making the
entire temporary mount business more logical and less confusing.
Although DOS drives can be easily temporarily handled within this
arrangement, some people may wish to have a permanent mounting point
for their DOS drives. The most sensible proposals that have been
extended by DOS users is to place DOS in a directory tree named '/dos'
with subdirectories named according to traditional DOS schemes,
i.e. '/dos/a', '/dos/b', and '/dos/c'. Other foreign operating
systems can also probably be mounted in a similar manner. This
paragraph is *not* an official part of the filesystem draft.
------------------------------------------------------------------------
/proc : Proc based process system
The procps filesystem is becoming the standard Linux method for
handling process information rather than /dev/kmem and other nasty
methods. This is only recommended, but should in time become the
standard for the storage and retrieval of process information as well
as other kernel and memory information.
------------------------------------------------------------------------
/sbin : System binaries (binaries once kept in /etc)
Utilities used for system administration (and other root-only
commands) are stored in /sbin, /usr/sbin, and /usr/local/sbin. /sbin
typically contains files essential for the booting phase of starting
the system up. Any non-essential commands should be placed into
/usr/sbin. Local-only system administration stuff should now be
placed into /usr/local/sbin.
The concept of what goes into "sbin" directories is simple. If a user
will need to run it, then it should go somewhere else. If it will
only be run by root (i.e. system administration commands, networking
daemons, system startup), then it should go in /sbin (or in /usr/sbin
if the item is not essential). Files such as 'chfn' and 'ac' which
users only occasionally use should still be placed in /usr/bin.
'ping', although it is absolutely necessary for root (network recovery
and diagnosis) is often used by users and should live in /bin for that
reason.
Let me state it one more time, if there is any chance at all that a
user should need to run it, do not put it here! Users should never
have to place /sbin (or any of the 'sbin' directories) in their path.
It is true that they should probably not even be able to execute
anything in /sbin if you (and programmers) have done the job right.
(It is reasonable to let them see what files are in /sbin - please
don't make the directory totally unreadable unless you must!)
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
REQUIRED files for /sbin:
general:
{ getty, init, update, mkswap, swapon, swapoff }
shutdown commands:
{ halt, reboot, shutdown }
filesystem commands:
{ fsck, fsck.*, tunefs, mkfs, mkfs.*, mount, umount }
networking:
{ ifconfig, route }
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
/sbin is traditionally known for statically linked files although as
you can see we have not even mentioned linking anything statically
yet. This is because we feel that the need for statically linked
files is not great except in several cases:
RECOMMENDED to be linked statically: ln, sync
Yes, neither 'ln' or 'sync' are normally placed in /sbin. If the
version of 'ln' and 'sync' that you possess are not a reduced (in
functionality or interface) version of the normal commands then they
should just replace the ones in /bin. If either is a reduced version
that only offers minimal features then it should be kept separately in
/sbin for obvious reasons.
========================================================================
/usr : Second major mount point (permanent)
|
|- X11 : The X windows directory version 11
|- bin : Most user commands
|- dict : Spelling dictionaries
|- doc : Miscellaneous documentation
|- etc : Other configuration files (for programs in /usr/bin)
|- g++-include : GNU C++ include files
|- games : Games and educational binaries
|- include : Header files included by C programs
|- info : The GNU info documentation system's primary directory
|- lib : Libraries
|- local : Local directory (empty after main installation)
|- man : Online manuals
|- sbin : Non-essential system administration binaries
\- src : Source code
Unfortunately, at least the following list of directory symbolic links
need to be added. This is done so that /usr can be read read only and
the name /usr/X386 can be changed to the well-accepted /usr/X11. This
only needs to be done until compatibility with the /var scheme can be
assumed to exist (and the Xfree86 folks realize that 99% of the world
uses /usr/X11 or /usr/X11R5).
/usr/X386 -> /usr/X11
/usr/adm -> /var/adm
/usr/lib/emacs/lock -> /var/lock/emacs (sometimes /usr/local/lib)
/usr/preserve -> /var/preserve
/usr/spool -> /var/spool
/usr/tmp -> /var/tmp
/* question on X11: should we make it X11R5, X11R6, etc. rather than
just X11, I think this would make transition periods easier. */
------------------------------------------------------------------------
/usr/X11 : X386 X11 installation directory
|- bin
|- doc
|- include
|- lib
\- man
This hierarchy is reserved for the use of the X386 release.
The name "X386" is out of date and should really be replaced with the
more accepted, X11, but in order to simplify matters and make X386
more compatible with other X11 packages from XFree86, our
recommendation is to place a symbolic link, /usr/X386 pointing to
/usr/X11.
/* see the above question on the naming of /usr/X11 */
------------------------------------------------------------------------
/usr/etc : Non-essential system configuration files
All non-essential system configuration should be placed in here.
Basically, files placed in here will be configuration for files in
/usr/bin or /usr/sbin.
------------------------------------------------------------------------
/usr/lib : Libraries for programming and packages
|- emacs : Support files for the GNU Emacs editor
|- groff : Libaries/directories for the GNU groff system
|- gcc-lib : System specific files/directories for GNU C compiler
|- terminfo : Directories for terminfo database
|- uucp : Commands for uucp
\- zoneinfo : Timezone information and configuration
The word, library, includes static data files and some internal
binaries as well.
------------------------------------------------------------------------
/usr/local : Local directory
|- bin : Local only binaries
|- etc : Configuration for local only binaries
|- games : Locally installed games
|- lib : Libraries for /usr/local
|- info : Local info pages
|- man : Man page hierarchy for /usr/local
|- sbin : Local only system administration
\- src : Local source code
This should be 100% empty after installing Linux, no exceptions other
than the listed _empty_ directories.
Let me spell it out for the concept impaired, "E-M-P-T-Y".
It should also be untouched during system upgrades.
------------------------------------------------------------------------
/usr/man : Manual page hierarchy
|- man1 : User programs
|- man2 : System calls
|- man3 : Library functions and subroutines
|- man4 : Devices
|- man5 : File formats
|- man6 : Games
|- man7 : Miscellaneous
|- man8 : System Administration
\- man9 : Kernel internal variables and functions
The cat page sections (cat[1-9]) containing formatted manual page
entries are also found within subdirectories of /usr/man, but are not
required nor should they be distributed in lieu of formatted manual
pages.
Local manual pages should be stored in /usr/local/man which contains a
similar directory structure (man[1-8], empty subdirectories can be
omitted).
X Windows manual pages should be stored in /usr/X11/man in an
identical directory structure (man[1-8], empty subdirectories can be
omitted).
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A description of each section follows:
man1: User programs
Manual pages that describe publicly accessible commands are contained
in this chapter. Most program documentation that a user will need to
use is located here.
man2: System calls
This section describes all of the system calls which are entries to
the Linux kernel (operating system). This section can be very useful
to programmers, but users have little need of the items in section 2.
man3: Library functions and subroutines
Section 3 describes user-level library routines. This is another
chapter that is only really of interest to programmers.
man4: Special files
Section 4 describes the special files, related driver functions, and
networking support available in the system. Typically, the device
files found in /dev.
man5: File formats
The formats for many nonintuitive data files are documented in the
section 5. This includes various include files, program output files,
and system files
man6: Games
This chapter documents games, demos, and generally trivial programs.
Different people have various notions about how essential this is.
man7: Miscellaneous
Manual pages that are difficult to classify are designated as being
section 7. The *roff and other text processing macro packages are
found here.
man8: System administration
Documentation for programs used by system administrators for system
operation and maintenance are documented here. Some of these programs
are also occasionally useful for normal users.
man9: Kernel internal variables and functions
This appears on Linux systems to document the kernel source code.
------------------------------------------------------------------------
/usr/sbin : Non-essential standard system binaries
Any non-essential system administration binaries, non-essential
networking daemons (most other than those mentioned to be in /sbin),
large system administration tools, interface programs, or anything
used only by the sysadmin that isn't essential.
Local system binaries and local administration shell scripts belong in
/usr/local/sbin.
------------------------------------------------------------------------
/usr/src : Source code
|
\- linux : Source code for Linus' kernel
Any non-local source code should be placed in this subdirectory, the
only thing in /usr/src that should always be placed in a certain
location is the kernel source (when present or linked in part to the
/usr/include structure). [ Author's note: Also, if you have any
taste, you'll learn to use subdirectories. ]
The source code for the kernel should always be in place or at least
the include files from the kernel source. Those files are located in
these directories:
/usr/src/linux/include/asm
/usr/src/linux/include/linux
/usr/include usually contains links to 'asm' and 'linux' in the source
directory, therefore, at least those include files should always be
distributed with installations. They should also be distributed in
the /usr/src/linux directory so there are no problems when system
administrators upgrade their kernel version.
------------------------------------------------------------------------
/var : Directories of files that vary on different systems and machines
|- adm : System logging and accounting files
|- domain : DNS files
|- locks : Lock files
|- preserve : Used to save text edited by 'vi' after crash or hangup
|- spool : Directories for queuing work to be performed later
\- tmp : Second temporary directory
This directory contains the directories of all files that vary with
time and is usually a local directory. These include logging files,
accounting files, backup files for editors and other programs, and
spool directories.
The reason for a /var is to make it possible to mount /usr read-only.
Everything that once went into /usr that is written to on a temporary
basis, now goes into /var. Symbolic links, mentioned below, should be
added to /usr for compatibility. This is very helpful if you are
mounting /usr through NFS or if you want a read-only /usr.
/* /var/domain should be included in the standard (with forward and
reverse subdirectories) */
/* What was the suggested format for a lock file? Was it
"{device-name}.LOCK" or "LOCK.{device-name}" or was it something very
different? */
------------------------------------------------------------------------
/var/spool : Spooling directories (queue work, work to be done later)
|- at : at jobs
|- cron : Cron jobs
|- lpd : Printer spool directory
|- mail : Directory for user mailboxes
|- mqueue : Outgoing mail queue
\- uucp : Spool directory for uucp
/var/spool/lpd : Printer spool directory
|- lpd/{printer device name} : Spools for a given printer
\- {lpd lock files}
/* I think all future (or not too entrenched) lock files belong in
"/var/locks" */
------------------------------------------------------------------------
ISSUES
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
What is Essential?
The answer is: essential to clean, create, prepare, check, find and
mount other filesystems (possibly on remote machines). There are
other definitions, but this is a general definition that most people
will at least incorporate into their own.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Networking
Networking presented an interesting dilemma. Many people like to
place networking binaries and configuration separate from other
binaries and configuration. However, we disagree. We feel that
networking is not a "package" in the way of Emacs or X386, but an
integral part of most Unix machines. Networking files are certainly
not required on a system, but once they do appear on a system, it is
rare that they will need to be de-installed or upgraded in the same
manner than one upgrades Emacs or Gcc.
/bin : anything a user will want to use that is also
considered essential (telnet, ping, ftp)
/sbin : anything only root needs and is considered essential
(ifconfig)
/usr/bin : any binaries a user will want to use, that are not
essential (rcp, rlogin, ...)
/usr/sbin : any root only networking binaries that are not
essential (networking daemons, lpd, et al.)
While this may seem confusing at first (and it does take a moment to
digest), it does make sense. If you can only mount root for some
reason and you need access to networking to repair your system, you
don't need the files to be off in /usr/etc (as they often are). Files
that are needed to mount /usr in normal (and emergency situations) are
placed on the root subtree and any others are placed in /usr in order
to keep the size of root small.
Configuration files for networking similarly go into /etc and /usr/etc
dependent on how they are deemed, essential, or non-essential. This
should coincide with any respective binaries in /sbin or /usr/sbin.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Symbolic Links
There are a wide range of uses for symbolic links (symlinks) in every
filesystem. While symlinks are not encouraged for default setup
(found after installing Linux) in a standard such as this, they are
often used with good purpose on different systems. The point is that
symlinks should be there to keep everything where everyone else
expects find it
Be prepared to accept that certain directories, even those contained
on the root directory, are still going to be symlinks. For instance,
on some systems /home will not be on the root, but symlinked to a /var
directory, or to somewhere else. /home could also have its own
physical partition, of course, and be mounted on its own.
Similarly, because /usr might be on a central fileserver mounted via
NFS, /usr/local could be symlinked to /var/local. Like
/usr/emacs/lock, this change can be justified by recalling the
definition of /var: "directories of files that vary on different
systems and machines".
Sometimes systems will also link /tmp to /var/tmp if the root
partition becomes too small (or starts out too small). There are more
examples of "good" uses of symbolic links, but the entire issue boils
down to two things: packages should be able to find things where they
expect them (within reason) and symbolic links can be used to solve
the problem in many cases. However, problems also can arise from
using too many symbolic links. These problems include overreliance on
symbolic links to solve problems, confusion resulting from overuse of
symbolic links, and the athethic preferences of different people.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Statically linked binaries
Linux is currently running on a wide variety of systems, some single
user with small disks, some as servers in large networked
environments. Because of this variety, this standard sets no rule
regarding what binaries are static or dynamic with the following two
exceptions. Both 'ln' and 'sync' should have static versions in /sbin
in addition to dynamic versions in /bin since everyday users may wish
to run these too. Large Linux systems may wish to include other
statically linked binaries (sh, init, mkfs, fsck, tunefs, mount,
umount, swapon, swapoff, getty, login, et al). The developers and/or
system administrators are free to statically/dynamically link these
and other binaries as they see fit, as long as the location of the
binaries doesn't change.
Networked systems (especially those of the future which may lack
floppy drives), may want to make ifconfig, route, hostname, and ftp
(meaning an additional static copy in /sbin) static as well.
------------------------------------------------------------------------
ACKNOWLEDGEMENTS
Credit for this text should be given to the FSSTND activists,
developers, users, and system administrators whose input was essential
to this standard. I also wish to thank each of the contributors who
helped me to write and compose this, a consensus standard.
------------------------------------------------------------------------
Major Contributors:
Drew Eckhardt <drew@kinglear.cs.Colorado.edu>
Ian Jackson <ijackson@nyx.cs.du.edu>
Ian McCloghrie <ian@ucsd.edu>
Daniel Quinlan <quinlan@bucknell.edu>
Theodore Ts'o <tytso@athena.mit.edu>
Other Contributors:
Mike Sangrey <mike@sojurn.lns.pa.us>
David H. Silber <dhs@glowworm.firefly.com>
Stephen Tweedie <sct@dcs.ed.ac.uk>
------------------------------------------------------------------------

837
ftp-archives/tsx-11.mit.edu/1996-10-07/docs/linux-standards/private/fsstnd/pre-release/draft-93.10.02 Normal file
View File

@@ -0,0 +1,837 @@
Filesystem Standard Group Daniel Quinlan
draft submitted: 93/10/02 quinlan@bucknell.edu
A Linux Filesystem Structure
Status of this draft
This draft is being distributed to the members of the Linux
community in order to solicit their reaction to the proposals
contained in it. While the issues and solutions discussed may not
meet everyone's specific approval, they may be a good beginning to
solving many problems.
This draft is a product of the Filesystem Standard (FSSTND) section
of the linux-activists@niksula.hut.fi mailing list. This draft is a
working document of the Filesystem Standard channel, the author, and
all other groups collaborating to help create this draft. The
distribution of this draft is limited at this time to those directly
involved in its creation.
------------------------------------------------------------------------
ABSTRACT
This document is an extensive attempt to correct outstanding
problems with the de-facto filesystem standard in use by developers,
programmers, administrators, and users. Our purpose and goal is to
produce a draft of exceptional quality that developers and others will
voluntarily adopt to solve well acknowledged problems.
[ Author's note: My personal hope is that this draft will be
eventually adopted as a better standard than the de-facto standard
produced by the current disarray of ideas. ]
We felt it desirable to first call attention to some fundamental
problems with the current filesystem situation:
(1) There is no single well-accepted Linux directory structure. There
are many different ones, each incompatible with each other, and
this alone is enough of a problem to justify this effort.
(2) In the most commonly used filesystem hierarchies, the directories
are not well structured and differ gratuitously from more modern
standards.
(3) The current layout is known to be confusing to the new user and
equally frustrating (for different reasons, but the same cause)
in nature for the experienced Unix user.
(4) There are incompatibilities between installation packages and
other packages that are usually solved by methods of a less than
appealing nature.
(5) Overall, symbolic links are used too often within the filesystem
to fix problems. However, there are times when symbolic links
need to be used to ensure backward compatibility or to allow
specific systems to have an individual filesystem structure.
The FSSTND group seeks to correct these problems by proposing a good
filesystem structure that the Linux community may voluntarily follow.
While developing this draft, approval and input was received from a
number of Linux developers, noted Linux programmers, many system
administrators, and both experienced and novice users. For this
reason, I feel that following our recommendations is a good thing. If
you feel that there is a problem with this effort or the substance of
the draft, please contact me, Daniel Quinlan <quinlan@bucknell.edu>,
with your comments.
/* I think it may be of benefit to have a "This standard is supported
by these groups, programmers, and developers" section here or
elsewhere in the document, possibly towards the end */
------------------------------------------------------------------------
SPECIFIC PROBLEMS
Naturally, while defining a Linux filesystem structure, there were
some specific problems that we sought to correct. Here are some of
the major and well-accepted ones:
o Linux is not well prepared for a network installation including
the possibility of a read-only /usr partition and diskless (or
small local disk) workstations.
o The primary binary directories, /bin and /usr/bin, do not have
well defined divisions between them. The binaries that are in
each path greatly differ between the various Linux installation
packages.
o Problems concerning /etc
- Many configuration files that aren't essential appear in /etc.
- Non-essential binaries, such as networking binaries, are often
dumped into /etc and symbolic links applied to fix any
compatibility problems
- Including both binaries and configuration files in /etc makes
it more confusing and harder to maintain for inexperienced
users or system administrators with especially large systems.
o The current implementation of /usr cannot be mounted read-only
because it contains variable files and directories that need to
be written to.
o In a networked environment, certain filesystems contain
information specific to a single machine. Therefore these
filesystems cannot be shared (with NFS).
o More than one temporary mount point is needed on the multiple
disk systems of today's computers.
------------------------------------------------------------------------
OBJECTIVES
In trying to solve the above problems, we saw several objectives that
needed to be accomplished in addition to the more technical matters.
These goals comprise the correction of outstanding problems as well as
the validation of our discussion and work.
o Solve the above problems while also creating as few possible
problems with the past de-facto standards.
o Gain approval of distributors, developers, and other important
people in the Linux movement, as well as their suggestions.
o Provide a standard that all of the Linux community would choose
to follow because it will solve the above problems as well
as provide the most elegant structure for Linux's filesystem.
o While conformance to this or any other standard in Linux is
obviously completely voluntary, we wish to impress upon
developers that this organization is a very sensible way to
lay out a Linux filesystem. If you, as a developer, wish
to suggest any improvements, I am very eager to listen.
========================================================================
THE FILESYSTEM STRUCTURE
This is the root directory structure. In general, enough should be
contained in root partition to boot, restore, recover, and/or repair
the system.
Our primary concern was to keep root as small as reasonably possible
in terms of number of directories, files, and disk space. You might
ask, "Why is this desirable?"
o The root is often mounted from very small media. For example,
most people using Linux install and do recovery by mounting root
off of a RAM disk which is copied from a single 1.44M or 1.2M
floppy disk.
o Root has many system unique configuration files in it, a kernel
that may be specific to the system, a different hostname, etc.
This means that root isn't usually shareable between networked
systems. Keeping root small on networked systems minimizes the
amount of space lost on servers to non-shareable files. It also
allows workstations with smaller local hard drives.
o While you may have a large root partition, and may be able to
fill it to your heart's content, there will be people with
smaller partitions. If you have more files installed, you may
find incompatibilities with other systems using limited root
partitions. If you are a developer then the problem is no longer
just a personal one.
No single package should have its own specific root directory. This
structure provides more than enough flexibility for any package. Any
package which does occupy a directory under root suffers from sheer
arrogance.
/ : the root directory
|
|- bin : essential command binaries
|- boot : static files of the boot loader
|- dev : device files
|- etc : essential system configuration
|- home : user home directories
|- lib : shared libraries (libc and libm)
|- lost+found : files and directories found by 'fsck'
|- mnt : mount points of temporary partitions
|- proc : process information pseudo-filesystem
|- root : home directory for 'root'
|- sbin : essential system binaries
|- tmp : temporary files
|- usr : second major permanent mount point
|- var : files that vary with time or by machine (non-configuration)
\- {kernel image}
Following this section, each directory is explained in full.
The root directory always contains the current kernel image. The
kernel image name is user configurable, but the name suggested by the
current Linux kernel sources (by Linus Torvalds) is "vmlinux". I am
one that agrees with Linus in this case.
------------------------------------------------------------------------
/boot : static files of the boot loader
This directory contains everything for boot except configuration files
and the map installer. This includes saved master boot sectors,
sector map files, and anything else that is not directly edited by
hand. The boot loader program should be placed into /sbin and
configuration files for boot loaders into /etc.
For LILO:
Old location New location
------------------------ -----------------
/etc/lilo/config.defines /etc/lilo.defines
/etc/lilo/config /etc/lilo.conf
/etc/lilo/disktab /etc/disktab
/etc/lilo/lilo /sbin/lilo
/etc/lilo/boot.NNNN /boot/boot.NNNN
/etc/lilo/part.NNNN /boot/part.NNNN
/etc/lilo/map /boot/map
/etc/lilo/*.b /boot/*.b
*.b are the first and second stage boot loader, plus all those chain
loaders. QuickInst should probably be placed into /usr/sbin and
activate is left out of this scheme because its future is uncertain at
this time. (The LILO distribution itself just puts them into the
current directory.)
------------------------------------------------------------------------
/bin : essential binaries only (for use by all users)
There should be no subdirectories within /bin.
The /bin directory should not contain binaries that are only for use
by root. All root-only binaries such as standard daemons, init,
getty, mkfs, et al (previously found in /etc), shall now be placed in
/sbin or /usr/sbin depending on the necessity of the command. For
discussion and our definition of essential (necessity and related
concepts) please read the "ISSUES" section towards the end of this
draft.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
REQUIRED files for /bin:
general commands:
The following commands have been added because of their
essential nature in the system. A few have been added
because of their traditional placement in /bin.
{ cat, chgrp, chmod, chown, cmp, compress, cp, date, dd, df, du,
ed, false, free, grep, hostname, kill, killall, ln, login, ls,
mkdir, mknod, mv, od, ps, pwd, rm, rmdir, sh, stty, su, sync,
test, touch, true, uncompress, uptime, w, zcat }
networking:
These are deemed the only necessary networking binaries that
both root and users will want or need to execute other than
the ones in /usr/bin, obviously.
{ ftp, netstat, ping, telnet }
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
RECOMMENDED files for /bin:
These files should appear in /bin if space is not at a premium
{ csh (or tcsh), more (or less), passwd, wall, write }
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
OPTIONAL files for /bin:
These may appear in /bin at the discretion of system
administrators, but are in no way required and may be better
placed in /usr/bin.
{ awk, basename, dirname, expr, head, pstree, tload, top, sed, "other
login shells deemed necessary (bash, tcsh, zsh, et cetera)" }
------------------------------------------------------------------------
/dev : Device files
There are no subdirectories within /dev.
/dev usually also contains a file, MAKEDEV, a shell script designed to
create devices as needed. It also often contains a MAKEDEV.local for
any local-only devices.
Symbolic links within /dev "to make it easier to understand" are
dangerous and not a good idea. The largest problem with symlinks in
/dev is that they are often not updated when other devices are. If
you feel you absolutely MUST create links in /dev then use hard links,
and not symbolic ones.
A good standard already exists for Linux devices. We believe that the
current standard should by followed in all cases. The device list is
maintained by Rick Miller <rick@ee.uwm.edu>, the Linux Device
Registrar.
------------------------------------------------------------------------
/etc : Essential system configuration files
No binaries or subdirectories should go directly into /etc. Commands
which would have in the past been found in /etc should now be placed
in /sbin. This includes such commands as init, getty, and update.
Binaries such as hostname which are used by users as well as root
should not be placed in /sbin, but in /bin.
REQUIRED files for /etc:
{ adjtime, fdprm, fstab, group, initttab, issue, magic, motd, mtab,
mtools, passwd, printcap, profile, protocols, rc*, securetty,
services, shells, termcap, utmp }
networking REQUIRED files (if networking is installed):
{ ftpusers, host, host.conf, hosts.equiv, networks }
shadow REQUIRED files (if the shadow password suite is used):
{ shadow }
Of course, there may be more configuration files than just these, but
some that are not essential should be placed in /usr/etc rather than
/etc.
------------------------------------------------------------------------
/home : User home directories
Each user's directory is typically one of the many subdirectories of
/home.
/home is a fairly standard concept, but it is clearly a local
filesystem. The setup will likely differ from machine to machine.
For instance, administrators of larger systems may wish to subdivide
users into separate directories such as 'staff', 'faculty',
'students', or 'guests'.
Many people prefer to place user accounts in a variety of places and
because of this reason, no programming should rely on this location.
If you want to find out a user's home directory, you should use the
field in /etc/passwd or another reliable method (I know of no other
reliable methods).
------------------------------------------------------------------------
/lib : Shared libraries (needed to run dynamically linked binaries)
Only the shared library images necessary to boot the system should be
placed in /lib. The shared library images are "/lib/libc.so.*" and
"/lib/libm.so.*" and not the actual ".a" files.
Xfree86 libraries do not belong in /lib. Essentially, only the
dynamic shared libraries needed to run programs in /bin and /sbin
should be here.
A single symbolic link for gcc currently exists in /lib pointing
"/lib/cpp -> /usr/lib/gcc-lib/i-?86-linux/2.4.?/cpp". No binaries
should be added to /lib in addition to cpp.
------------------------------------------------------------------------
/mnt : Major mount points for temporary partitions from local devices
This directory should contain all temporary mount points. The naming
convention that we recommend using is naming the mount point
(subdirectories of /mnt) after the device that it is being mounted
from. Examples are /mnt/fd0 and /mnt/hda2. It solves the problem of
wanting to temporarily mount two drives at once as well as making the
entire temporary mount business more logical and less confusing.
Although DOS drives can be easily temporarily handled within this
arrangement, some people may wish to have a permanent mounting point
for their DOS drives. The most sensible proposals that have been
extended by DOS users is to place DOS in a directory tree named '/dos'
with subdirectories named according to traditional DOS schemes,
i.e. '/dos/a', '/dos/b', and '/dos/c'. Other foreign operating
systems can also probably be mounted in a similar manner. This
paragraph is *not* an official part of the filesystem draft.
------------------------------------------------------------------------
/proc : Proc based process system
The procps filesystem is becoming the standard Linux method for
handling process information rather than /dev/kmem and other nasty
methods. This is only recommended, but should in time become the
standard for the storage and retrieval of process information as well
as other kernel and memory information.
------------------------------------------------------------------------
/sbin : System binaries (binaries once kept in /etc)
Utilities used for system administration (and other root-only
commands) are stored in /sbin, /usr/sbin, and /usr/local/sbin. /sbin
typically contains files essential for the booting phase of starting
the system up. Any non-essential commands should be placed into
/usr/sbin. Local-only system administration stuff should now be
placed into /usr/local/sbin.
The concept of what goes into "sbin" directories is simple. If a user
will need to run it, then it should go somewhere else. If it will
only be run by root (i.e. system administration commands, networking
daemons, system startup), then it should go in /sbin (or in /usr/sbin
if the item is not essential). Files such as 'chfn' and 'ac' which
users only occasionally use should still be placed in /usr/bin.
'ping', although it is absolutely necessary for root (network recovery
and diagnosis) is often used by users and should live in /bin for that
reason.
Let me state it one more time, if there is any chance at all that a
user should need to run it, do not put it here! Users should never
have to place /sbin (or any of the 'sbin' directories) in their path.
It is true that they should probably not even be able to execute
anything in /sbin if you (and programmers) have done the job right.
(It is reasonable to let them see what files are in /sbin - please
don't make the directory totally unreadable unless you must!)
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
REQUIRED files for /sbin:
general:
{ getty, init, update, mkswap, swapon, swapoff }
shutdown commands:
{ halt, reboot, shutdown }
filesystem commands:
{ fsck, fsck.*, tunefs, mkfs, mkfs.*, mount, umount }
networking:
{ ifconfig, route }
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
/sbin is traditionally known for statically linked files although as
you can see we have not even mentioned linking anything statically
yet. This is because we feel that the need for statically linked
files is not great except in several cases:
RECOMMENDED to be linked statically: ln, sync
Yes, neither 'ln' or 'sync' are normally placed in /sbin. If the
version of 'ln' and 'sync' that you possess are not a reduced (in
functionality or interface) version of the normal commands then they
should just replace the ones in /bin. If either is a reduced version
that only offers minimal features then it should be kept separately in
/sbin for obvious reasons.
========================================================================
/usr : Second major mount point (permanent)
|
|- X11 : The X windows directory version 11
|- bin : Most user commands
|- dict : Spelling dictionaries
|- doc : Miscellaneous documentation
|- etc : Other configuration files (for programs in /usr/bin)
|- g++-include : GNU C++ include files
|- games : Games and educational binaries
|- include : Header files included by C programs
|- info : The GNU info documentation system's primary directory
|- lib : Libraries
|- local : Local directory (empty after main installation)
|- man : Online manuals
|- sbin : Non-essential system administration binaries
\- src : Source code
Unfortunately, at least the following list of directory symbolic links
need to be added. This is done so that /usr can be read read only and
the name /usr/X386 can be changed to the well-accepted /usr/X11. This
only needs to be done until compatibility with the /var scheme can be
assumed to exist (and the Xfree86 folks realize that 99% of the world
uses /usr/X11 or /usr/X11R5).
/usr/X386 -> /usr/X11
/usr/adm -> /var/adm
/usr/lib/emacs/lock -> /var/lock/emacs (sometimes /usr/local/lib)
/usr/preserve -> /var/preserve
/usr/spool -> /var/spool
/usr/tmp -> /var/tmp
/* question on X11: should we make it X11R5, X11R6, etc. rather than
just X11, I think this would make transition periods easier. */
------------------------------------------------------------------------
/usr/X11 : X386 X11 installation directory
|- bin
|- doc
|- include
|- lib
\- man
This hierarchy is reserved for the use of the X386 release.
The name "X386" is out of date and should really be replaced with the
more accepted, X11, but in order to simplify matters and make X386
more compatible with other X11 packages from XFree86, our
recommendation is to place a symbolic link, /usr/X386 pointing to
/usr/X11.
/* see the above question on the naming of /usr/X11 */
------------------------------------------------------------------------
/usr/etc : Non-essential system configuration files
All non-essential system configuration should be placed in here.
Basically, files placed in here will be configuration for files in
/usr/bin or /usr/sbin.
------------------------------------------------------------------------
/usr/lib : Libraries for programming and packages
|- emacs : Support files for the GNU Emacs editor
|- groff : Libaries/directories for the GNU groff system
|- gcc-lib : System specific files/directories for GNU C compiler
|- terminfo : Directories for terminfo database
|- uucp : Commands for uucp
\- zoneinfo : Timezone information and configuration
The word, library, includes static data files and some internal
binaries as well.
------------------------------------------------------------------------
/usr/local : Local directory
|- bin : Local only binaries
|- etc : Configuration for local only binaries
|- games : Locally installed games
|- lib : Libraries for /usr/local
|- info : Local info pages
|- man : Man page hierarchy for /usr/local
|- sbin : Local only system administration
\- src : Local source code
This should be 100% empty after installing Linux, no exceptions other
than the listed _empty_ directories.
Let me spell it out for the concept impaired, "E-M-P-T-Y".
It should also be untouched during system upgrades.
------------------------------------------------------------------------
/usr/man : Manual page hierarchy
|- man1 : User programs
|- man2 : System calls
|- man3 : Library functions and subroutines
|- man4 : Devices
|- man5 : File formats
|- man6 : Games
|- man7 : Miscellaneous
|- man8 : System Administration
\- man9 : Kernel internal variables and functions
The cat page sections (cat[1-9]) containing formatted manual page
entries are also found within subdirectories of /usr/man, but are not
required nor should they be distributed in lieu of formatted manual
pages.
Local manual pages should be stored in /usr/local/man which contains a
similar directory structure (man[1-8], empty subdirectories can be
omitted).
X Windows manual pages should be stored in /usr/X11/man in an
identical directory structure (man[1-8], empty subdirectories can be
omitted).
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A description of each section follows:
man1: User programs
Manual pages that describe publicly accessible commands are contained
in this chapter. Most program documentation that a user will need to
use is located here.
man2: System calls
This section describes all of the system calls which are entries to
the Linux kernel (operating system). This section can be very useful
to programmers, but users have little need of the items in section 2.
man3: Library functions and subroutines
Section 3 describes user-level library routines. This is another
chapter that is only really of interest to programmers.
man4: Special files
Section 4 describes the special files, related driver functions, and
networking support available in the system. Typically, the device
files found in /dev.
man5: File formats
The formats for many nonintuitive data files are documented in the
section 5. This includes various include files, program output files,
and system files
man6: Games
This chapter documents games, demos, and generally trivial programs.
Different people have various notions about how essential this is.
man7: Miscellaneous
Manual pages that are difficult to classify are designated as being
section 7. The *roff and other text processing macro packages are
found here.
man8: System administration
Documentation for programs used by system administrators for system
operation and maintenance are documented here. Some of these programs
are also occasionally useful for normal users.
man9: Kernel internal variables and functions
This appears on Linux systems to document the kernel source code.
------------------------------------------------------------------------
/usr/sbin : Non-essential standard system binaries
Any non-essential system administration binaries, non-essential
networking daemons (most other than those mentioned to be in /sbin),
large system administration tools, interface programs, or anything
used only by the sysadmin that isn't essential.
Local system binaries and local administration shell scripts belong in
/usr/local/sbin.
------------------------------------------------------------------------
/usr/src : Source code
|
\- linux : Source code for Linus' kernel
Any non-local source code should be placed in this subdirectory, the
only thing in /usr/src that should always be placed in a certain
location is the kernel source (when present or linked in part to the
/usr/include structure). [ Author's note: Also, if you have any
taste, you'll learn to use subdirectories. ]
The source code for the kernel should always be in place or at least
the include files from the kernel source. Those files are located in
these directories:
/usr/src/linux/include/asm
/usr/src/linux/include/linux
/usr/include usually contains links to 'asm' and 'linux' in the source
directory, therefore, at least those include files should always be
distributed with installations. They should also be distributed in
the /usr/src/linux directory so there are no problems when system
administrators upgrade their kernel version.
------------------------------------------------------------------------
/var : Directories of files that vary on different systems and machines
|- adm : System logging and accounting files
|- domain : DNS files (for named), networking only
|- locks : Lock files
|- preserve : Used to save text edited by 'vi' after crash or hangup
|- spool : Directories for queuing work to be performed later
\- tmp : Second temporary directory
This directory contains the directories of all files that vary with
time and is usually a local directory. These include logging files,
accounting files, backup files for editors and other programs, and
spool directories.
The reason for a /var is to make it possible to mount /usr read-only.
Everything that once went into /usr that is written to on a temporary
basis, now goes into /var. The aforementioned symbolic links, also
mentioned below in the "ISSUES" section, should be added to /usr for
compatibility. This is very helpful if you are mounting /usr through
NFS or if you want a read-only /usr.
/* Should we specify that all future lock files be placed in
/var/locks and then further define the structure within /var/locks?
I think "yes" */
------------------------------------------------------------------------
/var/domain: DNS and named stuff (only needed for networking)
|- forward
\- reverse
/* Waiting for technical details */
------------------------------------------------------------------------
/var/spool : Spooling directories (queue work, work to be done later)
|- at : at jobs
|- cron : Cron jobs
|- lpd : Printer spool directory
|- mail : Directory for user mailboxes
|- mqueue : Outgoing mail queue
\- uucp : Spool directory for uucp
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
/var/spool/lpd : Printer spool directory
|- lpd/{printer device name} : Spools for a given printer
\- {printer device}.LOCK : Printer lock files
------------------------------------------------------------------------
ISSUES
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
What is Essential?
The answer is: essential to clean, create, prepare, check, find and
mount other filesystems (possibly on remote machines). There are
other definitions, but this is a general definition that most people
will at least incorporate into their own.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Networking
Networking presented an interesting dilemma. Many people like to
place networking binaries and configuration separate from other
binaries and configuration. However, we disagree. We feel that
networking is not a "package" in the way of Emacs or X386, but an
integral part of most Unix machines. Networking files are certainly
not required on a system, but once they do appear on a system, it is
rare that they will need to be de-installed or upgraded in the same
manner than one upgrades Emacs or Gcc.
/bin : anything a user will want to use that is also
considered essential (ftp, netstat, telnet, ping)
/sbin : anything only root needs and is considered
essential (ifconfig, route)
/usr/bin : any binaries a user will want to use, but are not
essential (finger, rcp, rlogin, et al.)
/usr/sbin : any root only networking binaries that are not
essential (networking daemons, lpd, et al.)
While this may seem confusing at first (and it does take a moment to
digest), it does make sense. If you can only mount root for some
reason and you need access to networking to repair your system, you
don't need the files to be off in /usr/etc (as they often are). Files
that are needed to mount /usr in normal (and emergency situations) are
placed on the root subtree and any others are placed in /usr in order
to keep the size of root small.
Configuration files for networking similarly go into /etc and /usr/etc
dependent on how they are deemed, essential, or non-essential. This
should coincide with any respective binaries in /sbin or /usr/sbin.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Symbolic Links
There are a wide range of uses for symbolic links (symlinks) in every
filesystem. While symlinks are not encouraged for default setup
(found after installing Linux) in a standard such as this, they are
often used with good purpose on different systems. The point is that
symlinks should be there to keep everything where everyone else
expects find it
Be prepared to accept that certain directories, even those contained
on the root directory, are still going to be symlinks. For instance,
on some systems /home will not be on the root, but symlinked to a /var
directory, or to somewhere else. /home could also have its own
physical partition, of course, and be mounted on its own.
Similarly, because /usr might be on a central fileserver mounted via
NFS, /usr/local could be symlinked to /var/local. Like
/usr/emacs/lock, this change can be justified by recalling one
definition of /var: "directories of files that vary on different
systems and machines".
Sometimes systems will also link /tmp to /var/tmp if the root
partition becomes too small (or starts out too small). There are more
examples of "good" uses of symbolic links, but the entire issue boils
down to two things: packages should be able to find things where they
expect them (within reason) and symbolic links can be used to solve
the problem in many cases. However, problems also can arise from
using too many symbolic links. These problems include overreliance on
symbolic links to solve problems, confusion resulting from overuse of
symbolic links, and the athethic preferences of different people.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Statically linked binaries
Linux is currently running on a wide variety of systems, some single
user with small disks, some as servers in large networked
environments. Because of this variety, this standard sets no rule
regarding what binaries are static or dynamic with the following two
exceptions. Both 'ln' and 'sync' should have static versions in /sbin
in addition to dynamic versions in /bin since everyday users may wish
to run these too. Large Linux systems may wish to include other
statically linked binaries (sh, init, mkfs, fsck, tunefs, mount,
umount, swapon, swapoff, getty, login, etc.). The developers and/or
system administrators are free to statically/dynamically link these
and other binaries as they see fit, as long as the location of the
binaries doesn't change.
Networked systems (especially those of the future which may lack
floppy drives), may want to make ifconfig, route, hostname, and ftp
(meaning an additional static copy in /sbin) static as well.
------------------------------------------------------------------------
ACKNOWLEDGEMENTS
Credit for this text should be given to the FSSTND activists,
developers, users, and system administrators whose input was essential
to this standard. I also wish to thank each of the contributors who
helped me to write and compose this, a consensus standard.
------------------------------------------------------------------------
Contributors:
Drew Eckhardt <drew@kinglear.cs.colorado.edu>
Ian Jackson <ijackson@nyx.cs.du.edu>
Ian McCloghrie <ian@ucsd.edu>
Daniel Quinlan <quinlan@bucknell.edu>
Mike Sangrey <mike@sojurn.lns.pa.us>
David H. Silber <dhs@glowworm.firefly.com>
Theodore Ts'o <tytso@athena.mit.edu>
Stephen Tweedie <sct@dcs.ed.ac.uk>
------------------------------------------------------------------------

943
ftp-archives/tsx-11.mit.edu/1996-10-07/docs/linux-standards/private/fsstnd/pre-release/draft-93.10.15 Normal file
View File

@@ -0,0 +1,943 @@
Filesystem Standard Group Daniel Quinlan
draft submitted: 93/10/15 quinlan@bucknell.edu
Advance Draft on Linux Filesystem Structure
Status of this draft
This draft is being distributed to the members of the Linux community
in order to solicit their reactions to the array of ideas, concepts,
and proposals included within it. While the entire content of the
draft may not meet everyone's individual approval, they may be a good
beginning to solving many problems.
This draft is the product of the Filesystem Standard (FSSTND) unit
of the linux-activists@Niksula.hut.fi mailing list. This draft is a
working document of the Filesystem Standard channel, the author, and
all other groups collaborating to help create this draft. The
distribution of this draft is limited at this time to those directly
involved in its development.
------------------------------------------------------------------------
ABSTRACT
This document is an extensive undertaking to correct outstanding
problems with the de-facto filesystem standard in use by developers,
programmers, administrators, and users. Our purpose and goal is to
produce a draft of exceptional quality that developers and others
will voluntarily adopt to solve well acknowledged problems.
The FSSTND group hopes that this draft will be eventually adopted as
a better standard than the de-facto standard produced by the current
disarray of ideas.
We felt that it was desirable to first call attention to some of the
fundamental problems with the current filesystem situation:
(1) There is no single well-accepted Linux directory structure.
Instead, there are many different ones, each being incompatible
with each other, this is a problem that justifies our effort.
(2) In the most widely used filesystem hierarchies, the directories
are not well structured and differ gratuitously from more modern
standards.
(3) The current layout is confusing for new users and equally
unsettling in nature for well-experienced Unix users.
(4) The incompatibilities between primary installation packages and
other software packages are typically solved by methods of a less
than appealing nature.
(5) Overall, symbolic links are used too often within the filesystem
to fix problems. However, there are times when symbolic links
need to be used to ensure backward compatibility or to allow
specific systems to have an individual filesystem structure.
The FSSTND group seeks to correct these problems by proposing a good
filesystem structure that the Linux community may voluntarily follow.
While developing this draft, approval and input was received from a
number of Linux developers, noted Linux programmers, many system
administrators, and both experienced and novice users. For this
reason, I feel that following our recommendations is a good thing.
If you feel that there is a problem with this effort or the substance
of the draft, please first contact the draft coordinator, Daniel
Quinlan <quinlan@bucknell.edu>, with your comments.
------------------------------------------------------------------------
SPECIFIC PROBLEMS
Naturally, while defining a Linux filesystem structure, there were
some specific problems that we sought to correct. Here are some of
the major and well-accepted ones:
o Linux is not well prepared for a network installation including
the possibility of a read-only /usr partition and diskless (or
small local disk) workstations.
o The primary binary directories, /bin and /usr/bin, do not have
well defined divisions between them. The binaries that are in
each path greatly differ between the various Linux installation
packages.
o Problems concerning /etc
- Many configuration files that aren't essential appear in /etc.
- Non-essential binaries, such as networking binaries, are often
dumped into /etc and symbolic links applied to fix any
compatibility problems
- Including both binaries and configuration files in /etc makes
it more confusing and harder to maintain for inexperienced
users or system administrators with especially large systems.
o The current implementation of /usr cannot be mounted read-only
because it contains variable files and directories that need to
be written to.
o In a networked environment, certain filesystems contain
information specific to a single machine. Therefore these
filesystems cannot be shared (with NFS).
While these are some of the major problems we addressed, there were
numerous additional problems that needed to be solved. This draft
attempts to address many of those other problems, but there may be
something we missed. If you wish to bring something to our
attention, please note there are some things we have discussed at
length, but did not include in this draft (for good reasons).
------------------------------------------------------------------------
OBJECTIVES
In trying to solve the above problems, we saw several objectives that
needed to be accomplished in addition to the more technical matters.
These goals comprise the correction of outstanding problems as well
as the validation of our discussion and work.
o Solve the above problems while also limiting the possible
transition difficulties resulting from moving away from the former
de-facto standards.
o Gain approval of distributors, developers, and other important
people in the Linux movement, as well as their suggestions.
o Provide a standard that all of the Linux community would choose
to follow because it will solve the above problems as well
as provide the most sensible structure for Linux's filesystem.
o While conformance to this or any other standard in Linux is
obviously completely voluntary, we wish to impress upon
developers that this organization is a very sensible way to
lay out a Linux filesystem. If you, as a developer, wish
to suggest any improvements, we are willing to listen.
========================================================================
THE FILESYSTEM STRUCTURE
This is the root directory structure. In general, enough should be
contained in root partition to boot, restore, recover, and/or repair the
system.
Our primary concern was to keep root as small as reasonably possible in
terms of number of directories, files, and disk space. You might ask,
"Why is this desirable?"
o The root is often mounted from very small media. For example, most
people using Linux install and do recovery by mounting root off of a
RAM disk which is copied from a single 1.44M or 1.2M floppy disk.
o Root has many system-specific configuration files in it, a kernel
that is specific to the system, a different hostname, etc. This
means that root isn't usually shareable between networked systems.
Keeping root small on networked systems minimizes the amount of
space lost on servers to non-shareable files. It also allows
workstations with smaller local hard drives.
o While you may have a large root partition, and may be able to fill
it to your heart's content, there will be people with smaller
partitions. If you have more files installed, you may find
incompatibilities with other systems using limited root partitions.
If you are a developer then you may be sharing this problem with a
large number of users.
No single package should have its own specific root directory. This
structure provides more than enough flexibility for any package. Any
package which does occupy a directory under root suffers from sheer
arrogance.
/ : the root directory
|
|- bin : essential command binaries
|- boot : static files of the boot loader
|- dev : device files
|- etc : essential system configuration
|- home : user home directories
|- lib : shared libraries ("libc.so.*" and "libm.so.*")
|- lost+found : files and directories found by 'fsck'
|- mnt : mount point of temporary partitions
|- proc : process information pseudo-filesystem
|- root : home directory for root
|- sbin : essential system binaries
|- tmp : temporary files
|- usr : second major permanent mount point
|- var : files that vary with time or by machine (non-configuration)
\- {kernel image}
Following this section, each directory is explained in full.
The root directory always contains the current kernel image. The kernel
image name is user configurable, but the name suggested by the current
Linux kernel sources (from Linus Torvalds) is "vmlinux".
------------------------------------------------------------------------
/bin : essential binaries only (for use by all users)
There should be no subdirectories within /bin.
The /bin directory should not contain binaries that are only for use by
root. All root-only binaries such as standard daemons, init, getty,
mkfs, et al (previously found in /etc), shall now be placed in /sbin or
/usr/sbin depending on the necessity of the command. For discussion and
our definition of essential (necessity and related concepts) please read
the issues and rationale section towards the end of this draft.
Command binaries that are not essential enough to place into /bin should
be placed into /usr/bin, instead.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
REQUIRED files for /bin:
general commands:
The following commands have been added because of their
essential nature in the system. A few have been added
because of their traditional placement in /bin.
{ cat, chgrp, chmod, chown, cmp, compress, cp, date, dd, df, du,
ed, false, free, grep, hostname, kill, killall, ln, login, ls,
mkdir, mknod, mv, od, ps, pwd, rm, rmdir, sh, stty, su, sync,
test, touch, true, uncompress, uptime, w, zcat }
/* possible removal: od */
networking:
These are deemed the only necessary networking binaries that
both root and users will want or need to execute other than
the ones in /usr/bin or /usr/local/bin.
{ ftp, netstat, ping, telnet }
/* possible removal: ftp, telnet */
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
RECOMMENDED files for /bin:
These files should appear in /bin if space is not at a premium
{ "an interactive shell" (preferably csh), "a pager" (more or less),
passwd, wall, write }
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
OPTIONAL files for /bin:
These may appear in /bin at the discretion of system
administrators, but are in no way required and are be better
placed in /usr/bin.
{ awk, basename, dirname, expr, head, pstree, tload, top, sed, "other
login shells deemed necessary (bash, tcsh, zsh, et cetera)" }
/* possible removal: awk, sed
musing: tail
possible move up: basename, dirname, expr (often used in sh scripts) */
------------------------------------------------------------------------
/boot : static files of the boot loader
This directory contains everything for boot except configuration files
and the map installer. This includes saved master boot sectors, sector
map files, and anything else that is not directly edited by hand. The
boot loader program should be placed into /sbin and configuration files
for boot loaders into /etc.
For LILO:
Old location New location
------------------------ -----------------
/etc/lilo/config.defines /etc/lilo.defines
/etc/lilo/config /etc/lilo.conf
/etc/lilo/disktab /etc/disktab
/etc/lilo/lilo /sbin/lilo
/etc/lilo/boot.NNNN /boot/boot.NNNN
/etc/lilo/part.NNNN /boot/part.NNNN
/etc/lilo/map /boot/map
/etc/lilo/*.b /boot/*.b
*.b are the first and second stage boot loader, plus all those chain
loaders. QuickInst (if used at all) should be placed into /usr/sbin and
the activate command is left out of this scheme because its future is
uncertain at this time.
Extra kernel images should be stored in /boot. The main kernel can
either be placed in / or in /boot according to personal preference. If
placed in /, the kernel may possibly be a symlink to a kernel image in
/boot.
------------------------------------------------------------------------
/dev : Device files
There are no subdirectories within /dev.
/dev usually also contains a file, MAKEDEV, a shell script designed to
create devices as needed. It also often contains a MAKEDEV.local for
any local-only devices.
Symbolic links within /dev "to make it easier to understand" are
dangerous and not a good idea. The largest problem with symlinks in /dev
is that they are often not updated when other devices are. If you feel
you absolutely must create links in /dev then use hard links, and not
symbolic ones.
A good standard already exists for Linux devices. We believe that the
current standard should by followed in all cases. The device list is
maintained by Rick Miller <rick@ee.uwm.edu>, the Linux Device Registrar.
/* where is the device standard stored? */
------------------------------------------------------------------------
/etc : Essential system configuration files
No binaries or subdirectories should go directly into /etc. Commands
which would have in the past been found in /etc should now be placed in
/sbin. This includes such commands as init, getty, and update.
Binaries such as hostname which are used by users as well as root should
not be placed in /sbin, but in /bin.
REQUIRED files for /etc:
{ adjtime, fdprm, fstab, group, initttab, issue, magic, motd, mtab,
mtools, passwd, printcap, profile, protocols, rc*, securetty,
services, shells, termcap, utmp }
networking REQUIRED files (if networking is installed):
{ ftpusers, host, host.conf, hosts.equiv, networks }
There may be more configuration files than just these, but some that are
not essential should be placed in /usr/etc rather than /etc.
------------------------------------------------------------------------
/home : User home directories
/home is a fairly standard concept, but it is clearly a site-specific
filesystem. The setup will differ from machine to machine.
On small systems, each user's directory is typically one of the many
subdirectories of /home ("/home/jane", "/home/bill", "/home/xavier", et
cetera).
On large systems (especially when the /home directories are mounted
across a number of machines using NFS) it is a good idea to subdivide
user home directories. Subdivision can be accomplished by using
subdirectories such as /home/staff, /home/guests, /home/students, et
cetera.
Different people prefer to place user accounts in a variety of places
and because of this reason, no programming should rely on this location.
If you want to find out a user's home directory, you should use the
field in /etc/passwd or another reliable method (I know of no other
reliable methods).
------------------------------------------------------------------------
/lib : Shared libraries (needed to run dynamically linked binaries)
Only the shared library images necessary to boot the system should be
placed in /lib. The shared library images are "/lib/libc.so.*" and
"/lib/libm.so.*" and not the actual ".a" files.
XFree86 libraries do not belong in /lib. Essentially, only the dynamic
shared libraries needed to run programs in /bin and /sbin should be
here.
A single symbolic link for gcc currently exists in /lib pointing
"/lib/cpp -> /usr/lib/gcc-lib/i-?86-linux/2.4.?/cpp". No binaries
should be added to /lib in addition to cpp.
------------------------------------------------------------------------
/mnt : Mount point for temporarily mounted filesystems
This is the location where the system administrator may temporarily
mount filesystems as needed. The setup of this directory is a local
issue and should not affect the way any program is run.
------------------------------------------------------------------------
/proc : Proc based process system
The procps filesystem is becoming the standard Linux method for handling
process information rather than /dev/kmem and other nasty methods. This
is only recommended, but should in time become the standard for the
storage and retrieval of process information as well as other kernel and
memory information.
------------------------------------------------------------------------
/sbin : System binaries (binaries once kept in /etc)
Utilities used for system administration (and other root-only commands)
are stored in /sbin, /usr/sbin, and /usr/local/sbin. /sbin typically
contains files essential for the booting phase of starting the system
up. Any non-essential commands should be placed into /usr/sbin.
Local-only system administration stuff should now be placed into
/usr/local/sbin.
The concept of what goes into "sbin" directories is simple. If a user
will need to run it, then it should go somewhere else. If it will only
be run by root (i.e. system administration commands, networking daemons,
system startup), then it should go in /sbin (or in /usr/sbin if the item
is not essential). Files such as 'chfn' and 'ac' which users only
occasionally use should still be placed in /usr/bin. 'ping', although
it is absolutely necessary for root (network recovery and diagnosis) is
often used by users and should live in /bin for that reason.
Let me state it one more time, if there is any chance at all that a user
should need to run it, do not put it here! Users should never have to
place /sbin (or any of the 'sbin' directories) in their path. It is
true that they should probably not even be able to execute anything
dangerous in /sbin if you (and programmers) have done the job right. It
is reasonable to want to let them see what files are in /sbin.
Therefore, don't make the directory totally unreadable unless you must.
/sbin was not created to protect users or to prevent them from seeing
the OS, but to provide a good division between binaries everyone uses
and commands that *only* administrators use (99.9% of the time).
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
REQUIRED files for /sbin:
general:
{ getty, init, update, mkswap, swapon, swapoff }
shutdown commands:
{ halt, reboot, shutdown }
filesystem commands:
{ fsck, fsck.*, tunefs, mkfs, mkfs.*, mount, umount }
networking:
{ ifconfig, route }
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
/sbin is traditionally known for statically linked files although as you
can see we have not even mentioned linking anything statically yet.
This is because we feel that the need for statically linked files is not
great except in several cases:
RECOMMENDED to be linked statically: ln, sync
Yes, neither 'ln' or 'sync' are normally placed in /sbin. If the
version of 'ln' and 'sync' that you possess are not a reduced (in
functionality or interface) version of the normal commands then they
should just replace the ones in /bin. If either is a reduced version
that only offers minimal features then it should be kept separately in
/sbin so that users do not have to use a reduced functionality
command.
========================================================================
/usr : Second major mount point (permanent)
|
|- X11 : The X windows directory version 11
|- bin : Most user commands
|- dict : Spelling dictionaries
|- doc : Miscellaneous documentation
|- etc : Other configuration files (for programs in /usr/bin)
|- g++-include : GNU C++ include files
|- games : Games and educational binaries
|- include : Header files included by C programs
|- info : The GNU info documentation system's primary directory
|- lib : Libraries
|- local : Local directory (empty after main installation)
|- man : Online manuals
|- sbin : Non-essential system administration binaries
\- src : Source code
X11 is possibly a symlink to /usr/X386 or something else.
The following list of directory symbolic links need to be added. This
only needs to be done until compatibility with the /var scheme can be
assumed to exist.
/usr/adm -> /var/adm
/usr/preserve -> /var/preserve
/usr/spool -> /var/spool
/usr/tmp -> /var/tmp
Most of the above symlinks should in time become unneeded as packages
are changed to support /var in addition to /usr.
The GNU Emacs lock file directory, if Emacs is installed, should be a
symlink pointing to /var/lock/emacs if you want to be able to mount /usr
read-only. It is usually found in /usr/emacs, /usr/lib/emacs, or
/usr/local/lib/emacs.
------------------------------------------------------------------------
/usr/X11 : X386 X11 installation directory
|- bin
|- doc
|- include
|- lib
\- man
This hierarchy is reserved for the use of XFree86 X11 releases.
In order to simplify matters and make X386 more compatible with other
X11 packages from XFree86, our recommendation is to place a symbolic
link, /usr/X11 pointing to /usr/X386 (or whatever directory your X11
package was compiled to utilize).
------------------------------------------------------------------------
/usr/etc : Non-essential system configuration files
All non-essential system configuration should be placed in here.
Basically, files placed in here will be configuration for files in
/usr/bin or /usr/sbin.
------------------------------------------------------------------------
/usr/lib : Libraries for programming and packages
|- emacs : Support files for the GNU Emacs editor
|- groff : Libaries/directories for the GNU groff system
|- gcc-lib : System specific files/directories for GNU C compiler
|- terminfo : Directories for terminfo database
|- uucp : Commands for uucp
\- zoneinfo : Timezone information and configuration
The word, library, includes static data files and some internal
binaries as well.
------------------------------------------------------------------------
/usr/local : Local directory
|- bin : Local only binaries
|- etc : Configuration for local only binaries
|- games : Locally installed games
|- lib : Libraries for /usr/local
|- info : Local info pages
|- man : Man page hierarchy for /usr/local
|- sbin : Local only system administration
\- src : Local source code
This should be 100% empty after installing Linux, no exceptions other
than the listed _empty_ directory stubs.
Let me spell it out for the concept impaired, "E M P T Y".
It should also be untouched during system upgrades.
Locally installed software should be placed within /usr/local rather
than /usr *unless* it is being installed to replace or upgrade software
in /usr *or* it is felt that the installed software is "important
enough" to place in /usr or in /.
------------------------------------------------------------------------
/usr/man : Manual page hierarchy
|- man1 : User programs
|- man2 : System calls
|- man3 : Library functions and subroutines
|- man4 : Devices
|- man5 : File formats
|- man6 : Games
|- man7 : Miscellaneous
|- man8 : System Administration
\- man9 : Kernel internal variables and functions
The cat page sections (cat[1-9]) containing formatted manual page
entries are also found within subdirectories of /usr/man, but are not
required nor should they be distributed in lieu of nroff source manual
pages.
Local manual pages should be stored in /usr/local/man which contains a
similar directory structure (man[1-8], empty subdirectories can be
omitted).
X Windows manual pages should be stored in /usr/X11/man in an
identical directory structure (man[1-8], empty subdirectories can be
omitted).
As Linux (and Unix) is further utilized in foreign countries and manual
pages are translated to non-English versions, there is the impending
problem that these manual pages will have to be stored somewhere else.
Some German releases of Linux have already created a manual page system
that is placed in /usr/man with the suffix "g". This is a poor solution
and will cause further problems in the long run as other langauges
appear, especially other langauges starting with the same letter
(Gaelic, Greek, whatever).
Therefore, all non-English manual pages sections should be stored in
subdirectories within /usr/man named according to the language that the
the contained manual pages are written in (lowercase characters), hence,
for the German manual pages:
/usr/man/german/man[1-9] and possibly /usr/man/german/cat[1-9]
Then, German-speaking Linux users can add /usr/man/german to their
MANPATH before /usr/man so that /usr/man/german manual pages are
referenced first. If a German manual page is not found for a given
command then the English version may be referenced. This setup will be
needed as the number of foreign (non-English) manual pages increases.
German is the language mentioned here since it is the only non-English
manual page system distributed with any Linux system at this time.
Other languages will probably follow and they should follow this scheme
as well.
The practice of placing non-English in subdirectories of /usr/man should
be followed as well for other manual page hierarchies, such as
/usr/local/man and /usr/X11/man.
Using the language itself (/usr/man/deutsch) rather than the English
(/usr/man/german) was strongly considered, but this was met with
disapproval from many people, including those who do not speak English
as a first language. Reasons: simplicity, the difficulty in displaying
many languages' names in 7 bit characters, and the fact that everyone
can hopefully recognize what their language is in English.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A description of each section follows:
man1: User programs
Manual pages that describe publicly accessible commands are contained
in this chapter. Most program documentation that a user will need to
use is located here.
man2: System calls
This section describes all of the system calls which are entries to
the Linux kernel (operating system). This section can be very useful
to programmers, but users have little need of the items in section 2.
man3: Library functions and subroutines
Section 3 describes user-level library routines. This is another
chapter that is only really of interest to programmers.
man4: Special files
Section 4 describes the special files, related driver functions, and
networking support available in the system. Typically, the device
files found in /dev.
man5: File formats
The formats for many nonintuitive data files are documented in the
section 5. This includes various include files, program output files,
and system files
man6: Games
This chapter documents games, demos, and generally trivial programs.
Different people have various notions about how essential this is.
man7: Miscellaneous
Manual pages that are difficult to classify are designated as being
section 7. The *roff and other text processing macro packages are
found here.
man8: System administration
Documentation for programs used by system administrators for system
operation and maintenance are documented here. Some of these programs
are also occasionally useful for normal users.
man9: Kernel internal variables and functions
This appears on Linux systems to document the kernel source code.
------------------------------------------------------------------------
/usr/sbin : Non-essential standard system binaries
Any non-essential system administration binaries, non-essential
networking daemons (most other than those mentioned to be in /sbin),
large system administration tools, interface programs, or anything
used only by the sysadmin that isn't essential.
Local system binaries and local administration shell scripts belong in
/usr/local/sbin.
------------------------------------------------------------------------
/usr/src : Source code
|
\- linux : Source code for Linus' kernel
Any non-local source code should be placed in this subdirectory, the
only thing in /usr/src that should always be placed in a certain
location is the kernel source (when present or linked in part to the
/usr/include structure). [ Author's note: Also, if you have any taste,
you'll learn to use subdirectories. ]
The source code for the kernel should always be in place or at least the
include files from the kernel source. Those files are located in these
directories:
/usr/src/linux/include/asm
/usr/src/linux/include/linux
/usr/include usually contains links to 'asm' and 'linux' in the source
directory, therefore, at least those include files should always be
distributed with installations. They should also be distributed in the
/usr/src/linux directory so there are no problems when system
administrators upgrade their kernel version for the first time.
------------------------------------------------------------------------
/var : Directories of files that vary on different systems and machines
|- adm : System logging and accounting files
|- domain : DNS files (for named), networking only
|- lock : Lock files
|- preserve : Used to save text edited by 'vi' after crash or hangup
|- spool : Directories for queuing work to be performed later
\- tmp : Second temporary directory
This directory contains the directories of all files that vary with time
and is usually a local directory. These include logging files,
accounting files, backup files for editors and other programs, and spool
directories.
The reason for a /var is to make it possible to mount /usr read-only.
Everything that once went into /usr that is written to on a temporary
basis, now goes into /var. The aforementioned symbolic links, also
mentioned below in the issues and rationale section, should be added to
/usr for compatibility. This is very helpful if you are mounting /usr
through NFS or if you want a read-only /usr.
------------------------------------------------------------------------
/var/domain : DNS and named stuff
|- forward
\- reverse
This is only needed for systems using DNS (networking protocol for
name servers).
/* I am hoping to add a *much* more extensive explanation after some
contact is made with Linux networking developers. There is a very
excellent proposal from Drew Eckhardt (that has precedence as well)
that will eventually be discussed. */
------------------------------------------------------------------------
/var/lock : Lock files
|- device : Device locks
\- emacs : Emacs lock files
Lock files should be stored with a subdirectory of /var/lock appropriate
subdirectory such as the emacs lock file directory. This directory
*does not* replace older locations for lock files other than
/usr/spool/uucp and the serial lock files that were contained within it.
However, if you are the maintainer of a program that uses lock files and
you wish to add a subdirectory for lock files within /var/lock, then it
is a good idea to contact the FSSTND channel or myself to discuss
placement of a directory for your lock files.
If you are interested in being able to mount /usr read-only then you may
wish to recompile whatever package it is that uses /usr for lock files
and place them in here, again - contact me if you want to add stuff on a
permanent basis (i.e. you are a developer or a programmer of a Linux
package).
The Emacs editor's lock files should be saved in /var/lock/emacs. It is
necessary to recompile Emacs to do this or to place an appropriate
symlink where the Emacs lock file directory lies.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
/var/lock/device: Device lock files
All lock files for devices should now be placed in /var/lock/device
rather than /usr/spool/uucp or whereever they were stored in the past.
------------------------------------------------------------------------
/var/spool : Spooling directories (queue work, work to be done later)
|- at : at jobs
|- cron : Cron jobs
|- lpd : Printer spool directory
|- mail : Directory for user mailboxes
|- mqueue : Outgoing mail queue
\- uucp : Spool directory for uucp
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
/var/spool/lpd : Printer spool direcotry
|- {printer name} : Spools for a specific printer
\- {printer name}.LOCK : Lock file for a specific printer
------------------------------------------------------------------------
Issues and Addtional Rationale
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
What is Essential?
The answer is: essential to clean, create, prepare, check, find and
mount other filesystems (possibly on remote machines). There are other
definitions, but this is a general definition that most people will at
least incorporate into their own.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Networking
Networking presented an interesting dilemma. Many people like to place
networking binaries and configuration separate from other binaries and
configuration. However, we disagree. We feel that networking is not a
"package", but an integral part of most Unix machines. Because of this
networking should not be placed into a single directory, but
systematically placed in the appropriate directories.
/bin : anything a user will want to use that is also
considered essential (ftp, netstat, telnet, ping)
/sbin : anything only root needs and is considered
essential (ifconfig, route)
/usr/bin : any binaries a user will want to use, but are not
essential (finger, rcp, rlogin, et al.)
/usr/sbin : any root only networking binaries that are not
essential (networking daemons, lpd, et al.)
While this may seem confusing at first (and it does take a moment to
digest), it does make sense. If you can only mount root for some reason
and you need access to networking to repair your system, you don't need
the files to be off in /usr/etc (as they often are). Files that are
needed to mount /usr in normal (and emergency situations) are placed on
the root subtree and any others are placed in /usr in order to keep the
size of root small.
Configuration files for networking similarly go into /etc and /usr/etc.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Architecture-independent Structures
Many people note that in this draft, there is no /usr/share. The
structure, /usr/share, typically contains architecture-independent files
such as man-pages, timezone, terminfo information, et al. As of this
time, there are no different architectures for Linux, but with the
passage of time we should see Linux include other architectures.
The reason that we do not include /usr/share in this standard is that
/usr/share is very difficult to set up *without* another architecture to
examine when defining the structure. Keep in mind that things commonly
specified, like "/usr/share/man" are obvious . . . and wrong. After
all, some manual pages (like the man pages for the devices:
/usr/man/man4) will be architecture specific. In addition, there may be
other files which may actually turn out to be architecture specific
simply because the DBM formats are not compatible.
Thus, we are going to wait on /usr/share for now. If we need /usr/share
in the future, it is simple enough to put in symlinks from the current
existing structure into /usr/share. So the primary directory names
which programs should reference should be /usr/man, and then if
appropriate certain directories in /usr/man can be symlinked to
/usr/share/man. This avoid "gotcha's" like /usr/man/man4 that people
will probably forget about if we try to design /usr/share without
actually mapping out a NFS supported /usr that supports multiple
architectures.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Symbolic Links
There are a wide range of uses for symbolic links (symlinks) in every
filesystem. While symlinks are not encouraged for default setup (found
after installing Linux) in a standard such as this, they are often used
with good purpose on different systems. The point is that symlinks
should be there to keep everything where everyone else expects find it
Be prepared to accept that certain directories, even those contained on
the root directory, are still going to be symlinks. For instance, on
some systems /home will not be on the root, but symlinked to a /var
directory, or to somewhere else. /home could also have its own physical
partition, of course, and be mounted on its own.
Similarly, because /usr might be on a central fileserver mounted via
NFS, /usr/local could be symlinked to /var/local. Like /usr/emacs/lock,
this change can be justified by recalling one definition of /var:
"directories of files that vary on different systems and machines".
Sometimes systems will also link /tmp to /var/tmp if the root partition
becomes too small (or starts out too small). There are more examples of
"good" uses of symbolic links, but the entire issue boils down to two
things: packages should be able to find things where they expect them
(within reason) and symbolic links can be used to solve the problem in
many cases. However, problems also can arise from using too many
symbolic links. These problems include overreliance on symbolic links
to solve problems, confusion resulting from overuse of symbolic links,
and the athethic preferences of different people.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Statically linked binaries
Linux is currently running on a wide variety of systems, some single
user with small disks, some as servers in large networked environments.
Because of this variety, this standard sets no rule regarding what
binaries are static or dynamic with the following two exceptions. Both
'ln' and 'sync' should have static versions in /sbin in addition to
dynamic versions in /bin since everyday users may wish to run these too.
Large Linux systems may wish to include other statically linked binaries
(sh, init, mkfs, fsck, tunefs, mount, umount, swapon, swapoff, getty,
login, etc.). The developers and/or system administrators are free to
statically/dynamically link these and other binaries as they see fit, as
long as the location of the binaries doesn't change.
Networked systems (especially those of the future which may lack floppy
drives), may want to make ifconfig, route, hostname, and ftp (meaning an
additional static copy in /sbin) static as well.
------------------------------------------------------------------------
ACKNOWLEDGEMENTS
Credit for this text should be given to the FSSTND activists,
developers, users, and system administrators whose input was
essential to this standard. I also wish to thank each of the
contributors who helped me to write, compile, and compose this,
a consensus standard.
------------------------------------------------------------------------
Contributors:
[in alphabetical order]
Drew Eckhardt <drew@kinglear.cs.colorado.edu>
Ian Jackson <ijackson@nyx.cs.du.edu>
Ian McCloghrie <ian@ucsd.edu>
Daniel Quinlan <quinlan@bucknell.edu>
Mike Sangrey <mike@sojurn.lns.pa.us>
David H. Silber <dhs@glowworm.firefly.com>
Theodore Ts'o <tytso@athena.mit.edu>
Stephen Tweedie <sct@dcs.ed.ac.uk>

943
ftp-archives/tsx-11.mit.edu/1996-10-07/docs/linux-standards/private/fsstnd/pre-release/draft-93.10.17 Normal file
View File

@@ -0,0 +1,943 @@
Filesystem Standard Group Daniel Quinlan
draft submitted: 93/10/17 quinlan@bucknell.edu
Advance Draft on Linux Filesystem Structure
Status of this draft
This draft is being distributed to the members of the Linux community
in order to solicit their reactions to the array of ideas, concepts,
and proposals included within it. While the entire content of the
draft may not meet everyone's individual approval, they may be a good
beginning to solving many problems.
This draft is the product of the Filesystem Standard (FSSTND) unit
of the linux-activists@Niksula.hut.fi mailing list. This draft is a
working document of the Filesystem Standard channel, the author, and
all other groups collaborating to help create this draft. The
distribution of this draft is limited at this time to those directly
involved in its development.
------------------------------------------------------------------------
ABSTRACT
This document is an extensive undertaking to correct outstanding
problems with the de-facto filesystem standard in use by developers,
programmers, administrators, and users. Our purpose and goal is to
produce a draft of exceptional quality that developers and others
will voluntarily adopt to solve well acknowledged problems.
The FSSTND group hopes that this draft will be eventually adopted as
a better standard than the de-facto standard produced by the current
disarray of ideas.
We felt that it was desirable to first call attention to some of the
fundamental problems with the current filesystem situation:
(1) There is no single well-accepted Linux directory structure.
Instead, there are many different ones, each being incompatible
with each other, this is a problem that justifies our effort.
(2) In the most widely used filesystem hierarchies, the directories
are not well structured and differ gratuitously from more modern
standards.
(3) The current layout is confusing for new users and equally
unsettling in nature for well-experienced Unix users.
(4) The incompatibilities between primary installation packages and
other software packages are typically solved by methods of a less
than appealing nature.
(5) Overall, symbolic links are used too often within the filesystem
to fix problems. However, there are times when symbolic links
need to be used to ensure backward compatibility or to allow
specific systems to have an individual filesystem structure.
The FSSTND group seeks to correct these problems by proposing a good
filesystem structure that the Linux community may voluntarily follow.
While developing this draft, approval and input was received from a
number of Linux developers, noted Linux programmers, many system
administrators, and both experienced and novice users. For this
reason, I feel that following our recommendations is a good thing.
If you feel that there is a problem with this effort or the substance
of the draft, please first contact the draft coordinator, Daniel
Quinlan <quinlan@bucknell.edu>, with your comments.
------------------------------------------------------------------------
SPECIFIC PROBLEMS
Naturally, while defining a Linux filesystem structure, there were
some specific problems that we sought to correct. Here are some of
the major and well-accepted ones:
o Linux is not well prepared for a network installation including
the possibility of a read-only /usr partition and diskless (or
small local disk) workstations.
o The primary binary directories, /bin and /usr/bin, do not have
well defined divisions between them. The binaries that are in
each path greatly differ between the various Linux installation
packages.
o Problems concerning /etc
- Many configuration files that aren't essential appear in /etc.
- Non-essential binaries, such as networking binaries, are often
dumped into /etc and symbolic links applied to fix any
compatibility problems
- Including both binaries and configuration files in /etc makes
it more confusing and harder to maintain for inexperienced
users or system administrators with especially large systems.
o The current implementation of /usr cannot be mounted read-only
because it contains variable files and directories that need to
be written to.
o In a networked environment, certain filesystems contain
information specific to a single machine. Therefore these
filesystems cannot be shared (with NFS).
While these are some of the major problems we addressed, there were
numerous additional problems that needed to be solved. This draft
attempts to address many of those other problems, but there may be
something we missed. If you wish to bring something to our
attention, please note there are some things we have discussed at
length, but did not include in this draft (for good reasons).
------------------------------------------------------------------------
OBJECTIVES
In trying to solve the above problems, we saw several objectives that
needed to be accomplished in addition to the more technical matters.
These goals comprise the correction of outstanding problems as well
as the validation of our discussion and work.
o Solve the above problems while also limiting the possible
transition difficulties resulting from moving away from the former
de-facto standards.
o Gain approval of distributors, developers, and other important
people in the Linux movement, as well as their suggestions.
o Provide a standard that all of the Linux community would choose
to follow because it will solve the above problems as well
as provide the most sensible structure for Linux's filesystem.
o While conformance to this or any other standard in Linux is
obviously completely voluntary, we wish to impress upon
developers that this organization is a very sensible way to
lay out a Linux filesystem. If you, as a developer, wish
to suggest any improvements, we are willing to listen.
========================================================================
THE FILESYSTEM STRUCTURE
This is the root directory structure. In general, enough should be
contained in root partition to boot, restore, recover, and/or repair the
system.
Our primary concern was to keep root as small as reasonably possible in
terms of number of directories, files, and disk space. You might ask,
"Why is this desirable?"
o The root is often mounted from very small media. For example, most
people using Linux install and do recovery by mounting root off of a
RAM disk which is copied from a single 1.44M or 1.2M floppy disk.
o Root has many system-specific configuration files in it, a kernel
that is specific to the system, a different hostname, etc. This
means that root isn't usually shareable between networked systems.
Keeping root small on networked systems minimizes the amount of
space lost on servers to non-shareable files. It also allows
workstations with smaller local hard drives.
o While you may have a large root partition, and may be able to fill
it to your heart's content, there will be people with smaller
partitions. If you have more files installed, you may find
incompatibilities with other systems using limited root partitions.
If you are a developer then you may be sharing this problem with a
large number of users.
No single package should have its own specific root directory. This
structure provides more than enough flexibility for any package. Any
package which does occupy a directory under root suffers from sheer
arrogance.
/ : the root directory
|
|- bin : essential command binaries
|- boot : static files of the boot loader
|- dev : device files
|- etc : essential system configuration
|- home : user home directories
|- lib : shared libraries ("libc.so.*" and "libm.so.*")
|- lost+found : files and directories found by 'fsck'
|- mnt : mount point of temporary partitions
|- proc : process information pseudo-filesystem
|- root : home directory for root
|- sbin : essential system binaries
|- tmp : temporary files
|- usr : second major permanent mount point
|- var : files that vary with time or by machine (non-configuration)
\- {kernel image}
Following this section, each directory is explained in full.
The root directory normally contains the current kernel image. The
kernel image name is locally configurable, but the name we suggest (that
has been used in recent Linux kernel sources) is "vmlinux".
------------------------------------------------------------------------
/bin : essential binaries only (for use by all users)
There should be no subdirectories within /bin.
The /bin directory should not contain binaries that are only for use by
root. All root-only binaries such as standard daemons, init, getty,
mkfs, et al (previously found in /etc), shall now be placed in /sbin or
/usr/sbin depending on the necessity of the command. For discussion and
our definition of essential (necessity and related concepts) please read
the issues and rationale section towards the end of this draft.
Command binaries that are not essential enough to place into /bin should
be placed into /usr/bin, instead.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
REQUIRED files for /bin:
general commands:
The following commands have been added because of their
essential nature in the system. A few have been added
because of their traditional placement in /bin.
{ cat, chgrp, chmod, chown, cmp, compress, cp, date, dd, df, du,
ed, false, free, grep, hostname, kill, killall, ln, login, ls,
mkdir, mknod, mv, od, ps, pwd, rm, rmdir, sh, stty, su, sync,
test, touch, true, uncompress, uptime, w, zcat }
/* possible removal: od */
networking:
These are deemed the only necessary networking binaries that
both root and users will want or need to execute other than
the ones in /usr/bin or /usr/local/bin.
{ ftp, netstat, ping, telnet }
/* possible removal: ftp, telnet */
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
RECOMMENDED files for /bin:
These files should appear in /bin if space is not at a premium
{ "an interactive shell" (preferably csh), "a pager" (more or less),
passwd, wall, write }
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
OPTIONAL files for /bin:
These may appear in /bin at the discretion of system
administrators, but are in no way required and are be better
placed in /usr/bin.
{ awk, basename, dirname, expr, head, pstree, tload, top, sed, "other
login shells deemed necessary (bash, tcsh, zsh, et cetera)" }
/* possible removal: awk, sed
musing: tail
possible move up: basename, dirname, expr (often used in sh scripts) */
------------------------------------------------------------------------
/boot : static files of the boot loader
This directory contains everything for boot except configuration files
and the map installer. This includes saved master boot sectors, sector
map files, and anything else that is not directly edited by hand. The
boot loader program should be placed into /sbin and configuration files
for boot loaders into /etc.
For LILO:
Old location New location
------------------------ -----------------
/etc/lilo/config.defines /etc/lilo.defines
/etc/lilo/config /etc/lilo.conf
/etc/lilo/disktab /etc/disktab
/etc/lilo/lilo /sbin/lilo
/etc/lilo/boot.NNNN /boot/boot.NNNN
/etc/lilo/part.NNNN /boot/part.NNNN
/etc/lilo/map /boot/map
/etc/lilo/*.b /boot/*.b
*.b are the first and second stage boot loader, plus all those chain
loaders. QuickInst (if used at all) should be placed into /usr/sbin and
the activate command is left out of this scheme because its future is
uncertain at this time.
Extra kernel images should be stored in /boot. The main kernel can
either be placed in / or in /boot according to personal preference. If
placed in /, the kernel may possibly be a symlink to a kernel image in
/boot.
------------------------------------------------------------------------
/dev : Device files
There are no subdirectories within /dev.
/dev usually also contains a file, MAKEDEV, a shell script designed to
create devices as needed. It also often contains a MAKEDEV.local for
any local-only devices.
Symbolic links within /dev "to make it easier to understand" are
dangerous and not a good idea. The largest problem with symlinks in /dev
is that they are often not updated when other devices are. If you feel
you absolutely must create links in /dev then use hard links, and not
symbolic ones.
A good standard already exists for Linux devices. We believe that the
current standard should by followed in all cases. The device list is
maintained by Rick Miller <rick@ee.uwm.edu>, the Linux Device Registrar.
/* where is the device standard stored? */
------------------------------------------------------------------------
/etc : Essential system configuration files
No binaries or subdirectories should go directly into /etc. Commands
which would have in the past been found in /etc should now be placed in
/sbin. This includes such commands as init, getty, and update.
Binaries such as hostname which are used by users as well as root should
not be placed in /sbin, but in /bin.
REQUIRED files for /etc:
{ adjtime, fdprm, fstab, group, initttab, issue, magic, motd, mtab,
mtools, passwd, printcap, profile, protocols, rc*, securetty,
services, shells, termcap, utmp }
networking REQUIRED files (if networking is installed):
{ ftpusers, host, host.conf, hosts.equiv, networks }
There may be more configuration files than just these, but some that are
not essential should be placed in /usr/etc rather than /etc.
------------------------------------------------------------------------
/home : User home directories
/home is a fairly standard concept, but it is clearly a site-specific
filesystem. The setup will differ from machine to machine.
On small systems, each user's directory is typically one of the many
subdirectories of /home ("/home/jane", "/home/bill", "/home/xavier", et
cetera).
On large systems (especially when the /home directories are mounted
across a number of machines using NFS) it is a good idea to subdivide
user home directories. Subdivision can be accomplished by using
subdirectories such as /home/staff, /home/guests, /home/students, et
cetera.
Different people prefer to place user accounts in a variety of places
and because of this reason, no programming should rely on this location.
If you want to find out a user's home directory, you should use the
field in /etc/passwd or another reliable method (I know of no other
reliable methods).
------------------------------------------------------------------------
/lib : Shared libraries (needed to run dynamically linked binaries)
Only the shared library images necessary to boot the system should be
placed in /lib. The shared library images are "/lib/libc.so.*" and
"/lib/libm.so.*" and not the actual ".a" files.
XFree86 libraries do not belong in /lib. Essentially, only the dynamic
shared libraries needed to run programs in /bin and /sbin should be
here.
A single symbolic link for gcc currently exists in /lib pointing
"/lib/cpp -> /usr/lib/gcc-lib/i-?86-linux/2.4.?/cpp". No binaries
should be added to /lib in addition to cpp.
------------------------------------------------------------------------
/mnt : Mount point for temporarily mounted filesystems
This is the location where the system administrator may temporarily
mount filesystems as needed. The setup of this directory is a local
issue and should not affect the way any program is run.
------------------------------------------------------------------------
/proc : Proc based process system
The procps filesystem is becoming the standard Linux method for handling
process information rather than /dev/kmem and other nasty methods. This
is only recommended, but should in time become the standard for the
storage and retrieval of process information as well as other kernel and
memory information.
------------------------------------------------------------------------
/sbin : System binaries (binaries once kept in /etc)
Utilities used for system administration (and other root-only commands)
are stored in /sbin, /usr/sbin, and /usr/local/sbin. /sbin typically
contains files essential for the booting phase of starting the system
up. Any non-essential commands should be placed into /usr/sbin.
Local-only system administration stuff should now be placed into
/usr/local/sbin.
The concept of what goes into "sbin" directories is simple. If a user
will need to run it, then it should go somewhere else. If it will only
be run by root (i.e. system administration commands, networking daemons,
system startup), then it should go in /sbin (or in /usr/sbin if the item
is not essential). Files such as 'chfn' and 'ac' which users only
occasionally use should still be placed in /usr/bin. 'ping', although
it is absolutely necessary for root (network recovery and diagnosis) is
often used by users and should live in /bin for that reason.
Let me state it one more time, if there is any chance at all that a user
should need to run it, do not put it here! Users should never have to
place /sbin (or any of the 'sbin' directories) in their path. It is
true that they should probably not even be able to execute anything
dangerous in /sbin if you (and programmers) have done the job right. It
is reasonable to want to let them see what files are in /sbin.
Therefore, don't make the directory totally unreadable unless you must.
/sbin was not created to protect users or to prevent them from seeing
the OS, but to provide a good division between binaries everyone uses
and commands that *only* administrators use (99.9% of the time).
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
REQUIRED files for /sbin:
general:
{ getty, init, update, mkswap, swapon, swapoff }
shutdown commands:
{ halt, reboot, shutdown }
filesystem commands:
{ fsck, fsck.*, tunefs, mkfs, mkfs.*, mount, umount }
networking:
{ ifconfig, route }
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
/sbin is traditionally known for statically linked files although as you
can see we have not even mentioned linking anything statically yet.
This is because we feel that the need for statically linked files is not
great except in several cases:
RECOMMENDED to be linked statically: ln, sync
Yes, neither 'ln' or 'sync' are normally placed in /sbin. If the
version of 'ln' and 'sync' that you possess are not a reduced (in
functionality or interface) version of the normal commands then they
should just replace the ones in /bin. If either is a reduced version
that only offers minimal features then it should be kept separately in
/sbin so that users do not have to use a reduced functionality
command.
========================================================================
/usr : Second major mount point (permanent)
|
|- X11 : The X windows directory version 11
|- bin : Most user commands
|- dict : Spelling dictionaries
|- doc : Miscellaneous documentation
|- etc : Other configuration files (for programs in /usr/bin)
|- g++-include : GNU C++ include files
|- games : Games and educational binaries
|- include : Header files included by C programs
|- info : The GNU info documentation system's primary directory
|- lib : Libraries
|- local : Local directory (empty after main installation)
|- man : Online manuals
|- sbin : Non-essential system administration binaries
\- src : Source code
X11 is possibly a symlink to /usr/X386 or something else.
The following list of directory symbolic links need to be added. This
only needs to be done until compatibility with the /var scheme can be
assumed to exist.
/usr/adm -> /var/adm
/usr/preserve -> /var/preserve
/usr/spool -> /var/spool
/usr/tmp -> /var/tmp
Most of the above symlinks should in time become unneeded as packages
are changed to support /var in addition to /usr.
The GNU Emacs lock file directory, if Emacs is installed, should be a
symlink pointing to /var/lock/emacs if you want to be able to mount /usr
read-only. It is usually found in /usr/emacs, /usr/lib/emacs, or
/usr/local/lib/emacs.
------------------------------------------------------------------------
/usr/X11 : X386 X11 installation directory
|- bin
|- doc
|- include
|- lib
\- man
This hierarchy is reserved for the use of XFree86 X11 releases.
In order to simplify matters and make X386 more compatible with other
X11 packages from XFree86, our recommendation is to place a symbolic
link, /usr/X11 pointing to /usr/X386 (or whatever directory your X11
package was compiled to utilize).
------------------------------------------------------------------------
/usr/etc : Non-essential system configuration files
All non-essential system configuration should be placed in here.
Basically, files placed in here will be configuration for files in
/usr/bin or /usr/sbin.
------------------------------------------------------------------------
/usr/lib : Libraries for programming and packages
|- emacs : Support files for the GNU Emacs editor
|- groff : Libaries/directories for the GNU groff system
|- gcc-lib : System specific files/directories for GNU C compiler
|- terminfo : Directories for terminfo database
|- uucp : Commands for uucp
\- zoneinfo : Timezone information and configuration
The word, library, includes static data files and some internal
binaries as well.
------------------------------------------------------------------------
/usr/local : Local directory
|- bin : Local only binaries
|- etc : Configuration for local only binaries
|- games : Locally installed games
|- lib : Libraries for /usr/local
|- info : Local info pages
|- man : Man page hierarchy for /usr/local
|- sbin : Local only system administration
\- src : Local source code
This should be 100% empty after installing Linux, no exceptions other
than the listed _empty_ directory stubs.
Let me spell it out for the concept impaired, "E M P T Y".
It should also be untouched during system upgrades.
Locally installed software should be placed within /usr/local rather
than /usr *unless* it is being installed to replace or upgrade software
in /usr *or* it is felt that the installed software is "important
enough" to place in /usr or in /.
------------------------------------------------------------------------
/usr/man : Manual page hierarchy
|- man1 : User programs
|- man2 : System calls
|- man3 : Library functions and subroutines
|- man4 : Devices
|- man5 : File formats
|- man6 : Games
|- man7 : Miscellaneous
|- man8 : System Administration
\- man9 : Kernel internal variables and functions
The cat page sections (cat[1-9]) containing formatted manual page
entries are also found within subdirectories of /usr/man, but are not
required nor should they be distributed in lieu of nroff source manual
pages.
Local manual pages should be stored in /usr/local/man which contains a
similar directory structure (man[1-8], empty subdirectories can be
omitted).
X Windows manual pages should be stored in /usr/X11/man in an
identical directory structure (man[1-8], empty subdirectories can be
omitted).
As Linux (and Unix) is further utilized in foreign countries and manual
pages are translated to non-English versions, there is the impending
problem that these manual pages will have to be stored somewhere else.
Some German releases of Linux have already created a manual page system
that is placed in /usr/man with the suffix "g". This is a poor solution
and will cause further problems in the long run as other langauges
appear, especially other langauges starting with the same letter
(Gaelic, Greek, whatever).
Therefore, all non-English manual pages sections should be stored in
subdirectories within /usr/man named according to the language that the
the contained manual pages are written in (lowercase characters), hence,
for the German manual pages:
/usr/man/german/man[1-9] and possibly /usr/man/german/cat[1-9]
Then, German-speaking Linux users can add /usr/man/german to their
MANPATH before /usr/man so that /usr/man/german manual pages are
referenced first. If a German manual page is not found for a given
command then the English version may be referenced. This setup will be
needed as the number of foreign (non-English) manual pages increases.
German is the language mentioned here since it is the only non-English
manual page system distributed with any Linux system at this time.
Other languages will probably follow and they should follow this scheme
as well.
The practice of placing non-English in subdirectories of /usr/man should
be followed as well for other manual page hierarchies, such as
/usr/local/man and /usr/X11/man.
Using the language itself (/usr/man/deutsch) rather than the English
(/usr/man/german) was strongly considered, but this was met with
disapproval from many people, including those who do not speak English
as a first language. Reasons: simplicity, the difficulty in displaying
many languages' names in 7 bit characters, and the fact that everyone
can hopefully recognize what their language is in English.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A description of each section follows:
man1: User programs
Manual pages that describe publicly accessible commands are contained
in this chapter. Most program documentation that a user will need to
use is located here.
man2: System calls
This section describes all of the system calls which are entries to
the Linux kernel (operating system). This section can be very useful
to programmers, but users have little need of the items in section 2.
man3: Library functions and subroutines
Section 3 describes user-level library routines. This is another
chapter that is only really of interest to programmers.
man4: Special files
Section 4 describes the special files, related driver functions, and
networking support available in the system. Typically, the device
files found in /dev.
man5: File formats
The formats for many nonintuitive data files are documented in the
section 5. This includes various include files, program output files,
and system files
man6: Games
This chapter documents games, demos, and generally trivial programs.
Different people have various notions about how essential this is.
man7: Miscellaneous
Manual pages that are difficult to classify are designated as being
section 7. The *roff and other text processing macro packages are
found here.
man8: System administration
Documentation for programs used by system administrators for system
operation and maintenance are documented here. Some of these programs
are also occasionally useful for normal users.
man9: Kernel internal variables and functions
This appears on Linux systems to document the kernel source code.
------------------------------------------------------------------------
/usr/sbin : Non-essential standard system binaries
Any non-essential system administration binaries, non-essential
networking daemons (most other than those mentioned to be in /sbin),
large system administration tools, interface programs, or anything
used only by the sysadmin that isn't essential.
Local system binaries and local administration shell scripts belong in
/usr/local/sbin.
------------------------------------------------------------------------
/usr/src : Source code
|
\- linux : Source code for Linus' kernel
Any non-local source code should be placed in this subdirectory, the
only thing in /usr/src that should always be placed in a certain
location is the kernel source (when present or linked in part to the
/usr/include structure). [ Author's note: Also, if you have any taste,
you'll learn to use subdirectories. ]
The source code for the kernel should always be in place or at least the
include files from the kernel source. Those files are located in these
directories:
/usr/src/linux/include/asm
/usr/src/linux/include/linux
/usr/include usually contains links to 'asm' and 'linux' in the source
directory, therefore, at least those include files should always be
distributed with installations. They should also be distributed in the
/usr/src/linux directory so there are no problems when system
administrators upgrade their kernel version for the first time.
------------------------------------------------------------------------
/var : Directories of files that vary on different systems and machines
|- adm : System logging and accounting files
|- domain : DNS files (for named), networking only
|- lock : Lock files
|- preserve : Used to save text edited by 'vi' after crash or hangup
|- spool : Directories for queuing work to be performed later
\- tmp : Second temporary directory
This directory contains the directories of all files that vary with time
and is usually a local directory. These include logging files,
accounting files, backup files for editors and other programs, and spool
directories.
The reason for a /var is to make it possible to mount /usr read-only.
Everything that once went into /usr that is written to on a temporary
basis, now goes into /var. The aforementioned symbolic links, also
mentioned below in the issues and rationale section, should be added to
/usr for compatibility. This is very helpful if you are mounting /usr
through NFS or if you want a read-only /usr.
------------------------------------------------------------------------
/var/domain : DNS and named stuff
|- forward
\- reverse
This is only needed for systems using DNS (networking protocol for
name servers).
/* I am hoping to add a *much* more extensive explanation after some
contact is made with Linux networking developers. There is a very
excellent proposal from Drew Eckhardt (that has precedence as well)
that will eventually be discussed. */
------------------------------------------------------------------------
/var/lock : Lock files
|- device : Device locks
\- emacs : Emacs lock files
Lock files should be stored with a subdirectory of /var/lock appropriate
subdirectory such as the emacs lock file directory. This directory
*does not* replace older locations for lock files other than
/usr/spool/uucp and the serial lock files that were contained within it.
However, if you are the maintainer of a program that uses lock files and
you wish to add a subdirectory for lock files within /var/lock, then it
is a good idea to contact the FSSTND channel or myself to discuss
placement of a directory for your lock files.
If you are interested in being able to mount /usr read-only then you may
wish to recompile whatever package it is that uses /usr for lock files
and place them in here, again - contact me if you want to add stuff on a
permanent basis (i.e. you are a developer or a programmer of a Linux
package).
The Emacs editor's lock files should be saved in /var/lock/emacs. It is
necessary to recompile Emacs to do this or to place an appropriate
symlink where the Emacs lock file directory lies.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
/var/lock/device: Device lock files
All lock files for devices should now be placed in /var/lock/device
rather than /usr/spool/uucp or whereever they were stored in the past.
------------------------------------------------------------------------
/var/spool : Spooling directories (queue work, work to be done later)
|- at : at jobs
|- cron : Cron jobs
|- lpd : Printer spool directory
|- mail : Directory for user mailboxes
|- mqueue : Outgoing mail queue
\- uucp : Spool directory for uucp
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
/var/spool/lpd : Printer spool direcotry
|- {printer name} : Spools for a specific printer
\- {printer name}.LOCK : Lock file for a specific printer
------------------------------------------------------------------------
Issues and Addtional Rationale
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
What is Essential?
The answer is: essential to clean, create, prepare, check, find and
mount other filesystems (possibly on remote machines). There are other
definitions, but this is a general definition that most people will at
least incorporate into their own.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Networking
Networking presented an interesting dilemma. Many people like to place
networking binaries and configuration separate from other binaries and
configuration. However, we disagree. We feel that networking is not a
"package", but an integral part of most Unix machines. Because of this
networking should not be placed into a single directory, but
systematically placed in the appropriate directories.
/bin : anything a user will want to use that is also
considered essential (ftp, netstat, telnet, ping)
/sbin : anything only root needs and is considered
essential (ifconfig, route)
/usr/bin : any binaries a user will want to use, but are not
essential (finger, rcp, rlogin, et al.)
/usr/sbin : any root only networking binaries that are not
essential (networking daemons, lpd, et al.)
While this may seem confusing at first (and it does take a moment to
digest), it does make sense. If you can only mount root for some reason
and you need access to networking to repair your system, you don't need
the files to be off in /usr/etc (as they often are). Files that are
needed to mount /usr in normal (and emergency situations) are placed on
the root subtree and any others are placed in /usr in order to keep the
size of root small.
Configuration files for networking similarly go into /etc and /usr/etc.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Architecture-independent Structures
Many people note that in this draft, there is no /usr/share. The
structure, /usr/share, typically contains architecture-independent files
such as man-pages, timezone, terminfo information, et al. As of this
time, there are no different architectures for Linux, but with the
passage of time we should see Linux include other architectures.
The reason that we do not include /usr/share in this standard is that
/usr/share is very difficult to set up *without* another architecture to
examine when defining the structure. Keep in mind that things commonly
specified, like "/usr/share/man" are obvious . . . and wrong. After
all, some manual pages (like the man pages for the devices:
/usr/man/man4) will be architecture specific. In addition, there may be
other files which may actually turn out to be architecture specific
simply because the DBM formats are not compatible.
Thus, we are going to wait on /usr/share for now. If we need /usr/share
in the future, it is simple enough to put in symlinks from the current
existing structure into /usr/share. So the primary directory names
which programs should reference should be /usr/man, and then if
appropriate certain directories in /usr/man can be symlinked to
/usr/share/man. This avoid "gotcha's" like /usr/man/man4 that people
will probably forget about if we try to design /usr/share without
actually mapping out a NFS supported /usr that supports multiple
architectures.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Symbolic Links
There are a wide range of uses for symbolic links (symlinks) in every
filesystem. While symlinks are not encouraged for default setup (found
after installing Linux) in a standard such as this, they are often used
with good purpose on different systems. The point is that symlinks
should be there to keep everything where everyone else expects find it
Be prepared to accept that certain directories, even those contained on
the root directory, are still going to be symlinks. For instance, on
some systems /home will not be on the root, but symlinked to a /var
directory, or to somewhere else. /home could also have its own physical
partition, of course, and be mounted on its own.
Similarly, because /usr might be on a central fileserver mounted via
NFS, /usr/local could be symlinked to /var/local. Like /usr/emacs/lock,
this change can be justified by recalling one definition of /var:
"directories of files that vary on different systems and machines".
Sometimes systems will also link /tmp to /var/tmp if the root partition
becomes too small (or starts out too small). There are more examples of
"good" uses of symbolic links, but the entire issue boils down to two
things: packages should be able to find things where they expect them
(within reason) and symbolic links can be used to solve the problem in
many cases. However, problems also can arise from using too many
symbolic links. These problems include overreliance on symbolic links
to solve problems, confusion resulting from overuse of symbolic links,
and the athethic preferences of different people.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Statically linked binaries
Linux is currently running on a wide variety of systems, some single
user with small disks, some as servers in large networked environments.
Because of this variety, this standard sets no rule regarding what
binaries are static or dynamic with the following two exceptions. Both
'ln' and 'sync' should have static versions in /sbin in addition to
dynamic versions in /bin since everyday users may wish to run these too.
Large Linux systems may wish to include other statically linked binaries
(sh, init, mkfs, fsck, tunefs, mount, umount, swapon, swapoff, getty,
login, etc.). The developers and/or system administrators are free to
statically/dynamically link these and other binaries as they see fit, as
long as the location of the binaries doesn't change.
Networked systems (especially those of the future which may lack floppy
drives), may want to make ifconfig, route, hostname, and ftp (meaning an
additional static copy in /sbin) static as well.
------------------------------------------------------------------------
ACKNOWLEDGEMENTS
Credit for this text should be given to the FSSTND activists,
developers, users, and system administrators whose input was
essential to this standard. I also wish to thank each of the
contributors who helped me to write, compile, and compose this,
a consensus standard.
------------------------------------------------------------------------
Contributors:
[in alphabetical order]
Drew Eckhardt <drew@kinglear.cs.colorado.edu>
Ian Jackson <ijackson@nyx.cs.du.edu>
Ian McCloghrie <ian@ucsd.edu>
Daniel Quinlan <quinlan@bucknell.edu>
Mike Sangrey <mike@sojurn.lns.pa.us>
David H. Silber <dhs@glowworm.firefly.com>
Theodore Ts'o <tytso@athena.mit.edu>
Stephen Tweedie <sct@dcs.ed.ac.uk>

1099
ftp-archives/tsx-11.mit.edu/1996-10-07/docs/linux-standards/private/fsstnd/pre-release/draft-93.11.14 Normal file
View File

File diff suppressed because it is too large Load Diff

1124
ftp-archives/tsx-11.mit.edu/1996-10-07/docs/linux-standards/private/fsstnd/pre-release/draft-93.11.16 Normal file
View File

File diff suppressed because it is too large Load Diff

1149
ftp-archives/tsx-11.mit.edu/1996-10-07/docs/linux-standards/private/fsstnd/pre-release/draft-93.11.17 Normal file
View File

File diff suppressed because it is too large Load Diff

1171
ftp-archives/tsx-11.mit.edu/1996-10-07/docs/linux-standards/private/fsstnd/pre-release/draft-93.11.22 Normal file
View File

File diff suppressed because it is too large Load Diff

1252
ftp-archives/tsx-11.mit.edu/1996-10-07/docs/linux-standards/private/fsstnd/pre-release/draft-93.12.07 Normal file
View File

File diff suppressed because it is too large Load Diff

1270
ftp-archives/tsx-11.mit.edu/1996-10-07/docs/linux-standards/private/fsstnd/pre-release/draft-93.12.08 Normal file
View File

File diff suppressed because it is too large Load Diff

1832
ftp-archives/tsx-11.mit.edu/1996-10-07/docs/linux-standards/private/fsstnd/pre-release/draft-94.01.14 Normal file
View File

File diff suppressed because it is too large Load Diff

1832
ftp-archives/tsx-11.mit.edu/1996-10-07/docs/linux-standards/private/fsstnd/pre-release/draft-94.01.15 Normal file
View File

File diff suppressed because it is too large Load Diff

2127
ftp-archives/tsx-11.mit.edu/1996-10-07/docs/linux-standards/private/fsstnd/pre-release/draft-94.02.05 Normal file
View File

File diff suppressed because it is too large Load Diff

2186
ftp-archives/tsx-11.mit.edu/1996-10-07/docs/linux-standards/private/fsstnd/pre-release/draft-94.02.06 Normal file
View File

File diff suppressed because it is too large Load Diff

2186
ftp-archives/tsx-11.mit.edu/1996-10-07/docs/linux-standards/private/fsstnd/pre-release/draft-94.02.07 Normal file
View File

File diff suppressed because it is too large Load Diff

2245
ftp-archives/tsx-11.mit.edu/1996-10-07/docs/linux-standards/private/fsstnd/pre-release/draft-94.02.08 Normal file
View File

File diff suppressed because it is too large Load Diff

2245
ftp-archives/tsx-11.mit.edu/1996-10-07/docs/linux-standards/private/fsstnd/pre-release/draft-94.02.10 Normal file
View File

File diff suppressed because it is too large Load Diff

2304
ftp-archives/tsx-11.mit.edu/1996-10-07/docs/linux-standards/private/fsstnd/pre-release/draft-94.02.13 Normal file
View File

File diff suppressed because it is too large Load Diff

2304
ftp-archives/tsx-11.mit.edu/1996-10-07/docs/linux-standards/private/fsstnd/release/fsstnd-1.0.txt Normal file
View File

File diff suppressed because it is too large Load Diff

BIN
ftp-archives/tsx-11.mit.edu/1996-10-07/docs/linux-standards/rfc-template.tar.gz Normal file
View File

Binary file not shown.

BIN
ftp-archives/tsx-11.mit.edu/1996-10-07/docs/linuxdoc-sgml-1.0.tar.gz Normal file
View File

Binary file not shown.

56
ftp-archives/tsx-11.mit.edu/1996-10-07/docs/linuxdoc-sgml-1.1.FIXES Normal file
View File

@@ -0,0 +1,56 @@
Here is a list of fixes for common problems with Linuxdoc-SGML v1.1.
Newsgroups: comp.os.linux.announce,comp.infosystems.www.providers,comp.text.sgml
Path: cornell!mdw
From: mdw@cs.cornell.edu (Matt Welsh)
Subject: Re: Linuxdoc-SGML v1.1 now available
Message-ID: <1994Jun10.160728.23274@cs.cornell.edu>
Followup-To: comp.os.linux.misc
Keywords: Linuxdoc-SGML text formatting LaTeX HTML ASCII nroff
Organization: Cornell CS Robotics and Vision Laboratory, Ithaca, NY 14850
References: <1994Jun7.194322.21396@cs.cornell.edu>
Date: Fri, 10 Jun 1994 16:07:28 GMT
Approved: linux-announce@tc.cornell.edu (Matt Welsh)
Lines: 37
In article <1994Jun7.194322.21396@cs.cornell.edu> mdw@cs.cornell.edu (Matt Welsh
) writes:
>I have uploaded Linuxdoc-SGML v1.1 to sunsite.unc.edu:/pub/Linux/Incoming.
>It is also available on ftp.cs.cornell.edu:/pub/mdw.
Some folks have had problems compiling Linuxdoc-SGML on Linux systems.
(It's a case of foot-in-mouth disease.)
1. Linux systems generally have GNU flex installed, in which case you need
to edit html-fix/Makefile, and change the two instances of "-ll" to "-lfl".
This applies to other systems where flex is used instead of lex.
2. There is a bug in sgmls-1.1/configure which creeps up if you use bash
or zsh. Change the line:
if test "X$(PREFIX)" != "X/usr/local"
to
if test "X${PREFIX}" != "X/usr/local"
3. You may need to comment out the last three lines in sgmls-1.1/msgcat.h:
nl_catd catopen();
int catclose();
char *catgets();
if you get conflicting prototype errors from nl_types.h when building
the sgmls parser.
4. Also, you need getopt (the program, not the library function) installed,
which is used within the various shell scripts in bin/.
This is available for Linux in
sunsite.unc.edu:/pub/Linux/system/Misc/util-linux-1.6.tar.gz
If you have any problems getting the system to work (on Linux or
any other platform) please get in touch with me.
Cheers,
mdw

Some files were not shown because too many files have changed in this diff Show More