Ze hangt wel eens in de gordijnen, soms probeert ze Bommel te vangen maar eigenlijk is ze heel lief. Blacky en Koetje kunnen het heel erg goed vinden, dus het is een gezellige beestenboel met onze 3 katten…

Hier is ze in de weer met een duivenveer die ze in de tuin gevonden heeft – blijkbaar héél interessant!

♫ Happy Birthday to Koe,
Happy Birthday to Koe… ♫

Just like the check_disk plugin, it has the nagios_checkdisk_plugin_exec_t SELinux type. As of May 2012, this problem has not yet been fixed.

The workaround is simple, as with the check_disk plugin:

chcon -t nagios_unconfined_plugin_exec_t /usr/lib64/nagios/plugins/check_linux_raid

Or, for 32-bit systems:

chcon -t nagios_unconfined_plugin_exec_t /usr/lib/nagios/plugins/check_linux_raid

Hardware

I decided to install a low-profile Intel NIC and upgrade the RAM memory to run ZFS comfortably.

HP have published some videos on (dis-)assembling the server, making the job a lot easier. There was only one issue: the mini-SAS connector is a pain to remove. Some Googling later, I found this post:

    To unplug a Mini-SAS x4 cable, squeeze the clip on the plug, then push the plug in before pulling it out. (Source: Oracle)

ZFS is very RAM-hungry, so I installed 2x 4GB Unregistered ECC DIMMs, giving me the maximum supported 8GB configuration:

    Crucial 4GB 240-pin DIMM 512Mx72 DDR3 PC3-10600 ECC (CT51272BA1339)

The Crucial DIMMs were detected without problems. It is possible to use standard non-ECC memory, but I wanted the extra reliability offered by having RAM with Error Correction.

Software

There are two ways to run FreeNAS: bare metal, or in a virtual machine. If you want to go the virtual route, HP has made a customized version of VMware ESXi 5 available for ProLiant servers. To minimize complexity, I run FreeNAS on bare metal. This avoids having to deal with raw device passthrough in VMware and ensures maximum performance.

FreeNAS installation

Installation was a breeze. I created a bootable USB stick (4GB, but 2GB should be fine) using VMware Fusion on my Mac; create a new VMware guest (FreeBSD 8, 64-bit) and set it to boot from the ISO image. Connect the USB stick to the VM; the FreeNAS installer will detect it and ask if you want to install to the USB drive. After installation, shut down the VM and plug the USB stick into the internal USB-port in the MicroServer. Done.

Next, you’ll want to add your harddisks and create a ZFS Volume. I enabled the “4k sectors” option for my 2TB Western Digital drives.

You can simply share this entire volume, or create ZFS Datasets within the ZFS Volume. This gives you more fine-grained control over permissions and sharing.

I mainly use NFS and SMB (CIFS) shares at the moment. They can be used from Mac OSX without problems. Having a central LDAP directory (or perhaps even NIS) helps when setting the correct ownership and permission.

Practical experience

So far, I’m quite happy with FreeNAS performance and ease of use.

FreeNAS 8.2.0-BETA3 appears quite stable; I haven’t found any major bugs yet.

Links

• ZFS Evil Tuning Guide
• Running ZFS over NFS as a VMware store
• Frequently Asked Questions About Flash Memory (SSDs) and ZFS

For additional security, SElinux is enabled on the monitoring host. There is no standard SElinux policy for applications like PNP4Nagios, so we need to develop a custom policy. This sounds harder than it actually is:

• Run the software as you normally would (SElinux will interfere, so prepare for errors)
• Extract audit messages and use them to create or update a local SElinux policy for the software
• Repeat until everything works

In this example, I am running Nagios 3.2.3 with PNP4Nagios 0.6.16 on EL6, 64-bit.

After configuring Nagios and PNP4Nagios integration in Synchronous Mode (see documentation), I noticed that PNP4Nagios is not logging any performance data to /var/lib/pnp4nagios/.

Normally, PNP4Nagios should automatically create directories and files under /var/lib/pnp4nagios as performance data is received by Nagios. This smells of an SElinux issue, so check /var/log/audit/audit.log for suspicious messages. Sure enough, several audit messages have been logged. They look like this:

type=AVC msg=audit(1329129875.344:198212): avc:  denied  { getattr } for  pid=26692 comm="process_perfdat" \
    path="/var/lib/pnp4nagios/orac/Root_Partition.xml.26692" dev=dm-0 ino=1444378 \
    scontext=unconfined_u:system_r:nagios_t:s0 tcontext=unconfined_u:object_r:var_lib_t:s0 tclass=file
type=SYSCALL msg=audit(1329129875.344:198212): arch=c000003e syscall=5 success=no exit=-13 a0=3 a1=25440a0 \
    a2=25440a0 a3=0 items=0 ppid=26691 pid=26692 auid=0 uid=498 gid=498 euid=498 suid=498 fsuid=498 egid=498 \
    sgid=498 fsgid=498 tty=(none) ses=14942 comm="process_perfdat" exe="/usr/bin/perl" subj=unconfined_u:system_r:nagios_t:s0 key=(null)

Create a policy

You can run the “audit2allow” command (part of the policycoreutils-python RPM) to display suggested policy improvements based on the audit log:

audit2allow -a

The output can be saved in a file, for example local_nagios.te:

grep nagios_t /var/log/audit/audit.log | audit2allow -l -v -m local_nagios > local_nagios.te

This generates an output file suitable for compiling into a custom SElinux module.

Note: ALWAYS prefix the policy name with something like local_ to prevent overwriting system policies!

Test and refine the policy

Compile and load the SElinux policy module:

checkmodule -M -m -o local_nagios.mod local_nagios.te
semodule_package -o local_nagios.pp -m local_nagios.mod
semodule -v -i local_nagios.pp

Note: The above tools can be found in the checkpolicy and policycoreutils RPMs.

Re-run the software and check for SElinux audit messages. New issues can be captured and translated into a new policy:

grep nagios_t /var/log/audit/audit.log | audit2allow -l -v -m local_nagios > local_nagios.te_NEW

Merge the new results (in local_nagios.te_NEW) with your existing policy (in local_nagios.te). Compile and reload the module.

Lather, rinse, repeat

Results

After some iterations, your local_nagios.te file will look something like this:

module local_nagios 1.0;

require {
    type nagios_t;
    type var_log_t;
    type var_lib_t;
    class dir { write create add_name remove_name };
    class file { create getattr ioctl lock open read rename unlink write };
}

#============= nagios_t ==============
allow nagios_t var_lib_t:dir { add_name create remove_name write };
allow nagios_t var_lib_t:file { create getattr ioctl lock open read rename unlink write };
allow nagios_t var_log_t:file { read rename unlink };

If all is well, the audit.log should not show any new messages for nagios_t:

clear;tail -f /var/log/audit/audit.log |grep nagios_t

Note: The new SElinux policy will survive reboots; it is automatically copied to /etc/selinux/targeted/modules/active/modules/local_nagios.pp.

Enjoy!

By default, these AVC denials are not logged in /var/log/audit/audit.log which makes this problem harder to spot (if you want, you can enable all audit-messages by running semodule -DB).

There are at least two relevant entries in Bugzilla:

• Bug 771245 – nagios-plugins-disk fails when checking /boot on RHEL6.2 boxes
• Bug 768055 – SELinux silent denials of Nagios NRPE check of /boot

Fortunately, there is a simple workaround while we wait for an updated selinux-policy package. As root, do the following:

chcon -t nagios_unconfined_plugin_exec_t /usr/lib64/nagios/plugins/check_disk

Or, for 32-bit systems:

chcon -t nagios_unconfined_plugin_exec_t /usr/lib/nagios/plugins/check_disk

No need to restart anything; just wait until Nagios re-checks the service and the problem should be gone. Enjoy!

The onboard web interface does not seem to offer a way to configure these presets – but there is another way!

I have written a couple of small shell scripts (for Linux or Mac OS X) that allow you to set a preset, move to a preset and even take a snapshot right from the command line.

The first script stores the current camera position into the specified preset.

You need to open a web browser or camera app (my favorite: Live Cams Pro on iPad/iPhone) and set the camera position.

Then, run this script, specifying the preset number (for example, “foscam_set 0” to set the first preset):

#!/bin/bash
# Store current camera position in specified preset (0..16)

# Commandline handling
#
preset=$1
if [ -z $preset ];
then
    echo "Syntax: $0 <preset>, where preset is a number (0..16)"
    exit 1
fi

# Address (or address:port number) where to reach the camera
# Username / password to access camera functions
#
CAMERA=192.168.1.2
USERNAME=theUsername
PASSWORD=thePassword

# Presets are set using URL with command (30 + preset*2), and recalled using URL with command (31 + preset*2)
#
command=$((30 + 2*$preset))
echo "Storing current camera position in preset ${preset} (command = ${command})"
wget -O - http://${CAMERA}/decoder_control.cgi?command=${command}\&user=${USERNAME}\&pwd=${PASSWORD}

Next, a script to move the camera to a specified preset (for example, “foscam_go 3“:

#!/bin/bash
# Move camera to specified preset (0..16)

# Commandline handling
#
preset=$1
if [ -z $preset ];
then
    echo "Syntax: $0 <preset>, where preset is a number (0..16)"
    exit 1
fi

# Address (or address:port number) where to reach the camera
# Username / password to access camera functions
#
CAMERA=192.168.1.2
USERNAME=theUsername
PASSWORD=thePassword

# Presets are set using URL with command (30 + preset*2), and recalled using URL with command (31 + preset*2)
#
command=$((31 + 2*$preset))
echo "Moving camera to preset ${preset} (command = ${command})"
wget -O - http://${CAMERA}/decoder_control.cgi?command=${command}\&user=${USERNAME}\&pwd=${PASSWORD}

Finally, a demo script that moves the camera to a preset, takes a snapshot and stores it locally (based on a post by 1994MGoBlue):

#!/bin/bash
# Take snapshots of certain preset camera locations

# Address (or address:port number) where to reach the camera
# Username / password to access camera functions
#
CAMERA=192.168.1.2
USERNAME=theUsername
PASSWORD=thePassword

# The camera should normally be in this position
DEFAULT_PRESET=3

# Seconds to sleep after issuing a camera move command, allow it to reach new position.
# You may have to change this value to your needs
DELAY=10

# Presets are set using URL with command (30 + preset*2), and recalled using URL with command (31 + preset*2)
#
for preset in 0 1 2 3 4;
do
    command=$((31 + 2*$preset))
    echo "Taking snapshot in preset ${preset} (command = ${command})"

    # Move camera, delay, take snapshot (stored in /tmp/)
    wget -O - http://${CAMERA}/decoder_control.cgi?command=${command}\&user=${USERNAME}\&pwd=${PASSWORD}
    sleep ${DELAY}
    wget -O /tmp/preset-${preset}.jpg http://${CAMERA}/snapshot.cgi?user=${USERNAME}\&pwd=${PASSWORD}
done

# Done, send camera back to default position
command=$((31 + 2*$DEFAULT_PRESET))
wget -O - http://${CAMERA}/decoder_control.cgi?command=${command}\&user=${USERNAME}\&pwd=${PASSWORD}

Enjoy!

… ook namens onze veestapel, Bommel, Blacky en Koetje

This plug contains a separate receiver and transmitter board. After consulting the schematic, it appears that the receiver is hooked up to the AIO pin, while the transmitter is connected to the DIO pin. This information is needed when reconfiguring the software for the actual Port socket you plugged the OOK433 into.

There are two solder jumpers that need to be made (marked in the picture on the right):

• The upper one selects supply voltage. According to current documentation, the rightmost two pads need to be bridged, selecting +3V.
• The lower solder jumper should always be bridged (except if a resistor R1 is to be installed)

Note that the Receiver and Transmitter modules have “+5V’ and “+12V” markings on them – apparently, they also work at this much lower voltage.

After making these two solder jumpers, continue assembly. I soldered a 6-pin header (not included with the kit)  to the Port connector so I can plug it straight into a JeeNode.

The trick here is to apply some solder to one pad and one pin first. Then, hold the header in place while re-heating the solder on that pad. The remaining pads can now be soldered properly. The picture shows the solder jumpers I made, as well as the preparations for soldering the 6-pin header in place.

Make sure you get shiny solder joints that are properly heated (lead-free solder tends to shine a bit less than the 60/40 I use).

Next up: the transmitter module. Note that when soldering, you usually work from “lowest” to “highest” component. This makes life easier. Simply insert the transmitter module into the 3 holes and solder it. Note that the module has an antenna connector (marked “ANT”) for adding a straight-wire antenna, approx. 17cm in length. This corresponds to 1/4 wavelength at 433MHz.

Finally, the receiver module. Insert it into the 4 holes and solder it. This module also has an antenna connector, you may want to add a 17cm straight-wire antenna here as well.

The end result is in the picture below. Now for the moment of truth: trying to make it work with a JeeNode and a software sketch.

This is where my trouble began. I used various sketches with my new KAKU remote, to no avail:

• kaku_demo
• KlikAanKlikUit_A_type
• ookRelay
• ookScope2
• recv433_test

I searched the blog and forums using Google (“site:jeelabs.net OOK433″) and found several people struggling to make the OOK433 Plug work. Several issues appear to be at play here:

1. Confusion regarding the correct supply voltage; it seems that +3V is not enough.
   This means that you would need to bridge the leftmost two pads on the upper solder jumper, instead of the rightmost two pads.
2. Confusion regarding port numbers / Arduino pin numbers.
   The KlikAanKlikUit_A_type sketch is the only one that seems to clearly document where the Plug is expected to be for the sketch to work.
3. Confusion regarding the antennas being “optional” or not.
   I have no antennas connected at the moment, but I’m using the remote at close range so it should not be a problem.
4. Confusion regarding the different KAKU protocols out there.
   I think I have the most recent protocol, with house code (A-D on my remote). The old protocol apparently does not have that.

All in all, quite a few variables

I decided to go ahead with the ookScope2.ino sketch – that appears to be a fairly recent sketch; hopefully that code works as expected. First hurdle: determining which port to plug the OOK433 Plug into…

The code contains this line:

#define OOK_PIN   2   // this is the input pin with the signal to be analyzed

This might refer to AVR pin PD2, Arduino pin “Digital 2″ but that would mean it’s connected to the RFM12B INT line! Not very likely… I tried the code, and apart from the [ookScope] identifier, nothing happened. So, where does that OOK433 Plug need to go for the sketch to work?

OK, back to the schematic I talked about at the start of this post. The OOK433 receiver module appears to be connected to the AIO pin. If I want to use the plug in Port 3, I need to find the proper value for AIO3. That would be Analog 2 / Digital 16 (hey, ’2′ looks familiar but it didn’t work).

I then tried seting OOK_PIN to 16 (Digital 16), plugged the OOK433 into Port 3 and behold! The sketch starts, and emits binary garbage on the serial output! This is promising!

Next up: install the JeeRev / JeeMon software on my Mac according to instructions. Unfortunately, that didn’t result in a nice bar graph display – the bars remain at zero, even though I pressed the remote buttons. Perhaps the ookScope2.ino sketch doesn’t work with this version of the JeeMon software? What’s next? Debugging the JeeMon installation? Nah…

Anyway, my head hurts after reading through the various forum and blog posts – once I get this working I’ll post “part 2″ of this adventure

P.S.: I think we as a community should work on improving the “Out of Box Experience” for the JeeLabs hardware. Detailed assembly instructions, a simple test sketch with clear instructions on setting up the test bed – life would be so much easier If possible, add a low-level hardware diagnostics mode in that test sketch to help isolate the cause of any hardware-related problems. For example, try communicating over the SPI / I2C bus. If that doesn’t work, you might have to inspect your soldering. And most importantly: find a way to reduce @JCW’s workload – it would not be realistic to expect him to do all the work on documentation / test sketches etc.

Still massively enjoying the JeeLabs learning experience, one (steep) step at a time

Onwards!

After soldering the control board to the LCD display,I tried compiling the lcd_demo.ino demo sketch. No luck – it seems that the code no longer compiled with Arduino 1.0.

I added the include-file that was missing:

#include <PortsLCD.h>

and suddenly… nothing happened.

I verified the connections – everything looked good. Oh well – “if all else fails, read the manual”. There were no detailed assembly instructions for this kit, so I had to search through various posts to help debug the issue.

Turns out that you have to set two solder jumpers (Logic to 3v3, Backlight to 3v3) as well as short out a current limiting resistor (which is not actually present on the board). Click the annotated image on the left for a (blurry) close-up.

This still did not seem to solve the problem – the backlight worked, but still no text on the display. After adjusting the contrast level with the trimpot (near the read arrow in the image), the display finally sprang to life. I had to rotate it completely counter-clockwise.

The test assembly looks like this – battery holder on top, JeeNode in the middle, LCD Plug at the bottom of the image. The LCD Plug is connected to Port 1 on the JeeNode.

The basic approach is this:

1. Use Cobbler as you normally would (you will trigger several SElinux denials, so expect errors)
2. Extract the relevant SElinux audit messages; convert them into a local policy
3. Load your local policy
4. Repeat steps 1..3 until everything works as expected

First attempt: the “cobbler import” command fails; rsync cannot access files on the mounted DVD ISO. Time to start writing a local policy!

The following command generates a basic SElinux policy from the SElinux audit messages:

  cat /var/log/audit/audit.log | audit2allow -l -v -m local > local.te

The resulting local.te file (ASCII, open it in your favorite editor) will list various items, some if which are not related to the Cobbler / Rsync operations. Edit the file to taste. Now, compile and load that policy:

  checkmodule -M -m -o local.mod local.te
  semodule_package -o local.pp -m local.mod
  semodule -v -i local.pp

Note: every invocation of “audit2allow -l” will overwrite your local.te policy file with new events since the last time a policy module was loaded. This is why you should keep backup copies of the previous versions so you can merge new events in with the existing ones.

In the end, you will end up with a policy in local.te like this:

module local 1.0;

require {
    type cobblerd_t;
    type cobbler_var_lib_t;
    type iso9660_t;
    type public_content_t;
    type rpm_var_lib_t;
    type rsync_etc_t;
    type security_t;
    type tmp_t;
    class capability { sys_module fsetid };
    class dir { add_name create getattr open read remove_name rmdir search write };
    class file { create getattr open read unlink write };
    class lnk_file create;
    class unix_dgram_socket create;
}

#============= cobblerd_t ==============
allow cobblerd_t cobbler_var_lib_t:lnk_file create;
allow cobblerd_t iso9660_t:dir { open read search getattr };
allow cobblerd_t iso9660_t:file { open read getattr };
allow cobblerd_t public_content_t:dir { write rmdir remove_name };
allow cobblerd_t rpm_var_lib_t:dir { open read search getattr write };
allow cobblerd_t rsync_etc_t:file create;
allow cobblerd_t security_t:dir read;
allow cobblerd_t self:capability fsetid;
allow cobblerd_t self:unix_dgram_socket create;
allow cobblerd_t tmp_t:dir { add_name create remove_name rmdir write };
allow cobblerd_t tmp_t:file { create getattr open read unlink write };