Today, one of my colleagues inadvertently set off a linear fork bomb of ksh processes on a critical infrastructure machine. Linux held up well to this, since basically these processes were just entries in the scheduling table and very little else. The system was pretty responsive, albeit with a load average hovering between 800 and 3000, and we ran out of process identifiers fairly quickly.

Clearly, all of these processes would have the same process group, so we just needed to kill the process group as a whole. My other colleague and I came up with a good, stupid simple solution that neither of us had immediately thought of. As it turns out, Perl’s kill() system call interface has an interesting caveat that allows you to kill processes in exactly this way: when the signal is specified as a negative number, the function treats the other parameters as process groups to kill.

Actually, it turns out a lot of systems and shells allow specifying the process group ID as negative numbers to kill command/built-in where the pids would ordinarily go to specify the same action. It’s too bad my colleague was using an old version of ksh.

I finally got around to posting my OSCON 2010 attendee profile.

I wrote:

I work as a database administrator in a global team looking after a large financial institution’s relational database plant. For better or worse, this plant is 100% COTS; we’ll see what I can do to change that. While database administration in our group is awesome (computing + adrenaline = fun), I most enjoy the time spent writing internal tools in Perl and C, from compiled plugins for DB2 to automation solutions, and analyzing system faults in Linux. Evangelizing and teaching new trends, technologies, and best practices to my group is as important and enjoyable as the code I write, though. I love the reaction I get from disciples who finally realize and understand the power of git and zsh.

The company I work for somehow decided to get their SSL certificate for their employee portal from a CA not trusted by one of the main applications on the portal, the Citrix Client. (There may be an addition of “Xen” in the actual product name, who knows).

I received the error:

“You have not chosen to trust “UTN-USERFirst-Hardware”, the issuer of the server’s security certificate (SSL error 61).

The answer is fairly clear: we need to add this particular SSL cert, or the CA’s root cert into our trust anchor. To do this, we could save this cert and put it in the right place, or we can trust that OpenSSL has the appropriate root certs.

I chose the latter. To do this, we simply move the certificates trusted by the Citrix installation and symlink to the OpenSSL-based certs. Not rocket science.

$ sudo mv /usr/lib/ICAClient/keystore/cacerts /usr/lib/ICAClient/keystore/cacerts.old $ sudo ln -sf /usr/lib/ssl/certs /usr/lib/ICAClient/keystore/cacerts

Voila. Retrying to connect to the Citrix (?:Xen)?(?:App)? Server works.

A really sweet animation of Git interaction between developers of the Linux Kernel:

I’m currently reading Christian Benvenuti‘s excellently written Understanding Linux Network Internals from O’Reilly which is helping to shore up my knowledge about how the networking stack is implemented in Linux. It’s a fantastic read so far, on course to match Linux Kernel Development by Robert Love, one of my all-time favorite books.

The following paragraph from Benvenuti’s book really made me step back and take a look at the bigger picture:

A device driver can also disable the egress queue before a transmission (to prevent the kernel from generating another transmission request on the device), and re-enable it only if there is enough free memory on the NIC; if not, the device asks for an interrupt that allows it to resume transmission at a later time. Here is an example of this logic, taken from the el3_start_xmit routine, which the drivers/net/3c509.c driver installs as its hard_start_xmit function in its net_device structure…

That passage is just brilliant. Count the occurrences of jargon there!

I guess i should read more arXiv papers to better understand how much larger the world actually is.

The following some XSLT sufficient to transform an OPML file into a list, ready for you to edit and post:

<?xml version="1.0" encoding="UTF-8"?></p>

<p><xsl:stylesheet version="1.0"
  xmlns:xhtml="http://www.w3.org/1999/xhtml"
  xmlns="http://www.w3.org/1999/xhtml"
  xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
  xmlns:xs="http://www.w3.org/2001/XMLSchema"
  exclude-result-prefixes="xhtml xsl xs"></p>

<pre><code>&lt;xsl:template match="body"&gt;
    &lt;ol&gt;&lt;xsl:text&gt;
</code></pre>

<p></xsl:text>
            <xsl:for-each select="outline">
                <li> <a href="{@htmlUrl}" ><strong><xsl:value-of select="@text" /></strong></a> - your text </li><xsl:text>
</xsl:text>
            </xsl:for-each>
        </ol>
    </xsl:template>
</xsl:stylesheet></p>

<p>

It isn’t 100% complete, but will get you a list of the form:

</p>

<ol>
    <li><a href="URL"><strong>Title</strong></a> - your text</li>
</ol>

<p>

In a sane interface to an operating system, you can run the following to produce transformed output, given the XSL above and an OPML file:

$ xsltproc extract.xsl google-reader-subscriptions.xml

In response to the current /. poll, Most Useful UNIX Tool: I have the following from my ~/.zhistory at work:

$ for cmd in sed grep cat find telnet init exit ; do echo -n $cmd= ; grep -c “$cmd ” ~/.zhistory; done sed=85 grep=875 cat=762 find=126 telnet=15 init=32 exit=33

Which is interesting to me. I can explain some of the counts:

• I run ‘cat $file | (grep|sed|awk) | …’ too often out of a good/bad habit.
• ‘exit’ is small because I’ve bound ”x’ to exit (which itself is a bad habit; I should have just started using ‘Control-D’.
• ‘ssh’ > ‘telnet’
• I don’t have root, so ‘init’ isn’t really used, and my regex isn’t careful enough to eliminate ‘disk_init’.
• ‘sed’ is mega-useful, but is usually the second command in a pipeline. I want to start using ‘perl -pe’ more.

I’ve always wondered why Macs could wakeup from sleep by a mere keystroke, but my Linux boxes required me to press the power button. It turns out you can enable wake from suspend/hibernate in Linux by adding the following to /etc/rc.local, which is run at startup:

for i in <code>/bin/grep USB /proc/acpi/wakeup | /usr/bin/awk '{print $1}'</code>; 
do 
    echo $i > /proc/acpi/wakeup; 
done

/proc/acpi/wakeup will then look something like:

$ cat /proc/acpi/wakeup
Device  S-state   Status   Sysfs node
PCI0      S5     disabled  no-bus:pci0000:00
PEX0      S5     disabled  pci:0000:00:1c.0
PEX1      S5     disabled  pci:0000:00:1c.1
PEX2      S5     disabled

PEX3      S5     disabled

PEX4      S5     disabled

PEX5      S5     disabled

HUB0      S5     disabled  pci:0000:00:1e.0
IGBE      S5     disabled

USB0      S3     enabled   pci:0000:00:1d.0
USB1      S3     enabled   pci:0000:00:1d.1
USB2      S3     enabled   pci:0000:00:1d.2
USB3      S3     enabled   pci:0000:00:1a.0
USB4      S3     enabled   pci:0000:00:1a.1
USB5      S3     enabled   pci:0000:00:1a.2
EHC1      S3     disabled  pci:0000:00:1d.7
EHC2      S3     disabled  pci:0000:00:1a.7
AZAL      S5     disabled  pci:0000:00:1b.0

and voila: when your Linux box suspends, you can wake it up by pressing any key on your USB keyboard.

I’ve started to use ratpoison on my netbook. I’ve made a script that displays a menu of power-related actions and the current state of the battery. Here is a screenshot:

[discharging 58%] SLEEP HIBERNATE REBOOT SHUTDOWN LOCK

The script uses ratmenu to actually display the menu and uses dbus to send signals.

download ratpower.sh

Saw this on Freshmeat today:

About: [some open source project] is a real-time collaboration (RTC) server. It uses the only widely adopted open protocol for instant messaging, XMPP (also called Jabber). [some open source project] is incredibly easy to setup and administer, but offers rock-solid security and performance. Changes [in the new version]: A security flaw allowed authentication to be bypassed, allowing arbitrary code execution. This was fixed. JDBC and JID optimizations were done.

(Emphasis mine).

Wait, really? rock-solid security != arbitrary code execution, last time I checked.