Corrupted boot archive on Solaris X86

We have an old rack server that runs a version of Solaris 10 for X86. For the most part, this machine never gives any trouble and we very rarely need to reboot. However, in recent months when we have rebooted it,  it has sometimes failed to boot, failing with a system console error that looks something like:

cannot read biosint
trap type 13 (0xd) err code 0x98b8 eip=0x0
...lots of register and stack trace data...
panic: corrupted boot archive . . . boot loader
Press any key to reboot

We found the instructions detailed here resolved this issue for us (although the error message is not exactly the same).

MySQL Upgrade Gotcha

I was trialling a MySQL database upgrade today (from 5.0 to 5.1) and hit a nasty little gotcha that I feel warrants a mention (mostly to myself). In its simplest form, the upgrade process is very straightforward and involves simply loading data dumped from MySQL 5.0 into a 5.1 database (using a regular mysql command), followed by a once-off execution of the mysql_upgrade command (to bring the various tables and grants up to date):

$ mysql -u root -p testdb < dumped50.sql
$ mysql_upgrade -u root -p testdb

However, when I tried the latter command, I received this error:

Looking for 'mysql' in: mysql
FATAL ERROR: Can't find 'mysql'

I did fine a simple solution here which was to first change to the directory containing the mysql_upgrade program itself and execute it from there:

$ cd /opt/coolstack/mysql/bin
$ ./mysql_upgrade -u root -p testdb

As I said, its a simple solution and I do tend to follow this general rule most of the time but nevertheless, the error generated when you don’t do this is far for informative.

Renaming a Solaris zone

I needed to rename a zone on a Solaris 10 system earlier this week and here are some notes on how I did it.

The process of renaming a zone is essentially a task of renaming, editing and replacing strings in a series of (mostly XML) configuration files. All of the tasks below were carried out from the global zone on the system in question.

1. Shut down the zone to be renamed

# zoneadm -z <oldname> halt

2. Modify the configuration files that store the relevant zone configuration

# vi /etc/zones/index
Change all references of <oldname> to <newname> as appropriate
# cd /etc/zones
# mv <oldname>.xml <newname>.xml
# vi <newname>.xml

Change all references of <oldname> to <newname> as appropriate

3. Rename the main zone path for the zone

# cd /export/zones
# mv <oldname> <newname>

Your zone path may be different than the one shown above

4. Modify (network) configuration files of new zone

Depending on the applications installed in your zone, there may be several files you need to update. The essential networking files are:

# cd /export/zones/<newname>/root
# vi etc/hosts
# vi etc/nodename

But others containing your old host/zone name can also be found using this command:

# cd /export/zones/<newname>/root/etc
# find . -type f | xargs grep <oldname>

5. Boot the new zone again
# zoneadm -z <newname> boot

Solaris Coolstack roadmap update

The Solaris Coolstack team have announced some important changes that impact on the future of the popular open source software stack. In a nutshell, they are combining their Cool Stack software (intended for use with Solaris 10) with their Web Stack software (intended for use for OpenSolaris) into a single software bundle, which will be known as Sun Web Stack.

Not only will this new stack be supported on Solaris 10 and OpenSolaris, but Linux support is also being added, as is full support for those using the software in production a capacity.

The first version of Sun Web Stack is scheduled for release in November 2008 and will follow the version numbering from Coolstack. Thus, the first release will be Sun Web Stack 1.4.

Source: Shanti’s Blog

Coolstack Squid Installation Notes

I recently installed Squid, the HTTP Proxy, for the first time. The version I installed was 2.6-STABLE16 and came as part of Solaris Coolstack 1.2. Here are some notes from the installation process:

Installation

The application on Solaris x86 using the pkgadd utility and the appropriate Coolstack Squid package file (CSKsquid_1.2_x86.pkg). The installation process also created a new SMF service called csk-squid.

Setup

This was the first time I had installed Squid so, after reading the documentation provided by Coolstack, I tried starting the Squid service. Unfortunately, it kept complaining about missing cache directories and file permissions, and would not start. In the end, a colleague directed me towards the squid -z command, which carried out all of the required post-installation setup and duly sorted out all of the directory/permissions problems.

Configuration

I only had to make two small changes to the Squid configuration file (/opt/coolstack/squid/etc/squid.conf):

  1. Squid uses port 3128 by default but, since our corporate firewall permits very few outbound ports, we modified squid to use port 8080 instead:
  2. http_port 8080

  3. We wanted to restrict access to the new HTTP Proxy to only a certain range of corporate IP addresses. This was easily achieved by adding a simple access rule as follows:
  4. acl my_networks src XXX.XXX.XXX.XXX/24
    http_access allow my_networks

Other than this, the process was surprisingly straightforward.

Trial migration from Coolstack 1.2 to 1.3.1

I got an opportunity to run a trial migration of several applications from Solaris Coolstack version 1.2 to version 1.3.1 recently. The Coolstack applications that we use include MySQL, Apache (including mod_jk), Tomcat and Memcached.

I had no problems at all with the Tomcat or Memcached upgrades but did hit 2 minor issues with MySQL and Apache (mod_jk actually).

1. MySQL

This involved going from MySQL 5.0.45 to 5.1.25 and whilst I found that a regular mysqldump of my MySQL 5.0 databases imported without error into MySQL 5.1, I did encounter some minor issues with user permissions later on. Fortunately, the guide to Upgrading from MySQL 5.0 to 5.1 proved very useful and revealed that I had missed an essential step in the upgrade process which was the use of the mysql_upgrade utility. There is lots more to read about in the upgrade guide and depending on your configuration, there may be more steps to be considered.

2. Apache (mod_jk)

Whilst the Apache upgrade (2.2.6 to 2.2.9) worked a treat, I found that mod_jk 1.2.26 employs stricter rules in relation to the placement of JkMount/JkMountFile commands in VirtualHosts. In my previous configuration, I had a single JkMount command inside my mod_jk.conf file (which in turn was included from the main httpd.conf file). However, using this configuration with Apache 2.2.9 and mod_jk 1.2.26, I found that my AJP load balancer was not working correctly for one of my VirtualHosts. It was only when I moved my JkMount command inside the scope of the VirtualHost that it started working again.

Other Comments

Most of the SMF service names in the Coolstack 1.3.1 applications have been renamed slightly. In Coolstack 1.2, all of the SMF service names began with csk- but now they all end with -csk instead. This was apparently done to make the service names more compatible with OpenSolaris but, to be honest, I find it a little bit annoying as we’ve written a number of useful scripts that manage these services explicitly by name.

Coolstack 1.3.1 includes two different versions of Tomcat (5.0 and 6.0) which install to different locations and have different SMF service names.

The Road to Solaris Coolstack 1.3.1

It would appear that the release of Coolstack 1.3.1 was a little more adventurous than previous versions, as the following timeline illustrates.

10 June 2008

Firstly, we had the launch of Coolstack 1.3 Release Candidate 1 which seemed to work fine on my 10u3 systems but was still technically only a candidate release.

11 July 2008

Then, around 4 weeks later, the official version of Coolstack 1.3 was released. This included a number of minor software revision enhancements but more importantly, included the addition of DTrace probes in applications such as MySQL, Ruby and Memcached. However, the addition of these probes required either the use of Solaris 10 U5 or the installation of a number of Solaris kernel patches, neither of which went down too well in the Coolstack community. As a result, this version 1.3 was withdrawn and 1.3RC1 became the official 1.3 release.

14 August 2008

In an effort to support Solaris versions prior to U5, the DTrace probes were backed out of the affected applications and Coolstack 1.3.1 was born. A number of other minor software enhancements were also added but in essence, 1.3.1 was all about satisfying the wider Coolstack community.

I did eventually get the opportunity to try out Coolstack 1.3.1 and did not encounter any major issues. We are planning a more comprehensive review of the reported MySQL performance gains though.

Apache Log File Rotation on Solaris

Here are some quick commands to configure daily rotation of the two main Apache logging files, on a Solaris system that uses a nightly cron task to execute the logadm utility (this is enabled by default on a clean installation of Solaris).

Purge any existing entries

To make nice clean start, you may wish to remove any existing log rotation entries.

# logadm -r /log/apache/access_log
# logadm -r /log/apache/error_log

Commit new log rotation settings

Our requirements were that the log files in question be rotated each day, no matter what size they are, and that the resultant file be compressed and named after the current date.

logadm -c -p 1d -t '$file-%Y-%m-%d' -z 0 -w /log/apache/access_log
logadm -c -p 1d -t '$file-%Y-%m-%d' -z 0 -w /log/apache/error_log

The -c indicates that the log files should copied and truncated rather than renamed. The -w parameter ensures that all of the settings specified in the command be written to the central log rotation configuration file in /etc/logadm.conf

Solaris ipfilter broken by Patch 125503-02

We recently installed a number of patches onto a T1000 server running Solaris 10 U3, only to discover that the ipfilter service was broken thereafter. The service itself appeared to be configured correctly with no visible signs of error but we discovered that many ports that we had configured to be blocked from certain sources were not.

After some careful analysis of the patches applied, we discovered that Patch 125503-02 had replaced a number of the files associated with the SUNWipfilter package, resulting in the main network interface for our system no longer being plumbed for use with the pfil driver.

Here is how we recovered from this situation:

1. Back out the patch and reboot

# smpatch remove –i 125503-02
# reboot

2. Replumb the appropriate network interface

# ifconfig bge0 modinsert pfil@2
# autopush -f /etc/ipf/pfil.ap
# ifconfig bge0 unplumb
# ifconfig bge0 plumb

Note: Replace bge0 with e1000g0 for a T2000 and ensure your pfil.ap has the correct entry in it.

Thanks to derkeiler.com for assistance.

Solaris CoolStack 1.3 released

CoolStack is a collection of some of the most commonly used open source applications optimized for the Sun Solaris platform. The latest version of this software suite, Cool Stack 1.3, has just been released. Here is a brief overview:

Notable Additions

  • Python 2.5.2
  • Nginx 0.6.31
  • New Apache modules including mod_python, mod_ruby, mod_dtrace etc.

Updated Versions

  • Apache 2.28
  • Tomcat 5.5.26
  • MySQL 5.1.24
  • PHP 5.2.6
  • Memcached 1.2.5
  • Ruby 1.8.6p114 with Ruby Gems 1.1.1 and Rails 2.0.2

Other Enhancements

  • Ruby performance improvements in the order of 20-30% (with a further 8-15% coming down the line when Ruby 1.8.7 is released)
  • Better support for installing Ruby Gems that require native compilation on SPARC systems

The addition of Nginx an Python support along with the performance improvements in Ruby as well as the additional Apache modules are all very useful additions and have yet again come at just the right time for our organisation. Well done to Shanti and his team for providing almost exactly everything we were hoping for in this release, again!