I'd decided ahead of time that I wanted to use Internode as my ISP, and had ordered a Naked DSL service from them and also decided to bundle my mobile phone with them as well. For reasons that only made sense to me 7 years ago, I've been paying Telstra to keep my mobile number going, but I've long since lost the SIM. My current phone has a micro-SIM anyway, so I needed a replacement SIM. My grand plan had been to order the SIM, order the number port from Telstra to Internode, and then, well, profit from the moment I stuck the SIM in my phone. Unfortunately the port didn't go through as planned, and I was left incommunicado for the better part of two and a half days. I felt like I had my hands tied behind my back not having a mobile data service. It was also mildly annoying not being able to call people or be contactable, given the amount of running around I was doing. But it got resolved and is fast becoming a distant memory. The DSL service required a Telstra technician to come out (I'm not actually sure why) and that was scheduled for Thursday. I happened to catch him while he was at my building's MDF, and had a bit of a chat with him. He was a Scotsman, and I didn't get all the details, but he was going on about how he was only there to operate on the exchange side of the MDF, and I'd have to get someone else to jumper it up to my apartment. This wasn't what I expected from an installation service, but sure enough when I finally got around to plugging the ADSL modem in on Saturday morning, there was no line sync to be had. A call to Internode confirmed that he'd only jumpered it up to exchange side of the MDF. What was even more annoying was I'm pretty sure I saw him yanking out jumper wires from the MDF when he was working on it. Jumper wires that connected the exchange side of the MDF to my apartment. I was not thrilled with the idea of waiting (and paying) for a cabling contractor to come out and hook up a couple of bits of jumper wire, so I put out a call on Facebook for a Krone tool and a tone generator, and Brent was able to come through for me. He dropped the gear around while I was out shopping with Kristy, and when we got back, I located the pair for my unit, and rejumpered the existing jumper wire that I'm pretty sure the Telstra technician had disconnected. Lo and behold, my ADSL started working. I felt pretty proud of myself. It's fun operating at Layer 1 every now and then. The FRITZ!Box Fon WLAN 7270 is quite the beast of a box. Not only is it an ADSL modem, it's a wireless router, DECT base station, VoIP thingy and an answering machine! I've managed to connect my Engin account up to it, so once I get a DECT handset, I'll be able to make VoIP calls through it. I don't need to run Asterisk any more.

On Monday I took part in my first triathlon, a "sprint" distance race organised by Thames Turbo Triathlon Club.

I was really not doing well by yesterday, I had developed quite the runny nose. I've discovered that it's neigh on impossible (from my sample set of two pharmacies) to get pseudoephedrine over the counter in this country. In the US, you have to provide ID and they report all purchases to the government and if you start buying too much, they come and kick down the door of your meth lab. Here, you seem to need a prescription. One pharmacy told me that 1 in 10 pharmacies will sell it over the counter. I ended up with the Australian equivalent of Afrin, which I don't particularly like, but it at least dried up my nose. Discussions on Facebook suggest that I may have been dealing with second-rate pharmacies, and the "big ones" would be more useful. I was also advised to try begging and pleading for Claritin-D. The damn meth labs have ruined it for everybody. It's too bad they can't come up with an additive that is safe to ingest, but would fuck up the meth cooking process. Not content with only two marathon shopping days, Kristy came back for a third day of driving me all around town, as my quest for a sofa bed and a dining table continued. It turns out that one does not simply walk into a furniture store and walk out with a sofa bed (or a dining table, for that matter). These things all seem to be on boats from China, or at best interstate warehouses, and most places can sell you something they know is in transit at best, but they're loathe to sell floor stock (for obvious reasons), and they seem to not have anything in a Brisbane warehouse (plenty of stuff was in Sydney or Melbourne and they'd ship it up). Plushhad a chaise sofa bed that had a nice sprung mattress, and was due in late this month or early next, and they would lend me something in the meantime, so they got my business. I look forward to having something to sit on. We then had an epic time at Bunnings getting all sorts of random household stuff, with the obligatory sausage sizzle before and after. Oh, how I have missed proper sausages! It turns out I'm looking for something that doesn't seem to exist over here, Rubbermaid don't seem to make the plastic "shed" cupboards in Australia, so I'll have to look elsewhere (Clark Rubber seems to make something approximately like what I'm looking for). Then I picked up some towels from Westfield Chermside and resumed the search for a dining table. I was really liking the idea of at least one bench seat, and we finally found a matching table, a bench seat, some shelving and a coffee table that would work as an entertainment unit, at OZ Design Furniture. They had a 20% off sale that made it all fairly reasonable. The entertainment unit was available immediately, and the rest of the stuff should be delivered in a couple of weeks. That just leaves finding some dining chairs that will go with it. OZ Design Furniture had the most unusual delivery charging system. They charge by the flight of stairs. Living on the 2nd floor does have its disadvantages. At least I won't be moving out of here any time soon. By the end of the day, I was totally done, but very happy to have finally sorted out the elusive remaining bits of furniture. I had my first night sleeping in my new home.

Besides my RTL work on Libreoffice, every once in a while I just go over the regular commit log to see what have changed. I don t necessary understand each line in the commit, but do get the general idea from the commit message. Being more dependent on the commit messages makes me review them more thoroughly (hence the topic of this post). As many projects, Libreoffice has notifications of commits related to bugs reports when the bug number is properly mentioned in the commit message. This is very useful for other developers and also for QA people. After verification of a bug is fixed, I often use the commits listed on the bug report to cherry pick them to an older branch. Going to search for an unreferenced commit isn t much fun. One of the things I notice is different ways people reference bugs from not referencing them at all to referencing them in various ways like linking to the bugs system, just writing the number (without the fdo# prefix) and other creative ways This is also true for first time contributors, which might not know the standards or the rules . When I see such a case I usually put a manual notification in the bug report, and mail the author of doing so. For new or sporadic contributors this is also an opportunity to welcome and thank them for the commit and even encourage future contributions. I have been asked why aren t that info on the wiki, so I went looking and found out the info is in the right place under the Development/GetInvolved page. The relevant part is:

When you type a commit message:

• start the first line with a bug reference like fdo#12345, if you have one for your commit (see details below)
• use the rest of the first line as a concise summary of your changes
• the 2nd line remains empty
• and starting on the 3rd line you can explain how and what changes have been made for what reasons.

Thanks in advance and happy coding (:
Filed under: LibreOffice

Ben Goldacre (Bad Science), is running a campaign for all medical trials to be published. It seems that best current evidence indicates that about half of the trials for treatments currently in use remain unpublished. That's pretty astounding when you think about it. Given that many of the trials that are published only compare new treatments against placebo, rather than against the best available existing treatment, and often barely show them as being more effective than homeopathy^Wsugar, one has to wonder how dire were the results that are not being published. If you prefer to have science done in the open, then I'd encourage you to visit www.alltrials.net and sign the petition and/or give them a donation. The fix is pretty straight-forward: Simply insist that clinical trials have to register before they start in order to be considered valid, and that all registered trials have to report their results. It need not be expensive to do -- a git repo. shared across the industry, containing a file for each trial in a standard format would do the trick probably. I imagine they'll come up with a more expensive solution, but in comparison to the cost of running a decent sized trial, it'll still be pocket change. (A note from the campaign, sent to existing petition signatories, is what prompted this blog post -- please read it and be inspired to help)

(See here for an update to this)

A hardware vendor apparently had a copy of an AMI private key on a public FTP site. This is concerning, but it's not immediately obvious how dangerous this is for a few reasons. The first is that this is apparently the firmware signing key, not any of the Secure Boot keys. That means it can't be used to sign a UEFI executable or bootloader, so can't be used to sidestep Secure Boot directly. The second is that it's AMI's key, not a board vendor - we don't (yet) know if this key is used to sign any actual shipping firmware images, or whether it's effectively a reference key. And, thirdly, the code apparently dates from early 2012 - even if it was an actual signing key, it may have been replaced before any firmware based on this code shipped.

But there's still the worst case scenario that this key is used to sign most (or all) AMI-based vendor firmware. Can this be used to subvert Secure Boot? Plausibly. The attack would involve producing a new, signed firmware image with Secure Boot either disabled or with an additional key installed, and then to reflash that firmware. Firmware images are very board-specific, so unless you're engaging in a very targeted attack you either need a large repository of firmware for every board you want to attack, or you need to perform in-place modification.

Taking a look at the firmware update tool used for AMI systems, the latter might be possible. It seems that the AMI firmware driver allows you to dump the existing ROM to a file. It'd then be a matter of pulling apart the firmware image, modifying the key database, putting it back together, signing it and flashing it. It looks like doing this does require that the user enter the firmware password if one's set, so the simplest mitigation strategy would be to do that.

So. If this key is used by most vendors shipping AMI-based firmware, and if it's a current (rather than test) key, then it may well be possible for it to be deployed in an automated malware attack that subverts the Secure Boot trust model on systems running AMI-based firmware. The obvious lesson here is that handing out your private keys to third parties that you don't trust is a pretty bad idea, as is including them in source repositories.

(Wow, was this really as long ago as 2004? How little things change)

comments

phpMyAdmin has in last year received various useful features, which are not that well known. I've decided to give them some promotion before releasing phpMyAdmin 4.0. The server monitoring part is already present since phpMyAdmin 3.5, but some of the parts were further improved in 4.0. Server monitor (as you can see on picture above or on demo server) allows you to follow server status in real time. Besides predefined charts, you can choose to follow any of MySQL server status variables or some system parameters. If you see something weird in the charts, you can select interval and inspect slow or general query log (if you have enabled it). This can help you finding most problematic queries for your server. Advisor (on picture above or on demo server) is another way to improve server performance - it comes with extensive set of rules, which can help you tuning performance for your workload. Your server has to be running for significant time to give some reasonable recommendations (so don't expect these on the demo server, which is restarted quite often). However it is still recommended to read server documentation before doing any adjustments, as the setting might have some side effects, which will affect your workload as well. Of course these are not magic pill to cure your unresponsive server, but can help you a lot in finding possible bottlenecks.

Filed under: English Phpmyadmin 0 comments Flattr this!

Not content with just one day of driving all over town, Kristy came back for another day of it. I decided that rather than specifically shopping, I needed to do some of the more bureaucratic stuff, so that I could ensure things like the electricity could get put on in my name. I determined that in order to get the electricity in my name, I'd need to provide either a driver's licence number or Medicare card number. Unfortunately I remember separating my expired ACT licence and Medicare cards from my other random cards while I was packing up my temporary apartment in the US, but I can't for the life of me recall what I did with them, so our first port of call was the Department of Transport in Zillmere to get a new licence. Talk about a painless experience. The most annoying thing was that on Wednesdays they open at 9:30am instead of 8:30am. We got there at 9:10am. I had Zoe with me, and Kristy had her daughter, and they happily played while we waited outside. I just had to fill out a fairly simple form, and I was called up promptly and there were no problems at all. In under 30 minutes of walking in the door, we were driving away with a temporary licence. Vastly different from my experience with the DMV. I'll get the genuine article in the mail in a few weeks. Then we headed over to Westfield Chermside to go to Medicare, Medibank Private, and as I was growing frustrated with how long my mobile phone number was taking to port from Telstra to Internode, a Telstra Shop to try and get a replacement Telstra SIM. This is where I ran into more of a bureaucratic brick wall. For Medicare, I wanted to get my own Medicare card (and number) again, instead of a shared one, and so I essentially had to re-apply. They wanted more than just a passport entry stamp and something with an address on it. They wanted specific documents with an address on it, and an offer letter to show I was employed, so I had to leave there empty handed. Medibank Private was even worse. In a "shut up and take my money!" kind of moment, they told me to prematurely unsuspend a suspended policy, I needed to request a document from the Department of Immigration that showed my international movements to confirm that I was indeed back in the country. I've always found this somewhat ironic, given I'm sitting in front of a Medibank Private employee when they're telling me this, and I'm trying to give them money. So I left there empty handed as well. I grabbed some cutlery and crockery from Big W. The Telstra Shop had a 45 minute wait, and as I didn't want to over-stretch Zoe, we headed back to my parents. I took the opportunity to open an electricity account with AGL, now that I had a driver's licence number. Zoe declined to take a nap, and was having a good time playing with Kristy's daughter, and they both wanted to stay at my parent's place, so we left them there and dashed over to Ikea to rectify the bed slat issue. While we were at Ikea, my number finally ported across and my phone started working, which was a huge relief. Being uncontactable during a period of many interactions with random people was highly frustrating for me. Not having mobile Internet access for a few days of extreme mobility showed how much my phone is an extension of my brain. I also picked up a bunch of other random stuff from Ikea, stools that hadn't been in stock the day before, drinking glasses, that sort of thing. We then dropped all that off at the apartment before heading back to my parents' place. So it was another busy day of running all over town, and again, I'm very grateful to Kristy for volunteering her time to make it happen. Most notable accomplishments: complete bed for Zoe, electricity, and a working mobile phone.

This was the first "normal" (i.e. not part of the Easter "long weekend") day. As it happened, Easter Monday was surprisingly retail-friendly anyway. My friend Kristy picked me up in the morning, and we dropped past the real estate agent for my apartment to see if the tenants had happened to drop the keys back yet (they hadn't) and then we went to Ikea and bought a bed for Zoe a bunch of other random stuff. I also bought a bed frame and mattress while we were at the neighbouring Logan MegaCentre (it's not a bad shopping centre) The bed frame is wooden and is taking 6-8 weeks to be made, so in the meantime, because I bought a mattress from them, they're lending me a mattress base. That's getting delivered on Saturday. We then headed over to Harvey Norman in Fortitude Valley. We'd just got started there when the real estate agent called to say the tenants had dropped the keys back, so we stopped and headed back over to meet the property manager at the apartment and get the keys. After that, we headed back to Harvey Norman and bought a fridge, TV, and a bunch of small appliances, and then headed back to the apartment to do some Ikea assembly. We'd just about finished putting Zoe's bed together when we discovered we'd gotten the wrong width slats for her bed. It turns out there are two widths of the "Sultan Lade" slats, and they're right next to each other in the warehouse. We'd picked up from the correct location, but I think the piles had become jumbled. Lesson learned: cross check the SKU as well as the pickup location. It was a long day, and I was enormously grateful to Kristy for driving me all over the place, and generally helping me shop. I think it ended up being a 15 hour day for her.

Given the recent discussions on planet.debian.org I use the opportunity to describe how you can handle upstream history in a git-dpm workflow. One of the primary points of git-dpm is that you should be able to just check out the Debian branch, get the .orig.tar file(s) (for example using pristine-tar, by git-dpm prepare or by just downloading them) and then calling dpkg-buildpackage. Thus the contents of the Debian branch need to be clean from dpkg-source's point of view, that is do not contain any files the .orig.tar file(s) contains not nor any modified files. The easy way The easiest way to get there is by importing the upstream tarball(s) as a git commit, which one will usually do with git-dpm import-new-upstream as that also does some of the bookkeeping. This new git commit will have (by default) the previous upstream commit and any parent you give with -p as parents. (i.e. with -p it will be a merge commit) and its content will be the contents of the tarball (with multiple orig files, it gets more complicated). The idea is of course that you give the upstream tag/commit belonging to this release tarball with -p so that it becomes part of your history and so git blame can find those commits. Thus you get a commit with the exact orig contents (so pristine-tar can more easily create small deltas) and the history combined.. Sometimes there are files in the upstream tarball that you do not want to have in your Debian branch (as you remove them in debian/rules clean), then when using this method you will have those files in the upstream branch but you delete them in the Debian branch. (This is why git-dpm merge-patched (the operation to merge a new branch with upstream + patches with your previous debian/ directory) will look which files relative to the previous upstream branch are deleted and delete them also in the newly merged branch by default). The complicated way There is only a way without importing the .orig.tar file(s), though that is a bit more complicated: The idea is that if your upstream's git repository contains all the files needed for building your Debian package (for example if you call autoreconf in your Debian package and clean all the generated files in the clean target, or if upstream has a less sophisticated release process and their .tar contains only stuff from the git repository), you can just use the upstream git commit as base for your Debian branch. Thus you can make upstream's commit/tag your upstream branch, by recording it with git-dpm new-upstream together with the .orig.tar it belongs to (Be careful, git-dpm does not check if that branch contains any files different than your .orig.tar and could not decide if it misses any files you need to build even if it tried to tell). Once that is merged with the debian/ directory to create the Debian branch, you run dpkg-buildpackage, which will call dpkg-source which compares your working directory with the contents of the .orig.tar with the patches applied. As it will only see files not there but no files modified or added (if everything was done correctly), one can work directly in the git checkout without needing to import the .orig.tar files at all (altough the pristine-tar deltas might get a bit bigger).

Seeing what has been posted recently in planet.d.o, I would like to share as well my thoughts and work-flow, and tell that I do agree with Joey Hess on many of his arguments. Especially when he tells that Debian fetishises upstream tarballs. We re in 2013, at the age of Internet, and more and more upstream authors are using Git, and more and more they don t care about releasing tarballs. I ve seen some upstream authors who simply stopped doing so completely, as a Git tag is really enough. I also fully agree than disk space and network speed isn t much of a problem these days. When there are tags available, I use the following debian/gbp.conf:

[DEFAULT]
upstream-branch = master
debian-branch = debian
upstream-tag = %(version)s
compression = xz
[git-buildpackage]
export-dir = ../build-area/

On many of my packages, I now just use Git tags from upstream if they are available. To make it more easy, I now nearly always use the following piece of code in my debian/rules files:

DEBVERS         ?= $(shell dpkg-parsechangelog   sed -n -e 's/^Version: //p')
VERSION         ?= $(shell echo '$(DEBVERS)'   sed -e 's/^[[:digit:]]*://' -e 's/[-].*//')
DEBFLAVOR       ?= $(shell dpkg-parsechangelog   grep -E ^Distribution:   cut -d" " -f2)
DEBPKGNAME      ?= $(shell dpkg-parsechangelog   grep -E ^Source:   cut -d" " -f2)
DEBIAN_BRANCH   ?= $(shell cat debian/gbp.conf   grep debian-branch   cut -d'=' -f2   awk ' print $1 ')
GIT_TAG         ?= $(shell echo '$(VERSION)'   sed -e 's/~/_/')
get-upstream-sources:
        git remote add upstream git://git.example.org/proj/foo.git   true
        git fetch upstream
        if ! git checkout master ; then \
                echo "No upstream branch: checking out" ; \
                git checkout -b master upstream/master ; \
        fi
        git checkout $(DEBIAN_BRANCH)
make-orig-file:
        if [ ! -f ../$(DEBPKGNAME)_$(VERSION).orig.tar.xz ] ; then \
                git archive --prefix=$(DEBPKGNAME)-$(GIT_TAG)/ $(GIT_TAG)   xz >../$(DEBPKGNAME)_$(VERSION).orig.tar.xz ; \
        fi
        [ ! -e ../build-area ] && mkdir ../build-area   true
        [ ! -e ../build-area/$(DEBPKGNAME)_$(VERSION).orig.tar.xz ] && cp ../$(DEBPKGNAME)_$(VERSION).orig.tar.xz ../build-area   true

Packaging a new upstream VERSION now means that I only have to edit the debian/changelog, do ./debian/rules get-upstream-source so that I get new commits and tags, then git merge -X theirs VERSION to import the changes, then finally invoke ./debian/rules make-orig-file to create the orig.tar.xz. My debian branch is now ready for git-buildpackage. Note that the sed with the GIT_TAG thing is there because unfortunately, Git doesn t support the ~ char in tags, and that most of the time, upstream do not use _ in version numbers. Let s say upstream is releasing version 1.2.3rc1, then I simply do git tag 1.2.3_rc1 1.2.3rc1 so that I have a new tag which points to the same commit as 1.2.3rc1, but that can be used for the Debian 1.2.3~rc1-1 release and the make-orig-file. All this might looks overkill at first, but in fact it is really convenient and efficient. Also, even though there is a master branch above, it isn t needed to build the package. Git is smarter than this, so even if you haven t checked out upstream master branch from the upstream remote, make-orig-file and git-buildpackage will simply continue to work. Which is cool, because this means you can store a single branch on Alioth (which is what I do).

Thanks to a generous donation by Bytemark Hosting, Debian started deploying machines for its core infrastructure services in a new data center in York, UK. This hardware and hosting donation will allow the Debian Systems Administration (DSA) team to distribute Debian's core services across a greater number of geographically diverse locations, and improve, in particular, the fault-tolerance and availability of end-user facing services. Additionally, the storage component of this donation will dramatically reduce the storage challenges that Debian currently faces. The hardware provided by Bytemark Hosting consists of a fully-populated HP C7000 BladeSystem chassis containing 16 server blades:

• 12 BL495cG5 blades with 2x Opteron 2347 and 64GB RAM each
• 4 BL465cG7 blades with 2x Opteron 6100 series and 128GB RAM each

and several HP Modular Storage Arrays:

• 3 MSA2012sa
• 6 MSA2000 expansion shelves

with 108 drive bays in total, mostly 500GB SATA drives, some 2TB, some 600GB 15kRPM SAS, providing a total of 57 TB. 57 TB today could host roughly 80 times the current Debian archive or 3 times the Debian Snapshot archive. But remember both archives are constantly growing!

Since there's a discussion of packaging software for Debian that uses Git upstream on Planet Debian right now, I wanted to weigh in and advocate for my current workflow for this situation, which I'm quite fond of. It's worth noting that I'm also upstream for quite a few of the packages I maintain, all in Git, and I use (almost) exactly the same structure for packaging my own software as for packaging anyone else's. So I have some experience with both sides of this. First off, I completely agree with Joey: if upstream is already using Git, there's no reason not to base the Debian packaging on the upstream repository, and many, many reasons to do so. One of the biggest advantages is that when repositories share a common basis and have been regularly merged, you can easily cherry-pick commits, which is wonderful for security releases and situations where you need a quick bug fix from an unreleased upstream branch. I make very heavy use of this when packaging OpenAFS. I do, however, like to base the Debian packaging on the released tarball, if for no other reason than that's the artifact that other people can more easily confirm. Yes, you can do the same thing with a Git tag, but the tarball is what upstream considers a release, so if one is available, I think it makes the most sense to base the packaging on it. I do this even for my own software. Thankfully, it's not that difficult to do both. Sam Hartman was the one who showed me this technique, and (after I used a manual script for some time for a couple of packages) Guido G nther incorporated the support into git-import-orig. The key idea is to still import the tarball into the upstream branch, but instead of making that import a simple commit, you make it a merge commit referencing the upstream release tag or commit from their Git repository. This means that you still get the exact contents of the release tarball on the upstream branch (and pristine-tar works as normal), but that branch is also based on the full upstream line of development. Therefore, so is your packaging branch (master or what have you) since you merge upstream into it. You can then charry-pick and take advantage of all of the normal Git features when following upstream development. This is dead simple to do with git-import-orig. Just add the upstream repository as a remote for your Git repository, make sure it's up to date with git fetch and you have the upstream tags, and then pass the flag --upstream-vcs-tag <tag> to git-import-orig whenever importing the upstream release tarball. git-import-orig will handle the construction of the merge commit for you and everything will just work, exactly like it normally does with git-buildpackage except with a more complete history. This support was added in git-buildpackage 0.6.0~git20120324, so it's available in unstable and testing. (I was going to update my notes on Debian packaging with Git to include this information before posting this, but I see that it will require some restructuring and quite a few changes to that document and I don't have time tonight. Hopefully soon.)

Today was spent at my apartment with Zoe. Harvey Norman were scheduled to deliver the fridge, washing machine and TV. Someone from Telstra was scheduled to come out and monkey with the MDF to get the naked ADSL happening, and my desk was scheduled to be delivered. My parents drove us over in the morning, with some of our suitcases. Zoe was very happy with her new room and bed. I was going to get a 1 hour advance warning of Harvey Norman coming, so we all went for a little walk around the neighbourhood to explore. It turns out there's a convenience store right next door, which is, well extremely convenient. I won't need to even hop in the car to get last minute bread or milk or anything like that. Very happy about that. There's also a really gorgeous little boutique deli/gourmet grocery that is easily within walking distance. The neighbourhood is indeed very nice. Mid-morning, Brent dropped around with his daughter to say hi. Zoe had a good time playing with her as well, and we went out for lunch at the Hawthorne Garage. At the end of lunch, Harvey Norman called to say they'd be an hour away, which was well timed. Zoe declined to nap again, so we just hung out waiting for the delivery. In the middle of them delivering, the desk delivery happened as well, and then as Brent was leaving, the Telstra guy turned up, so it all happened at once. I set up the TV and DVD player and Zoe happily christened it all by watching some Play School DVDs, and then my Dad came back and picked us up. So the apartment is now almost habitable. I just need my bed. That's scheduled for Saturday. I'm planning on sleeping there on Saturday night. In the furniture department, I'm still lacking a sofa, a dining table and something to put the TV on. Leah has volunteered to help me shop tomorrow, but I'm starting to think I should focus on resolving the lack of a car, then I can do any further shopping myself. Nick had set me up with a car wholesaler who was going to search for a used Subaru Forester for me, but so far he hasn't turned anything up, so I'm thinking I need to widen my net a little and use some other avenues as well. I'd really wanted for the car finding to be outsourced as much as possible so I could focus on other things, but it's not looking like that's going to be the case, and I really need mobility. I got a notification from Internode after I'd left today that the Internet should now be working, so I need to configure the ADSL router when I next get a chance and confirm that's the case, then I'm all sorted for being technologically able to work from home.

Puppet is a nice tool but it has a significant problem with passwords:

• it is recommended to store puppet manifests (*.pp) and related files in a VCS (i.e. git)
• it is not recommended to store password in a VCS

This lead to complex situation and various workaround that more or less work:

• serve password in a separate file/DB or do an extlookup on the master (pre-set passwords)
• store password on the server and get them through a generate function (random password but on the master)

Most of these workarounds are complex, don't allow you to share the password you have set easily and most of the time are stored in another place than the target node. So I have decided to create my own solution: sekred (LGPL-2.1). The idea of sekred is to generate the password on the target node and made it available to the user that needs it. Then the user just have to ssh into the host and get the password. Pro:

• the password is generated and stored on the node
• no VCS commit of your password
• no DB storage of your password beside the local filesystem of the host
• no need to use a common pre-set password for all you host, the password is randomly generated for only one host
• to steal the password you need to crack the host first but if you have root access on the host, accessing a random generated password is pointless

Cons:

• the password is stored in clear text
• the password is only protected by the filesystem ACL

Let see some concrete examples. Setting mysql root password This is a very simple problem. When you first install mysql on Debian Squeeze, the root password is not set. That's bad. Let set it using sekred and puppet.

node "mysqlserver"  
  package  
    ["mysql-server",
     "mysql-client",
     "sekred"]:
      ensure => installed;
   
  service  
    "mysqld":
      name => "mysql",
      ensure => running,
      hasrestart => true,
      hasstatus => true;
   
  exec  
    "mysql-set-root-password":
      command => "mysqladmin -u root password $(sekred get root@mysql)",
      onlyif => "mysql -u root",  # Trigger only if password-less root account.
      require => [Service["mysqld"], Package["mysql-client", "sekred"]];
   
 

And to get the root password for mysql, just login into the node "mysqlserver":

$> sekred get root@mysql
Cie8ieza

Setting password for SSH-only user This example is quite typical of the broken fully automated scenario with passwords: - you setup a remote host only accessible through SSH - you create a user and set its SSH public key to authorize access - your user cannot access its account because SSH prevent password-less account login! In other word, you need to login into the node, set a password for the user and mail him back.... That defeats a little bit the "automation" provided by puppet. Here is what I do with sekred:

define user::template ()  
  user  
    $name:
      ensure => present,
      membership => minimum,
      shell => "/bin/bash",
      ....
   
  include "ssh_keys::$name"
  # Check password less account and set one, if required.
  $user_passwd="$(sekred get --uid $name $name@login)"
  exec  
    "user-set-default-password-$name":
      command => "echo $name:$user_passwd   chpasswd",
      onlyif => "test \"$(getent shadow $name   cut -f2 -d:)\" = \"!\"",
      require => [User[$name], Package["sekred"]];
   
 

So the command "test \"$(getent shadow $name cut -f2 -d:)\" = \"!\"" test for a password-less account. If this is the case, it creates a password using sekred get --uid $name $name@login and set it through chpasswd. Note that $user_passwd use a shell expansion that will be evaluated when running the command only, on the host. The --uid flag of sekred assign the ownership of the password to the given user id. So now the user (foo) can login into the node and retrieve its password using sekred get foo@login. Try it! Sekred was a very short project but I am pretty happy with it. It solves a long standing problem and helps to cover an extra mile of automation when setting up new nodes. The homepage is here and you can download it here. Feel free to send patches, bugs and feature requests (here, login required).

A few weeks ago I taught a class on Open Source: Contributing to free culture (catalog entry) for Spark, a one-day program put on by the student-run MIT Educational Studies Program. I was fortunate to have two helpful co-teachers, Tyler Hallada and Jacob Hurwitz, who assisted with the lesson plan and the in class lecture.

We ended up teaching 3 sessions of the 1hr 50min class that Saturday, with about 10 students in each session.

I was pretty impressed by the quality of the students; a number of them had used GNU/Linux before, but even those who hadn't were able to gain something from the experience. The class was broken up into three segments:

1. Lecture on a brief history of open source and the free software movement
2. Small research project on an open source project
3. Lab where students could work through OpenHatch's training missions