ixs' Vodkamelone

A little shell spinner

2011-09-13T09:03:05Z

Sometimes you want to see if a connection to a remote system is still alive or you just want to keep it alive by transmitting some data. I've found the following little shell one-liner to be quite useful:

$ while true; do for i in '|' '/' '-' '\'; do echo -n $i; sleep 0.25; echo -ne '\b'; done; done

This will create a little ascii spinner and keep a line spinning until you press CTRL-C.

FrOSCon

2011-08-28T13:11:37Z

Christoph Wickert already wrote a lot about FrOSCon 2011 so I do not have to add much. Thank god for that as I find blogging to be rather tedious lately...

Suffice to say the conference was great fun.

Even though I wasn't at FrOSCon for Fedora but for my employer Booking.com, who was one of the FrOSCon sponsors, I still managed to spend quite some time with the fellow Fedora people. I even got roped into providing a talk during the Fedora Activity Day.

As a topic I chose func, a remote execution framework we have been using quite successfully at Booking for automating a lot of processes.

For the people who either missed the talk or want the slides for later reference, the slidedeck is available as a PDF.

Fedora 15, not as bad as people claim...

2011-03-09T00:07:01Z

Reading the fedora planet I got the impression that the new Fedora 15 alpha release must suck.

This impression is mostly based on the screenshots Nicu posted as well as the accompanying, vicious review.

Having seen these, I naturally had to try the new F15 release for myself to see what this is all about.

Having booted it up in a virtual machine I am now ready to proclaim that Fedora 15 does not suck. The system greets me the same way prior releases did and the only noticable difference is a different release name and newer kernel release.

However, in the few minutes I spent with the new release I have to say that I already found two bugs:
After switching to the graphical login screen with gdm3, the screen becomes garbled. Suddenly the background is full of scanlines reminding me of the old days when I didn't had the correct modeline in the /etc/X11/X11.conf file.
I was assured however on IRC, that my hardware is not broken and this is the normal design for the Alpha release and the final one will not destroy my display. Thank god for that.

The other bug is that after ignoring the garbled screen and actually logging in, the desktop has become totally broken and hideous. Black and grey bars are alternating and hurting my eyes, functionality is missing, I have to switch constantly to the command line to change settings etc...

Again however the friendly people on the IRC channel came to the rescue and informed me that this is a known bug (tracked in the ohh so aptly named F15GnomeFAIL tracker) and it is actually not a software bug but human error.
It seems I just picked the wrong iso image thinking that the Desktop-ISO is actually for the Desktop. It looks like this is a common mistake and the real Desktop Spin is further down on the Download page. Silly me, we obviously have to better educate our Target Audience to pick the right image.

While I am actually very interested in seeing what the Gnome3 shell actually has to offer, this is not the release to do so. I seriously ask myself if this is the most unfinished and broken-by-default Fedora release there ever was. The Go/No-Go meeting should have just taken the hard decision and delayed the F15 release by 6 months. Maybe then this would look more like a release and less than a trainwreck.
I am basically disgusted at this point.

Monitoring a Snom phone with MRTG through SNMP

2011-01-28T09:58:57Z

Snom is the maker of pretty decent VoIP phones running Linux. I have had a Snom 360 for some time now and am reasonably happy with it.

The Snom phones do support SNMP but their SNMP daemon is severly limited. It only supports GETs on a small number of OIDs, doesn't support WALK and standard MIBs like the system-MIB are not supported. The Snom Wiki has a list of the supported OIDs and a description how to enable SNMP on the phones.
The limited support makes autodetection by network management systems or MRTG's cfgmaker fail. In order to chart this data, a manually created template is therefore needed.

Traffic Monitoring (bytes) a Snom Phone

The Snom phone exports all it's interfaces aggregated. This means all vlans and locally generated traffic. The only traffic not exported is the traffic generated on the loopback interface and the traffic bypassing the phone completely via the internal switch. The latter means that the traffic of the machine connected to the PC/passthrough port is not monitored. The MRTG template to chart the incoming and outgoing bytes is the following. The IP Address 192.168.2.124 would have to be changed, as well as the descriptive details.

Traffic Analysis for Net -- 192.168.2.124

"sysdetails">

System:	192.168.2.124 in Amsterdam
Maintainer:	root@localhost
Description:	Net Port
ifType:	ethernetCsmacd (6)
Max Speed:	100.0 Mbits/s

Traffic Monitoring (packets) a Snom Phone

The setup to monitor packets is basically the same as for traffic. MRTG can do this out of the box and only needs labels changed.

######################################################################
# System: Snom360
# Description: Snom VoIP Phone
# Contact: System Administration
# Location: Amsterdam, The Netherlands
######################################################################

### Interface Net >> Descr: 'Net' | Name: 'Net Port' | Ip: '192.168.2.124' | Eth: '' ###

Target[192.168.2.124_Net_pkts]: 1.3.6.1.2.1.7526.2.1.2&1.3.6.1.2.1.7526.2.2.2:public@192.168.2.124
RouterUptime[192.168.2.124_Net_pkts]: 1.3.6.1.2.1.7526.2.8:public@192.168.2.124
SetEnv[192.168.2.124_Net_pkts]: MRTG_INT_IP="" MRTG_INT_DESCR="Net"
MaxBytes[192.168.2.124_Net_pkts]: 10000000
Title[192.168.2.124_Net_pkts]: Traffic Analysis (packets) for Net -- 192.168.2.124
YLegend[192.168.2.124_Net_pkts]: Pkts per Second
Legend1[192.168.2.124_Net_pkts]: Avg Input Unicast Packets
Legend2[192.168.2.124_Net_pkts]: Avg Output Unicast Packets
Legend3[192.168.2.124_Net_pkts]: Maximal Input Unicast Packets
Legend4[192.168.2.124_Net_pkts]: Maximal Output Unicast Packets
LegendI[192.168.2.124_Net_pkts]: ifInUcastPkts:
LegendO[192.168.2.124_Net_pkts]: IfOutUcastPkts:
ShortLegend[192.168.2.124_Net_pkts]: p/s
PageTop[192.168.2.124_Net_pkts]:

Traffic Analysis (packets) for Net -- 192.168.2.124

"sysdetails">

System:	192.168.2.124 in Amsterdam
Maintainer:	root@localhost
Description:	Net Port
ifType:	ethernetCsmacd (6)

Some other values worth charting could be CPU load and free memory or the number of registered extensions. This could be useful for tracking down errors. Unfortunately, mrtg is unable to chart this correctly out of the box and needs some help converting the data.
This is therefore left as an excercise to the reader.

VirtualBox USB support on Fedora. The right way.

2010-11-07T13:08:29Z

The proprietary version of Oracle VirtualBox does offer USB support.
This means that the guest operating system can access USB devices plugged into the host system.

This USB passthrough feature is also available with many other desktop virtualization solutions, e.g. KVM and Qemu. Nevertheless it seems VirtualBox is favoured by a large number of users who are installing VirtualBox only to find that they cannot actually make their USB devices visible to the guest operating system. The common problem seems to be that they checkboxes next to the devices are grayed out, preventing the user from marking them to be added to the guest.

There are a large number of forum articles and blog posts available which all claim to have a solution to the issue. Very often the suggested solution is to change the mount options for /proc/bus/usb in fstab or add an appropriate entry. Sometimes it is suggested to mount usbdevfs to /sys/bus/usb/drivers. Some report success by editing certain udev rules so that files the in the procfs belong to the user executing the VirtualBox binary.

All these solutions have one thing in common:
They are all wrong!
The fact that they are mindlessly repeated by posters in a large number of user-centric web forums does not help at all.
It is still wrong!
I said it before but it still is true: Web forums are full of cargo-cult users: No idea what they are doing but trying and talking about it in the hope that it will achieve something.

The right solution is actually very simple. All that is needed is to add the user running VirtualBox to the vboxusers group:

[root@minos ~]# usermod -a -G vboxusers athienemann
[root@minos ~]# groups athienemann
athienemann : athienemann vboxusers
[root@minos ~]#

That's all. The user athienemann now can add and remove USB devices from VirtualBox guests.
Wasn't that easy? No fiddling with udev or fstab needed.