My jabra finally working with bluez...

As I have hit the bottom on my coding task (a project I have been planning for the past 6 months and writing it for the last month), I needed to get my mind off of it and do something I'm good at - debugging - and what better thing to debug than getting my Jabra to work with Skype. As I gave a shot at it some time ago and wasn't happy with the results, so I tried again.

The distribution is Fedora 8 (i386) and headset is Jabra BT 500v.

The first thing I upgraded was Skype itself - from 2.0.0.27 to 2.0.0.43 (built under Fedora Core 5 - isn't it about a time to upgrade?!?!).

At first I tried with the Fedora default bluez packages (version 3.20), but no luck there. Same results as before. At least this time I was just playing with it - hoping that the Fedora team had patched something.

Oh well - back to the basics. The latest version of bluez-libs and bluez-utils is 3.28, so why not give it a try. As I'm a lazy person and the archives did not include a spec file I reused the 3.20 spec files. As I'm am apt user I used "apt-get source bluez-libs bluez-utils" but somehow it is also doable in yum. This should create 2 spec files in "/usr/src/redhat/SPECS" folder. All I need to do was to copy the source archives into "/usr/src/redhat/SOURCES" folder and mod the spec files.

Bluez-libs was pretty easy to rebuild - just edited the spec file and replaced the "Version:" from 3.20 to 3.28 and ran the "rpmbuild -ba bluez-libs.spec". This created:
Wrote: /usr/src/redhat/SRPMS/bluez-libs-3.28-1.fc8.src.rpm
Wrote: /usr/src/redhat/RPMS/i386/bluez-libs-3.28-1.fc8.i386.rpm
Wrote: /usr/src/redhat/RPMS/i386/bluez-libs-devel-3.28-1.fc8.i386.rpm
Wrote: /usr/src/redhat/RPMS/i386/bluez-libs-debuginfo-3.28-1.fc8.i386.rpm

Now a little "rpm -Uvh /usr/src/redhat/RPMS/i386/bluez-libs-3.28-1.fc8.i386.rpm /usr/src/redhat/RPMS/i386/bluez-libs-devel-3.28-1.fc8.i386.rpm" and we have a newer libs in place (the devel package is needed for building the utils packages).

The bluez-utils was a bit more complicated as I had a bad experience when building the 3.20 version last time. Namely the "--enable-all" flag did NOT work at that time so just in case I modified the configure parameters. The basics are the same - replace the "Version:" string from 3.20 to 3.28 and the "Release:" string from "6%{?dist}" to "1%{?dist}". Now for the "%configure" parameters - the first thing was to replace "--disable-obex" with "--enable-obex". I'm not sure as to why it is disabled, but just in case I need obex I have it. After the obex I also added "--enable-alsa --enable-oss --enable-hal --enable-usb --enable-glib --enable-gstreamer". Now all I needed to do was a "rpmbuild -ba bluez-utils.spec" and woala:
Wrote: /usr/src/redhat/SRPMS/bluez-utils-3.28-6.fc8.src.rpm
Wrote: /usr/src/redhat/RPMS/i386/bluez-utils-3.28-6.fc8.i386.rpm
Wrote: /usr/src/redhat/RPMS/i386/bluez-utils-cups-3.28-6.fc8.i386.rpm
Wrote: /usr/src/redhat/RPMS/i386/bluez-utils-gstreamer-3.28-6.fc8.i386.rpm
Wrote: /usr/src/redhat/RPMS/i386/bluez-utils-alsa-3.28-6.fc8.i386.rpm
Wrote: /usr/src/redhat/RPMS/i386/bluez-utils-debuginfo-3.28-6.fc8.i386.rpm

Now a little "rpm -Uvh /usr/src/redhat/RPMS/i386/bluez-utils-3.28-6.fc8.i386.rpm /usr/src/redhat/RPMS/i386/bluez-utils-alsa-3.28-6.fc8.i386.rpm" and bluez should work.

So to start the bluetooth audio service I have this script headset.py:
#!/usr/bin/python
import dbus
bus = dbus.SystemBus()
manager = dbus.Interface(bus.get_object('org.bluez', '/org/bluez'), 'org.bluez.Manager')
bus_id = manager.ActivateService('audio')
audio = dbus.Interface(bus.get_object(bus_id, '/org/bluez/audio'), 'org.bluez.audio.Manager')

In theory this could be done from command line, but some time ago I found this little snippet that works for me. Basically all it does is activate and register the service as root through the dbus and it works from regular user account.

Now for the last but not the least we have to define the headset that will be used in our home folder. The file is ~/.asoundrc and mine contains the following:
pcm.bluetooth {
type bluetooth
device "00:13:17:2B:0D:11"
profile "auto"
}

where the device is the mac address of the device.

Now - to use the headset with Skype. first I run the headset.py script from console and then run Skype and BINGO - the sound starts almost the same time Skype starts. not 40 seconds later like with version 3.20. Not bad considering the connection is crypted and wireless :)
So the next step was to try the test call - and it worked without a delay!!! Last time I had to wait up to 2 minutes for Skype to initialize the output and input and thats if the connection staid up that long.

So - my headset is working and hopefully it will continue to work with Fedora 9 when it will be available and I hope it will be helpful to someone else.

Blogged with Flock

Linux Bioapi on Fedora 7...

I have been using bioapi and pam_bioapi on my T43p ThinkPad under SuSE 10 Pro for the past 2 years and been happy with it. No annoying password prompts to type your passwords and well typing your password to the screen saver prompt... I wont go into that...

As always all good things have to end sometime, so went my bioapi when I replaced my SuSE with Fedora 7. The reason to switch to Fedora was forced upon me by the all famous evil MicroSoft with its all famous MSN version upgrade. As I hacked the Kopete as much I could the old libs in SuSE were not just up to the task of plain rebuild to a newer version.

After backing up the usuals about a week ago I reinstalled my laptop. No big deal. Around half an hour of installation, another half a hour to strip all of the gnome components and yum junk and another 2 hours of installing and configuration of KDE. All was well untill I remembered the most important thing - I didn't backup my own rpm's. And this included the bioapi and the pam module. After about 20 times entering the password for screen saver the old finger swiping reflex started to come back. Crap...

Oh well - I had to start from the beginning.

The first thing to do is the bioapi lib's. Everything is straight forward until I started packaging it. Google was no help - the best thing google could offer was the "--with-Qt-dir=no" configure option, but that was not acceptable for me. I needed the Qt for my screen saver so after little debugging I found the evil source of the Qt compile errors. It is an rpm macro

# here is a hack
# in /usr/lib/rpm/rpmrc line 18
# replace optflags: i386 -O2 -g -march=i386 -mcpu=i686
# with optflags: i386 -O2 -g -march=i386

Every time when compiling the configure test part spitted out error messages about mcpu being deprecated and the test failed.
As I'm low on time for the time being I just used the hack and Bingo - every test was passed successfully.
As this is literally an hack I wont be using it for other packages until needed again, but basically its biapi's testing problem and currently I don't have time to start fixing it. The i386 rpm is here and the source rpm is here. One day I will move the udev rules the the bioapi package, but not right now.

Ok, so everything should be set to run the bioapi right? Well, not really - the one thing that I had totally forgotten was the UPEK inc. tfmss bsp api. This was the most frustrating thing as I had forgotten about it totally. As it is distributed under property license and it seems everyone have drawn back their binary and source packages I'll just publish the spec to build the rpm and the config. It seems that UPEK is forcing their license, so here is the spec and here is the configuration fail. A simple rpmbuild will build the package that can be installed. For licensing read the SDK EULA, and thus I'm not responsible for whatever you do after building the package - this information is provided AS IS, without any warranty by the packager.

The final thing is the pam_bioapi package. This packaged nicely without any hiccups. But then the problems started. It seems that the new version of the module is only capable of using SQLlite3 back end and not the old flat bir file based back end (atl east I dint find an option to enable it). Thus I'm still without a working bioapi. Oh well - back to the old reliable 0.2.1 it went. After little patching it built nicely. But the problems did not end - I started to get bioapi errors. "BioAPI error #194d" - google did not give any good answer to it except it is a permissions error. After some debugging I found out that the error is cosed by wrong permissions on the usb fingerprint reader device. By default it is owned by root and writable by user root - naturally I'm not a root on everyday tasks so I did some magic and got it running. To make the changes permanent I wrote a little udev rule that makes the device to be owned by group "fingerprint" and made it writable by the group so it started to work nicely. Here is the rpm and here is the source rpm.

I also included a mini "howto" on how to get it to work fast and easy. I also may be missing some libs and deps from the packages as my systems are always bloated with libs and development headers, but the examples are here, so have fun everybody.

Some useful links allso: udev rule writing, file permissions in linux, a good howto on enabling fingerprint reader, the bioapi error I mentioned before, another error symptom, Novell way of doing things, the TFMSS fingerprint reader api.

Thats about it for today - have fun and play nice :)
PS! Great thanks the the people in UPEK for releasing the Linux port for the fingerprint reader api :)

Blogged with Flock

Adobe Reader and Fedora 7...

Like always, nothing is without problems - this time is not an exception.

So as everybody has heard the Linux AdobeReader_enu-7.0.8-1 has some holes in it and the 7.0.9-1 is available. So today I thought that it would be a good idea to upgrade my old version to the new version.

Lets just say it did not go as expected....

Its good that Adobe makes an effort to provide the reader in rpm format, but this time I ran into a small problem. It seems Fedoras libgtk-x11 version has gotten a bit too new version. The "rpm -Uvh" went fine, nut when I tried to launch the reader form the start menu nothing happened. After few tries the reader didn't start - no errors nor warning were displayed, so the easiest thing to do was to open my favorite tool the console :)

When starting the "acroread" script from the command line it starts spitting out "expr: syntax error" errors. This usually means that the evaluated expression is faulty ore some values have not been assigned. Right it just couldn't go without the pain of debugging...

Oh well, fairing up the vi and opening the "/usr/local/Adobe/Acrobat7.0/bin/acroread" showed too much info to start with. First step was to debug the script to see where it crashed. Just by replacing the first line "#/bin/sh" with a bit more intelligent shell with debugging output "#/bin/bash -x" showed me the problem location.

It looks like the "base_version" variable will get an empty value witch on the other hand makes the loop to go wild. So to fix it we have to look at the "get_gtk_file_ver()" function.

And here it is - on line 418 - "echo $mfile| sed 's/libgtk-x11-\([0-9*\).0.so.0.\([0-9]\)00.\([0-9]*\)\|\(.*\)/\1\2\3/g'". This regex expects to find the version <= 900 but in fedora it is 1000 so we need to mod it to look like this "echo $mfile| sed 's/libgtk-x11-\([0-9*\).0.so.0.\([0-9]\)000.\([0-9]*\)\|\(.*\)/\1\2\3/g'". This one extra zero will make it run nicely and this method is applicable on one machine at a time, but when going full scale the regex should be modified to look for 2 OR 3 zeros, so lets hope that Adobe fixes it soon.

This "bug" also hunts the CentOS 5 and RHEL 5 and maybe some other newer distros.

So hope for the best and a quick fix from Adobe :)

technorati tags:Fedora, 7, CentOS, 5, Adobe, Reader, Bug, Fix

Blogged with Flock

LVM volume management made easy...

As a enterprise architect/infrastructure developer I'm faced with allot of problems that seem trivial on small scale but when you need to manage thousands of workstations or servers become critical problems. One of them is hard drive partitioning.

For security and stability reasons it is wise to split your root file system to several peaces - my default is:

/boot
/
/tmp
/var
/var/log
/home
swap

This may seem like crazy layout, but when you think of it, most problems start with servers getting root kited by some trivial exploit that will be used to trigger a buffer overflow and there for get a shell. If the tmp, var, var/log and home are mounted as noexec even when the exploit manages to download the overflow script - it wont be allowed to execute. This means its 1 step closer to avoid a security breach.

As I said before - it looks like a trivial task - install the server properly and thats it. Well this advice is good for up to 25..50 machines per admin, but it will fail miserably when you are running hundreds or thousands of machines. You may succeed to install them but soon after you are faced with a problem that some partitions need to be resized because one is almost empty and the other is constantly filling up.

If its just a pc you can take it offline and reinstall/boot to rescue and resize them. But when you are running mission critical servers its not an option. The same gos when you are running systems with different hardware configurations and there fore with different disk sizes. Here comes in the Logical Volume Manager (LVM). It creates another layer of abstraction on top of the physical layer therefore giving you another layer of dynamic configuration.

The greatest advantage of using LVM is that it you can create/resize/delete volumes on the fly without needing to reboot the server or boot to rescue to manage it. Sure it is not as simple as it sounds but basically it works wonders. It also gives the possibility to build the LVM volume on top of the hard drive or a raid device on full extent leaving you (in ideal case) with only 1 partition on the device (I use 2 - I like to keep /boot separately).

So in my case it is not wise make "full" partitioning of the drive, but to keep the partition sizes to minimum (that means with 10% overhead) leaving the rest of the drive free. This will allow me the simply "add" space to the volume that needs space without needing to shrink another volume (this volume cant be mounted while shrinking so this will need rescue mode!!!). Also keeping operating system on one volume group and data on another can save allot of work when restoring a system. For this I use a software designed by me called FabricManager - looks like I have to blog about in the future...

This works well until you run into a problem - You have 1000 workstations installed with this configuration and you want to do a dist upgrade. All is goo until you run out of space in the root volume to do it. 80% of the disk is filled with downloaded rpm's and there is no space left to install them. With LVM it is no problem, You just add some space to the root volume and all works out well, but here comes the catch - how long will it take to manually resize the root volume in 1000 workstations? I'm guessing around a month or two. And this is the best case scenario. Assuming that a good security policy is in place and none of the workstations have the same root password the time could be extended to few years which defies the whole point of upgrading. Sure if all the workstations have been installed with the same root password you can use an script to run the command automatically, but then You will run into about 10% of computers that wont accept the password and the 10..20% of PCs that are turned off at the time you run it. What about strict security policy that wont allow root to even log in remotely? What if the workstations are in different locations or countries or even continents? You can't just run the script few times and hope for the best as some workstations get several times the space needed and some get none.

And so a trivial problem grew out of proportions in seconds and one small design flaw can cost ALLOT of time trying to fix all the problems separately. this led me to write a small shell script that would be able to create/extend logical volumes as needed and it can be found here. It is not 100% what I need but the core functionality is there and it works.

This also solves problems with few "special" applications that need their own partition to run and as I try towards simplicity I can now package the script into the autoupdate package (right... haven't mentioned it before also... need to fix it in near future...) and set a dependence for it. So to automate the install of the application I just add one row in the %pre section of the package and woala - new volume created in the install time :D

It also helps to resize partitions by simply updating the base package of my configuration that contains the sizes of the required volumes. this gives me the ability to reconfigure workstations in few days to new configuration and life can go on...

For conclusion - security is important, so no cutbacks should be made there, noexec and nodev are your friends - use them wisely, LVM is a great tool but it is not a magic bullet - adding an extra abstraction layer multiples the complexity of the system so use it carefully and when developing large scale infrastructure multiply the the count of computers with 1000 and think if the solution is easily managed then.

This script was built for CentOS 4.4 and tested on it - it will work on other distros but may need some modifications.

technorati tags:CentOS, LVM, security, Infrastructure, bash, script, rpm, management, partitioning

Blogged with Flock

Centos 4.4 and 4.5 apt problems...

Ok, so the first question would be "Why the f*** do you use apt for CentOS?!?!". Well the answer is simple - yum is too intelligent and is too big of a blabber, so its not useful for automation. Thats why apt is preferred - its dumb as a door knob, it works fast and it does not try to do things fully automatically (like up2date).

up2date is also an alternative that could be used but wen you one day discover that the uber expensive and uber busy system has crashed and its the fault of up2date upgrading the system automatically, well... no thanks...

There is a file conflict between the centos-release and apt - one of them has got too smart. In 4.3 the centos-release provided just basic necessities, but now also includes both yum and apt repository lists. And as apt has not been upgraded for a while, there is a file conflict at hand.

The bug has been reported and assigned in the centos bug tracker, but it looks like the fix wont come out anytime soon.

So here is my quick fix - rebuild the apt rpm. In the apt spec file line 122 is:

%{__install} -p -m0644 centos.list %{buildroot}%{_sysconfdir}/apt/sources.list.d/

remove or comment out this line and run:

rpmbuild -ba apt.spec

To make the build succeed I also had to do this "hack" on line 140:

%doc %{_mandir}/man?/* -> %doc %{_mandir}/man*

This will produce a new rpm that can be manually upgraded with rpm and the upgrade to centos 4.5 can continue. This will also give an opportunity that when the conflict is finally resolved the new apt will get upgraded or the old one can be reinstalled depends on who gives up the file...

Also a recommendation for the apt maintainer would be to include a buildreq. for "bzip2-devel" and "libselinux-devel"

Update:

As I was asked for my version of the apt.spec I uploaded it here.

technorati tags:centos, 4.4, 4.5, apt, rpm, file, conflict, solution

Blogged with Flock