Hide logs from wheel users

If you have grown accustomed to FreeBSD administration, you’ve probably learned that users need to be member of the wheel group to be able to use the su command. Some in the land of GNU don’t agree so much with this way of doing and firmly believe that wheel is an instrument of power (which is true in a literal sens) but that’s another story.

In fact I am perfectly fine with this save for one little detail. By default most log files are owned by root:wheel. Altough while some of them have permission 600, a lot of them are 640 which means that members of the wheel group will be able to read them. We have basically two solutions to fix this:

  • Fix permissions in /etc/newsyslog.conf.
  • Use another group instead of wheel for the su command.

Fixing newsyslog.conf is quite easy, just replace the mode column with any permission you fancy (in our case 600). Don’t forget to restart newsyslog and fix existing permissions with find /var/log -type f -exec chmod 600 {} \;.

However that might not be enough. You see on most BSD wheel has gid 0, whereas on Linux it is root that has gid 0. Nobody is supposed to be a member of root, but it serves as a general purpose group for anything owned solely by root. As such you can often use chown 0:0 as a synonym of owned by root.

But root:root on Linux would not have the same meaning as root:wheel on BSD. In particular you can generally suppose that files owned by root:root with permission 640 on Linux are only readable by the root user but the same supposition doesn’t translate so well for us BSD users.

While I’m not keen of importing such kind of Linuxism into FreeBSD, one way to deal with it would be to use another group for su users. For this we would:

  • Create the su system group.
  • Move all members of wheel to this group.
  • Modify /etc/pam.d/su to use group=su instead of group=wheel.

Now I don’t personally do that, but I guess what you do it’s your business.

MSP430 and Contiki on FreeBSD

If you were trying to compile a Contiki application that targets an MSP430 platform (T-Mote Sky for example) on FreeBSD, you might have noticed that msp430-gcc was removed from the port tree and replaced by gcc-msp430-ti-toolchain. Contiki does not support this newer toolchain so you might find yourself a bit stuck there.

Fortunately you can still access the last version of the msp430-gcc packages from the FreeBSD archives:

Suspend on lid closed + battery

If you use FreeBSD 11 on the good ol’ ThinkPad X201, you’ve probably noticed now that suspend and resume work perfectly flawlessly with the latest FreeBSD release.

You probably wish to take advantage of this and suspend your laptop automatically when the lid is closed. Nothing could be easier:

sysctl hw.acpi.lid_switch_state=S3

Save this option /etc/sysctl.conf for it to be permanent.
Close the lid, the laptop goes to sleep, you’re done!
It’s that simple.

But, with this method it will go to sleep each time the lid is closed, completely ignoring whether the laptop is on battery or not. And if you’re like me you probably don’t want this. Instead you want it to suspend itself when the lid is closed and the laptop is on battery. Easy enough! We just have to invoke the mighty power of devd along with a very little shell script.

First we need to tell devd how to react when the lid is closed. Put this in /etc/devd/lid.conf, then restart (service devd restart):

# Notify lid close/open events.
notify 10 {
  match  "system"    "ACPI";
  match  "subsystem" "Lid";
  action "/etc/acpi/lid.sh $notify";
};

Now we will make a script that checks the lid and AC line states and chooses to suspend the laptop when both the lid is closed and AC line is disconnected. This goes in /etc/acpi/lid.sh:

#!/bin/sh

lid="$1" # 0x00 is closed, 0x01 is open (see devd.conf)
acline=$(sysctl -n hw.acpi.acline) # 0 is battery, 1 is online (man acpi)

if [ \( "$lid" = "0x00" \) -a \( "$acline" -eq 0 \) ]
then
  logger "Lid closed on battery. Going to sleep."
  acpiconf -s3
fi

Try it out! Disconnect the AC line, close the lid, it should go to sleep within seconds. However if it doesn’t work you might want to modify the script above a little to check whether lid events are received correctly or not.

Now you may use a modified version of this script to lock xscreensaver when the lid is closed and before the actual suspend. Well OK, I’ve done that for you:

#!/bin/sh
# XScreensaver should be called BEFORE going to sleep to avoid the desktop to be
# shown for a few seconds when the system resumes from sleep.
PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin

lid="$1" # 0x00 is closed, 0x01 is open (see devd.conf)
acline=$(sysctl -n hw.acpi.acline) # 0 is battery, 1 is online (man acpi)

lock_display() (
  socket="$1"
  display=$(echo "$socket" | tr "X" ":")

  # Temporary pid file for the watching command
  tpid=$(mktemp)

  # Wait until the display is actually locked.
  (timeout 2s xscreensaver-command -display "$display" -watch & echo $! > $tpid) | (
    # Issue the lock command only when we know that
    # the watching pipe is ready.
    xscreensaver-command -display "$display" -lock

    while read line
    do
      line=$(echo $line | cut -d' ' -f 1)

      if [ "$line" = LOCK ]
      then
        # We have to kill the watching command manually before breaking.
        kill -TERM $(cat $tpid)
        break
      fi
    done
  )

  rm $tpid
)

# The X server may not be running
if [ ! -d /tmp/.X11-unix ]
then
  exit 0
fi

# Lock each available display
for socket in $(ls /tmp/.X11-unix)
do
  # Lock the display
  logger "Locking xscreensaver on $socket"
  lock_display $socket &
done

# Wait until every displays are locked
wait

# Now we can suspend if needed
if [ \( "$lid" = "0x00" \) -a \( "$acline" -eq 0 \) ]
then
  logger "Lid closed on battery. Going to sleep."
  acpiconf -s3
fi

Linuxulator ist kaputt

Since a few weeks I’m running RELEASE on a custom kernel to use a patch that I made for a missing feature in the IPv6 stack (namely icmp_may_rst).

But a few minutes ago I had the surprise to find that the Linuxulator was no longer working. Trying to run a Linux binary failed with the following error:

ELF binary type "0" not known.
exec: test: Exec format error

Actually looking at kldstat, the Linux kernel module wasn’t even loaded. Trying to load it manually gave me the following error:

link_elf_obj: symbol kern_sched_setscheduler undefined
linker_load_file: Unsupported file type

OK so what is this sched_setscheduler you are talking about? Well there you go!
Now the Linuxulator depends on that syscall, but for some reason the necessary option disappeared from my custom kernel configuration. All I had to do was to add it again and recompile:

options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions

And now I can run Linux binaries again!

Display WiFi RSSI on FreeBSD

On FreeBSD we also use the ifconfig command to configure wireless interfaces. The command ifconfig wlan0 list scan lists available AP along with their SNR. However the ifconfig command does not display the RSSI/SNR on the current link. To do so we need another command, wlanstats. It is not included in base system but you can find it in the source tree under /usr/src/tools/tools/net80211/wlanstats. This command also shows you the signal level (in dBm) and current transmit rate among other things.

I wonder why the RSSI is not visible with the ifconfig command. I suppose they wanted to regroup all those stats with another command. But again I wonder why this command is not part of the base system.

Dedibox serial shell access

If you cannot access the shell on a FreeBSD dedibox from the online.net console, here is a quick tip. Create an alternate root account with csh or tcsh and access ttyu1 on this account instead. That’s almost precisely what the toor account is made for, except that we generally leave the default shell on root.

No idea why sh, bash and zsh are not working through the serial connection, more doesn’t work either, but vi does. Probably a termcap thingy ? If anyone has a clue…

Install FreeBSD 11 with ZFS on Dedibox XC 2016

Online.net’s Dedibox XC 2016 comes with 16 GB DDR3 and 1 To SATA or 250 GB SSD on a 8 cores Atom CPU. This is a very nice entry-level dedicated box for anyone who want to upgrade from a small VPS (yes, there is some upgrade in the air). There is only one HDD and no RAID though. But they offer (for free) a 100 GB FTP storage space which is more than enough to backup the base system and bootstrap it again in case of disk failure.

An advantage of dedicated over VPS is that you can install almost any OS you want. The management console comes with an easy install for FreeBSD 11 on UFS. But I thought it would be nice to use ZFS instead. Yeah, I hear you, why using ZFS with only one HDD and non-ECC memory? But with 16 GB it still comes as a viable alternative.

The method I used was adapted from a post on Online.net’s forum. So here we go. First, reboot in rescue mode from the console. Choose FreeBSD 10.2 (or higher) as the rescue OS. Once you are logged on the rescue, switch to root and bootstrap FreeBSD:


SWAP_SIZE=4g
TEMP_ROOT_PASSWORD="1337rul35"

# Create partitions table
gpart destroy -F ada0
gpart create -s gpt ada0
gpart add -t freebsd-boot -l boot -s 512K ada0
gpart add -t freebsd-swap -l swap -s $SWAP_SIZE -a 1m ada0
gpart add -t freebsd-zfs -l zfs0 ada0

# Install MBR
dd if=/dev/zero of=ada0p3 count=560 bs=512
gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ada0

# Create ZFS pool and FS
zpool create -f -m none -o altroot=/mnt -o cachefile=/tmp/zpool.cache -O compress=lz4 -O atime=off zroot gpt/zfs0
zfs create -o mountpoint=/ zroot/ROOT
zfs create -o mountpoint=/usr zroot/usr
zfs create -o mountpoint=/var zroot/var
zfs create -o mountpoint=/tmp zroot/tmp
zfs create -o mountpoint=/www zroot/www
zfs create -o mountpoint=/usr/home zroot/usr/home
zpool set bootfs=zroot/ROOT zroot

# Bootstrap
cd /mnt
fetch ftp://ftp.freebsd.org/pub/FreeBSD/releases/amd64/amd64/11.0-RELEASE/base.txz
fetch ftp://ftp.freebsd.org/pub/FreeBSD/releases/amd64/amd64/11.0-RELEASE/kernel.txz
tar --unlink -Jxpf base.txz -C /mnt
tar --unlink -Jxpf kernel.txz -C /mnt
rm base.txz kernel.txz

# Configuration
# 1) fstab and swap
cat << EOF > /mnt/etc/fstab
ada0p2 none swap sw 0 0
EOF

# 2) rc.conf
cat << EOF > /mnt/etc/rc.conf
keymap="fr.acc"
ifconfig_igb0="DHCP"
ifconfig_igb1="DHCP"
fsck_y_enable="YES"
background_fsck="YES"
zfs_enable="YES"
sshd_enable="YES"
EOF

# 3) loader.conf
cat << EOF > /mnt/boot/loader.conf
zfs_load="YES"
vfs.root.mountfrom="zfs:zroot/ROOT"
boot_multicons="YES"
boot_serial="YES"
comconsole_speed="9600"
console="comconsole"
comconsole_port="0x2F8"
EOF

# 4) TTY for serial console
cat << EOF >> /mnt/etc/ttys
ttyu1 "/usr/libexec/getty std.9600" vt100 on secure
EOF

# 5) Temporary root password
echo "$TEMP_ROOT_PASSWORD" | pw -R /mnt user mod -n root -h 0

# Last step
cd ~
zpool export zroot
zpool import -o altroot=/mnt -o cachefile=/tmp/zpool.cache zroot
cp /tmp/zpool.cache /mnt/boot/zfs

# Terminated!
halt

Now from the management console, reboot in normal mode and connect to your box using serial connection. You should be able to login with root and continue the configuration from there.

FreeBSD 10 on ThinkPad X250

UPDATE:


I’m now using FreeBSD 10-RELEASE on a ThinkPad X250. It’s been quite a while now, and I should have written this long ago. Well… Here we go! Everything works fine except for:

  • Intel Broadwell integrated graphics
  • Intel Wireless 7265
  • Resume/Suspend

For the integrated graphics, the Broadwell architecture is not yet supported [1, 2]. But it works well using VESA at native resolution (1920×1080). I had to tweak the MTTR a little to get reasonable performance. Of course you cannot use your VGA and miniDP anymore. That’s a bummer for giving presentations. To this regard, I still rely on Linux. Also you cannot adjust screen luminosity, it’s always at full power. So if you are in a dark room or a car at night, you will transform yourself into a lamppost.

Here is what I have in my /etc/rc.local for the MTTRs:

memcontrol clear -b 0xc0000000 -l 0x20000000
memcontrol set -b 0xc0000000 -l 0x20000000 -o BIOS write-combine

I also had to force the DPI in /usr/local/etc/X11/xorg.conf.d/dpi.conf

Section "Monitor"
  Identifier "Monitor0"
  Option     "DPI" "96x96"
EndSection

For the WiFi, there is an iwm driver coming in FreeBSD 11 that was ported from OpenBSD. Until recently I used a Ralink RT2500USB card to get it working. But last week, I did a quick and dirty backport for FreeBSD 10, it is available here. This is a fork of the iwm driver before its inclusion in HEAD. It works somewhat. But please keep in mind that I have no clue here. I still have to read more and get into the FreeBSD kernel. And this is a temporary solution while we are waiting for the release of FreeBSD 11.

The driver still crashes when loaded with virtual box modules. Also the channel is currently locked. So if you want to use it, you need to find the correct channel first, select it manually, and then try to associate. There is a small script on the repo to do so.

Use notify-send as root

The automount script is a neat devd based automounter for FreeBSD. Just pkg install automount and all your removable media will mount themselves automatically in /media when you plug them in. It’s very clean. You may also check vumount, a short script that I made to list all removable media and remove the mount point when you unmount them.

It’s possible to configure automount to send a notification to your desktop using notify-send from libnotify. What it does exactly is (as root):

env DISPLAY=:0 notify-send automount "Device '${1}' mounted on '${3}' directory."

Except that it doesn’t work… I started dbus-monitor and tried notify-send as root (from ttyv2) but didn’t receive anything and notify-send did not complain. So I tried to start dbus-monitor from root instead, in the hope that it would be a bit more verbose than notify-send. I got this error message:

Failed to open connection to session message bus: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.

By default DBus sessions are private and don’t accept connections from other users than the one that own the bus, even root. The solution is to configure DBus to allow root on the session bus. Edit /usr/local/etc/dbus-1/session.conf and add this line to the default policy:

<allow user="root"/>

But you still need tell DBus how to connect to the session bus. To do so you have to specify the session bus address in DBUS_SESSION_BUS_ADDRESS. Fortunately automount is a shell script, so you can fetch and export the bus address from its configuration file. Just add this to /usr/local/etc/automount.conf:

# Load DBus session bus address
DBUS_USER=your-user
if [ -d /home/$DBUS_USER/.dbus/session-bus ]
then
  dbus_file=$(ls -t1 /home/$DBUS_USER/.dbus/session-bus | head -n1)
  export DBUS_SESSION_BUS_ADDRESS=$(cat /home/$DBUS_USER/.dbus/session-bus/$dbus_file | \
                                    grep "DBUS_SESSION_BUS_ADDRESS=" | \
                                    sed 's/[A-Z_]*=//')
fi