Odi's astoundingly incomplete notes
New entriesCode
back | nextJ2ME ebuild for Gentoo
The good and the cheap
Joel has a commercial understanding of what I have been saying for years. Read Hitting the High Notes in his blog.
mad
Gentoo on Acer TM 4650
I installed Gentoo on my brand new work laptop last week. It was a little tricky that one because the Gentoo Live CD does not work well out of the box. For some stupid bug the system will not be able to access the CD-ROM from the LiveCD. Be sure you still have a Windows partition. Download and save the CD image there. Also burn a CD from it. Then boot the LiveCD. First the framebuffer driver turns your screen pitch black. So use the gentoo-nofb boot option. Then the APIC makes the kernel hang at boot. So turn APIC off with the noapic option.
Now the CD boots and finally fails to mount the CD-ROM. Go into shell mode and create the device files for the hard drive manually. The first Windows partition is /dev/hdc2 which has a device number of 22 2. Now mount the windows partition. Create device nodes for some loop back devices. Now mount the CD-Image via the loop device. Copy the compressed image off the mounted CD. Mount the compressed image via a second loop back device. Finally chroot into that file system. Now use fdisk to create your partitions. Be sure not to touch the first Windows partition as you are currently using it. Format your new partition. Copy your complete environment onto the new Linux partition. Exit and unmount everything. Then reboot into the LiveCD.
Go into shell mode again. Create the device file for your Linux partition. Exit. Enter the name of the device file. Now init will boot from your new Linux partition - which is now writable. From here create a new directory somewhere, unpack the stage1 tarball there and chroot into it. Continue the installation as usual. Exit when the environment is ready for booting and move everything out of the subdirectory to the top level. Reboot.
This is all a bit annoying but it works finally. I still have to figure out why the IDE drive does not want to go into DMA mode. This slows down the computer terribly: unable to work while updatedb is running or unpacking a kernel tarball. Wifi works great with the fwb2200 drivers and firmware.
Subclipse under Gentoo
Subclipse is still a masked package in Portage. I installed it via the Eclipse update site to a user-local extension point. There is a small catch however:
emerge subversion- set
LD_LIBRARY_PATH=/usr/libwhen you start Eclipse
Vulnerabilities, Patents and Vendors
According to an article on Kernel Trap it is very alarming how some system vendors react when you tell them their product has a security flaw. Focus on the section "The politics of vulnerabilities". Some vendors, instead of fixing the problem, try to: boldly patent your work, shut you up, hire you (so they can easier patent your work and make you shut up), accuse you for terrorism.
[qmail] TLS found no client cert in control/clientcert.pem
I encountered the above error message in the qmail logs while our remote message queue was slowly growing. We had just installed a Thawte server certificate for our mail gateway. We had put the RSA key plus the certificate into /var/qmail/control/servercert.pem and made a symlink clientcert.pem to that file.
After searching the web for a possible solution to the problem I found nothing helpful. So I dug up the C code that seemed to cause the problem: In qmail-remote.c there is a line:
if ((stat("control/clientcert.pem", &st) == 0) &&
((SSL_CTX_use_RSAPrivateKey_file(ctx, "control/clientcert.pem", SSL_FIL
ETYPE_PEM) <= 0) ||
(SSL_CTX_use_certificate_chain_file(ctx, "control/clientcert.pem") <= 0
) ||
(SSL_CTX_check_private_key(ctx) <= 0)))
/* if there is a cert and it is bad, I fail
if there is no cert, I leave it to the other side to complain */
SSL_CTX_set_client_cert_cb(ctx, client_cert_cb);
This line seems to perform various checks on the client certificate and if one of those fails, sets a callback (client_cert_cb) that issues the error message.
What caught my attention was the call to SSL_CTX_use_certificate_chain_file - mostly intuition. On Google I found documentation for this function at IBM. It says: The first certificate in the file must be the certificate for your application. The next certificate in the file must be the certificate for the certificate authority (CA) that signed the certificate for your application. Subsequent certificates, if any exist, are for the CAs in the signing sequence. Duh!
Apparently all the qmail docs on the web are not very useful. They all use self-signed certs and suggest just to put your private key plus the certificate into the servercert file and use a symlink to it as the clientcert. While that is true, the setup is a little bit more complicated when using a real certificate. It seems we must make a servercert.pem that contains all of
- The private key
- The certificate
- All the certificates including the root certificate of all the signers.
This is actually documented in the qmail TLS patch: Note: you can add the CA certificate and intermediate certs to the end of servercert.pem. But some patch walkthroughs don't do it correctly.
What the docs don't say
The API Docs for javax.servlet.ServletRequest don't mention that any Object stored into the request is cloned! That means when you get an attribute from a request and modify it, you still have to set it again in the request to publish the changes!
Non well-defined time zone in iCal and Outlook
As noted earlier the time zone must always be specified in DTSTART for recurring iCal events. If instead UTC format is used in DTSTART the days of the week in the RRULE is undefined and may lead to unexpected results. I crafted such a not well-defined iCal:
BEGIN:VCALENDAR PRODID:-//www.odi.ch//Test//EN VERSION:2.0 METHOD:REQUEST BEGIN:VEVENT ORGANIZER;ROLE=NON-PARTICIPANT:MAILTO:iwontread@despammed.org ATTENDEE;ROLE=REQ-PARTICIPANT;RSVP=FALSE;TYPE=INDIVIDUAL:MAILTO:iwontread@despammed.org DTSTART:20050308T233000Z DTEND:20050309T003000Z RRULE:FREQ=WEEKLY;UNTIL=20050329T003000Z;INTERVAL=1;BYDAY=TU;WKST=MO TRANSP:TRANSPARENT SEQUENCE:1 UID:1 DTSTAMP:20050305T130637Z SUMMARY:A not well-defined entry PRIORITY:5 CLASS:PUBLIC END:VEVENT END:VCALENDAR
When imported into Outlook 2000 in Zurich (GMT+1:00) the event shows up every Tuesday. The same event with a well-defined timezone looks like:
BEGIN:VCALENDAR PRODID:-//www.odi.ch//Test//EN VERSION:2.0 METHOD:REQUEST BEGIN:VTIMEZONE TZID:GMT BEGIN:STANDARD END:STANDARD DTSTART:19000101T000000 TZOFFSETFROM:0000 TZOFFSETTO:0000 END:VTIMEZONE BEGIN:VEVENT ORGANIZER;ROLE=NON-PARTICIPANT:MAILTO:iwontread@despammed.org ATTENDEE;ROLE=REQ-PARTICIPANT;RSVP=FALSE;TYPE=INDIVIDUAL:MAILTO:iwontread@despammed.org DTSTART;TZID=GMT:20050308T233000 DTEND;TZID=GMT:20050309T003000 RRULE:FREQ=WEEKLY;UNTIL=20050329T003000Z;INTERVAL=1;BYDAY=TU;WKST=MO TRANSP:TRANSPARENT SEQUENCE:1 UID:2 DTSTAMP:20050305T130637Z SUMMARY:A well-defined entry PRIORITY:5 CLASS:PUBLIC END:VEVENT END:VCALENDAR
This event correctly appears on every Wednesday when imported into Outlook in Zurich.
iCal recurrence and time zones
iCal (RFC-2445) lets you define recurrent events by setting a recurrence rule property (RECUR, section 4.3.10). RECUR takes a BYDAY parameter to define the days of the week the event will reoccur. Sample:
RRULE:FREQ=WEEKLY;BYDAY=MO,TU,WE,TH,FRWhenever we speak about a day of the week we must however define the time zone we are referring to: Monday in Sidney Australia does not start at the same time as Monday in Zurich Switzerland. RRULE does not allow a time zone parameter however. Luckily RFC-2445 also says that Information, not contained in the rule, necessary to determine the various recurrence instance start time and dates are derived from the Start Time (DTSTART) entry attribute.
That leads to the following conclusion: Days of the week referred to in a RRULE are respective to the time zone defined by DTSTART.
DTSTART is defined in section 4.8.2.4 and takes a time zone ID as an optional parameter. When a time zone is not specified the time must be specified in UTC format. It might be reasonable to assume the time zone used to interprete the days of the week implicitly as GMT then, but actually it is not well defined. To be certain one must always specify a time zone in DTSTART for recurring events.
So iCal is actually very precise here! When generating iCal records from Java this poses a little problem, however. Java has all the time zones information built into the stock class library: java.util.TimeZone. Unfortunately it is impossible to query this class for all the information needed to write out a time zone component in iCal (section 4.6.5). Also it is not possible to convert the times to one single time zone (like GMT) as their dailight savings time effective date may be different.
All this leads us to the final sad conclusion: Time zone information must be obtained from somewhere outside the JDK when dealing with recurrent iCal entries and if you need correct time zone handling.
-George Sexton-
http://www.mhsoftware.com/
Running clamd under daemontools
ClamAV's clamd can be run under the daemontools.
Unfortunately most users patch clamd to support logging to stderr. This way you can use multilog to capture the log output. However patching clamd seems awkward and can not be done if you use a binary distribution.
You can instead use a pipe to transport the log from clamd to stderr. Create a log pipe:
cd /var/log/clamd/ mkpipe logpipe chown clamav:clamav logpipe chmod 640 logpipe
Configure clamd to log to the pipe by editing /etc/clamd.conf:
LogFile /var/log/clamd/logpipe LogFileUnlock LogTime #LogFileMaxSize #LogSyslog
The daemontools run script for clamd must be changed like this:
#!/bin/sh exec /usr/sbin/clamd -c /etc/clamd.conf 2>&1 & sleep 2 cat /var/log/clamd/logpipe