eulinux

Gather metrics from a Dutch smart meter via hass & usb2net

2020-10-26T00:00:00+01:00

Preface

Modern electricity/gas meters in the Netherlands support the so-called DSMR standard(is it even a standard?), also known as Slimme meter, or P1 poort. One can easily find a FTDI-based "P1 cable" in many on-line Dutch shops (will not link to a particular one but a quick internet search on "P1 cable" or "P1 slimme meter kabel" will return more than enough results).

Collecting data

To collect the data from your meter, you would use this "USB-to-P1 cable" (for the lack of a better name), and some software, e.g DSMR reader, or HomeAssistant (see the DSMR integration)

Since my home lab is nowhere close to the "meterkast", I would have needed a really long USB cable... Instead, we can fix this with science! A quick search through my modest hardware pile produced a Raspberry Pi 1 (the original!), a short network cable, an SD card and a pl2303-based USB to TTL adapter (see Serial console on a Raspberry Pi), and the idea to use ser2net emerged, as the dsmr reader integration supports it.

Here comes OpenWRT

Raspbian or anything as heavy as that would be overweight for this old board, so I went for OpenWRT, really lightweight (the final install uses around 14MB), and easy to configure.

I followed the official OpenWRT on Raspberry Pi docs for the installation, and performed the initial configuration (network, root password, etc) via the serial console. After making sure that the system can be reached via ssh, I moved it next to the smart meter.

To use the FTDI adapter, and ser2net, we need to install some prerequisites first:

opkg update
opkg install ser2net
opkg install kmod-usb-serial-ftdi

There's already a (disabled) ser2net config for ttyUSB0:

# uci show ser2net
...
ser2net.@proxy[1]=proxy
ser2net.@proxy[1].enabled='0'
ser2net.@proxy[1].port='5001'
ser2net.@proxy[1].protocol='telnet'
ser2net.@proxy[1].timeout='0'
ser2net.@proxy[1].device='/dev/ttyUSB0'
ser2net.@proxy[1].baudrate='115200'
ser2net.@proxy[1].databits='8'
ser2net.@proxy[1].parity='none'
ser2net.@proxy[1].stopbits='1'
...

The ser2net proxy has been enabled, and some serial parameters had to be changed as my meter is an Iskra which uses the 2.2 version of DSMR::

root@OpenWrt:~# uci set ser2net.@proxy[1].enabled=1
root@OpenWrt:~# uci set ser2net.@proxy[1].protocol='raw'
root@OpenWrt:~# uci set ser2net.@proxy[1].baudrate=9600
root@OpenWrt:~# uci set ser2net.@proxy[1].parity=even
root@OpenWrt:~# uci set ser2net.@proxy[1].databits=7
root@OpenWrt:~# service ser2net enable
root@OpenWrt:~# service ser2net start

telnet can be used to validate that this actually works (a "telnet <ip> 5001" would return several lines of data every 10 seconds).

At this point, I could follow the DSMR integration docs to add the meter to HomeAssistant.

Bonus: prometheus metrics

HomeAssistant has a Prometheus integration. Short config excerpt for exporting only the DSMR metrics to prometheus:

# configuration.yaml
prometheus:
  namespace: hass
  filter:
    include_entity_globs:
      - sensor.energy_*
      - sensor.gas_*
      - sensor.power_consumption
      - sensor.power_production
      - sensor.power_tariff

Bonus: prometheus metrics take 2

It looks like there's even a prometheus-node-exporter clone in OpenWRT, that can provide a bunch of system metrics (if you're running Prometheus for your network monitoring of course):

opkg install prometheus-node-exporter-lua
uci set prometheus-node-exporter-lua.main.listen_interface=lan
service prometheus-node-exporter-lua enable

Serial console on a Raspberry Pi

2020-10-25T00:00:00+02:00

Tested on: Raspberry Pi 1, model A+, Raspberry Pi 1 model B

To enable a login serial console on your RaspberryPi running Alpine Linux, run:

echo "ttyAMA0::respawn:/sbin/getty -L ttyAMA0 115200 vt100" >> /etc/inittab
echo "ttyAMA0" >> /etc/securetty
lbu commit -d

A USB-to-TTL cable will be required, I've used some no-name, pl2303-based cable that came with one of my Rasbperry Pi orders. The following pins have to be connected (see the official pinout documentation ):

GND (usually black) to 'Ground' (3nd pin from the top)
RX (white?) to TXD (GPIO 14), 4th pin
TX (green?) to RXD (GPIO 15), 5th pin

My cable also has a 5V wire (red), that can be used to provide power to the Raspberry board via the first pin on the GPIO header, but only for the low power boards like the Zero, or the A+ (not 3A+, but the original 1A+. If your board is powered in a 'traditional' way (via the microUSB socket), DO NOT connect the 5V line, you might (and probably will) fry something.

If the board boots up successfully, you can attach to the serial console by running, e.g, screen /dev/ttyUSB0 115200 (provided that your pl2303 cable is at /dev/ttyUSB0)

Serial console access to MikroTik devices

2020-03-15T00:00:00+01:00

RB2011

Baud rate: 115200
Data bits: 8
Parity: none

A standard Cisco/Arista-compatible rj45 console cable should just work™

Backup mikrotik router configs with rancid

2020-02-08T00:00:00+01:00

Ok, I've had this running for years now, so this is mostly a 'do not forget' note-to-self. Rancid supports backing up MikroTik RouterOS configuration.

Add a readonly user to your RouterOS device:

/user add group=read name=rancid disabled=no password=huwakui5phiiVahnuecheiri
# use a long random password

Add the user/password to your .cloginrc:

add user 10.0.0.1 rancid
add noenable 10.0.0.1 1
add password 10.0.0.1 huwakui5phiiVahnuecheiri
add method 10.0.0.1 ssh

... and add the router to router.db:

10.0.0.1;mikrotik;up

Manipulating yaml data on the CLI

2019-10-06T00:00:00+02:00

If you have ruby and jq installed, it's as easy as adding a function to your ~/.bashrc (or .kshrc):

function yaml2json()
{
    ruby -ryaml -rjson -e \
         'puts JSON.pretty_generate(YAML.load(ARGF))' $*
}

And then yaml2json document.yaml|jq ...

Make your scripts better with shellcheck

2019-09-18T00:00:00+02:00

Being a system engineer (or a fan of a UNIX-like OS) would most certainly mean that one is also writing shell scripts. If this is a daily thing, a pattern has probably emerged in the way the scripts are written, a certain style is used in all those scripts. This does not necessarily mean that the style is good (how to define good?) or that the scripts are completely correct and portable.

Many programming languages have their own style and syntax check tools (the interpreter or compiler itself could serve as the ultimate validator, but some mistakes in the code might not make the script invalid, and only alter it's behavior and make it work in unintended ways).

Luckily, a similar tool exists for shell scripts as well.

Please use it, it will help you write portable scripts and spot issues that might only happen in odd an inappropriate moments. Just think about adding an extra space in the wrong place of a full path:

# rm -rf / tmp/bla
         ^^^

... or using an undefined variable in a similar statement:

# rm -rf ${mypath}/*
#           ^^- what if this is undefined?

... or using relative paths and launching your script in the wrong directory?

# rm -rf *

BTW, shellcheck is available on OpenBSD as well, as a package:

doas pkg_add shellcheck

In search of the perfect browser

2018-12-03T00:00:00+01:00

Please take this with a grain of salt, this is not a real technical article. Consider it a 'rant about browsers'

Modern day browsers are, in general, steaming piles\^W\^W almost full operating systems. You can even emulate x86 hardware in the browser (e.g: jemul8). This is not completely the web browsers' 'fault', it's more like the WWW lost it's initial meaning (see the Architecture of the World Wide Web, Volume One introduction).

Disregard the 'steaming pile' above, at least the mainstream browsers out there are some rather advanced pieces of technology. But as they say, with great complexity comes great responsibility. There are so many aspects that are quite tricky (if we're talking about security). I'm not even talking about various tracking mechanisms built into some browsers (this is more about privacy than security though).

Also, to prevent complexity from getting in the way, one needs a lot of processing power for a pleasant interaction with the browser.

Going back to the title: I still didn't find a perfect browser (by 'perfect', I mean something that would suit my needs, and not frustrate me at the same time).

Some of the requirements:

secure
fast
reasonable resource usage (doesn't need a octa-core system with 32G of ram, just to open a web page)
configurable

Try running Firefox/Chromium on an old Atom-based single-core netbook. It will work, but makes you want to smash that poor thing against the wall, if all you need is a quick web search for a 'chili con carne' recipe.

I've been using Iridium for quite a while, but still not completely satisfied with it.

Of course, there are always things like w3m which is close to obsolete, last release was somewhere around 2011 (I still use it as a html previewer with mutt), or lynx (using it for visiting gopher 'sites'), or links2 which even has graphics support.

Recently I've rediscovered vimb, thanks to this thread on reddit. For sure it is fast, and doesn't use too many resources (with JS off). Can't make a statement about how secure it is though. As secure as WebKit gets, I assume.

Do you really need a fancy terminal emulator?

2018-08-11T00:00:00+02:00

Over the years I've been using multiple Linux distros, and was always trying new terminal emulators. Each of them comes with a bunch of eye-candy features, and it's too hard to settle on one of them.

Just try running pacman -Ss terminal emulator (if you're on Arch of course. Otherwise use your favourite package manager. ) What one should actually do, is ask oneself, "Do I really need a fancy terminal emulator?"

After switching to OpenBSD, I settled on xterm. Now whenever I'm on Linux, I use xterm as well.

It's light, it's simple, it's in base in OpenBSD. Since quite a while it also supports utf8.

It's easy to configure:

# .Xresources:
XTerm*font:             -xos4-terminus-medium-*-*-*-14-*-*-*-*-*-*-*
XTerm*dynamicColors:    true
XTerm*utf8:             2
XTerm*eightBitInput:    false
XTerm*scrollBar:        false
XTerm*loginShell:       true
XTerm*background:       black
XTerm*foreground:       green

Some additional tips: Define custom actions for specific key combinations, in this example - zoom in/out

xterm*VT100.Translations: #override \
    Ctrl <Key> minus: smaller-vt-font() \n\
    Ctrl <Key> plus: larger-vt-font() \n\
    Ctrl <Key> 0: set-vt-font(d)

Define custom sizes for the VT font:

! VT Font Menu: Unreadable
xterm*faceSize1: 8
! VT font menu: Tiny
xterm*faceSize2: 10
! VT font menu: Medium
xterm*faceSize3: 12
! VT font menu: Large
xterm*faceSize4: 16
! VT font menu: Huge
xterm*faceSize5: 22

httpd/relayd behind a reverse proxy on OpenBSD

2018-07-30T00:00:00+02:00

Tested on: OpenBSD 6.4 - 6.6

I'm moving some of my homelab infrastructure to OpenBSD, and in the meantime I have to use httpd(8) behind a reverse proxy. Issue being: httpd doesn't support extracting the real IP address from headers like X-Forwarded-for, and you can't really log the actual IP of the client. Granted, I was in control of my reverse-proxy so I could log the info there, but we can make a nice learning experience out of this 'issue'.

relayd(8) to the rescue!

Since the httpd's log format cannot be changed, we can stick relayd in front of it and use it to log the data we need (see relayd.conf(5) for more details). The match ... log directives can be used to add additional fields to the log. In this case I wanted to log the Host, Referer, User agent, and reverse proxy IP. And since relayd only logs connection details by default, I added th url as well:

    webhost="127.0.0.1"
    web_port="80"
    table <webhosts> {$webhost}

    log state changes
    log connection

    http protocol "httpfilter" {

        # Add custom fields to the log:
        match header log "Host"
        match header log "X-Forwarded-For"
        match header log "User-Agent"
        match url log
        match header log "Referer"

        match request header "Host" value "example.com" forward to <webhosts>
    }

    relay "http" {
        listen on 0.0.0.0 port 80
        protocol "httpfilter"
        forward to <webhosts> port $web_port check tcp interval 60
    }

httpd will of course only see (and log) '127.0.0.1' as the remote host, although relayd will happily log everything:

Aug  2 06:01:48 puffy relayd[46936]: relay http, session 27 (1 active), 0, 10.10.4.200 -> 127.0.0.1:80, done, [Host: example.com] [X-Forwarded-For: 10.10.4.1] [User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.99 Safari/537.36] [example.com/] GET;
Aug  2 09:33:11 puffy relayd[19347]: relay http, session 29 (1 active), 0, 10.10.4.200 -> 127.0.0.1:80, done, [Host: example.com] [X-Forwarded-For: 181.101.XXX.XXX] [User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.3440.75 Safari/537.36] [example.com/] GET;

In this case 10.10.4.200 is the reverse proxy, 10.10.4.1 is the local gateway doing hairpin nat for another local network (more about this - maybe later).

Update:

Since OpenBSD 6.6 httpd supports a new log format (forwarded) so relayd is technically not required (if this is it's only purpose).

So, go to your httpd.conf(5) and replace:

log style common

with:

log style forwarded

Running OpenBSD on a Hetzner.de server

2018-07-10T00:00:00+02:00

Disclaimer: I'm not running any servers at Hetzner currently, and cannot give you any recommendations over the quality of their services.

You know you just can't pass those cheap hetzner dedicated servers. I mean, come on, EUR24/month for your own dedi? Sign me up!

There's only one problem with Hetzner: you can only choose from some predefined OSs, and you need to jump through hoops if you want a custom install.

I wanted to run OpenBSD, and of course there's no OS image available. Now, there are two options:

request a kvm so you could mount your own .iso file, and do a custom install (but that will require you to talk to support, and you only get the kvm console for a few hours), or:
hack it in using the rescue console and qemu ;)

First of all, you will need an install image that has the serial console enabled. On your OpenBSD machine (you're already running OpenBSD, right? ;), download the latest installXX.fs (minirootXX.fs will do, too). Then, you need to modify boot.conf inside the install image.

    vnconfig -c vnd0 install63.fs
    mount /dev/vnd0a /mnt/
    echo "stty com0 115200" >> /mnt/etc/boot.conf
    echo "set tty com0" >> /mnt/etc/boot.conf
    umount /mnt/
    vnconfig -u vnd0

Sync your modified install63.fs to the server (which is already booted in the rescue console).

    # not sure why this was needed, qemu should do this internally
    root@rescue ~ # iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
    root@rescue ~ # qemu-system-x86_64 -m 4096 -hdb /dev/sda -hdc /dev/sdb \
        -hda install63.fs -net nic -nographic -serial mon:stdio -net user

At this point, you will be left in the serial console and should see OpenBSD booting. From here, just follow the standard OpenBSD installation process, or, in case your system has 2x HDDs/SSDs, follow the softraid installation guide as well.

After the installation is done (don't forget about installboot(8) if you're installing on softraid), you can try and see if this newly installed system boots:

    root@rescue ~ # qemu-system-x86_64 -m 4096 -hda /dev/sda -hdb /dev/sdb \
        -net nic -nographic -serial mon:stdio -net user

One last thing you'll have to do is to rename hostname.em0 to something else, depending on the NIC model available on your server. In my case, I had to:

    # cd /etc/
    # mv hostname.em0 hostname.re0

Exit qemu, and exit the rescue console. If the NIC configuration is correct, your new system should start responding to ping soon enough.

Elasticsearch tips #2: modifying and removing index settings

2017-10-23T00:00:00+02:00

Elasticsearch tip #2:

TL;DR: configure an index setting to null, to use the default

Quite often you might need to change an elasticsearch' index setting to something else than the default, e.g. to manually control the shard allocation process (allocating specific indices only on specific nodes):

# curl -XPUT localhost:9200/indexname/_settings -d '{ "index.routing.allocation.require._ip": "10.0.0.11,10.0.0.12" }'
{"acknowledged":true}

It's not clear how to go about resetting the setting (or, basically, removing it) (See updating index settings) There is a related feature, documented in Cluster Update Settings, which actually works for indices, too:

Resetting persistent or transient settings can be done by assigning a null value. If a transient setting is reset, the persistent setting is applied if available. Otherwise Elasticsearch will fallback to the setting defined at the configuration file or, if not existent, to the default value.

It turns out that the feature is indeed there, just not documented yet (see #22870). So, for example, to reset the allocation settings for the same index (see first example):

# curl -XPUT localhost:9200/indexname/_settings -d '{ "index.routing.allocation.require._ip": null }'
{"acknowledged":true}

Sidenote: this feature stopped working in ElasticSearch 5.4.0, because of an seemingly unrelated change that added an 'IP validator' for several index/cluster settings. I ran into it while upgrading from 5.0.2, and there is a fix for it in 5.4.1 already (I reported the bug to the ES team, see: #24709).

What would happen is:

# curl -XPUT localhost:9200/indexname/_settings -d '{ "index.routing.allocation.require._ip": null }'
{
 "error" : {
   "root_cause" : [
     {
       "type" : "null_pointer_exception",
       "reason" : null
     }
   ],
   "type" : "null_pointer_exception",
   "reason" : null
 },
 "status" : 500
}

Ansible: Using conditional role dependencies

2016-01-19T01:10:00+01:00

TL;DR: You can use when: in ${role}/meta/main.yml

A while ago I started using Ansible to provision some aspects of my lab and servers. At some point, for one of the roles being worked on (some elasticsearch mini-cluster in this particular case), a specific role needed to be applied to some servers, but only when a condition was met. There are a few ways in which this can be achieved:

Include your roles for specific hosts only, in site.yml, e.g:

# site.yml
- name: configure the elasticsearch cluster
  hosts:
    - elasticsearch_servers
  roles:
    - elasticsearch
- name: configure the data indexers on the master node only
  hosts:
    - elasticsearch_masters
  roles:
    - es_indexer

The above will work just as intended, but IMHO it's not too elegant, and requires you to define a second elasticsearch_masters host group.

Or, use role dependencies, by configuring a meta/main.yml to the elasticsearch role:

# roles/elasticsearch/meta/main.yml
---
dependencies:
  - role: es_indexer

However, this will apply the es_indexer to all the elasticsearch nodes. With only a small change we can beat it into submission: by using the when keyword:

# roles/elasticsearch/meta/main.yml
---
dependencies:
  - role: es_indexer
    when: es_master_node == True

Just remember to define es_master_node = True in your host_vars for the specific nodes (or use some other external variable if you have a dynamic inventory script with an external data source)

Logstash tips #1: Measuring logstash performance

2015-10-17T03:00:00+02:00

Earlier, I've mentioned that I intend to start a series of short notes and tips. Today, a new tip.

Logstash tip #1: measuring logstash performance

TL;DR: use the 'metrics' filter to gather metrics about your logstash instance.

A while ago I started using logstash for, well, collecting some logs, and storing them in Elasticsearch.

Everything works like a charm most of the time, if you've got your filters right... except for the fact that logstash itself does not provide any insight into how it is performing. How many messages per second are being processed, etc etc. Of course, you can get that data from Elasticsearch. And that's a good solution most of the time. If it works for you - fine, stop reading :)

Thing is, in my specific setup I'm only indexing a fraction of the logs to Elasticsearch, everything else gets dropped.

Enter the logstash metrics filter. You can pretty much count anything in logstash using this filter.

In my logstash pipeline, I'm adding a logtype field to all my inputs, so let's say the lumberjack input is configured like this:

input {
  lumberjack {
    port => 5043
    ssl_certificate => "/etc/logstash/ssl/logstash-forwarder.crt"
    ssl_key => "/etc/logstash/ssl/logstash-forwarder.key"
    add_field => {
      "logtype" => "application"
    }
  }
}

This way, all the messages that are received by logstash have a logtype field.

Let's say I want to know how many messages are being received, per logtype. Then I can just do:

filter {
  metrics {
    meter => [ "logtype.%{logtype}" ]
    add_tag => "logstash_metric"
    flush_interval => 60
    rates => []
  }
}

Additionally, for the application logs, I want to know how many messages are being processed, per log level (or severity).

if [logtype] == 'application' {
  metrics {
    meter => [
      "loglevel.%{level}"
    ]
    add_tag => "logstash_metric"
    flush_interval => 60
    rates => []
  }
}

What this does, is to create a logtype.${logtype} / loglevel.${loglevel} metric, with additional fields. E.g:

logtype.application.count
logtype.application.rate_1min
logtype.application.rate_5min
logtype.application.rate_15min
...
loglevel.error.count
loglevel.error.rate_1min
...
loglevel.warn.count
loglevel.warn.rate_1min
...

I don't care about the rates, so I can specify that using rates => [](no rates will be collected). At the end, I can write the metrics to a file, to Elasticsearch, etc. In my specific case, I decided to store those metrics in graphite, as that's what I've setup for metrics storage:

output {
  if "logstash_metric" in [tags] {
    graphite {
      host => "localhost"
      port => "2003"
      metrics_format => "general.logstash.*"
      include_metrics => ["log.*\.count"]
      fields_are_metrics => true
    }
  }
}

If you have multiple logstash servers, you might want to replace metrics_format => "general.logstash.*" with metrics_format => "general.logstash.${hostname}.*"

Oh, and if you use graphite, don't forget about configuring your storage aggregation rules. By default, the metrics are treated as gauge, while this here is a counter.

Elasticsearch tips #1: deploying Elasticsearch to multi-homed servers

2015-10-06T00:00:00+02:00

I figured I should start a series of short notes (can't call them articles) about random stuff I encounter in my day-to-day job, and which took me some time to figure out. Here we go.

Elasticsearch tip #1:

TL;DR: make use of the network.publish_host setting when deploying ES to multi-homed servers

Let's say you're deploying an ES(Elasticsearch) cluster.

In a production environment It's not uncommon to have multi-homed servers (that is, with multiple network interfaces connected to different networks/vlans/etc).

You've installed ES using your package manager of choice, you have setup your elasticsearch.yml. Multicast is disabled, and you have something like this for your unicast discovery:

discovery.zen.ping.multicast.enabled: false
discovery.zen.ping.unicast.hosts: ["server1", "server2"]

Everything looks fine, you start your ES nodes... and they don't see each-other. Just (maybe) some timeouts in the logs.

There's no firewall between the nodes, routing is allright, it looks like you can connect from one node to the other, and vice versa, but it still won't work...

This will save your day:

network.publish_host: this.servers.hostname

or you can use an IP as well...

According to the official documentation at elastic.co:

(edited) The network.publish_host setting allows to control the host the node will publish itself within the cluster so other nodes will be able to connect to it. Of course, this can’t be '0.0.0.0', and by default, it will be the first non loopback address (if possible), or the local address.

What hapenned is that the first non loopback address might be on a vlan that doesn't allow the nodes to talk to each other (even if your connectivity tests worked because the default route goes through a different interface)

My .fluxbox/keys

2014-11-11T10:00:00+01:00

Just for future reference. If you want - use it, at your own risk ;)

# click on the desktop to get menus
OnDesktop Mouse1 :HideMenus
OnDesktop Mouse2 :WorkspaceMenu
OnDesktop Mouse3 :RootMenu

# scroll on the desktop to change workspaces
OnDesktop Mouse4 :PrevWorkspace
OnDesktop Mouse5 :NextWorkspace

# scroll on the toolbar to change current window
OnToolbar Mouse4 :PrevWindow {static groups} (iconhidden=no)
OnToolbar Mouse5 :NextWindow {static groups} (iconhidden=no)

# alt + left/right click to move/resize a window
OnWindow Mod1 Mouse1 :MacroCmd {Raise} {Focus} {StartMoving}
OnWindowBorder Move1 :StartMoving

OnWindow Mod1 Mouse3 :MacroCmd {Raise} {Focus} {StartResizing NearestCorner}
OnLeftGrip Move1 :StartResizing bottomleft
OnRightGrip Move1 :StartResizing bottomright

# alt + middle click to lower the window
OnWindow Mod1 Mouse2 :Lower

# control-click a window's titlebar and drag to attach windows
OnTitlebar Control Mouse1 :StartTabbing

# double click on the titlebar to shade
OnTitlebar Double Mouse1 :Shade

# left click on the titlebar to move the window
OnTitlebar Mouse1 :MacroCmd {Raise} {Focus} {ActivateTab}
OnTitlebar Move1  :StartMoving

# middle click on the titlebar to lower
OnTitlebar Mouse2 :Lower

# right click on the titlebar for a menu of options
OnTitlebar Mouse3 :WindowMenu

# alt-tab
Mod1 Tab :NextWindow {groups} (workspace=[current])
Mod1 Shift Tab :PrevWindow {groups} (workspace=[current])

# cycle through tabs in the current window
Mod4 Tab :NextTab
Mod4 Shift Tab :PrevTab

# go to a specific tab in the current window
Mod4 1 :Tab 1
Mod4 2 :Tab 2
Mod4 3 :Tab 3
Mod4 4 :Tab 4
Mod4 5 :Tab 5
Mod4 6 :Tab 6
Mod4 7 :Tab 7
Mod4 8 :Tab 8
Mod4 9 :Tab 9

# open a terminal
Mod1 F1 :Exec x-terminal-emulator

# open a dialog to run programs
Mod1 F2 :Exec fbrun

# volume settings, using common keycodes
# if these don't work, use xev to find out your real keycodes
176 :Exec amixer sset Master,0 1+
174 :Exec amixer sset Master,0 1-
160 :Exec amixer sset Master,0 toggle

# current window commands
Mod1 F4 :Close
Mod1 F5 :Kill
Mod1 F9 :Minimize
Mod1 F10 :Maximize
Mod1 F11 :Fullscreen

# open the window menu
Mod1 space :WindowMenu

# exit fluxbox
Control Mod1 Delete :Exit

# change to previous/next workspace
Control Mod1 Left :PrevWorkspace
Control Mod1 Right :NextWorkspace

# send the current window to previous/next workspace
Mod4 Left :SendToPrevWorkspace
Mod4 Right :SendToNextWorkspace

# send the current window and follow it to previous/next workspace
Control Mod4 Left :TakeToPrevWorkspace
Control Mod4 Right :TakeToNextWorkspace

# change to a specific workspace
Control F1 :Workspace 1
Control F2 :Workspace 2
Control F3 :Workspace 3
Control F4 :Workspace 4
Control F5 :Workspace 5
Control F6 :Workspace 6
Control F7 :Workspace 7
Control F8 :Workspace 8
Control F9 :Workspace 9
Control F10 :Workspace 10
Control F11 :Workspace 11
Control F12 :Workspace 12

# send the current window and change to a specific workspace
Control Mod4 F1 :TakeToWorkspace 1
Control Mod4 F2 :TakeToWorkspace 2
Control Mod4 F3 :TakeToWorkspace 3
Control Mod4 F4 :TakeToWorkspace 4
Control Mod4 F5 :TakeToWorkspace 5
Control Mod4 F6 :TakeToWorkspace 6
Control Mod4 F7 :TakeToWorkspace 7
Control Mod4 F8 :TakeToWorkspace 8
Control Mod4 F9 :TakeToWorkspace 9
Control Mod4 F10 :TakeToWorkspace 10
Control Mod4 F11 :TakeToWorkspace 11
Control Mod4 F12 :TakeToWorkspace 12

Mod1 F2 :ExecCommand fbrun
Mod4 m :RootMenu
Mod4 r :ExecCommand urxvt
Mod4 a :ExecCommand gnome-terminal
Mod4 x :ExecCommand mousepad
Mod4 f :ExecCommand firefox
Mod4 t :ExecCommand terminator
Mod4 m :ExecCommand mozilla
Mod4 g :ExecCommand gimp
Mod4 y :ExecCommand thunar
Mod1 F4 :Close
Mod4 F1 :ToggleDecor
Mod4 F2 :MaximizeWindow
Mod4 l :ExecCommand gnome-screensaver-command -l

Mod4 k :ExecCommand /usr/bin/xrandr --output DP3 --off --output DP2 --off --output DP1 --off --output HDMI3 --mode 1920x1080 --pos 1920x0 --rotate normal --output HDMI2 --off --output HDMI1 --off --output LVDS1 --off --output VGA1 --mode 1920x1080 --pos 0x0 --rotate normal
Mod4 u :ExecCommand /usr/bin/xrandr --output DP3 --off --output DP2 --off --output DP1 --off --output HDMI3 --off --output HDMI2 --off --output HDMI1 --off --output LVDS1 --mode 1366x768 --pos 0x0 --rotate normal --output VGA1 --mode 1920x1080 --pos 1366x0 --rotate normal
Mod4 i :ExecCommand /usr/bin/xrandr --output DP3 --off --output DP2 --off --output DP1 --off --output HDMI3 --off --output HDMI2 --off --output HDMI1 --off --output LVDS1 --off --output VGA1 --mode 1920x1080 --pos 0x0 --rotate normal
Mod4 o :ExecCommand /usr/local/sbin/dock.sh 1
Mod4 p :ExecCommand /usr/bin/xrandr --output DP3 --off --output DP2 --off --output DP1 --off --output HDMI3 --off --output HDMI2 --off --output HDMI1 --off --output LVDS1 --mode 1366x768 --pos 0x0 --rotate normal --output VGA1 --off

None XF86AudioLowerVolume :ExecCommand amixer -q set Master 5%- unmute
None XF86AudioMute :ExecCommand amixer -q set Master toggle
None XF86AudioRaiseVolume :ExecCommand amixer -q set Master 5%+ unmute

Mod4 Up :ExecCommand amixer -q set Master 5%+ unmute
Mod4 Down :ExecCommand amixer -q set Master 5%- unmute