Posts Tagged ‘OpenBSD’
OSError with duplicity 0.6.19 on OpenBSD and OS X
Sometime around duplicity 0.6.15 (ish) I started running into OSError exceptions that I just didn’t have time to track down. I’ve finally made time, though, and it wasn’t too hard to track down the culprit. I didn’t realize it at the time, but this only affects non-privileged users running duplicity. tl;dr choose a different TMPDIR.
Updated OpenBSD softraid install page
With their 5.1 release, OpenBSD has added support for placing the root filesystem on a softraid(4) device for the i386 and amd64 architectures. Additionally, the amd64 port supports booting the system from a kernel on the softraid device.
Previously, the way to provide system redundancy using software RAID was to use softraid for all of your filesystems except the root filesystem. The root filesystem would be copied to an identically sized partition on the second disk every night by the /etc/daily script. It was up to you to keep the boot blocks up-to-date.
Awesome. I’ve updated my Installing OpenBSD using softraid page. I’ll let you know how it goes.
OpenBSD Install via IPMI on SuperMicro Server
This is a step-by-step guide for how I remotely installed OpenBSD 5.0 to my SuperMicro X8SIE-LN4F based server. This includes setting up IPMI and remote serial console.
Insufficient serial devices in the amd64 GENERIC kernel for SuperMicro
As I was futzing around trying to get OpenBSD 5.0 (amd64) to play well with the SOL provided by the BMC on my new SuperMicro server, I noticed something unexpected about the amd64 GENERIC kernel.
I really want a reliable console on these new servers, and I’m pretty sure that if any OS is going to manage decent serial support, it’s going to be OpenBSD. Getting OpenBSD to use a serial console is well documented and pretty easy, but installing via serial console is a little more difficult. In my case, though, I don’t need to modify the install CD because I don’t technically need a 100% serial install.
The AMI BIOS on this server provides console redirection that — while not the best — works well enough to allow me to interrupt the VGA boot loader and change the console to the serial port via set tty com2. After that, the ramdisk kernel booted with a console on the third serial port and my generic OpenBSD 5.0 install went very smoothly. Until it came time to boot into the new OS, that is.
An OpenBSD install is a thing a beauty. It’s the most well thought out installer I’ve ever used, and it’s exclusively text-based. So it’s a great fit for a serial console install. It even detected that I was using com2, and asked if I wanted to make that the console on the install. When I rebooted, however, I received all the kernel messages on the SOL console, but nothing from the startup scripts or getty.
It appears to me the problem is that — while the amd64/RAMDISK_CD and the i386/GENERIC kernels both come configured with 3 COM ports — the amd64 GENERIC kernel is only configured with 2 COM ports. If I use config -e to add a third com port and boot that modified kernel, everything works perfectly.
As soon as I understand the issue a bit better, I’ll be posting a step-by-step guide with some model numbers.
OpenBSD Embedded Router
The excellent flashrd project makes easy work of installing OpenBSD as an embedded platform. I had an excellent experience installing OpenBSD 5.0 on a PCEngines ALIX 2d13 using a 4GB CF. A rough outline of the steps follows.
Shells shells everywhere
tmux makes it easy to construct a plethora of ssh connections via tmux neww "ssh $HOST", so I find myself frequently doing this from scripts. tmux uses a shell to execute the ssh command, though, and I never liked how it left idle shells littering my process tree thusly:
\-+= 23132 user tmux: server (/tmp/tmux-505/default) (tmux) |-+= 25189 user sh -c sh | \--- 01613 user ssh hostA |-+= 08778 user sh -c sh | \--- 03665 user ssh hostB
Recently I actually bumped into my process limit and couldn’t spawn any new windows. This turned out to be pretty solve, though. I couldn’t figure out how to convince tmux not to use a shell to execute the command, but we can at least replace that shell process by telling the shell to exec rather than fork/exec. Now my script looks like this, and my process tree is nice and tidy.
let i=1
for host in $hosts; do
tmux neww -d -n ${host%%.*} -t $session:$i "exec ssh $host"
let i=i+1
done
OpenBSD creating additional ptys
I like a lot of windows. A lot of them. Today I bumped into a default limit on OpenBSD 4.8 and tmux(1) started returning “No such file or directory” when I attempted to create a new window. This turned out to be a simple thing to solve, though.
Software RAID on OpenBSD 4.8
jpiasetz has a very good recipe on installing with software raid on OpenBSD 4.6, and so far I’ve had good success doing something very similar with OpenBSD 4.8. The biggest thing I changed was using wd1a rather than sd0a for /altroot. Then it’s easy enough to use daily(8)’s integrated altroot sync to keep altroot up-to-date.
OpenBSD 4.8 duplicity port isn’t getting the job done
Trying to use duplicity from the current OpenBSD -stable (4.8) was a non-starter for me. The failure took the form of:
% duplicity -v1 /path/to/files file:///path/to/backups
Traceback (most recent call last):
File "/usr/local/bin/duplicity", line 1236, in
with_tempdir(main)
File "/usr/local/bin/duplicity", line 1229, in with_tempdir
fn()
File "/usr/local/bin/duplicity", line 1207, in main
full_backup(col_stats)
File "/usr/local/bin/duplicity", line 416, in full_backup
globals.backend)
File "/usr/local/bin/duplicity", line 294, in write_multivol
globals.gpg_profile, globals.volsize)
File "/usr/local/lib/python2.5/site-packages/duplicity/gpg.py", line 278, in GPGWriteFile
bytes_to_go = data_size - get_current_size()
File "/usr/local/lib/python2.5/site-packages/duplicity/gpg.py", line 270, in get_current_size
return os.stat(filename).st_size
OSError: [Errno 2] No such file or directory: '/tmp/duplicity-leH-Rr-tempdir/mktemp-nQQHGO-2'
Which turned out to be a terribly confusing and unrelated error message. The error reported in the above stack trace was actually an error in the cleanup process. The actual problem had been masked by duplicity’s gpg fork a long time prior.
So what was the problem?
- pkg_add satisfied duplicity’s gnupg dependency by installing gnupg-2.0.15
- duplicity’s child was attempting to execute gpg, but only gpg2 had been installed by gnupg-2.0.15
That’s right. This problem was solved with ln -s /usr/local/bin/gpg2 /usr/local/bin/gpg.
Well, at least I had the opportunity to get intimate with the python debugger…
tech stuff. 