Posts Tagged apache

How To Fix WordPress Automatic Upgrades in WordPress 2.5. – 2.7 (Plugins and WordPress)

Posted by clifgriffin in Technology on December 9th, 2008

Note: These instructions assume Apache is running as the user apache under the group apache. This may not be how your installation is setup.  For instance, my MediaTemple account runs apache under the user clifgriffin.com and the group clifgriffin.com.  Your mileage may vary.  Substitute your user and group for apache and apache in the instructions below.

If you’re looking for a quick solution, skip down to “The easy way”.

I manage three WordPress installations currently. Two are personal.  One is for my employer.  The personal installations are hosted with MediaTemple. The other is hosted internally on a Dell server with RedHat.

Quite awhile ago, I upgraded this WordPress installation to 2.5.1. At the time, I noticed that automatic plugin upgrades were not functioning, but I didn’t bother to figure out why.  After I upgraded to 2.7-RC1, I noticed that the same fate had befell WordPress upgrades. I couldn’t automatically upgrade WordPress or plugins.

When trying to upgrade, I would be presented with a screen asking for my FTP information, including hostname, username, and password.

So, today, armed with absolutely nothing else to do, I decided to attempt to fix this problem.  Initially, I was suspicious that the only way WordPress can do upgrades is by utilizing an ftp server on the current machine.  Fortunately, this was not the case–in fact its the last resort. While a few Google searches turned up nothing initially, I eventually found this which led me to this.  In this article, Keith outlays a few steps to fix this (if you need to fix this, do not perform the following steps…there is an easier way…read on):

  • Change the group for the wp-content/plugins directory to apache.
  • Manually define a WP_TEMP_DIR
  • Set write permissions for this folder and assign apache as the group for this folder as well.
  • Lastly, he recommends replacing the function getmyuid() with posix_getuid() in wp-admin/includes/file.php

This last step he identifies as either a bug or a feature. (He isn’t sure which.)

These steps seemed to fix the problem–especially the last one–but I wasn’t satifised the result. I’m using WordPress 2.7-RC1…that means this problem has persisted two major versions.  I decided to investigate further.

As Keith explaisn, getmyuid() and posix_getuid() return two different things.  getmyuid() returns the UID of the person who owns the script that is running.  posix_getuid() returns the UID of the process running the script.  This led me to believe that the underlying problem was not a bug and simply an issue of file ownership.

The easy way:

I reverted the changes to /wp-admin/includes/file.php and proceeded to do a recursive ownership change across my whole WordPress installation. I also made sure that wp-content/ was user writeable.  Simply put, run the following commands from the directory in which WordPress is installed:

chown -R apache:apache *
chmod 755 wp-content/

The first command sets both the owner and group of all files and folders in the current directory to apache.  It is important to do this because WordPress uses the apache user to accomplish the upgrade. If any of the files are owned by your user, root, or anyone else, it will fail.

After I made these changes, I was able to do all upgrades (both plugins and WordPress) with no issues.  Keith’s instructions are very nearly correct. They simply overlook the owner and focus on the group. The group may be important, but it isn’t the problem in this scenario.

If you do not have root access…

If you do not have root access, you will not be able to change ownership of the files.  You should be able to compensate for this with more liberal permissions.

If this is true for you, try setting wp-content/ to 775 instead of 755.

So, in short to enable automatic plugin upgrades on WordPress 2.5.1 and later:

  1. Change owernship and group of all WordPress files to apache.
  2. Make sure the wp-content/ directory is writeable by apache.

[Thanks to commenter Daniel for non-root user instructions.]

, , ,

18 Comments

Using mod_ldap With Apache

Posted by clifgriffin in Technology on December 8th, 2008

I did a small test of mod_ldap today. It wasn’t terribly difficult, but most guides online seemed to overly complicate the matter.

In my test, I chose a directory located off of my website root that I wanted to restrict to only users with an LDAP account.  (That’s any user…regardless of OU, Group, or hair color.)In this example, I’ll use http://server/ldaptest as my protected location and some.domain.com as my domain.

  • First, I setup a dummy index page in /var/www/html/ldaptest. (This location will vary obviously depending on your Apache installation)
  • Next, I opened my httpd.conf file (mine was in /etc/httpd/conf/httpd.conf) and made sure these two lines were present: 
    LoadModule ldap_module modules/mod_ldap.so
    LoadModule authnz_ldap_module modules/mod_authnz_ldap.so      

    This indicates that mod_ldap and mod_authnz_ldap (both necessary) are installed. 

  • Next, I added the following lines to httpd.conf:
    <Directory "/var/www/html/ldaptest">
    Order deny,allow
    Deny from All
    AuthName "Company.com Intranet"
    AuthType Basic
    AuthBasicProvider ldap
    AuthzLDAPAuthoritative off
    AuthLDAPUrl ldap://dc1.some.domain.com/dc=some,dc=domain,dc=com?uid
    Require valid-user
    Satisfy any
    AuthLDAPBindDN "CN=PortalReader,OU=Service Accounts,OU=IS,OU=FSA,DC=some,DC=domain,DC=com"
    AuthLDAPBindPassword somePa$$W0rd
    </Directory> 
  • I then restarted apache by issuing the command:
    service httpd restart

Terms explained (as best I can):

  • /var/www/html/ldaptest is the directory location on the local server you want to set settings for.
  • Order deny,allow specifies the order permissions are applied in. (This is typical.)
  • Deny from All prohibits all non-authenticated users from proceeding. 
  • AuthName "Company.com Intranet" simply provides a name for your service that the browser will show in its authentication prompt.
  • AuthType Basic  specifies the type of authentication to be used for the directory. 
  • AuthBasicProvider ldap specifies who is going to handle the basic authentication.
  • AuthzLDAPAuthoritative off is required when using valid-user (see below)
  • AuthLDAPUrl is the location we are searching. This includes your domain controller and your domain.
  • Require valid-user tells mod_ldap to accept all valid domain users regardless of location.
  • AuthLDAPBindDN "CN=PortalReader,OU=Service Accounts..." tells mod_ldap the fully qualified location of the account to use to bind to your domain. This account needs read priviliges on your domain.
  • AuthLDAPBindPassword is simply the password for your bind account. 

That was all there was to it.  I did have a couple of issues though:

  1. I didn’t get the DN (Distinguished Name) for the AuthLDAPBindDN right the first time.  In order to get the correct DN, I used ADSIEdit to find the actual object and copy the DN directly,  putting it in quotes.  (If you fail to use quotes, Apache will not start on the basis that you cannot have more than one value for that setting.)
  2. In order to determine that I was having the above problem, I had to set logging to the debug level. You do this by finding LogLevel in httpd.conf and setting it to debug. Previously, I had warn set.
  3. Lastly,  I didn’t watch the right log for errors at first.  I defaulted to trying error_log, but in my particular case I was using SSL so the correct log was ssl_error_log. 

This code allows ANY valid user in the specified domain to login. In order to use groups and things of that nature, I recommend you look at this guide.

, , ,

No Comments

Enabling Mod_Rewrite in Apache 2.x

Posted by clifgriffin in Technology on October 28th, 2008

Trying to enable mod_rewrite in Apache 2? Check these things.

  1. In your httpd.conf file (probably in/etc/httpd/conf/), search for the line:
    LoadModule rewrite_module modules/mod_rewrite.so
    Ensure there is no pound sign (#) in front of this line.
  2. Search for AllowOverride and ensure it is set to All.
  3. Search for AccessFileName. If you do not find a line that says:
    AccessFileName   .htaccess
    You need to add it.
  4. Restart Apache (service httpd restart OR /etc/init.d/httpd restart)

That should be it.

,

4 Comments