blog.forret.com

When you migrate web sites from one place to another, and the URLS change, you don’t want to lose visitors that still use the old links. If your ‘old’ website ran on Apache, you can use its mod_alias/mod_rewrite functionality to automatically redirect to the new URL. This involves adding redirect rules to the .htaccess file in the base folder of the redirects. Some examples:

Generic structure of the .htaccess redirects

Redirect permanent /(old url) (new url)
Redirect … (add all your one-2-one redirects here)
RedirectMatch permanent ^/old_stuff/.*html$ http://www.example.com/
RedirectMatch … (add your catch-all redirects here)

RewriteEngine on
RewriteBase /blog/
RewriteRule ^([regex])$ http://blog.example.com/$1 [R,L]
RewriteRule … (add all your variable redirects here)

EXAMPLE: old Blogger site (on your own server) to new Wordpress site
I’ve done a migration from a blog published by Blogger (via FTP) onto my own webspace, to a blog run by Wordpress. I’ve used the following Rewrite rules to handle the redirections.
* HOMEPAGE:
redirect /index.html and / to your new blog URL
Redirect permanent / http://blog.example.com/
Redirect permanent /index.html http://blog.example.com/

* FEED:
redirect e.g. /atom.xml to your Feedburner feed
Redirect permanent /atom.xml http://feeds.feedburner.com/(exampleblog)

* ARCHIVES:
redirect e.g. /archive/2005_03_posts.html to the new Wordpress archives
RedirectMatch permanent /archive/([0-9][0-9][0-9][0-9])_([0-9][0-9])_.*$ http://blog.example.com/$1/$2/

* POST PAGES:
This is tricky, because Blogger and Wordpress do not use exactly the same rules for constructing the text-like URL (the ‘post slug’). E.g a post called how-to-podcast-with-blogger-and.html on my old Blogger site became how-to-podcast-with-blogger-and-smartcast/ on the new Wordpress one. So what I did consisted of 2 type of rules:
a) redirecting individual pages
Redirect permanent 2004/10/how-to-podcast-with-blogger-and.html http://blog.example.com/2004/10/how-to-podcast-with-blogger-and-smartcast/
b) a generic rule for the others (this uses Rewrite instead of RedirectMatch!): each page is redirected to a search on the Wordpress blog within the correct month with the two first words of the title:
RewriteRule ^([0-9][0-9][0-9][0-9])/([0-9][0-9])/([a-z0-9]*)-([a-z0-9]*).*$ http://blog.example.com/$1/$2/?s=$3+$4 [R,L]
This method is far from perfect, but will bring visitors a lot closer to the right page. If you use pretty distinctive words for titles (e.g. “Myspace: bulletin and other spam“), chances are the right page show up first. If you start all your posts with “The ten best ways to …” then you will need a more sophisticated rule; e.g. using the 6th and 7th word:
RewriteRule ^([0-9][0-9][0-9][0-9])/([0-9][0-9])/[a-z0-9]*-[a-z0-9]*-[a-z0-9]*-[a-z0-9]*-[a-z0-9]*-([a-z0-9]*)-([a-z0-9]*).*$ http://blog.example.com/$1/$2/?s=$3+$4 [R,L]

Not losing the querystring
Redirect and RedirectMatch cannot redirect to a URL with a querystring (e.g. to newpage.php?param1=val1&param2=val2). For that you will need to use the RewriteRule. An example: redirect all links like test.asp?param=value on the old domain to the new domain while keeping all querystring parameters:
RewriteRule ^tools/test.asp\??(.*)$ http://web.example.com/tools/test.asp [L,QSA]
where the QSA = (query string append) keep existing querystring, and L = (last rule) stop looking further for rule matches.

If you're new here, you may want to subscribe to my RSS feed or receive updates via email. Thanks for visiting!

Squid has a little system statistics viewer built-in:

The cache manager (cachemgr.cgi) is a CGI utility for displaying statistics about the squid process as it runs. The cache manager is a convenient way to manage the cache and view statistics without logging into the server.
(from Squid FAQ)

The only thing is … it’s so ugly! It uses plain HTML and cannot be customized, the FAQ says. However, there is a way to do it:

I did something a bit different (I wanted to use the CSS of my own website), so I ‘ll show you the difference between the two versions.
In order to get to the following comparison, I did a strings cachemgr.cgi > cachemgr.txt to extract only the text parts, and I did a diff cachemgr.txt cachemgr2.txt to compare both files. You cannot do a file comparison of 2 binary files.

<em>173,174c173,174</em>
< <HTML><HEAD><TITLE>Cache Manager Interface</TITLE>
< <STYLE type="text/css"><!-- BODY{background-color:#ffffff;font-family:verdana,sans-serif} --></STYLE></HEAD>
---
> <HTML><HEAD><TITLE>Cache Manager (pforret)</TITLE>
> <link rel="stylesheet" type="text/css" href="http://www.forret.com/forret/forret.css" mce_href="http://www.forret.com/forret/forret.css" /> </HEAD>
<em>199c199</em>
< <STYLE type="text/css"><!-- BODY{background-color:#ffffff;font-family:verdana,sans-serif} TABLE{background-color:#333333;border:0pt;padding:0pt}TH,TD{background-color:#ffffff}--></STYLE>
---
> <link rel="stylesheet" type=text/css href="http://www.forret.com/forret/forret.css" mce_href="http://www.forret.com/forret/forret.css"><!-- TABLE{background-color:#333333;border:0pt;padding:0pt} TH,TD{background-color:#ffffff}--></STYLE>


I have one server with apparently an exceptional stability:
# uptime

3:45pm  up 524 days,  1:22,  1 user,  load average: 0.44, 0.16, 0.13

Unfortunately I know this is not correct (I remember rebooting it some weeks ago). So what are other ways to get the date/time of the last boot?

Looking at the RedHat manuals, the following thing should work too:
# cat /proc/stat
cpu 33813143 210619911 30093342 59435750
cpu0 33813143 210619911 30093342 59435749
(…)
btime 1096157569
(…)

The btime gives us the last boot time in seconds since 1 Jan 1970. I can find and convert it with gawk:
# gawk “/btime/{ print (`date +%s` - $2) / (3600 * 24.0) ,”days -”,strftime(”%a %b %d %H:%M:%S %Z %Y”,$2)}” /proc/stat
38.6473 days - Sun Sep 26 02:12:49 CEST 2004
Which gives us an uptime of 38,6 days – that looks more like it!

Another way of calculating the uptime:
# gawk “/cpu/ {print $1,($2 + $3 + $4 + $5)/(3600 * 24 * 100)}” /proc/stat
cpu 38.6515
cpu0 38.6515
Confirmation of the previous measurement!

# cat /proc/uptime
45282758.17 663091.26
The first number is the # of seconds since last boot. The other one (idle time) we don’t need. What is that in days?
# gawk “{print $1/(3600 * 24.0)}” /proc/uptime
524.106

This is where the wrong data is coming from! So I’ll ignore this data.

Remark: This server is one of my oldest ones and is still running Redhat 7.2 (Enigma). Looks like this bug was fixed in later versions of RedHat, since none of my other servers have it.