Configure Wordpress 3.5 with Shibboleth2

Recently I installed Wordpress. There was a requirement to get Single Sign On (SSO) working for the admin users.
Googling for Shibboleth and Wordpress brings up a Wordpress plugin that hasn’t been updated in over two years.

There were some problems with this plugin:
1). It didn’t work. I thought I’d try it any way, it’s broken.
2). The plugin automatically creates users in the Wordpress DB if they don’t exist.
Ideally in our secure environments we don’t want users getting automatically created anywhere.

I thought about trying to fix the plugin, but considering I don’t really do PHP or Wordpress the time investment would be too high. Therefore I started looking for alternative SSO methods or rather SSO plugins. After thinking about how our other SSO based sites worked I remembered about the REMOTE_USER Apache variable. (Cue Google…)

The solution was to uninstall the broken Shibboleth2 plugin and install the ‘HTTP Authentication’ plugin here. Just ensure /wp-admin/ location in protected by Shibboleth and manually create the users in Wordpress. If they don’t exist in Wordpress then they fail to login…Exactly what we require!

Import signed certificate for VDI-in-a-Box - Java keystore

You’d think it would be easy to perform what should be a common task. Purchase a SSL certificate from an Issuer and install it your Citrix VDI-in-a-Box server. As anyone who has performed the same with Apache it is a fairly trivial task.
But because ViaB is some sort of black magic it is rather difficult, well that and the fact the java ‘keytool’ is fu%#*ing pain the a$$!

A lot of documentation reports that ‘The cerificate must be installed to the same keystore that was used to generate the CSR. If you try to install it to a different keystore it will not work.’
Even the stupid Citrix documentation doesn’t even tell you how to do it. What they do tell you to do is to generate the CSR on ViaB server and then get that signed! This doesn’t help the 99.99% of the world who have corporate certificates created another way!

But fear not - IT CAN BE DONE! It took me fair too long to work it out but no you can do it with ease! Please follow the directions to the letter. Please type the passwords on the command line, omitting them seems to make it not work. In my example I used DigiCert who supply four certificates in the chain of trust. If you received less that OK but make sure the order you do things in (PEM generation) is the same!

# Import all the damn certs in the chain into a PEM file:

cat www.yourwebsite.com.crt >> all-certs.pem
cat DigiCertCA.crt >> all-certs.pem 
cat DigiCertCA2.crt >> all-certs.pem
cat TrustedRoot.crt >> all-certs.pem

# Import the private key and create a PKCS12 file (that contains the full chain + private key)
openssl pkcs12 -export -in all-certs.pem -inkey www.yourwebsite.com -out all-certs.p12

# Now create a java keystore based on the PKCS12 file

keytool -importkeystore -deststorepass PASSWORD-GOES-HERE -destkeystore all-certs.jks \
-srckeystore all-certs.p12 -srcstoretype PKCS12 -srcstorepass PASSWORD-GOES-HERE

# Check the output (although you can't really tell if it's going to work until you try it...)
keytool -list -keystore all-certs.jks 

# Output should be similar to: 
Enter keystore password:                                                                                                                                     
                                                                                                                                                             
Keystore type: JKS                                                                                                                                           
Keystore provider: SUN                                                                                                                                       
                                                                                                                                                             
Your keystore contains 1 entry                                                                                                                               
                                                                                                                                                             
1, 15-Jun-2013, PrivateKeyEntry,                                                                                                                             
Certificate fingerprint (SHA1): xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx 

# Check the full certificate chain
keytool -list -v -keystore all-certs.jks 

# (DigiCert supplies four certifcates in this example)
# Check the order, it should be your www.yourwebsite.com, the Issuing CA, Issuing CA's Root, TrustedRoot Cert.

# Update the cert on the VDI server: 
ssh to vdi server as kvm
cd /home/kvm/kvm/install/servlet_container/conf
Backup the default keystore file:
mv .keystore old.keystore
Copy (SCP?) the new keystore file to the conf directory:
cp /home/kvm/kvm/install/servlet_container/conf/all-certs.p12 .keystore
Verify that the .keystore and old.keystore files exist:
ls –al

# Update the SSL Password in the configuration file:

Edit the server.xml file using the vi editor:
Find the clientAuth line by searching: /clientAuth=
Verify the keystorePass=”password” entry does not already exist in entire Define a SSL HTTP/1.1 Connector
 on port 8443 section. Add the following line, replacing “password” with your keystore password:
If keystorePass=”changeit” already exists in the section, simply replace the “changeit” with your
 keystore password.

# Note: Having two keystorePassword lines in the server.xml file may cause tomcat to fail when starting. 
Ensure there is only one instance of the keystorePassword.
Save and exit 

# Restart Tomcat Services
(as the kvm user)
tc_stop && tc_start

GlusterFS: host, is not befriended at the moment

When attempting to expand the replication distrubted file system of our cluster nodes I struck the error message:

[root@index03 ~]# gluster volume replace-brick drvol01 index04:/srv/gluster/drbrk02 index05:/srv/gluster/drbrk01 start
index05, is not befriended at the moment

Which was strange considering the previous ‘peer probe’ from another host to join the new server (index05) was successfully:

[root@index04 ~]# gluster peer probe index05
Probe successful 

I think the only clue was (on the last line):

[root@index03 drbrk02]# gluster peer status
Number of Peers: 4

Hostname: index02
Uuid: 31c0f246-0a8b-4c68-8ffa-42b2e6bb42ce
State: Peer in Cluster (Connected)

Hostname: index04
Uuid: ca61b983-b8fd-4fcc-848a-6c33f102cd5c
State: Peer in Cluster (Connected)

Hostname: index01
Uuid: b9bc474c-0017-4191-82b9-5760ba0d00fc
State: Peer in Cluster (Connected)

Hostname: index05
Uuid: c6a7cb83-4c1f-42ff-8421-bea9cc911d0f
State: Accepted peer request (Connected)

Anyway I confirmed that there were no firewall rules blocking the requests Doco: Gluster Firewall Ports and restarted the glusterd service on index05, which seems to have resolved the problem.

[root@index03 ~]# gluster peer status
Number of Peers: 4

Hostname: index02
Uuid: 31c0f246-0a8b-4c68-8ffa-42b2e6bb42ce
State: Peer in Cluster (Connected)

Hostname: index04
Uuid: ca61b983-b8fd-4fcc-848a-6c33f102cd5c
State: Peer in Cluster (Connected)

Hostname: index01
Uuid: b9bc474c-0017-4191-82b9-5760ba0d00fc
State: Peer in Cluster (Connected)

Hostname: index05
Uuid: c6a7cb83-4c1f-42ff-8421-bea9cc911d0f
State: Peer in Cluster (Connected)

In summary I believe there were firewall rules in place, when the ‘gluster peer probe index05′ was run. The rules were removed, but the gluster daemon on index05 then required a restart to become active in the cluster.