Re: Alternate installation paths

[Jens Benecke <jens@xxxxxxxxxxxxxx>]

On Mon, Mar 04, 2002 at 01:20:33AM +0800, Adrian Ho wrote:

> [This is more of a rant, so not everything might make sense. 8-]

OK. :)
 
> On Sun, Mar 03, 2002 at 12:11:43PM +0100, Jens Benecke wrote:
> > A) NFS mounted directories just about always imply NIS or LDAP or
> > whatever to distribute the user IDs as well. Otherwise, NFS doesn't
> > really make much sense.
> The qmail uids are usually considered system-level ones, and thus can
> be expected to change from machine to machine (ie. you're not forced
> to find a single set of available uids across all of your servers).

Of course. You're not forced to have them at all. It's the sysadmins
responsibility.

If *I* were to set up 10 or 100 mail servers, though I would try to keep
them as similar as possible. Anything else only makes the task more
difficult.
 
> > B) 84k	/etc/qmail
> > Even with thousands of domains I don't know how the qmail configuration
> > can get bigger than a few hundred kilobytes, perhaps a megabyte.
 
> When every other program 

No. Not every _other_. _Every_ program is supposed to have
machine-specific, user-global configuration in /etc. Really global data
and configuration files (which usually get overridden on user (~) or
machine (/etc) basis) belong in /usr/share.

> is dumping their config files in the same place?  Does the phrase "the
> straw that breaks the camel's back" sound familiar?

If your root partition is full, you have a problem anyway. Not being
able to enlarge /etc will probably be one of your smallest problems
then. That's why a full root partition is usually the LAST thing that
breaks a properly configured system.
 
> > C) Qmail is one of the very few programs that break the expectation of Unix
> > sysadmins that binaries go in bin,
> Which bin?  /bin?  /usr/bin?  /usr/local/bin?  /opt/bin?  (etc.)

Simple enough. One of the ones that were made for the purpose.

/bin	for programs that are needed for system maintenance, and are
	used by users as well. e.g. ls, cp, echo, grep, ...

/sbin	for programs that are needed to boot, for system maintenance,
	and _NOT_ for users. e.g. fdisk, mkfs, ifconfig, ...

/usr/bin	for programs that are _not_ needed for booting and
		setting up the system (because /usr can be NFS) and are
		used by users. e.g. xemacs, gcc, etc.

/usr/sbin	for non-user programs that are not needed for system
		maintenance / booting. E.g. lpd, smbd, rpm, ...

/usr/local	for stuff you compiled yourself, so that it doesn't
		interfere with the packaging system, or which is
		specific for some systems ("local software"), if /usr
		isn't NFS

/opt		for binary stuff that has its own directory structure, 
		e.g. StarOffice, or commercial software, and that 
		doesn't come in source form. "optional software"
 
> > configuration in etc,
> Which etc?  /etc?  /usr/etc?  /usr/local/etc?  /opt/etc?  (etc.)

There is only one /etc.
 
> > spool and log files in var.
> Which var?  /var?  /usr/var?  /usr/local/var?  /opt/var?  (etc.)

There is only one /var.
 
> Ever seen packages with binaries in /usr/local/bin, config files in
> /etc and state files in /usr/var?

No. I've been using Debian, since 1995. It just doesn't happen here.

I've heard it happen with RPM packages though, that's one reason why I
have abandoned RPM based systems completely. RPM creates more problems
than it solves because (IMHO) it does the task of managing files and
packages only with half a heart. It's not strict enough.
 
> > This makes maintenance harder than needed (e.g. maintaining /etc
> Nothing prevents you from physically storing the files just about
> anywhere you please (check out Bruce Guenter's qmail RPM for
> instance).  That's where symlnks really shine, but you already know

Yes.
 
> OTOH, consider how much work your favorite package management system
> has to do to uninstall or otherwise keep track of a single package
> that was designed to go "splat" across several directories common to
> all the other hundreds of packages on the same system.  A single
> package DB corruption could ruin your whole day...

my problem with every program having its own top level directory can be
summarized by saying "C:\Program Files". 

How long would your PATH, LIBPATH, LD_LIBRARY_PATH, INCLUDE_PATH, and
WHATNOT_PATH have to be if every single one of the (let's see) 1213
packages I have installed currently lived in /var/$PACKAGE,
/opt/$PACKAGE, /usr/$PACKAGE, /$PACKAGE or wherever the author decided
it would be fun to put them.

The problem is that qmail, like just about every other program that
claims similar things, is NOT 100% in /var/qmail: It needs daemontools,
which create a /service tree full of stuff. Or init scripts in
/etc/init.d. It needs uscpi-tcp files in /etc. Extra environment
variables. inittab entries. It may need cron jobs. Special users with
special .qmail files. And so on. 

My point is, when you claim removing /var/qmail to deinstall qmail is
enough, you are wrong, and doing this leaves lots of orphaned files on
the system.
 
> (As an aside, does anyone else find it amusing to see master config
> files that specify the full pathnames to secondary config files?  Such
> things are never necessary with qmail's one-place-for-all-my-things
> approach, as opposed to one-place-for-everyone's-things.)

That's the problem: If this becomes popular, I would not have one, I
would have 1213 place-for-all-my-things. 1213 /usr/$FOO/bin entries in
my PATH. 1213 subdirectories under /usr - or worse, only 609 in /usr,
the rest scattered over /var, /usr/opt, /opt, etc. because author and/or
packager felt like it.

And, additionally, it makes implementing NFS properly impossible. There
are user-specific (~), machine-specific (/etc, /boot), architecture
specific (bin, lib) files, global files (/usr/share, /usr/include), and
so on. If those are grouped together, you can administer a NFS network
with ease. If you need to make each application "network capable"
seperately, like with Windows, you will die before finishing.

It's better to make life easy for 98% of 1213 programs, than for 100% of
1 program. That's what standards are for. Pity we have so many.

> However, qmail isn't just one monolithic program with a single
> configuration file.  When you have multiple programs that have to call
> each other to process a single message end-to-end, it's a Good Thing
> to be assured that each component looks for each of its configuration
> files and its sibling components at a fixed location.

Yes. And other programs have to be able to call qmail. And qmail has to
be able to call other programs. So why not rely on the system to find
them? Call "qmail-queue", and let $PATH figure out where it is. This is
easiest if $PATH is fairly small.
 
> And since that location is cast in stone everywhere in the code, y..

You are considering that all people will run is qmail, on 1000 different
boxes. If that is indeed the case, you are probably right, it is simpler
to install everything in the same place (though why that should be in
/var/, I don't know).

Honestly, though, I've seen more setups with 1000 applications on one
system, than with 1 application on 1000 systems, if you agree to exclude
special cases like GMX or Hotmail, which bake their own bread anyway.
And in cases with 1000 apps on one system a package manager is
mandatory.

And even with 1 app running on 1000 systems, which administrator will
choose 1000 completely different systems? It would be suicide. Choose
1000 identical systems and set them up to mirror each other's setups,
except for strategic configuration files. Much easier, especially if you
can find all configuration in /etc.
 
> It's even more useful if /you/ are the outside help.  Example: Your
> client has /etc/qmail/locals and /usr/local/etc/qmail-locals on his
> Red Hat system, both of whose contents are in the control/locals
> style.
 
> [1] Which one is being read by his qmail setup?

If he didn't screw up completely (in which case I'd tell him to better
run qmail on WinXP, just for kicks): The /etc one by the qmail suite
that was installed by RPM, the /usr/local one by the qmail he compiled
himself.

And if this isn't obvious, there's always strace. Or installing Debian.
;)

> [2] How do you know?

How do you know the old sysadmin hasn't patched qmail2 to read 
	"/home/..               ./.. ./foo"
because he or she thought it would be cool?

> [3] How about for that second virus-filtering qmail installation (in
> /var/qmail2) that the first one forwards incoming mail to?

qmail is the only software I know that needs to be installed several
times to perform certain tasks, or read two different configuration
files. I haven't yet got behind the reason, I'll answer this as soon as
I understood it. I assume it's because someone decided to hard code the
config paths into the qmail binaries, and not making them configurable
via environment or parameters.

> [4] How about the Solaris box next to it, which was set up by a
> grizzled Unix vet who's no longer with the company?

In case he knew what he was doing:

config files in /etc, binaries according to above, logs in /var/log.

In case he didn't, reformat and install from scratch, the box has
probably been rooted anyway.

 
> > This is like the Windows method of giving each program a sepera..
> > ..ole system. That's how 10.000.000 DLL files ended up in
> > /windows/system, because "one directory or file more or less doesn..
> It's funny you mention Windows.  IMO, it's potentially /easier/ to
> manage apps in Windows, 

It is, as long as there are few, and you don't have to uninstall,
reinstall, move or otherwise change the setup. And it is, because
Windows still doesn't have a proper packaging management system that
could do the work for you.

Have you ever been asked by Windows if you want to remove lots of
"shared files"?  So? How the heck should *I* know? That's what a package
manager is for!

Have you ever seen a Windows installation with 1213 or more
"Applications" installed? No? That's why it still "mostly" works.

> and it's structured surprisingly similar to the qmail philosophy.
> Consider an idealized Windows setup (there /are/ apps that do this,
> BTW, but they tend to be small and simple -- like qmail):
 
>   Windows: Uninstall via 'deltree /y "C:Program Files\My Application"'

Which is almost never the case. What about (perhaps automatically
generated) registry entries, DLLs from /windows/system, .ini files in
/windows, configuration files, and so on?

>   qmail:   Uninstall via 'rm -fr /var/qmail'

This is not enough. See above.
 
> Now consider a different setup (and the equivalent qmail one):
> 
>   Windows: All executable files in C:\bin, with all other apps

Wouldn't work, because Windows doesn't have LD_LIBRARY_PATH. DLLs _must_
be in the .EXE directory, the current directory, or /windows/system
(system32?). Pity, actually.

>   Windows: All config info in Windows Registry, with all other apps'
>   qmail:   All config info in /etc, with all other apps'

which, at least here, means that I can save /etc  and a list of
installed packages, and be able to duplicate exactly the same setup on a
second system. If the whole Windows Configuration were saved in the
registry and it weren't such a fragile thing, it would be a good thing
(IMHO).

>   Windows: Must look up pathnames to everything in Windows Registry
>            for multiple configurations

And the alternative is to install everything twice? For 1MB apps like
qmail, this might be feasible but I'd rather set some environment vars
or use different command line parameters than install ANY application
twice.

Why shouldn't you re-use the binary files from one qmail installation in
a second, if you really _need_ two installations? For the second one,
e.g. set $QMAILDIR or whatever, and be happy.

>   qmail:   Must look up pathnames to everything in config files
>            for multiple configurations

otherwise: Must hard code pathnames to everything in the binary? Is that
better?
 
>   Windows: Must rename to resolve namespace collisions (surprises user)
>   qmail:   Must rename to resolve namespace collisions (surprises user)

Why?
 
>   Windows: Uninstall requires pkg mgt system (complex framework)
>   qmail:   Uninstall requires pkg mgt system (complex framework)

Which Windows doesn't have (and therefore _has_ to do these quirks) and
doesn't really need (because in Windows nobody in his right mind would
install thousands of applications on _one_ system).

But Linux and many other Unix systems _do_ have one and the admin has to
know it anyway. Why not use it?
 
> IMO, many (most?) Unix integrators are pushing the second vision, or
> something very close to it.

Which is a Bad Thing(tm). Even MS has realized that and is pushing *.MSI
files (Microsoft Installer), which has surprisingly many similarities to
RPM or DEB file formats, one thing being that MSI files aren't directly
executable (some contain an EXE stub that is capable of displaying an
error message to download an update to the MS Installer at
http://foo.com/bar).
 
> Also IMO, at least two missing components in Windows would make the
> first vision more palatable in that OS environment:
> [1] transparent links (symbolic or otherwise -- /not/ shortcuts)
> [2] LD_LIBRARY_PATH (to address your DLL gripe)

I know. MS has apparently abandoned this because it is "too unixy".
Theoretically, NTFS would have the capability (I've been told). Plus,
this would probably make half of Norton's products meaningless.
 
> > > I have no idea why would you want this directory structure, since
> > > /var/qmail is the best of all.
> > ... only it violates just about every other standard out there.
> "The nice thing about standards -- is that there are so many of them."

See above. :)
 
> You probably won't really understand the impact of that statement
> until you've managed a multi-OS/system cluster that has been growing
> over time.  (Or if you've read <http://cr.yp.to/compatibility.html>.)

If all you have is a mess to start with, there is no basis to build on,
so the best you can do is add to the mess. However if you have a clean
system and a decent packaging system to build on that takes away 90% of
the work, you should use it.

All I need to duplicate my setup (except user data) is a copy of /etc, a
list of packages that were installed, and an installation CDROM. There
are no hidden files, secret packages in non-standard locations or
whatever. This is the case with every FHS-compliant Linux system, and it
makes life really easier.

I don't really *care* where a program installs. What I care about is
that I can expect to mount /usr readonly (as intended), or via NFS, and
that I can safely leave most of /var out of backups, because just about
everything there can be or will be regenerated, and so on.

If there is one application that jumps out of the line, it destroys all
these expectations and makes system maintenance much harder.

IMHO.


PS: I like the calm atmosphere of this discussion. Let's keep it that way.

-- 
mfg, Jens Benecke  /// www.hitchhikers.de, www.linuxfaq.de, www.linux.ms
This mail is an attachment? Read http://www.jensbenecke.de/misc/outlook.html

V: Epson Stylus Color 600, 1440dpi, inkl. 4F+4SW-Patronen
V: MP3-Discman, spielt MP3-CDs und CDA
V: 8/40x TEAC SCSI CD-Writer, kann Überlänge

PGP signature