The login control function is used to dynamically prevent interactive login of users on a node basis. Preventing interactive login of users on nodes running parallel jobs is desirable for performance purposes.
You might want to use login control to temporarily restrict all but a few users on a node for a specific purpose.
You can issue commands to temporarily restrict or unrestrict a user's interactive access to nodes running parallel jobs. The login control utility does not prevent LoadLeveler from running jobs submitted by blocked users because LoadLeveler logs in as root and then switches to the user. Root is never blocked on a node.
User login completes successfully under AIX after checking attributes in the /etc/security/user file. The attributes are login and rlogin. If these values are set to true, the user is allowed to log in. Conversely, if these values are set to false, the user cannot log in. Login Control updates this file dynamically for a user or several users when a request is received.
The spacs_cntrl command takes four state keywords that manage user access to a parallel node:
These keywords are used by a system administrator to dynamically restrict and unrestrict access to a node for a user or a group of users. These keywords are intended to set the user to a known state (either restricted or unrestricted) in the /etc/security/user file and in the spacs_data file.
These keywords can be used by a job submission system on a transactional basis to update the user state. Multiple usage of spacs_cntrl with one of these keywords for a user results in the request state being updated in spacs_data.
A user can be in one of four states when these keywords are used:
State 3 can occur when other jobs by this user are still running. A deny request removes one allow request: in this case, the first allow from the first job.
State 4 can occur when more than one deny request is issued for a user. A deny request removes one allow request.
A special file, spacs_data, is created when a user access change request is made more than once by a job submissions system using the keywords allow or deny. It can be said that this file holds the state of requests for a user. After the initial allow or deny request has been processed in /etc/security/user, the next allow or deny request sets a request count for the user. The same number of subsequent opposite requests will check the count, decrement it and remove the user, if present, from spacs_data. The use of the block and unblock keywords by the System Administrator updates spacs_data, clearing all multiple job submission system allow/deny requests for a user before changing the state in /etc/security/user. These keywords are intended to set the user to a known state (either restricted or unrestricted) in the /etc/security/user file and in the spacs_data file. The spacs_data file is owned by root and is located in the /var/spacs directory.
Login control recognizes requests made with the spacs_cntrl command. (See the PSSP: Command and Technical Reference for syntax.) This command is run on each parallel node and can be used with dsh for this purpose.
Login Control uses a lock on the spacs_cntrl.lock file to prevent more than one instance of Login Control from updating the files. This file is created the first time the spacs_cntrl command is executed. This file also resides in the /var/spacs directory.
When spacs_cntrl block or deny is used, all of the following types of interactive access are disallowed:
As system administrator, you can disallow users from using ftp on a node by placing users in the /etc/ftpusers file. This file can be kept in a file collection and distributed to the appropriate nodes. The ftp daemon can also be disabled to prevent all ftp access.
You can also use the ruser command to manage ftp usage by a user on a node:
ruser -a -f username
Using this command with dsh to the appropriate nodes allows manipulation of the /etc/ftpusers file on a per user basis.
A sample Perl script called block_usr_sample is located in the /usr/lpp/ssp/samples directory. This script creates a file of user IDs, /tmp/usr.input, that can be used with the spacs_cntrl -f command to restrict user access. It serves as a model for formatting other files for use with the spacs_cntrl command:
userid1 userid2 userid3
Once you are familiar with the login control script, the spacs_cntrl command can be run within this script by removing the comments surrounding the command. A copy of this file is located in Appendix C, Sample files.
Before using this script you must edit the threshold UID ($uidstart) in the script to make it large enough so that system IDs and SP system IDs are not restricted. These IDs include bin, admin, lpd, supman, and prtid. The default threshold UID is set at 125. The block_usr_sample script can be added to the script.cust file or to the inittab file of the node.
Adding the script to run from the script.cust file will create the /tmp/user.input file and run spacs_cntrl block when you install the node to initially restrict interactive access for all users. Users would remain in this state across a reboot unless specifically unrestricted by the system administrator or by the job submission system. New users that are added to the system would not be included until the block_usr_sample script was run again at some later time.
Adding the block_usr_sample script to the inittab file will run this script at node boot time. This will include any new users on the node but might also increase the time to boot the node. This script must be added after the rc.sp script in the inittab file. The rc.sp script removes the login control lock file, spacs_cntrl.lock, if present, when booting a node to ensure login control will run if a node is rebooted after a crash.
There are many ways you can use login control on your SP system. You can restrict all or a subset of users on a parallel node to prevent the users from gaining interactive access. The restriction remains in effect until you specifically use the unblock keyword to unrestrict access for the restricted users.
This enables you to set aside a parallel node for the use of select users for interactive and parallel jobs. You can list the users on the command line or use a file containing the user names in a column. Note that this file must reside on the parallel node in order to be accessible to the login control command.
To restrict user Betty on a particular node, on that node issue:
spacs_cntrl block betty
This example requires authority to run the rsh command on the nodes.
hostlist -av | pcp -w - -r root@mynode:/tmp/usr.input /tmp/usr.input
dsh -a spacs_cntrl -f /tmp/usr.input block
The following information is important for Login Control to function properly.
Since the /etc/security/user file is used by Login Control for state information, and by the AIX system for restricting and unrestricting login for users, this file is machine dependent and should not be overwritten. The /etc/security/user file should not be distributed through file collections or any other mechanism throughout the SP system.
The spacs_cntrl command might generate a large log file, depending on which flags you specify. The default for trimming the log file is 400 lines and is done every night through a cron job. If you want to save the log for some reason, you can rename the file and a new log file will be created.
You must issue the spacs_cntrl command to block new users added to a node if you have previously blocked all users on that node. Users denied login will see the standard message, "You have entered an invalid login name or password".
Each time the log is opened, a date stamp is written. This might be followed by messages depending on the options chosen on the command line. The following spacs.log example shows the output when using the -d and -l flags on the spacs_cntrl command line.
"Tue Apr 26 10:11:47 EDT 1994"
spacs_cntrl: Command Invocation: spacs_cntrl -d -l deny nancy.
spacs_cntrl: CPFILE called for /etc/security/user and /etc/security/user.17008.
spacs_cntrl: ACS_FILE/lock called for /var/spacs/spacs_data.lck.
spacs_cntrl: List of users in deny list: .
spacs_cntrl: List of users in allow list: ,mroz.
spacs_cntrl: Deny processing.
spacs_cntrl: List of users in send list: nancy.
spacs_cntrl: MUSRFILE called.
spacs_user: Called with parameters: /usr/lpp/ssp/bin/spacs_user -l -d deny nancy.
spacs_user: Attribute for user nancy changed to requested value.
spacs_cntrl: List of users in return list: nancy:0.
spacs_cntrl: CPFILE called for /var/spacs/spacs_data and /var/spacs/spacs_data.17008.
spacs_cntrl: ACS_FILE/unlock called for /var/spacs/spacs_data.lck.
"Tue Apr 26 10:11:52 EDT 1994"
spacs_cntrl: Command Invocation: spacs_cntrl -d -l deny pepper.
spacs_cntrl: CPFILE called for /etc/security/user and /etc/security/user.20102.
spacs_cntrl: ACS_FILE/lock called for /var/spacs/spacs_data.lck.
spacs_cntrl: List of users in deny list: .
spacs_cntrl: List of users in allow list: ,mroz.
spacs_cntrl: Deny processing.
spacs_cntrl: List of users in send list: pepper.
spacs_cntrl: MUSRFILE called.
spacs_user: Called with parameters: /usr/lpp/ssp/bin/spacs_user -l -d deny pepper.
spacs_user: Attribute for user pepper changed to requested value.
spacs_cntrl: List of users in return list: pepper:0.
spacs_cntrl: CPFILE called for /var/spacs/spacs_data and /var/spacs/spacs_data.20102.
spacs_cntrl: ACS_FILE/unlock called for /var/spacs/spacs_data.lck.