Archive
Posts in OpenBSD
Sometimes it's the little things that bite you
After installing a new OpenBSD image on my Soekris net4801, I needed to become root to perform some post installation configuration. When I ran the su command, it exited without switching me to the root user: This baffled me for a minute, since my user and group identifiers looked fine, and I was in the wheel group (OpenBSD allows you to use the group wheel to control which users can become uid 0): To see what was going on, I ran ktrace to view the call path for the su executable: After reviewing the complete dump, I noticed that the su executable couldn't open the secure passwd database: It then dawned on me that I shouldn't be able to ktrace a setuid executable as an unprivileged user, so I decided to check the permissions of the su utility to see why the kdump worked: Well I'll be. When I extracted the files tonight to create my archive, I either extracted then as an unprivileged user (which is why the setuid / setgid bits weren't preserved), or I forgot to use tar's "-p" option to preserve the file modes (I no longer have the history file, so I can't see where I made my mistake). I think the tryptophan from the turkey is setting in…
$ read more →Locating OpenBSD devices for kernel builds
I run OpenBSD on a few soekris net4801s, which don't have a whole lot of memory. To ensure that I am efficiently using the hardware, I build custom kernels that contain just the devices needed to load and run the OpenBSD kernel on the soekris. This minizes the kernel memory footprint, and allows me to eeek out a few extra pages of spare memory. To build a custom kernel with just the devices I need, I usually start by running the dmassage utility to identify the devices on my system: Once I have the devices, I use my OpenBSD kernel build procedure, but trim the devices that aren't displayed by dmassage…
$ read more →Monitoring hardware sensors with the OpenBSD sensor daemon
In OpenBSD 3.9, the sensor framework was added to allow users to monitor systems that contained hardware sensors (e.g., temperature, voltage, fan speed, etc.). Sensor data is made available through one or more "hw.sensors" kernel state variables, which can be viewed with the sysctl utility: In addition to kernel support, OpenBSD has a userland daemon, sensorsd, which can be used to monitor one or more sensor values. If one of the sensor values that sensorsd is monitoring goes above or below an administrator defined threshold, sensorsd will by default write an entry similar to the following to the system log: Sensor thresholds are defined in the file /etc/sensorsd.conf. Each entry in /etc/sensorsd.conf contains the name of a sensor to monitor, the value "high" or "low" to indicate a peak or valley for the sensor value, and the value the sensor value cannot go above or below…
$ read more →Viewing OpenBSD server utilization with systat
OpenBSD has a number of nifty utilities, and I happened to come across the systat(1) utility this weekend while looking for an executable in /usr/bin. Systat prints out performance data in an ncurses display, and can be used to view CPU saturation, I/O statistics, swap utilization, netstat data, and MBUF and network interface utilization. The utility takes the metric to display as an argument, and allows an interval to be used to control how often data is displayed: I absolutely love UNIX, BSD and Linux systems. There are so many nifty tools available for these operating systems, and it's a h00t when you come across a new utility that you didn't previously know about…
$ read more →Setting up the OpenBSD watchdog daemon (watchdogd)
The watchdog daemon (watchdogd) was introduced in OpenBSD 3.8, and can be used to help machines automatically recover from system hangs. If the OpenBSD hardware watchdog daemon is enabled, it will periodically update the hardware watchdog timer built into the system. If this timer is not reset for a period of time, the hardware will reset itself. The watchdog daemon is not enabled by default, and can be enabled (assuming OpenBSD can find a watchdog timer in your system) by adding a pair of empty quotes to the watchdog_flags variables in /etc/rc.conf: The update interval is controlled through the kern.watchdog.period variable, which can be set in /etc/sysctl.conf, and viewed with the sysctl(8) command: Using the hardware watchdog can be useful when you are running routers and access points in remote locations, and don't want to spend time driving to a remote location to reboot a hung system…
$ read more →