Search Results: "ana"

26 October 2015

Simon Josefsson: Combining Dnsmasq and Unbound

For my home office network I have been using Dnsmasq for some time. Dnsmasq provides me with DNS, DHCP, DHCPv6, and IPv6 Router Advertisement. I run dnsmasq on a Debian Jessie server, but it works similar with OpenWRT if you want to use a smaller device. My entire /etc/dnsmasq.d/local configuration used to look like this: 
dhcp-authoritative
interface=eth1
read-ethers
dhcp-range=192.168.1.100,192.168.1.150,12h
dhcp-range=2001:9b0:104:42::100,2001:9b0:104:42::1500
dhcp-option=option6:dns-server,[::]
enable-ra
Here dhcp-authoritative enable DHCP. interface=eth1 says to listen on eth1 only, which is my internal (IPv4 NAT) network. I try to keep track of the MAC address of all my devices in a /etc/ethers file, so I use read-ethers to have dnsmasq give stable IP addresses for them. The dhcp-range is used to enable DHCP and DHCPv6 on my internal network. The dhcp-option=option6:dns-server,[::] statement is needed to inform the DHCP clients of the DNS resolver s IPv6 address, otherwise they would only get the IPv4 DNS server address. The enable-ra parameter enables IPv6 router advertisement on the internal network, thereby removing the need to run radvd too useful since I prefer to use copyleft software. Recently I had a desire to use DNSSEC, and enabled it in Dnsmasq using the following statements: 
dnssec
trust-anchor=.,19036,8,2,49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5
dnssec-check-unsigned
The dnssec keyword enable DNSSEC validation in dnsmasq, using the indicated trust-anchor (get the root-anchors from IANA). The dnssec-check-unsigned deserves some more discussion. The dnsmasq manpage describes it as follows:
As a default, dnsmasq does not check that unsigned DNS replies are legitimate: they are assumed to be valid and passed on (without the authentic data bit set, of course). This does not protect against an attacker forging unsigned replies for signed DNS zones, but it is fast. If this flag is set, dnsmasq will check the zones of unsigned replies, to ensure that unsigned replies are allowed in those zones. The cost of this is more upstream queries and slower performance.
For example, this means that dnsmasq s DNSSEC functionality is not secure against active man-in-the-middle attacks between dnsmasq and the DNS server it is using. Even if example.org used DNSSEC properly, an attacker could fake that it was unsigned to dnsmasq, and I would get potentially incorrect values in return. We all know that the Internet is not a secure place, and your threat model should include active attackers. I believe this mode should be the default in dnsmasq, and users should have to configure dnsmasq to not be in that mode if they really want to (with the obvious security warning). Running with this enabled for a couple of days resulted in frustration about not being able to reach a couple of domains. The behaviour was that my clients would hang indefinitely or get a SERVFAIL, both resulting in lack of service. You can enable query logging in dnsmasq with log-queries and enabling this I noticed three distinct form of error patterns: 
jow13gw dnsmasq 460 - -  forwarded www.fritidsresor.se to 213.80.101.3
jow13gw dnsmasq 460 - -  validation result is BOGUS

jow13gw dnsmasq 547 - -  reply cloudflare-dnssec.net is BOGUS DNSKEY
jow13gw dnsmasq 547 - -  validation result is BOGUS

jow13gw dnsmasq 547 - -  reply linux.conf.au is BOGUS DS
jow13gw dnsmasq 547 - -  validation result is BOGUS
The first only happened intermittently, the second did not cause any noticeable problem, and the final one was reproducible. To be fair, I only found the last example after starting to search for problem reports (see post confirming bug). At this point, I had a confirmed bug in dnsmasq that affect my use-case. I want to use official packages from Debian on this machine, so installing newer versions manually is not an option. So I started to look into alternatives for DNS resolving, and quickly found Unbound. Installing it was easy: 
apt-get install unbound
unbound-control-setup
I created a local configuration file in /etc/unbound/unbound.conf.d/local.conf as follows: 
server:
	interface: 127.0.0.1
	interface: ::1
	interface: 192.168.1.2
	interface: 2001:9b0:104:42::2
	access-control: 127.0.0.1 allow
	access-control: ::1 allow
	access-control: 192.168.1.2/24 allow
	access-control: 2001:9b0:104:42::2/64 allow
	outgoing-interface: 155.4.17.2
	outgoing-interface: 2001:9b0:1:1a04::2
#	log-queries: yes
#	verbosity: 2
The interface keyword determine which IP addresses to listen on, here I used the loopback interface and the local address of the physical network interface for my internal network. The access-control allows recursive DNS resolving from those networks. And outgoing-interface specify my external Internet-connected interface. log-queries and/or verbosity are useful for debugging. To make things work, dnsmasq has to stop providing DNS services. This can be achieved with the port=0 keyword, however that will also disable informing DHCP clients about the DNS server to use. So this has to be added in manually. I ended up adding the two following lines to /etc/dnsmasq.d/local: 
port=0
dhcp-option=option:dns-server,192.168.1.2
Restarting unbound and dnsmasq now leads to working (and secure) internal DNSSEC-aware name resolution over both IPv4 and IPv6. I can verify that resolution works, and that Unbound verify signatures and reject bad domains properly with dig as below, or use online DNSSEC resolver test page although I m not sure how confident you can be in the result from that page. 
$ host linux.conf.au
linux.conf.au has address 192.55.98.190
linux.conf.au mail is handled by 1 linux.org.au.
$ host sigfail.verteiltesysteme.net
;; connection timed out; no servers could be reached
$
I use Munin to monitor my services, and I was happy to find a nice Unbound Munin plugin. I installed the file in /usr/share/munin/plugins/ and created a Munin plugin configuration file /etc/munin/plugin-conf.d/unbound as follows: 
[unbound*]
user root
env.statefile /var/lib/munin-node/plugin-state/root/unbound.state
env.unbound_conf /etc/unbound/unbound.conf
env.unbound_control /usr/sbin/unbound-control
env.spoof_warn 1000
env.spoof_crit 100000
I run munin-node-configure --shell sh to enable it. To work unbound has to be configured as well, so I create a /etc/unbound/unbound.conf.d/munin.conf as follows. 
server:
	extended-statistics: yes
	statistics-cumulative: no
	statistics-interval: 0
remote-control:
	control-enable: yes
The graphs may be viewed at my munin instance.

25 October 2015

Johannes Schauer: unshare without superuser privileges

TLDR: With the help of Helmut Grohne I finally figured out most of the bits necessary to unshare everything without becoming root (though one might say that this is still cheated because the suid root tools newuidmap and newgidmap are used). I wrote a Perl script which documents how this is done in practice. This script is nearly equivalent to using the existing commands lxc-usernsexec [opts] -- unshare [opts] -- COMMAND except that these two together cannot be used to mount a new proc. Apart from this problem, this Perl script might also be useful by itself because it is architecture independent and easily inspectable for the curious mind without resorting to sources.debian.net (it is heavily documented at nearly 2 lines of comments per line of code on average). It can be retrieved here at https://gitlab.mister-muffin.de/josch/user-unshare/blob/master/user-unshare Long story: Nearly two years after my last last rant about everything needing superuser privileges in Linux, I'm still interested in techniques that let me do more things without becoming root. Helmut Grohne had told me for a while about unshare(), or user namespaces as the right way to have things like chroot without root. There are also reports of LXC containers working without root privileges but they are hard to come by. A couple of days ago I had some time again, so Helmut helped me to get through the major blockers that were so far stopping me from using unshare in a meaningful way without executing everything with sudo. My main motivation at that point was to let dpkg-buildpackage when executed by sbuild be run with an unshared network namespace and thus without network access (except for the loopback interface) because like pbuilder I wanted sbuild to enforce the rule not to access any remote resources during the build. After several evenings of investigating and doctoring at the Perl script I mentioned initially, I came to the conclusion that the only place that can unshare the network namespace without disrupting anything is schroot itself. This is because unsharing inside the chroot will fail because dpkg-buildpackage is run with non-root privileges and thus the user namespace has to be unshared. But this then will destroy all ownership information. But even if that wasn't the case, the chroot itself is unlikely to have (and also should not) tools like ip or newuidmap and newgidmap installed. Unsharing the schroot call itself also will not work. Again we first need to unshare the user namespace and then schroot will complain about wrong ownership of its configuration file /etc/schroot/schroot.conf. Luckily, when contacting Roger Leigh about this wishlist feature in bug#802849 I was told that this was already implemented in its git master \o/. So this particular problem seems to be taken care of and once the next schroot release happens, sbuild will make use of it and have unshare --net capabilities just like pbuilder already had since last year. With the sbuild case taken care of, the rest of this post will introduce the Perl script I wrote. The name user-unshare is really arbitrary. I just needed some identifier for the git repository and a filename. The most important discovery I made was, that Debian disables unprivileged user namespaces by default with the patch add-sysctl-to-disallow-unprivileged-CLONE_NEWUSER-by-default.patch to the Linux kernel. To enable it, one has to first either do 
echo 1   sudo tee /proc/sys/kernel/unprivileged_userns_clone > /dev/null
or 
sudo sysctl -w kernel.unprivileged_userns_clone=1
The tool tries to be like unshare(1) but with the power of lxc-usernsexec(1) to map more than one id into the new user namespace by using the programs newgidmap and newuidmap. Or in other words: This tool tries to be like lxc-usernsexec(1) but with the power of unshare(1) to unshare more than just the user and mount namespaces. It is nearly equal to calling: 
lxc-usernsexec [opts] -- unshare [opts] -- COMMAND
Its main reason of existence are: I hoped that systemd-nspawn could do what I wanted but it seems that its requirement for being run as root will not change any time soon Another tool in Debian that offers to do chroot without superuser privileges is linux-user-chroot but that one cheats by being suid root. Had I found lxc-usernsexec earlier I would've probably not written this. But after I found it I happily used it to get an even better understanding of the matter and further improve the comments in my code. I started writing my own tool in Perl because that's the language sbuild was written in and as mentioned initially, I intended to use this script with sbuild. Now that the sbuild problem is taken care of, this is not so important anymore but I like if I can read the code of simple programs I run directly from /usr/bin without having to retrieve the source code first or use sources.debian.net. The only thing I wasn't able to figure out is how to properly mount proc into my new mount namespace. I found a workaround that works by first mounting a new proc to /proc and then bind-mounting /proc to whatever new location for proc is requested. I didn't figure out how to do this without mounting to /proc first partly also because this doesn't work at all when using lxc-usernsexec and unshare together. In this respect, this perl script is a bit more powerful than those two tools together. I suppose that the reason is that unshare wasn't written with having being called without superuser privileges in mind. If you have an idea what could be wrong, the code has a big FIXME about this issue. Finally, here a demonstration of what my script can do. Because of the /proc bug, lxc-usernsexec and unshare together are not able to do this but it might also be that I'm just not using these tools in the right way. The following will give you an interactive shell in an environment created from one of my sbuild chroot tarballs: 
$ mkdir -p /tmp/buildroot/proc
$ ./user-unshare --mount-proc=/tmp/buildroot/proc --ipc --pid --net \
    --uts --mount --fork -- sh -c 'ip link set lo up && ip addr && \
    hostname hoothoot-chroot && \
    tar -C /tmp/buildroot -xf /srv/chroot/unstable-amd64.tar.gz; \
    /usr/sbin/chroot /tmp/buildroot /sbin/runuser -s /bin/bash - josch && \
    umount /tmp/buildroot/proc && rm -rf /tmp/buildroot'
(unstable-amd64-sbuild)josch@hoothoot-chroot:/$ whoami
josch
(unstable-amd64-sbuild)josch@hoothoot-chroot:/$ hostname
hoothoot-chroot
(unstable-amd64-sbuild)josch@hoothoot-chroot:/$ ls -lha /proc   head
total 0
dr-xr-xr-x 218 nobody nogroup    0 Oct 25 19:06 .
drwxr-xr-x  22 root   root     440 Oct  1 08:42 ..
dr-xr-xr-x   9 root   root       0 Oct 25 19:06 1
dr-xr-xr-x   9 josch  josch      0 Oct 25 19:06 15
dr-xr-xr-x   9 josch  josch      0 Oct 25 19:06 16
dr-xr-xr-x   9 root   root       0 Oct 25 19:06 7
dr-xr-xr-x   9 josch  josch      0 Oct 25 19:06 8
dr-xr-xr-x   4 nobody nogroup    0 Oct 25 19:06 acpi
dr-xr-xr-x   6 nobody nogroup    0 Oct 25 19:06 asound
Of course instead of running this long command we can also instead write a small shell script and execute that instead. The following does the same things as the long command above but adds some comments for further explanation: 
#!/bin/sh

set -exu

# I'm using /tmp because I have it mounted as a tmpfs
rootdir="/tmp/buildroot"

# bring the loopback interface up
ip link set lo up

# show that the loopback interface is really up
ip addr

# make use of the UTS namespace being unshared
hostname hoothoot-chroot

# extract the chroot tarball. This must be done inside the user namespace for
# the file permissions to be correct.
#
# tar will fail to call mknod and to change the permissions of /proc but we are
# ignoring that
tar -C "$rootdir" -xf /srv/chroot/unstable-amd64.tar.gz   true

# run chroot and inside, immediately drop permissions to the user "josch" and
# start an interactive shell
/usr/sbin/chroot "$rootdir" /sbin/runuser -s /bin/bash - josch

# unmount /proc and remove the temporary directory
umount "$rootdir/proc"
rm -rf "$rootdir"
and then: 
$ mkdir -p /tmp/buildroot/proc
$ ./user-unshare --mount-proc=/tmp/buildroot/proc --ipc --pid --net --uts --mount --fork -- ./chroot.sh
As mentioned in the beginning, the tool is nearly equivalent to calling lxc-usernsexec [opts] -- unshare [opts] -- COMMAND but because of the problem with mounting proc (mentioned earlier), lxc-usernsexec and unshare cannot be used with above example. If one tries anyways one will only get: 
$ lxc-usernsexec -m b:0:1000:1 -m b:1:558752:1 -- unshare --mount-proc=/tmp/buildroot/proc --ipc --pid --net --uts --mount --fork -- ./chroot.sh
unshare: mount /tmp/buildroot/proc failed: Invalid argument
I'd be interested in finding out why that is and how to fix it.

Russ Allbery: Review: The Thrilling Adventures of Lovelace and Babbage

Review: The Thrilling Adventures of Lovelace and Babbage, by Sydney Padua
Publisher: Pantheon
Copyright: 2015
ISBN: 0-307-90827-5
Format: Hardcover
Pages: 317
I seem to be writing a lot of reviews lately where any reader can easily do their own research and see if this is something they'd like. This is another of those, but perhaps a bit more obscure. As Padua explains in the preface, the first Lovelace and Babbage strip was intended to be a one-off joke. A friend suggested that she draw a comic telling the (short and rather tragic) life of Ada Lovelace, widely considered the first computer programmer even though the computer for which she wrote programs was never built: Charles Babbage's Analytic Engine. Padua found the story of Babbage and Lovelace's collaboration fascinating but too grim, and so wrote an alternate ending involving a pocket universe in which Babbage and Lovelace lived on to fight crime! Or at least fought against street organs and poetry. Padua meant this as a joke. The Internet took it as a teaser. Quite to her surprise, she found herself writing occasional additional episodes and getting lost in fascinating research about Lovelace and Babbage. The result is all at 2dgoggles.com. This book is a curated collection of those comics, including much of their (extensive) footnotes and research notes, in a very attractive and well-constructed book form. The best review, therefore, would be to go read some of the comics yourself, easily accessible via the Comics tab on the web site, and see if this is the sort of thing you'd enjoy. There is some material in the book that isn't on the web site, but most of it is there (including one full story that didn't make it into the book). There are a few reasons to buy a collection like this of material that previously appeared on the Internet. One, of course, is out of gratitude to support the author, which is the main reason I bought it. If you want to do that, though, you probably already know you do. Another reason is for additional unpublished material, but that's not really the case here. But a third is that, despite all the technology of the web, books can sometimes provide a more elegant and beautiful presentation. And that's very much the case for The Thrilling Adventures of Lovelace and Babbage. The hardcover is a beautiful work of art. It has what you would expect from a hardcover graphic novel, of course: sturdy paper, lovely story headings in the form of Victorian-style posters, and very nice artwork beneath the dust jacket. (I've been so happy to see that in the last few hardcovers I've reviewed.) But, best of all, it presents the primary research notes on each page underneath comic panels. Those who have been reading Lovelace and Babbage as it appears on the web know Padua's copious research notes. But they're normally presented at the end of each complete part, and I found myself often not reading them in detail. This might not be the case for everyone, but at least for me this presentation works so much better. Historical notes are at the bottom of (nearly) every page, in context. This might sound like it would distract from and break up the flow of the story, but at least for me it does the opposite. The comics feel so much richer when intermixed with the actual history (which in some cases is surprisingly similar to what seemed to be wild, invented scenarios). The historical notes also have end notes, and quite substantial ones. I found that organization less successful (readers of my reviews will know I have a long-standing antipathy towards end notes for anything other than cross-references), but I have to admit I have no idea how Padua would have fit those on the same page as footnotes. They're also written well enough, and with sufficient detail, that I could usually read a chapter and then read all the end notes and mostly remember what they referred to. Padua also takes advantage of the format to play a few neat games with frame breaks: characters commenting on the notes, stabbing things into them, or otherwise affecting them. I have to admit to some mild frustration where this makes the notes unreadable, since they're nearly as fascinating as the comics, but the overall effect is still worth it. (And, of course, the full notes are available on the web if one wishes to look them up.) Rounding out the book version are a few of the best original source documents that Padua found, thankfully excerpted and well-edited to not outlive their welcome for those of us who don't like poring over Victorian letters. And, finally, some beautiful illustrations of the mechanisms of the Analytic Engine with supporting descriptions of how they were supposed to work. I'm not particularly mechanically inclined, nor that fascinated by steampunk, and I still found these diagrams impressive and fun to look at. Someone more interested in such things will be in for a treat. I've been thoroughly enjoying the (sadly infrequent) installments of Lovelace and Babbage for years now, and am utterly delighted by their hardcover appearance. If you already knew about Padua's work and have any interest in nice hardcovers of such things, I don't think you'll regret the purchase. If you haven't heard of her, or this series, before, some quick reading at the web site should quickly reveal whether this is something you'd enjoy. Rating: 9 out of 10

24 October 2015

Mart n Ferrari: Tales from the SRE trenches - Part 1

A few weeks ago, I was offered the opportunity to give a guest talk in the Romanian Association for Better Software. RABS is a group of people interested in improving the trade, and regularly hold events where invited speakers give presentations on a wide array of topics. The speakers are usually pretty high-profile, so this is quite a responsibility! To make things more interesting, much of the target audience works on enterprise software, under Windows platforms. Definitely outside my comfort zone! Considering all this, we decided the topic was going to be about Site Reliability Engineering (SRE), concentrating on some aspects of it which I believe could be useful independently of the kind of company you are working for. I finally gave the talk last Monday, and the audience seemed to enjoy it, so I am going to post here my notes, hopefully some other people will like it too.

Why should I care? I prepared this thinking of an audience of software engineers, so why would anyone want to hear about this idea that only seems to be about making the life of the operations people better? The thing is, having your work as a development team supported by an SRE team will also benefit you. This is not about empowering Ops to hit you harder when things blow apart, but to have a team that is your partner. A partner that will help you grow, handle the complexities of a production environment so you can concentrate on cool features, and that will get out of the way when things are running fine. A development team may seem to only care about adding features that will drive more and more users to your service. But an unreliable service is a service that loses users, so you should care about reliability. And what better to have a team has Reliability on their name?

What is SRE? SRE means Site Reliability Engineering, Reliability Engineering applied to "sites". Wikipedia defines Reliability Engineering as:
[..] engineering that emphasizes dependability in the life-cycle management of a product.
This is, historically, a branch of engineering that made possible to build devices that will work as expected even when their components were inherently unreliable. It focused on improving component reliability, establishing minimum requirements and expectations, and a heavy usage of statistics to predict failures and understand underlying problems. SRE started as a concept at Google about 12 years ago, when Ben Treynor joined the company and created the SRE team from a group of 7 production engineers. There is no good definition of what Site Reliability Engineering means; while the term and some of its ideas are clearly inspired in the more traditional RE, he defines SRE with these words1:
Fundamentally, it's what happens when you ask a software engineer to design an operations function.

Only hire coders After reading that quote it is not surprising that the first item in the SRE checklist2, is to only hire people who can code properly for SRE roles. Writing software is a key part of being SRE. But this does not mean that there is no separation between development and operations, nor that SRE is a fancy(er) name for DevOps3. It means treating operations as a software engineering problem, using software to solve problems that used to be solved by hand, implementing rigorous testing and code reviewing, and taking decisions based on data, not just hunches. It also implies that SREs can understand the product they are supporting, and that there is a common ground and respect between SREs and software engineers (SWEs). There are many things that make SRE what it is, some of these only make sense within a special kind of company like Google: many different development and operations teams, service growth that can't be matched by hiring, and more importantly, firm commitment from top management to implement these drastic rules. Therefore, my focus here is not to preach on how everybody should adopt SRE, but to extract some of the most useful ideas that can be applied in a wider array of situations. Nevertheless, I will first try to give an overview of how SRE works at Google.
That's it for today. In the next post I will talk about how to end the war between developers and SysAdmins. Stay tuned!
  1. http://www.site-reliability-engineering.info/2014/04/what-is-site-reliability-engineering.html
  2. SRE checklist extracted from Treynor's talk at SREcon14: https://www.usenix.org/conference/srecon14/technical-sessions/presentation/keys-sre
  3. By the way, I am still not sure what DevOps mean, it seems that everyone has a different definition for it.
Comment

23 October 2015

Clint Adams: Beware of typhoons or tsunamis

The 12 member nations of the Trans-Pacific Partnership pact have agreed to prohibit demands that companies reveal software source code*, a step that appears aimed at curbing efforts by China to gain access to this sensitive information, The Yomiuri Shimbun has learned. Source code is the confidential information for software and is a blueprint embedded in many commonly used products, such as vehicles, mobile phones and home appliances. Source code is usually tightly guarded because it conatins commands that make using the software easier. China requires foreign companies operating there to hand over source code, a move that has sparked sharp criticism from many countries. Observers believe the decision by TPP participants to ban demands to reveal this code is intended to restrain China's move. The TPP's electronic commerce chapter in principle prohibits the 12 member nations from demanding access to source code for mass-produced software. According to the Economy, Trade and Industry Ministry, the Japan-Mongolia economic partnership agreement signed in February contains a stipulation banning demands for such information, but there are very few other examples around the world. Japan, the United States and other nations that are home to many information technology companies want to make the stipulation effectively a global standard, and they are considering whether to incorporate such a condition in economic partnership agreements that will be inked in the future. Source code is an important corporate secret for development firms. *Source code A software program written in a language a computer understands. As well as containing expert details about the unique functions of the product, the software is essential for fixing glitches and making improvements. Hackers have attempted to access source code because gaining this information would make it easier to create viruses that could exploit any software defects. In the software business, it is rarely made public, as it is considered a corporate secret.

22 October 2015

Norbert Preining: CafeOBJ 1.5.4 released

Yesterday we have released CafeOBJ 1.5.4 with a long list of changes, and many more internal changes. Documentation pages have been updated with the latest reference manual (PDF, Html) as well as some new docs on CITP (in Japanese for now) and tutorials. cafeobj-logo To quote from our README:
CafeOBJ is a new generation algebraic specification and programming language. As a direct successor of OBJ, it inherits all its features (flexible mix-fix syntax, powerful typing system with sub-types, and sophisticated module composition system featuring various kinds of imports, parameterised modules, views for instantiating the parameters, module expressions, etc.) but it also implements new paradigms such as rewriting logic and hidden algebra, as well as their combination.
Changes Changes since the last release are as follows Availability Binary packages for Windows, MacOS, and Linux have been built, and can be found at the CafeOBJ download page. The source code can also be found on the download page, or directly from here: cafeobj-1.5.4.tar.gz. The CafeOBJ Debian package has been updated and is already included in Debian/sid. Macports file has also been updated, please see the above download/install page for details how to add our sources to your macport. Bug reports If you find a bug, have suggestions, or complains, please open an issue at the issue tracker for CafeOBJ. For other inquiries, please use info@cafeobj.org

Daniel Pocock: New planet sites for SIP

I've started syndicating some SIP-related blogs at planet.sip5060.net (English) and planet.sip5060.net/es (Spanish). If anybody would like to have their blog added or suggest other blogs that deserve recognition, please email me. If a blog is not entirely dedicated to SIP, it is better to use a tag or category with a dedicated RSS feed URL for SIP articles. Articles related to Asterisk, FreeSWITCH, SIP proxies and softphones are all welcome. Please also remember to create links to the planet sites from your own blogs and web sites, it helps solutions based on free software to become more prominent online. Streamlining planet-site management I'm also looking for feedback about how to streamline management of the planet sites, maybe providing a self-service portal or letting people add themselves with Github pull requests. Has anybody else seen solutions for this?

Pau Garcia i Quiles: FOSDEM Desktops DevRoom 2016

It is now official: KDE will be present again at FOSDEM in the 2016 edition, on the 30th and 31st of January, 2016. Talks will take place at the Desktops DevRoom, on Sunday the 31st, but not exclusively: in past years, there were Qt and KDE-related talks at the mobile devroom, lightning talks, distributions, open document editors and more. KDE will be sharing the room with other desktop environments, as usual: Gnome, Unity, Enlightenment, Razor, etc. Representatives from those communities will be helping me in managing and organizing the devroom: Christophe Fergeau, Michael Zanetti, Philippe Caseiro and J rome Leclanche. I would like to extend the invitation to any other free/open source desktop environment and/or related stuff. Check last year s schedule for an example. Closed-source shops (Microsoft, Apple, Oracle, etc) are ALSO invited, provided that you will talk about something related to open source. We will publish the Call for Talks for the Desktops DevRoom 2016 soon. Stay tuned. In the meanwhile, you can subscribe to the Desktops DevRoom mailing list to be informed of important and useful information, and talk about FOSDEM and specific issues of the Desktops DevRoom.

Russ Allbery: Review: What If?

Review: What If?, by Randall Munroe
Publisher: Houghton Mifflin Harcourt
Copyright: 2014
ISBN: 0-544-27299-4
Format: Hardcover
Pages: 295
This is another one of those reviews that's somewhat pointless to write, at least beyond telling people who for some strange reason aren't xkcd readers that this is a thing that exists in the world. What If? is a collection of essays from that feature on the xkcd web site and new essays in the same vein. (Over half are new to this collection.) If you've read them, you know what to expect; if you haven't, and have any liking at all for odd scientific facts or stick figures, you're in for a treat. So, short review: The subtitle is Serious Scientific Answers to Absurd Hypothetical Questions, and it's exactly what it says on the tin, except that "serious" includes a healthy dose of trademark xkcd humor. Go read what-if.xkcd.com for numerous samples of Munroe's essay style. If you like what you see, this is a whole book of that: a nice, high-quality hardcover (at least the edition I bought), featuring the same mix of text and cartoon commentary, and with new (and in some cases somewhat longer) material. You probably now have all the information necessary to make a purchasing decision. If you need more motivation, particularly to buy a physical copy, the inside of the dust jacket of the hardcover is a detailed, labeled map of the world after a drain in the Marianas Trench has emptied most of the oceans onto Mars. And the book inside the dust jacket is embossed with what happens after the dinosaur on the cover is lowered into, or at least towards, the Great Pit of Carkoon. This made me particularly happy, since too often hardcovers inside the dust jacket look just like every other hardcover except for the spine lettering. Very few of them have embossed Star Wars references. Personally, I think that's a great reason to buy the hardcover even if, like me, you've been following What If? on the web religiously since it started. But of course the real draw is the new material. There's enough of it that I won't try any sort of comprehensive list, but rest assured that it's of equal or better quality than the web-published essays we know and love. My favorite of the new pieces is the answer to the question "what would happen if you made a periodic table out of cube-shaped bricks, where each brick was made of the corresponding element?" As with so many What If? questions, it starts with killing everyone in the vicinity, and then things get weird. Another nice touch in this collection is what I'd call "rejected questions": questions that people submitted but that didn't inspire an essay. Most of these (I wish all) get a single cartoon of reaction to the question itself, which include some of the funniest (and most touching) panels in the book. Ebook formatting has gotten much better, so there's some hope that at least some platforms could do justice to this book with its embedded cartoons. Putting the footnotes properly at the bottom of each page (thank you!) might be a challenge, though. Writing mixed with art is one of the things I think benefits greatly from a physical copy, and the hardcover is a satisfying and beautiful artifact. (I see there's also an audio book, but I'm sure how well that could work; so much of the joy of What If? is the illustrations, and I'm dubious that one could adequately describe them.) Prior web readers will be relieved to know that the mouse-over text is preserved as italic captions under the cartoons, although sadly most cartoons are missing captions. (As I recall, that's also the case for the early web What If? essays, but later essays have mouse-over text for nearly every cartoon.) Anyway, this is a thing that exists. If you follow xkcd, you probably knew that already, given that the book was published last year and I only now got around to reading it. (My current backlog is... impressive.) If you were not previously aware of What If? or of xkcd itself, now you are, and I envy you the joy of discovery. A short bit of reading will tell you for certain whether this is something you want to purchase. If your relationship to physics is at all similar to mine, I suspect the answer will be yes. A small personal note: I just now realized how much the style of What If? resembles the mixed text and illustrations of One Two Three... Infinity. Given how foundational that book was to my love of obscure physics facts, my love of What If? is even less surprising. Rating: 10 out of 10

Joey Hess: propellor orchestration

With the disclamer that I don't really know much about orchestration, I have added support for something resembling it to Propellor. Until now, when using propellor to manage a bunch of hosts, you updated them one at a time by running propellor --spin $somehost, or maybe you set up a central git repository, and a cron job to run propellor on each host, pulling changes from git. I like both of these ways to use propellor, but they only go so far... All those scenarios are supported by propellor now! Well, I haven't actually implemented concurrently yet, but the point is that the conducts property can be used with any of propellor's property combinators, like before etc, to express all kinds of scenarios. The conducts property works in combination with an orchestrate function to set up all the necessary stuff to let one host ssh into another and run propellor there. 
main = defaultMain (orchestrate hosts)
hosts = 
    [ master
    , webservers 
    , ...
    ]
The orchestrate function does a bunch of stuff: I've very pleased that I was able to add the Propellor.Property.Conductor module implementing this with only a tiny change to the rest of propellor. Almost everything needed to implement it was there in propellor's infrastructure already. Also kind of cool that it only needed 13 lines of imperative code, the other several hundred lines of the implementation being all pure code.

21 October 2015

Antoine Beaupr : Proprietary VDSL2 Linux routers adventures

I recently bought a wireless / phone adapter / VDSL modem from my Internet Service Provider (ISP) during my last outage. It generally works fine as a VDSL modem, but unfortunately, I can't seem to get used to configuring the device through their clickety web user interface... Furthermore, I am worried that I can't backup the config in a meaningful way, that is: if the device fails, I will probably not find the same model again and because they run a custom Linux distributions, the chances of the backup being possible to restore on another machine are basically zero. No way i will waste my time configuring this black box. So I started looking at running a distribution like OpenWRT on it.
(Unfortunately, I don't even dare hoping to run a decent operating system like Debian on those devices, if only because of the exotic chipsets that require all sorts of nasty hacks to run...)
The machine is a SmartRG SR630n (specs). I am linking to third party site, because the SmartRG site doesn't seem to know about their own product (!). I paid extra for this device to get one that would do both Wifi and VoIP, so i could replace two machines: my current Soekris net5501 router and a Cisco ATA 186 phone adapter that seems to mysteriously defy the challenges of time. (I don't remember when I got that thing, but it's at least from 2006.) Unfortunately, it seems that SmartRG are running a custom, proprietary Linux distribution. According to my ISP, init is a complete rewrite that reads an XML config file (and indeed it's the format of the backup files) and does the configuration through a shared memory scheme (!?). According to DSL reports, the device seems to be running a Broadcom 63168 SOC (system on a chip) that is unsupported in Linux. There are some efforts to write drivers for those from scratch, but they have been basically stalled for years now. Here are more details on the sucker: Now the next step would logically be to "simply" build a new image with OpenWRT and install it in place. Then I would need to figure out a way to load the binary blobs into the OpenWRT kernel and run all the ADSL utilities as well. It's basically impossible: the odds of the binary modules being compatible with another arbitrary release of the Linux kernel are near zero. Furthermore, the userland tool are most likely custom as well. And worse of all: it seems that Bell Canada deployed a custom "Lucent Stinger" DSLAM which requires a custom binary firmware in the modem. This could be why the SmartRG is so bizarre in the first place. As long as the other end is non-standard, we are all screwed. And those Stinger DSLAM will stick around for a long time, thanks to bell.
See this other good explanation of Stinger.
Which means this machine is now yet another closed box sitting on the internet without firmware upgrades, totally handicapped. I will probably end up selling it back for another machine that has OpenWRT support for their VDSL modems. But there are very few such machines, and with a lot of those, VDSL support is often marked as "spotty" or "in progress". Some machines are supported but are basically impossible to find. There's the Draytek modems are also interesting because, apparently, some models run OpenWRT out of the box too, which is a huge benefit. This is because they use the more open Lantiq SOC. Which are probably not going to support Stinger lines. Still, there are some very interesting projects out there... The Omnia is one I am definitely interested in right now. I really like their approach... But then they don't have a VDSL chipset in there (I asked for one, actually). And the connectors are only mini-PCIe, which makes it impossible to connect a VDSL PCI card into it. I could find a single VDSL2 PCI card online, and it could be supported, but only the annex B is available, not the annex A, and it seems the network is using "annex A" according to the ADSL stats i had in 2015-05-28-anarcat-back-again. With such a card, I could use my existing Soekris net5501 router, slam a DSL card into it, and just use the SmartRG as a dumb wifi router/phone adapter. Then it will remain to see how supported are those VDSL cards in FreeBSD (they provide Linux source code, so that's cool). And of course, all this assumes the card works with the "Stinger" mode, which is probably not the case anyways. Besides, I have VDSL2 here, not the lowly ADSL2+. By the way, Soekris keeps on pushing new interesting products out: their net6501, with 2 extra Gig-E cards could be a really interesting high-end switch, all working with free software tools. A friend has a SmartRG 505n modem, which looks quite similar, except without the ATA connectors. And those modems are the ones that Teksavvy recommends ("You may use a Cellpipe 7130 or Sagemcom F@ST 2864 in lieu of our SmartRG SR505N for our DSL 15/10, DSL 25 or DSL 50 services."). Furthermore, Teksavvy provides a firmware update for the 505n - again, no idea if it works with the 630n. Of course, the 505n doesn't run OpenWRT either. So, long story short, again I got screwed by my ISP: I thought i would get a pretty hackable device, "running Linux" that my ISP said over the phone. I got weeks of downtime, no refund, and while i got a better line (more reliable, higher bandwidth), my costs doubled. And I have yet another computing device to worry about: instead of simplifying and reducing waste, I actually just added crap on top of my already cluttered desk. Next time, maybe I'll tell you about how my ISP overbilled me, broke IPv6 and drops large packets to the floor. I haven't had a response from them in months now... hopefully they will either answer and fix all of this (doubtful) or I'll switch to some other provider, probably Teksavvy. Many thanks to the numerous people in the DSL reports Teksavvy forum that have amazing expertise. They are even building a map of Bell COs... Thanks also to Taggart for helping me figure out how the firmware images work and encouraging me to figure out how my machine works overall.
Note: all the information shared here is presented in the spirit of the fair use conditions of copyright law.

20 October 2015

Russ Allbery: Review: The Oathbound

Review: The Oathbound, by Mercedes Lackey
Series: Vows and Honor #1
Publisher: DAW
Copyright: July 1988
ISBN: 0-88677-414-4
Format: Mass market
Pages: 302
This book warrants a bit of explanation. Before Arrows of the Queen, before Valdemar (at least in terms of publication dates), came Tarma and Kethry short stories. I don't know if they were always intended to be set in the same world as Valdemar; if not, they were quickly included. But they came from another part of the world and a slightly different sub-genre. While the first two Valdemar trilogies were largely coming-of-age fantasy, Tarma and Kethry are itinerant sword-and-sorcery adventures featuring two women with a soul bond: the conventionally attractive, aristocratic mage Kethry, and the celibate, goddess-sworn swordswoman Tarma. Their first story was published, appropriately, in Marion Zimmer Bradley's Swords and Sorceress III. This is the first book about Tarma and Kethry. It's a fix-up novel: shorter stories, bridged and re-edited, and glued together with some additional material. And it does not contain the first Tarma and Kethry story. As mentioned in my earlier Valdemar reviews, this is a re-read, but it's been something like twenty years since I previously read the whole Valdemar corpus (as it was at the time; I'll probably re-read everything I have on hand, but it's grown considerably, and I may not chase down the rest of it). One of the things I'd forgotten is how oddly, from a novel reader's perspective, the Tarma and Kethry stories were collected. Knowing what I know now about publishing, I assume Swords and Sorceress III was still in print at the time The Oathbound was published, or the rights weren't available for some other reason, so their first story had to be omitted. Whatever the reason, The Oathbound starts with a jarring gap that's no less irritating in this re-read than it was originally. Also as is becoming typical for this series, I remembered a lot more world-building and character development than is actually present in at least this first book. In this case, I strongly suspect most of that characterization is in Oathbreakers, which I remember as being more of a coherent single story and less of a fix-up of puzzle and adventure stories with scant time for character growth. I'll be able to test my memory shortly. What we do get is Kethry's reconciliation of her past, a brief look at the Shin'a'in and the depth of Tarma and Kethry's mutual oath (unfortunately told more than shown), the introduction of Warrl (again, a relationship that will grow a great deal more depth later), and then some typical sword and sorcery episodes: a locked room mystery, a caravan guard adventure about which I'll have more to say later, and two rather unpleasant encounters with a demon. The material is bridged enough that it has a vague novel-like shape, but the bones of the underlying short stories are pretty obvious. One can tell this isn't really a novel even without the tell of a narrative recap in later chapters of events that you'd just read earlier in the same book. What we also get is rather a lot of rape, and one episode of seriously unpleasant "justice." A drawback of early Lackey is that her villains are pure evil. My not entirely trustworthy memory tells me that this moderates over time, but early stories tend to feature villains completely devoid of redeeming qualities. In this book alone one gets to choose between the rapist pedophile, the rapist lord, the rapist bandit, and the rapist demon who had been doing extensive research in Jack Chalker novels. You'll notice a theme. Most of the rape happens off camera, but I was still thoroughly sick of it by the end of the book. This was already a cliched motivation tactic when these stories were written. Worse, as with the end of Arrow's Flight, the protagonists don't seem to be above a bit of "turnabout is fair play." When you're dealing with rape as a primary plot motivation, that goes about as badly as you might expect. The final episode here involves a confrontation that Tarma and Kethry brought entirely on themselves through some rather despicable actions, and from which they should have taken a lesson about why civilized societies have criminal justice systems. Unfortunately, despite an ethical priest who is mostly played for mild amusement, no one in the book seems to have drawn that rather obvious conclusion. This, too, I recall as getting better as the series goes along and Lackey matures as a writer, but that only helps marginally with the early books. Some time after the publication of The Oathbound and Oathbreakers, something (presumably the rights situation) changed. Oathblood was published in 1998 and includes not only the first Tarma and Kethry story but also several of the short stories that make up this book, in (I assume) something closer to their original form. That makes The Oathbound somewhat pointless and entirely skippable. I re-read it first because that's how I first approached the series many years ago, and (to be honest) because I'd forgotten how much was reprinted in Oathblood. I'd advise a new reader to skip it entirely, start with the short stories in Oathblood, and then read Oathbreakers before reading the final novella. You'd miss the demon stories, but that's probably for the best. I'm complaining a lot about this book, but that's partly from familiarity. If you can stomach the rape and one stunningly unethical protagonist decision, the stories that make it up are solid and enjoyable, and the dynamic between Tarma and Kethry is always a lot of fun (and gets even better when Warrl is added to the mix). I think my favorite was the locked room mystery. It's significantly spoiled by knowing the ending, and it has little deeper significance, but it's a classic sort unembellished, unapologetic sword-and-sorcery tale that's hard to come by in books. But since it too is reprinted (in a better form) in Oathblood, there's no point in reading it here. Followed by Oathbreakers. Rating: 6 out of 10

Ritesh Raj Sarraf: Controlling ill behaving applications with Linux Cgroups

For some time, I have been wanting to read more on Linux Cgroups to explore possibilities of using it to control Ill behaving applications. At this time, while I'm stuck in travel, it has given me some time to look into it. In our Free Software world, most of the things are do-o-cracy, i.e. when your use case is not the common one, it is typically you who has to explore possible solutions. It could be Bugs, Feature Requests or as is in my case, performance issues. But that is not to assume that we do not have better quality software in Free Software world. Infact, in my opinion, some of the tools available are far much more better than the competition in terms of features, and to add a sweetener (or nutritional facts) to it is the fact that Free Software liberates the user. One of my favorite tool, for photo management, is Digikam. Digikam is a big project, very featureful, and has some functionalities that may not be available in the competition. But as is with most Free Software projects, Digikam is a tool which underneath consumes many more subprojects from the Free Software ecosystem. For anyone who has used Digikam, may know some of the bugs that surface on it. Not necessarily a bug in Digikam, but maybe in one of the underneath libraries/tools that it consumes (Exiv, libkface, marble, OpenCV, libPGF etc). But the bottom line is that the overall Digikam experience (and if I may say: the overall GNU/Linux experience) takes a hit. Digikam has pretty powerful features for annotation, tagging, facial recognition. These features, together with Digikam, make it a compelling product. But the problem is that many of these projects are independent. Thus tight integration is a challenge. And at times, bugs can be hard to find, root cause and fix. Let's take a real example here. If you were to use Digikam today (version 4.13.0) with annotation, tagging and facial recognition as some of the core features for your use case, you may run into frustrating overall experience. Not just that, the bugs would also effect your overall GNU/Linux experience. The facial recognition feature, if triggered, will eat up all your memory. Thus leading you to uncover Linux's long old memory bug. The tagging feature, if triggered, again will lead to frequent I/O. Thus again leading to a stalled Linux system because of blocked CPU cycled, for nothing. So one of the items on my TODO list was to explore Linux Cgroups, and see if it was cleanly possible to tame a process to a confinement, so that even if it was ill behaving (for whatever reasons), your machine does not take the beating. And now that the cgroups consumer dust has kinda settled down, systemd was my first obvious choice to look at. systemd provides a helper utility, systemd-run, for similar tasks. With systemd-run, you could apply all the resource controller logic to the given process, typically cpu, memory and blkio. And restrict it to a certain set. You can also define what user to run the service as. 
rrs@learner:/var/tmp/Debian-Build/Result$ systemd-run -p BlockIOWeight=10 find /
Running as unit run-23805.service.
2015-10-20 / 21:37:44         
rrs@learner:/var/tmp/Debian-Build/Result$ systemctl status -l run-23805.service
  run-23805.service - /usr/bin/find /
   Loaded: loaded
  Drop-In: /run/systemd/system/run-23805.service.d
            50-BlockIOWeight.conf, 50-Description.conf, 50-ExecStart.conf
   Active: active (running) since Tue 2015-10-20 21:37:44 CEST; 6s ago
 Main PID: 23814 (find)
   Memory: 12.2M
      CPU: 502ms
   CGroup: /system.slice/run-23805.service
            23814 /usr/bin/find /
Oct 20 21:37:45 learner find[23814]: /proc/3/net/raw6
Oct 20 21:37:45 learner find[23814]: /proc/3/net/snmp
Oct 20 21:37:45 learner find[23814]: /proc/3/net/stat
Oct 20 21:37:45 learner find[23814]: /proc/3/net/stat/rt_cache
Oct 20 21:37:45 learner find[23814]: /proc/3/net/stat/arp_cache
Oct 20 21:37:45 learner find[23814]: /proc/3/net/stat/ndisc_cache
Oct 20 21:37:45 learner find[23814]: /proc/3/net/stat/ip_conntrack
Oct 20 21:37:45 learner find[23814]: /proc/3/net/stat/nf_conntrack
Oct 20 21:37:45 learner find[23814]: /proc/3/net/tcp6
Oct 20 21:37:45 learner find[23814]: /proc/3/net/udp6
2015-10-20 / 21:37:51
But, out of the box, graphical applications do not work. I haven't looked, but it should be doable by giving it the correct environment details.
Underneath, systemd is using the same Linux Control Groups to limit resources for individual applications. So, in cases where you have a requirement and do not have systemd, or you directly want to make use of cgroups, it could be easily done with basic cgroups tools like cgroup-tools.
With cgroup-tools, I now have a simple cgroups hierarchy set for my current use case, i.e. Digikam
rrs@learner:/var/tmp/Debian-Build/Result$ ls /sys/fs/cgroup/memory/rrs_customCG/
cgroup.clone_children           memory.kmem.tcp.limit_in_bytes      memory.numa_stat
cgroup.event_control            memory.kmem.tcp.max_usage_in_bytes  memory.oom_control
cgroup.procs                    memory.kmem.tcp.usage_in_bytes      memory.pressure_level
digikam/                        memory.kmem.usage_in_bytes          memory.soft_limit_in_bytes
memory.failcnt                  memory.limit_in_bytes               memory.stat
memory.force_empty              memory.max_usage_in_bytes           memory.swappiness
memory.kmem.failcnt             memory.memsw.failcnt                memory.usage_in_bytes
memory.kmem.limit_in_bytes      memory.memsw.limit_in_bytes         memory.use_hierarchy
memory.kmem.max_usage_in_bytes  memory.memsw.max_usage_in_bytes     notify_on_release
memory.kmem.slabinfo            memory.memsw.usage_in_bytes         tasks
memory.kmem.tcp.failcnt         memory.move_charge_at_immigrate
2015-10-20 / 21:45:38         
rrs@learner:/var/tmp/Debian-Build/Result$ ls /sys/fs/cgroup/memory/rrs_customCG/digikam/
cgroup.clone_children           memory.kmem.tcp.max_usage_in_bytes  memory.oom_control
cgroup.event_control            memory.kmem.tcp.usage_in_bytes      memory.pressure_level
cgroup.procs                    memory.kmem.usage_in_bytes          memory.soft_limit_in_bytes
memory.failcnt                  memory.limit_in_bytes               memory.stat
memory.force_empty              memory.max_usage_in_bytes           memory.swappiness
memory.kmem.failcnt             memory.memsw.failcnt                memory.usage_in_bytes
memory.kmem.limit_in_bytes      memory.memsw.limit_in_bytes         memory.use_hierarchy
memory.kmem.max_usage_in_bytes  memory.memsw.max_usage_in_bytes     notify_on_release
memory.kmem.slabinfo            memory.memsw.usage_in_bytes         tasks
memory.kmem.tcp.failcnt         memory.move_charge_at_immigrate
memory.kmem.tcp.limit_in_bytes  memory.numa_stat
2015-10-20 / 21:45:53         

rrs@learner:/var/tmp/Debian-Build/Result$ cat /sys/fs/cgroup/cpu/rrs_customCG/cpu.shares 
1024
2015-10-20 / 21:48:44         
rrs@learner:/var/tmp/Debian-Build/Result$ cat /sys/fs/cgroup/cpu/rrs_customCG/digikam/cpu.shares 
512
2015-10-20 / 21:49:05         
rrs@learner:/var/tmp/Debian-Build/Result$ cat /sys/fs/cgroup/memory/rrs_customCG/memory.limit_in_bytes 
9223372036854771712
2015-10-20 / 22:20:14         
rrs@learner:/var/tmp/Debian-Build/Result$ cat /sys/fs/cgroup/memory/rrs_customCG/digikam/memory.limit_in_bytes 
2764369920
2015-10-20 / 22:20:27         
rrs@learner:/var/tmp/Debian-Build/Result$ cat /sys/fs/cgroup/blkio/rrs_customCG/blkio.weight
500
2015-10-20 / 21:51:43         
rrs@learner:/var/tmp/Debian-Build/Result$ cat /sys/fs/cgroup/blkio/rrs_customCG/digikam/blkio.weight
10
2015-10-20 / 21:51:50
The base group, $USER_customCG needs super admin privileges. Which once set appropriately, allows the user to further self-define sub-groups. And users can then also define separate limits per sub-group.
With the resource limitations set in place, my overall experience on very recent hardware (Intel Haswell Core i7, 8 GiB RAM, 500 GB SSHD, 128 GB SSD) has improved considerably. It still is not perfect, but it definitely is a huge improvement over what I had to go through ealire: A stalled machine for hours.
top - 21:54:38 up 1 day,  6:46,  1 user,  load average: 7.22, 7.51, 7.37
Tasks: 299 total,   1 running, 298 sleeping,   0 stopped,   0 zombie
%Cpu0  :  7.1 us,  3.0 sy,  1.0 ni, 11.1 id, 77.8 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu1  :  6.0 us,  4.0 sy,  2.0 ni, 49.0 id, 39.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu2  :  5.0 us,  2.0 sy,  0.0 ni, 24.8 id, 68.3 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu3  :  5.9 us,  5.0 sy,  0.0 ni, 21.8 id, 67.3 wa,  0.0 hi,  0.0 si,  0.0 st
MiB Mem : 7908.926 total,   96.449 free, 4634.922 used, 3177.555 buff/cache
MiB Swap: 8579.996 total, 3454.746 free, 5125.250 used. 2753.324 avail Mem 
PID to signal/kill [default pid = 8879] 
  PID  PPID nTH USER        PR  NI S %CPU %MEM     TIME+ COMMAND                           UID 
 8879  8868  18 rrs         20   0 S  8.2 31.2  37:44.64 digikam                          1000 
10255  9960   4 rrs         39  19 S  1.0  0.8  19:47.73 tracker-miner-f                  1000 
10157  9960   7 rrs         20   0 S  0.5  3.0  32:29.76 gnome-shell                      1000 
    7     2   1 root        20   0 S  0.2        0:53.48 rcu_sched                           0 
  401     1   1 root        20   0 S  0.2  1.3   0:54.93 systemd-journal                     0 
10269  9937   4 rrs         20   0 S  0.2  0.4   2:34.50 gnome-terminal-                  1000 
15316     1  14 rrs         20   0 S  0.2  3.7  30:05.96 evolution                        1000 
23777     2   1 root        20   0 S  0.2        0:05.73 kworker/u16:0                       0 
23814     1   1 root        20   0 D  0.2  0.0   0:02.00 find                                0 
24049     2   1 root        20   0 S  0.2        0:01.29 kworker/u16:3                       0 
24052     2   1 root        20   0 S  0.2        0:02.94 kworker/u16:4                       0 
    1     0   1 root        20   0 S       0.1   0:18.24 systemd                             0
The reporting tools may not be correct here. Because from what is being reported above, I should be having a machine stalled, and heavily paging, while the kernel scanning its list of processes to find the best process to kill. From this approach of jailing processes, the major side effect I can see is that the process (Digikam) is now starved of resources and will take much much much more time than what it would have been usually. But in the usual cases, it takes up all, and ends up starving (and getting killed) for consuming all available resources. So I guess it is better to be on a balanced resource diet. :-)

Categories:

Keywords:

Like:

18 October 2015

Lunar: Reproducible builds: week 25 in Stretch cycle

What happened in the reproducible builds effort this week: Toolchain fixes Niko Tyni wrote a new patch adding support for SOURCE_DATE_EPOCH in Pod::Man. This would complement or replace the previously implemented POD_MAN_DATE environment variable in a more generic way. Niko Tyni proposed a fix to prevent mtime variation in directories due to debhelper usage of cp --parents -p. Packages fixed The following 119 packages became reproducible due to changes in their build dependencies: aac-tactics, aafigure, apgdiff, bin-prot, boxbackup, calendar, camlmix, cconv, cdist, cl-asdf, cli-common, cluster-glue, cppo, cvs, esdl, ess, faucc, fauhdlc, fbcat, flex-old, freetennis, ftgl, gap, ghc, git-cola, globus-authz-callout-error, globus-authz, globus-callout, globus-common, globus-ftp-client, globus-ftp-control, globus-gass-cache, globus-gass-copy, globus-gass-transfer, globus-gram-client, globus-gram-job-manager-callout-error, globus-gram-protocol, globus-gridmap-callout-error, globus-gsi-callback, globus-gsi-cert-utils, globus-gsi-credential, globus-gsi-openssl-error, globus-gsi-proxy-core, globus-gsi-proxy-ssl, globus-gsi-sysconfig, globus-gss-assist, globus-gssapi-error, globus-gssapi-gsi, globus-net-manager, globus-openssl-module, globus-rsl, globus-scheduler-event-generator, globus-xio-gridftp-driver, globus-xio-gsi-driver, globus-xio, gnome-control-center, grml2usb, grub, guilt, hgview, htmlcxx, hwloc, imms, kde-l10n, keystone, kimwitu++, kimwitu-doc, kmod, krb5, laby, ledger, libcrypto++, libopendbx, libsyncml, libwps, lprng-doc, madwimax, maria, mediawiki-math, menhir, misery, monotone-viz, morse, mpfr4, obus, ocaml-csv, ocaml-reins, ocamldsort, ocp-indent, openscenegraph, opensp, optcomp, opus, otags, pa-bench, pa-ounit, pa-test, parmap, pcaputils, perl-cross-debian, prooftree, pyfits, pywavelets, pywbem, rpy, signify, siscone, swtchart, tipa, typerep, tyxml, unison2.32.52, unison2.40.102, unison, uuidm, variantslib, zipios++, zlibc, zope-maildrophost. The following packages became reproducible after getting fixed: Packages which could not be tested: Some uploads fixed some reproducibility issues but not all of them: Patches submitted which have not made their way to the archive yet: Lunar reported that test strings depend on default character encoding of the build system in ongl. reproducible.debian.net The 189 packages composing the Arch Linux core repository are now being tested. No packages are currently reproducible, but most of the time the difference is limited to metadata. This has already gained some interest in the Arch Linux community. An explicit log message is now visible when a build has been killed due to the 12 hours timeout. (h01ger) Remote build setup has been made more robust and self maintenance has been further improved. (h01ger) The minimum age for rescheduling of already tested amd64 packages has been lowered from 14 to 7 days, thanks to the increase of hardware resources sponsored by ProfitBricks last week. (h01ger) diffoscope development diffoscope version 37 has been released on October 15th. It adds support for two new file formats (CBFS images and Debian .dsc files). After proposing the required changes to TLSH, fuzzy hashes are now computed incrementally. This will avoid reading entire files in memory which caused problems for large packages. New tests have been added for the command-line interface. More character encoding issues have been fixed. Malformed md5sums will now be compared as binary files instead of making diffoscope crash amongst several other minor fixes. Version 38 was released two days later to fix the versioned dependency on python3-tlsh. strip-nondeterminism development strip-nondeterminism version 0.013-1 has been uploaded to the archive. It fixes an issue with nonconformant PNG files with trailing garbage reported by Roland Rosenfeld. disorderfs development disorderfs version 0.4.1-1 is a stop-gap release that will disable lock propagation, unless --share-locks=yes is specified, as it still is affected by unidentified issues. Documentation update Lunar has been busy creating a proper website for reproducible-builds.org that would be a common location for news, documentation, and tools for all free software projects working on reproducible builds. It's not yet ready to be published, but it's surely getting there. Homepage of the future reproducible-builds.org website Who's involved? page of the future reproducible-builds.org website Package reviews 103 reviews have been removed, 394 added and 29 updated this week. 72 FTBFS issues were reported by Chris West and Niko Tyni. New issues: random_order_in_static_libraries, random_order_in_md5sums.

17 October 2015

Iustin Pop: Server upgrades and monitoring

Undecided whether the title should be "exercises in Yak shaving" or "paying back technical debt" or "too much complexity for personal systems". Anyway I started hosting my personal website and some other small stuff on a dedicated box (rented from a provider) in early 2008. Even for a relatively cheap box, it worked without issues for a good number of years. A surprising number of years, actually; the only issue was a power supply failure that was solved by the provider automatically and then nothing for many years. Even the harddrive (mechanical) had no issues at all for 7 years (Power_On_Hours: 64380; I probably got it after it had a few months of uptime). I believe it was the longest running harddrive I've ever used (for the record: Seagate Barracuda 7200.10, ST3250310AS). The reason I delayed upgrade for a long time was twofold: first, at the same provider I couldn't get a similar SLA for the same amount of money. I could get better hardware, but with worse SLA and options. This is easily solvable, of course, by just finding a different provider. The other issue was that I never bothered to setup proper configuration management for the host; after all, it was only supposed to run Apache with ikiwiki and some other trivial small other things. The truth was that over time it started pilling up more and more "small things" so actually changing the host is expensive. As the age of the server neared 7 years, I thought to combine upgrade from Wheezy to Jessie with a HW upgrade. Managed to find a different provider that had my desired SLA and HW configuration, got the server and the only thing left was to do the migration. Previous OS upgrades were simple as they were on the same host; i.e. rely on Debian's reliable upgrade and nothing else to, eventually adjust slightly some configs. With a cross-host upgrade (I couldn't just copy the old OS since it was also a 32-to-64 bit change) it's much worse: since there's no previous installation, I had to manually check and port the old configuration for each individual service. This got very tedious, and I realised I have to make it somehow better. "Proper" configuration management aside, I thought that I need proper monitoring first. I already had (for a long while actually) graphing via Munin, but no actual monitoring. Since the host only had few services, this was again supposed to be easy - same mistake again. The problem is that once you have any monitoring system setup, it's very easy to actually add "just one more" host or service to it. First it was only the external box, then it was my firewall, then it was the rest of my home network. Then it was the cloud services that I use for example, checking whether my domain registrar's nameservers still are authoritative for my domain or whether the expiration date it still far in the future. And so on In the end, what was in previous iterations (e.g. Squeeze to Wheezy upgrade) a half-weekend job only, spread out over many weekends (interleaved with other activities, not fully working on it). I had to keep the old machine running for a month more in order to make sure everything was up and running, and I ended up with 80 services monitored across multiple systems; the migrated machine itself has almost half of these. Some of these are light items (e.g. a checking that a single vhost responds) other are aggregates. I still need to add some more checks though, especially more complex (end-to-end) ones. The lesson I learned in all this is that, with or without configuration management in place, having monitoring makes it much easier do to host or service moves, as you know much better when everything is done whether it's "done-done" or just "almost done". The question that remains though: with 80 services for a home network plus external systems (personal use); I'm not sure if I'm doing things right (monitor the stuff I need) or wrong (do I really need these many things)?

16 October 2015

Vincent Sanders: Raspberries are not the only fruit

I have worked with ARM based systems for longer than I care to admit to myself. From the Acorn Archimedes 305 in 1987 through to modern 64bit systems I have seen many many changes in the ARM community. One big change has been the rise of the inexpensive single board computer (SBC).

Arguably the Raspberry Pi (RPi) was responsible for starting this trend. Before RPi there were small development boards available, I was even involved in producing some of them, none of these really became a big thing and were principally vehicles for silicon vendors to showcase their SoC in an accessible way. When I say accessible I mean for silicon vendors who were previously used to charging many thousands of pounds for their development boards now only charging hundreds.

Raspberry Pi 2 B+ in my case
In my opinion the RPi was a complete disruption to the SBC market. In early 2012 a complete ARM computer system could now be purchased for $35 ( 25) which was substantially cheaper than the best contemporary competitor the Beaglebone $89 ( 60)

To be clear, the reason the RPi succeeded (millions sold, household name) was not on price alone but also the large amount of good supporting software and how easy it was made for teachers and makers to use.

There were several areas that the RPi managed to change perceived issues into opportunities for using what was already available or third parties to provide. There were also several issues raised about the original RPi:
Some of these have been addressed since release as the foundation now sells cases, hardware revisions with much more powerful processors, pre-configured storage, cameras and displays. The important thing to note here though is the RPi has made the bare SBC a much more widely accepted product where all the non critical parts are considered "extras" and a lot is forgiven because of the price.

With that acceptance there have been many, many new SBC coming to market with better peripherals and increasingly competitive pricing. These are technically not clones as none of them use the Broadcom processor of the RPi but they often share many features and possibly even a compatible expansion header.

Banana pi in my case with a 2.5inch drive bay
The Banana Pi was one of these copycats which I acquired for a similar price as an RPi in 2014. The main processor of this system was a 1Ghz dual core Allwinner A20 processor (a considerable advance on the 700MHz single core of the original RPi) coupled to a gigabyte of memory. Additionally the board benefited from having SATA and gigabit Ethernet MAC which made for a much more versatile system. Various third parties filled in the missing peripherals including my own attempt at a case.

I acquired a cubietruck for the NetSurf project to use as a build node in their CI system this is again based on the A20 but with more memory and somewhat better peripheral support but at a substantial cost over the Banana Pi.

The most recent addition to this form factor is the introduction by Xunlong Software of the Orange Pi PC. This little board is the same footprint as the RPi2 B+ design but with differing connector placement. The processor is a quad core 1.6GHz Allwinner H3 with a gigabyte of memory and has has Ethernet and USB but no SATA.

Pile of Orange Pi PC in my cases
The big news about this board though is the price, at $15 ( 10) it resets the price expectations just as the RPi did before it. I was initially sceptical of the quality of the product (or if it would arrive at all) but I have acquired five of these boards and every one of them came well packaged, boxed and in a static bag, just like the RPi does, and they all worked.

I created a case design based on my RPi slimline case so they would be protected when piled up with all the other boards. The use of a DC barrel jack instead of micro USB for power is better in that the connector is more robust and intended for higher current draws but does mean additional leads are needed. There are, however, two flies in the ointment, neither are showstoppers but make the board a little more difficult to use.

Orange Pi in my case with heatsinkOne is a simple necessity of a substantial heatsink on the H3 processor. Initially I used a small 20 x 20mm copper heatsink (around 800mm square surface area) but this was insufficient under full load. I did not want to have to use a fan so I milled some slots into copper round bar, then cut off sections and faced them on a lathe. The completed design had more than 2200 square mm surface area and cost around $2.5 ( 1.5) in material (and a couple of hours in the workshop but that was fun and I made something)

The second issue and arguably much more serious is that of software. Let me be honest, it is dreadful, I mean very bad indeed. The images provided from the Orange Pi website are some of the worst examples of "do something quick" I have experienced.

Fortunately a user on the forums named loboris decided to create scripts that generate a Debian (and Ubuntu and Fedora) distribution images that can be installed from SD card. He relies on a somewhat patched 3.4 kernel full of Allwinner vendor changes and the inevitable binary blobs for the Marli GPU but the result does work.

I have had a few units acting as distcc compiler slaves for two weeks now at 100% CPU loading and they are still running. The processor does not get overly warm with the heatsink installed and Debian behaves just fine. The main caveat being that it is definitely not going to work if you try and update the kernel through packaging.

My ARM build farm as a pile of SBC
The state of software support and Xunlong Software relying on a forum user to complete their product does tarnish an otherwise impressive and possibly market changing SBC.

Perhaps I expect too much for fifteen bucks? I guess when the cost of the case, heatsink, cables and memory storage card is similar to the rest of the computer there is simply no margin left for anything else.

In conclusion hopefully this brief overview has provided some insight into what is available in this market and that the Raspberry Pi is indeed not the only option.

I finish with an image is of my ARM build farm consisting of every SBC I mention here (including a couple of RPi)

Daniel Pocock: Enterprise-grade SIP coming to Telepathy

I've just announced the reSIProcate connection manager for the Telepathy framework on the Linux desktop. As the announcement states, it is still a proof-of-concept. It was put together very rapidly just to see how well the reSIProcate project and its build system interacts with TelepathyQt, the Qt framework and DBus. That said, I've been able to make calls from GNOME Empathy to Jitsi, Lumicall and Asterisk. Why this is important Telepathy is the default communications framework installed on many Linux desktops. Yet none of the standard connection managers offers thorough support for NAT traversal. NAT traversal is essential for calling people who are not on the same LAN, whether it is just making a call across town or across the world. The XMPP connection manager offers limited support for NAT traversal if one party in the call is using a Google account, but with Google deprecating XMPP support and not everybody wanting to use Google anyway, that is not a stable foundation for free operating systems. The reSIProcate solution TURN is the standard (RFC 5766) for relaying media streams when two users want to communicate across the boundaries of NAT networks. There are several TURN servers packaged on Linux now. TURN has also been adopted for WebRTC, so it is a good foundation to build on. reSIProcate's reCon library provides a high-level telephony API supporting TURN as well as DTLS-SRTP encryption and many other enterprise-grade features. It also has thorough support for things like DNS NAPTR and SRV records, so you can just put in your SIP address and password and it can discover the correct SIP server, port number and transport protocol from DNS queries. This helps solve another common problem, the complexity of configuring some other softphones. Screenshots A SIP buddy list isn't supported yet: We have to use the Empathy menu to start calls (New Call...) or access account settings: The account settings are very simple. Everything can be discovered using NAPTR and SRV queries, saving the user typing. For now, the TURN server is entered manually but that can also be discovered using an SRV query. Placing a call from my fedrtc.org Fedora SIP account to my debian.org SIP account: Project status and direction More work is required to make this connection manager fully functional. It is available now for testing against other products and to get feedback about how the design should evolve.

Russ Allbery: Review: Ancillary Mercy

Review: Ancillary Mercy, by Ann Leckie
Series: Imperial Radch #3
Publisher: Orbit
Copyright: October 2015
ISBN: 0-316-24668-9
Format: Trade paperback
Pages: 330
This is the third book of the series that starts with Ancillary Justice. Please don't read it out of order. The three books form a rare thing in SF: a trilogy with a clear start and a clear ending. They're ideally read fairly close together so that you can remember the people involved. By the end of Ancillary Sword, Leckie had apparently resolved most of the plot in the Athoek system, although the Ghost Gate and broader imperial turmoil still lurked. I was expecting this novel to be another change of scene, and probably a broadening of the scope into the more sweeping events set off by earlier books. That's not what Ancillary Mercy is at all. Leckie caught me by surprise early, and the book kept not going in the direction I was expecting. And the result is brilliant. It's obviously difficult to talk about this in detail, since there's no way I'm going to spoil this or any of the previous books. This is some of the best SF I've ever read, and I want anyone who's not read the series yet to have the full experience. What I will say is that there was a lot of character growth left, including in some places that I thought would remain setting-mandated blind spots. Leckie tackles some very tricky themes, ones that are hard to do well because of how thoroughly the ground has already been explored, and still manages to find an original take and an even more original tone. And remains true to Breq's characterization throughout, including one critical scene that's masterful in its heart-breaking understatedness. Breq's flat affect is both very difficult and incredibly rewarding as a first-person protagonist. If I had to call out one thing that makes this series so special to me, it's the way that Leckie puts the reader in the middle of a restrained and very careful culture, centers the book on a character with a very unusual relationship to emotion, nearly completely avoids outward displays of feeling, treats emotions primarily as data to be weighed with other information, and yet provides just the right amount of subtle clues and external reflection to show just how central emotion is to everything that happens. This is an incredibly difficult balancing act, much harder than an openly emotional book (let alone the tough-guy cliches that military SF is normally full of), and it makes the occasional pay-offs so rewarding. I think some people might find Ancillary Mercy too understated, but I thought it was note-perfect throughout. And the ending was spectacular. For those who are less enamored of Breq and more interested in the plot, don't worry: we do get some resolution to most of the loose threads. There's clearly potential in this universe for more stories (and apparently more books coming!), but this trilogy comes to a definite end. If I had to quibble, I'd say that a few bits of the plot are too convenient: the resolution would have been impossible without one very critical mistake at the start of the second book, and there's at least one perfectly-timed accident. But Leckie's most critical plot resolution tool was properly hung on the wall in the last book and used perfectly. It's hard to manage a satisfying resolution to a twisty political conflict between very sharp antagonists; for me, at least, Leckie pulls it off. Looking back on the whole series, I find it striking how much more satisfying and believable Leckie's military culture is for her setting than those I normally read. I think we're too often given far-future military stories that are full of impulsive drama, high emotion, and physical feats. But in a world of starships and space stations, advanced computers, careful and systematized roles, and precise engineering, that's not realistic. While there is some physical violence required, problems in that world are more likely to look like operational computer problems than gladiatorial problems. That means the required tools are careful and fast analytical skills, quick iterative decision-making, and precise execution, not physical toughness and grit. In that world, adrenaline is at best useless and often your enemy. Leckie's world of tea sets and emotional control is partly driven by other world-building factors, but, particularly in this book, I was struck by how well-adapted it is to a military where calm decisions and efficient follow-through are far more important than adrenaline-driven courage. The emotion is absolutely there, but the catharsis doesn't come through bloody battles or feats of physicality. Again, so tricky to pull off, since it plays against the expectations we bring as readers to a war story, but I found it so much more satisfying when written well. I also love that this series is not about saving the world, at least in any direct sense. It is about justice, and ethics, and about standing up for what's right, but it's just as much about identity, about how to choose and define one's ethics, and how to make the most of the small number of decisions one gets to make. Everyone in this world is operating under sharp constraints: culture, ability, available alliances, physical limitations, and particularly the role into which they were cast. Huge things happen in this series, but not from the dramatic, order-overturning action of Chosen Ones. Rather, change is created by individuals who find small points of leverage and definition, and who make quiet, critical decisions to become better people than they were. I adore this series, and particularly this conclusion, beyond all rational measure. I'm sure that won't be universal, just as other readers weren't as enamored as I was of the direction Leckie went in Ancillary Sword. But this was a series conclusion that I was not expecting at all, that kept surprising me right up to the climax, and was exactly the conclusion that I wanted. If you liked the previous books, and particularly if you liked Ancillary Sword but thought Breq was a bit too much in control of the plot and a bit too able to make things go her way, I think you'll love Ancillary Mercy. This is simply the best SF series I've read in a long time. Rating: 10 out of 10

Dirk Eddelbuettel: R / Finance 2016 Call for Papers

Earlier today, Josh sent the text below in this message to the R-SIG-Finance list as the very first heads-up concerning the 2016 edition of our successful R/Finance series. We are once again very excited about our conference, thrilled about upcoming keynotes (some of which are confirmed and some of which are in the works), and hope that many R / Finance users will not only join us in Chicago in May 2016 -- but also submit an exciting proposal. So read on below, and see you in Chicago in May!
Call for Papers R/Finance 2016: Applied Finance with R
May 20 and 21, 2016
University of Illinois at Chicago, IL, USA The eight annual R/Finance conference for applied finance using R will be held on May 20 and 21, 2016, in Chicago, IL, USA at the University of Illinois at Chicago. The conference will cover topics including portfolio management, time series analysis, advanced risk tools, high-performance computing, market microstructure, and econometrics. All will be discussed within the context of using R as a primary tool for financial risk management, portfolio construction, and trading. Over the past seven years, R/Finance has included attendees from around the world. It has featured presentations from prominent academics and practitioners, and we anticipate another exciting line-up for 2016. We invite you to submit complete papers in pdf format for consideration. We will also consider one-page abstracts (in txt or pdf format) although more complete papers are preferred. We welcome submissions for both full talks and abbreviated "lightning talks." Both academic and practitioner proposals related to R are encouraged. All slides will be made publicly available at conference time. Presenters are strongly encouraged to provide working R code to accompany the slides. Data sets should also be made public for the purposes of reproducibility (though we realize this may be limited due to contracts with data vendors). Preference may be given to presenters who have released R packages. The conference will award two (or more) $1000 prizes for best papers. A submission must be a full paper to be eligible for a best paper award. Extended abstracts, even if a full paper is provided by conference time, are not eligible for a best paper award. Financial assistance for travel and accommodation may be available to presenters, however requests must be made at the time of submission. Assistance will be granted at the discretion of the conference committee. Please make your submission online at this link. The submission deadline is January 29, 2016. Submitters will be notified via email by February 29, 2016 of acceptance, presentation length, and financial assistance (if requested). Additional details will be announced via the R/Finance conference website as they become available. Information on previous years' presenters and their presentations are also at the conference website. For the program committee:
Gib Bassett, Peter Carl, Dirk Eddelbuettel, Brian Peterson,
Dale Rosenthal, Jeffrey Ryan, Joshua Ulrich

15 October 2015

Laura Arjona: Long summer story, Welcome team, and I am a Debian Developer now

Note: 2015/10/16: I need to add some links but I won t delay this more, posting now, will edit later. Summer ended long time ago, but believe me, I m still catching up with all the things that I began in June/July, all the things I left in August when I went holidays, and more things that appeared in August and September. This is a long overdue post, I hope you bear with me for waiting so long, and writing (now) so long too! June In June, I was 100% sure that I would not attend DebConf15 (well, I was 98% sure until then), and when the new Outreach Sponsorship grants were announced, I decided to write some mails to several Debian contributors, so they consider applying for the grant and attend DebConf (and maybe trigger some i18n/l10n meeting ). They kindly declined, and I understood their reasons, but also wondered what would have happened if the proposal would have come from somebody more official instead of a random contributor that they don t know. I also hoped that lots of other Debianites also write to newbies or not-yet-DD-contributors or non-packaging contributors to invite them to DebConf, and I hoped that they had better luck than me in convincing them :) July In July I usually work hard preparing the computer labs for next academic year at my workplace in the University, but I also have more free time in the long afternoons and evenings, since I don t sleep much, and there is not much to do outside with the summer hot. So I used that month to go on contributing to DebConf publicity and think a bit more about Debian and the other free software communities. I didn t put much time in advancing my selfhosting (no SSL yet in *.larjona.net! booooo!) but I decided to deep my toe in Sandstorm.io, and try to selfhost an instance ( http://lacaja.larjona.net ) and try Etherpad inside Sandstorm (since I failed in deploying Etherpad by myself in my jessie+nginx+postgres box). Sandstorm worked, and Etherpad was packaged in Sandstorm so it worked too; and I have my free-software-base pads now for writing and share. So I joined #sandstorm IRC channel since then, and there I learnt that Asheesh Laroia (who works in Sandstorm.io and is also a Debian Developer and was going to give a talk about Sandstorm.io in DebConf15) was offering mentorship for people wanting to learn Sandstorm packaging, and his proposal was to begin packaging Framadate. I also failed in selfhosting Dudle (prepared for Apache + FastCGI, couldn t make it work in my Nginx), so Asheesh s proposal looked suitable for me. We talked and decided to invest the rest of July and first days of August in learning to package Framadate. I learned a lot, but couldn t finish the task. I encountered many issues (setting my dev environment, and later trying to package), and we solved some of them but my time ran out. I posted my work in the list, and I hope that my feedback on the documentation and the issues I encountered helped Asheesh and the Sandstorm community. Framadate is packaged in Sandstorm.io now, Drew Fisher packaged it, not sure if my stuff was useful or not (it s been useful for me, for learning, at least). I ll talk more about Sandstorm.io in a future blog post updating on my selfhosting adventures. What I liked most was the kind of proposal of mentoring that Asheesh made. It was very detailed in every aspect: the task, the things you need to accomplish it, details about his availability for mentorship I try to be welcoming in the teams in which I participate, but the fact is that I fail in actually mentor, maybe because of not making specific proposals to people (until now, I was like Hi, newcomer! Go read this, this and this, and try for yourself any task you feel you like it, and come back if you have issues , la Debian ). This, plus the thoughts about my mails in June for diversity outreach in DebConf, made me feel the need of having a team where people willing to welcome newcomers share tricks and procedures, write together more specific proposals, and follow up the newcomers experiences in a regular way. I talked with Enrico Zini and we wrote down some notes for a Welcome Team in Debian; he said he would spread the word during DebCamp/DebConf and we would see what people thinks about it. August August came, and the day before going on holidays I was really tired: too much luggage to prepare, too many hours in front of the computer, and the usual stress of traveling; and I took the bad decision of signing some GPG keys of several Debianites that I met in July. I say bad decision because the lack of sleep showed its black magic and I accidentally deleted my secring.gpg file. I knew I had a backup but I didn t have too much time to invest and I didn t want to mess it with the backup too, and my laptop was going to stay at home, powered off, during the whole month, so I just went on holidays and left the GPG issue for later. The day after, meanwhile I was waiting in the airport for my boarding time, I received a mail accepting me as Debian Developer. Wow!! Really, I was not expecting that the process was already finished, I had interchanged several mails with my Application Manager (who happens to be the current DPL!) and I thought that his summer could be quite packed of Debian/DebConf work and my process could wait a bit. So it was a very happy news and very motivating after one month (July) full of free software work. On the other side, I was a bit scared: what type of Debian Developer are you, larjona, not capable to sign some GPG keys without breaking your setup?! but I answered myself well, I m the type of Debian Developer that has backups :) and then, with that mixed feelings of excitement and impostor syndrome, I took my plane and went on holidays, not expecting to touch any computer until the end of the month. August is probably the month in the year when I have more free time (holidays), but less time to dedicate to free software. I devote most of the month to visit family and stay with them, with no internet connection available or no free time to look at the mailbox or social networks or IRC But DebCamp and DebConf15 were happening during my holidays. And this DebConf15 was the first one in which I participated in the organization, and the first one in which I felt more than being a consumer of Debian videos . I could not follow the streamings, my only internet-capable device was my Android 2.x phone, but when I had wifi I fetched the mail, and during the nights, while everybody else was sleeping and I was laying on the terrace, below the sky full of stars, I could read batches of hundred of mails from debconf-discuss mailing list. And I could get some feeling from DebConf life, because I learned about the ad-hoc BoFs and discussions, the morning bike rides and swimming proposals, and the dancing classes, the i18m/l10n meeting, and many other things. I could answer some mail from time to time, and I also knew that a fellow Debianite from Madrid was going to bring me some stickers, maybe a t-shirt, and shake hands in my name to some persons. September and October September was about finishing reading all the mails and try to answer the pending ones, and preparing my computer to use my new Debian identity (and stop using larjona-guest). I still have some things to do, pending technical work, and some mails that I should have answered and I ve forgotten, for sure (if you sent me a mail that needs answer or would be fine that I answer (even if it was months ago!), please resend or ping me). I recovered my secring.gpg but and just now I added larjona@debian.org to the ID in my GPG key, but didn t signed the pending keys again (sorry dkg and holger! will catch up there soon). My subkeys expired and I m trying to find out how to proceed (they are in my FSFE SmartCard) :/ About the Debian teams, I ve resumed my work in publicity team (this year I ll try to be more involved, in Debian Project News in particular), partially in the website team, and recently I ve finished catching up with the Spanish translation of the website. I ve also joined the DebConf team again (for DebConf16, no matter I probably won t attend) and documented the Publicity task for DebConf, and I try to engage the mailing list and the IRC meetings. I finally could have time to watch some DebConf15 videos and Andreas Tille s talk ( Creating a more inviting environment for newcomers New experiences from MoM, SoB, Teammetrics ) helped me to step ahead in welcoming people with more useful stuff than Hi, newcomer! Go read this (general URLs), try for yourself whatever you like . I have made specific proposals for two people. In mid September I accepted an interview about Debian for a podcast with quite a lot audience (in Spanish), in which I explained the idea of the Welcome Team and offered myself as first-contact. Since then, two more people have contacted me and I have offered specific tasks I think are suitable for them. I also try to be more available in the IRC and offer some time spans for new contributors to DebConf to explain the git setup, the wiki, and all this stuff that looks more complicated than what it is. And I think that s all. My Debianite friend kindly brought me some stickers and a DebConf t-shirt, plus the organization t-shirt that the team gave me as present for my contributions in DebConf15. Neil McGovern kindly sent me a certificate of my new Debian Developer status (thanks!!), and it s posted in my wall at work. Here you are a photo! larjona_dd.JPG (Note: my wall is full of stickers and pieces of papers with things I need, things I like and things I use to explain my work (sometimes sarcastically/ironically ). Maybe some day I ll make a blog post about that!) I feel very proud and happy. Still, a lot of things to learn and work to do, but my intentions are: to keep on progressing (sometimes fast, sometimes slowly), never give up, and enjoy the multiple flowers I find in my way :) Thanks everybody! October and future Some other ideas/plans for the future (the ones I didn t say yet): Comments? If you want to comment you can use this pump.io thread.
Filed under: My experiences and opinion, News Tagged: Communities, Contributing to libre software, Debian, Developer motivations, encryption, English, Free Software, gpg, libre software

Next.

Previous.