Joseph Price

Updating OCI images in Incus with Tofu/Terraform

Unknown — Mon, 10 Feb 2025 00:00:00 +0000

TL;DR: github.com/PriceChild/terraform-incus-oci-image-updating</a> will update docker/oci images when applying.

I deploy to Incus</a> containers and take advantage of it's support for OCI (Docker) images</a> to avoid running Docker as well. I deploy using tofu/terraform and the incus provider</a> which seems to have a small drawback around keeping images updated.

Restic backups to B2 without delete - 2023

Unknown — Tue, 28 Mar 2023 00:00:00 +0000

Restic 0.15.0</a> quietly merged #2398</a> which finally allows native support of keys without delete permissions.
After updating the binary on relevant systems, reversing the two changes from my earlier post</a> (i.e. swapping rclone:b2:bucketname/foldername</code> back to b2:bucketname:foldername</code> & removing the extra rclone args) leaves a simple restic solution working with defaults. Awesome!
I had updated directly from 0.9.6 and checking the docs</a> includes quite a significant warning:
Warning: Due to issues with error handling in the current B2 library that restic uses, the recommended way to utilize Backblaze B2 is by using its S3-compatible API. Follow the documentation to generate S3-compatible access keys</a> and then setup restic as described at Amazon S3</a>. This is expected to work better than using the Backblaze B2 backend directly. Different from the B2 backend, restic’s S3 backend will only hide no longer necessary files. Thus, make sure to setup lifecycle rules to eventually delete hidden files. </blockquote> Backblaze have also publicised the S3 api as a good default</a>: So, which API should you use? In a nutshell, if your app is already written to work with S3, if you’re using tools that are written to S3, or if you’re just unsure, the S3 Compatible API is a good choice. If you’re looking for more control over access and key management, the B2 Native API is the way to go. </blockquote> It looks like this github comment</a> is the source of that warning showing that the b2 library used has been a maintenance burden for the project. Amusingly, and as per the warning above, the S3 api uses hide file rather than delete in the first place! I guess I'll be following that recommendation...
ARM Templates: list*() & reference() functions in variables workaround Unknown — Mon, 28 Jun 2021 00:00:00 +0000 Use ARM templates enough and eventually you'll wish to use one of the list*()</code> functions or reference()</code> in your variables. For example, you have multiple app services which require near identical appsettings. You'd like to define this object/array once, then reuse multiple times elsewhere in the template. Who likes repeating themselves? Unfortunately one of those settings includes e.g. a storage account access key or a reference()</code> to grab an application insights key... Unfortunately, it's well documented that this is not supported:</a> The template function 'listKeys' is not expected at this location </blockquote> CVE-2020-15228 redux: Azure DevOps Pipelines RCE Unknown — Mon, 22 Mar 2021 00:00:00 +0000 Reading hackernews, I came across Issue 2070: Github: Widespread injection vulnerabilities in Actions</a>. While I've yet to use github actions seriously, I recognised the feature described as near idential to Azure DevOps' "Logging Commands</a>" and decided to look at whether they were vulnerable to the same issue. They are: Azure DevOps suffers from the same vulnerability.</li> The problem was reported through the Microsoft Azure DevOps Bounty Program</a> and confirmed by Microsoft.</li> An opt-in mitigation was released this year which I describe below.</li> Azure DevOps users remain vulnerable by default, unless they take (in my opinion) unreasonably cumbersome precautions.</li> </ul> Restic backups to B2 without delete Unknown — Fri, 30 Oct 2020 00:00:00 +0000 Update 2023-03-28: Restic now supports limited keys by default, and also recommends the B2 S3 api instead. See here</a> Original Post:</h1> Since setting up restic to back up to b2 I had embarassingly missunderstood the following UI wording around lifecycle settings: </a> I had assumed that this meant that all versions of the file would be maintained, no matter what clients did. The B2 docs</a> are much clearer, explaining that these rules are really only automation on your existing files. They're not blocks/holds/locks which can take any action before or affect api calls. In short: Lifecycle Rules schedule cleaning up version history, they don't prevent you deleting that version history. One of the capabilities I want from my backup system is that the system backing data up should not also be able to destroy existing backups. (I'm not bothered about it reading previous backups) I had assumed lifecycle rules gave me this, I was wrong, time for a quick fix... The obvious solution is to restrict the capabilities of the b2 api key</a> during creation, specifically to omit deleteFiles</code>. Unfortunately, restic doesn't currently handle this well, for example during basic backups it requires the ability to delete files in the locks/</code> directory and will complain loudly. There are a few open issues</a> and existing</a> [PR]https://github.com/restic/restic/pull/2398(https://github.com/restic/restic/pull/2398)'s but nothing yet merged. Enter rclone</h2> A few years ago rclone gained support for serving storage to restic via it's api</a> and since rclone supports using soft delete by default</a> swapping to this backend is pretty trivial. One of the best bits is that you can continue to use your existing config, the repository format is unchanged. The first thing to do is to generate a new key without deleteFiles</code>: $ b2 authorize-account Using https://api.backblazeb2.com Backblaze application key ID: <account key id> Backblaze application key: $ b2 create-key --bucket bucketname keyname listBuckets,listFiles,readFiles,writeFiles <app key id> <app key secret> </code></pre> ...and then take that output to set up an rclone backend. You can either go through rclone config</code> (See their docs</a> for an example) or just drop a file into place: $ cat ~/.config/rclone/rclone.conf [b2] type = b2 account = <app key id> key = <app key secret> </code></pre> Then all that's left is to update your backup script: e.g. if previously it wasb2:bucketname:foldername </code></pre> then now it'll berclone:b2:bucketname/foldername </code></pre> (Note that the second part (b2</code>) now refers to the name of the rclone backend, not the type. e.g. the bit within the square brackets of rclone.conf config)</li> Alter the options rclone is called with. Annoyingly, even though rclone uses soft delete in b2 by default, restic sets --b2-hard-delete by default...</a> so add the following option whenever you run restic:-o rclone.args="serve restic --stdio" </code></pre> </li> </ol> Back to the lifecycle...</h2> Beyond restic forget</code>/prune</code> to manage old snapshots, we've now got to consider cleaning up soft deleted files. Given my backups are largely additive, forget</code> rarely frees much space so it's not my biggest priority. rclone provides a handy cleanup</code> command</a>, but it's very tempting to go back to where I began and let Backblaze b2 lifecycles clean them up without any extra scheduling on your own infrastructure. Obligatory https://restic.readthedocs.io/en/stable/045_working_with_repos.html#checking-integrity-and-consistency reminder. Multi-repos KISS Unknown — Sat, 26 Sep 2020 00:00:00 +0000 I have never worked in a monorepo professionally. LXD performance observation Unknown — Tue, 26 May 2020 00:00:00 +0000 You might want to consider enabling tmpfs... AppArmor hat & child profiles Unknown — Thu, 19 Mar 2020 00:00:00 +0000 My last post</a> omitted the real reason I hadn't swapped to OnlyOffice was that I was too lazy to look further into apparmor. Allowing dash to inherit the php permissions with /bin/dash ix,</code> is one solution but for other reasons, I wanted to write a more contained profile to spawn dash within. Searching the internet & reading my favourite apparmor docs</a> didn't enlighten. Why I'm not using ONLYOFFICE yet. Unknown — Wed, 26 Feb 2020 00:00:00 +0000 I'm a huge fan of Nextcloud and version 18 brought great integration with ONLYOFFICE</a>. I'm not using it though because it ships with binaries that aren't always straightforward to execute. Connection reset... Unknown — Thu, 28 Nov 2019 00:00:00 +0000 After switching energy supplier, I discovered I couldn't connect to their website. This is an explanation with notes of how I've attempted to diagnose the issue so far. Nextcloud, CVE's & Apparmor Unknown — Sat, 26 Oct 2019 00:00:00 +0000 Nextcloud</a> and others recently reported on CVE-2019-11043</a> which looks like a particularly nasty RCE affecting only nginx+php-fpm with certain configurations. Unfortunately, the configuration the Nextcloud documentation recommended was one of those vulnerable configurations. Switching backups to Restic - update Unknown — Fri, 18 Oct 2019 00:00:00 +0000 In a previous post</a> I mentioned swapping my backups to restic</a>. Since then, I've found my B2 storage costs increased substantially and wanted to figure out why. Azure DevOps permissions primer Unknown — Fri, 11 Oct 2019 00:00:00 +0000 I often join Azure DevOps</a> projects some time after they were started and can almost guarantee I'll find... questionable... permissions have been applied. If you search for e.g. "azure devops permissions" you'll get pages like this</a> which only tell half the story, so here's a quick primer... Switching backups to Restic Unknown — Sun, 01 Sep 2019 00:00:00 +0000 I have used Duplicati</a> uneasily for some time to back up my personal server which hosts Nextcloud and other bits. First thoughts on Zola Unknown — Mon, 19 Aug 2019 00:00:00 +0000 Zola</a> is a static site generator in Rust. Wanting to blog a bit more and having a passing interest in Rust, I figured I might as well rebuild my blog rather than actually write anything... Invoke-ASCmd Caches xmla? Unknown — Mon, 12 Aug 2019 00:00:00 +0000 tldr: Invoke-ASCmd</code></a> caches xmla files somewhere. Always provide the absolute path to Invoke-ASCmd -InputFile</code>. Should I hand over my account & card details? Unknown — Mon, 03 Oct 2016 00:00:00 +0000 While logging in to online banking... .uk domain transfers are scary Unknown — Fri, 03 Jun 2016 00:00:00 +0000 .uk transfers are a little different: You instruct your old registrar to change the "IPS tag" to point the domain to your new registrar.</li> You tell your new registrar that the domain just assigned to them is yours.</li> </ul> The new registrar then dutifully updates all of Nominet's records. Even if the name... email... address... you provided them with bears no relation to the existing (private?) registration information. Who cares if you had 2 factor authentication enabled on the original Nominet account, your domain is gone. Nominet says the onus is on the registrar to ensure they verify you're the owner when going through this process. But they don't? What's to stop someone scraping whois records (that IPS tag is public) and racing to claim the domains you're transferring before you do? Apparently nothing. A few weeks ago I ran a little test. I registered a new domain at one registrar and immediately asked they change the IPS tag to another. A coworker watched over my shoulder as I retrieved the whois details for my domain to see the tag change, but then I got distracted looking for cake/looking over their shoulder. They set up a new account at the second registrar and claimed the domain, using no secret information and without either registrar or Nominet gaining my consent. What am I missing? Do some registrars I haven't tried put effort into verifying your ownership? Is it just a few bad actors? UPDATE: One registrar I've contacted has now promised they've updated their systems to email the owner listed by Nominet for confirmation, before handing over the domain. Minor success... Chromecasts, Netflix & UI-200 Unknown — Mon, 23 Mar 2015 00:00:00 +0000 My Chromecast has regularly been refusing to play Netflix streams recently with error ui-200. identifying to the freenode testnet with certfp Unknown — Fri, 06 Apr 2012 00:00:00 +0000 freenode will be upgrading their services very soon. One of the major new features that this upgrade will bring is the ability to identify using ssl certificates. Here's a very quick guide on how to get started.

Joseph Price

Updating OCI images in Incus with Tofu/Terraform

Restic backups to B2 without delete - 2023

ARM Templates: list*() & reference() functions in variables workaround

CVE-2020-15228 redux: Azure DevOps Pipelines RCE

Restic backups to B2 without delete

Back to the lifecycle...</h2> Beyond restic forget</code>/prune</code> to manage old snapshots, we've now got to consider cleaning up soft deleted files. Given my backups are largely additive, forget</code> rarely frees much space so it's not my biggest priority.</p>

Multi-repos KISS

LXD performance observation

AppArmor hat & child profiles

Why I'm not using ONLYOFFICE yet.

Connection reset...

Nextcloud, CVE's & Apparmor

Switching backups to Restic - update

Azure DevOps permissions primer

Switching backups to Restic

First thoughts on Zola

Invoke-ASCmd Caches xmla?

Should I hand over my account & card details?

.uk domain transfers are scary

Chromecasts, Netflix & UI-200

identifying to the freenode testnet with certfp