SLVQC@CUNYVM.BITNET (Salvatore Saieva) (02/27/91)
I recently installed NeXTStep v2.0 and the Unix `w' command no
longer works. (It used to work under v1.0.) Whenever I try to run
w I get the message ``No namelist''. Does anyone know what this
message means? Any ideas why it doesn't work?
Sal.
-------
Salvatore Saieva Internet: slvqc@cunyvm.cuny.edu
Queens College, Academic Computer Center BITNET: slvqc@cunyvm.bitnet
65-30 Kissena Blvd, Flushing, N.Y. 11367 DeskNet: (718) 520-7662
awk, sed, grep, lex, yacc, make, >, <, |,... ``I got the Power!''eps@toaster.SFSU.EDU (Eric P. Scott) (02/27/91)
In article <91057.115121SLVQC@CUNYVM.BITNET> SLVQC@CUNYVM.BITNET (Salvatore Saieva) writes: >I recently installed NeXTStep v2.0 and the Unix `w' command no >longer works. (It used to work under v1.0.) Whenever I try to run >w I get the message ``No namelist''. Does anyone know what this >message means? Any ideas why it doesn't work? w attempts to get a namelist from /mach--this is normally a symbolic link to the $BOOTFILE metalink. If you've booted from od or sd you shouldn't have any problems (unless you mucked with the system files). If you've booted from en or tp the metalink may be invalid--but since you had it working under 1.0, I'm inclined to rule this out. -=EPS=-
nerd@percy.rain.com (Michael Galassi) (02/27/91)
In article <91057.115121SLVQC@CUNYVM.BITNET> SLVQC@CUNYVM.BITNET (Salvatore Saieva) writes: >I recently installed NeXTStep v2.0 and the Unix `w' command no >longer works. (It used to work under v1.0.) Whenever I try to run >w I get the message ``No namelist''. Does anyone know what this >message means? Any ideas why it doesn't work? Sounds like /mach has been striped or something similar. This is not the situation on all 2.0 systems, at least not mine, BUT... I just dialed up my cube at home (2.0/030) and did a 'w', it showed me as idle 15 days on the console, I know I checked my mail this morning, infact, the system's uptime is only ~3 days. Has my time perception gotten warped like all else about me or is this a 'feature'? -- Michael Galassi | nerd@percy.rain.com MS-DOS: The ultimate PC virus. | ...!tektronix!percy!nerd
matthews@lewhoosh.umd.edu (Mike Matthews) (02/28/91)
In article <1991Feb27.154738.26022@percy.rain.com> nerd@percy.rain.com (Michael Galassi) writes: >Sounds like /mach has been striped or something similar. This is not >the situation on all 2.0 systems, at least not mine, BUT... I just >dialed up my cube at home (2.0/030) and did a 'w', it showed me as >idle 15 days on the console, I know I checked my mail this morning, >infact, the system's uptime is only ~3 days. Has my time perception >gotten warped like all else about me or is this a 'feature'? It's a feature... I have no idea why, but the console is never right in the idle time. Once it told me I was idle for about a year and a half. >Michael Galassi ------ Mike Matthews, matthews@lewhoosh.umd.edu (NeXT)/matthews@umdd (bitnet) ------ Law of Selective Gravity: An object will fall so as to do the most damage. Jenning's Corollary: The chance of the bread falling with the buttered side down is directly proportional to the cost of the carpet.
SLVQC@CUNYVM.BITNET (Salvatore Saieva) (02/28/91)
In article <1367@toaster.SFSU.EDU>, eps@toaster.SFSU.EDU (Eric P. Scott) says: > >In article <91057.115121SLVQC@CUNYVM.BITNET> SLVQC@CUNYVM.BITNET > (Salvatore Saieva) writes: >>I recently installed NeXTStep v2.0 and the Unix `w' command no >>longer works. (It used to work under v1.0.) Whenever I try to run >>w I get the message ``No namelist''. Does anyone know what this >>message means? Any ideas why it doesn't work? > >w attempts to get a namelist from /mach--this is normally a >symbolic link to the $BOOTFILE metalink. If you've booted >from od or sd you shouldn't have any problems (unless you >mucked with the system files). If you've booted from en or >tp the metalink may be invalid--but since you had it working >under 1.0, I'm inclined to rule this out. > [Which starts me thinking...] The last time I booted the system it was from OD to build the hard drive (I just installed a Maxtor 8760S no too long ago). Apparently, w was confused as to where to look for /mach. After a quick reboot everything is working fine, including w. Thanks! Sal. ------- Salvatore Saieva Internet: slvqc@cunyvm.cuny.edu Queens College, Academic Computer Center BITNET: slvqc@cunyvm.bitnet 65-30 Kissena Blvd, Flushing, N.Y. 11367 DeskNet: (718) 520-7662 awk, sed, grep, lex, yacc, make, >, <, |,... ``I got the Power!''
dan@gacvx2.gac.edu (02/28/91)
In article <1367@toaster.SFSU.EDU>, eps@toaster.SFSU.EDU (Eric P. Scott) writes: > In article <91057.115121SLVQC@CUNYVM.BITNET> SLVQC@CUNYVM.BITNET > (Salvatore Saieva) writes: >>I recently installed NeXTStep v2.0 and the Unix `w' command no >>longer works. (It used to work under v1.0.) Whenever I try to run >>w I get the message ``No namelist''. Does anyone know what this >>message means? Any ideas why it doesn't work? > > w attempts to get a namelist from /mach--this is normally a > symbolic link to the $BOOTFILE metalink. If you've booted > from od or sd you shouldn't have any problems (unless you > mucked with the system files). If you've booted from en or > tp the metalink may be invalid--but since you had it working > under 1.0, I'm inclined to rule this out. > > -=EPS=- I have the same problem on netboot clients. "w" and "netstat" return "No namelist" programs like "monitor" don't work either. It worked under 0.8 and 0.9. It quit when I upgraded to 1.0. I still see the problem on 2.0. I was told that this is due to NFS maps the UID of root to -1 so that it does not have the same abilities on the network file system as it would on a local file system. The documentation (on-line I think) for 1.0 mentioned a patch that could be entered into the kernal using 'adb' that would give root UID 0 on the network file systems. I was not able to get 'adb' to work on 1.0, and NeXT did not recommend the patch. It bothers me that "netstat" does not work, because it comes in handy. All works correctly on the servers, only the netboot clients show the problem. -- Dan Boehlke Internet: dan@gac.edu Campus Network Manager BITNET: dan@gacvax1.bitnet Gustavus Adolphus College St. Peter, MN 56082 USA Phone: (507)933-7596
bennett@mp.cs.niu.edu (Scott Bennett) (03/01/91)
In article <1991Feb27.172635.132@gacvx2.gac.edu> dan@gacvx2.gac.edu writes: >In article <1367@toaster.SFSU.EDU>, eps@toaster.SFSU.EDU (Eric P. Scott) writes: >> In article <91057.115121SLVQC@CUNYVM.BITNET> SLVQC@CUNYVM.BITNET >> (Salvatore Saieva) writes: >>>I recently installed NeXTStep v2.0 and the Unix `w' command no >>>longer works. (It used to work under v1.0.) Whenever I try to run >>> [text deleted --SJB] > >I have the same problem on netboot clients. "w" and "netstat" return "No >namelist" programs like "monitor" don't work either. It worked under 0.8 and >0.9. It quit when I upgraded to 1.0. I still see the problem on 2.0. I was >told that this is due to NFS maps the UID of root to -1 so that it does not >have the same abilities on the network file system as it would on a local file >system. The documentation (on-line I think) for 1.0 mentioned a patch that >could be entered into the kernal using 'adb' that would give root UID 0 on the >network file systems. I was not able to get 'adb' to work on 1.0, and NeXT >did not recommend the patch. It bothers me that "netstat" does not work, Damned straight they didn't recommend this. Do *not* do this if you ever plan to have your machine connected to any network that extends beyond the walls of your house. The remapping is done for a very good reason and should not be defeated. If UID 0 *were* maintained in such a situation, anyone who had the root password for a machine served by your machine would have unrestricted access to anything on your machine. Given that anyone with a workstation--and keep in mind that workstations are commonly served by other machines via NFS--can boot a workstation in single-user mode, honoring UID 0 across an NFS connection would effectively eliminate *all* security on the serving system and any other machines served by it. Be a good Internet neighbor and don't even dream of doing this sort of thing. If the documentation mentions the zap you describe, then NeXT has slipped up badly by even publishing it. (The people at the NIC would be apoplectic if they saw it.) >because it comes in handy. All works correctly on the servers, only the >netboot clients show the problem. > >-- >Dan Boehlke Internet: dan@gac.edu >Campus Network Manager BITNET: dan@gacvax1.bitnet >Gustavus Adolphus College >St. Peter, MN 56082 USA Phone: (507)933-7596 Scott Bennett, Comm. ASMELG, CFIAG Systems Programming Northern Illinois University DeKalb, Illinois 60115 ********************************************************************** * Internet: bennett@cs.niu.edu * * BITNET: A01SJB1@NIU * *--------------------------------------------------------------------* * "WAR is the HEALTH of the STATE" --Albert Jay Nock (I think:-) * **********************************************************************
eps@toaster.SFSU.EDU (Eric P. Scott) (03/02/91)
In article <1991Feb27.172635.132@gacvx2.gac.edu> dan@gacvx2.gac.edu writes: >I have the same problem on netboot clients. "w" and "netstat" return "No >namelist" programs like "monitor" don't work either. It worked under 0.8 and >0.9. It quit when I upgraded to 1.0. I still see the problem on 2.0. Interesting. I saw that problem in 0.9 and 1.0, but *not* on 2.0. > I was >told that this is due to NFS maps the UID of root to -1 so that it does not >have the same abilities on the network file system as it would on a local file >system. The documentation (on-line I think) for 1.0 mentioned a patch that >could be entered into the kernal using 'adb' that would give root UID 0 on the >network file systems. I was not able to get 'adb' to work on 1.0, and NeXT >did not recommend the patch. I think you're extremely confused. /etc/exports controls who can perform NFS mounts, and what access is permitted. The default setting has uids traverse the network, except "unknown users" and those claiming to be root instead operate with the permissions of "nobody"--uid -2. There are two NFS options that modify that behavior. The first is root. This takes a colon-separated list of hostnames for which uid 0 should be honored. The second is anon--this alters the the uid "unknown" access is granted. There are no kernel patches involved. In article <1991Mar1.010704.25496@mp.cs.niu.edu> bennett@mp.cs.niu.edu (Scott Bennett) writes: > The remapping is done for a very good >reason and should not be defeated. If UID 0 *were* maintained in such >a situation, anyone who had the root password for a machine served by >your machine would have unrestricted access to anything on your machine. >Given that anyone with a workstation--and keep in mind that workstations >are commonly served by other machines via NFS--can boot a workstation >in single-user mode, honoring UID 0 across an NFS connection would >effectively eliminate *all* security on the serving system and any other >machines served by it. You're still not protected from a client masquerading as any other uid and getting owner access to any user's files. What's more valuable? System software that can be restored from original distribution media? Or personal work you "forgot" to back up? The bottom line is that you have to trust _any_ workstation that does NFS mounts. Exporting directories read- only when feasible helps. ROM Passwords help (to the extent that they deter the less-skilled crackers). Telling NeXT you want to see "Secure NFS" a la SunOS in a future release helps. When is it necessary for clients to have root access to / on the server? As far as I can tell, the only thing that breaks without it is the Guided Tour demo. I'm a little worried about having it on NetBoot clients; it does [the equivalent of] a dwrite loginwindow DefaultUser NextTour as root on the server machine. Can you say "race condition?" The really insecure option setting is anon=0 ("anybody I don't know gets root access"). _Network and System Administration_ says you need to use this to run the braindead UserManager application "on any machine on the network." (Then it asks for root's password... what's the POINT???) Stupid, stupid, stupid. This whole GUI mess ("we must hide command-line interfaces at all costs") is getting out of hand. Hey sysadmin wannabes: it's really ok to hit Command-Shift-U to run UserMangler remotely with -NXHost. PublicWindowServer on a client is a heck of a lot less risky than open root access on the server. You heard it here first. -=EPS=-