OSNews

So what about packages you ask? Well OpenBSD 3.5 for SPARC64 does sport a new package for MySQL 4.0.18, so I set out to run sql-bench against that.

I ran into some problems, however.

Like many package management systems, OpenBSD packages have the concept of dependencies, where certain packages are required before installing other packages.

Installing the mysql-server required mysql-client. No big deal. But it also required a myriad of other semi-related packages, including p5-DBD-mysql-2.90.03, p5-DBI-1.38, p5-PIRPC-0.2017 and probably a few more.

I'm not sure why they were set as dependencies, as DBI and DBD are Perl modules that are only required when running Perl applications that utilize MySQL. The benchmark suite sql-bench requires them, but for the database server itself to run they are not required.

The frustrating part about this is that there doesn't appear to be a way to successfully force package installation to ignore dependencies. Using various combinations of the -f keys argument failed install the package.

I tried to install the required packages anyway, but I already had Perl DBI installed, so the package installation failed with the following complaint:

Dependencies for p5-DBI-1.38 resolve to: p5-PlRPC-0.2017
Collision: the following files already exists
        /usr/local/libdata/perl5/site_perl/sparc64-openbsd/Bundle/DBI.pm
        /usr/local/libdata/perl5/site_perl/sparc64-openbsd/DBD/ExampleP.pm
        /usr/local/libdata/perl5/site_perl/sparc64-openbsd/DBD/NullP.pm
        /usr/local/libdata/perl5/site_perl/sparc64-openbsd/DBD/Proxy.pm
        /usr/local/libdata/perl5/site_perl/sparc64-openbsd/DBD/Sponge.pm
        ...

I gave up on the package system and just untarred the tgz file and installed the binaries manually. It was a little tricky, but I got MySQL up and running, and I ran sql-bench against the 4.0.18 package.

The results were somewhat in line with the 4.0.17 version I compiled, although it performed worse in a few of the individual tests.

It looks like they creators of the package are aware of the --open-files-limit fix, as it was incorporated into the mysqld_safe startup script.

Other Odds And Ends

I also had an issue with my compiled PostgreSQL 7.4.2 from source and PostgreSQL 7.3.2 from ports where sql-bench would die from a bus error. However, I didn't try the package initially so I gave it a try. It also died with the bus error during sql-bench. So no joy there.

I noticed a couple of comments regarding X11, with several incredulous "of course it wouldn't work!" comments when I tried starting X11 from the serial console. That starting X11 from the serial console didn't work wasn't my point; I even stated it wouldn't work. My concern was that it actually crashed the system, instead of simply exiting with an error. While probably not a DoS tactic, it's definately not stable behavior.

Another comment sent my way was that OpenBSD doesn't actually listen externally on port 25 when sendmail is running; it's only running as an internal MTA. Yeah, sorry about that, dumb assumption on my part.

Conclusion

While the OpenBSD results didn't compare to well with the other SPARC64 operating systems performance-wise, it doesn't detract from its usefulness, especially as a firewall/router system. The test was only MySQL, and with MySQL running, it's all that much more of a useful system and would make a good development system in addition to a great firewall/router.