Just a quick tip. If you’ve ever tried to run sshd with the option X11UseLocalhost set to no (e.g. in a cluster environment where interactive jobs running not on the login node should be able to display something), you might have observed that X11 forwarding suddenly stops working. And although the DISPLAY variable is set accordingly and xauth list shows that authentication tokens are present, X clients still can’t connect:

hristo@cn001:~$ echo $DISPLAY
cn001:10.0
hristo@cn001:~$ xauth list
cn001.local:10  MIT-MAGIC-COOKIE-1  0123...
hristo@cn001:~$ xterm
xterm Xt error: Can't open display: cn001:10.0

And it’s even worse:

hristo@cn001:~$ telnet cn001 6010
Trying 10.1.1.1...
telnet: Unable to connect to remote host: Connection refused

The root of the problem stems from the fact that sshd usually binds only to the first address family it finds in the system and if your system has IPv6 enabled (e.g. the default on Ubuntu Server 7.10) it ends up binding only a tcp6 socket (and the X11 client library tries to establish a regular TCP connection):

hristo@cn001:~$ netstat -an | grep 6010
tcp6   0  0 :::6010     :::*  LISTEN

In order to fix this you can either disable IPv6 in the kernel or simply add the following option to /etc/ssh/sshd_config:

AddressFamily inet

After you restart the SSH server it will no longer use IPv6 and will start binding its X11 proxy listeners to the usual IPv4 INADDR_ANY of 0.0.0.0.

Ето един вече стар трик, който, за мое голямо учудване, мнозина все още не знаят. Става дума за не особено познатия параметър fmt в URL-ите на YouTube. С него се указва числен идентификатор на формат, представляващ комбинация от кодеци и качество на компресията на звука и картината. Възможните стойности са най-различни (за любопитните има търсачки), но особено интересна е стойността 18, която задава използване на MPEG-4 поток с видео кодек H.264 (480×360, 24 fps) и AAC (44,1 kHz, 128 kbps) стерео звук, очевидно предназначен за устройствата на Apple. За сравнение стандартният формат (когато не е указан параметър fmt) използва FLV поток с видео кодек Sorenson (320×240, 30 fps) и MP3 (22 kHz, 64 kbps ABR) моно звук.

За превключване на формата е достатъчно да се добави &fmt=18 в края на YouTube връзката, например: http://uk.youtube.com/watch?v=mLLBcAL8IdA&fmt=18. За сравнение, същият клип със стандартния формат. Дори да няма толкова очевидна разлика в качеството на картината, звукът се променя коренно. Теоретично (т.е. не съм проверявал на практика), съхранен във файл с разширение .mp4, видеопотокът във формат 18 следва да може директно да се гледа със софтуер и хардуер, използващ техонологии от ябълката.

Разбира се, всяко удоволствие си има цена. В случая тя е повече от двукратно завишаване на скоростта на битовия поток, от 200 kbps на 512 kbps, което означава повече трафик за хората с мобилни връзки и по-голямо време за зареждане при бавни такива. И не всички клипове се транскодират до по-високо качество.

Друг интересен формат е 6, който доставя отново FLV със Sorenson видео кодек и моно MP3 звук, но този път при разделителна способност 480×360 и 44,1 kHz/96 kbps CBR. Цената му е дори още по-висока — 900 kbps. Последният може да се избере за подразбиращ се при всички прегледи в секцията Video Playback Quality от настройките на акаунта в YouTube (да, трябва да сте регистрирани).

Трикът е изключително полезен за музикалните клипове в YouTube, които при стандартния формат трудно стават за слушане.

П.П. Въпреки, че котките са ми любимци, примерното клипче съдържа само кучета :)

If for some obscure reason you ever want to use Ubuntu Server 7.10 in a HPC scenario where your compute nodes are interconnected through InfiniBand fabric bear this in mind — Ubuntu’s IB support is broken and it has been in such a state for at least an year!

Besides from not providing the full OFED package, Ubuntu also gives us errors in udev’s configuration, namely in /etc/udev/rules.d/20-names.rules. On a pristine system the Infiniband section reads:

...
# Infiniband devices
KERNEL=="umad[0-9]*",         NAME="infiniband/%k"
KERNEL=="issm[0-9]*,          NAME="infiniband/%k"
KERNEL=="uverbs[0-9]*,        NAME="infiniband/%k"
KERNEL=="ucm[0-9]*,           NAME="infiniband/%k"
KERNEL=="rdma_cm",            NAME="infiniband/%k"
...

Noticed it? The closing double quotes on the lines for issm, uverbs and ucm are missing. Thus udev ignores those lines as errors and puts theirs device nodes in /dev instead of /dev/infiniband/ where most software expects them to be. For example OpenMPI’s openib BTL fails to run with such a configuration.

Correct the section so that it reads:

# Infiniband devices
KERNEL=="umad[0-9]*",         NAME="infiniband/%k"
KERNEL=="issm[0-9]*",         NAME="infiniband/%k"
KERNEL=="uverbs[0-9]*",       NAME="infiniband/%k"
KERNEL=="ucm[0-9]*",          NAME="infiniband/%k"
KERNEL=="rdma_cm",            NAME="infiniband/%k"

Now reboot and your device nodes will be placed where they are meant to be.

If you like me have used Firefox under Mac OS X, but prefer Safari for one reason or another, you might have already noticed that Safari does not support protecting your web form passwords with some kind of a master password. The reason for this behaviour is that Safari stores your sensitive passwords in the default “login” keychain that is automatically unlocked whenever you log into your OS X account and is kept unlocked until you log off. Safari is also granted an unlimited access to its entries in this keychain. The net result is that if someone gains access to your browser he can log into all those sites that you have your passwords remembered for.

One easy remedy is to create a separate keychain and to move your site passwords there. To do that:

1. Open Keychain Access from Applications:Utilities (or just type Keychain Access in Spotlight and hit Enter).
2. From the File menu select New Keychain… (or press ⌥⌘N)
3. Type a name for the new keychain file, i.e. Passwords and click the Create… button.
4. Pick up some good password and enter it twice in the following dialog.
5. When the new keychain is created Ctrl click (or right click) on it in the Keychains panel and select Change Settings for Keychain “Passwords”…. Make sure that Lock when sleeping is selected and you can also adjust the automatic lock timeout. I personally set it to 20 minutes.
6. Now select back the login keychain, click the Kind column header to sort keychain entries by kind and locate all of the “Web form password” entries that you want to secure and select them.
7. Drag the selected entries to your new keychain (Password in my case). You might have to enter your login password when moving each one of them.

That’s it — your web passwords are now protected by a kind of master password, used to unlock the new keychain. Unfortunately you’ll have to manually move all new passwords that you entrust Safari to remember from the “login” keychain to your secure store.