[domcyrus]

Add a Dockerfile and job to build it during package workflow.

#69

[domcyrus]

@GyulyVGC this works on my feroda 41 using following steps:

docker build -t sniffnet .

docker run -it \
  --net=host \
  -v $XDG_RUNTIME_DIR/$WAYLAND_DISPLAY:/tmp/$WAYLAND_DISPLAY \
  -e WAYLAND_DISPLAY=$WAYLAND_DISPLAY \
  -e XDG_RUNTIME_DIR=/tmp \
  -e RUST_BACKTRACE=full \
  -e ICED_BACKEND=tiny-skia \
  --cap-add=NET_ADMIN \
  --cap-add=NET_RAW \
  sniffnet

I created a draft because I think it would be good to test some things a bit more e.g. on different linux versions maybe and with and without gpu. And certainly add some documentation because this approach is not OS agnostic for example if you would like to use the container on windows or mac it might be a bit more challenging as you would need to have wayland running on mac. Please let me know how you want to deal with this.

[GyulyVGC]

Thank you very much 🔥

I think before testing it'd be nice to make this as platform agnostic as possible, as it's one of the main purposes is the container.

[domcyrus]

@GyulyVGC regarding platform agnostic. AFAICT docker images ARE platform dependent and can't be made platform agnostic. That said I've altered the github workflow docker job to build various different images for each platform.

          platforms: linux/amd64,linux/arm64,linux/386,linux/arm/v7

I've also tested using docker buildx locally like this:

 docker buildx build --platform linux/arm64 -t domcyrus/sniffnet:arm64 --load .
2025/02/23 12:21:35 in: []string{}
2025/02/23 12:21:35 Parsed entitlements: []
[+] Building 3300.1s (15/15) FINISHED                                                               docker-container:multiarch-builder
 => [internal] load build definition from Dockerfile                                                                              0.0s
 => => transferring dockerfile: 865B                                                                                              0.0s
 => [internal] load metadata for docker.io/library/rust:1.85-slim                                                                 1.4s
 => [internal] load metadata for docker.io/library/debian:bookworm-slim                                                           1.2s
 => [internal] load .dockerignore                                                                                                 0.0s
 => => transferring context: 221B                                                                                                 0.0s
 => [builder 1/5] FROM docker.io/library/rust:1.85-slim@sha256:c46b18afcf69c93b00781d3108addc0f5d5f113cd69faccb02e1c22b470e6b3d   9.8s
 => => resolve docker.io/library/rust:1.85-slim@sha256:c46b18afcf69c93b00781d3108addc0f5d5f113cd69faccb02e1c22b470e6b3d           0.0s
 => => sha256:809ab4ce3403ef1471e13068ac77fcbcabb76460a40a555a3a348b1b0a69bf3b 323.01MB / 323.01MB                                3.6s
 => => extracting sha256:809ab4ce3403ef1471e13068ac77fcbcabb76460a40a555a3a348b1b0a69bf3b                                         6.1s
 => [stage-1 1/3] FROM docker.io/library/debian:bookworm-slim@sha256:40b107342c492725bc7aacbe93a49945445191ae364184a6d24fedb2817  1.7s
 => => resolve docker.io/library/debian:bookworm-slim@sha256:40b107342c492725bc7aacbe93a49945445191ae364184a6d24fedb28172f6f7     0.0s
 => => sha256:4d2547c084994a809c138e688fbe4ee14eedbc6e2defc5b1c680edd16e291473 28.04MB / 28.04MB                                  0.5s
 => => extracting sha256:4d2547c084994a809c138e688fbe4ee14eedbc6e2defc5b1c680edd16e291473                                         1.1s
 => [internal] load build context                                                                                                 0.7s
 => => transferring context: 121.28MB                                                                                             0.6s
 => [stage-1 2/3] RUN apt-get update && apt-get install -y     libfreetype6     libexpat1     libpcap0.8     libasound2     lib  85.9s
 => [builder 2/5] RUN apt-get update && apt-get install -y     libfreetype6-dev     libexpat1-dev     libpcap-dev     libasoun  167.8s
 => [builder 3/5] WORKDIR /usr/src/sniffnet                                                                                       0.2s 
 => [builder 4/5] COPY . .                                                                                                        0.4s 
 => [builder 5/5] RUN cargo build --release                                                                                    3112.9s 
 => [stage-1 3/3] COPY --from=builder /usr/src/sniffnet/target/release/sniffnet /usr/local/bin/sniffnet                           0.2s 
 => exporting to docker image format                                                                                              7.3s 
 => => exporting layers                                                                                                           4.2s 
 => => exporting manifest sha256:74b4f8bc6ecf8981f29cc2e7e50c1d85de93ebd62e8b423a23c76e838859db56                                 0.0s 
 => => exporting config sha256:7d947c4124756bf3cd67e67cc51e490da4308471d06f5fb0518aa819616d7bd2                                   0.0s 
 => => sending tarball                                                                                                            3.1s 
 => importing to docker                                                                                                           2.6s 
 => => loading layer 6917fb72c784 53.11MB / 53.11MB                                                                               2.6s 
 => => loading layer b88da0c93ef3 18.99MB / 18.99MB                                                                               0.3s 

It took a bit of time to compile it ;) but it looks alright to me.

Let me know what you think about this approach.

[GyulyVGC]

Thank you very much again.

I'm pretty busy these days, will check and test as soon as I get some time.

[GyulyVGC]

Hey @domcyrus from a quick review, I suggest covering the following points if possible.

• use a different CI/CD file to build the image so that I can run independently from the package workflow (I may run the package multiple times for each release but I only want to publish one image)
• The tag of the pushed image should be equal to the version of the project from the Cargo.toml manifest file
• Document how to run the image on Windows and macOS, and we should ensure that the instructions you provided for Linux work on the majority of Linux distros/environments

[domcyrus]

@GyulyVGC Thanks for your comment.

I did spend quite a bit of time on this and I believe that we should primarily focus on supporting the Docker on Linux, where it can function with full capabilities e.g. by using --net=host and some display variables.

For Windows and macOS, there are many more challenges.

One is that there are network traffic capture limitations in that docker containers on Windows/macOS are running in a VM and therefore --net=host doesn't provide access to the host's network traffic and you would only see traffic within the Docker VM, not actual host traffic.

Another issue is that GUI application are not trivial to run. You would need to install things like XQuartz on macOS and on Windows it would require to installing an X server (like VcXsrv) and likely a bunch more tricky things like configuring firewall exceptions and dealing with WSL2 display forwarding.

Therefore I would recommend that we focus on primarly supporting linux. I can still try to run it on macOS or Windows but without network traffic from the host. One way around that would be that you could precapture network traffic and share a PCAP file but as mentioned above this is not trivial and quite brittle and therefore we should recomment to run native sniffnet application on Windows and macOS.

What do you think?

[GyulyVGC]

One is that there are network traffic capture limitations in that docker containers on Windows/macOS are running in a VM and therefore --net=host doesn't provide access to the host's network traffic and you would only see traffic within the Docker VM, not actual host traffic.

This is a good point, I didn't think about it.
At this point, given that running Sniffnet without host traffic wouldn't make much sense, let's just support Linux 👍

[domcyrus]

@GyulyVGC

• use a different CI/CD file to build the image so that I can run independently from the package workflow (I may run the package multiple times for each release but I only want to publish one image)
• The tag of the pushed image should be equal to the version of the project from the Cargo.toml manifest file
• Document how to run the image on Windows and macOS, and we should ensure that the instructions you provided for Linux work on the majority of Linux distros/environments

I've tested it two wayland distros with fedora 41 and ubuntu 25.04. I've also tested it on X11 using debian trixie XFCE desktop.

[GyulyVGC]

Thank you so much @domcyrus for your work 🙏

I’m going to merge the PR into a secondary branch first just to test that it correctly publish the image (I need to be owner of a branch to read GitHub secrets).
I will tag you in case of need!

@all-contributors please add @domcyrus for platform.

[allcontributors]

@GyulyVGC

I've put up a pull request to add @domcyrus! 🎉

[GyulyVGC]

Hey @domcyrus I want to thank you again for the work, I tested it and everything is fine.
The only minor doubt I have is that when an image is published, also two more untagged images are published as well.
Do you have any idea why this is happening?

Edit: oh, it appears they are the images referring to the target platform (so linux/amd64 and unknown/unknown).
The only reason why I don't like it very much is that in this way the number of downloads is duplicated: for each download of the tagged image, also one of the untagged images is counting a download.
I will check if this is expected in ghcr.io, even if it seems weird.

[domcyrus]

Hey @domcyrus I want to thank you again for the work, I tested it and everything is fine. The only minor doubt I have is that when an image is published, also two more untagged images are published as well. Do you have any idea why this is happening?

Edit: oh, it appears they are the images referring to the target platform (so linux/amd64 and unknown/unknown). The only reason why I don't like it very much is that in this way the number of downloads is duplicated: for each download of the tagged image, also one of the untagged images is counting a download. I will check if this is expected in ghcr.io, even if it seems weird.

Hi @GyulyVGC, I did look a bit more into it and I think this is normal. I've made some small changes in the docker.yml here in order to run with my personal ghcr.io and also test all the different platforms which I've seen that the arm/v7 doesn't actually work and propably is also not needed as it is quite an old platform. The versioning on the other hand seems to work fine.

Is there anything you would like me to add or remove?

[GyulyVGC]

No don't worry, mine was just more a curiosity

[reneleonhardt]

@domcyrus Great to see a Dockerfile 👍

The build took 7 minutes, can caching be added to speed-up new builds?
https://github.com/GyulyVGC/sniffnet/actions/runs/15935788507
https://depot.dev/blog/rust-dockerfile-best-practices

Is it possible to build a multi-platform image instead of linux/amd64 only?
https://hub.docker.com/_/debian/tags?name=bookworm-slim

Would it be more graceful to use a container init instead of the binary directly to handle shutdown signals?
https://github.com/openSUSE/catatonit

The .dockerignore is great! But for what reason is the Dockerfile required inside the container? 😄

The brew cask only offers Linux and macOS 13-15 binaries, are other macOS versions automatically not installable or would explicit rules be better?

  depends_on macos: ">= :ventura"
  depends_on macos: "< :tahoe"

Can libgtk-3 be migrated to libgtk-4?
https://packages.debian.org/search?keywords=libgtk&searchon=names&suite=bookworm&section=all
https://docs.gtk.org/gtk4/wayland.html