Debian: a brief status report
Ian A Murdock
and suggestions. I'm sorry that I didn't have time to respond to them all, but
there was simply no way for me to do so and make progress on the Debian
release at the same time :)
I'm going to keep this brief, but I just wanted everyone to know how things
were going. Sorry I've been so quiet for the last few weeks, but I've been
extremely busy (to say the least). First of all, two requests:
1) I have a generic IDE controller and drive, so if there are kernel
patches for your SCSI board that are not yet a part of the
standard kernel then please let me know. Please tell me the
*exact* name of the package and it's *exact* location. I will
patch the bootdisk kernel with all available SCSI patches
to ensure that as few people as possible have trouble with the
initial install. I don't keep up with SCSI developments so
please help me out. :)
2) Would everyone prefer a distribution in 'package' format (i.e.
base.tgz, bin.tgz, etc.) or 'disk' format (i.e. disk1, disk2,
etc.)? The latter 'disk' format would consist of Linux disk
images that would need to be either rawritten (under DOS)
or dd'ed (under UNIX). I would personally prefer the latter,
but if everyone else likes the 'package' format then I will
use it instead. The 'series' format, ala SLS and Slackware,
will not be used. Please let me know what you would prefer.
I would like to point out here that I would like this distribution to develop
in the same way as much of the rest of Linux has developed. In other words,
I want everyone to *contribute* to this effort and not simply use something
that one man or team has put together. This distribution will be improved
by the Linux community as a whole, and I will simply serve as the
coordinator of the effort.
For this reason, the first release of the Debian distribution will only be a
TESTING release. It will be available to everyone who wants it (the exact
location will be disclosed when an official announcement is made on c.o.l.a.),
but I strongly recommend that anyone who does not want to be involved in its
initial development wait until Debian has left the TESTING phase. Please
remember that I started this release from scratch and that thus far only a
few others have seen it. I want to get some input and make some changes
before I deem the distribution suitable for the 'end-user'.
Anyway, that's all for now. Keep an eye out for an official announcement on
c.o.l.a. at the beginning of next week. Please drop me a line if you're
interested in 'joining the team'.
See you on c.o.l.a.,
Ian
--
Ian Murdock Internet: imur...@shell.portal.com
The Linux Warehouse
Chris Cannon
Leon Dent
let people decide whatever else they want. One day there may be a standard
way to upload binaries such that any uploaded binary may be installed
as a package.
(What is the derivation of the name Debian?)
Leon Dent
l...@umcc.umich.edu
John Paul Morrison
Leon Dent <l...@umcc.umcc.umich.edu> wrote:
>I'd prefer a package layout. This would allow a smaller base install and
>let people decide whatever else they want. One day there may be a standard
>way to upload binaries such that any uploaded binary may be installed
>as a package.
I'm interested in having some public discussion(or mailing list) about
the layout, the versions, etc. The outcome of the discussions would
be a "recommended" layout for Linux, so we don't have every package
making company/person coming up with their own esoteric and incompatible
system for naming things, organizing directories etc.
The newbies just want to get a system up and running, but many people
have previous experience and preferences about things should be done.
Ie, some people want Linux to be more like SunOS, or BSD or SysV or
whatever. I'm not trying to start a religious war, but I think reasonable
system organization would evolve if it were discussed openly a bit.
People can do what they like with their own machines, but I think some
public persuasion would help package developers create better packages.
I think SLS was a good way to bootstrap Linux, but because Peter
cobbled it together with his own personal preferences and idiosyncrasies,
SLS is cluttered, incompatible and hard to maintain.
SLS suffered from having duplicates, outdated versions, and *unknown*
versions of programs. If we discuss things publicly, and print up
a list of recommendations, then hopefully SLS, Slackware, MCC, Debian
will tag along. Maybe we can take a straw poll on a few programs, and
then try to stick to those; then the recommended list can say:
"it's a good idea to use Sys V init, version x.y.z". or "use getty_ps
version x.y, and put it in /etc". The package makers simply do not
have the experience to create an optimal distribution if they try to
go it alone. A recommend list should tell people: which program to use
(and whether to use it), what version, where to install it, any
important tips for compiling it properly; possible substitutes, ie
if someone is a UUCP only site, or an Internet site or whatever
If I can start things off (man hier I guess):
/dev
has the dust finally settled here?
(not trying to pick at old wounds, but it is a good idea
to get it right)
/bin
what should go here?
should it be shared lib linked files just to get the system
up? keep in mind that some people use (and probably most SHOULD)
a small root partition.
is a /sbin a better idea?
/etc
basic system files...
passwd... can we agree to use shadow passwds too?
(some people are multiuser systems on real, security conscious
networks. shadow passwds make sense, and it isnt a hassle to
the single user, no network system )
net2 seems to be the way to go. net-2 is organized like SysV
shall we use /etc/rd.d/ for rc files? net-2 and SysV init
like this setup.
"traditional" binaries, ie dont cram everything into /usr/bin
just because it is executable
/usr/etc
a seperate directory, not a symlink. probably on another filesystem
I hated the SLS /etc/inet setup
login, write, who: poeigl (possibly getty as well)
init, reboot, shutdown, halt, last, wall: SysV init 2.4
getty, uugetty: gettyps
networking: net-2 (if you are pl10 or higher). setup in /etc and /usr/etc.
patched for shadow passwds where needed.
man: man 1.1, patched for gzip instead of compress; -mandoc
/usr/bin: most Gnu things...binutils, shellutils, text etc...
/usr/ucb: make any sense? (I dont really care for it, but I'd go along
with it)
>
>(What is the derivation of the name Debian?)
instead of Linux/Pro, how about the Linux Standard Distribution (LSD)?
(not a distribution package, just the semi-official, right way to roll
you own distribution).
For the way Linux ought to be organized and maintained; if anyone is stuck
with an old SLS system, they can just read what the collective net experts
more-or-less agree is a good way to do things, and they can compile
the right programs and put them in the right place. I dont think
SLS or Slackware or MCC will every get it right so that upgrading is
painless and trivial. LSD guidelines would let people maintain their
own systems.
Maybe people can post the hier man page for a few popular Unixes, and we
can debate a bit about how to organize things. For particular versions
of a program, people can give their testimonials etc. (any package I've
recommended, is because it worked, it was flexible, and I could find
sources for it. the point isn't to say: my getty can beat up your getty!
what works and what can be managed easily is what matters)>
(I won't change the newsgroups, but maybe this should be followed up
in another newsgroup if appropriate)
>
>Leon Dent
>l...@umcc.umich.edu
>
--
___________________________________________________________________________
John Paul Morrison |
University of British Columbia, Canada | Hey hey!! Ho ho!!
Electrical Engineering | Tax & spend liberals
jmor...@rflab.ee.ubc.ca VE7JPM | have got to go!!
________________________________________|__________________________________
Michael Elkins
John Paul Morrison <jmor...@rflab.ee.ubc.ca> wrote:
>/bin
> what should go here?
> should it be shared lib linked files just to get the system
> up? keep in mind that some people use (and probably most SHOULD)
> a small root partition.
> is a /sbin a better idea?
I personally vote for /sbin and /usr/sbin. But I'd like to see them be
something that is optional. Some people are of the opinion that a rather
large subset of progs should be statically linked, others are not (me being
one; i have no static links on my system)
>/etc
> basic system files...
> passwd... can we agree to use shadow passwds too?
> (some people are multiuser systems on real, security conscious
> networks. shadow passwds make sense, and it isnt a hassle to
> the single user, no network system )
I'd agree, once someone actually claims that everything I want to be running
will work ok (and be secure) under the shadow stuff. Right now there is an
awful lot of stuff in the SLS dist that needs recompiling (dunno about
slackware, but I assume the same for it)
> net2 seems to be the way to go. net-2 is organized like SysV
> shall we use /etc/rd.d/ for rc files? net-2 and SysV init
> like this setup.
yup.
> "traditional" binaries, ie dont cram everything into /usr/bin
> just because it is executable
>
>/usr/etc
> a seperate directory, not a symlink. probably on another filesystem
> I hated the SLS /etc/inet setup
>
>
>login, write, who: poeigl (possibly getty as well)
>init, reboot, shutdown, halt, last, wall: SysV init 2.4
>getty, uugetty: gettyps
>networking: net-2 (if you are pl10 or higher). setup in /etc and /usr/etc.
> patched for shadow passwds where needed.
I agree with this.
>man: man 1.1, patched for gzip instead of compress; -mandoc
>/usr/bin: most Gnu things...binutils, shellutils, text etc...
I'd argue that the shell, bin, and textutils should all be in /bin. Things
like ls are good to have when going single user and you have a separated /usr
filesystem... ;-)
>/usr/ucb: make any sense? (I dont really care for it, but I'd go along
> with it)
I suppose that would be ok, but I don't really think that it's necessary. Of
course, if you did, you'd have problems deciding which progs went in there
(should we put vi in there?, etc)
me
michael elkins elk...@aero.org
computer science and technology subdivision
aerospace corporation tel: +1 310-336-8040
el segundo, ca fax: +1 310-336-4402
OUTTA HERE!
In article <263bc7$m...@news.aero.org> elk...@aerospace.aero.org (Michael Elkins) writes:
>In article <263a6k$2...@iskut.ucs.ubc.ca>,
>John Paul Morrison <jmor...@rflab.ee.ubc.ca> wrote:
>>/bin
>I personally vote for /sbin and /usr/sbin. But I'd like to see them be
>something that is optional. Some people are of the opinion that a rather
>large subset of progs should be statically linked, others are not (me being
>one; i have no static links on my system)
^^^yes, the fewer of them damned links the better!
Why sbin rather than bin? (Personally, I prefer /bin -- most systems I've
used don't have an /sbin... what's the history behind /sbin??)
>>/usr/etc
>> a seperate directory, not a symlink. probably on another filesystem
>> I hated the SLS /etc/inet setup
>>
>>login, write, who: poeigl (possibly getty as well)
>>init, reboot, shutdown, halt, last, wall: SysV init 2.4
>>getty, uugetty: gettyps
>>networking: net-2 (if you are pl10 or higher). setup in /etc and /usr/etc.
>> patched for shadow passwds where needed.
What's the difference between /etc and /usr/etc? Similar to the
concept behind /bin and /usr/bin.
>>/usr/ucb: make any sense? (I dont really care for it, but I'd go along
>> with it)
What's /usr/ucb for?
On some systems I've seen stuff scattered between /usr/bin and /usr/ucb
with no real distinction.
I'm of the thought that we should keep things simple.
Maybe just /etc, /bin, and /usr/bin and maybe axe /usr/etc and /usr/ucb??
I'm fully behind a standard setup for Linux. I'd even like to help!
It drives me crazy to have some programs expect /bin/lpr and others
expect /usr/bin/lpr... so as a consequence I need to either hunt down
the darn source and recompile, or ln -s lpr ../usr/bin/lpr!
-Anthony
Gilbert Nardo
[excerpted]
: I think SLS was a good way to bootstrap Linux, but because Peter
: SLS is cluttered, incompatible and hard to maintain.
I'll try keep my comment simple. Being a pioneer in something
usually entails experimentation. SLS had to have some basis and so it
is understandible that its creator used his prefereneces.
However, if you take the X Window approach, then what would be
optimal is an installation manager, something akin to a window manager.
In this way the user would be able to apply his/her preferences to the
manager, while clients (aka, packages) would supply "hints" for relocating
its files.
--
Gil Nardo | g...@netcom.com
Migrant Computing Services | (415)664-1032 (voice)
1032 Irving Street, #435 |-----------------
San Francisco, 94122 | Save the Universe: Stop Entropy Now!
Ian A Murdock
>No flames, just honest questions:
>
>In article <263bc7$m...@news.aero.org> elk...@aerospace.aero.org (Michael Elkins) writes:
>>In article <263a6k$2...@iskut.ucs.ubc.ca>,
>>John Paul Morrison <jmor...@rflab.ee.ubc.ca> wrote:
>>>/bin
>>I personally vote for /sbin and /usr/sbin. But I'd like to see them be
>>something that is optional. Some people are of the opinion that a rather
>>large subset of progs should be statically linked, others are not (me being
>>one; i have no static links on my system)
> ^^^yes, the fewer of them damned links the better!
>
>Why sbin rather than bin? (Personally, I prefer /bin -- most systems I've
>used don't have an /sbin... what's the history behind /sbin??)
/sbin holds statically linked binaries, traditionally. One or two statically
linked binaries are justifiable (Debian contains a statically linked ln,
as I seem to have gotten into the habit of hosing my links in /lib on a
fairly regular basis :). In my opinion, any more than a few is a waste of
disk space.
>
>>>/usr/etc
>>> a seperate directory, not a symlink. probably on another filesystem
>>> I hated the SLS /etc/inet setup
>>>
>>>login, write, who: poeigl (possibly getty as well)
>>>init, reboot, shutdown, halt, last, wall: SysV init 2.4
>>>getty, uugetty: gettyps
>>>networking: net-2 (if you are pl10 or higher). setup in /etc and /usr/etc.
>>> patched for shadow passwds where needed.
>
>What's the difference between /etc and /usr/etc? Similar to the
>concept behind /bin and /usr/bin.
According to the SAG by Lars Wirzenius, /usr/etc "typically contains only
configuration files for programs in /usr/bin, not system-wide things."
I like /usr/etc because it helps /etc stay uncluttered.
>
>>>/usr/ucb: make any sense? (I dont really care for it, but I'd go along
>>> with it)
>
>What's /usr/ucb for?
>On some systems I've seen stuff scattered between /usr/bin and /usr/ucb
>with no real distinction.
/usr/ucb contains binaries from the Berkeley distribution, I believe: vi,
more, etc. etc. etc. I don't see much purpose in a Linux /usr/ucb, though.
Correct me if I'm wrong about the above.
>
>I'm of the thought that we should keep things simple.
>Maybe just /etc, /bin, and /usr/bin and maybe axe /usr/etc and /usr/ucb??
>
>I'm fully behind a standard setup for Linux. I'd even like to help!
Well, I don't know if there'll ever be a "standard" setup for Linux, but
I'm trying to start assembling people who are interested in becoming a
part of the Debian project. Anyone interested may join the DEBIAN channel
of the linux-activists mailing list at niksula.hut.fi. Please note that
I just created it so there's not too much activity yet :) I sent something
to c.o.l.a. a few days ago, but it hasn't appeared yet. So, let's get
some discussion going, guys and girls! Don't be shy! :)
One announcement for all of you who are interested in the status of Debian:
I'm going out-of-town for the weekend and I'll be giving Debian to a few
locals to install and kick around for the weekend. If all goes well it will
be available soon after I return. (Hmm, doesn't that sounds familiar... :)
Sunando Sen
setup. As things stand now, if one wants to move from the SLS to the MCC
distribution (say, after hearing all those horror stories recently), one has
to pretty much reformat the disk and start from scratch, because the
distributions are so incompatible with each other. With more and more
distributions looming in the horizon, this is clearly getting out of hand.
I believe there is no reason why we cannot reach a consensus about file
system layout, _if_ the heavyweights (you know who you are, I hope) lend
their support. After all, things like the kernel and the libraries are
being developed in a systematic way.
That being said, however, consensus will not easy to achieve. The three
or four varieties of Unix that I have seen all seem to have differnt ideas.
For example, under AIX, /bin is linked to /usr/bin and /lib to /usr/lib.
One could take this as an effective end to questions like `does this go in
/bin or /usr/bin?' I noticed that SLS attempts to resolve the same question
by placing some of the binaries in both. At least AIX's method wastes less
space.
About /sbin, I think it is totally unncessary. There is a program called
`sash' (stands for `secure administration shell', or something like that)
that has a number of useful builtin commands: such as cp, ls, rm, mv, ln,
eventar and compress. Given a statically linked copy of this program, one
does not need anything else for emergencies. There is also another program
called `chlib' for safely upgrading shared libraries. For additional
insurance, one can statically link init, mount, sync. But then, these
programs have to remain in their standard place, which is probably /etc.
On the other hand, Linux is moving towards binary compatibility with
SVR4. If commercial SVR4 programs expect certain binaries to live in
certain places, this will pretty much force the issue. We will have no
choice but to adopt whatever is the SVR4 convention.
Sunando Sen
John Paul Morrison
OUTTA HERE! <aeh...@sumax.seattleu.edu> wrote:
:No flames, just honest questions:
:
:In article <263bc7$m...@news.aero.org> elk...@aerospace.aero.org (Michael Elkins) writes:
:>In article <263a6k$2...@iskut.ucs.ubc.ca>,
:>John Paul Morrison <jmor...@rflab.ee.ubc.ca> wrote:
:>>/bin
:>I personally vote for /sbin and /usr/sbin. But I'd like to see them be
:>something that is optional. Some people are of the opinion that a rather
:>large subset of progs should be statically linked, others are not (me being
:>one; i have no static links on my system)
: ^^^yes, the fewer of them damned links the better!
:
:Why sbin rather than bin? (Personally, I prefer /bin -- most systems I've
:used don't have an /sbin... what's the history behind /sbin??)
I know Suns have a /sbin. The point is to keep a minimal set of binaries
around to make it easier if (when) the system gets hosed.
:
:What's the difference between /etc and /usr/etc? Similar to the
:concept behind /bin and /usr/bin.
/bin and /etc typically have a minimal set of binaries and config
files needed to mount the /usr, /var, /tmp and /home file systems, and
possibly NFS filesystems. If you are a single user system, or you have
a small disk, the distinction between /bin and /usr/bin probably don't
seem relevant.
Once filesystems are mounted, you wont notice the difference, but it is
important at the physical level. I keep a smallish root partition. That
way if / gets hosed, damage is limited. Except for /etc/passwd and
a few easily preserved files, the root partition should be expendable,
ie it can be easily restored. I think the root partion can be more likely
to get thrashed, so if individual partitions are easy to restore, that's
a Good Thing. Isolating things on different filesystems can help contain
damage, and make things a bit easier to restore.
If you have your filesystems on the same drive, then a drive failure
would trash everything, no matter how you partition it. but
partitioning can still help isolate damage caused by bugs (not
gauranteed to, but it can help). If you care about your users, you
can leave /home unmounted if you are doing anything risky.
At the very least, I think it is a good idea to have:
/ root, 5-20 megs, possibly higher depending on your drive(s)
/everything_else
I would go further still:
/ root, small drive or partition
/tmp small drive or partition
/var medium to large, depending on whether you spool news, uucp, mail etc.
/usr large drive or partion, or NFS
/home depends on how many users you plan to support. you can always have:
/home/mystuff....the good fast SCSI 2 drive
/home/friends....mount point for another drive, or symlink
/home/losers.....people you sort of have to give an account;
(old, MFM drive, need whack to start spinning :-)
Linux doesn't have quotas, and if you don't use extfs 2, you can't reserve
space for root. Isolating things on partitions can prevent the system
from gettting crippled by a runaway user process, or a pig in /home.
(obviously, you would have to keep world writable files out of important
filesystems). If waycoolfs alpha 0.9 is released, you can easily try it out,
by nuking /tmp. Or you can use a slower, but sturdy filesystem for /home,
but use a faster, possibly buggy filesystem, on a diectory that isn't
critical. An ideal distribution package would be so complete and easy to
install, that you would never have to back up /usr or /var, because
the whole deal was already on the distribution disks or tapes. That
makes it easier to back up a few files in /etc, and backup /home regularly.
(that can still be done on a filesystem, but havin seperate filesystems
tends to enforce it, so system stuff and user stuff dont get mixed).
That's the general idea. Once things are mounted, it doesnt matter.
but is makes sense for administration. Our Suns are organized
along those lines, depending on whether they are diskless, servers etc.
It's basic stuff, and it would be a nice idea for package developers
to offer to install that way. If good practices go into the installation
and distribution packages, that makes life easier for all.
:>>/usr/ucb: make any sense? (I dont really care for it, but I'd go along
:>> with it)
:
:What's /usr/ucb for?
:On some systems I've seen stuff scattered between /usr/bin and /usr/ucb
:with no real distinction.
typically, the Berkeley things go in ucb. Some people wanted compatibility
with SysV and berekely, so there might be a different ls in ucb. A lot
of Berekely networking things go in /usr/ucb, at least in SunOS.
:
:I'm of the thought that we should keep things simple.
:Maybe just /etc, /bin, and /usr/bin and maybe axe /usr/etc and /usr/ucb??
This was the SLS approach. There's the tradion based argument; that isn't
very convincing, except that it can make life easier, since other UNIX
people will know what you are talking about. For a practical reason, it
makes some things easier, for the reasons I described above (multiple
disks, etc).
:
:I'm fully behind a standard setup for Linux. I'd even like to help!
:
:It drives me crazy to have some programs expect /bin/lpr and others
:expect /usr/bin/lpr... so as a consequence I need to either hunt down
:the darn source and recompile, or ln -s lpr ../usr/bin/lpr!
most programs should use the path anyway. If the various Linux distributions
had some common guidelines to follow, then installed systems wouldnt have
that problem. Some problems are caused by bugs; otehr problems are caused
by improper configuration, becuase people arent sure what to do.
Example: is Linux BSD? SysV? POSIX? If people don't know the answer, then
stuff may be compiled wrong. init will make entries in /etc/utmp, but
so will some gettys. this just buggers up "last". If login sends logs
to the wrong place, then finger won't show correct login info for users.
If you put BSD manpages in with other man pages, your man pages wont
look right when formatted. The list goes on; when everyone does
their own thing, you have to be an expert to sort out and track down
all the bugs. When installation packages get it wrong, then total newbies
get confused, and people waste time, or get poor results. The FAQ
doesnt have enough scope to answer: where to install things, what version
of a program to install, where to install it, etc. If we can spec things
out then SLS, Slackware, Debian will (probably) follow. The merits of
each package can be based on how well it does the job, not in what or
where it installs things.
I saw a few things in the Linux-activists list. Once channel seems to
be secret and by invitation only (possibly a good thing); and I'm not
sure if others are active. Since the "Debian" packages looks like it
is trying to do things correctly from scratch, we can discuss it on
the Debian channel. If people don't mind, I think it would be nice to
discuss it out in the open. (unfortunately, at the risk of starting
religious wars; if we can reference things to published standards, or
at least to how some existing systems do it, maybe that can cut out
some nonsense. Above all, guidelines should be based on software that
is available, being maintained by someone, and that works correctly in
at least 90% of all cases, save the 10% of cases for some other
pacakge or way of configuring. So a guideline would recommend one
package over another based on those criteria). Perhaps we can setup an
automated "best of" poll for a few contentious issues, which would
resolve how things ought to be arranged, which package to use in
preference to another, etc.
:
:-Anthony
:
Ian McCloghrie
>All I can say is that it would be _extremely_ useful to have a standard
>setup. As things stand now, if one wants to move from the SLS to the MCC
There are efforts going toward this, on the FSSTND channel of
the linux-activists list.
> About /sbin, I think it is totally unncessary. There is a program called
>`sash' (stands for `secure administration shell', or something like that)
>that has a number of useful builtin commands: such as cp, ls, rm, mv, ln,
>eventar and compress. Given a statically linked copy of this program, one
>does not need anything else for emergencies. There is also another program
First off, /sbin is not for statically linked binaries.
/sbin is for SYSTEM binaries, and is intended to take binaries
out of /etc. /sbin and /usr/sbin are used for programs that only
root would run. ifconfig, mkfs, fsck, things like that. Secondly,
that's going to be one _huge_ binary that will hardly ever be used,
sounds like a great waste of disk space to me.
> On the other hand, Linux is moving towards binary compatibility with
>SVR4. If commercial SVR4 programs expect certain binaries to live in
>certain places, this will pretty much force the issue. We will have no
>choice but to adopt whatever is the SVR4 convention.
symlinks are an easy way to fix this question.
--
/~> Ian McCloghrie | Commandant of Secret Police - Cal Animage Beta.
< < /~\ |~\ |~> | | <~ | email: i...@ucsd.edu Net/2, USL 0!
\_> \_/ |_/ |~\ |__| _> | Card Carrying Member, UCSD Secret Islandia Club
Nick Ruprecht
>/bin what should go here?
> should it be shared lib linked files just to get the system up?
Due to the general confusion between /bin and /usr/bin it might be
best to go the SunOS way and make /bin a symlink to /usr/bin. The
essential standalone utilities and stuff you need before /usr is
mounted could go into /etc or /sbin.
>/etc basic system files...
>/usr/etc
> a seperate directory, not a symlink. probably on another filesystem
In a network, /usr will normally be a NFS mounted filesystem shared by
all machines, so /usr/etc should contain `etc' stuff that can be
shared. /etc should contain stuff that differs between machines (like
passwd, rc* etc.) or that must be available before mounting.
>/usr/ucb: make any sense? (I dont really care for it, but I'd go along
> with it)
I think we could reserve that for programs which are incompatible
between SysV and Berkeley version, like ls, ps etc. This way, users
could select the UCB version by putting /usr/ucb before /usr/bin in
their path.
>Maybe people can post the hier man page for a few popular Unixes,
I include the SunOS hier man page at the end of this mail.
In article <sens.133....@FASECON.ECON.NYU.EDU>, se...@FASECON.ECON.NYU.EDU (Sunando Sen) writes:
> About /sbin, I think it is totally unncessary. There is a program called
>`sash' (stands for `secure administration shell', or something like that)
>that has a number of useful builtin commands: such as cp, ls, rm, mv, ln,
>eventar and compress. Given a statically linked copy of this program, one
>does not need anything else for emergencies.
/sbin is nice for system administration binaries needed before
filesystems other than root are available. Having sash in there sounds
like a good idea, as this takes up less space than all the commands
contained in it as separate, statically linked, commands (as the
library is only included once instead of once for each program).
Just my DM0.03 (approx. $0.02) -
Nick
--
Nick Ruprecht rupr...@ls7.informatik.uni-dortmund.de
The Computer Graphics Group phone: +49-231-755 6134
Department of Computer Science fax: +49-231-755 6321
University of Dortmund D-44221 Dortmund, Germany
-----8<----- snip snip -----8<-----
HIER(7) ENVIRONMENTS, TABLES, AND TROFF MACROS HIER(7)
NAME
hier - file system hierarchy
DESCRIPTION
The following outline gives a quick tour through a typical
SunOS file system hierarchy:
/ root directory of the file system
/dev/
devices (Section 4)
MAKEDEV
shell script to create special files
MAKEDEV.local
site specific part of MAKEDEV
console
main system console, console(4S)
drum paging device, drum(4)
*mem memory special files, mem(4S)
null null file or data sink, null(4)
pty[p-z]*
pseudo terminal controllers, pty(4)
tty[ab]
CPU serial ports, zs(4S)
tty[0123][0-f]
MTI serial ports mti(4S)
tty[hijk][0-f]
ALM-2 serial ports mcp(4S)
tty[p-z]*
pseudo terminals, pty(4)
vme* VME bus special files, mem(4S)
win window system special files, win(4S)
xy* disks, xy(4S)
rxy* raw disk interfaces, xy(4S)
...
/etc/
system-specific maintenance and data files
dumpdates
dump history, dump(8)
exports
table of file systems exportable with NFS,
exports(5)
fstab
file system configuration table, fstab(5)
group
group file, group(5)
hosts
host name to network address mapping file,
hosts(5)
hosts.equiv
list of trusted systems, hosts.equiv(5)
motd message of the day, login(1)
mtab mounted file table, mtab(5)
networks
network name to network number mapping file,
networks(5)
passwd
password file, passwd(5)
phones
private phone numbers for remote hosts, as
described in phones(5)
printcap
table of printers and capabilities, printcap(5)
protocols
protocol name to protocol number mapping file,
protocols(5)
rc shell program to bring the system up multiuser
rc.boot
startup file run at boot time
rc.local
site dependent portion of rc
remote
names and description of remote hosts for tip(1C),
remote(5)
services
network services definition file, services(5)
ttytab
database of terminal information used by getty(8)
...
/export/
directory of exported files and file systems for
clients, including swap files, root, and /usr file
systems
/home/
directory of mount points for remote-mounted home
directories and shared file systems
user home (initial working) directory for user
.profile
set environment for sh(1), environ(5V)
.project
what you are doing (used by (finger(1))
.cshrc
startup file for csh(1)
.exrc
startup file for ex(1)
.plan
what your short-term plans are (used by
finger(1))
.rhosts
host equivalence file for rlogin(1C)
.mailrc
startup file for mail(1)
calendar
user's datebook for calendar(1)
...
/lost+found
directory for connecting detached files for fsck(8)
/mnt/
mount point for file systems mounted temporarily
/sbin/
executable programs needed to mount /usr/
hostname
ifconfig
init
mount
sh
/tmp/
temporary files, usually on a fast device, see also
/var/tmp/
ctm* used by cc(1V)
e* used by ed(1)
...
/var/
directory of files that tend to grow or vary in size
adm/ administrative log files
lastlog
record of recent logins, utmp(5V)
lpacct
line printer accounting lpr(1)
messages
system messages
tracct
phototypesetter accounting, troff(1)
utmp table of currently logged in users, utmp(5V)
vaacct, vpacct
varian and versatec accounting vtroff(1),
pac(8)
wtmp login history, utmp(5V)
...
preserve/
editor temporaries preserved here after
crashes/hangups
spool/
delayed execution files
cron/
used by cron(8)
lpd/ used by lpr(1)
lock present when line printer is active
cf* copy of file to be printed, if necessary
df* control file for print job
tf* transient control file, while lpr is
working
mail/
mailboxes for mail(1)
name mail file for user name
name.lock
lock file while name is receiving mail
mqueue/
mail queue for sendmail(8)
secretmail/
like mail/, but used by xsend(1)
uucp/
work files and staging area for uucp(1C)
LOGFILE
summary log
LOG.*
log file for one transaction
...
tmp/ temporary files, to keep /tmp/ small
raster
used by plot(1G)
stm* used by sort(1V)
...
yp/ Network Information Service (NIS) database files,
ypfiles(5)
/usr/
general-purpose directory, usually a mounted file
system
bin/ utility programs
as assembler, as(1)
cc C compiler executive, c.f. /usr/lib/ccom,
/usr/lib/cpp, /usr/lib/c2
csh the C-shell, csh(1)
sh the Bourne shell, sh(1)
...
demo/
demonstration programs
diag/
system tests and diagnostics
dict/
word lists, etc.
spellhist
history file for spell(1)
words
principal word list, used by look(1)
...
etc/ system administration programs; c.f. section 8
catman
update preformatted man pages, catman(8)
cron the clock daemon, cron(8)
dump file system backup program dump(8)
getty
part of login(1), getty(8)
in.comsat
biff server (incoming mail daemon),
comsat(8C)
init the parent of all processes, init(8)
mount
mount(8)
yp/ NIS programs
ypinit
build and install NIS database,
ypinit(8)
yppush
force propagation of a changed NIS map,
yppush(8)
ypset
point ypbind at a particular server,
ypset(8)
...
...
games/
backgammon
lib/ library directory for game scores, etc.
quiz.k/
what quiz(6) knows
africa
countries and capitals
index
category index
...
...
...
hosts/
symbolic links to rsh(1C) for commonly accessed
remote hosts
include/
standard #include files
a.out.h
object file layout, a.out(5)
images/
icon images
machine/
header files from /usr/share/sys/sys/machine;
may be a symbolic link
math.h
intro(3M)
net/ header files from /usr/share/sys/sys/net; may
be a symbolic link
nfs/ header files used in the Network File System
(NFS)
stdio.h
standard I/O, intro(3)
sys/ kernel header files, c.f. /usr/share/sys/sys
...
lib/ object libraries, compiler program binaries, and
other data
ccom C compiler proper
cpp C preprocessor
c2 C code improver
eign list of English words to be ignored by ptx(1)
font/
fonts for troff(1)
ftR Times Roman
ftB Times Bold
...
libc.a
system calls, standard I/O, etc. (2,3,3S)
libm.a
math library, intro(3M)
lint/
utility files for lint
lint[12]
subprocesses for lint(1V)
llib-lc
dummy declarations for /usr/lib/libc.a,
used by lint(1V)
llib-lm
dummy declarations for /usr/lib/libm.a
...
units
conversion tables for units(1)
uucp/
programs and data for uucp(1C)
L.sys
remote system names and numbers
uucico
the real copy program
...
...
local/
locally maintained software
old/ obsolete and unsupported programs
pub/ publicly readable data files
sccs/
binaries of programs that compose the source code
control system (SCCS)
src/ system source code tree
stand/
standalone programs (not run under the Sun
Operating System)
share/
architecture independent files
lib/ architecture independent data files
termcap
description of terminal capabilities,
termcap(5)
tmac/
macros for troff(1)
tmac.an
macros for man(7)
tmac.s
macros for ms(7)
...
...
man/ on-line reference manual pages, man(1)
man?/
source files (nroff(1)) for sections 1
through 8 of the manual
as.1
...
cat?/
preformatted pages for sections 1
through 8 of the manual
...
sys/ SunOS kernel source and object modules
ucb/ binaries of programs developed at the University
of California, Berkeley
ex line-oriented editor for experienced users,
ex(1)
vi screen-oriented editor, vi(1)
...
/vmunix
the SunOS kernel binary
SEE ALSO
filesystem(7), find(1), finger(1), grep(1V), ls(1V),
rlogin(1C), whatis(1), whereis(1), which(1), ncheck(8)
BUGS
The locations of files are subject to change without notice;
the organization of your file system may vary.
This list is incomplete.
The Network Information Service (NIS) was formerly known as
Sun Yellow Pages (YP). The functionality of the two remains
the same; only the name has changed.
Jon Hamilton
[...]
>
> That being said, however, consensus will not easy to achieve. The three
>or four varieties of Unix that I have seen all seem to have differnt ideas.
>For example, under AIX, /bin is linked to /usr/bin and /lib to /usr/lib.
>One could take this as an effective end to questions like `does this go in
>/bin or /usr/bin?' I noticed that SLS attempts to resolve the same question
>by placing some of the binaries in both. At least AIX's method wastes less
>space.
How do you arrive at that conclusion? If you've got 70M of binaries spread
over the whole disk vs 70M of binaries all shoved in one diretory, they take
up the same amount of space. Actually, putting them all in one directory
will use a bit *more* space, since the directory entry will be larger, but
that's pretty trivial.
I don't like the links solution, but consider SLS 1.02 (latest one I have
any experience with) - look in /bin and /usr/bin and you will find *many*
duplicates (so many you can't count them on both hands and both feet).
That's a waste of space. I don't think the answer is to do away with
/usr/etc and /usr/bin though - some people like having their root mounted
on a small, fast disk or partition, and throwing everything in /usr/bin
and /usr/etc in /bin and /etc just makes their / partition that much larger.
[...]
>
> On the other hand, Linux is moving towards binary compatibility with
>SVR4. If commercial SVR4 programs expect certain binaries to live in
>certain places, this will pretty much force the issue. We will have no
>choice but to adopt whatever is the SVR4 convention.
If they're looking for _config_ files, you've probably got a pretty good
point. If they're looking for _binaries_, other than a very few, they're
broken.
>
>Sunando Sen
--
====================================================================
= Jon Hamilton | "Please saw off my legs. =
= j...@iastate.edu | -- George Carlin =
====================================================================
James Fidell
I'd be quite happy to see Linux moving towards an SVR4-style organisation.
At least it addresses some of the issues regarding why certain files go
where. It is also moving *towards* a state where hardly any files on the
root and system /usr partitions need to be writeable, which ought to be
a plus for security in a ``real-world'' system.
According to a list I have, SVR4 splits the file-systems up as :
/ root file system
/etc machine-specific admin. config. files and databases
/tmp small temporary files
/sbin admin. utillities used to boot the machine
/usr static, architecture dependent files
/var files and directories which change over time
/dev device files
/home user's home directories
/usr/bin system utilities
/usr/sbin system admin. utilities
/var/tmp large temp. files.
/etc/fs
/etc/lib/fs file-system specific stuff.
/usr/lib
/usr/ccs/lib libraries and architecture dependent databases.
/usr/share architecture independent shareable files.
/opt addon packages.
James.
--
"Yield to temptation -- |
it may not pass your way again" | jf...@mfltd.co.uk
|
- Lazarus Long | James Fidell
Theodore Ts'o
Date: 2 Sep 93 04:40:30 GMT
About /sbin, I think it is totally unncessary. There is a program called
`sash' (stands for `secure administration shell', or something like that)
that has a number of useful builtin commands: such as cp, ls, rm, mv, ln,
eventar and compress.
/sbin is for more than just statically linked copies of cp, ls, rm, etc.
In the new BSD filesystem standard, /sbin is where all of the executable
files that used to be in /etc are moved to. So getty, init, fsck,
login, etc., would all be moved into /sbin.
- Ted
Sunando Sen
>
> First off, /sbin is not for statically linked binaries.
>/sbin is for SYSTEM binaries, and is intended to take binaries
>out of /etc. /sbin and /usr/sbin are used for programs that only
>root would run. ifconfig, mkfs, fsck, things like that. Secondly,
>that's going to be one _huge_ binary that will hardly ever be used,
>sounds like a great waste of disk space to me.
>
I assume you are speaking of the size of sash. It is actually a little bit
more than 100k, hardly a waste of space cosidering the peace of mind it
gives you.
Sunando Sen
Jim Haynes
Is this whole discussion going on with no knowledge of the one that has
taken place on the fsstnd channel?
--
hay...@cats.ucsc.edu
hay...@cats.bitnet
"Ya can talk all ya wanna, but it's dif'rent than it was!"
"No it aint! But ya gotta know the territory!"
Meredith Willson: "The Music Man"
Carlo James Calica
Here is the hier manpage for HP-UX 9.0 (Maybe 9.01)
hier - file system hierarchy
The following outline gives a quick tour through a representative HP-
UX directory hierarchy. Some of the directories listed only appear
with HP-UX versions that support certain optional commands or packages
that use those directories. Some HP-UX versions add special
directories not shown here.
/ Root directory.
/bin Frequently-used commands and those required to
boot, restore, recover, and/or repair the system.
/dev Special files (device files); see _ m_ k_ n_ o_ d(1).
/etc
/etc/newconfig New (updated) versions of customizable
(localizable) configuration files and shell
scripts. Shipped here so as not to overwrite
current versions. Copied to regular locations for
newly installed systems. System administrators
may wish to keep them for later reference.
/lib Frequently-used object code libraries and related
utilities.
/lost+found For connecting detached files; for use by _ f_ s_ c_ k(1).
/rbin An analog to / / / /b b b bi i i in n n n for users in the restricted
environment of _ r_ s_ h(1).
/tmp Place to put temporary files (those normally with
short lifetimes and which may be removed without
notice).
/users User home directories; sometimes immediate,
sometimes at lower levels.
/users/guest Default home directory for user "guest"; see
_ p_ a_ s_ s_ w_ d(4). Directory exists for novice users; you
may wish to remove it.
/usr Less-frequently-used commands and other
miscellaneous things; historically, often a
separate, mounted volume.
/usr/adm
Hewlett-Packard Company - 1 - HP-UX Release 9.0: August 1992
/usr/adm/sa
/usr/bin Less-frequently-used commands and those not
required to boot, restore, recover, and/or repair
the system.
/usr/bin/graph _ G_ u_ t_ i_ l(1) graphics commands.
/usr/contrib User-contributed (unsupported, internal) commands,
files, etc. Files under this directory come from
outside the local site or organization, e.g. from
users groups, HP service engineers, etc. See
/ / / /u u u us s s sr r r r/ / / /l l l lo o o oc c c ca a a al l l l for local-site commands and files.
/usr/contrib/bin User-contributed commands.
/usr/contrib/games User-contributed games.
/usr/contrib/include
User-contributed include files. To include them,
you must (in C) give a complete pathname, for
example, #include "/usr/contrib/include/symtab.h".
/usr/contrib/lib User-contributed libraries.
/usr/contrib/man/cat[1-8]
User-contributed manual entries, formatted.
/usr/contrib/man/man[1-8]
User-contributed manual entries, unformatted.
/usr/contrib/man/$LANG/cat[1-8]
User-contributed manual entries, formatted form
for installed native languages. The LANG
environment variable may take on values given in
the / / / /u u u us s s sr r r r/ / / /l l l li i i ib b b b/ / / /n n n nl l l ls s s s/ / / /c c c co o o on n n nf f f fi i i ig g g g table.
/usr/contrib/man/$LANG/man[1-8]
User-contributed manual entries, unformatted form
for installed native languages.
/usr/include High-level C-language header files (shared
definitions).
/usr/include/sys Low-level (kernel-related) C-language header
files.
/usr/lib Less-frequently-used object code libraries,
related utilities, miscellaneous data files, etc.
Hewlett-Packard Company - 2 - HP-UX Release 9.0: August 1992
/usr/lib/acct Certain system-administrative commands.
/usr/lib/cron For _ c_ r_ o_ n(1M) and _ a_ t(1) scheduling information.
/usr/lib/graphics/c Device-independent Graphics Library (DGL) special
C-language include files. Optional on some
systems.
/usr/lib/graphics/demos
DGL demonstration software.
/usr/lib/graphics/fortran
DGL special FORTRAN-language include files.
/usr/lib/graphics/pascal
DGL special Pascal-language include files.
/usr/lib/help Data files for _ h_ e_ l_ p(1).
/usr/lib/lex Data files for _ l_ e_ x(1).
/usr/lib/macros Macro definition packages for _ n_ r_ o_ f_ f(1) and _ t_ r_ o_ f_ f.
/usr/lib/nlio Native Language I/O.
/usr/lib/nls Native Language support.
/usr/lib/nls/config Correspondence between integer language id and
name.
/usr/lib/nls/$LANG Language definition (Character Set Support, Local
Customs, and Messages) for installed native
languages. The LANG environment variable may take
on values given in the / / / /u u u us s s sr r r r/ / / /l l l li i i ib b b b/ / / /n n n nl l l ls s s s/ / / /c c c co o o on n n nf f f fi i i ig g g g table.
/usr/lib/sa
/usr/lib/spell Data files for _ s_ p_ e_ l_ l(1).
/usr/lib/tabset Data files to set tabstops.
/usr/lib/term Terminal initialization files.
/usr/lib/tmac Macro definition packages for _ n_ r_ o_ f_ f(1) and _ t_ r_ o_ f_ f.
/usr/lib/uucp[/*] Commands, configuration files, and working
directories for _ u_ u_ c_ p(1).
/usr/local Site-local commands, files, etc. Files under this
directory come from inside the local site or
organization. See / / / /u u u us s s sr r r r/ / / /c c c co o o on n n nt t t tr r r ri i i ib b b b for non-local
Hewlett-Packard Company - 3 - HP-UX Release 9.0: August 1992
unsupported commands and files.
/usr/local/bin Site-local commands.
/usr/local/games Site-local games.
/usr/local/include Site-local include files. To include them, you
must (in C) give a complete pathname, for example,
#include "/usr/local/include/symtab.h".
/usr/local/lib Site-local libraries.
/usr/local/man/cat[1-8]
Site-local manual entries, formatted.
/usr/local/man/man[1-8]
Site-local manual entries, unformatted.
/usr/local/man/$LANG/cat[1-8]
Site-local manual entries, formatted form for
installed native languages. The LANG environment
variable may take on values given in the
/ / / /u u u us s s sr r r r/ / / /l l l li i i ib b b b/ / / /n n n nl l l ls s s s/ / / /c c c co o o on n n nf f f fi i i ig g g g table.
/usr/local/man/$LANG/man[1-8]
Site-local manual entries, unformatted form for
installed native languages.
/usr/mail User mailboxes.
/usr/man Online documentation.
/usr/man/cat[1-8] Optional formatted (by nroff) versions of online
documentation for use by _ m_ a_ n(1).
/usr/man/man[1-8] Unformatted (nroff-compatible source) versions of
online documentation for use by _ m_ a_ n(1).
/usr/man/$LANG Online documentation for installed native
languages. The LANG environment variable may take
on values given in the / / / /u u u us s s sr r r r/ / / /l l l li i i ib b b b/ / / /n n n nl l l ls s s s/ / / /c c c co o o on n n nf f f fi i i ig g g g table.
/usr/man/$LANG/cat[1-8]
Formatted native language versions of online
documentation for use by _ m_ a_ n(1).
/usr/man/$LANG/man[1-8]
Unformatted native language versions of online
documentation for use by _ m_ a_ n(1).
Hewlett-Packard Company - 4 - HP-UX Release 9.0: August 1992
h h h hi i i ie e e er r r r( ( ( (5 5 5 5) ) ) ) h h h hi i i ie e e er r r r( ( ( (5 5 5 5) ) ) )
/usr/news Local-system news articles for _ n_ e_ w_ s(1).
/usr/preserve Place where _ e_ x(1) and _ v_ i(1) save lost edit
sessions until recovered.
/usr/rbin An analog to / / / /u u u us s s sr r r r/ / / /b b b bi i i in n n n for users in a restricted
environment (as imposed by _ r_ s_ h(1)).
/usr/spool Spooled (queued) files for various programs.
/usr/spool/cron Spooled jobs for _ c_ r_ o_ n(1M) and _ a_ t(1).
/usr/spool/cron/atjobs
Spooled jobs for _ a_ t(1).
/usr/spool/lp Control and working files for _ l_ p(1).
/usr/spool/lp/class Printer class definition files.
/usr/spool/lp/interface
Printer interface shell scripts.
/usr/spool/lp/member
Printer class member definition files.
/usr/spool/lp/request
Spool directories for each logical destination.
/usr/spool/uucp Queued work, lockfiles, logfiles, status files,
and other files for _ u_ u_ c_ p(1).
/usr/spool/uucppublic[/*]
Publicly-accessible directory for use with
_ u_ u_ c_ p(1).
/usr/src Source files. Only present on HP-UX
implementations which support source.
/usr/src/cmd/* Source for commands. Simple command sources
reside at the top level. Subdirectories are named
after specific commands, e.g. / / / /u u u us s s sr r r r/ / / /s s s sr r r rc c c c/ / / /c c c cm m m md d d d/ / / /c c c cc c c c,
and contain the source for multi-file or otherwise
complicated commands. Directory structure below
here depends on the individual command; see the
associated makefiles.
/usr/src/games/* Source for games. Simple game sources reside at
the top level. Subdirectories are named after
specific games, e.g. / / / /u u u us s s sr r r r/ / / /s s s sr r r rc c c c/ / / /g g g ga a a am m m me e e es s s s/ / / /m m m ma a a as s s st t t te e e er r r r, and
contain the source for multi-file or otherwise
complicated games. Directory structure below here
Hewlett-Packard Company - 5 - HP-UX Release 9.0: August 1992
h h h hi i i ie e e er r r r( ( ( (5 5 5 5) ) ) ) h h h hi i i ie e e er r r r( ( ( (5 5 5 5) ) ) )
depends on the individual game; see the associated
makefiles.
/usr/src/head Include files which are copied into
/ / / /u u u us s s sr r r r/ / / /i i i in n n nc c c cl l l lu u u ud d d de e e e/ / / /* * * *.
/usr/src/lib Source for libraries, in many subdirectories.
/usr/src/lib/libF77 Source for FORTRAN-77 miscellaneous (mostly math)
libraries.
/usr/src/lib/libI77 Source for FORTRAN-77 I/O libraries.
/usr/src/lib/libPW Source for Programmer's Workbench libraries.
/usr/src/lib/libc Source for standard C libraries.
/usr/src/lib/libcurses/*
Source for curses (cursor control) libraries.
/usr/src/lib/libl Source for _ l_ e_ x(1) libraries.
/usr/src/lib/libm Source for C math libraries.
/usr/src/lib/liby Source for _ y_ a_ c_ c(1) libraries.
/usr/tmp Alternate place to put temporary files; usually
used when there may be very many of them or if
they will be large.
D D D DE E E EP P P PE E E EN N N ND D D DE E E EN N N NC C C CI I I IE E E ES S S S
Some directories include commands or files not supported on all HP-UX
implementations.
S S S SE E E EE E E E A A A AL L L LS S S SO O O O
find(1), grep(1), ls(1), whereis(1).
Hewlett-Packard Company - 6 - HP-UX Release 9.0: August 1992
--
/------------------------------+--------------------------------------\
| Carlo J. Calica | Linux: Choice of the GNU Generation |
| cal...@cae.wisc.edu | Dittos from the People's |
\ University of Wisconsin | Republic of Madison /
Arjan de Vet
>I'm interested in having some public discussion(or mailing list) about
>the layout, the versions, etc. The outcome of the discussions would
>be a "recommended" layout for Linux, so we don't have every package
>making company/person coming up with their own esoteric and incompatible
>system for naming things, organizing directories etc.
There is already a channel on Linux Activists called FSSTND which has been
discussing these issues for two months or so...
Arjan
--
Arjan de Vet <Arjan....@adv.win.tue.nl> (home)
Eindhoven University of Technology, the Netherlands <de...@win.tue.nl> (work)
Warner Losh
>> (some people are multiuser systems on real, security conscious
>> networks. shadow passwds make sense, and it isnt a hassle to
>> the single user, no network system )
Until shadow breaks old, non-recompiled programs in a fail-safe way,
it is totally useless, as it potentially allows root access (put a '*'
in the password field to find old, broken prorgams faster).
>I'd agree, once someone actually claims that everything I want to be running
>will work ok (and be secure) under the shadow stuff. Right now there is an
>awful lot of stuff in the SLS dist that needs recompiling (dunno about
>slackware, but I assume the same for it)
I know that rshd needs something done to it to make it secure with
shadow passwords.
We need to have /etc/rc files that will properly check file systems
before mounting them.
We need to have some way of UPDATING a system w/o wiping the old
configuration.
We need to at least set the damn time zone information from the
install script.
Net-2 configuration needs to be a little smoother. Don't get me
wrong, I think net-2 is wonderful. The config is not the easiest in
the world, however and some attention should be paid to it after the
other functionality bugs are fixed.
I think there should be some way to configure in various packages a
little more easily and elegantly than SLS does now.
I think that there should be some set of statically linked utilities
that will save your butt in case of fires. However, they could easily
be like the BSD boot disk where the programs aren't ment to used by
humans and have little error checking.
Warner
--
Warner Losh i...@boulder.parcplace.COM ParcPlace Boulder
I've almost finished my brute force solution to subtlety.
Warner Losh
>used don't have an /sbin... what's the history behind /sbin??)
Well, there was /bin, then there was /usr/bin, then the two were
merged. /sbin was invented to have a place to put those binaries that
you must have. At least that is my view of history through SunOS
filters. SYS V took a different path that I don't know much about.
>What's the difference between /etc and /usr/etc? Similar to the
>concept behind /bin and /usr/bin.
/etc is for each machine (since it is on the root partition).
/usr/etc is shared stuff, since /usr is often mounted from a remote
machine on smaller systems. Again, SunOS filters here.
>What's /usr/ucb for?
>On some systems I've seen stuff scattered between /usr/bin and /usr/ucb
>with no real distinction.
That's where program from bsd are stored. It has also become a place
to put bsd variants on other systems.
>I'm of the thought that we should keep things simple.
>Maybe just /etc, /bin, and /usr/bin and maybe axe /usr/etc and /usr/ucb??
No. We shouldn't axe /usr/etc. I can live without /usr/ucb (and in
fact, I do). /usr/etc vs /etc provides a good split between sharing
things that are common (eg ifconfig) and machine specific data (eg ip
addresses rc.local scripts, etc).
>I'm fully behind a standard setup for Linux. I'd even like to help!
Same here.
>It drives me crazy to have some programs expect /bin/lpr and others
>expect /usr/bin/lpr... so as a consequence I need to either hunt down
>the darn source and recompile, or ln -s lpr ../usr/bin/lpr!
What drives me nuts is that /bin/ls exists on all machines, except for
Linux so I had to hack ObjectBuilder and some other things to make
them work.
Zack Evans
In article <2641p5$3...@iskut.ucs.ubc.ca>,
John Paul Morrison <jmor...@rflab.ee.ubc.ca> wrote: (jpm)
In article <263k6k...@sumax.seattleu.edu>,
OUTTA HERE! <aeh...@sumax.seattleu.edu> wrote: (ae)
In article <263bc7$m...@news.aero.org> elk...@aerospace.aero.org (Michael Elkins) writes: (me)
me> I personally vote for /sbin and /usr/sbin. But I'd like to see them be
me> something that is optional. Some people are of the opinion that a rather
me> large subset of progs should be statically linked, others are not (me being
me> one; i have no static links on my system)
Nor do I; since it's only me using the system, I can afford to rely on a
boot floppy. It strikes me that there will be a _lot_ of people in this
situation.
ah> Why sbin rather than bin? (Personally, I prefer /bin -- most systems I've
ah> used don't have an /sbin... what's the history behind /sbin??)
On Suns, the 's' is for statically linked I think, in other words if /lib dies
you still have enough binaries that work, to sort out the mess. Exactly what
constitutes 'enough' is one of those religious things...
jpm>Linux doesn't have quotas, and if you don't use extfs 2, you can't reserve
jpm>space for root.
I think the quota patches are heading for a revival and will be in PL13, or at
least available for PL13. And if you don't use ext2fs, why not?
jpm>typically, the Berkeley things go in ucb. Some people wanted compatibility
jpm>with SysV and berekely, so there might be a different ls in ucb. A lot
jpm>of Berekely networking things go in /usr/ucb, at least in SunOS.
Sun's 5bin is bloody confusing if you ask me - if you are going to have a dual
universe have one, instead of this bizarre kludge.
jpm>If you put BSD manpages in with other man pages, your man pages wont
jpm>look right when formatted.
I noticed that this morning :( Is there anything I can do about it? Does anyone
have a super duper BSD to Linux man page conversion perl script?
jpm>their own thing, you have to be an expert to sort out and track down
jpm>all the bugs.
I decided to have a good sort out and make sure I had the latest version of
everything, last week; I am still doing it now. It's great fun getting
everything to work with everything else :)
jpm>I saw a few things in the Linux-activists list. Once channel seems to
jpm>be secret and by invitation only (possibly a good thing); and I'm not
jpm>sure if others are active.
Is it? As far as I know the Standards discussion channel is as open as any of
the others... still, I won't give it's full name here just in case I am wrong
:) Someone on that channel is about to publish a draft standard as well...
As an aside, I now _do_ have an sbin, where s is for superuser not static -
everything that normal users won't use is in there - I don't have any binaries
in /etc now.
Zack
--
Zack Evans pyc...@cent1.lancs.ac.uk or zev...@nyx.cs.du.edu
UNIX was not designed to stop its users from doing stupid things,
as that would also stop them from doing clever things.
John Paul Morrison
Jim Haynes <hay...@cats.ucsc.edu> wrote:
>
>Is this whole discussion going on with no knowledge of the one that has
>taken place on the fsstnd channel?
what's wrong with having it here? is standardizing meant to be secret?
Standards, personal preferences, flame wars etc. have a broad enough
scope for everyone to follow. I can count four activists channels
that look related to standards, and it isnt clear which is the dominant,
active one.
>
>--
>hay...@cats.ucsc.edu
>hay...@cats.bitnet
>
>"Ya can talk all ya wanna, but it's dif'rent than it was!"
>"No it aint! But ya gotta know the territory!"
> Meredith Willson: "The Music Man"
>
John Paul Morrison
Arjan de Vet <de...@adv.win.tue.nl> wrote:
:In article <263a6k$2...@iskut.ucs.ubc.ca>,
:John Paul Morrison <jmor...@rflab.ee.ubc.ca> wrote:
:
:>I'm interested in having some public discussion(or mailing list) about
:>the layout, the versions, etc. The outcome of the discussions would
:>be a "recommended" layout for Linux, so we don't have every package
:>making company/person coming up with their own esoteric and incompatible
:>system for naming things, organizing directories etc.
:
:There is already a channel on Linux Activists called FSSTND which has been
:discussing these issues for two months or so...
Maybe they can post a summary from time to time, to keep the riff raff
abreast of things :-) "Proceeding of the Linux FSSTND Working Committee..."
:
:Arjan
:
:--
:Arjan de Vet <Arjan....@adv.win.tue.nl> (home)
:Eindhoven University of Technology, the Netherlands <de...@win.tue.nl> (work)
Jim Haynes
In article <266h42$9...@iskut.ucs.ubc.ca> jmor...@rflab.ee.ubc.ca (John Paul Morrison) writes:
>Maybe they can post a summary from time to time, to keep the riff raff
>abreast of things :-) "Proceeding of the Linux FSSTND Working Committee..."
many places it's discussed - I just wondered if all the discussion in this
newsgroup had any knowledge of the one in fsstnd, and vice versa.
Nick Ruprecht
>On Suns, the 's' is for statically linked I think, in other words if /lib dies
>you still have enough binaries that work, to sort out the mess. Exactly what
According to the SunOS `hier' man page, /sbin is for `executable
programs needed to mount /usr', as /bin is just a link to /usr/bin
under SunOS. It's probably a good idea to have programs in there
statically linked. We might also add a few more, e.g. sash.
>Sun's 5bin is bloody confusing if you ask me - if you are going to have a dual
>universe have one, instead of this bizarre kludge.
SunOS 4 uses BSD versions of programs by preference, but also offers
the SysV versions. 5bin contains SysV versions of programs with
incompatible user interfaces (like ls, ps ...). The bizarreness stems
from having unix variants where the same commands work differently. I
see no better way to deal with this than having the different versions
in different directories.
>jpm>If you put BSD manpages in with other man pages, your man pages wont
>jpm>look right when formatted.
>I noticed that this morning:( Is there anything I can do about it? Does anyone
>have a super duper BSD to Linux man page conversion perl script?
I haven't looked at it, but getting BSDish roff macros for man pages
(under SunOS, these are in /usr/share/lib/tmac/tmac.an) might help.
Cheers -
Anthony Shipman
>I personally vote for /sbin and /usr/sbin. But I'd like to see them be
>something that is optional. Some people are of the opinion that a rather
>large subset of progs should be statically linked, others are not (me being
>one; i have no static links on my system)
I recommend that you keep a small number of file utilities statically linked.
I know of someone who managed to rename the C shared library in /lib one day
and all utilities broke including mv and cp. Fortunately we had another
machine on which we could develop a statically linked fixup program and rcp it
over.
I've thought that a statically linked "repair" shell would be useful.
It would implement very basic mv, cp, cd, ls etc as built-in commands.
--
Anthony Shipman "You've got to be taught before it's too late,
CP Software Export Pty Ltd, Before you are six or seven or eight,
4th Flr, 493 St Kilda Rd, To hate all the people your relatives hate,
Melbourne, Australia, 3121 You've got to be carefully taught." R&H
E-mail: a...@cpsg.com.au, Phone: +61 3 2432374
Simon Johnston BRA08 7261 x6320
: /dev
: has the dust finally settled here?
: (not trying to pick at old wounds, but it is a good idea
: to get it right)
what about sysv like /dev/dsk/c?d?s? type device descriptors, for instance
we could use psuedo-channel numbers, so that 0=IDE, 1=SCSI disks, 2=SCSI CD
so you could use a mapping like:
hda1 /dev/dsk/c0d1s1
hda2 /dev/dsk/c0d1s2
hdb1 /dev/dsk/c0d2s1
hdb2 /dev/dsk/c0d2s2
sda1 /dev/dsk/c1d1s1
sda2 /dev/dsk/c1d1s2
sdb1 /dev/dsk/c1d2s1
sdb2 /dev/dsk/c1d2s1
sr0 /dev/dsk/c2d1s0 <- use 0 to indicate whole disk.
sr1 /dev/dsk/c2d2s0 so that hda is /dev/dsk/c0d1s0.
( comments please, I like this idea but is it practical ? )
: /etc
: basic system files...
: passwd... can we agree to use shadow passwds too?
: (some people are multiuser systems on real, security conscious
: networks. shadow passwds make sense, and it isnt a hassle to
: the single user, no network system )
: net2 seems to be the way to go. net-2 is organized like SysV
: shall we use /etc/rd.d/ for rc files? net-2 and SysV init
: like this setup.
How about the boot utils package the /etc/fs directory using generic fsck
and mkfs is very useful.
keep it up !
MODULE Sig;
FROM ICL IMPORT StdDisclaimer;
BEGIN
(*-----------------------------------------------------------------------------.
| Simon K. Johnston - Development Engineer | ICL Retail Systems, |
| ------------------------------------------------------ | 3/4 Willoughby Road,|
| Unix Mail : S.K.Johnst...@oasis.icl.co.uk | Bracknell, Berks, |
| Telephone : +44 (0)344 476320 Fax: +44 (0)344 476084 | United Kingdom |
| Internal : 7621 6320 OP Mail: S.K.Johnston@BRA0801 | RG12 8TJ |
`-----------------------------------------------------------------------------*)
END Sig.
OUTTA HERE!
>what about sysv like /dev/dsk/c?d?s? type device descriptors, for instance
>we could use psuedo-channel numbers, so that 0=IDE, 1=SCSI disks, 2=SCSI CD
>so you could use a mapping like:
>
>hda1 /dev/dsk/c0d1s1
>hda2 /dev/dsk/c0d1s2
>hdb1 /dev/dsk/c0d2s1
>hdb2 /dev/dsk/c0d2s2
>sda1 /dev/dsk/c1d1s1
>sda2 /dev/dsk/c1d1s2
>sdb1 /dev/dsk/c1d2s1
>sdb2 /dev/dsk/c1d2s1
>sr0 /dev/dsk/c2d1s0 <- use 0 to indicate whole disk.
>sr1 /dev/dsk/c2d2s0 so that hda is /dev/dsk/c0d1s0.
>
>( comments please, I like this idea but is it practical ? )
Aw man, I dunno about this...
For me it's purely a matter of laziness/easy-of-typing/remembering.
It's simple enough to type e2fsck /dev/hda1 or whatever rather than (a)
remembering and (b) typing e2fsck /dev/dsk/c0d1s1.
Well, for hard disks it isn't really a problem because how often does
one need to type out harddisk stuff. However, floppies are another
matter. I'm currently in the process of porting the software at work
from SCO (barf) to another SYSV flavor and to tar over disks I have to
type tar xvpf /dev/dsk/blahblahdiskblah (whatever). I can never
remember the damned disk name. It's rather long and rather
un-intuitive. I much prefer /dev/fd0.
(Yes, I know, I know, sym-links...).
-Anthony
--
Anthony Hall _ _ Unix System Administrator
aeh...@seattleu.edu /_/ /_/ Physician Micro Systems, Inc.
_ _ 2033 6th Ave Suite 707
/_/ /_/ Seattle, WA 98122 206-441-8490
Andreas Klemm
> On the other hand, Linux is moving towards binary compatibility with
>SVR4. If commercial SVR4 programs expect certain binaries to live in
>certain places, this will pretty much force the issue. We will have no
>choice but to adopt whatever is the SVR4 convention.
Yes, it would simplify the whole story, if we would accept the
System V R4 directory structure as a quasi standard.
The way of packaging should be made similar to SVR4. If binary
compatibility with SVr4 becomes true, then we _do_ need programs
like pkgadd/pkgrm to be able to easily install or remove software
in a SVR4 manner.
Further it would be a great idea, as somebody already stated out,
to create one Linux Standard Distribution (LSD ;-) that only contains
basic stuff. This would be a good start for all other packages !!!
It would be a big deal, that *all other packages* would be installable
by the above mentioned pkgadd utility.
The goal of a LSD distrib should be
- easy to upgrade
- therefore not too large
- installation of basic non conflicting stuff
- kernel
- C/C++ compiler, header files, libs
- shared libs
- Gnu file and binutils
- support of all known filesystems
- elvis
- groff
- line printer scheduler
- pkgadd/pkgrm utility
To this LSD (Linux Standard Distribution) there should be
a source disk available, which contains the sources to all
programs that belongs to the LSD distribution.
All other packages shuld be optional installable via floppy
or tape in the SVR4 package format.
These optional packages should then be
the *new* kind of SLS, XYZ, ... distributions.
That means
designing optional packages
- based on a unified platform
- based on a given filesystem hierarchy
- based on a given package format that
is compatible to the SVR4 standard.
What do you think of that ?
Is it that, what you want to create Ian (Murdock) ???
Andreas.
--
/-\ Andreas Klemm <and...@knobel.knirsch.de> +-----------------+
|@|########################################################-@ "pay for it !" |
\-/ 41469 Neuss Germany phone +49/ 2137 12609 +-----------------+
Randy Terbush
>> >John Paul Morrison <jmor...@rflab.ee.ubc.ca> wrote:
>> >I personally vote for /sbin and /usr/sbin. But I'd like to see them be
>> >something that is optional. Some people are of the opinion that a rather
>> >large subset of progs should be statically linked, others are not (me being
>> >one; i have no static links on my system)
>>
I agree completely. Why create Yet Another Place to look for
BINaries? I first saw 'sbin' on SunOS, which I understood to be SysV
style bins. SVR4 seems to have kept 'sbin' just to make things
confusing. /etc and /bin should be files that are necessary to boot
the various 'init' levels in order to keep things on the small
(5-10MB) root partition.
>> >>/usr/etc
>> >> a seperate directory, not a symlink. probably on another filesystem
>> >> I hated the SLS /etc/inet setup
>>
>> What's the difference between /etc and /usr/etc? Similar to the
>> concept behind /bin and /usr/bin.
/bin:
/etc:
Should be all programs and config files necessary to boot both
single user, and multi-user levels. This should include all of the
networking code as well. I tend to agree with the SVR4 location of
/etc/uucp for this same reason. It should contain all programs needed
for filesystem repair and disk installation. I like rc1.d, rc2.d
directories for startup scripts ran at the corresponding init levels.
/root:
root shell configs.
/tmp:
This should be a separate filesystem from / to reduce
fragmentation of the / filesystem by frequent file creation. Do we
really need /var? Convention seems to use /tmp, /usr/tmp. It would
be nice to direct this along with the spool directory to a "scratch"
disk.
/lib:
shared libraries needed for these utilities.
(probably everything except X11 libraries).
It would be nice to put enough tools on the root partition to build
kernels, although this might be defeated by the arguments against
creating files in the / partition.
/usr/bin:
/usr/lib:
I would propose a different "standard" and use these
directories to put symbolic links to startup binaries in
subdirectories for multi-executable program sets. smail is a good
example of this, with /usr/bin/smail now being a link to
/usr/bin/mail/smail. (OK... Call it /usr/bin/sendmail)
/usr/lib/smail containing support files for the mail utils.
>> >>/usr/ucb: make any sense? (I dont really care for it, but I'd go along
>> >> with it)
>>
>> What's /usr/ucb for?
>> On some systems I've seen stuff scattered between /usr/bin and /usr/ucb
>> with no real distinction.
This adds confusion. We should attempt to add flags to support both
BSD and SYSV syntax in one program.
Where do we put log files created in single user mode?
--
Randy Terbush
INET: ran...@cse.unl.edu
UUCP: netcomsv!dsndata!randyt
--
Randy Terbush
INET: ran...@cse.unl.edu
UUCP: netcomsv!dsndata!randyt
Scott Telford
> jpm>If you put BSD manpages in with other man pages, your man pages wont
> jpm>look right when formatted.
>
> I noticed that this morning :( Is there anything I can do about it? Does anyone
> have a super duper BSD to Linux man page conversion perl script?
With groff (the grof106A.taz package in the archives is old but still
works!) you get both -man and -mdoc macros, and you can use grog(1) to
choose the appropriate one automagically according to the contents of
the manpage file. I have a simple man(1) shellscript (adapted from the
one in Steve Bourne's "The Unix System") which runs grog on the
appropriate file - I could post it if there's interest. Originally, I
tried to get the -mdoc macros from 386BSD running with cawf, but that
was beginning to look non-trivial. Of course, using groff/grog is
slower than cawf.
--
Scott Telford, Edinburgh Parallel Computing Centre, <s.te...@ed.ac.uk>
University of Edinburgh, Mayfield Rd, Edinburgh, EH9 3JZ, UK. (+44 31 650 5978)
Nick Ruprecht
>BINaries? I first saw 'sbin' on SunOS, which I understood to be SysV
>style bins. SVR4 seems to have kept 'sbin' just to make things
No, it's not. It's an attempt to move binaries out of /etc.
>/usr/bin:
>/usr/lib:
> I would propose a different "standard" and use these
>directories to put symbolic links to startup binaries in
>subdirectories for multi-executable program sets. smail is a good
>example of this, with /usr/bin/smail now being a link to
>/usr/bin/mail/smail. (OK... Call it /usr/bin/sendmail)
>/usr/lib/smail containing support files for the mail utils.
This sounds like a reasonable idea. In order to make version switches
easy, /usr/bin/mail/smail might even be a link to /usr/bin/mail/smail-12.34
(or whatever is the current version), so changing that link will cause
everything (bin, man, libs) belonging to one package to be updated
simultaneously.
>This adds confusion. We should attempt to add flags to support both
>BSD and SYSV syntax in one program.
The sad truth is that options to some commands have opposite meanings
in different versions, e.g. "-g" means "no groups for long listings"
under SysV ls and "show groups" under BSD ls. B^(
Have a nice weekend -
Matthias Urlichs
imcc...@cs.ucsd.edu (Ian McCloghrie) writes:
>
> First off, /sbin is not for statically linked binaries.
> /sbin is for SYSTEM binaries, and is intended to take binaries
> out of /etc.
Good idea.
Actually, I like the new BSD setup -- compiled stuff is in /usr, setup is in
/etc, transient files are in /var, things like dictionaries, macro files,
manpage templates, fonts, ... are in /share.
This cuts through a whole lot of accumulated cruft, though admittedly it has
its share of backwards-compatibility problems -- your sendmail.cf is unlikely
to be in /usr/lib and your mail certainly isn't in /usr/spool.
--
Matthias Urlichs -- url...@smurf.sub.org -- Phone: NONE; use email or lose.
Schleiermacherstrasse 12 -- 90491 Nuernberg -- Germany || Linux+Mac Consulting
David W. Summers
>No flames, just honest questions:
>
>In article <263bc7$m...@news.aero.org> elk...@aerospace.aero.org (Michael Elkins) writes:
>>In article <263a6k$2...@iskut.ucs.ubc.ca>,
>>John Paul Morrison <jmor...@rflab.ee.ubc.ca> wrote:
>>>/bin
>>I personally vote for /sbin and /usr/sbin. But I'd like to see them be
>>something that is optional. Some people are of the opinion that a rather
>>large subset of progs should be statically linked, others are not (me being
>>one; i have no static links on my system)
> ^^^yes, the fewer of them damned links the better!
>
>Why sbin rather than bin? (Personally, I prefer /bin -- most systems I've
>used don't have an /sbin... what's the history behind /sbin??)
>
>>>/usr/etc
>>> a seperate directory, not a symlink. probably on another filesystem
>>> I hated the SLS /etc/inet setup
>>>
>>>login, write, who: poeigl (possibly getty as well)
>>>init, reboot, shutdown, halt, last, wall: SysV init 2.4
>>>getty, uugetty: gettyps
>>>networking: net-2 (if you are pl10 or higher). setup in /etc and /usr/etc.
>>> patched for shadow passwds where needed.
>
>What's the difference between /etc and /usr/etc? Similar to the
>concept behind /bin and /usr/bin.
>
>>>/usr/ucb: make any sense? (I dont really care for it, but I'd go along
>>> with it)
>
>What's /usr/ucb for?
>On some systems I've seen stuff scattered between /usr/bin and /usr/ucb
>with no real distinction.
>
>I'm of the thought that we should keep things simple.
>Maybe just /etc, /bin, and /usr/bin and maybe axe /usr/etc and /usr/ucb??
>
>I'm fully behind a standard setup for Linux. I'd even like to help!
>
>It drives me crazy to have some programs expect /bin/lpr and others
>expect /usr/bin/lpr... so as a consequence I need to either hunt down
>the darn source and recompile, or ln -s lpr ../usr/bin/lpr!
>
>-Anthony
>
I think the reasoning behind /sbin, /usr/sbin, /etc, /usr/etc, /bin, and
/usr/bin has kind of "melted" in the last few years and is confusing to
people who are used to only one kind of system.
I like the way SunOS does it. The / file system is just for the bare
minimum to get going, including /bin. In this scenario, /sbin is for
statically linked binaries.
IMHO, /etc should ONLY have system configuration files and no binaries. Put
them in /bin or /sbin.
The /usr system should be READ-ONLY, and should be able to be shared across
NFS, and replaceable with another archetecture's binaries.
Symlinks to various places are put at the appropriate places so that on
all machine architectures things look exactly alike.
I know Linux doesn't NEED this but if it is done this way then it would
be trivial to drop in another architecture when the time comes.....just
planning ahead.
It is very instructive to read the SunOS manual describing the various
file systems, directories, etc. It tells WHY they did it that way and,
like I mentioned above makes it trivial to implement multiple architectures.
Just some random comments from the mental bitstream of....
--
"Never under-estimate the bandwidth of a station-wagon
David Summers full of tapes, hurtling down the highway."
d...@engr.uark.edu - Tanenbaum, "Computer Networks"
Carl Schott
|> >> passwd... can we agree to use shadow passwds too?
|> >> (some people are multiuser systems on real, security conscious
|> >> networks. shadow passwds make sense, and it isnt a hassle to
|> >> the single user, no network system )
|>
|> Until shadow breaks old, non-recompiled programs in a fail-safe way,
|> it is totally useless, as it potentially allows root access (put a '*'
|> in the password field to find old, broken prorgams faster).
|>
I couldn't agree more. Leaving password fields empty in /etc/passwd is
just plain stupid and an invitation to big trouble. A special character should
be used in the password field to indicate that a shadow password file
is to be used for the encrypted password. AIX uses a bang(!) for this.
Carl Schott
Nick Holloway
> /sbin is for more than just statically linked copies of cp, ls, rm, etc.
> In the new BSD filesystem standard, /sbin is where all of the executable
> files that used to be in /etc are moved to. So getty, init, fsck,
> login, etc., would all be moved into /sbin.
Does this mean they do not use /usr/etc?
I am setting up my machine (migrating) so that it has configuration
files under /etc, and binaries for such under /usr/etc.
Hopefully, when I get a new disk, I shall set up my root partition to
be as small as possible (it will contain the bare minimum) and have the
rest under a /usr partition.
This means that /sbin is a neccesity, and will contain things such as
init, sh, mount.
I shall take the SunOS route that reckons it is safe enough to mount /
and /usr as readonly at boottime, perform the fsck (which can come off
/usr/etc), then remount rw. If this doesn't work, then I would guess
it would be bootdisk time anyway.
I would guess this would be the route taken by people that have /usr
shared over nfs (so add ifconfig to /sbin also).
--
Nick Holloway | `O O' | al...@dcs.warwick.ac.uk, al...@warwick.UUCP,
[aka `Alfie'] | // ^ \\ | ..!uunet!mcsun!uknet!warwick!alfie
Bill Rielly
>se...@FASECON.ECON.NYU.EDU (Sunando Sen) writes:
>
>Yes, it would simplify the whole story, if we would accept the
>System V R4 directory structure as a quasi standard.
If I remeber correctly, there is a directory structure described in the
Linux System Administration Guide. Why not use that as the "standard"? Or
at least coordinate with its authors so that it can document a standard for
use by software delvelopers.
>The way of packaging should be made similar to SVR4. If binary
>compatibility with SVr4 becomes true, then we _do_ need programs
>like pkgadd/pkgrm to be able to easily install or remove software
>in a SVR4 manner.
I started writing some install scripts using the SLS sysinstall as a start.
I don't see any problem with modifying them to be more of a package maintanace
system.
>
>Further it would be a great idea, as somebody already stated out,
>to create one Linux Standard Distribution (LSD ;-) that only contains
>basic stuff. This would be a good start for all other packages !!!
>It would be a big deal, that *all other packages* would be installable
>by the above mentioned pkgadd utility.
I agree. This can ensure that the basics of the system are where you would
expect them to be (without having a million sys-links all over the place)
I don't think that it would be difficult to have packages installable by a
pkgadd kind of thing either.
>The goal of a LSD distrib should be
>- easy to upgrade
>- therefore not too large
>- installation of basic non conflicting stuff
>
> - kernel
> - C/C++ compiler, header files, libs
> - shared libs
> - Gnu file and binutils
> - support of all known filesystems
> - elvis
> - groff
> - line printer scheduler
> - pkgadd/pkgrm utility
>
>To this LSD (Linux Standard Distribution) there should be
>a source disk available, which contains the sources to all
>programs that belongs to the LSD distribution.
>
Now to add new packages are you suggesting that packages be made to
fit the installation program or an installation utility be designed flexible
enough to handle almost any kind of package (tarfile, source distribution, etc.)
I think that the latter would be better (just what to you really need to know
about a given package anyway?) if just for the sake of robustness(suppose
someone gets lazy and forgets to make that configururation file or whatever).
Considering that most binary packages come as a tar file, I think that this
should be the standard package format, with all inforamtion needed stored inside
as either a README or eqivalent or from the directory structure imbedded in the
file (as is done with sysinstall).
Just my $.02
Patrick J. Volkerding
In a previous article, bi...@fs1.rockefeller.edu (Bill Rielly) says:
>I started writing some install scripts using the SLS sysinstall as a start.
>I don't see any problem with modifying them to be more of a package maintanace
>system.
I didn't see a problem either. :^)
You might as well start over. I did the same thing and had Peter
MacDonald inform me that the scripts are not free, are copyrighted to
SLS, and that modified versions can't be redistributed.
By all means though, feel free to start with the install scripts from
the Slackware boot disk. They work with the same package format, so it
should be easy enough. Make sure to get them from version 1.0.2, because
earlier versions still contained pieces of "forbidden" code.
--
Patrick Volkerding
volk...@mhd1.moorhead.msus.edu
bf...@cleveland.freenet.edu
Kevin Samborn
> Actually, I like the new BSD setup -- compiled stuff is in /usr, setup is in
> /etc, transient files are in /var, things like dictionaries, macro files,
> manpage templates, fonts, ... are in /share.
>
I really like this setup too, however, I think there should be a division between
system-admin, system-user, and 3rd-party (which includes local stuff) binaries.
Perhaps the Depot systems can be used here. This also allows for multiple
architectures. Depot is an architecture that was developed for LISA IV.
Plus that, I suggest the "modules" package for user accounts. This allows for
easy installation of third party software, without modifying user's "login scripts",
eg .bashrc, .login, etc. It is based on Tcl.
Depot is from some people at NIST. I have the paper if anyone is interested.
Modules is from John L. Furlani - john.f...@east.sun.com
kevin
---
kevin samborn
sakura global capital, nyc
sam...@mtkgc.com
Robert W. Brewer
>By all means though, feel free to start with the install scripts from
>the Slackware boot disk. They work with the same package format, so it
>should be easy enough. Make sure to get them from version 1.0.2, because
>earlier versions still contained pieces of "forbidden" code.
There's something called StopALOP available in the BETA/packages
directory on tsx-11 which is supposed to do this. StopALOP is
short for "Stop A Lot Of Problems" and is supposed to be a pretty good
package maintenance/version control/installation script. I haven't
used it much yet, but the docs are promising. I think the Debian
developer is going to use it as his installation system.
-Rob
--
Robert W. Brewer Linux and XFree86: Two great tastes...
Daniel Quinlan
bi...@fs1.rockefeller.edu (Bill Rielly) writes:
> >se...@FASECON.ECON.NYU.EDU (Sunando Sen) writes:
> >
> >Yes, it would simplify the whole story, if we would accept the
> >System V R4 directory structure as a quasi standard.
>
> If I remeber correctly, there is a directory structure described in the
> Linux System Administration Guide. Why not use that as the "standard"? Or
> at least coordinate with its authors so that it can document a standard for
> use by software delvelopers.
First of all, the Linux System Administration Guide is documentation,
not a standard, mind you, even worse it is documentation that is only
in the ALPHA stage.
Second, it only explains how to work with the broken standard
filesystem arrangement that substandard packages like SLS utilize.
Third, it is not comprehensive (in terms of naming all standard
directories).
Fourth, a single person wrote most of it, seemingly to help people to
work with SLS (and exclude other better releases). It even goes so
far to document to poorly documented SLS that it names SLS specific
(i.e. utterly nonstandard) directories. If people used MCC (with
excellent (wonderful!) documentation and installation directions) this
guide would not even be required.
Fifth, there is a group of people (administrators, users, and
developers) and so on already working on a file standard to be used.
The FSSTND channel of the Linux-activists mailing list is conducting
an extensive attempt to find solutions to the many problems of Linux
not having a file system standard. If you wish to join, we welcome
input, but we ask that you not flame or post without knowing what is
going on. Discussion has been going on for a long time and most
topics have been discussed. The eventual product of the group will be
a standard (voluntary, of course) for developers to follow.
Now, before you flame me, I do wish to say that the SAG is a very
excellent piece of documentation that will really help people run
their systems. Lars Wirzenius and everyone else of the LDP has done a
great job helping SLS do the job they could not.
You may wish to know that I am coordinating the compilation and
writing of the FSSTND's first draft of the filesystem standard (which
is not ready for public release quite yet, no ALPHA's here folks,
sorry) so if you have any questions or flame me for not liking SLS, I
would be very happy to answer anyone through email.
Dan
--
--------------------------------
Daniel Quinlan
qui...@spectrum.cs.bucknell.edu
Mike Jagdis
ZE> jpm>If you put BSD manpages in with other man pages, your man pages wont
ZE> jpm>look right when formatted.
ZE> I noticed that this morning :( Is there anything I can do
ZE> about it? Does anyone
ZE> have a super duper BSD to Linux man page conversion perl
ZE> script?
If you are using groff then you'll find that -mandoc works for more things
than -man.
man and xman generally invoke 'nroff -man'. With groff nroff is a shell
script. I changed mine to trap a -man argument and replace it with a -mandoc
before calling groff itself. It's that simple :-).
Mike
Mike Jagdis
WL> Until shadow breaks old, non-recompiled programs in a fail-safe way,
WL> it is totally useless, as it potentially allows root access (put a '*'
WL> in the password field to find old, broken prorgams faster).
Nonononono. Shadow *does* lock out the password field of /etc/passwd. SLS
might not but that's just SLS...
WL> >I'd agree, once someone actually claims that everything I want to be
WL> >running will work ok (and be secure) under the shadow stuff.
It's easy to fix. There are plenty of examples. I've released patches for
xdm, xlock, many of the network daemons. If "distributors" can't manage to
grep for crypt and copy code from half a dozen examples they should have
immediately to hand you've more to worry about than you think :-).
Is there a definitive list of things you want?
WL> I know that rshd needs something done to it to make it secure with
WL> shadow passwords.
That's about the only one of the net-2 programs I missed then. I didn't
think rshd did it's own password checks. I thought it just invoked
/bin/login if the incoming wasn't trusted according to hosts.equiv or
rhosts. The fix is trivial if you have the source :-).
WL> We need to have /etc/rc files that will properly check file
WL> systems before mounting them.
I have this. In fact everyone should have it. Simple inspection of the
bootutils should allow it to be added to just about any setup.
WL> We need to have some way of UPDATING a system w/o wiping the
WL> old configuration.
I have this.
WL> We need to at least set the damn time zone information from
WL> the install script.
I have this.
WL> Net-2 configuration needs to be a little smoother.
I have this too.
WL> I think there should be some way to configure in various packages a
WL> little more easily and elegantly than SLS does now.
And this. It's all in the Purple Distribution. I would put it on an archive
site but I'm on the end of a modem connection on which I pay the bills. So
far exactly two (2) people have shown an interest in it appearing on an
archive site so it hardly seems worth my while.
WL> I think that there should be some set of statically linked
WL> utilities that will save your butt in case of fires.
Now that's where we disagree :-). Use a boot disk. Even if you let LILO boot
a hard disk kernel but point it at a root floppy with root=/dev/fd0. Get in
the habit of thinking three times before doing *anything* as root. If you
have to recover it treat it as a learning experience. Make sure it has
impact :-).
Mike
Andreas Klemm
>In article <1993Sep3.1...@knobel.knirsch.de> and...@knobel.knirsch.de (Andreas Klemm) writes:
>>se...@FASECON.ECON.NYU.EDU (Sunando Sen) writes:
>>
>>Yes, it would simplify the whole story, if we would accept the
>>System V R4 directory structure as a quasi standard.
>If I remeber correctly, there is a directory structure described in the
>Linux System Administration Guide. Why not use that as the "standard"? Or
>at least coordinate with its authors so that it can document a standard for
>use by software delvelopers.
Lars Wirzenious said, that this description is outdated and
no standard. It was a description of *his* system, not a standard
that we are looking for ...
>>The way of packaging should be made similar to SVR4. If binary
>>compatibility with SVr4 becomes true, then we _do_ need programs
>>like pkgadd/pkgrm to be able to easily install or remove software
>>in a SVR4 manner.
>I started writing some install scripts using the SLS sysinstall as a start.
>I don't see any problem with modifying them to be more of a package maintanace
>system.
Not bad ... what do you think about kooperating with the one
who wants to create LSD (Linux Standard Distribution) and Demian ?!
>>Further it would be a great idea, as somebody already stated out,
>>to create one Linux Standard Distribution (LSD ;-) that only contains
>>basic stuff. This would be a good start for all other packages !!!
>>It would be a big deal, that *all other packages* would be installable
>>by the above mentioned pkgadd utility.
>I agree. This can ensure that the basics of the system are where you would
>expect them to be (without having a million sys-links all over the place)
>I don't think that it would be difficult to have packages installable by a
>pkgadd kind of thing either.
Ok.
>>The goal of a LSD distrib should be
>>- easy to upgrade
>>- therefore not too large
>>- installation of basic non conflicting stuff
>>
>> - kernel
>> - C/C++ compiler, header files, libs
>> - shared libs
>> - Gnu file and binutils
>> - support of all known filesystems
>> - elvis
>> - groff
>> - line printer scheduler
>> - pkgadd/pkgrm utility
>>
>>To this LSD (Linux Standard Distribution) there should be
>>a source disk available, which contains the sources to all
>>programs that belongs to the LSD distribution.
>>
>Now to add new packages are you suggesting that packages be made to
>fit the installation program or an installation utility be designed flexible
>enough to handle almost any kind of package (tarfile, source distribution, etc.)
>I think that the latter would be better (just what to you really need to know
>about a given package anyway?) if just for the sake of robustness(suppose
>someone gets lazy and forgets to make that configururation file or whatever).
No. basically it should do what SVR4 tools do. Perhaps with a kind
of compatibility mode to old package format ...
>Considering that most binary packages come as a tar file, I think that this
>should be the standard package format, with all inforamtion needed stored inside
>as either a README or eqivalent or from the directory structure imbedded in the
>file (as is done with sysinstall).
Ok, I'm arguing for svr4 pkg format only for two reasons:
o we want a standard
o we are becoming SVR4 binary compatibility
o SVR4 is a standard, Solaris is SVR4 based and same standard,
would be nice to move Linux forward in this direction
o people wanted a tool to fiz permissions
o since SVR4 pkg utilities _are_ a standard and
do logging of installed files and packages and
do fixing of permissions
it would be great to integrate this tool
as standard,
- perhaps only for LSD (Linux Standard Distrib)
- or maybe only as a separate tool parallel to svr4 binary
compatibility packages
- or in the future for all packages ????
Warner Losh
ja...@purplet.demon.co.uk (Mike Jagdis) writes:
>That's about the only one of the net-2 programs I missed then. I didn't
>think rshd did it's own password checks. I thought it just invoked
>/bin/login if the incoming wasn't trusted according to hosts.equiv or
>rhosts. The fix is trivial if you have the source :-).
It checks to see if there is a password, and if there isn't, it
goes ahead and approves the command.
>WL> We need to have /etc/rc files that will properly check file
>WL> systems before mounting them.
>
>I have this. In fact everyone should have it. Simple inspection of the
>bootutils should allow it to be added to just about any setup.
Where can I get them? I've hacked my /etc/rc files to do the right
thing for my system, but it needs to be default.
>And this. It's all in the Purple Distribution. I would put it on an archive
>site but I'm on the end of a modem connection on which I pay the bills. So
>far exactly two (2) people have shown an interest in it appearing on an
>archive site so it hardly seems worth my while.
Please share this with the rest of the world. It does no good to say
"I've got this great distribution, but I won't distribute it. If it
is as good as you say it is, then it might be worth it. Heck, if you
send me disks/tape, I'll be happy to give it a spin and upload it to
whatever archives you'd like.
>WL> I think that there should be some set of statically linked
>WL> utilities that will save your butt in case of fires.
>
>Now that's where we disagree :-). Use a boot disk. Even if you let LILO boot
>a hard disk kernel but point it at a root floppy with root=/dev/fd0. Get in
>the habit of thinking three times before doing *anything* as root. If you
>have to recover it treat it as a learning experience. Make sure it has
>impact :-).
I've been a Unix user for at least 7 years, and have had root access
for most of that time. Things still go wrong, and you do need a few,
choice staticlly linked aps to keep your system sane should something
go wrong. 50k of disk space should be ample for all the things that
I'd like to see (sync, which is one disk block, a simple staticlly
linked ln. mv, cp etc would be nice, but aren't needed).
Warner
--
Warner Losh i...@boulder.parcplace.COM ParcPlace Boulder
I've almost finished my brute force solution to subtlety.
Andreas Klemm
I saw the posting / announcement of this package some time ago.
Certainly great stuff. But I would recommend to use installation
routines that will become de facto standard.
The only package standard, that I know, that will survive the
next years will be the SVR4 Standard. This is standard at SUN
Microsystems and standard of all other verdors which sell
SVR4 based systems and software.
I repeat it again ... If we look towards a Linux SVR4
"binary compatibility" the next logical step would be to
be "package compatible" with SVR4.
For the Linux kind of Installing software there is no clean
standard between the package maintainers ... (I think)
Therefore we are now free to deceide for a wise and promising
step to svr4 pkgadd/.... utilities ....
If I remember right, there is somebody who did it already.
Perhaps he could be so kind and tell us again something
about the status of his project ....
Thanks a lot !
Petter Reinholdtsen
(Andreas Klemm) writes:
>Therefore we are now free to deceide for a wise and promising
>step to svr4 pkgadd/.... utilities ....
>If I remember right, there is somebody who did it already.
>
>Perhaps he could be so kind and tell us again something
>about the status of his project ....
Well, the status of the project is "starting" :-)
We started last week, and I am currently gathering information.
Some people has showed interest, but we have not come so far as to distribute
the
tasks. Interested people can mail me. NO BETATESTERS! We are at pre-pre alpha.
Interested programmers with or without SysVr4 knowledge are welcome. (I had no
SysV knowhow when I started :) )
I'll get back with more info when there is time to betatest.
##> Petter Reinholdtsen <## pet...@stud.cs.uit.no
Zeyd M. Ben-Halim
>In article <1993Sep9.1...@knobel.knirsch.de>, and...@knobel.knirsch.de
>(Andreas Klemm) writes:
>>Therefore we are now free to deceide for a wise and promising
>>step to svr4 pkgadd/.... utilities ....
>>If I remember right, there is somebody who did it already.
>>
>>Perhaps he could be so kind and tell us again something
>>about the status of his project ....
>
>Well, the status of the project is "starting" :-)
>
>We started last week, and I am currently gathering information.
I'm almost finished with pkgproto.c and hope to tackle pkgadd.c
next.
>Some people has showed interest, but we have not come so far as to distribute
>the
>tasks. Interested people can mail me. NO BETATESTERS! We are at pre-pre alpha.
>Interested programmers with or without SysVr4 knowledge are welcome. (I had no
>SysV knowhow when I started :) )
Maybe we should set-up a mailing list or another channel on
linux-activists. I can set-up the list here at netcom if
necessary.
In the meanwhile, my latest efforts can be found on
netcom.com:pub/zmbenhal
>I'll get back with more info when there is time to betatest.
>
>##> Petter Reinholdtsen <## pet...@stud.cs.uit.no
--
Zeyd M. Ben-Halim zmbe...@netcom.com
10479 1/4 Santa Monica Blvd, LA, CA, 90025 (310) 470-0281
Mike Jagdis
[rshd...]
WL> It checks to see if there is a password, and if there isn't,
WL> it goes ahead and approves the command.
Ah! That would explain why it escaped the crypt() hunt :-). Does this imply
that there is only a problem with those broken versions of SLS which,
apprently, leave the password field blank rather than locking it in
/etc/passwd?
WL> >And this. It's all in the Purple Distribution. I would put it on an
WL> archive
WL> >site but I'm on the end of a modem connection on which I pay the bills.
WL> So
WL> >far exactly two (2) people have shown an interest in it appearing on an
WL> >archive site so it hardly seems worth my while.
WL> Please share this with the rest of the world. It does no good to say
WL> "I've got this great distribution, but I won't distribute
WL> it.
I never said that. In fact I *do* distribute it, particularly within the UK
FidoNet community.
WL> If it is as good as you say it is, then it might be worth it.
I never said it was particularly good either :-). If having all these
(essential) "features" that people keep mentioning make it "good" so be it.
I know where the bugs are though :-).
This distribution thread seems to have an excessively high
manager-to-worker ratio, however since I've now had almost a whole *half
dozen* expressions of interest from the Internet side I'll see about
uploading it somewhere. Or at least some of it...
Mike