Total Pageviews

Showing posts with label apache. Show all posts
Showing posts with label apache. Show all posts

Wednesday, September 11, 2013

Pitfalls installing wordpress on a Linux box using Multisite with sub directories

This post is not about installing wordpress on a Linux box. It just covers two problems I have faced when installing wordpress 3.6 on my Ubuntu 12.04 box at home.
I did install wordpress using the distributed zip archive following the detailed instructions on the wordpress site. Setting up the database and editing the PHP config files was no problem.
The installation went smooth and everything was working as expected.

Problem 1: Configuring Multisite

Multisite is a great feature of wordpress. It gives you the ability to create more than one site (or blog) within your wordpress installation.
I did the setup using this step-by-step guide. So far so good. With my new multisite feature enabled I wanted to create a new site and filled in the necessary informations for it. The creation succeeded without an error and when I clicked on the dashboard of the newly created site I got a "Page Not Found" error.
Hm ... googling around I didn't really find a good answer.
I decided to check the network administration guide of the wordpress documentation and found a really helpful paragraph about using mod_rewrite (multisite feature needs mod_rewrite) and Apache Virtual Hosts.
My Apache installation is using virtual hosts so what finally did the trick was to add these lines to my VirtualHost section:


 <VirtualHost *:80>    
  <Directory /var/www/vhosts/wordpress>  
   AllowOverride Fileinfo Options  
  </Directory>  

Problem 2: Changing the domain name (or change the URL)

I am using DynDNS and I (and my users) want to access the wordpress installation from the internet. During the installation I did not realize that this was so important, because I thought I can change it easily afterwards. Well, changing it in a Non-Multisite environment is easy, but it turns out that a change of the domain name in a multisite installation is a little bit harder.
What helped me a lot was this documentation on the wordpress site.
Because my installation was totally fresh I skipped the step to make a backup of my database. I walked through all tables of the database and replaced every occurrence of my old domain name with the new DynDNS domain name.
Finally I changed the DOMAIN_CURRENT_SITE attribute in the wp-config.php file to point to the DynDNS name as well and after that my multisite wordpress installation was accessible via the DynDNS url.

I can't say whether it would have been easier to change the domain name before I activated the multisite feature, but it would make sense to me.

Anyway, it works now.

Thursday, March 01, 2012

Setting up an Apache cluster under RedHat Enterprise Linux

If it ever happens that you have to set up an Apache Linux cluster, I highly recommend the step-by-step manual from clusterlabs.org.
The docs are really easy to read and are very helpful.
I only have two negative points:

  1. Sometimes the commands you have to enter into the console are not clearly separated from the parameters or text you have to pass. Example:
    cat <<-END >>/etc/corosync/service.d/pcmkservice {
            # Load the Pacemaker Cluster Resource Manager
            name: pacemaker
            ver:  1
    }
    END
    The file to create is called /etc/corosync/service.d/pcmk (NOT pcmkservice) and the content of the file starts with "service {
    # Load the Pacemaker ..."
    I assume this has something to do with the formatting of the docs.
  2. The docs almost never tell you what to do in case things go wrong or you did a typo or your environment differs from the one used in the docs.
    In that case you have to use google and cross your fingers or use other resources like this one.
After all I only had to consult google once during the complete setup.
My failover tests succeeded after a few hours of setup including writing a howto for my specific setup.
Now the cluster works using corosync and pacemaker as services.

Thursday, February 02, 2012

Don't use commons lang < 2.4 with HtmlUnit

In case you have a project which has a dependency to Apache commons-lang and you plan to use the latest HtmlUnit (as of writing this post this is HtmlUnit 2.9) you should take care of the version of commons-lang.

HtmlUnit is using a method (startsWithIgnoreCase) from commons-lang that was introduced in commons-lang 2.4.
So any commons-lang version below 2.4 will produce runtime exceptions when using HtmlUnit. The stacktrace may be similar to this one:

 java.lang.NoClassDefFoundError: Could not initialize class  
 com.gargoylesoftware.htmlunit.WebClient  
     at net.sourceforge.jwebunit.htmlunit.HtmlUnitTestingEngineImpl.createWebClient(HtmlUnitTestingEngineImpl.java:804)  
     at net.sourceforge.jwebunit.htmlunit.HtmlUnitTestingEngineImpl.initWebClient(HtmlUnitTestingEngineImpl.java:813)  
   
 also :  
   
 java.lang.NoSuchMethodError:  
 org.apache.commons.lang.StringUtils.startsWithIgnoreCase(Ljava/lang/String;Ljava/lang/String;)Z  
     at com.gargoylesoftware.htmlunit.util.URLCreator$URLCreatorStandard.toUrlUnsafeClassic(URLCreator.java:66)  
     at com.gargoylesoftware.htmlunit.util.UrlUtils.toUrlUnsafe(UrlUtils.java:193)  
     at com.gargoylesoftware.htmlunit.util.UrlUtils.toUrlSafe(UrlUtils.java:171)  
     at com.gargoylesoftware.htmlunit.WebClient.<clinit>(WebClient.java:162)  
     at net.sourceforge.jwebunit.htmlunit.HtmlUnitTestingEngineImpl.createWebClient(HtmlUnitTestingEngineImpl.java:804)  
     at net.sourceforge.jwebunit.htmlunit.HtmlUnitTestingEngineImpl.initWebClient(HtmlUnitTestingEngineImpl.java:813)  
   
   
   

In case you use Maven as your build tool you can check the dependencies using the command:

mvn dependency:tree

To avoid this error you can declare version 2.6 of commons-lang in your project.

Thursday, July 02, 2009

Howto change password expiration in Apache Continuum

Apache Continuum is bothering me with regularly messages that my password has expired and I need to change it. Well, there is a way to turn password expiration completely off.
Just create the file

/path/to/continuum/conf/security.properties

with the following content:

security.policy.password.expiration.enabled=false
security.policy.password.expiration.days=90

 
No annoying password changes anymore. But keep in mind that this may be a security risk!
Another option is to extend the number of days a password needs to expire.
For a complete reference of available properties check the site:

http://redback.codehaus.org/configuration.html

Have fun!

Thursday, July 26, 2007

Howto configure SSL for Apache2

To enable SSL support in Apache2 the first step is to create a SSL certificate. If you are not among the lucky ones having apache2-ssl-certificate installed you can use the Linux shell script below to create a SSL certificate

#!/bin/bash
SERVER=your.server.com
PRIVATE_KEY=$SERVER.private.key
CERTIFICATE_FILE=$SERVER.crt
VALID_DAYS=365

echo Delete old private key
rm $PRIVATE_KEY
echo Create new private/public-keys without passphrase for server
openssl genrsa -out $PRIVATE_KEY 1024

echo Create selfsigned certificate
rm $CERTIFICATE_FILE
# From man req:
#  -x509
#    this option outputs a self signed certificate instead
#    of a certificate request. This is typically used to
#    generate a test certificate or a self signed root CA.
#    The extensions added to the certificate (if any) are
#    specified in the configuration file.

openssl req -new         -days $VALID_DAYS         -key $PRIVATE_KEY         -x509         -out $CERTIFICATE_FILE

echo private-keyfile is $PRIVATE_KEY
echo server-certificate-file is $CERTIFICATE_FILE

ls -l $PRIVATE_KEY $CERTIFICATE_FILE

The SERVER variable is very important. Please name your fully qualified server name there. After executing the script and answering the questions you've got two files: the certificate file (suffix .crt) and the key file (suffix .key).
Copy those two files into the directory /etc/apache2/ssl.
Now install the Apache2 ssl module: a2enmod ssl
The next step is to create a new virtual host for our https sites. Simply copy the default site to a new site called default-ssl:

cp /etc/apache2/sites-available/default /etc/apache2/sites-available/default-ssl


Replace the first two lines in the file with the following lines:

NameVirtualHost :443
:443>
# SSL (START)

SSLEngine on
SSLCertificateFile /etc/apache2/ssl/my.apache.crt
SSLCertificateKeyFile /etc/apache2/ssl/my.apache.key

SSLProtocol all
SSLCipherSuite HIGH:MEDIUM
# SSL (ENDE)


After this edit the file /etc/apache2/ports.conf and add the following line:

Listen 443


The last thing is to enable the site calling a2ensite default-ssl
Finally restart your Apache2: /etc/init.d/apache2 restart