Inspired by some of the cool kids, I’ve spent the last couple of evenings migrating my blog over to Octopress. The main motivators were my desire to put my posts under version control (we’ve been going a bit nuts for Git at Pebble towers recently), and that I wanted to use the excellent Byword app to compose my posts (I just need to work out how I’m going to be able to use the iOS app to publish on the go - probably some Dropbox trickery). ...
Before I descend into a massive rant, let me preface this post with this: I hate BT. I always have, and I probably always will. They are generally the most incompetent, uncooperative company on the planet. Let me take you back to October 2011. I was perusing the BT website looking for BT Infinity - their brand name for up to 40meg VDSL. I popped in my postcode and was told that I was in a trial area for FTTP at a stonking 100meg. Obviously I thought about the pain I was letting myself in for, having to deal with BT, but I was sure that I could cope with it if I was getting such insanely fast Internet at the end of it. If only I knew how painful it was going to be. ...
I’ve pushed some updates to this script, mainly switching to using The Luggage for making the package. As ever, it’s up on Github.
So you’ve lovingly crafted your never booted image in InstaDMG. It’s fully up to date and lovely. And then you try to enable FileVault 2. As you have no Recovery HD, it’s not going to happen. I’ve tried several methods to get around this, including taking an image of an existing Recovery HD. It worked (ish), but didn’t feel right. Then I found this post on google +. I’ve lovingly ripped off the method and put it into a package for deployment with DeployStudio, ARD, or anything else that can take normal packages. You can download everything from my GitHub, usage instructions are in the readme.
Recently, I was tasked with moving a client’s web server from a box in their office, to something a little more robust when they put something up there that caused the server to go nuts (30 mb/s nuts!). The main goals were: Fast, scalable web server Multiple FTP users for the client’s web team to modify the site Integrates with their existing CrashPlan PROe backup system. Use GUI’s as much as possible for admin so lower level techs could make changes on the server. After considering several options, we decided to go with Linode. I’ve had great success hosting my own site with them, and as we had full access to the box, we could install anything we wanted - including CrashPlan. ...
We’ve been using a 10.7 Server in the office since Lion was released, but it is only now that I’m about to install an all Lion office, so will get the chance to use Profile Manager in a real install. Over the last few months, I’ve noticed a couple of things: Don’t bother using a self signed SSL certificate. Preferences will fail to push seemingly at random without a proper certificate. For what they cost, get over to Godaddy and buy yourself a cheap certificate and save yourself hours of head scratching. ...
Starting with Lion Server, a fair bit of data is now stored in Postgres databases. If you use Time Machine, you’ll get this backed up properly for you. If you use a proper backup solution (I prefer CrashPlan), you won’t get automated dumps. This script rectifies this, by dumping all of your Postgres data, and keeping 7 days worth. You can grab the code, along with a pre-built pkg installer from GitHub. ...
The problem Lion Server takes over every ethernet interface when you enable any web services (Web, Wiki, Profile Manager, basically anything!). This leaves us with two options: putting Kerio on a non-standard port and getting the users to type that in every time, or completely disabling apache and not using any of the good stuff that came with Lion Server. Or, we could work out a way to redirect users to the right port number when they hit mail.example.com ...