Blog of Echothrust Solutions

In a world that three operating systems dominate (Windows, Linux, MacOS) and alternative sounds weird we gave a run at OpenBSD as our operating system from end-to-end. The following document is the third part of a four part paper that describes how we managed to setup our entire company using only OpenBSD and its provided ports and tools.

We hope you enjoy the reading.

Introduction

In the past papers we described how our servers and workstations were configured. In the following paper we take a look at the development network, what kind of services were offered and how OpenBSD helped us setup a stable server farm for our needs.

Development Network

Granting, most workstations were quite well equipped, to handle development tasks (with virtual machines, local web servers, databases etc.), there were cases that this was not enough. For stress testing and security audit of our projects, we needed a central system that we were already familiar with its performance, that could easily be accessed by every developer.

Repository Server

The repository server was holding all the source code and even text documents. The repositories were under a Subversion server, although CVS would also serve us nicely. The reason we chose Subversion as our primary versioning system, was the fact that many of the hosting providers, we were working with, offered it as an option.

Note though, that we didn't limit our options. There was a CVS server running, that only a single developer had access to. Every major branch and release was imported on the CVS server for each project. We didn't mind so much about every little change that took place, but we wanted to be able, if worse thing happens (who knows), to switch as smooth as possible.

For web browsing of the repositories we used Trac and cvsweb from the ports. Although Trac is a bit heavy compared with alternative subversion interfaces, it offered an impressive integration with subversion, which we found very helpful. Furthermore, Trac provided a way to manage source code specific tasks at the same time which made it a clear winner.

Products Beta Testing

For our beta testing purposes we used a dedicated OpenBSD server running a clean installation of 4.1. Since our workstations were full of packages that we couldn't track (installing Firefox for instance, installs a large number of dependencies), we needed the system clean, in order to be able to verity that the entire process (installation, configuration, launch) of an application is in compliance with the current documentation.

Additionally, this system was serving as a beta testing machine for various applications (PHP mostly), that we wanted to test or approve. With the help of systrace, chroot-ed Apache and the documentation provided with OpenBSD, we were able to monitor and evaluate third-party applications with confidence and gain deep understanding of inner workings of the tested application.

After every test was completed, all packages were removed and verification that the system was intact was performed, with the nice mtree utility shipped with OpenBSD.

Database Server

In order to be able to test and run all those applications, many of which needed database or LDAP access, we used another OpenBSD system that had Postgres, MySQL and OpenLDAP installed from the ports. Despite all those services running at the same time, the system was not heavily used and OpenBSD performed without a hitch.

Overall

Overall, the development network did not differ from the previous configurations (back-end, workstations), however, the little bits and pieces of OpenBSD security made it worth of mention.

One of the little problems, known to most OpenBSD users, was the fact that a significant portion of applications that we attempted to test failed in compilation. There were three types of application problems that we encountered. Some of them we manage to overcome, others not.

• Application OS Specific. In cases that an application was specifically designed for a specific operating system, it was understandable that there will be some problems. Usually, applications that for some reason required the sources of the Linux kernel and such. Whenever, that happened we tried to locate an alternative more open project, even if that meant that we had to create large patch-sets.
• Application tweak. Other times the application was just fine, but certain header locations were different under OpenBSD so usually, we were able to overcome this problem with a bit of source code editing and command CFLAGS/LDFLAGS tweaking.
• Unknown errors. And of course, there were cases that we simply could not figure out what was wrong. Some applications were so badly written, or simply were so massive in code base, that trying to figure out what is being going on was simply too much of an effort.

The difficulties we encountered, could hardly be blamed on OpenBSD. For every application we needed, and was not existing under the ports, OpenBSD package maintainers provided an alternative, often much better and worth learning (such as LaTeX, back when Abiword and OpenOffice was not existing in the ports).