OpenBSD Journal

Editors Blog - Looking Forward to 4.3

Contributed by jason on from the chasing-each-other-around-with-a-blunt-object dept.

The release of OpenBSD 4.3 is right around the corner. A group of Undeadly editors was overheard in IRC discussing their favorite new features. We've compiled their list here for you to review. Which are your preferred features, and do you have any unique uses for them?

Jason Dixon (jason), on snmpd(8) and simplified carp(4) load balancing...

The new snmpd in base is a blessing for those of us managing networks with OpenBSD. We currently have a dozen or so firewalls and VPN servers in production, and they all use net-snmp's snmpd. Net-snmp's configuration is usable, but unwieldy. I really appreciate the simplicity of this new snmpd implementation (along with snmpctl(8)), and am grateful for Reyk Floeter's (reyk@) hard work on this new feature.

I've been using carp(4) for years. It's an immensely useful feature and has saved my cookies numerous times. But one thing that's always been a minor inconvenience is setting up CARP load balancing. You'd have to create multiple interfaces with the same address, manage those hostname.carp* files, and make sure to get the advskew just right. While much of the underlying design hasn't changed, Marco Pfatschbacher (mpf@) recognized the complexity and made numerous changes to simplify usage. Rather than creating multiple interfaces with the same address, we can now just create a single carp interface and assign it multiple carpnodes with their respective advskews. This is a time-saver and should ease troubleshooting across CARP members.

Peter Hessler (phessler) is looking forward to the new Intel 2.2.0 Xorg drivers...

New laptop means new quirks and bugs to deal with. This time around, the biggie was the screen. Intel 965 with 4.2 defaulted to 1024x768, which defeated the purpose of me upgrading to the really nice screen. Poked around and I found a tool in ports that let me use the native resolution. Inelegant, because I couldn't dynamically resize my screen, use accelerated 2d, or other nifty features of X.

But then the 2.2 Intel drivers were imported, and all of that melted away. No need for 915resolution, the screen was natively supported. Changing resolutions is now as easy as changing my pants. Watching movies in mplayer is snappier, and uses less CPU. Connecting to a projector is as simple as running xrandr(1). Fitter, Happier, More Productive.

Paul Greidanus (paul) likes the new includes directive for pf.conf(5)...

The ability to include multiple files into pf.conf will aid greatly in complex PF rulesets. For example, an administrator can now have a single ruleset per network, rather then hundreds of lines in their primary pf.conf. Personally, I have a 550 line pf.conf in front of six interfaces filtering three class-C networks worth of IP addresses. Being able to distribute filtering logic and policies to dedicated ruleset files will ease administration and increase efficiency.

From pf.conf:

     Additional configuration files can be included with the include keyword,
     for example:

           include "/etc/pf/sub.filter.conf"

The include feature is useful for administrators who might otherwise use anchors, but wish to also store macros and tables in there as well. There's probably a lot of interesting uses for this that will be revealed as users adopt OpenBSD 4.3 in production.

Michael Erdely (merdely) talks about support for sshd(8) chroot and how svnd(4) devices now work on block devices...

I host a small mail/web server for family and friends. I've always wanted to provide a means for my users to manage their websites without giving them access to the whole system. Along with Match, AllowTcpForwarding, X11Forwarding, ForceCommand and ChrootDirectory (previously reported), I can provide the access I want without relying on FTP+chroot, FTP+ssl+chroot (w/ pure-ftpd), scponly, some systrace hack or some third party ssh hack.

Here's a quick list of steps I used to make ChrootDirectory work:

  • mkdir -p /var/www/sites/user1/home/user1/www
  • Add user1 to wwwusers in /etc/group
  • Add to /etc/ssh/sshd_config:
            Match Group wwwusers
            X11Forwarding no
            AllowTcpForwarding no
            ForceCommand internal-sftp
            ChrootDirectory /var/www/sites/%u
    
  • If using public-key authentication, copy authorized_keys file to /var/www/sites/user1/home/user1/.ssh and create a symlink to /var/www/sites/user1/home/user1 in /home.
  • Configure web server to point to /var/www/sites/user1/home/user1/www for user1's website.

Using /var/www/sites/%u ensures that user1 can only see user1's home directory. The lines in sshd_config also prevent ssh tunneling and X11 forwarding. To add more users, add them to wwwusers and create, for example, /var/www/sites/user2/home/user2/www.

For backing up my systems, I chose to use an external USB disk with Bacula to store the monthly full backups. I'll take that disk off-site during the month while incremental backups are stored on a local disk. Because I'll be storing my USB disk offsite where others may have access to the drive, I want to encrypt the disk:

  • sd0a already exists, is empty and takes up the entire disk
  • Create the encrypted "disk": vnconfig -ck svnd1 /dev/sd0a
  • Partition the encrypted "disk": fdisk -i svnd1
  • Create a disklabel on svnd1 (I used the whole disk for a)
  • Format the disk: newfs -O2 /dev/rsvnd1a

Lastly, I mount /dev/rsvnd1a as /usb and configure Bacula to use File Media Type storage in /usb.

Janne Johansson (jj), on large filesystem (>2TB) support and spinlock improvements for SMP arches...

I like the incremental way support has been added in order to support large (2TB) file systems. The way is has been done at other places seems to me to have included far too much bridge-burning decisions and handling the inevitable fallout, whereas the OpenBSD devs in this case made neat step-by-step evolution even when the results weren't visible in order to finally reach a point where all parts simultaneously support really large file systems and small file systems beyond the 2+ TB boundary.

OpenBSD 4.3 will have spinlock improvements for SMP arches. This one, even though it might not be the shocker of the century, is one of my favourites. Sometimes, someone decides not to go for the sexy stuff but rather dig into one particular hot spot and comes out with a performance improvement no one knew was to be found. So for this point, looking at how the SMP system behaves while spinning (which of course is a major point for kernels that don't have fine-grained locking yet) gives us a neat boost while waiting for non-biglocked kernels. The fact that the improvements are good and usable for all the current SMP platforms also adds bonus points in my book.

Johan M:son Lindman (johan), on ACPI and sparc64 SMP

ACPI is as of the 4.3 release turned on by default. This means that a fair amount of newer computers that would previously require manual configuring by means of UKC or config will now "just work". As with most large changes acpi(4) is still a tad rough around the edges but the fundamental pieces are in and this should make it easier for developers to further extend and add features to it. One much anticipated feature will be suspend/wake, it is not yet working so a lot of OpenBSD laptop users will be looking forward to this being added in the future.

Sparc64 gained SMP support in time for 4.3 and this is something many of us have been waiting for a long time, so here it is, go throw it at all your SUN UltraSPARC gear out there and report back if you encounter problems.

(Comments are closed)


Comments
  1. By glthornberry (glthornberry) gerald@thornberry.net on

    This makes for a really good read. I hope you'll post more editor summaries in the future.

    My needs are simple this release, but merdely's comments have me intrigued. For now, I'm already enjoying the new bwi driver for the Broadcom 4318 in my HP L2005CL notebook. Works great! I'm glad I won't have to plug in a USB receiver any more. I'm looking forward to the ACPI changes, too. Thanks for the hard work.

  2. By Anonymous Coward (63.107.91.99) on

    Curious, do these editors reside in a public IRC channel, or a private one just for editors? I enjoy idle/tech chatter about OpenBSD, and am curious about such a forum.

    Comments
    1. By Paul (129.128.68.27) on

      > Curious, do these editors reside in a public IRC channel, or a private one just for editors? I enjoy idle/tech chatter about OpenBSD, and am curious about such a forum.

      Many people are on #openbsd on irc.freenode.net, including a few of the devs.

  3. By Venture37 (venture37) venture37<A>hotmail.com on www.geeklan.co.uk

    Just received tracking info for my CD from wim via ups. Cant wait! :)

  4. By Anonymous Coward (216.68.192.45) on

    Very happy that OpenBSD continues to evolve in making things great, simpler, and secure.

    While my IT needs are very simple now, learning viable tools that will should still be around and evolving is priceless. Compare that to those who went all out learning FW-1. I bought a book on Iptables in 2002, GRR, thankfully I went to OpenBSD, rather than Linux. Thank god OpenBSD pf, et all, allows a set and ~forget, solid system, compared to Microsoft and others.

    Large disk support is something I am happy is here, although my data needs still are well supported by FFS, < 1TB, although that is changing as I'm learning the skills of data mining / preprocessing of lots of files.

    Comments
    1. By Anonymous Coward (24.37.242.64) on

      > Very happy that OpenBSD continues to evolve in making things great, simpler, and secure.
      >
      > While my IT needs are very simple now, learning viable tools that will should still be around and evolving is priceless. Compare that to those who went all out learning FW-1. I bought a book on Iptables in 2002, GRR, thankfully I went to OpenBSD, rather than Linux. Thank god OpenBSD pf, et all, allows a set and ~forget, solid system, compared to Microsoft and others.
      >
      > Large disk support is something I am happy is here, although my data needs still are well supported by FFS, < 1TB, although that is changing as I'm learning the skills of data mining / preprocessing of lots of files.

      Linux? What's that?

      Comments
      1. By Anonymous Coward (217.22.88.121) on

        > Linux? What's that?

        Its amazing, inconsistent as fuck, no logic/justification for anything & useless documentation/man pages to boot, start here for more insight:
        http://marc.info/?l=openbsd-misc&m=120769546120760&w=2

        Comments
        1. By Anonymous Coward (217.22.88.121) on

          As Marco P pointed out:
          http://web.archive.org/web/20061004200708/http://www.funroll-loops.org/

          Comments
          1. By Nick Holland (68.43.113.17) nick@holland-consulting.net on http://www.openbsd.org/faq/

            > As Marco P pointed out:
            > http://web.archive.org/web/20061004200708/http://www.funroll-loops.org/

            new site:
            http://funroll-loops.info/

            Nick.

            Comments
            1. By Anonymous Coward (71.162.20.124) on

              > http://funroll-loops.info/

              This reminds me of the Gentoo/FreeBSD project:
              http://www.gentoo.org/doc/en/gentoo-freebsd.xml
              The project has the "goal of providing a fully-capable FreeBSD operating system featuring design sensibilities taken from Gentoo Linux"!

              Comments
      2. By Anonymous Coward (68.150.143.243) on

        >
        > Linux? What's that?

        It's another kernel, but it has smp support out to hundreds of cpus, memory past 4Gb, wpa/wpa2 support, high performance graphics.. crappy networking, and the code's insane, but who's perfect.

        Comments
        1. By Janne Johansson (82.182.176.20) jj@inet6.se on .

          > >
          > > Linux? What's that?
          >
          > It's another kernel, but it has smp support out to hundreds of cpus, memory past 4Gb, wpa/wpa2 support, high performance graphics.. crappy networking, and the code's insane, but who's perfect.
          >

          Sounds like Vista. One can safely assume I need the specs above just to boot it.

        2. By phessler (phessler) on first undead, then not, then undead again.

          > >
          > > Linux? What's that?
          >
          > It's another kernel, but it has smp support out to hundreds of cpus,
          > memory past 4Gb, wpa/wpa2 support, high performance graphics.. crappy
          > networking, and the code's insane, but who's perfect.
          >

          tried wpa support. failed in hilarious ways. ended up plugging in an ethernet cable.

          high performance graphics. oh yea, kernel panics. thank you binary blob drivers.

          linux is adorable and all, but I like being able to use my system and not fight it.

          Comments
          1. By Anonymous Coward (151.188.18.43) on

            > tried wpa support. failed in hilarious ways. ended up plugging in an ethernet cable.
            >
            > high performance graphics. oh yea, kernel panics. thank you binary blob drivers.
            >
            > linux is adorable and all, but I like being able to use my system and not fight it.

            That solid SMP support is why we currently run Nagios and NMIS on Linux systems. That, and the fact that it is Free Software (at my insistence, we don't run blobs on our Linux boxes).

            As OpenBSD improves its SMP performance, I'd certainly welcome doing an NMIS deployment on it. I've used it since 2.8 and have always liked its premise of security and correctness.

            As for networking in Linux being "crappy," I find that it actually works rather nicely. Of course, I'm speaking from the perspective of a systems engineer, not a kernel hacker, so my perspective may be somewhat different from others here. Wireless, for me, "just works."

            One thing I wish would stop is this "mine's better, yours 5uxx0rz" junk that I see here on this forum and others. It's not at all productive.
            "Linux" isn't your enemy, and you're certainly not Linux's. What Microsoft and Apple represent *are* our mutual enemy.

            --TP

    2. By Terrell Prude' Jr. (151.188.18.43) tprude@cmosnetworks.com (this is a spamtrap address) on http://www.cmosnetworks.com/

      > Very happy that OpenBSD continues to evolve in making things great, simpler, and secure.
      >

      You, me, and a whole bunch of others. The dev team does great work.

      > While my IT needs are very simple now, learning viable tools that will should still be around and evolving is priceless. Compare that to those who went all out learning FW-1. I bought a book on Iptables in 2002, GRR, thankfully I went to OpenBSD, rather than Linux. Thank god OpenBSD pf, et all, allows a set and ~forget, solid system, compared to Microsoft and others.
      >

      I used to work with Check Point's products. I found them to be not just crap, but also backdoored.

      As for iptables vs. PF, I come originally from a Cisco background, so learning iptables and PF syntax was rather easy for me. I like and use both of them. While I think I understand why PF uses the "last matching rule wins" method, I prefer the "first matching rule wins" method, and I nearly always use the "quick" keyword for that reason. I like that the option for either way is present.

      One thing I like a lot about iptables is that I can tarpit not just SMTP as PF/spamd does, but also any other service. I use this to annoy SSH attackers, just like I do with spamd on OpenBSD. :-) I also have this on a friend's Web server in the case of a DoS attack (too many connections in a certain time period on TCP 80, you get tarpitted for an hour). Defense in depth--it's very effective.

      Linux makes a fine, full-featured packet filter. So does OpenBSD. I'm glad for the existence of both of them.

      --TP

      Comments
      1. By Brad (2001:470:8802:3:216:41ff:fe17:6933) brad at comstyle dot com on

        > One thing I like a lot about iptables is that I can tarpit not just SMTP as PF/spamd does, but also any other service. I use this to annoy SSH attackers, just like I do with spamd on OpenBSD. :-) I also have this on a friend's Web server in the case of a DoS attack (too many connections in a certain time period on TCP 80, you get tarpitted for an hour). Defense in depth--it's very effective.

        You can easily do that with PF as well.

        Comments
        1. By noob,obviously (24.68.188.52) on

          > You can easily do that with PF as well.

          I, for one, would love an expanded version of that comment. Commented code, not "Y o u c a n e a s i l y..." :)

          I'm just getting around to putting an OBSD box on the wild wild web this weekend, and would love some examples to work with. But on the other hand, is it possible to whitelist a tarpitted IP if it's a NAT box or cache engine (assuming you can get that information)?

          Comments
          1. By Mike Erdely (merdely) on http://erdelynet.com/

            > > You can easily do that with PF as well.
            > 
            > I, for one, would love an expanded version of that comment. Commented 
            > code, not "Y o u  c a n  e a s i l y..." :)

            Start with the documentation. Search for "bad_hosts".

            > I'm just getting around to putting an OBSD box on the wild wild web this 
            > weekend, and would love some examples to work with. But on the other 
            > hand, is it possible to whitelist a tarpitted IP if it's a NAT box or 
            > cache engine (assuming you can get that information)?

            One thing to learn right away is that OpenBSD's documentation is excellent. Between the man pages and the FAQ, you get most of the information you need.

  5. By Rob (2001:610:64b:6:217:31ff:fe26:9760) on

    Are there plans to expand the 'include' directive in pf.conf so rulesets can be loaded/unloaded by using pfctl just like anchors ?

    This way (generic) rules recipes can be created and loaded/unloaded when needed. For this functionality i am know using anchors, but what is miss in anchors is the 'macros' functionality

    Regards Rob

    Comments
    1. By jason (jason) on http://www.dixongroup.net/

      > Are there plans to expand the 'include' directive in pf.conf so rulesets can be loaded/unloaded by using pfctl just like anchors ?

      What's so difficult about commenting out the include and running pfctl -f /etc/pf.conf?

      -J.

      Comments
      1. By Rob (80.127.105.250) on

        > Are there plans to expand the 'include' directive in pf.conf so rulesets can be loaded/unloaded by using pfctl just like anchors ?
        >
        > What's so difficult about commenting out the include and running pfctl -f /etc/pf.conf?
        >
        > -J.

        Nothing, but commenting out include directives and reloading a the complete ruleset does not lend itself to scripting whereas with anchors recipes can be remotely enabled/disabled via ssh

        Rob

    2. By henning (80.86.183.226) on

      > Are there plans to expand the 'include' directive in pf.conf so rulesets
      > can be loaded/unloaded by using pfctl just like anchors ?
      > This way (generic) rules recipes can be created and loaded/unloaded when
      > needed. For this functionality i am know using anchors, but what is miss
      > in anchors is the 'macros' functionality

      no, that is what anchors are for.
      includes are processed at load time.
      in your case, put your macros in some file (say, /etc/pf/macros.conf) and use
      include "/etc/pf/macros.conf"
      in each of your anchors.


Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]