rbraun@spdcc.COM (Rich Braun) (05/16/91)
The documentation on 'cu' and 'getty' on the RS/6000 doesn't seem to answer the following question: How do I set up my modems so I can dial in and dial out on each of them? The 'getty' doc mentions a '-r' command-line option, but when I put that into inittab I can't log in. It also mentions the fact that a number of parameters such as the device protection mode are stored in the ODM database, about which I know nothing. Can anyone shed some light on this? At this point I've got major resource-contention problems because I can only set up one modem for outgoing 'cu' and 'uucp' use. IBM's response was "take two aspirin and call us in a month": i.e. wait for your 3.1.5 tape and then let us know if the problem still exists. -rich
eravin@panix.uucp (Ed Ravin) (05/16/91)
In article <7532@spdcc.SPDCC.COM> rbraun@spdcc.COM (Rich Braun) writes: >The documentation on 'cu' and 'getty' on the RS/6000 doesn't seem to >answer the following question: > > How do I set up my modems so I can dial in and dial out > on each of them? > >The 'getty' doc mentions a '-r' command-line option, but when I >put that into inittab I can't log in. Try it again, using SMIT to do your dirty work. Use either the "share" or "delay" option under "Login Type" or whatever the menu entry on SMIT is. SMIT calls "chdev" to do this, and there may be some other flag somewhere that needs setting. >It also mentions the fact that >a number of parameters such as the device protection mode are stored >in the ODM database, about which I know nothing. As near as I can tell, this is a lie. I've asked IBM support several times if they can further explain this, and they can't. What I've observed is that when 3003 getty opens the tty port, it sets the protection to 661, meaning that the owner (root) and the group members (system) can access it. If you need a quick and dirty fix, before you get 3005, make "cu" and "uucico" set-GID to system. This has security implications which may or may not bother you, and might also confuse some of the uucp maintenance daemons. 3005 sets the protections to 666 so that everyone can access the tty ports. >Can anyone shed some light on this? Write me if you're having more trouble -- after fixing the protection problem I was able to use bidirectional ports without difficulty. -- Ed Ravin | I'm sorry, sir, but POSTAL REGULATIONS don't allow cmcl2!panix!eravin | PLASTIC tape over PAPER tape and NYLON cord on an philabs!trintex!elr | 86 inch girth to LITHUANIA... +1 914 993 4737 |
rbraun@spdcc.COM (Rich Braun) (05/18/91)
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
robin@pensoft.uucp (Robin Wilson) (05/21/91)
In article <7551@spdcc.SPDCC.COM> rbraun@spdcc.COM (Rich Braun) writes: >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. Ask IBM DEFECT SUPPORT to write an APAR. Ask the person on the line at Level 2 to call me (Robin Wilson, 343-1111 -- in Austin) if they do not understand... In fact, ask to talk to Lucinda Maddin, and tell her I thought this might be a bug. (DON'T ABUSE THIS HELP... OR I'LL SHUT IT OFF QUICKLY!) >Argh. Why can't IBM just get it right? They are human you know... >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.) How true. Do yourself a favor and don't "experiment" or you'll end up re-installing. Just try to live with it until they get the "bug" processed. >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. You can either setup the modem to do speed conversion for you... (ie. you talk to the modem at one speed only, and the modem establishes the conversion required to connect to remote modems at different speeds). Or, you set the "BAUD rate" parameter to "19200,9600,2400,1200" (or whatever). That's right, SMIT allows you do this, and always has... BUT, it didn't work (even though SMIT allowed you to set it this way) until the 3003 update. You will then be forced to send a BREAK character to the serial port to get getty to cycle the speed. BTW, this also works with "Parity" and "Data bits" and "Stop bits"; but they use a funny way to go to it... each entry must match up with a corresponding BAUD rate, parity, stop bits, and data bits entry. For example, setting: BAUD rate 19200,9600,2400 parity none,even,odd data bits 8,7,5 stop bits 1,1,2 Will yield the following tty device characteristics after successive BREAK characters are sent: NO BREAKS: 19200, 8, N, 1 1 BREAK: 9600, 7, E, 1 2 BREAKS: 2400, 5, O, 2 3 BREAKS: (Back to the top). (If you are going to be cycling more than 1 of these settings, it is best to match them up first to first, second to second, and so on... or else you will have one of them wrap to the beginning of its list before the other gets to the end of its, and so on....) +-----------------------------------------------------------------------------+ |The views expressed herein, are the sole responsibility of the typist at hand| +-----------------------------------------------------------------------------+ |UUCP: pensoft!robin | |USNail: 701 Canyon Bend Dr. | | Pflugerville, TX 78660 | | Home: (512)251-6889 Work: (512)343-1111 | +-----------------------------------------------------------------------------+
rbraun@spdcc.COM (Rich Braun) (05/22/91)
Kudos to Rich and Craig of IBM/Austin for responding so quickly to my inquiry. Overnight, I got a bug fix on diskette for this problem; I have yet to test it, but suffice it to say that IBM means it when they say "we're working on it". I have one more public request to make of IBM: Can you make a bug list and a directory of patches available on the Internet somewhere (a la SCO, which maintains a patch archive on uunet), for those sites which want to resolve already-fixed problems prior to getting an update tape? And can you make a periodic posting to this newsgroup about known and fixed bugs? I used to work for DEC's TOPS-10 support group, and would have loved to have a communications medium like this in order to get information out to customers more quickly. This would probably save time and effort on telephone support. -rich