I have been so happy with my gentoo boxes lately, having had zero problems for the past few months, and no itch to bump. I must have lucked out and hit a really stable spot in the ever-changing world of open source.

But I don’t want to get too comfortable. Much longer and I probably won’t have a clean upgrade path. Besides, I think I smell something shiny out there somewhere… Seriously, I am looking forward to the latest XBMC changes. That software absolutely rocks.

Here we go! (continued…)

Google implemented my results preview concept. You’ll start seeing integrated previews now in your google results – they did a great job! It’s nice to be validated, and frankly, nice to have the monkey off my back as far as trying to repeatedly resurrect Google Results Walker. Re-engineering someone else’s web site is fun as hell, until you’ve over-committed, and then the original website exits stage left on you and invalidates all your work.

It sure was a fun ride while it lasted – 50,000 downloads in its heyday, when I was knee-deep in the Mozilla Add-ons developer community. That’s the most successful software I’ve ever written, in terms of users. Coupled with the joy of a completely cross-platform solution!

So to sum up, thanks Google for improving your search in exactly the way I thought needed it to be done. :>

I love my websites and servers and applications. I expose a lot of my toys on the internet, because it’s FUN and USEFUL. I try to apply the 80/20 rule in getting things done, doing 20% of the security I should to achieve an 80% benefit. I don’t have time to “do it right”, if that’s even possible. I know this is a terrible approach to network security, but it is my conscious choice. There is fun to be had.

The approach burns me on occassion, but I get by. I’ve been hacked twice in 10 years, not a bad record considering my approach. The second hack occurred recently. Some poor bastard in backwoods Russia or God-knows-where has been scanning and hacking WordPress sites with a backdoor approach to adding admin accounts. Once the admin account is set up, they inject redirection scripts into the php template code.

I have not taken the time to install all the WordPress updates the moment they come out – classic example of my slacker approach to security. So at some point in time, I got hacked. The sad part is that I did not even notice it until much later, when Firefox’s automatic malware detection kicked in and Google and StopBadware.org started denying me access to my own site.

Apparently the injected code had the capacity to install malware – not that I would know, being a linux user. The cleanup involved purging all the injected php code, which was obfuscated with “eval(base64)” wrappers, and removing the hacked WordPress admin accounts.

The fact that I was potentially adding malware to the computers of people visiting my websites is enough to make me physically ill. Some of that paranoia and obsession required to achieve a moderate level of security has surfaced. My WordPress and Mediawiki sites are too rich and chock full of functionality for me to personally do any real level of guarantee of security – I have to rely on the popularity of their code base and assume issues get caught quickly. But the least I can do is upgrade them whenever a new stable release is available. Generally speaking, this is what keeps me on the internet, and it is no longer an optional activity.

The only other flaw in my setup of which I am painfully aware is due to virtual hosting restrictions. I do a LOT with my one little IP and my one little server (including truly free truly legit SSL), but I cannot host more than one SSL virtual site on port 443. Just “the way things are”. I need to be diligent about redirecting secure traffic through the one configured SSL domain. But this is never easy.

The silver lining: the WordPress iPhone app now works! The pace of blogging should now improve from glacial to very infrequently. :>

Peace out.

This toolkit was written by a guy down the road over in Chapel Hill, it seems. The idea seems to be to generate and configure MVC-structured PHP code with RESTful web access. Supports multiple apps with one installation. Works for me.

I grabbed the 0.20 release. It comes with a web-based front end that will mock up your initial application code. Unfortunately the javascript wasn’t working and it looked like it had a bad path to the embedded jquery library. Rather than kill myself researching, I switched to the git “edge” branch:

cd development/git
git clone http://github.com/recess/recess.git
  Initialized empty Git repository in /home/m/development/git/recess/.git/
git checkout master 
  Already on 'master'

Now it seems to be able to find its css and javascript.

Next problem was with mod_rewrite. It just wouldn’t work. Time to troubleshoot… and fixed. In Recess’ defense, this was probably the reason the 0.20 release didn’t work well.

Next, I went to create an app. I had to change the permissions on the apps directory, as instructed, since I unzipped recess under a group for which apache did not have write access.

Next, I cranked through a model for one of my apps. WOW, now I have a full set of “routes”, URL’s with which to RESTfully access my model. This is looking nice… to be continued…

mod_rewrite is essential if you’re going to write RESTful web services. Here are the steps I went through to troubleshoot my installation:

1. Ensure you included mod_rewrite in your apache installation. For gentoo, you can use [eix www-servers/apache] – Gentoo’s apache2_modules_rewrite flag is enabled for apache, looks good.
2. Test to see if it is being loaded. I created a dummy page phpinfo.php with the contents [<?php phpinfo(); ?>], to see what PHP had to say about it. Search for mod_rewrite – yep, there it is, good. If not, make sure it’s loaded in httpd.conf, the load line may be commented out.
3. Now make sure it’s enabled for the path you’re using. The apache directive is [RewriteEngine On], and it has to be somewhere in your httpd.conf or an included file. In my case I use virtual hosts. According to Apache docs, I needed to add both of these to the top level of my virtual host directive:

   RewriteEngine On
   RewriteOptions Inherit

4. The mod_rewrite rules I’m dealing with are all in .htaccess files. In that case you have to make sure you’ve turned on the switch that allows .htaccess files to override your settings. Basically, you’ll need [AllowOverride All] enabled for the path where you want to use .htaccess files.
5. Finally, make sure your .htaccess settings and rules look good. Here’s an example I pulled from another good troubleshooting blog entry:

   cat .htaccess
    Options +FollowSymLinks
    RewriteEngine On
    RewriteRule ^alice.html$ bob.html
    RewriteRule ^bob.html$ alice.html

   It should force bob’s page to load when you request alice’s, and vice versa. Nice simple little test.

Once I went through this list, I was good to go.