(yet another) Non official client build

cyruspy

Renowned Member
Jul 2, 2013
208
34
93
Hello,

I would like to share the initiative of packaging the Linux client for different distributions as a nice opportunity to give back to the PBS creators and the community.

I've repackaged the original supported client in native RPM/DEB packages for:


1786493118552.png

Install​

Replace <REPO> with your distro's repository name from the table, and see the live index at https://download.opensuse.org/repositories/home:/ciriarte:/pbs-client/.

Distro<REPO>
TumbleweedopenSUSE_Tumbleweed
SlowrollopenSUSE_Slowroll
Leap 16.0openSUSE_Leap_16.0
Leap 15.6openSUSE_Leap_15.6
Rocky 9RockyLinux_9
Rocky 10RockyLinux_10
Ubuntu 24.04Ubuntu_24.04
Ubuntu 26.04Ubuntu_26.04
Debian 11 (arm64/armhf/ppc64el)Debian_11
Debian 12 (arm64/armhf/ppc64el)Debian_12
Debian 13 (arm64/armhf/ppc64el)Debian_13

openSUSE (zypper)​

Bash:
BASE=https://download.opensuse.org/repositories/home:/ciriarte:/pbs-client/<REPO>
sudo zypper addrepo -f -G "$BASE/home:ciriarte:pbs-client.repo"
sudo zypper --gpg-auto-import-keys refresh
sudo zypper install proxmox-backup-client proxmox-backup-file-restore

Rocky Linux (dnf)​

Bash:
BASE=https://download.opensuse.org/repositories/home:/ciriarte:/pbs-client/<REPO>
sudo dnf install -y dnf-plugins-core
sudo dnf config-manager --add-repo "$BASE/home:ciriarte:pbs-client.repo"
sudo dnf install -y proxmox-backup-client proxmox-backup-file-restore

Ubuntu (apt)​

Bash:
BASE=https://download.opensuse.org/repositories/home:/ciriarte:/pbs-client/<REPO>
sudo install -d /etc/apt/keyrings
curl -fsSL "$BASE/Release.key" | sudo gpg --dearmor -o /etc/apt/keyrings/pbs-client.gpg
echo "deb [signed-by=/etc/apt/keyrings/pbs-client.gpg] $BASE/ ./" \
| sudo tee /etc/apt/sources.list.d/pbs-client.list
sudo apt-get update
sudo apt-get install -y proxmox-backup-client proxmox-backup-file-restore

I've proposed upstream the work done here for their adoption in direction to the "Backup clients for other operating systems" roadmap target. If accepted, I'll eliminate the non official repos once re-published. If not accepted, will keep the current scope updated when a new release arrives.

For the time being, find the artifacts at https://github.com/ciroiriarte/pbs-client

Note: I've seen requests for armv7l in the forum. I did my best to build them, but keep in mind there are important drawbacks with it (can't count after year 2038, signed 32-bit, which can't address more than 2GB files). They are there for the time being, but unlikely for upstream to maintain them. Valid usecase, old Raspberry backing up config files.

I don't have ARM or PowerPC machines at hand to fully test those builds, so feedback is welcome.
 
Last edited:
  • Like
Reactions: Johannes S
Hi cyruspy,

Nice work — good to see another take on this. We maintain a similar unofficial repository, so here is what we found on our side, in case it helps.

Coverage is close to yours but not identical: Fedora, RHEL, Rocky, AlmaLinux (dnf), Arch (pacman), Alpine (apk), and Debian/Ubuntu served the upstream .deb byte for byte. amd64 and arm64 (not tested, no ARM 64 CI server for now).

One gotcha you may hit outside Debian: the static binary has Debian's OpenSSL directory (/usr/lib/ssl) compiled in. Where that directory does not exist, the client rejects valid certificates and asks for a fingerprint (certificate validation failed - Certificate fingerprint was not confirmed). We reproduced it on Alpine 3.24 and Fedora 43. Our RPM, Arch and APK packages add two symlinks only — /usr/lib/ssl/cert.pem and /usr/lib/ssl/certs pointing at the distribution's CA bundle. Linking the whole directory also makes the static OpenSSL read the distribution's openssl.cnf, which you probably do not want.

On freshness: we check Proxmox's repository daily, verify the upstream .deb against their signed index (gpgv on InRelease, then SHA256 from Packages), repackage without recompiling, sign everything, and publish only after install tests pass — currently 27 containers, from CentOS 7 to Ubuntu 26.04. arm64 comes from the official aarch64 static build in Proxmox's test component, so it can lag one release, and we do not install-test it yet.

Repository and install instructions: unofficial-repository-proxmox-backup-client
Build scripts (MIT): Github repo

Unofficial, not affiliated with Proxmox, same as yours.

You mentioned proposing this upstream. If you go that way, happy to back the request: two independent repackaging efforts are a decent argument that official RPM/APK packages would be worth it.

Regards,
 
  • Like
Reactions: Johannes S
Hi cyruspy,

Nice work — good to see another take on this. We maintain a similar unofficial repository, so here is what we found on our side, in case it helps.

Coverage is close to yours but not identical: Fedora, RHEL, Rocky, AlmaLinux (dnf), Arch (pacman), Alpine (apk), and Debian/Ubuntu served the upstream .deb byte for byte. amd64 and arm64 (not tested, no ARM 64 CI server for now).

One gotcha you may hit outside Debian: the static binary has Debian's OpenSSL directory (/usr/lib/ssl) compiled in. Where that directory does not exist, the client rejects valid certificates and asks for a fingerprint (certificate validation failed - Certificate fingerprint was not confirmed). We reproduced it on Alpine 3.24 and Fedora 43. Our RPM, Arch and APK packages add two symlinks only — /usr/lib/ssl/cert.pem and /usr/lib/ssl/certs pointing at the distribution's CA bundle. Linking the whole directory also makes the static OpenSSL read the distribution's openssl.cnf, which you probably do not want.

On freshness: we check Proxmox's repository daily, verify the upstream .deb against their signed index (gpgv on InRelease, then SHA256 from Packages), repackage without recompiling, sign everything, and publish only after install tests pass — currently 27 containers, from CentOS 7 to Ubuntu 26.04. arm64 comes from the official aarch64 static build in Proxmox's test component, so it can lag one release, and we do not install-test it yet.

Repository and install instructions: unofficial-repository-proxmox-backup-client
Build scripts (MIT): Github repo

Unofficial, not affiliated with Proxmox, same as yours.

You mentioned proposing this upstream. If you go that way, happy to back the request: two independent repackaging efforts are a decent argument that official RPM/APK packages would be worth it.

Regards,
Hello, thanks for the insights. I'll double check on "freshness" on my side, there might be improvement opportunities.

No feedback on the proposal unfortunately.
 
  • Like
Reactions: rdemongeot
Thanks. On freshness, the trick is cheap: a daily job that only reads Proxmox's InRelease and Packages, compares the newest version with what we already publish, and exits when they match. The build only runs when there is something new, so it costs nothing to check often.

Shame about the proposal. Where did you send it — Bugzilla, the pbs-devel list, or here? If there is a ticket, point me at it and I will add our case to it: two independent repackagers, both hitting the same gaps (no RPM, no APK, no ARM install tests), is a better argument than one.