Rico's Blog

Continuous Integration, Delivery, OSX, OpenJDK, Tomcat and much more.

Mountain Lion and Apxs

Mountain Lion came with a version of apxs where C compiler and pre-processor are defined to a location not in phase with XCode 4.5.

If you try to build any apxs related modules or Tomcat Native Library, it will fail like this :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

checking build system type... x86_64-apple-darwin12.2.0
checking host system type... x86_64-apple-darwin12.2.0
checking target system type... x86_64-apple-darwin12.2.0
checking for a BSD-compatible install... /usr/bin/install -c
checking for working mkdir -p... yes
Tomcat Native Version: 1.1.24
checking for chosen layout... tcnative
checking for APR... yes
  setting CC to "/Applications/Xcode.app/Contents/Developer/Toolchains/OSX10.8.xctoolchain/usr/bin/cc"
  setting CPP to "/Applications/Xcode.app/Contents/Developer/Toolchains/OSX10.8.xctoolchain/usr/bin/cc -E"
checking for JDK location (please wait)... /System/Library/Frameworks/JavaVM.framework/Versions/A/
checking Java platform... checking Java platform...
checking for sablevm... NONE
  adding "-I/System/Library/Frameworks/JavaVM.framework/Versions/A//Headers" to TCNATIVE_PRIV_INCLUDES
checking os_type directory... jni_md.h found in /System/Library/Frameworks/JavaVM.framework/Versions/A//Headers
checking for gcc... /Applications/Xcode.app/Contents/Developer/Toolchains/OSX10.8.xctoolchain/usr/bin/cc
checking whether the C compiler works... no
configure: error: in `/Users/henri/tomcat-native-1.1.24-src/jni/native':
configure: error: C compiler cannot create executables
See `config.log' for more details

apxs get its configurations from /usr/share/httpd/build/config_vars.mk who reference /Applications/Xcode.app/Contents/Developer/Toolchains/OSX10.8.xctoolchain.

1
2

CC = /Applications/Xcode.app/Contents/Developer/Toolchains/OSX10.8.xctoolchain/usr/bin/cc
CPP = /Applications/Xcode.app/Contents/Developer/Toolchains/OSX10.8.xctoolchain/usr/bin/cc -E

If you installed XCode to standard location, you’ll find toolchain at /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain.

So until Apple fix apxs, you should create a symlink between real and expected location :

1

sudo ln -s /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain /Applications/Xcode.app/Contents/Developer/Toolchains/OSX10.8.xctoolchain

Configure will now works as expected :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

mbp-rico:native henri$ CFLAGS='-arch i386 -arch x86_64' ./configure --with-apr=/usr --with-ssl=/usr --with-java-home=/System/Library/Frameworks/JavaVM.framework/Versions/A/
checking build system type... x86_64-apple-darwin12.2.0
checking host system type... x86_64-apple-darwin12.2.0
checking target system type... x86_64-apple-darwin12.2.0
checking for a BSD-compatible install... /usr/bin/install -c
checking for working mkdir -p... yes
Tomcat Native Version: 1.1.24
checking for chosen layout... tcnative
checking for APR... yes
  setting CC to "/Applications/Xcode.app/Contents/Developer/Toolchains/OSX10.8.xctoolchain/usr/bin/cc"
  setting CPP to "/Applications/Xcode.app/Contents/Developer/Toolchains/OSX10.8.xctoolchain/usr/bin/cc -E"
checking for JDK location (please wait)... /System/Library/Frameworks/JavaVM.framework/Versions/A/
checking Java platform... checking Java platform...
checking for sablevm... NONE
  adding "-I/System/Library/Frameworks/JavaVM.framework/Versions/A//Headers" to TCNATIVE_PRIV_INCLUDES
checking os_type directory... jni_md.h found in /System/Library/Frameworks/JavaVM.framework/Versions/A//Headers
checking for gcc... /Applications/Xcode.app/Contents/Developer/Toolchains/OSX10.8.xctoolchain/usr/bin/cc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether /Applications/Xcode.app/Contents/Developer/Toolchains/OSX10.8.xctoolchain/usr/bin/cc accepts -g... yes
checking for /Applications/Xcode.app/Contents/Developer/Toolchains/OSX10.8.xctoolchain/usr/bin/cc option to accept ISO C89... none needed
checking for OpenSSL library... using openssl from /usr/lib and /usr/include
checking OpenSSL library version... ok
checking for OpenSSL DSA support... yes
  setting TCNATIVE_LDFLAGS to "-lssl -lcrypto"
  adding "-DHAVE_OPENSSL" to CFLAGS
  setting TCNATIVE_LIBS to ""
  setting TCNATIVE_LIBS to " -L/usr/lib -R/usr/lib -lapr-1 -lpthread"
configure: creating ./config.status
config.status: creating tcnative.pc
config.status: creating Makefile
config.status: executing default commands

Thanks stack-exchange for covering this issue

Understanding Java From Command Line on OSX

Java on OSX

OSX is a good platform for Java development but also running Java applications. Sadly XServe servers are no more available but in many cases Mac Mini could to pretty good works as Java server applications.

For a long time, OSX Java was maintained by Apple, from Sun Hotspot and was often a bit late vs Windows/Linux releases.

With Lion, Apple announced that they won’t produce Java for their futures OS, starting with Mountain Lion (10.8) and Oracle will do the job as they did for major distributions.

OpenJDK project included OSX support more than one year ago and there is now a very good coverage of Java for OSX.

It take some time to see first official Java 7 from Oracle on OSX, for Lion only, but there was community alternatives like openjdk-osx-build, where you could find a large choice of OpenJDK for OSX (7, 8, 8 with Lambda, 8 with Jigsaw).

If you install Java’s from Oracle or openjdk-osx-build, you may want to know how to select one of them for your application and even select a specific one for some of your applications.

Java Preferences

Apple provide a good tool to select default JVM, Java Preferences :

In this screenshot you could see many JVM, from many sources, Apple, Oracle and openjdk-osx-build and default ordering Java (from up to bottom).

Here you’ll see that default JVM will be Apple Java 1.6.0_33-b03-424 in 64bits, next choice will be Apple Java 1.6.0_33-b03-424 in 32bits. You will notice these JVM are marked as System, more on this later.

Next you’ll find Apple Java 1.6.0_31 in 64 and 32 bits and then Java 1.7 (1.7.0-jdk7u6-b20-20120719) from openjdk-osx-build. By the end you’ll find latest official Oracle Java 7, aka 1.7.0_05.

What does it means for you in a command line mode, console is just mandatory for any serious OSX geek ?

Let see java used by default :

1
2
3
4

mbp-rico:~ henri$ java -version
java version "1.6.0_33"
Java(TM) SE Runtime Environment (build 1.6.0_33-b03-424-11M3720)
Java HotSpot(TM) 64-Bit Server VM (build 20.8-b03-424, mixed mode)

Default Java is Apple 1.6.0_33, 64bits as expected, so far so good.

What should i do if I want to select instead Java 7 ?

Standard Unix way

You could just update your PATH environment variable to update search path :

1
2
3
4
5

mbp-rico:~ henri$ export PATH=/Library/Java/JavaVirtualMachines/1.7.0u6.jdk/Contents/Home/bin:$PATH
mbp-rico:~ henri$ java -version
openjdk version "1.7.0-jdk7u6-b20"
OpenJDK Runtime Environment (build 1.7.0-jdk7u6-b20-20120719)
OpenJDK 64-Bit Server VM (build 23.2-b09, mixed mode)

It works but OSX provide smarter mechanism.

OSX way

Keeping in mind we’re discussing command line operation, updating default JVM via Java Preferences will not be retained, will define instead JAVA_HOME environment variable like this :

1
2
3
4
5

mbp-rico:~ henri$ export JAVA_HOME=/Library/Java/JavaVirtualMachines/1.7.0u6.jdk/Contents/Home/
mbp-rico:~ henri$ java -version
openjdk version "1.7.0-jdk7u6-b20"
OpenJDK Runtime Environment (build 1.7.0-jdk7u6-b20-20120719)
OpenJDK 64-Bit Server VM (build 23.2-b09, mixed mode)

We could keep our current PATH and it will be Apple java bootstrap system, living into /usr/bin/java who make use of JAVA_HOME and launch the proper JVM. Simple but efficient .

java_home

As we see previously, Java Preferences define an order of preferred JVM on OSX, like alternatives does on many Linux systems, especially those using JPackage tooling. So there should be a way to get access to these preferences and here entering java_home

java_home is located in /usr/libexec and has many useful features :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

mbp-rico:~ henri$ /usr/libexec/java_home --help
Usage: java_home [options...]
    Returns the path to a Java home directory from the current user's settings.

Options:
    [-v/--version   <version>]       Filter Java versions in the "JVMVersion" form 1.X(+ or *).
    [-a/--arch      <architecture>]  Filter JVMs matching architecture (i386, x86_64, etc).
    [-d/--datamodel <datamodel>]     Filter JVMs capable of -d32 or -d64
    [-t/--task      <task>]          Use the JVM list for a specific task (Applets, WebStart, BundledApp, JNI, or CommandLine)
    [-F/--failfast]                  Fail when filters return no JVMs, do not continue with default.
    [   --exec      <command> ...]   Execute the $JAVA_HOME/bin/<command> with the remaining arguments.
    [-R/--request]                   Request installation of a Java Runtime if not installed.
    [-X/--xml]                       Print full JVM list and additional data as XML plist.
    [-V/--verbose]                   Print full JVM list with architectures.
    [-h/--help]                      This usage information.

Let’s play with java_home now.

Obtaining path of default JVM :

1
2

mbp-rico:~ henri$ /usr/libexec/java_home
/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home

Obtaining path of default Java 7 JVM :

1
2

mbp-rico:~ henri$ /usr/libexec/java_home -v 1.7
/Library/Java/JavaVirtualMachines/1.7.0u6.jdk/Contents/Home

Obtaining path of default Java 8 JVM :

1
2

mbp-rico:~ henri$ /usr/libexec/java_home -v 1.8
/Library/Java/JavaVirtualMachines/1.8.0.jdk/Contents/Home

Obtaining path of default Java 1.6 32 bits JVM :

1
2

mbp-rico:~ henri$ /usr/libexec/java_home -v 1.6 -a i386
/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home

Obtaining path of default Java 1.6 64 bits JVM :

1
2

mbp-rico:~ henri$ /usr/libexec/java_home -v 1.6 -a x86_64
/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home

Here you could see that 32 and 64bits JVM have the same path. This is because due to universal mode (i386/x86_64), Apple produce a dual mode JVM. This is not the case for Oracle Java 7 where only 64bits JVM is available.

Let’s combine java_home and JAVA_HOME :

1
2
3
4
5

mbp-rico:~ henri$ export JAVA_HOME=`/usr/libexec/java_home -v 1.7`
mbp-rico:~ henri$ java -version
openjdk version "1.7.0-jdk7u6-b20"
OpenJDK Runtime Environment (build 1.7.0-jdk7u6-b20-20120719)
OpenJDK 64-Bit Server VM (build 23.2-b09, mixed mode)

This is a very nice features if you want to specify a Java Level (6 or 7) following your Java Preferences for some of your server side application (let say Apache Tomcat) or command operation (like Apache Maven).

Typically for my Apache Tomcat powered application like Jenkins, I usually set it in bin/setenv.sh :

1
2

export JAVA_HOME=`/usr/libexec/java_home -v 1.7`
CATALINA_OPTS=-Xms256m -Xmx512m -DJENKINS_HOME=$JENKINS_HOME -Dhudson.model.Hudson.logStartupPerformance=true -Duser.language=en -Djava.awt.headless=true

Do you want to get a list of all JVM on your system ?

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37

mbp-rico:~ henri$ /usr/libexec/java_home -V
Matching Java Virtual Machines (33):
    1.6.0_33-b03-424, x86_64: "Java SE 6"   /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home
    1.6.0_33-b03-424, i386:   "Java SE 6"   /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home
    1.6.0_31-b04-411, x86_64: "Java SE 6"   /Library/Java/JavaVirtualMachines/1.6.0_31-b04-411.jdk/Contents/Home
    1.6.0_31-b04-411, i386:   "Java SE 6"   /Library/Java/JavaVirtualMachines/1.6.0_31-b04-411.jdk/Contents/Home
    1.7.0-jdk7u6-b20-20120719, x86_64:    "OpenJDK 7"   /Library/Java/JavaVirtualMachines/1.7.0u6.jdk/Contents/Home
    1.8.0-jdk8-b47-20120720, x86_64:  "OpenJDK 8"   /Library/Java/JavaVirtualMachines/1.8.0.jdk/Contents/Home
    1.7.0-jdk7u4-b21-20120427, i386:  "OpenJDK 7"   /Library/Java/JavaVirtualMachines/1.7.0u4.jdk/Contents/Home
    1.7.0_05, x86_64: "Java SE 7"   /Library/Java/JavaVirtualMachines/1.7.0.jdk/Contents/Home
    1.6.0_33-b03-424, x86_64: "Java SE 6"   /Library/Java/JavaVirtualMachines/1.6.0_33-b03-424.jdk/Contents/Home
    1.6.0_33-b03-424, i386:   "Java SE 6"   /Library/Java/JavaVirtualMachines/1.6.0_33-b03-424.jdk/Contents/Home
    1.8.0-jdk8-b45-20120713-jigsaw, x86_64:   "OpenJDK 8"   /Library/Java/JavaVirtualMachines/1.8.0-jigsaw.jdk/Contents/Home
    1.8.0-b48-20120720-lambda, x86_64:    "OpenJDK 8"   /Library/Java/JavaVirtualMachines/1.8.0-lambda.jdk/Contents/Home
    1.7.0-jdk7u6-b20-20120719, i386:  "OpenJDK 7"   /Library/Java/JavaVirtualMachines/1.7.0u6.jdk/Contents/Home
    1.7.0-jdk7u4-b21-20120427, x86_64:    "OpenJDK 7"   /Library/Java/JavaVirtualMachines/1.7.0u4.jdk/Contents/Home
    1.7.0-jdk7u4-b21-20120421, x86_64:    "OpenJDK 7"   /Library/Java/JavaVirtualMachines/1.7.0u4-64.jdk/Contents/Home
    1.7.0, x86_64:    "OpenJDK 7"   /Library/Java/JavaVirtualMachines/1.7.0u.jdk/Contents/Home
    1.7.0, i386:  "OpenJDK 7"   /Library/Java/JavaVirtualMachines/1.7.0u.jdk/Contents/Home
    1.6.0_32-b05-420, x86_64: "Java SE 6"   /Library/Java/JavaVirtualMachines/1.6.0_32-b05-420.jdk/Contents/Home
    1.6.0_32-b05-420, i386:   "Java SE 6"   /Library/Java/JavaVirtualMachines/1.6.0_32-b05-420.jdk/Contents/Home
    1.6.0_32-b05-417, x86_64: "Java SE 6"   /Library/Java/JavaVirtualMachines/1.6.0_32-b05-417.jdk/Contents/Home
    1.6.0_32-b05-417, i386:   "Java SE 6"   /Library/Java/JavaVirtualMachines/1.6.0_32-b05-417.jdk/Contents/Home
    1.6.0_31-b04-413, x86_64: "Java SE 6"   /Library/Java/JavaVirtualMachines/1.6.0_31-b04-413.jdk/Contents/Home
    1.6.0_31-b04-413, i386:   "Java SE 6"   /Library/Java/JavaVirtualMachines/1.6.0_31-b04-413.jdk/Contents/Home
    1.6.0_30-b12-409, x86_64: "Java SE 6"   /Library/Java/JavaVirtualMachines/1.6.0_30-b12-409.jdk/Contents/Home
    1.6.0_30-b12-409, i386:   "Java SE 6"   /Library/Java/JavaVirtualMachines/1.6.0_30-b12-409.jdk/Contents/Home
    1.6.0_30-b12-404, x86_64: "Java SE 6"   /Library/Java/JavaVirtualMachines/1.6.0_30-b12-404.jdk/Contents/Home
    1.6.0_30-b12-404, i386:   "Java SE 6"   /Library/Java/JavaVirtualMachines/1.6.0_30-b12-404.jdk/Contents/Home
    1.6.0_29-b11-397, x86_64: "Java SE 6"   /Library/Java/JavaVirtualMachines/1.6.0_29-b11-397.jdk/Contents/Home
    1.6.0_29-b11-397, i386:   "Java SE 6"   /Library/Java/JavaVirtualMachines/1.6.0_29-b11-397.jdk/Contents/Home
    1.6.0_27-b07-395, x86_64: "Java SE 6"   /Library/Java/JavaVirtualMachines/1.6.0_27-b07-395.jdk/Contents/Home
    1.6.0_27-b07-395, i386:   "Java SE 6"   /Library/Java/JavaVirtualMachines/1.6.0_27-b07-395.jdk/Contents/Home
    1.6.0_26-b03-383, x86_64: "Java SE 6"   /Library/Java/JavaVirtualMachines/1.6.0_26-b03-383.jdk/Contents/Home
    1.6.0_26-b03-383, i386:   "Java SE 6"   /Library/Java/JavaVirtualMachines/1.6.0_26-b03-383.jdk/Contents/Home

/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home

Note on JVM Locations

You may have noticed many differents paths for JVM :

  • /System/Library/Java/JavaVirtualMachines is where Apple install System JVM. Here you could have only one JVM by family, ie 1.6, 1.7. These JVM will be available to all users on system.

  • /Library/Java/JavaVirtualMachines is a slot location for guest JVMs, specially designed to host contributors JVM like Oracle, openjdk-osx-build or Apple Developper Preview JVMs Also, these JVM will be available to all users on system.

  • /Users/bill/Library/Java/JavaVirtualMachines is a slot for contributor JVMs but only available to user bill.

To conclude

OSX is probably the platform with the more choice of Java to run and experiment, Java 6, Java 7, OpenJDK 7, 8, Lambda, Jigsaw.

And with its /usr/libexec/java_home and JAVA_HOME environment variable, you could select any of them for your console or command mode operations very easily.

Enjoy Java on OSX !

Building Universal Apache Tomcat Native Library on OS/X - Updated

Updated build process for tomcat-connector, 1.1.24, no more APXS variable or configure parameters required

1
2
3
4
5
6
7
8
9
10
11
12

TCN_RELEASE=1.1.24
curl http://mir2.ovh.net/ftp.apache.org/dist//tomcat/tomcat-connectors/native/$TCN_RELEASE/source/tomcat-native-$TCN_RELEASE-src.tar.gz -o tomcat-native-$TCN_RELEASE-src.tar.gz
tar xvzf tomcat-native-$TCN_RELEASE-src.tar.gz
cd tomcat-native-$TCN_RELEASE-src/jni/native

CFLAGS='-arch i386 -arch x86_64' APXSLDFLAGS='-arch i386 -arch x86_64' ./configure --with-apr=/usr --with-ssl=/usr --with-java-home=/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home
make clean
make

sudo cp .libs/libtcnative-1.0.1.24.dylib /usr/lib/java
sudo rm -f  /usr/lib/java/libtcnative-1.dylib
sudo ln -s /usr/lib/java/libtcnative-1.0.1.24.dylib /usr/lib/java/libtcnative-1.dylib

A note about Lion

If you get Java on Lion using the java command on terminal or via the Java Developer Package for Mac OS X 10.7, Java headers are not on the usual location and you could find them under /System/Library/Frameworks/JavaVM.framework/Versions/A/Headers

You should then update the configure command line like this :

1

CFLAGS='-arch i386 -arch x86_64' ./configure --with-apr=/usr --with-ssl=/usr --with-java-home=/System/Library/Frameworks/JavaVM.framework/Versions/A/

1
2
3
4
5
6
7
8
9
10
11
12

TCN_RELEASE=1.1.24
curl http://mir2.ovh.net/ftp.apache.org/dist//tomcat/tomcat-connectors/native/$TCN_RELEASE/source/tomcat-native-$TCN_RELEASE-src.tar.gz -o tomcat-native-$TCN_RELEASE-src.tar.gz
tar xvzf tomcat-native-$TCN_RELEASE-src.tar.gz
cd tomcat-native-$TCN_RELEASE-src/jni/native

CFLAGS='-arch i386 -arch x86_64' ./configure --with-apr=/usr --with-ssl=/usr --with-java-home=/System/Library/Frameworks/JavaVM.framework/Versions/A/
make clean
make

sudo cp .libs/libtcnative-1.0.dylib /usr/lib/java
sudo rm -f  /usr/lib/java/libtcnative-1.dylib
sudo ln -s /usr/lib/java/libtcnative-1.0.dylib /usr/lib/java/libtcnative-1.dylib

Using Apache Tomcat Connector (Mod_jk) on OSX

You’ll need first mod_jk installed, follow Building Guide.

Create /etc/apache2/other/jk.conf :

1
2
3
4
5
6
7
8
9
10
11
12

# Load JK Module
LoadModule jk_module     libexec/apache2/mod_jk.so
# JK workers.properties
JkWorkersFile /etc/apache2/other/workers.properties
# JK shared memory location
JkShmFile     /var/log/apache2/mod_jk.shm
# JK logs
JkLogFile     /var/log/apache2/mod_jk.log
# JK log level [debug/error/info]
JkLogLevel    info
# JK timestamp log format
JkLogStampFormat "[%a %b %d %H:%M:%S %Y] "

Create /etc/apache2/other/workers.properties

1
2
3
4
5
6
7
8
9
10
11
12
13

worker.list=jenkins,watch,manage

# Set properties for worker jenkins (ajp13)
worker.jenkins.type=ajp13
worker.jenkins.host=localhost
worker.jenkins.port=8009

# status workers
worker.watch.type=status
worker.watch.read_only=true
worker.watch.mount=/user/status/jk
worker.manage.type=status
worker.manage.mount=/admin/status/jk

I choose to use VirtualName Hosting and so defined one into /etc/apache2/extra/httpd-vhosts.conf :

1
2
3
4
5
6
7
8
9
10
11
12
13
14

NameVirtualHost *:80

<VirtualHost *:80>

    ServerName  mbpbuilder.hgomez.net
    ServerAlias mbpbuilder
    ServerAdmin webmaster@mbpbuilder.hgomez.net

    ErrorLog    "/var/log/apache2/mbpbuilder.org-error_log"
    CustomLog   "/var/log/apache2/mbpbuilder-access_log" common

    JkMount  /* jenkins

</VirtualHost>

Building Universal Apache Tomcat Connector (Mod_jk) on OSX

Build Universal Apache Tomcat Connector (mod_jk) for OSX follow tricks used for Apache Tomcat Native Library.

1

CFLAGS='-arch i386 -arch x86_64' APXSLDFLAGS='-arch i386-arch x86_64'

Here is a small script to do it :

1
2
3
4
5
6
7
8
9
10
11
12

#!/bin/sh
#

JK_VERSION=1.2.37

curl http://mir2.ovh.net/ftp.apache.org/dist/tomcat/tomcat-connectors/jk/tomcat-connectors-${JK_VERSION}-src.tar.gz -o tomcat-connectors-${JK_VERSION}-src.tar.gz
tar xvzf tomcat-connectors-${JK_VERSION}-src.tar.gz
cd tomcat-connectors-${JK_VERSION}-src/native

./configure --with-apxs=/usr/sbin/apxs CFLAGS='-arch i386 -arch x86_64' APXSLDFLAGS='-arch i386-arch x86_64'
make clean
make

Installation is pretty simple :

1

sudo cp apache-2.0/.libs/mod_jk.so /usr/libexec/apache2/

You could then restart your Apache HTTPd server to get new mod_jk used :

1

sudo /usr/sbin/apachectl restart

SSD or Not SSD ?

My MacBookPro is quite old now :

  • MacBook Pro 5.1 (Late 2008)

  • Core2Duo 2.66Ghz

Under Lion, MBP appears to be sometime laggy even if I already updated it :

  • Replaced original 4Gb RAM to 8Gb DDR3 (GSkill PC8500 SQ (1066 MHz), 7-7-7-20)

  • Replaced original Hitachi 320GB/5400 RPM by a 500Gb WesternDigital Black Black 7200RPM (WD5000BEKT-75KA9T0)

I run GeekBench 2.2.7 and give me a bench result of 3752 :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

Benchmark Summary
  Integer Score              3123 |||||||||
  Floating Point Score       5493 ||||||||||||||||
  Memory Score               2629 |||||||
  Stream Score               2110 ||||||

  Geekbench Score            3752 |||||||||||

System Information
  Operating System      Mac OS X 10.7.3 (Build 11D50)
  Model                 MacBook Pro (Late 2008)
  Motherboard           Apple Inc. Mac-F42D86A9 Proto
  Processor             Intel Core 2 Duo T9550 @ 2.66 GHz
                        1 Processor, 2 Cores, 2 Threads
  Processor ID          GenuineIntel Family 6 Model 23 Stepping 10
  L1 Instruction Cache  32.0 KB x 2
  L1 Data Cache         32.0 KB x 2
  L2 Cache              6.00 MB
  L3 Cache              0.00 B
  Memory                8.00 GB 1067 MHz DDR3
  BIOS                  Apple Inc.    MBP51.88Z.007E.B06.1202061253

IOs seems to be the limiting factor, especially when I’m using VirtualBox, I feel a slow IO performances.

Time to bench IOs

There is no tools like HD Tune on OSX, so I wrote a very simple shell script to measure raw IO performances.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

#!/bin/sh
COUNT=2048

echo "testing pseudo-IO performances - 1st Pass"
dd if=/dev/zero of=/dev/null bs=1m count=$COUNT

echo "testing IO write performances - 1st Pass"
dd if=/dev/zero of=PERFTEST bs=1m count=$COUNT

echo "testing IO read performances - 1st Pass"
dd if=PERFTEST of=/dev/null bs=1m count=$COUNT

echo "testing IO read performances - 2nd Pass"
dd if=PERFTEST of=/dev/null bs=1m count=$COUNT

echo "testing IO write performances - 2nd Pass"
dd if=/dev/zero of=PERFTEST bs=1m count=$COUNT

Results :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

testing pseudo-IO performances - 1st Pass
2048+0 records in
2048+0 records out
2147483648 bytes transferred in 0.225590 secs (9519410157 bytes/sec)
testing IO write performances - 1st Pass
2048+0 records in
2048+0 records out
2147483648 bytes transferred in 29.882202 secs (71864973 bytes/sec)
testing IO read performances - 1st Pass
2048+0 records in
2048+0 records out
2147483648 bytes transferred in 0.677308 secs (3170615711 bytes/sec)
testing IO read performances - 2nd Pass
2048+0 records in
2048+0 records out
2147483648 bytes transferred in 0.675835 secs (3177527036 bytes/sec)
testing IO write performances - 2nd Pass
2048+0 records in
2048+0 records out
2147483648 bytes transferred in 33.203725 secs (64675986 bytes/sec)

Note, I run this performance tests from a directory excluded from Spotlight indexing !

  • Pseudo IO performance is justing virtual IO (/dev/zero and /dev/null), so it provide max raw IO performance : 9078 MB/s

  • Write IO performance is between 61 and 68 MB/s

  • Read IO performance is very high with 3023 MB/s

I replayed script raising COUNT from 2048 to 20480 to reduce OSX ram buffer impact in Read IO performance but still get about 2000 MB/s

iStat Menu disk activity - Write Performance

Conclusions

  • WD Black Edition perform pretty well on raw sequential Read Operations

  • With its average 63 MB/s raw sequential Write Operations, WD is about 7 time slower than faster SSD like OCZ Vertex 3

Is it time to update MBP to SSD ? Probably and my candidates are :

  • Crucial M4 128GB. This SSD is reported very stable and reliable. Bonus, its firmware could be updated from Mac.

  • OCZ Vertex 3 120GB. This SSD is top performer in benchmarks but Googling it reports many reliability problems.

I’d like to get feedback from you, performing same performance testing on your Mac hardware (MBP/ SSD configurations very welcomed).

DevOps Logo 2nd Try

Here is the second try of logos for DevOps, still provided by Sabrina (@saabpii). She carefully tracked comments here and on Twitter :

Please vote for your preferred one.

DevOps Logos

I asked some times ago Sabrina Perrin (@saabpii) a great graphic designer I worked with for years, if she could try to works on some DevOps logo.

As expected she has been very motivated and inspired.

Here are the results :

Now I need you to comments and votes for them.

All of this artwork is free to use, just mention Sabrina somewhere on your sites/blogs/presentations.

Thanks again Sabrina !

Uninstalling MacFuse on Lion

If you installed MacFuse on Lion (10.7) and tried to uninstall you may encountered the following error :

1
2

sudo /Library/Filesystems/fusefs.fs/Support/uninstall-macfuse-core.sh
MacFUSE Uninstaller: Can not find the Archive.bom for MacFUSE Core package.

Uninstaller didn’t check for Lion (uname -r reporting 11.x). So fix is easy, just edit uninstaller script /Library/Filesystems/fusefs.fs/Support/uninstall-macfuse-core.sh and add 11) in case next to 10)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

...

OS_RELEASE=`/usr/bin/uname -r`
case "$OS_RELEASE" in
  8*)
    log "Incorrect uninstall. Use the Tiger version please."
    exit 1
    ;;
  9*)
    PACKAGE_RECEIPT="$INSTALL_VOLUME/Library/Receipts/MacFUSE Core.pkg"
    OUTER_PACKAGE_RECEIPT="$INSTALL_VOLUME/Library/Receipts/MacFUSE.pkg"
    BOMFILE="$PACKAGE_RECEIPT/Contents/Archive.bom"
    ;;
  10*|11*)
     PACKAGE_RECEIPT=""
     BOMFILE="$INSTALL_VOLUME/var/db/receipts/com.google.macfuse.core.bom"
     ;;
esac

Batch Rpm Signing

I’m using Jenkins to build RPMs with free-style scripts.

Decent RPM packager should sign his RPMs so they could be checked by yum/zypper tools.

Here you could be in trouble since rpm signing require a password to be passed in command line :

1
2

rpm --addsign -D "_signature gpg" -D "_gpg_name packagers@myforge.org" RPMS/noarch/myjenkins-1.0.0-1.noarch.rpm<br />
Enter pass phrase:<br />

It’s quite problematic for a RPM build factory.

After digging around Internet, best solution appears to be using expect and I developped a simple script for such purpose with following constraints :

  • packager gpg name should be parametized (to avoid injecting it in ~/.rpmmacros)

  • gpg passphrase should be provided to command line (could be read from a secret file)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

#!/usr/bin/expect -f
#
# rpmsign-batch.expect : expect powered rpm signing command
#

proc usage {} {
        send_user "Usage: rpmsign-batch.expect gpgname passphrase rpmfile\n\n"
        exit
}

if {[llength $argv]!=3} usage

set gpgname [lrange $argv 0 0]
set passphrase [lrange $argv 1 1]
set rpmfile [lrange $argv 2 2]

send_user "passphrase=$passphrase gpgname=$gpgname\n"

spawn rpm --addsign -D "_signature gpg" -D "_gpg_name $gpgname" $rpmfile
expect -exact "Enter pass phrase: "
send -- "$passphrase\r"
expect eof

You could then use it to sign rpms from your freestyle jobs like :

1
2
3
4
5
6

# Password provided in clear in job (weird)
rpmsign-batch.expect packagers@myforge.org mypassphrase RPMS/noarch/myjenkins-1.0.0-1.noarch.rpm

# Password grabbed from a secret file (better)
PASSPHRASE=`cat /my/secret-passphrase-file`
rpmsign-batch.expect packagers@myforge.org $PASSPHRASE RPMS/noarch/myjenkins-1.0.0-1.noarch.rpm