|
Softpanorama |
May the source be with you, but remember the KISS principle ;-)
Softpanorama Search
|
There are three ways to administer users and groups in AIX
Before going into the commands to create, modify, and maintain users and groups in AIX, it is important that you know what is happening behind the scenes. For example, you should understand the files and what they mean.
Look at the some of the files that affect the user itself:
The file /etc/passwd contains the basics of a user and is probably the best-known file to UNIX® and Linux® users for user administration.
root:!:0:0::/:/usr/bin/ksh daemon:!:1:1::/etc: bin:!:2:2::/bin: sys:!:3:3::/usr/sys: adm:!:4:4::/var/adm: uucp:!:5:5::/usr/lib/uucp: guest:!:100:100::/home/guest: nobody:!:4294967294:4294967294::/: lpd:!:9:4294967294::/: lp:*:11:11::/var/spool/lp:/bin/false invscout:*:6:12::/var/adm/invscout:/usr/bin/ksh snapp:*:200:13:snapp login user:/usr/sbin/snapp:/usr/sbin/snappd ipsec:*:201:1::/etc/ipsec:/usr/bin/ksh nuucp:*:7:5:uucp login user:/var/spool/uucppublic:/usr/sbin/uucp/uucico pconsole:*:8:0::/var/adm/pconsole:/usr/bin/ksh esaadmin:*:10:0::/var/esa:/usr/bin/ksh sshd:*:206:201::/var/empty:/usr/bin/ksh atc:!:8000:400:Adam Cormany,Sr UNIX Admin:/home/atc:/bin/ksh amdc:!:8001:401:AMDC:/home/amdc:/bin/ksh pac:!:8002:400:PAC,Jr UNIX Admin:/home/pac:/bin/ksh atc2:!:8003:402:ATCv2:/home/atc2:/bin/kshAs you can see, the file is colon (
:) delimited, and each entry contains
seven fields in the following format (with spaces added before and after delimiter
to ease reading):
Username : Password Flag : UID : GID : GECOS : Home : Shell/CommandHere's the line-by-line breakdown:
! or *. If the ! is displayed,
a password has been set for the user. If no password has been set, *
appears. The passwords themselves are stored in /etc/security/passwd. The file /etc/security/.profile can really save you some valuable time and ease
frustration. When you create a user using the mkuser command, the script
/usr/lib/security/mkuser.sys is executed. This script creates the user's directory,
sets the correct permissions, and "creates" the user's .profile. The mkuser.sys
script actually copies the /etc/security/.profile file into the user's new home
directory.
If you are building a new system, or maybe a new division of 100 people needs accounts on a system, make sure you make your changes to the /etc/security/.profile file before creating all the users' accounts. If you create the accounts and then realize that you need to make a simple change in a variable or modify another setting, you're going to have to manually make the change to everyone's profile. It could be scripted out easily, but life would have been much simpler if you would have just changed the /etc/security/.profile.
PATH=/usr/bin:/etc:/usr/sbin:/usr/ucb:$HOME/bin:/usr/bin/X11:/sbin:. export PATH if [ -s "$MAIL" ] # This is at Shell startup. In normal then echo "$MAILMSG" # operation, the Shell checks fi # periodically.
The /etc/security/limits file contains all the ulimits, or users'
system resource limitations. The fields in the /etc/security/limits file:
| Soft limit | Hard limit | Description |
|---|---|---|
fsize |
fsize_hard |
Size of file a user can create |
core |
core_hard |
Size of core file a user can create |
cpu |
cpu_hard |
The amount of system time allowed |
data |
data_hard |
Size of the process data segment |
stack |
stack_hard |
Size of the process stack segment |
rss |
rss_hard |
Physical memory allowed |
nofiles |
nofiles_hard |
Number of open file descriptors at one time |
nproc |
nproc_hard |
Number of running processes at one time |
What's the difference between soft and hard limits? A soft limit is a value that a user or application can change on the fly up to the maximum (the hard limit). The hard limit is just that -- the maximum value a parameter can be set to. If setting the parameter to a numeric value is too difficult (for example, if a developer has no idea how much memory his or her program is going to take or the number of files it will need to open), you can set the parameter to -1, which translates to unlimited.
It isn't imperative that you set individual ulimits for each and
every user, however. The /etc/security/limits file contains a section called
default that defines a template of standard values for each user unless
that user has set custom values. If the default section doesn't exist,
IBM kindly set predetermined limits just in case.
The IBM default values are:
* Attribute Value * ========== ============ * fsize_hard set to fsize * cpu_hard set to cpu * core_hard -1 * data_hard -1 * stack_hard 8388608 * rss_hard -1 * nofiles_hard -1 |
default: fsize = 4194303 core = 16384 cpu = -1 data = 262144 rss = 65536 stack = 65536 pac: fsize = 131072 fsize_hard = 262144 core = 262144
Considering that user "pac" is a junior UNIX administrator, his fsize
soft value was reduced from the default section's 4,194,303 to 131,072;
however, you were nice enough to allow the user to increase his value to 262,144,
if needed. Also, pac is notorious for finding ways to break his own programs. As
a result, you've increased his core ulimit to 262,144.
The /etc/security/passwd file contains the AIX user's password information. The file contains three fields per user:
Note: If this field contains only an asterisk (*), the
account is locked until a password has been set.
su. Listing 4 provides an example of a /etc/security/password file.
amdc: password = oBQaUkPkUryCY lastupdate = 1243972006 flags = ADMCHG |
In this example, user "amdc" has a password that was set on Tue. Jun. 2
15:46:46 EDT 2009. The next time the user logs in or sus to amdc, he
or she will be prompted to change the password.
To convert the seconds from epoch to timestamp you can use Perl one-kliner:
# perl -e 'use POSIX; print strftime("%c\n", localtime(1243972006));'
Tue Jun 2 15:46:46 EDT 2009
Now you're getting into the meat of AIX user administration. The /etc/security/user
file contains the most important settings, outside of the basics in /etc/passwd,
for a user:
| Parameter | Format | Description |
|---|---|---|
account_locked |
TRUE | FALSE | Lock out the account; the user is unable to log in if set to True. |
admin |
TRUE | FALSE | If True, the user has administrative rights. |
expires |
MMDDHHYY | If the date has been reached, the account has expired and is locked. |
histexpire |
0-260 | Number of weeks the user can't reuse a password. |
histsize |
0-50 | Number of passwords previously used that can't be reused. |
login |
TRUE | FALSE | User can log in if True. |
maxage |
0-52 | Number of weeks a password is valid. |
minage |
0-52 | Number of weeks a user must wait before changing his or her password. |
rlogin |
TRUE | FALSE | The account can be accessed remotely if set to True. |
su |
TRUE | FALSE | Others can use su to access this account if set to True.
|
For a full listing of all parameters, look in your AIX system under /etc/security/user,
or see
AIX Information Center. Like /etc/security/limits, a default section
sets all the fields if not specified by the individual account.
/usr/lib/security/mkuser.default
The /usr/lib/security/mkuser.default file contains values used when creating
a new AIX user through mkuser.
user: pgrp = staff groups = staff shell = /usr/bin/ksh home = /home/$USER admin: pgrp = system groups = system shell = /usr/bin/ksh home = /home/$USER
More parameters can be defined in this file. To view the full list, look at
man chuser.
AIX user and group administration by Adam Cormany
getconf: See IBM's man page for the getconf command.
chuser
command.
Copyright © 1996-2009 by Dr. Nikolai Bezroukov. www.softpanorama.org was created as a service to the UN Sustainable Development Networking Programme (SDNP) in the author free time. Submit comments This document is an industrial compilation designed and created exclusively for educational use and is placed under the copyright of the Open Content License(OPL). Site uses AdSense so you need to be aware of Google privacy policy. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.
Disclaimer:
Last modified: October 27, 2009