vaultwarden 1.30.0 breaks Dockerfile patching
kevinior opened this issue · 11 comments
Using latest main (da9ce2e):
./build.sh -o bookworm -r 1.30.0
~/reps/vaultwarden-debian/git ~/reps/vaultwarden-debian
HEAD is now at cec1e876 Fix importing Bitwarden exports (#4030)
Removing debian/
~/reps/vaultwarden-debian
Hmm... Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- git/docker/amd64/Dockerfile 2023-07-29 15:42:52.131945764 -0500
|+++ Dockerfile 2023-07-29 16:18:19.915440456 -0500
--------------------------
patching file /home/kevin/reps/vaultwarden-debian/Dockerfile (read from /home/kevin/reps/vaultwarden-debian/git/docker/amd64/Dockerfile)
Using Plan A...
Hunk #1 FAILED at 77.
1 out of 1 hunk FAILED -- saving rejects to file /home/kevin/reps/vaultwarden-debian/Dockerfile.rej
done
It looks like the vaultwarden project has drastically changed how the Dockerfiles are arranged: https://github.com/dani-garcia/vaultwarden/tree/1.30.0/docker
I've tried manually applying the changes to the new Dockerfile and then generating a new patch. That also required changing the path to the Dockerfile to patch.
Unfortunately it seems like they've changed enough that just doing that isn't enough:
./build.sh -o bookworm -r 1.30.0
~/reps/vaultwarden-debian/git ~/reps/vaultwarden-debian
HEAD is now at cec1e876 Fix importing Bitwarden exports (#4030)
Removing debian/
~/reps/vaultwarden-debian
Hmm... Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff --git a/docker/Dockerfile.debian b/docker/Dockerfile.debian
|index 26a53b0a..4b25c82b 100644
|--- a/docker/Dockerfile.debian
|+++ b/docker/Dockerfile.debian
--------------------------
patching file /home/kevin/reps/vaultwarden-debian/Dockerfile (read from /home/kevin/reps/vaultwarden-debian/git/docker/Dockerfile.debian)
Using Plan A...
Hunk #1 succeeded at 140.
done
[INFO] docker build -t vaultwarden-deb /home/kevin/reps/vaultwarden-debian --build-arg DB=sqlite
DEPRECATED: The legacy builder is deprecated and will be removed in a future release.
Install the buildx component to build images with BuildKit:
https://docs.docker.com/go/buildx/
Sending build context to Docker daemon 12.91MB
Step 1/46 : FROM --platform=linux/amd64 docker.io/vaultwarden/web-vault@sha256:419e4976921f98f1124f296ed02e68bf7f8ff29b3f1fba59e7e715228a065935 as vault
docker.io/vaultwarden/web-vault@sha256:419e4976921f98f1124f296ed02e68bf7f8ff29b3f1fba59e7e715228a065935: Pulling from vaultwarden/web-vault
1ae2a6326c52: Pull complete
f68e3bc71a52: Pull complete
Digest: sha256:419e4976921f98f1124f296ed02e68bf7f8ff29b3f1fba59e7e715228a065935
Status: Downloaded newer image for vaultwarden/web-vault@sha256:419e4976921f98f1124f296ed02e68bf7f8ff29b3f1fba59e7e715228a065935
---> 58b13e4f2b7b
Step 2/46 : FROM --platform=linux/amd64 docker.io/tonistiigi/xx@sha256:c9609ace652bbe51dd4ce90e0af9d48a4590f1214246da5bc70e46f6dd586edc AS xx
docker.io/tonistiigi/xx@sha256:c9609ace652bbe51dd4ce90e0af9d48a4590f1214246da5bc70e46f6dd586edc: Pulling from tonistiigi/xx
3074371de66a: Pull complete
Digest: sha256:c9609ace652bbe51dd4ce90e0af9d48a4590f1214246da5bc70e46f6dd586edc
Status: Downloaded newer image for tonistiigi/xx@sha256:c9609ace652bbe51dd4ce90e0af9d48a4590f1214246da5bc70e46f6dd586edc
---> 25ff0b939382
Step 3/46 : FROM --platform=$BUILDPLATFORM docker.io/library/rust:1.73.0-slim-bookworm as build
failed to parse platform : "" is an invalid component of "": platform specifier component must match "^[A-Za-z0-9_-]+$": invalid argument
Can you check out the master branch? There were a couple of changes to make it build the 1.30.
Unfortunately it seems like they've changed enough that just doing that isn't enough:
Step 3/46 : FROM --platform=$BUILDPLATFORM docker.io/library/rust:1.73.0-slim-bookworm as build failed to parse platform : "" is an invalid component of "": platform specifier component must match "^[A-Za-z0-9_-]+$": invalid argument
I was getting that same error, installing docker-buildx fixed it. I also had to install python-jinja. So perhaps these two things should be added to the build requirements.
I've been wanting to simplify all of this for a while, can you check the next branch please? It shouldn't try to rebuild everything.
It means that trust is delegated to the upstream release? I quite liked the idea that it only relies on sources, but I have to admit that it's a real pain to maintain…
I've been wanting to simplify all of this for a while, can you check the
nextbranch please? It shouldn't try to rebuild everything.
The next branch builds. There's a huge diff on the config.env file but I guess that's upstream's fault.
When installing the package I get an error: Failed to open 'vaultwarden.conf', ignoring: No such file or directory
That install leaves vaultwarden in a broken state:
Nov 08 15:29:01 oelph systemd[1]: Started vaultwarden.service - Vaultwarden API server.
Nov 08 15:29:01 oelph (ltwarden)[944580]: vaultwarden.service: Failed to locate executable /usr/bin/vaultwarden: No such file or directory
Nov 08 15:29:01 oelph (ltwarden)[944580]: vaultwarden.service: Failed at step EXEC spawning /usr/bin/vaultwarden: No such file or directory
Nov 08 15:29:01 oelph systemd[1]: vaultwarden.service: Main process exited, code=exited, status=203/EXEC
Nov 08 15:29:01 oelph systemd[1]: vaultwarden.service: Failed with result 'exit-code'.
I've just unpacked the .deb file and there's no /usr/bin/ directory, looks like the executable is now /usr/local/bin/vaultwarden
If I change the path in vaultwarden.service I still get the error about "vaultwarden.conf" but now the vaultwarden service fails to start with this error:
Nov 08 15:58:26 oelph systemd[1]: Started vaultwarden.service - Vaultwarden API server.
Nov 08 15:58:26 oelph vaultwarden[945329]: /usr/local/bin/vaultwarden: error while loading shared libraries: libpq.so.5: cannot open shared object file: No such file or directory
Nov 08 15:58:26 oelph systemd[1]: vaultwarden.service: Main process exited, code=exited, status=127/n/a
Nov 08 15:58:26 oelph systemd[1]: vaultwarden.service: Failed with result 'exit-code'.
So it's building the for postgresql although the default is supposed to be sqlite? The package was called vaultwarden-1.30.0-sqlite-amd64.deb
The upstream Dockerfile defaults to building for sqlite, mysql AND postgresql: https://github.com/dani-garcia/vaultwarden/blob/cec1e87679cfd0e2f0bce9b7dc3256dbbd2effa8/docker/Dockerfile.debian#L105
So if you're just using their image you need dependencies for all 3 installed. Adding , libmariadb3, libpq5 to VAULTWARDEN_DEPS in build.sh produces a package that installs and works.
It means that trust is delegated to the upstream release? I quite liked the idea that it only relies on sources, but I have to admit that it's a real pain to maintain…
You still have to option to build from source, see this section.
Closing this as the next branch has been merged. Hopefully this will make following upstream easier.
So to summarize, I see that I need a tool (Docker) with a subtool/plugin (buildx bake) with a dedicated configuration (docker-bake.hcl) that uses a CPU emulator (qemu) to build using an image of my own OS (Debian) emulating my own CPU. All of this with a new copy of Rust that I already have on installed on my Debian/unstable using apt, since setting rust-version to 1.70.0 (version in Debian/unstable) in Cargo.toml and launching cargo build just work fine.
Is it just me that find this a little bit too much? Am I over exaggerating the pile of software that seems barely unneeded?
Of course, for building images on other architectures, qemu is needed, even if cross-compilation is supported. I think that nonetheless, building a Debian package my target OS shouldn't need this.
I've used your great work (really, it is) for many years because rust packaging in Debian was lagging behind, but I think it's time for me to switch.