x-man WebDAV URL is missing the exposed port

[dhufe]

Dear all,

I currently trying to get x-man to run for testing purposes. I just cloned the project and adjusted minor thing regarding the use of rootless podman instead of docker. But there is one thing, where it stucks.

In compose.override.yml you are exposing the host port 8082 an redirecting it to the internal port 80.

    image: bytemark/webdav
    environment:
      USERNAME: ${WEBDAV_USERNAME}
      PASSWORD: ${WEBDAV_PASSWORD}
    ports:
      - 8082:80
    volumes:
      - ./data/webdav:/var/lib/dav

That's totally fine but, shouldn't it reused in the server part?

If I try to run the successfully built containers

2024/05/30 08:42:23 panic: Connect http://webdav//: 503 goroutine 26 [running]: runtime/debug.Stack() /usr/local/go/src/runtime/debug/stack.go:24 +0x5e runtime/debug.PrintStack() /usr/local/go/src/runtime/debug/stack.go:16 +0x13 lath/xman/internal/xdomea.HandlePanic({0xc000442050, 0x4b}) /xman/internal/xdomea/clearing.go:55 +0xd2 panic({0xd2cd60?, 0xc00034de90?}) /usr/local/go/src/runtime/panic.go:770 +0x132 lath/xman/internal/xdomea.readMessagesFromWebDAV({0x2, {0xe8289e0, 0xedde9fcd1, 0x15914e0}, {0xe8289e0, 0xedde9fcd1, 0x15914e0}, {0xc00003c4f8, 0x18}, {0xc00038d3c0, ...}, ...}, ...) /xman/internal/xdomea/transferdir.go:153 +0x39c lath/xman/internal/xdomea.readMessages() /xman/internal/xdomea/transferdir.go:105 +0x125 lath/xman/internal/xdomea.watchLoop({0xc000135aa0, {0xc00004c508, 0x270409963afdc, 0x3b9aca00, 0xe71918, {0xcbb820, 0xc000135aa0}, 0x0, 0x0, 0x1}}, ...) /xman/internal/xdomea/transferdir.go:86 +0x7a created by lath/xman/internal/xdomea.MonitorTransferDirs in goroutine 1 /xman/internal/xdomea/transferdir.go:75 +0x1a5 2024/05/30 08:42:23 Processing error for message : Anwendungsfehler

In internal/xdomea/init.go you're build the TransferDirURL by using the hardcoded name of the container without any port.

TransferDirURL: fmt.Sprintf("dav://%s:%s@webdav/", os.Getenv("WEBDAV_USERNAME"), os.Getenv("WEBDAV_PASSWORD")),

I'm not sure if it's a podman related problem (like exposing 465 for tls isn't supported out of the box).

If you need any further information, don't hestiate to conect me either on GitHub or over the DIMAG consortium.

Best regards and thanks in advance, Danie

[christopher-l]

Hi @dhufe, thank you for reporting the issue and for your interest in the project!

The problem with using the exposed port is, that it is exposed on the host network only and the host network is not accessible from the server's docker container. That is why the server connects to the webdav container directly via webdav as hostname (where the webdav service is exposed on port 80) instead of using the exposed port on the host network. We expose the port only, so a user can connect to it by other means.

However, I don't know why connecting via webdav as hostname doesn't work on your system. Do you use docker-compose in combination with podman? Are other containers within the compose file usually visible with the container's name as hostname in your setup?

[dhufe]

Wow thanks for the fast reply. No I'm using podman-compose, which parses the compose.yaml (and the compose.override.yml) and creates the containers and the network.

But you're right. I checked the naming and podman-compose creates conatinernames with a different naming scheme. In case of the "webdav"-container it creates a container named "x-man_webdav_1". The naming scheme is also applied on the other containers (e.g., x-man_mongo_1, x-man_report_1)

Quite strange, since for borg it works flawlessly (neglecting some minor changes).

Edit:

In the compose-file of borg you used container_name to explicitly name the container. In case of the webdav container I had to add container_name: webdav.

[christopher-l]

Using docker-compose, the containers are named similarly (x-man-webdav-1 in my case), but the container is accessible under the hostname webdav for services in the compose file anyway.

I guess the takeaway is that we should consider to test and support deployment using podman.

[christopher-l]

I tried running x-man with podman and I ran into the same issue (Connect http://webdav//: 503). However, in my case it turned out to be a proxy-related problem: While I could ping the host "webdav" fine, any HTTP request would be routed through the configured proxy which of cause doesn't know about any containers. Setting container_name: webdav didn't have any effect.

https://github.com/Landesarchiv-Thueringen/x-man/commit/6dcb93daa66d2c035db6e78b764bca4f98e57061 seems to fix it.

[dhufe]

One week ago, I also got it work properly by setting the no_proxy env for all containers and using the current release.

I played a bit with the Go-Code of the server, manipulating the timeouts for the transports and so on.

Know it works great in combination with borg(format) and we‘re currently running some tests with it.

[christopher-l]

Closing since the original issue seems to be resolved. Please reopen or open a new issue if anything comes up.