Here it is:

#!/bin/bash
# To change wallpaper automatically after N minutes, add this to your CRON (where N is minutes): N 0 * * * /path/to/wp-show
base="/home/pluc/.walls/"
photo=$(find $base -regex ".*\([jJ][pP][gG]\|[jJ][pP][eE][gG]\|[gG][iI][fF]\|[pP][nN][gG]\|[bB][mM][pP]\)$"  -type f | while read x; do echo "`expr $RANDOM % 1000`:$x"; done | sort -n | sed 's/[0-9]*://' | head -1)
uri="file://"$photo
gsettings set org.gnome.desktop.background picture-uri "$uri"

See, the OAuth protocol uses timestamps and nonces to validate requests. Should the timestamp of the requestee be negative or inferior to the timestamp of the requested, the request will fail and the whole OAuth workflow will fail, and chances are you'll have no goddamn clue why. Fear not! I experienced it, so I had to understand it.

Here's what happened: first, I need to properly illustrate the data I was working with:

• OAuth request sent to Context.IO (in the  "America/Montreal" (EST)  timezone);
• OAuth request sent from my application's server  (in the "America/Chicago" (CST) timezone);
• Server from which the request originates  is  a VPS from WebbyNode running Xen under Debian 6;

Now, there's a chance that, if you're in the same timezone or your timezones and date settings are properly set, all OAuth API calls will work just fine... but if the time would never change, there would be little reasons to make so many utilities to update it. So, it changes. If that happens, and it changes just enough to fail the OAuth check.. well that's where the problem is.

Having a Xen-powered VPS means that the system clock is controlled by the host (or the "parent" machine if you will). Whenever I would set the date to match the one of the server I was sending requests to, it would revert right back. It sucked. For a long time. The fix is pretty simple, you just have to know it:

echo 1 > /proc/sys/xen/independent_wallclock && ntpdate pool.ntp.org

If independent_wallclock exists, permissions won't let you pipe output to overwrite it, so use:

echo 1 >! /proc/sys/xen/independent_wallclock && ntpdate pool.ntp.org

After that, your timestamp should be good and the update you performed with ntpdate will finally stick.

What you need to do is rather simple and safe. It does involve modifying the Apache configuration files though, so make backups of every file mentioned in this article if you feel the need to.

While you could build mod_pagespeed from the source, (with the official instructions provided on the mod_pagespeed wiki) we'll use the RPM binaries that you can get for your distribution here. I suggest you copy the appropriate file's URL (such as https://dl-ssl.google.com/dl/linux/direct/mod-pagespeed-beta_current_i386.rpm) so you can wget it later. Here goes some shell code you'll want to run as root:

cd /usr/local/src
mkdir mod_pagespeed
cd mod_pagespeed
wget https://dl-ssl.google.com/dl/linux/direct/mod-pagespeed-beta_current_i386.rpm
rpm2cpio mod-pagespeed-beta_current_i386.rpm | cpio -idmv
cp /usr/local/src/mod-pagespeed/usr/lib/httpd/modules/mod_pagespeed.so /usr/local/apache/modules/
cp /usr/local/src/mod-pagespeed/etc/httpd/conf.d/pagespeed.conf /usr/local/apache/conf/
chmod 755 /usr/local/apache/modules/mod_pagespeed.so
mkdir /var/mod_pagespeed/{cache,files} -p
chown nobody:nobody /var/mod_pagespeed/*

mod_pagespeed has a dependency that you'll want to enable: mod_deflate (the httpd source directory (2.2.16) may vary depending on your install):

/usr/local/apache/bin/apxs -c -i /home/cpeasyapache/src/httpd-2.2.16/modules/filters/mod_deflate.c

After that, we'll have to edit the mod_pagespeed configuration file located at /usr/local/apache/conf/pagespeed.conf to reflect the correct paths, the LoadModule directives should fetch the modules in "modules/module_name.so":

LoadModule pagespeed_module modules/mod_pagespeed.so
LoadModule deflate_module modules/mod_deflate.so
ModPagespeedFileCachePath            "/var/mod_pagespeed/cache/"
ModPagespeedGeneratedFilePrefix      "/var/mod_pagespeed/files/"

After that, we'll need to include the mod_pagespeed configuration in Apache's configuration file (/usr/local/apache/conf/httpd.conf):

Include “conf/pagespeed.conf”

And finally, restart your HTTP server by issuing a service httpd restart command. Once your web server fires up, it'll be mod_pagespeed-enabled. If all goes well, you should be able to see a new "X-Mod-Pagespeed" header when requesting resources on your server.

Before you start, you'll need the following:

• e2fsprogs >= 1.41.3 (1.41.4 comes with Jaunty)
• Linux Kernel >= 2.6.28 (2.6.28- comes with Jaunty)
• gParted >= 0.4.3 (0.4.3 comes with Jaunty)
• If you wish to convert the partition containing /boot, you'll also need
  • GRUB 0.97 (0.97  comes with Jaunty) ^[1]
  • grub4ext4 0.97 - Patches GRUB with basic ext4 support ^[1]
  • Ubuntu 9.04 Live CD ^[1]

Converting extra partitions

What I mean by "extra" is simply any partition or devices that do not contain your Ubuntu system. The process is extremely simple and extremely fast. It'll take you about 30 seconds for every partition you wish to convert to ext4. Make sure you're not using any files on the partition we'll work with (torrents, music, system resources, etc). If your command line-fu is good, just unmount the partition you want to convert (umount /dev/XXX where XXX is your device and partition (sda2, sdb1, hdc3)). Otherwise, fire up the GNOME Partition Editor (gparted) that's in System > Administration > Partition Editor. Select the device containing the partition you want to convert, right click on the partition and select "Unmount". Take note of the "Partition" label (such as /dev/sda2 or /dev/sdb1 or /dev/hdc3).

Now that your partition is unmounted, we can convert it to ext4. Fire up a terminal (run -> gnome-terminal) and run this command as root, replacing XXX with your device and partition name/identification (that you should've noted or should know by now):

tune2fs -O extents,uninit_bg,dir_index /dev/XXX

I'll take a few seconds, and you'll have an ext4 filesystem. Easy enough, right? For added security, we'll run a filesystem check after each conversion using fsck:

fsck -pf /dev/XXX

The last thing we need to do is let your system know about the change we just did. We can do that by editing /etc/fstab as root (using whatever editor you're comfortable with) and changing the filesystem of the partition. Once /etc/fstab is open, look for a line starting with your device and partition (/dev/XXX) or your device's UUID (you can get your device's UUID by typing sudo vol_id --uuid /dev/XXX). Change the "ext3" to "ext4", and you're done. Repeat this process for every other partition you want to convert, except for your boot partition (the one containing /boot). Once all your partitions are converted and updated in fstab, run sudo mount -a to remount them all, or you can also do them manually by performing the inverse of the process you went through to unmount them.

Converting the main system partition (the one with /boot)

Here's where it gets tricky a bit. A lot of people in the Ubuntu community and some of the sources used in this article advise against doing this since there's no real gain, except boot speed increase and the GRUB boot loader doesn't officially support booting from ext4 filesystems. It's still a fun thing to do, and well you've already got a theoretically unstable system anyway, so why the hell not give it a shot?

Obsolete (but tested & working) method:^[1] Apply the patch you downloaded from grub4ext4 ^[1] (some instructions are in the grub4ext4/grub-0.97/INSTALL file). That'll add some basic ext4 support to your boot loader. After that, edit GRUB's configuration file (/boot/grub/menu.lst) as root to include the ext4 change. Append the "rootfstype=ext4" directive to the boot line ^[1], as follows, run update-grub as root and proceed with the rest of the tutorial below.

title        Ubuntu jaunty (development branch), kernel 2.6.28-10-generic
uuid        2134efa6-d23f-4aeb-8157-5ac06f95634b
kernel        /boot/vmlinuz-2.6.28-10-generic root=UUID=2134efa6-d23f-4aeb-8157-5ac06f95634b ro splash vga=792 quiet rootfstype=ext4
initrd        /boot/initrd.img-2.6.28-10-generic
quiet

Then run update-grub as root to generate a new menu.lst (not sure why, but apparently it's needed. Kind of redundant if you ask me). Since you can't unmount the main system's partition while working on the system, you'll have to reboot onto the Jaunty LiveCD you downloaded earlier in order to do it. Make sure to boot from the LiveCD, because at this stage, GRUB is configured to boot on a ext4 filesystem that we haven't yet created, and it won't boot until we do so. From the LiveCD, make sure your device isn't mounted (you can use gparted here too) then run the two commands we discussed above (tune2fs and fsck) on the device. Reboot and voila! You're booting with a full ext4 system.

New (but untested) method: With this new method, you won't need to patch your GRUB or edit your menu.lst. It's unconfirmed and I haven't personally done this specific procedure, so if you're feeling adventurous, go ahead and let me know if it does work. If you do try it though, be prepared for a possible boot fail. It would be wise to put the grub4ext code on a USB key or save the URL or files somewhere you can access from a LiveCD. Should that happen, restore (and continuation of the procedure) is easily doable from the LiveCD. Simply mount your original system's partition from the LiveCD, create a chroot, patch GRUB and continue with this tutorial from that chroot. Jaunty's version of GRUB is apparently ^[1] already supporting ext4 boot , so all you'd have to do is run the conversion and check commands mentioned above on your partition, then run update-grub as root.

Notes

1. Apparently, patching GRUB using grub4ext4 and adding rootfstype=ext4 within /boot/grub/menu.lst would be obsolete. FuturePilot reports on Ubuntu Forums that simply reinstalling GRUB to your machine's master boot record (MBR) will do the trick. More information within bug #353071 on Launchpad. I have not tested this method, but it would make sense to work. If you successfully do, give me a holler and I'll update accordingly.

Sources

• Ext4 Howto at Ext4 Wiki
• Linux Convert ext3 to ext4 file system at nixCraft