Recently in solutions Category

Some time ago I was experimenting with pfSense and HAProxy to deploy both as firewall and load balancer for one of the websites I was working on at the time. The key incentive was that pfSense is great BSD based firewall distribution with amazing features offered out of the box, and if that was not enough, you can install additional packages to add features you need.
One of those packages is HAProxy (proxy/load balancer) and both work together very nicely but...

Problem
I have installed pfSense with HAProxy several times, more than several in fact... and every time I did it, the configuration file generated using HAProxy web configurator (integrated with pfSense interface) was broken. First row in the table showing defined backends was empty -  the configuration file itself had just variables but no values. The second entry was just fine... Obviously HAProxy refused to start.

Quick fix
Just so I remember next time what I did. Get shell on pfSense console or install file manager package and edit /usr/local/pkg/haproxy.inc to add the line highlighted below:

Not a rocket science, just shift() the first (empty) backend definition and let the script do the rest.

Note
Manually fixing config file is pointless because new config is generated every time HAProxy (re)starts and the code above is used to generate it.

Recently I needed something like web based equivalent of tail -f and tail -n commands, so I could display running tail or last N lines from specific log file. To avoid reinventing the wheel I started looking at previous works on-line and found some interesting bits here and there - one of the most useful being AJAX Logfile Tailer & Viewer, so I based my work on this one.

The trick is, that as far as it does exactly what I needed, this solution requires web server with PHP... and installing web server (not to mention PHP) is not really what I want on my logserver.

Mojolicious to the rescue!

Mojolicious is a very powerful Perl web framework that comes without bloat (almost unheard of these days!) - all you need is standard Perl interpreter and core Perl modules as they come preinstalled with your Linux distro and you can install Mojolicious - no other dependencies. On Debian systems installation is as simple as

apt-get install libmojolicious-perl

and we're up and running. Writing Mojolicious::Lite app is really simple and the best part is that it comes with it's own, built in web server (operating in several different modes if needed). Sounds like nice way to go - no dedicated web server on the machine, self-contained application, etc. One more thing - writing, testing and deploying the whole code to actual machine took less than 10 minutes!

I didn't blog for a long time, so it will be a long post caused by some nightmares I had about not doing proper backups on some of my hosts.

Servers - all those small and big machines most of the geeks own, run or operate. As VPS pricing drops, we see more and more of those low-end, resource strapped servers. Organic growth usually means you start with empty server, some kind of definition what it will be doing and... from there it just goes downhill. How do you backup such VPS? Here is something I use myself.

My backup requirements

• Automated - it has to run without supervision in roughly regular time intervals, if it's not automated it will never be done (read no backup)
• Off-site - in case I loose the whole machine for some reason (because RAID is not backup and what fire doesn't destroy, water poured by firemen will)
• No Cross-Backups - because they require trust relationship between machines and if you think about using cheap VPS'es for cross-backups, remember that you get what you pay for!
• Automatically delete old backups - to save space, (my) time and money
• Append only - machine can only write data to its own, designated backup volume but can not delete or modify other volumes (accidents and rogue users do happen)
• Confidentiality - no unauthorized access backed up data
• Availability - storage volume has to be highly available so I can not only write to it knowing it's there, but also access backups when I need them
• Access controls - ability to define granular access rules and enforce append-only usage
• Economy - it has to have reasonable cost

This time from the department of almost wasted time...

We all know that serial ports come very handy when you need to (re)configure something like a switch/server/firewall or similar device. In theory you can do that over TCP/IP nowadays with one hint - you need to have connectivity. All would be ok if not the fact that those very switches/firewalls you want to reconfigure actually provide the connectivity you need :-)

The Idea

Now... why spend hundreds of pounds/dollars on off-the shelf kit? Sure, it's cool, properly built and works unless you mess it up, but where's the fun part?! Today I needed a very very quick and cheap solution, so:

1. SheevaPlug - £114.00
2. 13-port USB hub - £19.99
   
3. USB-serial dongles (pl2303) - £14.99 each

This way I have fully networked console server with 4 ports just under £200 - acceptable, especially when the whole thing is running off DHCP and calls home via OpenVPN - very easy to deploy!

Tricky bits

Generic Sheeva has one USB host port and hub has 13 of them - I want to send it off to remote location and have somebody plug it in and not mess up what's where. Trick is to write appropriate udev rules to detect adapters and give them ttyUSBn names according to physical port on the hub.

All would be fine and easy if it worked as documented - sadly it doesn't. First problem was that ATTRS{devpath} (as returned by udevadm info --attribute-walk -n /dev/ttyUSBn that allows to distinguish usb ports) was used by rule in tests but wasn't propagated properly on none of my Debian or Ubuntu boxes. Then I tried to match KERNELS for parent devices - nope... if you go too far up the tree it doesn't see s**t :-/

Recently I had some serious problems with wi-fi at home - especially one of the laptops was dropping off and couldn't come back. Quick survey using Kismet and other tools to scan what's flying around has proven that my network is in less populated part of the spectrum (at least here) but still, problems are getting worse and worse.

I was fully aware of Wi-Spy by Metageek, seen it in action previously but never had a chance to buy one. Part of the decision was the price back then, maybe now it would be another game, but anyway - I got myself another device, made by well known wi-fi vendor Ubiquiti and it's called AirView2.



What's so special about this one? Why it's better than Wi-Spy?

First of all I didn't say it's better. It's different, woks with Linux, Mac OS X and Windows, has a nice price tag and does pretty much the same as Wi-Spy. Let's have a closer look then, shall we?