mycroes

There's always time to play

Thursday, May 23, 2013

Testing Watchdog related code without reboots

While writing some code for handling the Watchdog on the Raspberry Pi I wanted to verify what I had written so far. If using the character-based approach it's easy to simulate with any file and watch the contents, but when using IOCTL's or for a more realistic test it's better to just use a real Watchdog driver. Fortunately it's easy to do on Linux without causing any sudden reboots when the Watchdog isn't stopped when exiting your program. There's a softdog module that is providing a software-level watchdog driver, which can also be set up not to reboot at all, which makes testing really easy. Let's start by loading the module:

$ sudo modprobe softdog soft_noboot=1 soft_margin=15

dmesg | grep softdog should include a line similar to this:

softdog: Software Watchdog Timer: 0.08 initialized. soft_noboot=1 soft_margin=15 sec soft_panic=0 (nowayout=0)

Now you can run your watchdog code, for example echo a | sudo tee /dev/watchdog (just don't use V, because it stops the watchdog) and a line similar to this will show:

watchdog watchdog0: watchdog did not stop!

Now if you wait another 15 seconds (as set by the soft_margin argument to modprobe) you will see the following message:

softdog: Triggered - Reboot ignored

That's it. The watchdog was triggered, left running, and it triggered. You can run it again and again, and your system won't suddenly reboot (as it would when testing with the actual hardware watchdog).

Tuesday, April 2, 2013

Prevent Ubuntu (12.10+) modem-manager from keeping your Sheevaplug busy

As of Ubuntu 12.10 the very helpful modem-manager will try to connect to about any serial device. Unfortunately that means that when you connect a Marvell Sheevaplug it will connect to that as well, resulting in device or resource busy error when trying to open a screen session to your Sheevaplug. However, the solution is fairly easy, just add the following to /etc/udev/rules.d/70-mm-no-sheevaplug.rules:

ACTION!="add|change", GOTO="mm_usb_device_blacklist_end"
SUBSYSTEM!="usb", GOTO="mm_usb_device_blacklist_end"
ENV{DEVTYPE}!="usb_device",  GOTO="mm_usb_device_blacklist_end"

# Marvell Sheevaplug
ATTRS{idVendor}=="9e88", ATTRS{idProduct}=="9e8f", ENV{ID_MM_DEVICE_IGNORE}="1"

LABEL="mm_usb_device_blacklist_end"

Now do a simple sudo service udev reload, and enjoy your screen sessions with the Sheevaplug again!

Thursday, March 28, 2013

Setting up NTP signing (ntp_signd) with Samba 4 (in other words: providing time to Windows clients)

In an Active Directory domain, the focus usually is on Windows clients. One key aspect in an Active Directory domain is time synchronization. If you're here you probably know something about NTP, and maybe even that Windows won't just use the NTP server you specify using DHCP. The reason is that Windows wants a NTP server that provides signed NTP responses. ntpd actually supports providing these signed responses, but in order to do so it requires a signing provider. Samba 4 can provide this, by way of a socket specifically made for this purpose.

This post continues where I left off with Install Samba 4(.0.4) on Ubuntu 12.04 LTS, from source. It assumes Samba is already working properly, and that the ntp_signd task/service is enabled (which is by default). If you didn't install ntpd yet, do it with the following command:

$ sudo apt-get install ntp

The socket that is used for signing responses resides at /usr/local/samba/var/lib/ntp_signd/socket. The permissions on the socket should indicate that it's world writable, the permissions on the ntp_signd directory however only allow root (as user) full read/write and root (as group) read access. In order to allow ntpd to write to the socket it's necessary to grant it permissions on the ntp_signd directory, which we can do as follows:

$ sudo chgrp ntp /usr/local/samba/var/lib/ntp_signd

There's no need to change permissions of the socket file, if ntp can access it, it can write to it as well (remember, it's world writable).

There is an issue one might easily overlook. By default Ubuntu comes with apparmor enabled, which will prevent some programs from accessing files they normally shouldn't access. One of the programs that is actually configured to be restricted by apparmor, is ntp. Because Ubuntu by default doesn't know about our source-compiled Samba 4 installation, it also doesn't know about the ntp_signd socket. The fix for this is to edit /etc/apparmor.d/local/usr.sbin.ntpd:

# Site-specific additions and overrides for usr.sbin.ntpd.
# For more details, please see /etc/apparmor.d/local/README.
/usr/local/samba/var/lib/ntp_signd/socket rw,

Last but not least we need to configure ntpd so it knows that it is allowed to do signed responses and how it should sign them. This requires the addition of the following lines to /etc/ntp.conf (rest of file omitted for brevity):

ntpsigndsocket /usr/local/samba/var/lib/ntp_signd
restrict default mssntp

Now restart ntpd:

$ sudo service ntp restart

That should be it, but beware! ntpd needs some time to establish a reliable time for itself. Before it has established a reliable time it's useless. You can check if it has established time by running the following command:

$ ntpdate -q localhost
server 127.0.0.1, stratum 3, offset -0.000004, delay 0.02563
28 Mar 22:03:29 ntpdate[15015]: adjust time server 127.0.0.1 offset -0.000004 sec

In the output above it shows stratum 3, if it shows a higher number I guess you can forget requesting time from the server. In my case it will start at 16 and jump back to 3, at which point it has established a reliable time for itself.

At this point you can test with a Windows client. Just open a command prompt and type the following:

C:\>w32tm /resync
Sending resync command to local computer...
The command completed successfully.

C:\>

And that's it! If it doesn't work out this well for you, then I'd suggest you start by running ntpd in debug mode, which will at least show when it's receiving requests from clients:

$ sudo service ntp stop
$ sudo ntpd -d

If it doesn't work, or you want to thank me for the instructions, use the comments!

Friday, March 22, 2013

Install Samba 4(.0.4) on Ubuntu 12.04 LTS, from source

At the office we've been running Samba 4 for quite a while already. However, the version(s) in use date back to what was found in Ubuntu releases available at install time. The Samba team has actually done a great job at releasing a stable version for Samba 4, but I haven't seen anyone offering prebuilt packages for Ubuntu.

Recently I have been wondering if it would be a good idea to build Samba 4 from source instead. I don't like this approach much, because I prefer having all packages handled by the package manager. Then again, /usr/local/ doesn't need to stay empty, and my domain controllers are just that; domain controllers.

So yesterday I did my first attempt at building Samba from source, which went so well that I did it again today, on a fresh new Ubuntu 12.04 LTS install. I actually switched it to the IP of the primary DC as well, and stopped the old primary DC because the new one was working without any issues at all.

Now onto the actual instructions (assumes a clean 12.04 LTS basic Ubuntu server install):

$ mkdir src
$ cd src

$ wget http://ftp.samba.org/pub/samba/samba-4.0.4.tar.gz
$ tar xf samba-4.0.4.tar.gz
$ cd samba-4.0.4

$ sudo apt-get install build-essential pkg-config libkrb5-dev libacl1-dev \
libattr1-dev python2.7-dev libpam0g-dev libldap2-dev

$ ./configure && make

$ sudo make install

I've omitted all of the output, since the process was so easy. The description is easy as well:

  1. Make a directory to store the samba source in
  2. Download the Samba 4.0.4 source file
  3. Extract it
  4. Install build utilities, Samba dependencies
  5. Configure and build Samba
  6. Install Samba into /usr/local/samba

After these steps you can either follow the Samba 4 documentation to provision a new domain or join a domain, or copy the necessary files from your old domain controller onto this one if you're replacing your domain controller.

There is one important final step, and that's to create an init file. On the Samba 4 InitScript page there's a script listed that will work just fine, I copied it here for reference:

description "SMB/CIFS File and Active Directory Server"
author      "Jelmer Vernooij "
start on (local-filesystems and net-device-up)
stop on runlevel [!2345]
expect fork
normal exit 0
pre-start script
 [ -r /etc/default/samba4 ] && . /etc/default/samba4
 install -o root -g root -m 755 -d /var/run/samba
 install -o root -g root -m 755 -d /var/log/samba
end script
exec /usr/local/samba/sbin/samba -D

Copy this file to /etc/init/samba4.conf and you can use service samba4 start to start Samba 4.

All of these steps will probably apply to Ubuntu 12.10 as well, but I haven't verified yet. Also, since Samba 4 doesn't require anything that's not in Ubuntu 12.04 LTS, it might be wise to stick to this release until another LTS is released.

Please share any thoughts using the comments!