blog@insidesystems.net

It turns out that the problem is that within FreeBSD’s installation of PECL, it calls PHP from the command line with the -n flag. a.k.a. —no-php-ini

This prevents /usr/local/etc/php/extensions.ini from getting loaded, and thus there is no PCRE support.

You can work around it by removing “-n” from inside the pecl script.

He solved his problem by forcing clamd to use a different set of threading libraries than default. (The older “libthr”, to be precise.)

He did this by using the libmap functionality that had been added to FreeBSD in 5.1 It’s incredibly simple, you just create /etc/libmap.conf, add a few lines of configuration saying what object files to substitute, and then run your app.

[clamd]
libc_r.so.5             libthr.so.2
libc_r.so.6             libthr.so.2
libthr.so.2             libthr.so.2
libpthread.so.1         libthr.so.2
libpthread.so.2         libthr.so.2 

It worked perfectly. The application worked flawlessly with the older thread library.

So next time you want to use a non-standard library for just one application, remember that libmap.conf is your friend.

Now you know. And knowing is half the battle.

• At the bottom, we have our Ruby on Rails websites.
• They get web-enabled via Mongrel Cluster.
• And then Apache 2.2 with mod_proxy_balancer spreads the end-users hits across the hordes of mongrels.

It works well, but there are a few problems with management. Notably, there is no FreeBSD rc.d script to easily start and stop individual sites, or to automatically start them all on boot.

As such, we quickly wrote a mongrel_cluster rc.d script that accepts a few rc.conf variables, to get your mongrel cluster running on FreeBSD in no time flat.

• Make a directory (/usr/local/etc/mongrel_cluster)
• Put your mongrel_cluster yml files in that directory, naming each one for the site it represents (foo.yml bar.yml baz.yml)

• mongrel_cluster_enable=”YES”
• mongrel_cluster_dir=”/usr/local/etc/mongrel_cluster”
• mongrel_cluster_list=”foo bar baz”

And now put the attached mongrel_cluster file in your /usr/local/etc/rc.d directory.

Now you can do things like:

Hopefully that makes managing your FreeBSD mongrels just a bit simpler!

mongrel_cluster

#!/bin/sh
# PROVIDE: mongrel_cluster
# REQUIRE: DAEMON
# KEYWORD: shutdown
#
# Add the following line to /etc/rc.conf to enable mongrel_cluster:
# mongrel_cluster_enable (bool):      Set to "NO" by default.
#                                     Set it to "YES" to enable mongrel_cluster
# mongrel_cluster_list (str):         Set to "" by default.
#                                     The list of mongrel_cluster_list to start (leave off the .yml)
# mongrel_cluster_dir (str):          Set to "/usr/local/etc/mongrel_clusters" by default.
#
. /etc/rc.subr
PATH=$PATH:/usr/local/bin

name="mongrel_cluster" 
rcvar=`set_rcvar`
start_cmd="${name}_start" 
stop_cmd="${name}_stop" 

load_rc_config $name

eval "${rcvar}=\${${rcvar}:-'NO'}" 
[ -z "$mongrel_cluster_list" ]        && mongrel_cluster_list="" 
[ -z "$mongrel_cluster_dir" ]        && mongrel_cluster_dir="/usr/local/etc/mongrel_clusters" 
required_dirs=$mongrel_cluster_dir

# First, let's setup our start/stop routines
mongrel_cluster_start()
{
    echo "Starting Mongrel Clusters:" 
    for mongrel in $mongrel_cluster_list; do
        echo -n "   ${mongrel} -- " 
        /usr/local/bin/mongrel_rails cluster::start -C $mongrel_cluster_dir/$mongrel.yml
    done
    return 0
}

mongrel_cluster_stop()
{
    echo "Stopping Mongrel Clusters:" 
    for mongrel in $mongrel_cluster_list; do
        echo -n "   $mongrel -- " 
        /usr/local/bin/mongrel_rails cluster::stop -C $mongrel_cluster_dir/$mongrel.yml
    done
    return 0
}

# everything after the start/stop is a mongrel to be started/stopped
cmd="$1" 
if [ $# -gt 0 ]; then
    shift
fi
if [ -n "$*" ]; then
    mongrel_cluster_list="$*" 
fi

run_rc_command "${cmd}" 

options            COMPAT_LINUX32

and then downloaded the latest Statically linked binary for Linux/i386 from the Darcs website.

Put the darcs executable in /usr/local/bin (or wherever you prefer) then make sure FreeBSD knows what kind of executable it is by running the following:

brandelf -t Linux /usr/local/bin/darcs

Reboot and voilà! Working darcs, that seems to function not only with a small test repository, but with large, complex production repositories.

So yes, BSD-Heads, Linux is good for something after all. And yes, we are aware that this is a filthy solution, but our attempt to successfully port GHC to FreeBSD/amd64 was abandoned after it became clear that it would be very time-consuming for us, and likely very simple for somebody more familiar with the GHC build process.

After some experimentation, it became clear that the least bad solution would be to create a statically linked 32-bit binary, that could be run an i386 compatible kernel.

options       COMPAT_IA32

Then on an FreeBSD/i386 machine, we went about building a binary package with a statically linked binary, by making a few edits to the darcs ports Makefile. Here is the diff:

--- Makefile.orig       Sat Feb 10 14:02:34 2007
+++ Makefile    Sat Feb 10 14:18:44 2007
@@ -14,10 +14,10 @@
 MAINTAINER=    haskell@FreeBSD.org
 COMMENT=       Yet another replacement for CVS, written in Haskell

-BUILD_DEPENDS= ghc:${PORTSDIR}/lang/ghc
-LIB_DEPENDS=   curl:${PORTSDIR}/ftp/curl \
-               gmp.7:${PORTSDIR}/math/libgmp4 \
-               readline.5:${PORTSDIR}/devel/readline
+BUILD_DEPENDS= ghc:${PORTSDIR}/lang/ghc \
+               curl:${PORTSDIR}/ftp/curl \
+               /usr/local/lib/libgmp.so.7:${PORTSDIR}/math/libgmp4 \
+               /usr/local/lib/libreadline.so.5:${PORTSDIR}/devel/readline

 OPTIONS=       SERVER "install server" off
 USE_AUTOTOOLS= autoconf:259
@@ -25,6 +25,7 @@
 CONFIGURE_ENV= CPPFLAGS="-I${LOCALBASE}/include ${PTHREAD_CFLAGS}" \
                LDFLAGS="-L${LOCALBASE}/lib -L${PREFIX}/lib/ ${PTHREAD_LIBS}" \
                CFLAGS="" 
+CONFIGURE_ARGS= --with-static-libs
 USE_GMAKE=     yes
 MAKEFILE=      GNUmakefile
 ALL_TARGET=    darcs darcs.1

And then, still on the i386, in ports/devel/darcs, I ran make package to create a new darcs binary package, containing the statically linked binary.

This package was then able to be copied over to the amd64 machines, and installed via pkg_add, without issue.

Edit: This binary then worked fine on a test repository, but it dumped core on a large, production repository. As such we switched to a different tactic. Read about it in Part 2.