- Understanding the Background and Case Scenario
- Integrating Solaris Resource Manager Software
- About the Author
- Acknowledgements
- Related Resources
- Ordering Sun Documents
- Accessing Sun Documentation Online
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Integrating Solaris Resource Manager Software
Integrating Solaris Resource Manager software with Sun Ray requires the Fair Share Scheduler (FSS) as the system-wide default scheduler. The following method requires a reboot, although the reboot is not strictly necessary.
NOTE
The process for migrating a running system into the FSS without rebooting is documented in the Sun Blueprints OnLine article titled "Resource Management in the Solaris 9 Operating Environment." Also documented in the "Resource Management in the Solaris 9 Operating Environment" article are important details about when to run other scheduling classes simultaneously with the FSS.
Sun Ray1# dispadmin -d FSS Sun Ray1# init 6
Aggregate User Processes
Users initiate many processes during their normal workflow. For example, a simple GNOME session typically employs about forty processes. While these processes work together to present users with an integrated desktop environment, Solaris Operating System (Solaris OS) treats each process as an independent entity. To meaningfully control consumption of key system resources, the system must treat all of the processes belonging to a single user as a single entity.
In Solaris Resource Manager software, the project container provides a convenient mechanism for aggregating user processes. Although technically a project might contain the processes of multiple users, placing each user within a separate project enables the defined resource constraints to individually operate on users.
The simplest way to define a project is to add it to the local project repository /etc/project. Each Sun Ray user needs a dedicated project, that is, a project for which the user is the sole user. By convention, projects for users are prefixed with user (user-dot).
Sun Ray1# projadd -c "Smith, Mary" -U ms12345 -p 84855 user.ms12345
The parameters to projadd have a similar context to those of useradd:
-c argument specifies a comment.
-U designates the usernames belonging to the project.
-p gives a unique identifier for the project (similar to a UID).
Like useradd, the last parameter denotes a common name for the project entry.
By default a project is not resource constrained. However, common Solaris utilities such as prstat(1M) can aggregate their output by project.
To add resource controls to the project entry in /etc/project, edit the file and append the resource controls without line breaks to the appropriate entries. An automated script is provided to accomplish this without manually editing /etc/project.
Control CPU Shares
Controlling the CPU shares of Sun Ray users requires the presence of a project.cpu-shares constraint. Users should not be able to modify the number of CPU shares allotted to their projects, and the share limit should be enforced when a project hits the threshold. Appending the following to a project entry specifies these limits.
project.cpu-shares=(privileged,1,deny)
Generically, resource controls are specified by triplets (type, value, and action). The triplet in the code example (privileged,1,deny) sets a control on the project's CPU shares with a value of 1 (1 share) that denies further shares when the 1 share threshold is reached; superuser (or privileged) permissions are required to change this value. Refer to the project manual page project(4) for more details
Multiple resource constraints of type project.cpu-shares might exist for a single project. However, this solution assumes that only a single project.cpu-shares constraint exists for each project; additional constraints on cpu-shares might lead to unexpected results.
The complete line in /etc/project should look similar to the following. Note that the entry should be constrained to a single line in the file, without line continuation.
user.mary:12345:Smith, Smith:marys::project.cpu-shares=(privileged,1,deny)
Now when the individual Mary Smith (username marys) logs into the system, or starts a process via cron, the user.marys project will have 1 share of the CPU. If Smith has existing processes, they will inherit this limit.
Using Scripts to Allocate Shares Automatically
With only a little scripting, we can automatically increase a user's shares whenever the user inserts a smart card into a Sun Ray DTU. The Sun Ray command utaction is the mechanism for specifying commands to execute when users insert or remove cards at a DTU. With utaction, administrators can either specify a time delay for the action, or alternatively specify that the action should be taken immediately.
An unmodified Sun Ray server installation starts two utaction processes for each card user when a user removes the card. The first process immediately locks the screen via utxlock. (This can be modified to specify a time delay, for example, two minutes, so if a user re-inserts the card within two minutes of removing it, the user does not need to unlock the screen.) The second process performs housecleaning after a user logs out of a session.
Because utaction operates on card insert and remove events, it cannot be used to control non-card Sun Ray users. However, with the resource constrained project(s) just created, the commands specified to utaction increase or decrease a user's CPU shares appropriately for card-based users.
Let's start with the scripts that actually increase or decrease a user's CPU shares. For now, assume the utaction command was invoked properly, and it provides us with the user name (sometimes referred to as the user ID, however, not the numeric ID). The connectme.sh and disconnectme.sh scripts operate on this user name, accepted as a single argument.
When a user inserts a smart card, we want to run the connectme.sh script.
#!/bin/sh # M. Smith, December 2003 # connectme.sh - when a user inserts their card, increase # the number of CPU shares for their project # # requires $1 to be a valid username, and # a user.$1 project in /etc/project, with a project.cpu-shares constraint prctl -t privileged -e deny -n project.cpu-shares -r -v 50 -i project user.$1
When user Smith inserts her card, or connects to her Sun Ray session, this script sets the CPU shares for her project to 50. The call to the prtctl command replaces (-r) the first resource control (identified by the -n argument, here project.cpu-shares) with the new triplet specified by the type (-t), value (-v), and action (-e). The final arguments to prtctl indicate to what entity the new resource control should apply, namely, a project entity (-i project) identified by user.$1 (in this example, user.marysmarys).
Similarly, when Smith removes her card from a Sun Ray, her shares should return to 1, as shown in the following disconnectme.sh script.
#!/bin/sh # M. Smith, December 2003 # disconnectme.sh - when a user removes their card, decrease # the number of CPU shares for their project # # requires $1 to be a valid username, and # a user.$1 project in /etc/project, with a project.cpu-shares constraint prctl -t privileged -e deny -n project.cpu-shares -r -v 1 -i project user.$1
Can you see the difference between the two scripts? The value (-v) argument to the prctl command is the only difference. Therefore, we can consolidate both into a single script named adjustshares.sh and pass a new argument specifying the number of shares (depending on whether the user inserts or removes the card).
#!/bin/sh # M. Smith, February 2004 # adjustshares.sh - adjust a user's shares whenever they insert or # remove their smartcard from a Sun Ray # # requires $1 to be a valid username, # requires $2 to be a valid number of cpu-shares for the user's project, and # a user.$1 project in /etc/project, with a project.cpu-shares constraint prctl -t privileged -e deny -n project.cpu-shares -r -v $2 -I project user.$1
Now that the adjustshares.sh script is defined, we turn our attention to invoking utaction. For controlling a user's CPU shares, the utaction process must be active throughout the lifetime of the desktop session.
Preventing Users From Modifying Share Limits
To prevent a user from circumventing the utaction process and keeping shares increased even though the card is removed, utaction must be run as root user. Solaris OS provides a handy mechanism for doing this. When a user successfully authenticates to the system, the system must perform certain tasks that the user does not normally have permission to do. For example, when a user logs into a system console, the system grants to the user read and write permissions for the console device. Similarly, these changes must be undone when the user logs out. These changes are symmetrically made in Xstartup and Xreset.
NOTE
An additional script, Xsetup, can be used to set up the X server before the authentication screen is displayed. Additional files exist; refer to the FILES section of the dtlogin(1X) manual page for more details.
FIGURE 1 depicts the time line of a user session.
)
FIGURE 1 Structure
of an X11 Session
In FIGURE 1, the grey boxes represent functions that execute with root permissions immediately before and after a user's session. The system default Xstartup and Xreset scripts are maintained in /usr/dt/config.
Preserving Share Limits Before Patches and Upgrades
Because the scripts in /usr/dt/config might be changed by patches or Solaris upgrades, it is considered best practice to copy these files into /etc/dt/config, and modify them there. Be sure to make the script executable, otherwise the X session will not start correctly (the dtlogin screen will reappear).
Alternatively, the default scripts in /usr/dt/config could be sourced from the new scripts in /etc/dt/config, which would automatically incorporate any changes to the default scripts.
The dtlogin process searches the /etc/dt/config directory first, and uses the scripts there if they exist with the proper permissions. The /etc/dt/config does not exist by default, so you might need to create it.
Sun Ray# mkdir -p /etc/dt/config Sun Ray# cp /usr/dt/config/Xstartup /etc/dt/config Sun Ray# cp /usr/dt/config/Xreset /etc/dt/config
For simplicity, this article sources the default scripts /etc/dt/config/Xstartup.
#!/bin/ksh # the corresponding script in /usr may be modified by patches, etc. # get the latest version . /usr/dt/config/Xstartup # then invoke utaction (place in background) /opt/SUNWut/bin/utaction -i -c "adjustshares.sh $USER 50" -d "adjustshares.sh $USER 1" &
Adjusting Background Processor Shares
The utaction command terminates when the user's session is destroyed; it does not run the disconnect command before doing so. If the user logs out, or the session is reaped according to administrative policies, the user still has 50 shares. To rectify this, run the adjustshares.sh script in the Xreset script.
Now any background processes started by the user will have fewer shares of the processor /etc/dt/config/Xreset.
#! /bin/ksh # the corresponding script in /usr may be modified by patches, etc. # get the latest version . /usr/dt/config/Xreset # then invoke the adjust shares script adjustshares.sh $USER 1