Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!think.com!mintaka!spdcc!rbraun From: rbraun@spdcc.COM (Rich Braun) Newsgroups: comp.unix.aix Subject: Re: CU and getty on a single line Message-ID: <7551@spdcc.SPDCC.COM> Date: 17 May 91 18:59:17 GMT Organization: Kronos Inc., Waltham, Mass. Lines: 33 The U.S. Postal Service finally came to my rescue yesterday and plopped my 3.1.5 upgrade tape on my desk. After many hours, I finally got it up and found that cu and getty work together wonderfully. (The 3.1.1 stuff simply did *not* work, SMIT or no SMIT. I tried every conceivable combination of parameters one could feed into SMIT, prior to hacking with protections and the like.) The only trouble is, getty and uucico don't get along now. Whenever I dial into the system, the /etc/locks file is set up correctly for that terminal port and the /dev/ttyx protection is set to 622. Then, when I log out, /dev/ttyx is set to 662 instead of 666. The revision to 'cu' doesn't mind this, but 'uucico' gives an error code 13 when it encounters this protection. I suppose I could change the ownership code of uucico to root instead of uucp, but this might break something else. Interestingly, when 'cu' exits it sets the protection to 666, regardless of what it was before. So to free up a terminal line which has been locked out by getty, I can briefly run 'cu' on it. Argh. Why can't IBM just get it right? So what's my best solution? Setting the ODM database entry for this terminal so it gets restored to 666 instead of 662, or making uucico setuid to root? (I don't know how to manage the ODM entry, and IBM carefully made this a well-hidden feature of SMIT. It's really not supposed to be necessary to poke around in this, from what I gather.) Just to add another question, how do I set things up so dialup modems can autobaud? The way things are, the baud rate is 2400 and will always be 2400, even if someone tries to connect at 1200 or 9600. SMIT *should* have a selectable feature for autobaud in the TTY menu. It doesn't. -rich