mpd@anomaly.sbs.com (Michael P. Deignan) (05/29/91)
I've tried posting this question to the Opendesktop group, but didn't get a reply, so I'll try something more generic. My /etc/hosts file looks as follows: 127.0.0.1 localhost 192.76.250.1 anomaly anomaly.sbs.com sbs.com 128.120.253.1 idsvax idsvax.ids.com Now, when I start a SL/IP connection between anomaly and idsvax, people on anomaly can telnet fine to idsvax. However, anyone attempting to rlogin/telnet/ ftp to anomaly get an error message. Furthermore, anyone on anomaly who tries to "rlogin localhost" or "rlogin anomaly" get the password prompt, but are then given the same error message. The error is "Bad login user id". I've RTFM, but can't locate a reference to getting rid of this error. Of course, I might have missed it at 3am. MD -- -- Michael P. Deignan / -- Domain: mpd@anomaly.sbs.com / This space intentionally -- UUCP: ...!uunet!rayssd!anomaly!mpd / left blank... -- Telebit: +1 401 455 0347 /
wul@sco.COM (Wu Liu) (05/30/91)
/--mpd@anomaly.sbs.com (Michael P. Deignan) said... | I've tried posting this question to the Opendesktop group, but didn't get a | reply, so I'll try something more generic. | | My /etc/hosts file looks as follows: | | 127.0.0.1 localhost | 192.76.250.1 anomaly anomaly.sbs.com sbs.com | 128.120.253.1 idsvax idsvax.ids.com | | Now, when I start a SL/IP connection between anomaly and idsvax, people on | anomaly can telnet fine to idsvax. However, anyone attempting to rlogin/telnet/ | ftp to anomaly get an error message. Furthermore, anyone on anomaly who tries | to "rlogin localhost" or "rlogin anomaly" get the password prompt, but are | then given the same error message. | | The error is "Bad login user id". | | I've RTFM, but can't locate a reference to getting rid of this error. Of course, | I might have missed it at 3am. \-- I'm not sure if it's mentioned in the doc... Your problem is that TCP on anomaly wasn't started by init. Your inetd process can't have an luid set, or else telnet/rlogin breaks with this error message. The only way to get a process to not have an luid is if you start it during boot (i.e. have init fork it off).
jim@tiamat.fsc.com ( IT Manager) (05/30/91)
In article <12337@scolex.sco.COM>, wul@sco.COM (Wu Liu) writes: > > Your problem is that TCP on anomaly wasn't started by init. Your > inetd process can't have an luid set, or else telnet/rlogin breaks > with this error message. The only way to get a process to not have > an luid is if you start it during boot (i.e. have init fork it off). Let me expand on this a little. What Wu is telling you (and I discovered this myself), is that if you kill "inetd" and restart it while the system is running, the "inetd" process will inherit your "login ID". This causes programs which interface with "login" (e.g. rlogind and telnetd) to break. The solution: 1) reboot the ODT machine. This will cause inetd to be started during "rc" execution, so it will not have a "login ID". 2) When changing inetd.conf on the fly, use inetd's "signal" option to signal the currently running process that a new config file is present. Good luck. ------------- James B. O'Connor jim@tiamat.fsc.com Ahlstrom Filtration, Inc. 615/821-4022 x. 651
wul@sco.COM (Wu Liu) (05/31/91)
I'm forwarding the following for Scott Deardorff, who's got some additional information. Scott's comments follow at the bottom... >/--mpd@anomaly.sbs.com (Michael P. Deignan) said... >| I've tried posting this question to the Opendesktop group, but didn't get a >| reply, so I'll try something more generic. >| >| My /etc/hosts file looks as follows: >| >| 127.0.0.1 localhost >| 192.76.250.1 anomaly anomaly.sbs.com sbs.com >| 128.120.253.1 idsvax idsvax.ids.com >| >| Now, when I start a SL/IP connection between anomaly and idsvax, people on >| anomaly can telnet fine to idsvax. However, anyone attempting to rlogin/telnet/ >| ftp to anomaly get an error message. Furthermore, anyone on anomaly who tries >| to "rlogin localhost" or "rlogin anomaly" get the password prompt, but are >| then given the same error message. >| >| The error is "Bad login user id". >| >| I've RTFM, but can't locate a reference to getting rid of this error. Of course, >| I might have missed it at 3am. >\-- > >[ wul@sco.com (Wu Liu) replies... ] >I'm not sure if it's mentioned in the doc... > >Your problem is that TCP on anomaly wasn't started by init. Your >inetd process can't have an luid set, or else telnet/rlogin breaks >with this error message. The only way to get a process to not have >an luid is if you start it during boot (i.e. have init fork it off). Michael, In addition to Wu's response, I wanted to include an item from our information tools database which also addresses this problem. This database is available to our supported customers online via a machine named sosco. For more info on accessing this database please contact your SCO Customer Service, or Sales Representitive. Regards, Scott Deardorff rlogin or telnet give the error message "bad login user id." KEYWORDS: rlogind telnetd init bad login user id fails error unix RELEASE: SCO TCP/IP Release 1.1 PROBLEM: When using rlogin or telnet to log on to a machine running SCO UNIX System V/386 Release 3.2, the error message "bad login user id" is displayed. SCO UNIX has C2 like security. This error message is caused when login calls setluid(). The problem is that the loginid has already been set because someone (root) did a "tcp stop" followed by a "tcp start." When root logs in, a loginid is automatically set. This loginid is passed on to inetd which passes it on to rlogind or telnetd. rlogind or telnetd exec /bin/login which inherits the previously set loginid. Then login calls setluid() which fails because the loginid is already set. SOLUTION: This error is caused by doing a "tcp stop" followed by a "tcp start." init(M) has the unique property in that it does not have a loginid associated with it. Therefore, when SCO TCP/IP is started by init, there is no loginid associated with the inetd process. The proper method to restart SCO TCP/IP follows: # init 1 (while logged in as root on /dev/tty01) < here all the user processes are killed by "init 1" > Then type CONTROL-d to proceed with normal startup. SEE ALSO: init(M), setluid(S) --- ___________________________________________________________________ The only dumb question is the one you don't ask. Internet : scottd@sco.COM ****STANDARD DISCLAIMER**** UUCP : { uunet, ucbvax!ucscc, decvax!microsoft, sun}!sco!scottd
gws@xensoft.xenitec.on.ca (Geoff Scully) (06/01/91)
>>/--mpd@anomaly.sbs.com (Michael P. Deignan) said... >> [rlogin/telnet problem] >>| >>| The error is "Bad login user id". >>| >>| I've RTFM, but can't locate a reference to getting rid of this error. Of course, >>| I might have missed it at 3am. >>\-- >> >>[ wul@sco.com (Wu Liu) replies... ] >>I'm not sure if it's mentioned in the doc... >> >>Your problem is that TCP on anomaly wasn't started by init. Your >>inetd process can't have an luid set, or else telnet/rlogin breaks >>with this error message. The only way to get a process to not have >>an luid is if you start it during boot (i.e. have init fork it off). > >[Scott Deardorff adds], >Michael, > In addition to Wu's response, I wanted to include an item from >our information tools database which also addresses this problem. >This database is available to our supported customers online via >a machine named sosco. For more info on accessing this database >please contact your SCO Customer Service, or Sales Representitive. > >Regards, > Scott Deardorff > >rlogin or telnet give the error message "bad login user id." > >PROBLEM: When using rlogin or telnet to log on to a machine running > SCO UNIX System V/386 Release 3.2, the error message "bad > login user id" is displayed. > >SOLUTION: This error is caused by doing a "tcp stop" followed by a > "tcp start." init(M) has the unique property in that it does > not have a loginid associated with it. Therefore, when SCO > TCP/IP is started by init, there is no loginid associated > with the inetd process. > > The proper method to restart SCO TCP/IP follows: > > # init 1 > > (while logged in as root on /dev/tty01) > > < here all the user processes are killed by "init 1" > > > Then type CONTROL-d to proceed with normal startup. > >SEE ALSO: init(M), setluid(S) Another option that is available that avoids having to bring a possibly production machine down to single user and back up, is to use inittab's a b and c 'pseudo state' entries to start single shot processes from init. I use this on xenitec for restarting the cron if I have had to kill it off, using the following inittab entry. cron:a:once:/etc/cron So you could set-up something like, slip:b:once:/etc/tcp start to restart tcp after you have manually done a 'tcp stop'. To use these pseudo state entries, use the command 'telinit <state>', or 'telinit b' for the above example for tcp. The nice thing about these pseudo states is that the processes they start are not killed by changing init states, except when going to state 0, 1, or S. Don't forget to also make these changes to /etc/conf/cf.d/init.base if you want them to stick around through rebuilds of the kernel environment. --- Geoff Scully -- XeniTec Consulting Services gws@xenitec.on.ca {watmath, utai!lsuc}!xenitec!gws