rlucas.net: The Next Generation Rotating Header Image

ancient

[BUG] ActiveRecord woes with SQL Server odd names (spaces and brackets), ntext data types

ActiveRecord (latest versions of ODBC, DBI, and AR as of today
2005-12-01) seems to be having trouble with at least two things that
SQL Server 7 does:

1. The SQL Server adaptor (sqlserver_adaptor.rb) get_table_name sub
expects a name to have no whitespace in it.  The conditional and
regex need to be changed to look for bracketed names like [Poorly
Designed Table].  Then, the columns sub needs to know to take the
brackets off the ends of the names when it looks up the table by its
textual value.  To complicate this, according to
http://msdn2.microsoft.com/en-us/library/ms176027.aspx you can have
either double-quotes or square brackets as your delimiters in SQL
Server names, and you can even escape brackets by doubling.  I
have written hackish code that solves for simple [Dumb Name] tables but
not the whole enchilada, so I'm not posting it here yet.

2. The data type “ntext” seems to create memory allocation problems; I get an error of:

/usr/lib/ruby/site_ruby/1.8/DBD/ODBC/ODBC.rb:220:in `fetch': failed to allocate memory (NoMemoryError)

Running this on CYGWIN_NT-5.1 RANDALL-VAIO 1.5.19s(0.141/4/2) 20051102 13:29:13 i686 unknown unknown Cygwin on Win XP Pro.

[HINT] Preprocessing mongo XML files for use with XML::Simple

If you are a reasonable Perlista, the first thing you will do when you
have to do some modest but non-trivial munging of data locked up in XML
is to use XML::Simple.  The API is nearly perfect (absent the lack
of some defaults that could be more helpfully set for strictness) for
purposes of comprehensibility and transparency.

However, if you prototype on a small document, and then try to use your
code on a much bigger XML document, you will find the drawback:
tree-building is costly, and you may spend the vast majority of your
program's time parsing in the document.  One handy solution is to
preprocess your XML — just run XML::Simple's XMLin sub, and use
Data::Dumper to spit out the structure that results to a file. 
When you want to use it, you can simply “eval” it, for it defines a
native Perl structure, and you can use the remainder of your code
unchanged.  This resulted for me in a 2x – 10x speedup for certain
documents and certain sizes.

However — now imagine that you have some real torture-test data — 10
MB, heavily nested monstrosities of XML.  The Dumper output of the
parsed tree is now working on 100 MB!  Slurping this in and
evaling it is now the real problem.

Here's an idea: rather than slurping and evaling, try inlining it at
the compilation stage.  That's right — make use of Perl's much
more efficient way of slurping and evaling a filehandle with a pipe:

cat preprocessed_xml.dd myscript.pl | perl

It's somewhat unorthodox, but entirely functional.  Combined with
judicious use of gzip, this could be a very efficient way to get
little-changing XML documents into perl quickly — often very important
when doing dev work for which numerous iterations are required and for
which a minutes-long parse stage would adversely affect progress.

Update: It occurred to me that
using Storable or a Cache::* module might be faster yet.  At this
point, my work proceeds with tolerable speed using Data::Dumper, plus I
like using Dumper so that I can edit the output structures by hand if
need be.  But perhaps you should try those modules if you need
even better performance, or cringe at the hackishness of catenating
files piped to perl.

"Can't coerce GLOB to string in entersub" means "File not found"

For users of the Perl modules XML::LibXML and XML::LibXSLT, you will save yourself much puzzlement if you understand that “Can't coerce GLOB to string in entersub” really means “file not found.”

NOTE that the file which is not found might be your XML, your XSLT, or the schema / DTD for these things! Maybe some -e tests are in order (but don't forget that filenames hidden in your XML pointing to bad DTD paths, for example, will throw the same cryptic error).

See also http://maclux-rz.uibk.ac.at/~maillists/axkit-users/msg05794.shtml

WORKAROUND: Excel for Mac toolbars "trapped" off the screen

If you hook up an external monitor to your Mac OS X machine and run Excel 2004 for Mac on it, you might move your toolbars completely or partially over to the second desktop area. If you then remove the external monitor, it is possible for the toolbars to get “stuck” such that only a corner (like the resizing corner) is visible. You can resize them, but not move them back onto your main screen.

You can try to use “Reset” in the View:Toolbars:Customize Toolbars/Menus, but that doesn't work. There's some other reset-to-defaults choice somewhere that I tried (and can't find now) that didn't work either. Quitting and restarting does nothing.

Try going into your home directory (/Users/username) and nuking this file:

/Users/username/Library/Preferences/Microsoft/Excel Toolbars (11)

Upon restarting Excel, they were back to normal location. Problem solved (except for the braindead engineering).

[BUG] Lotus Notes sending malformed base64 encoded attachments

It appears that Lotus Notes occasionally sends malformed base64
encoded attachments.  I received a message from a Notes user that
was a forwarded message; the old message got hamburgered.

Others?  Appears so.

http://www.linux.ucla.edu/pipermail/linux/2002-February/006367.html

We especially suffer this with our RT installation.  No particular word on a fix at present.

Downgrading to Apache 1.3 from Apache 2 under Red Hat 9

Apache 2.0 can be a real cast-iron bitch.  It's got this cool
support for threading that you think will make your life easier but it
turns out to have all sorts of little API differences that break your
legacy apps, in really horrifyingly difficult to discern ways. 
This might be the apps' fault or Apache's fault, but either way it
makes your life hard if you are used to things working smoothly under
Apache 1.3x and then get jolted into the cruel world of 2.x.

 

Red Hat has put out Apache 2.0 since at least Red Hat 8.0.  Red
Hat 9 comes with Apache 2 as well.  However, Red Hat knows about
the problems as well as anybody: the non-gratis Red Hat Enterprise
Linux distros come with Apache 1.3x!  [UPDATE: Enterprise
Linux 2.x came with 1.3.x; Red Hat has made
the questionable choice of putting Apache 2 in Enterprise Linux
3.0 and removing things like the venerable Pine…] 
It's clear that if you actually want stability, you should use 1.3
until the rest of the world catches up with Apache 2.0.

(Other people know this too: see http://linux.derkeiler.com/Mailing-Lists/RedHat/2003-07/0726.html and http://lists.freshrpms.net/pipermail/rpm-list/2003-May/004682.html )

If you want to downgrade your Red Hat 9 Apache version, you can
either try to compile, which is fairly straightforward once you find
the fixes I mention below, but if you want mod_perl and mod_ssl, and if
you are not very smart, like me, you really are better off using the
rpm packaged versions.

 

Unfortunately, the openssl 9.7 that comes with Red Hat 9 will
prevent you from installing mod_ssl 2.8 to go with Apache 1.3. 
So, here's how to install Apache 1.3 with mod_perl and mod_ssl:

 

1. Erase the apache 2.0 rpm from the system.  Nuke the dependent packages as well (mod perl, mod ssl, php, etc).

2. Get:

apache-1.3.27-2.i386.rpm

mod_perl-1.26-5.i386.rpm

mod_ssl-2.8.12-2.i386.rpm

openssl-0.9.6b-32.7.i386.rpm

 Warning: these packages are
end-of-lifed and may present security hazards (read: your box could be
owned if you do this!).  I am no longer running a box with these
packages and I suggest you do not either!  I currently recommend
apachetoolbox (apachetoolbox.com) for a quick and relatively painless
recompile, rather than relying upon these old dusty rpms.

3. Install apache and mod_perl.  Ensure that it works fine (sanity check).

4. Back up /usr/share/ssl/* to e.g. /usr/share/ssl9.7a/

5. Back up /usr/bin/openssl to e.g. /usr/bin/openssl9.7a

6. Install openssl with a suitable command line:

rpm -ivh openssl-0.9.6b-32.7.i386.rpm –excludedocs –oldpackage –force

7. Now back up /usr/share/ssl/* to /usr/share/ssl9.6b/ and restore ssl9.7a/

8. Back up /usr/bin/openssl to openssl9.6b and restore openssl9.7a

9. You should now have both openssl 9.6b and 9.7a installed on your system.  You can verify this with rpm -q openssl

10. Now install the mod_ssl RPM.

 

Make sure you've used lokkit (or manually arranged) to open up both
port 80 and 443 or else you'll drive yourself crazy for 20 minutes,
like I did, wondering why http is running but not answering.

[BUG/WORKAROUND] Microsoft Outlook 2003 / XP can't import vCard notes field; Entourage on Mac can

I am trying to sync my contact information between apps and machines. Here are my absolute, non-negotiable requirements:

(“Works
with” means I can round-trip in the given format — not necessarily
that it is native, and it's OK if I have to use a tool or a script
intermediary since I'll be scripting this stuff anyhow.)

1. Works with Outlook.

2. Works with Address Book on Mac.

3. Works with abook from the command line.

4. Is editable text in case I need to switch platforms, or do revision control, or any of a host of things.

I
was good with some kind of cobbled-together vCard solution, until I
discovered that MS Outlook 2003 on Windows XP could export note:
fields in .vcf files (oh, and insult to injury — there is no “Export”
option to vCard, you have to do some right-clicky nonsense or else
highlight all your contacts and “Forward as vCard”) but would not
import those same notes!

Outlook does not round trip a fully-spec'ed RFC standard?!?! What the hell?

Happily
(?) my workaround is to use MS Entourage for the Mac, which will
round-trip appropriately and sync itself with the Exchange server at my
work.  For those who cannot, perhaps there is a VBA
solution.  If you have one, please comment; I will update if I
discover how to get Outlook 2003 to accept the notes fields.

[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
directories:

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`"

fi

 

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

https://listman.redhat.com/archives/shrike-list/2003-April/msg00160.html

[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
presence).

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!