carlo@electro.UUCP (Carlo Sgro) (01/08/89)
This is being posted for a friend of mine (berner!richard). Please reply to me by E-mail as: 1) we don't receive the xenix newsgroup, and 2) his main feed is the one with the problem (dvlmarv). berner recently upgraded from SCO XENIX 2.3 to 2.3.1 (using HDB UUCP). Since the upgrade, their main news feed has not been able to log in via modem. The background is this ... 1) berner has a 2400/1200/300 modem. dvlmarv has a 1200 baud modem. 2) berner cannot call dvlmarv due to restrictions on dvlmarv's phone line. 3) dvlmarv polls berner regularly. Before the upgrade, there was no problem with connecting. 4) dvlmarv uses Ultrix on a Microvax. The symptoms are: 1) When dvlmarv calls, berner's modem answers. berner sends a BREAK to change to 1200 baud. 2) The login prompt appears. berner responds with their userid. 3) The password prompt appears. berner's attempt to enter their password does not succeed (it appears that everything freezes after the password prompt appears). 4) The connection times out. 5) They do not have accounting on so they cannot tell what berner's system thinks dvlmarv is entering as a userid. They have established that dvlmarv never manages to get logged on. Richard suspects that there may be a problem with getty and parity. They have tried all types of parity with no success (he thinks that the system is ignoring his attempts to change parity). The getty definition file entry is: B1200 HUPCL # B1200 HUPCL SANE IXANY Does anyone have any suggestions as to what the problem/solution might be? -- Carlo Sgro NET POLICE WARNING: .signatures that watmath!watcgl!electro!carlo are too long will be trunc
usenet@cps3xx.UUCP (Usenet file owner) (01/08/89)
Yes it seems to ignore parity changes. What will work, at least with a ordinary login, is to follow the login name with a ctrl-j. After that all is ok. ==larry --------------------------- LARRY SHIELDS UUCP: ...!frith!lunapark!larry P.O. Box 6159 BIX: lshields E. Lansing, MI 48826 Compuserve: 70277, 3677 BBS: lunapark 1200 7-1-E / 2400 8-1-N 24hrs (517) 487-3356 login: bbs
root@mjbtn.MFEE.TN.US (Mark J. Bailey) (01/09/89)
I have never really noticed anyone complaining, so maybe I read the docs
wrong, but the mkuser command (as is packaged with 2.3.x and HDB UUCP)
creates the home directories for uucp logins in /usr/spool/uucp. This is
just what the Version 2 UUCP on earlier Xenix versions have been doing.
In and of itself, there is no problem here. However, I upgraded to
the 2.3.1 and subsequently setup HDB on my system, and everything worked
like a champ...for one day. The next day, *ALL* uucp login attempts from
other sites to my system failed after the password.
I discovered that the home directories created by mkuser in /usr/spool/uucp
had vanished mysteriously. I proceeded to recreate them by hand, and again
everything worked great until the day after. This problem frustrated me for
several days until I by chance examined the uudemon.clean shell script
supplied with HDB. I run it every morning around 4:30am. In stepping through
it, I discovered that the script would delete *ALL* empty directories in
/usr/spool/uucp and also old ones. Since uucp login home directories are
always empty, they were axed every night. I corrected this easily enough
by simply relocating my uucp login home directories to /usr/spool/uucphomes
(an arbitrary location, of course). I also modified the files in
/usr/lib/mkuser/uucp to have all future uucp logins created in the new
spot. Once again, all is well with my uucp world. :-) I will add that
the SCO login does not allow logins of userids that have no existing home
directory. Some flavors of unix have a default directory. SCO's login
just shows a message and promptly returns to login. As the uucp home
directories had been axed, all attempts failed after the password.
It appears to me (whether documented or not) that this is a considerably
devastating problem created by SCO by shipping the release with such a setup.
Again, maybe it is in the docs, if so, I just missed it. But in either
case, I hope this may be of some help.
Mark.
--
Mark J. Bailey "Y'all com bak naw, ya hear!"
USMAIL: 511 Memorial Blvd., Murfreesboro, TN 37129 ___________________________
VOICE: +1 615 893 0098 | JobSoft
UUCP: ...!{ames,mit-eddie}!killer!mjbtn!mjb | Design & Development Co.
DOMAIN: mjb@mjbtn.MFEE.TN.US | Murfreesboro, TN USAclarke@acheron.UUCP (Ed Clarke) (01/09/89)
From article <397@mjbtn.MFEE.TN.US>, by root@mjbtn.MFEE.TN.US (Mark J. Bailey): > (an arbitrary location, of course). I also modified the files in > /usr/lib/mkuser/uucp to have all future uucp logins created in the new > spot. Once again, all is well with my uucp world. :-) I will add that > the SCO login does not allow logins of userids that have no existing home I don't understand why you want to give uucp logins a private home directory. All of my uucp logins have "/usr/spool/uucppublic" as their home directory. This shouldn't cause any problems as far as I can see. Am I missing something? -- Ed Clarke uunet!bywater!acheron!clarke
jbayer@ispi.UUCP (Jonathan Bayer) (01/09/89)
In article <397@mjbtn.MFEE.TN.US> root@mjbtn.MFEE.TN.US (Mark J. Bailey) writes:
=
=wrong, but the mkuser command (as is packaged with 2.3.x and HDB UUCP)
=creates the home directories for uucp logins in /usr/spool/uucp. This is
=just what the Version 2 UUCP on earlier Xenix versions have been doing.
=In and of itself, there is no problem here. However, I upgraded to
=the 2.3.1 and subsequently setup HDB on my system, and everything worked
=like a champ...for one day. The next day, *ALL* uucp login attempts from
=other sites to my system failed after the password.
=
=I discovered that the home directories created by mkuser in /usr/spool/uucp
=had vanished mysteriously. I proceeded to recreate them by hand, and again
=everything worked great until the day after. This problem frustrated me for
=several days until I by chance examined the uudemon.clean shell script
=supplied with HDB. I run it every morning around 4:30am. In stepping through
=it, I discovered that the script would delete *ALL* empty directories in
=/usr/spool/uucp and also old ones. Since uucp login home directories are
=always empty, they were axed every night. I corrected this easily enough
=by simply relocating my uucp login home directories to /usr/spool/uucphomes
=(an arbitrary location, of course). I also modified the files in
=/usr/lib/mkuser/uucp to have all future uucp logins created in the new
=spot. Once again, all is well with my uucp world. :-) I will add that
=the SCO login does not allow logins of userids that have no existing home
=directory. Some flavors of unix have a default directory. SCO's login
=just shows a message and promptly returns to login. As the uucp home
=directories had been axed, all attempts failed after the password.
=
This is a known bug which has been reported to SCO many times. It is
due to be corrected in the next release.
Hello, SCO. Where is the next release???????
--
Jonathan Bayer "The time has come," the Walrus said...
Intelligent Software Products, Inc.
19 Virginia Ave. ...uunet!ispi!jbayer
Rockville Centre, NY 11570 (516) 766-2867 jbayer@ispimanes@marob.MASA.COM (Steve Manes) (01/10/89)
From article <397@mjbtn.MFEE.TN.US>, by root@mjbtn.MFEE.TN.US (Mark J. Bailey): > I discovered that the home directories created by mkuser in /usr/spool/uucp > had vanished mysteriously. > It appears to me (whether documented or not) that this is a considerably > devastating problem created by SCO by shipping the release with such a setup. Hey, it's a *feature*! It's nice having a UUCP demon clean up all those unneeded spool directories, especially if you allow anonymous UUCP logins. Seriously though, the oversight is mkuser's using /usr/spool/uucp/XXX for the /etc/passwd home directory. Most BNU installations just specify a single communal directory with read/write permissions for UUCP, like /usr/spool/uucppublic. This is just to get past 'login'. /usr/spool/uucp directories will still be created as needed as needed. -- Steve Manes Roxy Recorders, Inc. Magpie-HQ BBS UUCP : {rutgers|cmcl2}!hombre!magpie!manes (212)420-0527 Smail: manes@MASA.COM
root@mjbtn.MFEE.TN.US (Mark J. Bailey) (01/10/89)
In article <439@acheron.UUCP>, clarke@acheron.UUCP (Ed Clarke) writes: > From article <397@mjbtn.MFEE.TN.US>, by root@mjbtn.MFEE.TN.US (Mark J. Bailey): > > (an arbitrary location, of course). I also modified the files in > > /usr/lib/mkuser/uucp to have all future uucp logins created in the new > > spot. Once again, all is well with my uucp world. :-) I will add that > > the SCO login does not allow logins of userids that have no existing home > > I don't understand why you want to give uucp logins a private home > directory. All of my uucp logins have "/usr/spool/uucppublic" as > their home directory. This shouldn't cause any problems as far as > I can see. Am I missing something? The issue I am concerned with is not the home directories for uucp logins. I know that that really is trivial. The problem was that "as shipped" from SCO, 2.3.[01] with HDB, had a mkuser setup to create uucp-user home dirs in /usr/spool/uucp as has been the case for 2.2.x xenix versions. Under Version 2 uucp it wasn't a problem, ever. But under HDB UUCP, the uudemon.clean script would wipe out those home dirs STILL created in /usr/spool/uucp by the mkuser command. For me, it is easy enough to change that to somewhere else. uucppublic is a perfect place, however, I have a lot of uucp logins (I prefer a login for every site calling for login record's sake - call it a weakness :-) ), and I simply preferred avoiding the clutter of a slew of empty directories (I use PUBDIR as a pass thur in my local unix network and wanted to keep it free except for traffic). But to get back to my main point, a virgining user, or one who just wants the machine to work within the frame of what is described in the docs, doesn't and shouldn't have to worry about the mkuser command (which IS a convenient way to create uucp logins!) choosing a spot for the uucp login home dir. Not everyone is blessed with instinctive System Administrator qualities such that they ever get around to learning about home directories, etc. I am simply stating that my release, and a client's, were SHIPPED that way, and it was a problem. The solution was to edit /usr/lib/mkuser/uucp/mkuser.defs and set the home directory to PUBDIR (or wherever). I am just saying that many xenix users never would have picked up on that as they simply DON'T WANT to know that much detail. I just felt it needed to be pointed out. I think they are up to 2.3.2, so it may be fixed by now. Mark. -- Mark J. Bailey "Y'all com bak naw, ya hear!" USMAIL: 511 Memorial Blvd., Murfreesboro, TN 37129 ___________________________ VOICE: +1 615 893 0098 | JobSoft UUCP: ...!{ames,mit-eddie}!killer!mjbtn!mjb | Design & Development Co. DOMAIN: mjb@mjbtn.MFEE.TN.US | Murfreesboro, TN USA
jim@tiamat.FSC.COM (Jim O'Connor) (01/10/89)
In article <439@acheron.UUCP>, clarke@acheron.UUCP (Ed Clarke) writes: > I don't understand why you want to give uucp logins a private home > directory. All of my uucp logins have "/usr/spool/uucppublic" as > their home directory. This shouldn't cause any problems as far as > I can see. Am I missing something? The practice of separate home directories parallels the practice of separate login accounts, and is convenient if your uucp neighbors are sending in files. With separate home directories, each acount can uucp to ~account, and have the files show up in separate directories. I used this for a while when we had remote machines sending in daily data files, and it helped eliminate some confusion. Other than convenience, there should be no reason why you can't specify /usr/spool/uucppublic as all uucp account home directories. To re-iterate other's warnings, though: Be careful not to remove this directory when using rmuser to cancel a uucp account. Then all other accounts will not have a home directory and login will complain. --jim ------------- James B. O'Connor jim@FSC.COM Filtration Sciences Corporation 615/821-4022 x. 651
john@jetson.UPMA.MD.US (John Owens) (01/11/89)
Xenix typically uses eight bits, no parity on dialup lines, and the configuration you showed keeps that setup. Most uucicos use 7 bits, even parity by default. Some can be configured to use zero parity (which is equivalent for logging in with 7-bit ASCII characters) with a string like "P_ZERO" in the L.sys file. Worst case, you'll have to pick characters for the remote systems password that have even parity without setting the parity bit, and have him end his password with a newline (\n) instead of a carriage return.... Good luck! -- John Owens john@jetson.UPMA.MD.US uunet!jetson!john +1 301 249 6000 john%jetson.uucp@uunet.uu.net
bill@ssbn.WLK.COM (Bill Kennedy) (01/11/89)
In article <210@tiamat.FSC.COM> jim@tiamat.FSC.COM (Jim O'Connor) writes: >In article <439@acheron.UUCP>, clarke@acheron.UUCP (Ed Clarke) writes: >> I don't understand why you want to give uucp logins a private home >> [ ... ] > >The practice of separate home directories parallels the practice of >separate login accounts, and is convenient if your uucp neighbors are sending >in files. I suggest that this point is moot because HDB includes a script, "uuto" which creates a rather lengthy path that is absolutely unique insofar as the originating site!user and the destination site!user are concerned. Any user at any site can send a file to another user at another site with little risk of file name collision in uucppublic if you stick with uuto. I'm not trying to diminish the utility of separate directories to enable transfers to ~account, but if you can uuto filename site!user, it seems to be as easy as mail (at least to me). -- Bill Kennedy usenet {killer,att,cs.utexas.edu,sun!daver}!ssbn!bill internet bill@ssbn.WLK.COM
jim@tiamat.FSC.COM (Jim O'Connor) (01/12/89)
In article <609@ssbn.WLK.COM>, bill@ssbn.WLK.COM (Bill Kennedy) writes: > In article <210@tiamat.FSC.COM> jim@tiamat.FSC.COM (Jim O'Connor) writes: > >The practice of separate home directories parallels the practice of > >separate login accounts, and is convenient if your uucp neighbors are sending > >in files. > I suggest that this point is moot because HDB includes a script, "uuto" > which creates a rather lengthy path that is absolutely unique insofar as > the originating site!user and the destination site!user are concerned. That's great, and I agree "uuto" is the better solution, but unfortunately not everyone has HDB available. At the time we were running Version 2 uucp, and this method was the simplest available. > I'm not trying to diminish the utility of separate directories to enable > transfers to ~account, but if you can uuto filename site!user, it seems > to be as easy as mail (at least to me). uuto is one of the many great features added in HDB, but unless Altos goes through some big shakedown, us poor soles with Xenix3.4b on the 80286 machines will probably be stuck with Version 2 uucp as long as the machines stay around (which shouldn't be too much longer :-). --jim ------------- James B. O'Connor jim@FSC.COM Filtration Sciences Corporation 615/821-4022 x. 651
davidsen@steinmetz.ge.com (William E. Davidsen Jr) (01/12/89)
I had the same problem, and just hacked the cleanup script to be a
little smarter. I have some non-standard stuff on my system, but you can
do a quick and dirty check by using grep and looking at the status. I
don't remember the name of the env variable with the dirname, but this
is the idea:
grep ":${dirname}:" /etc/passwd || rmdir ${dirname}
--
bill davidsen (wedu@ge-crd.arpa)
{uunet | philabs}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -merick@seismo.CSS.GOV (Rick Adams) (01/12/89)
uuto is a lot older than HDB. I think it goes back to System III or even earlier. At the very least it was on my System V.2 tape. (dont forget the companion uupick)
davidsen@steinmetz.ge.com (William E. Davidsen Jr) (01/12/89)
In article <212@tiamat.FSC.COM> jim@tiamat.FSC.COM (Jim O'Connor) writes: | That's great, and I agree "uuto" is the better solution, but unfortunately | not everyone has HDB available. At the time we were running Version 2 uucp, | and this method was the simplest available. [ stuff ] | uuto is one of the many great features added in HDB, but unless Altos goes I'm sure a lot of people will tell you, uuto came in with SysIII. I just looked in my old December 1984 manual, and there it is. No Revision bars, either. If you don't have uuto you have a UNIX subset, or V7 based system (such as BSD). By the way, I don't really LIKE uuto, I have to get at the files using yet another arcane program with its own command set. -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
jwc@Thalatta.COM (Bill Campbell Guest account) (01/13/89)
In article <1465@cps3xx.UUCP> las@frith.UUCP (Larry A. Shields {runs Lunapark}) writes: >Yes it seems to ignore parity changes. What will work, at least >with a ordinary login, is to follow the login name with a ctrl-j. >After that all is ok. > I have seen this happen because of a problem in /etc/gettydefs. The gettydefs entry consists of five parts separated by the '#' characters. The first is an identifier referenced in /etc/ttys on Xenix systems or in /etc/inittab on sysV, the second sequence is the baud rate... used for login password, the third the baud rate... for use after login, the fourth is the login prompt, and the last is the next gettydefs entry to use (cycles baud rates...). The following two entries cycle between 1200 and 2400 baud. 2 # B1200 HUPCL OPOST CR1 NL1 # B1200 CS8 SANE HUPCL TAB3 IXANY # \r\n@!Login: # 3 3 # B2400 HUPCL OPOST CR1 NL1 # B2400 CS8 SANE HUPCL TAB3 IXANY # \r\n@!Login: # 2 I have messed this up by copying an existing entry to create an entry for a new baud rate, and forgetting to change the baud rate on the second entry so that it changes after you finish the login :-( Another common error is to screw up the last entry which tells getty which entry to use next so that the baud rates don't cycle properly. Bill Campbell.
larry@tapa.UUCP (Larry Pajakowski) (01/13/89)
Uuto is also on the 2.2 286 and 386 versions of pre HDP SCO Xenix. Larry
root@mjbtn.MFEE.TN.US (Mark J. Bailey) (01/14/89)
In article <598@tapa.UUCP>, larry@tapa.UUCP (Larry Pajakowski) writes: > Uuto is also on the 2.2 286 and 386 versions of pre HDP SCO Xenix. > > Larry Yeah, but I think what Jim is talking about is Altos Xenix for the 286. The word 'Altos' represents a completely different ball game. Altos has good equipment, but their PROPRIETARY xenix is *NO* SCO 286. You can't even take binaries from SCO (ie, products of the cc on SCO) and run them on the 286 Altos. Something to do with the header formats being different. While SCO has uuto (and everyone else), it is not at all suprising that Altos would have left them out. No offense to Altos, they just do things differently...there own way. Mark. -- Mark J. Bailey "Y'all com bak naw, ya hear!" USMAIL: 511 Memorial Blvd., Murfreesboro, TN 37129 ___________________________ VOICE: +1 615 893 0098 | JobSoft UUCP: ...!{ames,mit-eddie}!killer!mjbtn!mjb | Design & Development Co. DOMAIN: mjb@mjbtn.MFEE.TN.US | Murfreesboro, TN USA
rac@jc3b21.UUCP (Roger A. Cornelius) (01/16/89)
From article <402@mjbtn.MFEE.TN.US>, by root@mjbtn.MFEE.TN.US (Mark J. Bailey):
- In article <598@tapa.UUCP>, larry@tapa.UUCP (Larry Pajakowski) writes:
-> Uuto is also on the 2.2 286 and 386 versions of pre HDP SCO Xenix.
->
-> Larry
-
- Yeah, but I think what Jim is talking about is Altos Xenix for the 286.
- The word 'Altos' represents a completely different ball game. Altos has
- good equipment, but their PROPRIETARY xenix is *NO* SCO 286. You can't even
- take binaries from SCO (ie, products of the cc on SCO) and run them on
- the 286 Altos. Something to do with the header formats being different.
- While SCO has uuto (and everyone else), it is not at all suprising that
- Altos would have left them out. No offense to Altos, they just do things
- differently...there own way.
-
- Mark.
Altos uses version 3 derived Xenix on the 286 machines as opposed to SCO's
system 5. This is why you can't take binaries directly from one to the
other without mods. If you compile on SCO with the -compat compiler
flag, you can run most binaries on the altos. You can also use SCO's
fixhdr program to modify some binaries so they will run.
As far as Altos' Xenix being no SCO, I totally agree.
Rogerdet@hawkmoon.MN.ORG (Derek E. Terveer) (01/18/89)
In article <212@tiamat.FSC.COM>, jim@tiamat.FSC.COM (Jim O'Connor) writes: > In article <609@ssbn.WLK.COM>, bill@ssbn.WLK.COM (Bill Kennedy) writes: > > I suggest that this point is moot because HDB includes a script, "uuto" > > That's great, and I agree "uuto" is the better solution, but unfortunately > not everyone has HDB available. Yes, but uuto (and its companion uupick) is really a simple shell script that invokes uucp with a somewhat unique destination path. One should, with relative ease, be able to write a much simplified uuto and/or uupick and retain much of the same functionality. derek -- Derek Terveer det@hawkmoon.MN.ORG || ..!uunet!rosevax!elric!hawkmoon!det w(612)681-6986 h(612)688-0667 "A proper king is crowned" -- Thomas B. Costain
allbery@ncoast.UUCP (Brandon S. Allbery) (01/21/89)
As quoted from <402@mjbtn.MFEE.TN.US> by root@mjbtn.MFEE.TN.US (Mark J. Bailey): +--------------- | In article <598@tapa.UUCP>, larry@tapa.UUCP (Larry Pajakowski) writes: | > Uuto is also on the 2.2 286 and 386 versions of pre HDP SCO Xenix. | | Yeah, but I think what Jim is talking about is Altos Xenix for the 286. | The word 'Altos' represents a completely different ball game. Altos has | good equipment, but their PROPRIETARY xenix is *NO* SCO 286. You can't even +--------------- Altos and SCO both get Xenix from Microsoft. My opinion? I can't see how anyone can stand SCO Xenix (well, pre-3.2, at least). (For that matter, I can't see how anyone can stand Intel processors....) ++Brandon -- Brandon S. Allbery, moderator of comp.sources.misc allbery@ncoast.org (soon) uunet!hal.cwru.edu!ncoast!allbery ncoast!allbery@hal.cwru.edu Send comp.sources.misc submissions to comp-sources-misc@<backbone> NCoast Public Access UN*X - (216) 781-6201, 300/1200/2400 baud, login: makeuser
clewis@ecicrl.UUCP (01/21/89)
In article <544@jc3b21.UUCP> rac@jc3b21.UUCP (Roger A. Cornelius) writes: >Altos uses version 3 derived Xenix on the 286 machines as opposed to SCO's ^^^^^^^ >system 5. Xenix may be archaic, but it ain't *that* old! ;-) -- Chris Lewis, Markham, Ontario, Canada {uunet!attcan,utgpu,yunexus,utzoo}!lsuc!ecicrl!clewis Ferret Mailing list: ...!lsuc!gate!eci386!ferret-request (or lsuc!gate!eci386!clewis or lsuc!clewis)