Search Results: "cas"

15 December 2015

Chris Lamb: Peake Nationalism

Timothy Peake boarded the International Space Station a few hours ago becoming the United Kingdom's first official astronaut. It has become headline news, dominating the day's news cycle. But whilst Peake left our pale blue dot with only the humble honorific "Mister", he has subsequently been awarded the dubious appellation of "British Astronaut". Now, I'm no open-borders pan-nationalist and nor do I in any wish to detract or denigrate Peake's accomplishments indeed, it is only out of a genuine respect of "our Tim's" achievements that I pen this in the first place but are we still clinging to the idea that an extraordinary effort by a co-member of our species requires a nationalistic qualifier? How much do we really have in common with our "fellow countrymen"? This is, after all, the International Space Station, to which Peake was elevated from Kazakhstan on the back of a Russian rocket, in order that he may peacefully collaborate with an American, a Ukrainian, etc. I encountered the rebuttal that support of this nature is inspirational and incentive to others, but is it really motivating to know that if you toil to achieve greatness in this life then your accomplishments will be cheaply co-opted by mediocrities who only share the same colour passport as you? In this sense, isn't national pride really a form of national insecurity? A "Briton" in space: if space travel can teach us anything, it's that broadcasting the specific patch of ground you were born in is an outdated, tribalistic contrivance and should be assigned to the dustbin of history.

Vasudev Kamath: Persisting resource control options for systemd-nspawn containers

In my previous post on systemd-nspawn I mentioned, I was unclear on how to persist resource control options for a container. Today I accidentally discovered how can the property be persisted across boot without modifying service file or writing custom service file for container. It is done using systemctl set-property To set CPUAccounting and CPUShares for a container we need to run following command.

systemctl set-property systemd-nspawn@container.service  CPUACCounting=1 CPUShares=200

This actually persists these settings at location, /etc/systemd/systemd-nspawn@container.service.d/ folder. So in our case there will be 2 files created under above location by name 50-CPUAccounting.conf and 50-CPUShares.conf with following contents.

# 50-CPUAccounting.conf
[Service]
CPUAccounting=yes
# 50-CPUShares.conf
[Service]
CPUShares=200

Today when I discovered this folder and saw the file contents, I became curious and started to wonder who created this folder. The look at systemctl man page made showed me this.

set-property NAME ASSIGNMENT...

Set the specified unit properties at runtime where this is supported. This allows changing configuration parameter properties such as resource control settings at runtime. Not all properties may be changed at runtime, but many resource control settings (primarily those in systemd.resource-control(5)) may. The changes are applied instantly, and stored on disk for future boots, unless --runtime is passed, in which case the settings only apply until the next reboot. The syntax of the property assignment follows closely the syntax of assignments in unit files. Example: systemctl set-property foobar.service CPUShares=777
Note that this command allows changing multiple properties at the same time, which is preferable over setting them individually. Like unit file configuration settings, assigning the empty list to list parameters will reset the list.

I did remember doing this for my container and hence it became clear these files are actually written by systemctl set-property. In case you don't want to persist the properties across boot you can simply pass --runtime switch. Basically this is not just for container, resource control can be thus applied to any running service on the system. This is actually cool.

Michal Čihař: Weekly phpMyAdmin contributions

It has been already one week since last report and here comes next one. This week was half focused on fixing issues with Docker container for phpMyAdmin and on code cleanups. The Docker container got support for more options, making it better suited for various use cases. I'm still thinking whether using PHP's built in server here is a good idea or we should switch to something like nginx + PHP FPM, what would make the container bigger, but it would perform better. On the code cleanup and issues side, I started to work on two issues 11741 and 11731, which both pointed me to quite some code which could be removed or improved. Many of that was to support older PHP versions, which we no longer support. Anyway the work here is still in progress and both issues will take some time to resolve.

Filed under: English phpMyAdmin 0 comments

Antoine Beaupr : Using a Yubikey NEO for SSH and OpenPGP on Debian jessie

I recently ordered two Yubikey devices from Yubico, partly because of a special offer from Github. I ordered both a Yubikey NEO and a Yubikey 4, although I am not sure I remember why I ordered two - you can see their Yubikey product comparison if you want to figure that out, but basically, the main difference is that the NEO has support for NFC while the "4" has support for larger RSA key sizes (4096). This article details my experiment on the matter. It is partly based on first hand experience, but also links to various other tutorials that helped me along the way. Especially thanks to folks on various IRC channels that really helped me out in understanding this. My objective in getting a hardware security token like this was three-fold:

use 2FA on important websites like Github, to improve the security of critical infrastructure (like my Borg backup software)
login to remote SSH servers without exposing my password or my private key material on third party computers
store OpenPGP key material on the key securely, so that the private key material can never be compromised

To make a long story short: this article documents step 2 and implicitly step 3 (because I use OpenPGP to login to SSH servers). However it is not possible to use the key on arbitrary third party computers, given how much setup was necessary to make the thing work at all. 2FA on the Github site completely failed, but could be used on other sites, although this is not covered by this article. I have also not experimented in details the other ways the Yubikey can also be used (sorry for the acronym flood) as:

PIV (Personnal Identity Verification): basically to run your own Certificate Authority
OTP (One Time Password): allows sites to request a OTP from a Yubikey server validator. I haven't explored that mode since it requires a third party server and more modifications on the server side.
OATH (Initiative for Open Authentication): a purely "offline" and more "traditionnal" approach to OTP. In this mode, you can authenticate with only the token given by the key and a shared secret. Maybe i will follow this OATH tutorial eventually.

Update: OATH works! It is easy to configure and i added a section below.

Not recommended After experimenting with the device and doing a little more research, I am not sure it was the right decision to buy a Yubikey. I would not recommend buying Yubikey devices because they don't allow changing the firmware, making the device basically proprietary, even in the face of an embarrassing security vulnerability on the Yubikey NEO that came out in 2015. A security device, obviously, should be as open as the protocols it uses, otherwise it's basically impossible to trust that the crypto hasn't been backdoored or compromised, or, in this case, is vulnerable to the simplest drive-by attacks. Furthermore, it turns out that the primary use case that Github was promoting is actually not working as advertised: to use the Yubikey on Github, you actually first need to configure 2FA with another tool, either with your phone's text messages (SMS) or with something like Google Authenticator. After contacting Github support, they explained that the Yubikey is seen as a "backup device", which seems really odd to me, especially considering the promotion and the fact that I don't have a "smart" (aka "Google", it seems these days) phone or the desire to share my personal phone number with Github. Finally, as I mentioned before, the fact that those devices are fairly new and the configuration necessary to make them work at all is completely obtuse, non-standardized or at least not available by default on arbitrary computers makes them basically impossible to use on other computers than your own specially crafted gems.

Plugging it in The Yubikey, when inserted into a USB port, seems to be detected properly. It shows up both as a USB keyboard and a generic device.

d c 14 17:23:26 angela kernel: input: Yubico Yubikey NEO OTP+U2F as /devices/pci0000:00/0000:00:12.0/usb3/3-2/3-2:1.0/0003:1050:0114.0016/input/input127
d c 14 17:23:26 angela kernel: hid-generic 0003:1050:0114.0016: input,hidraw3: USB HID v1.10 Keyboard [Yubico Yubikey NEO OTP+U2F] on usb-0000:00:12.0-2/input0
d c 14 17:23:26 angela kernel: hid-generic 0003:1050:0114.0017: hiddev0,hidraw4: USB HID v1.10 Device [Yubico Yubikey NEO OTP+U2F] on usb-0000:00:12.0-2/input1

We'll be changing this now - we want to to support OTP, U2F and CCID. Don't worry about those acronyms now, but U2F is for the web, CCID is for GPG/SSH, and OTP is for the One Time Passwords stuff mentionned earlier. I am using the Yubikey Personalization tool from stretch because the jessie one is too old, according to Gorzen. Indeed, I found out that the jessie version doesn't ship with the proper udev rules. Also, note that we need to run as sudo otherwise we get a permission denied:

$ sudo apt install yubikey-personalization/stretch
$ sudo ykpersonalize -m86
Firmware version 3.4.3 Touch level 1541 Program sequence 1
The USB mode will be set to: 0x86
Commit? (y/n) [n]: y

To understand better what the above does, see the NEO composite device documentation. The next step is to reconnect the key, for the udev rules to kick in. If you were like me, you enthusiastically plugged in the device before installing the yubikey-personalization package, and the udev rules were not present then.

Configuring a PIN Various operations will require you to enter a PIN when talking to the key. The default PIN is 123456 and the default admin PIN is 12345678. You will want to change that, otherwise someone that gets a hold of your key could do any operation without your consent. For this, you need to use:

$ gpg --card-edit
> passwd
> admin
> passwd

Be sure to remember those passwords! Of course, the key material on the Yubikey can be revoked when you loose the key, but only if you still have control of the master key, or if you have a OpenPGP revocation certification (which you should have).

Configuring GPG To do OpenPGP operations (like decryption, signatures and so on), or SSH operations (like authentication on a remote server), you need to talk with GPG. Yes, OpenPGP keys are RSA keys that can be used to authenticate with SSH servers, that's not new and I have already been doing this with Monkeysphere for a while. Now the challenge is how to make GPG talk with the Yubikey. So the next step is to see if gpg can see the key alright, as described in the Yubikey importing keys howto - you will need first to install scdaemon and pcscd (according to this howto) for gpg-agent to be able to talk with the key:

$ sudo apt install scdaemon gnupg-agent pcscd
$ gpg-connect-agent --hex "scd apdu 00 f1 00 00" /bye
ERR 100663404 Card error <SCD>

Well that failed. At this point, touching the key types a bunch of seemingly random characters wherever my cursor is sitting - fun but totally useless still. That was because I failed to reconnect the key: make sure the udev rules are in place and reconnect the key, the above should work:

$ gpg-connect-agent --hex "scd apdu 00 f1 00 00" /bye
D[0000]  01 00 10 90 00                                     .....
OK

This shows it is running the firmware 1.10, which is not vulnerable to the infamous security issue. (Note: I also happened to install opensc and gpgsm because of this suggestion but I am not sure they are required at all.)

Using SSH To make GPG work with SSH, you need somehow to start gpg-agent with ssh support, for example with:

gpg-agent --daemon --enable-ssh-support bash

Of course, this will work better if it's started with your Xsession. Such an agent should already be started, so you just need to add the ssh emulation to its configuration file and restart your X session.

echo 'enable-ssh-support' >> .gnupg/gpg-agent.conf

In Debian Jessie, the ssh-agent wrapper will not start if it detects that you have already one running (for example from gpg-agent) but if that fails, you can try commenting out use-ssh-agent from /etc/X11/Xsession.options to keep it from starting up in your session. (Thanks to stackexchange for that reference.) Here I assume you have already created an authentication subkey on your PGP key. If you haven't, I suggest trying out simply monkeysphere gen-subkey, which will generate an authentication subkey for you. You can also do it by hand by following one of the OpenPGP/SSH tutorials from Yubikey, especially the more complete one. If you are going to generate a completely new OpenPGP key, you may want to follow this simpler tutorial here. Then you need to move your authentication subkey to the Yubikey. For this, you need to edit the key and use the keytocard command:

$ gpg2 --edit-key anarcat@debian.org
> toggle
> key 2
> keytocard
> save

Here, we use toggle to show the OpenPGP private key material. You should see a key marked with A for Authentication. Mine was the second one so I selected it with key 2 which put a star next to it. The keytocard command moved it to the key and save ensure the key was removed from the local keyring. Obviously, backups are essential before doing this, because it's perfectly possible to loose that key in the process, for example if you destroy or lose the key or forget the password. It's probably better to create a completely different authentication subkey for just this purpose, but that may require reconfiguring all remote SSH hosts, and you may not want to do that. Then SSH should magically talk with the GPG agent and ask you for the PIN! That's pretty much all there is to it - if it doesn't, it means that gpg-agent is not your SSH agent, and obviously things will fail... Also, you should be able to see the key being loaded in the agent when it is:

$ ssh-add -l
2048 23:f3:be:bf:1e:da:e8:ad:4b:c7:f6:60:5e:03:c2:a6 cardno:000603647189 (RSA)

.. that's about it! I have yet to cover 2FA and OpenPGP support, but that got me going for a while and I'll stop geeking around with that thing for now. It was fun, for sure, but not sure it's worth it for now.

Using OATH This is pretty neat: it allows you to add two factor authentication to a lot of things. For example, PAM has such a module, which I will configure here to allow myself to login to my server from untrusted machines. While I will expose my main password to keyloggers, the OTP password will prevent that from being reused. This is a simplified version of this OATH tutorial. We install the PAM module with:

sudo apt install libpam-oath

Then, we can hook it into any PAM consumer, for example with sshd:

--- a/pam.d/sshd
+++ b/pam.d/sshd
@@ -1,5 +1,8 @@
 # PAM configuration for the Secure Shell service
+# for the yubikey
+auth required pam_oath.so usersfile=/etc/users.oath window=5 digits=8
+
 # Standard Un*x authentication.
 @include common-auth

We also needed to allow OTP passwords in sshd explicitely, with:

ChallengeResponseAuthentication yes

This will force the user to enter a valid oath token on the server. Unfortunately, this will affect all users, regardless of whether they are present in the users.oath file. I filed bug #807990 regarding this, with a patch. Also, it means the main password is still exposed on the client machine - you can use the sufficient keyword instead of required to workaround that, but then it means anyone with your key can login to your machine, which is something to keep in mind. The /etc/users.oath file needs to be created with something like:

#type   username        pin     start seed
HOTP    anarcat -   00

00 is obviously a fake, and insecure string. Generate a proper one with:

dd if=/dev/random bs=1k count=1   sha1sum # create a random secret

Then the shared secret needs to be added to the Yubikey:

ykpersonalize -1 -o oath-hotp -o oath-hotp8 -o append-cr -a

You simply paste the random secret you created above, when prompted, and that shared secret will be saved in a Yubikey slot for future use. Next time you login to the SSH server, you will be prompted for a OATH password, you just touch the button on the key and it will be pasted there:

$ ssh -o PubkeyAuthentication=no anarc.at
One-time password (OATH) for  anarcat':
Password:
[... logged in!]

Final note: the centralized file approach makes it hard, if not impossible, for users to update their own secret token.. It would be nice if there would be a user-accessible token file, maybe ~/.oath? Filed feature request #807992 about this as well.

14 December 2015

Matthias Klumpp: AppStream/DEP-11 fully supported in Debian now!

Back in 2011, when the AppStream meeting in N rnberg had just happened, I published the DEP-11 (Debian Extension Project 11) draft together with Michael Vogt and Julian Andres Klode, as an approach to implement AppStream in Debian. Back then, the FTPMasters team rejected the suggestion to use the official XML specification, and so the DEP-11 specification was adapted to be based on YAML instead of XML. This wasn t much of a big deal, since the initial design of DEP-11 was to be a superset of the AppStream specification, so it wasn t meant to be exactly like AppStream anyway. AppStream back then was only designed for applications (as in stuff that provides a .desktop file ), but with DEP-11 we aimed for much more: DEP-11 should also describe fonts, drivers, pkg-config files and other metadata, so in the end one would be able to ask the package manager meaningful questions like is the firmware of device X installed? or request actions such as please install me the GIMP , making it unnecessary to know package names at all, and making packages a mere implementation detail. Then, GNOME-Software happened and demanded all these features. Back then, I was the de-facto maintainer of the AppStream upstream project already, but didn t feel like being the maintainer yet, so I only curated the existing specification, without extending it much. The big push forward GNOME-Software created changed that dramatically, and with me taking control of the specification and documenting it properly, the very essence of DEP-11 became AppStream (that was around the AppStream 0.6 release). So today, DEP-11 is mainly a YAML-based version of the AppStream XML specification. AppStream XML and DEP-11 YAML are implemented by two projects, GLib and Qt libraries exist to access the metadata and AppStream is used by the software centers of GNOME, KDE and Elementary. Today there are two things to celebrate for me: First of all, there is the release of AppStream 0.9 (that happened last Saturday already), which brings some nice improvements to the API for developers and some micro-optimizations to speed up Xapian database queries. Yay! The second thing is full DEP-11 support in Debian! This means that you don t need to copy metadata around manually, or install extra packages: All you need to do is to install the appstream package, everything else is done for you, and the data is kept up to date automatically. This is made possible by APT 1.1 (thanks to the whole APT team!), some dedicated support for it in AppStream directly, the work of our Sysadmin team at Debian, which set up infrastructure to build the metadata automatically, as well as our FTPMasters team where Joerg helped with the final steps of getting the metadata into the archive. That AppStream data is now in the archive doesn t mean we live in a perfect utopia yet there are still issues to be handled, but all the major work is done now and we can now gradually improve the data generator and tools and squash the remaining bugs. And another item from the good news department: It s highly likely that Ubuntu will follow Debian in AppStream/DEP-11 support with the upcoming Xenial release! But how can I make use of the new metadata? Just install the appstream package everything is done for you! Another easy way is to install GNOME-Software, which makes use of the new metadata already. KDE Discover in Debian does not enable support for AppStream yet, this will likely come later. If you prefer to use the command-line, you can now use commands like

sudo appsteamcli install org.kde.kate.desktop

This will simply install the Kate text editor. Who wants some statistics? At time the Debian Sid/Unstable suite contains 1714 valid software components. It could be even more if the errors generated during metadata extraction would be resolved. For that, the metadata generator has a nice statistics page, showing the amount of each hint type in the suite and the development of the available software components in Debian and the hint types count over time (this plot feature was just added recently, so we are still a bit low on data). For packagers and interested upstreams, the data extractor creates detailed reports for each package, explaining why data was not included and how to fix the issue (in case something is unclear, please file a bug report and/or get in contact with me). In summary Thanks to everyone who helped to make this happen! For me this project means a lot, when writing this blog post I realized that I am basically working on it for almost 5 years (!) now (and the idea is even older). Seeing it to grow to such a huge success in other distributions was a joy, but now Debian can join the game with first-class AppStream support as well, which makes me even happier. Afterall Debian is the distribution I feel most at home. There is still lots of work to do (and already a few bugs known), but the hardest part of the journey is done let s walk into a bright future with AppStream!

13 December 2015

Vasudev Kamath: Mount ordering and automount options in systemd

Just to give a brief recap of why I'm writing this post, I've to describe a brief encounter I had with systemd which rendered my system unbootable. I first felt its systemd's problem but later figured out it was my mistake. So below is brief story divided into 2 sections Problem and Solution. Here Problem describes issue I faced with systemd and Solution discusses the .mount and .automount suffix files used by systemd.

Problem I have several local bin folders and I don't want to modify PATH environment variable adding every other folder path. I first started using aufs as alternative to symlinks or modifying PATH variable. Recently I learnt about much more light weight union fs which is in kernel, overlayfs. And Google led me to Arch wiki article which showed me a fstab entry like below

overlay        /usr/local/bin        overlay noauto,x-systemd.automount,lowerdir=/home/vasudev/Documents/utilities/bin,upperdir=/home/vasudev/Documents/utilities/jonas-bin,workdir=/home/vasudev/Documents/utilities/bin-overlay    0       0

And after adding this entry, on next reboot systemd is not able to mount my LVM home and swap partition. It does however mount root partition. It gives me emergency target but login never returns. So without any alternative I had to reinstall the system. But funnily enough I started encountering the same issue (yeah after I had added above entry into fstab). Yeah that time I never thought that its culprit. My friend Ritesh finally got my system booting after the weird x-systemd.automount option. I never investigated further that time on why this problem occurred.

Solution After re-encounter with similar problem and some other project I read the manual on systemd.mount, systemd-fstab-generator and systemd.automount and I had some understanding of what really went wrong in my case above. So now let us see what really is happening. All the above happened because, systemd translates the /etc/fstab into .mount units at run time using systemd-fstab-generator. Every entry in fstab translates into a file named after the mount point. The / in the path of the mount point is replaced by a -. So / mount point is named as -.mount and /home is named as home.mount and /boot becomes boot.mount. All these files can be seen in directory /run/systemd/generator. And all these mount points are needed by local-fs.target , if any of these mount points fail, local-fs.target fails. And if local-fs.target fails it will invoke emergency.target. systemd-fstab-generator manual suggests the ordering information in /etc/fstab is discarded. That means if you have union mounts, bind mounts or fuse mounts in the fstab which is normally at end of fstab and uses path from /home or some other device mount points it will fail to get mounted. This happens because systemd-fstab-generator didn't consider the ordering in fstab. This is what happened in my case my overlay mount point which is usr-local-bin.mount was some how happened to be tried before home.mount because there is no explicit dependency like Requires= or After= was declared. When systemd tried to mount it the path required under /home were not really present hence failed which in return invoked emergency.target as usr-local-bin.mount is Requires= dependency for local-fs.target. Now what I didn't understand is why emregency.target never gave me the root shell after entering login information. I feel that this part is unrelated to the problem I described above and is some other bug. To over come this what we can do is provided systemd-fstab-generator some information on dependency of each mount point. systemd.mount manual page suggests several such options. One which I used in my case is x-systemd.requires which should be placed in options column of fstab and specify the mount point which is needed before it has to be mounted. So my overlay fs entry translates to something like below

overlay        /usr/local/bin        overlay noauto,x-systemd.requires=/home,x-systemd.automount,lowerdir=/home/vasudev/Documents/utilities/bin,upperdir=/home/vasudev/Documents/utilities/jonas-bin,workdir=/home/vasudev/Documents/utilities/bin-overlay   0       0

There is another special option called x-systemd.automount this will make systemd-fstab-generator to create a .automount file for this mount point. What does systemd.automount do? It achieves on-demand file mounting and parallelized file system mounting. Something similar to systemd.socket the file system will be mounted when you access the mount point for first time. So now if you try to see dependency of usr-local-bin.mount you will see following.

systemctl show -p After usr-local-bin.mount
After=-.mount systemd-journald.socket local-fs-pre.target system.slice usr-local-bin.automount

This means now usr-local-bin.mount depends on usr-local-bin.automount. And let us see what usr-local-bin.automount needs.

systemctl show -p Requires usr-local-bin.automount
Requires=-.mount home.mount
systemctl show -p After usr-local-bin.automount
After=-.mount home.mount

So clearly usr-local-bin.automount is activated after -.mount and home.mount is activated. Similar can be done for any bind mounts or fuse mounts which require other mount points before it can be mounted. Also note that x-systemd.autmount is not mandatory option for declaring dependencies, I used it just to make sure /usr/local/bin is mounted only when its really needed.

Conclusion A lot of traditional way has been changed by systemd. I never understood why my system failed to boot in first place this happened because I was not really aware of how systemd works and was trying to debug the problem with traditional approach. So there is really a learning curve involved for every sysadmin out there who is going to use systemd. Most of them will read documentation before hand but others like me will learn after having a situation like above. :-). So systemd interfering into /etc/fstab is good?. I don't know but since systemd parallelizes the boot procedure something like this is really needed. Is there a way to make systemd not touch /etc/fstab?. Yes there is you need to pass fstab=0 option in kernel command line and systemd-fstab-generator doesn't create any .mount or .swap files from your /etc/fstab. !NB Also it looks like x-systemd.requires option was introduced recently and is not available in systemd <= 215 which is default in Jessie. So how do you declare dependencies in Jessie system?. I don't have any answer!. I did read that x-systemd.automount which is available in those versions of systemd can be used, but I'm yet to experiment this. If it succeeds I will write a post on it.

Robert Edmonds: Works with Debian: Intel SSD 750, AMD FirePro W4100, Dell P2715Q

I recently installed new hardware in my primary computer running Debian unstable. The disk used for the / and /home filesystem was replaced with an Intel SSD 750 series NVM Express card. The graphics card was replaced by an AMD FirePro W4100 card, and two Dell P2715Q monitors were installed. Intel SSD 750 series NVM Express card This is an 800 GB SSD on a PCI-Express x4 card (model number SSDPEDMW800G4X1) using the relatively new NVM Express interface, which appears as a /dev/nvme* device. The stretch alpha 4 Debian installer was able to detect and install onto this device, but grub-installer 1.127 on the installer media was unable to install the boot loader. This was due to a bug recently fixed in 1.128:

grub-installer (1.128) unstable; urgency=high
  * Fix buggy /dev/nvme matching in the case statement to determine
    disc_offered_devfs (Closes: #799119). Thanks, Mario Limonciello!
 -- Cyril Brulebois <kibi@debian.org>  Thu, 03 Dec 2015 00:26:42 +0100

I was able to download and install the updated .udeb by hand in the installer environment and complete the installation. This card was installed on a Supermicro X10SAE motherboard, and the UEFI BIOS was able to boot Debian directly from the NVMe card, although I updated to the latest available BIOS firmware prior to the installation. It appears in lspci like this:

02:00.0 Non-Volatile memory controller: Intel Corporation PCIe Data Center SSD (rev 01)
(prog-if 02 [NVM Express])
    Subsystem: Intel Corporation SSD 750 Series [Add-in Card]
    Flags: bus master, fast devsel, latency 0
    Memory at f7d10000 (64-bit, non-prefetchable) [size=16K]
    Expansion ROM at f7d00000 [disabled] [size=64K]
    Capabilities: [40] Power Management version 3
    Capabilities: [50] MSI-X: Enable+ Count=32 Masked-
    Capabilities: [60] Express Endpoint, MSI 00
    Capabilities: [100] Advanced Error Reporting
    Capabilities: [150] Virtual Channel
    Capabilities: [180] Power Budgeting <?>
    Capabilities: [190] Alternative Routing-ID Interpretation (ARI)
    Capabilities: [270] Device Serial Number 55-cd-2e-41-4c-90-a8-97
    Capabilities: [2a0] #19
    Kernel driver in use: nvme

The card itself appears very large in marketing photos, but this is a visual trick: the photographs are taken with the low-profile PCI bracket installed, rather than the standard height PCI bracket which it ships installed with. smartmontools fails to read SMART data from the drive, although it is still able to retrieve basic device information, including the temperature:

root@chase 0 :~# smartctl -d scsi -a /dev/nvme0n1
smartctl 6.4 2015-06-04 r4109 [x86_64-linux-4.3.0-trunk-amd64] (local build)
Copyright (C) 2002-15, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF INFORMATION SECTION ===
Vendor:               NVMe
Product:              INTEL SSDPEDMW80
Revision:             0135
Compliance:           SPC-4
User Capacity:        800,166,076,416 bytes [800 GB]
Logical block size:   512 bytes
Rotation Rate:        Solid State Device
Logical Unit id:      8086INTEL SSDPEDMW800G4                     1000CVCQ531500K2800EGN  
Serial number:        CVCQ531500K2800EGN
Device type:          disk
Local Time is:        Sun Dec 13 01:48:37 2015 EST
SMART support is:     Unavailable - device lacks SMART capability.
=== START OF READ SMART DATA SECTION ===
Current Drive Temperature:     31 C
Drive Trip Temperature:        85 C
Error Counter logging not supported
[GLTSD (Global Logging Target Save Disable) set. Enable Save with '-S on']
Device does not support Self Test logging
root@chase 4 :~#

Simple tests with cat /dev/nvme0n1 >/dev/null and iotop show that the card can read data at about 1 GB/sec, about twice as fast as the SATA-based SSD that it replaced. apt/dpkg now run about as fast on the NVMe SSD as they do on a tmpfs. Hopefully this device doesn't at some point require updated firmware, like some infamous SSDs have. AMD FirePro W4100 graphics card This is a graphics card capable of driving multiple DisplayPort displays at "4K" resolution and at a 60 Hz refresh rate. It has four Mini DisplayPort connectors, although I only use two of them. It was difficult to find a sensible graphics card. Most discrete graphics cards appear to be marketed towards video gamers who apparently must seek out bulky cards that occupy multiple PCI slots and have excessive cooling devices. (To take a random example, the ASUS STRIX R9 390X has three fans and brags about its "Mega Heatpipes".) AMD markets a separate line of "FirePro" graphics cards intended for professionals rather than gamers, although they appear to be based on the same GPUs as their "Radeon" video cards. The AMD FirePro W4100 is a normal half-height PCI-E card that fits into a single PCI slot and has a relatively small cooler with a single fan. It doesn't even require an auxilliary power connection and is about the same dimensions as older video cards that I've successfully used with Debian. It was difficult to determine whether the W4100 card was actually supported by an open source driver before buying it. The word "FirePro" appears nowhere on the webpage for the X.org Radeon driver, but I was able to find a "CAPE VERDE" listed as an engineering name which appears to match the "Cape Verde" code name for the FirePro W4100 given on Wikipedia's List of AMD graphics processing units. This explains the "verde" string that appears in the firmware filenames requested by the kernel (available only in the non-free/firmware-amd-graphics package):

[drm] initializing kernel modesetting (VERDE 0x1002:0x682C 0x1002:0x2B1E).
[drm] Loading verde Microcode
radeon 0000:01:00.0: firmware: direct-loading firmware radeon/verde_pfp.bin
radeon 0000:01:00.0: firmware: direct-loading firmware radeon/verde_me.bin
radeon 0000:01:00.0: firmware: direct-loading firmware radeon/verde_ce.bin
radeon 0000:01:00.0: firmware: direct-loading firmware radeon/verde_rlc.bin
radeon 0000:01:00.0: firmware: direct-loading firmware radeon/verde_mc.bin
radeon 0000:01:00.0: firmware: direct-loading firmware radeon/verde_smc.bin

The card appears in lspci like this:

01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Cape Verde GL [FirePro W4100]
(prog-if 00 [VGA controller])
    Subsystem: Advanced Micro Devices, Inc. [AMD/ATI] Device 2b1e
    Flags: bus master, fast devsel, latency 0, IRQ 55
    Memory at e0000000 (64-bit, prefetchable) [size=256M]
    Memory at f7e00000 (64-bit, non-prefetchable) [size=256K]
    I/O ports at e000 [size=256]
    Expansion ROM at f7e40000 [disabled] [size=128K]
    Capabilities: [48] Vendor Specific Information: Len=08 <?>
    Capabilities: [50] Power Management version 3
    Capabilities: [58] Express Legacy Endpoint, MSI 00
    Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+
    Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1 Len=010 <?>
    Capabilities: [150] Advanced Error Reporting
    Capabilities: [200] #15
    Capabilities: [270] #19
    Kernel driver in use: radeon

The W4100 appears to work just fine, except for a few bizarre error messages that are printed to the kernel log when the displays are woken from power saving mode:

[Sun Dec 13 00:24:41 2015] [drm:si_dpm_set_power_state [radeon]] *ERROR* si_enable_smc_cac failed
[Sun Dec 13 00:24:41 2015] [drm:si_dpm_set_power_state [radeon]] *ERROR* si_enable_smc_cac failed
[Sun Dec 13 00:24:41 2015] [drm:radeon_dp_link_train [radeon]] *ERROR* displayport link status failed
[Sun Dec 13 00:24:41 2015] [drm:radeon_dp_link_train [radeon]] *ERROR* clock recovery failed
[Sun Dec 13 00:24:41 2015] [drm:radeon_dp_link_train [radeon]] *ERROR* displayport link status failed
[Sun Dec 13 00:24:41 2015] [drm:radeon_dp_link_train [radeon]] *ERROR* clock recovery failed
[Sun Dec 13 00:24:41 2015] [drm:si_dpm_set_power_state [radeon]] *ERROR* si_enable_smc_cac failed
[Sun Dec 13 00:24:41 2015] [drm:radeon_dp_link_train [radeon]] *ERROR* displayport link status failed
[Sun Dec 13 00:24:41 2015] [drm:radeon_dp_link_train [radeon]] *ERROR* clock recovery failed
[Sun Dec 13 00:24:41 2015] [drm:radeon_dp_link_train [radeon]] *ERROR* displayport link status failed
[Sun Dec 13 00:24:41 2015] [drm:radeon_dp_link_train [radeon]] *ERROR* clock recovery failed

There don't appear to be any ill effects from these error messages, though. I have the following package versions installed:

 / Name                          Version             Description
+++-=============================-===================-================================================
ii  firmware-amd-graphics         20151207-1          Binary firmware for AMD/ATI graphics chips
ii  linux-image-4.3.0-trunk-amd64 4.3-1~exp2          Linux 4.3 for 64-bit PCs
ii  xserver-xorg-video-radeon     1:7.6.1-1           X.Org X server -- AMD/ATI Radeon display driver

The Supermicro X10SAE motherboard has two PCI-E 3.0 slots, but they're listed as functioning in either "16/NA" or "8/8" mode, which apparently means that putting anything in the second slot (like the Intel 750 SSD, which uses an x4 link) causes the video card to run at a smaller x8 link width. This can be verified by looking at the widths reported in the "LnkCap" and "LnkSta" lines in the lspci -vv output:

root@chase 0 :~# lspci -vv -s 01:00.0   egrep '(LnkCap LnkSta):'
        LnkCap: Port #0, Speed 8GT/s, Width x16, ASPM L0s L1, Exit Latency L0s <64ns, L1 <1us
        LnkSta: Speed 8GT/s, Width x8, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
root@chase 0 :~#

I did not notice any visible artifacts or performance degradation because of the smaller link width. The sensors utility from the lm-sensors package is capable of reporting the temperature of the GPU:

root@chase 0 :~# sensors radeon-pci-0100
radeon-pci-0100
Adapter: PCI adapter
temp1:        +55.0 C  (crit = +120.0 C, hyst = +90.0 C)
root@chase 0 :~#

Dell P2715Q monitors Two new 27" Dell monitors with a native resolution of 3840x2160 were attached to the new graphics card. They replaced two ten year old Dell 2001FP monitors with a native resolution of 1600x1200 that had experienced burn-in, providing 4.32 times as many pixels. (TV and monitor manufacturers now shamelessly refer to the 3840x2160 resolution as "4K" resolution even though neither dimension reaches 4000 pixels.) There was very little to setup beyond plugging the DisplayPort inputs on these monitors into the DisplayPort outputs on the graphics card. Most of the setup involved reconfiguring software to work with the very high resolution. X.org, for tl;dr CLOSED NOTABUG reasons doesn't set the DPI correctly. These monitors have ~163 DPI resolution, so I added -dpi 168 to /etc/X11/xdm/Xservers. (168 is an even 1.75x multiple of 96.) Software like Google Chrome and xfce4-terminal rendered fonts and graphical elements at the right size, but other software like notion, pidgin, and virt-manager did not fully understand the high DPI. E.g., pidgin renders fonts at the correct size, but icons are too small. The default X cursor was also too small. To fix this, I installed the dmz-cursor-theme package, ran update-alternatives --config x-cursor-theme and selected /usr/share/icons/DMZ-Black/cursor.theme as the cursor theme. Overall, these displays are much brighter and more readable than the ones they replaced.

11 December 2015

Matthias Klumpp: What s up in Tanglu?

It is time again for another Tanglu blogpost (to be honest, this article is pretty much overdue

). I want to shine a spotlight on the work that s done in Tanglu, be it ongoing or past work done for the new release. Why is the new release taking longer than usual? As you might have noticed, usually a new Tanglu release (Tanglu 4 Dasyatis ) should be released this month. We decided a while ago, however, to defer the release and are now aiming for an release in February / March 2016. Reason for this change in schedule is the GCC 5 transition (and more importantly the huge amount of follow-up transitions) as well as some other major infrastructure tasks, which we would like to complete and give them a good amount of testing before releasing. Also, some issues with our build system, and generally less build power than in previous releases is a problem (At least the Debile build-system issues could be worked around or solved). The hard disk crash in the forum and bugtracking server also delayed the start of the Tanglu 4 development process a lot. In all of these tasks, manpower is of course the main problem

Software Tasks General infrastructure tasks Improvements on Synchrotron Synchrotron, the software which is synchronizing the Tanglu archive with the Debian archive, received a few tweaks to make it more robust and detect installability of packages more reliably. We also run it more often now. Rapidumo improvements Rapidumo is a software written to complement dak (the Debian Archive Kit) in managing the Tanglu archive. It performs automatic QA tasks on the archive and provides a collection of tools to perform various tasks (like triggering package rebuilds). For Tanglu 4, we sometimes drop broken packages from the archive now, to speed up transitions and to remove packages which got uninstallable more quickly. Packages removed from the release suite still have a chance to enter it again, but they need to go through Tanglu s staging area again first. The removal process is currently semiautomatic, to avoid unneccessary removals and breakage. Rapidumo could benefit from some improvements and an interactive web interface (as opposed to static HTML pages) would be nice. Some early work on this is done, but not completed (and has a very low priority at the moment). DEP-11 integration There will be a bigger announcement on AppStream and DEP-11 in the next days, so I keep this terse: Tanglu will go for full AppStream integration with the next release, which means no more packaged metadata, but data placed directly in the archive. Work on this has started in Tanglu, but I needed to get back to the drawing board with it, to incorporate some new ideas for using synergies with Debian on generating the DEP-11 metadata. Phabricator Phabricator has been integrated well into our infrastructure, but there are still some pending tasks. E.g. we need subprojects in Phabricator, and a more powerful Conduit interface. Those are upstream bugs on Phabricator, and are actively being worked on. As soon as the missing features are available in Phabricator, we will also pursue the integration of Tanglu bug information with the Debian DistroTracker, which was discussed at DebConf this summer. UEFI support UEFI support is a tricky beast. Full UEFI support is a release-goal for Tanglu 4 (so we won t release without it). At time, our Live-CDs start on pure EFI systems, but there are several reported issues with the Calamares live-installer as well as Debian-Installer, which fails to install GRUB correctly. Work on resolving these problems is ongoing. Major LiveCD rework Tanglu 4 will ship with improved live-cds, which e.g. allow selecting the preferred locale early in the bootloader. We switched from live-boot to manage our live sessions to casper, the same tool which is also used in Ubuntu. Casper fixed a few issues we had, and brought some new, but overall using it was a good choice and work on making top-notch live-cds is progressing well. KDE Plasma Integration of the latest Plasma release is progressing, but its speed has slowed down since fewer people are working on it. If you want to help Tanglu s KDE Workspace integration, please help! For the upcoming release, the Plasma 5 packages which we created based on a collaboration with Kubuntu for the previous Tanglu 3 release have been merged with their Debian counterparts. This action fortunately was possible without major problems. Now Tanglu is (mostly) using the same Plasma 5 packages as Debian again (lots of Kudos go the the Kubuntu and Debian Qt/KDE packagers!). GNOME The same re-merge with Debian has been done on Tanglu s GNOME flavor (Tanglu also shipped with a more recent GNOME release than Debian in Tanglu 3). So Tanglu 4 GNOME and Debian Testing GNOME are at (almost) the same level. Unfortunately, the GNOME team is heavily understaffed a GNOME team member left at the beginning of the year for personal reasons, and the team now only has one semi-active member and me. Other An fvwm-nightshade spin is being worked on

. Apart from that, there are no teams maintaining other flavors in Tanglu. Security & Stable maintenance Thanks to several awesome people, the current Tanglu Stable release (Tanglu 3 Chromodoris ) receives regular updates, even for many packages which are not in the fully supported set. Tangluverse Tasks Tasks (not) done in the global Tanglu universe. HTTPS for community sites Thanks to our participation in the Let s Encrypt closed beta program, Tanglu websites like the user forums and bugtracker have been fully encrypted for a while, which should make submitting data to these sites much more secure. So far, we didn t encounter issues, which means that we will likely aim for getting HTTPS encryption enabled on every Tanglu website. Tanglu.org website The Tanglu main website didn t receive much love at all. It could use a facelift and more importantly updated content about Tanglu. So far, nobody volunteered to update the website, so this task is still open. It is, however, a high-priority task to increase our public visibility as a project, so updating the website is definitely something which will be done soon. Promotion It doesn t hurt to think about how to sell Tanglu as brand : What is Tanglu? Our motivation, our goals? What is our slogan? How can we communicate all of this to new users, without having them to read long explanations? (e.g. the Fedora Project has this nicely covered on their main website, and their slogan Freedom, Friends, Features, First immediately communicates the project s key values) Those are issues engineers don t think about often, still it is important to present Tanglu in a way that is easy to grasp for people hearing about it for the first time. So far, no people are working on this task specifically, although it regularly comes up on IRC. Sponsoring & Government Tanglu is by design not backed by any corporation. However, we still need to get our servers paid. Currently, Tanglu is supported by three sponsors, which basically provide the majority of our infrastructure. Also, developers provide additional machines to get Tanglu running and/or packages built. Still, this dependency on very few sponsors paying the majority of the costs is very bad, since it makes Tanglu vulnerable in case one sponsor decides to end sponsorship. We have no financial backing to be able to e.g. continue to pay an important server in case it s sponsor decides to drop sponsorship. Also, since Tanglu is no legal entity, accepting donations is hard for us at time, since a private person would need to accept the money on behalf of Tanglu. So we can t easily make donating to Tanglu possible (at least not in the way we want donations to be). These issues are currently being worked on, there are a couple of possible solutions on the table. I will write about details as soon as it makes sense to go public with them. In general, I am very happy with the Tanglu community: The developer community is a pleasure to work with, and interactions with our users on the forums or via the bugtracker are highly productive and friendly. Although the development speed has slowed down a bit, Tanglu is still an active and awesome project, and I am looking forward to the cool stuff we will do in future!

Lunar: Reproducible builds: week 32 in Stretch cycle

The first reproducible world summit was held in Athens, Greece, from December 1st-3rd with the support of the Linux Foundation, the Open Tech Fund, and Google. Faidon Liambotis has been an amazing help to sort out all local details. People at ImpactHub Athens have been perfect hosts. North of Athens from the Acropolis with ImpactHub in the center

North of Athens from the Acropolis with ImpactHub in the center

Nearly 40 participants from 14 different free software project had very busy days sharing knowledge, building understanding, and producing actual patches. Anyone interested in cross project discussions should join the rb-general mailing-list. What follows focuses mostly on what happened for Debian this previous week. A more detailed report about the summit will follow soon. You can also read the ones from Joachim Breitner from Debian, Clemens Lang from MacPorts, Georg Koppen from Tor, Dhiru Kholia from Fedora, and Ludovic Court s wrote one for Guix and for the GNU project. The Acropolis from

Infrastructure Several discussions at the meeting helped refine a shared understanding of what kind of information should be recorded on a build, and how they could be used. Daniel Kahn Gillmor sent a detailed update on how .buildinfo files should become part of the Debian archive. Some key changes compared to what we had in mind at DebConf15:

Two .buildinfo with different environment information can attest to the same exact binary artifact.
Multiple .buildinfo files can coexist for the same .deb as long as the listed checksums match the source and binary package in the archive.
.buildinfo can be signed in-line to certify where a build comes from.

Hopefully, ftpmasters will be able to comment on the updated proposal soon. Packages fixed The following packages have become reproducible due to changes in their build dependencies: fades, triplane, caml-crush, globus-authz. The following packages became reproducible after getting fixed:

binutils/2.25.90.20151125-2 uploaded by Matthias Klose, original patch by Reiner Herrmann.
chocolate-doom/2.2.1-2 by Fabian Greffrath.
csound/1:6.05~dfsg1-7 by Felipe Sateler.
dispcalgui/3.0.5.0-1 uploaded by Christian Marillat, original patch by Reiner Herrmann.
drmips/2.0.1-1 by Bruno Nova.
ghc/7.10.1-5 by Joachim Breitner.
gitolite3/3.6.3-3 by David Bremner.
libdigidoc/3.10.1.1208+ds1-1 uploaded by Andrew Shadura, original patch by Reiner Herrmann.
liberasurecode/1.1.0-3 uploaded by Thomas Goirand, original patch by Chris Lamb.
libjs-jcrop/0.9.13+dfsg-1 uploaded by David Pr vot, original patch by Chris Lamb.
libnet-interface-perl/1.012-3 uploaded by gregor herrmann, original patch by Reiner Herrmann.
libosmocore/0.9.0-1 uploaded by Ruben Undheim, original patch by Reiner Herrmann.
libperl-apireference-perl/0.21-2 fixed by Niko Tyni (#807111).
netrik/1.16.1-2 by Axel Beckert.
openssl/1.0.2e-1 by Kurt Roeckx.
snp-sites/2.0.2-2 uploaded by Sascha Steinbiss, original patch by Reiner Herrmann.
xfonts-shinonome/1:0.9.11-1 by Hideki Yamane, original patch by Chris Lamb.

Some uploads fixed some reproducibility issues, but not all of them:

raster3d/3.0-3-2 uploaded by Andreas Tille, original patch by Lunar.

Patches submitted which have not made their way to the archive yet:

#806580 on metview by Reiner Herrmann: remove timestamps from metview script.
#806974 on xpra by Reiner Herrmann: interpret the changelog date as UTC.
#807051 on why by Valentin Lorentz: removes extra timestamps from the build system.

akira sent proposals on how to make bash reproducible. Alexander Couzens submitted a patch upstream to add support for SOURCE_DATE_EPOCH in grub image generator (#787795). reproducible.debian.net An issue with some armhf build nodes was tracked down to a bad interaction between uname26 personality and new glibc (Vagrant Cascadian). A Debian package was created for koji, the RPM building and tracking system used by Fedora amongst others. It is currently waiting for review in the NEW queue. (Ximin Luo, Marek Marczykowski-G recki) diffoscope development diffoscope now has a dedicated mailing list to better accommodate its growing user and developer base. Going through diffoscope's guts together enabled several new contributors. Baptiste Daroussin, Ed Maste, Clemens Lang, Mike McQuaid, Joachim Breitner all contributed their first patches to improve portability or add new features. Regular contributors Chris Lamb, Reiner Herrmann, and Levente Polyak also submitted improvements.

The next release should support more operating systems, filesystem image comparison via libguestfs, HTML reports with on-demand loading, and parallel processing for the most noticeable improvements. Package reviews 27 reviews have been removed, 17 added and 14 updated in the previous week. Chris Lamb and Val Lorentz filed 4 new FTBFS reports. Misc. Baptiste Daroussin has started to implement support for SOURCE_DATE_EPOCH in FreeBSD in libpkg and the ports tree. Thanks Joachim Breitner and h01ger for the pictures.

8 December 2015

Daniel Pocock: Comparison of free, open source accounting software

There are a diverse range of free software solutions for accounting. Personally, I have been tracking my personal and business accounts using a double-entry accounting system since I started doing freelance work about the same time I started university. Once you become familiar with double-entry accounting (which doesn't require much more than basic arithmetic skills and remembering the distinction between a debit and a credit) it is unlikely you would ever want to go back to a spreadsheet. Accounting software promoted for personal/home users often provides a very basic ledger where you can distinguish how much cash goes to rent, how much to food and how much to the tax man. Software promoted for business goes beyond the core ledger functionality and provides helpful ways to keep track of which bills you already paid, which are due imminently and which customers haven't paid you. Even for a one-man-band, freelancer or contractor, using a solution like this is hugely more productive than trying to track bills in a spreadsheet. Factors to consider when choosing a solution Changing accounting software can be a time consuming process and require all the users to learn a lot of new things. Therefore, it is generally recommended to start with something a little more powerful than what you need in the hope that you will be able to stick with it for a long time. With proprietary software this can be difficult because the more advanced solutions cost more money than you might be willing to pay right now. With free software, there is no such limitation and you can start with an enterprise-grade solution from day one and just turn off or ignore the features you don't need yet. If you are working as an IT consultant or freelancer and advising other businesses then it is also worthwhile to choose a solution for yourself that you can potentially recommend to your clients and customize for them. The comparison Here is a quick comparison of some of the free software accounting solutions that are packaged on popular Linux distributions like Debian, Ubuntu and Fedora:

Product	Postbooks	Tryton	GnuCash	LedgerSMB	HomeBank	Skrooge	KMyMoney	BG Financas	Grisbi
GUI	Y	Y	Y	N	Y	Y	Y	Y	Y
Web UI	Y	Y	N	Y	N	N	N	N	N
Multi-user	Y	Y	N	Y	N	N	N	N	Y
File storage	N	Y	Y	N	Y	Y	Y	N	N
SQL storage	Y	Y	Y	Y	N	N	Y	Y	Y
Multi-currency	Y	Y	Y	Y	N	Y	Y		Y
A/R	Y	Y	Y	Y	N	Y	Y		Y
A/P	Y	Y	Y	Y	N	Y	Y		Y
VAT/GST	Y	Y	Y	Y	N	N	Y		Y
Inventory	Y	Y	N	Y	N		N		N
Linux	Y	Y	Y	Y	Y	Y	Y	Y	Y
Windows	Y	Y
Mac OS	Y	Y
Technology	C++, JavaScript, Node	Python	C	Perl	C			Java
License	CPAL	GPL3	GPL2	GPL2

The table doesn't consider Odoo (formerly OpenERP) because the packages were considered buggy and are not maintained any more, it is replaced by Tryton. Compiere and Adempiere are other well known solutions but they haven't been packaged at all. Features in detail While the above list gives a basic summary of features, it is necessary to look more closely at how they are implemented. For example, if you need to report on VAT or GST, there are two methods of reporting: cash or accrual. Some products only support accruals because that is easier to implement. Even in commercial products that support cash-based VAT reporting, the reports are not always accurate (I've seen that problem with the proprietary Quickbooks software) and a tax auditor will be quick to spot such errors. The only real way to get to know one of these products is to test it for a couple of hours. Postbooks, for example, provides the Demo database so you can test it with dummy data without making any real commitment. User interface choices If you need to support users on multiple platforms or remote users such as an accountant or book-keeper, it is tempting to choose a solution with a web interface. The solutions with desktop interfaces can be provisioned to remote users using a terminal-server setup. The full GUI solutions tend to offer a richer user interface and reporting experience. It can frequently be useful to have multiple windows or reports open at the same time, doing this with browser tabs can be painful. File or database storage There are many good reasons to use database storage and my personal preference is for PostgreSQL. Using a database allows you to run a variety of third-party reporting tools and write your own scripts for data import and migration. Community and commercial support When dealing with business software, it is important to look at both the community and the commercial support offerings that are available. Some communities have events, such as xTupleCon for Postbooks or a presence at other major events like FOSDEM. Summary My personal choice at the moment is Postbooks from xTuple. This is because of a range of factors, including the availability of both web and desktop clients, true multi-user support, the multi-currency support and the PostgreSQL back-end.

Vincent Sanders: I said it was wired like a Christmas tree

I have recently acquired a 27U high 19 inch rack in which I hope to consolidate all the computing systems in my home that do not interact well with humans.

My main issue is that modern systems are just plain noisy, often with multiple small fans whining away. I have worked to reduce this noise by using quieter components as replacements but in the end it is simply better to be able to put these systems in a box out of the way.

The rack was generously given to me by Andy Simpkins and aside from being a little dirty having been stored for some time was in excellent condition. While the proverbs "never look a gift horse in the mouth" and "beggars cannot be choosers" are very firmly at the front of my mind there were a few minor obstacles to overcome to make it fit in its new role with a very small budget.

The new home for the rack was to be a space under the stairs where, after careful measurement, I determined it would just fit. After an hour or two attempting to manoeuvre a very heavy chunk of steel into place I determined it was simply not possible while it was assembled. So I ended up disassembling and rebuilding the whole rack in a confined space.

The rack is 800mm wide IMRAK 1400 rather than the more common 600mm width which means it employs "cable reducing channels" to allow the mounting of standard width rack units. Most racks these days come with four posts in the corners to allow for longer kit to be supported front and back. This particular rack was not fitted with the rear posts and a brief call to the supplier indicated that any spares from them would be eyewateringly expensive (almost twice the cost of purchasing a new rack from a different supplier) so I had to get creative.

Shelves that did not require the rear rails were relatively straightforward and I bought two 500mm deep cantilever type from Orion (I have no affiliation with them beyond being a satisfied customer).

I took a trip to the local hardware store and purchased some angle brackets and 16mm steel square tube. From this I made support rails which means the racked kit has support to its rear rather than relying solely on being supported by its rack ears.

The next problem was the huge hole in the bottom of the rack where I was hoping to put the UPS and power switching. This hole is intended for use with raised flooring where cables enter from below, when not required it is filled in with a "bottom gland plate". Once again the correct spares for the unit were not within my budget.

Around a year ago I built several systems for open source projects from parts generously donated by Mythic Beasts (yes I did recycle servers used to build a fort). I still had some leftover casework from one of those servers so ten minutes with an angle grinder and a drill and I made myself a suitable plate.

The final problem I faced is that it is pretty dark under the stairs and while putting kit in the rack I could not see what I was doing. After some brief Googling I decided that all real rack lighting solutions were pretty expensive and not terribly effective.

At this point I was interrupted by my youngest son trying to assemble the Christmas tree and the traditional "none of the lights work" so we went off to the local supermarket to buy some bulbs. Instead we bought a 240 LED string for 10 (15usd) in the vague hope that next year they will not be broken.

I immediately had a light bulb moment and thought how a large number of efficient LED bulbs at a low price would be ideal for lighting a rack. So my rack is indeed both wired like and as a Christmas tree!

Now I just have to finish putting all the systems in there and I will be able to call the project a success.

7 December 2015

Francois Marier: Tweaking Cookies For Privacy in Firefox

Cookies are an important part of the Web since they are the primary mechanism that websites use to maintain user sessions. Unfortunately, they are also abused by surveillance marketing companies to follow you around the Web. Here are a few things you can do in Firefox to protect your privacy.

Cookie Expiry Cookies are sent from the website to your browser via a Set-Cookie HTTP header on the response. It looks like this:

HTTP/1.1 200 OK
Date: Mon, 07 Dec 2015 16:55:43 GMT
Server: Apache
Set-Cookie: SESSIONID=65576c6c64206e6f2c657920756f632061726b636465742065686320646f2165
Content-Length: 2036
Content-Type: text/html;charset=UTF-8

When your browser sees this, it saves that cookie for the given hostname and keeps it until you close the browser. Should a site want to persist their cookie for longer, they can add an Expires attribute:

Set-Cookie: SESSIONID=65576c...; expires=Tue, 06-Dec-2016 22:38:26 GMT

in which case the browser will retain the cookie until the server-provided expiry date (which could be in a few years). Of course, that's if you don't instruct your browser to do things differently.

Controlling Cookie Expiry In order to change your cookie settings, you must open the Firefox preferences, click on "Privacy" and then choose "Use custom settings for history" under the "History" heading. There, you will have the ability to turn off cookies entirely (`network.cookie.cookieBehavior = 2`), which I don't recommend you do in your browser since you won't be able to login anywhere. On the other hand, turning off cookies is what I do (and recommend) in Thunderbird since I can't think of a legitimate reason for an email to leave a cookie in my mail client. Another control you'll find there is "Keep until" which defaults to honoring the server-provided expiry ("they expire" aka `network.cookie.lifetimePolicy = 0`) or making them expire at the end of the browsing session ("I close Firefox" aka `network.cookie.lifetimePolicy = 2`). A third option is available if you type `about:config` into your URL bar and looking for the `network.cookie.lifetimePolicy` preference. Setting this to `3` will honor the server-provided expiry up to a maximum lifetime of 90 days. You can also make that 90 days be anything you want by changing the `network.cookie.lifetime.days` preference. Regardless of the settings you choose, you can always tell Firefox to clear cookies when you close it by selecting the "Clear history when Firefox closes" checkbox, clicking the "Settings" button and making sure that "Cookies" is selected (`privacy.clearOnShutdown.cookies = true`). This could be useful for example if you'd like to ensure that cookies never last longer than 5 days but are also cleared whenever you shut down Firefox.

Third-Party Cookies So far, we've only looked at first-party cookies: the ones set by the website you visit and which are typically used to synchronize your login state with the server. There is however another kind: third-party cookies. These ones are set by the third-party resources that a page loads. For example, if a page loads JavaScript from a third-party ad network, you can be pretty confident that they will set their own cookie in order to build a profile on you and serve you "better and more relevant ads".

Controlling Third-Party Cookies If you'd like to opt out of these, you have a couple of options. The first one is to turn off third-party cookies entirely by going back into the Privacy preferences and selecting "Never" next to the "Accept third-party cookies" setting (`network.cookie.cookieBehavior = 1`). Unfortunately, turning off third-party cookies entirely tends to break a number of sites which rely on this functionality (for example as part of their for login process). A more forgiving option is to accept third-party cookies only for sites which you have actually visited directly. For example, if you visit Facebook and login, you will get a cookie from them. Then when you visit other sites which include Facebook widgets they will not recognize you unless you allow cookies to be sent in a third-party context. To do that, choose the "From visited" option (`network.cookie.cookieBehavior = 3`). In addition to this setting, you can also choose to make all third-party cookies automatically expire when you close Firefox by setting the `network.cookie.thirdparty.sessionOnly` option to `true` in `about:config`.

Other Ways to Limit Third-Party Cookies Another way to limit undesirable third-party cookies is to tell the browser to avoid connecting to trackers in the first place. This functionality is now built into Private Browsing mode and enabled by default. To enable it outside of Private Browsing too, simply go into `about:config` and set `privacy.trackingprotection.enabled` to `true`. You could also install the EFF's Privacy Badger add-on which uses heuristics to detect and block trackers, unlike Firefox tracking protection which uses a blocklist of known trackers.

My Recommended Settings On my work computer I currently use the following:

network.cookie.cookieBehavior = 3
network.cookie.lifetimePolicy = 3
network.cookie.lifetime.days = 5
network.cookie.thirdparty.sessionOnly = true
privacy.trackingprotection.enabled = true

which allows me to stay logged into most sites for the whole week (no matter now often I restart Firefox Nightly) while limiting tracking and other undesirable cookies as much as possible.

6 December 2015

Elena 'valhalla' Grandi: Blocked by indiegogo because of blocked javascript?

Blocked by indiegogo because of blocked javascript?

I usually browse the web with javascript blocked, for obvious security reasons and slightly less obvious free software reasons https://www.gnu.org/philosophy/javascript-trap.html, adding sites to a temporary whitelist when absolutely needed.

I know that this hurts the revenue model of many websites, in some cases I'm sorry, in other cases I pay a subscription so that I don't have to be sorry, and in other cases I just don't care, depending on the service they provide.

One thing that I hate are websites that require javascript even to show their basic contents: I understand why some of them are doing it, but less so when they aren't getting money from ads, but from actually providing a paid service, such as indiegogo.

This morning I was browsing a campaign on that crowdfunding site, grudgingly allowed javascript from their domain to be able to see the campaign description and suddenly found this:

http://social.gl-como.it/photo/dde1ddaa79d831ffbc2bee30110a2497.png

So ok, they want me to confirm I'm a human, ok, I'm fine with that, but asking for personal identification? just to be able to browse your site securely? No thanks. The support page linked in that says that this company also support just asking to fill a captcha, which is probably not as effective, but also much less intrusive.

I was browsing a campaign for an (apparently) open hardware encryption device, which is probably enough these days to get you somewhat under the radar (luckily, I am already, and I have a t-shirt to prove it :) ), so being asked to identify myself before I could even start considering whether the device was interesting enough to support (in a public-ish way) was expecially bad.

So, if you are working on something like that, maybe you could consider using a different crowdfunding website, one that respects more their users?

5 December 2015

Lunar: Everyone can be a target

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

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

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

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

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

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

Gunnar Wolf: Scientific resarch and a moral stand should go hand in hand

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

4 December 2015

Joachim Breitner: Reproducible Builds World Summit

This week, I was attending the first Reproducible Builds World Summit in Athens. A while ago, I have fixed some reproducibility bugs in the Haskell compiler GHC (parts of #4012), and that got me a ticket to this fully sponsored and nicely organised event. This was the first event I attended that had a dedicated and professional moderator, Gunner from Aspiration, who came up with a suitable on-the-fly-schedule, ensured the time was structured by shorter plenary rounds with all ~40 attendees as well as longer working sessions in groups of usually at most 10 people, motivated people to run ( facilitate ) these working groups as well as ensured that any results were noted and collected. This definitely makes a difference to the otherwise unstructured let s all sit in a big circle and endlessly discuss things or let s all just hack on what we want to hack on right now structure of less professionally organised meetings. But after 1 days of talking, a certain desire to hack and get work done could be felt throughout the group, so most of us were happy to be allowed to make use of the laptop on Wednesday afternoon. At least as far as possible the wireless was not expecting this crowd, it seems. Besides the few patches above, my involvement in the project is rather rudimentary, so I tried to contribute as far as possible during the event itself. This was not always easy, as many of the working sessions were either self-reflecting or forward-facing: What problems do we see? What should we get done next? How do we talk to users/upstream/press/doners? Where possible, I tried to at least be helpful in the discussion. During the hacking sessions, I found it most useful to contribute to diffoscope, a program to recursively and deeply show the difference between files of any format, so there are now patches to implement a multi-file HTML output, to more efficiently include large diffs, and more importantly I assisted Lunar in making diffoscope multi-threaded. In Python this is not a very great experience; I guess I am spoiled by Haskell (as it is often the case). I enjoyed the group; a bit like DebConf but with many new faced from similarly-minded, but different projects. It was, however, again a Free Software event with an embarrassing low number of female participants. I liked discussing a proof of G del s first incompleteness theorem during a skill exchange session. Unfortunately, I had to leave very timely after the event on Thursday evening, in order to attend the Haskell in Leipzig workshop.

Ritesh Raj Sarraf: Freedom, Privacy and Our Choices

When I bought my Lenovo Yoga 2 13, I had great plans. I wanted a device, that I could use both, as a laptop, and also as a tablet. The path hasn't been easy. But then, no path in Free Software against Freedom and Privacy has been easy. The choice is left to us, the users. I had been a long time KDE User. With KDE's decision to have different UIs for different form factors (plasma active, plasma netbook, plasma desktop), it was now time to try something different. I had 2 choices to explore: Unity and GNOME. But given that Unity is not feasible in Debian, the obvious first option to explore was GNOME. And I guess my timing was perfect. I started with 3.14 which showed great promises about touch support, followed by 3.16 and now 3.18. There's still a long way to go, but GNOME definitely is in the right direction and improves impressively with each release. I would like to thank the Debian GNOME Team. You guys just are amazing. The pace at which the packages are prepared and pushed, it is a tough job. So, thank you. Now that I use GNOME, I also follow some GNOME development, file bugs and read User Feedback. While (many of) the design decisions that GNOME makes today is in line with what I desire, there are other users who aren't happy. Many don't like the new UI design GNOME is heading to, i.e. the fusion of the UI such that it is usable on both form factors: Desktop and Tablet. People find the Toolbars bloated. GNOME developer Allan Day has a good blog post showing the facts. But I think there's the other aspect which needs to be emphasized. By improving the same tools, the GNOME devs are making them capable to be used both, on Laptops and Tablets. This is important to me as a user. I still have the freedom of the tools I use.. And those tools don't sniff. By using the same tools in both modes, I also can reliably build a workflow. I remember when I was moving from IceDove to Evolution. It was painful, but once done, I now have an email client I can still use with basic touch workflow. If you take current GNOME out of the picture, what would a user do. Live with a Laptop and a Tablet, 2 separate device. The laptop running Debian and the Tablet ??? In the direction GNOME is in, it allows me to be liberated for both the use cases. My most valuable assets: data and time, both are efficient in use. And not to forget the reason for this blog entry: Freedom and Privacy. Sure you can choose not to buy/use a tablet at all, and live in a world 10yrs behind. By improving the same tools for both use cases, GNOME is also ensuring that they don't throw away learnings from the past. Today Gtk is touch ready and the same libs also are running when on Laptop. A feature addition/enhancement gets leveraged by both. The Search Bar addition into File Dialog is available both, in Laptop and Tablet mode. And the list could go on.... On the other hand, I'm not sure what the KDE User Experience is today. But if I have to log out of my plasma desktop session, to use in Tablet Mode (plasma active), that workflow is already a broken one. I do miss the flexibility KDE used to provide, where in a substantial part of the user flow could be heavily customized. This is one gripe I have with the GNOME Project in general. They just don't balance things at all. Elegance is not about cutting out features. There are simple things you'll miss in GNOME if you come from KDE. Like Ctrl+R in Kwrite. You can't do that in GEdit. Today, with companies like Google, who are developing tools that are cross-platform, stand as good examples as to what GNOME/KDE should do. Don't bloat the UI, but then again don't strip it off either. The Chromium Browser's UI is a great example. The Chromium UI Devs are pretty strict on what new visible field can be added. But under one Wrench button, they provide a world for everyone to be happy. Power Users can run through the option available, and Super Power Users can use things like chrome://settings and chrome://flags I the new world today, where without a proprietary stack running on your mobil device, it is literally useless; Efforts like that of from the GNOME Project, gives some hope.

Categories:
Debian-Blog
Technology

Keywords:
KDE
gnome
Yoga 2 13
Yoga
Lenovo
Touch
UI
Design
Freedom
Privacy

RHUT

3 December 2015

Arturo Borrero Gonz lez: current status of HA stack on Debian

Let's analyse the current status of the HA (high availability) stack on Debian.

For me, the two most important packages are corosync and pacemaker.
It is widely known that Debian jessie was released without these two packages in shape.

But, why?
Problem 1One of the main problems was with the relationship between pacemaker and libqb.
In short, a libqb issue prevented pacemaker to be built for Debian jessie. And that wasn't fixed in time for the Debian jessie stable release.
You can read the Debian bug #768618 [pacemaker: FTBFS in jessie: build-dependency not installable: libqb-dev (>= 0.16.0.real)] to know a bit more about the issue.
Problem 2

While at it, the corosync package was in very bad shape.

To get an idea of what I mean for bad shape, just look at the size of the changelog of the first try to fix the package, almost 90 lines long.

Problem 3

Perhaps the most important problem: the Debian team behind the HA stack seems inactive.

This was sent by one of the members, 19 Jan 2015:

[...]
I wonder if there are any active members of the Debian linux-ha team.
[...]

So, there is clearly lack of manpower, lack of interest in maintaining the stack.

I'm sure the first 2 problems could have been resolved in time if the Debian team were active.
It's Debian! How is this possible!?I have asked that myself several times. Debian is a community and collaborative project. This means that the quality of the product (the OS itself) is directly related to the amount of effort spent on it (by people that in most cases aren't being paid for the task).
I believe that in such specific pieces of software, we require a bit more push from companies which are using it for their own benefit as well.

Also, perhaps the Debian QA team may step in and do something about the situation, let's say simply distributing a big REQUEST FOR HELP alert in all official Debian channels.

So, what if I need to run now corosync+pacemaker in Debian?

I'm sorry, you should stick to Debian wheezy :-(

Fortunately, the versions shipped in Debian wheezy are fine. Unfortunately, Debian wheezy contains lots of old software (such as the kernel).

What should I expect for Debian stretch?

Well, some good news: corosync and libqb have been already fixed and they look good.

The pacemaker package is still lacking the needed updates, but there are some people [slowly] working on it.

I myself have contributed a bit: tested some related packages, opened some bugs, and so on. See #801853 and #801870 for instance.

Note that the development status is not easy to follow. Among other things, the 'official' git packaging repos aren't being used.

From the user/sysadmin point of view, any important news will be reflected in the Debian package trackers. Here are links to both:

pacemaker: https://tracker.debian.org/pkg/pacemaker
corosync: https://tracker.debian.org/pkg/corosync

(BTW the new Debian tracker: what a nice tool)
I want to contribute!By now, I recommend you to head to the Debian IRC channel #debian-ha

2 December 2015

Colin Watson: SSH SHA-2 support in Twisted

Launchpad operates a few SSH endpoints: bazaar.launchpad.net and git.launchpad.net for code hosting, and upload.ubuntu.com and ppa.launchpad.net for uploading packages. None of these are straightforward OpenSSH servers, because they don t give ordinary shell access and they authenticate against users SSH keys recorded in Launchpad; both of these are much easier to do with SSH server code that we can use in library form as part of another service. We use Twisted for several other tasks where we need event-based networking code, and its conch package is a good fit for this. Of course, this means that it s important that conch keeps up to date with the cryptographic state of the art in other SSH implementations, and this hasn t always been the case. OpenSSH 7.0 dropped support for some old algorithms, including disabling the 1024-bit diffie-hellman-group1-sha1 key exchange method at run-time. Unfortunately, this also happened to be the only key exchange method that Launchpad s SSH endpoints supported (conch supported the slightly better diffie-hellman-group-exchange-sha1 method as well, but that was disabled in Launchpad due to a missing piece of configuration). SHA-2 support was clearly called for, and the fact that we had to get this sorted out in conch first meant that everything took a bit longer than we d hoped. In Twisted 15.5, we contributed support for several conch improvements:

diffie-hellman-group14-sha1 key exchange (mostly by Ian Moore, finished off by me)
diffie-hellman-group-exchange-sha256 key exchange
hmac-sha2-256 and hmac-sha2-512 MACs

Between them and with some adjustments to the lazr.sshserver package we use to glue all this together to add support for DH group exchange, these are enough to allow us not to rely on SHA-1 at all, and these improvements have now been rolled out to all four endpoints listed above. I ve thus also uploaded OpenSSH 7.1 packages to Debian unstable. If you also run a Twisted-based SSH server, upgrade it now! Otherwise it will be harder for users of recent OpenSSH client versions to use your server, and for good reason.

Andrea Veri: Three years and counting

It s been a while since my last what s been happening behind the scenes e-mail so I m here to report on what has been happening within the GNOME Infrastructure, its future plans and my personal sensations about a challenge that started around three (3) years ago when Sriram Ramkrishna and Jeff Schroeder proposed my name as a possible candidate for coordinating the team that runs the systems behind the GNOME Project. All this followed by the official hiring achieved by Karen Sandler back in February 2013. The GNOME Infrastructure has finally reached stability both in terms of reliability and uptime, we didn t have any service disruption this and the past year and services have been running smoothly as they were expected to in a project like the one we are managing. As many of you know service disruptions and a total lack of maintenance were very common before I joined back in 2013, I m so glad the situation has dramatically changed and developers, users, passionates are now able to reach our websites, code repositories, build machines without experiencing slowness, downtimes or
unreachability. Additionally all these groups of people now have a reference point they can contact in case they need help when coping with the infrastructure they daily use. The ticketing system allows users to get in touch with the members of the Sysadmin Team and receive support right away within a very short period of time (Also thanks to Pagerduty, service the Foundation is kindly sponsoring) Before moving ahead to the future plans I d like to provide you a summary of what has been done during these roughly three years so you can get an idea of why I define the changes that happened to the infrastructure a complete revamp:

Recycled several ancient machines migrating services off of them while consolidating them by placing all their configuration on our central configuration management platform ran by Puppet. This includes a grand total of 7 machines that were replaced by new hardware and extended warranties the Foundation kindly sponsored.
We strenghten our websites security by introducing SSL certificates everywhere and recently replacing them with SHA2 certificates.
We introduced several services such as Owncloud, the Commits Bot, the Pastebin, the Etherpad, Jabber, the GNOME Github mirror.
We restructured the way we backup our machines also thanks to the Fedora Project sponsoring the disk space on their backup facility. The way we were used to handle backups drastically changed from early years where a magnetic tape facility was in charge of all the burden of archiving our data to today where a NetApp is used together with rdiff-backup.
We upgraded Bugzilla to the latest release, a huge thanks goes to Krzesimir Nowak who kindly helped us building the migration tools.
We introduced the GNOME Apprentice program open-sourcing our internal Puppet repository and cleansing it (shallow clones FTW!) from any sensitive information which now lives on a different repository with restricted access.
We retired Mango and our OpenLDAP instance in favor of FreeIPA which allows users to modify their account information on their own without waiting for the Accounts Team to process the change.
We documented how our internal tools are customized to play together making it easy for future Sysadmin Team members to learn how the infrastructure works and supersede existing members in case they aren t able to keep up their position anymore.
We started providing hosting to the GIMP and GTK projects which now completely rely on the GNOME Infrastructure. (DNS, email, websites and other services infrastructure hosting)
We started providing hosting not only to the GIMP and GTK projects but to localized communities as well such as GNOME Hispano and GNOME Greece
We configured proper monitoring for all the hosted services thanks to Nagios and Check-MK
We migrated the IRC network to a newer ircd with proper IRC services (Nickserv, Chanserv) in place.
We made sure each machine had a configured management (mgmt) and KVM interface for direct remote access to the bare metal machine itself, its hardware status and all the operations related to it. (hard reset, reboot, shutdown etc.)
We upgraded MoinMoin to the latest release and made a substantial cleanup of old accounts, pages marked as spam and trashed pages.
We deployed DNSSEC for several domains we manage including gnome.org, guadec.es, gnomehispano.es, guadec.org, gtk.org and gimp.org
We introduced an account de-activation policy which comes into play when a contributor not committing to any of the hosted repositories at git.gnome.org since two years is caught by the script. The account in question is marked as inactive and the gnomecvs (from the old cvs days) and ftpadmin groups are removed.
We planned mass reboots of all the machines roughly every month for properly applying security and kernel updates.
We introduced Mirrorbrain (MB), the mirroring service serving GNOME and related modules tarballs and software all over the world. Before introducing MB GNOME had several mirrors located in all the main continents and at the same time a very low amount of users making good use of them. Many organizations and companies behind these mirrors decided to not host GNOME sources anymore as the statistics of usage were very poor and preferred providing the same service to projects that really had a demand for these resources. MB solved all this allowing a proper redirect to the closest mirror (through mod_geoip) and making sure the sources checksum matched across all the mirrors and against the original tarball uploaded by a GNOME maintainer and hosted at master.gnome.org.

I can keep the list going for dozens of other accomplished tasks but I m sure many of you are now more interested in what the future plans actually are in terms of where the GNOME Infrastructure should be in the next couple of years. One of the main topics we ve been discussing will be migrating our Git infrastructure away from cgit (which is mainly serving as a code browsing tool) to a more complete platform that is surely going to include a code review tool of some sort. (Gerrit, Gitlab, Phabricator) Another topic would be migrating our mailing lists to Mailman 3 / Hyperkitty. This also means we definitely need a staging infrastructure in place for testing these kind of transitions ideally bound to a separate Puppet / Ansible repository or branch. Having a different repository for testing purposes will also mean helping apprentices to test their changes directly on a live system and not on their personal computer which might be running a different OS / set of tools than the ones we run on the GNOME Infrastructure. What I also aim would be seeing GNOME Accounts being the only authentication resource in use within the whole GNOME Infrastructure. That means one should be able to login to a specific service with the same username / password in use on the other hosted services. That s been on my todo list for a while already and it s probably time to push it forward together with Patrick Uiterwijk, responsible of Ipsilon s development at Red Hat and GNOME Sysadmin. While these are the top priority items we are soon receiving new hardware (plus extended warranty renewals for two out of the three machines that had their warranty renewed a while back) and migrating some of the VMs off from the current set of machines to the new boxes is definitely another task I d be willing to look at in the next couple of months (one machine (ns-master.gnome.org) is being decommissioned giving me a chance to migrate away from BIND into NSD). The GNOME Infrastructure is evolving and it s crucial to have someone maintaining it. On this side I m bringing to your attention the fact the assigned Sysadmin funds are running out as reported on the Board minutes from the 27th of October. On this side Jeff Fortin started looking for possible sponsors and came up with the idea of making a brochure with a set of accomplished tasks that couldn t have been possible without the Sysadmin fundraising campaign launched by Stormy Peters back in June 2010 being a success. The Board is well aware of the importance of having someone looking at the infrastructure that runs the GNOME Project and is making sure the brochure will be properly reviewed and published. And now some stats taken from the Puppet Git Repository:

$ cd /git/GNOME/puppet && git shortlog -ns
3520 Andrea Veri
506 Olav Vitters
338 Owen W. Taylor
239 Patrick Uiterwijk
112 Jeff Schroeder
71 Christer Edwards
4 Daniel Mustieles
4 Matanya Moses
3 Tobias Mueller
2 John Carr
2 Ray Wang
1 Daniel Mustieles Garc a
1 Peter Baumgarten

and from the Request Tracker database (52388 being my assigned ID):

mysql> select count(*) from Tickets where LastUpdatedBy = '52388';
+----------+
  count(*)  
+----------+
  3613  
+----------+
1 row in set (0.01 sec)
mysql> select count(*) from Tickets where LastUpdatedBy = '52388' and Status = 'Resolved';
+----------+
  count(*)  
+----------+
  1596  
+----------+
1 row in set (0.03 sec)

It s been a long run which made me proud, for the things I learnt, for the tasks I ve been able to accomplish, for the great support the GNOME community gave me all the time and most of all for the same fact of being part of the team responsible of the systems hosting the GNOME Project. Thank you GNOME community for your continued and never ending backing, we daily work to improve how the services we host are delivered to you and the support we receive back is fundamental for our passion and enthusiasm to remain high!

Next.

Previous.