Planet ALUG

Syndicate content
Planet ALUG - http://planet.alug.org.uk/
Updated: 26 min 47 sec ago

Jonathan McDowell: Home Automation: Graphing MQTT sensor data

Tue, 22/05/2018 - 22:28

So I’ve setup a MQTT broker and I’m feeding it temperature data. How do I actually make use of this data? Turns out collectd has an MQTT plugin, so I went about setting it up to record temperature over time.

First problem was that although the plugin supports MQTT/TLS it doesn’t support it for subscriptions until 5.8, so I had to backport the fix to the 5.7.1 packages my main collectd host is running.

The other problem is that collectd is picky about the format it accepts for incoming data. The topic name should be of the format <host>/<plugin>-<plugin_instance>/<type>-<type_instance> and the data is <unixtime>:<value>. I modified my MQTT temperature reporter to publish to collectd/mqtt-host/mqtt/temperature-study, changed the publish line to include the timestamp:

publish.single(pub_topic, str(time.time()) + ':' + str(temp), hostname=Broker, port=8883, auth=auth, tls={})

and added a new collectd user to the Mosquitto configuration:

mosquitto_passwd -b /etc/mosquitto/mosquitto.users collectd collectdpass

And granted it read-only access to the collectd/ prefix via /etc/mosquitto/mosquitto.acl:

user collectd topic read collectd/#

(I also created an mqtt-temp user with write access to that prefix for the Python script to connect to.)

Then, on the collectd host, I created /etc/collectd/collectd.conf.d/mqtt.conf containing:

LoadPlugin mqtt <Plugin "mqtt"> <Subscribe "ha"> Host "mqtt-host" Port "8883" User "collectd" Password "collectdpass" CACert "/etc/ssl/certs/ca-certificates.crt" Topic "collectd/#" </Subscribe> </Plugin>

I had some initial problems when I tried setting CACert to the Let’s Encrypt certificate; it actually wants to point to the “DST Root CA X3” certificate that signs that. Or using the full set of installed root certificates as I’ve done works too. Of course the errors you get back are just of the form:

collectd[8853]: mqtt plugin: mosquitto_loop failed: A TLS error occurred.

which is far from helpful. Once that was sorted collectd started happily receiving data via MQTT and producing graphs for me:

This is a pretty long winded way of ending up with some temperature graphs - I could have just graphed the temperature sensor using collectd on the Pi to send it to the monitoring host, but it has allowed a simple MQTT broker, publisher + subscriber setup with TLS and authentication to be constructed and confirmed as working.

Categories: LUG Community Blogs

Daniel Silverstone (Kinnison): Runtime typing

Mon, 21/05/2018 - 15:53

I have been wrestling with a problem for a little while now and thought I might send this out into the ether for others to comment upon. (Or, in other words, Dear Lazyweb…)

I am writing system which collects data from embedded computers in my car (ECUs) over the CAN bus, using the on-board diagnostics port in the vehicle. This requires me to generate packets on the CAN bus, listen to responses, including managing flow control, and then interpret the resulting byte arrays.

I have sorted everything but the last little bit of that particular data pipeline. I have a prototype which can convert the byte arrays into "raw" values by interpreting them either as bitfields and producing booleans, or as anything from an unsigned 8 bit integer to a signed 32 bit integer in either endianness. Fortunately none of the fields I'd need to interpret are floats.

This is, however, pretty clunky and nasty. Since I asked around and a majority of people would prefer that I keep the software configurable at runtime rather than doing meta-programming to describe these fields, I need to develop a way to have the data produced by reading these byte arrays (or by processing results already interpreted out of the arrays) type-checked.

As an example, one field might be the voltage of the main breaker in the car. It's represented as a 16 bit big-endian unsigned field, in tenths of a volt. So the field must be divided by ten and then given the type "volts". Another field is the current passing through that main breaker. This is a 16 bit big-endian signed value measured in tenths of an amp, so must be interpreted as as such, divided by ten, and then given the type "amps". I intend for all values handled beyond the raw byte arrays themselves to simply be floats, so there'll be signedness available regardless.

What I'd like, is to later have a "computed" value, let's call it "power flow", which is the voltage multiplied by the current. Naturally this would need to be given the type 'watts'. What I'd dearly love is to build into my program the understanding that volts times amps equals watts, and then have the reader of the runtime configuration type-check the function for "power flow".

I'm working on this in Rust, though for now the language is less important than the algorithms involved in doing this (unless you know of a Rust library which will help me along). I'd dearly love it if someone out there could help me to understand the right way to handle such expression type checking without having to build up a massively complex type system.

Currently I am considering things (expressed for now in yaml) along the lines of:

- name: main_voltage type: volts expr: u16_be(raw_bmc, 14) / 10 - name: main_current type: amps expr: i16_be(raw_bmc, 12) / 10 - name: power_flow type: watts expr: main_voltage * main_current

What I'd like is for each expression to be type-checked. I'm happy for untyped scalars to end up auto-labelled (so the u16_be() function would return an untyped number which then ends up marked as volts since 10 is also untyped). However when power_flow is typechecked, it should be able to work out that the type of the expression is volts * amps which should then typecheck against watts and be accepted. Since there's also consideration needed for times, distances, booleans, etc. this is not a completely trivial thing to manage. I will know the set of valid types up-front though, so there's that at least.

If you have any ideas, ping me on IRC or perhaps blog a response and then drop me an email to let me know about it.

Thanks in advance.

Categories: LUG Community Blogs

Jonathan McDowell: Home Automation: Raspberry Pi as MQTT temperature sensor

Wed, 16/05/2018 - 21:16

After setting up an MQTT broker I needed some data to feed it. It made sense to start basic and gradually build up bits and pieces that would form a bigger home automation setup. As it happened I have an old Raspberry Pi B (original rev 1 [2 if you look at /proc/cpuinfo] with 256MB RAM) and some DS18B20 1-Wire temperature sensors lying around, so I decided to make a heavyweight temperature sensor (long term I’m hoping to do something with some ESP8266s).

There are plenty of guides out there about hooking up the DS18B20 to the Pi; Adafruit has a reasonable one. The short version is that GPIO4 can be easily configured to be a 1-Wire bus and you hook the DS18B20 up with a 4k7Ω resistor across the data + 3v3 power pins. An initial check can be performed by enabling the DT overlay on the fly:

sudo dtoverlay w1-gpio

Detection of 1-Wire devices is automatic so you should see an entry in dmesg looking like:

w1_master_driver w1_bus_master1: Attaching one wire slave 28.012345678abcd crc ef

You can then do

$ cat /sys/bus/w1/devices/28-*/w1_slave 1e 01 4b 46 7f ff 0c 10 18 : crc=18 YES 1e 01 4b 46 7f ff 0c 10 18 t=17875

Which shows a current temperature of 17.875°C in my sudy. Once that’s working (and you haven’t swapped GND and DATA like I did on the first go) you can make the Pi bootup with 1-Wire enabled by adding a dtoverlay=w1-gpio line to /boot/config.txt. The next step is to get that fed into the MQTT broker. A simple Python client seemed like the right approach. Debian has paho-mqtt but sadly not in a stable release. Thankfully the python3-paho-mqtt 1.3.1-1 package in testing installed just fine on the Raspbian stretch image my Pi is running. I dropped the following in /usr/locals/bin/mqtt-temp:

#!/usr/bin/python3 import glob import time import paho.mqtt.publish as publish Broker = 'mqtt-host' auth = { 'username': 'user2', 'password': 'bar', } pub_topic = 'test/temperature' base_dir = '/sys/bus/w1/devices/' device_folder = glob.glob(base_dir + '28-*')[0] device_file = device_folder + '/w1_slave' def read_temp(): valid = False temp = 0 with open(device_file, 'r') as f: for line in f: if line.strip()[-3:] == 'YES': valid = True temp_pos = line.find(' t=') if temp_pos != -1: temp = float(line[temp_pos + 3:]) / 1000.0 if valid: return temp else: return None while True: temp = read_temp() if temp is not None: publish.single(pub_topic, str(temp), hostname=Broker, port=8883, auth=auth, tls={}) time.sleep(60)

And finished it off with a systemd unit file - I know a lot of people complain about systemd, but it really does make it easy to just spin up a minimal service as a unique non-privileged user. The following went in /etc/systemd/system/mqtt-temp.service:

[Unit] Description=MQTT Temperature sensor After=network.target [Service] # Hack because Python can't cope with a DynamicUser with no HOME Environment="HOME=/" ExecStart=/usr/local/sbin/mqtt-temp DynamicUser=yes MemoryDenyWriteExecute=true PrivateDevices=true ProtectKernelTunables=true ProtectControlGroups=true RestrictRealtime=true RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX RestrictNamespaces=true [Install] WantedBy=multi-user.target

Start it up and enable for subsequent reboots:

systemctl start mqtt-temp systemctl enable mqtt-temp

And then watch on my Debian test box as before:

$ mosquitto_sub -h mqtt-host -p 8883 --capath /etc/ssl/certs/ -v -t '#' -u user1 -P foo test/temperature 17.875 test/temperature 17.937
Categories: LUG Community Blogs

Jonathan McDowell: Home Automation: Getting started with MQTT

Thu, 10/05/2018 - 20:53

I’ve been thinking about trying to sort out some home automation bits. I’ve moved from having a 7 day heating timer to a 24 hour timer and I’d forgotten how annoying that is at weekends. I’d like to monitor temperatures in various rooms and use that, along with presence detection, to be a bit more intelligent about turning the heat on. Equally I wouldn’t mind tying my Alexa in to do some voice control of lighting (eventually maybe even using DeepSpeech to keep everything local).

Before all of that I need to get the basics in place. This is the first in a series of posts about putting together the right building blocks to allow some useful level of home automation / central control. The first step is working out how to glue everything together. A few years back someone told me MQTT was the way forward for IoT applications, being more lightweight than a RESTful interface and thus better suited to small devices. At the time I wasn’t convinced, but it seems they were right and MQTT is one of the more popular ways of gluing things together.

I found the HiveMQ series on MQTT Essentials to be a pretty good intro; my main takeaway was that MQTT allows for a single message broker to enable clients to publish data and multiple subscribers to consume that data. TLS is supported for secure data transfer and there’s a whole bunch of different brokers and client libraries available. The use of a broker is potentially helpful in dealing with firewalling; clients and subscribers only need to talk to the broker, rather than requiring any direct connection.

With all that in mind I decided to set up a broker to play with the basics. I made the decision that it should run on my OpenWRT router - all the devices I want to hook up can easily see that device, and if it’s down then none of them are going to be able to get to a broker hosted anywhere else anyway. I’d seen plenty of info about Mosquitto and it’s already in the OpenWRT package repository. So I sorted out a Let’s Encrypt cert, installed Moquitto and created a couple of test users:

opkg install mosquitto-ssl mosquitto_passwd -b /etc/mosquitto/mosquitto.users user1 foo mosquitto_passwd -b /etc/mosquitto/mosquitto.users user2 bar chown mosquitto /etc/mosquitto/mosquitto.users chmod 600 /etc/mosquitto/mosquitto.users

I then edited /etc/mosquitto/mosquitto.conf and made sure the following are set. In particular you need cafile set in order to enable TLS:

port 8883 cafile /etc/ssl/lets-encrypt-x3-cross-signed.pem certfile /etc/ssl/mqtt.crt keyfile /etc/ssl/mqtt.key log_dest syslog allow_anonymous false password_file /etc/mosquitto/mosquitto.users acl_file /etc/mosquitto/mosquitto.acl

Finally I created /etc/mosquitto/mosquitto.acl with the following:

user user1 topic readwrite # user user2 topic read ro/# topic readwrite test/#

That gives me user1 who has full access to everything, and user2 with readonly access to the ro/ tree and read/write access to the test/ tree.

To test everything was working I installed mosquitto-clients on a Debian test box and in one window ran:

mosquitto_sub -h mqtt-host -p 8883 --capath /etc/ssl/certs/ -v -t '#' -u user1 -P foo

and in another:

mosquitto_pub -h mqtt-host -p 8883 --capath /etc/ssl/certs/ -t 'test/message' -m 'Hello World!' -u user2 -P bar

(without the --capath it’ll try a plain TCP connection rather than TLS, and not produce a useful error message) which resulted in the mosquitto_sub instance outputting:

test/message Hello World!

Trying:

mosquitto_pub -h mqtt-host -p 8883 --capath /etc/ssl/certs/ -t 'test2/message' -m 'Hello World!' -u user2 -P bar

resulted in no output due to the ACL preventing it. All good and ready to actually make use of - of which more later.

Categories: LUG Community Blogs

Jonathan McDowell: The excellent selection of Belfast Tech conferences

Fri, 04/05/2018 - 18:30

Yesterday I was lucky enough to get to speak at BelTech, giving what I like to think of as a light-hearted rant entitled “10 Stupid Reasons You’re Not Using Free Software”. It’s based on various arguments I’ve heard throughout my career about why companies shouldn’t use or contribute to Free Software, and, as I’m sure you can guess, I think they’re mostly bad arguments. I only had a 20 minute slot for it, which was probably about right, and it seemed to go down fairly well. Normally the conferences I would pitch talks to would end up with me preaching to the converted, but I felt this one provided an audience who were probably already using Free software but hadn’t thought about it that much.

And that got me to thinking “Isn’t it fantastic that we have this range of events and tech groups in Belfast?”. I remember the days when the only game in town was the Belfast LUG (now on something like its 5th revival and still going strong), but these days you could spend every night of the month at a different tech event covering anything from IoT to Women Who Code to DevOps to FinTech. There’s a good tech community that’s built up, with plenty of cross over between the different groups.

An indicator of that is the number of conferences happening in the city, with many of them now regular fixtures in the annual calendar. In addition to BelTech I’ve already attended BelFOSS and Women Techmakers this year. Product Camp Belfast is happening today. NIDevConf is just over a month away (I’ll miss this year due to another commitment, but thoroughly enjoyed last year). WordCamp Belfast isn’t the sort of thing I’d normally notice, but the opportunity to see Heather Burns speak on the GDPR is really tempting. Asking around about what else is happening turned up B-Sides, Big Data Belfast and DigitalDNA.

How did we end up with such a vibrant mix of events (and no doubt many more I haven’t noticed)? They might not be major conferences that pull in an international audience, but in some ways I find that more heartening - there’s enough activity in the local tech scene to make this number of events make sense. And I think that’s pretty cool.

Categories: LUG Community Blogs

Chris Lamb: Free software activities in April 2018

Mon, 30/04/2018 - 14:54

Here is my monthly update covering what I have been doing in the free software world during April 2018 (previous month).

Reproducible builds

Whilst anyone can inspect the source code of free software for malicious flaws, most software is distributed pre-compiled to end users.

The motivation behind the Reproducible Builds effort is to allow verification that no flaws have been introduced — either maliciously or accidentally — during this compilation process by promising identical results are always generated from a given source, thus allowing multiple third-parties to come to a consensus on whether a build was compromised.

This month I:

  • Gave the keynote presentation at FLOSSUK's Spring Conference in Edinburgh, Scotland on reproducible builds and how it can prevent individual developers & centralised infrastructure from becoming targets from malicious actors.
  • Presented at foss-north 2018 in Gothenburg, Sweden to speak about diffoscope, our in-depth tool to analyse reproducibility issues in packages and how it can be used in quality-assurance efforts more generally.
  • Filed 10 upstream patches to make their build or output reproducible for the Sphinx documentation generator [...], the Lexicon DNS manager [...], the Dashell C++ stream library [...], Pylint static analysis tool [...], the vcr.py HTTP-interaction testing tool [...], the Click Python command-line parser [...], the ASDF interchange format [...], the strace system call tracer [...], the libdazzle Glib component library [...] and the Corosync Cluster Engine [...].
  • Updated the diffoscope tests to prevent a build failure under file 5.33. (#897099)
  • Dropped support for stripping text from PHP Pear registry file in our strip-nondeterminism tool to remove specific non-deterministic results from a completed build as we can fix this in the toolchain instead. [...]
  • Added an example on how to unmount the manpage in disorderfs, our FUSE-based filesystem that deliberately introduces non-determinism into directory system calls in order to flush out reproducibility issues. [...]
  • Migrated our weekly blog reports and related machinery from the deprecated Alioth and Debian-branded service to the more-generic reproducible-builds.org domain as well as made some cosmetic changes to the site itself. [...]
  • In Debian, I:
  • Categorised a large number of packages and issues in the Reproducible Builds "notes" repository.
  • Worked on publishing our weekly reports. (#154, #155 & #156).
Debian

My activities as the Debian Project Leader are covered in my monthly "Bits from the DPL" email to the debian-devel-announce mailing list.

I contributed the following patches for Debian:

  • debhelper: Does not accept zero as a valid version number in debian/changelog. (#894895)
  • python-colormap: Please drop override of new-package-should-not-package-python2-module. (#896662)
  • whatthepatch: Please drop override of new-package-should-not-package-python2-module. (#896664)
  • libdazzle: Incorrect Homepage: field. (#896065)
  • python-click: Please correct Homepage: field. (#895277)
  • libmypaint: Incorrect Homepage: field. (#895402)
  • figlet: Add missing space in figlet(6) manpage. (#894541)
Debian LTS

This month I have been paid to work 16¼ hours on the Debian Long Term Support (LTS) project. In that time I did the following:

Uploads
  • sphinx (1.7.2-1) — New upstream release, apply my upstream patch to make the set output reproducible (#895553), don't use Google Fonts to avoid local privacy breaches, fix testsuite to not rely on specific return types, etc.
  • python-django (1:1.11.12-1 & 2.0.4-1) — New upstream bugfix releases.
  • installation-birthday (9) — Also use /var/lib/vim to determine installation date. (#895686)
  • ruby-rjb (1.5.5-2) — Fix FBTFS under Java 9. (#874146)
  • redisearch:
    • 1.0.10-1 — New upstream release.
    • 1.0.10-2 — Drop -mpopcnt from CFLAGS. (#896593)
    • 1.0.10-3 — Use upstream's patch for removing -mpopcnt.
    • 1.1.0-1 — New upstream release.
  • libfiu (0.96-2) — Apply patch from upstream to make the build reproducible. (#894776)
  • redis (5:4.0.9-1) — New upstream release.
  • python-redis (2.10.6-3) — Fix tests when performed against an i386 Redis server. (#896864)

I also performed six sponsored uploads: connman-ui (0~20150623-0.1), playerctl (0.5.0-1), yasnippet-snippets (0.2-1), nose2 (0.7.4-2), pytest-tornado (0.5.0-1) & django-ipware (2.0.2-1).

FTP Team

As a Debian FTP assistant I ACCEPTed 108 packages: appstream, ayatana-indicator-messages, ayatana-indicator-notifications, buildbot, ccextractor, ccnet, cfitsio, cloudcompare, cpprest, cross-toolchain-base, cross-toolchain-base-ports, dde-qt5integration, deepin-deb-installer, deepin-voice-recorder, desktop-autoloader, dh-r, dlib, falkon, flask-babelex, flif, fscrypt, gcc-7-cross, gcc-7-cross-ports, gcc-8-cross, gcc-8-cross-ports, gegl, gimp, golang-github-dropbox-dropbox-sdk-go-unofficial, golang-github-jedisct1-dlog, golang-github-jedisct1-xsecretbox, golang-github-sanity-io-litter, googleplay-api, haskell-bsb-http-chunked, haskell-cmark-gfm, haskell-config-ini, haskell-genvalidity, haskell-genvalidity-property, haskell-hedgehog, haskell-hslua-module-text, haskell-ini, haskell-microstache, haskell-multimap, haskell-onetuple, haskell-only, haskell-parser-combinators, haskell-product-isomorphic, haskell-rate-limit, haskell-singleton-bool, haskell-tasty-expected-failure, haskell-validity, haskell-vector-builder, haskell-wl-pprint-annotated, haskell-word-wrap, haskell-yi-keymap-emacs, haskell-yi-keymap-vim, horizon-eda, iwd, jquery-i18n.js, kitty, kiwisolver, knot-resolver, libbpp-phyl, libdeclare-constraints-simple-perl, libgpg-error, libkf5incidenceeditor, libmypaint, linux, linux-latest, maildir-utils, moment-timezone.js, musescore-general-soundfont, mypaint-brushes, nmap, node-tar, openstack-meta-packages, orcania, osmo-fl2k, osmo-iuh, peek, peruse, protobuf, python-async-generator, python-cerberus, python-datrie, python-h11, python-libevdev, python-panwid, python-plaster, python-plaster-pastedeploy, python-readme-renderer, qpid-proton, razercfg, rebound, ruby-iso8601, ruby-tomlrb, ruby-xmlrpc, rustc, sent, shoogle, snapcast, texext, texlive-bin, u-boot, virtualbox-guest-additions-iso, vnlog, vtk7, xorgxrdp & zodbpickle.

I additionally filed 10 RC bugs against packages that had incomplete debian/copyright files against: appstream, cfitsio, dlib, falkon, horizon-eda, maildir-utils, osmo-fl2k, peruse, python-h11 & qpid-proton.

Categories: LUG Community Blogs

Jonathan McDowell: Using collectd for Exim stats

Wed, 25/04/2018 - 19:16

I like graphing things; I find it’s a good way to look for abnormal patterns or try to track down the source of problems. For monitoring systems I started out with MRTG. It’s great for monitoring things via SNMP, but everything else needs some custom scripts. So at one point I moved my home network over to Munin, which is much better at graphing random bits and pieces, and coping with collecting data from remote hosts. Unfortunately it was quite heavyweight on the Thecus N2100 I was running as the central collection point at the time; data collection resulted in a lot of forking and general sluggishness. So I moved to collectd, which is written in C, relies much more on compiled plugins and doesn’t do a load of forks. It also supports a UDP based network protocol with authentication + encryption, which makes it great for running on hosts that aren’t always up - the collection point doesn’t hang around waiting for them when they’re not around.

The problem is that when it comes to things collectd doesn’t support out of the box it’s not quite so easy to get the stats - things a simple script would sort in MRTG need a bit more thought. You can go the full blown Python module route as I did for my Virgin Super Hub scripts, but that requires a bit of work. One of the things in particular I wanted to graph were stats for my mail servers and having to write a chunk of Python to do that seemed like overkill. Searching around found the Tail plugin, which follows a log file and applies regexes to look for stats. There are some examples for Exim on that page, but none were quite what I wanted. In case it’s of interest/use to anyone else, here’s what I ended up with (on Debian, of course, but I can’t see why it wouldn’t work elsewhere with minimal changes).

First I needed a new data set specification for email counts. I added this to /usr/share/collectd/types.db:

mail_count value:COUNTER:0:65535

Note if you’re logging to a remote collectd host this needs to be on both the host where the stats are collected and the one receiving the stats.

I then dropped a file in /etc/collectd/collectd.conf.d/ called exim.conf containing the following. It’ll need tweaked depending on exactly what you log, but the first 4 <Match> stanzas should be generally useful. I have some additional logging (via log_message entries in the exim.conf deny statements) that helps me track mails that get greylisted, rejected due to ClamAV or rejected due to being listed in a DNSRBL. Tailor as appropriate for your setup:

LoadPlugin tail <Plugin tail> <File "/var/log/exim4/mainlog"> Instance "exim" Interval 60 <Match> Regex "S=([1-9][0-9]*)" DSType "CounterAdd" Type "ipt_bytes" Instance "total" </Match> <Match> Regex "<=" DSType "CounterInc" Type "mail_count" Instance "incoming" </Match> <Match> Regex "=>" DSType "CounterInc" Type "mail_count" Instance "outgoing" </Match> <Match> Regex "==" DSType "CounterInc" Type "mail_count" Instance "defer" </Match> <Match> Regex ": greylisted.$" DSType "CounterInc" Type "mail_count" Instance "greylisted" </Match> <Match> Regex "rejected after DATA: Malware:" DSType "CounterInc" Type "mail_count" Instance "malware" </Match> <Match> Regex "> rejected RCPT <.* is listed at" DSType "CounterInc" Type "mail_count" Instance "dnsrbl" </Match> </File> </Plugin>

Finally, because my mail servers are low volume these days, I added a scaling filter to give me emails/minute rather than emails/second. This went in /etc/collectd/collectd.conf.d/filters.conf:

PreCacheChain "PreCache" LoadPlugin match_regex LoadPlugin target_scale <Chain "PreCache"> <Rule> <Match "regex"> Plugin "^tail$" PluginInstance "^exim$" Type "^mail_count$" Invert false </Match> <Target "scale"> Factor 60 </Target> </Rule> </Chain>

Update: Some examples…

Categories: LUG Community Blogs

Chris Lamb: Re-elected as Debian Project Leader

Wed, 18/04/2018 - 19:24

I have been extremely proud to have served as the Debian Project Leader since my election in early 2017. During this time I've learned a great deal about the inner workings of the Project as well as about myself. I have grown as a person thanks to all manner of new interactions and fresh experiences.

I believe is a privilege simply to be a Debian Developer, let alone to be selected as their representative. It was therefore an even greater honour to learn that I have been re-elected by the community for another year. I profoundly and wholeheartedly thank everyone for placing their trust in me for another term.



Being the "DPL" is a hard job. It is even difficult to even communicate exactly how and any statistics somehow fail to capture it. However, I now understand the look in previous Leaders' eyes when they congratulated me on my appointment and future candidates should not nominate themselves lightly.

Indeed, I was unsure whether I would stand for re-appointment and I might not have done had it not been for some touching and encouraging words from some close confidants. They underlined to me that a year is not a long time, further counselling that I should consider myself just getting started and only now prepared to start to take on the bigger picture.



Debian itself will always face challenges but I sincerely believe that the Project remains as healthy as ever. We are uniquely cherished and remain remarkably poised to improve the free software ecosystem as a whole. Moreover, our stellar reputation for technical excellence, stability and software freedom remains highly respected and without peer. It is truly an achievement to be proud of.



I thank everyone who had the original confidence, belief and faith in me, but I offer my further sincere and humble thanks to all those who have felt they could extend this to a second term, especially with such a high turnout. I am truly excited and looking forward to the year ahead.


Categories: LUG Community Blogs

Chris Lamb: Free software activities in March 2018

Sat, 31/03/2018 - 20:10

Here is my monthly update covering what I have been doing in the free software world during March 2018 (previous month):


Reproducible builds

Whilst anyone can inspect the source code of free software for malicious flaws, most software is distributed pre-compiled to end users.

The motivation behind the Reproducible Builds effort is to allow verification that no flaws have been introduced — either maliciously or accidentally — during this compilation process by promising identical results are always generated from a given source, thus allowing multiple third-parties to come to a consensus on whether a build was compromised.

This month I:



Debian Debian LTS

This month I have been paid to work 18 hours on Debian Long Term Support (LTS). In that time I did the following:

  • "Frontdesk" duties, triaging CVEs, reviewing other maintainers' packages, etc.
  • Issued DLA 1299-1 fixing an XML External Entity (XXE) attack in the JGraphX diagramming library.
  • Issued DLA 1304-1 for zsh to fix four vulnerabilities, including a privilege-elevation issue.
  • Issued DLA 1306-1 for the libvips image processing library where attackers could cause a remote denial of service.
  • Issued DLA 1311-1 for the adminer web-based database administration tool. I also updated jessie-backports and proposed updates for stretch (#893803) and jessie (#893804).
  • Issued DLA 1317-1 for the net-snmp server management framework to correct a heap corruption vulnerability.
  • Issued DLA 1318-1 for irssi closing an issue where nicknames could result in out-of-bounds access.
Uploads
  • python-django (2.0.3-1 & 1.11.11-1) — New upstream security releases.
  • libfiu:
    • 0.95-5 — Add support for cross-compilation. (#892946)
    • 0.95-6 & 0.95-7 — Incorrect attempts to fix a build failure. (#893049)
    • 0.96-1 — New upstream release, fixing the aforementioned build failure caused by Make parellelism.
  • redisearch (1.0.9-1) — New upstream release.
Debian bugs filed
  • postgresql-10: Please update NEWS entry for 10.3-1. (#891898)
  • python-meshio: Installs test files to /usr/lib/python3/dist-packages. (#892019)
  • clang-tidy-7: Missing depends on libclang-common-7-dev. (#891999)
  • lintian: Warn about "old" X-Python3-Version fields? (#892304)
  • todoman: Bogus description in manpage. (#892381)
FTP Team

As a Debian FTP assistant I ACCEPTed 53 packages: akonadi, akonadi-calendar, arch-install-scripts, beets, calligraplan, cenon.app, cross-toolchain-base-ports, dcontainers, debiman, deepin-movie-reborn, deepin-screenshot, deepin-terminal, dput-ng, dump1090-mutability, fonts-ubuntu, gcc-7-cross, gcc-8-cross, gnome-themes-extra, iotjs, isl, isl-0.18, ksmtp, ldc, ledger-wallets-udev, lexicon, libmath-random-secure-perl, libtgvoip, linux, magic-wormhole-transit-relay, mailman-suite, mailman3, mustache-d, node-split-string, nvidia-cuda-toolkit, nvidia-graphics-drivers, python-memoize, python-orderedattrdict, python-requests-ntlm, python-test-server, python-wsproto, pyzabbix, r-cran-pbmcapply, r-cran-spdata, r-cran-squarem, r-cran-zeligchoice, ruby-batch-loader, ruby-commonmarker, ruby-enum, ruby-fast-blank, social-auth-core, stdx-allocator, tldextract & xorgproto.

I additionally filed 6 RC bugs against packages that had incomplete debian/copyright files against: cenon.app, gnome-themes-extra, isl, isl-0.18, libtgvoip & python-wsproto.

Categories: LUG Community Blogs

Jonathan McDowell: First impressions of the Gemini PDA

Mon, 19/03/2018 - 21:41

Last March I discovered the IndieGoGo campaign for the Gemini PDA, a plan to produce a modern PDA with a decent keyboard inspired by the Psion 5. At that point in time the estimated delivery date was November 2017, and it wasn’t clear they were going to meet their goals. As someone has owned a variety of phones with keyboards, from a Nokia 9000i to a T-Mobile G1 I’ve been disappointed about the lack of mobile devices with keyboards. The Gemini seemed like a potential option, so I backed it, paying a total of $369 including delivery. And then I waited. And waited. And waited.

Finally, one year and a day after I backed the project, I received my Gemini PDA. Now, I don’t get as much use out of such a device as I would have in the past. The Gemini is definitely not a primary phone replacement. It’s not much bigger than my aging Honor 7 but there’s no external display to indicate who’s calling and it’s a bit clunky to have to open it to dial (I don’t trust Google Assistant to cope with my accent enough to have it ring random people). The 9000i did this well with an external keypad and LCD screen, but then it was a brick so it had the real estate to do such things. Anyway. I have a laptop at home, a laptop at work and I cycle between the 2. So I’m mostly either in close proximity to something portable enough to move around the building, or travelling in a way that doesn’t mean I could use one.

My first opportunity to actually use the Gemini in anger therefore came last Friday, when I attended BelFOSS. I’d normally bring a laptop to a conference, but instead I decided to just bring the Gemini (in addition to my normal phone). I have the LTE version, so I put my FreedomPop SIM into it - this did limit the amount I could do with it due to the low data cap, but for a single day was plenty for SSH, email + web use. I already have the Pro version of the excellent JuiceSSH, am a happy user of K-9 Mail and tend to use Chrome these days as well. All 3 were obviously perfectly happy on the Android 7.1.1 install.

Aside: Why am I not running Debian on the device? Planet do have an image available form their Linux Support page, but it’s running on top of the crufty 3.18 Android kernel and isn’t yet a first class citizen - it’s not clear the LTE will work outside Android easily and I’ve no hope of ARM opening up the Mali-T880 drivers. I’ve got plans to play around with improving the support, but for the moment I want to actually use the device a bit until I find sufficient time to be able to make progress.

So how did the day go? On the whole, a success. Battery life was great - I’d brought a USB battery pack expecting to need to boost the charge at some point, but I last charged it on Thursday night and at the time of writing it’s still claiming 25% battery left. LTE worked just fine; I had a 4G signal for most of the day with occasional drops down to 3G but no noticeable issues. The keyboard worked just fine; much better than my usual combo of a Nexus 7 + foldable Bluetooth keyboard. Some of the symbols aren’t where you’d expect, but that’s understandable on a scaled down keyboard. Screen resolution is great. I haven’t used the USB-C ports other than to charge and backup so far, but I like the fact there are 2 provided (even if you need a custom cable to get HDMI rather than it following the proper standard). The device feels nice and solid in your hand - the case is mostly metal plates that remove to give access to the SIM slot and (non-removable but user replaceable) battery. The hinge mechanism seems robust; I haven’t been worried about breaking it at any point since I got the device.

What about problems? I can’t deny there are a few. I ended up with a Mediatek X25 instead of an X27 - that matches what was initial promised, but there had been claims of an upgrade. Unfortunately issues at the factory meant that the initial production run got the older CPU. Later backers are support to get the upgrade. As someone who took the early risk this does leave a slightly bitter taste but I doubt I’ll actually notice any significant performance difference. The keys on the keyboard are a little lop sided in places. This seems to be just a cosmetic thing and I haven’t noticed any issues in typing. The lack of first class Debian support is disappointing, but I believe will be resolved in time (by the community if not Planet). The camera isn’t as good as my phone, but then it’s a front facing webcam style thing and it’s at least as good as my laptop at that.

Bottom line: Would I buy it again? At $369, absolutely. At the current $599? Probably not - I’m simply not on the move enough to need this on a regular basis, so I’d find it hard to justify. Maybe the 2nd gen, assuming it gets a bit more polish on the execution and proper mainline Linux support. Don’t get me wrong, I think the 1st gen is lovely and I’ve had lots of envious people admiring it, I just think it’s ended up priced a bit high for what it is. For the same money I’d be tempted by the GPD Pocket instead.

Categories: LUG Community Blogs

Chris Lamb: Free software activities in February 2018

Wed, 28/02/2018 - 19:36

Here is my monthly update covering what I have been doing in the free software world in February 2018 (previous month):

Reproducible builds

Whilst anyone can inspect the source code of free software for malicious flaws, most software is distributed pre-compiled to end users.

The motivation behind the Reproducible Builds effort is to allow verification that no flaws have been introduced — either maliciously or accidentally — during this compilation process by promising identical results are always generated from a given source, thus allowing multiple third-parties to come to a consensus on whether a build was compromised.

This month I:



I also made the following changes to diffoscope, our in-depth and content-aware diff utility that can locate and diagnose reproducibility issues:

  • Add support for comparing Berkeley DB files. (Unfortunately this is currently incomplete because the libraries do not report metadata reliably!) (#890528)
  • Add support for comparing "XMLBeans" binary schemas. [...]
  • Drop spurious debugging code in Android tests. [...]


Debian

My activities as the current Debian Project Leader are covered in my "Bits from the DPL" email to the debian-devel-announce mailing list.

Patches contributed
  • debian-policy: Replace dh_systemd_install with dh_installsystemd. (#889167)
  • juce: Missing build-depends on graphviz. (#890035)
  • roffit: debian/rules does not override targets as intended. (#889975)
  • bugs.debian.org: Please add rel="canonical" to bug pages. (#890338)
Debian LTS

This month I have been paid to work 18 hours on Debian Long Term Support (LTS). In that time I did the following:

Uploads
  • redis:
    • 4.0.8-1 — New upstream release and fix a potential hardlink vulnerability.
    • 4.0.8-2 — Also listen on ::1 (IPv6) by default. (#891432)
  • python-django:
    • 1.11.10-1 — New upstream security release.
    • 2.0.2-1 — New upstream security release.
  • redisearch:
    • 1.0.6-1 — New upstream release.
    • 1.0.7-1 — New upstream release & add Lintian overrides for package-does-not-install-examples.
    • 1.0.8-1 — New upstream release, which includes my reproducibility-related change improvement.
  • adminer:
    • 4.6.1-1 — New upstream release and override debian-watch-does-not-check-gpg-signature as upstream do not release signatures.
    • 4.6.2-1 — New upstream release.
  • process-cpp:
    • 3.0.1-3 — Make the documentation reproducible.
    • 3.0.1-4 — Correct Vcs-Bzr to Vcs-Git.
  • sleekxmpp (1.3.3-3) — Make the build reproducible. (#890193)
  • python-redis (2.10.6-2) — Correct autopkgtest dependencies and misc packaging updates.
  • bfs (1.2.1-1) — New upstream release.

I also made misc packaging updates for docbook-to-man (1:2.0.0-41), gunicorn (19.7.1-4), installation-birthday (8) & python-daiquiri (1.3.0-3).

Finally, I performed the following sponsored uploads: check-manifest (0.36-2), django-ipware (2.0.1-1), nose2 (0.7.3-3) & python-keyczar (0.716+ds-2).

Debian bugs filed
  • zsh: Please make apt install completion work on "local" files. (#891140)
  • git-gui: Ignores git hooks. (#891552)
  • python-coverage:
    • Installs pyfile.html into wrong directory breaking HTML report generation. (#890560)
    • Document copyright information for bundled JavaScript source. (#890578)
FTP Team

As a Debian FTP assistant I ACCEPTed 123 packages: apticron, aseba, atf-allwinner, bart-view, binutils, browserpass, bulk-media-downloader, ceph-deploy, colmap, core-specs-alpha-clojure, ctdconverter, debos, designate, editorconfig-core-py, essays1743, fis-gtm, flameshot, flex, fontmake, fonts-league-spartan, fonts-ubuntu, gcc-8, getdns, glyphslib, gnome-keyring, gnome-themes-extra, gnome-usage, golang-github-containerd-cgroups, golang-github-go-debos-fakemachine, golang-github-mattn-go-zglob, haskell-regex-tdfa-text, https-everywhere, ibm-3270, ignition-fuel-tools, impass, inetsim, jboss-bridger, jboss-threads, jsonrpc-glib, knot-resolver, libctl, liblouisutdml, libopenraw, libosmo-sccp, libtest-postgresql-perl, libtickit, linux, live-tasks, minidb, mithril, mutter, neuron, node-acorn-object-spread, node-babel, node-call-limit, node-color, node-colormin, node-console-group, node-consolidate, node-cosmiconfig, node-css-color-names, node-date-time, node-err-code, node-gulp-load-plugins, node-html-comment-regex, node-icss-utils, node-is-directory, node-mdn-data, node-mississippi, node-mutate-fs, node-node-localstorage, node-normalize-range, node-postcss-filter-plugins, node-postcss-load-options, node-postcss-load-plugins, node-postcss-minify-font-values, node-promise-retry, node-promzard, node-require-from-string, node-rollup, node-rollup-plugin-buble, node-ssri, node-validate-npm-package-name, node-vue-resource, ntpsec, nvidia-cuda-toolkit, nyx, pipsi, plasma-discover, pokemmo, pokemmo-installer, polymake, privacybadger, proxy-switcher, psautohint, purple-discord, pytest-astropy, pytest-doctestplus, pytest-openfiles, python-aiomeasures, python-coverage, python-fitbit, python-molotov, python-networkmanager, python-os-service-types, python-pluggy, python-stringtemplate3, python3-antlr3, qpack, quintuple, r-cran-animation, r-cran-clustergeneration, r-cran-phytools, re2, sat-templates, sfnt2woff-zopfli, sndio, thunar, uhd, undertime, usbauth-notifier, vmdb2 & xymonq.

I additionally filed 15 RC bugs against packages that had incomplete debian/copyright files against: browserpass, designate, fis-gtm, flex, gnome-keyring, ibm-3270, knot-resolver, libopenraw, libtest-postgresql-perl, mithril, mutter, ntpsec, plasma-discover, pytest-arraydiff & r-cran-animation.

Categories: LUG Community Blogs

Jonathan McDowell: Getting Debian booting on a Lenovo Yoga 720

Wed, 21/02/2018 - 22:46

I recently got a new work laptop, a 13” Yoga 720. It proved difficult to install Debian on; pressing F12 would get a boot menu allowing me to select a USB stick I have EFI GRUB on, but after GRUB loaded the kernel and the initrd it would just sit there never outputting anything else that indicated the kernel was even starting. I found instructions about Ubuntu 17.10 which helped but weren’t the complete picture. What seems to be the situation is that the kernel won’t happily boot if “Legacy Support” is not enabled - enabling this (and still booting as EFI) results in a happier experience. However in order to be able to enable legacy boot you have to switch the SATA controller from RAID to AHCI, which can cause Windows to get unhappy about its boot device going away unless you warn it first.

  • Fire up an admin shell in Windows (right click on the start menu)
  • bcdedit /set safeboot minimal
  • Reboot into the BIOS
  • Change the SATA Controller mode from RAID to AHCI (dire warnings about “All data will be erased”. It’s not true, but you’ve back up first, right?) Set “Boot Mode” to “Legacy Support”.
  • Save changes and let Windows boot to Safe Mode
  • Fire up an admin shell in Windows (right click on the start menu again)
  • bcdedit /deletevalue safeboot
  • Reboot again and Windows will load in normal mode with the AHCI drivers

Additionally I had problems getting the GRUB entry added to the BIOS; efibootmgr shows it fine but it never appears in the BIOS boot list. I ended up using Windows to add it as the primary boot option using the following (<guid> gets replaced with whatever the new “Debian” section guid is):

bcdedit /enum firmware bcdedit /copy "{bootmgr}" /d "Debian" bcdedit /set "{<guid>}" path \EFI\Debian\grubx64.efi bcdedit /set "{fwbootmgr}" displayorder "{<guid>}" /addfirst

Even with that at one point the BIOS managed to “forget” about the GRUB entry and require me to re-do the final “displayorder” command.

Once you actually have the thing installed and booting it seems fine - I’m running Buster due to the fact it’s a Skylake machine with lots of bits that seem to want a newer kernel, but claimed battery life is impressive, the screen is very shiny (though sometimes a little too shiny and reflective) and the NVMe SSD seems pretty nippy as you’d expect.

Categories: LUG Community Blogs

MJ Ray: How hard can typing æ, ø and å be?

Wed, 21/02/2018 - 17:14

Petter Reinholdtsen: How hard can æ, ø and å be? comments on the rubbish state of till printers and their mishandling of foreign characters.

Last week, I was trying to type an email, on a tablet, in Dutch. The tablet was running something close to Android and I was using a Bluetooth keyboard, which seemed to be configured correctly for my location in England.

Dutch doesn’t even have many accents. I wanted an e acute (é). If you use the on screen keyboard, this is actually pretty easy, just press and hold e and slide to choose the accented one… but holding e on a Bluetooth keyboard? eeeeeeeeeee!

Some guides suggest Alt and e, then e. Apparently that works, but not on keyboards set to Great British… because, I guess, we don’t want any of that foreign muck since the Brexit vote, or something(!)

Even once you figure out that madness and switch the keyboard back to international, which also enables alt i, u, n and so on to do other accents, I can’t find grave, check, breve or several other accents. I managed to send the emails in Dutch but I’d struggle with various other languages.

Have I missed a trick or what are the Android developers thinking? Why isn’t there a Compose key by default? Is there any way to get one?

Categories: LUG Community Blogs

Mick Morgan: database failure

Sun, 18/02/2018 - 16:31

In 1909, Franz Kafka wrote the “Inclusion of Private Automobile Firms in the Compulsory Insurance Program” as part of “The Office Writings”. His experience of tortuous bureaucracy in Insurance and elsewhere was later reflected in one of his most famous novels “Der Process” (known in English translation as “The Trial”).

Back in October last year I bought another motorcycle to go with my GSX 1250. I’d just sold three other older bikes and felt the need to fill up the resultant hole in my garage. Besides, a man can never have too many motorcycles. At the time I bought the new Yamaha I spoke to my insurers about getting it added to my existing policy. Unfortunately they had recently changed their systems and I could no longer have one policy covering both bikes. So I took out a new separate policy. Oddly enough, that policy cost me twice as much as I paid for cover on the GSX, a bike with over twice the power and a lot more grunt than my new Yamaha. I was told that whilst /I/ was still the same risk, the underwriters assumed that my Yamaha was a riskier vehicle to insure. The ways of insurers are odd indeed and beyond the ken of mortal man.

For the past few months, both my bikes have been wrapped up warm and dry in my garage awaiting a change in the weather so that I no longer have to use the car for everything. This turns out to be a very good thing indeed.

A couple of days ago I received a letter from the Motor Insurer’s Bureau and DVLA. That letter, headed “Stay Insured, Stay Legal” gave the registration number of my Yamaha and stated, in red, “Do not ignore this letter” and went on to say “To avoid a penalty, you will need to take action immediately”. “The record of insurance for your vehicle [REG NO] does not appear on the Motor Insurance Database (MID) and this means if you take no action, you will get a fine.”

The letter also explained that it was my responsibility, as registered keeper, to ensure that my bike was insured. If I was certain that my bike was insured, I was instructed to “contact [my] Insurance provider” since “MIB and DVLA cannot update your records on the MID”.

Pretty worrying and very specific about what I needed to do. So, firstly I checked the MID at “askmid.com” and sure enough, my bike did not appear.

I then ‘phoned my Insurers who confirmed that I was insured and had been since October of last year when I took out the policy. I explained that I knew that was the case because I had the policy in front of me. But that didn’t help me because both DVLA and the MIB believed otherwise. Worse, the MID is used by the Police who will therefore similarly believe otherwise. Worse even than that, is the fact that an extract of the MIB database is supplied for use by ANPR cameras across the UK (See www.mib.org.uk). This means that I only have to pass an ANPR (which I do – a lot) whilst riding that particular bike to almost guarantee a police stop. I therefore asked my insurers to do what the MIB suggested and update my records. No can do, say my insurers. According to their systems I /am/ already on the MIB. After several, rather fruitless conversations (they called me back, I called them again) they suggested that I call the MIB. I explained again that the MIB had clearly stated that /they/ could do nothing, it was down to my insurer and them alone to ensure that my records were correct. Furthermore, the askmid website reinforces the message that “askMID and MIB do not sell insurance nor can we update the Motor Insurance Database (MID). These services are provided by your chosen insurer or broker”.

Nevertheless, since I was getting nowhere with my insurer, I agreed to try to speak to the MIB and, if necesssary, get them to talk to my insurer. Here, dear reader, is where the situation spirals further into the absurd. The letter from the MIB gives a contact telephone number which is completely automated. That advice line (you know the type, “press 1 for this option, 2 for that” etc.) eventually gave me the advice I had already received from the MIB letter and the askmid website – viz: “We cannot do anything, you must talk to your insurer”. So I went back to my insurer. You will not be surprised to read that my insurer, whilst sympathetic and understanding felt that they had done their bit and the fault lay elsewhere.

Now, as a paying customer of a (compulsory) service I don’t care where the fault lies. My only point of leverage is with my insurer. I pay them for a service which does not simply stop with them issuing cover. They must also ensure that the relevant databases are kept up to date. This requirement is laid upon them by Statutory Instrument no 37 of 2003 – “The Motor Vehicles (Compulsory Insurance) (Information Centre and Compensation Body) Regulations 2003”.

The person I spoke to on my third, or possibly fourth, conversation with my Insurer suggested that in order to show that I /was/ fully insured I should carry a copy of my policy with me at all times when riding my bike.

This completely misses the point. It is a legal requirement for my bike’s records on the MIB database to be correct. Only my Insurer can do that. If those records are not correct, I face the almost certain chance of being stopped by the police. Now whilst I can (if I remember to “carry my papers” in the correct Orwellian manner) show the Officers stopping me that I /am/ insured, that will have wasted my time and the Police Officers’ time.

Not good. Not good at all. I’m sure Kafka would have understood my frustration.

And guess what may happen when the time comes for me to renew my insurance – on all my vehicles.

Categories: LUG Community Blogs

Daniel Silverstone (Kinnison): Epic Journey in my Ioniq

Wed, 14/02/2018 - 22:18

This weekend just-gone was my father's 90th birthday, so since we don't go to Wales very often, we figured we should head down to visit. As this would be our first major journey in the Ioniq (I've done Manchester to Cambridge a few times now, but this is almost 3 times further) we took an additional day off (Friday) so that we could easily get from our home in southern Manchester to my parent's house in St Davids, Pembrokeshire.

I am not someone to enter into these experiences lightly. I spent several hours consulting with zap-map and also Google maps, looking at chargers en-route. In the UK there's a significant number of chargers on the motorway system provided by Ecotricity but this infrastructure is not pervasive and doesn't really extend beyond the motorway service stations (and some IKEAs). I made my plan for the journey to Wales, ensuring that each planned stop was simply the first in a line of possible stops in order that if something went wrong, I'd have enough charge to move forwards from there.

First leg took us from our home to the Ecotricity charger at Hilton Park Southbound services. My good and dear friend Tim very kindly offered to charge us for free and he used one of his fifty-two free charges to top us up. This went flawlessly and set us in a very good mood for the journey to come. Since we would then have a very long jump from the M5 to the M4, we decided that our second charge would be to top-up at Chateau Impney which has a Polar charger. Unfortunately by this point the wind and rain were up and the charger failed to work properly, eventually telling us that its input voltages were unbalanced and then powering itself off entirely. We decided to head to the other Polar charger at Webbs of Wychbold. That charger started up fine so we headed in, had a loo visit, grabbed some lunch, watched the terrapins swimming around, and when a sufficient time had passed for the car to charge, headed back only to discover that it had emergency-stopped mere moments after we'd left the car, so we had no charge for the entire time we were there. No matter we thought - we'd sit in the car while it charged, and eat our lunch. Sadly we were defeated, the charger repeatedly e-stopped, so we gave up.

Our fallback position was to charge at the Strensham services at the M5/M50 junction. Sadly the southbound services have no chargers at all (they're under a lot of building work right now, so perhaps that's part of it) so we had to get to the northbound services and charge there. That charge went fine, and with a £2.85 bill from Ecotricity automatically paid, we snuck our way along back-roads and secret junctions to the southbound services, and headed off down the M50. Sadly we're now a lot later than we should have been, having lost about ninety minutes in total to the wasted time at the two Polar chargers, which meant that we hit a lot of congestion at Monmouth and around Newport on the M4.

We made it to Cardiff Gate where we plugged in, set it charging, and then headed into the service area where we happened to meet my younger brother who was heading home too. He went off, and I looked at the Ecotricity app on my phone which had decided at that point that I wasn't charging at all. I went out to check, the charger was still delivering current, so, chalking it up to a bit of a de-sync, we went in, had a coffee and a relax, and then headed out to the car to wait for it to finish charging. It finished, we unplugged, and headed out. But to this day I've not been charged by Ecotricity for that so "yay".

Our final stop along the M4 was Swansea West. Unfortunately the Pont Abraham services don't have a rapid charger compatible with my car so we have to stop earlier. Fortunately there are three chargers at Swansea West. Unfortunately the CCS was plugged into an i3 which wasn't charging but was set to keep the connector locked in so I couldn't snarf it. I plugged into a slower (AC) charger to get a bit of juice while we went in to wait for the i3 owner to leave. I nipped out after 10 minutes and conveniently they'd gone, so I swapped the car over to the CCS charger and set it going. 37 minutes later and that charger had actually worked, charged me up, and charged me a princely £5.52 for the privilege.

From here we nipped along the A48/A40, dropped in on my sister-in-law to collect a gift for my father, and then got to St Davids at around nine pm. A mere eleven hours after we left Manchester. By comparison, when I drove a Passat, I would leave Manchester at 3pm, drive 100 fewer miles, and arrive at around 9pm, having had a few nice stops for loo breaks and dinner.

Saturday it had been raining quite hard overnight, St Davids has one (count it, ONE) charger compatible with my car (type 2 in this instance) but fortunately it's free to use (please make donation in the tourist-information-office). Unfortunately after the rain, the parking space next to the charger was under a non-trivial amount of water, so poor Rob had to mountaineer next to the charger to plug in without drowning. We set the car charging and went to have a nice breakfast in St Davids. A few hours later, I wandered back up to the car park with Rob and we unplugged and retrieved the car. Top marks for the charger, but a pity the space was a swimming pool.

Sunday morning dawned bright and early we headed out to Llandewi Velfrey to visit my brother who runs Silverstone Green Energy. We topped up there and then headded to Sarn Parc at his suggestion. It's a nice service area, unfortunately the AC/Chademo charger was giving 'Remote Start Error' so the Leaf there was on the Chademo/CCS charger. However as luck would have it, that charger was on free-vend, so once we got on the charger (30m later or so) we got to charge for free. Thanks Ecotricity.

From Sarn Parc, we decided that since we'd had such a good experience at Strensham North, we'd go directly there. We arrived with 18m to spare in the "tank" but unfortunately the CCS/Chademo charger was broken (with an error along the lines of PWB1 is 0x0008) and there was an eGolf there which also had wanted to use CCS but had to charge slowly in order to get enough range to get to another charger. As a result we had to sit there for an hour to wait for him to have enough in his 'tank' that he was prepared to let us charge. We then got a "full" 45 minute charge (£1.56, 5.2kWh) which gave us enough to get north again to Chateau Impney (which had been marked working again on Zap-map).

The charge there worked fine (yay) so we drove on north to Keele services. We arrived in the snow/hail/rain (yay northern weather) found the charger, plugged in, tried to set it going using the app, and we were told "Unable to contact charger". So I went through the process again and we were told "Charger in use". It bloody well wasn't in use, because I was plugged into it and it definitely wasn't charging my car. We waited for the rain to die down again and looked at the charger, which at that moment said "Connect vehicle" and then it started up charging the car (yay). We headed in for a loo and dinner break. Unfortunately the app couldn't report on progress but it had started charging so we were confident we'd be fine. More fool us. It had stopped charging moments after we'd left the car and once again we wasted time because it wasn't charging when we thought it was. We returned, discovered the car hadn't charged, but then discovered the charger had switched to free-vend so we charged up again for free, but that was another 40 minute wait.

Finally we got home (via a short stop at the pub) and on Monday I popped along to a GMEV rapid charger, and it worked perfectly as it has every single time I've used it.

So, in conclusion, the journey was reasonably cheap, which is nice, but we had two failed charge attempts on Polar, and several Ecotricity cockups (though they did mostly end up in our favour in terms of money) which cost us around 90 to 120 minutes in each direction. The driving itself (in the Ioniq) was fine and actually meant I wasn't frazzled and unhappy the whole time, but the charging infrastructure is simply not good enough. It's unreliable, Ecotricity don't have support lines at the weekend (or evenings/early mornings), and is far too sparse to be useful when one wishes to travel somewhere not on the motorway network. If I'd tried to drive my usual route, I'd have had to spend four hours in Aberystwyth using my granny charger to put about 40 miles in the tank from a public 3 pin socket.

Categories: LUG Community Blogs

Jonathan McDowell: collectd scripts for the Virgin Media Super Hub

Tue, 06/02/2018 - 19:33

As I’ve previously stated I’m no longer using Virgin Media but when I was I had written a script to scrape statistics from the cable modem and import them into collectd. Primarily I was recording the upstream/downstream line speed and the per channel signal figures, but they could easily be extended to do more if you wanted. Useful to see when Virgin increase your line speed, or see if your line quality has deteriorated. I’ve shoved the versions I had for the Super Hub v1 and v3 in GitHub in the hope they’ll be of use to someone. Note that I posted my SuperHub 3 back to Virgin yesterday so I no longer have any hardware that needs these scripts.

Categories: LUG Community Blogs