Wikipedia defines a best practice as:
A method or technique that has consistently shown results superior to
those achieved with other means, and that is used as a benchmark. In
addition, a “best” practice can evolve to become better as improvements
are discovered. Best practice is considered by some as a business
buzzword, used to describe the process of developing and following a
standard way of doing things that multiple organizations can use.
With vFabric tc Server, we are building several conventions and other techniques into the software to form a core set of best practices. With this new installation method for tc Server, we are going beyond copying files. These steps implement a set of conventions designed to enhance the manageability, consistency, and security of a tc Server installation. For sysadmins, it isn’t a cure for “on the job insanity,” but it helps.
While my VMworld session will go into greater detail on overall best practices for tc Server, (APP-CAP1676, tc Server Best Practices for Security, Stability, and Sanity), this post provides some background on how the RPM Installation of vFabric tc Server works and facilitates runtime best practices.
VMware vFabric tc Server was created to merge the best of both worlds by adding enterprise-level deployment and administration functionality to the lightweight runtime of the Apache Tomcat application server. To that end, tc Server includes scripts and other tools to simplify deployment and maintenance. For example, it includes templates to encapsulate standard configuration elements, making it simple to deploy multiple, identical tc Server instances.
The ability to install tc Server on Linux with RPM and YUM is a recently added feature that further simplifies administration. Previous versions of tc Server were “installed” by simply unpacking an archive file. This made each individual administrator responsible for adhering to conventions, such as what user id tc Server should be run as, or what directory tc Server should be installed into. When the installation process enforces deployment and runtime conventions, administrators make fewer mistakes and are free to concentrate on other tasks.
This article describes the actions performed by the RPM installation (besides copying the tc Server files onto the target system). We point out the conventions involved so they can be understood and accounted for by persons administering the systems.
RPM Install Actions
The RPM install is described in the vFabric 5.1 documentation. The first step is to add the vFabric software repositories to the target system with the following rpm commands (run as root:
prompt# rpm -Uvh http://repo.vmware.com/pub/rhel5/vfabric/5.1/vfabric-5.1-repo-5.1- 1.noarch.rpm
prompt# rpm -Uvh http://repo.vmware.com/pub/rhel5/vfabric-all/vfabric-all-repo-1- 1.noarch.rpm
The rpm commands here are used on RHEL 5 systems. On RHEL 6 systems, the URLs of the rpm files are slightly different; replace
rhel6. After adding the repositories, you can use the yum command to install vFabric components. To install tc Server, run
prompt# yum install vfabric-tc-server-standard
Enter y at the prompt to begin the actual installation. If you have not already accepted the VMware license terms, a prompt asks you and you must answer
yes to continue.
If the installation is successful, you see a
Complete! message at the end.
The installation of tc Server with YUM/RPM performs the following actions.
1. Automatically downloads latest appropriate version
One of the values of this install mechanism is that selection and downloading of the correct rpm file for the software is done for you.
2. Create vfabric group
The RPM installation creates the Linux user group vfabric. This group is used as a common group for files installed as part any of the vFabric software packages, such as GemFire, or Hyperic.
3. Create tcserver user
The RPM installation creates the Linux user tcserver in the vfabric group. tc Server should be run as this user, rather than root, as a matter of security.
4. Create directory for tc Server instances
The RPM installation creates the directory /var/opt/vmware/vfabric-tc-server-standard, which is owned by the user tc Server with group attribute vfabric. This directory is intended to be used as target directory for creating tc Server instances. The directory /opt/vmware/vfabric-tc- server-standard and its subdirectories, where the tc runtime software is installed, are owned by root and hence are not suitable for the creation of tc Server instances, since the tc Server user can not write to them.
The implication of this convention for tc Server administrators is that when they create a new instance of tc Server with the tcruntime-instance.sh script, they should specify this target directory with the –i option. For example, as the user tcserver, from the directory /opt/vmware/vfabric-tc-server-standard, you would execute
prompt% ./tcruntime-instance.sh create node1 -i /var/opt/vmware/vfabric-tc-server- standard -t nio -t nio-ssl
5. Create bash completion files for tcruntime scripts
As part of the installation files are created in the directory /etc/ bash_completion.d, one for the script tcruntime-ctl.sh and one for tcruntime-instance.sh. These completion files enable the bash shell to provide intelligent completion of command options and arguments for those scripts. At any point in the typing of either a tcruntime-instance.sh command or a tc-runtime-ctl.sh command, you can hit TAB for a list of valid inputs. For example, pressing TAB after entering “./tcruntime-instance.sh “ prompts you with a list of the valid commands for the script. Note that you must have the bash_completion package installed on your system to use this feature.
Although, it’s not part of the RPM install, it’s worth pointing the new convenience script added to tc Server. The latest releases of vFabric tc Server provide a new script, quickstart/createInstance.sh, which simplifies the creation of an initial tc Server instance. It’s mentioned here as another way in which the developers of tc Server continue to improve the usability and convenience of the product.
Executing quickstart/createInstance.sh guides you through the creation and configuration of a tc Server instance with a bio and bio-ssl connector. You should run this script as the tcserver user. In sequence, the script prompts for
1. The directory in which to install the instance. This defaults to the directory /var/opt/vmware/vfabric-tc-server-standard (discussed previously).
2. The name of the instance. Default is
3. Whether to start the instance after it is created. Default is ‘N’, for no. At this point the script begins the creation process, before prompting for..
4. User account under which to run the instance when using the init.d script created with the instance. Default is “tcserver”.
5. Value for
base.jmxremote.password. Default is a randomly-generated string.
6. Path for the SSL keystore. Default is blank which creates a new keystore.If you choose to create a new keystore, the script will then prompt you for all of the attributes of the certificate created in the keystore, like number of bits in the SSL key, distinguished name, and so forth. After you enter all the information associated with the SSL certificate, you will be prompted for
7. Shutdown port. Default is -1, which means no shutdown port, the most secure option
8. JMX Socket Listener Port. Default is 6969.
9. BIO Connector Port. This is the port that tc Server will listen on for HTTP requests. Default is 8080.
10. Redirect Port for HTTPS. Default is 8443.
11. Listen Port for HTTPS. Default is 8443. In any case, the value entered here needs to match what was entered for the redirect port.
At the completion of the script, a new tc Server instance with the name you entered will have been created in the given directory. Assuming all the default values were accepted, and you chose not to start the instance at the completion of the creation script, you can now start it with the command
prompt% /var/opt/vmware/vfabric-tc-server-standard/EXAMPLE-INSTANCE/bin/tcruntime-ctl.sh start
Then verify that it started successfully by browsing http://:8080/.
We hope these conventions and techniques help you improve the management, consistency, and security of your tc Server installations. We certainly appreciate any feedback or thoughts in the comments below. If you are going to VMworld, I hope you have an opportunity to attend my session which goes broader and deeper into tc Server best practices (APP-CAP1676, tc Server Best Practices for Security, Stability, and Sanity).