Older blog entries for dkg (starting at number 48)

EDAC i5000 non-fatal errors

I've got a Debian GNU/Linux lenny installation (2.6.26-2-vserver-amd64 kernel) running on a Dell Poweredge 2950 with BIOS 2.0.1 (2007-10-27).

It has two Intel(R) Xeon(R) CPU 5160 @ 3.00GHz processors (according to /proc/cpuinfo, 8 1GiB 667MHz DDR2 ECC modules (part number HYMP512F72CP8N3-Y5), according to dmidecode, and an Intel Corporation 5000X Chipset Memory Controller Hub (rev 12) according to lspci.

The machine has been running stably for many months.

On the morning of March 31st, i started getting the following messages from the kernel, on the order of one pair of lines every 3 seconds:

Mar 31 07:04:38 zamboni kernel: [16883514.141275] EDAC i5000 MC0: NON-FATAL ERRORS Found!!! 1st NON-FATAL Err Reg= 0x800
Mar 31 07:04:38 zamboni kernel: [16883514.141278] EDAC i5000: 	NON-Retry  Errors, bits= 0x800

A bit of digging turned up a redhat bug report that seems to suggest that these warnings are just noise, and should be ignorable. Another link thinks it's a conflict with IPMI, though i don't think this model actually has an IPMI subsystem.

However, i also notice from munin logs that at the same time the error messages started, the machine exhibited a marked change in CPU activity (including in-kernel activity) and local timer interrupts:

I also note that more rescheduling interrupts started happening, and fewer megasas interrupts at about the same time. I'm not sure what this means.

A review of other logs and graphs on the system turns up no other evidence of interaction that might cause this kind of elevated activity.

One thought was that the elevated activity was just due to writing out a bunch more logs. So i tried removing the i5000_edac module just to keep dmesg and /var/log/kern.log cleaner. Leaving that turned off doesn't lower the CPU utilization or change the interrupts, though.

Any suggestions on what might be going on, or further diagnostics i should run? The machine is in production, and I'd really rather not take down the machine for an extended period of time to do a lengthy memory test. But i also don't want to see this kind of extra CPU usage (more than double the machine's baseline).

Tags: i5000_edac, troubleshooting

Syndicated 2011-04-09 00:00:00 from Weblogs for dkg

Debian on Thecus N8800Pro

I recently set up debian on a Thecus N8800Pro. It seems to be a decent rackmount 2U chassis with 8 3.5" hot-swap SATA drives, dual gigabit NICs, a standard DB9 RS-232 serial port, one eSATA port, a bunch of USB 2.0 connectors, and dual power supplies. I'm happy to be able to report that Thecus appears to be attempting to fulfill their obligations under the GPL with this model (i'm fetching their latest source tarball now to have a look).

Internally, it's an Intel Core 2 Duo processor, two DIMMS of DDR RAM, and a PCIe slot for extensions if you like. It has two internally-attached 128MiB SSDs that it wants to boot off of.

The downsides as i see them:

BIOS

The BIOS only runs over VGA, which is not easy to access. I wish it ran over the serial port. It's also not clear how one would find an upgrade to the BIOS. dmidecode reports the BIOS as:

        Vendor: Phoenix Technologies, LTD
        Version: 6.00 PG
        Release Date: 02/24/2009

RAM

The mainboard has only two DIMM sockets. It came pre-populated with two 2GiB DDR DIMMs. memtest86+ reports those DIMMs clearly, but sees only 3070MiB in aggregate. The linux kernel also sees ~3GiB of RAM, despite dmidecode and lshw reporting that the two DIMM modules each are only 1GiB in size. I'm assuming this is a bios problem. Anyone know how to get access to the full 4GiB? Should i be reporting bugs on any of these packages?

SSDs

The internal SSDs are absurdly small and very slow for both reading and writing. This isn't a big deal because i'm basically only using them for the bootloader, kernel, and initramfs. But i'm surprised that they could even find 128MiB devices in these days of $10 1GiB flash units.

processor

/proc/cpuinfo reports two cores of a Intel(R) Core(TM)2 Duo CPU T5500 @ 1.66GHz, each with ~3333 bogomips, and apparently without hardware virtualization support. It's not clear to me whether the lack of virtualization support is something that could be fixed with a BIOS upgrade.

I used Andy Millar's nice description of how to get access to the BIOS -- I found i didn't need a hacksaw to modify the VGA cable i had. just pliers to remove the outer metal shield on the side of the connector i plugged into the open socket.

lshw sees four SiI 3132 Serial ATA Raid II Controller PCI devices, each of which appears to support two SATA ports. I'm currently using only four of the 8 SATA bays, so i've tried to distribute the disks so that each of them is attached to an independent PCI device (instead of having two disks on one PCI device, and another PCI device idle). I don't know if this makes a difference, though, in the RAID10 configuration i'm using.

There's also a neat 2-line character-based LCD display on the front panel which apparently can be driven by talking to a serial port, though i haven't tried. Apparently there are also LEDs that might be controllable directly from the kernel via ICH7 and GPIO, but i haven't tried that yet either.

Any suggestions on how to think about or proceed with a BIOS upgrade to get access to the full 4GiB of RAM, BIOS-over-serial, and/or enable hardware virtualization?

Tags: n8800pro, thecus

Syndicated 2011-04-05 20:07:00 from Weblogs for dkg

auto-built debirf images

jrollins and i recently did a bunch of cleanup work on debirf, with the result that debirf 0.30 can now build all the shipped example profiles without error (well, as long as debootstrap --variant=fakechroot is working properly -- apprently that's not the case for fakechroot 2.9 in squeeze right now, which is why i've uploaded a backport of 2.14).

To try to avoid getting into a broken state again, we set up an autobuilder to create the images from the three example profiles (minimal, rescue, and xkiosk) for amd64 systems. The logs for these builds are published (with changes) nightly at:

git://debirf.cmrg.net/debirf-autobuilder-logs

But even better, we are also publishing the auto-generated debirf images themselves. So, for example, if you've got an amd64-capable machine with a decent amount of RAM (512MiB is easily enough), you can download a rescue kernel and image into /boot/debirf/, add a stanza to your bootloader, and be able to reboot to it cleanly, without having to sort out the debirf image creation process yourself.

We're also providing ISOs so people who still use optical media don't have to format their own.

Please be sure to verify the checksums of the files you download. The checksums themselves are signed by the OpenPGP key for Debirf Autobuilder <debirf@cmrg.net>, which i've certified and published to the keyserver network.

What's next? It would be nice to have auto-built images for i386 and other architectures. And if someone has a good idea for a new example profile that we should also be auto-building, please submit a bug to the BTS so we can try to sort it out.

Tags: debirf

Syndicated 2011-03-29 08:00:00 from Weblogs for dkg

CryptLib and the OpenSSL License

I spent part of today looking at packaging Peter Gutmann's CryptLib for debian. My conclusion: it may not be worth my time.

One of the main reasons i wanted to package it for debian is because i would like to see more OpenPGP-compliant free software available to debian users and developers, particularly if the code is GPL-compatible.

Cryptlib makes it quite clear that it intends to be GPL-compatible:

cryptlib is distributed under a dual license that allows free, open-source use under a GPL-compatible license and closed-source use under a standard commercial license.

However, a significant portion of the cryptlib codebase (particularly within the bn/ and crypt/ directories) appears to derive directly from OpenSSL, and it retains Eric Young's copyright and licensing. This licensing retains the so-called "advertising clause" that is generally acknowledged to be deliberately incompatible with the GPL. (A common counterargument for this incompatibility is that OpenSSL should be considered a "System Library" for GPL'ed tools that link against it; whether or not you believe this for tools linked against OpenSSL, this counterargument clearly does not hold for a project that embeds and ships OpenSSL code directly, as CryptLib does)

This does not mean that CryptLib is not free software (it is!), nor does it mean that you cannot link it against GPL'ed code (you can!). However, you probably can't distribute the results of linking CryptLib against any GPL'ed code, because the GPL is incompatible with the OpenSSL license.

The un-distributability of derived GPL-covered works makes the CryptLib package much less appealing to me, since i want to be able to write distributable code that links against useful libraries, and many of the libaries i care about happen to be under the GPL.

I also note that Peter Gutmann and CryptLib Security Software (apparently some sort of company set up to distribute CryptLib) may be in violation of Eric Young's License, which states:

 * 3. All advertising materials mentioning features or use of this software
 *    must display the following acknowledgement:
 *    "This product includes cryptographic software written by
 *     Eric Young (eay@cryptsoft.com)"
 *    The word 'cryptographic' can be left out if the rouines from the library
 *    being used are not cryptographic related :-).

A Google search for Eric Young's name on cryptlib.com yields no hits. I do find his name on page 340 of the Cryptlib manual, but that hardly seems like it covers "All advertising materials mentioning features or use of this software". I suppose it's also possible that CryptLib has negotiated an alternate license with Eric Young that I simply don't know about.

In summary: i think CryptLib could go into debian, but its incorporation of OpenSSL-licensed code makes it less useful than i was hoping it would be.

I have a few other concerns about the package after looking it over in more detail. I suspect these are fixable one way or another, but i haven't sorted them out yet. I'm not sure i'll spend the time to do so based on the licensing issues i sorted out above.

But in case anyone feels inspired, the other concerns i see are:

embedded code copies

In addition to embedded (and slightly-modified) copies of bn/ and crypt/ from OpenSSL, CryptLib contains an embedded copy of zlib. Debian has good reasons for wanting to avoid embedded code copies. I've got it CryptLib building against the system copy of zlib, but the bits copied from OpenSSL seem to be more heavily patched, which might complicate relying on the system version.

executable stack

lintian reports shlib-with-executable-stack for the library after it is built. I don't fully understand what this means or how to fix it, but i suspect it derives from the following set of object files that also have an executable stack:

0 dkg@pip:~/src/cryptlib/cryptlib$ for foo in $(find . -iname '*.o'); do
>  if ! readelf -S "$foo" | grep -q .note.GNU-stack ; then
>   echo "$foo"
>  fi
> done
./shared-obj/desenc.o
./shared-obj/rc5enc.o
./shared-obj/md5asm.o
./shared-obj/castenc.o
./shared-obj/bfenc.o
./shared-obj/rmdasm.o
./shared-obj/sha1asm.o
./shared-obj/bn_asm.o
./shared-obj/rc4enc.o
0 dkg@pip:~/src/cryptlib/cryptlib$ 

They probably all need to be fixed, unless there's a good reason for them to be that way (in which case they need to be documented).

non-PIC code

lintian reports shlib-with-non-pic-code on the library after it is built. I don't fully understand what this means, or how to resolve it cleanly, but i imagine this is just a question of sorting out the details.

Anyone interested in using my packaging attempts as a jumping off point can start with:

git clone git://lair.fifthhorseman.net/~dkg/cryptlib

Oh, and please correct me about anything in this post; I'd be especially happy to hear that my analysis of the licensing issues above is wrong :)

Tags: cryptlib, gpl, licensing, openssl

Syndicated 2011-03-16 04:40:00 from Weblogs for dkg

PHP, MySQL, and SSL?

Is there a way to access a MySQL database over the network from PHP and be confident that

• the connection is actually using SSL, and
• the server's X.509 certificate was successfully verified?

As far as i can tell, when using the stock MySQL bindings, setting MYSQL_CLIENT_SSL is purely advisory (i.e. it won't fail if the server doesn't advertise SSL support). This means it won't defend against an active network attacker performing the equivalent of sslstrip.

Even if MYSQL_CLIENT_SSL was stronger than an advisory flag, i can't seem to come up with a way to tell PHP's basic MySQL bindings the equivalent of the --ssl-ca flag to the mysql client binary. Without being able to configure this, a "man-in-the-middle" should be able to intercept the connection by offering their own certificate on their endpoint, and otherwise relaying the traffic. A client that does not verify the server's identity would be none the wiser.

One option to avoid a MITM attack would be for the server to require client-side certs via the REQUIRE option for a GRANT statement, but the basic MySQL bindings for php don't seem to support that either.

PHP's mysqli bindings (MySQL Improved, i think) feature a command called ssl_set() which appears to allow client-side certificate support. But its documentation isn't clear on how it handles an invalid/expired/revoked server certificate (let alone a server that announces that it doesn't support SSL), and it also mentions:

This function does nothing unless OpenSSL support is enabled.

Given that debian MySQL packages don't use OpenSSL because of licensing incompatibilities with the GPL, i'm left wondering if packages built against yaSSL support this feature. And i'm more than a little bit leery that i have no way of telling whether my configuration request succeeded, or whether this function just happily did nothing because the interpreter got re-built with the wrong flags. Shouldn't the function fail explicitly if it cannot meet the user's request?

Meanwhile, the PDO bindings for MySQL apparently don't support SSL connections at all.

What's going on here? Does no one use MySQL over the network via PHP? Given the number of LAMP-driven data centers, this seems pretty unlikely. Do PHP+MySQL users just not care about privacy or integrity of their data?

Or (please let this be the case) have i just somehow missed the obvious documentation?

Tags: mysql, php, question, security, ssl, tls

Syndicated 2011-03-07 06:02:00 from Weblogs for dkg

Turning my back on the IEEE

I used to maintain a membership with IEEE. I no longer do.

The latest nonsense to come from them is a change for the worse in their copyright assignment policy, which i thought was already problematic.

Other engineering societies (IETF, USENIX, etc) continue to do socially relevant, useful work without attempting to control copyright of work contributed to them. This just makes IEEE look like a power- and money-hungry organization, rather than a force for positive advancement of technology.

For shame, IEEE.

I will not consider reinstating my membership unless the organization changes their copyright assignment and publication policy to better reflect the spirit of scientific inquiry and technological advancement they should stand for.

Tags: freedom, ieee, policy

Syndicated 2011-03-01 18:32:00 from Weblogs for dkg

resetting passphrases for mapped LUKS volumes

Let's say you set up a machine using an encrypted disk with LUKS (debian-installer's partman makes this wonderfully easy!). You choose an initial passphrase, get the machine working, and it's working great. Then, you need to restart it, and realize that (for whatever reason) you've forgotten or lost the passphrase for the volume. oops! (i'm sure this has never happened to you -- let's just pretend it's your less-fortunate friend).

If your system is still running, and you have superuser access to it, you can actually set a new passphrase for the LUKS volume using information that the dm-crypt kernel module has about the in-use mapping. In my examples, i'll imagine that the source volume is /dev/XXX2 and the exported cleartext volume is known by the device-mapper as XXX2_crypt

In the bigger picture, this should serve as a reminder that even though your disk is encrypted, if someone gets live access to the superuser account on a system with the encryption keys loaded, your data is no longer secret.

Before you do any tweaking, you might want to back up your LUKS header, just in case:

0 root@example:~# umask 077
0 root@example:~# cryptsetup luksHeaderBackup /dev/XXX2 --header-backup-file XXX2.luksheader.backup
0 root@example:~# 

Maybe also copy that off the machine, since a copy of the LUKS header stored within its own volume isn't terribly useful for a backup-recovery situation.

You might also be interested in looking at the contents of the LUKS header:

0 root@example:~# cryptsetup luksDump /dev/XXX2
LUKS header information for /dev/XXX2

Version:       	1
Cipher name:   	aes
Cipher mode:   	cbc-essiv:sha256
Hash spec:     	sha1
Payload offset:	2056
MK bits:       	256
MK digest:      93 51 6c 66 ec ce 32 54 6f 6b 52 d1 27 9b 5a 62 6f 6b 52 d1
MK salt:       	b2 ca 20 49 9f 78 49 c2 fe 15 b4 0f 74 11 23 49
               	64 9e 61 bb f2 82 60 47 a5 76 fa a4 24 0e 5a 7e
MK iterations: 	10
UUID:          	052f1da0-21a1-11e0-ac64-0800200c9a66

Key Slot 0: ENABLED
	Iterations:         	218733
	Salt:               	f2 ae 8c 53 48 a5 f0 bf e1 2c 06 5f 5a bd ff d9
	                      	9a 2e d1 49 3a 63 f8 49 82 ed ae 86 7b 7b 7e 76 
	Key material offset:	8
	AF stripes:            	4000
Key Slot 1: DISABLED
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED
0 root@example:~# 

Now, the fix: We pull the live "master key" from the running device map, and fill a new luksKeySlot from it (this example uses bash's <() syntax for process substitution -- if you use a different shell, i'm sure you can find a different way to do it):

0 root@example:~# cryptsetup --master-key-file <( 
> dmsetup --showkeys table | awk '/^XXX2_crypt: /{ print $6 }' | tr -d '\n' | perl -e 'print pack("H*", <STDIN>);' 
> ) luksAddKey /dev/XXX2
Enter new passphrase for key slot: abc123
Verify passphrase: abc123
2 root@example:~# 

(note that the luksAddKey invocation above returned an error code of 2 even though it succeeded. I think this is a bug in cryptsetup's return code, not a bug in the password resetting -- it should have returned 0 instead of 2).

You can check to see that a new key slot was enabled by re-running cryptsetup luksKeyDump

And if you really want to double-check before you reboot, you can try enabling a third keyslot using the passphrase you just added, since this would not succeed if your new passphrase failed to unlock any of the existing keyslots:

0 root@example:~# cryptsetup luksAddKey /dev/XXX2
Enter any passphrase: abc123
Enter new passphrase for key slot: anotherpassphrase
Verify passphrase: anotherpassphrase
0 root@example:~# 

You can also get rid of the original keyslot (which you don't know the passphrase to) like this:

0 root@example:~# cryptsetup luksKillSlot /dev/XXX2 0
Enter any remaining LUKS passphrase: abc123
0 root@example:~# 

(the above commands were all demonstrated using debian testing, with cryptsetup 2:1.1.3-4 and dmsetup 2:1.02.48-4)

Tags: cryptsetup, dmsetup, luks, tip

Syndicated 2011-01-16 19:57:00 from Weblogs for dkg

Liberating Knowledge: A Librarian's Manifesto

A friend just pointed me to Liberating Knowledge: A Librarian's Manifesto for Change by Barbara Fister, an academic librarian who also happens to write mystery novels.

She has an excellent perspective on the meaning of libraries, and the tradeoffs involved with the current societal trend toward privatizing knowledge through so-called "intellectual property" regulations. In a great critique of the passivity of academia and libraries in the face of attempts at intellectual enclosure by private corporations, she writes:

This uninformed indifference is laying the groundwork for a new tragedy of the commons: a world in which knowledge is turned into intellectual property, monetizied, and made artificially scarce.

She closes with a six-point manifesto that begins:

Liberation bibliography arises out of outrage at the injustice of the current system. It’s not about saving money, it’s about the empowering nature of knowledge and the belief that it shouldn’t be a luxury good for the few.

The article abounds in examples of heinous arrangements in the current system that seem to be accepted as standard procedure, and clear thinking about what the actual tradeoffs are (and how we, as a society, are making them poorly).

If i had one objection, it would be that she neglects to mention increased surveillance as one of the problems that come with privatization of knowledge. Our abilities to read privately and anonymously, and to correspond confidentially are at risk because of these systems of control.

Anyway, I'd love to see more open allegiances between librarians and free software folks; the ideals and struggles are very much in parallel. Go talk to your librarian friends about this stuff today! (and if you don't have any librarian friends, go to your local library and meet them. They're great people, doing important work.)

Tags: academia, freedom, intellectual property, libraries

Syndicated 2011-01-06 05:52:00 from Weblogs for dkg

converting eviews models to gretl?

Someone recently pointed me to some economic/statistical models that were designed for eviews (a proprietary tool).

They were looking for help converting the model into a format that could work with gretl (the Gnu Regression, Econometrics and Time-series Library). I'm afraid i'm an economics dunce, and i have no experience with this stuff. Any pointers?

Tags: conversion, economics, gretl

Syndicated 2010-12-13 00:17:00 from Weblogs for dkg

forwarding unix domain sockets with ssh and socat

i suspect a lot of people are used to forwarding TCP sockets with SSH -- for example, to connect locally to a mysql daemon that runs only on the loopback interface of a remote machine (this is debian's default mysql-server configuration):

ssh -N -T -oExitOnForwardFailure=yes -L 3306:localhost:3306 remoteuser@mysqlserver.example

But sometimes, the remote service runs on a UNIX-domain socket, not on a TCP socket -- for example, debian's default configuration for postgresql is to have it listen only on a UNIX domain socket in /var/run/postgresql, and use SO_PEERCRED with a simple system account == psql account mapping scheme to authenticate users without needing any extra credentials. This is not quite as simple to forward over ssh, but it's doable as long as socat is installed on both your local host and on the remote postgres server.

Here's one way to do it if $SOCKET_DIR points to the full path of a directory under the user's control (this is all one command, split across lines for easier reading):

socat "UNIX-LISTEN:$SOCKET_DIR/.s.PGSQL.5432,reuseaddr,fork" \
   EXEC:'ssh remoteuser@psqlserver.example socat STDIO UNIX-CONNECT\:/var/run/postgresql/.s.PGSQL.5432'

Then, you'd connect with something like:

psql "user=remoteuser host=$SOCKET_DIR"

Each such psql connection will trigger an ssh connection to be made. Of course, this won't work well if ssh has to prompt for passwords, but you should be using ssh-agent anyway, right?

There are at least a couple nice features of being able to use postgresql from a local client like this:

• your psql client can load files from your local machine, and can dump/export files to the local machine.
• your ~/.psql_history stays local, so you can review what you did even when you're offline
• you can run local RDBMS administrative GUIs like pgadmin3 with minimal network traffic and no extra packages installed on the server.
• unlike forwarding TCP ports (where any other user account on the machine can hop onto your connection), you can control access to your local UNIX-domain socket with standard filesystem permissions on $SOCKET_DIR.

Of course, postgresql itself already comes with a nice range of high-quality network-capable authentication mechanisms you could use. But many of them (like GSSAPI or X.509 mutual key-based authentication over TLS) require additional infrastructure setup; and you probably already have sshd up and running on that machine -- so why not make use of it?

Tags: postgresql, socat, ssh, tip, unix-domain socket

Syndicated 2010-12-02 09:41:00 from Weblogs for dkg