Parallels Cloud Server 6.0 (PCS) is a virtualization solution that allows you to run multiple virtual machines and Containers on a single physical server.

In this topic, we install PCS on Vmware

And then, we click Agree

Select type keyboard for install

Then set hostname for PCS

In step we format disk for install

That okie. We can using it for Our cloud.

Configure Apache for SSL HTTPS CentOS 6

Using Apache over HTTPS or SSL allows a slightly more secure setup, any computer that connects over ssl is automatically encrypted.

Original Reference:

http://xmodulo.com/2014/04/https-apache-web-server-centos.html

Here’s the basic instructions:

Login to your server, and su to root

install modssl and openssl

The next Large step is to generate a self-signed certificate

create a Private Key

done

now you must generate the CSR, or Certificate Signing Request

Fill in all the necessary fields, this will be different for almost every scenario

Finally, Generate a Self-Signed Certificate for the Life of the Server, 365 days * 7 (allowing up to 7 years)

you should see signature OK

now copy the necessary files to the appropriate directories:

Now all we have to do is set-up Apache to use the certificates:

Edit the Apache SSL.conf

Comment Out Line 105, and add 106

now do the same for 113 and 114

### The following parameter does not need to be modified in case of a self-signed certificate. ### ### If you are using a real certificate, you may receive a certificate bundle. The bundle is added using the following parameters ### SSLCertificateChainFile /etc/pki/tls/certs/example.com.ca-bundle (reference below)

now restart apache

the webserver should now be able to use HTTPS.

That’s it!

Original Reference:

http://xmodulo.com/2014/04/https-apache-web-server-centos.html

We all know Varnish is awesome. I went as far as presenting a topic on Varnish then writing about it. This is a known fact.

However, what happens to all that caching goodness when you want to run your entire site over SSL? Out of the box, Varnish doesn’t support it. While I’ve heard some mention that not supporting SSL is an oversight,there exists some very sound reasoning for why not.

So how do people terminate SSL?

• Nginx – How Acquia, my employer does it
• Stunnel – Software I’m fond of
• Pound – My preferred method
• Apache – mod_ssl

What is Pound?

Without copying exactly what’s on the Pound documentation, or theWikipedia entry about Pound, it’s essentially a reverse proxy, SSL terminator and load balancer but NOT a webserver. It’s small, easy enough to install and has minimal configuration. Stunnel is similarly simple, but since I have quite extensive experience using Stunnel, I decided to learn something new.

On my load balancing servers, Pound listens on port 443 and Varnish listens on port 80. When traffic comes in on port 443, it hits Pound, gets decrypted using my server certificate and then gets passed to Varnish on port 80. By putting all traffic through Varnish, I’m able to take advantage of its caching ability for both HTTP and HTTPS traffic.

It’s almost, that simple. I had to make some minor changes to my VCL to receive and cache mixed mode traffic. Prior to these changes, I would sometimes deliver resources using the HTTP schema to pages delivered over HTTPS. This had the understandable effect of causing my browser to complain about insecure resources.

Getting Varnish and Pound to play nicely

Realising that we need to handle HTTP/HTTPS traffic differently in Varnish, even though it all comes in on port 80, I decided to use a separate cache hash key for each. Varnish uses hashes of the URI as a key to store and look up data by. My VCL implements the vcl_hashsubroutine to detect HTTPS traffic and alter the hash key. We add a header in Pound to tell Varnish that the traffic came in over SSL and then watch the magic happen.

pound.cfg

ListenHTTPS
  Address 0.0.0.0
  Port 443
  HeadRemove "X-Forwarded-Proto"
  AddHeader "X-Forwarded-Proto: https"
  Cert "/etc/ssl/certs/adammalone.net.pem"
End
 
Service
  HeadRequire "Host:.*adammalone.net.*"
    Backend
      Address 127.0.0.1
      Port 80
    End
End

default.vcl – vcl_hash {}

sub vcl_hash {
  hash_data(req.url);
  if (req.http.host) {
    hash_data(req.http.host);
  } else {
    hash_data(server.ip);
  }
  # Use special internal SSL hash for https content
  # X-Forwarded-Proto is set to https by Pound
  if (req.http.X-Forwarded-Proto ~ "https") {
    hash_data(req.http.X-Forwarded-Proto);
  }
  return (hash);
}

The hash_data function allows us to add further information to the hash. By adding ‘https’ to the host and uri information, we’re altering the hash in such a way that it is different from just the host + uri that an http request would use.

I’ve also attached a downloadable copy of my full Pound config and the puppet manifest that generates it for people who are interested in replicating this functionality. I’m using my Pound puppet class located at typhonius/puppet-pound, a fork of mrintegrity/puppet-pound.

Drupal configuration

The final thing to do is to inform Drupal it needs to be in SSL mixed mode and to enter a small snippet in my settings.php so it can be turned on or off based on the incoming request. If Varnish is running on the same server as your Drupal installation, you’ll need to replace www.xxx.yyy.zzz with 127.0.0.1. Otherwise it’ll be the IP of your load balancing server.

// Varnish Settings
$conf['reverse_proxy'] = TRUE;
$conf['reverse_proxy_addresses'] = array('www.xxx.yyy.zzz');
$conf['reverse_proxy_header'] = 'HTTP_X_FORWARDED_FOR';
$conf['page_cache_invoke_hooks'] = FALSE;
 
if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] == 'https') {
  $_SERVER['HTTPS'] = 'on';
}

This is how I allow SSL through Varnish, if you do it differently, add a comment!

You can download the latest JDK here: http://www.oracle.com/technetwork/java/javase/downloads/index.html

We’ll install JDK 7, Update 60 (7u60). The JDK is specific to 32 and 64 bit versions.

My CentOS box is 64 bit, so I’ll need: jdk-7u60-linux-x64.tar.gz.

If you are on 32 bit, you’ll need: jdk-7u60-linux-i586.tar.gz

Start by creating a new directory /usr/java:

[root@srv6 ~]# mkdir /usr/java

Change to the /usr/java directory we created

Download the appropriate JDK and save it to /usr/java directory we created above.

Unpack jdk-7u60-linux-x64.tar.gz in the /usr/java directory using tar -xzf:

This will create the directory /usr/java/jdk1.7.0_60. This will be our JAVA_HOME.

We can now set JAVA_HOME and put Java into the path of our users.

To set it for your current session, you can issue the following from the CLI:

To set the JAVA_HOME permanently, however, we need to add below to the ~/.bash_profile of the user (in this case, root).
We can also add it /etc/profile and then source it to give to all users.

Once you have added the above to ~/.bash_profile, you should log out, then log back in and check that the JAVA_HOME is set correctly.

Note: If you decided to use JDK 6 rather than 7 as we did above, simply save the JDK 6 bin file to /opt (or another location), then navigate to /usr/java and issue: ‘sh /opt/jdk-6u33-linux-x64.bin’. This will create a JAVA Home of /usr/java/jdk1.6.0.33

We will install Tomcat 8 under /usr/share.

Switch to the /usr/share directory:

Download apache-tomcat-8.0.8.tar.gz (or the latest version) here

and save it to /usr/share

Once downloaded, you should verify the MD5 Checksum for your Tomcat download using the md5sum command.

Compare the output above to the MD5 Checksum provided next to the download link and you used above and check that it matches.

unpack the file using tar -xzf:

This will create the directory /usr/share/apache-tomcat-8.0.8

We will now see how to run Tomcat as a service and create a simple Start/Stop/Restart script, as well as to start Tomcat at boot.

Change to the /etc/init.d directory and create a script called ‘tomcat’ as shown below.

And here is the script we will use.

The above script is simple and contains all of the basic elements you will need to get going.

As you can see, we are simply calling the startup.sh and shutdown.sh scripts located in the Tomcat bin directory (/usr/share/apache-tomcat-8.0.8/bin).

You can adjust your script according to your needs and, in subsequent posts, we’ll look at additional examples.

CATALINA_HOME is the Tomcat home directory (/usr/share/apache-tomcat-8.0.8)

Now, set the permissions for your script to make it executable:

We now use the chkconfig utility to have Tomcat start at boot time. In my script above, I am using chkconfig: 234 20 80. 2345 are the run levels and 20 and 80 are the stop and start priorities respectively. You can adjust as needed.

Verify it:

Now, let’s test our script.

Start Tomcat:

Stop Tomcat:

Restarting Tomcat (Must be started first):

We should review the Catalina.out log located at /usr/share/apache-tomcat-8.0.8/logs/catalina.out and check for any errors.

We can now access the Tomcat Manager page at:

http://yourdomain.com:8080 or http://yourIPaddress:8080

and we should see the Tomcat home page.

Tomcat 8 contains a number of changes that offer finer-grain roles.

For security reasons, no users or passwords are created for the Tomcat manager roles by default. In a production deployment, it is always best to remove the Manager application.

To set roles, user name(s) and password(s), we need to configure the tomcat-users.xml file located at $CATALINA_HOME/conf/tomcat-users.xml.

In the case of our installation, $CATALINA_HOME is located at /usr/share/apache-tomcat-8.0.8.

By default the Tomcat 8 tomcat-users.xml file will have the elements between the and tags commented-out. .

New roles for Tomcat 8 offer finer-grained access and The following roles are now available:

manager-gui
manager-status
manager-jmx
manager-script
admin-gu
admin-script.

We can set the manager-gui role, for example as below

Caution should be exercised in granting multiple roles so as not to under-mind security.

Getting the right heap memory settings for your installation will depend on a number of factors.

For simplicity, we will set our inital heap size, Xms, and our maximum heap size, Xmx, to the same value of 128 Mb

Simliarly, there are several approaches you can take as to where and how you set your JAVA_OPTS

Again, for simplicity, we will add our JAVA_OPTS memory parameters in our Catalina.sh file.

So, open the Catalina.sh file located under /usr/share/apache-tomcat-8.0.8/bin with a text editor or vi.

Since we are using 128 Mb for both initial and maximum heap size, add the following line to Catalina.sh

I usually just add this in the second line of the file so it looks as so:

In our Tomcat configuration above, we are running Tomcat as Root.

For security reasons, it is always best to run services with the only those privileges that are necessary.

There are some who make a strong case that this is not required, but it’s always best to err on the side of caution.

To run Tomcat as non-root user, we need to do the following:

1. Create the group ‘tomcat’:

2. Create the user ‘tomcat’ and add this user to the tomcat group we created above.

The above will create a home directory for the user tomcat in the default user home as /home/tomcat

If we want the home directory to be elsewhere, we simply specify so using the -d switch.

The above will create the user tomcat’s home directory as /usr/share/apache-tomcat-8.0.8/tomcat

3. Change ownership of the tomcat files to the user tomcat we created above:

Note: it is possible to enhance our security still further by making certain files and directories read-only. This will not be covered in this post and care should be used when setting such permissions.

4. Adjust the start/stop service script we created above. In our new script, we need to su to the user tomcat:

Note: the following applies when you are running Tomcat in “stand alone” mode with Tomcat running under the minimally privileged user Tomcat we created in the previous step.

To run services below port 1024 as a user other than root, you can add the following to your IP tables:

Be sure to save and restart your IP Tables.

As an alternative to running Tomcat on port 80, if you have Apache in front of Tomcat, you can use mod_proxy as well as ajp connector to map your domain to your Tomcat application(s) using an Apache vhost as shown below.

While Tomcat has improved it’s ‘standalone performance’, I still prefer to have Apace in front of it for a number of reasons.

In your Apache config, be sure to set KeepAlive to ‘on’. Apache tuning, of course, is a whole subject in itself…

Example 1: VHOST with mod_proxy:

Example 2: VHOST with ajp connector and mod_proxy:

In both vhost examples above, we are “mapping” the domain to Tomcat’s ROOT directory.

If we wish to map to an application such as yourdomain.com/myapp, we can add some rewrite as shown below.

This will rewrite all requests for yourdomain.com to yourdomain.com/myapp.

Example 3: VHOST with rewrite: