wpa_supplicant in debian/ubuntu/raspbian – getting it to work on your raspberry pi

Hi again,

This time, I will go through a couple of things that I learned today, which has bugged me for quite some time. It also took me forever to figure it out why I could not get it to work the way I wanted to. It also was not made easier with a recent change in the network management of Raspbian Jessie. Proper wifi configuration (on the command line) on the Raspberry Pi 3 with its built in wifi is simple, but not easy. This blog entry is about the scenario whan you do all your configuration on the command line. I have no clue on how to do it through any GUI tools.

What I wanted to do, could in principle be easily solved by the first two examples below, but I really wanted to both understand what I was doing, as well as having a flexible solution where my raspberry pi would also be a bit more mobile. By setting the ssid and wpa2 passwords directly in the /etc/network/interfaces file, I would have to remember and reconfigure the wifi configuration (prefreably before I unplug the device) if I were to move a raspberry pi from my home to my office (since they have different ssid:s and network configurations).

So i will touch these topics, since they are closely related:

  • Proper use of wpa_supplicant.conf in a wifi setup
  • Why on earth the raspberry pi claims a DHCP Ip address on eth0, wlan0, etc even if you configure a static IP address

For the quick solution, there are basically two scenarios:

  • If you want wifi, and are ok with DCHP: stay with the default configuration of /etc/network/interfaces, and just add a “network” section to /etc/wpa_supplicant/wpa_supplicant.conf
  • If you want wifi and a static IP address: The key items to remember is: id_str in /etc/wpa_supplicant/wpa_supplicant.conf and wpa-roam instead of wpa-conf in /etc/network/interfaces.

In the “jessie” release of Raspbian, the /etc/network/interfaces configuration changed from using wpa-roam to using wpa-conf to fit with the change to use a system component called dhcpcd. Basically, without any reconfiguration the dhcpcd daemon will monitor the states of any network interface (also eth0) and request an IP address from your DHCP server (which most likely is your internet router at home). In the bulk of installations, this is perfectly ok, even for advanced users, and for beginners it just works out of the box. The default configuration of the /etc/network/interfaces file will now expect you to use the stansa “iface xxx inet manual” instead of “iface xxx inet dhcp”. The DHCP stansa will still work, but is sort of redundant, since dhcpcd should be taking care of your DHCP requests.

Most how-to’s on the internet, showing you how to set up a static ip address on an interface, will work as expected (almost). You will get a static ip addres configured on your interface, but in the background you will also get a second ip address through the dhcpcd daemon, which you sadly will not see with the ifconfig -a command. You will, though, see it with either “hostname -I” or ip addr show“. One side effect (which is also merely more than an annoyance) is that you get a second route to your default gateway. Since the route you configure with your static ip configuration takes precedence, you will not even notice it, but it is there (which is seen by using “netstat -nr” or “ip route show“.

Wifi configurations that come quickly to a decently round up linux admin (which would not at all use the wpa_supplicant.conf):

  • Putting the ssid and WPA2 password directly in the /etc/network/interfaces, using DHCP
allow-hotplug wlan0
iface wlan0 inet dhcp
wpa-ssid "MY_SSID"
wpa-psk "MY_SECRET_PASSWORD"
  • Using the ssid and WPA password directly in the /etc/network/interfaces, using static IP configuration
allow-hotplug wlan0
iface wlan0 inet static
wpa-ssid "MY_SSID"
wpa-psk "MY_SECRET_PASSWORD"
address 192.168.3.11
netmask 255.255.255.0
network 192.168.3.0
broadcast 192.168.3.255
gateway 192.168.3.1
dns-nameservers 192.168.3.1

Although both these ways of configuring the wifi on my raspberry pi works, they are both very static. As mentioned above, I would have to re-configure the /etc/network/interfaces file before I shut the raspberry pi down if I were to move it to another wifi network. I would like to just shut it down, move it, and start it up with a working configuration.

In the second case I would also get that “shadow” ip address:

pi@raspberrypi:~ $ hostname -I
192.168.3.11 192.168.3.133

The difference between “wpa-conf” and “wpa-roam” in the /etc/network/interfaces file, is that when you use “wpa-conf” you should not be moving your gear around that much. If you want to use DHCP, just set up your network in the /etc/wpa_supplicant/wpa_supplicant.conf or directly in your /etc/network/interfaces file. One network to rule them all. If you move your device, you should be prepared before you shut down, or be prepared for a big hassle when you arrive at your new destination. When using “wpa-roam” you should either accept that you get a shadow IP address, or disable the wlan0 interface in the dhcpcd configuration, or turn off dhcpcd once and for all.

I set up a simple test, which still turned out to be 20 scenarios to go through. Sorry for the crappy table format. The table is mostly for show. Green is where the configuration is ok, yellow is where it looks to work at first glance but there is something lurking in the background.

Test#  Config file:
/etc/network/interfaces
DHCPCD enabled ->
“sudo update-rc.d dhcpd enable; sudo shutdown -r”
DHCPCD disabled ->
“sudo update-rc.d dhcpd enable; sudo shutdown -r now”
1 allow-hotplug wlan0
iface wlan0 inet dhcp
wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf

works (ping 192.168.3.1)
dhclient -v … is running
works (ping 192.168.3.1)
dhclient -v … is running
2 allow-hotplug wlan0
iface wlan0 inet manual
wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf

works (ping 192.168.3.1)
no dhcp client running after reboot
does not work, but if you start the dhclient manually, you will get an ip address
3 allow-hotplug wlan0
iface wlan0 inet static
wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf

invalid config without the “address” variable invalid config without the “address” variable
4 allow-hotplug wlan0
iface wlan0 inet static
wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf
address 192.168.3.11

Works (ping 192.168.3.1)
ifconfig show only one IP address
“ip addr show” shows 2 ip addresses
“netstat -nr” show a default route (from dhcp)
Works (ping 192.168.3.1), but no default route
ifconfig show only one IP address
“ip addr show” shows 1 ip addresses
“netstat -nr” show no default route (from dhcp)
5 allow-hotplug wlan0
iface wlan0 inet static
wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf
address 192.168.3.11
# bad gateway address
gateway 192.168.3.99

Works (ping 192.168.3.1), but no default route
ifconfig show only one IP address
“ip addr show” shows 2 ip addresses
“netstat -nr” show 2 default routes (from dhcp), but the bad one has precedence
when removing the bad route “sudo route del -net 0.0.0.0 gw 192.168.3.99” all works
Works (ping 192.168.3.1), but no default route
ifconfig show only one IP address
“ip addr show” shows 1 ip addresses
“netstat -nr” show no default route (from dhcp)
6 allow-hotplug wlan0
iface wlan0 inet static
wpa-conf /etc/wpa_supplicant/wpa_supplicant.confiface stg inet static
address 192.168.3.11
netmask 255.255.255.0
gateway 192.168.3.1
broadcast 192.168.3.255
dns-nameservers 192.168.3.1

does not work, missing required variable: address does not work, missing required variable: address
7 allow-hotplug wlan0
iface wlan0 inet manual
wpa-conf /etc/wpa_supplicant/wpa_supplicant.confiface stg inet static
address 192.168.3.11
netmask 255.255.255.0
gateway 192.168.3.1
broadcast 192.168.3.255
dns-nameservers 192.168.3.1

Works (ping 192.168.3.1)
ifconfig show only one IP address
“ip addr show” shows 1 ip addresse (dhcp)
“netstat -nr” show a default route (from dhcp)
does not work, although “sudo wpa_cli status” show proper connection to the ssid
running “dhclient -v …” gives wlan0 an IP address
8 allow-hotplug wlan0
iface wlan0 inet manual
wpa-roam /etc/wpa_supplicant/wpa_supplicant.confiface stg inet static
address 192.168.3.11
netmask 255.255.255.0
gateway 192.168.3.1
broadcast 192.168.3.255
dns-nameservers 192.168.3.1

Works (ping 192.168.3.1)
proper gw, dns, all
wpa_cli status” show proper connection
“ip addr show” shows 2 ip addresses
“netstat -nr” shows 2 routes to the default gateway
Works (ping 192.168.3.1)
proper gw, dns, all
wpa_cli status” show proper connection
“ip addr show” shows only 1 ip address
9 command line:
echo “denyinterfaces wlan0” | sudo tee -a /etc/hdcpcd.conf
sudo service dhcpcd restart/etc/network/interfaces

configuration:
allow-hotplug wlan0
iface wlan0 inet manual
wpa-roam /etc/wpa_supplicant/wpa_supplicant.confiface stg inet static
address 192.168.3.11
netmask 255.255.255.0
gateway 192.168.3.1
broadcast 192.168.3.255
dns-nameservers 192.168.3.1

Works as expected. Static IP set.
Ping 192.168.3.1 ok
proper gw, dns, all
wpa_cli status” show proper wifi connection
“ip addr show” shows 1 ip address
“hostname -I” shows 1 ip address
“netstat -nr” shows 1 default route
n/a, will work, see test 8
10 command line:
echo “denyinterfaces wlan0” | sudo tee -a /etc/hdcpcd.conf
sudo service dhcpcd restart/etc/network/interfaces

configuration:
allow-hotplug wlan0
iface wlan0 inet manual
wpa-roam /etc/wpa_supplicant/wpa_supplicant.confiface default dhcp

Works as expected. DHCP address.
“wpa_cli status” show proper wifi connection
dhclient -v … is running
Ping 192.168.3.1 ok
proper gw, dns, all
wpa_cli status” show proper wifi connection
“ip addr show” shows 1 ip address
“hostname -I” shows 1 ip address
“netstat -nr” shows 1 default route
n/a, will work, see test 8

You can ignore your wlan0 interface by doing the following (which will survive a reboot).

echo "denyinterfaces wlan0" | sudo tee -a /etc/dhcpcd.conf
sudo service dhcpcd restart

In the end, the choice is yours. If you are decently experienced and you disable dhcpcd, you will not lose much at all. I would even recommend it.

  • Disable dhcpcd
sudo update-rc.d dhcpcd disable
sudo service dhcpcd stop
# sudo shutdown -r now
  • /etc/wpa_supplicant/wpa_supplicant.conf
country=GB
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1

network={
  ssid="AT_HOME"
  psk="SUPERSECRET"
  id_str="HOME_SSID"
  priority=15
}

network={
  ssid="OFFICE_SSID"
  psk="SUPERSECRET"
  id_str="OFFICE"
  priority=14
}
  • /etc/network/interfaces
auto lo
iface lo inet loopback

allow-hotplug wlan0
iface wlan0 inet manual
    wpa-roam /etc/wpa_supplicant/wpa_supplicant.conf

iface default inet dhcp

iface HOME inet static
  address 192.168.2.11
  netmask 255.255.255.0
  gateway 192.168.2.1
  broadcast 192.168.2.255
  dns-nameservers 192.168.2.1

iface OFFICE inet static
  address 192.168.3.11
  netmask 255.255.255.0
  gateway 192.168.3.1
  broadcast 192.168.3.255
  dns-nameservers 192.168.3.1

Useful commands:

  • wpa_cli status
  • sudo iw wlan0 scan | grep -i ssid
  • hostname -I
  • iwconfig wlan0
  • ip addr show
  • ip route show

References:

  • https://wiki.debian.org/WPA
  • http://manual.aptosid.com/en/inet-setup-en.htm
  • https://www.raspberrypi.org/forums/viewtopic.php?t=110606

Integrating a traffic light with OP5 through a Raspberry Pi

The last couple of months, I have been amazed about the Raspberry Pi. I won’t go into great detail on this wonderful device, other than the obvious.

  • It is cheap
  • It comes with Ethernet, HDMI
  • It runs Debian Linux
  • It has GPIO, general purpose input output, pins on the board

So, the device itself is just screaming for some interesting projects, interfacing with stuff that normally are not integrated with your IT stack. I’ve tried it out in a few different ways already, and I’ve bought a handful of devices. One of them has a fixed position, connected to my TV, running XBMC.

Well, let’s go back a few years in time. Quite many years, will say. Back to the days when I had just started growing a beard, and was just that naïve that only youngsters freshly out of high-school can be. I headed off to university and one of the first day of the introduction week we went to the student pub. There I saw one of the coolest things since the invention of sliced bread, a pedestrian crossing light.

Normally, such thing would not leave that much of an impression with me, but this one was special. Our own student pub was one of three student pubs in the same basement corridor. But there was only one WC. In principle, this was not a problem early in the evening, but as the night went on, the line to the WC was an annoyance. In our pub, the one with the crossing light, we were less stressed about it than people in the other pubs, since our crossing light was connected to the lock of the WC door. Whenever the lock was locked, our crossing light was red; hence when the door was unlocked it was green.

When we relocated the pub, we ended up in a location where the WC situation was much better. I had personally made sure that we brought the crossing light with us, but I could never come up with as good of a use for it. This was a long time ago, but the bright idea (pun intended) stuck with me over the years.

When I implemented Nagios/OP5 at my new workplace, I started playing with the thought that I wanted some way of raising the attention of the monitoring with my guys. The classical “big screen on the wall” was of course one of the first things that crossed our minds. This was easy, and people notice it – goal achieved. But I wanted something else, something more… catchy.

Just by a coincident, I got in contact with a guy who is responsible for replacing old bulb-based traffic lights with new LED-based traffic lights. He gave me a handful of 3-light (red, yellow, green) pedestrian crossing lights, and now I was able to get going with my latest project.

A Nagios/OP5 installation that shows service states on a traffic light.

Note that you are on your own when connecting the things together. If you are not completely sure of what you are doing, then don’t. I’ve been doing things like this for a while, so I trust myself. But I do not take any responsibility what so ever for any mistakes you do yourself. This project involves 220V, which can be lethal. Don’t blame me if things go bo-boo. End of disclaimer.

 

This is the conceptual view:

All in all, I’ve got a Nagios/OP5 installation in a virtual machine. In this example, one of my services is configured with an event handler, pointing to a command configured in checkcommands.cfg. I decided that the communication between my monitoring system and the Raspberry Pi would go over nrpe, which is anyways the standard Nagios Agent. Adding a couple of scripts on the server to take care of events, and the client side, to control the GPIO, was fairly simple.

Let us go through the whole chain on both hosts, the Nagios/OP5 system and the Raspberry Pi. I will start in a reverse order, as the Nagios configuration is simple and does not require much of explanation. Which service to chose for your traffic light is up to you. There are a couple of interesting constructs that come with OP5, that is not readily available out of the box in a Nagios installation. One of these is the “Business process view”, that allows you to perform logical operations on service states. You can also create new services from these aggregations. I will leave this part out of this blog entry, but the principle is so easy, that if you manage with the rest in this article, your should not have a hard time figuring that part out either.

In principle, I just chose one service and added an event_handler to it. That’s it. The event_handler is configured as any other command in the _checkcommands.cfg_ file. An event handler should take care of a couple of checks, so that you are sure that you really want to do something when the event hander is triggered, as it is triggered quite often. Basically, check the state (OK, WARNING, CRITICAL) and the state type (hard, soft) and make up your mind.

As mentioned before, I chose to use _check_nrpe_ to integrate Nagios with my Raspberry Pi, since it is readily available and very simple to configure. All I need to do, is to remotely run a script on the Raspberry Pi, which nrpe allows me to do after a very simple configuration. I just had to come up with a name for my remote command, add it to the nrpe configuration on the Raspberry Pi, restart nrpe, and start using check_nrpe on the Nagios/OP5 server.

On the Nagios/OP5 server, you need to get the following into your configuration files. When using OP5 there is a very simple web-gui to do this in. Othervise just fire up your favorite editor (which should be _vi_).

Here is the service in the Nagios/OP5 services.cfg for my dummy service to monitor and display on the traffic light. The magic is in the sauce, I mean event_handler:

1
2
3
4
5
6
7
8
# service 'remote debug'
define service{
  use default-service
  host_name pi-s001
  service_description remote debug
  check_command check_nrpe!-H $HOSTADDRESS$ -c kmg_dummy
  event_handler event_ampel
}

This event handler is configured in the Nagios/OP5 configuration file checkcommands.cfg. Note the arguments I am sending to the script.

  • $SERVICESTATE$ – Nagios macro for the current state of the service
  • $SERVICESTATETYPE$ – Nagios macro for the current type (soft or hard) of the service
  • $HOSTNAME$ – Nagios macro for the service’s host
  • $SERVICEDESC$ – Nagios macro for the name of the service
  • $SERVICEATTEMPTS$ – Nagios macro for the number of attempts
1
2
3
4
5
6
</div>
# command 'event_ampel'
define command{
  command_name event_ampel
  command_line $USER1$/kmg/event_ampel $SERVICESTATE$ $SERVICESTATETYPE$ $HOSTNAME$ $SERVICEDESC$ $SERVICEATTEMPT$
}
The $SERVICEATTEMPTS$ macro together with the $SERVICESTATETYPE$ and the $SERVICESTATE$ gives you the possibility to actually try and fix a problem before Nagios/OP5 even has notified a sysadmin. In a default installation/config, Nagios will test a service so many times before it is a hard CRITICAL, which is notified to the outside world. If you write your event handler in such way, that it tests these parameters, i.e service state = CRITICAL, type = soft, service attempts = 3, then you can perform something like restarting a server, before waking up the sysadmin. My event handler is a bit simpler than that. I am just to trigger a relay, controlling a light bulb, so I skipped some of that. This is the event handler script:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
#!/usr/bin/ksh

state=$1
statetype=$2
serviceHost=$3
service=$4
serviceattempt=$5

raspberryPi=10.64.150.5

logfile=/opt/monitor/var/eventhandler.log

# Sep 25 14:53:14
date=`date +"%b %d %H:%M:%S"`

case "$state" in
  OK)
    command=kmg_ampel_green
    ;;
  WARNING)
    command=kmg_ampel_yellow
    ;;
  CRITICAL)
    command=kmg_ampel_red
    ;;
esac
/bin/echo -en "$date; restart_windows_service.sh; $serviceHost:$service; Got a $statetype $state at try $serviceattempt, sending $command to host $raspberryPi " >> $logfile

/opt/plugins/check_nrpe -H $raspberryPi -c $command >> $logfile
echo "Set Ampel ok"

If you by any chance had the Raspberry Pi setup and running already, you could test the event handler and the integration in two ways from the Nagios/OP5 host:

1
2
3
4
5
6
#--- check that nrpe works (i.e allowed_hosts on the pi is set properly)
op5$ /opt/plugins/check_nrpe -H 10.64.150.5
#--- check that the commands config on the pi works
op5$ /opt/plugins/check_nrpe -H 10.64.150.5 kmg_ampel_green
#--- check that the whole stack works
op5$ ./event_ampel kmg_ampel_red

So far, the Nagios configuration. We also need the relay control and the Raspberry Pi configuration. This is the hardware you need to complete this project:

  • One Raspberry Pi
  • 5V DC source (Micro USB charger)
  • 12V DC source (to drive the relays)
  • 3 x 5kOhm resistors
  • 3 x BC237C transistors
  • 3 x Relays, 12VDC activation/250AC switching
  • A few cables.
I used a 12V/DC power source to drive the relays, since I could not quickly find any 5V/DC relays. If you do find such relays, just connect the Raspberry Pi pin 2 (5V) to the driver, and you will save yourself a couple of bucks.
Install the Debian Squeeze on a SD card, enable SSH, and expand the root fs at the first boot. Then log into your box and install ksh and nagios-nrpe-server.
1
2
sudo apt-get install ksh
sudo apt-get install nagios-nrpe-server

That is basically it. You will survive without ksh, but since I am an old fart, I tend to stick to what I know from before. Ksh was there in the dawn of UNIX. In the good old days, it was the bread and butter of decent scripting. Nowadays you’ll manage with bash, and wont miss ksh a lot. More about that in a different blog post. If you don’t care for ksh, just change the references to it in my examples to bash.

Now we will configure the nrpe daemon correctly.

1
2
3
4
5
6
7
8
9
10
11
12
pi@raspberrypi /etc/nagios $ grep allowed_hosts nrpe.cfg
allowed_hosts=127.0.0.1,192.168.2.34,194.40.128.84
pi@raspberrypi /etc/nagios $ cat nrpe.d/kmg_commands.cfg
command[kmg_ampel_red]=/app/prd/op5/bin/ampel red
command[kmg_ampel_yellow]=/app/prd/op5/bin/ampel yellow
command[kmg_ampel_green]=/app/prd/op5/bin/ampel green
command[kmg_ampel_blink]=/app/prd/op5/bin/ampel blink
command[kmg_ampel]=/app/prd/op5/bin/ampel blink
command[kmg_dummy]=/app/prd/op5/bin/dummy
pi@raspberrypi /etc/nagios $ sudo /etc/init.d/nagios-nrpe-server restart
[ ok ] Stopping nagios-nrpe: nagios-nrpe.
[ ok ] Starting nagios-nrpe: nagios-nrpe.

With that taken care of, the integration between the Nagios/OP5 server and the Raspberry Pi is set up. The best way to test this is the commands in one of the examples above (check_nrpe -H 10.64.150.5). If that doesn’t work, kill the nrpe process on the Raspberry Pi with “kill” and start it again. That usually solves most problems.

Interfacing with the GPIO ports is extremely easy in the Debian/Raspbian squeeze. You just echo some commands to files in the /sys filesystem. Firstly you’ve got to enable some GPIO ports and set the direction. I’ve done this in a startup script, /etc/init.d/ampel, to which I also symbolically linked /etc/rc2.d/S99ampel so that it will automatically do this at reboot. Debian is a weird beast, though. Note that I put the startup script in rc2.d, which is the default runlevel for Debian, whereas I would have put this in rc3.d on an Ubuntu box.

Here is my /etc/init.d/ampel script:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
#!/usr/bin/ksh
# /etc/init.d/ampel
#

### BEGIN INIT INFO
# Provides: ampel
# Required-Start:
# Required-Stop:
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: Ampel
# Description: Ampel
### END INIT INFO
################################################################################

TS=$(date "+%Y%m%d %H:%M:%S")
echo "$TS; $0 $1" >> /var/log/ampel.log

case $1 in
  start)
    echo "$TS; setup gpio" >> /var/log/ampel.log

    echo "17" > /sys/class/gpio/export
    echo "18" > /sys/class/gpio/export
    echo "21" > /sys/class/gpio/export

    echo "out" > /sys/class/gpio/gpio17/direction
    echo "out" > /sys/class/gpio/gpio18/direction
    echo "out" > /sys/class/gpio/gpio21/direction

#--- to rid the sudo part - change the permissions

    chmod 666 /sys/class/gpio/gpio17/value
    chmod 666 /sys/class/gpio/gpio18/value
    chmod 666 /sys/class/gpio/gpio21/value
    ;;
esac
This makes sure that the GPIO pins are correctly set, which you can control in the file system by checking the /sys/class/gpio directory. Note that I am changing the file permissions for the “value” files. If you don’t do this, you must write to these files as root, which is easily done by using “sudo”. But since the Raspberry Pi isn’t a state of the art box when it comes to security anyways, I just decided that if you by any chance is logged in to the system, you should be able to set these values, never mind which user you are.
If you see “your” gpio pins there, you should be fine.
1
2
3
4
5
6
7
8
9
10
pi@raspberrypi ~ $ ls -la /sys/class/gpio/
total 0
drwxr-xr-x 2 root root 0 Aug 16 16:58 .
drwxr-xr-x 26 root root 0 Aug 16 16:58 ..
--w------- 1 root root 4096 Aug 16 16:58 export
lrwxrwxrwx 1 root root 0 Aug 16 16:58 gpio17 -> ../../devices/virtual/gpio/gpio17
lrwxrwxrwx 1 root root 0 Aug 16 16:58 gpio18 -> ../../devices/virtual/gpio/gpio18
lrwxrwxrwx 1 root root 0 Aug 16 16:58 gpio21 -> ../../devices/virtual/gpio/gpio21
lrwxrwxrwx 1 root root 0 Aug 16 16:58 gpiochip0 -> ../../devices/virtual/gpio/gpiochip0
--w------- 1 root root 4096 Aug 16 16:58 unexport
The nrpe configuration in /etc/nagios/nrpe.d/kmg_commands.cfg points out the /app/prd/op5/bin/ampel script, which is merely a wrapper, if there were anything clever to be done before actually switching the relays. In this example, I am not logging anything, and there is very little magic around it. It is usually wise to have such a wrapper between nrpe and whatever you want to perform on the system; for me it comes naturally to do it this way.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
#!/usr/bin/ksh

ampel_bin=/app/prd/ampel/bin
#ampel="sudo $ampel_bin/setAmpel_a1"
ampel="$ampel_bin/setAmpel_a1"

blink(){
  $ampel all
  sleep 0.2s
  $ampel none
  sleep 0.2s
  $ampel all
  sleep 0.2s
  $ampel none
  sleep 0.2s
}

red(){
  blink
  echo "  - Set ampel to: red"
  $ampel red
}
yellow(){
  blink
  echo "  - Set ampel to: yellow"
  $ampel yellow
}
green(){
  blink
  echo "  - Set ampel to: green"
  $ampel green
}

echo "Ampel"
case $1 in
  red)
    red
    ;;
  yellow)
    yellow
    ;;
  green)
    green
    ;;
  blink)
    blink
    ;;
esac

exit 0
In the end, this wrapper will execute the “$ampel” script, which is set to “/app/prd/ampel/bin/setAmpel_a1” with one parameter; red, yellow, green, or blink. This is the setAmpel_a1 script:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
#!/usr/bin/ksh

#-----------------------------
# Base configuration
#-----------------------------
this_dir=$(cd `dirname $0`; pwd)
base_dir=$(cd `dirname $0`/..;pwd)

. $base_dir/conf/gpio.conf

off=0
on=1

red(){
  echo "$on" > /sys/class/gpio/gpio${a1red}/value
}

yellow(){
  echo "$on" > /sys/class/gpio/gpio${a1yellow}/value

}

green(){
  echo "$on" > /sys/class/gpio/gpio${a1green}/value
}

none(){
  echo "$off" > /sys/class/gpio/gpio${a1red}/value
  echo "$off" > /sys/class/gpio/gpio${a1yellow}/value
  echo "$off" > /sys/class/gpio/gpio${a1green}/value
}

all(){
  echo "$on" > /sys/class/gpio/gpio${a1red}/value
  echo "$on" > /sys/class/gpio/gpio${a1yellow}/value
  echo "$on" > /sys/class/gpio/gpio${a1green}/value
}

#================================
# MAIN
#================================
case $1 in
  red)
    none
    red
    ;;
  yellow)
    none
    yellow
    ;;
  green)
    none
    green
    ;;
  none)
    none
    ;;
  all)
    all
    ;;
esac
That’s all folks!