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. -Nick
