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...

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!

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"?]

And as of about 09:30 UTC, it's back up again. Just like last year [webhostingtalk.com].

Odd.

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]

This introduced a new problem (technically it already existed in Net::Server) when using a sock_owner or sock_group other than the Net::Server user (or user's groups, respectively).

The patch has been updated. For more info, see Bug #3 [bugs.mifflinet.org].

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.

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).

Not to mention, go into a textarea and hit ctrl+i, and it goes ahead and fires up gvim for you. I didn't find that at first and installed the "It's All Text" addon, but that was totally unnecessary.

Still loving it.

How's the snow SUCKERS?

How's the snow SUCKERS?

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.

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.

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)?

Some updates...

ulppd now has a project page here [ulppd.projects.mifflinet.org]. You can check it out further there (not much up yet).

In addition, I have put out an alpha release of the software. It's in a working state, but I'm not ready to say it's beyond alpha yet.

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

sorry. i was at work and if i clicky on the boards tab..it says i'm blocked.

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.

HI.

I have a suggestion for userlame.com.

Can you have it so I can add a photo that is not from a URL. One that I can dump from my desktop.

K?

Thanks!

Cheer me up.

Thanks.

You should be cheered up by now...considering..

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

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.

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.

Never posted back about this did I? Oops. Well, here's a fix that should apply to most any vulnerable kernel. The affected file is fs/splice.c:

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.

Done!

Did I win?

I bet the time on the site will show it took like 2 seconds.


...really it took about 5.

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

Here it is.

Are you ready?

Hrm...

You did post in the very thread about the dates [userlame.com].

Long story short, as of now I dunno what the deal is.

The title says it all. There are some very big things in the works. That's all I have time to say now. The big things are keeping me busy.

Oh, and there was some breakage around the site. That's all better. Oops.

I'm developing and building out some really really cool nerd-stuffs right now.

The hardware list in my new stuff (mostly accurate) is available: here [userlame.com].

Also I apparently substitute emoticons before links - a link with "colon capital O" in it breaks horribly.

I don't like yahoo very much these days. They are (were) a minor but annoying thorn in my side. Lemme splain.

Yahoo has this nice feature for its email client called a vacation response. Basically you type in what you want it to say - "out of the office riding goats" or whathaveyou, and when someone sends an email to your account it sends back an email with the subject "Yahoo! Auto Response" - the text of the email contains "out of the office riding goats" or whatever you typed in.

Great. I can tell people I'm not going to read their email for a while. Whoopie.

Some flaws (besides the obvious AUTO-RESPONSES ARE EVIL. DO NOT USE THEM):

1) It doesn't keep track of who it has sent a response to. If I sent two emails to an account with that activiated, I'd get two "Yahoo! Auto Response" replies. Not terrible, though it could possibly lead to some funny mail loops.

2) It's really easy to set up a yahoo account. It would be pretty easy to script an account setup that would present just the captchas to be solved. Then the script could set up an auto-response.

3) No anti-spam policies at all seem to be applied to email that will be auto-responded to. At least I know they aren't checking SPF.

Mix em all together and you get a delicious spam pie. I've written a proof of concept (not a script, you'll have to do it by hand - the rest is an exercise I'll kill the reader for following) so you can see it in action. Try it yourself [userlame.com]. But please, have some netiquette.

In short, spammers are sending email to fake accounts with spam vacation responses. They are faking lots and lots of from addresses on those emails and the spam vacation response is sent to the faked from address. Thus, I end up with a buttload of spam.

It also is completely valid mail. It comes from otherwise (I guess) sane outbound mailservers for yahoo. The email will have a valid domain DomainKey-Signature and everything. It was getting by all my anti-spam because it looks so real.

And so finally, a resolution...spamassassin. Here's a simple rule to send all that crap where it belongs. Adjust the score accordingly if you need to.

header YAHOO_AUTORESPONSE_SPAMZ Subject =~ /^Yahoo! Auto Response$/
score YAHOO_AUTORESPONSE_SPAMZ 5.0
describe YAHOO_AUTORESPONSE_SPAMZ Yahoo auto-response spam

I'm going to bed.

Edit: Yikes, that link was broken. Originally it was .html, and I moved it to .php but didn't update the link. My browser had the .html cached so I never noticed. Sigh.

Well well, it actually just got much easier [internetcommunications.tmcnet.com] to abuse this.