Tidy of Mercurial Repositories
The Faelix Mercurial Repositories have been tidied up in advance of the Faelix New Year’s Resolution. More on this to follow in due course.
The Faelix Mercurial Repositories have been tidied up in advance of the Faelix New Year’s Resolution. More on this to follow in due course.
So as to make updating the Faelix NOC/OSS/Blog easier, it has been moved off-site to tumblr.com.
For several years Faelix has built and maintained a library of tools, utilities and scripts in Python. Today these have been ported to support Mac OS X 10.5 (Leopard). You can either download the zipped mpkg Universal binary, ready for installation (requires Python 2.5 included with Leopard) or get the source from the Mercurial repository.
The Faelix Python library is also available for:
Debian versions can also be installed by adding deb.faelix.net to your apt packages list.
Having used the PKCS#15 signer in i386 platforms with success, we had problems on amd64 Linux. A small patch should fix the problem.
We tested the PKCS#15 signer (written for .se NIC’s DNSSEC deployment) on AMD64 (Debian sarge) and found it would segfault in the strftime() calls in write_RRSIG() in dns-util.c:
Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "x86_64-linux"...Using host libthread_db library "/lib/libthread_db.so.1". (gdb) run Starting program: /home/maz/dns/pkcs15-dnssec-0.1/pkcs15-dnssec -s -n faelix.net. -i input.txt -o output.txt -c 20070401000000 -x 20070430235959 [Thread debugging using libthread_db enabled] [New Thread 46954030179488 (LWP 27574)] Enter PIN [XXXX@YYYY]: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 46954030179488 (LWP 27574)] 0x00002ab455dcafd7 in strftime () from /lib/libc.so.6
The gmtime() calls on lines 189 and 192 return nil, and that appears to be caused by the sizes of various ints:
sizeof( time_t ) == 8 (returned by string2time(), from mktime()) sizeof( u_int32_t ) == 4 (used in struct dns_type_rrsig)
A tiny patch appears to resolve this:
--- a/dns-util.c Thu Apr 05 14:28:20 2007 +0100
+++ b/dns-util.c Thu Apr 05 14:28:31 2007 +0100
@@ -182,14 +182,17 @@ write_RRSIG(FILE *f, const dns_type_rrsi
int c, b64len;
char b64buf[MAX_LINE];
char expiration[MAX_TIMESTAMP], inception[MAX_TIMESTAMP];
+ time_t t;
const char *tformat = "%Y%m%d%H%M%S";
+ t = rrsig->expiration;
strftime(expiration, sizeof(expiration), tformat,
- gmtime((time_t *) &rrsig->expiration));
-
+ gmtime((time_t *) &t));
+
+ t = rrsig->inception;
strftime(inception, sizeof(inception), tformat,
- gmtime((time_t *) &rrsig->inception));
+ gmtime((time_t *) &t));
b64len = b64_ntop (rrsig->sigdata, rrsig->siglen, b64buf, MAX_LINE);
b64buf[b64len] = (char) 0;
Please note: this has not been fully tested on either 32-bit or 64-bit platforms! It might generate invalid RRSET records/signatures/etc, but given the simplicity of the patch we think it’s probably ok to publish before our in-house testing is complete.
On very long-running FUSE sessions Faelix has noticed gradual memory leakage, and today we’ve finally tracked it down to FuseGetContext().
The first difficulty was to upgrade to the latest FusePython to see if the problem had been reported and fixed in a newer version. Unfortunately it had not, and so began the painstaking process of tracking down the bug.
We tracked the problem down to a layer underneath our filesystem, either FusePython, FUSE orPython itself. We began with xmp.py, which didn’t exhibit the memory leak, and began comparing the calls it made with our filesystem. Quickly this began to suggest FuseGetContext() (which our filesystem uses, but xmp.py does not) and a one-line patch to readdir() made it easy to replicate the memory leak:
946 maz 18 0 42032 3308 884 S 0.0 0.3 0:00.05 python ...30 seconds later... 946 maz 18 0 43344 4588 884 S 3.7 0.4 0:00.73 python ...and another 30 seconds... 946 maz 18 0 45712 6968 884 S 2.0 0.7 0:01.94 python
It appears that there are three Py_XDECREF() calls missing from FuseGetContext(), and our fixed version is now available from http://hg.faelix.net/contrib/fuse-python (patch) or add the three lines below by hand to FuseGetContext():
num = PyInt_FromLong(fc->uid);
PyDict_SetItemString(ret, "uid", num);
+ Py_XDECREF( num );
num = PyInt_FromLong(fc->gid);
PyDict_SetItemString(ret, "gid", num);
+ Py_XDECREF( num );
num = PyInt_FromLong(fc->pid);
PyDict_SetItemString(ret, "pid", num);
+ Py_XDECREF( num );
