The recent work I've been doing on podlators taught me that the build system of my other core module, Term::ANSIColor, was also doing the wrong thing when installed on Perl versions older than 5.11, even though no one had reported it. While I was there, I also switched back to ExtUtils::MakeMaker for the build system so that I'm testing the same build system that's also used for Perl core. Since it had been more than a year since the last release, I also made some minor cleanup of new perlcritic warnings and fixed a place where coverage analysis was misanalyzing a bit of code. There are no significant code changes. You can get the latest version from the Term::ANSIColor distribution page.

A minor update to the builder glue script for git-buildpackage. This release just has documentation fixes. I had missed that you no longer need explicit gbp.conf configuration because git-buildpackage now has a --git-pbuilder flag, and, when using that, there are a variety of other command-line flags to use instead of environment variables. Thanks to Ken Dreyer for the fixes. You can get the latest version from scripts distribution page.

My flight from Athens where I had the pleasure to attend the first reproducible world summit landed at the scheduled time in Paris (CDG). While people were getting their bags and putting their coats on, one member of the cabin crew announced that a police control will take place outside the plane and that we should have ready identity documents. My seat was in the back of the plane, so I had time to wait in the cold of the jetway while all passengers were controlled one after the other. Three cops were set up right at the entrance of the terminal. One was taking cards or passports and looking at people's face. He then passed it to another cop in front of a suitcase that seemed to contain a scanner and a computer. The third one was just standing against the wall watching. When it was my turn, after scanning my passport, the cop had this nice gesture where she started to move her hand holding the passport toward me just like she had just did a hundred times before pulling it backward when the result appeared on the screen. I had the confirmation that I was registered as a dangerous political activist in 2012 when David Dufresne published Magasin G n ral. One report from the interior intelligence service from 2008 was leaked to promote the book. My name had not been properly redacted from the very first version that went online and was associated with a political self-organized space in Dijon. Some Debian Developers had the pleasure to visit that space in 2005, 2006, or 2007. The report was full of mistakes, like almost all police files, so I don't want to comment on it. The good news is that since then, I have stopped being paranoid. I knew, and thus could take appropriate precautions. Just like every time I have to approach an airport, all my (encrypted) electronic devices were turned off. I had shaved a couple hours before. I know a lawyer ready to represent me. I am fully aware that it's best to say as little as possible. Although it has been a while since I had such a blatant confirmation that I was still a registered anarchist. It should not be a surprise though. Once you are in, there's no way out. I was then asked to step aside while they proceeded with the rest of the queue. I put my backpack down and leaned against the wall. Once they were over, one of the cops asked me to follow him. We walked through the corridors to reach the office of the border police. While we were walking, they asked me a series of questions. I'm not mentioning the pauses in between, but here's what I can remember:

Do you have a connection?
No.
Are you going to Paris?
To my parents' in the suburbs.
How long have you been staying in Greece?
5 days.
flipping the pages of my passport And you come back from the U.S. in Feb. 2015?
No, that was the maximum stay. I was there in August 2014.
Why were you in Greece? Vacations?
Work. I was at a meeting.
What do you do?
Free software.
What is that?
I am a developper.
Oh, computers.
Yes.
Is that why you also were in the US?
Yes, it was another conference.
And so you travel because of that. That's nice.

Are you a freelancer?
I work with a coop, but yes.

The cop also commented that they had to do some simple checks and that they would then let me go as I was coming back. I did not trust this but said nothing. When then passed through a door where the cop had to use their badge to unlock it. I was asked to sit on a chair in the corridor between two offices (as far as I could see). I could hear one cop explaining the situation to the next: Il a une fiche. Ah, une fiche. They seemed quite puzzled that I was not controlled when I flew out on Monday. After some minutes, another cop came back asking me for my boarding pass. Some more minutes later, he came back asking me if the address on my passport was still valid. I replied no . They gave me a piece of paper asking me for my current address, a phone number and an email address. As these information are all easy to find, I thought it was easier to comply. I gave my @irq7.fr address that I use for all public administrations. When the cop saw it, he asked:

What is it?
I don't understand.
Is it your company?
It is a non-profit.

He gave me my passport back and showed me the way out. (I will spare you details on the discussion I had to listen while waiting between two cops about how one loved to build models of military weapons used in wars against communism because of his origins. And that he was pissed off because fucking Europe disallowed some (toxic) paints he was used to.) To the best of my understanding, what happened is that they made a phone call and were just asked to update my personal details by the intelligence service. I don't know, but I'm left to wonder if all these people might just have been controlled because I was on the flight. All-in-all this didn't take too long: one hour after leaving the plane I was on the platform for the regional trains. The cops stayed polite the whole time. I am privileged: French citizen, white, able to speak French with a teacher accent. I am pretty sure it would have not been that good if I had been displaying a long beard or a djellaba. I took the time to document this because I know too many people who think that what the French government is doing doesn't concern them. It does. It's been a couple of years now that antiterrorism is how governments keep people in check. But we are reaching a whole new level now. We are talking about cops keeping their guns while off duties, house searches at any hours without judge oversight, and the government wants to change the constitution to make the state of emergency permanent. We've seen so many abuses in just two weeks. It will not go well. Meanwhile, instead of asking themselves why young people are killing others and themselves, state officials prefer dropping bombs. Which will surely prevent people ready to die from using suicidal tactics, right? We are at the dawn of an environmental crisis that will end humanity. Every human on this planet is concerned. People get beaten up when they march to pressure governments to do something about it. We need to unite and resist. And yes, we are going to get hurt but freedom is not free.

During the last few days, I found several references to a beautiful just-published paper, which I hope everybody reads: The Moral Character of Cryptographic Work, by Phillip Rogaway; Cryptology ePrint Report 2015/1162, published on December 1st this year. It is more an academic essay than most crypto-related papers, and a long one at that (46 pages, packed with references and anecdotal notes). But it is surprisingly easy to read. I am sitting in front of my computer while my students work on their final exam, and I have got over half way through the text; earlier today I looked at the quick presentation (as this work was presented by Rogaway at the Asiacrypt 2015 as an invited talk), and just loved it. Now, I know most of the people reading my blog have a moral stand on their work (after all, I expect most of you to be committed to Free Software just as I am, and that is a tremendous political statement). We are also more a practice community than an academic/scientific one. But many of us dwell on several projects and hold more than one hats in life through which we are defined. This paper/essay is really clicking with me, and it deeply resonates with the justification I presented when I joined the Masters on Security Engineering and Information Technologies program which I'm halfway through. Computer security does not exist in a void, and does not exist just for itself. As professionals, we have a mission to fulfill in society, and that will then shape how society evolves. So, I invite everybody to at least take a casual look at this paper. I hope you enjoy it as much as I did, and I hope it changes people's hearts and career decisions.

Last summer, Innuendo Studios made a series of 6 short videos trying to understand why would anyone get involved in a coordinated harrasment campaign. The recent articles making straw man arguments and gross mischaracterization of the actions of people trying to grow the pool of free software contributors reminded me of these videos, especially the fifth episode which describes why some people get so angry when others point out that maybe the general homogeneity of backgrounds is also related to how we treat people. Guess we can transpose one of the explanation in the video to free software communities:

Bad People do bad things; a sexist is a wife-beater or sexual assailant; I am neither; therefore I am a Good Person and the things I do are good; I work on free software where people report sexist biases; therefore they say I am a wife-beater or sexual assailant; this is a false and ridiculous claim; therefore they are bad.

This slightly helps to better understand why some people would attack efforts that don't concern them so strongly. Sadly, it doesn't help much with what we could do about it. Perhaps we can help them understand that they might be just as biased as everyone else living in an institutionally sexist and racist society. This does not make them bad people. It's just something we all need to keep in mind to improve the situation. (Also, be sure to read the follow-up post if you watch the series until the last episode.) Thanks to Nicolas Dandrimont for his comments and suggestions.

The previous release, switching to Module::Build, created a circular dependency with Module::Build itself with older versions of Perl. I pondered various ways to get around this, since I'm no longer a fan of ExtUtils::MakeMaker, but I finally decided that I was being silly. So podlators now just uses ExtUtils::MakeMaker it does support the new metadata keys these days rather than trying to support two separate build systems. (ExtUtils::MakeMaker is required for Perl core integration.) This release also didn't fix the problems with Term::Cap 1.16 in particular (although it worked with 1.17). That's also now fixed in this release by ensuring that Pod::Text::Termcap doesn't override an existing TERMPATH environment variable setting, something it shouldn't have been doing in the first place. You can get the latest release from the podlators distribution page.

A new package! A couple of weeks ago folks at Google released CCTZ: a C++ library for translating between absolute and civil times using the rules of a time zone. It requires only a proper C++11 compiler and the standard IANA time zone data base which standard Unix, Linux, OS X, ... computers tend to have in /usr/share/zoneinfo. And as the world needs nothing more than additional date, time, or timezones libraries, I started to quickly create a basic R wrapper package. This stalled as the original version of CCTZ used an __int128 for extended precision. That is not only not portable, but also prohibits compilation on baby computers still running a 32 OS (such as my trusted X1 laptop merrily plugging along with 4 gb of ram under Linux). Hence I filed an issue ticket which, lo and behold, got resolved two days ago. And so now we have a shiny new RcppCCTZ package on CRAN in a very basic version 0.0.1. It happily runs all the original examples from CCTZ as e.g. this one:

// from examples/hello.cc
//
// [[Rcpp::export]]
int helloMoon()  
    cctz::TimeZone syd;
    if (!cctz::LoadTimeZone("Australia/Sydney", &syd)) return -1;
    // Neil Armstrong first walks on the moon
    const auto tp1 = cctz::MakeTime(1969, 7, 21, 12, 56, 0, syd);
    const std::string s = cctz::Format("%F %T %z", tp1, syd);
    Rcpp::Rcout << s << "\n";
    cctz::TimeZone nyc;
    cctz::LoadTimeZone("America/New_York", &nyc);
    const auto tp2 = cctz::MakeTime(1969, 7, 20, 22, 56, 0, nyc);
    return tp2 == tp1 ? 0 : 1;
 

which results in

R> library(RcppCCTZ)
R> helloMoon()
1969-07-21 12:56:00 +1000
[1] 0
R>

indicating that the two civil times in fact correspond to the same absolute times when Armstrong walked on the moon. If you want to learn more about CCTZ, there was a corresponding talk CppCon (Youtube, Slides). I hope this provides a starting point for some new interesting computation on time from R. Collaboration welcome via the RcppCCTZ GitHub repo.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

FTP assistant This month I marked 352 packages for accept and rejected 61 of them. I had to send only 15 emails to maintainers. I also started to work on #796095 and #796784, but my first patch was rejected. So expect more to come here Squeeze LTS This was my seventeenth month that I did some work for the Squeeze LTS initiative, started by Raphael Hertzog at Freexian. Due to Toshiba becoming the first platinum sponsor, I got a workload of 21.25h. This is a new and delightful record! Altogether I uploaded those DLAs:

• [DLA 341-1] php5 security update
• [DLA 343-1] libpng security update
• [DLA 355-1] libxml2 security update
• [DLA 356-1] libsndfile security update

I also started to work on two bugs that were filed against the pseudo-package ftp.debian.org, which are somehow related to the security team: #796095 and #796784 (see above). Moreover I started to work on the next php5 upload, which will happen at the end of December. As more and more people work at the LTS frontdesk now, this month I could chill out a bit and let the others do the work. Other stuff As the Advent season started again I would also like to draw some attention to the Debian Med Advent Calendar. It was announced here and like the past years, the Debian Med team starts a bug squashing event from the December 1st to 24th. Every bug that is closed will be registered in the calendar. So instead of taking something from the calendar, this special one will be filled and at Christmas hopefully every Debian Med related bug is closed. Don t hestitate, start to squash .

When Akonadi silently fails to sync your calendar... Bug severity: seriously ruining my life. Try to use korganizer to create a calendar entry when the server is not reachable (say, you are offline, or you typed the wrong password), and you may find that you end up with no error messages, an entry that shows up perfectly fine, but that will never be synced to the server, ever again. I use korganizer, radicale and caldav for important things. The practical ramifications of me inserting entries in korganizer, seeing that everything looks ok, and then not finding them on my phone while on the go, are scary. Think of things like importing .ics files with flight schedules, entering tax deadlines, time and places for customer meetings, time and places of arrival of loved ones I'm supposed to pick up. I spent time setting up my own infrastructure for this exactly because I care that all of this works reliably. And now I urgently took a morning off work to find a way to detect those entries that Akonadi is refusing to update, The whole thing is cumbersome to run, but if you are using kdepim-based tools to manage your calendars and sync them across devices, you may want to give it a go every once in a while. You can find the script and the notes I took so far on the issue at https://github.com/spanezz/akonadi-workarounds.

My monthly report covers a large part of what I have been doing in the free software world. I write it for my donators (thanks to them!) but also for the wider Debian community because it can give ideas to newcomers and it s one of the best ways to find volunteers to work with me on projects that matter to me. Debian LTS This month I have been paid to work 21.25 hours on Debian LTS. During this time I worked on the following things:

• From November 2nd to November 8th, I was handling the LTS frontdesk, triaging new CVE, filing bugs, and ensuring timely answers on the mailing list. I pushed 26 commits to the security tracker. While investigating CVE-2015-7183 I discovered more embedded copies of nspr (which resulted in #804058). I also commented on the upstream fix for CVE-2015-5602 which looked like insufficient.
• Prepared and released DLA-339-1 on libhtml-scrubber-perl fixing one CVE.
• Prepared and released DLA-350-1 on eglibc with a non-trivial backport fixing one CVE.
• Prepared and released DLA-353-1 on imagemagick fixing two security issues without CVE yet (and marking one as not-affecting squeeze).
• Added a third patch after review by the upstream author on my still pending bouncycastle update. The upstream author asked me to further defer the update as they have some related fixes coming up.
• I did preparatory work for DLA-352-1 by identifying the upstream commits that fixed the security issue.
• I spent some time checking issues that have been assigned for a long time without any visible progress being made in the hope to unblock them (libvncserver, pound, quassel).

The Debian Administrator s Handbook Now that the English version has been finalized for Debian 8 Jessie (I uploaded the package to Debian Unstable), I concentrated my efforts on the French version. The book has been fully translated and we re now finalizing the print version that Eyrolles will again edit. Paris Open Source Summit On November 18th and 19th, I was in Paris for the Paris Open Source Summit. I helped to hold a booth for Debian France during two days (with the help of Fran ois-R gis and several others).

Fran ois-R gis Vuillemin, Juliette Belin and Rapha l Hertzog

On the booth, we had the visit of Juliette Belin who created the theme and the artwork of Debian 8 Jessie. We lacked goodies but we organized a lottery to win 12 copies of my French book. Debian packaging work Django. After two weeks of preparation for revers dependencies, I uploaded Django 1.8 to unstable and raised the severity of remaining bugs. Later I uploaded a new upstream point release (1.8.6). I also handled a release critical bug first by opening a ticket upstream and then by writing a patch and submitting it upstream. I uploaded 1.8.7-2 to Debian with my patch. I also submittted another small fix which has been rejected because the manual page is generated via Sphinx and I thus had to file a bug against Sphinx (which I did). A work-around has been found in the mean time. apt-xapian-index NMU. A long time ago, I filed a release critical bug against that package (#793681) but the maintainer did not handle it. Fortunately Sven Joachim prepared an NMU and I just uploaded his work. This resulted in another problem due bash-completion changes that Sven promptly fixed and I uploaded a second NMU a few days later. Gnome-shell-timer. I forwarded #805347 to gnome-shell-timer issue #29 but gnome-shell-timer is abandoned upstream. On a suggestion of Paul Wise, I tried to get this nice extension integrated into gnome-shell-extensions but the request has been turned down. Is there anyone with javascript skills who would like to adopt this project as an upstream developer? It s a low maintenance project with a decent and loyal user base. Misc. I fixed bug #804763 in zim which was the result of a bad Debian-specific patch.
I sponsored pylint-plugin-utils_0.2.3-2.dsc for Joseph Herlant to fix a release critical bug. I filed 806237 against lintian. I filed more tickets upstream, related to my Kali packaging work: one against sddm, one against john Other Debian-related work Distro-Tracker. I finally merged the work of Orestis Ioannou on bug #756766 which added the possibility to browse old news of each package. Debian Installer. I implemented two small features that we wanted in Kali: I fixed #647405 to have a way to disable deb-src lines in generated sources.list files. I also filed #805291 to see how to allow kernel command line preseeding to override initrd preseeding the fix is trivial and it works in Kali. I just have to commit it in Debian, I was hoping to get an ack from someone in charge before doing it. Thanks See you next month for a new summary of my activities.

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

Just in case someone else finds these useful, some bash functions I ve got into the habit of having in ~/.bashrc:

mcd()  mkdir "$1"; cd "$1";  
gum()  git checkout "$1" && git rebase master && git checkout master;  
gsb()   LIST= git branch egrep -v '(release staging trusty playground stale)' tr '\n' ' ' tr -d '*' ; git show-branch $LIST;  
gleaf()  git branch --merged master   egrep -v '(release staging trusty playground pipeline review stale)';  

mcd is the oldest one and the simplest. The others are just useful git management shortcuts. I can use gum to bring a feature branch back to master and gsb to show me which branches need to be rebased on master, typically after a pull. The list of excluded branches includes branches which should not be rebased against master (I could do some processing of git branch -r to not have those hardcoded) but the odd one is stale. Sometimes, I get an idea for a feature which is too intrusive, too messy or just too incomplete to be rebased against master. Rather than losing the idea or wasting time rebasing, I m getting into the habit of renaming the branch foo as stale-foo and gsb then leaves it alone. Equally, there are frequently times when I need to have a feature branch based on another feature branch, sometimes several feature branches deep. Identifying these branches and avoiding rebasing on the wrong branch is important to not waste time. gsb takes a bit of getting used to, but basically the shorter and cleaner the output, the less work needs to be done. As shown, gsb is git show-branch under the hood. What I m looking for is multiple commits listed between a branch and master. Then I know which branches to use with gum. Finally, gleaf shows which feature branches can be dropped with git branch -d.

Here is my monthly update covering a large part of what I have been doing in the free software world (previously):

• Did further significant work on a beta/stealth healthcare project released under a free-software license.
• Added support to the Reddit Enhancement Suite to avoid potential double-posting on CTRL+Enter. (#2537)
• Added the ability to specify the Vault password from the environment in Ansible. (#13206)
• Submitted a proof-of-concept patch to Django to workaround the latest release shipping invalid .py files that are used as templates. (#5735)
• Wrote django-template-tests, a tool to perform static analysis on Django templates prior to production. (code)
• Fixed a long-standing attachment encoding issue and added a "subjects" command to my tickle-me-email GTD email toolbox.
• Corrected the output of a template subsystem deprecation warning in Django. (#5681)
• Added Django 1.9 support to django-setuptest. (#26)
• Packaged django-switch-templatetag to avoid embedding this functionality in a number of projects of mine. (code)
• Corrected the exit semantics of blockfinder's testsuite. (#89)
• Corrected the queue documentation and worked with Bastian Hoyer to merge Python 3 support into django-slack. (#12)
• Added Python 3 support to django-auto-one-to-one. (diff)
• Adjusted first-commit.com's regex to be more lenient. (#3)
• Worked with @freeyoung to merge support for an improved config file format into dns-filter. (#4)
• Added audiobook support to my personal music library.
• Moved my TP-Link TR-ML3020 router to OpenWRT and started to configure it using Ansible, without requiring Python to be installed on the target device. (code)

---

Eric Raymond, author of The Cathedral and the Bazaar (an important work describing the effectiveness of open collaboration and development), recently wrote a piece calling for "Social Justice Warriors" to be ejected from the hacker community. The primary thrust of his argument is that by calling for a removal of the "cult of meritocracy", these SJWs are attacking the central aspect of hacker culture - that the quality of code is all that matters.

This argument is simply wrong.

Eric's been involved in software development for a long time. In that time he's seen a number of significant changes. We've gone from computers being the playthings of the privileged few to being nearly ubiquitous. We've moved from the internet being something you found in universities to something you carry around in your pocket. You can now own a computer whose CPU executes only free software from the moment you press the power button. And, as Eric wrote almost 20 years ago, we've identified that the "Bazaar" model of open collaborative development works better than the "Cathedral" model of closed centralised development.

These are huge shifts in how computers are used, how available they are, how important they are in people's lives, and, as a consequence, how we develop software. It's not a surprise that the rise of Linux and the victory of the bazaar model coincided with internet access becoming more widely available. As the potential pool of developers grew larger, development methods had to be altered. It was no longer possible to insist that somebody spend a significant period of time winning the trust of the core developers before being permitted to give feedback on code. Communities had to change in order to accept these offers of work, and the communities were better for that change.

The increasing ubiquity of computing has had another outcome. People are much more aware of the role of computing in their lives. They are more likely to understand how proprietary software can restrict them, how not having the freedom to share software can impair people's lives, how not being able to involve themselves in software development means software doesn't meet their needs. The largest triumph of free software has not been amongst people from a traditional software development background - it's been the fact that we've grown our communities to include people from a huge number of different walks of life. Free software has helped bring computing to under-served populations all over the world. It's aided circumvention of censorship. It's inspired people who would never have considered software development as something they could be involved in to develop entire careers in the field. We will not win because we are better developers. We will win because our software meets the needs of many more people, needs the proprietary software industry either can not or will not satisfy. We will win because our software is shaped not only by people who have a university degree and a six figure salary in San Francisco, but because our contributors include people whose native language is spoken by so few people that proprietary operating system vendors won't support it, people who live in a heavily censored regime and rely on free software for free communication, people who rely on free software because they can't otherwise afford the tools they would need to participate in development.

In other words, we will win because free software is accessible to more of society than proprietary software. And for that to be true, it must be possible for our communities to be accessible to anybody who can contribute, regardless of their background.

Up until this point, I don't think I've made any controversial claims. In fact, I suspect that Eric would agree. He would argue that because hacker culture defines itself through the quality of contributions, the background of the contributor is irrelevant. On the internet, nobody knows that you're contributing from a basement in an active warzone, or from a refuge shelter after escaping an abusive relationship, or with the aid of assistive technology. If you can write the code, you can participate.

Of course, this kind of viewpoint is overly naive. Humans are wonderful at noticing indications of "otherness". Eric even wrote about his struggle to stop having a viscerally negative reaction to people of a particular race. This happened within the past few years, so before then we can assume that he was less aware of the issue. If Eric received a patch from someone whose name indicated membership of this group, would there have been part of his subconscious that reacted negatively? Would he have rationalised this into a more critical analysis of the patch, increasing the probability of rejection? We don't know, and it's unlikely that Eric does either.

Hacker culture has long been concerned with good design, and a core concept of good design is that code should fail safe - ie, if something unexpected happens or an assumption turns out to be untrue, the desirable outcome is the one that does least harm. A command that fails to receive a filename as an argument shouldn't assume that it should modify all files. A network transfer that fails a checksum shouldn't be permitted to overwrite the existing data. An authentication server that receives an unexpected error shouldn't default to granting access. And a development process that may be subject to unconscious bias should have processes in place that make it less likely that said bias will result in the rejection of useful contributions.

When people criticise meritocracy, they're not criticising the concept of treating contributions based on their merit. They're criticising the idea that humans are sufficiently self-aware that they will be able to identify and reject every subconscious prejudice that will affect their treatment of others. It's not a criticism of a desirable goal, it's a criticism of a flawed implementation. There's evidence that organisations that claim to embody meritocratic principles are more likely to reward men than women even when everything else is equal. The "cult of meritocracy" isn't the belief that meritocracy is a good thing, it's the belief that a project founded on meritocracy will automatically be free of bias.

Projects like the Contributor Covenant that Eric finds so objectionable exist to help create processes that (at least partially) compensate for our flaws. Review of our processes to determine whether we're making poor social decisions is just as important as review of our code to determine whether we're making poor technical decisions. Just as the bazaar overtook the cathedral by making it easier for developers to be involved, inclusive communities will overtake "pure meritocracies" because, in the long run, these communities will produce better output - not just in terms of the quality of the code, but also in terms of the ability of the project to meet the needs of a wider range of people.

The fight between the cathedral and the bazaar came from people who were outside the cathedral. Those fighting against the assumption that meritocracies work may be outside what Eric considers to be hacker culture, but they're already part of our communities, already making contributions to our projects, already bringing free software to more people than ever before. This time it's Eric building a cathedral and decrying the decadent hordes in their bazaar, Eric who's failed to notice the shift in the culture that surrounds him. And, like those who continued building their cathedrals in the 90s, it's Eric who's now irrelevant to hacker culture.

(Edited to add: for two quite different perspectives on why Eric's wrong, see Tim's and Coraline's posts)

comments

This weekend I've mostly been tidying up some personal projects and things.

http://debian-administration.org/

This was updated to use recaptcha on the sign-up page, which is my attempt to cut down on the 400+ spam-registrations it receives every day. I've purged a few thousand bogus-accounts, which largely existed to point to spam-sites in their profile-pages. I go through phases where I do this, but my heuristics have always been a little weak.

http://dhcp.io/

This site offers free dynamic DNS for a few hundred users. I closed fresh signups due to it being abused by spammers, but it does have some users and I sometimes add new people who ask politely. Unfortunately some users hammer it, trying to update their DNS records every 60 seconds or so. (One user has spent the past few months updating their IP address every 30 seconds, ironically their external IP hadn't changed in all that time!) So I suspended a few users, and implemented a minimum-update threshold: Nobody can update their IP address more than once every fifteen minutes now.

Literate Emacs Configuration File

Working towards my stateless home-directory I've been tweaking my dotfiles, and the last thing I did today was move my Emacs configuration over to a literate fashion. My main emacs configuration-file is now a markdown file, which contains inline-code. The inline-code is parsed at runtime, and executed when Emacs launches. The init.el file which parses/evals is pretty simple, and I'm quite pleased with it. Over time I'll extend the documantion and move some of the small snippets into it.

Offsite backups

My home system(s) always had a local backup, maintained on an external 2Tb disk-drive, along with a remote copy of some static files which were maintained using rsync. I've now switched to having a virtual machine host the external backups with proper incrementals - via attic, which beats my previous "only one copy" setup.

Virtual Machine Backups

On a whim a few years ago I registered rsync.io which I use to maintain backups of my personal virtual machines. That still works, though I'll probably drop the domain and use backup.steve.org.uk or similar in the future.

FWIW the external backups are hosted on BigV, which gives me a 2Tb "archive" disk for a 40 a month. Perfect.

remctl is a simple and secure remote command execution protocol using GSS-API. Essentially, it's the thinnest and simplest possible way to deploy remote network APIs for commands using Kerberos authentication and encryption. Most of the work in this release is around supporting anonymous authentication for an upcoming project of mine. This included cleaning up ACL handling so that clients that authenticated with anonymous PKINIT didn't count as ANYUSER (it's not likely this would have been a security problem for existing users, since you would have had to enable anonymous service tickets in your KDC), and adding new anyuser:auth and anyuser:anonymous ACLs that are explicit about whether anonymous users are included. With this change, it's possible, using a KDC with anonymous service tickets enabled, to use anonymous PKINIT to make entirely unauthenticated remctl calls. I plan on using this with wallet to support initial system key bootstrapping using external validation of whether a system is currently allowed to bootstrap keys. Note that you need to be very careful when enabling anonymous service tickets, since many other Kerberos applications (including remctl prior to this release) assume that any client that can get a service ticket is in some way authenticated. Also new in this release, the server now sets the REMOTE_EXPIRES environment variable to the time when the authenticated remote session will expire. This is usually th expiration time of the user's credentials. I'm planning on using this as part of a better kx509 replacement to issue temporary X.509 certificates from Kerberos tickets, limited in lifetime to the lifetime of the Kerberos ticket. This release also includes some portability fixes, a bug fix for the localgroup ACL for users who are members of lots of local groups, and some (mildly backwards-incompatible) fixes for the Python RemctlError exception class. You can get the latest release from the remctl distribution page.

I have been using Replicant on the Samsung SIII I9300 for over two years. I have written before on taking a backup of the phone using rsync but recently I automated my setup as described below. This work was prompted by a screen accident with my phone that caused it to die, and I noticed that I hadn t taken regular backups. I did not lose any data this time, since typically all content I create on the device is immediately synchronized to my clouds. Photos are uploaded by the ownCloud app, SMS Backup+ saves SMS and call logs to my IMAP server, and I use DAVDroid for synchronizing contacts, calendar and task lists with my instance of ownCloud. Still, I strongly believe in regular backups of everything, so it was time to automate this. For my use-case, taking backups of the phone whenever I connect it to one of my laptops is sufficient. I typically connect it to my laptops for charging at least every other day. My laptops are all running Debian, but this should be applicable to most modern GNU/Linux system. This is not Replicant-specific, although you need a rooted phone. I thought that automating this would be simple, but I got to learn the ins and outs of systemd and udev in the process and this ended up taking the better part of an evening. I started out adding an udev rule and a small script, thinking I could invoke the backup process from the udev rule. However rsync would magically die after running a few seconds. After an embarrassing long debugging session, finally I found someone with a similar problem which led me to a nice writeup on the topic of running long-running services on udev events. I created a file /etc/udev/rules.d/99-android-backup.rules with the following content:

ACTION=="add", SUBSYSTEMS=="usb", ENV ID_SERIAL_SHORT =="323048a5ae82918b", TAG+="systemd", ENV SYSTEMD_WANTS +="android-backup@$env ID_SERIAL_SHORT .service"
ACTION=="add", SUBSYSTEMS=="usb", ENV ID_SERIAL_SHORT =="4df9e09c25e75f63", TAG+="systemd", ENV SYSTEMD_WANTS +="android-backup@$env ID_SERIAL_SHORT .service"

The serial numbers correspond to the device serial numbers of the two devices I wish to backup. The adb devices command will print them for you, and you need to replace my values with the values from your phones. Next I created a systemd service to describe a oneshot service. The file /etc/systemd/system/android-backup@.service have the following content:

[Service]
Type=oneshot
ExecStart=/usr/local/sbin/android-backup %I

The at-sign ( @ ) in the service filename signal that this is a service that takes a parameter. I m not enough of an udev/systemd person to explain these two files using the proper terminology, but at least you can pattern-match and follow the basic idea of them: the udev rule matches the devices that I m interested in (I don t want this to happen to all random Android devices I attach, hence matching against known serial numbers), and it causes a systemd service with a parameter to be started. The systemd service file describe the script to run, and passes on the parameter. Now for the juicy part, the script. I have /usr/local/sbin/android-backup with the following content.

#!/bin/bash
DIRBASE=/var/backups/android
export ANDROID_SERIAL="$1"
exec 2>&1   logger
if ! test -d "$DIRBASE-$ANDROID_SERIAL"; then
    echo "could not find directory: $DIRBASE-$ANDROID_SERIAL"
    exit 1
fi
set -x
adb wait-for-device
adb root
adb wait-for-device
adb shell printf "address 127.0.0.1\nuid = root\ngid = root\n[root]\n\tpath = /\n" \> /mnt/secure/rsyncd.conf
adb shell rsync --daemon --no-detach --config=/mnt/secure/rsyncd.conf &
adb forward tcp:6010 tcp:873
sleep 2
rsync -av --delete --exclude /dev --exclude /acct --exclude /sys --exclude /proc rsync://localhost:6010/root/ $DIRBASE-$ANDROID_SERIAL/
: rc $?
adb forward --remove tcp:6010
adb shell rm -f /mnt/secure/rsyncd.conf

This script warrant more detailed explanation. Backups are placed under, e.g., /var/backups/android-323048a5ae82918b/ for later off-site backup (you do backup your laptop, right?). You have to manually create this directory, as a safety catch to not wildly rsync data into non-existing directories. The script logs everything using syslog, so run a tail -F /var/log/syslog& when setting this up. You may want to reduce verbosity of rsync if you prefer (replace rsync -av with rsync -a). The script runs adb wait-for-device which you rightly guessed will wait for the device to settle. Next adb root is invoked to get root on the device (reading all files from the system naturally requires root). It takes some time to switch, so another wait-for-device call is needed. Next a small rsyncd configuration file is created in /mnt/secure/rsyncd.conf on the phone. The file tells rsync do listen on localhost, run as root, and use / as the path. By default, rsyncd is read-only so the host will not be able to upload any data over rsync, just read data out. Next rsync is started on the phone. The adb forward command forwards port 6010 on the laptop to port 873 on the phone (873 is the default rsyncd port). Unfortunately, setting up the TCP forward appears to take some time, and adb wait-for-device will not wait for that to complete, hence an ugly sleep 2 at this point. Next is the rsync invocation itself, which just pulls in everything from the phone to the laptop, excluding some usual suspects. The somewhat cryptic : rc $? merely logs the exit code of the rsync process into syslog. Finally we clean up the TCP forward and remove the rsyncd.conf file that was temporarily created. This setup appears stable to me. I can plug in a phone and a backup will be taken. I can even plug in both my devices at the same time, and they will run at the same time. If I unplug a device, the script or rsync will error out and systemd cleans up. If anyone has ideas on how to avoid the ugly temporary rsyncd.conf file or the ugly sleep 2, I m interested. It would also be nice to not have to do the adb root dance, and instead have the phone start the rsync daemon when connecting to my laptop somehow. TCP forwarding might be troublesome on a multi-user system, but my laptops aren t. Killing rsync on the phone is probably a good idea too. If you have ideas on how to fix any of this, other feedback, or questions, please let me know!