This is an old post. It may contain broken links and outdated information.
Brandon Mathis, the creator and maintainer of Octopress, recently tweeted a method to programmatically create tweets from new Octopress blog posts. Moments after that, he retweeted a reponse from another Octopress user which outlined a simpler method using ifttt.com, a web site which lets you create automated actions based on conditions.
The site’s name is pronounced like “lift” but without the “l”, as it they proclaim on their homepage. The awkward construction comes from “if this then that”, which describes the web site’s purpose: if a thing happens, then do something.
This is an old post. It may contain broken links and outdated information.
A few years ago I created a web site called the Chronicles of George, featuring some badly-written help desk tickets from the job I had at the time. It gained me some small amount of Internet fame (but no fortune), and developed a loyal community of sympathizers. For a long time we hung out on a self-hosted phpbb forum, but a change in web hosting led to the opportunity to also change the forum software away from something as hack-prone and complex as phpbb to something faster, simpler, and ostensibly more secure: Vanilla.
Out of the box, Vanilla operates a bit differently from a traditional thread-based forum like phpbb. It is a discussion-focused forum, deprioritizing standard categorical organization in favor of bringing the things being talked about to the forefront. This has advantages in some forum models, like a support forum for a specific product or service, where the first thing a reader wants to see is discussion, not a choice of categories, but it’s not necessarily what most folks are used to seeing out of a web forum. Fortunately, Vanilla also offers configuration options to make it behave more like a “standard” web forum.
Why choose it, then, if we’re just going to override its most distinguishing characteristic? Because, as mentioned in the opening paragraph, it’s light and fast and secure. Additionally, the 2.1 branch (currently under development and downloadable here) comes with an absolutely killer theme that we can easily customize and prettify with some quick CSS.
This is an old post. It may contain broken links and outdated information.
Wordpress is the Microsoft Word of blogging platforms—it’s overkill for almost everyone, but everyone uses it anyway. It’s a popular, monstrous, ugly app that requires regular patching to keep evildoers from doing evil with it, but it’s still a top choice for self-hosted blogging because if you can fight your way through its ridiculously complex interface, you can use it to make a good-looking blog without having to know a lot about HTML or CSS.
Our blogging platform here at the Bigdino compoud is obviously Octopress—which you’re reading right now—but I had occasion to stand up a Wordpress blog recently and wanted to share what I learned doing it. Wordpress’s ubiquity means that there are a million-billion-trillion guides out there for getting it working; however, the vast majority of them focus on how to make it work with Apache, not Nginx. What I hope differentiates this post is that I’m going to focus on taking common .htaccess-based security practices and turning them into Nginx-specific location directives and rules.
I host a small Minecraft server with maybe a couple dozen players total, and for the past several months we’ve been using a wiki to catalog our achievements. I started with DokuWiki, a flat-file wiki, because I was reluctant to weigh down a webserver with a database just to host a small wiki, but now that Bigdinosaur.org is hosting some … Read more
This is an old post. It may contain broken links and outdated information.
In the previous post, I discussed one possible method of keeping undesirables from connecting to your server via ssh: using the DenyHosts TCP wrapper to watch authentication attempts and block remote hosts based on conditions you set. DenyHosts (and other TCP wrappers) are easy to set up and don’t require much maintenance, but the block list files they generate can grow to a not-insignificant size; further, your web server must spend resources matching incoming ssh connection attempts against the block lists. If you’re on a particularly resource-constrained shared host, this might have some impact on overall server performance. Plus, even in its most recent update, DenyHosts can lag a bit in its blocking—because it uses regexes run against your server’s auth.log file to figure out what it needs to do, a remote attacker blasting out a tremendous number of logon attempts per second could get far above your allowed threshold of connection attempts in before DenyHosts drops the hammer.
There are lots of other things you can do to help secure your web server’s ssh port, but one of the most powerful and flexible is to bring iptables into the mix. Iptables is an applicaiton which comes preinstalled on most modern GNU/Linux distros and which provides instructions to the Linux kernel firewall. It is not a firewall in and of itself; rather, it provides a (relatively) easy way to view and modify the way the system’s built-in firewall tracks, filters, and transforms the network packets it receives.
In this particular use case, we care about iptables’s ability to perform actions on incoming ssh packets, based on parameters we define. Specifically, we’re going to use it to track all incoming ssh requests, and then block any host that tries to connect too many times. This is a simpler and more robust approach than the one DenyHosts takes, and the advantages are that it is self-maintaining and not dependent on log file parsing to work.
(Special thanks to my friend and mentor RB for passing along his feedback on the previous post and the instruction on how to get rolling with iptables!)
This is an old post. It may contain broken links and outdated information.
Running any kind of server at all is a risk, because the internet is a bad place full of bad people who like to destroy things for fun (and if you don’t believe me, read this). It becomes a matter of risk management—you have to expose certain things, like TCP ports 80 and maybe 443, for your web server to be reachable; you also probably need to expose at least one management port somewhere so that your server can be poked and prodded should things go wrong with it.
This usually means exposing port 22 for ssh if you’re on some kind of Unix-ish operating system like we are here at the Bigdinosaur.org compound. Blindly exposing your ssh port is not without peril, but there are several things you can do to manage the risk—namely, moving the ssh daemon onto a different port; controlling which local accounts are allowed to log on via ssh; and most importantly, installing and configuring something like DenyHosts, a TCP wrapper designed to help keep undesirables from being allowed to log on at all.
This is an old post. It may contain broken links and outdated information.
In a previous post, I discussed how to alter Octopress’s configuration to serve web fonts via the @font-face CSS method. This works great and will get your Octopress site working with locally-served web fonts, but there’s some optimization that can be done on the web server side; specifically, three of the four types of web font files are compressable and benfit from being gzipped by Nginx (or whatever web server you’re using) as they’re served out to your site’s readers.
We use Nginx here at the Bigdinosaur.org compound, and so this post will focus only on how to enable gzipping web font files with Nginx. Instructions for doing this with other web servers are easily locatable via the googles.
Most people use a NAT router at home for connecting to the Internet, and most consumer-grade NAT routers offer some limited version of DHCP for automatically handing out IP addresses to desktops and laptops and game consoles and smartphones and some limited version of DNS for making sure all the devices on the network know what all the other devices are called. However, the feature set and functionality of these cut-down DHCP and DNS instances are almost always too limited to handle more than the simplest of network designs; sometimes, you need to be able to do more. For example, if you wanted to set up a separate DHCP zone for handing out addresses to untrusted wireless clients versus trusted clients, or if you wanted to do something more awesome like implement the Upside-Down-Ternet, you’d need something a lot more configurable than the little NAT router’s applications.
There are lots of options, but it’s easiest to just pull out the big guns and set up BIND9, the current version of the DNS software that powers the Internet, along with the ISC’s DHCP server. DNS and DHCP are like peas and carrots, as the saying goes—DHCP hands out the addresses, but doesn’t communicate to other network hosts who has what address; DNS knows how to correlate names to addresses but doesn’t hand out addresses itself. In this post, we’ll set up DNS and DHCP on Ubuntu, and then configure them to work together.
(NB. This blog entry ended up being bloody huge, because I don’t just list the configuration options to set but rather go into detail on what each one does. I’d intended to bang the post out in a single evening, but instead it’s taken a couple of hours over three days to complete. I hope it is informative and helpful!)
This is an old post. It may contain broken links and outdated information.
Octopress comes with awesome support for Google Web Fonts, which lets you quickly and easily add fonts to your web site from Google’s large library, but Google Web Fonts have their drawbacks. Using one Google Web Font will have little impact on your site’s load time, but every additional font you add to your web page increases the page’s load time, as clients must use additional HTTP requests to pull the web fonts from Google’s servers while at the same time loading your page and its contents. Plus, sometimes you want to use a (free and legal) font that’s not in Google’s library.
There’s a workaround—a CSS method named @font-face (more info), which allows you to host your own fonts on your web server and serve them to clients along with your page. At first glance, this doesn’t seem too terribly different from simply including fonts from a web source like Google, but hosting your own fonts via @font-face on a web server with keepalive is much quicker than pulling them from a separate server, as far fewer HTTP sessions have to be used to load the page and its contents. Fewer sessions means faster page loading!
While Octopress comes with a ready-made method of adding Google Web Fonts, it’s not set up out of the box to use @font-face-served fonts. However, it’s pretty easy to change the configuration!
This is an old post. It may contain broken links and outdated information.
Like most open source projects, Nginx has more than one “branch” of code—that is, more than one version available for public consumption. Ignoring platform-specific versions, the two main branches are “stable”, and “development”.
This is a common dichotomy. For projects divided thusly, the “stable” branch is intended to be a thoroughly tested, minimally-bugged, production-ready version of the application which can be deployed in real life. Conversely, the “development” branch usually has more features, but is typically a lot more rough and potentially buggy, having undergone less testing. Stable is for production, development is so that users can test upcoming features.
