We are searching a motive for a painting or a painting itself for a quite while now. This should find it’s place in our living room. Unfortunately we didn’t found one, which matched our both prospect and/or wasn’t compatible with the rest of our living room.

Yesterday we stumbled upon a motive which was quite nice, but was too small and it was neighter possible to get it in a bigger size nor to find out who was the origin painter of the picture. Now we are searching for the name of the picture and/or the painter.

Any hints appreciated at ‘blog - at - waja - dot - info’. A photo with higher resolution can be found here

Update: Okay … an unknown people (many thanks) hinted me, that google image search is the tool that could be very usefull. Google revealed that the painter is Inna Panasenko.

P.S. Is it noticeable that I’m in vacation mode? ;)

Today we where packing back our holiday decorations into boxes. We also had a music box to put away.

Do you see the defect in the picture? ;) No? Okay … some years ago my oldest daughter broke it into some pieces and a friend of us (Hi muempf! ;) did glue all together. When he showed us the nice music box, it was recovered very well, but one detail was changed from original. One horseman wasn’t reassembled as the other onces.

If you you didn’t found the defect, please have a look here.

You had fun with this? Maybe this is another one for you, I took that photo on christmas eve when my youngest daughter had placed her new ‘Lisa Plastic’:

Keep smiling!

Today short before ending business hours I was noticed that there is a problem with a server system (domU). Login with unprivileged user was possible but using “su” didn’t worked, also login in as root via privkey failed. Fortunately I was able to connect via xen console and login via tty. Looking into the bash history the reason revealed quickly:

4979 2013-02-01 15:03:39 cd /var/www/test.org/data/galleries/
4980 2013-02-01 15:03:43 chown www-data:www-data -R /var/www/test.org/data/galleries/
4981 2013-02-01 15:04:36 ls -la
4982 2013-02-01 15:04:46 ls -la
4983 2013-02-01 15:04:54 chown www-data:www-data -R /*
4984 2013-02-01 15:07:42 chown www-data:www-data -R /var/www/test.org/data/galleries/
4985 2013-02-01 15:36:55 chown www-data:www-data -R /var/www/test.org/data/galleries/

This made my day (and maybe parts of the rest of the weekend).

For recovery our 1st Level mounted the domU-fs on the dom0 to ‘/tmp/recover’ and did:

2131  2013-02-01 21:29:28 cd /tmp/recover
[...]
2142  2013-02-01 21:31:17 rm -r lib64/

The experienced reader may see the problem:

# ls -lad lib64
lrwxrwxrwx 1 root root 4 Jun 28  2011 /lib64 -> /lib

So also the dom0 was knocked out … what a funny evening (and maybe night). Maybe our staff looked similar like here.

Usually I’m monitoring stuff with Icinga (Nagios in the past). But for my small network, I primary needed monitoring of bandwidth.

In our commercial environment we are using a closed source software for accounting traffic. There is also a license for testing purpose with a reduced number of sensors available. But I’m neither running windows in this network nor feeling happy with this.

Cacti is a bit bloated for this small network and zabbix is (caused by what?) removed in wheezy, beside that I’m not getting the concept behind it. So I thought I could give munin a try and on the first view it doesn’t look so bad. Monitoring my half dozens openwrt devices works like a charm by installing muninlite just the package.

One central part of the network is a QNAP TS-459 Pro+, hosting a BackupPC and TimeMachine service, proving SMB/AFS data store and running SqueezeBox Server for another half dozen streaming devices. Unfortunately there is no optware package to provide a munin node. So I just copied the shell script of muninlite and the xinet config over from an openwrt device. At first it looked not bad, but than munin wasn’t able to collect the data. After a while I realized, that munin was failing when collecting the network informations. A look into the muninlite script revealed that it was failing when trying to discover the interface speed of eth1 via ethtool.

In my setup the QNAP is just connected with with one network interface, the second one is unconnected. Unfortunately all network interfaces on QNAP devices are up and therefore listed in /proc/net/dev where muninlite is discovering the network interfaces:

[~] # grep '^ *\(ppp\|eth\|wlan\|ath\|ra\|ipsec\|tap\|br-\)\([^:]\)\{1,\}:' /proc/net/dev | cut -f1 -d: | sed 's/ //g
> s/\-/_/g'
eth1
eth0

Let’s look into it:

[~] # ethtool eth0| grep Speed:
    Speed: 1000Mb/s
[~] # ethtool eth0| grep "Link detected:"
    Link detected: yes
[~] # ethtool eth1| grep Speed:
    Speed: Unknown! (65535)
[~] # ethtool eth1| grep "Link detected:"
    Link detected: no

Maybe you see .. the interface eth1 is up but has no link, so there is no speed negotiated and muninlite is failing. Thus I hacked the scripted and now it’s working like a charme.

(muninlite_fix-unused-up_interface.diff) download
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
--- /opt/sbin/munin-node.orig   2013-01-27 15:13:51.869007214 +0100
+++ /opt/sbin/munin-node 2013-01-27 16:11:20.536006950 +0100
@@ -133,7 +133,7 @@
   if [ -n "$(which ethtool)" ]; then
  if [ -x "$(which ethtool)" ]; then
          if ethtool $1 | grep -q Speed; then
-                MAX=$(($(ethtool $1 | grep Speed | sed -e 's/[[:space:]]\{1,\}/ /g' -e 's/^ //' -e 's/M.*//' | cut -d\  -f2) * 1000000))
+                MAX=$(($(ethtool $1 | grep Speed | sed -e 's/[[:space:]]\{1,\}/ /g' -e 's/^ //' -e 's/M.*//' | sed -e 's/Unknown\!/0/' | cut -d\  -f2) * 1000000))
              echo "up.max $MAX"
              echo "down.max $MAX"
      fi
@@ -535,19 +535,31 @@
     for INTER in $(grep '^ *\(ppp\|eth\|wlan\|ath\|ra\|ipsec\|tap\|br-\)\([^:]\)\{1,\}:' /proc/net/dev | cut -f1 -d: | sed 's/ //g
 s/\-/_/g');
     do
-      INTERRES=$(echo $INTER | sed 's/\./VLAN/')
-      RES="$RES if_$INTERRES"
-      eval "fetch_if_${INTERRES}() { fetch_if $INTER $@; };"
-      eval "config_if_${INTERRES}() { config_if $INTER $@; };"
+      if [ -n "$(which ethtool)" ]; then
+        if [ -x "$(which ethtool)" ]; then
+          if [ -n "$(ethtool $INTER | grep 'Link detected: yes')" ]; then
+            INTERRES=$(echo $INTER | sed 's/\./VLAN/')
+            RES="$RES if_$INTERRES"
+            eval "fetch_if_${INTERRES}() { fetch_if $INTER $@; };"
+            eval "config_if_${INTERRES}() { config_if $INTER $@; };"
+          fi
+        fi
+      fi
     done
   elif [ "$PLUG" = "if_err_" ]; then
     for INTER in $(grep '^ *\(ppp\|eth\|wlan\|ath\|ra\|ipsec\|tap\|br-\)\([^:]\)\{1,\}:' /proc/net/dev | cut -f1 -d: | sed 's/ //g
 s/\-/_/g');
     do
-      INTERRES=$(echo $INTER | sed 's/\./VLAN/')
-      RES="$RES if_err_$INTERRES"
-      eval "fetch_if_err_${INTERRES}() { fetch_if_err $INTER $@; };"
-      eval "config_if_err_${INTERRES}() { config_if_err $INTER $@; };"
+      if [ -n "$(which ethtool)" ]; then
+        if [ -x "$(which ethtool)" ]; then
+          if [ -n "$(ethtool $INTER | grep 'Link detected: yes')" ]; then
+            INTERRES=$(echo $INTER | sed 's/\./VLAN/')
+            RES="$RES if_err_$INTERRES"
+            eval "fetch_if_err_${INTERRES}() { fetch_if_err $INTER $@; };"
+            eval "config_if_err_${INTERRES}() { config_if_err $INTER $@; };"
+          fi
+        fi
+      fi
     done
   elif [ "$PLUG" = "netstat" ]; then
     if netstat -s >/dev/null 2>&1; then

Today I planed to move my FTP server to a new system running Debian wheezy. Usually I’m running vsftpd, so this was also the plan for the new host. As this system is dual stacked, I wanted to offer the service on IPv6 too.
On the old system I started vsftpd via xinetd, as far as I remember was vsftpd in squeeze not able to bind on the IPv4 and the IPv6. Anyways … I didn’t wanted to use any inetd system … So I looked if there is any way to solve that.

By a quick search I found vsftpd-2.3.4-listen_ipv6.patch, which indicated that just binding to [::] will also accept IPv4 connections.

Setting the following in /etc/vsftpd.conf worked out like a charm:

listen=NO
listen_ipv6=YES

I just updated #574837 so hopefully more people can benefit in the future.

You may have noticed that I recently started posting more updates again. The reason is, I switched over from Wordpress to Octopress as blogging engine.

The idea was driven, cause my used theme K2 got stuck and with the upcoming release of Debian wheezy I’m forced to switch to a more recent Wordpress release, which is likely incompatible.
Another reason is, that I got bored by wordpress itself (and it’s software dependencies). With octopress these dependencies are lowered to a webserver which can server static files and rsync on the server side.

Maybe I will post some parts of the story, what I did when migrating the content and what components (plugins, theme …) I’m using, later.

This year it turned out that we had to care the first time for ourself about Christmas dinner. So we decided to try a roast goose. Obtaining the goose is a different story and will maybe told later.

The second challenge was to select a recipe. We found a great one at Die Rezeptesammlung der Unix-AG