Tuesday, November 20, 2007

OpenSolaris Nevada Build 76 and Xming/XDMCP

I upgraded my box from build 59 in order to check out the new Xen support.

With the new "secure by default" implementations, I had to re-enable XDMCP by clearing the cde-login arguments, like this:

# svccfg -s cde-login setprop dtlogin/args = \"\"
# svcadm refresh cde-login
# svcadm restart cde-login


This allows XDMCP requests to come in (the default args set the udp port to 0).

However, Xming would get a login cursor and blackscreen, then would die.

Turns out, whatever has changed in dtlogin needs some fonts I dont have, so I had to start up a font server:

# svcadm enable xfs

With this in place, I can once again X into my OpenSolaris box from my Vista desktop!

Oh and another nice thing I did was to enable screensave/poweroff for the console X server by adding a line to /usr/dt/config/Xsetup (around line 81):

$XDIR/xset dpms 60 120 180

My OpenSolaris box is connected to my second LCD panel on the EVGA connection, and my Vista box uses the DVI connectors. When the Vista box tried to power off the second LCD, the OpenSolaris box would be sitting there, a bit annoying, so the dpms change to the X server did the trick. The second panel now powers off correctly.

Wednesday, April 25, 2007

An SMF package for Maven Continuum

The Continuum continuous build system is excellent for Maven projects (and ant, etc), but it doesn't ship with a good way to start/stop it. It only comes with a start script, and a wrapper for sparc solaris that'll start/stop, which naturally won't work.

So, why not an SMF package?

Download:
GTcontinuum-smf.pkg.gz

Manual Installation:

Decompress:
# gunzip GTcontinuum-smf.pkg.gz
Add the Package:
# pkgadd -d GTcontinuum-smf.pkg

You will be prompted for the install location of continuum, the user and group to run as, and where the Java JDK is located.

Verify SMF sees it:
# svcs continuum
Startup Continuum:
# svcadm enable continuum
Check logs:
# tail -f /var/svc/log/network-continuum\:default.log

Automated Install

Create a response file like this gtcontinuum.cf:

CONTINUUM_HOME=/usr/local/continuum
CONTINUUM_USER=mvnbuild
CONTINUUM_GROUP=other
JAVA_HOME=/usr/java

Run pkgadd using response file:
# echo y | pkgadd -r gtcontinuum.cf -d GTcontinuum-smf.pkg GTcontinuum-smf

I'll post a "how to setup continuum" as well soon, since you'll probably want to change the port that it starts up on.

Cheers

Brian

Compiling Nagios 3.0a3 (and plugins) for OpenSolaris 64bit

Wrestling with the "native" cc in OpenSolaris is not my favorite thing to do, and I really wish the whole project would drop "cc" in favor of gcc.

Nagios is a good example of a "common" application that "just compiles" on Linux, and has to be thoughtfully compiled on OpenSolaris.

By default, Nagios will choose gcc as the compiler, but it links in 32bit libraries (specifically libopenssl.so and libcrypto.so). The native compiler chokes on the plugins (mostly the check_dhcp plugin, but also check_mysql, etc).

But enough of that, here's how to compile Nagios for OpenSolaris in 64bit mode.

Step 1: Download Source
Get GD from here
Get Nagios from here
Get Nagios Plugins from here

Step 2: Create nagios user and group
#groupadd nagios
#useradd -g nagios nagios

Step 3: Build GD
Note: having to dynamically link this in is the default, and preferably there would be a method to just statically link in this library, but for this doc, we'll install GD somewhere common and pass in the search path.

Extract the source:
#gtar xfz gd-2.0.34.tar.gz

Setup Environment:
#export CFLAGS=-m64
#export PATH=$PATH:/usr/ccs/bin

Configure:
#./configure --prefix=/usr/local/gd-2.0.34

Compile:
#make

Install:
#make install

Step 4: Build Nagios

Extract the source:
#gtar xfz nagios-3.0a3.tar.gz

Setup Environment:
#export CFLAGS=-m64
#export LDFLAGS="-L/usr/local/src/gd-2.0.34/lib -R/usr/local/src/gd-2.0.34/lib"

Configure:
#./configure --prefix=/usr/local/nagios-3.0a3 --with-gd-lib=/usr/local/gd-2.0.34/lib \
--with-gd-inc=/usr/local/gd-2.0.34/include \
--with-init-dir=/usr/local/nagios-3.0a3/init.d

Compile:
#make all

Install:
#make install
#make install-init
#make install-commandmode
#make install-config

Step 5: Build Nagios Plugins
Extract the plugins:
#gtar xfz nagios-plugins-1.4.8.tar.gz

Setup Environment:
#export PATH=$PATH:/usr/ccs/bin
#export CFLAGS=-m64
#export LDFLAGS="-Xlinker -64 -L/usr/sfw/lib/amd64 -R/usr/sfw/lib/amd64"

Configure:
#./configure --prefix=/usr/local/nagios-3.0a3

Compile:
#make

Install:
#make install

Step 6: Setup Nagios Configuration
# cd /usr/local/nagios-3.0a3/etc
# cp -p cgi.cfg-sample cgi.cfg
# cp -p commands.cfg-sample commands.cfg
# cp -p localhost.cfg-sample localhost.cfg
# cp -p nagios.cfg-sample nagios.cfg
# cp -p resource.cfg-sample resource.cfg

Step 7: Install SMF package for Nagios
See this post for the SMF package

Cheers

Brian

Friday, April 13, 2007

OpenSolaris - an SMF Package for Nagios

(Updated to be zone-friendly)

While playing around with Nagios, I figured it was time to learn how SMF
works a bit more, and brush on Solaris packaging while I was at it.

I've created an SMF package for Nagios, which I hope others find useful.

The first pass at this allows you to specify the location where nagios is install (detecting /usr/local/nagios is the default action).

In addition, you can specify the username and group that nagios is launched by.

Download:

Without further ado: GTnagios-smf-1.1.pkg.gz

Version 1.1 will create the startup files in /opt/GTnagios-smf, which can be installed in a zone by itself, or made globally available (pkgadd -G).

The first version (if you dont require zones) can be used GTnagios-smf-1.0.pkg.gz Zones are useful, so I'm updating the SMF packages I've written to adhere to their rules.

Manual Installation
Decompress:
# gunzip GTnagios-smf-1.1.pkg.gz
Add the Package:
# pkgadd -d GTnagios-smf-1.1.pkg
Verify SMF sees it:
# svcs nagios
Startup nagios:
# svcadm enable nagios
Check logs:
# tail -f /var/svc/log/network-nagios\:default.log

Automated Install

Automated installs are common, here's how to automate pkgadd.

Create a response file like this gtresponse.cf:
NAGIOS_HOME=/usr/local/nagios
NAGIOS_USER=nagios
NAGIOS_GROUP=nagios
Run pkgadd using response file:
# echo y | pkgadd -r gtresponse.cf -d GTnagios-smf-1.1.pkg GTnagios-smf

I'll publish the "how to make an smf package installer" soon as well.

Cheers

Brian

Saturday, March 31, 2007

Building Subversion for OpenSolaris 11

Subversion isn't available from the OpenSolaris install (snv_59), and with the availability of gcc and Sun's cc compilers, building subversion can be rather involved (and there are some gotchas).

Subversion uses APR and APR-UTIL from apache.org. Optionally it can use Berkeley DB and neon for webdav. I chose to enable BDB and NEON.

APR/APR-UTIL are supplied with OpenSolaris, but apr-util is not compiled with Berkely DB, plus apache2 is compile with Sun's cc vs gcc.

OpenSSL is supplied with OpenSolaris, but it's a little old, and linking is a pain, with all the other stuff inside /usr/sfw/lib, so just compile the latest. I tried for hours to get this to link clean, and gave up and built my own openssl libs.

Subversion is available from www.sunfreeware.com, but this should be a more "complete" build, and completely reproducible.

Step 1: Download source
Apache apr and apr-util from http://apr.apache.org/download.cgi
I grabbed apr-1.2.8.tar.gz and apr-util-1.2.8.tar.gz

Berkeley DB from http://www.sleepycat.com/download/index.shtml
I grabbed http://www.oracle.com/technology/software/products/berkeley-db/htdocs/popup/db/4.5.20/db-targz.html (Berkeley DB 4.5.20 with AES encryption)

Neon from: http://www.webdav.org/neon
I grabbed http://www.webdav.org/neon/neon-0.25.5.tar.gz since Subversion wanted that version (looks like it can be overridden as well).

Get the lastest OpenSSL from from http://www.openssl.org/source/
I grabbed openssl-0.9.8e.tar.gz

Subversion from http://subversion.tigris.org/
I grabbed http://subversion.tigris.org/downloads/subversion-1.4.3.tar.gz

Step 2: Setup build environment
Everything that I build goes into /depot, and source goes into /depot-src. I drop the tar files into /depot-src/tarballs.

Additionally, I'm building everything as root in a bash shell.

# convenience vars
export MYSOURCEDIR=/depot-src
export MYOUTPUTDIR=/depot

# extract files
/usr/sfw/bin/gtar xfz $MYSOURCEDIR/tarballs/openssl-0.9.8e.tar.gz
/usr/sfw/bin/gtar xfz $MYSOURCEDIR/tarballs/neon-0.25.5.tar.gz
/usr/sfw/bin/gtar xfz $MYSOURCEDIR/tarballs/db-4.5.20.tar.gz
/usr/sfw/bin/gtar xfz $MYSOURCEDIR/tarballs/apr-util-1.2.8.tar.gz
/usr/sfw/bin/gtar xfz $MYSOURCEDIR/tarballs/apr-1.2.8.tar.gz
/usr/sfw/bin/gtar xfz $MYSOURCEDIR/tarballs/subversion-1.4.3.tar.gz

# Use cc
export PATH=/usr/ccs/bin:$PATH
export CC=cc
export CXX=CC
# 64bit support required
export CFLAGS="-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64"
# needed for apr-util to link berkeley db
export LDFLAGS="-L/$MYOUTPUTDIR/db-4.5.20/lib -R/MYOUTPUTDIR/db-4.5.20/lib"

Step 3: Build Berkeley DB

cd $MYSOURCEDIR/db-4.5.20/build_unix
../dist/configure --prefix=/$MYOUTPUTDIR/db-4.5.20
make
make install

Step 4: Build APR
cd $MYSOURCEDIR/apr-1.2.8
./configure --prefix=/$MYOUTPUTDIR/apr-1.2.8
make
make install

Step 5: Build APR-UTIL
cd $MYSOURCEDIR/apr-util-1.2.8
./configure --prefix=/$MYOUTPUTDIR/apr-util-1.2.8 \
--with-apr=/$MYOUTPUTDIR/apr-1.2.8 \
--with-berkeley-db=/$MYOUTPUTDIR/db-4.5.20
make
make install

Step 6: Build OpenSSL
cd $MYSOURCEDIR/openssl-0.9.8e
./Configure --prefix=/$MYOUTPUTDIR/openssl-0.9.8e solaris-x86-cc
make
make install

Step 7: Build Neon
cd $MYSOURCEDIR/neon-0.25.5
./configure --prefix=/$MYOUTPUTDIR/neon-0.25.5 \
--with-ssl=openssl --with-libs=/$MYOUTPUTDIR/openssl-0.9.8e
make
make install

Step 8: Build Subversion!
cd $MYSOURCEDIR/subversion-1.4.3
./configure --prefix=/$MYOUTPUTDIR/subversion-1.4.3 \
--with-apxs=/usr/apache2/bin/apxs \
--with-apr=/$MYOUTPUTDIR/apr-1.2.8 \
--with-apr-util=/$MYOUTPUTDIR/apr-util-1.2.8 \
--enable-experimental-libtool \
--with-neon=/$MYOUTPUTDIR/neon-0.25.5 \
--disable-nls --enable-ssl \
--with-libs=/$MYOUTPUTDIR/openssl-0.9.8e
make

Have subversion run its tests, if any fail something has gone wrong.
In my build switch_tests.py reported FAILURE /shrug

make check
make install

That's it, subversion is built and running for OpenSolaris x86.