Setting Up Unix Users for tc Server and Hyperic

On Unix-like systems, the interaction between Hyperic and tc Server is straightforward as long as tc Runtime instances and the Hyperic Agent run as the same user. You can start, stop, or restart tc Runtime instances and deploy web applications using the Hyperic interface without permission or ownership conflicts, since all processes and commands run as the same user.

Beginning with Hyperic release 4.6, the tc Server Hyperic plug-in allows you to run Hyperic Agent and tc Runtime instances with different user IDs. You might do this for increased security, or because the Hyperic Agent needs to run as a privileged user to manage some other resource on the computer, or perhaps you want to run different tc Runtime instances as different users to take advantage of process accounting.

The Hyperic 4.6 tc Server plug-in detects the user and group running the tc Server process and records them in parameters in the Hyperic Server resource created for the instance. If the user is different from the user running Hyperic Agent, the plug-in uses su or sudo to set the user whenever you start, restart, or stop a tc Runtime instance or change the tc Runtime instance's configuration through Hyperic. When you deploy a web application through Hyperic, the plug-in ensures that the WAR file ownership and file permissions are set so that the tc Runtime instance can deploy the application.

Both Hyperic Agent and tc Runtime instances should ideally run as regular, non-root users. In some cases, you may have to run Hyperic Agent as root in order to monitor or manage resources through Hyperic that cannot be managed with a non-root user. Never, however, run a tc Server instance as root.

If you use different non-root users to run tc Server instances and Hyperic Agent, you must create them in the same primary group. This is necessary to allow Hyperic Agent to read files written by the tc Runtime instance. It also enables web application deployments through Hyperic; Hyperic Agent deploys WAR files with group permissions set (640) so that members of the same group can read the WAR. If the Hyperic Agent and tc Runtime instance users are in different groups, tc Runtime will not be able to read the WAR file to deploy it.

Subtopics

Creating Users and Groups for Hyperic and tc Server

Setting the tc Server User in Hyperic

Enabling Hyperic Agent Access to su or sudo

Deploying Web Applications on Unix Systems

Creating Users and Groups for Hyperic Agent and tc Server

When you run Hyperic Agent and tc Runtime instances with different users, they must be in the same primary group to allow them to share files. For better security, you can create a separate group for them.

The following procedure shows how to create a group and add users to it for tc Server and Hyperic Agent on Red Hat Linux. The exact commands may be different on other operating systems.

Procedure

  1. Log in as root and start a terminal session.

  2. Use the groupadd command to create a new group. The following example creates a spring group:

    prompt$ groupadd spring
  3. Use the useradd command to create a user for Hyperic Agent in the group you created in the previous step. The following example creates a hyperic user in the spring group:

    prompt$ useradd hyperic -g spring

    You can include the -M option to prevent creating a home directory for the user and the -s /sbin/nologin option to prevent anyone from logging in as the hyperic user.

    Install and run Hyperic Agent as this user.

  4. Use the useradd command to create a user to run tc Server instances. The following example creates a tcserver user in the spring group:

    prompt$ useradd tcserver -g spring

    You can include the -M option to prevent creating a home directory for the user and the -s /sbin/nologin option to prevent anyone from logging in as the tcserver user.

    Create the tc Server instance and run it as this user.

  5. If you want to run multiple tc Runtime instances under separate user accounts on the same computer, repeat the previous step to create additional tc Server users.

Setting the tc Server User in Hyperic

Hyperic uses auto-discovery to detect tc Runtime instances. The first time it discovers an instance, it records the user and group running the process. Therefore, the usual method to set the tc Server user is to create the instance and run it as the desired user, allowing Hyperic Agent to discover the instance.

If you are migrating to a new Hyperic release and you have existing tc Runtime instances detected by an earlier version of Hyperic, the user and group parameters are blank. The first time auto-discovery runs, the instances will show up as modified in the auto-discovery queue. When you accept the modified resources, the user and group are recorded. If you perform any management operations before these existing instances are auto-discovered, the operation will be performed with the Hyperic Agent user and group. To avoid this, after upgrading Hyperic from a pre-4.6 release, force auto-detection and accept the modified resources before performing any management operations with Hyperic.

If you decide to change the tc Server user for an instance previously created with a different user, be sure to chown all the files in the tc Runtime instance directory and ensure they are readable and writable by the new user. Then start the instance as the new user and trigger auto-detect in Hyperic to record the new user in the Hyperic resource record.

Enabling Hyperic Agent Access to su or sudo

Hyperic Agent uses the su or sudo command to execute tasks as the tc Server user. Specifically, if Hyperic Agent is running as root, it uses /bin/su to change to the desired user to perform the task. If running as a non-root user, Hyperic Agent instead uses /bin/sudo to do the work as the tc Server user. There are some prerequisites you must verify to ensure that Hyperic can use su or sudo, described below.

If Hyperic Agent is running as root

If Hyperic Agent is running as root, it will use su to execute tasks as the tc Server user. You must ensure that /bin/su exists. If not, create a link to it.

For example, if su is in /sbin, but not /bin, create a link as follows:

prompt$ sudo ln -s /sbin/su /bin/su

If Hyperic Agent is running as a non-root user

If Hyperic Agent is running as a non-root user, it will use sudo to execute tasks as the tc Server user. You must ensure that /usr/bin/sudo exists and also grant required permissions to the tc Server user in the /etc/sudoers file.

For example, if sudo is in /usr/sbin/, but not /bin, create a link as follows:

prompt$ sudo ln -s /usr/sbin/sudo /bin/sudo

The user running Hyperic Agent needs permission to run the tcruntime-ctl.sh script as the tc Server user without having to enter a password. This is accomplished by editing the /etc/sudoers file as root and adding an entry. For example, if Hyperic Agent is running as user hyperic, tc Server runtime instances are running as user tcserver, and the tcruntime-ctl.sh script is in /opt/vmware/vfabric-tc-server-standard-2.6.0.RELEASE/tcruntime-ctl.sh, you would add the following entry to /etc/sudoers:

hyperic ALL=(tcserver) NOPASSWD: /opt/vmware/vfabric-tc-server-standard-2.6.0.RELEASE/tcruntime-ctl.sh

Deploying Web Applications on Unix Systems

The Hyperic tc Server plug-in ensures that when you deploy a web application, the WAR file ownership and access rights are set so that the tc Runtime instance is able to read the WAR. Depending on the users running Hyperic Agent and the tc Runtime instance, and the method used to deploy the WAR file, there are different scenarios.

Cold Deploy

When you cold-deploy an application with Hyperic, the Hyperic Agent copies the WAR file into the tc Server instance's webapps/ directory. The WAR file owner and permissions depend on the Hyperic Agent user.

  • If Hyperic Agent is running as root, the WAR file owner and group are set to the user and group stored in the Hyperic resource record for the tc Server instance. The file permissions are set to 600, so only the tc Server instance user has read permission.

    Note

    If the tc Server user and group in the Hyperic resource record are blank, the owner and group are the same as the Hyperic Agent user. If the tc Runtime instance starts as a user other than the Hyperic Agent user, tc Runtime will fail to open the WAR, and the deployment will fail. This could happen after migrating from a pre-4.6 Hyperic release, before the tc Server user is detected and recorded in the Hyperic resource record.

  • If Hyperic Agent is running as a non-root user, the WAR file owner and group are set to the Hyperic Agent user and group, and the file permissions are set to 640 so that members of the same group can read the file. If the tc Runtime user and Hyperic Agent user belong to the same primary group, the application will deploy when the tc Runtime instance starts up.

Hot Deploy

When you hot-deploy an application with Hyperic, the source WAR file is either uploaded to tc Server via the Hyperic Agent or copied from a file already on the computer. The tc Runtime instance writes the WAR file into its webapps/ directory, so it creates the file as the user and group currently executing the tc Runtime instance. The file permissions are determined by the umask of that user. This ensures that there should be no file permission conflicts during deployment.