Zakame::Blog

Making Net-Akismet play with TypePad AntiSpam

Wed, 04 Jun 2008 10:10:38 +0000

I've been getting a lot of blog spam lately; it appears that Akismet is slipping. Fortunately, there's a new Akismet-compatible alternative at TypePad AntiSpam which I read about from Justin Mason's post. And it being perl, I decided to try it out here on my blog (never mind it being Blosxom, as long as it uses Frank Hecker's feedback plugin that in turn uses Net::Akismet.

But alas, the current version of Net::Akismet doesn't support user-supplied REST endpoints, so I added it, and promptly filed a report on the CPAN. Hopefully it gets included in the next release very soon.

As for the Blosxom feedback plugin, tweaking it to use the new feature in Net::Akismet was a cinch, so only the real test (of incoming spam filtered by TypePad) remains. Hopefully it does work.

[PS: Looks like the first line in blosxom posts don't like package-like names such as Net::Akismet (during editing my blog title disappeared on the render!) Needs to be looked at later...]

Where's the Open?

Wed, 14 May 2008 11:31:08 +0000

Ok, so it seems that the whirlwind on OpenSSL has settled down a bit. Posts about it are coming from everywhere, ranging from rants on package maintenance to blame-pointing on both upstream and packager sides. And, of course, Slashdot.

Where does all this leave the end user with? Well, probably not much except to regenerate weak SSH keys with the new openssh-server (now enhanced with openssh-blacklist, see the new advisory) and hope to $DEITY all gets well soon. And maybe, just maybe, a minor suspicion that other Debian-packaged software may be "tainted" with a similar blemish (that being having patches that are supposed to fix something, applied with upstream's blessing, and yet not really audited enough to ensure functionality AND security of the system is maintained.)

Obviously, there's going to be some adjustments to be made on the Debian side. But I do hope to $DEITY that major revamps ought to happen on the OpenSSL side as well, in particular on clarifying their public channels to reaching upstream developers (read: publish openssl-team@openssl.org in a legitimate way, being the legitimate upstream contact endpoint it is,) and keeping a closer eye on the vendors who package their software (yeah, it may not be an obligation at all for OpenSSL, but heck, their vendors are users, too!) Upstream may be free not to partake on a social contract like Debian's, but it shouldn't escape from them the fact that vendors nevertheless aggregate continuing and potential users (aside from being users themselves) for their benefit.

More importantly though, is that delivering FOSS is a community effort. Sure, its easy to put blame now, but in the end, the blame isn't as important as the real cause and effects of the problem/bug/issue are. Better to move on and work together towards a real fix, rather than the bickering that currently passes as FOSS entertainment.

OpenSSL Ouch

Tue, 13 May 2008 16:32:44 +0000

I won't repeat it here, but there's DSA-1571-1 waiting for your attention, especially if you made some material out of openssl over the last couple of years or so. Yes, you read it right: COUPLE.

Upgrading to the new OpenSSL is easy. Generating new keys is another story.

To save (or add to, depending on how you handle this) your pain, there is a simple checker that can currently see if your OpenSSH or OpenVPN public keys are weak enough to warrant replacement. I await a version that can handle X.509 certificates too (though I only just generated a new one today, before the announcement, so that means I have to do it again (and get its CSR to CACert for signing, etc.)

And yeah, if you're running openssh-server, consider regenerating your host RSA and DSA keys, e.g.:

# mv /etc/ssh/ssh_host_{dsa,rsa}_key* /some/place/else
# dpkg-reconfigure -plow openssh-server

That should regenerate your keys and restart openssh-server once the new keys are installed to /etc/ssh.

The hard part (of making sure all the keys of your systems are updated and tested) is still up to you, however.

UPDATE: The Debian wiki has up-to-date information regarding other packages that generate SSH/SSL keys at postinst. Please refer to that while the key-rollover page isn't up yet.

UPDATE 2: openssh-server is updated (with corresponding DSA-1576-1) that is linked to the updated OpenSSL library. Be sure to upgrade! The new package also pulls in openssh-blacklist, a new package that contains the database needed by the new ssh-vulnkey for checking SSH public keys.

Adding Some Blog Bling

Sun, 11 May 2008 01:46:53 +0000

I added some more bling to this blog last night, like a spiffy new CSS theme (based on twocolumncss) and a handful of plugins to improve feed generation, readable and extensionless URIs, and support for comments and trackbacks. Blosxom indeed is such a flexible toolkit for making a blog! :D

That said, I did find one or two quirks in the plugins existing in the blosxom and blosxom-plugins CVS repository; I'll post patches to my git mirrors of these repositories. I'll probably add some more features on some of the plugins I used too (that reminds me, I should put up a list somewhere.)

Apache2 Worker MPM on Low Memory Servers

Sat, 10 May 2008 02:42:53 +0000

If you're running Apache2 on a memory-constrained system (like in a virtual machine,) you may want to choose the prefork MPM to save memory at the cost of more process forks. However, if you have more than one CPU on that same machine, you may also want to consider using the threaded worker MPM and tweak its MaxClients and ThreadsPerChild settings from the default configuration.

On a typical apache2 installation on a Debian system, the worker MPM configuration looks like this:

<IfModule mpm_worker_module>
    MaxClients          150
    MinSpareThreads      25
    MaxSpareThreads      75
    ThreadsPerChild      25
    MaxRequestsPerChild   0
</IfModule>

Using these default settings on a resource-constrained system (say a server with 128MB of RAM but with no swap) would be overkill, and the web server processes will definitely eat up all of that memory, leaving little or no room for even simple CGI scripts.

In my setup, I experimented with tweaking the values above to get apache2 to serve without eating up too much precious memory. I found that the important values to consider here are MaxClients, which dictate how many clients can connect simultaneously to my server, and ThreadsPerChild, which specifies how many threads of execution can run in a child/worker process. My resulting config becomes:

<IfModule mpm_worker_module>
    MaxClients           15
    MinSpareThreads       3
    MaxSpareThreads       7
    ThreadsPerChild       3
    MaxRequestsPerChild 200
</IfModule>

With this setup, I free up a significant amount of RAM from apache2's hold whle maximizing my thread usage in each worker process; at the same time, I avoid keeping each child process for too long by setting a maximum number of requests each worker can serve, preventing the workers to bloat too much when handling CGI.

I also tweaked the KeepAliveTimeout setting to just 2 seconds (instead of the default 15) so that each worker process can go to the next request quickly and preventing them from being tied up to a connection for too long. I also set the Timeout to 30 seconds.

Some Exim4 hacks

Mon, 28 Apr 2008 15:03:10 +0000

Exim is the stock MTA in Debian, and rightly so, since its pretty much the most flexible MTA around (note: I did say "most flexible," not "most secure.") It is also very easy to set up, thanks to its debconf integration and sane configuration interface; however, there may be some bits that still needs that extra tweaking that a dialog or menu interface can't reach:

Setting the Right mailserver hostname

Most mailservers typically go by a hostname of "mail" or "mx," for various reasons. Of course, this requires setting the right DNS entry for your domain, but Exim may miss this and use the internal hostname of your mailserver instead. There are quite a lot of ways to set the "right" mailserver name in Exim, but in Debian, it is recommended that one DOESN'T set it via the primary_hostname variable, as this can mess up other places in the Exim configuration and complicate matters. Instead, one can use smtp_active_hostname in the global options:

smtp_active_hostname = mail.foobar.net

Changing Received: header

If one changes the mailserver hostname like above, then it also probably needs to change some headers as well, like the "Received:" header. Again, this is a global options setting, controlled by received_header_text:

received_header_text = Received: \
${if def:sender_rcvhost {from $sender_rcvhost\n\t}\
{${if def:sender_ident {from $sender_ident}}\
${if def:sender_helo_name {(helo=$sender_helo_name)\n\t}} }}\
by $smtp_active_hostname \
${if def:received_protocol {with $received_protocol}} \
${if def:tls_cipher {($tls_cipher)\n\t}}\
(Exim $version_number)\n\t\
${if def:sender_address {(envelope-from <$sender_address>)\n\t}}\
id $message_id\
${if def:received_for {\n\tfor $received_for}}

Note that this changes the header when your Exim receives mail; when your Exim sends mail to another mailserver, you'll have to ensure that the header made by the destination mailserver has its hostname matching your own. Thus, you need to fix the "remote_smtp" transport a bit:

remote_smtp:
  debug_print = "T: remote_smtp for $local_part@$domain"
  driver = smtp
  # to disable TLS on outgoing connections, uncomment this
  # hosts_avoid_tls = *
  helo_data = $smtp_active_hostname    # use the variable we set earlier
  # use the interface our Exim is running on and where the mailserver name points to
  interface = 1.2.3.4

Changing Message-Id

Finally, one can change the "Message-Id" header to match the new hostname above, via another global options variable, message_id_header_domain:

message_id_header_domain = $smtp_active_hostname

Subdomains for Blog and Code

Sun, 27 Apr 2008 16:41:15 +0000

I have reorganized the site a bit. This blog is now on its own subdomain (and www currently redirects to it.) My existing and new projects (under their own git trees) are now on the code subdomain, with gitweb as root.

I'll probably put up a wiki as the main www, and maybe even lists (in case some of my projects go gold heh.)

Hello, World

Sat, 26 Apr 2008 07:44:21 +0000

You have reached my little site. There's not much here at the moment, but do drop by every now and then; its a work in progress.

As you can see, this site is quite spartan, and that's the way I like it. I'm currently using blosxom for this ephemeral blog site, despite the prevalence of database-backed blogging and CMS software with all the Web 2.0, AJAX, and Web Services bullshit. Those are not for me, at least for the moment; nor do I want to encourage a "community" around my site, whatever that is, as I have better things to do than exchange pleasantries.

That said, I know that the blosxom code is rather old and the plugins available for it seem to be disappearing. Since its in Perl, however, I think I can take a crack at writing my own plugins (and possibly improving blosxom itself.) I might probably rewrite it in CGI::Application, if it comes to that.

By the way, in case you're wondering: I'm Zak B. Elep, and I go by zakame on the Internets. I actually have an older, more dynamic, and friendlier weblog at spunge.org, where it all started; more on that later.

And yeah, the standard disclaimers for blogging applies: this site contains my own personal opinions on various matters (and maybe some real, hard facts, from time to time,) and in now way should these opinions be construed as official statements of organizations or companies I'm connected with. They have their own PR reps: talk to them if you need "official" shit.

That's all for the moment: I'll go play out with some code.