This is a re-post of an old tutorial I wrote with some minor updates for more recent versions of OpenBSD.
One of the greatest challenges in migrating my server from a managed FreeBSD server to the new OpenBSD server was learning how to implement support for SASL on SMTP connections. This seems like something so elementary in a mail server that it should be really simple. Unfortunately, simply installing the cyrus-sasl package doesn’t handle the integration with sendmail for you nor is there any really good documentation online. I was particularly disappointed that OpenBSD’s documentation was completely silent on how to do it.
After searching online nearly all searches for SASL on OpenBSD were for Postfix. Fortunately I did come across an article on how to do it. While it was written for OpenBSD 3.3 nearly all of the steps also apply to 4.7 and later. You can find the original article here.
First we’re going to need to install the cyrus-sasl package. We’re going to be using the plain vanilla version which allows us to use OpenBSD’s Unix style authentication from /etc/master.passwd. There are other flavors for LDAP, MySQL, and db4.
Here we’ll choose option 1.
Next we want to let saslauthd (the Cyus SASL 2 daemon) know that it’s going to be working with sendmail and what types of authentication we want to support. This is done by creating a file called Sendmail.conf in /usr/local/lib/sasl2 like this. The cat command listed first allows you to enter the contents into the file without opening an editor such as vi.
# cat > /usr/local/lib/sasl2/Sendmail.conf
mech_list: LOGIN PLAIN
(hit ctrl-d to save)
There are other authentication methods than just LOGIN and PLAIN that you can use such as DIGEST-MD5 and CRAM-MD5 that you can also add on the second line of the file if you plan on using them. Since we’re using OpenBSD’s own authentication mechanism we’ll omit them from the line.
Before we forget, let’s add our startup script to /etc/rc.local to ensure that saslauthd is started with the server:
if [ -x /usr/local/sbin/saslauthd ]; then
echo -n ‘ saslauthd’; /usr/local/sbin/saslauthd -a getpwent
On OpenBSD 5.0 and later*, saslauthd will be started using the rc.d(8) mechanism. You will need to add the following line to /etc/rc.conf.local:
* Substitute “pkg_scripts” for “rc_scripts” if you’re using 4.9.
Worth noting here is that we are using getpwent(3) as our authentication method. This is basically just saying that we’re authenticating against /etc/master.passwd. Since saslauthd defaults to starting up 5 threads or processes each time it runs, we can limit this by adjusting the startup command with a -n option followed by the desired number of threads we want to limit to. This may be desirable on an older machine with fewer resources.
Recently I’ve had this really nagging issue where I could no longer send email from Roundcube. Mail would send just fine from any email client. A review of the mail logs for the failed message being sent from Roundcube gave a puzzling error about an unbalanced “< ” proceeding the recipient’s name with the email address. I did find that removing the person’s name proceeding the email address from the “To” line allowed me to send the message. Basically, removing the name when the field looks like this:
John Doe <firstname.lastname@example.org>
I tried playing around with a few things including re-installations of Roundcube and did a really thorough glean of my sendmail config files comparing them to the defaults. Looking through the MySQL database showed no extra angle brackets in any of the stored contacts. I did find a post on the Roundcube forums about the same error but for an older version. I tried messing around with some of the PHP files as the fix mentioned in the article was no longer applicable due to filename changes, but had no change in behavior. Thinking that perhaps there was some bug in the PHP code itself I tried installing later versions but I still got the same error about the message failing to send. I had no issues with the 0.3.x releases. This issue cropped up in the 0.5.x branch.
Finally on a hunch I began to suspect that mini_sendmail-chroot was the culprit. It turns out that I was exactly right. A search of the OpenBSD mailing list archives pointed me to a replacement called femail-chroot which was described as being less problematic. I tried it out and problem resolved! I’m not sure what it was about mini_sendmail that breaks with newer PHP scripts. Unfortunately, the project is apparently no longer maintained with the last release being from 2005.
Femail is basically a drop-in replacement for mini_sendmail. The only work involved is to just point PHP to it in your php.ini and restart Apache. You can install femail-chroot as a package (run pkg_add femail-chroot as root) or from ports (mail/femail). If you install it from ports please note that the chrooted version is available as a flavor.
Yes, it is true. The OpenBSD Journal has a very interesting article put together by one of the OpenBSD developers on how they’re using it in their business to not only build networks, but to switch office environments over to OpenBSD. It’s a very interesting read and speaks for itself on how versatile OpenBSD can be.
Want to add some color to your shell environment? FreeBSD and most Linux distros have color options included in the “ls” utility by default. OpenBSD doesn’t but but it’s very easy to add. We just need to install the “colorls” package (sysutils/colorls in ports).
# pkg_add colorls
Colorls works exactly the same as regular “ls”. To get the color option you just need to use the -G option. If you want it to replace “ls” for regular work you can create an alias in your favorite shell’s environment file. The output for file and directory listings will now have a different color for different types of files.
White = regular file
Purple = directory
Red = executable file
Magenta = symbolic link
White highlight = Set Group ID enabled
Red highlight = Set User ID enabled
Yellow highlight = Sticky bit enabled
Enjoy! Almost as good as getting the window seat at work.
It’s a long waged battle to get working Flash support on BSD. Most OpenBSD users either learn to live without it or try semi-working solutions such as gnash. On FreeBSD the support is somewhat passable using Linux emulation with a Linux binary version of Flash.
In yet another attempt to get Adobe to reconsider their position the PC-BSD team has put together a petition to get Flash for FreeBSD. Getting Adobe to see the growing number of BSD users is very important in making BSD more mainstream. Adobe has maintained Solaris support for Flash for a number of years. I think we’ve come a long way since Solaris was last a mainstream Unix desktop system compared to the number of desktop BSD systems there are now. If Adobe were to make Flash for FreeBSD I believe that it would be a fairly simple matter to get it to work under OpenBSD’s FreeBSD emulation mode.
Please take a moment to sign.
My favorite computer book publisher O’Reilly Media has announced a giveaway of $500 worth of their titles (print, ebooks, videos, etc.) that you choose. Here’s what I’d like to read this year:
The Book of PF 2nd edition
Mac OS X for Unix Geeks (Leopard), Fourth Edition
Mac OS X Snow Leopard: The Missing Manual
Practical UNIX and Internet Security, Third Edition
Unix Power Tools, Third Edition
Learning Perl, Fifth Edition
Learning the bash Shell, Third Edition
Classic Shell Scripting
Postfix: The Definitive Guide
The contest ends on February 22, 2011 at 11:59 PM PST. Good luck!
Development is being made in the CVS tree to implement RC scripts in OpenBSD which should be part of 4.9. Historically in true BSD fashion OpenBSD has used two rc scripts: /etc/rc and /etc/rc.local. The former being the default script read to start the OS and the latter to start any daemons that have been added to the OS such as MySQL. This also has served as a clean way of upgrading the OS since /etc/rc should never be altered.
The new change that I’m referring to will change this and put OpenBSD in line with the way FreeBSD and NetBSD have been doing things for quite a while with individual rc scripts for each daemon being placed in /etc/rc.d. I’m not sure how OpenBSD will implement this functionality. The way that it has worked on FreeBSD (I haven’t used NetBSD for any length of time to know how it works there) is that you start and stop daemons using the individual scripts. For example, If I wanted to restart sendmail on a FreeBSD system I would run this command:
# /etc/rc.d/sendmail restart
Pretty simple, huh? If I wanted to change how the daemon starts on boot with additional options I would add a line to /etc/rc.conf. This is also where I would tell my system to start foo daemon on boot such as:
Assuming that the implementation on OpenBSD will be similar this greatly changes having to add each script by hand to one big script in rc.local with all the startup options defined. I’m guessing that starting a daemon on boot would be defined in /etc/rc.conf.local.
Now the real question is, why now? Seeing as FreeBSD made the switchover years ago it’s definitely an odd time to change. I understand that adding new features to OpenBSD is much slower than on some other open source projects since the development model is a bit different with security and bug-free code being the highest priority. I’m curious if this is an effort to increase compatibility with the other BSDs and thus a way to bring new developers in, or simply a highly requested feature from system admins.
Update: With OpenBSD 4.9 currently being in beta the developers have added a section to the porting guide on openbsd.org.
We always hear how important backups are and the need to backup often. What’s the right tool to use? This will vary by your needs and how important your data is to you. I want to recommend a solution rooted in the BSD community called Tarsnap.
Tarsnap is a really easy to use command line utility that resembles the traditional tar(1) utility that we all know and love. It compresses the data that you want to backup and uploads it to an Amazon S3 storage server and keeps it encrypted. The cost is $0.30 per gigabyte. It works on a prepaid basis where you deposit funds into your account from which it draws when you transfer data. There’s a minimum $5 US deposit to start using it. The project is headed by the FreeBSD chief security office Colin Percival and the profits help fund the FreeBSD project.
Unfortunately, there’s no package or port for OpenBSD currently so you’ll have to compile it from source. Fortunately, this is super easy on a BSD system since all the necessary pieces are normally already in place unlike most Linux distros. Just to compare I compiled it on CentOS 5.5 and kept getting prompted to install additional packages like the installation instructions mention on the Tarsnap installation page.
There are a few caveats with building it on OpenBSD as opposed to FreeBSD. Mainly the location of the tarsnap.conf file and the man pages. Since the configure script is just detecting that it’s building on BSD it takes a few FreeBSD liberties such as placing tarnsap.conf.sample in /usr/local/etc instead of /etc. If you move the file to /etc the binaries will not see it. OpenBSD frowns on the use of /usr/local/etc due to the fact that /usr/local is commonly exported over NFS. The other gotcha is that the man pages are installed to /usr/local/share/man which does not exist by default on OpenBSD. This means you’ll need to make some adjustments in /etc/man/conf.
If you’re looking for easy and and cheap cloud storage I would strongly suggest that Tarsnap is the way to go. Being security conscious OpenBSD users we definitely can appreciate the Tarsnap approach to backups.
Update: I found a workaround for the issue I had with the files being put in a FreeBSD-like directory structure. When you’re running the configure script you just need to pass a couple extra arguments so that the files are put in the proper OpenBSD sanctioned directories like this:
# ./configure –sysconfdir=/etc –mandir=/usr/local/man
I recompiled Tarsnap and it worked like a charm without having to tweak /etc/man.conf or the like.
Update 2: There’s been some recent chatter on the ports@ mailing list about a tarsnap port.