Processing Deferred Messages in Postfix

For anyone who's had to cleanup some mail problems with Postfix configuration (or more often with other things, like anti-spam, tied in but not part of postfix), it may be common enough that a large spool of mail gets queued up and needs to be pushed out. The easy way to do this is to do either "postfix flush" or "postqueue -f" which basically force Postfix to re-process pending messages (actually "deferred" usually) and send them out.

However, if either the queue is huge, or you don't really know if you have your problems resolved and want to try a few messages before unleashing the masses, I found it was not clear how this can be done. There is a straight-forward way to do this which is to put everything on hold using "postsuper -h ALL deferred", and then un-hold whichever messages you do want processed with "postsuper -H ".

Tres handy

Let's FUSE him with this juice!

Back in the olden days, like a year or two ago, Filesystem in Userspace (FUSE) was a fancy feature that allows users to mount file systems. Using FUSE means that you can create a file system driven by an application rather than a driver (e.g. a kernel module). When I first tried it, it meant customizing your kernel to include this feature and building a bunch of utilities and drivers and generally it was awesome, but not something one does for a "quick fix".

Fast forward to a few months later (or aeons in OSS terms) and there's standard kernels and packages to operate FUSE. You can pull everything you need from your distro's stock repository.

In particular, there is sshfs which is hella tight. "sshfs" is, as you might guess, a file system over SSH, e.g. in FUSE. This means the security and features of SSH including SSH keys and all that good fun. Installing "sshfs" and FUSE is a simple three step process:

1. yum install sshfs (or aptitude install sshfs for Debian / Ubuntu users)


2. ?


3. Profit!

Similarly, once you've installed "sshfs", using it is a simple three step process:

1. sshfs myhost.example.com:/some/remote/path /some/local/path


2. ?


3. Profit!

What could be simpler? If you're finding your virtual file system access in Gnome or KDE produces odd behaviour sometimes, just FUSE your remote file system instead. You get fully functional and secure access to remote file systems.

Oh, and just one last note, you use a FUSE command to disconnect the mount:

fusermount -u /some/local/path

Thanks, Toddz for mentioning FUSE the other day and getting me to revisit it.

Ciao,
- Arch

(title for this post nicked from an Invader Zim quote)

Crappy Power

I've had some problems in the somewhat recent past where my UPS goes into panic mode and because the battery was old / crappy, this made things "very bad". I've had no issues since replacing the battery, but now I'm getting a picture of why it was so awful from apcupsd:

Mon Aug 31 11:13:36 PDT 2009  Power is back. UPS running on mains.
Mon Aug 31 11:13:34 PDT 2009  Power failure.
Thu Aug 27 11:20:20 PDT 2009  Power is back. UPS running on mains.
Thu Aug 27 11:20:18 PDT 2009  Power failure.
Sat Aug 22 16:59:32 PDT 2009  Power is back. UPS running on mains.
Sat Aug 22 16:59:29 PDT 2009  Power failure.
Sat Aug 22 16:56:29 PDT 2009  Power is back. UPS running on mains.
Sat Aug 22 16:56:27 PDT 2009  Power failure.
Fri Aug 21 00:12:33 PDT 2009  Power is back. UPS running on mains.
Fri Aug 21 00:12:31 PDT 2009  Power failure.
Fri Aug 21 00:11:52 PDT 2009  Power is back. UPS running on mains.
Fri Aug 21 00:11:50 PDT 2009  Power failure.
... etc

There are a lot of power events going on. Given that the time of the "power failure" is always 2 seconds, my guess is that this just means power is fluctuating. I've lived in places where this happened a bit and where it happened not at all, but this is the worst I've seen.

The only thing I can say is: get a UPS if you don't have one! You may not need battery backup per se, but this is the kind of stuff that will send the power supply unit in your PC to an early grave. And if you're unlucky, the PSU may just take other components of your PC with it.

- Archangel

Rolling dice in Bash

I often need short random numbers at work. For example, if I'm scheduling a whole bunch of servers to do the same automated tasks and I want them to not run at exactly the same time, I'll use a random number between 1 and 60 to have them run on different minutes. You can do this somewhat easily in bash using the $RANDOM variable and a mod operation like so:

echo $((RANDOM%60))

However, it's a bit long to type and sometimes I need batches of numbers. So I looked around at dice rolling programs but most were too fancy. So I wrote a simple simple script I called "roll" which returns sets of random numbers.

#!/bin/bash

# Roll
#   This script returns the values and sum of a set of dice rolls.  The first 
#   arg is optional and gives a number of dice.  The second arg is the number 
#   of sides on the dice.  For example "roll 2 6" will give two values from 1 
#   to 6 and also returns their sum.
#
# (c)2009 Dominic Lepiane 

sides=6
dice=1
total=0
c=0

if [ $# = 2 ] ; then
        dice=$1
        sides=$2
elif [ $# = 1 ] ; then
        sides=$1
else
        echo "Usage: $0 [# of dice] <# of sides>" >&2
        exit -1
fi

#echo "Rolling {$dice}d{$sides}"

while [ $c -lt $dice ] ; do
        c=$((c+1))
        roll=$((RANDOM%sides + 1))
        total=$((total+roll))
        echo -n "$roll "
done

if [ $dice -gt 1 ] ; then
        echo -n " = $total"
fi

echo ""

So if I want 12 numbers from 1 to 60, it looks like this:

./roll 12 60
21 32 30 38 56 36 27 19 25 34 25 48  = 391

Very handy!

VMware and Unity

I've been running Fedora 11 (x64) on my workstation at work and running Windows XP (32b) in a VMware virtual machine. It was a VM I'd created with server so all I needed to run it was the free VMware Player.

First, installing VMware Player was a bit of a problem. The install from RPM didn't work, it hosed initially. Then the install from the bundle also failed... Much like it does for many users Online it turned out so there was a community-created patch which worked just fine.

Then there was running the VM. Initially, it seemed great. I was running Windows XP full-screen on my right-screen and had my Fedora desktop / apps on my left screen. But it was pretty wonky about mouse control so I got to the point where I was firing up the Windows VM only when I needed it and then not in full-screen mode.

But I discovered that VMware's Unity mode helps bridge the gap. It pulls you out of console mode and launches any apps from the guest VM in their own windows in your desktop environment. This is especially useful for say, running MSIE or MS Outlook. It's still a little weird because the apps *look* like they should be running natively yet the responsiveness is clearly far behind local apps, but the only real gap is that I can't Shift+Right-Click -> Run As... on tools like Active Directory Users and Computers (which I need). I tried switch back to the console, doing the Run As... and then switching back to Unity, but the escalated app doesn't show up.

Well, it's great and closes the gap some, but for now I'll just keep updating Player and Tools and see if eventually that full-screen mode just gets fixed and works transparently.

- Arch

SpamAssassin

On previous mail server setups, I've tried to pass all mail coming into the server through SpamAssassin (The Fight Against Spam) and it's a bit of a struggle to get it working sometimes so I've had nothing setup for a while other than some SMTP restrictions and a couple of the RBLs. So since SpamAssassin is generally geared to being run / configured per-user, I figured, what the hell, I'll try that. And it is way easier. All I did was plop this in my .procmailrc:

# SpamAssassin
:0fw: spamassassin.lock
| /usr/bin/spamassassin

:0:
* ^X-Spam-Status: Yes
Junk

So now, SA happily tags all my possibly spammy mail and then for actual spam, it dumps it in the Junk folder and it actually strips the content replacing it with all the reasons why the message was identified as spam (the original message is attached).

So far so good!

- Arch

Using proc to force a reboot

So we just had this little discussion on IRC and I figured I'd save it for posterity here:

[11:37:36]  to force a 'hard' reboot (if reboot is not working) - equivalent to pulling the power cable:
[11:37:44]  echo 1 > /proc/sys/kernel/sysrq; echo b > /proc/sysrq-trigger
[11:40:45]  come on dom, you know you want to try it.
[11:41:21]  heh
[11:42:29]  what's this do?  what's this do?  what's it do???
[11:43:13]  you tell us
[11:47:09]  yeah, that's awesome
[11:47:24]  it just tells BIOS to reboot
[11:47:35]  (or something like that anyhow)
[11:47:58]  so, immediate reboot in other words?
[11:47:58]  system just goes *blip* and starts posting

So there you go. Want to reboot without waiting for all those nasty processes to finish or phyiscally pressing the power button? That's your way out.

Thanks, toddz :D

- Arch