As my previous post suggested I'd been running a service for a few years, using Redis as a key-value store. Redis is lovely. If your dataset will fit in RAM. Otherwise it dies hard. Inspired by Memcached, which is a simple key=value store, redis allows for more operations: using sets, using hashes, etc, etc. As it transpires I mostly set keys to values, so it crossed my mind last night an alternative to rewriting the service to use a non-RAM-constrained service might be to juggle redis out and replace it with something else. If it were possible to have a redis-compatible API which secretly stored the data in leveldb, sqlite, or even Berkley DB, then that would solve my problem of RAM-constraints, and also be useful. Looking around there are a few projects in this area nds fork of redis, ssdb, etc. I was hoping to find a Perl Redis::Server module, but sadly nothing exists. I should look at the various node.js stub-servers which exist as they might be easy to hack too. Anyway the short version is that this might be a way forward, the real solution might be to use sqlite or postgres, but that would take a few days work. For the moment the service has been moved to a donated guest and has 2Gb of RAM instead of the paltry 512Mb it was running on previously. Happily the server is installed/maintained by my slaughter tool so reinstalling took about ten minutes - the only hard part was migrating the Redis-contents, and that's trivial thanks to the integrated "slave of" support. (I should write that up regardless though.)

Sociological Images has an interesting post by Jay Livingston PhD about a tennis final as a ritual [1]. The main point is that you can get a much better view of the match on your TV at home with more comfort and less inconvenience, so what you get for the price of the ticket (and all the effort of getting there) is participating in the event as a spectator. It seems to me that the same idea applies to community Linux conferences (such as LCA) and some Linux users group meetings. In terms of watching a lecture there are real benefits to downloading it after the conference so that you can pause it and study related web sites or repeat sections that you didn t understand. Also wherever you might sit at home to watch a video of a conference lecture you will be a lot more comfortable than a university lecture hall. Some people don t attend conferences and users group meetings because they would rather watch a video at home. Benefits of Attending (Apart from a Ritual) One of the benefits of attending a lecture is the ability to ask questions. But that seems to mostly apply to the high status people who ask most questions. I ve previously written about speaking stacks and my observations about who asks questions vs the number that can reasonably be asked [2]. I expect that most delegates ask no questions for the entire conference. I created a SurveyMonkey survey to discover how many questions people ask [3]. I count LCA as a 3 day conference because I am only counting the days where there are presentations that have been directly approved by the papers committee, approving a mini-conf (and thus delegating the ability to approve speeches) is different. Another benefit of attending is the so-called hallway track where people talk to random other people. But that seems to be of most benefit to people who have some combination of high status in the community and good social skills. In the past I ve attended the Professional Delegates Networking Session which is an event for speakers and people who pay the Professional registration fee. Sometimes at such events there has seemed to be a great divide between speakers (who mostly knew each other before the conference) and Professional Delegates which diminishes the value of the event to anyone who couldn t achieve similar benefits without it. How to Optimise a Conference as a Ritual To get involvement of people who have the ritualistic approach one could emphasise the issue of being part of the event. For example to get people to attend the morning keynote speeches (which are sometimes poorly attended due to partying the night before) one could emphasise that anyone who doesn t attend the keynote isn t really attending the conference. Conference shirts seem to be strongly correlated with the ritual aspect of conferences, the more corporate conferences don t seem to offer branded clothing to delegates. If an item of branded schwag was given out before each keynote then that would increase the attendance by everyone who follows the ritual aspect (as well as everyone who just likes free stuff). Note that I m not suggesting that organisers of LCA or other conferences go to the effort of giving everyone schwag before the morning keynote, that would be a lot of work. Just telling people that anyone who misses the keynote isn t really attending the conference would probably do. I ve always wondered why conference organisers want people to attend the keynotes and award prizes to random delegates who attend them. Is a keynote lecture a ritual that is incomplete if the attendance isn t good enough?

• [1] http://tinyurl.com/m74pc95
• [2] http://etbe.coker.com.au/2013/02/01/speaking-stacks/
• [3] https://www.surveymonkey.com/s/RZ958TJ

I recently had a medical appointment cancelled due to a computer crash . Apparently the reception computer crashed and lost all bookings for a day and they just made new bookings for whoever called and anyone who had a previous booking just missed out. I ll probably never know whether they really had a computer problem or just used computer problems as an excuse when they made a mistake. But even if it wasn t a real computer problem the fact that computers are so unreliable overall that computer crash is an acceptable excuse indicates a problem with the industry. The problem of unreliable computers is a cost to everyone, it s effectively a tax on all business and social interactions that involve computers. While I spent the extra money on a server with ECC RAM for my home file storage I have no control over the computers purchased by all the companies I deal with which are mostly the cheapest available computers. I also have no option to buy a laptop with ECC RAM because companies like Lenovo have decided not to manufacture them. It seems to me that the easiest way of increasing overall reliability of computers would be to use ECC RAM everywhere. In the early 90 s all IBM compatible PCs had parity RAM, that meant that for each byte there was one extra bit which would report 100% of single-bit errors and 50% of errors that involved random memory corruption. Then manufacturers decided to save a tiny amount of money on memory by using 8/9 the number of chips for desktop/laptop systems and probably make more money on selling servers with ECC RAM. If the government was to impose a 20% tax on computers that lack ECC RAM then manufacturers would immediately start using it everywhere and the end result would be no price increase overall as it s cheaper to design desktop systems and servers with the same motherboards apparently some desktop systems have motherboard support for ECC RAM but don t ship with suitable RAM or advertise the support for such RAM. This principle applies to many other products too. One obvious example is cars, a car manufacturer can sell cheap cars with few safety features and then when occupants of those cars and other road users are injured the government ends up paying for medical expenses and disability pensions. If there was a tax for every car that has a poor crash test rating and a tax for every car company that performs badly in real world use then it would give car companies some incentive to manufacture safer vehicles. Now there are situations where design considerations preclude such features. For example implementing ECC RAM in mobile phones might involve technical difficulties (particularly for 32bit phones) and making some trucks and farm equipment safer might be difficult. But when a company produces multiple similar products that differ significantly in quality such as PCs with and without ECC RAM or cars with and without air-bags there would be no difficulty in making them all of them higher quality. I don t think that we will have a government that implements such ideas any time soon, it seems that our government is more interested in giving money to corporations than taxing them. But one thing that could be done is to adopt a policy of only giving money to companies if they produce high quality products. If a car company is to be given hundreds of millions of dollars for not closing a factory then that factory should produce cars with all possible safety features. If a computer company is going to be given significant tax breaks for doing R&D then they should be developing products that won t crash.

When writing libraries with CMake, you need to set a couple of properties, especially the VERSION and SOVERSION properties. For library libbar, it could look like:

set_property(TARGET bar PROPERTY VERSION 0.0.0 )
set_property(TARGET bar PROPERTY SOVERSION 0 )

This will give you a libbar.so => libbar.so.0 => libbar.so.0.0.0 symlink chain with a SONAME of libbar.so.0 encoded into the library. The SOVERSION target property controls the number in the middle part of the symlink chain as well as the numeric part of the SONAME encoded into the library. The VERSION target property controls the last part of the last element of the symlink chain This also means that the first part of VERSION should match what you put in SOVERSION to avoid surprises for others and for the future you. Both these properties control Technical parts and should be looked at from a technical perspective. They should not be used for the version of the software , but purely for the technical versioning of the library. In the kdeexamples git repository, it is handled like this:

set(BAR_VERSION_MAJOR 1)
set(BAR_VERSION_MINOR 2)
set(BAR_VERSION_PATCH 3)
set(BAR_VERSION $ BAR_VERSION_MAJOR .$ BAR_VERSION_MINOR .$ BAR_VERSION_PATCH )

And a bit later:

set_target_properties(bar PROPERTIES VERSION $ BAR_VERSION
SOVERSION $ BAR_VERSION_MAJOR )

which is a fine way to ensure that things actually matches. Oh. And these components is not something that should be inherited from other external projects. So people, please be careful to use these correct.

I put out the call for nominations for the 2014 Software in the Public Interest (SPI) Board election last week. At this point I haven't yet received any nominations, so I'm mentioning it here in the hope of a slightly wider audience. Possibly not the most helpful as I would hope readers who are interested in SPI are already reading spi-announce. There are 3 positions open this election and it would be good to see a bit more diversity in candidates this year. Nominations are open until the end of Tuesday July 13th. The primary hard and fast time commitment a board member needs to make is to attend the monthly IRC board meetings, which are conducted publicly via IRC (#spi on the OFTC network). These take place at 20:00 UTC on the second Thursday of every month. More details, including all past agendas and minutes, can be found at http://spi-inc.org/meetings/. Most of the rest of the board communication is carried out via various mailing lists. The ideal candidate will have an existing involvement in the Free and Open Source community, though this need not be with a project affiliated with SPI. Software in the Public Interest (SPI, http://www.spi-inc.org/) is a non-profit organization which was founded to help organizations develop and distribute open hardware and software. We see it as our role to handle things like holding domain names and/or trademarks, and processing donations for free and open source projects, allowing them to concentrate on actual development. Examples of projects that SPI helps includes Debian, LibreOffice, OFTC and PostgreSQL. A full list can be found at http://www.spi-inc.org/projects/.

It seems to be a great time for monitoring solutions. Some of you may have noticed that Icinga has released it's first stable version of the completely redeveloped Icinga 2. After several changes in the recent past, where the Team maintaining the Plugins used for several Monitoring solutions was busy moving everything to new infrastructure, they are now back on track. The recent development milestone is reached and a call for testing was also sent out. In the meanwhile I prepared the packaging for this bigger move. The packages are now moved to the source package monitoring-plugins, the whole packaging changes can be observed in the changelog. With this new release we have also some NEWS, which might be useful to check. Same counts for upstream NEWS. You can give the packages a go and grab them from my 'unstable' and 'wheezy-backports' repositories at http://ftp.cyconet.org/debian/. Right after the stable release, the packages will be uploaded into debian unstable, but might get delayed by the NEW queue due the new package names.

Back in March, I uploaded a Debian s version of lcdproc with a unique feature: user and maintainer configurations are merged during package upgrade: user customizations and developers enhancements are both preserved in the new configuration file. (See this blog for more details). This avoids tedious edition of the configuration LCDd.conf file after every upgrade of lcdproc package. At the beginning of June, a new version of lcdproc (0.5.7-1) was uploaded. This triggered another round of automatic upgrades on user s systems. According to the popcon rise of libconfig-model-lcdproc-perl, about 100 people have upgraded lcdproc on their system. Since automatic upgrade has an opt-out feature, one cannot say for sure that 100 people are actually using automatic upgrade, but I bet a fair portion are them are. So far, only one people has complained: a bug report was filed about the many dependencies brought by libconfig-model-lcdproc-perl. The next challenge for lcdproc configuration upgrade is brought by a bug reported on Ubuntu: the device file provided by imon kernel module is a moving target: The device file created by the kernel can be /dev/lcd0 or /dev/lcd1 or even /dev/lcd2. Static configuration files and moving target don t mix well. The obvious solution is to provide a udev rule so that a symbolic link is created from a fixed location (/dev/lcd-imon) to the moving target. Once the udev rule is installed, the user only has to update LCDd.conf file to use the symlink as imon device file and we re done. But, wait The whole point of automatic configuration upgrade is to spare the user this kind of trouble: the upgrade must be completely automatic. Moreover, the upgrade must work in all cases: whether udev is available (Linux) or not. If udev is not available, the value present in the configuration file must be preserved. To know whether udev is available, the upgrade tool (aka cme) will check whether the file provided by udev (/dev/lcd-imon) is present or not. This will be done by lcdproc postinst script (which is run automatically at the end of lcdproc upgrade). Which means that the new udev rule must also be
activated in the postinst script before the upgrade is done. In other words, the next version of lcdproc (0.5.7-2) will:

• Install a new udev rule to provide lcd-imon symbolic link
• Activate this rule in lcdproc postinst script before upgrading the configuration (note to udev experts: yes, the udev rule is activated with --action=change option)
• Upgrade the configuration by running cme migrate in lcdproc postinst script.

In the lcdproc configuration model installed by libconfig-model-lcdproc-perl, the imon device parameter is enhanced so that running cme check lcdproc or cme migrate lcdproc issues a warning if /dev/lcd-imon exists and if imon driver is not configured to use it. This way, the next installation of lcdproc will deliver a fix for imon and cme will fix user s configuration file without requiring user input. The last point is admittedly bad marketing as users will not be aware of the magic performed by Config::Model Oh well In the previous section, I ve briefly mentioned that imon_device parameter is enhanced in lcdproc configuration model. If you re not already bored, let s lift the hood and see what kind of enhancements was added. Let s peek in lcdproc configuration file, LCDd.conf file which is used to generate lcdproc configuration model. You may remember that the formal description of all LCDd.conf parameters and their properties is generated from LCDd.conf to provide lcdproc configuration model. The comments in LCDd.conf follow a convention so that most properties of the parameters can be extracted from the comments. In the example below, the comments show that NewFirmware is a boolean value expressed as yes or no, the latter being the default :

# Set the firmware version (New means >= 2.0) [default: no; legal: yes, no]
NewFirmware=no

Back to the moving target. In LCDd.conf, imon device file parameter is declared this way:

# Select the output device to use
Device=/dev/lcd0

This means that device is a string where the default value is /dev/lcd0. Which is wrong once the special udev rule provided with Debian packages is activated. With this rule, the default value must be /dev/lcd-imon. To fix this problem, a special comment is added in the Debian version of LCDd.conf to tune further the properties of the device parameter:

# select the device to use
#  %
#   default~
#   compute
#     use_eval=1
#     formula="my $l = '/dev/lcd-imon'; -e $l ? $l : '/dev/lcd0';"
#     allow_override=1 -
#   warn_if:not_lcd_imon
#     code="my $l = '/dev/lcd-imon';defined $_ and -e $l and $_ ne $l ;"
#     msg="imon device does not use /dev/lcd-imon link."
#     fix="$_ = undef;"
#   warn_unless:found_device_file
#     code="defined $_ ? -e : 1"
#     msg="missing imon device file"
#     fix="$_ = undef;"
#   - % 
Device=/dev/lcd0

This special comment between % and % follows the syntax of Config::Model::Loader. A small configuration model is declared there to enhance the model generated from LCDd.conf file. Here are the main parts:

• default~ suppress the default value of the device parameter declared in the original LCDd.conf (i.e. /dev/ldcd0 )
• compute and the 3 lines below computes a default value for the device file. Since use_eval is true, the formula is evaluated as Perl code. This code will return /dev/lcd-imon if this file is found. Otherwise, /dev/lcd0 is returned. Hence, either /dev/lcd-imon or /dev/lcd0 will be used a as default value. allow_override=1 lets the user override this computed value
• warn_if and the 3 lines below test the configured device file with the Perl instructions provided by the code parameter. There, the device value is available in the $_ variable. This code will return true if /dev/lcd-imon exists and if the configured device does not use it. This will trigger a warning that will show the specified message.
• Similarly warn_unless and the 3 lines below warns the user if the configured device file is not found.

In both warn_unless and warn_if parts, the fix code snippet is run when by the command cme fix lcdproc and is used to repair the warning condition. In this case, the fix consists in resetting the device configuration value so the computed value above can be used. cme fix lcdproc is triggered during package post install script installed by dh_cme_upgrade. Come to think of it, generating a configuration model from a configuration file can probably be applied to other projects: for instance, php.ini and kdmrc are also shipped with detailed comments. May be I should make a more generic model generator from the example used to generate lcdproc model Well, I will do it if people show interest. Not in the form yeah, that would be cool , but in the form, yes, I will use your work to generate a configuration model for project [...] . I ll let you fill the blank ;-)
Tagged: Config::Model, configuration, debian, lcdproc, Perl, upgrade

For my local backup regimen I use flexbackup to create a full backup twice a year and differential/incremental backups on a weekly/monthly basis. I then upload these to a new amazon S3 bucket for each half year (so each bucket corresponds to the a full backup plus the associated differentials and incrementals). I then set the bucket's lifecycle to archive to glacier (cheaper offline storage) from the month after that half year has ended (reducing costs) and to delete it a year after the half ends. It used to be possible to do this via the S3 web interface but the absolute date based options seem to have been removed in favour of time since last update, which is not what I want. However the UI will still display such lifecycles if they are configured and directs you to the REST API to set them up. I had a look around but couldn't any existing CLI tools to do this directly but I figured it must be possible with curl. A little bit of reading later I found that it was possible but it involved some faff calculating signatures etc. Luckily EricW has written Amazon S3 Authentication Tool for Curl (AKA s3curl) which automates the majority of that faff. The tool is "New BSD" licensed according to that page or Apache 2.0 license according to the included LICENSE file and code comments. Setup Following the included README setup ~/.s3curl containing your id and secret key (I called mine personal which I then use below). Getting the existing lifecycle Retrieving an existing lifecycle is pretty easy. For the bucket which I used for the first half of 2014:

$ s3curl --id=personal -- --silent http://$bucket.s3.amazonaws.com/?lifecycle   xmllint --format -
<?xml version="1.0" encoding="UTF-8"?>
<LifecycleConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
  <Rule>
    <ID>Archive and Expire</ID>
    <Prefix/>
    <Status>Enabled</Status>
    <Transition>
      <Date>2014-07-31T00:00:00.000Z</Date>
      <StorageClass>GLACIER</StorageClass>
    </Transition>
    <Expiration>
      <Date>2015-01-31T00:00:00.000Z</Date>
    </Expiration>
  </Rule>
</LifecycleConfiguration>

See GET Bucket Lifecycle for details of the XML. Setting a new lifecycle The desired configuration needs to be written to a file. For example to set the lifecycle for the bucket I'm going to use for the second half of 2014:

$ cat s3.lifecycle
<LifecycleConfiguration>
  <Rule>
    <ID>Archive and Expire</ID>
    <Prefix/>
    <Status>Enabled</Status>
    <Transition>
      <Date>2015-01-31T00:00:00.000Z</Date>
      <StorageClass>GLACIER</StorageClass>
    </Transition>
    <Expiration>
      <Date>2015-07-31T00:00:00.000Z</Date>
    </Expiration>
  </Rule>
</LifecycleConfiguration>
$ s3curl --id=personal --put s3.lifecycle --calculateContentMd5 -- http://$bucket.s3.amazonaws.com/?lifecycle

See PUT Bucket Lifecycle for details of the XML.

When I first started using computers a word processor was a program that edited text. The most common and affordable printers were dot-matrix and people who wanted good quality printing used daisy wheel printers. Text from a word processor was sent to a printer a letter at a time. The options for fancy printing were bold and italic (for dot-matrix), underlines, and the use of spaces to justify text. It really wasn t much good if you wanted to include pictures, graphs, or tables. But if you just wanted to write some text it worked really well. When you were editing text it was typical that the entire screen (25 rows of 80 columns) would be filled with the text you were writing. Some word processors used 2 or 3 lines at the top or bottom of the screen to display status information. Some time after that desktop publishing (DTP) programs became available. Initially most people had no interest in them because of the lack of suitable printers, the early LASER printers were very expensive and the graphics mode of dot matrix printers was slow to print and gave fairly low quality. Printing graphics on a cheap dot matrix printer using the thin continuous paper usually resulted in damaging the paper a bad result that wasn t worth the effort. When LASER and Inkjet printers started to become common word processing programs started getting many more features and basically took over from desktop publishing programs. This made them slower and more cumbersome to use. For example Star Office/OpenOffice/LibreOffice has distinguished itself by remaining equally slow as it transitioned from running on an OS/2 system with 16M of RAM in the early 90 s to a Linux system with 256M of RAM in the late 90 s to a Linux system with 1G of RAM in more recent times. It s nice that with the development of PCs that have AMD64 CPUs and 4G+ of RAM we have finally managed to increase PC power faster than LibreOffice can consume it. But it would be nicer if they could optimise for the common cases. LibreOffice isn t the only culprit, it seems that every word processor that has been in continual development for that period of time has had the same feature bloat. The DTP features that made word processing programs so much slower also required more menus to control them. So instead of just having text on the screen with maybe a couple of lines for status we have a menu bar at the top followed by a couple of lines of toolbars , then a line showing how much width of the screen is used for margins. At the bottom of the screen there s a search bar and a status bar. Screen Layout By definition the operation of a DTP program will be based around the size of the paper to be used. The default for this is A4 (or Letter in the US) in a portrait layout (higher than it is wide). The cheapest (and therefore most common) monitors in use are designed for displaying wide-screen 16:9 ratio movies. So we have images of A4 paper with a width:height ratio of 0.707:1 displayed on a wide-screen monitor with a 1.777:1 ratio. This means that only about 40% of the screen space would be used if you don t zoom in (but if you zoom in then you can t see many rows of text on the screen). One of the stupid ways this is used is by companies that send around word processing documents when plain text files would do, so everyone who reads the document uses a small portion of the screen space and a large portion of the email bandwidth. Note that this problem of wasted screen space isn t specific to DTP programs. When I use the Google Keep website [1] to edit notes on my PC they take up a small fraction of the screen space (about 1/3 screen width and 80% screen height) for no good reason. Keep displays about 70 characters per line and 36 lines per page. Really every program that allows editing moderate amounts of text should allow more than 80 characters per line if the screen is large enough and as many lines as fit on the screen. One way to alleviate the screen waste on DTP programs is to use a landscape layout for the paper. This is something that all modern printers support (AFAIK the only printers you can buy nowadays are LASER and ink-jet and it s just a big image that gets sent to the printer). I tried to do this with LibreOffice but couldn t figure out how. I m sure that someone will comment and tell me I m stupid for missing it, but I think that when someone with my experience of computers can t easily figure out how to perform what should be a simple task then it s unreasonably difficult for the vast majority of computer users who just want to print a document. When trying to work out how to use landscape layout in LibreOffice I discovered the Web Layout option in the View menu which allows all the screen space to be used for text (apart from the menu bar, tool bars, etc). That also means that there are no page breaks! That means I can use LibreOffice to just write text, take advantage of the spelling and grammar correcting features, and only have screen space wasted by the tool bars and menus etc. I never worked out how to get Google Docs to use a landscape document or a single webpage view. That s especially disappointing given that the proportion of documents that are printed from Google Docs is probably much lower than most word processing or DTP programs. What I Want What I d like to have is a word processing program that s suitable for writing draft blog posts and magazine articles. For blog posts most of the formatting is done by the blog software and for magazine articles the editorial policy demands plain text in most situations, so there s no possible benefit of DTP features. The ability to edit a document on an Android phone and on a Linux PC is a good feature. While the size of a phone screen limits what can be done it does allow jotting down ideas and correcting mistakes. I previously wrote about using Google Keep on a phone for lecture notes [2]. It seems that the practical ability of Keep to edit notes on a PC is about limited to the notes for a 45 minute lecture. So while Keep works well for that task it won t do well for anything bigger unless Google make some changes. Google Docs is quite good for editing medium size documents on a phone if you use the Android app. Given the limitations of the device size and input capabilities it works really well. But it s not much good for use on a PC. I ve seen a positive review of One Note from Microsoft [3]. But apart from the fact that it s from Microsoft (with all the issues that involves) there s the issue of requiring another account. Using an Android phone requires a Gmail account (in practice for almost all possible uses if not in theory) so there s no need to get an extra account for Google Keep or Docs. What would be ideal is an Android editor that could talk to a cloud service that I run (maybe using WebDAV) and which could use the same data as a Linux-X11 application. Any suggestions?

• [1] http://keep.google.com/
• [2] http://etbe.coker.com.au/2014/04/19/phone-based-lectures/
• [3] http://www.onenote.com/

After dealing with the client side of the DNSSEC puzzle last week, I thought it behooved me to also go about getting DNSSEC going on the domains I run DNS for. Like the resolver configuration, the server side work is straightforward enough once you know how, but boy howdy are there some landmines to be aware of. One thing that made my job a little less ordinary is that I use and love tinydns. It s an amazingly small and simple authoritative DNS server, strong in the Unix tradition of do one thing and do it well . Unfortunately, DNSSEC is anything but small and simple and so tinydns doesn t support DNSSEC out of the box. However, Peter Conrad has produced a patch for tinydns to do DNSSEC, and that does the trick very nicely. A brief aside about tinydns and DNSSEC, if I may Poor key security is probably the single biggest compromise vector for crypto. So you want to keep your keys secure. A great way to keep keys secure is to not put them on machines that run public-facing network services (like DNS servers). So, you want to keep your keys away from your public DNS servers. A really great way of doing that would be to have all of your DNS records somewhere out of the way, and when they change regenerate the zone file, re-sign it, and push it out to all your DNS servers. That happens to be exactly how tinydns works. I happen to think that tinydns fits very nicely into a DNSSEC-enabled world. Anyway, back to the story. Once I d patched the tinydns source and built updated packages, it was time to start DNSSEC-enabling zones. This breaks down into a few simple steps:

1. Generate a key for each zone. This will produce a private key (which, as the name suggests, you should keep to yourself), a public key in a DNSKEY DNS record, and a DS DNS record. More on those in a minute. One thing to be wary of, if you re like me and don t want or need separate Key Signing and Zone Signing keys. You must generate a Key Signing key this is a key with a flags value of 257. Doing this wrong will result in all sorts of odd-ball problems. I wanted to just sign zones, so I generated a Zone Signing key, which has a flags value of 256. Big mistake. Also, the DS record is a hash of everything in the DNSKEY record, so don t just think you can change the 256 to a 257 and everything will still work. It won t.
2. Add the key records to the zone data. For tinydns, this is just a matter of copying the zone records from the generated key into the zone file itself, and adding an extra pseudo record (it s all covered in the tinydnssec howto).
3. Publish the zone data. Reload your BIND config, run tinydns-sign and tinydns-data then rsync, or do whatever it is PowerDNS people do (kick the database until replication starts working again?).
4. Test everything. I found the Verisign Labs DNSSEC Debugger to be very helpful. You want ticks everywhere except for where it s looking for DS records for your zone in the higher-level zone. If there are any other freak-outs, you ll want to fix those because broken DNSSEC will take your domain off the Internet in no time.
5. Tell the world about your DNSSEC keys. This is simply a matter of giving your DS record to your domain registrar, for them to add it to the zone data for your domain s parent. Wherever you d normally go to edit the nameservers or contact details for your domain, you probably want to do to the same place and look for something about DS or Domain Signer records. Copy and paste the details from the DS record in your zone into there, submit, and wait a minute or two for the records to get published.
6. Test again. Before you pat yourself on the back, make sure you ve got a full board of green ticks in the DNSSEC Debugger. if anything s wrong, you want to rollback immediately, because broken DNSSEC means that anyone using a DNSSEC-enabled resolver just lost the ability to see your domain.

That s it! There s a lot of complicated crypto going on behind the scenes, and DNSSEC seems to revel in the number of acronyms and concepts that it introduces, but the actual execution of DNSSEC-enabling your domains is quite straightforward.

In short: I love my MacBook Air. It is the best (laptop) hardware I ever owned. I have seen hardware which was much more flaky in the past. I can set the display backlight to zero via software, which saves me a lot of battery life and also offers a bit of anti-spy-acroos-my-shoulder support. WLAN and bluetooth work nicely. And I just love the form-factor and the touch-feeling of the hardware. I even had the bag I use to carry my braille display modified so that the Air just fits in. I can't say how it behaves with X11. Given how flaky accessibility with graphical desktops on Linux is, I have still not made the switch. My MacBookAir is my perfect mobile terminal, I LOVE it. I am sort of surprised about the recent rant of Paul about MacBook Hardware. It is rather funny that we perceive the same technology so radically different. And after reading the second part of his rant I am wondering if I am no longer allowed to consider myself part of the "hardcore F/OSS world", because I don't consider Apple as evil as apparently most others. Why? Well, first of all, I actually like the hardware. Secondly, you have to show me a vendor first that builds usable accessibility into their products, and I mean all their products, without any extra price-tag attached. Once the others start to consider people with disabilities, we can talk about apple-bashing again. But until then, sorry, you don't see the picture as I do. Apple was the first big company on the market to take accessibility seriously. And they are still unbeaten, at least when it comes to bells and whistles included. I can unbox and configure any Apple product sold currently completely without assisstance. With some products, you just need to know a signle keypress (tripple-press the home button for touch devices and Cmd+F5 for Mac OS/X), and with others, during initial bootup, a speech synthesizer even tells you how to enable accessibility in case you need it. And after that is enabled, I can perform the setup of the device completely on my own. I don't need help from anyone else. And after the setup is complete, I can use 95% of the functionality provided by the operating system. And I am blind, part of a very small margin group so to speak. In Debian circles, I have even heard the sentiment that we supposedly have to accept that small margin groups are ignored sometimes. Well, as long as we think that way, as long as we strictly think economically, we will never be able to go there, fully. And we will never be the universal operating system, actually. Sorry to say that, but I think there is some truth to it. So, who is evil? Scratch your own itch doesn't always work to cover everything. How do we motivate contributors to work on things they don't personally need (yet)? How can we ensure that complicated but seldomly used features stay stable and do not fall to dust just because some upstream decides to rewrite an essential subcomponent of the dependency tree? I don't know. All I know is that these issues need to be solved in an universal operating system.

The security model on the Google Nexus devices is pretty straightforward. The OS is (nominally) secure and prevents anything from accessing the raw MTD devices. The bootloader will only allow the user to write to partitions if it's unlocked. The recovery image will only permit you to install images that are signed with a trusted key. In combination, these facts mean that it's impossible for an attacker to modify the OS image without unlocking the bootloader[1], and unlocking the bootloader wipes all your data. You'll probably notice that.

The problem comes when you want to run something other than the stock Google images. Step number one for basically all of these is "Unlock your bootloader", which is fair enough. Step number two is "Install a new recovery image", which is also reasonable in that the key database is stored in the recovery image and so there's no way to update it without doing so. Except, unfortunately, basically every third party Android image is either unsigned or is signed with the (publicly available) Android test keys, so this new recovery image will flash anything. Feel free to relock your bootloader - the recovery image will still happily overwrite your OS.

This is unfortunate. Even if you've encrypted your phone, anyone with physical access can simply reboot into recovery and reflash /system with something that'll stash your encryption key and mail your data to the NSA. Surely there's a better way of doing this?

Thankfully, there is. Kind of. It's annoying and involves a bunch of manual processes and you'll need to re-sign every update yourself. But it is possible to configure Nexus devices in such a way that you retain the same level of security you had when you were using the Google keys without losing the freedom to run whatever you want. Here's how.

Note: This is not straightforward. If you're not an experienced developer, you shouldn't attempt this. I'm documenting this so people can create more user-friendly approaches.

First: Unlock your bootloader. /data will be wiped.
Second: Get a copy of the stock recovery.img for your device. You can get it from the factory images available here
Third: Grab mkbootimg from here and build it. Run unpackbootimg against recovery.img.
Fourth: Generate some keys. Get this script and run it.
Fifth: zcat recovery.img-ramdisk.gz cpio -id to extract your recovery image ramdisk. Do this in an otherwise empty directory.
Sixth: Get DumpPublicKey.java from here and run it against the .x509.pem file generated in step 4. Replace /res/keys from the recover image ramdisk with the output. Include the "v2" bit at the beginning.
Seventh: Repack the ramdisk image (find . cpio -o -H newc gzip > ../recovery.img-ramdisk.gz) and rebuild recovery.img with mkbootimg.
Eighth: Write the new recovery image to your device
Ninth: Get signapk from here and build it. Run it against the ROM you want to sign, using the keys you generated earlier. Make sure you use the -w option to sign the whole zip rather than signing individual files.
Tenth: Relock your bootloader
Eleventh: Boot into recovery mode and sideload your newly signed image.

At this point you'll want to set a reasonable security policy on the image (eg, if it grants root access, ensure that it requires a PIN or something), but otherwise you're set - the recovery image can't be overwritten without unlocking the bootloader and wiping all your data, and the recovery image will only write images that are signed with your key. For obvious reasons, keep the key safe.

This, well. It's obviously an excessively convoluted workflow. A *lot* of it could be avoided by providing a standardised mechanism for key management. One approach would be to add a new fastboot command for modifying the key database, and only permit this to be run when the bootloader is unlocked. The workflow would then be something like

• Unlock bootloader
• Generate keys
• Install new key
• Lock bootloader
• Sign image
• Install image

which seems more straightforward. Long term, individual projects could do the signing themselves and distribute their public keys, resulting in the install process becoming as easy as

• Unlock bootloader
• Install ROM key
• Lock bootloader
• Install ROM

which is actually easier than the current requirement to install an entirely new recovery image.

I'd actually previously criticised Google on the grounds that using custom keys wasn't possible on Android devices. I was wrong. It is, it's just that (as far as I can tell) nobody's actually documented it before. It's important that users not be forced into treating security and freedom as mutually exclusive, and it's great that Google have made that possible.

[1] This model fails if it's possible to gain root on the device. Thankfully this would never hold on what's that over there is that a distraction?

comments

A few interesting things happened after I got a macbook air.

Firstly, I got a lot of shit from my peers and friends about it. This was funny to me, nothing really bothered me about it, but I can see this becoming really tiresome at events like hackathons or conferences.

As a byproduct, there s a strong feeling in the hardcore F/OSS world that Apple hardware is the incarnation of evil.

As a result of both of the above, hardcore F/OSS (and Distro hackers) don t buy apple hardware.

Therefore, GNU/Linux is complete garbage on Apple hardware. Apple s firmware bugs don t help, but we re BAD.

Some might ask why this is a big deal. The fact is, this is one of the most used platforms for Open Source development (note I used that term exactly).

Are we to damn these users to a nonfree OS because we want to maintain our purity?

I had to give back my Air, but I still have a Mac Mini that i ve been using for testing bugs on OSX in code I have. Very soon, my Mac Mini will be used to help fix the common bugs in the install process.

Some things you can do:

• Consider not giving off an attitude to people with Apple hardware. Be welcoming.
• Consider helping with supporting your favorate distro on Apple hardware. Props to Fedora for doing such a great job, in particular, mjg59 and Peter Jones for all they do with it.
• Help me make Debian Apple installs one-click.

This is my monthly summary of my free software related activities. If you re among the people who made a donation to support my work (168.17 , thanks everybody!), then you can learn how I spent your money. Otherwise it s just an interesting status update on my various projects. Debian LTS After having put in place the infrastructure to allow companies to contribute financially to Debian LTS, I spent quite some time to draft the announce of the launch of Debian LTS (on a suggestion of Moritz M hlenhoff who pointed out to me that there was no such announce yet). I m pretty happy about the result because we managed to mention a commercial offer without generating any pushback from the community. The offer is (in my necessarily biased opinion) clearly in the interest of Debian but still the money doesn t go to Debian so we took extra precautions. When I got in touch with the press officers, I included the Debian leader in the discussion and his feedback has been very helpful to improve the announce. He also officially acked the press release to give some confidence to the press officers that they were doing the right thing. Lucas also pushed me to seek public review of the draft press release, which I did. The discussion was constructive and the draft got further improved. The news got widely relayed, but on the flip side, the part with the call for help got almost no attention from the press. Even Linux Weekly News skipped it! On the Freexian side, we just crossed 10% of a full-time position (funded by 6 companies) and we are in contact with a few other companies in discussion. But we re far from our goal yet so we will have to actively reach out to more companies. Do you know companies who are still running Debian 6 servers ? If yes, please send me the details (name + url + contact info if possible) to deblts@freexian.com so that I can get in touch and invite them to contribute to the project. Distro Tracker In the continuation of the Debian France game, I continued to work together with Joseph Herlant and Christophe Siraut on multiple improvements to distro tracker in order to prepare for its deployment on tracker.debian.org (which I just announced \o/). Debian France Since the Debian France game was over, I shipped the rewards. 5 books have been shipped to:

• Joseph Herlant and Christophe Siraut for their distro-tracker work
• Dylan Aissi for his help within the Debian Med team
• Samuel Dorsaz and Thomas Debesse for their work towards better support of Brother printers

Misc Debian work I orphaned sql-ledger and made a last upload to change the maintainer to Debian QA (with a new upstream version). After having been annoyed a few times by dch breaking my name in the changelog, I filed #750855 which got quickly fixed. I disabled a broken patch in quilt to fix RC bug #751109. I filed #751771 when I discovered an incorrect dependency on ruby-uglifier (while doing packaging work for Kali Linux). I tested newer versions of ruby-libv8 on armel/armhf on request of the upstream author. I had reported him those build failures (github ticket here). Thanks See you next month for a new summary of my activities.

One comment Liked this article? Click here. My blog is Flattr-enabled.

I have a number of USB hard disks. Like, I suppose, mostly everyone who reads this blog. Unlike many people who do, however, for whatever reason I decided to create LVM volumes on most of my USB hard disks. The unfortunate result is that these now contain a lot of data with a somewhat less than efficient partitioning system. I don't really care much, but it's somewhat annoying, not in the least because disconnecting an LVM device isn't as easy as it used to be; originally you could just run the lvm2 init script with the stop argument, but that isn't the case anymore today. That is, you can run that, but it won't help you because all that does, effectively, is exit 0. So what do you do instead? This:

• First, make sure your devices aren't mounted anymore. Note: do not use lazy umount for a device that you're going to remove from your system! I've seen a few forum posts here and there of people who think it's safe to use umount -l for a device they're about to remove from their system which is still in use. It's not. It's a good way to cause data loss. Instead, make sure your partitions are really unmounted. Use fuser -m if you need to figure out which process is still using the partition.
• Next, use vgchange -a n. This will cause LVM to deactivate any logical volumes and volume groups that aren't open any more. Note that this can't work if you haven't done the above. Also note that this doesn't cause the devices to be gone when you do things like vgs or so. They're still there, they're just not in use anymore. Skipping this step isn't recommended, though; it will make LVM unhappy, mostly because some caches are still in use.
• Remove your device from the computer. That is, disconnect the USB cable, or call nbd-client -d, or do whatever you need to make sure the PV isn't connected to your system anymore.
• Finally, run vgchange --refresh. This will cause the system to rescan all partitions, notice that the volume groups which you've just disconnected aren't there anymore, and remove them from configuration.

Voila, your LVM volume group is no longer available, and you've not suffered data loss. Kewl. Note: I don't know what the lvm2 init script used to do. I suspect there's another way which doesn't require the --refresh step. I don't think it matters all that much, though. This works, and is safe. That being said, comments are welcome...

1. This weekend I will apply to rejoin the Debian project, as a developer. 2. In the meantime I've been begun releasing some some code which powers the git-based DNS hosting site/service. 3. This is the end of my list. 4. I lied. This is the end of my list. Powers of two, baby.

There are only left 3 days to submit your talk. Submit yours before it s too late. From the submissions from the last week, we have accepted a second batch of talks:

• Validation and Continuous Integration BoF
• DSA Team round table/BoF
• debdry - Debian Don t Repeat Yourself
• Debian Contributors, one year later
• Jessie (bits from the release team)
• State of the ARM
• Debian installer and CD BoF
• OpenStack update & packaging experience sharing
• Meet the Technical Committee
• Upstream Guide BoF

If your talk is not on the list, it doesn t mean that it is not accepted. The talks team will go through the list of talks again, and will publish the final list of talks towards the end of the month. We ll keep the submission of talks open after the deadline. Talks submitted after the deadline still have the possibility of being scheduled as ad-hoc talks. We ll publish more information about this closer to the conference.

Hi Planet Debian! My name is Ian Donnelly. I am going into my Senior Year at Florida State University this fall but for the summer I am working on a Google Summer of Code project with Debian. My mentor is Markus Raab and I am working with the Elektra team to implement a great new feature for Debian! I am spending this summer working on a system to allow automatic conffile merging by utilizing the Elektra Framework. Elektra is designed to provide a universal and secure framework to store configuration parameters in a global, hierarchical key database. For this project, conffiles will be mounted to the Elektra framework as KeySets. I have written code that performs a three-way merge on these KeySets which is much more robust than merging individual lines. A conffile can easily be mounted to the Key database using the kdb mount command, which I detailed in a previous blog post. Elektra has many included plugins which allow all types of conffiles to be mounted to the Key database. With our newest release, we even added an augeas plugin which will provide compatibility for most of the major conffiles. Once a conffile is mounted, any changes to the Elektra KeySet it is contained in will be updated in the actual conffile and visa-versa. So far this summer, I have written code for a three-way merge of Elektra KeySets and we have begun to look at the next step of implementing a automatic merge into dpkg. We are currently working on identifying exactly how the merge should take place and where we need to modify dpkg. The basic idea of what will change is that:

• Dpkg will need to store base conffiles somewhere on the system.
• Conffiles will need to be edited to have options ready for mounting such as where the keys should be mounted (for a package to support the automatic merge).
• Mount conffiles during package installs.
• Attempt a three-way merge during a package upgrade (instead of showing the user a prompt)
• Fall back to the regular prompt if a conffile can t be merged without conflicts.

Once dpkg has been patched, we will modify some packages and thoroughly test the new merge operation. It is designed to be non-destructive and to not infringe with any of the advantages of the current system. Package maintainers would need to opt in to using this feature to insure that all packages get tested before using it. However, we have designed this system to require minimal modification in order for maintainers to utilize it. This project will benefit Debian by removing a large pain-point with users. For experienced uses, merging changes in conffiles can be a tedious process. For newer users, the current system can be downright confusing. The goal of our project is to make Debian easier to use for everybody while not loosing the features that make it such a powerful platform. Please let us know what you think of the project or if you have any questions. Sincerely,
Ian S. Donnelly

I would like to go over the kdb mount command. The mount command is used to mount configuration files to the Elektra Key Database. Once a file is mounted, any changes to the file will be reflected in the Elektra Keys and any changes to the keys will be reflected in the configuration file. So how do we use the mount command? kdb mount [filepath] [mountpoint] [plugin] For instance, to mount /etc/hosts to system/hosts (using the hosts plugin):
kdb mount /etc/hosts system/hosts hosts
At this point the hosts file has been mounted. On my system the following key now exist under system/hosts

system/hosts/ian-debian

Which makes sense as the only line in my hosts file is:

127.0.0.1 ian-debian

Now I can edit this configuration file through the Elektra API, the kdb tool, or by editing the file (like always). So if I make a change using kdb such as:

kdb set system/hosts/ian-debian 192.168.0.2

My hosts file will be updated accordingly:

192.168.0.2 ian-debian
So that s how kdb mount works! Update: For the sake of clarity, I just want to add a quick example of how to unmount a configuration file from Elektra. The command is:

kdb umount [backend]

For our above example:

kdb umount system_hosts


The most significant change in this release is a somewhat embarassing bug fix: the network_read and network_write functions introduced in version 4.2 to support timeouts didn't correctly handle a timeout interrupted by a signal. This is now fixed by restarting the calls on EINTR. Also in this release is a general cleanup for integer overflows during memory allocation. rra-c-util now provides a replacement for reallocarray for systems that don't have it, and calloc and reallocarray are used internally where a size is calculated with multiplication. The util library also now provides a checked xreallocarray function. There are also a few minor fixes: portable/system.h guarantees the inclusion of inttypes.h and limits.h, portable/pam.h will now build with a C++ compiler, the Kerberos Autoconf probes provide a Makefile variable that can be used to suppress warnings from Kerberos headers by forcing them to be system headers, and the util/messages-krb5 test will be skipped when not built with Kerberos support. You can get the latest version from the rra-c-util distribution page.