Threshold filter & what about RDF Annotations

I hope Google Sidewiki has a good threshold filter so we can vote down drivel and not have to see it. Browsing through the first several pages of the Google Sidewiki Sidewiki showed me this neat tool is already getting messy on a high-traffic page, and here I am adding to it. ;)

I've been waiting to try a mature RDF Annotations solution as proposed in the Amaya browser documentation for Annotations. A kind of mix between Google Sidewiki and Google Notebook.

in reference to: Google Sidewiki (view on Google Sidewiki)

Linux VServer & PAM limits

I've been getting some setrlimit "Security Events" reported by logcheck the past few weeks from a Debian 4.0 (Etch) virtual host running on a Debian 5.0 (Lenny) host. I was busy when they started and didn't drill down to see if it started with a security update in one system or the other.

Jun 15 10:09:01 green pam_limits[4284]: setrlimit limit #11 to soft=-1, hard=-1 failed: Operation not permitted; uid=0 euid=0 Jun 15 10:09:01 green pam_limits[4284]: setrlimit limit #12 to soft=-1, hard=-1 failed: Operation not permitted; uid=0 euid=0

Today I did some searching and found a few related posts ranging from bugs in sshd's limit setting to Linux-Vserver specific cases.

• http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=171673
• http://www.mail-archive.com/vserver@list.linux-vserver.org/msg08783.html
• http://osdir.com/ml/linux.pam/2007-09/msg00024.html

One suggestion from the Linux-Vserver list was to just comment out the use of pam_limit in the pam configuration files. I didn't want to throw the baby out with the bath water so I decided to take their other suggestion and modify the /etc/security/limits.conf file.

First I had to find out what limit #11 and #12 were on my system. I'm running a 686 kernel so I looked in include/asm-generic/resource.h of the matching kernel source. There I found that 11 was RLIMIT_SIGPENDING and 12 was RLIMIT_MSGQUEUE. Before getting there I had grepped around and noticed that the alpha and mips architectures swap a few values around so you may need to look at more than the generic header.

Next I used the ulimit command to list the values of pending signals (-i) and POSIX message queues (-q) applied to a default user session in the host system. I modified the /etc/security/limits.conf to set the hard and soft limits for these two resources to match. This stopped the setrlimit messages in /var/log/auth.log for new ssh logins, but they remained when cron attempts to run as root even after restarting cron. The same happens if I allow root ssh logins and login as root.

• http://linux.derkeiler.com/Mailing-Lists/Debian/2008-08/msg01096.html

PuTTY X11 forwarding stopped working on Vista

At work my primary desktop system is running Windows Vista Business 64 and our servers are all Debian. Almost daily I access these servers using ssh via the awesome PuTTY (0.60) program. When I want some graphical display returned, like a gvim, pgadmin3 or etherape, I fire up Cygwin/X and use it as my local X server. Once configured this has been working flawlessly for years on MS XP and Vista the past several months.

Yesterday when I tried firing up etherape to track down some network usage, I got the discouraging message "X connection to localhost:10.0 broken (explicit kill or server shutdown)." I followed some basic ssh and X forwarding troubleshooting steps and everything checked out. Finally I found and installed iftop which was everything I wanted ntop to be and did a good enough job.

Today I tackled the issue and found that a Cygwin/X xterm would properly bring the xclient home to my desktop, so the issue was not the servers (which had not had any software changes in the previous few days) it must be the software running on Windows.

I looked at the PuTTY > Connection > SSH > X11 settings and noticed the X display location was blank. I thought this might be akin to the $DISPLAY variable so I checked the help file. It said that if the field was blank PuTTY tried to use :0. Sounded reasonable, but I decided to test it anyway. The xterm had said $DISPLAY was 127.0.0.1:0.0 so, prefering names over numbers, I tried localhost:0.0. No dice. I then tried 127.0.0.1:0.0 and was rewarded with xclock and friends from the remote system.

A little googling lead me to a bug report from 2004 about possibly needing to specify the X display location. I don't think my issue was the same. The note claims that using localhost:0 on MS Windows should work, and it does not for me. I believe that some recent Windows Vista update or setting change (I have not changed networking settings for months) has broken localhost:0, but somehow using the ip address instead of the name works from PuTTY. It doesn't matter if I use the number or the name in a local Cygwin xterm.

Next I pulled up the trusty cmd.exe and tried ping localhost. This showed me that localhost resolves to the IPv6 address ::1. Perhaps this has changed recently due to a Windows update or some setting change I don't remember? I don't know if the root issue is Cygwin/X server not listening on IPv6 addresses (perhaps my version isn't even capable) or if the IPv6 syntax doesn't play nice with the final :0. I did try setting the display to ::1:0 in the xterm and that didn't work. It said "_X11TransSocketINETConnect: Can't get address for :: Error: Can't open display: ::1:0".

For now I'm going with updating all my PuTTY session configs to use 127.0.0.1:0.0