Super Guide: Installing ColdFusion 9 on CentOS Linux

February 7, 2011

Aaron West

31-Minute Read

This post is a followup to my previous guide to installing ColdFusion 9 on Ubuntu. While that post was all about the specifics to getting ColdFusion up and running on Ubuntu, this post is all about CentOS. The overall process is the same and I’m covering all the same steps, but the commands in this post are specific to the CentOS operating system. So why I’m writing this?

Overall, installing ColdFusion isn’t that big of a deal. But I’ve yet to see a guide or blog post that outlines all the other topics related to getting a decent ColdFusion server on CentOS up and running. That’s why I wrote this super guide, to outline what I believe is important to know about installing ColdFusion. Of course, I’m not covering every single possible detail, but I believe I’ve hit on all the major topics. Along the way I sprinkle in my own ideas, thoughts, and what I believe are best practices. After you read this post and walk through all the instructions you should have a very solid ColdFusion / Apache set up on CentOS Linux.

There are two important things to note, so please read on.

Everything you will read, all paths, and every setup aspect is written specifically for CentOS. I’ve tested these instructions on CentOS 5.5, but they should be applicable to other recent versions. If you need instructions for Ubuntu, please read that guide here.

Secondly, and this is extremely important, all commands throughout this post are assumed to be run as root. Some of the commands can be run without root, but most of them cannot. So please, log into your CentOS server using the root account, put sudo in front of every command, or run the su - root command (under a non-root account) before walking through the instructions.

Secondly, and this is extremely important, all commands throughout this post are assumed to be run as root. Some of the commands can be run without root, but most of them cannot. So please, log into your CentOS server using the root account, put sudo in front of every command, or run the su - root command (under a non-root account) before walking through the instructions.

Before we get going, here’s a list of what I’ll be covering:

Creating a Linux user for ColdFusion
Disabling SSH and FTP login for the coldfusion user account
Installing the required libstdc++.so.5 C++ Library
Running the ColdFusion installer
Starting ColdFusion for the first time
Installing the ColdFusion 9.0.1 updater
Verifying the installation of 9.0.1
Creating a new ColdFusion instance for general use
Tweaking the JVM memory settings
Hooking Apache and ColdFusion together
Getting the Apache Connector running with selinux
Locking down Apache
Configuring ColdFusion to start on system boot

Create a Linux user for ColdFusion

Generally speaking it’s a good idea to run each Linux service under its own Linux user account. This allows you to tailor the security and permissions of the service based on your application or business needs. When you install ColdFusion on Linux you will be asked which user account you want the service to run as. Create the user account using the command below. You don’t have to use the same username I am, but if you choose something different remember it as it’ll be needed later. The useradd command on CentOS will create a user account and group account of the same name. It’ll also create a home directory for the user in /home/coldfusion/. You won’t be prompted to create a password for the user account but that’s okay as we’ll be disabling remote logon in a moment.

useradd coldfusion

When you create a Linux user account the account comes with the ability to login to the server via SSH. This is generally a good thing but not when you are creating an account for the sole purpose of running an application as a service. The coldfusion user account you just created isn’t meant to be used as a remote access account so let’s lock it down so no one can use it to access the server.

# Open the CentOS passwd file in a text editor. Nano or vim work great. I'm a
# huge fan of vim, but since nano is easier I'll show the instructions for nano.
nano /etc/passwd

Look for the line that starts “coldfusion:x:501:501…” Your numbers may be different from mine. It should be the last line in the file. Change the last part of the line that reads “/bin/bash” - which is the users shell - to “/sbin/nologin.” Here’s both of my lines, before and after.

# BEFORE: coldfusion:x:501:501::/home/coldfusion:/bin/bash
# AFTER
coldfusion:x:501:501::/home/coldfusion:/sbin/nologin

# Exit the file and save
CTRL-x [enter]
y [enter]

Get the ColdFusion 9 installation file (.bin on Linux)

There are several ways you can go about getting the installation file for ColdFusion 9. The easiest is probably by logging into your Adobe account and downloading either the 32-bit install file (coldfusion_9_WWE_linux.bin) or the 64-bit install file (coldfusion_9_WWE_linux64.bin). I highly recommend you go with a 64-bit installation as this will allow you to allocate much more RAM to the ColdFusion server than in a 32-bit environment. Of course, this requires you have a 64-bit version of CentOS installed as well. After you’ve downloaded the install file you need to transfer it to your Linux server. I generally use scp (Secure Copy) on my MacBook Pro to transfer the coldfusion_9_WWE_linux64.bin file directly to my server via SSH. Here’s an example showing how to do that. Whether you are on a Mac or not, use whatever you’re comfortable with.

# Format: scp [path_to_file_on_your_mac] [linux_username]@[remote_server_ip]:[remote_path]
# You'll be prompted to enter the password for the remote user.
scp /Users/aaron/Downloads/coldfusion_9_WWE_linux64.bin user@10.0.1.9:/install

Make the install file executable

Before you can run the installation file you need to make it executable. Navigate to the directory where you placed the file and run the change mod command to make it executable.

cd /install

# For the 32-bit installation
chmod +x coldfusion_9_WWE_linux.bin

# For the 64-bit installation
chmod +x coldfusion_9_WWE_linux64.bin

Install the required libstdc++.so.5 C++ Library

There’s one final thing you need to do before running the installer. ColdFusion 8 and 9 require the libstdc++.so.5 C++ library for a few features such as custom tags, Web Services and some cfimage functionality. Download and install the library using the package manager built into CentOS.

yum install libstdc++.so.5

Run the ColdFusion installer

You now have your server set up and ready for ColdFusion. You created a user account for ColdFusion to run as, you downloaded the ColdFusion install file, and you installed the required C++ library libstdc++.so.5. To begin the ColdFusion installation, execute the install file with the following command:

# Be sure and run this command in the same directory where the ColdFusion .bin is located.
cd /install

# For the 32-bit installation (Remember to run this as root; use sudo)
./coldfusion_9_WWE_linux.bin

# For the 64-bit installation (Remember to run this as root; use sudo)
./coldfusion_9_WWE_linux64.bin

The install process may take a few minutes to get going depending on your server specs. You’ll be presented with a multi-page license agreement that you have to accept in order to continue the installation. After that, you are presented with installation questions. Below are the install options and the choices I recommend.

Install type: 30-day trial Choose this option even if you have purchased a ColdFusion serial number. You’ll be able to enter your serial number in the ColdFusion Administrator after the initial installation.
Install configuration: Enterprise Multiserver configuration This will install a J2EE server (Adobe’s own JRun 4) and create an initial instance of ColdFusion. This install type provides the most flexibility and future growth opportunities as you will be able to deploy multiple instances of ColdFusion on the same Linux server. All running on a single copy of JRun 4. More on this later.
The installer tells says you cannot install the Enterprise Multiserver configuration if ColdFusion 9 or JRun4 is already on the server. If this is the case, select option two for “No.”
Subcomponent installation You have the option of installing ColdFusion 9 documentation, Solr Services, and Search Services. You can also instruct the installer to “Start ColdFusion on system init.” For a production server, you never want to install the documentation so I recommend unchecking that option by pressing the appropriate letter and then hitting enter. Make a decision on the other options (Solr Services and Search Services) and deselect them if you want. Finally, deselect the last option about starting ColdFusion on system boot. This install option generally works okay on Windows servers, but not on any Linux server I’ve tested other than Ubuntu 8.04. We’ll manually take care of this step using an CentOS-specific set up later. After you’ve selected your options, press 5 for “Continue with installation” and then press enter.
Install Folder The installer asks where you want to install JRun 4. The typical directory for JRun 4 on Linux is /opt/jrun4. All the ColdFusion instances you create will live in /opt/jrun4/servers/[instance-name]. At the end of these instructions you’ll have two ColdFusion instances in the /opt/jrun4/servers/ directory. Keep this option set to the default by simply pressing enter.
Earlier versions of ColdFusion The installer asks if you have earlier versions of ColdFusion installed on the server. You shouldn’t, so select the “No” option which should be the default.
Configure Web Servers You have the option to configure an existing Web Server (Apache since you’re on Linux) so requests for ColdFusion resources such as .cfm and .cfc files are routed through Apache and then ColdFusion via the Apache Connector. I do not recommend configuring a Web server during installation. Why? There are several reasons, but the most important one is how I use the initial ColdFusion instance that the installer creates. During the installation process JRun 4 will be installed at /opt/jrun4 and an initial ColdFusion instance (with the instance name cfusion) will be installed at /opt/jrun4/servers/cfusion. The cfusion instance of ColdFusion functions as the “master” or main instance. When you log into the ColdFusion Administrator of this instance, there’s a tool called Enterprise Manager that lets you create additional instances of ColdFusion. New instances you create do not have the Enterprise Manager tool and thus cannot create other instances. My recommendation, is to use the cfusion instance as a management instance only to create new instances. If you use it this way, there’s no reason to hook Apache to ColdFusion during installation, because Apache will get hooked to the cfusion instance. Instead, you’ll hook Apache to new ColdFusion instances later. You might be reading this and thinking: Okay, if I don’t hook Apache to the main (cfusion) instance of ColdFusion, how will I access the ColdFusion Administrator? Easy, instead of using an external (external to ColdFusion) Web server, you’ll use the built-in Web server that comes with ColdFusion. This Web server runs on a separate port starting at port number 8300 on a multiserver configuration of ColdFusion. I’ll spend more time talking about this setup and how it provides some additional security in a bit. Select the option to continue the installation without configuring a Web server.
Runtime user You created a new Linux user account for ColdFusion earlier. It’s now time to type the name of the user you created. If you didn’t vary from my instructions the user will be coldfusion. Either way, type the name of the user account and then press enter. Be careful though. If you mistype the name, and the name you type isn’t a valid user on the server, you will not be able to start ColdFusion after the installation.
Configure OpenOffice I almost always skip the installation of OpenOffice components, but if you need them go ahead.
Administrator Password You are prompted to create a password for the ColdFusion Administrator Web app. Type your password and press enter. You will then need to confirm the password by typing it again. Press enter.
Enable RDS RDS or Remote Development Services allow a client machine - such as the machine you use to write code - to connect to the ColdFusion server for line debugging, report builder integration, Dreamweaver extensions, introspecting datasources, and more. For security reasons, never, ever enable this on a production server. My recommendation, is to ONLY enable this on the ColdFusion server running on your personal computer such as your development laptop. There are situations where it might be feasible to enable RDS on a server, such as a staging server. But covering all the possibilities in these instructions would be off topic. As a general rule, enable RDS on development servers only. Press “N” to disable RDS and then press enter.
Installation summary The installer displays a summary of the installation options you selected. Double-check your selections and if something is wrong type “quit” at the prompt and start over (by running the .bin file again). Yes, I realize having to do this sucks. I don’t know of a way to selectively change one incorrect choice; you have to quit the installer as a whole and rerun it. If everything in the summary looks correct, press enter to start the actual installation. Wait for the installer to finish which generally takes a few minutes.
Installation Complete After the installation is finished you will see a success screen that tells you to start ColdFusion and run the Configuration Wizard. The wizard isn’t something you have to run specifically, as the first time you launch the ColdFusion Administrator the wizard will run for you. You are given a URL for the ColdFusion Administrator:

http://[machinename]:8300/CFIDE/administrator/index.cfm

Start ColdFusion for the first time

You’re now ready to start the ColdFusion server for the first. Below are two options for doing this.

# Start CF without navigating to the /opt/jrun4/bin/ directory. (don't forget sudo if you need it)
/opt/jrun4/bin/jrun start cfusion &

# Start CF by navigating to the /opt/jrun4/bin/ directory first. (don't forget sudo if you need it)
cd /opt/jrun4/bin

./jrun start cfusion &

Finish the ColdFusion installation in your browser

Open your favorite browser and copy/paste the following into the address bar. Change machinename to the IP address of your server. A local IP such as 10.x.x.x or 192.x.x.x will work if you are connected to a server in your office or you are connected to an external server via VPN. You might also be able to use the external IP of the server. Or, if the server is already hosting a domain name, you could change machinename to yourdomain.com.

http://[machinename]:8300/CFIDE/administrator/index.cfm

After loading this URL you should see a ColdFusion-branded Configuration and Settings wizard screen with a password prompt. Enter the password for the ColdFusion Administrator you created during installation and press enter. ColdFusion will do a few things and then show a new screen with an okay button. Press the button to go straight to the main screen of the ColdFusion Administrator.

Install the ColdFusion 9.0.1 updater

Generally at this point, we’d be ready to create a new ColdFusion instance for everyday use. But our ColdFusion server is not up-to-date. Adobe released ColdFusion 9.0 at their annual MAX conference in October of 2009. Then, on July 13, 2010 they released ColdFusion 9.0.1. Before we create a new ColdFusion instance we need to install the 9.0.1 updater which is not cumulative. This means the 9.0.1 updater requires an existing installation of 9.0. Fortunately, you just completed the 9.0 installation. The basic steps for getting ColdFusion 9.0.1 installed are to stop all running CF services, download the 9.0.1 updater from Adobe, transfer it to the CentOS server and run it.

Shutdown all running ColdFusion and JRun services. To get a list of all currently running services use the following command.

/opt/jrun4/bin/jrun status

For each instance that is running, issue the following command to stop it.

# /opt/jrun4/bin/jrun stop [instance_name]
/opt/jrun4/bin/jrun stop cfusion

Next, download the 9.0.1 updater from Adobe. Access the download site and choose ColdFusion 9 in the product list. You’ll be required to login using your Adobe account in order to download the update. Make sure you choose the appropriate download, 32-bit or 64-bit. Transfer the updater file - either ColdFusion_update_901_WWEJ_linux.bin for 32-bit or ColdFusion_update_901_WWEJ_linux64.bin for 64-bit - to your CentOS server just like you transferred the 9.0 install file earlier.

Before you can run the updater file you need to make it executable. Navigate to the directory where you placed the file and run the change mod command to make it executable.

cd /install

# For the 32-bit installation
chmod +x ColdFusion_update_901_WWEJ_linux.bin

# For the 64-bit installation
chmod +x ColdFusion_update_901_WWEJ_linux64.bin

Next, run the updater file.

# Be sure and run this command in the same directory where you put the updater.
cd /install

# For the 32-bit installation (Remember to run this as root; use sudo)
./ColdFusion_update_901_WWEJ_linux.bin

# For the 64-bit installation (Remember to run this as root; use sudo)
./ColdFusion_update_901_WWEJ_linux64.bin

An introduction screen will display giving you some information and instructions relating to the update process. Press enter to advance through the software license agreement screens. You’ll have to agree to the license agreement by pressing “y” and enter.

Configure Installation Select the option for Multiserver configuration by pressing number 2.
A warning about shutting down JRun and ColdFusion services appears. You’ve already shut down all services so press enter.
Configure ColdFusion 9 (step 1) The next screen asks you to select the root directory that contains JRun 4. The default install folder, /opt/jrun4, should be listed so press enter to accept the default since we installed using the default folder.
Configure ColdFusion 9 (step 2) You are asked for the full system path where the ColdFusion 9 CFIDE directory is located. The default directory should be listed as /opt/jrun4/servers/cfusion/cfusion-ear/cfusion-war/CFIDE. The default is correct based on how you originally installed ColdFusion 9. Press enter to accept the default.
Pre-Installation Summary Finally, you are shown a summary of the updater installation. Like before, you can type “quit” and press enter to exit the updater if something isn’t correct. If everything is correct, press enter to start the actual installation.
Installation Complete After the installation is finished you will see a success screen that tells you ColdFusion 9.0.1 was installed at /opt/jrun4. Press enter to exit the installer.

Verify the installation of 9.0.1

The 9.0.1 updater installer displayed a success screen but it’s always a good idea to verify the version number of ColdFusion actually changed. To do this we need to start the main cfusion instance of ColdFusion and log into the ColdFusion Administrator.

# Start CF without navigating to the /opt/jrun4/bin/ directory. (don't forget sudo if you need it)
/opt/jrun4/bin/jrun start cfusion &

Once ColdFusion has started load the CF Admin in your browser using the URL http://[machinename]:8300/CFIDE/administrator/index.cfm. This time you’ll see the regular login form for the administrator instead of the configuration wizard you saw the first time. Log into the admin and click the blue “i” icon in the upper right of your browser. This will display the System Information screen for ColdFusion. Look for the version number in the system info grid and verify it is 9,0,1,xxxxx. At the time of this writing, the correct version number is 9,0,1,274733.

Create a new ColdFusion instance for general use

Now that you have ColdFusion updated to 9.0.1 you’re nearly done with the main instance of ColdFusion. It won’t be used for everyday activities, but it will be used to create additional instances of ColdFusion. And since we only have the main instance at this point, we need to create a new instance for everyday use. You should already have the ColdFusion Administrator loaded in your browser.

In the left navigation look for the Enterprise Manager section header (the last one) and expand it by clicking on it. Next, click on the Instance Manager link. Begin the process of adding a new CF instance by clicking on the Add New Instance button.

A form will display asking you to complete a few fields. But, the only field you really need to complete is the first one where you choose a name for the new instance. Keep your choice simple, something like marketing, staging, dev, or similar will do. For this post I’m going with dev. After you type the name of the instance press the tab key or use your mouse to give one of the other form fields focus. Doing this should cause the name you typed to display at the end of the second form field for Server Directory. Press the Submit button. NOTE: If you had previously packaged an existing ColdFusion instance as an EAR (.ear Enterprise Archive file) or WAR (.war Web Application Archive) you could enter the path to the .ear or .war file to create the new instance from the archive file. This comes with several benefits such as migrating ColdFusion Administrator settings into the new CF instance.

The Enterprise Manager will now create and start the new CF instance in 4 steps. When it is finished the new instance will be available and started. To verify this, run the following command to list all running JRun services. You should see a new line in the output that indicates the dev instance is running.

/opt/jrun4/bin/jrun status

We’re done with the main cfusion instance and won’t be using it for the rest of these instructions. But before shutting it down, click the Instance Manager link in the left navigation again. Notice how the new dev instance shows in the Available Servers list. You can use the controls here to start, stop, restart, and delete the instance. You can also click the rightmost icon to load the ColdFusion Administrator for the instance. I typically start and stop instances from the Mac or Linux command line. For this reason I typically shutdown the cfusion instance and only start it if I need to create a new CF instance.

/opt/jrun4/bin/jrun stop cfusion

If you decide to keep the cfusion instance shut down you won’t be able to launch the CF Admin for the dev instance using the Enterprise Manager -> Instance Manager screen. So, you might want to write down or remember the CF Administrator URL for your dev instance, which is http://[machinename]:8301/CFIDE/administrator/index.cfm by default. The only difference in this URL and the CF Admin URL for the cfusion instance is the port number. The cfusion instance uses port 8300 and the dev instance uses port 8301. The Enterprise Manager we used to create the dev instance assigns new instances a port number of current_highest_port_number + 1.

Tweak the JVM memory settings

ColdFusion runs in a JVM (Java Virtual Machine) and as such it is limited to the amount of system RAM you allocate to the JVM. On the multiserver version of ColdFusion these memory settings are configured in the /opt/jrun4/bin/jvm.config file. There are several memory settings you can change in this file and covering them all is outside the scope of this post. Also outside the scope of this post are the values you should put for each of the memory settings. Each server, each environment, and each application is different. You must tailor the settings to your server, your environment, and your apps. The only way to do this is to monitor your applications use of memory and adjust the settings accordingly.

The two settings I do want to spend a little time on are the initial JVM heap and the maximum JVM heap. These settings are defined in the -Xms and -Xmx arguments to the JVM respectively. By default only the maximum heap is included in jvm.config and it starts out at 512m or 512 megabytes. This means the maximum amount of memory ColdFusion can occupy on your server is 512 megabytes. Depending on your server that may or may not be a very good starting point for your environment, server, and app. On a virtual server with a limited amount of RAM you might want to define a smaller maximum heap. Likewise, you may want to include an initial heap value - the amount of RAM that will be allocated to ColdFusion when ColdFusion starts up. I cannot tell you what values make sense, so it’s up to you if you want to change these settings. But, let’s say you want to set the initial heap value to 386 megabytes and the maximum heap value to 512 megabytes. To do this, you add the -Xms argument and leave the -Xmx argument the way it is.

After editing the line it should look something like this:

java.args=-server -Xms386 -Xmx512m

A few things to remember:

the settings configured in jvm.config are applied to each instance of ColdFusion. Given the memory settings above and 4 instances of ColdFusion, your maximum memory footprint on the server is approximately 2 GB. Make sure your server has enough RAM to accommodate your settings.
the megabyte values must be divisible by 32. In other words, a value of 300 for either Xms or Xmx is technically invalid
-Xms cannot be larger than -Xmx (if you try this, you will get an error when trying to start instances)
You technically don’t have to define -Xms or -Xmx as arguments to the JVM. Your instances will still start up without these values. But, the amount of memory that gets allocated to each instance seems to vary server-to-server and I’ve yet to figure out why. As a general rule, I recommend providing the -Xmx argument at a minimum.
any changes made to jvm.config will be applied to a CF instance the next time it starts

If you made changes to jvm.config, as I did above, you need to restart the dev instance so your changes will take affect.

/opt/jrun4/bin/jrun restart dev &

Hook Apache and ColdFusion

So far, each time we’ve accessed the ColdFusion server from a Web browser we’ve done so through the built-in Web server that comes with ColdFusion (port 8300 for the cfusion instance and 8301 for the dev instance). The built-in Web server is great for accessing things like the ColdFusion Administrator but it’s not ideal for anyone other than yourself. No one wants to remember what port to put in a URL. To get around this, you “hook” ColdFusion to an external Web server such as Apache or Internet Information Server (IIS). Since we’re working with an CentOS server Apache is what we’ll use.

Once ColdFusion and Apache are hooked together, any HTTP request for files ending in .jsp, jws, .cfm, .cfml, .cfc, .cfr, and .cfswf will first be sent to Apache. Apache will recognize these file extensions as pertaining to a special JRun/CF module and it will pass the request through to ColdFusion. ColdFusion will perform whatever tasks are programmed in the file - which is typically a .cfm or .cfc - and it will return the processed result. Apache will then return the result to the browser in an HTTP Response. You can think of the Apache Connector as a sort of low-level HTTP proxy to ColdFusion, although this is not technically correct.

There’s a caveat to connecting ColdFusion and Apache on RHEL (RedHat Enterprise Linux), CentOS and other distributions that come with SELinux (Security Enhanced Linux). This service, if running in ENFORCING mode (which is the default), will not permit Apache and ColdFusion to communicate with one another via the Apache Connector.

To see if selinux is installed and running in enforcing mode on your system, run the following command.

cat /selinux/enforce

An output of 0 means selinux is in permissive mode, while 1 means enforcing mode. If you get an error, it probably means selinux isn’t installed. If selinux is running in enforcing mode you’ll need to temporarily put it in permissive mode, install the Apache Connector, and then configure the security context of the connector to work properly with selinux in enforcing mode.

If your output from the command above was a 1, run the following command to put selinux in permissive mode.

echo 0 >/selinux/enforce

# You can run the following again to verify you now get an output of 0.
cat /selinux/enforce

Another prerequisite to connecting Apache and ColdFusion is installing the httpd-devel package. If you skip this step and attempt to run the Apache Connector, you’ll get the following error:

Could not find the required apxs (Apache Extension Tool) binary /usr/sbin/apxs. Check that package httpd-devel package is installed. Could not build Apache2 web server connector from source.

Install the httpd-devel package:

yum install httpd-devel

Finally, verify the ColdFusion instance you want to hook to Apache is running. The Apache Connector tool will not work if the instance is shut down. Run the following command and make sure the dev instance is listed as running.

/opt/jrun4/bin/jrun status

If the instance isn’t running, be sure to start it using the jrun start command discussed already. With the dev instance running you’re ready to run the wsconfig tool.

You’re finally ready to run the Apache Connector tool. On Linux, this involves executing a single command (wsconfig, which comes with JRun/ColdFusion) with several arguments passed to the command. Here’s a quick run down of the arguments:

-ws (generic name of the Webserver) -dir (directory where the Web server configuration lives) -server (the instance name of the ColdFusion server we want to hook) -bin (the location of the Web server binary) -script (the location of the Web server configuration/control file) -coldfusion (the fact that we’re hooking coldfusion) -ws64 (used to configure a 64-bit connector on a 64-bit Linux install only) -v (run the wsconfig command in verbose mode)

Type the following command which should be entered on one line. If the line wraps in your terminal screen, that’s okay. Press enter after typing the command.

# For the 32-bit installation
/opt/jrun4/bin/wsconfig -ws Apache -dir /etc/httpd/conf -server dev -bin /usr/sbin/httpd -script /usr/sbin/apachectl -coldfusion -v

# For the 64-bit installation (the only difference here is the -ws64 argument)
/opt/jrun4/bin/wsconfig -ws Apache -dir /etc/httpd/conf -server dev -bin /usr/sbin/httpd -script /usr/sbin/apachectl -coldfusion -ws64 -v

The wsconfig tool should list several lines of output. If you want to verify the command worked you can open Apache’s global configuration file, httpd.conf, in a text editor and look for the addition of an block of code. This block of code will reference the connector module, mod_jrun22.c, and the IP address that’s bootstrapped. The IP might be 127.0.0.1 depending on your server set up. That shouldn’t pose any problems, but you can manually change the IP to the static IP of your server if you want. Just be sure and leave the port number after the IP. And if you do change the IP, you’ll need to restart Apache for the change to take affect.

# Stop/start Apache forcing config reload
service httpd reload

You’re now ready to test a simple ColdFusion page to see if the Apache and ColdFusion connection is working properly. You’ll create a simple index.cfm file in the default Apache webroot and access it in a browser.

# Use the CentOS text editor of your choice.
nano /var/www/html/index.cfm

# Add the following to the new file.
<cfoutput>#Now()#</cfoutput>

# Exit the file and save
CTRL-x [enter]
y [enter]

Now open your Web browser and access your server using the URL http://[machinename]/index.cfm. Replace machinename with your server’s IP address or domain name. If you enter the right URL, and Apache and ColdFusion are successfully hooked you should see the current server date and time in your browser. If everything worked you are ready to create additional Apache virtual hosts, define your Web sites, and start writing ColdFusion code.

Get the Apache Connector running with selinux

Earlier I mentioned the Apache Connector and selinux don’t play well together with selinux in enforcing mode. While it was easy to get around this by temporarily putting selinux in permissive mode, it’s not difficult to get the two to play nicely together so let’s take care of that.

First, stop Apache and your dev ColdFusion instance.

/opt/jrun4/bin/jrun stop dev
service httpd stop

Now, run the following commands:

# Set the Apache Connector to run in the same selinux security context as other Apache modules.
chcon --reference=/etc/httpd/modules/mod_auth_basic.so /opt/jrun4/lib/wsconfig/1/mod_jrun22.so

# Set the Apache Connector to use the proper selinux user security context
chcon -u system_u /opt/jrun4/lib/wsconfig/1/mod_jrun22.so

# Set the security file label of the jrunserver.store file to that of a regular static html file.
# This eliminates errors in the Apache logs.
chcon -R -h -t httpd_sys_content_t /opt/jrun4/lib/wsconfig/1/jrunserver.store

# Configure selinux to allow scripts to connect to Apache
setsebool -P httpd_can_network_connect=1

Finally, put selinux back into enforcing mode and start your dev ColdFusion instance and Apache.

# Put selinux into enforcing mode
echo 1 >/selinux/enforce

# Verify selinux is in enforcing mode
cat /selinux/enforce

# Restart the dev ColdFusion instance and Apache
/opt/jrun4/bin/jrun start dev &
service httpd start

To verify everything is working properly go back to your browser and be sure you can run the index.cfm template you created earlier (http://[machinename]/index.cfm). If the server date/time shows up, you’re golden.

FINAL NOTE ON selinux: I recommend double-checking the system level setting for selinux. You can do this by opening the /etc/selinux/config file and ensuring you see a line like SELINUX=enforcing. When Linux boots up it looks at the setting in the /etc/selinux/config file and configures selinux accordingly. If you’ve temporarily put selinux in permissive mode, but the config file has SELINUX=enforcing, your temp setting will be reversed during the next system boot. While I don’t recommend this, if you get frustrated with selinux you can permanently disable selinux by changing SELINUX=enforcing to SELINUX=disabled, and rebooting your server. There’s also some good info on selinux here.

Lock down Apache

Earlier I mentioned I don’t use the ColdFusion Administrator for the main cfusion instance except to create additional instances of ColdFusion. I typically leave the cfusion instance shut down unless I need it. To increase the security of my ColdFusion Administrator I also never access it through a Web server like Apache. Instead, I use the built-in Web server that comes with ColdFusion by loading the proper URL plus port number of the CF Admin I need to use. This is a nice start to security but you can always do more.

Another way I typically lock down my CF Administrator is by adding the following code to Apache’s global configuration file, httpd.conf.

# Open the global Apache config file
nano /etc/httpd/conf/httpd.conf

# Add the following Location directive in the file. For CentOS, I typically add this block of code just before the VirtualHost definitions.
<Location ~ "/CFIDE/administrator">
Order Deny,Allow
Deny from All
</Location>

# Exit the file and save
CTRL-x [enter]
y [enter]

In the event someone was to try and access my ColdFusion Administrator using a URL like http://mydomain.com/CFIDE/administrator/index.cfm, Apache stops them. This Location directive looks at the URL for the string sequence “/CFIDE/administrator” anywhere in the URL. If the sequence is found, Apache denies the request. I highly recommend implementing both these solutions, accessing your CF Admins from the built-in Web server, and disallowing any URL that looks like the CF Admins URL. Is this enough security? The answer depends on what you consider enough. I personally feel there can never be enough security to protect your customers and your business. There is a point where security begins to negatively impact developers, system admins, and daily work, so you need to judge what is secure enough for you. A final recommendation I have about locking down the CF Admin, is to access the built-in Web server via a private IP address such as 192.x.x.x or 10.x.x.x. You can do this with Virtual Private Networks and other setups. An attacker would need to first infiltrate your network and obtain an IP address on the network before the IP range 192.x.x.x or 10.x.x.x would be traversable. For more information on blocking the ColdFusion Admin from Apache, see my other post on the topic.

Configure ColdFusion to start on system boot

If you’ve gotten this far you’ve accomplished a lot in getting ColdFusion installed and configured on CentOS. You created a Linux user the ColdFusion server can use (though it isn’t use it yet) and you removed remote access from the user. You installed ColdFusion 9.0 and the 9.0.1 updater. You created a second ColdFusion instance for daily use and tweaked the JVM memory settings each ColdFusion instance will use. Next, you hooked ColdFusion and Apache together so your sites can benefit from all the Apache goodness, and so you can access CF resources without a port number in the URL. Finally, you locked down your ColdFusion Administrators by editing the Apache server configuration.

That’s a nice list of accomplishments, but there’s one important thing left to do. You need to configure the ColdFusion service so it starts when your CentOS server boots up. When we installed ColdFusion we explicitly skipped this step so we could manually set it up. And I think this is a better way to go.

To get this working you’ll create a script that will function as a service. You’ll store the script file in the /etc/rc.d/init.d directory and then add and configure the script to run as a service.

Create the service script

# Navigate to the /etc/rc.d/init.d directory
cd /etc/rc.d/init.d

# Create a new file that functions as the service.
# Use cf-[instance_name] where instance_name is the name of your CF instance
nano cf-dev

# Paste all of the following code into the file. Specifically, paste everything that
# is between the start of file indicator and end of file indicator.
# ---------------- start of file below this line
#!/bin/bash
#
# Startup script for ColdFusion
# chkconfig: 345 90 14
# description: Start/stop ColdFusion as service
#
INSTANCE_NAME="your_instance_name"
# Source function library.
. /etc/rc.d/init.d/functions
#
case "$1" in
start)
echo -n "Starting CF $INSTANCE_NAME: "
/opt/jrun4/bin/jrun -start $INSTANCE_NAME &
echo
;;
stop)
echo -n "Shuting down CF $INSTANCE_NAME: "
/opt/jrun4/bin/jrun -stop $INSTANCE_NAME
echo
;;
restart)
/opt/jrun4/bin/jrun -restart $INSTANCE_NAME &
;;
*)
echo "Usage: $0 {start|stop|restart}"
exit 1
esac
exit 0
# ---------------- end of file above this line

This script, when set up as a service, allows you to start, stop, restart, and get the status of the running ColdFusion instance. After you paste the script into the cf-dev file there is one line you need to change. This script is going to specifically start the dev CF instance when CentOS boots up so we need to change the INSTANCE_NAME variable.

# Find the following line: INSTANCE_NAME="your_instance_name"
# Change it so it looks like this
INSTANCE_NAME="dev"

# Exit the file and save
CTRL-x [enter]
y [enter]

The INSTANCE_NAME variable is a string that should be the exact same name of the CF instance that shows in the /opt/jrun4/servers directory. Now, we need to make the cf-dev file executable and add it as a service.

# Make the script executable
chmod +x cf-dev

# Add the script as a service
chkconfig --add cf-dev

After running these commands you can reboot your server and ensure your dev instance of ColdFusion starts automatically. You can do this by running the jrun status command (examples above) or by hitting your test index.cfm page you created earlier in the /var/www/html directory. To reboot your server now, run the following command.

reboot

aaron west