Buggy Intel RAID

Recently I solved an very nasty problem in the Intel RAID controller. The problem took me and my colleagues many hours and hairs, so I decided to describe it here in hope it will help someone.

The Intel RAID controller was configured from the BIOS to have two disks in RAID1 configuration and all was good.

00:1f.2 RAID bus controller: Intel Corporation 82801 SATA RAID Controller

Some time ago we put in additional harddisk (hot-swappable SATA) that was part of some other RAID in the past (it is important!), the machine recognized it, we formatted it and started using the disk. All was good until the moment we had to reboot the machine.

It just would not boot. The screen looked like this:

The message was (transcribing for keywords):
Gave up waiting for root device.
Check rootdelay=
Check root=
ALERT does not exist. Dropping to a shell!

"dmraid -ay" would sometimes detect the root filesystem and sometimes (with different disk) not.

After a while an idea struck me - could be that the RAID controller in addition to CMOS-kept configuration tries to autodetect the RAID partitions that might exist on the new disks.

This was the answer. After I cleared both start and end of the new disks, the RAID signature on the disks would no longer confuse dmraid and prevent the kernel to find the real root file system.

dd if=/dev/zero bs=1000000 count=200 of=/dev/sdc
# For a 1TB disk. For different disk you need to calculate bs and seek accordingly.
dd if=/dev/zero bs=1000000000 seek=1000 of=/dev/sdc

If this story helped someone, write in the comments.

Fiddler on Linux

A colleague of mine (web developer) recently undertook effort to move from Windows to Ubuntu. One last obstacle was lack of adequate analogs of program "Fiddler". Wireshark is too general to work with and does not allow http-specific operations (for example - change values in a request and replay it). It's cumbersome interface was also hard to work with.

Enter burp proxy suite. I know, I know, it is proprietary, closed source, cpu and memory hogging java application. But hey, if the alternative for the colleague to stay in Windows, anything counts.

As good as the program is, it remains to be proxy application. This posed a problem because the developer had to intercept http requests from a stand-alone application.

While intercepting network-originating requests is not trivial, on Linux there is simple way to redirect local traffic to the burp proxy. The trick is to run the program in "invisible proxy" mode using "root" account and redirect all traffic coming from certain user to port 80 through the proxy. This solves the catch22 problem of "intercepting all outgoing requests".

Here are the commands that accomplish that:

sudo iptables -t nat -I OUTPUT -p tcp --dport 80 -m owner \
--uid-owner evgeny -j REDIRECT --to-port 8080
sudo java -jar burpsuite_v1.3.03.jar
sudo iptables -t nat -D OUTPUT -p tcp --dport 80 -m owner \
--uid-owner evgeny -j REDIRECT --to-port 8080

An nice advantage of the burp proxy over fiddler is that developer can choose to modify the request on-the-fly. Now I have something to brag about to all fiddler-wielding windows losers :) .

mp10 DV003-XXL manual on russian

Инструкция по эксплуатации "шпионского фотоаппарата/камеры" MP10 (DV-003) на русском:
http://skliarie.meshanet.com/skliarie_blog/mp10_russian.odt

O GTalk team, where were thou?

Instant messaging (IM) penetrates our lives deeper and deeper, whether we like it or not. Most people start using whatever their peers so to be able to network with them. For that reason, switching default IM is tremendously hard thing to do, especially if one already accumulated number of contacts in previous network. This is called "Network Effect".

There are several factors that can make one consider the switch - presence of their peers on the alternative network, number of functions the IM client and the network offer, easy to use IM client, availability of the client on their platform and (unfortunately often neglected) - how proprietary the network protocol is.

For past several years GTalk team was consistently failing on almost every point (at least on Linux). There is no native GTalk client for Linux. Interoperability with open-source clients is poor, especially on advanced features (voice and video conferences). No Video in standalone GTalk client. No built-in group chat support. No way to transfer bunch of contacts. File transfer is not reliable. The XMPP servers occasionally refuse to allow login (on ports 5222 and 5223). No way to organize contacts per groups (in the official GTalk client). These are problems that I have struggled with. I am sure there are many others.

Some of the problems are caused by protocol restrictions. But Google already showed that it can extend protocols by adding Jingle to XMPP. Some are caused by open-source clients. Google also showed that it can fund that as part of summer of code projects. Apparently that was not enough. Google missed great opportunity to have an viable IM network by underfunding the GTalk team and most popular open source clients. For Google's finances that would be pocket charge expenses.

With the Network Effect the Skype network has accumulated, it will be impossible to revert the situation, unless something dramatically occurs. That makes me sad as XMPP+Jingle had great potential to become the IM of choice for the world.

I speculate that Google Voice will fail for this very reason, but once Google understand that, it will probably be too late.

Hebrew thesaurus for stardict

Someone asked me to find him stardict-compatible version of hebrew thesaurus. I have found torrent link that has english-hebrew, hebrew-english dictionaries and hebrew thesaurus. All files are in stardict format:
babylon_stardict.torrent

I am still looking for stardict-compatible version of russian-hebrew and hebrew-russian dictionaries. If someone has informative links, drop me an email please.

adaptec CLI management tool

Recently I had to install adaptec CLI management tool on an ubuntu 8.10 amd64 server. Despite the fact that aacraid driver is present in kernel, it took me a lot of time to find the management tools that allow to see the RAID status and manipulate it from command line. There are several names for the tools: afacli, aaccli, afaapps, afa-apps-snmp, arcconf, hrconf... oh my!
After I found the necessary tools (64bit arch), I packaged them into a tiny deb package adaptec-utils_0.0.1_amd64.deb, which can be downloaded from here: DELETED_AS_REDISTRIBUTION OF BINARIES_IS_PROHIBITED_BY_ADAPTEC

Also, I wrote a simple monitoring script (included in the deb package) that checks the state of the Adaptec RAID system and sends out an email if any of the published indicators is wrong (battery, failed disks, etc). The script can be downloaded from here:
http://skliarie.meshanet.com/skliarie_blog/adaptec-utils/adaptec_check.sh

Note that the script requires proprietary binary files to be installed. See the beginning of the script for the details.