Create packages to install rustic

[nickchomey]

Is it possible to create packages that can be installed from apt and yum? This would surely make it easier for people to use and adopt Rustic, as well as update it.

[aawsome]

I agree that this makes life easier for some people. However, the best benefit would come from packaging rustic directly into a distro, which is out of my hands.

That said, I appreciate to get a PR which includes this into the CI pipeline or adds packages by other means. As rustic is only a single binary to install, I think it's feasible to live without it; at least I won't be able to put energy into it in the near future.

[nickchomey]

Understood. Though it's highly doubtful it will be included in the major distros - that's what the package repos are for, which restic takes advantage of.

I have no idea how to achieve something like this, so hopefully someone else does.

Is there any other way you know of to automatically update/re-download rustic when a new version is released? I know that I will completely neglect it and miss out on your rapid improvements!

[aawsome]

About updating: I think adding a self-update functionality would be a good feature. I added this as #119

[nickchomey]

Oh great, that'll be nearly perfect! (package manager is still clearly better, but perhaps not worth the effort to figure out and manage)

[aawsome]

I added the low-prio tag as #124 is now merged.

[if-jeremy]

Given the fact that this package is dynamic-linked, creating native packages for various distro's would be problematic, since you'd need a separate package for each release of a distro. However, this would seem to be a prime candidate for something like Snap, Flatpak, or AppImage distribution, or even run within a docker container.

[aawsome]

You are right, Rust normally compiles to a dynamically-linked binary, basically linking to libc. I didn't get many problems so far with recent distributions to get the pre-compiled binary running. Also I thought that most distros would create their packages by compiling the source code themselves - this wouldn't be too much of a problem. For instance, debian has a ready-to-build template for Rust CLIs, IIRC.

But I would also appreciate having rustic in Snap, Flatpak, or whatever else. If you can propose a PR I'll most probably merge it!

Besides this, there is the option to compile Rust completely statically using musl-libc. This is done in the -musl binary. For machines where I got libc dependency problems, I used the -musl binary.

[nickchomey]

Just a question related to the current "installation" (download) process - which version should we be using?

I'm currently using rustic-v0.4.4-x86_64-unknown-linux-gnu.tar.gz but see that rustic-v0.4.4-x86_64-unknown-linux-musl.tar.gz is available. I see that the other versions available all have GNU. What's the difference between GNU and MUSL? Is there a preference for using one?

[Shadow53]

It's a difference of which libc they use/link to. Most Linux distributions use GNU libc (glibc) while I can think of two that offer musl libc.

Glibc requires dynamic linking -- that is, the rustic binary will use whichever version of glibc is provided by the Linux distribution. Musl libc, on the other hand, can be statically linked, or built directly into the restic binary.

The benefit of glibc is a smaller binary file, as the libc code is located elsewhere. The downside is that, in certain (rare) circumstances, the system glibc is not compatible with the one restic was compiled with, and so the program breaks. With musl, you have larger binary files, because a copy of the libc is built into the program, but that also means you can run it on almost any system without worrying about any dynamic library dependencies.

Is there a preference for using one?

Just personal preference. GNU works for you, so you should be fine to continue using it.

[nickchomey]

Thanks!

[ibotty]

I prefer using glibc, because of bugs and missing implementations in musl. But regarding the comment above

The benefit of glibc is a smaller binary file, as the libc code is located elsewhere. The downside is that, in certain (rare) circumstances, the system glibc is not compatible with the one restic was compiled with, and so the program breaks. With musl, you have larger binary files, because a copy of the libc is built into the program, but that also means you can run it on almost any system without worrying about any dynamic library dependencies.

just a note, that a sizable population of linux distributions ship an older glibc which is incompatible:

• older Debian and Ubuntu distributions,
• RHEL <=9 (which as of writing is all of them) and derivatives (CentOS, Rocky, Alma, Oracle, ...),
• possibly others.

I'd prefer if rustic would be built on a slightly older system so that at least glibc 2.34 is supported.

[aawsome]

I prefer using glibc, because of bugs and missing implementations in musl.

Is there a bug or missing implementation in musl which is affecting rustic?

About older glibc support: You can always build a rustic version yourself. Just intall rust (e.g. using rustup) and run build.sh (or cargo build).

[ibotty]

There is no bug affecting rustic in musl, that I know of. DNS resolution is the very big problem, but that's not relevant afaict because rustic is using trust-resolver. I'll test rustic in kubernetes, where these issues usually manifest and will add a PR documenting problems, if I find some.

[lephyrus]

I've been using the mazzolino/restic docker image with restic, and am now running a self-made image for rustic. Maybe it can be a starting point for others.

This is my Dockerfile:

FROM alpine:3

# Install required packages
RUN apk add --update --no-cache curl rclone tzdata

WORKDIR /root

# Rustic: download, unpack, move into PATH
RUN curl -L -o rustic.tar.gz 'https://github.com/rustic-rs/rustic/releases/download/v0.5.3/rustic-v0.5.3-x86_64-unknown-linux-musl.tar.gz' && \
  tar xzf ./rustic.tar.gz && \
  mv rustic /bin/ && \
  rm ./rustic.tar.gz

# Add crontab file
COPY crontab /etc/crontabs/root

# Run cron
ENTRYPOINT crond -f -d 8

The crontab would need to be at the root of the build context, and for me looks something like this:

0 3 * * * rustic backup
0 5 * * * rustic prune

You could of course throw a rustic check or even a rustic self-update in there.

This is how I spin up the container with docker-compose, bind-mounting the data directory and config files and providing some env variables:

  rustic:
    build: ${build_root}  # wherever you've placed the Dockerfile
    container_name: rustic
    hostname: ${HOSTNAME}
    environment:
      AWS_ACCESS_KEY_ID: ${RESTIC_AWS_KEY_ID}
      AWS_SECRET_ACCESS_KEY: ${RESTIC_AWS_KEY_SECRET}
      RCLONE_CONFIG: /root/rclone.conf
      RUSTIC_PASSWORD: ${RUSTIC_PASSWORD}
      TZ: ${TZ}
    volumes:
      - ${data_dir}:/data:ro
      - ${build_root}/rustic.toml:/root/rustic.toml:ro
      - ${build_root}/rclone.conf:/root/rclone.conf:ro
    restart: unless-stopped

[aawsome]

@lephyrus Thanks a lot for sharing! Would you mind creating a PR which adds Dockerfiles etc. to the git repository?

[z3cko]

Please also include homebrew (Mac OS). It is very easy to implement, and you can find details in the link i provided.

[aawsome]

@z3cko Would you be able to implement the homebrew distribution? I can easily create a homebrew-rustic project for this, but I fear I'm missing time to actually working on it (and as non-Mac user it honestly isn't too much on my personal prio list...)

[simonsan]

AUR Package repository: https://github.com/jiripospisil/archlinux-aur-rustic-bin

[snorremd]

Please also include homebrew (Mac OS). It is very easy to implement, and you can find details in the link i provided.

I've made an unofficial formula for rustic. https://github.com/snorremd/homebrew-tap/pkgs/container/tap%2Frustic

Three caveats:

1. I don't provide notarized binaries as I don't have an Apple developer account to use for code signing
2. I don't provide pre-bottled binary for OSX Arm64 (M1, M2, etc) as GitHub Actions don't provide runners for this platform yet, and renting a Mac M1 to run continuously for 24 hours (per Apple license) from a cloud provider just to build a bottle seems a bit overkill
3. I can't promise to stay in sync with new versions of Rustic. PRs are welcome though.

Use at your own discretion.