Creating a Sysctl application consists of the following basic steps:
Here is an example of how to write a Sysctl application that allows a user to execute a script including some commands requiring root execution privileges on all the nodes in an SP system in parallel. The user is not required to know any of the root passwords, but must be listed in an ACL specifically set up to authorize use of the script. A copy of this ACL resides on each node. The script containing the commands executable only by root is called /etc/root_script. Assume that /etc/root_script accepts a single argument, and that this script resides on each node.
The server side of the application does the root part of the job, which is to issue the /etc/root_script command with the correct arguments on behalf of authorized users. It first needs to determine if the client is authorized based on an authorization policy. As mentioned above, authorization is based on an access control list. There are no return values, but an error message is displayed when the user is not authorized to run the command. stdout and stderr are returned to the client.
The server command resides in /etc/sysctl/apps/adminscript and is coded as follows:
create proc adminscript {argument} AUTH {
global SCPRINCIPAL
if [aclcheck -f /etc/sysctl.adminscript.acl $SCPRINCIPAL] {
puts "[exec /etc/root_script $argument]"
return
}
puts "Not authorized to run adminscript"
}
The first line creates a new Sysctl procedure called adminscript. One argument is accepted, which will be passed unchanged to /etc/root_script. This procedure uses the provided AUTH authorization callback, which means that only authenticated clients can execute the command.
The second line issues the Tcl global command to provide the content of the SCPRINCIPAL variable to other Sysctl commands. (This is needed because SCPRINCIPAL is passed as an argument to aclcheck later.) The SCPRINCIPAL variable is the authenticated identity of the command issuer and is one of the variables set by the server and available to procedures and callbacks. See the Sysctld daemon information in the book PSSP: Command and Technical Reference for a list of all the variables.
The third line is Tcl code that uses the built-in aclcheck command to see if the user is in the ACL (/etc/sysctl.adminscript.acl) set up for this command. If the user is authorized, the program issues the /etc/root_script command with the supplied argument and then returns. If the user is not authorized, the program issues an error message. The program returns any output (information from /etc/root_script command or the error message) to the client user's terminal.
Note that in this example, further authorization checking is done in the body of the procedure after the authorization callback has completed. This is to demonstrate the use of the SCUSER variable provided by the server to procedures. Alternatively, this check could have been made part of the authorization callback itself.
The client side of the application needs to find out the necessary information to provide to the servers. It does not require root authority to be issued. The information in this case includes the single argument to be passed through to /etc/root_script. The client also needs to determine the hostnames of all the nodes in the SP System, so that the command can be sent to and run in parallel on all the nodes.
The client side is coded as follows in /usr/bin/doadminscript:
#!/usr/lpp/ssp/perl/bin/perl
# Run /etc/root_script on all the SP nodes in parallel by invoking
# the adminscript sysctl command on all the nodes. Invoke via:
# doadminscript arg_to_root_script
$#ARGV > 1 && die "too many arguments";
exec "/usr/lpp/ssp/bin/hostlist -av |
/usr/bin/sysctl -c - adminscript $ARGV[0]";
The first line checks for extraneous arguments. The exec statement uses the SP hostlist command to write all the currently responding hostnames in the SP System to stdout. The single argument to adminscript is passed along to the Sysctl adminscript server command.
A new ACL file needs to be put on each node in the system. The file /etc/sysctl.adminscript.acl looks like this:
#acl# # These are the users that can issue the adminscript command on this # node: _principal root@HPSSL.KGN.IBM.COM _principal newbie@HPSSL.KGN.IBM.COM _principal guru@HPSSL.KGN.IBM.COM
Note that each node can authorize different users to run the new command. In this case, assume that the ACL will be the same on all nodes. To distribute the ACL file to all the responding nodes, an authorized user enters the following (see the pcp man page for details):
pcp "-av" /etc/sysctl.adminscript.acl
In addition, the /etc/sysctl.conf file needs to be updated to include the new command. If the server code is to reside in /etc/sysctl/apps directory, the following lines can be added to /etc/sysctl.conf:
# Add the adminscript application include /etc/sysctl/apps/adminscript
The updated sysctl.conf file and the actual server code need to be distributed:
pcp "-av" /etc/sysctl.conf pcp "-av" /etc/sysctl/apps/adminscript
Now the servers need to be restarted to include the updated sysctl.conf file. Note that the following command requires ACL authorization:
hostlist -av | sysctl -c - svcrestart
Now, any of the users in /etc/sysctl.adminscript.acl (root, newbie, or guru) can run /etc/root_script with the argument mikef on all the nodes simultaneously by entering the following command:
doadminscript mikef
Variables are set by the server based on information on the client provided by SP security services. Authorization callbacks and Tcl scripts have access to these variables. See "Sysctld (daemon)" in the book PSSP: Command and Technical Reference for a list of all the authorization variables.