Creating and Deleting Lnodes

Whenever a new user is created, a corresponding lnode should be created and its limits and privileges should be set. When using Solaris Resource Manager, the administrator should maintain the limits database in parallel with the normal Solaris password map. The command:

# limreport \!flag.real - uid lname 

can be used to print a list of the UIDs and login names of any users who do not have corresponding lnodes.

Lnodes are not automatically created and deleted by the system commands used to create and delete accounts. It is up to the administrator to perform these actions. However, lnodes can be automatically created on-demand when the user logs in; see PAM Subsystem for more details.

Similarly, just before a user account is deleted from the password map, the corresponding lnode should be removed from the limits database by using the limadm(1MSRM) command.

When deleting lnodes, ensure that sub-trees are deleted from the bottom-most lnodes up. If you start at the top of the sub-tree you are deleting, you will lose control of the children of the lnodes deleted because they will become orphaned when their parents are removed.

If the UID of a user is ever changed, the contents of the user's lnode should be copied to a new lnode corresponding to the new UID and the original lnode should be deleted. See Copying and Removing Lnodes.

Any child lnodes should be attached either to the newly created lnode or to some other suitable parent lnode. The command:

# limreport 'sgroup==X' '%u\tsgroup=Y\n' uid | limadm set -u -f - 

can be used to find all lnodes with a scheduling group parent whose UID is X, and make them children of the lnode with a UID of Y.

The following steps illustrate how to change the UID of an lnode from X to Y.

1. Save the state of the lnode in which the UID is to be changed:

   # limreport 'uid==X' - lname preserve > /var/tmp/savelnode.X

2. Change the UID of the password map entry for the user from the old value (X) to that of the new UID (Y).

3. Create an lnode for the new UID, restoring the state from that which was previously saved:

   # limadm set -f /var/tmp/savelnode.X

4. For all child lnodes of the lnode to be changed (UID X), change their scheduling group to the new lnode (UID Y):

   # limreport 'sgroup==X' '%u\tsgroup=Y\n' uid | limadm set -u -f -

5. Ensure there are no processes currently attached to the old lnode.

6. Use the chown(2) command to change the owner of all files owned by the original UID to that of the new UID. For example:

   # find / -user X -print | xargs chown Y

7. Delete the old lnode:

   # limadm delete X

Lnode Maintenance Programs

The limadm command is the primary tool available to administrators for maintaining a user's lnode. This command changes Solaris Resource Manager attribute values for a given list of user accounts. If an lnode does not exist for any of the users, then a default-filled blank one is created first. New lnodes are created with the following properties:

• flag.real is set;

• cpu.shares and cpu.myshares attributes are set to 1;

• The flags uselimadm and admin are set to clear;

• All other flags are set to inherit;

• All limit and usage attributes are set to zero.

The scheduling group of the new lnode is set to user 'other' (srmother) if an lnode for that user account exists, or else to the root lnode.

The limadm invoker needs sufficient administrative privilege to perform the specified changes. The invoker must be the superuser, have a set uselimadm flag, or be a group administrator who is only changing the attributes of members of the scheduling group to which the invoker belongs. Restrictions apply to the use of limadm by group administrators.

• Group administrators cannot change the value of their own attributes.

• A user's sgroup attribute can only be assigned to the invoker or to a member of the invoker's scheduling group.

• Group administrators cannot change the attributes of users outside their scheduling group.

• They cannot alter the value of any attribute used to store usages other than term usage. Without this restriction, group administrators could circumvent the group limits in their own lnodes by reducing the usage of one of their children, thereby reducing the group usage.

• If they have a flag that evaluates to a value other than the default, group administrators can alter the value of that flag for another member of their group only if they are changing it to be the same non-default value.

  This ensures that group administrators with explicitly denied privileges cannot grant those privileges to any users under their influence.

The limadm command allows an administrator to remove an lnode without deleting the corresponding user account in the password map. To use limadm, the invoker must be the superuser or have a set uselimadm flag. If the invoker only has a set admin flag, then the invoker can only modify the lnodes of users under scheduling groups for which the invoker is the group header.