- Testing Raspberry Pi Images with Qemu
- Removing index.php from SEF URLs
- Audi A6: Front Brake Pad Replacement
- Usurping the BTHomeHub with a Raspberry Pi: Part 5 - Inbound OpenVPN
- Recovering from corrupted InnoDB Pages
- OpenVPN on CentOS 6 (Updated) - With HMAC
- Usurping the BTHomeHub with a Raspberry Pi: Part 4 - Using a VPN to Tunnel Connections to Specific IPs
- OpenVPN on Debian
- Usurping the BTHomeHub with a Raspberry Pi: Part 3 - Routing, Remote Administration and Utilities
- Usurping the BTHomeHub with a Raspberry Pi: Part 2 - DNS, DHCP and NTP
- Usurping the BTHomeHub with a Raspberry Pi: Part 1
- Creating a Virtual Network Interface in Debian
- Keeping Hitcounts accurate when using an NGinx Caching Proxy
- mod CatImplode
- Volvo 440: Voltage Decreases as Engine Speed Rises
- PHP GPX Ingest
- Joomla and NGinx Reverse Proxy Caching: Keeping your dynamic content fresh
- Making your Joomla Site Fly with NGinx Reverse Proxy Caching
- CentOS: Using NGinx as an SSL Reverse Proxy for Apache
- JoomShopping Plugin for ObRSS
Although changing the OS on a Raspberry Pi is quick and easy (especially if you have a spare SD card), there are times when you might want to test a system first, or simply tinker without needing a spare Pi.
This documentation details how to use Qemu to run a RaspberryPi image.
So you set up your Joomla! site, made it live, and later realised that you'd forgotten to enable the HTAccess file for SEF URL's.
The end result being that all your URLs contain /index.php/ What to do?
You could just enable the HTAccess file, but all the old URL's will then return a 404. Not great if your site has already been indexed by search engines, even worse if others have linked to you too.
In fact, on newer sites, it might even be worse - the old link will still be valid, but there'll be a 'new' link too, so you'll end up with two URLs for the same content.
It's actually incredibly simple to resolve, and this documentation details the two steps you need to take to resolve it, without breaking the old URLs.
Changing the front brake pads on the Audi A6 Savant is a relatively straight forward task to complete. The brakes are one of the areas where Audi appear to have taken the wise decision not to over-complicate things too much.
This documentation applies to the 2000 model, but the steps should be similar for others too
In Part 4 we configured our Raspberry Pi router to maintain a number of OpenVPN tunnels and to route through them selectively. Now we'll look at the steps needed to allow connection to our LAN via OpenVPN. Although helpful, as the HomeHub doesn't provide VPN connectivity, this stage doesn't really count as Usurping the BTHomeHub.
The steps are almost completely identical to those performed when Installing Open VPN on Debian. We're going to have to NAT connections though, as the HomeHub is a little stupid and we can't add static routes to it (so if we're connected to the VPN and accessing the Internet, it won't know where to route the response packets).
What we'll do, though, is only NAT if the connection isn't to something on the LAN.
I recently encountered an issue with various InnoDB pages becoming corrupted on the database that plays host to my JIRA install. It was - to some extent - a mess of my own making for mixing production and development databases (or more precisely, for hosting that production database on a dev machine).
Lesson learnt, sure, but I still needed to address the issue so that I could get JIRA up and running again.
This documentation details the steps to follow - it won't resolve every case of corruption, but it resolved the issues I was seeing
I've previously documented how to install and configure OpenVPN on CentOS 6, but the steps appear to be outdated.
In this documentation, we'll (very quickly) detail how to configure OpenVPN on CentOS 6. We're also going to enable TLS Authentication so that OpenVPN won't even respond unless the connecting client provides the right pre-shared key.
You'll need the EPEL repos installed and enabled.
Usurping the BTHomeHub with a Raspberry Pi: Part 4 - Using a VPN to Tunnel Connections to Specific IPs
Content Filtering is becoming increasingly popular amongst Politicians, ISPs and generally clueless do-gooders. The problem is, whatever you think of their motives, it's generally poorly implemented and interferes with the end-users browsing experience, even when it's not supposed to (the image to the right appeared with filtering off! - click to enlarge).
As we've been Usurping the BTHomeHub with a Raspberry Pi, we're going to take a brief break to implement some useful functionality that the HomeHub didn't provide.
In this Part, we're going to configure our Raspberry Pi to connect to an OpenVPN server and route some of our traffic over the tunnel - depending on the destination IP. This will allow us to easily bypass the troublesome content filtering, whilst not un-necessarily introducing any latency to any connection that is (for the time being at least) unaffected by the filters.
Note: We'll be manually specifying the connections that are routed via VPN, so that we can 'whitelist' mistakes such as the EFF and Wikipedia, whilst still being 'protected' against other filtered pages.
Unless otherwise stated, all commands need to be run as root
Setting up OpenVPN on Debian is as straight forward as on CentOS, though some of the file locations differ slightly.
This documentation details how to install and configure OpenVPN on a Debian server.
In Part One we configured a RaspberryPi to act as a Wireless Access point, providing DHCP services to wireless clients. In Part Two we then configured our Pi to provide DHCP, DNS and NTP services to the entire LAN.
In this part, we'll be taking some more responsibility away from the BTHomeHub, as well as configuring a few conveniences, such as Remote administration and useful utilities, including
- Wake On Lan
- Network Troubleshooting Tools
- Dynamic DNS Update Client (No-Ip.com)
In Part One, we configured our RaspberryPi to act as a Wireless access point and bridged the wireless and wired interfaces so that WLAN client's were easily accessible from the LAN.
As part of that setup, we configured a DHCP server, however we haven't yet made it the DHCP server for the LAN - our tired old BTHomeHub is still the authoritative server for the network.
In this part, we'll be reconfiguring our DHCP server so that it takes responsibility for the entire LAN, configuring DNS services, and making our Pi the LANs central NTP (Network Time Protocol) Server
Step by step, we'll be configuring our Raspberry Pi to take over nearly all of the duties performed by the BTHomeHub.
I used to run a nice pfSense box as my router, unfortunately power bills being what they are, I reverted back to using a BTHomeHub. Unfortunately, the BTHomeHub isn't particularly good - the Wifi signal sucks, it's DNS server seems to daydream and it occasionally forgets that it should be assigning some devices the same IP every time (or more precisely, will give their IP away if they are not currently present).
We could, of course, replace the HomeHub with something a bit more up market, but where's the fun in that? In this post, we'll be starting down the route of using a Raspberry Pi to usurp some of the power the BTHomeHub currently holds over the LAN. Eventually, the HH will be acting as nothing but a dumb internet gateway, doing a little bit of NAT and not much else.
There are times when you might want to assign more than one IP to a system, even if it only has a single physical NIC. This documentation details how to create a virtual network interface (known as aliasing) under Debian (see here for how to alias in Centos 6).
In previous documentation, we've configured sites to use NGinx as a Reverse Caching Proxy, leading to hugely improved response times on popular content. We've also implemented a custom configuration so that we can refresh the cache periodically, ensuring that dynamic content (such as Twitter modules) updates.
One thing we haven't done as yet, though, is to address the issue of internal hitcounts. We've looked specifically at using NGinx with Joomla, and noted that a side effect would be inaccurate hitcounts displayed within Joomla (which remains true even when using the internal page caching).
In this documentation, we'll be implementing a small script to ensure that hits served from the cache are still recorded within Joomla (or Wordpress, Drupal - whatever you happen to be using), albeit a little while after they happen.
mod_CatImplode is a Joomla module designed to display all articles within a com_content category as one indexed article. It was designed to increase the manageability of API documentation for VehicleFuelTracker.
This article forms the user documentation for the module
Having resolved the issue, it's a fairly garden variety fault, but I thought I'd document it in that the symptoms are almost exactly the opposite of what we expect to see when there's a fault with the charging system.
Essentially, as the engine speed rises, the voltage (measured across the battery, or from anywhere else in the car) drops - and not just a little.
GPS eXchange format files (GPX's) allow you to record data from your Global positioning system for processing/import into other systems.
The PHP GPX-Ingest class allows you to import basic GPX files and converts them into an object for easy data retrieval. In the process of doing so, it also generates basic statistics such as average speed, number of track points and journey length.
The resulting object can be exported as a JSON string for easy storage and re-import back into the class at a later date (perhaps to extract more information).
This documentation details how to include and use the class in your project.
PHP GPX-Ingest is licensed under the GNU GPL V2 License.
We've placed a caching NGinx reverse proxy in front of our Joomla site, but haven't yet addressed the issue of the content that we do want to remain dynamic. We might, for example, have a module such as mod_GoogPlusFeed embedded on a number of pages, but with the configuration we've used so far, this won't update until the cached copy has expired.
In this guide, we're going to walk through the few easy steps to ensure the content is regularly updated - without undermining what we were originally trying to achieve - fast response times.
The primary basis of what we're going to do is very similar to Dealing with Slow modules and Caching, so much so that some of the set up is the same
I've written previously about configuring NGinx to act as a reverse proxy for Apache, as well as some of the specific tweaks you need to make if you're serving a Joomla! based site. In this documentation, we're going to look at how to use NGinx's Reverse Proxy caching feature to make your site really fly.
There are a small number of technical hurdles which we'll overcome to ensure that the user is experience is fast and smooth without losing interactivity on those sites which demand it.
A little while ago, I published a guide to configuring NGinx to act as a Reverse Proxy for Apache. Although it was briefly mentioned, we never went through the steps necessary to configure NGinx to work in this manner for SSL connections - we simply left Apache listening on port 443.
This documentation details how to go about configuring NGinx to handle your SSL stuff as well. It assumes you've already generated CSR's and got the SSL certificate to use (presumably because they're already being used by Apache).
JoomShopping Plugin for ObRSS allows you to generate an RSS feed for your shop using the popular ObRSS component. It's intended as an alternative to the plugin sold by Foobla as that version may or may not work with later versions of ObRSS.
This post is the documentation for the plugin.