After digging around, (by looking at the ebuild file) I found out that imagemagick is actually making use of librsvg to do the heavy lifting when dealing with svg files.

librsvg is part of gnome-base packages (as can be seen in gentoo portage). Looking at the source code, I figured that it makes use of pango to render text.

From the days of working on SCIM project, I know for sure that pango is more than capable of rendering text with underlines. So there must be something missing in librsvg to render it. It turns out that, while the svg parser implemented in librsvg does indeed look for text-decoration, and recoganize underline (among strikethrough and overline), it is not actually making use of these parsed info to render the text.

After a bit of tracing the code, I found out how to patch it: the trick is just to add a pango underline attribute to the text layout, and everything else is taken care of by pango.

This bug is reported to upstream, and hopefully it will be merged there soon. The patch is available in that bug report, so you can grab it if you can’t wait. The patch also fixes a bug which is discovered after the underline problem is fixed: when a underlined text has stroke set, the stroke is rendered in wrong position.

Use Apache as proxy server

Today I decided to shield an apache proxy server in front of the cherrypy server to off load all static files serving duties from the latter, in the hope of speeding up reloading speed of the app.

The apache proxy should be setup so that it directly serves any files under /debug and /release, all other requests are dynamic and should be handled by cherrypy server. In addition, our backend app sometimes use HTTP redirects to direct client to a new page. In Apache configuration file, all this can be achieved by:

ProxyPassMatch ^/(?:debug|release)/.* !
ProxyPass / http://127.0.0.1:8000/
 
ProxyPassReverse / http://127.0.0.1:8000/
 
Alias /debug /var/www/htdocs
Alias /release /var/www/htdocs/release

Note: the /debug directory is the unbuilt frontend code, while the /release points to the built frontend code (by default, dojo will put the built version under release directly as peer of dojo dir).

With the above settings, cherrypy is nicely sitting behind the Apache server without worrying about any static files, and the reloading time of the unbuilt frontend code now reduces to about 4 seconds, which is a dramatic improvement.

Try nginx instead

nginx is normally considered to be a faster reverse proxy server than apache, so I want to give it a try.

In nginx configuration file, proxy_pass is used to pass the request to a backend server, while it does not use proxy_pass_reverse, instead the equivalent in nginx is proxy_redirect directive. As long as your host domain name is properly set up, the following nginx directive is equavalent to the above apache directive:

location /debug/ {
    alias /var/www/htdocs;
}
location /release/ {
    alias /var/www/htdocs/release;
}
location / {
    proxy_pass http://127.0.0.1:8000;
    proxy_redirect default;
}

More info on proxy_redirect can be found in official documentation.

Impression of Nginx compared to Apache

While I don’t want to do any thorough comparsion of the two reverse proxy servers, I just tried each of them several times and monitors the net panel output in firebug. It seems, nginx delievers more consistent performance: for the same page, apache sometimes deliver it in 1 second, sometimes in 4 seconds, while nginx always delivers it in 1 second. Thus I guess I will just keep using nginx at least for now.

In the thread about this issue, 5 possible workarounds are presented. However, none of them are easy under gentoo without messing up with ebuild/emerge. I found another way, and you don’t need to regenerate the configure file for rsync at all, all you need is to comment the following line in the config.h file (which is generated after you run the configure script):

#define HAVE_LUTIMES 1

then make and make install, all should be fine now.

To use this script, just extract the file, and place ec2.conf under /etc/conf.d and rename it as ec2, then move file ec2 to /etc/init.d

Before you can use it, you have to set some parameters in file /etc/conf.d/ec2, please consult the comments in that file.

In order to register IP address whenever the AMI is getting booted, a final step is needed:

rc-update add ec2 default

Googling around, it turns out that, it’s due to my “too recent” version of ruby (I only use stable packages in gentoo, but we all know gentoo is always cutting edge, even its stable branch, isn’t it?), which has a backward incompability. The fix is trivial:

— rexml/text.rb.orig 2007-10-22 08:00:04.000000000 +0100
+++ rexml/text.rb 2007-10-22 08:00:33.000000000 +0100
@@ -286,7 +286,7 @@
EREFERENCE = /&(?!#{Entity::NAME};)/
# Escapes all possible entities
def Text::normalize( input, doctype=nil, entity_filter=nil )
- copy = input
+ copy = input.to_s
# Doing it like this rather than in a loop improves the speed
#copy = copy.gsub( EREFERENCE, ‘&’ )
copy = copy.gsub( “&”, “&” )

If you are a gentooer, then you have to do it manually. The following is what I have done to make it work

rpm2targz ec2-ami-tools.noarch.rpm #if you don't have rpm2targz, run emerge rpm2targz first
tar xvfz ec2-ami-tools.noarch.tar.gz
mv usr/local/* /usr/local/
mv usr/lib/site_ruby/ /usr/lib/
mv etc/aes/ /etc/
ln -s /usr/lib/site_ruby/aes /usr/lib/ruby/site_ruby/1.8/i686-linux/aes

After that, you should be able to run ec2-bundle-vol and others just fine.

Another tip: I have this in my ~/.bash_profile (~/.bashrc will do too):

#for Amazon EC2 AMI bundle
EC2_BUNDLE="-k /path/to/your/pk/pem -c /path/to/your/cert/.pem -u <user_id>"
alias ec2-bundle-vol="ec2-bundle-vol $EC2_BUNDLE"
alias ec2-bundle-image="ec2-bundle-image $EC2_BUNDLE"

So that you don’t need to specify all those mandatory options every time you invoke these commands.

Cannot load /.../libphp5.so into server: /.../libphp5.so: undefined symbol: _efree

Google suggested that, lots of people have the exact error, but not a single page contains what caused this error or how to solve it. In addition, this error also happens with php 4 and apache 1.

After some hard time Trial and error, I found the issue: due to some reasons, the make install to install php 5 does not actually copy over the libphp5.la files to the right place. After manually copying the la file, apache 2 can be started happily with php 5 enabled.

Edit: Ivan reported that instead of the above,

make clean

will make it work for his case. Thanks. – Dec 21 2008

libsvn_ra_dav-1.so.0: undefined symbol: gss_delete_sec_context

After googling around, I found out that, someone suggested to disable neon when compiling subversion 1.4. That did do the trick, and binding works. However, with neon disabled, svn can not work with http/https repositories, which is not acceptable. So I have to find another workaround.

Google told me that gss_delete_sec_context is part of libgssapi.so, and "ldd libsvn_ra_dav-1.so.0" reveals that it does not link to any libgssapi.so at all. The obvious workaround is to explicitly specify that in the Makefile.

Edit the top Makefile in subversion 1.4.0, append "-lgssapi" to this line:

SVN_APR_LIBS = ...

(… is the actual content you will see) after installing it, everything works fine now.

It may be argued that this is not a subversion issue, rather than a neon one (it should link to gssapi). As subversion uses a bundled neon, so maybe it is more faire to call it a subversion bug.

This is the .htaccess (I have eZ installed in /ez38, so this .htaccess is under /ez38) required to have eZ work with apache rewrite properly in a subdir:

RewriteEngine On
RewriteRule !\.(gif|jpe?g|png|css|js|html|xml|ico)|var(.+)storage.pdf(.+)\.pdf$ index.php

DirectoryIndex index.php

In order for apache to read .htaccess in each dir, something like this has to be set in the httpd.conf file for apache:

<Directory />
    Options FollowSymLinks
    AllowOverride All
</Directory>

UPDATE (29/May/2006): *.ico should not be rewriten to index.php