Things on my mind. George Drapeau's Weblog

Sometimes my TiVo gets confused after a power outage, and it takes forever to reboot (I think it's trying to recover its files which takes a while when you have over 1TB of storage connected to the TiVo).  Sometimes, I lose some of my shows, and that makes me sad.

So I decided to find some software I could get running on OpenSolaris so I could use my home media server as a backup device for my TiVo shows.

I did it, using the Galleon open source Java application; here's how.

Now, if somebody smarter than me would just port the TiVo software to OpenSolaris, we'd have the benefits of ZFS on a TiVo box.  That would be fantastic.

Powered by ScribeFire.

I just published a short how-to video showing how you can easily install Acquia Drupal on OpenSolaris.


Sun's ISV Engineering group has been working with Drupal for a couple of years now; I also use Acquia Drupal to develop and maintain this web site, which also hosts my personal blog.  The Drupal community is amazingly vibrant and growing by leaps and bounds, and Acquia has done a nice job of commercializing the Drupal open source content management software package.  Acquia Drupal is still free, but it has some nice additions that any Drupal user or developer would want.

Anyway, check out the video; it's about 8 minutes long and walks you through the steps to find the catalog of third party applications, then get Acquia Drupal and configure it on your OpenSolaris system.  It's easy, and it just works.

Oh and by the way: props to our Sun Learning Exchange web site and staff for making it so darned easy to publish content.  Nice job, folks!

Powered by ScribeFire.

Rack is a webserver interface for the Ruby open source programming environment.  Amanda Waite took the trouble of making this package available via the OpenSolaris packaging mechanism; ultimately, ruby-rack will be in the OpenSolaris "contrib" repository, but not until it gets a little testing and review, and some votes from the community, this functionality is now in the OpenSolaris "pending" repository.  I admit to great naivete about Ruby, so I'll refer you to this excellent explanation of what Rack does for Ruby developers.  (my summary of what I got from the explanation: Rack is a web framework for Ruby developers; in other words, if you like writing Ruby code and you want to write code to create a web-based application, Rack is a nice extension to Ruby to make doing this easy).

Anyway, been doing some testing of the package that Amanda submitted.  Here's what I did and what I observed:

First, I made sure I had access to the OpenSolaris Source Juicer "pending" repository.  As I've noted before, two steps:

1. type "pfexec pkg set-publisher -O http://jucr.opensolaris.org/pending jucr-pending"
2. type "pfexec pkg refresh"

After that, the next time you launch the Package Manager application, look on the right side of the application and you can choose "jucr-pending" from the pop-up menu.  Do that, and after a moment you'll see a list of all the packages in the "pending" repository.  You will find the package "ruby-rack" there.  Note that case matters; the package name is all lowercase.

So I did this and downloaded the package.  The package notes that it depends on the Ruby package.  The Package Manager pulled it in just fine.  How do I know?  Before installation, I could not type "ruby" and get anything back.  Afterward, it worked.

Next step:

$ cd /usr/ruby/1.8/lib/ruby/gems/1.8/gems/rack-1.0.1/example
$ rackup lobster.ru


This starts a web server on port 9292 with a little "lobster" program.  I launch the web browser and go to "http://localhost:9292" and I saw a simple web app that shows a crude "picture" of a lobster, and two things I can do: flip the lobster from right to left and back again, and show a crash dump of the Ruby Rack program.  I tried both of those things; they worked just fine.

After this, I killed the "rackup" program then tried it again with the other ".ru" file in that same directory, "protectedlobster.ru".  That gives an added feature of authenticating into the web app (password is "secret"; as far as I can tell, use any username you wish).  That worked, too: if I didn't provide the right password, nothing happened.  If I provided the right password, it worked fine.

So that all worked just fine.  The next set of tests was more in-depth, running a partial test suite.  For this set of steps, I had to install both the "SUNWgcc" and "SUNWgmake" packages, again with the Package Manager.  I did these steps:

1. su - (i.e., pretend you're root; without doing this, step 3 below complained that it couldn't write to /var/ruby/1.8/gem_home/bin)
   
2. Add /var/ruby/1.8/gem_home/bin to your $PATH
3. type CXX=/usr/sfw/bin/g++ gem install memcache-client ruby-openid camping mongrel thin test-spec --no-ri --no-rdoc
4. type "gem install rake"
   
5. type "rake test".

The output showed it compiling some stuff, then it said "Started" followed by a bunch of periods showing status, then "Finish in 3.960495 seconds."  Finally, a results line said "267 tests, 928 assertions, 0 failures, 0 errors".

That sounds like good news to me!

So folks: the Ruby Rack web framework is available via OpenSolaris.  Check it out and see if it works for you, Ruby developers.  Let us know how it goes, will ya?

Powered by ScribeFire.

SilverStripe is an open source content management system (CMS); we in Sun's ISV Engineering department have been working on getting this and other important open source applications into the OpenSolaris "contrib" repository, a place meant for third party applications that anybody can contribute.  I've been testing the SilverStripe package that Jenny Chen contributed; here are my notes.

Mostly, SilverStripe installs just fine; however, it has the same little hiccup as Joomla! did when I tested its installer.  (I documented that problem and workaround here)  No big deal, though: it's easy to apply the same quick workaround for MySQL before you get on your way.

Once done, I launched my web browser on my OpenSolaris box and went here: "http://localhost/silverstripe".  That brings me to the web-based SilverStripe installer.  It all looks good, but one thing to note at the bottom of the page (in the "Webserver Configuration" section) is that SilverStripe can't tell what web server OpenSolaris is running.  With the Web Stack, we're running the Apache web server.

One other note from the SilverStripe installer: it advises me to set the "allow_call_time_pass_reference" parameter in /etc/php/5.2/php.ini to "On", which I did just to avoid getting warnings shown to me during the installation process.

Anyway, did that, then pressed the "Install SilverStripe" button to get the installation on its way.  The installation took two minutes fifteen seconds (really; I timed it) under a fairly heavily-loaded computer.

It worked fine; I was able to add a couple of pages to my site, add a user and give that user privileges, and see it in action.

So now, if you use SilverStripe you can get to it in OpenSolaris via the Package Manager.  If you don't know how to install packages from the OpenSolaris "pending" repository (a staging area we use to test packages before they're promoted to the "contrib" repo I mentioned above)., then the main thing you need to learn is how to add repositories to your Package Manager application.  Do these two steps from a shell on your OpenSolaris installation:

1. type "pfexec pkg set-publisher -O http://jucr.opensolaris.org/pending jucr-pending"
2. type "pfexec pkg refresh"

After that, the next time you launch the Package Manager application, look on the right side of the application and you can choose "jucr-pending" from the pop-up menu.  Do that, and after a moment you'll see a list of all the packages in the "pending" repository.  You will find the package "silverstripe" there.  Note that case matters; the package name is all lowercase.

Check it out and let us know what you think.  Did SilverStripe install and work fine for you in OpenSolaris?  Give us some feedback.

Powered by ScribeFire.

Nagios is an open source system monitoring software package; we thought it important to get the Nagios community supported on OpenSolaris so Sun's ISV Engineering department spent some time on the task.  You can check out our results by going to the OpenSolaris "pending" repository and installing these packages:

1. nagios
2. nagios-plugins
3. nrpe

If you want to see what I did to test these packages after installation, look at this review page and you'll see my comments from October 17.

If you don't know how to install packages from the OpenSolaris "pending" repository, then the main thing you need to learn is how to add repositories to your Package Manager application.  Do these two steps from a shell on your OpenSolaris installation:

1. type "pfexec pkg set-authority -O http://jucr.opensolaris.org/pending jucr-pending"
2. type "pfexec pkg refresh"

After that, the next time you launch the Package Manager application, look on the right side of the application and you can choose "jucr-pending" from the pop-up menu.  Do that, and after a moment you'll see a list of all the packages in the "pending" repository.  Nagios, nagios-plugins, and nrpe will be there.

Check 'em out, and leave comments to let us know what you think.  If they look fine, we'll promote them to the main third-party applications repository, the "contrib" repo.

Powered by ScribeFire.

Sun's ISV Engineering group has been working hard all spring and summer to get fistfuls of popular and important open source applications into the OpenSolaris "contrib" repository, a repo for third-party applications that can be assumed to have some level of sanity checking done on them.

Eric Reid in ISV Engineering has submitted three different releases of Drupal; today, the final release (Acquia Drupal) was approved and placed into /contrib.  These three applications are

1. Drupal 5 (release 5.20)
   
2. Drupal 6 (release 6.14)
   
3. Acquia Drupal, created by the commercial enterprise backing Drupal: Acquia.com
   

It's nice and easy to try out any of these Drupal packages in OpenSolaris.  Want help?  Read this entry on drupal.org for complete yet succinct instructions.

(update)
I should also point out that when you install Drupal in OpenSolaris, the package management system will pull in the Sun WebStack components automatically, which is all free as you would expect.  It's the AMP stack components you know and love, but optimized by Sun for out-of-the-box performance improvement, plus a management console that lets you see what's going on with the components while you're running your Drupal web site.

(Okay, that may have sounded a bit like an advertisement, but we really did put a lot of engineering effort into optimizing the AMP components on Sun's systems and the new analytics thingy is pretty cool looking.)
(/update)

Meanwhile, this adds one of the premier open source content management systems to the stable of apps freely and easily available to you when you install OpenSolaris on your computer.  You can even choose from amongst the leaders in blog engines / content management systems / web site building tools: Drupal, Joomla!, WordPress are all available now.  Here is a list of packages published to the contrib repository.

Check 'em out!

Powered by ScribeFire.

The OpenSolaris "/contrib" repository is a place where anybody can contribute open source software packages, which are then available for you to install on OpenSolaris.  Before a packages gets promoted to the contrib repo, you submit your package / application to a repository called "pending".  The idea is that people can test packages and get others to try them out before they get promoted so that the packages in "contrib" have been at least smoke-tested.

Recently I've noticed the number of packages and apps available growing pretty nicely, and I've been testing some of the apps that our own group (Sun's ISV Engineering organization) has been contributing.  Most of the packages I've tested have gone smoothly.  One gave me a little hiccup so I thought I'd describe what I did to get it working.

That package is the Joomla! content management system.

Installation was actually a snap; once you install the package with the OpenSolaris Package Manager, just fire up the web browser and go to http://localhost/joomla and you get the Joomla! installer.

Well, it's a little more complicated than that; you need to make sure you create a database for Joomla! to use, like this:

mysqladmin -u joomla -p create joomla

mysql -u joomla -p
mysql> grant all privileges on joomla.* to 'joomla'@'localhost' identified by [password in single quotes here];

(assuming I created a MySQL database user called "joomla", I'm also creating a database called "joomla")

After a few web screens, I can login as the Joomla! admin just fine, but trying to go to the Joomla! front page as a regular non-admin person causes a long series of errors to spit out at me (and rather rudely, I might add); see the end of this post for the details.

Turns out it's a MySQL problem; you can see the discussion here.  The current workaround is to run MySQL in 64-bit mode, but in order to do that, you need to make sure you're running OpenSolaris in 64-bit mode.  If you type "isainfo -k" and it returns "x86", that's not good enough.

I am doing my testing in VirtualBox; to make sure I'm running OpenSolaris in 64-bit mode, I go to the VirtualBox main application panel where I can see the settings for my virtual machine.  Near the top, the section called "General", The "OS Type" field sais "OpenSolaris".  I change that to "OpenSolaris (64-bit)" and the next time I boot OpenSolaris, it's in 64-bit mode.

One more step; making sure to launch the 64-bit version of the MySQL service.  Do this:

svccfg -s mysql:version_51 setprop mysql/enable_64bit=true
svcadm refresh mysql:version_51
svcadm restart mysql:version_51

I did just this, and went back to http://localhost/joomla and everything worked perfectly well.  Joomla! works just fine in OpenSolaris, as you would expect.  Nice looking app, too.

P.S.:  (Joomla / MySQL error message below)



* Error loading Modules:MySQL server has gone away SQL=SELECT
id, title, module, position, content, showtitle, control, params FROM
jos_modules AS m LEFT JOIN jos_modules_menu AS mm ON mm.moduleid =
m.id WHERE m.published = 1 AND m.access <= 0 AND m.client_id = 0 AND (
mm.menuid = 1 OR mm.menuid = 0 ) ORDER BY position, ordering
* Error loading Modules:MySQL server has gone away SQL=SELECT
id, title, module, position, content, showtitle, control, params FROM
jos_modules AS m LEFT JOIN jos_modules_menu AS mm ON mm.moduleid =
m.id WHERE m.published = 1 AND m.access <= 0 AND m.client_id = 0 AND (
mm.menuid = 1 OR mm.menuid = 0 ) ORDER BY position, ordering
* Error loading Modules:MySQL server has gone away SQL=SELECT
id, title, module, position, content, showtitle, control, params FROM
jos_modules AS m LEFT JOIN jos_modules_menu AS mm ON mm.moduleid =
m.id WHERE m.published = 1 AND m.access <= 0 AND m.client_id = 0 AND (
mm.menuid = 1 OR mm.menuid = 0 ) ORDER BY position, ordering
* Error loading Modules:MySQL server has gone away SQL=SELECT
id, title, module, position, content, showtitle, control, params FROM
jos_modules AS m LEFT JOIN jos_modules_menu AS mm ON mm.moduleid =
m.id WHERE m.published = 1 AND m.access <= 0 AND m.client_id = 0 AND (
mm.menuid = 1 OR mm.menuid = 0 ) ORDER BY position, ordering
* Error loading Modules:MySQL server has gone away SQL=SELECT
id, title, module, position, content, showtitle, control, params FROM
jos_modules AS m LEFT JOIN jos_modules_menu AS mm ON mm.moduleid =
m.id WHERE m.published = 1 AND m.access <= 0 AND m.client_id = 0 AND (
mm.menuid = 1 OR mm.menuid = 0 ) ORDER BY position, ordering
* Error loading Modules:MySQL server has gone away SQL=SELECT
id, title, module, position, content, showtitle, control, params FROM
jos_modules AS m LEFT JOIN jos_modules_menu AS mm ON mm.moduleid =
m.id WHERE m.published = 1 AND m.access <= 0 AND m.client_id = 0 AND (
mm.menuid = 1 OR mm.menuid = 0 ) ORDER BY position, ordering
* Error loading Modules:MySQL server has gone away SQL=SELECT
id, title, module, position, content, showtitle, control, params FROM
jos_modules AS m LEFT JOIN jos_modules_menu AS mm ON mm.moduleid =
m.id WHERE m.published = 1 AND m.access <= 0 AND m.client_id = 0 AND (
mm.menuid = 1 OR mm.menuid = 0 ) ORDER BY position, ordering
* Error loading Modules:MySQL server has gone away SQL=SELECT
id, title, module, position, content, showtitle, control, params FROM
jos_modules AS m LEFT JOIN jos_modules_menu AS mm ON mm.moduleid =
m.id WHERE m.published = 1 AND m.access <= 0 AND m.client_id = 0 AND (
mm.menuid = 1 OR mm.menuid = 0 ) ORDER BY position, orderingTechnorati Tags: opensource, opensolaris, solaris, joomla, virtualbox, mysql, install, installation, content management

Powered by ScribeFire.

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.

I listen to a lot of podcasts, usually when during my runs or while I'm driving.  One of the podcasts I've been listening to over the past few years is This Week in Tech (TWiT), hosted by Leo Laporte.

Well, he's got a network of podcasts on the TWiT Network and I recently found a new one that I think is pretty good: FLOSS (Free Libre Open Source Software).  It's a weekly show in an interview format; each episode is about a different open source topic or person.

Recently, FLOSS interviewed Sun's own Glynn Foster to discuss OpenSolaris.  Not a bad introduction to OpenSolaris if you haven't checked it out yet.

Another Sun-related FLOSS Weekly is the ZFS podcast.

I also enjoyed the interview with Jono Bacon of Canonical; it looks like there are plenty of other FLOSS episodes worth a listen.

Powered by ScribeFire.

Here's something I don't understand: I'm trying to compile the open source program "ffmpeg", useful for transcoding from one kind of movie file and video encoding format to another, plus a whole big bag-o-tricks.

So I download the source code:

svn checkout svn://svn.ffmpeg.org/ffmpeg/trunk ffmpeg

Then I go into the ffmpeg source directory and type "./configure".  It fails, reporting:

check_ld
check_cc
BEGIN /tmp/ffconf.XXRJaOkG.c
    1   #include <signal.h>
    2   static void sighandler(int sig){
    3       raise(SIGTERM);
    4   }
    5   int main(void){
    6       signal(SIGILL, sighandler);
    7       signal(SIGFPE, sighandler);
    8       signal(SIGSEGV, sighandler);
    9   #ifdef SIGBUS
   10       signal(SIGBUS, sighandler);
   11   #endif
   12       {     volatile int i=0;
   13       __asm__ volatile (
   14           "xorl %%ebp, %%ebp"
   15       ::: "%ebp");
   16       return i; }
   17   }
END /tmp/ffconf.XXRJaOkG.c
gcc -D_ISOC99_SOURCE -D_POSIX_C_SOURCE=200112 -std=c99
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D__EXTENSIONS__
-fomit-frame-pointer -c -o /tmp/ffconf.XXYJaalG.o
/tmp/ffconf.XXRJaOkG.c
gcc -o /tmp/ffconf.XXTJaWkG /tmp/ffconf.XXYJaalG.o
./configure: line 663: 16530: Terminated

I can't tell why it fails even making a Makefile, but after scanning the web for a while, I find a suggestion that says "use bash as your shell instead of whatever shell you were using."  I had been using tcsh, then tried ksh, then tried sh, all with the same error result.

So then I try "bash configure".  What do you know?  It created a Makefile just fine.

Now why is that?  Can somebody help me out here?  Because I don't know why the choice of a shell would make the configure script succeed or fail.  And that seems bad for the other shells available on OpenSolaris.

The app seems to compile, mostly.  Next: see how much of the app got compiled and how much of it runs.

Why am I doing this?  Because it's part of "pyTiVo", which I'd like to get running on my OpenSolaris home media server, so that I can back up the TiVo's content onto this nice, ZFS-enabled server.  I'll update my progress here.

Powered by ScribeFire.

The SourceJuicer is a tool in OpenSolaris meant to simplify the process of getting apps onto OpenSolaris.  The tool works by taking a file specifying the contents of the package to be installed (called a "spec file"); this includes information on where to fetch the source code for the application package, directions on how to build from source, then where to install the resulting app.

Ultimately, packages built using SourceJuicer will be reviewed and voted into the "/contrib" repository, a repo for third-party applications not necessarily part of the OpenSolaris core distribution.  SourceJuicer puts the packages it builds into a repo called "/pending"; to test these apps, you need to tell the package manager where the /pending repository is.

I want to take my OpenSolaris 2008.11 distribution and play with some of the new packages in /pending.  For example, I want to try the Azureus (now called Vuze) BitTorrent Java application which somebody just made available on OpenSolaris.  To do so, I need to do the following steps:

• Add the SourceJuicer "/pending" repo to the list of repo's known to the package manager:

• $ pfexec pkg set-authority -O http://jucr.opensolaris.org/pending jucrpending

• Now I can install the package I want (in this case, "vuze", the name of the Azureus/Vuze application):

• $ pfexec pkg install vuze

Simple as that.

I can also add this package repo and install the package via the graphical "Package Manager" interface, available via the menu choice System -> Administration -> Package Manager.  Once the Package Manager is launched, I choose the menu choice "Settings -> Manage Repositories..." to add the SourceJuicer pending repo.

Powered by ScribeFire.

As I'm learning how to use Drupal for creating and deploying web sites, I'm keeping track of it in blog entries.

The way I work: I do my development on a virtualized environment: I run OpenSolaris as a guest OS under VirtualBox; that way, I can easily blow away my development/test environment or send it to other machines running VirtualBox.  Then, I install the WebStack (PHP, Apache web server, MySQL), then I install Drupal using the instructions on the drupal.org web site.

Once I get my test Drupal site working, I follow these instructions to deploy to an actual production server.  It makes the develop-test-deploy cycle pretty easy, and I can develop and test pretty much anywhere.

Powered by ScribeFire.

Looks like the VirtualBox people keep chugging along (although if you're moving at 150mph, is it right to call it "chugging"?).  Yesterday I saw they've released version 2.2, which supports the Open Virtualization Format (OVF).  This is what I like about it: when I want to share my software configuration with somebody, I make a vbox image and give it to somebody, but then they have to know the vbox VM configuration I used.  That means they have to go into the vbox UI and manually set up the same settings I did.  It's not difficult, but it's error-prone and it's tedious.

No longer: now I just tell VirtualBox to create an appliance out of my vbox image and it creates two files: an OVF image and the OVF description of that image.  When my co-worker wants to use my appliance, she tells vbox to import that appliance (the OVF description) and it does the right thing.  No configuration, nothing: it's just ready to go.  Nice and easy.

Jignesh Shah tried it out yesterday and created a relatively small-footprint OVF appliance of PostgreSQL 8.3.

I think this is going to be the way to distribute software in the near future.  And if not the way, then a valid way.  Virtualized images solve a few problems that I can think of:

1. You don't have to worry about which operating system the customer has deployed on their desktop or server; as long as they're running a hypervisor, you can deliver your software to them easily, nicely pre-packaged in a virtualized image "appliance";
2. it eliminates the install step for trying software: you've already packaged up your app in an appliance, no installation needed for the customer just makes things simpler and faster for them to get rolling;
3. The transition to cloud computing becomes easier; if you use a virtualized image on your desktop, you can use the same image on a cloud like Sun's cloud computing offering, Amazon EC2, or other clouds that I'm sure will come online over the next few years.  This gives customers the flexibility to run apps where they want, and to migrate to/from clouds.

JumpBox is one example of a company that provides open source applications in virtualized appliance format, but also lets you try their appliances right now, for free, on a cloud: it's JumpBox.  Nice idea.

TurnKey Linux seeems to be something similar; I haven't looked much into it yet so don't know if they offer the cloud preview feature that JumpBox provides, but they do have the download-an-app-in-a-virtualized-image feature.

Powered by ScribeFire.

On drupal.org, 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:

• testing_server_install/profiles/opensolaris (new file)
• testing_server_install/install  (here is my modified version)
  

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 "testing_server_install.sh" 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 "www.opensolarisdrupaltest.com".

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

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

Obstacle #7: In my browser, went to http://www.opensolarisdrupaltest.com.  Nothing appeared.  Need to tell my system to resolve "www.opensolarisdrupaltest.com" to "127.0.0.1" (i.e., localhost).

Fix #7: added "www.opensolarisdrupaltest.com" to the end of the line in /etc/hosts that contains "127.0.0.1".  The entire line now looks like this:

127.0.0.1 vbox-testhost localhost loghost www.opensolarisdrupaltest.com

Obstacle #8: In my browser, went to http://www.opensolarisdrupaltest.com.  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 (www.opensolarisdrupaltest.com); 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 http://www.opensolarisdrupaltest.com 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 www.opensolarisdrupaltest.com?


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.

Not too long ago, I blogged about a workaround to a bug in VirtualBox.  The problem is fixed in VirtualBox version 2.1.4, available for download here.

Here's where the bug fix comes in handy: suppose you use VirtualBox to create a virtual machine that you want to use again and again; maybe it's a test environment of Windows, Linux, OpenSolaris...whatever you like.  An easy way to make copies of that test environment is to type "VBoxManage clonevdi WindowsXP.vdi copyOfWinXP.vdi" (or whatever you call your VirtualBox hard disk images).  But the "clonevdi" command wasn't making copies correctly, so there was a workaround.  It's not a big deal, but having the bug fixed makes it just that much easier to make perfect copies of the environment you worked so hard to create.

I discovered at DrupalCon that a lot of people are using VirtualBox.  I have been a faithful VMware user for well over five years and have liked it, but I've also been using VirtualBox for about six months now and I find it good enough for my personal needs that I've switched from VMware to VirtualBox.  One nice little benefit: it can be a host on all the operating systems I use (Ubuntu Linux, Mac OS X, OpenSolaris; I tend not to use Windows as a host OS, only as a guest, because I'm too concerned about viruses infecting my Windows environment and I'd like to be able to just blow it away and start from scratch easily; VirtualBox lets me do just that).