Sniffing reveals that my XMPP packets are not resulting in response in a reasonable time (more than 10 seconds), causing the client to retransmit several times. Eventually I get a response, but I believe that somewhere in the handshaking or even later, a timeout is reached and the connection fails. A screenshot, note the Time field:

I tried contacting their support two weeks ago, but no response yet.

Can anybody shed more light on this problem?

1. Hold Ctrl+Shift+U
2. Type the unicode hex code (e.g. 2603)
3. Press space

Viola☃

It’s been a while since I wrote these two posts about keyboard shortcut, so I’ll try to summarize some neat ones I’ve recently learned:

Unix Shell

• Ctrl+U deletes all characters on the cursor’s left. And.. keep it in the shell’s clipboard.
  
• Ctrl+K deletes all characters to the cursor’s right (including the cursor’s position), keeps in clipboard.
• Ctrl+Y: paste clipboard.
• Ctrl+R: search for string in history. Multiple Ctrl+R’s search for the next matches in history. Btw, It’s F7/F8 on windows command prompt.
  

Google vim keys and more

• Google search: Google Experimental Search, enables vim keys for browsing the results! Super useful.
  
• Google Calendar support vim keys (j, k, l, m) for navigating in the calendar. Type “?” for more keyboard shortcuts.

GNOME

• Alt+F10 toggles between maximal window size and original window size.
• Alt+F9 minimizes window
• Alt+F8 switches to resize window mode
• Alt+F1 opens the GNOME menu.

Thanks for Zohar and Aviv for presenting me with most of the above shortcuts.

Recently, the bus home was replaced with a shiny new one, which also provides Wi-Fi access. That’s brilliant – as long as I have a seat, I don’t mind how long the ride home takes. I just hope it doesn’t radiate too much =)

Anyway, I’ve noticed that I fail to connect to Google talk through my favorite client, Pidgin, when connected to this Bus’ wireless LAN. It’s really fun to do some debugging with xterm and wireshark with passengers watching with curiosity.

And to the point – I’m not sure where this standard is defined (XMPP?), but Google recommends setting the Google Talk “domain” as gmail.com. But where is the XMPP server ip/name taken from? It’s not gmail.com, as the telnet gmail.com 5222 fails.

Quick sniffing tells that my pidgin (and probably other clients) use DNS SRV records. SRV records (RFC2782) are a pretty neat idea: it lets you query your domain for services. Why remember (or worse: guess) what’s the name of the SMTP server? Instead, SRV records suggest a way to ask a domain what’s the IP of the domain’s major SMTP service.

The DNS name is of the following structure: _<service name>._<protocol>.domain.

In our case: _xmpp-client._tcp.gmail.com. Let’s run this nice command line:

# host -t SRV _xmpp-client._tcp.gmail.com

_xmpp-client._tcp.gmail.com has SRV record 20 0 5222 talk2.l.google.com.

_xmpp-client._tcp.gmail.com has SRV record 20 0 5222 talk3.l.google.com.

_xmpp-client._tcp.gmail.com has SRV record 20 0 5222 talk4.l.google.com.

_xmpp-client._tcp.gmail.com has SRV record 5 0 5222 talk.l.google.com.

_xmpp-client._tcp.gmail.com has SRV record 20 0 5222 talk1.l.google.com.

So briefly, each SRV record holds host name, port number, priority and weight. A single service may have several records, thus providing some kind of high availability and load balancing.

SRV records are intensively used in Microsoft Domains since Windows 2000, and it’s even possible that they invented it (they’re signed in the RFC after some non-microsoft guy). In that case, kudos to Microsoft for either inventing or pushing forward a good technological standard. Haven’t seen this frequently.

So, it seems that the DNS in this bus disrespects my SRV queries, and thus my Pidgin can’t figure out who is the Google Talk server. Setting another DNS server solved the problem.

This weekend I tried to debug an annoying problem in Drupal‘s Acquia Marina theme on RTL mode, in which a horizontal scroll bar appears with no good reason (layout doesn’t scale horizontally).

I turned to monkey HTML debugging, a term I just invented for removing element-by-element until getting to a super simple HTML file which reproduces the bug.

Eventually the one to blame was an element placed at “left: -999em” absolute position,  a far place horizontally, and triggered the scroll bar to appear (on FF and IE, not on Chrome). When on LTR mode, it didn’t, and things work perfectly. This setting aims to simply hide the drop-down menu when mouse is not hovering above it.

Q: Why don’t they use CSS display:none, which seems to make more sense than hiding things off the screen?

A: looks like it has to do with screen readers (as this article suggests), which are apparently not aware of display:none text but are aware of off-screen text. A little puzzling. I suspect that it’s too old info, for it seems to be written on 2003. I wonder if new screen readers have this problems as well, and whether the reason for using off-left is not just an ancient myth.

The problem with RTL

When placing things off-left (e.g. left: -999px) on LTR mode, all browsers do NOT widen the page horizontally. It makes sense – the page goes from left to right, not from left to even-more left.

However, when on RTL mode, left: -999px does widen the page horizontally to the right (and the off-left element is actually visible when scrolling there), which is a very unwanted effects.

Here’s a related drupal discussion about the problem and possible solutions.  The problem seems broader than just acquia marina .

Potential Solution #1: use off-right on RTL: BAD

That’s the most trivial solution. It seems to work on IE8, chrome and FF. However, IE7, even on RTL, keeps widening the page and creating a horiz. scroll bar when using right: -999px. as for my inspection IE7 does not cope well with off-right (nor off-left) on RTL!

Another, more minor downside, is that this solution requires different styling-code for LTR and RTL.  It’s always preferred to have code that is not direction-specific, so that even when not keeping RTL in mind, the page would be RTL-compliant.

Potential solution #2: off-top

As far as I know, there are no TTB (Top To Bottom) languages on the web, so hiding things off top would be best. From my tests, all common browsers (IE7, IE8, chrome, FF) like it. I wonder why people didn’t use it in first place instead of off-left, did I miss any disadvantage?

Long-term solution: an intuitive new standard

Personally I believe that neither off-left, off-right nor off-top are intuitive, these looks more like hacks, and I bet that most web developers don’t even know about these. So even, for the sake of accessibility, it’s important to resolve this screen reader crisis (if it exists at all), and have an industry standard for setting elements as hidden.

First step should be figuring out why/whether screen readers don’t support display:none; can readers confirm that and go into deeper details?

Second step might be fixing the standards so that screen readers would support it, if needed.

—–

And the patch for fixing the RTL horizontal-scroll bar bug in Drupal’s Acquia Marina theme:

— a/style.css
+++ b/style.css
@@ -1145,7 +1145,7 @@ div.rounded-inside {

#primary-menu ul.menu li ul {
background: transparent url(‘images/drop-bottom.png’) no-repeat 0 bottom;
-  left: -999em;
+  top: -999em;
opacity: 0.95;
margin: 0 0 0 -10px;
padding: 2px 0 4px;
@@ -1157,7 +1157,7 @@ div.rounded-inside {
#primary-menu ul.menu li:hover ul,
#primary-menu ul.menu li.hover ul {
display: block;
-  left: auto;
+  top: auto;
}

#primary-menu ul.menu li ul li {
@@ -1195,7 +1195,7 @@ div.rounded-inside {
}

#primary-menu ul.menu li ul li ul.menu {
-  left: -999em;
+  top: -999em;
margin: 0 0 0 -14px;    /* LTR */
padding: 6px 0 4px;
}
@@ -1231,7 +1231,7 @@ div.rounded-inside {
}

#primary-menu ul.menu li ul li ul.menu li ul.menu li ul.menu{
-  left: -999em;
+  top: -999em;
margin: 0 0 0 -14px;
padding: 6px 0 4px;
}

Update: I have opened a bug for acquia marina, and found another related bug (it’s me commenting there about off-top).

Back when I started my way with Linux with the brand new RedHat 6.0 (which as always, preferred GNOME). KDE always went forward: KDE1 was pretty.. basic, KDE2 was a big step, and same goes from KDE3. I’ve been using KDE 3.5.x for quite a long while (RHEL/CentOS5 and Debian sid until recently). 3.5.x symbolizes, in my opinion, the last “winning’ era of KDE:  It had the right features, but more important: it was mature and stable.

KDE 4 introduced important improvements:

• User interface continued the tradition of being much nicer than its predecessors. Compare for yourselves: KDE 1 2 3 4
• Very nice OpenGL effects were added with two important advantages over GNOME+ Compiz: the OpenGL features are fully integrated inside KDE, configuration is way easier (Compiz configuration tool is scary), and the attitude is more towards productivity and less toward eye-candiness. For example, instead of the useless wobbling windows and water effects of Compiz, KDE provides the useful feature that displays all open windows and allows search-as-you-type for choosing the right application by its name, by simply putting the mouse pointer  on the top-left corner.
• Simplified user interface: the developers had the courage to do some rewrites and strip complicated GUIs, even lose some features, and make the new KDE 4 apps more simple. This is mostly notable in konsole and amarok.

But, it also got worse than its predecessors on some areas:

• Relatively instability and immaturity: i’ve been finding too many elementary bugs, such as closing the laptop lid when locked doesn’t send computer to sleep, or low battery warning increases screen brightness instead of decreasing (My examples are especially in the power management area, but not only). Being important yet unresolved for almost a year, makes it really frustrating. which leads me to the next point…
• Relatively inactive community, bad bugzilla state: the KDE bugzilla is too messy: lots & lots of bugs stuck, neglected, on UNCONFIRMED, many bugs that are open for years (even bugs from KDE2). There should be much stricter policy there, irrelevant bugs should be rejected, confirmed bug should be set to NEW for distinguishing real from imaginary, and relevant bugs should be addressed. I’m aware that it’s a (mostly?) voluntary project, but it doesn’t mean that its problems shouldn’t be discussed.
• Unattractiveness to debug and fix the problems by myself: I admit that I didn’t try hard enough, but reading and fixing KDE’s code is an activity that I’m quite scared of. Maybe its the massiveness of the code, maybe it’s because KDE is not yet another application but my desktop environment.

3 things I recommend to the KDE project:

• Focus on stability, start a real feature freeze for the 4.x tree, clean the bugzilla: by either rejecting or fixing bugs.
• Attract more users to become developers and QA guys.
• Elect a leader. As far as I understand the KDE project doesn’t have a single leader. This is quite puzzling. I believe that in order to achieve real goals, there ought to be a single person to dictate the direction of the project.

As a new GNOME user, and for being fair, 3 things that GNOME should learn from KDE:

• gnome-terminal lacks many important features that konsole suggests: search buffer, unlimited buffer, notify on [in]activity.
• GNOME’s Run dialog (alt+f2) is quite “dumb” compared to KDE’s krunner.
• Compiz should be more integrated in GNOME, be simpler to configure and more productive.

I thank for the KDE developers and the Debian-KDE guys for their efforts; I hope to start a real discussion about the KDE project’s weaknesses, in order to improve them significantly, so I could switch back to KDE at 4.5.x !

UPDATE2: THE BUG WAS SOLVED! Alexander Wirt patched nfs-kernel-server: by removing the linkage of libtirpc, it now uses the previously method of IPv4 binding, thus not triggering the problem. When/if would rpcbind replace portmap – I don’t know.

[ This article describes my analysis to a problem found in Debian Unstable(sid) ]

1. The bug (link)

Since the end of December, a change in nfs-kernel-server package caused a change of behavior in some NFSv3 crucial services: rpc.statd, rpc.mountd. NFS is RPC-based, and as thus, it uses an RPC-to-UDP/TCP address translation service, aka port mapper. These services try to connect to port mapper when they need address translation, and since the recent change they first try to do it over IPv6.

portmap, the current widely-used rpc port mapper service, does not support IPv6. This causes these crucial services to die, and NFSv3 fails to start (actually, with default configuration it even prevents starting an NFSv4 server).

2. So… rpcbind?

While quickly researching the problem, I’ve leanred that rpcbind is a portmap-alternative, which does provide IPv6 support. While this is not necessarily the solution to the bug (rpc.* services could simply try IPv4 if IPv6 fails), it seems that a transition from portmap to rpcbind should be done anyway:

• rpcbind adds IPv6 support, which is, apparently the future (or is it..).
• Fedora12 (And thus the upcoming RHEL6) has already dropped portmap in favor of rpcbind.
• rpcbind is a fork from Sun, so I assume that modern Solaris also use rpcbind.
• rpcbind’s last commit took place on 4 months ago, while portmap’s last commit took place 10 months ago.

These reasons might not be strong enough. I just get the feeling that the winds blows toward the rpcbind direction, but I have no idea which code is actually better. It is, of course, possible to improve portmap instead of moving to rpcbind.

3. The current problems of  rpcbind transition

• [ UPDATE: FIXED ] The package doesn’t install an init script
• [ UPDATE: FIXED ] The package conflicts with portmap package (e.g. they both listen on the same port), but isn’t defined as conflicting
  • Filenames conflict as well (/usr/bin/rpcinfo), but the package maintainer solved it by renaming it to /usr/bin/rpcbindinfo

• Many packages depend on portmap only. They should allow rpcbind as well. And should be tested with it.
  • Actually.. for packages which cannot work with portmap anymore  (such as nfs-kernel-server), if there’s no plan to fix the portmap coupling, they should depend on rpcbind only now.

4. Why am I blogging this?

As always, to help people research their problem. According to popcon there are more than 10,000 Debian sid users, and that’s a lot of people potentially having NFS server problems.

And, because I’m a bit worried. Well, worried is a big word, it’s just a distro after all. Well, an unstable distro, even. Still, this is quite a major issue, and in the last 10 days I’ve hardly noticed any activity in the Debian community regarding this one. Only today it was mentioned on the mailing lists (yes, I know, I should have done this myself), and no replies yet. So, I hope that smart Debian guys would check it out and find the right recipe.

5. Oh, and a quick, dirty solution until they fix it

a. aptitude remove portmap (or just stop it and remove it from the boot sequence)

b. aptitude install rpcbind 0.2.0-2

c. Put an init script in /etc/init.d/rpcbind (here’s my recommended script)

d. Add rpcbind to /etc/insserv.conf, in the “portmap” line (so init script that depend on $portmap would depend on rpcbind also)

e. Run insserv /etc/init.d/rpcbind to reorder the init scripts.

f. Reboot (or start rpcbind and then all the rpc services).

Fabian Arrotin reports about this spamassassin bug, which tags mails dated 2010 and later – as potential spam (increases its spam-score). This is not silly – many spammers use fictional (far past/future) dates, wishing their spam would stay in the top/bottom of the long list of mails.

This bug alone didn’t cause false positives in my spam folder (only increased the score from 0.0 to 0.6), but in some configurations or situations it could happen.

The Fix

The bug was discovered about two hours after the first appearance of 2010 (UTC), and got fixed* a few hours later.

I was surprised to discover the sa-update tool which is an integral part of the spamassassin package. It fetches the updated rule sets to /var/lib/spamassassin dir, which spamassassin is aware of by default. This directory’s files override the shipped, old rules in /usr/share/spamassassin.

After this incident, I linked this file /usr/share/spamassassin/sa-update.cron to the /etc/cron.daily dir.

* The fix, by the way, is quite a patch – it makes sure the mail’s date is not after 2020.. I smell a repeat of events

Well, with all the udev badness, there are many useful tools in the udev package, which help to understand how udev works. I’m still far from knowing all the tricks, but here are some things that I’ve learned recently:

Note: the udev tools got changed several times during the last 5 years. I’ll cover here the latest version (149), and the older, RHEL/CENTOS5 version.

1. INFO: get all info available to udev about a certain device (or all devices):

# udevadm info -e (RHEL5: udevinfo -e)

Try it.. amazing, eh? You can use each detail to write udev rules to match these devices.

2. DEBUG: see everything that udev does

a. On demand debugging: udev sends messages to syslog. Easiest way to see what udev does, is by increasing the log level. as easy as a pie:

# udevadm control –log-priority=debug (RHEL5: udevcontrol log_priority=debug)

b. boot in debug mode: most of udev actions are running at boot time, so we need a way to tell udev to start in debug mode. This way /var/log/messages would contain all udev actions messages starting with the very first one. Yes, syslog is down when udev starts.. Any idea how it works?

How to do it?

# edit /etc/udev/udev.conf: set udev_log=”debug”

(RHEL5 has a nice trick: add udevdebug to the kernel boot parameters)

3. TRIGGER – causes something like a udev rescan: all add events are re-sent from the kernel, thus triggering all udev rules.

# udevadm trigger (RHEL5: udevtrigger)

4. SETTLE - blocks until udev has finished working on its queue. Due to the asynchronous nature of modern kernels, commands may return before the real expected action got finished. E.g.: a command for loading a kernel module might finish running before the network interface was really created, so if the next command expects a network interface it should wait until it’s created. Ok, to the business:

# udevadm settle (RHEL5: udevsettle)

5. TEST/MONITOR: sound very useful, although I found debugging (mentioned above) as the better method for most scenarios, so I didn’t dig them much.

I hope this article will be helpful. Do you have a cool udev tip or trick? Be nice and post it as a comment!

Q: How come “which ifconfig” (runing as a user) finds nothing, yet “sudo ifconfig” does work?

A: sudo has a compile-time parameter called with-secure-path, which sets a different PATH for the sudo environment. Debuntu secure path contains /sbin:/usr/sbin, and that’s how it works. This feature gets two goals: convenience (no full path required for common root cmds) and security (ignoring potentially bad user PATH).

NOTE that RHEL doesn’t use this option, and running “sudo ifconfig” there simply fails.

Q: How come sudo requests a password only on the first run?

A: Sudo has a nice mechanism for creating these “sudo session” things. After authentication, sudo creates a ‘timestamp dir’ (in /var/run/sudo on my Debian), then uses its date to check when the last successful authentication took place.

• Session timeout is configurable, defaults to 15mins.
• sudo -k kills this session by simply removing the timestamp dir.

All info is found in the sudo(8) and sudoers(5) manpages

Setuid and LD_LIBRARY_PATH

Just a quick insight from my workplace: to my surprise, a setuid binary deliberately ignores many environment variables such as LD_LIBRARY_PATH and LD_PRELOAD.

Security Shmecurity..