I'm writing this up while it's still fresh in my head. Very fresh. As in: I have just lost two hours trying to resolve a problem I was having using Apache's
mod_rewrite within a WAMP stack. Oy.
Fundamentally, I'm not doing anything all that exciting: I have a local WAMP server with a virtual host that I'm using to serve a test copy of a Joomla site I'm working on. For this particular site, we are using Search Engine Friendly URLs. A server-side redirect is required to implement these URLs, which for WAMP means an
.htaccess file (although this could also be done in the Apache config file… Joomla ships with an
.htaccess file though).
I had just about completed spinning up a new instance of the local test site, and one of my final tests was to make sure SEF was working. Unfortunately, when I finally got around to adding a page that would exercise this feature I got a 404 in the browser. I double-checked the filename, checked for stray comments in
.htaccess, re-re-reviewed my virtual host block, etc. Nothing seemed out of whack.
After spending way too much time trying (unsuccessfully) to set some redirect logging, re-start
mod_rewrite, and fiddling around with the Apache config file, I finally stopped for a moment and took stock of the situation.
Oddly, the earlier instance of the site (which I'd left in place) was still working fine, including SEF. Everything was identical. I'm ripping my hair out at this point. How is it possible for two identical setups to behave differently under the same server?
The answer (of course) is that they were not identical.
As I was slowly pouring over files again in a desperate search for some clue, I realized that for the 2nd site instance, I hadn't created a WAMP 'alias'. I'm not exactly sure what these aliases are used for (since I always use a virtual host block along with a '.local' TLD), but in the past I've always created one (mostly so I can resolve local test sites over my LAN without DNS).
So, I updated the existing alias (for site 1) with the new root path for site 2. And just like that, redirection was working properly on site 2, complete with our lovely SEF URLs. Perhaps even more interestingly, site 1 redirects now no longer worked. After adding an new alias for test site 1, those redirects started working again.
If you're an expert sys admin or server geek, you're probably laughing and saying 'Of course they did!'. Or maybe not. I know a bit about this stuff, but I have to admit I'm baffled as to why the alias made such a difference. I suspect that I'm doing something in the alias that I could be doing in my virtual host block which would resolve this, but I'm not sure what. Perhaps when I have some time I'll do a bit more research on it—and if so I'll update this post.
I wanted to write this in part because it was incredibly hard to find any helpful results while searching related to this issue. So for the sake of future searchers, take care when using
.htaccess redirects under WAMP server, or you'll encounter some issues!
Also, what's with the title of this post? Well, many moons ago I was a Clogger. One of the tunes we used to dance to was If You're Gonna Play In Texas… and I guess it just stuck with me! I was young and impressionable!
I've just launched a minor site update with some styling tweaks and more. Hopefully this update will make the site easier to use on small-screen devices.
I also redid the color palette, and finished some styling that was previously in an interim state. This the first real attempt at a color scheme!
The site definitely seems to "pop" a bit more than it did before!
Hard to believe, but I've finally gotten around to setting up SPF and DKIM for my Mailserver. In the process, I managed to clean up a few other things too. If you haven't set up SPF/DKIM yet, it's probably worth it–but maybe do it smarter than I did.
For a few years I've been ignoring some issues with my Mailserver. I have a small-ish VPS that I run a few sites from–It's probably more or less your standard WHM/cPanel on Linux. I've been hosting sites for more than 10 years now, through a succession of VPSes. Over the years I've built up more than a few domain forwards, unused email addresses, and random debris. All of this added up to fair amount of noise in my system email and logs.
Thinking I was clever, about two years ago I switched the system email address to a Gmail one; I was thinking that I'd use the features to help sort and categorize mail, and benefit from Google's robust SPAM filtering. That last part is what eventually brought the whole thing to a standstill.
Initially it worked ok, but as time went on more and more of the mail I got consisted of failure messages: my server's message was rejected by Gmail (so it never reached the inbox). Oddly, or obviously, enough, the failure message itself did reach my inbox.
While that issue was unfolding, a similar thing was happening on the couple of forms that appeared within the handful of sites on my server. The problem forms were sending (via my server's SMTP) submissions to outside addresses at Gmail and elsewhere. Within the last couple months, they eventually were being rejected almost every time–to the point that there were user complaints. Bad Webmaster.
Start the Repairs
Having let things languish for a couple years, it was now time to fix things ASAP. I'd noticed that there was a link in each email for more information, so I followed it and read through the (brief) info there. I also checked out a couple of the links within that page, where I learned about the importance of SPF/DKIM. Google dings you without them.
Fair enough, so off I went trying to set it all up. As it turns out, WHM/cPanel makes it fairly easy to add SPF/DKIM to your DNS records. Easy is a relative term though; I don't really know anything about this stuff, so it took a bit of reading and trying things before it started working. It wasn't initially apparent that I only needed part of the generated DKIM string to go into my DNS record.
Adding the email authentication stuff had a more or less immediate impact on deliverability. There were still some failures, but these were essentially actual SPAM messages being routed through the system (did I mention Bad Webmaster).
While I was doing that, I also registered for the Google Postmaster Tools by adding some TXT records. Ultimately this account hasn't really helped me: my server just doesn't send enough email to matter. The dashboard in GPT is still completely empty after several weeks. Similarly, my server doesn't really have a 'low' reputation... it just doesn't have a reputation at all.
Fortunately, the server IP doesn't appear to be on any blacklists at this point.
Getting Squared Away
The SPF/DKIM stuff was a start, but this revealed another problem: my server was not being very smart about routing email. It was essentially blindly relaying messages without doing much vetting aside from asking if the recipient existed. This is dumb, since there are some apparently reasonable tools for dealing with these problems included in WHM/cPanel.
After setting up global SPAM filtering and email authentication, there was a huge drop in the number of messages being passed along. It appears as though most of the messages that fail the basic SPF/DKIM tests are simply rejected on receipt. This is good. At this point form-based messages appear to be getting delivered 100% of the time. This is great.
Upon experiencing this success, I did what anybody would do: I kept pushing things too far.
Go Ahead and Blow Things Up
Feeling very content with myself for achieving teh awesome, I decided I'd start fiddling around with more advanced options, and run some other security checks. Don't be like me. Or, do be like me, but go about it differently. Read through things a few times first before you go a-wacking on the server. I on the other hand just set an option that prevents
nobody from sending mail. Doesn't that sound like a good idea?
It is a good idea- but if you don't have your PHP configured right, then it's a bad idea. As soon as I made the change, the form failures started rolling in. PHP likes to send mail as
nobody, unless you're using suPHP, in which case it'll send as the account name (which remote email servers like better). I switched to using suPHP (heedless of the warnings), and succeeded in breaking entire sites. Turns out, when they say that you'll need to check owners and permissions, they actually mean it.
Any Minor World that Breaks Apart Falls Together Again
Long story short: when I finally got the owner/permission issues sorted out (and a little hack for a PHP weirdness), I finally had forms sending properly header-ed email with appropriate SPF/DKIM records.
A nice side-benefit of all this is that I was actually able to correct a bit of a problem I was having with posts in this very blog.
So, to recap, if you want to get your email server straightened out, you just need to have a little knowledge of the following:
- Encryption-based authentication
- The whims of Gmail
- How to maintain your cool when you dig a big hole for yourself
...and that's it!
I guess the moral of this story is if you're going to have a server, you have to take care of it. It's like a kid... er, pet.... er, houseplant?
I wanted to test how Flickr embeds look in here, so:
Mushroom Stand at SF Ferry Building
An early fall bounty of fungi. Pretty darn colorful.
Unfortunately, my wife doesn't like mushrooms. We did not bring any home.
So now, up and running, I have this mini-blog.
The very first post was originally written as HTML. I've since converted that post over to Markdown. In fact, I wrote the entire site in HTML first—including first copy drafts (I'll post about that later).
But in this post, I'm going to talk a bit about how I built this.
The idea was to make it simple. Save the posts as Markdown files. Read one or a few of those files out of a directory, and send them through a parser to output HTML. I hadn't even really thought through the authoring side of it, but that turned out fairly simple too. I don't need anything fancy, and I want to edit in Markdown, so I don't even need to parse in the edit case.
I did make it easier to post by making a very sparse form interface for creating/editing. I don't even have to fire up FTP when I just want to jot a few thoughts down.
So far, really impressed with the markdown parser I've chosen (which is Parsedown). I was able to extend it pretty easily to give special markup treatment for the post title and date. It added a small overhead of custom syntax, which I then concealed in the form interface so I don't even have to type the extra bits.
Writing down my thoughts in Markdown feels pretty natural, at least it does these days. That's probably because I've written a lot of internal documentation with it. If you don't bold or italicize things (or whatever), you can completely forget about marking things up and just write.
Still considering the possibility of some JSON-based index (or something), to facilitate (somewhat) easy content searching. I have a few other ideas that may be needed once I get a few dozen posts in, but fortunately I don't have that problem right now.
Also not so fond of the URLs for these posts; 'blogId=1' doesn't inspire much interest from Google. I suppose I oughta figure that out before I get too far, but my whole ambition here was to keep it simple. Maybe having headline-like URLs isn't that important anymore. My SEO skills are rusty.
But let's just wait and see how much I post…
If this works, it means I've officially entered the age of “blogging on-the-go”
This is my official kick-off post for the new site, in which I confront my age-old nemesis: regular blogging.
Over the years I’ve made several attempts to start blogging, but never managed to get very far. Maybe because I am often more interested in doing stuff than talking (or writing) about it.
As my skills have improved and my work has become more and more complex, I’ve found myself wanting to write about interesting (to me) things I find while working on stuff. Wanting to document quirks or confusions I’ve had for future reference.
I’m not sure how long this attempt will last, but we’ll never know unless we try. So in the interest of getting the ball rolling here’s the first post.
Why I’m implementing this blog simply
I’ve configured blogs in a few common ways (Wordpress, Blogger, ExpressionEngine), and even built custom themes a time or two. One thing that’s always struck me is the amount of stuff you need to make it all work. I’ve spent a bit of time trying to think about this, and I recently decided to try this out in a very simple way:
Just use Markdown on static files.
Ridiculous, right? Sometimes I get downright wacky.
The bottom line is that I just want a quick, simple way to type a few more characters than a tweet every so often. I think this approach could be a contender for that role.
Speaking of Twitter, I wonder if I could set it up so that it automatically Tweets a link when I make a new post...
To Be Continued