What happens downstream?: Scott Mattoon's blog

OpenSolaris is widely know as a state of the art and feature rich server operating system. So, it's a little surprising to many users trying it for the first time when they find that it is also a full fledged desktop environment.

But what if you don't want all that Gnome-Firefox-VNC-Xorg goodness in your base installation?

Well, you could pick through all the packages on the system looking for the desktop tools, examine them for dependencies, and build a manifest for removal. Or, if you're on OpenSolaris 200906, then you could just use Glenn's minimization script that comes in the samples with Immutable Service Containers (ISC) Construction Kit for OpenSolaris. To get it, grab a copy of the ISC project:

	$ hg clone https://kenai.com/hg/isc~source  isc

Then run the script:

	$ pfexec isc/opt/samples/minimization.ksh

The script will remove 237 packages and disable 11 services that are non-essential to running OpenSolaris strictly as a server. The project page on Kenai gives a little more background on the minimization script. Note: this minimization is separate from the hardening that the core ISC installation will perform on the systems. While you're at it, you might also try ISC itself, or install the pre-configured OpenSolaris ISC image, which is available in OVF format. Instructions are on the Immutable Service Containers Construction Kit page.

Whilst installing Drupal 6.0 on Solaris Express Developer Edition (SXDE) 1/08 I ran into a few glitches with the brand new Webstack, which makes it's debut in this build of OpenSolaris.  (SXDE is Sun's distro of OpenSolaris.  It's the best way to get access to all the latest stuff in a relatively feature complete distro of OpenSolaris without having to build the whole O/S yourself.)  With the advent of Webstack integration you don't need a separate download to get all the AMP stack integration and optimizations previously only available in Coolstack.

The executive summary of the solution to the Drupal 6.0 install glitches is:

1. Edit  /etc/php5/5.2.4/php.ini  to add '.' and Drupal's base dir (/opt/drupal-6.0, in my case) to PHP's include_path:

   include_path = ".:/usr/php5/5.2.4/include/php:/opt/drupal-6.0"  

2. Spoof PHP into thinking it's using an older MySQL client:
   

   ln -sf /usr/mysql/5.0/lib/mysql/libmysqlclient.so.15 \ 
   /usr/mysql/5.0/lib/mysql/libmysqlclient.so.12 

Now, with these fixes in place, I have the advantages of the Service Management Framework (SMF) and DTrace, plus an AMP stack compiled with optimizations for Solaris and the processor architecture (AMD64, in my case). 

If you're interested in a more detailed account of the glitches and fixes, read on...

---

The first glitch prevented the Drupal index.php page from rendering, and appeared in the apache error_log as:

PHP Warning:  include_once() [<a href='function.include'>function.include</a>]: Failed opening 
'includes/install.inc' for inclusion (include_path='/usr/php5/5.2.4/include/php' 

which was remedied by adding '.' to the include path in include_path in /etc/php5/5.2.4/php.ini

include_path = ".:/usr/php5/5.2.4/include/php" 

Then, proceeding to the database setup, MySQL gave an error:

"Client does not support authentication protocol requested"

This was easily resolved by the procedure posted on http://dev.mysql.com/doc/refman/5.0/en/old-client.html, but that's a compromise on MySQL password strength, so not ideal.   This allowed me to proceed to the next glitch, which apache error_log explained as:

"ld.so.1: httpd: fatal: relocation error: file 
/usr/php5/5.2.4/modules/mysqli.so: symbol 
mysql_set_local_infile_handler: referenced symbol not found" 

After much hair pulling, Sriram pointed me to the solution he worked out for the same problem with MediaWiki installation:

ln -sf /usr/mysql/5.0/lib/mysql/libmysqlclient.so.15 \
/usr/mysql/5.0/lib/mysql/libmysqlclient.so.12  

and another addition to include_path in /etc/php5/5.2.4/php.ini to add Drupal's base dir

include_path = ".:/usr/php5/5.2.4/include/php:/opt/drupal-6.0" 

Turns out that spoofing the library name like this also solved the "Client does not support authentication protocol ..." problem too, so I'm back to full MySQL password strength.

After these three simple but obscure fixes it was all clean sailing.  I now have Drupal running in six zones across two separate instances of SXDE 1/08 using the latest Webstack.