Jun 04, 2008
Making Net-Akismet play with TypePad AntiSpam
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...]
Tags: akismet, blosxom, perl, www. | Posted at: 18:10 | 0 Comments/Trackbacks.
May 14, 2008
Where's the Open?
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.
Tags: community, debian, linux, openssh, openssl. | Posted at: 19:31 | 2 Comments/Trackbacks.
OpenSSL Ouch
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.
Tags: debian, linux, openssh, openssl, perl, remote, vulnerability. | Posted at: 00:32 | 13 Comments/Trackbacks.
May 11, 2008
Adding Some Blog Bling
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.)
Tags: blosxom, perl, www. | Posted at: 09:46 | 0 Comments/Trackbacks.
May 10, 2008
Apache2 Worker MPM on Low Memory Servers
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.
Tags: apache2, debian, linux, lowmem. | Posted at: 10:42 | 2 Comments/Trackbacks.
Apr 28, 2008
Some Exim4 hacks
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
Tags: debian, exim, linux, mail. | Posted at: 23:03 | 0 Comments/Trackbacks.
Subdomains for Blog and Code
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.)
Tags: git, www. | Posted at: 00:41 | 0 Comments/Trackbacks.
Apr 26, 2008
Hello, World
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.
Tags: blosxom, cgi-app, morphlabs, perl, ubuntu. | Posted at: 15:44 | 0 Comments/Trackbacks.