Well I just touched back down in Christchurch after returning from LCA2010 in Wellington. Overall the event was worth every penny and featured a number of high profile speakers from a number of FOSS projects. In fact, one thing that really struck me about the event was the number of 'offshore' speakers (in fact delegates too) - people that I would never have an opportunity to meet or hear present otherwise.

This was my first LCA and obviously coming from a Plone background, the web-related talks interested me most. So my conference itinerary consisted of (in no particular order): Puppet, Ruby, Drupal (yes I checked out 'the competition'), Pyglet (hey it's Python), PostgreSQL, Git, Xapian etc etc.

Some of the Plone highlights included: the PloneBoF - we ended up having 7 come along, which was more than the number that indicated they would come along on the wiki. The really good thing was that 3 of these hadn't put their names up on the wiki so if all the BoF'ers had come we would've had about 9 there. There was a lot of positive comments that came out of the BoF but the most interesting comment I took away was from a Systems Architect (ex-Unisys employee) who mentioned that Plone has 3 categories of user: Enterprise who only ever install the stable releases and don't upgrade at all, Developers who are always on the bleeding edge, and Everyone else whose initial attempt at installing Plone is via their distros package management system (there's probably another category of user in here who downloads the installers from plone.org but this was what he said). And as the Plone packages in most of the distro repositories are pretty out-of-date, their initial experiences aren't all to good. I was thinking that as the Plone installation process is buildout-based, this would be quite difficult to merge with the package installation process of most distros. It would be good, though, to make contact with some of the volunteers producing the various Plone distro packages and getting them to participate and interact a bit more with the core Plone community.

Attending the Drupal tutorial also opened my eyes to the excellent 3rd-party package installation experience Drupal provides for their users. Users can install 3rd-party packages directly from the administrative interface and also search for and install updates for their currently installed ones. That is something we need in Plone! Drupal does appear to be going through some of the growing pains Plone went through with content types developed thru-the-web and difficulty in porting this content type code to other Drupal instances - an essentially solved problem in the Plone space.

All-in-all an excellent event and one I'd definitely recommend to anyone. LCA2011 will be in Brisbane in February 2011 (dates to be confirmed). As an aside, I also took away some tips for Kiwi PyCon 2010, which is looking to be held in November 2010 - hopefully we'll see some of you there!

Recently I had to setup Enfold Server on Windows XP and as I run Kubuntu on my notebook, the virtual environment I've chosen to run Windows under is QEMU. I've been running QEMU for some time now and it provides all the features I need in a virtual machine, especially with kqemu installed. When I was in the process of setting up Enfold Server, though, I accidentally loaded the same QEMU image twice and the 2nd instance started running a CHKDSK on the drive and writing to it. After closing the 2nd instance down and restarting the already running Windows XP QEMU instance, Windows XP would get as far as the loading Windows XP screen and then cyclicly boot. I then attempted to mount the QEMU image (as it was in the RAW format) but when I did, I got the following error message: "primary boot sector is invalid". This was when alarm bells really started to ring as I'd put quite a lot of time and effort into this Windows XP QEMU image (including setting up all the Internet Explorer browsers and Safari for Windows), and unfortunately due to a file size error I was getting when attempting to backup the QEMU image, I didn't have a backup! After fruitlessly googling around for a resolution, I decided I'd attempt to boot off the Windows XP cdrom and attempt to recover the image that way. The following are the steps I took to restore my QEMU Windows XP Environment:

1. Booted off the Windows XP cdrom by typing the following at the command prompt:
   qemu winxp.img -cdrom /dev/cdrom -boot d
2. When the "Welcome to Setup" screen appeared, pressed R to start the Recovery Console.
3. Executed the FIXMBR command from the Recovery Console.
4. Ran a CHKDSK to fixup any other problems that may have existed.

I had the honour of giving the first Plone speech at the Academia Sinica in Taipei, Taiwan recently. TsungWei Hu, who arranged for me to give the speech, manages the Open Source Software Foundry (OSSF) project, whose key objectives are to promote Open Source Software in Taiwan. TsungWei mentioned that he had been meaning to ask Paul Everitt to give a speech regarding Plone at the Academia Sinica (Paul - hint, hint) but hadn't, so I got in first ;-)

This speech was the last in a series of Plone presentations I have been giving. The first of which was in Tokyo, Japan, and the next was for the Taipei Open Source Software User Group (TOSSUG). At the TOSSUG meetup I was able to meet Sean Moss-Pultz and Harald Welte of the OpenMoko project. Sean is the General/Technical Manager for the OpenMoko project, while Harald is the Lead System Level Architect. As I'm an Open Source fan and enjoy hacking my own computer, I'm really excited about what Sean, Harald and the rest of the OpenMoko Core Team are doing as mobile phones in general are pretty much closed devices nowadays.

N.B. The examples assume you are using a Linux-based operating system.

1. Do a subversion checkout of the instancemanager product into an appropriate location, by entering the following:
   

   svn co http://svn.plone.org/svn/collective/instancemanager/trunk/ instancemanager

2. Install instancemanager by entering the following command from within the instancemanager folder (this will ensure instancemanager runs from the checked out directory and can be easily updated):
   

   sudo python setup.py develop

3. The first time you run instancemanager (just type instancemanager and press Enter), it creates an .instancemanager directory in your home directory. There you'll find a userdefaults.py that you can customise to your local needs.
   The most relevant configuration directives you may want to change are the following:
   

   zope_instance_template (where your zope instances will reside)
   zope_location_template (the location where your zope server software resides - N.B. this can use python string substitution, e.g. /opt/zope/zope%(zope_version)s)
   user (default admin username)
   password (default admin password)

4. Following that, create a file called PROJECTNAME.py (can be empty) in the .instancemanager directory, customising that with project-specific settings (just copy the few items that you want to change from userdefaults.py.
   

   archive_basedir_template (the directory where all your zope/plone compressed product files are stored)
   symlink_basedir_template (the directory where you store your svn product checkouts)
   archivebundle_basedir_template (the directory where you store your zope/plone compressed product bundles - usually the same as archive_basedir_template)
   symlinkbundle_basedir_template (the directory where you store your svn bundle checkouts - usually the same as symlink_basedir_template)
   python (the path to your zope instance's python binary)
   zope_version (the version of the zope instance that hosts your Plone site)

5. Instancemanager expects to find the python/zope server software in a structured folder hierarchy (e.g. /opt/zope/zope2.9.6 and /opt/python/python2.4.4). I've found the easiest way to set this up is to use the Universal Installers listed on plone.org and modify the configuration directives in the install.sh bash script to point to those locations (for example, instead of pointing to /opt/Plone-2.5/ have them point to /opt/zope/zope2.9.6 and /opt/python/python2.4.4 respectively).
6. Copy the Data.fs with your Plone site's test data into the
   zope_instance_template/datafs folder, ensuring it's renamed to PROJECTNAME.fs.

   cp Data.fs ~/instances/datafs/PROJECTNAME.fs

7. Create the zope instance.
   

   instancemanager fresh PROJECTNAME

8. All going well, you should now have a new zope instance created for your Plone site accessible via the standard methods, i.e. http://localhost:8080/manage
9. Some further documentation regarding instancemanager can be found here.
   Some of the commands I often use are:
   

   instancemanager fresh PROJECTNAME (creates a new zope instance, including setting up all the Plone products as specified in the project file and also creates a new Plone site)
   instancemanager --products PROJECTNAME (just recreates the Products directory and all contained products)
   instancemanager soft PROJECTNAME (stops and starts the zope instance and reinstalls the products specified in the main_products configuration directive in the project file)
   instancemanager test PROJECTNAME (runs the tests for the main Plone product specified in the project file)
   instancemanager --test MyPloneProduct PROJECTNAME (runs the tests for the specified Plone product, i.e. MyPloneProduct)
   

Recently I had to setup Xen 3 for a client, and the following are the steps I undertook to install it (N.B. As a guide for the installation, I followed the instructions listed here).

The most pertinent hardware specifications for the server we installed Xen 3 on are as follows:

• 2x Intel Xeon 1.6 Ghz CPUs
• 4GB DDR2-667 RAM
• 3ware 9550SX-4LP PCI-X-to-SATA II RAID controller
• 4x Seagate Barracuda ES SATA 3.0GB/s 250GB hard drives (configured as RAID 5)
  

1. Firstly, I downloaded and burned the Debian testing (etch) netinst CD image to CD.
2. Following this, I began installing Debian etch on the server using the netinst CD.
   At the disk partitioning screen, I setup the hard drive as follows:
   Disk /dev/sda: 749.9 GB, 749966721024 bytes

255 heads, 63 sectors/track, 91178 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System
/dev/sda1 * 1 365 2931831 83 Linux
/dev/sda2 366 1581 9767520 8e Linux LVM
/dev/sda3 1582 4013 19535040 82 Linux swap / Solaris
/dev/sda4 4014 91178 700152862+ 8e Linux LVM

   N.B. The /dev/sda4 LVM partition is where the logical volumes for the Xen guest domains (virtual servers) are to be stored.
   I left the rest of the installation steps at their setup defaults.
   
3. I then installed Xen 3 on the server by entering the following command:
   apt-get install xen-linux-system-2.6.18-3-xen-686 xen-tools \\
xen-docs-3.0 libc6-xen file xen-hypervisor-3.0.3-1-i386-pae \\
xen-linux-system-2.6.18-3-xen-vserver-686 bridge-utils
4. Following this, I made the following change in the /etc/xen/xend-config.sxp file and rebooted the server:
   replace
   (network-script network-dummy)
   with
   (network-script 'network-bridge netdev=eth0')
5. I now made the following changes to the /etc/xen-tools/xen-tools.conf file:
lvm = vservers
debootstrap = 1
size = 10Gb
memory = 512Mb
swap = 1Gb
fs = reiserfs
dist = etch
image = sparse
kernel = /boot/vmlinuz-2.6.18-3-xen-vserver-686
initrd = /boot/initrd.img-2.6.18-3-xen-vserver-686
mirror = http://debian.orcon.net.nz/debian
   
6. Following this, I created a new guest domain (or virtual server) on the server by entering the following command:
   xen-create-image --hostname myservername.mydomain.co.nz --dhcp
7. I then booted the guest domain by entering the following:
   xm create /etc/xen/myservername.mydomain.co.nz.cfg
   
8. I now connected a virtual console to my newly created guest domain by entering the following and then logged on as root:
   xm console myservername.mydomain.co.nz
9. Finally, I set the root password and then logged off the
   virtual console by typing CTRL+] and then made a ssh connection to the guest domain and started setting up the services on it.