babu@meap.uta.edu (Dorai Babu) (03/14/91)
I need info. about NFS for Apollo machines. Where can I get the software and is there any problem in installing in Apollo DN3500.
hanche@imf.unit.no (Harald Hanche-Olsen) (03/14/91)
In article <BABU.91Mar13112135@meap.uta.edu> babu@meap.uta.edu (Dorai Babu) writes:
I need info. about NFS for Apollo machines. Where can I get the
software
From you friendly local HPollo dealer, where else?
and is there any problem in installing in Apollo DN3500.
I would not think so. You might have difficulties using it, though.
I seem to remember some discussions in this forum about various NFS
bugs a while back, but didn't follow those threads at the time. Now I
have a question/problem of my own.
Short summary: Problem with a mounted foreign file system. From the
mounting node, only root has access privileges. From other nodes, all
users do, except fror one node where the mount directory does not even
look like a directory.
Read on...
I have mounted a tree from a Sun on one of our Apollos. In the Sun's
/etc/exports file, one line reads
/local/ftp -ro
So I mounted it read only on one of our Apollos:
# /etc/mount -o soft,ro -v ugle:/local/ftp /global/ugle
and as long as I am root on the node that did the mount, OR I am on a
different node, I can cd /global/ugle (or cd //hufsa/global/ugle) and
see the files there just fine (but kind of slow, I think). However,
as an ordinary user on the node that did the mount:
hufsa 136 % ls /global/ugle
insufficient rights (process manager/mapped segment manager)
hufsa 137 % file !$
file /global/ugle
insufficient rights (process manager/mapped segment manager)
Also, on one particular node I get:
tootikki 36 % file //hufsa/global/ugle
//hufsa/global/ugle: nfs_gate
The correct answer is "directory". But from this node the file looks
like an ordinary file, although of an unusual type.
tootikki 38 % cd //hufsa/global/ugle
//hufsa/global/ugle: Not a directory
WHat's going on? Any ideas? (Did I not RTFM well enough? I tried!)
- Harald Hanche-Olsen <hanche@imf.unit.no>
Division of Mathematical Sciences
The Norwegian Institute of Technology
N-7034 Trondheim, NORWAYwjw@ebe.eb.ele.tue.nl (Willem Jan Withagen) (03/16/91)
In article <HANCHE.91Mar14163438@hufsa.imf.unit.no> hanche@imf.unit.no (Harald Hanche-Olsen) writes: =>In article <BABU.91Mar13112135@meap.uta.edu> babu@meap.uta.edu (Dorai Babu) writes: =>Short summary: Problem with a mounted foreign file system. From the =>mounting node, only root has access privileges. From other nodes, all =>users do, except fror one node where the mount directory does not even =>look like a directory. => =>I have mounted a tree from a Sun on one of our Apollos. In the Sun's =>/etc/exports file, one line reads => [delete full description] => Well this is also one of the items discussed in the thread you mentioned. I was the one starting it. I had the problem using NFS from Apollo to Apollo. And only root could really use the connection. My friendly Apollo-rep has even logged into our system, but was not able to find anything strange. It only started be be really strange when after a while the system started behaving like it should :{) (how about self reparing software) I'm convinced it has to do something with rights, but I'm still not able to see where :{ You will also notice (using ps axu) that the owner of the NFSD will change from one user to another, depending on who is the last with a file access. Note that /etc/nfsd does not have any strange rights which would make this possible. (Why not??) Still puzzled, Willem Jan Withagen Eindhoven University of Technology DomainName: wjw@eb.ele.tue.nl Digital Systems Group, Room EH 10.10 P.O. 513 Tel: +31-40-473401 5600 MB Eindhoven The Netherlands
howie@inmet.inmet.com (03/19/91)
We had the problem that only root could access files on an Apollo via NFS. The systems involved were a DN4500 running SR10.2.4 and two HP workstations, a 400s running HP-UX 7.05 and a 345 running 7.0. Whenever anyone other than root attempted to access Apollo NFS files from an HP machine, the HP machine's console would get a message about some sort of "authorization error". Anyone on the Apollo could get to HP-UX files via NFS without trouble. The problem went away when we installed patch "ri.apollo.patch_m0186.v.1.0" on the DN4500. NFS also seems faster now. I also noticed a clever trick being done by something, somewhere: Soft links in the Apollo file system with resolution names that begin with "//..." are replaced by "/apollo/...", so if you mount the Apollo "//" as /apollo, these links USUALLY work.
hanche@imf.unit.no (Harald Hanche-Olsen) (03/20/91)
In article <HANCHE.91Mar14163438@hufsa.imf.unit.no> hanche@imf.unit.no (Harald Hanche-Olsen) writes:
Short summary: Problem with a mounted foreign file system. From the
mounting node, only root has access privileges ... as an ordinary
user on the node that did the mount:
hufsa 136 % ls /global/ugle
insufficient rights (process manager/mapped segment manager)
(/global/ugle is the NFS mounted Sun file system)
David Ward <ward@software.org> has solved this particular mystery for
me: The `node_data/system_logs/nfs_data file needs to be world
writable! Of course that is what you get if you leave ACLs as Apollo
intended, but I am one of those overzealous sysadmins who tried to
close things up. And /usr/adm (or `node_data/system_logs) is one
directory which I have 'chacl -B'-ed. So when I manually mounted the
volume, or perhaps the first time I accessed it, the current umask had
the effect of setting nfs_data's permissions to 755, which ain't good
enough.
Any wonder people are afraid to stomp around in `node_data, tightening
up accesses? I just wonder how many of our "unexplainable" problems
arise from similar sources...
- Harald Hanche-Olsen <hanche@imf.unit.no>
Division of Mathematical Sciences
The Norwegian Institute of Technology
N-7034 Trondheim, NORWAYwjw@eba.eb.ele.tue.nl (Willem Jan Withagen) (03/22/91)
In article <HANCHE.91Mar19222107@hufsa.imf.unit.no> hanche@imf.unit.no (Harald Hanche-Olsen) writes: =>In article <HANCHE.91Mar14163438@hufsa.imf.unit.no> hanche@imf.unit.no (Harald Hanche-Olsen) writes: => => Short summary: Problem with a mounted foreign file system. From the => mounting node, only root has access privileges ... as an ordinary => user on the node that did the mount: => =>David Ward <ward@software.org> has solved this particular mystery for =>me: The `node_data/system_logs/nfs_data file needs to be world =>writable! Of course that is what you get if you leave ACLs as Apollo =>intended, but I am one of those overzealous sysadmins who tried to =>close things up. And /usr/adm (or `node_data/system_logs) is one =>directory which I have 'chacl -B'-ed. => =>Any wonder people are afraid to stomp around in `node_data, tightening =>up accesses? I just wonder how many of our "unexplainable" problems =>arise from similar sources... => Well: living with Apollo's for a while (5 years) it still nags me. The ACL's have always been a mess. Another nice thing is that the systems has this `node_data which is a good thing, But is treated a thrash-can. Why the hell is this essentail nfs_data file in system_logs. ^^^^ The system is swarming with tmp's, why not put it in systmp. Another thing which is in system_logs is proc_dump. I don't consider it a log and I don't think it should be there. It think it's about time that more info is given on what is in \`node_data, what rights are required for the files. What files need to be 'closed'. Eg. can I read other users data by peeking into nfs_data ??? Sorry for flaming, but they don't seem to care and being able to should is good for stress ( so the doctor told, :) ) Cioa, Willem Jan Eindhoven University of Technology DomainName: wjw@eb.ele.tue.nl Digital Systems Group, Room EH 10.10 P.O. 513 Tel: +31-40-473401 5600 MB Eindhoven The Netherlands