ldm@texhrc.UUCP (Lyle Meier) (11/28/90)
We have aquired an rs6000. We would like to be able to copy our existing password file over to the system and have it work. (We distribute a master password file to our yp domains, and the RS-6000 should set in a different domain than everyone else). When one copies the password file over one can log in as a user but an error message is created about being unable to set terminal permission and the user is logged off. Trying via telent yields similar results and a message that the connection was closed. A second related question. We have a central administration for uid's. If one creates a user using SMIT how can one set the uid for the user short of going thru the change user mechanism? Thank you for your help.
bware@slate.mines.colorado.edu (Bob Ware 209 Green C 2733987) (11/29/90)
In article <532@texhrc.UUCP> ldm@texhrc.UUCP (Lyle Meier) writes: > > We have aquired an rs6000. We would like to be able to copy our existing > password file over to the system and have it work. (We distribute a ... > If one creates a user using SMIT how can one set the uid for the user > short of going thru the change user mechanism? We recently worked through similar problems. (Just met with IBM people today and made them aware of the problems.) There is no way to set the uid short of the chuser program (or smit). The easiest way to transfer users from a non-RS/6000 system is to write shell a script that will extract the informatin from the old passwd file and then use mkuser, chuser, etc to create the accounts. The encrypted password fields will work ok, but must be added to /etc/secuity/passwd manually, or with a shell script (there is no AIX utility to do it on a batch of accounts). We have a system with a central user data base that contains a record for each user on campus that is allowed to have a login on general campus machines. Local software reads that data base and creates an account on the RS/6000 when the person logs in as 'newuser' and supplies requested information. The software basically does system calls to execute programs like chuser to set up the account. If you are adding a large number of users, watch out for the /etc/group file. Each user MUST be in a named group, but you may not be able to put them all in the same named group. The system gets real sick when a line in /etc/group execeeds 4096 bytes in length (it happened here), so we had to create a number of groups and distribute the users among them. Good luck. Bob Ware, Colorado School of Mines, Golden, Co 80401, USA (303) 273-3987 bware@slate.mines.colorado.edu bware@mines.colorado.edu bware@mines.bitnet -- Bob Ware, Colorado School of Mines, Golden, Co 80401, USA (303) 273-3987 bware@mines.colorado.edu bware@mines.bitnet isis!csm9a!bware
teexand@ioe.lon.ac.uk (Andrew Dawson) (11/29/90)
In <532@texhrc.UUCP> ldm@texhrc.UUCP (Lyle Meier) writes: > ...... When one copies the password > file over one can log in as a user but an error message is created about > being unable to set terminal permission and the user is logged off. > Trying via telent yields similar results and a message that the > connection was closed. We had this problem once. It was caused by a blank line at the top of /etc/group. It may be worth checking for something silly like this. > A second related question. We have a central administration for uid's. > If one creates a user using SMIT how can one set the uid for the user > short of going thru the change user mechanism? This is quite difficult. SMIT seems to allocate uid's on a next free basis. I think there is a file in /etc/security (.ids ???) containing the next number to allocate. You may be able to edit this just before running smit mkuser. -- Andrew Dawson, Computer Centre, University College London, Gower Street, London WC1E 6BT, England. JANET: ccaaand@uk.ac.ucl EARN/BITNET: ccaaand@ucl.ac.uk INTERNET: ccaaand%ucl.ac.uk@nsfnet-relay.ac.uk UUCP: ...!ukc!ucl.ac.uk!ccaaand
jfh@greenber.austin.ibm.com (John F. Haugh II) (11/30/90)
In article <1990Nov29.095750.24464@ioe.lon.ac.uk> teexand@ioe.lon.ac.uk (Andrew Dawson) writes: >In <532@texhrc.UUCP> ldm@texhrc.UUCP (Lyle Meier) writes: >> A second related question. We have a central administration for uid's. >> If one creates a user using SMIT how can one set the uid for the user >> short of going thru the change user mechanism? > >This is quite difficult. SMIT seems to allocate uid's on a next free basis. >I think there is a file in /etc/security (.ids ???) containing the next number >to allocate. You may be able to edit this just before running smit mkuser. I changed the "Add A User" SMIT panel because there were so many requests for this functionality. The "new" answer to this problem is to call the 800 number and get the latest level of the code for SMIT and MKUSER. With that update you will get a new SMIT dialog for "Add A User" and a new version of MKUSER which supports the "id=###" option. The new SMIT panel gives you the option to set just about everything that CHUSER gave you access to. -- John F. Haugh II | This space intentionally | MaBellNet: (512) 838-4330 SneakerNet: 809/1C079 | left blank ... | VNET: LCCB386 at AUSVMQ BangNet: ...!cs.utexas.edu!ibmchs!auschs!snowball.austin.ibm.com!jfh (e-i-e-i-o)
jfh@greenber.austin.ibm.com (John F. Haugh II) (11/30/90)
In article <532@texhrc.UUCP> ldm@texhrc.UUCP (Lyle Meier) writes: > We have aquired an rs6000. We would like to be able to copy our existing > password file over to the system and have it work. (We distribute a > master password file to our yp domains, and the RS-6000 should set > in a different domain than everyone else). When one copies the password > file over one can log in as a user but an error message is created about > being unable to set terminal permission and the user is logged off. > Trying via telent yields similar results and a message that the > connection was closed. There are three commands for checking the correctness of your password and group files. They are PWDCK, GRPCK, and USRCK. Chances are your password file contains referencs to group IDs which don't exist in your group file or that the files in /etc/security are out of date. Most likely your /etc/group file is missing entries that are needed for the users you are trying to login as. There must be a group which corresponds to the GID in the /etc/passwd file for each user. Your other comments lead me to believe that you are running an older version of AIX v3.1 and need to contact your SE to get the latest update. -- John F. Haugh II | This space intentionally | MaBellNet: (512) 838-4330 SneakerNet: 809/1C079 | left blank ... | VNET: LCCB386 at AUSVMQ BangNet: ...!cs.utexas.edu!ibmchs!auschs!snowball.austin.ibm.com!jfh (e-i-e-i-o)
boote@bierstadt.scd.ucar.edu (Jeff W. Boote) (11/30/90)
In <532@texhrc.UUCP> ldm@texhrc.UUCP (Lyle Meier) writes: > A second related question. We have a central administration for uid's. > If one creates a user using SMIT how can one set the uid for the user > short of going thru the change user mechanism? Try getting the 3002 updates. Smit now allows you to specify all kinds of initial settings for new users instead of making you change them after they are created. -- Jeff W. Boote SCD/NCAR boote@ncar.ucar.edu Boulder, Colo
bware@slate.mines.colorado.edu (Bob Ware 209 Green C 2733987) (12/04/90)
We just got 3002 installed on one of our 930's, and sure enough, mkuser now lets you set uid's, etc. One thing we noticed, however, is that you cannot do mkuser -a plus other attributes. If you set uid, etc, then do not do mkuser -a. Bob Ware, Colorado School of Mines, Golden, Co 80401, USA (303) 273-3987 bware@slate.mines.colorado.edu bware@mines.colorado.edu bware@mines.bitnet -- Bob Ware, Colorado School of Mines, Golden, Co 80401, USA (303) 273-3987 bware@mines.colorado.edu bware@mines.bitnet isis!csm9a!bware