A lot of work has been done on
ipsecctl, and it now completely supersedes
ipsecadm. What features does it offer?
ipsecctl(8) features an intuitive configuration syntax, similar to
pf(4), and sensible defaults. Our motto was that "IPsec should not be an enigma that is only usable by the ultra elite." In addition to ESP tunnels,
ipsecctl(8) now allows setting up AH, transport mode, and also over IPv6--the full gamut of IPsec, everything you could do with
ipsecadm(8), but in a more accessible manner.
ipsecctl(8) will take care of configuring
isakmpd(8) for you, making dynamic keying as simple as static setups and eliminating in virtually all cases the need for a cumbersome
isakmpd.conf(5) file. Dynamic IKE support and USER_FQDN IDs have been added for the benefit of roaming users. The documentation has been overhauled with an eye towards explaining the most common setups at the beginning. It has been our goal to make setting up an IPsec gateway with OpenBSD as painless as a filtering firewall.
sasyncd(8) has been better integrated with
carp(4), providing for robust IPsec failover.
What's new in bioctl and storage drivers?
David Gwynne: We've actually had a surprisingly large amount of work on storage in this release. For starters the behemoth that is pciide has had support for the following chipsets added:
- ATI IXP300 SATA, IXP600 IDE
- Intel 6321ESB IDE/SATA, 82801G SATA, and 82801H SATA
- IT Express IT8211F IDE
- NVIDIA MCP61 SATA, MCP65 SATA
- Promise PDC205xx SATA
- ServerWorks SATA
- VIA VT8237A SATA
One of the more fun additions in this release (in my opinion) is the new sdmmc support that Uwe Stuehler did. I think it's fun because he's completely emulating SCSI in the driver for the flash cards you plug in. Because of that he didn't have to write his own block device support since it just piggybacks the /dev/sd devices. It also means that the flash cards automatically take advantage of the work that has been done in the SCSI midlayer for hotplugging. It only took about 500 lines of code to make all that work. My guess is he'd need several thousand lines of his own code to do the same thing without the SCSI emulation.
For those of you who are in need of some more serious hardware for your storage needs, we have three brand new SCSI/RAID drivers:
mfi(4): LSI Logic MegaRAID SAS controllers
arc(4): Areca SATA RAID controllers
mpi(4): LSI Logic Fusion-MPT controllers
mfi is the successor to the ami controllers, and to be honest it does improve on the older generation quite a lot. Also, from what I can tell, Marco Peereboom managed to write the driver before any hardware was realistically available for purchase.
arc(4) driver was written after I had asked for ciss controllers to work on and someone sent me one in case I got bored with ciss. Instead of getting bored with ciss I got a bit distracted with arc. This hba has the simplest code path for performing IO that I have ever seen. If anyone is looking for hardware that performs well and has a reliable driver, I have to recommend this one because of its simplicity.
mpi(4) is actually a replacement for the
mpt(4) driver. The mpt driver suffered several problems. The most annoying was its size and complexity. It was about 10 thousand lines of code spread over half a dozen files, which in turn made it hard to deal with other problems it had. For example, the old mpt driver doesn't support SAS hardware (only SCSI and Fibre Channel, and the FC stuff extremely poorly), it wasn't 64bit or endian clean, its bus_dma usage was borked, and it was lacking support for proper use of RAID volumes. I decided it would be easier to write a driver from scratch than to pull mpt apart, clean it up, put it back together again in a sane fashion, and then add support for the SAS hardware and fix RAID on it. So I spent most of c2k6 working on mpi, and now we have a driver that is about a third of the size of mpt, runs perfectly on any machine with working PCI, supports more hardware, and works with RAID volumes.
bioctl itself hasn't changed that much in this release, i.e., the userland tool looks the same as it did in the last release. What's new is the fact that there are now four drivers in 4.0 that support bioctl. In 3.9 and 3.8 we only had support in
ami(4) but now we add
ciss(4) to the list. This is cool because it validates what we've been saying all along: RAID controllers don't need magical vendor tools to be manageable. For the tasks that people care about it is possible to provide a generic tool to do them with, and we prove it in 4.0.
pciide(4) now supports a lot of new chipsets made by NVIDIA, ATI, VIA, Promise, and others. How did you develop these drivers? Did you have any problem getting documentation?
Jonathan Gray: For most of the chips they act in a rather similar manner to either older revisions or other chips so it is mainly a matter of matching on new devices. The additional Promise support came from NetBSD with some further changes; it still needs quite a bit of additional work before it is really solid though. NVIDIA and ATI don't release standalone SATA/IDE chips, they release them as part of other south bridge chips that integrate a variety of slower IO devices. Getting documentation on NVIDIA/ATI/SiS/ULI south bridge chips is near impossible from what I can make out. Promise/Highpoint do not release documentation on their chips either, but at least the motherboard chipset manufacturers are slowly moving to a common interface (AHCI).
What advantages does the use of PKCS #5 PBKDF2 provide while generating keys with
Ted Unangst: PKCS #5 PBKDF2 is a method to turn a user's passphrase into a secure key. Previously, whatever passphrase the user entered was used directly as the key. This opened the door for a number of attacks. For instance, someone could precompute how a block of all zeroes would encrypt with every word in the dictionary.
-K option fixes this in two ways. First, the passphrase is combined with a random salt. This prevents precomputation. Further, the salt and the passphrase are essentially hashed together many times. This slows down the cracking attempt (after the disk and salt are stolen) by increasing the effort required to guess each password. For example, assume an attacker did not precompute anything, but could guess 100 passphrases per second against
vnconfig -k. That's about 40 minutes to guess all of /usr/share/dict/words. If we use an appropriate value of
-K that requires 5 seconds to compute the key, it would take closer to about 2 weeks.
A lot of modern systems don't include a serial port anymore, so we have to use USB-to-serial adapters. This release includes three new drivers for various chips. What should we keep in mind when we buy such an adaptor and want to use it with OpenBSD?
Jonathan Gray: Basically whatever you buy is going to work now; there are a few minor exceptions such as the Keyspan adapters, and the MosChip hardware, but they aren't really that common. I've only heard of one device with the MosChip serial chip so far and someone is sending me one so I can write a driver. Not all of the drivers support all types of flow control, most support sending a break; generally this is due to no documentation from the vendor in the case of things like the Arkmicro driver.
A USB serial port does not replace the function of a normal serial port; you can't use them for kernel debugging for example. It is generally the sort of thing people use to manage groups of machines from central points. It is nearly impossible to know which chip you're getting when buying a USB serial device, so normally you buy/test one from a supplier, then get as many as you need, typically going for the cheapest one you can find.
It seems that the installer now supports host-specific files for easy customization. Can you tell us more?
Chris Kuethe: For some time now, the installer would search for a siteXX tarball along with the standard sets (baseXX, etcXX, ...) and if it was found, would allow the user to extract the contents of the tarball into the root of the newly installed filesystem. If this tarball installs an executable named /install.site or /upgrade.site (depending on whether an install or an upgrade is being done) the installer will chroot into the destination filesystem and run that executable. This can be used to pre-populate the system with packages, non-packaged applications, configuration information, etc.
Under certain circumstances that is insufficient. Or put another way, there are times when installed systems need host-specific changes. If these changes can be placed into a tarball named something like siteXX-hostname it becomes very easy to replicate or restore configurations for a large number of systems, over the network.
Kenneth R. Westerback: Alex Holst has been working on a system for maintaining large numbers of customized OpenBSD installs for a while. During c2k6 Michael Knudsen (as I recall) brought his work to my attention again and I finally took a close look at his toolset. When I got back from c2k6 I realized that it would be trivial to greatly simplify his efforts with a simple extension to the install scripts. This was the addition of a new set we eventually decided to call siteXY-<hostname>.tgz. Since the install scripts will always know the hostname early in the install or upgrade process, this was basically a free way to find a customization file for any host. As with all the existing sets, the install and upgrade scripts will list this set if found in the directory specified to hold sets. The sets for other hosts will not appear to clutter up the display. siteXY-<hostname>.tgz will be the last set installed and is marked for installation by default.
Now, if someone installs OpenBSD, then customizes their installation, those changes can be captured as siteXY-<hostname>.tgz and uploaded to the set directory for easy application in the case of disaster recovery. Fancier tricks are possible, like giving your host a "role" as a hostname for initial installs, e.g., "newdnsserver" which would find a customization file for that role. In this case you would have to manually change a few bits to change to a real hostname and then create a new siteXY-<hostname>.tgz to preserve the final configuration for future use.
I'm sure our user community will come up with even more imaginative uses as time passes. I would encourage those interested in creating and maintaining large number of customized OpenBSD installs to check out Alex's ongoing work with
siteXYtools. Google will find it.