It should be simple to get authentication working for an smtp server; in fact, it should just be a feature that works out of the box. Postfix though, requires you to use saslauthd, and configuring that program is a bit of a pain. Since saslauthd can’t deal with hashed passwords stored in a SQL DB, the easiest way to authenticate users is against an IMAP server; however, documentation for the rimap mechanism is lacking, and many of the config examples on the web are either wrong or out of date. The errors you get from those configurations are also extremely useful:
SASL LOGIN authentication failed: no mechanism available
SASL PLAIN authentication failed: no mechanism available
To fix the problem, you need to adjust the settings in the configuration files indicated below:
# Use a remote IMAP server as the auth mech
# IMAP server address. If you run on a nonstandard port,
# you can add a slash and the port, e.g.
# -r passes username@domain instead of username
# -m is set for a chrooted postfix and will have to be changed
# if you are using a non chrooted setup
OPTIONS="-c -r -m /var/spool/postfix/var/run/saslauthd"
/etc/sasl/smtpd.conf and /etc/postfix/sasl/smtpd.conf
# Enable this to get more info in the logs
# if you encounter problems
# log_level: 7
mech_list: PLAIN LOGIN
# Leave this commented out. It was what DID NOT work.
# auxprop_plugin: rimap
Assuming you haven’t already told Postfix to allow SASL authenticated senders to relay mail, do that now by adding the below to the beginning of the smtpd_sender_restrictions list in /etc/postfix/main.cf
Once those configuration changes are made, restart saslauthd annd postfix. Postfix should auth users against the IMAP server at the IP/port that you set, and allow those users to relay mail.
Launching MC in rxvt showed all the box drawing characters replaced with strange looking accented characters. It turns out that none of the Windows fonts support box drawing characters (from what I’ve read, it seems that they don’t have the characters in the expected positions in the character table). The easiest solution is to tell MC to use non box drawing characters to draw boxes with the -a switch. The other solution is to get the Lucida ConsoleP Font. (887), and set rxvt to use it (as suggested by this guide).
You can set the fonts used by rxvt with command line switches, or use a .XResources file in your Cygwin home directory (base file from here)):
rxvt.font: Lucida Console-14
rxvt.boldFont: Lucida Console-14
If you want to use the box drawing font (you have to install it on the system first):
rxvt.font: Lucida ConsoleP-14
rxvt.boldFont: Lucida ConsoleP-14
If you use the standard DOS terminal for Cygwin, you may want to change the code page setting in the batch file to:
As an administrator of several Source based game servers, I’ve dealt with various known security vulnerabilities that Valve hasn’t bothered to fix. Some of the most common include client side console commands, that if run once, or spammed (which the server will allow), will cause a degradation (massive lag) or denial of service (you guessed it, the server will crash). These really aren’t all that bad, since they are well known, server plugins are available to block the commands.
The most troubling incident I’ve dealt with involved an attacker who exploited a security vulnerability in Valve’s server query protocol, which caused a serious degradation of service condition. I couldn’t simply block all the query packets, since legitimate clients needed to be able to query servers. To further complicate matters, the attacker was also spoofing IP headers, which ruled out the possibility of a simple firewall rule.
This particular vulnerability was not really bad design per say (although it was poorly designed), but more a really poor implementation. Here are the details:
After needing a copy of MinGW to compile some C code, I was somewhat annoyed to find that their all in one installer is now considered “deprecated”. That meant I had to download and extract 15 packages manually, and that’s not all: two of them were compressed as .lzma files. Why anyone would compress a package designed for Windows in .lzma format? The only way to extract it is with a command line sdk tool. Even on Linux, distributing archives in .lzma format is a little strange.
Anyhow, to save everyone the trouble, here’s a package (includes C, C++ and all necessary tools) in .7z format (which can be extracted by 7-Zip, the best file archiver for Windows) -> MinGW Compiler Package (781).
After getting somewhat annoyed with the slowness of my blog, and having nothing better to do, I decided to setup eAccelerator. I’m pretty sure I tried setting it up a long time ago, but for some reason, didn’t finish.
Following the path of logic, I went to the eAccelerator website in search of the appropriate files. Their Windows section directed me to SiteBuddy, which had a nice collection of binaries for various PHP versions. After determining my PHP version (5.2.9-2), I tried the closest match (5.2.9), and was greeted by the following error in the Windows event log:
Unable to start eAccelerator module in Unknown on line 0.
My initial reaction to the error: what the ****… (UPDATE: See this post for more details) After a quick Google search, I found that PHP modules must be built for the EXACT PHP version you plan to use them on.
Since I have just about every Microsoft C++ compiler from the last ten years, I figured compiling a new eAccellerator module for my version of PHP would be simple. I downloaded the archived PHP files I needed (now I understand why they keep archives), switched to the release configuration, and pressed build.
If you come across a Python module that doesn’t have a Windows installer package available for it, and it’s packaged with distutils (almost every module is), you can make one by running:
If you look in the dist folder, you’ll find a nice Windows installer for the module. More information on distutils can be found here.
I compiled some of the modules that I use, that don’t offer a binary package for Win32 Py2.6. You can download them from here.
Compiling mysql-python shouldn’t have been too complicated, since distutils automates the compilation process, but there were two minor issues. This particular module needed the /MANIFEST linker option, and the windows setup script didn’t work properly. Here are the compiled binaries (MySQL-python-1.2.3c1.win32-py2.6.exe (740)), and the fixed setup_windows.py (mysql-python-setup_windows.py (803)), if you want to compile mysql-python yourself.
Loops are another “flow control” tool, like an if statement. Loops allow you to repeat the same piece of code multiple times, which can be very useful when you are processing data.
There are two types of loops in Python, the for loop, and the while loop. The for loop is one of the easiest ways to process data. Let’s take a look:
The documentation for setting up a web server for RoR (Ruby on Rails) on Windows is really lacking. Figuring out what server software you’re supposed to use is probably the hardest part. Should you use Apache or IIS as the web server? How are you going to connect it to Ruby? CGI, FastCGI, fcgid, Mongrel, mod_ruby, passenger (aka mod_rails / mod_rack) or WEBrick (not recommended for production use)?
If you pick a combination that doesn’t work properly on Windows, you can spend hours (as I did with mod_fcgid) trying to figure it out. The solution that worked for me was setting up Mongrel (which is a Ruby web server) as a service, and using Apache to proxy Ruby requests to Mongrel. Here’s a step by step tutorial:
I spent a really long time (8+ hours) setting up an open source project tracker called InDefero. I was also trying to setup Git at the same time, but that’s something for another post.
InDefero has no install wizard (one is in the works though), so all the configuration is manual. Installing the DB tables requires you to run a PHP CLI script. Everything was going smoothly until I tried to install the tables. The script exited with no output every time I ran it.
I tried to debug the script with echo statements, and traced to issue to a require statement that was causing execution to stop. After tinkering with several of the scripts, including the script in the require statement (the config file), and still having the install script fail, the thought occurred to me, why am I not getting any debug info from PHP?
Since the php.ini I was using was setup for production, display_errors was off. After turning it on with a CLI switch, I got a debug message. My config file was messed up. After going to the indicated line, I realized what happened.