My last two posts, Starting NRPE via launchd and Nagios NRPE on OS X Server 10.5, concerned getting NRPE to run on OS X Server 10.5 and having it startup at system boot.
However, this is only part of the battle. Once you have Nagios monitoring setup on your server you also need to have some nice options for checking the availability of your running services.
Tim Wilson from the Savvy Technologist, wrote an NRPE plugin that helps out with this. The plugin check_osx_services does an excellent job of checking on the status for many services running on 10.5 Server.
The documentation on the plugin at the NagiosExchange site is pretty thorough. One thing that is not mentioned is that you will need to run the check_osx_services script as superuser since it calls the system level command serveradmin which must be run as root.
Last week I posted on how to setup NRPE on Mac OS X Server. Here is what you need to do to make it start up at system boot.
On a Linux or Solaris machine you can just include the call to the daemon in an init script like rc.local and it will be started when the OS boots. Unfortunately, Apple has made this a little more difficult on Mac OS X with Tiger and Leopard. The standard startup processes (cron, inetd, xinetd, etc.) have been rolled into a single process known as launchd.
Read more
Recently I was tasked to install the Nagios add-on NRPE on two OS X 10.5 servers.
I read a little on the ‘net about it, but no one actually had much in the way of a walkthrough, so I thought I would fill the void.
The basic steps involve compiling the NRPE source, but doing so involves altering some of the code.
Read more
At work we run the WebCT Vista course management system by Blackboard.
Recently I was requested to figure out how to import the security certificate from the command line so that we could add this to the login script used for our campus computers. The main reason behind this was to eliminate the need for the user to have to manually agree to the security certificate when browsing to the CMS.
Normally when you want to create a Java keystore, you would use the keytool program located in $JAVA_HOME/bin. If you run this program to import a certificate without specifying a location for the keystore it tries to create one named .keystore in the user profile home directory.
However, when the JRE actually imports a certificate it doesn’t put it in this file. After some investigation, it turns out that the JRE imports certificates into a file named trusted.certs which is located in the following directory
C:\Documents and Settings\USERNAME\Application Data\Sun\Java\Deployment\security\
In order to import a certificate into a keystore you need to vital pieces of information:
- the keystore name
- the keystore password
The problem here is that this keystore is being automatically created by the JRE. It turns out that this keystore has a password that is an empty string. What this means is that when you import a certificate you have to specify the password by using the storepass parameter with a value “”.
For example if the certificate that you want to import has a name and path of
c:\Blackboard.cer
the command to import the certificate for the user jdoe would be
keytool.exe -import -noprompt -keystore C:\Documents and Settings\jdoe\Application Data\Sun\Java\Deployment\security\trusted.certs -storepass "" -file c:\Blackboard.cer
Update 2008-04-09:
I have also found how to do this on Mac OS X. According to the developer documents, the JVM on Mac OS X uses the user’s default keychain to store this type of certificate instead of using a file-based keystore like the other OS.
In order to store the certificate in the user’s login keychain you can import it via the command line tool certtool that is installed on the OS.
The command to import this certificate from the command line is
certtool i path/to/cert/file k=~/Library/Keychains/login.keychain
If you want to have this happen at login for each user who might login, then you could implement this via a login hook. For more on this, take a gander at the article 301446 in the Apple knowledgebase.
At work I am in charge of running our Macromedia Adobe Contribute Publishing Server.
Since I like to duplicate my work environment on my laptop for local development, I needed to install JBoss 4.0.5.GA. I won’t go into why we are running such an old version, that’s all Adobe’s fault.
Installing JBoss
- Download the JEMS installer for 4.0.5.GA from the JEMS Installer Downloads page at jboss.org.
- Execute the installer:
java -jar jems-installer-1.2.0.GA.jar - If you get asked to allow java to talk through the firewall, choose Allow.
- The default installation location is: /Applications/jboss-4.0.5.GA
It will create the directory if it doesn’t exist already.
- During the install process choose the Advanced install method. This allows you to pick your database environment, as well as making the process of securing the JMX Console and JBoss Web Console much easier.
Starting JBoss
- Open a terminal
- Goto the install location binary directory (I used the default)
/Applications/jboss-4.0.5.GA/bin/ - execute run.sh
./run.sh -b 127.0.0.1 & - You will see the output of the startup process show up in the terminal window.
Stopping JBoss
- Open a terminal
- Goto the install location binary directory
cd /Applications/jboss-4.0.5.GA/bin - Run the shutdown script (don’t forget to authenticate!)
./shutdown.sh –server=localhost:1099 –shutdown -u admin -p password
Notes
- The default port for the HTTP connector is 8080
- The SSL connector is disabled by default
Next Page »