While designing a new deployment system for my company with Amazon’s AWS, I
stumbled onto a problem that cost me some time - I could not get my EC2
instances to connect to our Amazon RDS database servers. I figured I’d
document the solution here for the sake of those to follow.
I had created two webservers, and a MultiAZ instance of an RDS server with
which they were to transact. I could connect to each webserver and the RDS
server directly, but I could not get the webservers to connect to the RDS. The
issue ultimately ended up being related to my security groups configuration.
Earlier this week, my trusty Toshiba Satellite died after five years of
faithful service. I decided to go with the new Samsung Series 9 Laptop as
its successor, with the intention of configuring the system to dual-boot into
Ubuntu and Windows 7. I encountered a few brutal gotchas during the
installation process, so I figured I’d document them here. (To the best of my
Googling, there’s not a lot of information out there on the net as of today.)
What follows is what I believe to be the shortest path to a clean installation.
It is not the path that I took. Therefore, if you find that anything
does not work as described, please let me know.
I like Wordpress a lot. It’s one of my favorite open-source projects, and I use
it often for both my professional and personal projects. It’s been my go-to web
development framework for a number of years now.
There’s one thing I don’t like about Wordpress, though: the domain to which a
Wordpress site is deployed is saved as a setting in its database. I don’t think
that was a good design decision, because it makes it painful to move a
Wordpress site from one domain to another. This shortcoming is especially
evident if you’re trying to develop a Wordpress site on one domain, but would
like to deploy to another. (For example, I always set up my local sandbox such
that the WIP lives at example.dev, while deployments are pushed to
example.com). I really wish Wordpress had been designed to path against its
own document root, much like MediaWiki (another great piece of web software).
A while ago, though, I came up with a little hack to make Wordpress do exactly
that.
If you who haven’t heard of it, Tin Eye is an image search engine with a
unique twist. While most image search engines (like Google Image search)
allow you to search for images based off of textual search criteria, TinEye
allows you to search for images that are similar to other images. The
service works by allowing a user to upload an image file to TinEye. Images
that are “similar to” the uploaded image are returned in the search results.
(The ways in which the images are “similar”, of course, is up to the TinEye
algorithm, but in my opinion/experience, its groupings make sense to me as a
human.)
TinEye is thus a great resource for finding images in a series, or for finding
different variations upon a specific image. Looking for a higher quality
version of a low-res pic? Try TinEye. Curious where your favorite wallpaper
came from originally? Try TinEye. Looking for the same without Longcat
‘shopped into it? TinEye.
I believe, however, that this unique functionality has some interesting
security implications. I propose that, as TinEye is given more and more time
to index the web, it may open up new attack vectors on personal privacy.
TinyURL is a service that transforms long, inconvenient URLs (like
http://www.the-medium-and-the-messenger.com) into short, convenient ones
(like http://tinyurl.com/yb6p4oz). Services like TinyURL are frequently used
when posting links into Twitter, where character space is at a premium.
Like so many other web technologies, though, TinyURL can be abused for
nefarious purposes. Specifically, it can be used for disguising payloads used
in Cross-Site Scripting (XSS) attacks.