Keeping a ride together – The Cornerman System

The cornerman system (or 'corner marker system') works pretty well for larger groups, and those with some slow and some fast riders; it encourages overtaking. If there's only three or four riders, or everyone rides at about the same pace, follow the leader is normally a better match.

Most forums try to explain the cornerman system but make it sound far more complex than it is.

In short, there is a 'leader' and a 'tail' (who might also be called a 'tail-end Charlie', 'TEC', 'last man' or 'tailgunner'), and everyone should be able to identify the tail from the front and the leader from behind.

The leader goes at the front of the ride and knows where they're going, the tail stays at the back - nobody overtakes the leader, and the tail overtakes nobody.

Whenever the ride does anything other than go straight on, the rider immediately behind the leader stops and marks the corner - they are now a 'cornerman' or a 'cornermarker'. If the leader thinks a marker's needed somewhere then they'll point to where the marker should be, and the next rider should stop and mark whatever's been pointed at. Marking a corner is exactly that - pulling over (often just to the side of the road, but if there's a pavement or something that's fine too) so as to be able to direct other riders.

Riders approaching the corner will see this rider and know to turn, or at least that they need to do something other than just carry on riding straight on. It is quite important that the cornermarker positions themselves such that they are obvious to oncoming riders (not hidden behind a sign, or already round the corner), and also such that it is obvious what the oncoming rider must do - which turning, roundabout exit or lane they should be taking.

As the tail approaches the corner, the cornermarker gets back on their bike and rejoins the ride - pulling in before the tail, but after the previous rider has taken the corner.

And that's basically all there is to it. During the ride the faster riders will naturaly find themselves overtaking lots, and therefore at the front a lot, and so marking corners. Slower riders will sit in the middle with a steady stream of corner markers guiding them, and faster riders overtaking them to mark more corners.

Metal Mule pannier frames and a Fuel exhaust on a Tiger 800

The exhaust pipe on the Tiger is ginormous so almost all luggage options require assymetric panniers which look daft. Metal Mule, however, sell a set of their hard-bastard frames in a symmetrical form, for use with with a new narrower silencer (a rebranded Scorpion).

That silencer costs £250 and, since the only reason for it is the narrowness, I thought I'd try a cheaper one. I tend to default to Fuel for cheap exhaust pipes, and their narrower silencer for the tiger is only £150.

But neither Fuel nor Metal Mule will say for sure that the pipe will fit (Metal Mule are nice enough to not insist on my buying their Scorpion, though, and suggest that "it really should, but we can't guarantee it").

Turns out it does!

The rack does actually foul the linkpipe, though, but I've drilled a sidestand puck to space it out a bit:

and the gap I was concerned about (between the frame and silencer) is fine:

Everyone loves the cornerman system, which is explained both in great depth and with much convolution on most motorbike forums. But I quite like playing follow the leader, and much as it's probably how you ride anyway, sometimes people ask how a ride is going to work. Here's what I call 'follow the leader' and some other people call 'the buddy system':

• You set off in a line, and maintain that order. No overtaking each other.
• You pause at corners to wait for the guy behind you. At the beginning of the ride you agree on how he'll signal that he understands where to go - I always suggest a wave since that's really hard to accidentally do, but some people like headlight flashes.
• As you're going along, you keep an eye in your wing mirror for the guy behind you, if he disappears for a while you stop and wait, eventually going back if the guy in front of you comes back for you (he having waited a while).
• If you get to a corner and you don't know where to go you stop. Eventually the guys in front will be back.

Debian Wheezy ships with Dovecot 2.x which has a different config layout to the 1.x verion in Lenny and Squeeze. In response, I've created a wheezy branch of postfixadmin-installer (there's an issue for it, too) which configures Dovecot 2.x and it's actually been a really easy switch.

In much the same way as the current version generally does away with the heavily commented documentation masquerading as a config file, this one simply moves /etc/dovecot out of the way and writes two files into it - dovecot.conf and dovecot-sql.conf (which are the same as for 1.x). This causes a pretty hilarious reduction in filesize, too:

[email protected]:~# find /etc/dovecot/ -type f -exec cat {} \; | wc -l
48
[email protected]:~# find /etc/dovecot_2013-01-29/ -type f -exec cat {} \; | wc -l
1772
[email protected]:~#

Anyway, with some incredibly limited testing, and assuming you have already installed dovecot, this seems to work. If you want to test it (please!), enable Wheezy backports in Squeeze and then:

apt-get install libwww-perl mysql-server postfix
apt-get -t squeeze-backports install dovecot-common dovecot-imapd dovecot-pop3d

And, finally, here's that working config I'm using, in case that's what you're after:
/etc/dovecot/dovecot.conf

protocols = imap pop3
log_timestamp = "%Y-%m-%d %H:%M:%S "
mail_location = maildir:/var/vmail/%d/%n
mail_privileged_group = vmail
# This should match that of the owner of the /var/lib/vmail hierarchy, and
# be the same as the one postfix uses.
first_valid_uid = 999
# Allow people to use plaintext auth even when TLS/SSL is available (you
# might not want this but it is handy when testing):
disable_plaintext_auth = no
# Uncomment this to get nice and verbose messages about authentication
# problems:
# auth_debug=yes

ssl = no

protocol imap {
}

protocol pop3 {
pop3_uidl_format = %08Xu%08Xv
}

# 'plain' here doesn't override the disble_plaintext_auth_default of 'yes'.
# you should add any other auth mechanisms you want
#auth_mechanisms = plain
userdb {
driver = sql
args = /etc/dovecot/dovecot-sql.conf
}
passdb {
driver = sql
args = /etc/dovecot/dovecot-sql.conf
}

service auth {
unix_listener /var/spool/postfix/private/auth {
mode = 0660
# yes, 'postfix' (or the user that owns the above socket file), not vmail
user = postfix
group = postfix
}
}

/etc/dovecot/dovecot-sql.conf

connect = host=localhost dbname=vmail user=vmail password=1lgI2ehK6aEqytjkeDFT4Z7Pq
driver = mysql
default_pass_scheme = MD5-CRYPT
user_query = SELECT maildir, 999 AS uid, 122 AS gid FROM mailbox WHERE username = '%u' AND active='1'

I've *finally* merged about a billion changes into master in postfixadmin installer, chief amongst them is that most of the boring output now goes to a logfile, the vacation plugin might work after install and it the setup password is randomised. This is all procrastination in order to avoid working out how to configure Dovecot on Wheezy.

It's still a big pile of poor hacks rather than a 'proper' script, but if you just don't look at the source you'll be fine!

Sitecreator

I've just spent a few days using up spare holiday, which means I've been making things for work that work doesn't want but I do. This time it's sitecreator, a tool for configuring websites and all their dependencies (Unix users, databases, ssh keys, DNS records etc.) on servers.

Since there's so many possible things for the site to rely upon, and I'm not *that* fond of reinventing the wheel, all it really does is generate passwords and call scripts. There's a configuration file that tells it how many passwords to generate, how to work out what the username should be and perhaps to generate a couple of other things (like database names) if needed. Another bit of the config then explains which scripts to call and with which arguments (including these recently-generated passwords and usernames), and at the end it tells you what it thinks it did. I've written a few scripts for it already (mirroring what I want to do with it).

For example, here's a relatively simple config file with some explanation of what's going on, and some output with that configuration:

[email protected]:~sitecreator example.com
MySQL:
database: example

SSH:

MySQL dev:
database: example

[email protected]:~$And there's at least another example config file in etc/config/. Anyway, hopefully this'll be useful to somebody else who isn't quite into automation enough to have already done this (or to have started using puppet or similar), but does have enough users or systems to configure that some automation would be good. Oh, it's not very tested yet, and I've still not come up with a sane thing to do with the output from the scripts :) Network Manager disabling Virt-manager’s bridge This doesn't work, and it's filed as bug 1099949 in Ubuntu. So we'll see how that goes. As of about six hours ago, I've had this regularly popping up in my syslog: Jan 13 20:13:54 amazing NetworkManager[1347]: (virbr0): device state change: unavailable -> disconnected (reason 'none') [20 30 0] virbr0 is the bridge created by virt-manager for its VMs to communicate on and, franky, NetworkManager has no business doing anything to it, let alone disconnecting it (especially when it doesn't know why it's doing it). Fortunately, NetworkManager has an unmanaged-devices option that you can put in the irritatingly-capitalised file at /etc/NetworkManager/NetworkManager.conf. It belongs in the keyfile section (so you need to make sure keyfile is listed under plugins: [main] plugins=ifupdown,keyfile dns=dnsmasq [ifupdown] managed=false [keyfile] unmanaged-devices=mac:2e:e7:1f:7c:ef:76 Annoyingly, there doesn't appear to be a 'managed-devices' configuration, and virbr0's mac address changes from time to time. So far, sticking this at the end of /etc/rc.local to get the mac address of virbr0 and replace the old one in that file seems to be working: #! /bin/bash echo -n "Before : " egrep '^unmanaged-devices' /etc/NetworkManager/NetworkManager.conf mac=(ifconfig virbr0 | grep HWaddr | awk '{printNF}'); echo "New mac : mac"; perl -pi -e "s/^unmanaged-devices.+/unmanaged-devices=mac:mac/" /etc/NetworkManager/NetworkManager.conf echo -n "After : " egrep '^unmanaged-devices' /etc/NetworkManager/NetworkManager.conf Half an hour in, I've still got network connectivity on my VMs! :) Converting from Apache1-style to (Debian-style) Apache2-style vhosts Yeah, some of us are still doing that migration. Anyway, historically Apache vhosts are all in one file at /etc/apache/httpd.conf or if you're really lucky something like /etc/apache/vhosts.conf. Apache2 in Debian uses two directories - /etc/apache2/sites-available and /etc/apache2/sites-enabled. sites-available contains one file for each vhost and in order to enable them they're linked to from sites-enabled. This is all fairly nice an elegant and human friendly, but tedious to migrate to from Apache1. Since this one's coincided with a feeling that I should know more awk here's how I just did this one: cp /etc/apache/vhosts.conf /etc/apache2/sites-available awk '/^"vhost" n }' vhosts.conf for i in (ls vhost*); do name=(grep -i ^ServerName i | awk '{print2}'); mv iname ; done rm /etc/apache2/sites-available/vhosts.conf Yeah, the name should be doable in the initial awk, but by that point I sort-of just needed to get it done. Finding exploited wordpress pages WordPress seems to be hilariously easy to compromise (this might be a bad place to write that) and the general form of an exploit is to inject code like this 1. < ?php$a = base64_decode(YSBsb25nIHN0cmluZyBvZiBiYXNlNjQgdGV4dAo=.......);

right at the top of a script. base64_decode is rarely used by the Good Guys outside of mailers and doing tricks with images, but it's almost never found right at the top of a script. I did write a really convoluted script that found calls to base64_decode and exec and guessed whether they were nefarious (generally, for example, base64_decode is called with a variable (base4_decode($mailBody)), not just a string (base64_decode(dGV4dAo=)) but that just ate all my I/O and didn't really work. So I came up with a much cruder way of doing it. Have a script called ~/bin/base64_in_head #! /bin/bash file=1 headfile | grep base64 2>&1 >/dev/null || exit 1; echo$file
exit 0;

And then run it like this:

$ionice -c3 find /home/user/public_html/ -name \*.php -exec ~/bin/base64_in_head {} \; I've not yet had a situation where that's missed a file that later manual greps have found. Unattended Virtualmin installs A while ago I was asked to concoct a fire-and forget script to install Virtualmin without prompting. It's really easy: #!/bin/bash if [ -z 1 ]; then echo "Usage"; echo "0 [hostname]"; echo ""; exit fi wget http://software.virtualmin.com/gpl/scripts/install.sh -O install.sh export VIRTUALMIN_NONINTERACTIVE="1" chmod +x install.sh ./install.sh -f -host$1
rm install.sh

And then you call it like so:

./virtualmin.sh virtualmin.vm.avi.co