The main reason to want to print to Google Cloud Print is for future compatibility with printers within Linux – it means that any ‘Cloud Ready Printer’ can be printed to without having to install possibly closed-source, or non-existent printer drivers.

It also allows printing directly to Google Docs, so you can easily print documents from work straight into your Google Docs account, making archiving documents simple, and easily accessible.

With this in mind, I was looking for a simple CUPS driver, which would allow printing via the normal printing functionality of any application, however this didn’t seem to exist… so I decided to write a CUPS backend and driver to support it.

The github project is available here , and I have produced packages for Gentoo ( Sabayon etc ), Debian ( Ubuntu, Mint etc ) , RedHat ( Fedora, Centos, SuSe etc ) and Mac OS X, with instructions here.

/usr/include/pango-1.0/pango/pango-script.h:132: error: expected declaration specifiers or '...' before 'G_CONST_RETURN'
/usr/include/pango-1.0/pango/pango-script.h:133: error: expected declaration specifiers or '...' before 'G_CONST_RETURN'
In file included from /usr/include/pango-1.0/pango/pango-script.h:138,
                 from /usr/include/pango-1.0/pango/pango-gravity.h:98,
                 from /usr/include/pango-1.0/pango/pango-types.h:91,
                 from /usr/include/pango-1.0/pango/pango-font.h:26,
                 from /usr/include/pango-1.0/pango/pango-attributes.h:25,
                 from /usr/include/pango-1.0/pango/pango.h:25,
                 from /usr/include/gtk-2.0/gdk/gdktypes.h:37,
                 from /usr/include/gtk-2.0/gdk/gdkscreen.h:32,
                 from /usr/include/gtk-2.0/gdk/gdkapplaunchcontext.h:31,
                 from /usr/include/gtk-2.0/gdk/gdk.h:32,
                 from /usr/include/gtk-2.0/gtk/gtk.h:32,
                 from avahi-ui.c:30:

After doing some research, the problem seems to be that I have recently upgraded to version 2.30.0 of dev-libs/glib, which has removed G_CONST_RETURN . I believe packages in the future will remove references to G_CONST_RETURN , but for now, the best solution is to mask ( or remove from keywords ):

=dev-libs/glib-2.30.0

and reinstall the current stable version:

=dev-libs/glib-2.28.8

.

Preparing the Virtual Machine

The main special requirement for the VirtualBox based VM is that it needs to be configured to boot from a Xen-based kernel. Obviously VirtualBox can’t boot Xen-dependant kernels, so I usually have two similarly configured kernels, one with Xen support, one without.

Compiling a Linux kernel with Xen support ( at least on Gentoo ) results in a kernel image named ‘vmlinuz’ whereas the normal kernel without Xen support creates a kernel ( assuming compressed with bzip ) called ‘bzImage’. I have a Grub config file which tries the Xen-based kernel , then falls back to the normal one if this fails. The only disadvantage to this is I have to compile a kernel twice, once with Xen support, once without, but it allows me to test a kernel with my own configuration before I upload it to the cloud:

default 0
timeout 1
fallback 1

title Xen
root (hd0,0)
kernel /boot/vmlinuz spinlock=tickless root=/dev/sda1

title Local
root (hd0,0)
kernel /boot/bzImage spinlock=tickless root=/dev/sda1

Next, remove all data which you don’t want to upload yourself ( all my sites I am hosting on the image are stored in SVN, which I will just ‘svn co’ when the instance is running ), then clean the filesystem (  by filling the empty space with zeros ) to reduce the data we have to upload:

cat /dev/zero > /tmp/zerofill
sleep 1
sync
rm /tmp/zerofill
sleep 1
sync

Power off the VM, and we can now create an image we can create an AMI from.

Creating the Image

Next, delete all the VirtualBox snapshots for the VM, so the changes get merged into the ‘root’ image – if you do not do this then you get a version of your image before snapshots have happened ( I found this out the hard way when the VM booted with software running that I had long removed ).
Convert the virtualbox VDI to a raw image ( the VDI file is found in ~/.VirtualBox/Machines/machinename/ ):

VBoxManage internalcommands converttoraw vboximage.vdi ec2.img

Compress the image, this reduced my image down from 10GB to ~400MB:

tar cjf image.tar.bz2 ec2.img

Delete the uncompressed image:

rm ec2.img

Turning the Image into an AMI

Start up a new Amazon EC2 instance ( you can use any standard EC2 Linux VM for this ), and upload the image using scp (or another method):

scp image.tar.bz2 user@imagingserver:

Through the AWS control panel, create a new EBS volume ( ideally the same size as the VirtualBox VM ) and attach it to the instance. Make a note of the volume device name ( in my case /dev/sdi ), and overwrite the EBS volume with the image we have just uploaded:

tar xf image.tar.bz2 -O | dd of=/dev/sdi bs=10M

The EC2 volume now has our VM on it. You may notice that although the data has completed being written to the disk, there is no entries in /dev for the partitions. We need to tell Linux to update it’s partition listing, simply run fdisk against the volume, print the partition table, then write the ( unchanged )  layout:

# fdisk /dev/sdi

Command (m for help): p

Disk /dev/sdi: 10.7 GB, 10737418240 bytes
255 heads, 63 sectors/track, 1305 cylinders, total 20971520 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xeb52e322

   Device Boot      Start         End      Blocks   Id  System
/dev/sdi1              63    20964824    10482381   83  Linux

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.
Syncing disks.

/dev/sdi1 ( in this case ) now exists. Mount the volume to check that it looks sane, then unmount it:

mkdir /mnt/newimage
mount /dev/sdi1 /mnt/newimage
ls /mnt/newimage
...
umount /mnt/newimage

Through the AWS control panel, detach the volume, take a snapshot and make a note of the snapshot id. You can delete the volume once the snapshot is complete. Also find the correct snapshot id for your instance from this guide then register the image, replacing $SNAPSHOTID, $KERNELID, name and description with your values:

ec2-register -a x86_64 -n "Name" -d "Description" --root-device-name /dev/sda1 -b /dev/sda=$SNAPSHOTID:10:true --kernel $KERNELID

You should now be able to start the new instance and have it boot your own customized Linux EC2 AMI.

In this example, we have two servers, server1 and server2. If there is no DNS setup to do this already, the first step is to add these entries on each machine, replacing the server IPs with the correct ones:

192.168.1.100 server1
192.168.1.101 server2

Next, simply install and start sys-cluster/glusterfs on each machine:

emerge sys-cluster/glusterfs
/etc/init.d/glusterd start

A Glusterfs daemon should now be listening on both servers. Next we need to probe the second server from the first ( which fixes the ‘Host server2 not a friend’ error message which I had before I ran this ), simply run this on server1:

gluster peer probe server2

You can now confirm that the machines can see each other using the gluster peer status command ( you can do this on both machines and they should report each other ):

# gluster peer status
Number of Peers: 1

Hostname: server2
Uuid: 963aee89-fca3-4a5a-90ae-ada89f8a277d
State: Peer in Cluster (Connected)

Now we have GlusterFS up and running, we can create a directory to store the data on each machine:

mkdir -p /export/store1

Now we can actually create the volume for the data to sit on. For this example I have set replica to be 2, so the data will exist on all machines ( this command only needs to be ran on server1 ):

gluster volume create test-volume replica 2 transport tcp server1:/export/store1 server2:/export/store1

This should return successfully, now we can start the volume ( again, only run this on server1 ):

gluster volume start test-volume

We now have a GlusterFS volume up and running, but before we can access the file-system, we need to mount it. First create a mount-point on both servers:

mkdir /mnt/glusterfs

Then ensure GlusterFS runs on boot ( on both servers ):

rc-update add glusterd default

And add a row to fstab on server1 ( so the file-system is mounted on boot ):

server1:/test-volume /mnt/glusterfs glusterfs auto,rw,allow_other,default_permissions,max_read=131072 0 0

Then server2:

server2:
server2:/test-volume /mnt/glusterfs glusterfs auto,rw,allow_other,default_permissions,max_read=131072 0 0

On both servers we can now mount the file-system manually, and should be able to add/remove/copy etc files on one machine and have it appear on the other:

mount /mnt/glusterfs

Assuming there were no errors reporting, the disks should now stay in sync ( it seems that even when one machine is disabled, and files are added to the disk , the files are copied to the other machine when it returns. ), and you have a solution for serving or sharing multiple files across multiple servers.

checking for keyutils.h... no
configure: error: keyutils.h header not found.

!!! Please attach the following file when seeking support:
!!! /var/tmp/portage/net-fs/nfs-utils-1.2.4/work/nfs-utils-1.2.4/config.log
 * ERROR: net-fs/nfs-utils-1.2.4 failed (configure phase):
 *   econf failed
 *
 * Call stack:
 *     ebuild.sh, line   56:  Called src_configure
 *   environment, line 2566:  Called econf '--with-statedir=/var/lib/nfs' '--enable-tirpc' '--with-tcp-wrappers' '--enable-nfsv3' '--enable-nfsv4' '--enable-ipv6' '--disable-caps' '--disable-gss'
 *     ebuild.sh, line  561:  Called die
 * The specific snippet of code:
 *                      die "econf failed"
 *
 * If you need support, post the output of 'emerge --info =net-fs/nfs-utils-1.2.4',
 * the complete build log and the output of 'emerge -pqv =net-fs/nfs-utils-1.2.4'.
 * The complete build log is located at '/var/tmp/portage/net-fs/nfs-utils-1.2.4/temp/build.log'.
 * The ebuild environment file is located at '/var/tmp/portage/net-fs/nfs-utils-1.2.4/temp/environment'.
 * S: '/var/tmp/portage/net-fs/nfs-utils-1.2.4/work/nfs-utils-1.2.4'

>>> Failed to emerge net-fs/nfs-utils-1.2.4, Log file:

>>>  '/var/tmp/portage/net-fs/nfs-utils-1.2.4/temp/build.log'

 * Messages for package net-fs/nfs-utils-1.2.4:

 * ERROR: net-fs/nfs-utils-1.2.4 failed (configure phase):
 *   econf failed
 *
 * Call stack:
 *     ebuild.sh, line   56:  Called src_configure
 *   environment, line 2566:  Called econf '--with-statedir=/var/lib/nfs' '--enable-tirpc' '--with-tcp-wrappers' '--enable-nfsv3' '--enable-nfsv4' '--enable-ipv6' '--disable-caps' '--disable-gss'
 *     ebuild.sh, line  561:  Called die
 * The specific snippet of code:
 *                      die "econf failed"
 *
 * If you need support, post the output of 'emerge --info =net-fs/nfs-utils-1.2.4',
 * the complete build log and the output of 'emerge -pqv =net-fs/nfs-utils-1.2.4'.
 * The complete build log is located at '/var/tmp/portage/net-fs/nfs-utils-1.2.4/temp/build.log'.
 * The ebuild environment file is located at '/var/tmp/portage/net-fs/nfs-utils-1.2.4/temp/environment'.
 * S: '/var/tmp/portage/net-fs/nfs-utils-1.2.4/work/nfs-utils-1.2.4'

The solution seems to simply be install sys-apps/keyutils .