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.

GNU tar and remote hosts

A little tip that maybe it’s not so well known. When passing an argument to the -f option (–file) to GNU tar, you can specify a remote address using the standard colon format. For example

tar cfv user@remotehost:/path/to/tar /files/to/archive

will try to connect to remotehost via SSH and authenticate as user (asking the password or using your preferred ssh auth method). Obviously you have to have rsh on your local machine and an sftp capable server on the other side.

HOWTO: Active Directory authentication in Ubuntu 8.04 and 8.10

This is a second version of this other guide that applied to previous Ubuntu versions.
Since Ubuntu 8.04 (Hardy Heron), and now Ubuntu 8.10 (Intrepid Ibex) it come the Likewise Open package that makes basic Active Directory authentication in Ubuntu a breeze.

Just follow these steps:

1. sudo apt-get update
2. sudo apt-get install likewise-open
3. sudo domainjoin-cli join fqdn.of.your.domain Administrator
4. sudo update-rc.d likewise-open defaults
5. sudo /etc/init.d/likewise-open start

and you can now log into your machine using your DOMAIN\user credentials. Remember that the DOMAIN\ part is mandatory and that it represents the short name of your Active Directory domain. You can join the domain using any user with sufficient privileges (there’s no need to use Administrator), and you can even directly join the PC in a particular OU passing the –ou argument to domainjoin-cli. The fourth point maybe won’t be necessary when Ubuntu 8.04 LTS wil be released because it seems to be a bug in the package (it won’t start likewise on reboot, so if you don’t issue this command it would seem that nothing is working after a reboot).

I’ve just started to use this method on a test machine so I’ll leave more opinions on this product in the future.

EDIT: First impressions

After some days of not so extensive usage, I’ve seen a couple of things that it’s worth notice:

• the likewise-open process seems to “die” from time to time, blocking all your login accesses with a “ERROR” message. Restarting it through init script solves the issue… but it’s something that definitely should not happen
• It informs you on login if your password is going to expire in X days (as set in your GPO). Very nice indeed.

Notes to the readers: if you’re experiencing installation problem, the best way is to report them to the likewise-open-discuss mailing list. There you can contact directly likewise developers (of Samba fame) and solve your problems or doubts.

EDIT2: it seems that with the final Ubuntu 8.04 update, likewise-open package is now 100% stable, I didn’t have a single failure since last update (one week up, while before it died at least once per day)

EDIT3: as mentioned in the comment, with likewise-open 4.x you can add

winbind use default domain = yes

in /etc/samba/lwiauthd.conf so you d’nt have to specify the DOMAIN\ part every time you log in your box.