Subversion is a version control system. It can run as either it’s own server (svnserve), or as an Apache module (mod_dav_svn.so).

When using the mod_dav_svn module for Apache, and doing an svn copy operation on the repository itself can fail if the VirtualHost configuration for subversion is not correct. Put simply, if Apache itself and mod_dav_svn are serving content from the same path, then conflicts can occur. Apache can get confused if it attempts to serve a physical file instead of routing the request through mod_dav_svn.

“svn copy …” operations will fail, while “svn update …”, “svn commit …”, and “svn checkout …” operations work fine.

Detail of the problem, diagnosing the problem, and the fix are below.

Problem

Repository checkouts (svn co …) and commits (svn ci …) work fine and throw no errors, but svn trunk copying operations fail “svn copy …/trunk …/tags/x.x” with “svn: Repository moved permanently to ‘…’; please relocate”.


$ svn co https://svn.test.com/myproject/trunk myproject
... (checkout progress)
Checked out revision [x].
$ svn ci myproject
Committed revision [x].
$ svn cp https://svn.test.com/myproject/trunk https://svn.test.com/myproject/tags/x.x
svn: Repository moved permanently to 'https://svn.test.com/myproject/'; please relocate


Diagnostics

To diagnose the problem, first make sure the local checkout urls are correct.


$ svn info myproject
...
URL: https://svn.test.com/myproject/trunk
Repository Root: https://svn.test.com/myproject


The Repository Root should match the root url of the project repository that you are working with because the svn commit above worked. However, if they don’t match, then use svn switch to move the url that your local checkout is linked to:


$ svn switch --relocate [OLD URL] [NEW URL] myproject
$ svn cp https://svn.test.com/myproject/trunk https://svn.test.com/myproject/tags/x.x


If relocating the base url of the checkout (svn switch –relocate …) does not fix the problem, but checkouts and commits work fine, the next step is to look at the virtual host configuration in Apache for the subversion module. This is where I found my problem.

The Cause

The file path of the subversion repository was within public_html, so it had a physical path that was identitical to it’s url path.


$ ls public_html
repos
$ cat /etc/httpd/conf.d/subversion.conf
<VirtualHost 127.0.0.1:443> #YOUR IP ADDRESS:PORT
DocumentRoot /home/svn/public_html #YOUR WEBROOT PATH
...
<Location /repos>
DAV svn
SVNParentPath /home/svn/public_html/repos #YOUR REPOSITORY PATH
...
</Location>
</VirtualHost>


The problem is that the Location is an actual physical filepath, not an alias. So, Apache isn’t sure whether to attempt to serve the physical file itself, or to pass the request through to mod_dav_svn. Most of the time mod_dav_svn wins and Apache forward the request through. However, “svn copy” must work slighly differently, and Apache attempts to serve the request itself, rather than pass it through mod_dav_svn. The request then fails and svn errors out with the “svn: Repository moved permanently to ‘…’; please relocate” message.

A reader of this blog also pointed out that this can also happen if you have an overlap between a URL path alias and the repos folder itself:


#Alias /repos “/srv/svn/repos” #Commenting this line out fixed the problem


Fix

The fix is to 1) change the Apache configuration, and 2) change the physical path to the repository so that it does not match the url. This way, Apache will never attempt to serve a physical file itself, and will instead forward the requests to mod_dav_svn.

Edit /etc/httpd/conf.d/subversion.conf


<VirtualHost svn.test.com:443>
DocumentRoot /home/svn/public_html
...
<Location /repos>
DAV svn
SVNParentPath /home/svn/repos #NOTE THAT repos IS NOW OUT OF THE PHYSICAL WEBROOT PATH
...


Move the repository directory out of the physical webroot path and restart Apache.


[svn /home/svn]$ mv public_html/repos .
[svn /home/svn]$ sudo service httpd restart


All your “svn copy” operations should work now.

Technorati Tags: apache, repository moved permanently, subversion, svn copy

Situation #1:  SELinux denies httpd from opening socket

I ran into this simple, but annoying, problem after I migrated my development workstation to Fedora 12.

Problem:

A large PHP application that I have developed at Submerged Solutions (SandPiper Accounting) began throwing Permission Denied (13) system exceptions when attempting to send mail through Zend Framework’s Zend_Mail library.

All the phpunit unit tests worked fine and could send e-mail, but would fail when the usability tests started and any HTTP requests that sent e-mail were handled through Apache.

The Apache instance was being run as user apache / group apache, and php (mod_php) is run as user apache / group apache.

The exception occurred in Zend_Mail_Protocol_Abstract->_connect(), immediately following the socket opening call “stream_socket_client(…)”.

File: Zend/Mail/Protocol/Abstract.php; Line 224

50: abstract class Zend_Mail_Protocol_Abstract
51: {
...
218: protected function _connect($remote)
219: {
220: $errorNum = 0;
221: $errorStr = '';
222:
223: // open connection
224: $this->_socket = @stream_socket_client($remote, $errorNum, $errorStr, self::TIMEOUT_CONNECTION);
225: ...


fopen() calls using http and ftp protocols also failed:

Warning: fopen(…) [function.fopen]: failed to open stream: Permission denied in …

The fix:

The problem turned out to be the “httpd_can_network_connect” SELinux setting that is on by default in Fedora 12.

In a shell console, run as root:

# /usr/sbin/setsebool httpd_can_network_connect=1


Thanks to durwood, who pointed this out on PHP.net.

“Bug” Report at RedHat.com.

More info on SELinux.

Situation #2: PHP forbids opening socket to 255.255.255.255

A reader of this blog brought a problem of his to me.  I had never seen it before, so it was definitely interesting.

Problem:

This reader was using this PHP script that he had found to do Wake-on-LAN pings on his local network.  The script worked fine in Windows, but failed on his Fedora 10 server.  The error he received was Permission Denied (13).

His WoL packets were sent via udp to the broadcast address 255.255.255.255.  This worked fine in Windows, but failed in Linux.

His server’s PHP installation had socket support enabled, and udp was a registered stream socket transport.

His SELinux was disabled, so Situation #1 did not apply to him.

This is probably distribution specific.  I’m running Fedora 12, and had no such issues, whereas the person facing this problem was running Fedora 10.

Solution:

Either PHP or the the user running the PHP instance (“apache” in this case), was being forbidden from opening sockets to 255.255.255.255.  It turns out this is somewhat common.  Even when running the script as “root”, you can still get permission denied errors.

I came upon this short comment on php.net about someone else getting permission denied errors on socket_connect() calls.

There was also this comment which showed an easy way to get the broadcast address for the computer’s network interface. This method seems to work, however, it is limited to Linux since it relies upon the following gnu utilities: ifconfig, grep and cut.  It may work if you compile Windows ports to these utilities, or use cygwin.  (Note: The code snippet at PHP.net has errors.  A revised script is pasted below.)

Here’s the way to get the broadcast address:

exec("ifconfig | grep Bcast | cut -d \":\" -f 3 | cut -d \" \" -f 1",$addr);
$addr=array_flip(array_flip($addr));

By getting the broadcast address of the network interface, you can send Wake-on-LAN magic packets to that address rather than to 255.255.255.255.  Doing this, the sockets can be connected successfully, and the permission denied errors were resolved.

Here’s the “fixed” code from PHP.net.  It hasn’t been tested, so you very well may need to modify it for your needs.

<?php
/**
 * Wake-on-LAN
 *
 * @return boolean
 *   TRUE:    Socked was created successfully and the message has been sent.
 *   FALSE:   Something went wrong
 *
 * @param string|array  $mac   You will WAKE-UP this WOL-enabled computer, you
 *                             need to add the MAC-address here. Mac can be
 *                             array too.
 *
 * @param string|array  $addr  You will send and broadcast to this address.
 *                             Normally you need to use the 255.255.255.255
 *                             address, so I made it as the default. You don't need to do anything with this.
 *
 *                             If you get permission denied errors when using
 *                             255.255.255.255 have permission denied problems
 *                             you can set $addr = false to get the broadcast
 *                             address from the network interface using the
 *                             ifconfig command.
 *
 *                             $addr can be array with broadcast IP values
 *
 * Example 1:
 *   When the message has been sent you will see the message "Done...."
 *   if ( wake_on_lan('00:00:00:00:00:00'))
 *      echo 'Done...';
 *   else
 *      echo 'Error while sending';
 */

function wake_on_lan($mac, $addr=false, $port=7) {
    if ($addr === false){
        exec("ifconfig | grep Bcast | cut -d \":\" -f 3 | cut -d \" \" -f 1",$addr);
        $addr=array_flip(array_flip($addr));
    }
    if(is_array($addr)){
        $last_ret = false;
        for ($i = 0; $i < count($addr); $i++)
            if ($addr[$i] !== false) {
                $last_ret = wake_on_lan($mac, $addr[$i], $port);
            }
        return $last_ret;
    }
    if (is_array($mac)){
        $ret = array();
        foreach($mac as $k =< $v)
            $ret[$k] = wake_on_lan($v, $addr, $port);
        return $ret;
    }
    //Check if it's an real MAC-address and split it into an array
    $mac = strtoupper($mac);
    if (!preg_match("/([A-F0-9]{1,2}[-:]){5}[A-F0-9]{1,2}/", $mac, $maccheck))
        return false;
    $addr_byte = preg_split("/[-:]/", $maccheck[0]);

    //Creating hardware adress
    $hw_addr = '';
    for ($a = 0; $a < 6; $a++)//Changing mac adres from HEXEDECIMAL to DECIMAL
        $hw_addr .= chr(hexdec($addr_byte[$a]));

    //Create package data
    $msg = str_repeat(chr(255),6);
    for ($a = 1; $a <= 16; $a++)
        $msg .= $hw_addr;
    //Sending data
    if (function_exists('socket_create')){
        //socket_create exists
        $sock = socket_create(AF_INET, SOCK_DGRAM, SOL_UDP);    //Can create the socket
        if ($sock){
            $sock_data = socket_set_option($sock, SOL_SOCKET, SO_BROADCAST, 1); //Set
            if ($sock_data){
                $sock_data = socket_sendto($sock, $msg, strlen($msg), 0, $addr,$port); //Send data
                if ($sock_data){
                    socket_close($sock); //Close socket
                    unset($sock);
                    return true;
                }
            }
        }
        @socket_close($sock);
        unset($sock);
    }
    $sock=fsockopen("udp://" . $addr, $port);
    if($sock){
        $ret=fwrite($sock,$msg);
        fclose($sock);
    }
    if($ret)
        return true;
    return false;
}

if (@wake_on_lan('00:00:00:00:00:00')) {
    echo 'Done...';
} else {
    echo 'Error while sending';
}
?>

Technorati Tags: apache, Debugging, permission denied, php, selinux, stream_socket_client, zend framework, zend_mail