autorestic
autorestic copied to clipboard
cupcakearmy
Distribute releases as compressed tarballs
I'm using Saltstack to install autorestic on my homelab servers. Out of the box, Saltstack has good support for downloading a tarball and decompressing it into a directory; however, it's support for decompressing a regular file is basically non-existent. Consequently, I have to download the file and decompress it using non-idempotent tools, which kinda defeats the purpose of config management.
I'd like to see autorestic distributed as a compressed tarball instead. It shouldn't really impact anyone too greatly since Mac and Linux both have tools out of the box to handle tarballs.
bzip2 is installed; however saltstack’s archive function relies on having an archive file (like tarballs or zips) instead of a simple compressed file. The state modules don’t seem to support just a simple download and extract paradigm.
Ansible has the same type of issue. It’s modules are dependent on tarballs as well.
On Aug 3, 2021, at 5:17 AM, Nicco @.***> wrote:
So you only have tar but not bzip2 installed on Saltstack?
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.
But how do you install restic then?
autorestic, being a wrapper around restic has the same exact build chain and release nomenclature.
https://github.com/restic/restic/releases
Restic itself has the same distribution with .bz2, so to be consistent with it I'm quite opposed to chainging that.
The problem isn't "Can I install restic & autorestic?" The problem is "Can I manage restic & autorestic?"
My salt state runs an imperative command and only checks that a file exists on disk to see if it needs to be rerun. For example, the first time I install a box using salt, I can download the version of restic and autorestic I declaratively specify. On subsequent runs of the same state, salt looks to see if the restic and autorestic binaries exist on disk. If it does, it skips that step. If it doesn't, it reruns.
Now the problem comes: I want to update restic for whatever reason (like the speed enhancements for prune). I now have to delete the restic binary on all of my boxes, update the version I want to install in my pillar data, and rerun the salt states. If the binary was distributed using a tarball instead, I could remove the first step.
The above scenario is true for Ansible as well, AFAIK.
I do get wanting to distribute the binary in the same way as restic. They actually have an issue open for this exact ask. They haven't said one way or the other whether they'll do it, but the interest from (at the very least) a small subset of the community is there.
I see the problem :)
I would however stay consistent with restic itself. If they change their build system autorestic would follow. So let's keep an eye on https://github.com/restic/restic/issues/2346 and see what happens. :)
Wrong button. Apologies.
It's all good. I just wanted to make sure the ask and use case were both clear. :)
If you're following restic's distribution method, I'll respectfully wait for them to make their move.
Thanks for the awesome tool btw. Definitely makes managing a 3-2-1 backup strategy a heck of a lot easier.
Wrong button. Apologies.
It's all good. I just wanted to make sure the ask and use case were both clear. :)
If you're following restic's distribution method, I'll respectfully wait for them to make their move.
Thanks for the awesome tool btw. Definitely makes managing a 3-2-1 backup strategy a heck of a lot easier.
No worries :)