Infrastructure

16 posts

Releasing “Package Drone” 0.0.1

A package repository for Maven Tycho, OSGi and all the rest.

Itch: I want to have a software repository where Maven Tycho can deploy to and P2 can read from. Also I would like to re-use this repository as an OBR or OSGi R5 repository, and possibly as Maven repository.

Scratch: Package Drone, version 0.0.1

Now there already is the Nexus Repository and the Nexus Unzip Plugin. However this essentially uploads a full P2 repository ZIP file and uses Nexus as a plain web server, hosting that zipped P2 repository.

Instead I would like to not only have a P2 repository, but also an OSGi R5 repository, based on the same OSGi bundles uploaded. I would also like to upload bundles created by the Maven Bundle Plugin, or BNDtools. Also would I like to make a full, Maven like, release using Tycho and later host this as a Maven 2 repository. Now package drone is not quite there yet, but the basic Tycho Deploy -> P2 Consume workflow already works to some degree.

Package Drone is hosted on github and there is a small readme and wiki.

Be warned, this is alpha quality software. If it works for you, fine. If not please help me fix it!

Identify GSM modem devices using udev

Again an interesting problem, I do have a Linux box and it has two GSM modems and a RS-232 FTDI USB device built in. Each GSM modem brings three USB serial devices. Now I do want to dial up using the first of these modems and therefore I do need the device name, e.g. /dev/ttyUSB2.

However, each time the box boots up, either the RS-232 device or the modems are first in the order or devices found by the kernel. This results in the modem to be either /dev/ttyUSB2 or /dev/ttyUSB3. Since this definitely is an issue when dialing up, I would like to keep these device names persistent.

udev can help here. It allows one to influence the way devices are created in userland. Depending on your distribution, the rules files are located at /etc/udev/rules.d/ (at least for Ubuntu).

Now my modems can be identified by vendor and product id (12d1, 1404) so a simply udev rule should be fine:

[code]SUBSYSTEM=="tty", ATTRS{idVendor}=="12d1", ATTRS{idProduct}=="1404", SYMLINK+="gsm%s{bInterfaceNumber}"[/code]

In theory this should create additional entries under “/dev/” with map to the kernel assigned device names. For example /dev/gsm00 -> /dev/ttyUSBXX. So I could just access /dev/gsm01, whatever the boot order was.

The problem is that the device attribute bInterfaceNumber is not on the tty device, but on the usb device in the parent hierarchy.

Still it is possible to record the interface number of a first rule, and use it in a second one:

SUBSYSTEMS=="usb", ENV{.LOCAL_ifNum}="$attr{bInterfaceNumber}"
SUBSYSTEM=="tty", ATTRS{idVendor}=="12d1", ATTRS{idProduct}=="1404", SYMLINK+="gsm%E{.LOCAL_ifNum}"

This stores the attribute “bInterfaceNumber” into the environment variable .LOCAL_ifNum (the prefixed dot is a notation for temporary or hidden variables). In the second rule the same variable is pulled on using the %E syntax. Newer udev versions also support $env instead of %E.

Thanks to [1] for mentioning this trick!

[1] https://unix.stackexchange.com/questions/60154/udev-rule-file-for-modem-not-working

Build your own SIP trunk with Asterisk and mISDN

The mission: “save some bucks by using a free PBX using a cheap isdn card”. Don’t try! Buy something working in the first place. But if you have to, here is one example how it can be done. There are, for sure, many others!

The idea was to replace trixbox using an AVM Fritz!PCI card with something more up to date and not that buggy. FreePBX Distro kicked itself out because of the issues with mISDN. Elastix brought in mISDN support but still failed in configuring it. Since the setup was for only 3 users for now and the idea was to later buy something more professional (I really hope it comes to this point), I used Starface free. It has 4 users and 10 extensions for free. Yet the free version only allows using SIP providers. Also it was not possible to buy a Patton SmartNode 4120 at the moment, which I still hope to get somewhere in the future. So I needed to build our own SIP trunk since the provider used (M-NET) does not provide SIP trunks as a product.

Continue reading