Porting the Hiawatha server to Haiku

Haiku (the operating system) has included with it a web server (called “poor man”). It’s Ok for what it is, but I wanted a little more horsepower for some projects I’m working on. I decided to port the Hiawatha server to Haiku. (Note: Haiwatha is at: http://www.hiawatha-webserver.org).

My idea was to nudge the port maintainer for php on Haiku to include php-fpm in the package, then port a database of some sort, and finally  get the Zoneminder application (a video camera monitoring app)  to run on Haiku, while realizing that there are no guarantees.  Lacking a good result with the camera app, I can always use the increased horsepower of Hiawatha to run WordPress.

The first requirement included obtaining the cmake and libxslt packages for Haiku. That was done relatively easily with the pkgman utility:

  • pkgman install cmake_x86
  • pkgman install libxslt-devel

I downloaded the source for the server thusly:

After unpacking the tarball, I added the network library to the CMakeLists.txt file at the top of the source tree.  This can be done by inserting the library name into the “target_link_libraries” statements in that file.  Otherwise, Cmake will not link the network library on Haiku (which is relatively unique in the use of that library name).

A small change was necessary in src/hiawatha.c, to fix the undefined RLIMIT (resource limit) around line 807 IIRC.  In the ~/hiawatha-10.6/config.h.in is a reference to ENABLE_CHALLENGE_ON.  This is a feature of Hiawatha that helps protect against DDos attacks.  It requires a working random number generator, so I’ve temporarily disabled this feature in my port.  Haiku has an RNG (apparently), but I haven’t taken the time to see exactly how it has to be integrated by third party software.  Without the RNG, the server software will compile, but break when it executes.  I’ve temporarily “commented out” the ENABLE_CHALLENGE_ON option in config.h.in, since for my off-net purposes I’m not worried about the lack of challenge.  But, someone who needs better security and DDos defenses, or who puts the server on the real internet, SHOULD ensure the needed RNG access code is integrated into the server source, and that the challenge works.

Then, from home …

  • mkdir ~/hiawatha
  • cd ~/hiawatha-10.6
  • setarch x86
  • mkdir build
  • cd build

Finally … I executed cmake:

cmake -DENABLE_TLS=off -DENABLE_IPV6=off -DCONFIG_DIR=/boot/home/config/settings/hiawatha -DCMAKE_INSTALL_PREFIX:PATH=/boot/home/haiwatha ../

And then, “make install” …

Note that I excluded TLS and IPV6.  TLS requires quite a few additional changes to the source code, and my app doesn’t require SSL anyway.  I included an alternate installation directory (~/hiawatha), so that I could create a package easily after the build was complete.  And the /boot/home/config/settings/hiawatha directory seemed a convenient configuration directory on Haiku for the hiawatha.conf file.  Note that the config directory doesn’t yet exists, but the HPKG package that I build will contain a script to create it at installation time.

“Make install” did its job, and so it remained only to package the webserver as a HPKG package for the Haiku OS.

How does one do that, exactly?

There are at least two methods:

  • Use HaikuPorter
  • Use the “package” command line utility

I have looked at HaikuPorter, and it seems to have a decent learning curve.  So, I opted for the command line utility.  Is that lazy?  Probably.

The basic deal is this:

  • Create dir with the Haiku directory structure, and populate it with the app
  • Create a .PackageInfo file, and put it at the top of the just created dir tree.
  • Run “package create -C name-of-directory-just-created-haiku-dir-tree”

So, in my case, that was:

  • package create -C ~/hiawatha

Because I’d made the ~/hiawatha directory my installation target during the build process, the app was in ~/hiawatha.  Note that the directory structure in the created package directory doesn’t go all the way up to root.  The structure should be created “as if” one were inside of /boot/system or /boot/home/config/.   This allows the package to install in either place (system or user).  So, for my port of the server, inside the ~/hiawatha dir I now have:

  • bin
  • boot
  • data
  • documentation
  • lib
  • var
  • .PackageInfo

But, the build process had created the following directory structure, since the server was designed for the *nix world:

  • bin
  • sbin
  • lib
  • share

I copied

  • sbin/* to bin
  • share/man/man1 to documentation/man/man1/

Then, I deleted the share and sbin directories, leaving the directory structure shown in the first list.  In the data/settings/hiawatha directory I have all the hiawatha configuration files, including hiawatha.conf.  A script that I put inside of boot/post-install/setup-hiawatha.sh copies these config files over to /boot/home/config/settings/hiawatha when the package is installed.  This has to happen because I pointed the build to use the latter directory for configuration files.  It is easily writable by the user, unlike the system directories. Note that my port is intended to be installed in the system directory.

In order for the boot/post-install/setup-hiawatha.sh script to be executed, there has to be a line defining this action in the .PackageInfo file.  In my case, the .PackageInfo line looks like:

post-install-scripts {

The .PackageInfo file seems to be a little picky. Or, I should say that the software interpreting the .PackageInfo file is a little picky. There are a dozen or so other entries that must be made in this file, for the package to behave itself. I’ll get to those in a while …

My setup-hiawatha.sh script creates the “htdoc” (WebsiteRoot) directories for the web server, as well as the logging directory, pid dirs, and so forth. I wasn’t sure where I wanted to put these, so I ended up temporarily putting them in my home directory. Well, Haiku is not really multi-user yet, and I’m the only user, so I guess it’s alright. The script also creates /boot/home/config/settings/hiawatha before it copies the original configuration items from data/hiawatha/* to that user config directory.   I modified the data/hiawatha/hiawatha.conf file to contain a WebsiteRoot= statement that points to the correct directory in my home.  Probably I should move the WebsiteRoot directory to /boot/home/config/data.  Seems reasonable.

Read More …

FWIW: the author does not make any claims as to the accuracy of statements in this document.  Much of it has been taken from memory. 

Note: Hiawatha is hosted at https://www.hiawatha-webserver.org, and this site and author has no affiliation with them. Also, Haiku-OS is an operating system at http://www.haiku-os.org, and this site and author has no affiliation with them.