Apache2: seg fault or similar nasty error detected in the parent process

If you happen to see a message like this

seg fault or similar nasty error detected in the parent process

when reloading Apache2, and if you’re using PHP5 through mod_php5, then it may be related to having an extension loaded via php.ini and not really present on the system. It was my case with a redis extension (redis.so) and I banged my head a day before finding it.

Advertisements

Mod_Rewrite forbidden 403 with Apache 2.2.8

If you get a message like this and you are sure that your mod_rewrite rules are OK:

Tue Jun 10 11:18:59 2008] [error] [client 192.168.1.85] Options FollowSymLinks or SymLinksIfOwnerMatch is off which implies that RewriteRule directive is forbidden: /var/www/enterprise/file.html

You need to enable FollowSymLinks in the directory that uses mod_rewrite, if not, you will get a friendly 403 error message :)

<Directory /path/of/your/dir>
Options -All
Options +FollowSymLinks
</Directory>

To enable globally, use httpd.conf with

<Directory />
 Options +FollowSymLinks
</Directory>

See you!

X-Cache and X-Cache-Lookup headers explained

Ok, maybe you have no problems while dealing with web caches but I (and my workmates as well :P ) do, so here it goes this post.

Let imagine you are behind a classical transparent proxy on port 80 and you’re visiting a web site running an internal web cache (so, another proxy). If you inspect your HTTP headers looking for some info, you can find two lines that look like this, given domain.tld as the local website and proxy.local as your internal transparent proxy.


X-Cache HIT from proxy.domain.tld, MISS from proxy.local
X-Cache-Lookup HIT from proxy.domain.tld:3128, MISS from proxy.local:3128

What does this mean? That this is the first time you visit that website (MISS from proxy.local) and that their proxy has a valid copy of the page in its cache (X-Cache HIT proxy.domain.tld). I’ll explain X-Cache-Lookup meaning later


X-Cache MISS from proxy.domain.tld, MISS from proxy.local
X-Cache-Lookup HIT from proxy.domain.tld:3128, HIT from proxy.local:3128

Now, we’ve just refreshed the page (F5, Ctrl+R, you name it) but wait… what’s happening? It seems both proxies are not serving any page, and we’ve got two mysterious HITs in Cache-Lookup. Well, it’s very simple. We are not counting another level of cache. The browser web cache. So, the page now is not pulled at all from the net, instead Firefox (or your web browser of choice) is using it’s own cache to show the page, so we’ve got two MISSes in X-Cache but nonetheless both proxies are telling us that they would send the cache copy if asked. So, if you’re debugging your proxy system, it means it’s working correctly.

Now, what if we empty Firefox’s cache ??
Here it is:

X-Cache MISS from proxy.domain.tld, HIT from proxy.local
X-Cache-Lookup HIT from proxy.domain.tld:3128, HIT from proxy.local:3128

Our transparent proxy has got the page we need so it sends it to us (HIT from proxy.local), the remote proxy doesn’t need to do anything and both could send the page in case we want.

Although it could seem complicated, once you get it it’s very very simple, and you can easily nest more and more cache levels.

Apache, mod_rewrite and multiples RewriteCond

If you don’t kown Apache’s mod_rewrite, then you should, because it’s a very nice and flexible piece of software when you need to do URL mangling and L7 HTTP proxy. You cand do all sort of redirections, set cookies based on data like incoming URL, browser version etc or even set an environment variable with a value matching a regexp pattern.

You can find on the net very good tutorials about mod_rewrite, so I won’t waste your bandwith with a worse explication… anyway, today I want to share with you a little tip I found while working with mod_rewrite.

Imagine you need to write a rule involving two or more RewriteCond, and you want to use RewriteCond’s pattern matching backreferences in your rule (with %1, %2 … %N). Well, you have to keep in mind that you can use a backreference only from the LAST RewriteCond you have used. Example:

RewriteCond %{HTTP_HOST} (.*)\domain\.tld
RewriteCond %{REQUEST_URI} ^/(css|images|js)/
RewriteRule ^/(.*) http://www.domain.tld/%1/static/$1 [L]

At a first glance, if the original URI is

http://foo.domain.tld/js/script.js,

then the rewrited URI should be something like

http://www.domain.tld/foo/static/script.js

but that’s not true, because mod_rewrite is evaluating only the last RewriteCond! So, eventually the URL will be

http://www.domain.tld/js/static/script.js

that’s not what we (or at least I) were expecting. The solution, in this case, is to join the REQUEST_URI condition with the RewriteRule:

RewriteCond %{HTTP_HOST} (.*)\domain\.tld
RewriteRule ^/(css|images|js)/(.*) http://www.domain.tld/%1/static/$2 [L]

but you can easily see that it’s something you should be aware of when the conditions are more variegate.