Sunday Aug 09, 2009

Using ZFS Rollback and VirtualBox for Development

I came across this nice blog entry that shows how you can use ZFS's snapshot and rollback features along with VirtualBox to make it really easy (and safe) to try things out during development and not have to worry about losing track of exactly which changes you made when you want to go back to a clean state.

For me, this helps in creation of web sites.  I am using Drupal to create a web site, but there's a lot of exploratory development I'm doing and if I mess up something, I want to go back to a known-to-work state.  So, I create a VirtualBox image (OpenSolaris as my guest OS), then work with Drupal on that image.  The thing is, sometimes I make changes that affect the state of the operating system so I want to cleanly go back to a working state.  This blog entry shows me how to do exactly that.

Powered by ScribeFire.

Friday Mar 20, 2009

Notes on Setting up a Drupal automated test bot on OpenSolaris

On, there is a topic about how to set up an automated test bot.  I'd like us at Sun to contribute to Drupal's automated test farm, so I'm trying to set up a computer running OpenSolaris to be a test server.  Here are notes I've taken based on the work I've done so far to get it working.

I got the test package here.  Unpacked it into /var/local, as per the instructions listed here.

- To get my test bot running on OpenSolaris, I have modified the following files in the directory tree:
First, I created a new profile, called it "opensolaris" (here it is).  Some parameters are different on OpenSolaris than on CentOS or Debian / Ubuntu; re-defined as appropriate for OpenSolaris.  (example: starting, stopping, and re-launching services like Apache.  Use the Service Management Framework (SMF) In OpenSolaris for easy start/stop/restart of services and automatically take care of other services which may need to be managed as dependencies.)

Next, tried to run the "" script to see if everything just worked.  Nope.  Ran into several obstacles; here they are, with the fixes / workarounds to make things work.

Obstacle #1: cvs checkout with "-z6" option seemed to stall.  I think the check-out happened okay and cvs just isn't exiting, but I'm not sure.

Fix #1: added new variable to the profiles: CVS_COMPRESSION.  Then, modified the "install" shell script; whenever it used to say "$CVS -z6", substitute "$CVS $CVS_COMPRESSION".  Now in the platform-specific templates (in the profiles/ directory), look where "CVS" is defined.  Add a line before it, creating a new variable called "CVS_COMPRESSION" and on OpenSolaris, define it as empty (i.e., don't pass the "-z6" flag).  The cvs works fine without the "-z6" option.

Note to self: need to find out why -z6 didn't work.

Obstacle #2: tried running the script, it complained that it can't log into MySQL with root user & password.

Fix #2: I forgot to set up the DB with password.  Went into MySQL and did that.

Obstacle #3: APACHE_INIT didn't work as currently defined.  Needs to accommodate different ways of starting services; in particular, the OpenSolaris svcadm command syntax different from using init.d.

Fix #3: Modify the definition of $APACHE_INIT for OpenSolaris.  Also, modify the "install" script to just invoke "$APACHE_INIT" with no arguments (i.e., no "restart") since it'll now be part of the $APACHE_INIT variable itself.

Obstacle #4: during useradd, complains that usernames are too long. Red herring; it's a warning, not an error.

Fix #3: ignore it.  Ideally, either have OpenSolaris accept usernames longer than 8 characters (really, it doesn't do that?), or shorten the usernames for Drupal test package.

Obstacle #4: during useradd, the use of the "-m" flag caused useradd to fail.  Why does "-m" fail?  It's a conflict with trying to add directory in /home, which is automount-mapped to /export/home.  There's an OpenSolaris bug about this.

Fix #4: Specify a "-b" option to set the base directory to /export/home, i.e., "-b /export/home".  Added a variable to the profiles: "USERADDFLAGS", specified "-b /export/home" in the opensolaris profile.  Then, changed the "install" script to invoke $USERADD with $USERADDFLAGS.

Alternate Fix #4: disable automounting for the test apparatus.  I didn't try that.

Obstacle #5: PHP complains about not having valid timezone set.  Script continues fine, doesn't complain, but I'd like to get rid of the warning complaint message.  I'd rather not modify the php.ini file to set timezone, but setting TZ didn't work either.

Fix #5: Set /etc/php/5.2/php.ini line "date.timezone" to "US/Pacific"; that eliminates the warning complaint message.

After these fixes, the script ran to completion.  Next, launched the browser, tried to visit my virtual test site's virtual domain, which I called "".

Obstacle #6: In my browser, went to http://localhost.  Nothing appeared.

Fix #6: Don't go there; go to instead.  That's the virtual site used for the testing.

Obstacle #7: In my browser, went to  Nothing appeared.  Need to tell my system to resolve "" to "" (i.e., localhost).

Fix #7: added "" to the end of the line in /etc/hosts that contains "".  The entire line now looks like this: vbox-testhost localhost loghost

Obstacle #8: In my browser, went to  Apache told me it couldn't access this site; didn't have permissions to access the drupal subdir in /var/www, where the drupal instance is installed.  As it turns out; the install process creates a "vhosts.conf" file to tell Apache that we're creating a virtual host (; the install process puts this in /var/apache2/2.2/vhosts.conf which is fine, but the default Apache install on OpenSolaris denies access to virtual directories. 

Fix #8: Reverse access policy for the virtual host.  Modify the "install" script, the section that begins and add the following two lines to that directive:

Order allow,deny
Allow from all

(note: no space around the comman separating allow and deny)

Next, restart the web server (go to the GNOME Applications menu and choose "Applications -> Developer Tools -> Web Stack Admin -> Start Apache2/MySQL Servers".

Now, browsing to works; I see the DrupalTestBot page and can log into Drupal.

Note to self: was this the correct way to give permissions to Apache for the drupal directory root /var/www/drupal on the VirtualHost

Okay, so now it's all configured; so far, so good.  What next?

How can I try out my test bot to see if it's configured and working correctly?

How do I make my test bot part of the test server farm?

Powered by ScribeFire.


The views expressed on this blog are my own and do not necessarily reflect the views of Oracle. What more do you need to know, really?


« April 2014