Archive for the ‘Software and Tools’ Category

Android XMPP/Jabber xep-0045 support, and the Talkonaut team on why Android sucks

Monday, March 2nd, 2009

Talkonaut is a pretty cool XMPP/Jabber application for mobile platforms. Its based around a paid Googletalk-to-Voip gateway service developed by Evgeny Korolenko and Ruslan Zalata called Gtalk-to-Voip

I have been using Talkonaut for some time for its Multi-IM support, it will connect not only to Gtalk and other generic Jabber services, but also MSN. This was of course very useful.

Now recently, I have been using a new and in-development chat system called Bindpoint, and have been hanging out in the chat channel dedicated to the Wowcast podcast, on that system. (this is the chat windows you see in my sidebar on the blog, though I correct to it via the Pidgin client).

Recently, the start-up behind Bindpoint, AOEware, created a Jabber bridge. I immediately starting looking for Jabber clients that supported the xep-0045 extensions to Jabber, which is what the Jabber chat-room function is built around, if people so choose to implement it.

Talkonaut is one of the few, if not only mobile client that I am currently aware of, that supports these extensions, and thus supports multi-user Jabber chat rooms.

For a short time, I very happily used Talkonaut in this way, to chat with my friends in the Wowcast Bindpoint channel, on my old HTC Universal Windows mobile 5-based phone.

However, as you know, I recently got myself a G1, which has the Android OS on it.

Now there are a few Jabber clients out there for Android, most notably the built-in IM application that is there mainly to support Gtalk, but also the Meebo multi-IM client is popular. However, Meebo does not support multi-user Jabber chat rooms.

In fact, I have not been able to find a single decent Android multi-IM or Jabber client, that supports the xep-oo45 extentions, at all!

So I decided to mail the Talkonaut team, to see if they had an Android version of their client in development (hoping perhaps, to get into a private beta or some such). I exchanged a few very interesting emails with Ruslan Zalata, and they are reposted below with permission:


Hello Robert,
Thanks for using Talkonaut. Unfortunetly Androind is very crappy platform based on Java which prohibits low-lever audio access (no full-duplex), and has no audio codecs. This means, we are unable to implement our main feature – VoIP calling, hence we cannot make any profit from this platform. So, until Google “fixes” these issues, we won’t start porting Talkonaut to Android. Hope you understand our position.

Me and some other guys already addressed these voip related questions on Android devepolment forum, there followed no response from Google. I believe they do afraid of mobile carriers who treat voip as a death pill to their business, and that is really true :-). So, in near fure we don’t expect voip possibilities on Android.
What’s more amazing is that Google removed XMPP/Jabber from basic setup of Android by request form T-Mobile. Seems carriers develop same attitude towards IM messegers as they are “stealing” SMS profit from them.

As for iPhone, i think it’s bit better platform, because of:
1. It is based on real BSD Unix (Darwin), but not Java machine running under Linux like in Android.
2. It was cracked (jail-broken) and you can install any application which can have access to any device feature, including hardware codecs, low-level duplex audio, low-level networking, etc.
We are currently working on version of Talkonaut for jail-broken iPhones both 1.0 and 2.0.
Standard (not jail-broken) iPhone is same sort of crap as Android – they are both fascist systems made to tie up users to some certain set of services/companies. One more platform in this row is BREW from Qualcomm.
In this regards, Symbian S60 and Windows Mobile are two independent platforms which will be first choise for developers in near future. Besides, they are well spread, well documented and have a large scale of third-party libraries developed for them aready.


I was impressed by Ruslan’s honesty and I can completely understand their reasons for not pursuing Android at this time.

What I find discouraging is how Google seems to have, in this example, again bowed to the Mobile carriers. The Android OS is suppose to be an open one, and I thought that would mean there would be more or less no restrictions on what could be developed for it.

I also saw that the same limitation is to blame for the lack of any home-brewed video recorders for the G1 (explained here), a seriously lacking feature, as unforgivable to my mind as the Iphone’s lack of copy-paste or background applications.

So despite the openness of the platform, we are still depending on Google and whatever concessions they made with their mobile partners.

In the meantime, I am still looking for an Android client with xep-0045 Jabber support, so I can chat with my Bindpoint friends on the go.

Forcing hardware power on state with IBM Director

Thursday, December 28th, 2006

Okie.. so I am totally bored at work, lets see what fun I can have with IBM Director and some spare servers lying around.

I thought it might be cool to try and make a rule that checked if a server had been turned off, and then brought it back up.

This would be usefull for us, as we cannot physically administer all the servers we are responsible for, and there are always overzealos ‘admins’ walking about in remote locations who have a tendency to sometimes turn off servers instread of just logging out.

Above you see 2 IBM xseries 306m servers on the bench. They both contain the PCI version of the IBM RSA-II remote management card.

This card gives you a nice web-based management interface for your server, even if its powered down. You can, for example, turn on the server from here, or monitor its vital statistics, and take control of the console.

You can also set up the RSA card to report to a central IBM Director management server. Here you see the server listed as a “physical platform”, and as you can see, it has been associated with the IBM Director Agent component running in windows.

We can do a lot of stuff with the object here, same as via the web interface, as much more, as you can see from the menu.

As you can see above, one of the things we can do from here is turn the power on and off remotely, as with the web interface.

We now have all the bits we need to build a solution.

We have an Alert source: The RSA-II card, and a management server to interpret the alerts, the IBM Director Server
We have an eventing engine that can bind the alert to some actions, and the IBM director server itself is capable of actually performing the actions too.

To start, we create a rule in the IBM Director Event Action Plan builder tool.

It consists of 2 components.. an event filter.. or ‘trigger’ as I like to call it, and then some actions to perform once the trigger is tripped.

In the IBM world, servers and software (such as agents) generate alerts using a bunch of different languages or protocols. You can read about some of them here.

The one we are looking for here is a so-called MPA Alert. Its sent out by hardware like the RSA card, or the xseries BMC (Baseboard Management Controller), or in our case by the RSA-II card.

We are gonna respond to the MPA.Component.Server.Power.Off event, here you see it occuring in the IBM director eventlog:

In our event action plan, we make a Threshold Filter that looks specifically for this event occuring.

We assign a 10 second timeout to the filter, and the Count field is set to 1, it only needs to occur once for the filter to trigger the actions.

Actions are pretty straitforward. We want the server in question to be turned back on when the event is triggered, and we want to recieve some kind of alert of this happening.

As you could see before, the IBM director server itself gives various power options for servers.

Luckily for us, when building events, the Event Action Plan Builder provides an interface to many of these controls for the Eventing engine to use

The last bit we need is a neato mail to be sent to us admins when this event is triggered.

So, now we can take our finished Event Action Plan, and apply it to some objects.

For this to work, you need to apply the Action Plan to the physical platform, not the Agent Object of the server.

Ok.. thats about it.

If all goes well, you will find you can no longer turn off the server, whahah. 😀 (unless you unplug the Ethernet of the RSA card of course).  It will turn itself on every time within 10 seconds of being turned off. Talk about uptime!

And to boot, you get a nice mail in your inbox:

WUS Server Tryout

Tuesday, November 30th, 2004

–I never finished trying out WUS, its still installed on the server, but I didn’t get it work, and havn’t had time to get back to it! Please bear that in mind if you read or follow this article!–

–This article is not ‘finished’–


Microsoft has released Windows Update Services Open Evaluation.

Registration will get you the 70mb setup.

Wus seems to be a completely different beast than SUS, reading though the features summery, it appears to have adressed practicly every major issue SUS had.

I thought I would give WUS a spin, see what its like, and I will blog my progress here. This post should not be regarded as a guide or walk though, though you may find it usefull nonetheless.


SUS uses BITS 2.0 to download updates more efficiently. Before installing WUS you need to get the BITS 2.0 update. Windows Server 2003 requires a restart for this.

You will need an SQL database for the download metadata (not the actual updates), and for storing configuration information about WUS and about clients.

I have an unnused instance of SQL that I will be using, using the standard port.


The WUS installation will create a database for in the instance, I dont have to manually edit the settings.

SUS requires at least 6gb of free disk space for content,but 30gb is recommended.

I like to see what I am installing, so I always extract the single-file executables microsoft produces. This also often exposes and MSI file, which is rather handy for software distribution, but not in this case.







The final screen gives the option of launching the configuration screen.


Lets have a look at what WUS has installed on IIS


Notice the SelfUpdate virtual directory at the bottom? That will be important for later..

Under the options tab of the main menu, I can select settings for syncronisation.


Here I hit the products that WUS will update, and I deselect anthing exept for Windows XP and Server 2003 family, as I dont run anything else in my little network.  I select a large number of new classifications, just to see what kinda stuff that is.


I also change the default languages WUS downloads at the bottom om this screen, and confirm that only approved downloads will be downloaded to my server.


I have chosen to install WUS on a non-standard port. The primary reason for this is security, and also you dont want SUS to install itself all over any website you might already be running on port 80 on the server. WUS clients will work just find using the nonstandard port of 8530, however, the self update functionality of Automatic Updates clients, an all versions of Windows Prior to XP SP2, need to selfupdate from a website on port 80.

Since we are running SUS on the nondefault port, we need to create a virtual directory on our default port 80 site, where to host the so called ‘update tree’, for Automatic Update clients to look for in order to self-update.

In this beta version of WUS, a script is provided especially for this.

For the beta release, you can perform all the steps in this section, “Step 2: Create folders in the file system of the WUS server” and the next section, “Step 3: Setup virtual directories in the Web site on port 80 of the WUS server” by running the following script:

cscript WUS install drive:program filesMicrosoft Windows Update ServicesSetupInstallSelfupdateOnPort80.vbs

If this script doesn’t work, and it didn’t in my case, you need to follow the manual steps in the deployment guide, but its no biggy. You need to create 2 virtual directories on your default port 80 website: SeflUpdate, and ClientWebService, see the deployment guide for details.

Final steps for the web server setup is DNS if you hadn’t sorted this yet. Both A records in your DNS server, and the proper host headers configured per IIS site.
I end up with http://fs_srv1.fluffshack.local:8530/wusadmin/ for my admin site, http://fs_srv1.fluffshack.local:8530 for the actual WUS update location, and http://static.fluffshack.local for my default website, whereunder the SelfUpdate virtual directories can be found.
I use Fully Qualified domain names here as best practice, but you dont have to.
(Note: http://static.fluffshack.local is a site that was already running on this server, you can find it publicly at .. of course the Selfupdate and ClientWebService virtual directories are under there, but all it needs are read and run script rights.)
I have defined a new OU in Active Directory to host the computer account, so I can apply a test policy to the computer.
The test policy will do 2 things: First it will make sure that any clients that fall under it, recieve the SUS Client component.
This software is needed for clients that are either Windows 2000 SP2 and lower, and Windows XP without SP1. Anything above that already has a version of Automatic Updates that will auto-update to a WUS version, apon first contact with the WUS server.

And that is what the group policy is for secondly, to apply the settings that will make Automatic Updates behave the way we want it to.

Windows XP Service Pack 2 clients, already have the version of the Automatic Updates client that WUS would otherwise install, and it support all the client-side settings natively.

In order to apply WUS client side settings via group policy, we also need to use a newer administrative template for Group policy, than the one that was installed by default with Windows Server 2003.

Windows XP Service Pack 2 computers already contain the updated ADM file, simply copy this file to the same location on your server, or the pc from which you edit the policy in MMC (or the Group Policy Management Console). The ADM files are always located on %systemroot%windowsinf

The file is called wuau.adm

When loading the new ADM file for the first time, and this may be true of any ADM files that come with Windows XP SP1 or SP2, you may recieve and error box that says the following:

The following entry in the [strings] section is too long and has been truncated.
This is simply the Group Policy editor not being able to deal with these newer ADM templates, this bug is known under KB 842933, and you can get the fix on that KB page also.
I set up the group policy object I have linked, with the SUS client MSI as assigned software, and I fill in the SUS/WUS options that I want to be enforced.

New version of BlogJet out!

Monday, November 22nd, 2004

Dmitry has released the Blogjet 1.2 beta!

Very cool! 1.2 includes, amungst other things, image resizing, file attachments, extended entries, excerpts and keywords, a brand new code editor with syntax highlighting and better code completion, easier account switching, XML-based drafts, typographic characters and autoreplacement of smilies, full XHTML support,

I have said it before, blogging is made super easy with this tool, I wouldnt post half as much without it! Great to the firefox plugin now included as standard!

Grab it here!

T.L. Pakii Pierce has a review up on it.

Death to PST files… KVS Enterprise Vault for Exchange

Saturday, November 13th, 2004

Someone just introduced me to a product called Enterprise Vault 5.0, by KVS (soon to be part of Veritas)

Enterprise Vault is a series of enterprise storage products, and may be the awnser to getting rid of user’s pst file hassels.

KVS virtualizes your exchange mailbox and sticks half of it in a database, rulesets allow mail to be automaticly transferred to this storage, transparant to the end user.

Some reviews:

(Its funny, 3 out of the 7 calls in my current queue are pst file related… support costs anyone?)