Skip navigation


1 Post authored by: cgum

The purpose of this post is to create a reference on how to set up a server environment that helps support Jive Cloud app development.  In future posts, I may link back to this one to give people context for the environment that I'm working in.


Overview of what we'll be doing

- Create a new CentOS instance

- Create new non-root user with sudoer permissions

- Install prerequisite software/libraries

- Configure httpd

- Configure SSL

- Configure iptables


Once you're set up, this environment will help you to

- Use any server web app platform (ruby, Java, node, PHP, C#, etc.) - Note: For C#, IIS would be running on separate server

- Develop/debug from home or office

- Support UAT and production environments

- Exercise total control over firewall, routing, etc.



So, let's get started.

First thing we'll do is set up our server instance.  I always set up my server instances using some VM hosting service, like Rackspace or Amazon Web Services.  A good friend of mine (CTO of a web startup) just told me about a service called Digital Ocean.  They have a REALLY easy interface for creating new instances and they only use SSDs, so their disk IO performance is awesome.  They are inexpensive and their instances start up very quickly (less than a minute).  For simplicity, I'm going to walk you through the process of setting up a new instance using Digital Ocean, but you could really use any service you want.  After you get your instance set up, then we'll configure it.



Setting up a new CentOS instance on Digital Ocean

- Go to and sign up.

- You will receive an email to confirm your registration, click the link in it

- Next, you will need to set up payment - don't worry, it's cheap


- Add a credit card and you're ready to go

- Next, we'll create a "Droplet" - that's their term for VMs

- Click Droplets and then Create Droplet


- Next, you will set the hostname of your instance, the VM size, region, image type, and then create the "Droplet"


- Almost there...


- After the Droplet is created, check your email - they will send you the IP address of the new VM and the root user password (Note: there is also a way for you to create the VM using SSH keys instead of a root password.  In that case, follow the instructions to add the SSH keys and then you will have a new option when creating Droplets)



Configure your DNS

Now that you have your VM set up, you will need to create a DNS entry for it.  Here are some things to consider before you do this.  First of all, a little later, we're going to be setting up the server to support HTTPS.  I highly recommend that you just bite the bullet and set this up right.  Don't use self-signed certificates or anything like that.  Jive will barf on them (when doing webhooks callbacks, for instance) and will not provide much in the way of feedback to indicate what the problem is.  So set this stuff up right from the beginning and things will go much more smoothly.


I use GoDaddy to manage my domain and DNS.  You will need to do what you have to do to get this set up depending on your environment.  (This may require coordinating with your IT department - good luck with that.)


Add an "A" record that points the hostname that you entered when you created the Droplet (or other VM) to the IP address bound to the instance.  When you have finished this, you should be able to ping your instance by its host name.



Configure your instance

I do my development on a Mac, so I just use the terminal window to SSH into my new instance.  If you are on a PC, you'll use Putty or Cygwin (or whatever) to log in.  If you use Putty and you created your instance using SSH keys, you may have a little more work to convert your private key over the the format that Putty likes. Google it.  (Note to all you hackers: you can also configure Putty to use your instance as a proxy to get through your IT department's overly-restrictive firewall.  Shhhh, don't tell!)


Okay, so get a terminal window up and running and SSH into your new instance:


> ssh


You'll be prompted for your password - it came in the email.  (If you set everything up to use SSH keys, then I assume you know what you're doing and can use your key to log in.)



Create Non-root User

First, we'll add a new user, add them to the root group, change their password, and add them to the sudoers list.  (Note: I use vi, you can use emacs or nano or whatever you want)


> useradd myusername

> usermod -g root myusername

> passwd myusername


> vi /etc/sudoers


Look for a line in the file that looks like this:


root    ALL=(ALL)       ALL


Duplicate the line, adding the user that you just created:


root    ALL=(ALL)       ALL

myusername    ALL=(ALL)       ALL


Save the file (:w!) and exit (:q)


Now that your new user is created, exit your SSH session and log back in as that new user.  This is to save you from yourself.  I have actually accidentally deleted my root directory as the root user before.  It was a very bad thing to do.


> ssh



Install Prerequisites


> sudo yum update

> sudo yum install httpd

> sudo yum install mod_ssl openssl

> sudo yum install lsof

> sudo yum install git

> sudo yum install wget


httpd is your Apache web server.  mod_ssl and openssl are used to set up Apache (httpd) to receive requests over HTTPS.


Now that httpd is installed, we'll set it up so that it launches automatically as a service any time you restart the instance.  Finally, we'll start the service.


> sudo chkconfig --add httpd

> sudo chkconfig --levels 2345 httpd on

> sudo service httpd start


Update your software firewall (iptables)


Depending on the service/image that you used to create your VM, the default CentOS firewall may be either totally open or totally closed (only accepting SSH connections on port 22).  The following is the configuration that I use.  I am by no means a Linux expert, so if someone is and you want to offer any advice on a better way to configure iptables, let me know.


> sudo vi /etc/sysconfig/iptables


Delete (or comment out) what's already there and add this instead:






-A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

-A INPUT -p icmp -j ACCEPT

-A INPUT -i lo -j ACCEPT

-A INPUT -m conntrack --ctstate NEW -m tcp -p tcp --dport 22 -j ACCEPT

-A INPUT -m conntrack --ctstate NEW -m tcp -p tcp --dport 443 -j ACCEPT

-A INPUT -m conntrack --ctstate NEW -m tcp -p tcp --dport 80 -j ACCEPT

-A INPUT -j REJECT --reject-with icmp-host-prohibited

-A FORWARD -j REJECT --reject-with icmp-host-prohibited



Save the file (:w!) and exit (:q)


After updating the iptables configuration, you'll need to restart the iptables service.


> sudo service iptables restart


At this point, you should actually be able to make HTTP requests to your server.  If you want to see all the ports that it's currently listening on:


> sudo lsof -i -P


You should see that your sshd service is listening on port 22 and that httpd has a whole bunch of threads listening on ports 80 and 443.


If you navigate to your new server from a browser, you should see this page:





Getting an SSL certificate and setting up Apache to support HTTPS

For better or worse, I prefer to use a "wildcard" certificate.  They cost a little more, but I can put a wildcard certificate on any instance on the same domain, like,, etc. If that's not something you can do because of your IT policies, then just get a certificate for the hostname you specified earlier.  Like I said before, I use GoDaddy, and it was really easy to get my SSL certificate.  The first time I did it, I think the whole process took about half an hour.  Follow the instructions of the provider that is going to be issuing the certificate.  Once you have done all that, you should have the following three files.


1.  The SSL certificate itself (e.g. 18237563ksdjfh374.crt)

2.  The key file used to sign the certificate signing request (CSR) that you sent to the certificate provider  (e.g. myprivatekey.key)

3.  The SSL certificate chain file (e.g. ga_bundle.crt)


Make all of these files owned by and only read/write for the root user.


> sudo chown root:root mycertificatefile.crt

> sudo chown root:root myprivatekey.key

> sudo chown root:root gd_bundle.crt

> sudo chmod 600 mycertificatefile.crt

> sudo chmod 600 myprivatekey.key

> sudo chmod 600 gd_bundle.crt


Next, copy the files where they need to go.


> sudo cp mycertificatefile.crt  /etc/pki/tls/certs

> sudo cp myprivatekey.key  /etc/pki/tls/private

> sudo cp gd_bundle.crt  /etc/pki/tls/certs

Modify Apache's SSL configuration file


> sudo vi /etc/httpd/conf.d/ssl.conf


Look for these three entries and update them accordingly:


#   Server Certificate:

SSLCertificateFile /etc/pki/tls/certs/mycertificatefile.crt


#   Server Private Key:

SSLCertificateKeyFile /etc/pki/tls/private/myprivatekey.key


#   Server Certificate Chain:

SSLCertificateChainFile /etc/pki/tls/certs/gd_bundle.crt


Save the file (:w!) and exit (:q)


Set the server name in the Apache config file (httpd.conf).  If you don't do this correctly, calls from Jive may fail and it's very hard to debug this.


> sudo vi /etc/httpd/conf/httpd.conf


Look for this line:




And add the following line after it (updating, obviously, with your host name)





Save the file (:w!) and exit (:q)


> sudo service httpd restart


You did it!  After you restart the httpd service, you should be able to make requests to your server over HTTPS.  Double-check that it works in a browser.  Also in the browser, click the lock icon next to the https:// and make sure everything looks okay with the certificate.



Configuring Apache httpd to be a reverse proxy

This is really where the rubber meets the road.  We are going to use httpd to handle all the SSL stuff and forward requests coming into our server to go wherever we want them to.  For instance, we could have URLs that match a certain pattern go to our UAT or production app instances, or get forwarded right to our desktop computers at work or home.  This is REALLY, REALLY helpful for debugging any problems that might arise.


When you create Jive add-ons, you are going to specify a service_url property in the meta.json file.  This is the base URL that Jive will use for all communication with your app or service.  Since that URL can change for dev, production or UAT environments, I usually create Maven profiles (you could too if you are using Maven to build your project) to specify the different environments I'm using.  During the build process, I will use the maven-antrun-plugin to set the various properties of my meta.json file, depending on my profile.  I'll talk more about that in a future post.


Okay so let's say you have four different endpoints, your production app, your UAT app, and your work dev computer and your home dev computer.  I'll assume for a second, that you are running a Java-based app, hosted in Tomcat for your production and UAT environments, and for development, you are running a debugging session in IntelliJ or Eclipse at work or home.


We want the following routing rules:  ->  http://localhost:8080/my-cool-app-prod-v1.0.1  ->  http://localhost:8080/my-cool-app-test-v1.0.1  ->  (this is going straight to my dev computer at work)  ->  (this is going straight to my dev computer at home)


> sudo vi /etc/httpd/conf/httpd.conf


Look for a line like this:


#<IfModule mod_proxy.c>


Uncomment that line and put your mappings below it, like this:


<IfModule mod_proxy.c>

# production

ProxyPass /my-cool-app http://localhost:8080/my-cool-app

ProxyPassReverse /my-cool-app http://localhost:8080/my-cool-app



ProxyPass /my-cool-app-test http://localhost:8080/my-cool-app-test

ProxyPassReverse /my-cool-app-test http://localhost:8080/my-cool-app-test

#  Uncomment mapping below to direct traffic from UAT site to your dev machine

#  This is useful for when you want to attach a debugger to the running web app

#ProxyPass /my-cool-app-test

#ProxyPassReverse /my-cool-app-test

# dev

ProxyPass /my-cool-app-dev

ProxyPassReverse /my-cool-app-dev


# home

ProxyPass /my-cool-app-home

ProxyPassReverse /my-cool-app-home

Save the file (:w!) and exit (:q) and then restart the httpd service.


> sudo service httpd restart



That's all there is to it.  Once you've done this once or twice (assuming to are using a wildcard certificate), you should be able to get a new server instance up and running in about 10 or 15 minutes.  I have found this to be a very handy way to do development for apps running on Jive Cloud instances.  Maybe someone else will find this helpful as well.



Filter Blog