ISVE OpenSource Engineers

Downloading OpenSolaris Nagios Packages


The Nagios packages are in the OpenSolaris contrib repository.


You can install these packages either using the pkg command or via
the package manager, you can go to the /contrib
repository's catalog
page
and click on the 'install' link for the package(s) that you
want to install.


To set up /contrib as a valid publisher for use with the package
manager or the pkg command, do the following as a user with the root
role (or Software Installation profile):


pfexec pkg set-publisher -O http://pkg.opensolaris.org/contrib
contrib


Or you can add /contrib via the package manager through the File
-> Manage Repositories pull down. If installing from the "install"
link at http://pkg.opensolaris.org/contrib/en/catalog.shtml 
the package manager will automatically add /contrib to the list of
publishers.


To install packages using pkg, do the following:


pfexec pkg refresh
pfexec pkg install <package name
>


Each monitored OpenSolaris system must have the nrpe and
nagios-plugins packages installed.


The monitoring host must have the nagios package installed.



Other Nagios Installation Details


Make sure that each monitored host has the SUNWcryr and SUNWcryx
packages installed to allow for full encryption. Without those packages nrpe cannot negotiate a working key length properly (it defaults to 256 bit keys which it cannot generate without the extra packages). http://www.sun.com/download/index.jsp?cat=Security&tab=3&subcat=Cryptography%20%26%20Encryption




Editing the nrpe Configuration File


Each monitored host must have the /usr/nagios/etc/nrpe.cfg
file customized based on the local configuration.


There are 3 sets of parameters to be considered:


1. # ALLOWED HOST ADDRESSES


# allowed_hosts is an optional comma-delimited list of IP
address or hostnames that are allowed to communicate with the nrpe
daemon. The default value for this parameter is:


allowed_hosts=127.0.0.1


This default value allows the nrpe daemon to respond only to the
local host. Other systems attempting to communicate with nrpe will be
ignored.


2. Two other variables identify the effective user and
effective group that nrpe will run as.


nrpe_user=nagios


nrpe_group=nagios


These values must correspond to a user and group defined on the
local machine. The nrpe package install does NOT automatically create
user and group nagios, so the system administrator must either create
them or must set these parameters to a user and a group which do
exist. Use these commands to create group and user nagios:


groupadd nagios


useradd -d /export/home/nagios -g nagios -m nagios


3. COMMAND DEFINITIONS


Command definitions define the commands that the nrpe daemon will
run on this host. Definitions are in the following format:


command[<command_name>]=<command_line>


When the daemon receives a request to return the results of
<command_name> it will execute the command specified by the
<command_line> argument.


The command line cannot contain macros - it must be typed exactly
as it should be executed.


Note: Any plugins used in the command lines must reside on the
machine that this daemon is running on. The examples below assume
that you have plugins installed in the /usr/nagios/libexec directory.



command[check_users]=/usr/nagios/libexec/check_users -w 5 -c 10
command[check_load]=/usr/nagios/libexec/check_load -w 15,10,5 -c
30,25,20
command[check_hda1]=/usr/nagios/libexec/check_disk -w 20% -c 10%
-p /dev/hda1
command[check_zombie_procs]=/usr/nagios/libexec/check_procs -w 5
-c 10 -s Z
command[check_total_procs]=/usr/nagios/libexec/check_procs -w 150
-c 200
command[check_total_procs]=/usr/nagios/libexec/check_solaris_procs
150 200
command[check_swap]=/usr/nagios/libexec/check_solaris_swap 100000
50000

Issue the following command on each monitored host to start nrpe
running as a daemon:

/usr/nagios/bin/nrpe -c /usr/nagios/etc/nrpe.cfg -d


To start up nrpe in a non-global Solaris 10 zone, either
configure and build
with


LDFLAGS="-R/usr/sfw/lib",
or add /usr/sfw/lib to the runtime linker search path. See crle(1).


Editing the Nagios Configuration Files


The host on which Nagios (the monitor) is installed must have the
following files customized based on the local configuration:


/usr/nagios/etc/objects/commands.cfg


/usr/nagios/etc/objects/localhost.cfg


Two Solaris specific scripts have been written and are distributed
as part of the OpenSolaris nagios plugins package. These scripts
enable monitoring of the number of processes and amount of swap space
on the (Open)Solaris system. The scripts are named
check_solaris_procs and check_solaris_swap. Due to differences in
command implementation, the Linux scripts to check processes and swap
space do not run on Solaris.


To monitor the number of processes on a Solaris system, replace
these lines in the commands.cfg file:


command_name check_local_procs
command_line $USER1$/check_procs -w $ARG1$ -c $ARG2$ -s
$ARG3$


with:


command_name check_local_procs
command_line $USER1$/check_solaris_procs 250 400





Similarly, the lines to define the command to check swap space are
changed to:


command_name check_local_swap
command_line $USER1$/check_solaris_swap


Verify that your changes to these files are syntactically correct
by running this command:


/usr/nagios/bin/nagios -v /usr/nagios/etc/nagios.cfg


( Output should end with " Things look okay ..." )



Starting the Nagios Monitor


Once the commands.cfg and localhost.cfg file are modified to
specify the hosts and commands to be monitored, you start the Nagios
monitor with:


/usr/nagios/bin/nagios /usr/nagios/etc/nagios.cfg -d &


For more information, check:


http://nagios.sourceforge.net/docs/3_0/quickstart.html


Observing the Results


Open source Nagios addons have been written to graphically display
the results of the monitoring and to store the information in
various databases, including MySQL and RRD.


The basic output of the Nagios monitor can be viewed by regularly
checking the output of the status.dat file using this command:


grep plugin_output /usr/nagios/var/status.dat | grep -v long


All lines should contain "OK". The lines you see may
look like this:


plugin_output=PING OK - Packet loss = 0%, RTA = 0.09 ms
plugin_output=OK - load average: 0.00, 0.00, 0.00
plugin_output=USERS OK - 4 users currently logged in
plugin_output=PING OK - Packet loss = 0%, RTA = 0.09 ms
plugin_output=DISK OK - free space: / 47829 MB (91%
inode=99%):
plugin_output=OK - 134 processes


These output lines correspond to status checks on ping, load,
number of users, ping (remote monitored host), free disk space, and
number of processes.


A CGI based web interface may also be installed to provide a
graphic display of the parameter statuses for each monitored host.


This provides you with a basic view of Nagios capabilities. A
number of books have been written on the subject of configuring and
expanding Nagios, and a large and vibrant Nagios user community
exists.


Consult nagios.org as a starting point for expanding your
understanding of this popular network monitoring tool.







Went to London for the LOSUG meetup last night. Had a really fantastic time and met lots of great people. Thanks to James and Joy for organising my session and for inviting me along to talk. Met up with Ralph Turner from OpenAnswers who I've not seen for an age, Ralph used to do work for us when I was in Developer Tech Support and we see each other now and again, but not often enough. My former boss Dani Flexer was there and he seems to be doing really well for himself, he was a speaker at a previous LOSUG meeting in September. I have to read his white paper when I get the chance. I also met Robert Milkowski who is a regular contributor to SourceJuicer (he recently contributed Alpine). We had never met before so it was great to put a face to the name. I don't remember the names of everyone that I met last night but it was really, really good to get the chance to meet you all.

Owen Roberts' gave a great talk on creating an OpenSolaris build server from IPS images, it gave me a sense of DejaVu as so much of it was the same as what I'm doing with updating Lighttpd and Ruby for WebStack in OpenSolaris.

The slides for my talk are here, but they are fairly minimalist (which works so much better for me as a presenter). I'll also record the demo that I gave and post that on slx.sun.com.  I enjoyed giving the presentation immensely and I hope that everyone got as much from it as I did. I really, really look forward to going back in the the new year and going into the technical details of publishing a package into /contrib.

Also, a shout out to the SourceJuicer team in Dublin and to Jim Walker in California. They had a network outage during my afternoon yesterday that meant that the SourceJuicer site was unavailable and the systems couldn't be accessed at all. Everyone worked together to get it back up and running so that I could run my demo, keeping me informed by phone and by email. Thanks for that guys :o)

LinuxWorld is a congress annually held in the “Jaarbeurs” in Utrecht. It focusses on Linux, OpenSource and Free Software (hi Adriaan!). The visitors are informed about the latest developments in OpenSource, learn what OpenSource solutions could reduce cost in their organizations etc. Besides the technical information shared; these type of conferences are also great to network and meet colleagues in IT.

Co-located with LinuxWorld are the conferences infosecurity.nl, Storage Expo and the Tooling event addressing IT administration and Storage. So, all four big IT events are at one location at the same time! All four events in total draw thousands of people to Utrecht. In 2008 more than 8,000 people visited the four conferences in two days.

Sun got very good feedback on their VDI demo setup running 6 Sun rays and a Demo server with Open Source software stacks. Visitors were really impressed with the freedom of choice for OpenSource workplaces which is offered with VDI. This choice of freedom is really well in line with initiatives like Nederland Open In Verbinding: an initiative of the Dutch Ministry of Economic Affairs.

At StorageExpo the Sun stand was visited quite well. There theme was "Save Time”: fast storage, low prices. The breakout sessions on OpenStorage were packed. Both sessions had more than 60 people attending.

The Dutch OpenSolaris User Group (NLOSUG) was present as well. I gave a short presentation about OpenSolaris. What is it?, what are some of the key features?, the licensing model and how to contribute to OpenSolaris were some of the topics discussed. This talk was attended by about 30 people. Because one cannot tell everything about OpenSolaris in just 20 minutes there was a lot of talk about OpenSolaris afterwards. There was much interest in contributing to OpenSolaris using SourceJuicer, how to make an IPS package, ZFS features etc.

It is really good to see that there is so much interest in the products of Sun Microsystems and it's OpenSource solutions. The interest and popularity is growing bigger and bigger.


I'll be giving a talk on SourceJuicer at the London OpenSolaris User Group meeting on Wednesday 18th November. On before me is Owen Roberts from the Solaris Sustaining group, and he'll be talking about how the core of OpenSolaris will move to being built from source directly to IPS packages (yay!).

So if you are interested,  register in advance here and then come along to the Sun Customer Briefing Centre at:

45 King William Street
London, EC4R 9AN
Map

Doors open at 6PM and the talking starts at 6:30PM, there'll be food and socialising afterward.

While on the subject of SourceJuicer, George Drapeau the OSS core team lead here in ISV-Engineering at Sun has just published a video blog on installing Acquia Drupal on OpenSolaris from the /contrib repository. You can find it on George's Blog, it's very slick :o)

My Alfresco on Glassfish Walkthrough is over a year old now and is creaking at the seams a little so I plan to update it. Feel free to comment here on what the new walkthrough should cover, Glassfish v2.1 or v3? Solaris or OpenSolaris? Linux or Windows? Which DB (just MySQL or some other OSDB)?

In fact feel free to comment on anything you would like to see to do with running Alfresco (or any other (E)CMS app) on Sun gear.

Original blog entry: http://blogs.sun.com/mandy/entry/alfresco_on_glassfish_on_opensolaris

Cheers

Amanda

configure.ac files (configure.in in the old days) are used as input to autoconf which miraculously (it's all miraculous to me) expands the macros in the configure.ac file and creates a runnable configure shell script. Autoconf macros may be system dependent so if you decide to regenerate a configure script, it's the job of autoconf, in conjunction with aclocal, to locate all of the macro definitions that it's going to need to get the job done. These macro definitions may be supplied by the local installation of autoconf, by other packages via aclocal or actually supplied by the package you are building in a file named acinclude.m4

Due to some changes in the way Lighttpd is built I found that for Lighttpd 1.4.23 in WebStack we had to regenerate the configure script, I did this using the autogen.sh script that ships with the lighttpd source code. autogen.sh calls libtool, aclocal, automake, autoconf and autoheader. On Solaris 10 autoconf generated an error:

configure.ac:67: error: possibly undefined macro: AC_DEFINE
      If this token and others are legitimate, please use m4_pattern_allow.
      See the Autoconf documentation.

But AC_DEFINE is a standard autoconf macro so why can't it be found? We dug around and found mention of it being to do with pkg-config but couldn't work out why that would be. So We stripped down the lighttpd configure.ac bit by bit and found that the problem went away when we removed the lines referencing a macro named PKG_CHECK_MODULES. The file aclocal.m4 in the lighttpd build directory contains any additional macros required by autoconf to process configure.ac and is generated by aclocal. The lighttpd source distribution includes the aclocal.m4 file that was used to create the original configure script, but when you run aclocal, a new aclocal is generated from macros that have been registered with aclocal on the local system. On this system, after running aclocal, aclocal.m4 didn't contain a macro named PKG_CHECK_MODULES :o/

Further research showed that PKG_CHECK_MODULES is usually supplied in a file named pkg.m4 which is installed as part of pkg-config. It usually installs to /usr/share/aclocal which is the default location used by aclocal to locate macros. In this case though we were using a tool set specifically created by the WebStack team for building WebStack on Solaris 10. In this tool set (wstools),  aclocal lives in /export/wstools/bin and it looks for macro definitions in /export/wstools/share/aclocal. wstools doesn't include pkg-config so there's no pkg.m4. That explains why it couldn't find the PKG_CHECK_MODULES macro, but why the error about AC_DEFINE?

In configure.ac you'll find:

  if test "x$FAM_LIBS" = x; then
    PKG_CHECK_MODULES(FAM, gamin >= 0.1.0, [
      AC_DEFINE([HAVE_LIBFAM], [1], [libfam])
      AC_DEFINE([HAVE_FAM_H], [1], [fam.h])
    ])
  fi

So you can kind of see why the AC_DEFINEs passed to the PKG_CHECK_MODULES macro could be affected, but autoconf indicated that the error came from a line of code not related to PKG_CHECK_MODULES, i.e.:

AC_CHECK_MEMBER(struct tm.tm_gmtoff,[AC_DEFINE([HAVE_STRUCT_TM_GMTOFF],[1],[gmtoff
in struct tm])],,[#include <time.h>])

Here AC_DEFINE is used with another standard autoconf macro (AC_CHECK_MEMBER) and if you look at the generated configure script you find:

if test "x$ac_cv_member_struct_tm_tm_gmtoff" = x""yes; then

cat >>confdefs.h <<\_ACEOF
#define HAVE_STRUCT_TM_GMTOFF 1
_ACEOF

fi

Which shows that it didn't actually fail where it said it did. Turns out the time it failed to process AC_DEFINE were where it was used with PKG_CHECK_MODULES. The error from autoconf actually referenced the first use of AC_DEFINE and not where it failed. Best of all, rather than emit a warning about PKG_CHECK_MODULES being missing, it just adds this to the configure script:

  if test "x$FAM_LIBS" = x; then
    PKG_CHECK_MODULES(FAM, gamin >= 0.1.0,
      AC_DEFINE([HAVE_LIBFAM], [1], [libfam])
      AC_DEFINE([HAVE_FAM_H], [1], [fam.h])
    )
  fi

Which is the un-expanded macro calls from configure.ac. These aren't valid shell commands, so the generated configure script will fail. In this case the best way to fix the problem is by adding pkg-config to the WebStack build tool set.  I've also heard that this problem can occur on systems with older versions of pkg-config, I guess that they may not define a PKG_CHECK_MODULES with the signature required by the configure.ac script.

On october 29 the dutch Unix users group (NLUUG) organized the fall conference in congress center De Reehorst in Ede, Netherlands. This conference topic was “The Open Web”. It was to celebrate 20 years of the World Wide Web. It not only focussed on threads and challenges of today and tomorrow, but also on opportunities like integration and securing your web server with the Yubikey in combination with digital certificates.

Sun Microsystems was present with the NLOSUG; the dutch OpenSolaris User Group. The stand was manned by Kristian, Matt, Jan and myself. Kristian did an excellent job showing the advantages of Dtrace during web development. Matt showed the Snowman and Darkstar demos using the project Darkstar OpenSource gaming backend.

Many questions we got at the desk were about OpenSolaris and it's features. Much questions about ZFS, backups, DTrace and virtualization; but also much interest in how to setup a Sun Ray deployment properly, VDI and how to develop web applications using NetBeans.

On May 6 2010 the NLUUG will organize the spring conference. The title is “System Administration” and aims to extend and deepen the knowledge of system administrators. Interested in attending this conference or interested in participating? Please see the NLUUG website for more information.

The OpenSolaris /contrib package repository has a whole bunch of packages contributed by members of the OpenSolaris community or just by those who had a particular need for a certain package and who decided to submit it themselves.

You can install any of these packages either using the pkg command or via the package manager, you can even just go to the /contrib repository's catalog page and click on the 'install' link for the package(s) that you want to install.

To set up /contrib as a valid publisher for use with the package manager or the pkg command do the following as a user with the root role (or Software Installation profile):

pfexec pkg set-publisher -O http://pkg.opensolaris.org/contrib  contrib

Or you can add /contrib via the package manager through the File -> Manage Repositories pull down. If installing from the "install" link at http://pkg.opensolaris.org/contrib/en/catalog.shtml  the package manager will automatically add /contrib to the list of publishers.

To install packages using pkg, do the following:

pfexec pkg refresh
pfexec pkg install <package name>

You don't have to run 'pkg refresh' before installing every package, but it is probably best to do it reasonably regularly just to make sure that pkg has an up to date view of the repositories that it knows about.

There is also a /pending repository which is used to stage packages for testing while they are being made ready for promotion to /contrib. I wouldn't recommend arbitrarily using packages from /pending but you may want to provide feedback on a package, or as in the case with the ruby-mysql package, it maybe that the owner has suggested that you get it from /pending due to some issue getting it into /contrib.

To setup /pending as a publisher, you do much the same as you do for /contrib:

pfexec pkg set-publisher -O http://jucr.opensolaris.org/pending  pending

Or use the package manager File -> Manage Repositories menu.

To list the repositories that pkg knows about, run:

% pkg publisher 
PUBLISHER                             TYPE     STATUS   URI
opensolaris.org          (preferred)  origin   online   http://pkg.opensolaris.org/
contrib                               origin   online   http://pkg.opensolaris.org/contrib/
pending                               origin   online   http://jucr.opensolaris.org/pending/
mypkgs                                origin   online   http://localhost:80/
webstack                              origin   online   http://pkg.opensolaris.org/webstack/

If you have both /contrib and /pending added as publishers, when you install packages you'll need to qualify the package name with the name of the publisher from which you want to install it as follows:

pfexec pkg install pkg://pending/ruby-mysql

Which will install the 'ruby-mysql' package from the publisher name pending. Note that this is the publisher name, not the URI of the repository.

In the list of repositories above are a couple of other repositories that we've not talked about. The /webstack repository has packages that the WebStack team feel might be useful, but for which they are unable to offer support. This has packages for Web Tier applications such as Varnish and Nginx. We also sometime publish packages that are in the process of being integrated into OpenSolaris but are not yet available in the main repositories. The mypkgs repository is a repository local to our test system. It is very easy to set up a build environment for building your own packages from Spec files and then to publish them to a local repository. If you're going to do that though, you might as well publish them to /contrib via SourceJuicer.

Here's some other links that you might find useful:

Spec Files Extra is a project centered around the pkgbuild tool that builds Solaris SVR4 and/or IPS packages from spec files (and which is used by SourceJuicer)

The Genunix site has a page describing how to setup a SourceJuicer like environment

If you'd rather not get involved in submitting spec files to SourceJuicer but would like to see a package in OpenSolaris, drop us an email at sw-porters-discuss@opensolaris.org.

One of the big pain points when installing Native Ruby Gems is the need to have various build packages installed. Packages that deliver the likes of gcc, gmake and ginstall. You also need to know where the libraries and C header files that you want to build against are located. On OpenSolaris the last part should be a no-brainer at least with packages installed from the repository, but some packages such as MySQL don't install to /usr/lib and /usr/include and the mysql_config that the MySQL package ships is not on the default $PATH and even if it was, it emits Compiler and Linker information for Sun Studio, not for gcc.

What this means is that you have to install all of the tools above and then install the MySQL gem with options telling the build where to find the MySQL libs and the MySQL headers.

Making the MySQL gem available as an OpenSolaris package, means you don't have to worry about any of that. You just run:

pfexec pkg install ruby-mysql

and voila!, you have MySQL support in Ruby... But it doesn't work :o(

The ruby-mysql package was promoted to the /contrib repository this week. Unfortunately it was promoted before I had tested it fully (which shows we have some major holes in the processes used to get packages into /contrib). The version that's there currently is unusable as it causes a segmentation violation when running with Rails. If you want to use this package today then you can get it from the /pending repository. Details of how to make use of OpenSolaris repositories can be found on a separate blog entry here.


SilverStripe is a open source content management system(CMS) to create and
maintain website, it is currently published to the OpenSolaris /contib repository.


Installation of SilverStripe on OpenSolaris is straightforward by simply clicking
the installation button on the silverstrip's 'install.php' page,
however, the installation didn't work complaining with mysql query
execution failed:

"[User Error]  Couldn't run query: SELECT `SiteTree_Live`.*,
`GhostPage_Live`.*, `ErrorPage_Live`.*, `RedirectorPage_Live`.*,
`VirtualPage_Live`.*, `SiteTree_Live`.ID,
if(`SiteTree_Live`.ClassName,`SiteTree_Live`.ClassName,'SiteTree') AS
RecordClassName FROM `SiteTree_Live` LEFT JOIN `GhostPage_Live` ON
`GhostPage_Live`.ID = `SiteTree_Live`.ID LEFT JOIN `ErrorPage_Live`
ON `ErrorPage_Live`.ID = `SiteTree_Live`.ID LEFT JOIN
`RedirectorPage_Live` ON `RedirectorPage_Live`.ID =
`SiteTree_Live`.ID LEFT JOIN `VirtualPage_Live` ON
`VirtualPage_Live`.ID = `SiteTree_Live`.ID WHERE
(`SiteTree_Live`.`ParentID` = 1 AND `SiteTree_Live`.ID != 1 AND
ShowInMenus = 1) ORDER BY Sort Lost connection to MySQL server during
query


Running the same query within the MySQL client get the error of MySQL server
crash:


ERROR 2013 (HY000): Lost connection to MySQL server during query


It was caused by MySQL's bug: #44538 , the same problem as Joomlar! with MySQL explained
clearly in Georg's blog. To solve this problem, I enabled the 64-bit MySQL service
on OpenSolaris:


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


The SilverStripe installation succeed without the problem after using the
64-bit MySQL 5.1.

Several interesting packages were published to the OpenSolaris /contrib repository yesterday. They include Octave, SilverStripe and the 3 packages that make up Nagios. 

Nagios is a leading Open Source infrastructure monitoring tool that can monitor networks, hosts and even services, in fact it can monitor pretty much anything and it being Open Source it's fairly straightforward to add your own plugins. The main Nagios package is simply named nagios and delivers version 3.0.6 currently. In addition there is the nagios-plugins package which you'll install on systems that you want to monitor. A third package is nrpe (Nagios Remote Plugin Executor), which allows a centralised deployment of Nagios to execute and monitor plugins on other systems.

Octave is a GNU project, it's a high level language and runtime whose main use is for numerical computations. It's mainly command line driven, but can hook up with the likes of gnuplot in order to present graphs and other visual forms of mathematical data. I've tested it and it looks like it could be really useful for someone say, studying for a maths degree... like me for instance :o)

SilverStripe is a popular Open Source Content Management System, it's one of a number of such applications that OpenSolaris users have been clamouring for. Interestingly we did have some problems getting it to play nicely with MySQL 5.1 on OpenSolaris. When you are setting up the MySQL database prior to configuring SilverStripe modify the MySQL SMF service as follows:

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

You'll either need to do this as root or as a user with the root role. These changes cause MySQL 5.1 to run in 64-bit mode.

You can install any of these packages either using the pkg command or via the package manager, you can even just go to the /contrib repository's catalog page and click on the 'install' link for the package(s) that you want to install.

To set up /contrib as a valid publisher for use with the package manager or the pkg command do the following as a user with the root role (or Software Installation profile):

pfexec pkg set-publisher -O http://pkg.opensolaris.org/contrib  contrib

Or you can add /contrib via the package manager through the File -> Manage Repositories pull down. If installing from the "install" link at http://pkg.opensolaris.org/contrib/en/catalog.shtml  the package manager will automatically add /contrib to the list of publishers.

To install packages using pkg, do the following:

pfexec pkg refresh
pfexec pkg install <package name>

These packages are great additions to the growing list of packages available via the /contrib repository. If you would like to contribute a package to /contrib visit the SourceJuicer page on OpenSolaris.org. If you'd rather not get involved in submitting spec files to SourceJuicer but would like to see a package in OpenSolaris, drop us an email at sw-porters-discuss@opensolaris.org.

Alta Elsta & I just completed the DTrace Quick Start Guide: Observing Native and Web Applications in Production mini-book. If you need a hardcopy let me know but if you are like me and would love to save a few trees you can click on the picture below to download the pdf version.

We talk about why DTrace is so different from any observation tools you may have seen. We cover basic DTrace concepts and some details on writing d-scripts. We also have a lot of sample scripts. Sections on using DTrace to observe MySQL and Drupal are included.

The examples from the book have also been added to a wiki page for easier copy & paste.

(click the image to open PDF)

Last week Mark Niedzielski from OurStage and I did a webcast about ZFS. We cover some very basics of ZFS. There is good info on its storage management capabilities and filesystem and volume capabilities. We even look at hybrid storage, benefits of snapshots and some tuning hints as well.

If you missed the webcast here is a link to get to the recording & Slide deck.

Slides - CLICK HERE
Recording - CLICK HERE

Link to Other webinars - CLICK HERE

Please let me know if you need more details on ZFS or on these webinars

At Bay Area DrupalCamp today, Sun is handing out USB Flash sticks that boot any USB-bootable X86/X64 box into OpenSolaris with a running Drupal 6 instance. For those of you not at BADCamp this weekend, we've also made the USB image available for download here. It's a little less than 1GB, and fits on 1GB flash drives.

To burn the image to your own USB flash drive:

  • From a Windows box: see here
  • From an OpenSolaris box: install and use /usr/bin/usbcopy from SUNWdistro-const package

For those who'd rather try this from a "Live DVD", the .iso image is here.

Update 19 October: thanks to alert readers who spotted my ill-formed DVD link above. It's fixed now.druplicon

I can convince myself of anything. When we updated from RubyGems 0.9.4 to 1.3.5 I decided that it was ok for the 'rake' command to be in the $GEM_HOME/bin which then translated to /var/ruby/1.8/gem_home/bin. I justified it because users could run 'gem env', look at the "EXECUTABLE DIRECTORY" and see that they had to add /var/ruby/1.8/gem_home/bin to their $PATH env var. Having had to install and then run rake several times on different systems over the last few days I can see that this is wrong. I want to 'gem install rake' and then run 'rake <some rake task>' without the need to update my PATH. I'm certain that others will agree that this is how it should be.

I could easily change the way that we build RubyGems such that the "EXECUTABLE DIRECTORY" defaults to /usr/bin but I have no way of being certain that when the end user runs 'gem install <some gem with an executable>' that /usr/bin will actually be writable even by root (or the root role as used by pfexec). We have the Rails package in the /contrib repository that also delivers the Rake gem. This package installs the 'rake' executable to /usr/bin, but it's a bit much to ask you to install Rails just to get Rake. I seem to have the following options:

  1. With the SUNWruby18 package on OpenSolaris, provide wrapper scripts in /usr/bin for the popular gems that deliver executables. These would emit a message saying to install the require Gem should it not already be installed and run as normal if it is. This has a few corner cases that have to be considered
  2. Provide a /contrib package that provides wrapper scripts for popular gems which would work as described in (1)
  3. Change "EXECUTABLE DIRECTORY" to /usr/bin and modify RubyGems to detect the writability of /usr/bin. It does this by default but would end up installing any affected gems in root's ~/.gem directory.

I favour option 3, but only if it can be done without significant changes to RubyGems.