Notes on Setting up a Drupal automated test bot on OpenSolaris
By drapeau on Mar 20, 2009
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)
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
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?
Powered by ScribeFire.