One idea, which takes into account the thought that moving the admin commands
out of /usr/bin is a good thing, but moving them into /usr/sbin is bad, and
we want to keep it simple for new people.

Hows about the commands are stored in ~postgres (or whateber you are using
as an admin account). This is obviously configurable with --admin-dir in the
configure script.

This would probably work as:

a ) new admins that arent familiar with a system will likely have . in the
user paths, thus the commands will work

b ) experienced admins can just choose where to install things

						~Michael

Sun, 19 Sep 1999 07:36:08 +0100 (BST)
Michael Simms <grim@argh.demon.co.uk>
Command Locations (was Re: HISTORY for 6.5....)
On Sun, 19 Sep 1999, Michael Simms wrote:
> One idea, which takes into account the thought that moving the admin commands
> out of /usr/bin is a good thing, but moving them into /usr/sbin is bad, and
> we want to keep it simple for new people.
> 
> Hows about the commands are stored in ~postgres (or whateber you are using
> as an admin account). This is obviously configurable with --admin-dir in the
> configure script.

Under RedHat, ~postgres is /var/lib/pgsql, not the _obvious_ /home/postgres. 
No, there needs to be a particular place for such commands.  And /usr/sbin is
THE FSSTND-mandated place (now called the FHS -- www.pathname.com/fhs). Quoting
FHS 2.0:
---------------------------------------
Filesystem Hierarchy Standard

4.7 /usr/sbin : Non-essential standard system binaries

This directory contains any non-essential binaries used exclusively by the system 
administrator. System administration programs that are required for system
repair, system recovery, mounting /usr, or other essential functions should be
placed in /sbin instead. 

Typically, /usr/sbin contains networking daemons, any non-essential administration t
ools, and binaries for non-critical server programs. These server programs are used 
when entering the System V states known as "run level 2" (multi-user state)
and "run level 3" (networked state) or the BSD state known as "multi-user
mode". At this point the system is making services available to users (e.g.,
printer support) and to other hosts (e.g., NFS exports). 

-----------------------
Now, looking into my /usr/sbin, I find two owners -- root, and uucp.  That's
right -- most of the uucp stuff that is not executed except during daemon-time
(uucico, uuxqt, and friends) is in /usr/sbin.  Making the database service
available in "multi-user" mode is a good job for a binary in /usr/sbin.

Now, this is only if PostgreSQL is being installed in an FHS-compliant manner. 
Otherwise, make a /usr/local/pgsql/sbin.

It might be useful to provide an FHS-compliant configure option (hey, it would
make it easier for us packagers ;-)).

> a ) new admins that arent familiar with a system will likely have . in the
> user paths, thus the commands will work

Whoa.  Hold on.  Having '.' in PATH is a _major_ security hole.  It is almost
never a good idea for '.' to be on the PATH.  If you want to go the ~postgres
route, make a bin or sbin dir under ~postgres, and add '~postgres/bin' to PATH
in .profile.

IMHO.

Lamar Owen
WGCR Internet Radio

Sun, 19 Sep 1999 15:17:29 -0400
Lamar Owen <lamar.owen@wgcr.org>
Re: [HACKERS] Command Locations (was Re: HISTORY for 6.5....)
> One idea, which takes into account the thought that moving the admin commands
> out of /usr/bin is a good thing, but moving them into /usr/sbin is bad, and
> we want to keep it simple for new people.

I assume this is only an RPM discussion.  All third party stuff should
go in /usr/local I think.


> 
> Hows about the commands are stored in ~postgres (or whateber you are using
> as an admin account). This is obviously configurable with --admin-dir in the
> configure script.
> 
> This would probably work as:
> 
> a ) new admins that arent familiar with a system will likely have . in the
> user paths, thus the commands will work
> 
> b ) experienced admins can just choose where to install things
> 
> 						~Michael
> 
> ************
> 
> 


-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Sun, 19 Sep 1999 16:54:28 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] Command Locations (was Re: HISTORY for 6.5....)
On Sun, 19 Sep 1999, Bruce Momjian wrote:
> > One idea, which takes into account the thought that moving the admin commands
> > out of /usr/bin is a good thing, but moving them into /usr/sbin is bad, and
> > we want to keep it simple for new people.
> 
> I assume this is only an RPM discussion.  All third party stuff should
> go in /usr/local I think.

You assume partially correctly -- it started out that way.  In the meantime,
the general issue of administrative commands versus user commands arose, and
with it, the administrative man page thingy. 

I state things the way I do because RedHat is shipping PostgreSQL as a piece of
bona-fide Systems software -- fundamentally part of their distribution.  This
changes all the rules -- turns them on end, in reality.  While a FHS-compliant
linux distribution that does not ship PostgreSQL would need PostgreSQL in
/usr/local (after all, an OS upgrade could destroy it if it's installed
elsewhere), RedHat needs it in the FHS-mandated locations, because PostgreSQL
is part of RedHat's OS.  And, I am attempting to maintain a peice that is
shipping as part of their OS -- which gives me a slightly different point of
view from other PostgreSQL developers/maintainers.

More information about the RedHat-ized PostgreSQL install locations is at:
http://www.ramifordistat.net/postgres/build-it/README.rpm.postgresql-6.5.1

Lamar Owen
WGCR Internet Radio

Sun, 19 Sep 1999 17:17:18 -0400
Lamar Owen <lamar.owen@wgcr.org>
Re: [HACKERS] Command Locations (was Re: HISTORY for 6.5....)
> I state things the way I do because RedHat is shipping PostgreSQL as a piece of
> bona-fide Systems software -- fundamentally part of their distribution.  This
> changes all the rules -- turns them on end, in reality.  While a FHS-compliant
> linux distribution that does not ship PostgreSQL would need PostgreSQL in
> /usr/local (after all, an OS upgrade could destroy it if it's installed
> elsewhere), RedHat needs it in the FHS-mandated locations, because PostgreSQL
> is part of RedHat's OS.  And, I am attempting to maintain a peice that is
> shipping as part of their OS -- which gives me a slightly different point of
> view from other PostgreSQL developers/maintainers.

Sure, makes sense.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Sun, 19 Sep 1999 20:02:35 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] Command Locations (was Re: HISTORY for 6.5....)
On Sun, 19 Sep 1999, Bruce Momjian wrote:

> > One idea, which takes into account the thought that moving the admin commands
> > out of /usr/bin is a good thing, but moving them into /usr/sbin is bad, and
> > we want to keep it simple for new people.
> 
> I assume this is only an RPM discussion.  All third party stuff should
> go in /usr/local I think.

I can't agree more...I like things going into /usr/local/pgsql by
default...

Systems Administrator @ hub.org 
primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org 


Mon, 20 Sep 1999 18:40:45 -0300 (ADT)
The Hermit Hacker <scrappy@hub.org>
Re: [HACKERS] Command Locations (was Re: HISTORY for 6.5....)