This is really getting my goat. I've been stuck here for a day now.

I'm using a module MySite::Cache included as a PerlModule directive in httpd.conf. It implements Cache::FastMmap and makes a global cache for my objects. It looks like this:

So I'm implementing my own read_cb, write_cb, and delete_cb. The objects in the cache always have store() functions to stick themselves into the database. This module knows how to interpret cache keys to make db queries for read_cb and delete_cb.

This all works great, until I try to use write_back mode. Suddenly, the write_cb is never called and objects never store themselves in to the database. When objects are purged due to timeout or size limits, they are not written via the store() method at all. empty_on_exit is not called either. I've tried an empty() call in the DESTROY method of MySite::Cache, but that did not help.

I'll keep digging...

Well, after years of whinging, muttering, and inaction an actual rewrite if this website is underway. I'm moving from PHP to mod_perl (I'm a monger through and through) and things are going pretty slowly, but they're going.

Hooray!

Re-post from an email to my old LUG:

Ok this is weird.

First, I started getting 503 errors from mirrorlist.centos.org when
trying to use yum on some centos servers.

Then, no more centos.org DNS resolution at all. So first, I ran to
google. Turns out I found a post from Dec 4 2007 with the same problem. It was
apparently down for about an hour, then the user reported it was back again. I
also tried a few links to sites in the centos.org domain, but of course DNS is
broke for all of them, so that's a no-go.

So I tried tracing DNS from the root servers to get to centos.org. I got
to the org. nameservers, and ta-da! They have no idea who centos.org is.

Next I whois centos.org. Well, well, lookie here:

Domain ID:D103409469-LROR
Domain Name:CENTOS.ORG
Created On:04-Dec-2003 12:28:30 UTC
Last Updated On:05-Dec-2008 06:45:17 UTC
Expiration Date:04-Dec-2009 12:28:30 UTC
Sponsoring Registrar:Tucows Inc. (R11-LROR)
Status:CLIENT HOLD
Status:AUTORENEWPERIOD

Not only do they only register their domain for a year at a time
(apparently), but someone forgot to re-up. Again. For the second year in
a row.

wtf? Has it really been broken since 12:30 this afternoon UTC? I guess
my cache just expired.

I have packages to install.

[Edit: Also, the time on this post is wrong. This started (for me) at about 06:00 GMT -- taking that into account, what's with the "Last Updated On:05-Dec-2008 06:45:17 UTC"?]

This was something I wanted for a little while, and never got around to. I use logwatch [logwatch.org] on my servers to send out daily reports, and it's a useful tool to keep an eye on things. Certainly not the magic-server-admin-bullet for monitoring, but it provides a useful daily overview of what's going on. The default postfix reporting it creates is OK, but not that great. Especially with the fact that I use greylisting (currently via postgrey [postgrey.schweikert.ch]...at least until ulppd [ulppd.projects.mifflinet.net] is a little more stable) -- it prints out an ungodly number of lines showing me every time a delivery is tempfailed. Greylisting means that happens quite a bit.

So, in comes pflogsumm [jimsun.linxnet.com]. It's a very nice little perl script that runs through postfix logs and generates a fancy-schmancy report. I wanted to swap out the generic postfix stuff from logwatch with the output from pflogsumm. The following is the fruit of my efforts (only about 15 mins of work, really) -- how to integrate pflogsumm with logwatch.

First, install pflogsumm. The easiest way is probably to grab the script from James at the link above, and put it wherever you like (/usr/local/sbin is a reasonable choice). Don't forget to make it executable. If it's packaged for your distro and you prefer that method, go ahead and install it that way. Note that you'll also need the perl modules (not in my distro's perl) Bit::Vector, Carp::Clan, and Date::Calc.

Install logwatch as well. That's likely packaged for your distribution.

Next, you'll want to make a copy of the pflogsumm.pl script for logwatch to use. I say to make a copy, because you'll edit the file directly instead of passing command-line arguments. Unless I've missed something (quite possible), logwatch doesn't provide a method for giving command-line arguments to the service scripts. Anyway, copy pflogsumm.pl from wherever you've put it to a file named /etc/logwatch/scripts/services/postfix. You will likely need to create the /etc/logwatch/scripts/services directory. Make sure the file is executable.

Determine what command-line switches you would like to use with pflogsumm. I did this by running the script a few times with different flags until I found the output I wanted. You can ignore the -d flag since logwatch will only feed relevant lines to pflogsumm anyway. For me, I wanted to use the switches --mailq and --smtpd_stats. To set these, edit the /etc/logwatch/scripts/services/postfix file directly, and look for the GetOptions call. For me it was around line 464, but may vary depending on the version of pflogsumm you get. The section looks like this (sorry for the ugly formatting):

Set the options you want after the ') || die "$usageMsg\n";' line. Since I was using on/off switches, I just set the options to 1.

Save and close the file.

Next, you'll need to edit the service configuration to remove the call to the *RemoveHeaders shared script. Otherwise, pflogsumm gets confused by the log format, especially since it doesn't contain the date/time info. The easiest way to do that is to copy /usr/share/logwatch/default.conf/services/postfix.conf to /etc/logwatch/conf/services/postfix.conf. Then edit the /etc/logwatch/conf/services/postfix.conf file to comment out the *RemoveHeaders line. For me, the configuration file now looks like this (the commented out line is bolded and underlined):

That's all there is to it. You can check if it's the way you want it to look by running logwatch as "logwatch --print" to print it to STDOUT, and you should see the postfix section replaced with a nice pflogsumm report.

How did I not know about vimperator [vimperator.mozdev.org] before? VIM keybindings and VIM-ish interface for freakin firefox!! No more <C-d> to go down a page and getting the stupid Add Bookmark dialog. I've only used it for a few minutes now and oh yes, this is sweet. Off to the documentation...

Going with the latest version also pushed me into moving to firefox 3 (which I've been meaning to do for a couple weeks now).

How's the snow SUCKERS?

I had a bit of a hitch working on my ulppd [sourceforge.net] project. Using Net::Server, it's not possible to chown the UNIX sockets it creates. You can put a chown into the post_bind_hook and it will be executed, but it's soon undone in post_bind (the next stage). This stage takes care of dropping permissions and chowning files to the user/group it's dropping permissions to.

With this patch, you can simply pass sock_owner and sock_group to the Net::Server, and the sockets will be chowned to that user/group respectively. If one or both options are omitted, the previous behavior is maintained.

Patch is available here [ulppd.svn.sourceforge.net]

So I was getting all in a huff because logrotate wasn't rotating my log files (CentOS 5.2, but not a problem specific to that). It was really getting to me, as the config was EXACTLY the same as other servers (same OS, same versions of logrotate, even the same versions of crond running logrotate). I was testing by running "logrotate -d /etc/logrotate.conf" which reported that none of my logfiles needed to be rotated. The logfiles in question were over 2 weeks old and configured to rotate weekly, but still logrotate indicated they didn't need to be rotated. If I changed the config to daily instead of weekly, it correctly reported that they needed to be rotated.

Finally reading through the man page I noticed the -s, --state <statefile> flag, which I never really paid attention to (or knew about). Well, part of my investigation was trying to figure out how the heck logrotate determines when the log file was created. Turns out that it uses this state file to keep track of the last time logrotate rotated files, and thus when the files need to be rotated again.

That made the failure apparent -- I had only installed logrotate about 4 days ago, so on it's first run it wrote to the state file that the log files were "created" on that date. Since it only saw them as 4 days old, it determined they didn't need to be rotated. I confirmed that by editing the state file by hand to set the date back, and running logrotate with the -d flag again. Worked like a charm.

Long story short, after a fresh install and first run of logrotate it will take a full week to rotate weekly files, a month to rotate mothly files, etc. This can be corrected by editing the state file (/var/lib/logrotate.status by default) by hand.

I've had a few goings-on recently on some projects...

I finally released my UniversaL Postfix Policy Daemon as opensource here [ulppd.sourceforge.net]. It's still in early alpha, though it works. I'm not sure if it'll be useful for anyone or not. It's basically a perl daemon and framework which makes it easy to implement arbitrary anti-spam stuff in perl. All you have to do is create a package that implements Ulppd::Filter and tell the ulppd daemon to use it. There is absolutely no documentation yet, so if you're curious or would like to try it, go ahead and ask me questions. In fact, I haven't even packaged it for the downloads section yet, but you can grab it from sourceforge svn at svn://ulppd.svn.sourceforge.net/svnroot/ulppd [ulppd.svn.sourceforge.net]

I also put together some nifty stuff for managing DNS. Basically it's a package called Net::DNS::DynDomain implemented in a script called dnswatcher. It can watch dhcpd lease files, openvpn status files, local IP addresses, and static files, and automatically update internal/external servers' djbdns via Net::SSH::Perl when changes are detected. It's pretty localized to my environment, but it could easily be modified for your own stuff. If you're interested, once again let me know, and I can send you the source and help you set it up.

I've been pretty busy. In other news, I really should start working. Anyone need a sysadmin/perl developer (telecommute preferred and pay me lotsa dollars plskthx)?

Have you not been informed? There is a semantic well-known to be the lexical; all have auscultated.








Ba ba ba ba ba ba ba ba oo ma mow mow ba ba oo mow ma mow

userlame.com is no longer running on my personal network after probably 8 years or so. It now lives in a real-life datacenter!

In other news, I'm moving things off of my network because I have some big plans ahead...

Please do tell me if you see anything funky on the site or something doesn't work.

Also, I fixed the date/time problem. I really can't believe I waited so long to make a fix as minor as that was.

The title says it all. I've pondered this [plasmasturm.org] myself many times, and always reached the same conclusion.

Someone local (in my city) just checked out the site today for the first time in over a month.

WHO ARE YOU MYSTERY PERSON? SHOW YOURSELF!

Really, I'm just curious.

Um, turns out there's a local root exploit in the linux kernel versions 2.6.17 to 2.6.24.1. I just tried it on my machines - yeah, it works. Read the slashdot discussion here [it.slashdot.org] and see the proof of concept code here [milw0rm.com].

Still reading about it now. This is huge. Hold me.

By a picture on their website [bradblog.com]!

Haaahahahaha. You posted a close-up picture of the real key?! Haaaaaaaaahahahahahaha.

Edit: apparently I didn't read this (the date specifically) too closely. Old news, but still new to me and made me laugh.

After months of rigorous testing, sweat, blood and tears I've finally perfected the formula.

Here it is.

Are you ready?

Just so I won't forget and maybe google will spider this and it'll help somebody. There's a (kinda) bug [bugs.gentoo.org] in gentoo's 2007.0 stage3. I'm using amd64, but it's due to the version of ssh which was put into the stage3, so I'm sure it's across platforms. /etc/skel/.ssh is created with permissions 0600 - so when you add a user, by default they won't be able to cd to ~/.ssh. That's a problem when using ssh keys and it frustrated me for a few minutes because I couldn't login in to new servers.

Fix by the following:


After this any new users can use their .ssh directory. If you've already added users and are having problems here's a quick fix:

I just read this [edition.cnn.com] today:



Agreed. So, when does the US become a modern, confident nation?

I meant to post this a while ago, but never got around to it. If you've purchased a ZyXEL GS2024, and it came with firmware V3.8(LT.0)C0 I pity you. I too bought this lovely lemon. Long story short, it sucked. I was really disappointed when I had my new switch running for about 5 minutes and thought I had to RMA it.

I pulled it out of the box, fired it up, and started playing with it, and no sooner had I upped the serial baud rate when the hardware error light came on. Then it started flashing. Not steadily either, just random on/off. The second command I checked out was reading the logs. I found a whooole bunch of errors in the log about the fan dropping below threshold and recovering (many times per second). From running the diagnostics on the switch the fan was peachy. Sigh.

I checked for new firmware, but this was the most recent. So recent in fact (I thought) that it wasn't even on the manufacturer's site. The manual for 3.8 was there and released only weeks before. I'm sure they actually pulled the firmware down when they realized what a bad bug it had. I googled around and found someone else complaining of the same errors after upgrading from 3.6 to 3.8. I can't find the site now, which is weird. I was there numerous times and posted on it. Hm. I'd post the log messages from the switch, but mine are gone and the only place I knew that had them was that site.

Anyway, I downgraded the firmware and have been playing around with it while running version 3.6. The only feature that I noticed was missing was the ability to use ssh keys. I also noticed logging in as admin wasn't automatically in enable mode in the earlier version. Whatever.

Well, earlier this month, ZyXEL put out a bugfixed version of 3.8 which is available on their site [us.zyxel.com]. If you were one of the lucky ones to get your GS-2024 shipped with firmware V3.8(LT.0)C0 - well, hopefully you've downgraded, but now you can go get a better (read: working) version of 3.8. The version name is very similar - V3.8(LT.1)C0

I would like to point out that it's a very nice switch and I'm quite pleased with it now. ZyXEL was very fast with a fix, but it was disappointing that a bug so painfully obvious was put out, and loaded on production models. Running it for more than a minute or two showed the problem.

Update: Found the forum post I was talking about here [fixya.com]. The fan log messages looked like:

I just noticed the dates...on every post. Hrrrrrrmmmmmm....looks like I screwed the db transfer and didn't notice. Too bad the old one has already been blown away!

At least the IDs kept em in order. Sigh. Now to figure out why new posts get the same date.