Ticket History #56: "make install" failures w/ read-only source tree (nfs)

From jhawk@bbnplanet.com Fri Oct 4 04:00:56 1996
Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by rt-11.MIT.EDU (8.7.5/8.7.3) with SMTP id EAA19312 for <bugs@RT-11.MIT.EDU>; Fri, 4 Oct 1996 04:00:56 -0400
Received: from all-purpose-gunk.near.net by MIT.EDU with SMTP
id AA20438; Fri, 4 Oct 96 04:00:55 EDT
Received: (from jhawk@localhost) by all-purpose-gunk.near.net (8.8.0/8.8.0) id EAA04549; Fri, 4 Oct 1996 04:00:53 -0400 (EDT)
Message-Id: <199610040800.EAA04549@all-purpose-gunk.near.net>
Date: Fri, 4 Oct 1996 04:00:53 -0400 (EDT)
From: John Hawkinson <jhawk@bbnplanet.com>
To: krb5-bugs@MIT.EDU
Subject: "make install" failures w/ read-only source tree (nfs)

BBN Planet
System: SunOS all-purpo 4.1.4 4 sun4m
Architecture: sun4


I built kerberos on an NFS filesystem as user "jhawk".
I su-ed to root and did a "make install".

It failed in two ways:

1. ranlib under SunOS attempts to write __.SYMDEF in
the current working directory.

2. Various files were shipped as not world readable in
the distribution, including manpages. root can't read non-
world readable files since root-equiv was not on on the NFS
server for this client machine.

Certainly it's your option not to fix these (well, the 1st one -- it's sort of annoying.
But the competition has no such impedimenta).


./configure
make
su
make install

One would assume you would see these problems under AFS if you su-ed
to root and were careful to ensure that root was in a different PAG
(i.e. no tokens). I don't think people are careful enough about
that, in general. A word to the wise :-)


1. ranlib, either:

(a) Wrap ranlib with a script that cd's to /tmp and then runs /usr/bin/ranlib.
Clearly this is SunOS-specific.

(b) Invoke ranlib with -t, which causes it to merely touch the
destination rather than rewriting the SYMDEF stuff. The SunOS manpage
reads:
OPTIONS
-t ranlib only "touches" the archives and does not modify
them. This is useful after copying an archive or using
the -t option of make(1) to avoid having ld(1) complain
about an "out of date" symbol table.


2. make them world readable. It appears that the permissions are Just Wrong (tm)
in the CVS repository. I'm not sure how they got that way and what needs to be
done to prevent themfrom ending up that way again. Here's a list:

[all-purpose-gunk!jhawk] /usr/planet/src/security/kerberos/dist> tar ztvf krb5.src.B7.tar.gz | grep -v '^....r..r'
-rw-r----- 15806/101 4346 Dec 12 14:32 1995 krb5-beta7/doc/krb5-protocol/3-des.txt
-rw------- 15806/101 446 Sep 10 20:26 1996 krb5-beta7/src/gen-manpages/ChangeLog
-rw------- 15806/101 166 Sep 10 20:26 1996 krb5-beta7/src/gen-manpages/Makefile.in
-rw------- 15806/101 1631 Sep 10 20:26 1996 krb5-beta7/src/gen-manpages/k5login.M
-rw------- 15806/101 4270 Sep 10 20:26 1996 krb5-beta7/src/gen-manpages/kerberos.M
-rw------- 15806/101 19288 Sep 10 20:26 1996 krb5-beta7/src/kadmin/cli/kadmin.M
-rw------- 15806/101 18 Aug 29 16:36 1996 krb5-beta7/src/kadmin/cli/kadmin.local.M
-rw------- 15806/101 7476 Sep 10 20:27 1996 krb5-beta7/src/kadmin/server/kadmind.M
-rw------- 15806/101 670 Sep 10 20:28 1996 krb5-beta7/src/kadmin/v5passwdd/ChangeLog
-rw------- 15806/101 14422 Jul 25 18:29 1996 krb5-beta7/src/kadmin/v5passwdd/adm_rw.c
-rw------- 15806/101 367 Jul 25 18:29 1996 krb5-beta7/src/kadmin/v5passwdd/configure.in
-rw------- 15806/101 8440 Jul 25 18:29 1996 krb5-beta7/src/kadmin/v5passwdd/kadm5_defs.h
-rw------- 15806/101 8202 Jul 25 18:29 1996 krb5-beta7/src/kadmin/v5passwdd/main.c
-rw------- 15806/101 24898 Jul 25 18:30 1996 krb5-beta7/src/kadmin/v5passwdd/proto_serv.c
-rw------- 15806/101 23760 Jul 25 18:30 1996 krb5-beta7/src/kadmin/v5passwdd/srv_net.c
-rw------- 15806/101 1061 Sep 6 18:22 1996 krb5-beta7/src/kadmin/v5passwdd/Makefile.in
-rw------- 15806/101 2987 Jul 22 16:33 1996 krb5-beta7/src/lib/gssapi/krb5/export_sec_context.c
-rw------- 15806/101 2386 Jul 22 16:34 1996 krb5-beta7/src/lib/gssapi/krb5/import_sec_context.c
-rw------- 15806/101 2987 Jul 22 16:34 1996 krb5-beta7/src/lib/gssapi/krb5/inq_names.c
-rw------- 15806/101 2467 Jul 25 02:09 1996 krb5-beta7/src/lib/gssapi/krb5/rel_oid.c
-rw------- 15806/101 16355 Jul 24 20:40 1996 krb5-beta7/src/lib/gssapi/krb5/ser_sctx.c
-rw------- 15806/101 9449 Feb 27 18:53 1996 krb5-beta7/src/lib/gssapi/mechglue/oid_ops.c
-rw------- 15806/101 4216 Sep 6 18:23 1996 krb5-beta7/src/lib/kdb/keytab.c
-rw------- 15806/101 5724 Aug 29 14:32 1995 krb5-beta7/src/lib/krb5/ccache/ser_cc.c
-rw------- 15806/101 9008 Jun 12 01:09 1996 krb5-beta7/src/lib/krb5/keytab/file/ser_ktf.c
-rw------- 15806/101 16554 May 14 04:41 1996 krb5-beta7/src/lib/krb5/krb/ser_actx.c
-rw------- 15806/101 5741 Aug 29 14:38 1995 krb5-beta7/src/lib/krb5/krb/ser_adata.c
-rw------- 15806/101 5745 Mar 13 13:11 1996 krb5-beta7/src/lib/krb5/krb/ser_addr.c
-rw------- 15806/101 10092 Sep 22 21:59 1995 krb5-beta7/src/lib/krb5/krb/ser_auth.c
-rw------- 15806/101 5790 Aug 29 14:39 1995 krb5-beta7/src/lib/krb5/krb/ser_cksum.c
-rw------- 15806/101 18773 May 14 04:41 1996 krb5-beta7/src/lib/krb5/krb/ser_ctx.c
-rw------- 15806/101 7180 Sep 12 12:43 1995 krb5-beta7/src/lib/krb5/krb/ser_eblk.c
-rw------- 15806/101 5764 Sep 12 12:43 1995 krb5-beta7/src/lib/krb5/krb/ser_key.c
-rw------- 15806/101 5373 Aug 29 14:39 1995 krb5-beta7/src/lib/krb5/krb/ser_princ.c
-rw------- 15806/101 7061 Aug 29 14:39 1995 krb5-beta7/src/lib/krb5/krb/serialize.c
-rw------- 15806/101 20101 Apr 30 18:25 1996 krb5-beta7/src/lib/krb5/krb/t_ser.c
-rw-r----- 15806/101 5138 Jan 3 22:31 1996 krb5-beta7/src/lib/krb5/posix/setenv.c
-rw------- 15806/101 5845 Aug 29 14:35 1995 krb5-beta7/src/lib/krb5/rcache/ser_rc.c

From: "Theodore Y. Ts'o" <tytso@MIT.EDU>
To: John Hawkinson <jhawk@bbnplanet.com>
Cc: krb5-bugs@MIT.EDU
Subject: Re: krb5-misc/56: "make install" failures w/ read-only source tree (nfs)
Date: Tue, 29 Oct 1996 13:50:08 -0500

The second problem you reported (mode 400 files in the repository) has
been fixed.

The first one remains an issue, although arguably it's a SunOS bug.

- Ted

State-Changed-From-To: open-closed
State-Changed-By: hartmans
State-Changed-When: Wed Apr 10 15:47:27 2002
State-Changed-Why:
I believe that make install works in the situation described now.
Certainly the permissions on files are correct these days.
We don't support SunOS any more so the ranlib issue is a non-issue.