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.

The article is on the wiki, check it out if you have a minute and see what you think.

Ampache is basically a webservice that will remotely serve up the media on your mediacenter. This is a fundamental component of my long-term plans for world domination (or rather world subterfugation). You can play your music (yes, ALL of your music) through a browser once you have ampache set up. It’s a typical LAMP setup and takes about 10 seconds if you’re familiar with LAMP.

The “nice” linux client is supposed to be Amarok. Now, I am grateful that a nice client exists. And Ampache is the best thing since the best thing since sliced bread. But when developers don’t follow the Good Rules and intentionally create difficult installation situations for everyone, it really pisses me off. Here’s a quick cheatsheet to get you (me) through the bullshit:

• Edit [/etc/mysql/my.cnf]

# Comment out this line so that mysql allows connections other than from localhost (ie so you can connect from your LAN).
# I DO NOT appreciate having to do this and you should make sure you follow up with solid firewall rules.
# But Amarok wants direct access to your LAN's db server, so there you have it.
#bind-address				= 127.0.0.1

• Set up a mysql amarok user and database in standard mysql fashion.  Make sure the user has full remote access (not just from localhost).
• Now run ampache. This is just weird, but just do it. Ampache starts off fine for web acccess but to allow clients like Amarok to connect you have to add some ACL bullshit – it starts off totally locked down and disabled. Ampache->log in as admin->Admin tab->Show ACL’s->Add API/RPC Host->Add an entry. Use any name you want, make sure you pick RPC + ALL, and put in a start/end that matches your LAN IP range. Click Create ACL and three weird entries will be created for you. WHATEVER.
• Start amarok for the first time. It will fail because you don’t have a database set up yet. Settings->Configure Amarok->Database->Fill it out! It should work now that you opened up mysql in the first step. Then you’ll have to shut it down and restart.
• With a little luck you’ll finally be able to play some music.

I have been fighting with MythTV, trying to get it to play my videos for over a month. I have played with my MythTV compilation settings, tried turning off OpenGL, changing the video profile to “Slim”, recompiling my ATI video drivers, and messing with my X configuration. I finally solved it by deleting the installation and reinstalling:

su -
rm /usr/lib64/libmyth*
rm /usr/bin/myth*
(reinstall mythtv)

This messy post brought to you by the iPhone’s Dragon NaturallySpeaking app thank you very much…

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…