rlucas.net: The Next Generation Rotating Header Image


[FIX] Apache/OpenSSL won't talk to some browsers, with SSL3_GET_CLIENT_HELLO:no shared cipher

If you are finding that some browsers are talking to your new Apache/OpenSSL install,
while some are pulling a total blank (looks like a connection refused
or server not found), and you are getting this error:

OpenSSL: error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher [Hint: Too restrictive SSLCipherSuite or using DSA server certificate?]

then heed the warning.  You are likely using the DSA server
certificate that comes with some fresh installs.  Check your cert

ls -l /etc/httpd/conf/ssl.crt
ls -l /etc/httpd/conf/ssl.key

Do you see that your server.crt (or whatever your httpd.conf defines as
your cert) and your server.key (or whatever is your key) are symbolic
links to the default “snakeoil” certs?

server.crt -> snakeoil-dsa.crt
server.key -> snakeoil-dsa.key

Ok, then you might have better luck in using the RSA versions, which play nice with more browsers:

mv server.crt server.crt.orig
ln -s snakeoil-rsa.crt server.crt

mv server.key server.key.orig

ln -s snakeoil-rsa.key server.key

apachectl stop && apachectl start

(Remembering that with Apache, when playing with SSL stuff, do a full stop and start upon making changes — a HUP won't cut it)

As per all recommendations, do away with the snakeoil stuff ASAP and certainly before putting anything up on a public network.

CAVEAT: Do not use this advice for production.  This advice should
only be used for your own dev or testing, in order to get a fresh
install at least nominally working.  If you want real SSL and
can't figure it out, pay someone, because your security is worth it.

FIX: Apache 1.3.2x compiling with mod_ssl on Red Hat 9 / shrike bombs out with krb5.h error

If you try to compile Apache (1.3.28) with mod_ssl, following the plain vanilla directions in the relevant sources, under Red Hat 9 (and using RH9's installation of openssl), you are likely to get an ugly error like this:

gcc -c -I../../os/unix -I../../include -DLINUX=22 -I/usr/include/gdbm -DMOD_SSL=208115 -DUSE_HSREGEX -DEAPI -fpic -DSHARED_CORE `../../apaci` -DSHARED_MODULE -DSSL_COMPAT -DSSL_USE_SDBM -DSSL_ENGINE -DMOD_SSL_VERSION="2.8.15" mod_ssl.c && mv mod_ssl.o mod_ssl.lo

from mod_ssl.h:116,

from mod_ssl.c:65:

/usr/include/openssl/kssl.h:72:18: krb5.h: No such file or directory

In file included from /usr/include/openssl/ssl.h:179,

from mod_ssl.h:116,

from mod_ssl.c:65:

/usr/include/openssl/kssl.h:132: parse error before "krb5_enctype"

/usr/include/openssl/kssl.h:134: parse error before "FAR"

/usr/include/openssl/kssl.h:135: parse error before '}' token

/usr/include/openssl/kssl.h:147: parse error before "kssl_ctx_setstring"

/usr/include/openssl/kssl.h:147: parse error before '*' token


Apparently, this is due to a problem with the compiler adequately finding the kerberos part of the installed openssl package.  To fix it, you can 1. make clean your apache src dir, 2. place the following lines into your configure script in the apache-1.3.xx directory, around line 96 (exact location not critical):


if pkg-config openssl; then

     CFLAGS="$CFLAGS `pkg-config --cflags openssl`" 

     LDFLAGS="$LDFLAGS `pkg-config --libs-only-L openssl`"



Many thanks to Matthias Saou for this solution, found at:


[HOWTO] Getting your profit-sharing plans rolled out of Fidelity's non-prototype retirement accounts as qualified distributions to separate IRAs or 401ks.

If you are a small business with a Profit Sharing Plan / defined
benefit plan set up through an independent benefit advisor firm,
someone may have counseled you to set up your investments at
Fidelity.  They will create a “Non-prototype retirement account”
in the name of your Profit Sharing Plan trust.  You can make
trades and do what you will (although as of late they refuse to let you
buy funds that have even potentially a short term sales charge, which
really drastically limits you) and it's all for the big pool of
money.  As a “non-prototype” plan, Fidelity washes their hands of
the actual record-keeping of who is owed what and how much is vested to
whom, etc.  That's why you're paying your independent benefits
advisor all those fees each year, right?

When you discover that the costs invoved are so high as to cut
seriously into your returns, you'll want to dissolve your profit
sharing plan and distribute the assets among the beneficiaries so each
can put his funds into a low cost IRA.  Your advisor will have you
prepare corporate resolutions to that effect and tell you to distribute
the funds payable to the IRAs or 401ks of the beneficiaries, so that
they are qualified rollovers and so nobody has to withhold taxes for
the IRS.

Try telling that to Fidelity.  If your experience is like mine,
they'll have no idea, then check on things for you.  They'll come
back and say that they can make a check payable to the Trustees, to the
Plan, or they can do a qualified rollover to Fidelity.  They will
swear up and down that they can't send the money to a “contra FI”
(another bank).  They'll transfer you to “Retail Distribution,”
who will tell you that they can only pay out to the order of the
trustees, and that maybe you could have your trustees all sign the
check and then cash it at a bank, but that oh, yes, maybe, I suppose
you could get checkwriting privileges on the Fidelity account
itself.  If you are unlucky, you might try to do this.

However, if things get more and more fubared on your phone call, you
might get transferred to “Retirements Department” where someone puts
you on hold two more times to research and then discovers that yes,
those things mentioned above (only payable to the trustees or via a
Fidelity rollover) are trueish but there is one magical thing to do
otherwise, that will without any fee, cause the funds to be sent to the
new banks and the new IRAs, and that is this.

Prepare a letter containing these magical 5 elements:

1. Direction to Fidelity to make a check payable to “Contra FI FBO
Employee Name Account” (e.g., “Vanguard Funds FBO John Smith Rollover
IRA”), in an exact dollar amount, and with the address to which to send
that check.

2. Certification by the trustees that the distribution is an “eligible rollover distribution.”

3. Statement that the trustees assume all responsibility for
record-keeping for the plan assets and for reporting the distribution
to the IRS for tax purposes.

4. Statement that the trustees indemnify and hold Fidelity harmless for
any liability with respect to processing the direct rollover.

5. Original signature with a bank's signature guarantee from EACH of
the trustees (each must take the letter to the bank and sign in their

Send this mystical incantation, the specs of which are not available to phone reps or on the web site, to:

Fidelity Investments
Attn: Distribution Services
PO BOX 770001
Cincy OH 45277-0035

To their (sort of) credit, they had previously hinted to another
trustee that they needed a “distribution letter,” but did not mention
the 5 requirements, and when I called back to ask about it, had to put
me on hold 6 times and transfer me twice to get me the magical list of
things to do.  My cell phone is now almost out of batteries after
nearly 40 minutes on the line with them.  They were certainly
polite about the whole thing but it does seem a bit disingenuous of
them to keep insisting that we roll into Fidelity IRAs and “forgetting”
about this handy exception.

Of course, if you do this, you had better be damn sure that your p's
are crossed and your q's are dotted with respect to telling Uncle Sam
about the whole thing since Fidelity has now washed its hands of you.

Enjoy your new, rolled-over, low-overhead IRAs and 401ks!

Concentrating in History and Science at Harvard

Having had a not entirely satisfactory experience in the History and Science department at Harvard, I have been making notes ever since on how things might have been improved, and on things I wish I'd known before starting out.

Prospective concentrators in the department of History of Science at Harvard may want to check my notes, linked below:


These notes are not intended to be universally applicable — caveat lector — but would help someone like me who was considering, or struggling with, a concentration in History and Science.

FIX; DBD::Pg _is_utf8_string bug with Perl 5.6.0 on Mac OS X 10.2.2

After having fixed the DBD::Pg bug resulting from the faulty Apple Security Update, which necessitated recompiling Postgres and running sudo ranlib /usr/local/pgsql/lib/libpq.a I discovered another bug.

My PostgreSQL was compiled with UTF-8 support, and my DBD::Pg was rebuilt/reinstalled after the Postgres recompile. However, my scripts were still bombing out with:

dyld: perl Undefined symbols:
Trace/BPT trap

This posting speculates at the solution, which happily works:

Specifically, commenting out the code between the ifdefs in the section that refers to is_utf8_string (circa line 1482 of dbdimp.c), then make clean / make / make install allowed DBD::Pg 1.21 to install OK and stopped perl from crashing out with the above error.

Now, to see if that completely breaks something else…

[WARN] MD5 sums irredeemably broken

The MD5 hash function is dangerously unusable at this point.  I
was under the impression, casually following crypto over the last
couple years, that it was weak but likely “good enough” for
non-military, non-banking types of applications.  Dead wrong.

There are now known attacks — and doubtless toolchains for specific
exploits — that permit creating two completely different (but valid)
pieces of plaintext that generate the same MD5 sum.

See http://www.doxpara.com for an example of two mocked-up HTML pages,
one for “Lockheed” and one for “Boeing,” that share the same MD5 hash

See also Wikipedia's MD5 entry (which does not NEARLY sufficiently raise the alarum on this) at http://en.wikipedia.org/wiki/Md5

You might pooh-pooh my admittedly somewhat superficial take on this,
but ignore me at your peril: bad guys are doubtless developing toolkits
for creating two docs, one legit, one malicious, that share the same
MD5 sum.

Bottom line: time to use SHA1 (for a while until someone figures out
how to do the same thing).  Simple enough on debian; “sha1sum” is
in coreutils and is a seeming drop-in replacement for MD5 sums.

[SANITY CHECK] Apache 2 hangs with lots of STDERR output from CGI

You are not crazy. It is not an infinite recursion in your logic. Your code doesn't take that long to execute.

you output to STDERR (in Perl, this means Carp or warn or the venerable
print STDERR among others) from a CGI script under Apache 2.0, and you
end up dumping more than approximately 4k (note that if you are using
“warn” or “Carp” you may have extra stuff on there so that you only
output 3k or so but the extras bring it up to 4k), Apache 2 will hang
forever (as of today, 30 March 2004).

See this bug report: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22030

There are some patches proposed in the link above on the Apache project bugzilla, but they are not production releases.

case you were wondering,
http://blogs.law.harvard.edu/rlucas/2003/08/26#a13 shows some helpful
hints on how you can back down to version 1.3.

Question to all:
what are folks' recommendations for an Apache 1.3 packaged install? I
would tend to prefer statically linked with SSL and mod_perl, but the
only one I've seen folks using is from n0i.net which isn't entirely
satisfying because I don't speak Romanian.

Update: Using Apachetoolbox
(see Google), you can fairly simply compile apache 1.3 + mod_ssl + mod_perl
+ php and whatever 3rd party modules you like.  This makes for a fine alternative to RPM
versioning hell, or even to traipsing around your src tree typing make.  Be sure that if you do this, you specify
mod_perl 1.29 rather than 1.99, if you compile mod_perl in.

Solving a Real Problem

OK, I have determined what blogs are for. They give an easy way to publish aggregated technical fix information in a search-engine-friendly format. Aggregated: quite often, fixing a specific technical problem (even a common one!) requires looking around the web at a number of false leads on mailing list archives, tech docs, knowledge bases, etc. Putting the whole solution, once found, into a single blog entry (including links / attribution to the original solvers) makes sense. Seach-engine-friendly: mailing list archives are good, but only if they get web-published and Googled. Realistically, if it's not in Google, it doesn't exist — especially in the realm of technical problems that could have any number of origins (imagine compiling an XML to Excel Perl module on Mac OS X: is your problem with GCC, libxml, Excel, Perl, or Mac OS X? Which mailing lists do you search first?). Additionally, most computer problems have a characteristic error message which appears with some limited amount of variation. That message is easy to post on a blog. I originally believed that the solution to the aggregated technical fix information was a search-engine feeder backed by an RDBMS, but it is clear that any schema will be too inflexible for the variety of problems. Better to post error messages verbatim, try to be as explicit about keywords as practicable (if it segfaults, include the words “crash', “segmentation fault”, and “segfault” as an aid to searching), and let Google handle the hard stuff far better than a FTS through an RDBMS could hope. Why do this? Well, this is a case of the comedy of the commons: figuring out a solution like this on one's own or by searching through mailing lists piecemeal could consume hours or days of productive time. However, posting a solution once found is trivial, taking mere minutes. If even one other person posts a solution that I find which saves me 3-4 hours, it's worth all the time I'll ever spend in posting such things.

Unwire Portland (OR) Project: Public benefit through the "drinking fountain" model

Portland, Oregon is working toward a citywide, privately-operated
wireless network, under a public-private partnership model that
leverages city rights-of-way, among other assets, in return for certain
“public benefits.”  I strongly support this effort (the “Unwire
Portland” project).

The issue at hand is that the currently-proposed public benefit
structure is to create a “walled garden” of hand-picked sites that will
be freely available to the public.  A few moments' reflection
should alarm the reader: who will pick these sites, using what criteria
and what process for review, etc.?  Who will get sued when someone
inevitably disagrees with the choices?

My answer to these concerns is to do away with the “walled garden” and
in its place put a “drinking fountain” model, where each passerby may
take a small “trickle” of an unrestricted Internet connection for free.

I have put together a document supporting the adoption of the drinking fountain model here: http://rlucas.tercent.com/wifi.html

Your comments and suggestions are welcome.

[FIX] XFree86 stuck at 640 x 480 under Linux with Dell Dimension or Optiplex

With a fresh install of Red Hat 9 on a Dell Dimension 4600, the only video mode that would work with XFree86 was 640 x 480, which is ludicrously big on a decent-sized monitor.  Changing the config didn't do anything, even though the config was well within my monitor's limits.

The solution was to go into the BIOS setup and change the Integrated Devices (LegacySelect Options) / Onboard Video Buffer setting from 1 MB to 8 MB.  I'm not sure what the tradeoff with other aspects of the system is, but X nicely starts up at 1280 x 1024.  Apparently, this is the solution for other Dell models as well, including the Optiplex GX260; mine had Dell BIOS Revision A08.  Also, it seems to be the case that the problem is general to XFree86, although it manifested for me under Red Hat 9.

Thanks to Erick Tonnel at Dell, who kindly provided the solution here: