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.
Script to remove all versions of Java
Save the following as a batch script. I’ll let you work out the rest.
Eventcreate /L Application /T information /ID 69 /SO Remove-java.bat /D "Running J2SE Uninstall" wmic product where "name like 'J2SE Runtime%%'" call uninstall /nointeractive Eventcreate /L Application /T information /ID 69 /SO Remove-java.bat /D "Running Java(TM) Uninstall" wmic product where "name like 'Java(TM)%%'" call uninstall /nointeractive Eventcreate /L Application /T information /ID 70 /SO Remove-java.bat /D "Remove-Java.bat Completed"
How to fix: mktime(): It is not safe to rely on the system’s timezone settings
You might encounter a similar error message perhaps running wordpress or some other webapp.
[Tue Mar 12 09:41:14 2013] [error] [client 1.2.3.4] PHP Warning: mktime(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'Australia/ACT' for 'EST/10.0/no DST' instead in /var/www/html/smarty/plugins/function.html_select_date.php on line 192
To resolve either fix the code or an easy fix is edit: /etc/php5/php.ini or /etc/php.ini depending on your operating system.
Look for the line:
;date.timezone =
and make it:
date.timezone = 'Australia/Brisbane'
See a list of supported timezones from here: http://www.php.net/manual/en/timezones.php