last week

Time

First week in a while that I've managed to plan whole days for specific projects, rather than each day being a jumble of several. Also the first in ages that I've consistently left the house to work (using a couple of local co-working spaces).

For the next few weeks of summer holiday I'm intending to keep working away from the house most days as there's just too much noise and disruption with all three children at home.

Some while ago I planned each week, setting aside each day for a given project / topic (eg PaTMa marketing, consultancy work or All Secure Domains development). I'd work out this plan before the start of each week - normally around the end of the previous one. At some point a month or two ago this process fell apart somewhere.

This time around I'm taking a slightly different approach - I've split the week up in proportion to how I'm dividing my time to different projects at the moment and then allocated the appropriate number of set days each week and I'm simply going to repeat the same pattern every week until I re-evaluate. When I need to schedule meetings or client work I'll only offer times during the appropriate days. Hopefully this will help avoid me accidentally messing up my time allocations for each project.

Related to how time is spent, I found this podcast detailing a day in the life of a property investor interesting, if perhaps a little niche to their particular situation.

British Gas fun (and data protection)

More fun with British Gas this week - they've now got a debt collection agency involved.

A quick recap: I purchased a house with tenants already in place, with an AST but not one I provided. A few months later they decided to move (a group of friends adjusting their arrangements), they'd been living there for about seven years. I told British Gas their leaving date, meter reading and my details for taking over. The tenants had an online account with British Gas.

Just before new tenants moved in, British Gas sent a letter to the occupier which was a bill for the last two years of apparently unpaid supply!

I spoke to the previous tenants who said that when they closed their British Gas account, they'd received a large credit! For roughly the amount British Gas are now claiming was unpaid!

The difficulty here as that the previous tenants AST does not include a clause stating that the landlord can share their details with utility companies. I've spent quite a while trying to find guidance on this on the ICO website but have not been successful. The closest I've got is an old (2010) article about the subject that quotes the ICO as saying landlords should provide data to utilities but includes this:

"However, landlords must make tenants aware of these possible disclosures at the start of the tenancy."

Hence I think I'm a bit stuck.

I've emailed the previous tenants asking for permission to pass on their details but not yet had a reply. Obviously when the debt collection company take the matter to court I'll be able to provide any and all data I have about the previous tenants under "legal cause" provisions of data protection.

I think the law needs to be clarified (or perhaps defined) so that landlords can pass tenant data to utility companies as a direct legal requirement, without gaining the tenants consent first. It's clearly not something that is sensible or "right" to withhold.

Technology

Finally got around to looking up how to keep access to ssh-agent when sudo-ing.

I setup snapshot EBS backups this week and was very pleased to find that tool available via snap. Unfortunately the snap didn't work without a small adjustment. The required change was fairly obvious but managing to rebuild the snap to actually test (and use) it proved a little more involved...

Fixing LXD on my local machine

I use LXD on numerous servers but don't really use it locally (tending to use Vagrant with VirtualBox or just KVM for my local VM needs). So when I tried to use LXD for snapcraft this week I found it didn't work (I had some existing, old config which probably confused something)...

> lxc launch ubuntu:18.04 test
Creating test
Error: Failed container creation: No root device could be found.

I found a suitable hint to the answer here - my LXD didn't have a storage pool configured for root disk use.

I did have a "default" storage pool:

> lxc storage list
+---------+-------------+--------+------------------------------------+---------+
|  NAME   | DESCRIPTION | DRIVER |               SOURCE               | USED BY |
+---------+-------------+--------+------------------------------------+---------+
| default |             | dir    | /var/lib/lxd/storage-pools/default | 0       |
+---------+-------------+--------+------------------------------------+---------+

And the one-time fix was to include the storage pool when launching:

lxc launch ubuntu:18.04 test -s default

What it took me a little longer to realise was that "default" is just a name and doesn't actually mean it will be used as default storage! Hence I needed the following to actually set it to be used by default for root devices:

lxc profile device add default root disk path=/ pool=default

Snapcraft

Once I'd got LXD sorted out, the rest of the process to get started with Snapcraft was brilliantly simple.

Rebuilding with "snapcraft cleanbuild" ran and seemed to complete just fine. So next was installing the generated snap file manually (see dev setup guide):

snap install <snap file> --dangerous

That also seemed to work but unfortunately running ec2-consistent-snapshot resulted in other missing Perl libs. On closer inspection I realised snapcraft had built the new snap on a Xenial base, using a different Perl version; and generally produced a confused result.

So next up was working out how to get a build based on Ubuntu Bionic (18.04)...

I manually built a container for snapcraft:

lxc launch ubuntu:16.04 snapcraft -c security.privileged=true
lxc config device add snapcraft homedir disk source=/home/$USER path=/home/ubuntu

I then ran bash in the container so I could work there:

lxc exec snapcraft -- /bin/bash

Unfortunately installing the snapcraft snap inside the 18.04 container resulted in an error:

# snap install snapcraft --classic
error: cannot perform the following tasks:
- Setup snap "core" (4917) security profiles (cannot setup udev for snap "core": cannot reload udev rules: exit status 2
udev output:
)
- Setup snap "core" (4917) security profiles (cannot reload udev rules: exit status 2
udev output:
)

I found something similar with a mention that just trying the install again had worked - which it did for me too!

Now snapcraft was installed I could change to my modified clone of ec2-consistent-snapshot and build it:

snapcraft snap

Which resulted in the next issue - with GLIBC:

The GLIBC version of the targeted core is 2.23. A newer libc will be required for the following files:
- /home/ubuntu/src/ec2-consistent-snapshot/prime/lib/x86_64-linux-gnu/libexpat.so.1.6.7 (requires GLIBC 2.25)
- /home/ubuntu/src/ec2-consistent-snapshot/prime/usr/lib/x86_64-linux-gnu/libexpatw.so.1.6.7 (requires GLIBC 2.25)
'libc6' is required inside the snap for this part to work properly.
Add it as a `stage-packages` entry for this part.

Rather than fiddling around with GLIBC versions directly I thought it would probably be better to convince snapcraft to actually target Ubuntu 18.04. It seems this is possible by using the core18 snap as a base, by adding this to the top level of snapcraft.yaml:

base: core18

After that, I was able to successfully build, install and use my customised snap. :-)

One last note, mostly for my own future reference - listing files inside a snap:

unsquashfs -l <snap file>