Subject: straightening out NFS

From: Rick Hawkins <[email-masked]>
Date: Wed, 12 Jun 1996 12:26:35 CDT

I can't quite get nfs going for some reason.  I had it going quickly
under the 1.2 kernel (i have 2 machines sitting here).

I uncommented everything in /etc/init.d/netstd_nfs.  I added / to
exports.  I added ALL: .iastate.edu to hosts.allow.

ANd the two machines give me different errors  . . .

trying to mount from one, 

# mount -t nfs 129.186.31.38:/ /server/
mount clntudp_create: RPC: Program not registered

THe other (the .38 machine)  reports during boot that 
/etc/init.d/rc: /etc/rc2.d/S25netstd_nfs: permission denied.

however, it will mount .40's file system without complaint.
Unfortuneately, it is the other direction that is important . . .

What i need to figure out, in addition to getting them talking, is the
turning of one into a server for the other.

WHen these machines start getting replaced, we'll be able to grab them
for grad students as linux boxes as xterminals.  THey'll generally be
8mb (after cannibalizing another, or buying 4mb).  SOme (most?) will get
a second 80mb drive.

SO I need to come up with a base configuration that gets 16mb of swap,
and installs x in the remainder, followed by an allocation for the next
80mb that adds more useful stuff, followed by finding the rest on the
file system.

SO i need to configure paths so that both the second drive & the file
server mount into the original structure.  I'm not qiiiite sure how to
do this.  Can I mount another device as read only into the original file
system? 

And has anyone ever dealt with mounting AFS (mit's athena) to interact
with our worksations file system?

Finally, we have departmental servers for our dos/windows machines.
would mounting these be practical?  it seems possible somehow from the
kernal configuration questions.

which leaves the miscellaneous piece: how would i install packages into
a non-standard place (ie, the server?).

------- End of Forwarded Message

---

From: Craig Sanders <[email-masked]>
Date: Sat, 15 Jun 1996 16:27:58 +1000 (EST)

On Wed, 12 Jun 1996, Rick Hawkins wrote:

> # mount -t nfs 129.186.31.38:/ /server/ mount
> clntudp_create: RPC: Program not registered

I saw something very much like this on my home network after upgrading
all my linux machines to debian 1.1.

Even though I had an "ALL: .taz.net.au" in my /etc/hosts.allow, it still
didn't work until I fixed it by putting

portmap: 192.88.6.32/255.255.255.224

in /etc/hosts.allow (this specifies my class c subnet)

This is actually documented in /usr/doc/net/portmapper.doc.gz.  Here's
the relevant text (but read that file for full details of what's going
on!):

    By default, host access control is enabled. However, the host that
    runs the portmapper is always considered authorized. The host access
    control tables are never consulted with requests from the local
    system itself; they are always consulted with requests from other
    hosts.

    In order to avoid deadlocks, the portmap program does not attempt to
    look up the remote host name or user name, nor will it try to match
    NIS netgroups. The upshot of all this is that only network number
                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    patterns will work for portmap access control.
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

    Sample entries for the host access-control files are:

        /etc/hosts.allow:
        portmap: your.sub.net.number/your.sub.net.mask
        portmap: 255.255.255.255 0.0.0.0

        /etc/hosts.deny
        portmap: ALL: (/some/where/safe_finger -l @%h | mail root) &

> /etc/init.d/rc: /etc/rc2.d/S25netstd_nfs: permission denied.

it's probably not executable. check the permissions on the file
(remember that /etc/rc2.d/S25netstd_nfs should be a symlink to
/etc/init.d/netstd_nfs ... check the perms on the file, not the link)

Craig

---

From: Rick Hawkins <[email-masked]>
Date: Sat, 15 Jun 1996 11:47:42 CDT

[all kinds of useful info . . . ]

> /etc/init.d/netstd_nfs ... check the perms on the file, not the link)

this was also the case.  there were a handful of files that somehow lost
their execute permissions.

I reinstalled from the latest version of the boot disks, changed the
127.0.0.0 problem, uncommented the daemons, and all was well.

(hmm, how about a utility that runs around the disk, finds these kinds
of parameters, & saves them, so it can fix evil happenings later?  If i
knew enoght, i'd write one . . .)

---

From: Craig Sanders <[email-masked]>
Date: Sun, 16 Jun 1996 14:00:24 +1000 (EST)

> knew enoght, i'd write one . . .)

tripwire (which is available as a debian package) may be able to do some
(possibly most or even all) of what you need.

it's usually used as an automated way of monitoring changes to specified
files, with particular attention paid to setuid programs, etc. helps
keep an eye on the system to check if malicious users are hacking the
system and installing setuid root binaries in obscure directories.

You might be able to use it to monitor, e.g., all the scripts in
/etc/init.d/ for execute permission, and pipe the output into a script
which forces the right permissions.

Hmmmm..I vaguely recall that there IS a program to do what you want...i
might have seen an announcement of it in comp.os.linux.announce a year
or so ago.  Check the c.o.l.a archives or the linux software map.
No details, I don't even recall a name.  You're on your own.  Happy
hunting.

Craig