sysadmin/LicenseVirtualization written at 23:43:28; Add Comment
An advantage of virtualization for license servers
One of the more subtle advantages of full hardware virtualization is that your virtualized hardware always stays the same, no matter what actual hardware you happen to be running on. This is a real advantage for license servers, which are often nodelocked with various crazy schemes that assume you are trying to cheat on them if you change hardware.
(Sure, the company might fix the problem for us. If they're still in business, still interested in our business, still having anything to do with that ancient version of the software, and so on. All too often, companies seem to treat license problems as a great opportunity to extract more money from you.)
Virtualized hardware can even survive nodelocking schemes that require the inode numbers of crucial files to not change, because the disk is virtualized too. All you have to do is back up and restore the disk image (which is generally just some files), and everything comes back just as it was, inode numbers and all.
In fact, simplifying backup and restore in general is a nice feature of virtualized hardware. We no longer have to wrestle with various system specific programs that may or may not completely work; instead we can just snapshot, back up, and restore some files, something for which we have lots of tools. And we're guaranteed to back up and restore everything, with complete fidelity. And the whole process is much simpler, especially restoring a system (which can often be a nightmare).
The other great advantage of static hardware is static operating system stuff that depends on hardware, which in turn means that we never again have to do things like dig up a nearly exact replacement for a piece of dead hardware in order to get a system running again in a hurry without monkeying madly with its configuration. This is especially an issue for old systems, where you may not be able to reinstall the operating system on your recent hardware even if you want to because it lacks the necessary drivers.
python/LeaveIOErrorAlone written at 00:59:49; Add Comment
Please leave IOError and OSError alone
From Lawrence Oluyede's blog entry about recent Python SVN updates:
Augh. Wait, that's not strong enough, let me try again: AUGH.
In fact, it gets worse. To quote from the urrlib2 SVN source
code's comment about its
(urllib2 also directly raises mis-formatted
What these people have done, whether they realize it or not, is to turn
IOError exception objects into nothing more than strings, because
these modules have insured that there is no higher structure that you
can count on an IOError instance having. Unfortunately the relevant
does not mention this, and continues to mislead the innocent into
believing that when they catch an IOError exception they can do useful
things like look at its
Or, to boil it down: never raise or subclass IOError, OSError, or EnvironmentError.
(This applies to
The only exception is if you are somehow directly calling a C library
function (that is documented as setting
To my horror, urllib2 is hardly the only offender; there are even some in C level modules (in bz2module.c and zipimport.c). But that doesn't excuse them making the situation worse; in fact they should be moving towards making the situation better. Even with backwards compatibility concerns they could have raised URLError instead of IOError directly (or taken the opportunity to introduce a proper error class if they felt URLError was inapplicable).
(This rant has been brought to you by my attempt to catch up on Planet Python.)
spam/SpamSummary-2007-03-31 written at 00:29:27; Add Comment
Weekly spam summary on March 31st, 2007
This week, we:
Somewhat to my surprise, volume is down again from last week, although the concurrent connections highwater is up a lot.
Kernel level packet filtering top ten:
Host/Mask Packets Bytes 126.96.36.199/24 21236 1031K cox.net 188.8.131.52/24 17748 1065K centrum.cz 184.108.40.206/24 15832 718K bellsouth.net 220.127.116.11/24 13549 658K cox.net 18.104.22.168 13506 702K 22.214.171.124/24 9359 449K adelphia.net 126.96.36.199 8992 494K 188.8.131.52 5195 286K 184.108.40.206 4553 219K 220.127.116.11 4264 235K
By contrast, our kernel packet filtering blocks are up significantly from last week, partly because I was aggressive about throwing blocked advance fee fraud webmail sources into the kernel filters early on. As a result of this, blocked webmail sources account for half the top ten, and all four of the top spots. (To save space, I've just annotated the main listing with who each /24 belongs to.)
A note to people: if you want to look straightforward and innocent, don't give your machines separate domain names that vary only in their trailing digits, and especially don't try to send email from them with the same SMTP MAIL FROM. Because there are really not that many innocent explanations for why you would need your outgoing email pool machines to have different domain names.
Connection time rejection stats:
48510 total 26705 dynamic IP 16564 bad or no reverse DNS 3814 class bl-cbl 204 class bl-sbl 180 class bl-dsbl 161 acceleratebiz.com 110 class bl-pbl 109 dartmail.net 74 cuttingedgemedia.com 71 class bl-njabl 43 class bl-sdul
Seventeen of the top 30 most rejected IP addresses this week were
rejected 100 times or more; the leader is 18.104.22.168 (237
rejections, for having bad reverse DNS). Eleven of the top 30 are
currently in the CBL, 3 are currently in
(Locally, 18 were rejected as 'dynamic IP', 11 were rejected for bad or missing reverse DNS, and one was a cuttingedgemedia.com machine.)
This week's Hotmail numbers are:
And the final numbers:
Well, so much for the nice numbers on bad bounces from last week.
In better news, no particularly source of bad
Bad bounces were sent to 22 different bad usernames this week, with the
most popular being
The most prolific source of bad bounces is an ISP in Bulgaria, followed by Earthlink. The remaining bad bounces come from all over, including a well-named machine called 'mail.victim.com' (22.214.171.124).
* * *
Atom feeds are available; see the bottom of most pages.