Operating Network Services Under OpenBSD06/27/2000
OpenBSD is first and foremost a secure server operating system, the key function of which is to provide encrypted, code-audited, and stable network services. After basic network parameters have been set (as explained in article 1 of this series), the next step is to install, configure, secure, and automate network services.
Unlike other open source operating systems, namely Linux and FreeBSD, OpenBSD draws a firm demarcation line between what is supported native software and what is third party contributed software. A full OpenBSD system comes with a few code-audited network services, such as SSHD, sendmail, and Apache. Other services are third party and must be installed using the ports tree mechanism. For this example, we will discuss building a server which needs to run Apache, sendmail, and pop3d (a basic Web/mail server). With Apache and sendmail already installed as part of the OpenBSD base, we need to install cucipop (a lightweight secure pop3 server) from the ports tree.
Step 1 (building the ports tree):Download the ports tree framework from:
Extract this from /usr, to provide a ports tree framework in /usr/ports. The framework is a directory structure populated with makefiles and configuration files, telling the system where to download each piece of software from, what configuration options must be parsed at compile-time and where it will eventually be installed. The ports tree is organized into logical categories, such as "net," "www," and "databases." Hence, the required cucipop directory is /usr/ports/mail/cucipop.
Step 2 (installing cucipop from the ports tree):
Begin the installation procedure by running the command "make" from /usr/ports/mail/cucipop. This first determines and subsequently builds any prerequisite software (in this case, none), downloads the source distribution of cucipop, extracts it into a temporary work directory, parses suitable compile-time options to cucipop, and builds a working binary. Complete the installation by running "make install," which places the binary, manual pages, and related files in the correct directories, followed by "make clean," which removes the temporary work directory to save space.
Step 3 (configuring the services):
Apache and sendmail both have comprehensive configuration files, while cucipop, as a simple lightweight service, does not. Starting with sendmail: The two main configuration files, sendmail.cf and sendmail.cw, reside in /etc. While this article does not attempt to be a sendmail configuration guide, we will touch upon sendmail configuration parameters. First, set up sendmail.cw by adding to it all hosts/ip addresses for which the server should receive mail.
/etc/sendmail.cw: mydomain.com mysubhost.mydomain.com 126.96.36.199
Secondly, configure sendmail.cf. This can be a very lengthy and detailed process, but for the purposes of this article, we'll stick to a simple configuration. Here we define an aliases file and tell the system to automatically rebuild the file each time sendmail is restarted. All other options can remain default.
/etc/sendmail.cf: # location of alias file O AliasFile=/etc/mail/aliases # automatically rebuild the alias database? O AutoRebuildAliases
Apache's default configuration is adequate for a demonstration situation, but in practice, users would most likely want to change small options such as the logging format or documentroot directory. Here we will leave it as default.
Step 4 (setting services to start at boot):
OpenBSD uses a BSD-style boot, as opposed to sysv runlevels, which Linux uses. This means that upon boot, after the kernel has loaded, the init scripts are run until complete and then the login screens are displayed. Under a Linux system, several runlevels are worked through, starting services and daemons in a set sequence. Most services are easily controlled from OpenBSD's RC configuration file, /etc/rc.conf. For these purposes, we'll need to include the following lines:
/etc/rc.conf: sendmail_flags="-bd -q30m" # for normal use: "-bd -q30m" # This line sets sendmail to start at boot with the # command line parameters "-bd -q30m" httpd_flags="" # for normal use: "" (or "-DSSL" after reading ssl(8)) # This line sets httpd (Apache) to start at boot with # no command line parameters. The -DSSL option refers to # using OpenSSL for https. inetd=YES # almost always needed # This line sets inetd to start on boot.
OpenBSD uses "inetd" (Internet Daemon) to control smaller Internet-oriented services. Now that inetd is set to initialize on boot, cucipop must be set up within inetd. This system has its own configuration file where cucipop must be configured, /etc/inetd.conf.
/etc/inetd.conf: pop3 stream tcp nowait root /usr/sbin/cucipop cucipop # Sets up cucipop to start on boot as a TCP scream service on the # pop3 port (110)
Step 5 (rebooting and testing):
It is a wise idea to reboot the server and test all services on the spot, rather than starting each one manually and presuming that it works after a reboot. Upon resetting the server, you should see the newly configured services start. After logging in, check that the processes are running:
bash-2.03# ps aux | grep sendmail root 13229 0.0 0.6 532 364 ?? Ss 6:55PM 0:03.86 sendmail: accepting connections on port 25 (sendmail)
Repeat this process for each daemon.
In summary, OpenBSD servers are not nearly as difficult to configure as some may say. There are many differences in the installation, configuration, and management of services between systems such as Linux and OpenBSD, but this does not make OpenBSD more difficult; if anything, it makes it more logical.
David Jorm has been involved with open source and security projects for several years, originally with OpenBSD and Debian GNU/Linux, now with the development team at wiretapped.net.
Discuss this article in the Operating Systems Forum.
Return to the BSD DevCenter.