I love both Open Source and Cycling, but the 2 do not ofen meet. In fact the cycling industry is incredibly secretive and dominated by patents. It is one of the major reasons that it is very hard to enter the groupset market (for roadies there are 3 major brands, for MTBers only 2). SRAM recently completely changed the way derailleur shifting worked with their new eTap electronic groupset, basically to work around Shimano’s patent library. I haven’t tried it, but by all accounts it is excellent (for the price it should be), but still it is a little silly.

There has been boo-hoo-hooing the last few days about an injury sustained by Francisco Ventoso at Paris-Roubaix.

Yes that spongey looking bit is his bone. It is seriously nasty and the UCI have re-banned disc brakes as a result.

However, the fact is that disc brakes are a lot better than rim brakes. Rim brakes suck - especially in the wet. On carbon rims they suck even more even in the dry. In the wet, you may as well just give up. Ok, I am exagerating, a bit. It is not power which is the big difference though, but control. With a hydraulic disc, you can dial in just the amount you want. Overall this will mean less crashes - very important when you have 200 people all trying to share the same bit of road.

Drown is the latest vulnerability in OpenSSL. Essentially it allows an attacker to decrypt your TLS session and get data out of that session.

The thing is, it is based on a vulnerability in SSLv2! Here lies my problem with this: SSLv2 has been known to be insecure for 20 years. Not only that, but SSLv3 also and even TLS1.0 (effectively SSLv4).

The number of clients requiring even support for TLS1.0 is miniscule now, so anyone who has still got those algos enabled is clearly an idiot. They should be fired for gross-incompetence quite honestly.

Happy 2016 all

This weekend I finally got round to adding eyaml support to Puppet in my lab. What is on earth am I talking about?

Puppet can use a thing called Hiera as a data source, think of it as a database for configuraion. In an ideal world, your manifests will be completely generic - in fact your control repo could consist of nothing but a Puppetfile with a list of modules to install (if any one lives in that ideal world, you are better than me). Hiera in turn can have different backends for describing this data, such as:

I've been shopping! I've recently bought myself a new pair of pair of bib tights (for the full Dave Lee Roth effect) and a new jersey. More specifically I've bought DHB Vaeon Roubaix padded tights and a DHB Windslam jersey.

DHB is the house brand of online cycle megastore Wiggle. Wiggle are based in Portsmouth, which is where I studied, lived for 10 years, met my wife and where both my children were born. As a result, I probably have a slightly bias opinion of them - I could justifiably call them my LBS after all. I will try and put any bias aside however and just give an honest opinion here though.

The basics of defining what modules get applied to a particular node is really simple in Puppet. Out of the box you just use the hostname and the FQDN and everyone is happy. You find this everywhere in documentation, blog posts, presentations, etc. However is has a problem: scale.

What if you have an elastic infrastructure with nodes being created and destroyed automatically? What if you want to use the same manifests in different environment, but use different hostnames? What if you have stupidly complex host naming conventions that you cannot get your head round (current day job problem for me :-( )?

Recently I have been working a lot on a backup solution at work, which has been a painful experience to say the least. Why? Simply because there is no solution that meets my ideal requirements. These are pretty precise:

• Open Source
• Openstack Swift as a backend
• File level restores
• Scalable
• Lightweight
• An idiot must be able to restore a file
• Not a source of truth about my infrastructure
• Automated restore testing

A nice bonus would be volume level backups of Openstack Cinder.

It’s a process that strikes fear into the hearts of Sysadmins everywhere. This weekend I finally got round to upgrading the Openstack cluster in my lab to Kilo. As I have no spare machines lying around (Intel NUC/HP Microserver/similar donations welcome) I did it in place.

Did it go well? Mostly...

My base was a Juno install from Packstack. If your Juno install was different, then YMMV, but the idea should transfer. The basic process was to install the Kilo yum repo, then run an upgrade: