feat: check metered connection before automatic updates

[ArtikusHG]

This PR prevents automatic update services from running on a metered connection (see #113 for more details).

Explanation:

• /bin/bash -c is needed because systemd runs binaries, not shell scripts
• busctl get-property org.freedesktop.NetworkManager /org/freedesktop/NetworkManager org.freedesktop.NetworkManager Metered gets the value of the metered connection property
• ...but it doesn't just return the number, also some symbols behind it, so we trim them with | cut -c 3-
• == @(2|4) checks if the result is either 2 (NM_METERED_NO) or 4 (NM_METERED_GUESS_NO), as per documentation:

• the service only runs if the above code returns a success code

Regarding DE app stores and such: GNOME software seems to already have support for not running updates on a metered connection, pretty sure KDE and others have the same thing.

Note: I did test this and it seems to work, but I would like at least a few more people to confirm this before we can get this merged.

Also includes just commands to disable/enable automatic updates at will, without marking the connection as metered.

[tunix]

LGTM

[ArtikusHG]

@tunix did you test it? If so, did you test both the metered connection check and the just commands? I know some people have issues with rpm-ostreed-automatic.timer re-enabling by itself, but according to the docs this shouldn't happen

[ArtikusHG]

Also can someone from the maintainers please approve the build workflow? Ideally I want people to be able to rebase to this to test it, it's probably fine but I still wanna make sure this doesn't break anything for anyone

[KyleGospo]

Also can someone from the maintainers please approve the build workflow? Ideally I want people to be able to rebase to this to test it, it's probably fine but I still wanna make sure this doesn't break anything for anyone

Done, sorry for the long wait.

[ArtikusHG]

Thanks! No worries, we're all just regular people working on this in their free time, after all.

[bsherman]

Also can someone from the maintainers please approve the build workflow? Ideally I want people to be able to rebase to this to test it, it's probably fine but I still wanna make sure this doesn't break anything for anyone

I appreciate the desire to test before pushing this out to the world.

Building this workflow in PR is fine, but it won't create an image or RPM for you to test with.

What I do to test changes like this is:

1. build the config image locally (eg, podman build -f Containerfile)
2. access the RPMs using a temp container image

$ cat Tempfile
FROM registry.fedoraproject.org/fedora-toolbox:38
COPY --from=ghcr.io/ublue-os/config:latest /rpms /tmp/rpms

$ podman build -f Tempfile -t tmptoolbox
$ podman run --rm -it -v ./tmp/currentdir tmptoolbox 

Then I usually install the RPM inside that container, and if that's all I require, that's fine. Additionally, can copy the RPM to /tmp/currentdir and install locally on my real computer or a VM to make sure it works right.

[ArtikusHG]

Oh, I was mislead by the fact that one of the checks was called "build-ublue", and thought it builds the image. Thanks!

[bsherman]

one of the checks was called "build-ublue"

Good point. That is copy pasta 😂

But take a look at the actions tab and you see how the builds happen. When building for a PR we don't push images.

[ArtikusHG]

Has anyone tested this yet?

[bsherman]

One request then I'm ready to approve.

Will you please update the changelogs in the respective RPM spec files?

build/ublue-os-just/ublue-os-just.spec and rpmspec/ublue-os-update-services.spec

[bsherman]

LGTM! Thank you!

[bsherman]

@ArtikusHG this is approved and queued to merge. Thank you for the contribution.

I'd never used the "metered connection" feature before, so I learned something new and I'm excited to use this!

[ArtikusHG]

Thanks a lot for helping! I'm happy to be part of this amazing project :)