On Sat, May 10, 2025 at 2:32 PM Nick Couchman <vn...@apache.org> wrote:
> On Thu, May 8, 2025 at 3:32 PM Joachim Lindenberg > <guacam...@lindenberg.one.invalid> wrote: > >> Hello Nick, >> >> >>I build the docker containers out of staging/http://1.6.0. >> guacamole-server aka guacd builds & runs. However guacamole-client builds >> and reports (docker compose logs): >> >>guacamole | find: ‘/etc/guacamole/lib’: No such file or directory >> >>It looks like then the container is stuck. >> >> >Please make sure you definitely have the latest commits for that >> container and that it matches up with the Apache git repo - if you're >> checking out the code directly from the Apache >repos, do a "git pull" and >> make sure it updates as expected. If you have your own fork of the repo, >> make sure you've pulled in the latest commits from the Apache git repos. >> >> root@ubuntu:/opt/guacamole-server# git remote -v >> origin https://github.com/apache/guacamole-server.git (fetch) >> origin https://github.com/apache/guacamole-server.git (push) >> root@ubuntu:/opt/guacamole-client# git remote -v >> origin https://github.com/apache/guacamole-client.git (fetch) >> origin https://github.com/apache/guacamole-client.git (push) >> root@ubuntu:/opt/guacamole-client# git status >> On branch staging/1.6.0 >> Your branch is up to date with 'origin/staging/1.6.0'. >> >> looks ok to me, or what am I missing? Do you recommend a different branch >> or tag? >> I got one new commit guacamole-client between yesterday and today, which >> didn´t change the issue. >> > > Looks fine, and that is the correct branch for the current 1.6.0 code. > > >> >> >>Ok, I created an /etc/guacamole structure with a link to >> /opt/guacamole/extensions, guacamole.properties, and an empty lib >> directory. Now guacamole starts, but creates a >> >>GUACAMOLE_HOME is "/tmp/guacamole-home.HLzLUL4L9h", which contains my >> properties, but only one extension "Brute-force Authentication >> Detection/Prevention". >> >> >The new container build process creates a temporary directory and builds >> things up, and then maps that into the guacamole container. >> >> At build time or runtime? At build time seems broken to me. Anyway, the >> container did contain (or start) only one extension, which would also >> explain why others complain TOTP doesn´t work with containers. >> > > The GUACAMOLE_HOME directory is built at runtime based on the environment > variables passed through to the container. I've been unable to reproduce > any of the failures in my environment, and the user who was reporting TOTP > issues seems to have been manually placing JAR files in the GUACAMOLE_HOME > (or the template that is used to create it), which could cause issues. That > user reported that the issue was corrected when the JAR files were removed > from the template directory. > > I just built from the staging/1.6.0 branch without any issues - I cannot > reproduce a build failure in my environment. Also, we have automated builds > (including containers) of the various branches running, and I am not aware > of any build failures on those automated builds. > > >> Actually I think Guacamole should separate directories for "standard" and >> "custom" extensions in order to facilitate extensions in a docker scenario. > > > You're certainly welcome to propose ideas for this; however, the current > way that extensions are dealt with in the staging/1.6.0 environment has > been significantly re-worked to try to help improve the handling of both > built-in or standard extensions and facilitate users loading their own > extensions. But there may be better ways :-). > > >> >> >> >>I have no idea why it creates an (incomplete) copy. >> >>Is this known? Fixed? What branch do you recommend right now? >> >> >No, this is not known, and not something that I'm seeing in building >> from the staging/1.6.0 repo. Please verify the above items and let us know >> if you're still seeing it. >> >> Did you run a docker container at all? >> >> > Yes - several times in the past, and I've just finished building and > testing, again, with podman (instead of Docker), and am not seeing these > issues. Here was my process, start to finish: > > == > git clone https://github.com/apache/guacamole-server > cd guacamole-server > git checkout staging/1.6.0 > podman build . > podman image tag <image id> guacd:1.6.0 > cd .. > git clone https://github.com/apache/guacamole-client > cd guacamole-client > git checkout staging/1.6.0 > podman build . > cd .. > podman image tag <image id> guacamole:1.6.0 > podman network create guac > podman container create --network=guac --name guacdb -e POSTGRES_DB=guac > -e POSTGRES_USER=guac -e POSTGRES_PASSWORD=<REDACTED> postgres:16 > podman run --rm localhost/guacamole:1.6.0 /bin/bash > /opt/guacamole/bin/initdb.sh --postgresql | sudo podman exec -i guacdb psql > -U guac -d guac -f - > podman container create --network=guac --name guacd -e LOG_LEVEL=debug > localhost/guacd:1.6.0 > podman container create --network=guac -e LOG_LEVEL=debug -e > REMOTE_IP_VALVE_ENABLED=true -e POSTGRESQL_ENABLED=true -e > POSTGRESQL_DATABASE=guac -e POSTGRESQL_USERNAME=guac -e > POSTGRESQL_PASSWORD=<REDACTED> -e POSTGRESQL_HOSTNAME=guacdb -p 8080:8080 > localhost/guacamole:1.6.0 > == > > This resulted in a Guacamole interface at > http://guac.domain.local:8080/guacamole with a default login of > guacadmin/guacadmin. I'll re-test the process with the latest Docker > version and verify, but not seeing any issues in my environment. > > I've rebuilt and started the Guacamole containers in multiple environments: * Podman with root privileges (sudo podman commands) * Podman as unprivileged, non-root user (podman) * Docker as root user * Docker as non-root user In all of the cases I've been able to successfully build the images, create and start the containers, and log in to Guacamole, and have not been able to reproduce the errors that you've mentioned. -NIck >
