MGE Ellipse 750 UPS on Debian Squeeze

My home server is protected by an MGE Ellipse 750 UPS for years. I bought it for several reasons: it’s affordable, has good capacity and is Ubuntu certified.

I also read back then rumors implying that Nut’s maintainer was employed by MGE. Having a hardware manufacturer employing a fellow open-source hacker has certainly influenced my purchase decision.

MGE is no more and has been merged with EATON. But my UPS is still supported, and the release of Debian Squeeze is a good opportunity to consolidate my knowledge in the form of this tutorial.

So here is how I setup Nut on Debian Squeeze to monitor my UPS.

First things first, we have to install the main package and its USB driver:

$ aptitude install nut nut-usb

Now let’s configure Nut and run it:

$ sed -i 's/MODE=none/MODE=standalone/g' /etc/nut/nut.conf
$ echo '
[MGE-Ellipse750]
driver = usbhid-ups
port = auto
desc = "MGE UPS Systems"
' >> /etc/nut/ups.conf
$ sed -i 's/# LISTEN 127\.0\.0\.1 3493/LISTEN 127\.0\.0\.1/g' /etc/nut/upsd.conf
$ echo '
[kevin]
password = badpassword
upsmon master
' >> /etc/nut/upsd.users
$ sed -i 's/# NOTIFYCMD \/usr\/local\/ups\/bin\/notifyme/NOTIFYCMD \/sbin\/upssched/g' /etc/nut/upsmon.conf
$ echo '
MONITOR MGE-Ellipse750@localhost 1 kevin badpassword master
NOTIFYFLAG ONBATT SYSLOG+WALL+EXEC
NOTIFYFLAG ONLINE SYSLOG+WALL+EXEC
' >> /etc/nut/upsmon.conf
$ sed -i 's/CMDSCRIPT \/upssched-cmd/CMDSCRIPT \/etc\/nut\/upssched-cmd/g' /etc/nut/upssched.conf
$ sed -i 's/# PIPEFN \/var\/run\/nut\/upssched\/upssched.pipe/PIPEFN \/var\/run\/nut\/upssched.pipe/g' /etc/nut/upssched.conf
$ sed -i 's/# LOCKFN \/var\/run\/nut\/upssched\/upssched.lock/LOCKFN \/var\/run\/nut\/upssched.lock/g' /etc/nut/upssched.conf
$ echo '
AT ONBATT * START-TIMER onbatt 30
AT ONLINE * CANCEL-TIMER onbatt
' >> /etc/nut/upssched.conf
$ echo '
#!/bin/sh
exit 0
' > /etc/nut/upssched-cmd
$ /etc/init.d/nut restart

As you can see you have lots of stuff to configure before Nut can do what it was designed for. But after all of these commands, you should have a working UPS.

You can now test that your system works by using the command below, which list statistics of a given UPS:

$ upsc MGE-Ellipse750@localhost

But in some rare cases, your UPS will not be recognized and you’ll have like me the following messages in your /var/log/syslog:

May  5 16:12:36 paris-server upsmon[10773]: Poll UPS [MGE-Ellipse750@127.0.0.1] failed - Driver not connected

In this case, you should run Nut’s driver in debug mode:

$ /lib/nut/usbhid-ups -DDD -a MGE-Ellipse750
Network UPS Tools - Generic HID driver 0.34 (2.4.3)
USB communication driver 0.31
   0.000000     debug level is '3'
   0.013911     upsdrv_initups...
   0.189541     Checking device (0463/FFFF) (005/003)
   0.189705     - VendorID: 0463
   0.189741     - ProductID: ffff
   0.189767     - Manufacturer: unknown
   0.189794     - Product: unknown
   0.189819     - Serial Number: unknown
   0.189842     - Bus: 005
   0.189862     Trying to match device
   0.189906     Device matches
   0.189954     failed to claim USB device: could not claim interface 0: Operation not permitted
   0.189995     failed to detach kernel driver from USB device: could not detach kernel driver from interface 0: Operation not permitted
   0.190033     failed to claim USB device: could not claim interface 0: Operation not permitted
   0.190070     failed to detach kernel driver from USB device: could not detach kernel driver from interface 0: Operation not permitted
   0.190108     failed to claim USB device: could not claim interface 0: Operation not permitted
   0.190145     failed to detach kernel driver from USB device: could not detach kernel driver from interface 0: Operation not permitted
   0.190181     failed to claim USB device: could not claim interface 0: Operation not permitted
   0.190217     failed to detach kernel driver from USB device: could not detach kernel driver from interface 0: Operation not permitted
   0.190252     Can't claim USB device [0463:ffff]: could not detach kernel driver from interface 0: Operation not permitted

As you can see in messages above, Nut can’t see my UPS. By chance, forcing nut to use the root user let it see my UPS:

$ /lib/nut/usbhid-ups -DDD -u root -a MGE-Ellipse750
Network UPS Tools - Generic HID driver 0.34 (2.4.3)
USB communication driver 0.31
   0.000000     debug level is '3'
   0.001678     upsdrv_initups...
   0.172877     Checking device (0463/FFFF) (005/003)
   1.112408     - VendorID: 0463
   1.112464     - ProductID: ffff
   1.112489     - Manufacturer: MGE OPS SYSTEMS
   1.112516     - Product: ELLIPSE
   1.112542     - Serial Number: BDCJ3800Q
   1.112569     - Bus: 005
   1.112595     Trying to match device
   1.112647     Device matches
   1.112726     failed to claim USB device: could not claim interface 0: Device or resource busy
   1.113239     detached kernel driver from USB device...
   1.251394     HID descriptor, method 1: (9 bytes) => 09 21 00 01 21 01 22 01 03
   1.251460     HID descriptor, method 2: (9 bytes) => 09 21 00 01 21 01 22 01 03
   1.251491     HID descriptor length 769
   1.351379     Report Descriptor size = 769
   1.351456     Report Descriptor: (769 bytes) => 05 84 09 04 a1 01 09 24 a1 00 09 02 a1 00
   1.351509      55 00 65 00 85 01 75 01 95 05 15 00 25 01 05 85 09 d0 09 44 09 45 09 42 0b
(...)

So the issue is now clear and is related to permissions. I was able to fix this issue by changing the permissions on the USB device corresponding to my UPS:

$ chmod 0666 /dev/bus/usb/005/003

Another working way to fix this is to change the group of the device to nut:

$ chown :nut /dev/bus/usb/005/003

BTW, to get the bus number (005 here) and device number (003 in my case) of your UPS, run lsudb:

$ lsusb
Bus 005 Device 003: ID 0463:ffff MGE UPS Systems UPS
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Of course this fix is absolutely temporary, as you’ll need to perform the change above after every reboot. This is far from practical. In fact, as describe in this Fedora 10 bug report, but also in some other Debian bug report, this issue is directly tied to conflicting Udev rules.

Based on clues from these bug reports you can fix Udev using different strategies. As I can’t decide which one is the cleanest, I just did something that is quite brutal, but works. It consist of replacing in /lib/udev/rules.d/91-permissions.rules the line setting rights for USBfs-like devices:

--- /lib/udev/rules.d/91-permissions.rules-orig 2011-05-05 18:49:08.015538434 +0200
+++ /lib/udev/rules.d/91-permissions.rules      2011-05-05 18:49:16.663537978 +0200
@@ -33,7 +33,7 @@

 # usbfs-like devices
 SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", \
-                               MODE="0664"
+                               MODE="0666"

 # serial devices
 SUBSYSTEM=="tty",

Now all you have to do is to unplug the power cord and wait until your machine gracefully shut down as soon as batteries are low ! :)

MIDI-controlled Text Zoom in Quartz Composer

To end my series of experimentations with Quartz Composer that I started 2 months ago, here is my last patch:

It’s based on the previous one and is also driven by a Berhinger BCF-2000 MIDI controller. The purpose of this composition is to zoom a piece of text, give it some kind of velocity and change its color. Again, nothing fancy here: it’s just a simple patch, which source is available for download.

As for the last time, I recorded a little demo to pratice my new videomaking skills (and to find a justification for buying more video gear ;) ):

The audio part is Dream by Paolo Lunardi (from his album Essential). I found it on Jamendo under a Creative Common BY-SA v3.0 license.

Quartz Composer & Behringer BCF-2000 MIDI controller tests

Featured

A year ago I explored visual control by plugging a generic Behringer BCF2000 MIDI controller in Apple’s Quartz Composer. My initial intention was to drive some animations and visuals during Cool Cavemen‘s live concerts. Now that’s I’ve abandonned the idea of using Quartz Composer, it’s time to share these stuff with you.

So here is my MIDI playground:

Nothing exceptionnal to see here. It’s just a bunch of dumb patches to control the color of the background screen and its intensity. The latter can be modulated by pulses with different profiles, and also by the sound captured by the MacBook‘s microphone. The source composition is downloadable.

Just for the sake of it, I’ve recorded a quick and dirty demo with my Canon 7D (set to 1080p, 25 fps and 1/50 shutter speed) and the fantastic Tokina 11-16mm f/2.8:

Here is the video, which I edited with Kdenlive:

The audio is sourced from Jamendo. It’s the track One Year written by Paolo Lunardi for his album Essential, and released under a Creative Common BY-SA v3.0 license (thus making my video subject to the same license).

Enttec DMX-USB firmware upgrade with Qemu

A year ago, I brought a Enttec Pro USB/DMX widget. Since then, a new firmware was released. If it doesn’t fix any critical bug to me, I still have to upgrade it (don’t mind asking why… ;) ). And to make things fun (read “dangerous”), I choose to do it with Qemu.

This article explains how I upgraded the firmware of my Enttec DMX/USB widget under linux thanks to Qemu.

First, plug your device in one of your computer’s USB port. We need to get the hardware UID of the widget. We can do so as root in a linux terminal:

cat /proc/bus/usb/devices

This command output a big mess in which you should find a block of lines separated by two blank lines (one above and one below) corresponding to your USB device. It’s easy to spot, as it contain the ENTTEC string. Mine look like this:

T:  Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  2 Spd=12  MxCh= 0
D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor=0403 ProdID=6001 Rev= 6.00
S:  Manufacturer=ENTTEC
S:  Product=DMX USB PRO
S:  SerialNumber=ENQXXXXX
C:* #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr=300mA
I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=ftdi_sio
E:  Ad=81(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms

What we are looking for is the vendor’s ID and the product’s ID, that’s all Qemu needs to talk to the device. This is found on the line starting with P:. For me:

  • Vendor ID: 0403
  • Products ID: 6001

With this information, we can launch Qemu and bind it to the device. Assuming you already have a Qemu image containing a working version of windows XP, the command looks like this:

qemu -m 512 -usb -usbdevice host:0403:6001 -hda ./qemu-win-xp-with-freestyler.qcow

Alternatively, you can “hotplug” the USB device once inside Qemu. This can be done by calling the Qemu interactive shell by pressing Ctrl + Alt + 2 simultaneously. Then, to hotplug the USB device, type:

usb_add host:0403:6001

If you’re as unlucky as I am, you’ll get this error message:

Could not add USB device 'host:0403:6001'

Which is doubled by the following message from your legacy console:

/proc/bus/usb/002/002: Permission denied

The latter point to the restrictive access rights on our device, which can be fixed by:

chmod -R a+rw /proc/bus/usb/002/002

qemu-usb-console

Instead, if you get the following error message:

usb_host: device already grabbed

It probably mean that your linux kernel has already identified the device when you plugged in and has loaded some drivers. To unload them and free the device, I had to do:

lsmod
rmmod dmx_usb
rmmod ftdi_sio

At last, you can check under the emulated Windows that your Enttec widget is recognized by windows:

enttec-usb-dmx-widget-on-windows-xp-through-qemu

And finally you’re free to upgrade (at your own risks) your widget’s firmware with the tools available on Enttec’s official website:

enttec-dmx-usb-widget-firmware-upgrade-on-windows-xp-through-qemu

FYI, all these operations where performed on a Mandriva 2008.1, Qemu 0.9.0 and linux kernel 2.6.24.

QLC 2.6.1 for Mandriva 2008.1

QLC 2.6.1 on Mandriva 2008.1

I’ve just backported QLC 2.6.1 from Fedora Core to Mandriva 2008.1. Q Light Controller is a software designed to pilot lights (both moving and static ones) on stages via the DMX communication protocol. This is my first step to bring together two of my main recent interests: stage lighting and linux.

These RPMs are currently only available for the x86_64 version of Mandriva but includes the Open DMX USB drivers and Lighting Architecture for Linux (LLA) packages. All the sources of these packages came from the repository I found in the “LLA, OpenDMX USB and Q Light Controller Tutorial” tutorial.

I haven’t played with QLC yet: I’ve just started it and as you can see on the screenshot it seems to work. Happy testing ! ;)

Easy Mirroring Without RAID: the Poor Man’s Disk Array

This howto explain how to use rsync to build a data mirroring mechanism on a local machine, with two hard drives, ala RAID 1, but without RAID 1 (!).

I had the project to setup a RAID 5 array using 3*120 Gb hard drives in USB enclosures. Unfortunately my project stalled due to instability in early 2.6.x kernels (I heard that 2.6.12 and upper are now useable for “RAID over USB”).

Because of the urgency of reliable storage (and because I don’t want to waste time compiling and fine-tuning kernels), I decided to do it using traditionnal IDE host. So I plugged two 120Gb HDD on my machine as master device, one on each IDE channel.

Open Brick NG and RAID-1-like setup

Then I made a big XFS partition on each, and update my /etc/fstab:

/dev/sda1 /                auto  noatime   1 1
/dev/hda1 /mnt/hd1         xfs   defaults  1 2
/dev/hdc1 /mnt/hd1_mirror  xfs   defaults  1 2

At that moment I have to explain you that my machine is an OpenBrick NG, with a USB 2.0 512 Mb thumb drive (/dev/sda1 in the fstab) on which all my linux system is installed. That explain why my two IDE channels are free for use.

The idea is now to use /mnt/hd1 to store and manipulate my datas, then rsync that drive with his alter-ego (/mnt/hd1_mirror) every night. To do that, I’ve just added the following command in a cron entry:

rsync -a --delete --delete-excluded --delete-after /mnt/hd1/ /mnt/hd1_mirror/

And voilĂ  !

As you guess, this solution is far from perfect, and has major inconvenients regarding RAID 1:

  • No immediate backup : the backuped datas are 1-day old;
  • Seek time is not reduce by half;
  • Transfer rate is not doubled.

Oh, and by the way, be careful to not write files on /mnt/hd1_mirror/ because they will be deleted each night during the mirroring process.