A few days ago I got what, according to spamassassin, is a particularly stellar example of spam. The measure by which all other spam in my spambox shall be judged. Until it gets beaten, anyway.

I do have custom spamassassin rules, but this wasn't scored with any of them, or using any ones I modified. Seeing this took me on a quest to find other high scores and I couldn't find anything in the sixties, or anything higher that didn't use modified rules or scores - not that that's bad.

I don't imagine this is the worst I'll get, especially as I add my own custom weights. But this made me feel special for some unfathomable reason. Who can attract the highest spam score? I'll leave my e-mail addresses in plain text here to find out!

I would not advise going to the site in question in the e-mail, obviously.

A well-tuned my.cnf file can be the difference between a nicely purring database server and one that is crawling like frozen molasses. I present an annotated version of my own my.cnf file here for those interested in specific tuning suggestions for that file.

Do not blindly copy this code block into your my.cnf file - you need to set the path names appropriately for your needs, and in many cases, the default is just fine. On the other hand, I have divided my I/O load between two disk arrays, so I've changed the defaults some.

In this article we will be going over a higher level view of MySQL optimization - InnoDB versus MyISAM, whether or not you should use the Query Cache, and the new InnoDB Barracuda file format. We discuss what to use and when, which is important for tuning your own my.cnf configuration.

This article is for database server administrators or those who plan on being one soon, who want to have an efficient setup for serving database requests. This article primarily focuses on disk arrangement, partitioning, mounting, and making HugePages available to MySQL - in essence, setting up the server to run MySQL efficiently.

my.cnf configuration will be discussed in the next two articles, which will be more valuable to a wider class of users. VPS users should mostly focus on the tmpfs portion of this article, below, as they can safely make use of that. Some VPSes can also use HugePages, so if you can take advantage of them, do so.

Some time back, I came to a few not-terribly surprising conclusions.

1) Security information gets dated, fast. As attackers become aware of a given tool, they work to circumvent it. What is a secure, safe practice one year may actually be a security hazard later on. This bad advice tends to get 'stuck' on the Internet, made even worse by the fact that Google still gives immense weight to stale - but highly linked - articles.

2) Security advice is often completely unusable. One example of unusable security is 'use a different password for every website, alphanumeric plus symbols and mixed case, write nothing down and never use a password manager'. Security advice you are forced to ignore is horrible advice.

3) Security advice can also seem like a massive checklist, rather than a way of thinking. At best, your eyes glaze over, and you ignore pieces of it or make a mistake. At worst, you spend hours ticking off each item, and then consider yourself safe.

Security procedures need to be usable, reasonable, and practical. It needs to be something that you will not only get a definite benefit from, but also advice you are willing and able to follow. This series of blog posts will focus on providing advice that you can actually use, rather than some impossible checklist.

As the title suggests, this first article will cover passwords.

I happen to have what I think is a pretty ideal multi-site Drupal setup.

A rather annoying problem with Drupal's typical multisite support is that if you are handing sites to various users, they're all running under the same Drupal user, and if one of them wants file or php access, you put each of them at risk for the desires or needs of one single person. This is far from ideal - we want to keep the users separate while retaining the flexibility to give everyone full access to their directory structure.

So, Elliquiy's Ajax Chat finally got the better of it, size wise, and nearly brought down the server while I watched. You might ask why I'm running what amounts to IRC on the web and I will probably respond to that in some future article. E's silliness is beside the point, here.

I've been discussing server specifications with my webhost, going over hard drives, RAID configurations, and so on, eventually expressing a desire for a battery-backed cache unit and asking about RAID 6.

High Performance Communities: Choosing a Software Stack

So, your forum needs a new home. You buy a cheap dedicated server with a few frills - RAID 1 keeps you warm at night - and plan to setup shop. If you went the way of the VPS world, you might be more familiar with one form of server or another, but all that does is push the decision earlier. You need a server, you need it soon, and you need to know what it's going to run.

Although it might not seem obvious at first, moving to a dedicated server for most sites actually involves a reduction in peak capacity. Quality web hosts usually host their sites on high-end servers - eight or more cores, triply mirrored RAID 10 arrays, and high quality monitoring, redundant power supplies and so on. Your first dedicated server is hardly going to be so lavish - you are paying for consistency and freedom. Thus, it can make sense to stick with virtual private servers (VPSes) and high end shared hosting for a time.

This article is the first in a series for community owners who have outgrown a VPS or a larger shared hosting environment, and need their own server to handle similar load levels without running into bottlenecks, but want advice about what they need, from someone who has been there. Since both of my major communities are adult, I created this site in part to serve as a decidedly non-adult repository for presenting what I have learned.

For my own experience, I run two of the most active communities on the Internet - Elliquiy Adult Roleplaying Forums and the Blue Moon Sexual Role Playing Forum. The splash page of each forum does not involve anything racy, but the images and text inside of said forums might not be so gentle on the pure of mind - be forewarned.

As you take up more and more of your host's resources on a machine - whether high-end VPS or high-end shared - you are going to consume more and more of its I/O bandwidth. On a good host, this will typically be higher than what your first dedicated server would be - however, you are at the mercy of everyone else on the machine. And you will notice, repeatedly. When you or your host get fed up with this, it's time to move to a dedicated machine.

It always gets me a bit - naming your website after your own name or common handle. In this case though, it sort of makes sense.

Since the welcome page is apt to change over time, I will go over my goals for this site here.

First and foremost, I want to put my technical articles here - about securing Windows, optimizing Debian, hacking Simple Machines Forum, whatever. In addition to being an adult forum, Elliquiy is rather large, and placing it there only makes it all the more intimidating if people ever come to Elliquiy for that sort of thing.