I've been working with a customer to upgrade his osCommerce installation.  The interesting points of the upgrade are that he has a highly customized installation, both in the template and code.  Subversion comes to the rescue for all of that.  And I got his source code checked in (had to first figure out what version he was running, since it turns out he originally installed 2.2ms1, and had partially upgraded to 2.2ms2-2005 and then partially upgraded to 2.2ms2-2006, so it was pretty confusing as to which files and database tables had already been upgraded.

I've written a couple procmail scripts over the years, and I thought I should publish them since it might help someone.

The following script goes in /etc/procmailrc which allows users to disable the spam check for whatever reason - perhaps they use a different program or otherwise don't need the spamassassin check. (see next script, where my virtual users use a different spamd, since the user doesn't actually exist, so I need to change the username in spamc, and call a different spamd which is listening on a different port than the default spamd)

:0fw
* ? /usr/bin/test ! -e $HOME/.no-spam-check
| /usr/bin/spamc --headers

I use this next script for my "virtual" users - I now do all email via virtual users (except for the folks who were around before this switch) as it makes e-mail management easier, via PostgreSQL scripts, and a custom PHP customer script that allows them to make their own modifications easily.

This script also supports the username+extension@domain syntax, which is handy for folks who don't have whole domain names to use for email/spam tracking.  My users have an infinite number of email addresses which can be "created" by simply telling someone that their email address is john.doe+spammer@mydomain.com. If the user then creates a folder named "spammer", the mail will be delivered into that folder, and if the folder isn't created, this script will put the mail in the main inbox, and the user could filter it on the client-side using the X-Original-To: header.

##############################
## rename arguments into nice names
## strip out slashes and periods in the extension to avoid
## mis-writing stuff to other directories (like ../../../.procmailrc)
domain=$1
username=$2
extension=$3
extension=`echo "$extension" | sed -e 's/[\/.]/_/g'`

# strange formats, probably errors in the postfix database
:0
*$ ${domain:+!}
! vmail+$domain+$username+$extension+nodomain@xxxx.com
:0
*$ ${username:+!}
! vmail+$domain+$username+$extension+nousername@xxxx.com
# we disabled default spam checking with .no-spam-check
# so now we run it using the virtual spamd
#
# 02/04/2008, added --timeout=100, we are getting some cases
# where the procmail script is taking 1001 seconds to run,
# and postfix bounces the message...
:0fw
* ? /usr/bin/test -d $MAILDIR/$domain/$username
| /usr/bin/spamc --timeout=100 --port=784 --headers --username=$username@$domain

# chuck definitely known spam
:0 h
* ^X-Spam-Level: \*\*\*\*\*\*\*\*\*
/dev/null
# deliver to /home/vmail/mail/{domain}/{user}/mail/{extension}
# if they previously created the folder
:0:
*$ ! ${extension:+!}
* ? /usr/bin/test -e $MAILDIR/$domain/$username/mail/$extension
$domain/$username/mail/$extension

# deliver to /home/vmail/mail/{domain}/{user}/mail/mail
# if the directory exists.  if it doesn't, it is an error
:0:
* ? /usr/bin/test -d $MAILDIR/$domain/$username/mail
$domain/$username/mail/mail

# shouldn't ever get here unless there is a missing directory
:0
! vmail+$domain+$username+$extension+missing-dir@xxxx.com

Some spam blocking scripts:

# spammers like forging mail from @daley.snurgle.org
# and I no longer send mail using this address, so anyone
# who says they received mail from this address got spammed,
# and has a poor ISP which bounced the spam to a person who didn't send it.
:0
* ^X-Original-To: [^@]+@daley.snurgle.org
* ^Subject: .*(deliver|failure|returned|autoreply|challenge|blocked)
/dev/null

An old address that Eversave sold to spammers

:0
* ^TO_eversave@jondaley.cjb.net
/dev/null

I did some work for a client who was having high CPU load issues with their tiny (20 posts, no comments) Wordpress installation.

They already had the super-cache plugin installed (I think that should be shipped by default in wordpress), but the super-cache plugin (as of version 0.9.6.1) doesn't cache RSS feeds, so for each of the ~5000 viewers of the RSS feed, the feed is regenerated each time, causing this tiny site to be the largest CPU usage of all sites on this particular shared server.

It turns out that this is a known problem, so hopefully it will be fixed in later releases of the plugin. Especially since I am asked to fix this for different clients at different times, and I have to relearn how to fix it each time, because I can't keep it in my head...

The changes I made were:

modified wp-cache-phase2.php, line 36:

if ( $wp_cache_not_logged_in && is_user_logged_in() /*&& !is_feed()*/ && !is_admin() ) {

modified wp-cache-phase2.php, line 270:

if( !empty( $_GET ) || /*is_feed() ||*/ ( $super_cache_enabled == true && is_dir( substr( $supercachedir, 0, -1 ) . '.disabled' ) ) )

added to wp-cache-phase2.php, on line 364:

if (is_feed()) {
  $type = get_query_var('feed');
  $type = str_replace('/','',$type);
  switch ($type) {
    case 'atom':
      $mediaType = "application/atom+xml";
      break;
    case 'rdf':
      $mediaType = "application/rdf+xml";
      break;
    case 'rss':
    case 'rss2':
    default:
      $mediaType = "application/rss+xml";
  }
  $htaccess = @fopen ("{$dir}.htaccess", 'w');
  if ($htaccess) {
    fputs($htaccess, "<Files *.html>\n ForceType $mediaType\n</Files>\n");
    fputs($htaccess, "<Files *.gz>\n ForceType $mediaType\n</Files>\n");
    fclose($htaccess);
  }
}

added to .htaccess,top of file

RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_URI} ^/$
RewriteCond %{QUERY_STRING} ^feed=rss2?$
RewriteRule ^.*  /feed/?   [R,L]
RewriteRule ^feed$  /feed/   [R,L]

The code now traps /?feed=rss, /?feed=rss2, /feed and redirects them to /feed/ which is now cached appropriately by super-cache.

The changes/additions I made to Michael's fixes:

1. compressed feeds (.gz extension) work
2. the client's server required ForceType rather than AddType
3. I also wanted the "extra" feed URLs captured, so apache would handle the static files, rather than forcing Wordpress to dynamically redirect them

Lime Daley often acquires new customers when they leave a previous provider who either doesn't provide support, or the support that is provided consists of mostly trying to figure out what language they are speaking.   The person doesn't want to have to know technical details of why their site is getting the infamous 503 Internal Server Error, nor why their emails sometimes take 15 or 30 minutes to be delivered, and they are attracted to Lime Daley because they know they will get an engineer on the phone immediately, and problems are taken care of without hassle.

In addition to hosting phone services for other people, I also host my own phone numbers (personal and business).  I prefer to not have different phones for each line, but I like any phone to be used for either number at any given time.  I haven't gotten around to setting up distinctive ringing for the different lines, but instead, our home computer audibly announces the caller's name and number, and, for the business calls, which menu choice they made.

Some of my customers have a hard time creating the space-efficient .gsm files for their voice menus, so I created a simple extension where they can call up the Asterisk server, and record the menu as they want it, and then it can be placed into their dialplan.  (The number of voice menus that are created are small enough so I haven't gotten around to making the system more robust, where it would automatically move the file into a customer accessible place (and keep track of which customer recorded which menu).

There are a number of tutorials for people trying to setup blacklisting for their Asterisk server, but they all seem to assume that there is only one user on the server, or at least all users want to share the same blacklist.

Since I host for multiple, unrelated people, they don't necessarily want to share the same blacklist, so I had to come up with a configuration that would work for all customers.

I've not been happy with any of the choices that are available for content management, but lately I've been warming to Drupal. Each system has its downfalls, and upgrades seem to be pretty bad on all of the ones I've used extensively (webgui, drupal, joomla).

After spending hours trying to get the HAL/FDI method to work, I resorted to modifying the xorg.conf directly, though I was able to only add a couple lines, since my current xorg.conf is basically empty, with everything being auto-detected.

The main difference that I wanted (from lots of other posted information) was that I liked the fdi method of configuring things (xorg.conf has always been a scary file to play with) and so I didn't want to have to hard-code everything, which means, as far as I could figure out, to not have a ServerLayout section at all since once I added that to get the touchpad to work properly, it broke everything else.

Some people have been talking about whether they think in blogging, as in: "this is so much fun, I should blog about it", or, "look how cute the kids are being, I should grab a camera so I can post it on flickr", etc.

I didn't particularly relate to that, but this morning I re-discovered a cipher book I liked as a kid, and thought it would be fun to go through some of it.  And then thought, I could write a script to do this for me, and then, maybe I should blog about that. hrm....