SubVersion server setup on Snow Leopard Server

Thu, 18 Mar 2010 09:11:36 +1100

For a little while I’ve been thinking that I really should setup a SubVersion server again to store my source code in.
Of course the preferred way of would be to use only the Apple provided tools but since this is a little outside of what “most” people would want to use not all of the required configuration options aren available.

A little searching on the net and I came across this article Subversion on OS X Leopard Server by Nayan Hajratwala. Though this would seem to have been written for Leopard Server the instructions work exactly the same for Snow Leopard Server.
So instead of reinventing the setup procedure I thought it best to pass on the credit where it’s due. Thanks for the excellent post Nayan.

mod_perl on Snow Leopard Server

Sat, 16 Jan 2010 16:52:49 +1100

It’s been about four months since I first installed Snow Leopard Server, all in all I’m quite impressed. One thing that I found a great improvement over Leopard Server was that the mod_perl module was compiled properly to run on the server with no further changes required.

Enabling mod_perl
1. Click on the Web service
2. Click on Settings
1. Open Server Admin and connect to the Snow Leopard Server
1. Click on the modules tab
2. Click the + at the bottom of the module list and enter the following
• Module Name: perl_module
• Enabled [Checked]
• Module Path: libexec/apache2/mod_perl.so
1. Click OK
2. Click Save

mod_perl is now enabled and you can add your desired configuration to the site configuration files.

Using mod_perl
In /etc/apache2/sites you’ll find your website configuration files.
Edit the appropriate file for the site you want to enable mod_perl for and enter your configuration which will be along the lines of.
<IfModule mod_perl.c>
PerlRequire /Users/<MyUsername>/Library/Perl/startup.pl
<Location "/Somewhere">
SetHandler perl-script
PerlHandler MyModule
</Location>
</IfModule>
In startup.pl enter your standard mod_perl start up configuration.
This may look something like this.
#!/usr/bin/perl
####################
# Description: mod_perl startup script to pre-load perl
# modules that will used when running the
# web servers perl modules
#

####################
# Standard Modules
use strict;
# Custom Modules
use lib "/Users/<MyUsername>/Library/Perl";
use MyModule;

####################
# Do some processing

1;

In the site configuration and startup.pl you’ll note that I’ve put my Perl code in my home directory under Library/Perl. This could be anywhere of course. If your server will host websites for many users that will each be setting up / developing / using their own mod_perl modules then you quite possibly don’t want to do this as you give each user with mod_perl essentially root access the server.
In my case, I’m in complete control of the modules and don’t see this configuration to present an unacceptable security risk.

Compiling Open Source products with multi architecture support

Sat, 22 Aug 2009 18:59:22 +1000

Recently I posted about how to build Perl modules with support for multiple architectures. But what do you do if you need to use a library that Apple haven’t prebuilt for us?
Well fortunately this can be quite an easy process if the library uses configure nicely.

I wanted to build the GD library with PNG support.
First I downloaded the libpng and libgd sources.
The process of building is only slightly different to the usual configure; make; make install process.
Before we get into the usual process we need to set a couple of environment variables.
CFLAGS=”-O -g -isysroot /Developer/SDKs/MacOSX10.5.sdk -arch i386 -arch ppc -arch x86_64”
LDFLAGS=”-arch i386 -arch ppc -arch x86_64”
export CFLAGS LDFLAGS
Note that /Develper/SDKs/MacOSX10.5.sdk should point to the current SDK version installed.
Now we can go and run the configure script. This again has an extra option in addition to anything that you wish to add.
./configure --disable-dependency-tracking
According to Apple GCC’s dependancy checking can get confused when working with multiple architectures. The --disable-dependency-tracking tells GCC not to worry about it.
Now run make and the library will be built.
To check that it has all the desired architectures, check with the file command.
file .libs/libpng.3.dylib .libs/libpng12.0.dylib
.libs/libpng.3.dylib: Mach-O universal binary with 3 architectures
.libs/libpng.3.dylib (for architecture i386): Mach-O dynamically linked shared library i386
.libs/libpng.3.dylib (for architecture ppc7400): Mach-O dynamically linked shared library ppc
.libs/libpng.3.dylib (for architecture x86_64): Mach-O 64-bit dynamically linked shared library x86_64
.libs/libpng12.0.dylib: Mach-O universal binary with 3 architectures
.libs/libpng12.0.dylib (for architecture i386): Mach-O dynamically linked shared library i386
.libs/libpng12.0.dylib (for architecture ppc7400): Mach-O dynamically linked shared library ppc
.libs/libpng12.0.dylib (for architecture x86_64): Mach-O 64-bit dynamically linked shared library x86_64
Now all that remains is to run make install to install the library.

Compiling Perl modules with x86_64 support for use with mod_perl

Fri, 21 Aug 2009 21:49:04 +1000

Last night I was playing around with a mod_perl page on my Mac OS X Server and wanted to use DBI. Okay nothing too fancy there I thought. It’s been a couple of years since I was playing with this code as I’ve been busy doing other thing... Problem was that when I tried restart Apache I got server errors. What could be going on I though... I have come across that before. So I checked my test script which did the same thing without all the request handler goodness. All works as expected! Hmmm... Lets take another look at the logs...

[Thu Aug 20 23:53:29 2009] [error] Can't load '/Library/Perl/5.8.8/darwin-thread-multi-2level/auto/DBI/DBI.bundle' for module DBI: dlopen(/Library/Perl/5.8.8/darwin-thread-multi-2level/auto/DBI/DBI.bundle, 1): no suitable image found. Did find:\n\t/Library/Perl/5.8.8/darwin-thread-multi-2level/auto/DBI/DBI.bundle: no matching architecture in universal wrapper at /System/Library/Perl/5.8.8/darwin-thread-multi-2level/DynaLoader.pm line 230.\n at /Library/Perl/5.8.8/darwin-thread-multi-2level/DBI.pm line 263\nBEGIN failed--compilation aborted at /Library/Perl/5.8.8/darwin-thread-multi-2level/DBI.pm line 263.\nCompilation failed in require at /Users/Share/Library/Perl/Test.pm line 12.\nBEGIN failed--compilation aborted at /Users/Shared/Library/Perl/Test.pm line 12.\nCompilation failed in require at /Users/Shared/Library/Perl/startup.pl line 14.\nBEGIN failed--compilation aborted at /Users/Shared/Library/Perl/startup.pl line 14.\nCompilation failed in require at (eval 2) line 1.\n

A quick search on my favorite search engine returned a few interesting threads... It looked like my module wasn’t compiled to support the required architectures... i.e. the module bundle didn’t have an object for x86_64.
A quick check with the file command shows the problem.

file /usr/bin/perl
/usr/bin/perl: Mach-O universal binary with 2 architectures
/usr/bin/perl (for architecture ppc7400): Mach-O executable ppc
/usr/bin/perl (for architecture i386): Mach-O executable i386

file /usr/libexec/apache2/mod_perl.so
/usr/libexec/apache2/mod_perl.so: Mach-O universal binary with 4 architectures
/usr/libexec/apache2/mod_perl.so (for architecture ppc7400): Mach-O bundle ppc
/usr/libexec/apache2/mod_perl.so (for architecture ppc64): Mach-O 64-bit bundle ppc64
/usr/libexec/apache2/mod_perl.so (for architecture i386): Mach-O bundle i386
/usr/libexec/apache2/mod_perl.so (for architecture x86_64): Mach-O 64-bit bundle x86_64

file /Library/Perl/5.8.8/darwin-thread-multi-2level/auto/DBI/DBI.bundle
/Library/Perl/5.8.8/darwin-thread-multi-2level/auto/DBI/DBI.bundle: Mach-O universal binary with 2 architectures
/Library/Perl/5.8.8/darwin-thread-multi-2level/auto/DBI/DBI.bundle (for architecture ppc7400): Mach-O bundle ppc
/Library/Perl/5.8.8/darwin-thread-multi-2level/auto/DBI/DBI.bundle (for architecture i386): Mach-O bundle i386

So how can this be? I installed via the usual way
sudo perl -MCPAN -e shell
install DBI
So what did I do wrong?
Well nothing actually... You see Apple have compiled Apache and mod_perl with 64 bit support. This is for both Power PC and Intel CPUs. But the Perl has only been compiled with 32 bit support.

With a little more fishing around on the web I found that I need to add “-arch x86_64” to the compile flags for module when building them.

So here’s the slightly tricky bit that has absolutely no warranty. If you follow these instructions you do so at your own risk... But hey if you’re reading this then chances are you’re a techie and are willing to take the risk.

The compile flags used to compile all Perl stuff are set in the module Config which is created when Perl was originally compiled. But I don’t way to rebuild Perl. That’s Apples job to maintain. That’s why I have Mac OS X Server and not the Linux or Solaris boxes any more.
If you modify the Config module settings then any new modules you install will use these configuration options.
So what are we looking for? Well it was easy enough to see that Perl had been built with i386 support so lets look for that and see what comes up.
Where to look next... Well this is where the find and grep commands come in... Oh and perl of course...
perl -V
Tells you where all the default Perl module search paths are, so that narrows down the search a little. But I took a stab in the dark and thought that /System/Library/Perl sounded like a nice place to start.
cd /System/Library/Perl
find . -type f -exec grep -li "arch i386" {} \;
./5.8.8/darwin-thread-multi-2level/Config_heavy.pl
./Extras/5.8.8/darwin-thread-multi-2level/Apache2/BuildConfig.pm
Of these two modules Config_heavy.pl is what we are after. Apache2/BuildConfig.pm is part of the Apache mod_perl install and is completely the wrong thing.

So the edit...
sudo vi ./5.8.8/darwin-thread-multi-2level/Config_heavy.pl
Now we want to find where the architectures used to build are set.
With a quick search (/-arch i386) you’ll find yourself on line 1197 which will have the magic compiler options that we want to add to.
$archflags = exists($ENV{ARCHFLAGS}) ? $ENV{ARCHFLAGS} : '-arch ppc -arch i386';
You need to add to this line so that it looks like this
$archflags = exists($ENV{ARCHFLAGS}) ? $ENV{ARCHFLAGS} : '-arch ppc -arch i386 -arch x86_64';
Save the file and you’re done.

Now go back to the DBI build path in ~/.cpan/build and try to build it again manually.
cd
sudo -s
cd .cpan/build/DBI-1.609/
make distclean
perl Makefile.PL
make
make test
Now we want to check that what we have build has the required architectures.
file blib/arch/auto/DBI/DBI.bundle
blib/arch/auto/DBI/DBI.bundle: Mach-O universal binary with 3 architectures
blib/arch/auto/DBI/DBI.bundle (for architecture ppc7400): Mach-O bundle ppc
blib/arch/auto/DBI/DBI.bundle (for architecture i386): Mach-O bundle i386
blib/arch/auto/DBI/DBI.bundle (for architecture x86_64): Mach-O 64-bit bundle x86_64
As you can see you now have a bundle that supports x86_64.
A quick make install will overwrite the DBI that was previously built.

Now for the easy bit, testing...
Since the error was reported in the Apache error log starting the server and tailing the logs will show you if all is to plan.
tail -f /var/log/apache2/error_log
[Thu Aug 20 23:56:00 2009] [error] Can't load '/Library/Perl/5.8.8/darwin-thread-multi-2level/auto/DBI/DBI.bundle' for module DBI: dlopen(/Library/Perl/5.8.8/darwin-thread-multi-2level/auto/DBI/DBI.bundle, 1): no suitable image found. Did find:\n\t/Library/Perl/5.8.8/darwin-thread-multi-2level/auto/DBI/DBI.bundle: no matching architecture in universal wrapper at /System/Library/Perl/5.8.8/darwin-thread-multi-2level/DynaLoader.pm line 230.\n at /Library/Perl/5.8.8/darwin-thread-multi-2level/DBI.pm line 263\nBEGIN failed--compilation aborted at /Library/Perl/5.8.8/darwin-thread-multi-2level/DBI.pm line 263.\nCompilation failed in require at /Users/Shared/Library/Perl/Test.pm line 12.\nBEGIN failed--compilation aborted at /Users/Shared/Library/Perl/Test.pm line 12.\nCompilation failed in require at /Users/Shared/Library/Perl/startup.pl line 14.\nBEGIN failed--compilation aborted at /Users/Shared/Library/Perl/startup.pl line 14.\nCompilation failed in require at (eval 2) line 1.\n
[Thu Aug 20 23:56:11 2009] [notice] Apache/2.2.11 (Unix) mod_ssl/2.2.11 OpenSSL/0.9.7l PHP/5.2.8 mod_perl/2.0.2 Perl/v5.8.8 configured -- resuming normal operations
[Fri Aug 21 00:44:36 2009] [notice] caught SIGTERM, shutting down
[Fri Aug 21 00:44:46 2009] [notice] Apache/2.2.11 (Unix) mod_ssl/2.2.11 OpenSSL/0.9.7l PHP/5.2.8 mod_perl/2.0.2 Perl/v5.8.8 configured -- resuming normal operations
Yep thats what we want to see.

But remember that this is only a workaround and not a fix. Any patches to Perl will possibly overwrite the change and so it will need to be made again. (unless Apple apply this change to their distribution)
So when you are building / installing modules pay closer attention to the compiling of any C files and make sure it contains all the architectures that you need.

Why use iWeb when I can code a site

Sun, 2 Aug 2009 10:10:25 +1000

My parents wanted to put together a website to show the work they’ve been doing on the farm. Since they have a Mac I had a quick play with iWeb and found it was very usable.
I showed my parents how to write up the site and publish it. A process that was a lot harder with older versions of iWeb.
A little while later my sister wanted to set up a website to put stories of her travels on for family and friends to read about. Again I recommended iWeb to her as she has a Mac and wanted to do things simply.

I’ve always written my websites by hand with my text editor of choice vi. This of course means that the development process is slow at first. Though with some of the site’s I’ve put together over time the process of adding new content has been very quick once a framework was put together.
Then came along the pressure of putting together a blog. I resisted the urge for until a month ago and decided move a little more with the flock.
But what product to use? I could do what I’ve always done and write it up from scratch. After some thinking and procrastination, mostly in an effort to put off writing a blog. I decided I should practice what I preach and use iWeb. After all, why shouldn’t I. I has all the editing ability that I’d need to put together a site and the overhead and constraints it puts on how the site is but together aren’t that bad. are they?...
Well my initial thoughts were that there were too many overheads with what iWeb compiled.
My initial complaint is that you can’t (yet) specify that you don’t want your website to be under a specific directory. There are ways around this however and you can pretty much make it work as you want.

Getting started... my first instinct was to start with a blank page and build it up as I wanted. This worked just as expected and the result was okay. Though I think it wasn’t as good as it could have been due to lack of motivation.
Step two... take a look at the existing templates...

The thing I like about using the in built templates when working on a page is that you can change to another template and your content is all changed.
The thing I don’t like about using the templates is that if you change to another template any text boxes and other objects that you’ve added to the page aren’t completely changed to the new template format.
For the moment at least the built in templates in iWeb have won me over.