January 2010

installing PECL upload progress on ubuntu server

19 January 2010 - 11:17am — drew

Some of Drupal's CCK modules such as filefield and imagefield have support for a neat Upload Progress meter.

You may have seen a message in the status report of your Drupal site saying something like... "Upload progress not enabled - Your server is capable of displaying file upload progress, but does not have the required libraries. It is recommended to install the PECL uploadprogress library (prefered) or to install APC."

APC is primarily a PHP accelerator (there are many others available, but APC is simple to install and will apparently be included in the core of PHP 6). It also offers some uploadprogress functionality.

The information filefield module pokes into the status report tells you how to enable this feature if you've already got APC enabled, but it also adds "it is recommended to use PECL uploadprogress, which supports more than one simultaneous upload." (see filefield.install)

Whether you're already using APC or not, it's very easy to install PECL upload progress on a ubuntu server (and no doubt on other platforms, once you've got PEAR / PECL installed successfully). Here's how:

Install PECL / PEAR

The php5-dev package is also recommended, as you'll need it to install most of the extensions from PECL.

mcdruid@some-server:~> sudo apt-get install php-pear php5-dev

Install Upload Progress

mcdruid@some-server:~> sudo pecl install uploadprogress ...lots of output as PECL downloads and compiles the extension... Build process completed successfully Installing '/usr/lib/php5/20060613+lfs/uploadprogress.so' install ok: channel://pecl.php.net/uploadprogress-1.0.1 configuration option "php_ini" is not set to php.ini location You should add "extension=uploadprogress.so" to php.ini

...then simply follow that last instruction (which I've emphasised); I put the line near the file upload section of my php.ini, but you could put it anywhere. This is where I'd expect to find the php.ini file on a server running a recent version of ubuntu:

/etc/php5/apache2/php.ini

The change will not show up until you restart apache (a force-reload doesn't cut the mustard for this sort of change):

mcdruid@some-server:~> sudo /etc/init.d/apache2 restart * Restarting web server apache2 [OK]

You should now have a nice reassuring message on the status report saying PECL upload progress is enabled, and next time you upload to a filefield or imagefield you should see a smart new progress meter.

Tags:

linux

ubuntu

drupal

php

committing to subversion from behind a dodgy proxy

30 January 2010 - 5:42am — drew

I was recently doing some work in a hotel, and when I came to commit my changes back to my central subverson repository using git-svn, I got an error message that looked a lot like this:

Committing to http: //example.com/top_secret_svn_repo/trunk ... RA layer request failed: Server sent unexpected return value (400 Bad Request) in response to MKACTIVITY request for '/top_secret_svn_repo/trunk/!svn/act/7cc9df3f-2956-3669-8f25-45c093142061' at /usr/lib/git-core/git-svn line 3347

Putting (parts of) this error message into my favourite search engine yielded a few results suggesting the problem was a result of my being behind a proxy. I found a good explanation in a post on the subversion forums:

[subversion uses]... esoteric HTTP methods such as "OPTIONS", "PROPFIND" and "REPORT". If you have an HTTP proxy on your network, it is possible for it to be configured to allow the standard "GET" and "POST" HTTP methods, but to disallow the WebDAV methods that ...[interacting with]... a Subversion repository requires.

This made sense - the hotel I was in seemed to be using a squid proxy which had caused me one or two other problems.

I found a workaround in a post in a mail archive which looks like it will work for plain vanilla SVN as well as git-svn. I had to add a couple of lines to my subversion config at ~/.subversion/servers - something like this:

mygroup = example.com [mygroup] http-proxy-host = localhost http-proxy-port = 3128

...where example.com is the host where subversion's running. I then used an SSH tunnel to a machine running squid so that I could point subversion at port 3128 on localhost and have it talk to the proxy on the other end of the tunnel, which in turn spoke to the subversion server for me. Something like this:

mcdruid@laptop:~> ssh -L3128:localhost:3128 -C machine-running-squid.co.uk

...this only worked because the instance of squid I was now using was not configured to disallow the esoteric HTTP methods used by subversion.

All that remained was to remember to comment out those lines in ~/.subversion/servers when I checked out of the hotel (no bad version control pun intended).

Tags: