Here's some pretty incredible documentation, tips, and best practices regarding Software Delivery Jobs and Unix or Linux. Contributor (and Juice reader) Snowjgj is part of the support team working the lines to keep Altiris customers up and running. (Read: he knows his stuff).
How Software Delivery for Unix currently works by default:
The Altiris Agent for Unix is the base agent that establishes communications between the Notification Server and UNIX, Linux or Mac computers.
By default, the base agent includes the Software Delivery components needed to receive software delivery
packages at client computers. An example of the agent running on a Linux machine looks as follows:
root 409 1 0 Oct 19 ? 45:00 aex-monitor.bin
root 420 1 0 Oct 19 ? 142:54 aex-pluginmanager.bin -D
As you notice, these processes are running as the user "root". This is important as it will start all child processes as root also.
The Software Delivery Solution for Unix plugs into this agent and allows you to create software packages consisting of files, commands, or entire programs that can be deployed to client computers where the Altiris Agent is installed.
Notification policies sent by the Notification Server to a collection of client computers, initiate the
client computers to communicate with the Notification Server to receive the event in the client
computer.
When a new Software Delivery job is defined in the client's policy, the client machine then downloads the package containing the files locally to the /opt/altiris/notification/nsagent/var/packages/{GUID} folder and the Altiris Agent then executes the program.
A sample program to run a Software Delivery task for Unix would appear as follows:
The key to all Software Delivery jobs is the command line. This command line is run by the aex-pluginmanager.bin as root as root with the root users permissions. Though run with the root users permissions, no native environment is loaded for the root user through Altiris and the Altiris specific environment is used.
Why it would be necessary to run a job as a specified user?
As mentioned in the section for How Software Delivery works by default, all programs kick off by the Altiris agent run as root. More specifically the following is kicked off:
/bin/sh –c " COMMANDLINE "
Where COMMANDLINE is the command defined in the program. The /bin/sh –c is issued by the Altiris agent during execution and defines the shell to be used, in this case Bourne shell, and the command line to issue with the -c. There is no way to change this starting environment though you can use another shell be defining it inside your COMMANDLINE.
Problems may and often do arise from running a program this way. Because no native specific user environment is loaded all programs trying to use native user settings or variables such as $path, $libpath, $HOSTNAME, and many others will not be found and may cause failures.
In addition, you may have a specific user created the same way on all machines who you need to run a specific file. In order to run the program correctly, it would be necessary to execute the program as that specific user. For these types of jobs to work it may be necessary to inherit the environment of the user who will run this command.
How to run a job as a specific user in their native environment:
To perform tasks as a specified user it becomes necessary to use the "su" command. Su or Switch user enables a user to change their identity or to issue a single command as a specific user. In most cases it is best to run these commands using the specified users native environment. To do this you will need to use the –l flag. The –l flag is the most important as in addition to switching users to the specified user the –l also inherits the native environment and shell of that user as specified in that user's .bashrc and .login files.
When this flag is combined with the –c flag you have the perfect environment with which to run an Altiris Software Delivery job. The –c flag specifies a command to be executed. Once this command finishes the "su" command also exits and you are returned to your original shell as the original user.
A sample command line would be:
su –l USER –c "ls"
This command uses the specified users login environment, in this case the user named USER, and lists the content of the specified users home directory.
Some problems with su –l USER –c "command":
One thing to keep in mind is that when the "su –l" command is being issued the user issuing the command is literally logging in as that user. If a users native environment prompts the user for input on login, this same prompt will appear for the Altiris program. This will causes the program to hang indefinitely and the program will never complete. To resolve this issue it would be necessary to either adjust the command line so the users native environment is not inherited or adjust the users .bashrc, .tcshrc, .cshrc, or .login file depending on the users native settings.
The biggest problem with using "su –lc" is that "su –l" changes you to the other users default login location, or $HOME. It can then be difficult to get your command line correct to define the specific location of the package where the command you want issued is to be run.
Possible workarounds for the problem with having the Altiris working directory changed to $HOME:
There are two good ways to resolve this issue.
The first, though not the best, option is to copy the files to a temporary folder and execute the command from the temporary folder. For example, a program command line through Altiris might be:
cp –r * /tmp/; su –l USER –c "/tmp/programtorun"
An obvious problem with using this is that the files are left behind in the /tmp folder. You could run a mkdir first and remove the folder afterwards, but this would be fairly messy. For example, you may use the following command instead:
Mkdir /tmp/altswdjob; cp –r * /tmp/altswdjob; su –l USER –c "/tmp/programtorun"; rm –rf /tmp/altswdjob
Though cleaner, this creates a new folder and doubles the space used by the package. In addition, the "rm –rf" command is very powerful and accidentally typing "rm –rf / tmp/altswdjob" with the accidental space before "tmp/altswdjob" would delete the entire operating system and files so it is generally better to stay clear of this option.
A better, though not the best, option would be to use the full path to the existing package. For example, a command line might appear as follows:
su –l USER –c "/opt/altiris/notification/nsagent/var/packages/{GUID}/programtorun"
where {GUID} is the GUID of the package you are using.
Though effective, the problem with this option is that each package you create will have a unique GUID and it will require a unique command line for every package.
The best option would be to set an environment variable with the path to the package first and call this variable when running the command line of your program. This requires using export and unset. Export is used because, as we mention above in How Software Delivery currently works, the Agent always starts by executing /bin/sh –c " COMMANDLINE " which is the Bourne shell. For example, an optimal command line would be:
Export AltJob='pwd'; su –l USER –c "$AltJob/programtorun"; unset AltJob
By using environment variables, this command line can be applied to any package or program. Remember that the $AltJob is a reference to the location of the package on the client machine.
Why doesn't "su" prompt for a password?
Because the Altiris Agent currently runs as root, the su –l command is being issued by the super user. Because the superuser has all permissions to the machine the su program will accept any commands without question and no password is required.
A walkthrough of running a Software Delivery job as root with the root user's native environment:
The most useful application of using "su –c " to run a command is the ability to inherit the native user environment for the "root" user because most jobs will require wheel or similar permissions.
Following is a complete run through in which I create a job for the root user which will deliver the software "Adobe Reader for Linux".
The first thing we need to do is create the package:
I have specified a package location locally that contains my RPR file.
Next we will create the program:
I have set the command line as follows:
export AltJob='pwd'; su –lc "rpm –i $AltJob/adobe.rpm"; unset AltJob
The first command creates the AltJob variable as the current path of working directory. For the "su" command, "su –l" or "su –" default to switch user to the root user therefore I do not need to specify the user name "root". The –c has been combined in the flag set and I am running the rpm –i command to install the software from the package. Once this is complete I unset the environment variable AltJob in order to clean up after the job. I have not set an uninstall command as any exit code by 0 will not automatically be cleaned up by the rpm utility.
I will not make any changes on the Advanced tab as these settings are for Package Server download locations and client download locations.
The task for this job was then created as shown:
When run on the client machines, this task uses my root user's native environment to install ensuring that all my native libraries are called and executed correctly.