Horton

Thread

  1. Re: [HACKERS] make install fails in perl5 ...

    Tom Lane <tgl@sss.pgh.pa.us> — 1998-10-27T16:27:24Z

    The Hermit Hacker <scrappy@hub.org> writes:
> So, who took the root check out, and when, and why?  

Well, I didn't do it, but I agree with whoever took it out.  You cannot
test at *configure* time to see whether the invoker of configure is
root.  It is not reasonable to expect people to do the configure and
build as root, even if they su to root for the install step (which
is surely the WRONG thing for a Postgres install anyway!)

I wouldn't care for a test on rootness even if it were done at the right
time, ie, install step.  That's an entirely unwarranted assumption about
how people set up their file ownership.  (For example, on my machine the
Perl5 tree belongs to user "gnu", not root.)  A more useful test would
be whether you have write permission on the Perl5 install tree top-level
directory, but that seems to require knowing where the Perl5 install
tree *is*, a fact that's buried inside the Perl-generated makefile.

Maybe we could modify src/interfaces/Makefile along this line:

install-perl5:
	$(MAKE) -C perl5 clean
	cd perl5 && POSTGRES_HOME="$(POSTGRESDIR)" perl Makefile.PL
	if test -w `PERL-LIB` then
		$(MAKE) -C perl5 install
		rm -f perl5/Makefile
	else
		echo "Postponing Perl install, don't have permissions."
		echo "To install, cd into interfaces/perl5, su to Perl"
		echo "file owner, and do 'make install'."
	fi

where PERL-LIB is some sed hackery to extract the PERL_LIB
definition from the just-built perl5/Makefile.

If you like this I will see what I can do with the idea.

We'll also need to discuss this whole business in the INSTALL
directions.

			regards, tom lane

  2. Re: [HACKERS] make install fails in perl5 ...

    Vince Vielhaber <vev@michvhf.com> — 1998-10-27T16:47:55Z

    On Tue, 27 Oct 1998, Tom Lane wrote:

> The Hermit Hacker <scrappy@hub.org> writes:
> > So, who took the root check out, and when, and why?  
> 
> Well, I didn't do it, but I agree with whoever took it out.  You cannot
> test at *configure* time to see whether the invoker of configure is
> root.  It is not reasonable to expect people to do the configure and
> build as root, even if they su to root for the install step (which
> is surely the WRONG thing for a Postgres install anyway!)

Hmmm.  That's how I do it, although it *is* a PITA to chown everything
to do the regression tests.  It just seems odd to have one package
install this way when all the other packages I install are done from
root.

Vince.
-- 
==========================================================================
Vince Vielhaber -- KA8CSH   email: vev@michvhf.com   flame-mail: /dev/null
       # include <std/disclaimers.h>                   TEAM-OS2
   Online Searchable Campground Listings    http://www.camping-usa.com
       "There is no outfit less entitled to lecture me about bloat
               than the federal government"  -- Tony Snow
==========================================================================

  3. Re: [HACKERS] make install fails in perl5 ...

    Thomas Lockhart <lockhart@alumni.caltech.edu> — 1998-10-27T17:07:01Z

    > Maybe we could modify src/interfaces/Makefile along this line:
<snip> 
> We'll also need to discuss this whole business in the INSTALL
> directions.

This would be OK, but imho it would be acceptable to omit the perl
installation stuff from "make install" altogether. Then do the su to
root and install explicitly.

Or, have an "install-root" or somesuch in top level makefile to have a
catchall place for it.

So,

  make install
  su
  make install-root

or something like that.

Per my recent e-mail, we've also got tcl troubles in the installation...

                   - Tom

  4. Re: [HACKERS] make install fails in perl5 ...

    Thomas Lockhart <lockhart@alumni.caltech.edu> — 1998-10-27T17:23:38Z

    > Hmmm.  That's how I do it, although it *is* a PITA to chown everything
> to do the regression tests.  It just seems odd to have one package
> install this way when all the other packages I install are done from
> root.

There is a security exposure to running the server as root. Other
packages can make their own security arrangements; this is ours.

My commercial Ingres package didn't run as root either.

                  - Tom

  5. Re: [HACKERS] make install fails in perl5 ...

    Vince Vielhaber <vev@michvhf.com> — 1998-10-27T17:31:51Z

    On Tue, 27 Oct 1998, Thomas G. Lockhart wrote:

> > Hmmm.  That's how I do it, although it *is* a PITA to chown everything
> > to do the regression tests.  It just seems odd to have one package
> > install this way when all the other packages I install are done from
> > root.
> 
> There is a security exposure to running the server as root. Other
> packages can make their own security arrangements; this is ours.

I understand that, and I *don't* run it as root, I only install it
as root.  After it's installed I chown it to postgres which is what
many other packages do.  I also do everything from /usr/local/src/
instead of /usr/src.  IMO, /usr/src is no place for users to be
putting or building files. It's also alot easier to back up the local
tree and be done with it.  But these are just my preferences.  If
someone else wants to build it in / that's their business.

Vince.
-- 
==========================================================================
Vince Vielhaber -- KA8CSH   email: vev@michvhf.com   flame-mail: /dev/null
       # include <std/disclaimers.h>                   TEAM-OS2
   Online Searchable Campground Listings    http://www.camping-usa.com
       "There is no outfit less entitled to lecture me about bloat
               than the federal government"  -- Tony Snow
==========================================================================

  6. Re: [HACKERS] make install fails in perl5 ...

    Thomas Lockhart <lockhart@alumni.caltech.edu> — 1998-10-27T18:21:54Z

    > I understand that, and I *don't* run it as root, I only install it
> as root.  After it's installed I chown it to postgres which is what
> many other packages do.  I also do everything from /usr/local/src/
> instead of /usr/src.  IMO, /usr/src is no place for users to be
> putting or building files. It's also alot easier to back up the local
> tree and be done with it.  But these are just my preferences.  If
> someone else wants to build it in / that's their business.

Sorry about that. I agree with you completely (I may even agree with you
more than you do! :)

I do a _lot_ of postgres building, since developing the server is one of
my hobbies. istm it is much cleaner to do everything out of
/opt/postgres, owned by postgres (as opposed to scattering things below
/, which as you point out can be a mess). I put the builds into
directories like v6.3.2 or 981014.d, then point to one with a softlink
/opt/postgres/current. Then nothing needs to happen as root for months
on end, and I can switch between versions in a minute or two if
necessary.

I'm not sure what the current thinking is on the /opt concept wrt the
newer file system conventions being negotiated between Unices...

                    - Tom

  7. Re: [HACKERS] make install fails in perl5 ...

    Brook Milligan <brook@trillium.nmsu.edu> — 1998-10-27T18:23:33Z

       Well, I didn't do it, but I agree with whoever took it out.  You cannot
   test at *configure* time to see whether the invoker of configure is
   root.  It is not reasonable to expect people to do the configure and
   build as root, even if they su to root for the install step (which
   is surely the WRONG thing for a Postgres install anyway!)

Installing as root is fine; running as root is not.

   I wouldn't care for a test on rootness even if it were done at the right
   time, ie, install step.  That's an entirely unwarranted assumption about
   how people set up their file ownership.  (For example, on my machine the
   Perl5 tree belongs to user "gnu", not root.)  A more useful test would
   be whether you have write permission on the Perl5 install tree top-level
   directory, but that seems to require knowing where the Perl5 install
   tree *is*, a fact that's buried inside the Perl-generated makefile.

We don't really need to test this.  Use --with-perl if appropriate.
It will automatically find the right stuff via perl.

   Maybe we could modify src/interfaces/Makefile along this line:

No.  Why can't we rely on people using --with-perl correctly to
specify if they do or do not want perl.  The whole point of the recent
run-around with the perl Makefile stuff was so that postgres could be
installed without perl and later someone could do the normal perl
install in that directory.  You get this functionality by running
configure without the --with-perl option and all is well.

What am I missing?

Cheers,
Brook