rlucastemp

In Microsoft Internet Explorer >= 5, a DNS error (asking for a hostname that doesn’t exist) causes IE to pull an evil stunt and feed the requested URL to http://search.msn.com/dnserror.aspx , where it is used to search MSN and logged for who knows what nefarious purpose.  Rather than being opt-in behavior, this is opt-out, and rather than making it clear with a choice in options like “Automatically search when a site is not found”, opting out is a matter of making this choice:

Tools:Internet Options:Advanced:Search from the Address bar:Do not search from the Address bar.

Irksome.

Have you seen this spuriously:

Ops, no RSA or DSA server certificate found?!
You have to perform a *full* server restart when you added or removed a certificate and/or key file

in your ssl error log (and of course your Apache didn’t successfully start: ps -aux | grep httpd | wc -l is zero…) when you were using

apachectl restart

…or some utility that in turn used that method for restarting apache?  Try substituting

apachectl stop && apachectl start

INFO: Apache SSL error: You have to perform a *full* server restart when you added or removed a certificate … …

I have a Hawking Printserver, model number PS12U.  I had already set its IP address using the Windows software (it should be noted that you can ARP the printserver from Linux if need be; google for more info).  However, in order to set it up as a printer on my Linux machine, I needed the appropriate URI to feed to lpadmin.  I tried a number of things like ipp://192.168.0.1/lp1, etc., but finally gave up and used “printconf.”  The proper URI / URL to use, it appears, for addressing the Hawking PS12U is:

lpd://192.168.0.1/lp1

Where the IP address in the middle is naturally the one you’ve set for the Printserver and the “lp1” to “lp3” corresponds to the physical port on the PS12U to which you’ve connected the printer.

I didn’t say it was groundbreaking or an awesome fix, just info that I hadn’t been able easily to find.

Possible scenario: you wrote an ancient script using the CGI.pm module by Lincoln Stein, and it ran fine on your old RedHat 6.2 box with Perl 5.00503 and an ancient version of CGI.pm.   However, after reinstalling your script on a newer box with Perl 5.6, or else after upgrading your perl and/or CGI.pm, your script is broken and says

Undefined subroutine CGI::dump

Answer: in version 2.50 of CGI.pm, CGI::dump was changed to CGI::Dump. Try:

perl -pi -e ‘s/CGI::dump/CGI::Dump/’ yourscript.pl

FIX: “Undefined subroutine CGI::dump” crashes a formerly working script. …

I use SSH for everything from tunnelling outbound mail in order to avoid port 25 blocks on the freenet providers (such as www.personaltelco.net) to simple terminal sessions.  Also, most all of the time I am hooked up via a DSL or Cable modem with a router in front of it playing NAT tricks to get me to the outside network.  After about an hour (sometimes less) the SSH just hangs; from a Mac OS X terminal session it’s just unresponsive and needs to be killed, whereas on PuTTY on Windows, once it realizes the connection is no good it pops up a “Network error: Software caused connection abort” message.  The problem seemed to be worse with DSL from Verizon and Qwest, and seemed to be very mild with AT&T/Comcast cable in Cambridge, 02138 (advice: in Cambridge, you can’t go wrong with the Comcast digital cable.  I was getting speeds of (I seem to remember) almost a megabyte per second down and could pull down entire ISOs in minutes; debian net install on an old p233 was disk i/o limited and not network limited by what I could tell.

Happily, the good people at DSL Reports (www.dslreports.com) have put together an FAQ on this subject including some specific configuration options and links to more info:

http://www.dslreports.com/faq/7792

More on this as I determine if it actually works.

Update: So far, so good; a thunderstorm passing through caused a brief power cycle and that definitely reset the connection, but it seemed to hold otherwise, for example during lunch.  The real test will be leaving terminal sessions overnight.

Update: While looking for info on a superficially related problem, I came across this slashdot thread:

http://slashdot.org/askslashdot/00/06/24/0622236.shtml

This may also provide some assistance to seekers of info on this topic.  However! importantly, you should also examine the lengthy parenthetical in http://blogs.law.harvard.edu/rlucas/2003/11/17#a24 to determine if this is really your problem — the link to a TCP/IP theory page should help you as well.  This caveat is necessary because there are really two opposite problems that both manifest as “dropped ssh terminal sessions:” one, a NAT table on a cable/dsl router could be timing out (which argues for more frequently sending keepalive packets), or two, your connection could be flaking out briefly but coming back up fairly quickly (which argues against sending frequent keepalives).

FIX: SSH or telnet sessions timeout and drop connection on DSL or Cable modem behind NAT router …

If you go to install the Perl module DBD::Mysql on Red Hat 9 with MySQL 3.23 (and probably other versions as well), two gotchas might appear.  First, if the MySQL bin directory is not in your path, then you won’t be able to have it pull the options automatically.  Make sure that when the Makefile.PL runs (either because you’re running it or CPAN is) it can find and run mysql_config.

The second gotcha is that Red Hat shipped 9 with default LANG=en_US.UTF-8 in the shell environment.  This will cause your makefile to have some oddly malformed lines around line 89, and will cause a blizzard of these complaints:

The solution, according to the kind David Ross at Linuxquestions.org, is to

before running Makefile.PL. Many thanks.

http://www.linuxquestions.org/questions/history/62975

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

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.

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