Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
OpenBSD 5.1 released (openbsd.org)
112 points by hackermom on May 1, 2012 | hide | past | favorite | 38 comments


I love OpenBSD and have 5.0 installed on a router. But man they are old-school. Just looking at the upgrade instructions[1] brings me back to the time before package managers and makes my long for a nice "apt-get update && apt-get dist-upgrade".

[1] http://www.openbsd.org/faq/upgrade51.html


The last successful ubuntu upgrade I did was 10.04 (9.10 on my laptop), I think. 10.04 - 11.10 all broke (on multiple computers, in different ways) eventually requiring a liveboot and significant skill. (I'm now running arch, with significantly better results - but not perfect.)

I've never had an openbsd upgrade break, even when I do it the ninja way (which I often do, being a reckless fool).

Despite the longer setup time, I've found that openbsd servers end up needing far less maintenance than any others. It works well as a "fire-and-forget" operating system, a quality that seems to be lacking among the larger players.

(EDIT: not disagreeing that apt-get, yum, and pacman/yaourt are nice. Just talking about how awesome OpenBSD is.)


Note that apt-get isn't a supported way to upgrade in Ubuntu. You are supposed to use "do-release-upgrade" (or "Update Manager" in the GUI).


do-release-upgrade is how I did it - but it really just does apt-get underneath.


Awesome, isn't it. It's transparent and works every time. Not something you can say about apt-get...


"Awesome", yes. It's also going to take about an hour of my full concentration to accomplish. That's also not something I can say about apt-get...


The upgrade procedure takes but minutes in itself. The time you take to save and then write your old configuration files back to /etc and whatnot is on your hands :) Sure, upgrading OpenBSD's core system files isn't as smooth as doing it on f.e. FreeBSD via its package manager, but it's definitely not about hours.


It is in my experience.


I think Theo actually encourages clean installs. It's no surprise the upgrade procedure would leave something to be desired.


one thing to definitely watch in OpenBSD is their new mail daemon, OpenSMTPD. It has a configuration syntax that is about 100x easier to setup and understand than anything else out there, although they are still working to get it up to par feature wise. The code is also written with a heavy focus on security, correctness, and simplicity.

Its definitely something to watch for all those hackers that want an alternative to gmail that isnt the insanity of a postfix/qmail setup.

           listen on em0
           map aliases { source db "/etc/mail/aliases.db" }
           accept for local deliver to mbox
           accept for all relay
Thats all you need for a working mail setup :)

http://opensmtpd.org/


I don't think configuring e.g. postfix is that difficult:

    #
    # /etc/postfix/main.cf
    #
    # disable diff service
    biff = no

    # TLS parameters
    smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
    smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key
    smtpd_use_tls=yes
    smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
    smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache

    # disable warnings about NIS on mail delivery (default adds nis:mail.aliases)
    alias_maps = hash:/etc/aliases

    # do not grant special privileges to hosts except localhost
    mynetworks_style = host

    #set the mailbox size to limit to `unlimited'
    mailbox_size_limit = 0

    myhostname = fulla.mrothe.de
    mydestination = $myhostname, localhost.$mydomain, localhost,
                    mrothe.de

    mailbox_command = procmail -a "$EXTENSION"
And on a backup MX instead of adding your domains to `mydestination` you just set:

    [...]
    
    myhostname = blei.mrothe.de
    #don't touch mydestination, which defaults to "$myhostname, localhost.$mydomain, localhost"

    # accept mail for these domains to be relayed
    relay_domains = $mydestination, mrothe.de


I agree it's not that difficult and prior to OpenSMTPD I've been a user of Postfix for 10 years, so I know the software is good and far easier to setup than the big S. ;-)

However, here's a better example of a configuration that is simple with OpenSMTPD and slightly more complex on others:

    listen on em0 tls cert "mycert" enable auth
    map "vmap" { source plain "/etc/mail/virtual" }
    accept from all for virtual "vmap" deliver to maildir
    accept for all relay
This will have the daemon listen on all addresses of interface em0 (both IPv4 and IPv6), it will enable STARTTLS using certificate "mycert" and activating authentication for system users (no pop-before-smtp, no cyrus-sasl and whatnot). It will accept mail from anywhere for all virtual domains in the mapping "vmap" and deliver to maildirs, while relaying mails from local users to the world.

That is a fairly basic setup that quite a lot of people use, yet the effort required to achieve similar setup on other software can range from just "slightly irritating" to "extremely painful". Here it's done with 4 lines that are almost readable by someone who has never used the software.

Some other features like relaying through remote MX that require auth; tagging; forcing secure channels; allow more complex setups while retaining the same simple syntax.

/!\ warning: as a major contributor to OpenSMTPD, I'm biased ;-) /!\


Thank you. That is indeed easier to set up on OpenSMTPD than on Postfix.


Two nitpicks: you don't need to set myhostname; many mailservers will think you less spammy if your hostname is mail.$mydomain.


Thank you, but I set it, because myhostname is "fulla.localdomain" if I don't set it.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=214741


Which goes to show that you can still get it wrong after verifying locally (hostname typically does return a FQDN on OpenBSD)...


> accept for all relay

If this defines an open mail relay, please think twice because your machine may be used to send spam and get blacklisted.


nope, by default rules have "safe" implicit behavior:

accept for all relay -> accept from local for all relay

to create an open relay one has to explicitly:

accept from all for all relay


Let's hope that it does not end like: http://www.opencvs.org


The folks working on it are making pretty good progress and took in some donation money early in its existence.


They sometimes take on too much. They are very ambitious.


How did that end?


"OpenCVS is to be released soon." since 2004


I'll be giving this ago. Last time I set up a mail server I came pretty close to tears.


People still use qmail? I thought the more rational sendmail alternatives had gotten alot more traction?


I wish I could go back to using it but I currently have to do some GWT dev and they only officially support linux. I tried running a vm and dual boot but that was too much hustle... as soon as I'm done with this project I'll go back to this distro. :)


So far so good on this upgrade. Like all the recent versions I would seriously look at the changes to pf.conf. It seems like taking advantage of some of the new stuff would be in order.

Also, smtpd seems to be coming along nicely.


- NAT64 support in PF using the af-to keyword.

Sounds really interesting.


So what really sets the various BSDs apart? Has anyone done a good comparison between them?


There's a wikipedia page with tables of differences: https://en.wikipedia.org/wiki/Comparison_of_BSD_operating_sy...

In my opinion: OpenBSD - Focused on security above all else. Host project of OpenSSH and pf/carp/altq?. Lags behind on architecture support and performance (Previously poor SMP performance?). Primary use: Router/firewall.

FreeBSD - All around features and performance (zfs,dtrace,pf,linux syscall emulation layer). The most popular, and I believe has the most development effort. Popular freebsd derivatives: pfSense (firewall appliance), FreeNAS (zfs storage appliance), PC-BSD (packaged up for an easier desktop experience). Primary use: Desktop/server/firewall/storage/database.

NetBSD: Focused on architecture support. Supports 57 platforms/15 processor architectures: http://www.netbsd.org/ports/. Primary use: support on embedded/uncommon hardware.

DragonFlyBSD: Interesting technologies being developed: HAMMERfs (compare with zfs), application snapshots, virtualized kernel. Matt Dillon's fork of FreeBSD adding the spirit of AmigaOS. Primary use: Compute clusters?


This is actually a good summary, but it's missing the reason for the DragonFlyBSD fork: light-weight kernel threads. But yes, they've been doing a lot of work around clustering and performance in general.


FreeBSD is the one you should run. It has the best performance and hardware/software compatibility of the three. It's the easiest to get off the ground with for a beginner as well, so it's also a good starting point.

NetBSD is the one whose source you should study. The emphasis is on correctness and portability. The book Code Reading by Diomidis Spinellis used mainly examples from NetBSD even though he is a FreeBSD developer, because (he implies) the code is easier to read.

OpenBSD forked first and developed a reason to exist second; its storied past is really quite an interesting read, but won't leave you feeling like it is being developed by the greatest minds in security for exactly that purpose. I think its secure reputation is more fiat than fact and I'd like to see recent benchmarks substantiating the notion that it is better to run on routers and whatnot. I have no use for it.


One reason to run OpenBSD: pf/altq and OpenBGPD/OpenOSPFD are mostly developed there, and the other BSDs tend to have older versions.


NetBSD is the one whose source you should study.

Why not OpenBSD?


Because NetBSD's first priority is clean and correct code and it is often used for exactly this purpose.


Have you seen OpenBSD code? It's no less cleaner, and maybe even better in this regard.


Have you seen FreeBSD/NetBSD code? It's no less secure. :)


I actually rather like Wikipedia's page on the three - particularly the matrices of different options for the different BSDs.

http://en.wikipedia.org/wiki/Comparison_of_BSD_operating_sys...




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: