Again this list comes through. I received a total of 7 responses which
mentioned several causes of the problem. With the information provided
I have solved the problem for the present.
THE SOLUTION:
My understanding of how the hosts.equiv and .rhosts mechanism works was
incorrect. It only allows access for users with accounts on _both_ machines.
The Sequent software also added to the confusion by running the remote shell
as the UID of the owner of the print job. This made our analysis of the
problem difficult until it was pointed out by Gregg Siegfried (THANKS Gregg!).
Our solution was to add a user account to the Sun that's identical (yes it
*must* have the same GID too) to the account on the Sequent that we want
to print from. This makes for all kinds of headaches if lots of users want
to print but in this case it's only one user.
I also heard from our Sun tech rep who explained that the job is getting
run as UID 'nobody' and 'nobody' doesn't have permission to do anything. I
gather that the Sun solution would be to change the lpd system (permissions
on spool directories I assume) to allow UID 'nobody' to run the lpr command.
Since it's working I'll leave that for the next time this bites us.
Thanks to the following who responded and for the rest of you for sending
positive karmas my way and/or for not flaming me over such an obvious misuse
of hosts.equiv/.rhosts.
fetrow@biostat.washington.edu (David Fetrow)
rackow@mcs.anl.gov (Gene Rackow)
rel@mtu.edu (Robert E. Landsparger)
kevin@uniq.com.au (Kevin Sheehan)
grs@claircom.com (Greg Siegfried)
danny@ews7.dseg.ti.com (Danny Johnson)
whitener@esy.com (Rpb Whitener)
Kevin Gmyrek
Millipore Corporation
Life Science R,D&E
kjg@millipore.millipore.com
THE RESPONSES: [and my comments]
--------------------------------------------------------------------------------
>From uunet!biostat.washington.edu!fetrow Sat May 8 07:56:32 1993
From: David Fetrow <uunet!biostat.washington.edu!fetrow>
Subject: Re: Hosts.equiv not equiving!
To: kjg@millipore
Date: Sat, 8 May 93 3:31:56 PDT
X-Mailer: ELM [version 2.3 PL11]
Content-Length: 506
First off: Ptx a pretty standard SysV system is not quite true.
It may be a bigger problem than AIX in some ways (but of course
it does its multiprocesing thing very, very well which makes the
inconvenience worth it). Note that I'm not an expert at porting
between platforms.
If you are just worried about lpr why not use some printer system?
An example is ptr from ftp.u.washington.edu.
-- -dave fetrow- INTERNET: fetrow@biostat.washington.edu FAX: 206-543-3286 BITNET: fetrow@uwalocke[Another program wouldn't solve our problem right now. We wanted to ] [stay with the system software if possible. ] -------------------------------------------------------------------------------- >From uunet!mcs.anl.gov!rackow Sat May 8 13:44:16 1993 To: kjg@millipore (Kevin Gmyrek) Cc: rackow@mcs.anl.gov Subject: Re: Hosts.equiv not equiving! Date: Sat, 08 May 1993 08:20:58 -0500 From: Gene Rackow <uunet!mcs.anl.gov!rackow> Content-Length: 285
You should not need them to run the remote shell to get it to print to the sparc. Sequent supports the lpr/lpd stuff in a somewhat indirect, but usable mode. Just configure the print queue on the Sequent to use the lpd interface. Sequent Support should help you if needed.
--Gene [My MIS rep didn't know how setup the Sequent for the Berkeley print mechanism.] [Plus the thought of converting the other couple hundred printers on the ] [Sequent system really acted as a deterrent to changing it. ] -------------------------------------------------------------------------------- >From uunet!mtu.edu!rel Sat May 8 13:44:20 1993 Subject: Re: Hosts.equiv not equiving! To: kjg@millipore Date: Sat, 8 May 93 12:40:51 EDT From: uunet!mtu.edu!rel (Robert E. Landsparger) X-Quote-Cool: Darwin was right, and I'm helping. X-Quote-Orig: Fall behind early, it gives you more time to catch up. X-Wish: I want to run that RABBIT over and over and over and over and over... X-Mailer: ELM [version 2.3 PL11] Content-Length: 1613
Thus spake, Kevin Gmyrek: > > Hi managers: [...] >
On the Sun, there exits a /etc/hosts.lpd that if present will override /etc/hosts.equiv. A problem we ran accross when setting up .rhosts was in /etc/hosts.
[We didn't have a hosts.lpd file. We concentrated on .rhosts instead. ]
/.rhosts: geolabserver.geo root
/etc/hosts 141.219.21.210 geolabserver.geo.mtu.edu geolabsever.geo loghost
This didn't work until we used the geolabserver.geo.mtu.edu in .rhosts since it was the first one in the list for 141.219.21.210 from /etc/hosts. So now we've made sure the first entry in a /etc/hosts line, the the fully qualified host name, and use fqhn's in /.rhosts, /etc/hosts.equiv and /etc/hosts.lpd
[This is very true. We thought we might be having a name lookup problem ] [which we solved by adding both machine aliases in the .rhosts file. ]
If running NIS, check to see that your NIS servers /etc/hosts are setup the same way.
[Not running NIS for this machine but point well taken. ]
I hope this is of some help.
rel -- = Robert E. Landsparger Internet: rel@mtu.edu = Michigan Technological University Bitnet: rel@mtus5 = Department of Geology Office: (906) 487-2167 = 1400 Townsend Drive, MI 49931-1295 FAX: (906) 487-3371 = My comments do not represent those of my employer. -------------------------------------------------------------------------------- >From uunet!fourx.Aus.Sun.COM!ups!kalli!kevin Sat May 8 19:43:20 1993 From: uunet!fourx.Aus.Sun.COM!ups!kalli!kevin (Kevin Sheehan {Consulting Poster Child}) Date: Sun, 9 May 1993 07:23:17 EST X-Mailer: Mail User's Shell (7.1.1 5/02/90) To: fourx!millipore.millipore.com!kjg@fourx.aus.sun.com (Kevin Gmyrek) Subject: Re: Hosts.equiv not equiving! Content-Length: 2195
[ Regarding "Hosts.equiv not equiving!", fourx!millipore.millipore.com!kjg writes on May 7: ]
> Hi managers: [...]
Question 2 says you missed something - all hosts.equiv does is allow a normal user to log in without a passwd if a) they have an account b) they are in hosts.equiv. c) they have the hostname in ~/.rhosts
In addition to /etc/hosts.equiv, each user can have a file ~/.rhosts that controls which machines *they* trust. Root uses only this mechanism (not /etc/hosts.equiv at all), so /.rhosts controls root access.
[EXACTLY we had to add the user running the lp command as it turns out!]
> > 2) Any solutions other than the obvious one of figuring out > which UID the rsh is run at and adding that user to the > SunOS system?
Not really - you could use NIS to save on the admin, but to rsh you need an account visible somehow on both machines.
l & h, kev
Kevin Sheehan kevin@uniq.com.au | Uniq Professional Services Pty Ltd ACN 056 279 335 | Why Not? PO Box 70, Paddington, NSW 2021, (Sydney) Australia | Phone: +61-2-360-7434 Fax: +61-2-331-2572 | -------------------------------------------------------------------------------- >From uunet!claircom.com!grs Mon May 10 10:39:46 1993 Date: Mon, 10 May 93 06:57 PDT From: uunet!claircom.com!grs (Gregg Siegfried) To: kjg@millipore Subject: Re: Hosts.equiv not equiving! Content-Length: 1767
The AT&T (well Sequent, it sounds like) machine could be doing one of two things. Earlier lp spooler software (Pre AT&T SVR3.2) would run the printer interface script as user "lp". In this case, you can just add a user "lp" with the same UID on the Sun, set this id up with the proper rhost file, and things should be jolly.
More likely, and more convoluted to fix, is the post SVR3.2 lp spooler, which runs the printer interface as the user who submitted the print job. Out of the box, this means that everyone who wants to print from the Sequent to the Sun will need an ID on the Sun with an rhosts file setup to allow the sequent access. This, IMO was a grave misfeature of this particular spooling implementation.
[BINGO! We're running SVR 3.2.0 if you believe the MOTD and our software ] [is exactly as you described. It's running with the UID of the person who ] [queued up the job. That was the piece we were missing (we assumed that ] [it was running as root then later as UID 'lp' which were both incorrect! ]
To address this (I'll do my best.. this was a few years ago) I wrote a program that the System V machine uses in its printer interface file that sets the real and effective user ids to "lp" and therefore approach "A" above would work. The program has to be setuid root, of course, and mine had all manner of validations to ensure that it was being used properly, e.g. only from a child of the lp spooler, and could not be used as a general means to rsh from the System V machine to the Sun. This may be what you have to do.
[Very interesting although I`m told that the setuid mechanism is not ] [enabled and/or available on the Sequent software in use. ]
Which of the two lp spoolers you have can be ascertained like this:
If you have the directory /usr/spool/lp/admins/lp, you have the later spooling software. Otherwise, of course, the older stuff.
I'm remembering this from another time and place, so perhaps it is a little rough around the edges, but the major points should still hold.
Another alternative is to port Berkeley lpd to the Sequent, which really wouldn't be a difficult job, and may be available already somewhere.
Gregg Siegfried grs@claircom.com -------------------------------------------------------------------------------- >From uunet!ews7.dseg.ti.com!danny Mon May 10 12:42:28 1993 Date: Mon, 10 May 93 09:59:25 CDT From: uunet!ews7.dseg.ti.com!danny (Danny Johnson) To: kjg@millipore Subject: Re: Hosts.equiv not equiving! Content-Length: 71
keep in mind that hosts.equiv etc. works for user NAMES not id values.
[Thanks. We had to duplicate both the UID *and* the GID on the Sun to get ] [it to work as we expected. ] -------------------------------------------------------------------------------- >From uunet!Esy.COM!whitener Mon May 10 12:43:38 1993 From: uunet!Esy.COM!whitener (STSX - Rob Whitener) Subject: RE: Hosts.equiv not equiving! To: kjg@visage Date: Mon, 10 May 93 10:13:15 CDT X-Mailer: ELM [version 2.3 PL11] Content-Length: 834
Kevin,
I recently had a similar problem. I could not rsh to a local machine, even though that machine was listed in both the ~/.rhosts and /etc/hosts.equiv.
The solution: In ~/.rhosts and /etc/hosts.equiv, you MUST use the hosts' primary entry in the /etc/hosts file, not an alias. For example, if you had the following host entry:
192.100.5.3 sun3 guinan
Your ~/.rhosts and /etc/hosts.equiv must have a sun3 entry. If you had a guinan entry, you would not be allowed access.
Does this make sense? If it doesn't, reply to this and I will try to provide a better explanation.
[Makes perfect sense. There was some confusion about the host name of the ] [Sequent machine which recently changed and caused part of the problem. ]
Rob
-- Robert Whitener Email: whitener@Esy.COM E-Systems, Garland Division Voice: (214) 205-8089 1200 S. Jupiter Road, Garland, Texas 75042 FAX: (214) 272-8144 -------------------------------------------------------------------------------- ** End of responses **
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:07:50 CDT