Guacamole Problem

Ich habe hier ein frisch installiertes Cuacamole (Version 0.9.13-univention14) in der aktuellen UCS Version 4.3-3 errata419, was ich nicht zum Laufen bringe.

Öffne ich Guacamole, werde ich mit:

# Proxy Error

The proxy server received an invalid response from an upstream server.
The proxy server could not handle the request *[GET /guacamole/](https://192.168.xx.x/guacamole/)* .

Reason: **Error reading from remote server**

konfrontiert. Ändere ich von https://192.168.xx.x/guacamole/ auf http://192.168.xx.x/guacamole/

komme ich zumindest in die Einstiegsmaske. Nach der Anmeldung heisst es: " Verbindungsaufbau zu Guacamole. Bitte warten…". Dann geht nichts mehr weiter …

Der Rest, wie ich eine Konfiguration anlege und einem Benutzer zuteile, wäre mir ansonsten klar. Auch hatte ich schon auf einem Ubuntu Server 18.04 ein Guacamole erfolgreich aufgesetzt. Nur hier im UCS stosse ich auf Widerstände.

Nutze zusätzlich Nextcloud - ohne Probleme.

Vielleicht hat jemand eine Idee?

Eine Idee hab ich nicht.

Aber den gleichen Fehler mit Guacamole. :no_mouth:

Habe auch Nextcloud als weitere App installiert und der UCS-Server ist Mitglied einer Windows-Domäne.

same here … installed Guacamole from the app-center and created the configuration as adviced. Result is:

Proxy Error

The proxy server received an invalid response from an upstream server.
The proxy server could not handle the request GET /guacamole/ .

Reason: Error reading from remote server

Can someone from the UCS experts have a look or advice please?

I assume Guacamole app is installed as docker.
Can you check as root on UCS server with docker ps if the Guacamole Container is running?

If not use docker logs <containerid> to check for error messages.
If that gives not relevant hint you can check with docker inspect <containerid> for mounted volumes.
Some UCS apps mount a directory for logfiles.

BR,
Jörn

thx for your quick reply.

Docker containers are up- and running (first thing i have checked):

a120fd92459a docker.software-univention.de/guacamole-guacamole:0.9.13-univention13 “/opt/guacamole/bi…” 31 minutes ago Up 18 minutes 0.0.0.0:40001->8080/tcp guacamole_guacamole_1
64269927899f docker.software-univention.de/guacamole-guacd:0.9.13-univention13 “/usr/local/sbin/g…” 31 minutes ago Up 18 minutes 4822/tcp guacamole_guacd_1

Anything else I can/should check myself?

Next thing I would check is the reverse proxy rule at /etc/apache2/sites-enabled
There should be some config regarding guacamole.

And would start looking into UCR for variables on guacamole: ucr search guac

Hi,

this is what I have found under /etc/apache2/sites-enabled:

default-ssl.conf:
ProxyPass /guacamole http://127.0.0.1:40001/guacamole retry=0
ProxyPassReverse /guacamole http://127.0.0.1:40001/guacamole

000-default.conf:
ProxyPass /guacamole/ http://127.0.0.1:40001/guacamole/ retry=0
ProxyPassReverse /guacamole/ http://127.0.0.1:40001/guacamole/

ucr search guac gives me:
appcenter/apps/guacamole/container: a120fd92459ab50a3f7ef671678b2c0533909a1f6db20d4c32c1016ef43f5233

appcenter/apps/guacamole/hostdn: cn=guaca-14076491,cn=memberserver,cn=computers,dc=xxxdomain,dc=intranet

appcenter/apps/guacamole/image: docker.software-univention.de/guacamole-guacamole:0.9.13-univention13

appcenter/apps/guacamole/ports/8080: 40001

appcenter/apps/guacamole/status: installed

appcenter/apps/guacamole/ucs: 4.3

appcenter/apps/guacamole/version: 0.9.13-univention14

guacamole/autostart: yes

ucs/web/overview/entries/service/guacamole/description/de: Guacamole ist ein clientloses fern Desktop-Gateway
Defines the description of the corresponding entry of the UCS start site (optionally localized). Full format: ucs/web/overview/entries/{admin,service}//description[/].

ucs/web/overview/entries/service/guacamole/description: Guacamole is a clientless remote desktop gateway
Defines the description of the corresponding entry of the UCS start site (optionally localized). Full format: ucs/web/overview/entries/{admin,service}//description[/].

ucs/web/overview/entries/service/guacamole/icon: /univention/js/dijit/themes/umc/icons/scalable/apps-guacamole_20180525181438.svg
Defines the URL for the icon of the corresponding entry of the UCS start site (can also be a data URL). Full format: ucs/web/overview/entries/{admin,service}//icon.

ucs/web/overview/entries/service/guacamole/label/de: Guacamole
Defines the label of the corresponding entry of the UCS start site (optionally localized). Full format: ucs/web/overview/entries/{admin,service}//label[/].

ucs/web/overview/entries/service/guacamole/label: Guacamole
Defines the label of the corresponding entry of the UCS start site (optionally localized). Full format: ucs/web/overview/entries/{admin,service}//label[/].

ucs/web/overview/entries/service/guacamole/link: /guacamole/
Defines the link URL of the corresponding entry of the UCS start site. Full format: ucs/web/overview/entries/{admin,service}//link.

ucs/web/overview/entries/service/guacamole/port_http: 80
Forces the port for URL of the corresponding entry of the UCS start site. Used when the start site is opened with HTTP or when no port_https variable is set. Full format: ucs/web/overview/entries/{admin,service}//port_http.

ucs/web/overview/entries/service/guacamole/port_https: 443
Same as ucs/web/overview/entries/.*/port_http, but used when opening the start site with HTTPS or when no port_http variable is set. Full format: ucs/web/overview/entries/{admin,service}//port_https.

Have you tried to access Guacamole on the exposed port directly without reverse proxy?

Hi,

I was now able to land on the Guacamole login-page (by using the local IP-address or local machine name): e.g. https://192.168.0.xx/guacamole/#/

Accessing the page with external IP or DNS name is still not possible.

But now I’m not able to login, neither the configured users or Administrator are accepted. All I got is a message saying “Anmeldungsfehler”.

Any logs that can be checked for the root cause?

Hi,

did a “docker logs” once more and found this in the log file:

09:51:57.936 [http-nio-8080-exec-3] ERROR o.a.g.a.ldap.LDAPConnectionService - Unable to connect to LDAP server: Connect Error
09:51:57.936 [http-nio-8080-exec-3] ERROR o.a.g.a.l.AuthenticationProviderService - Unable to bind using search DN “cn=guaca-14076491,cn=memberserver,cn=computers,dc=domainxxx,dc=intranet”

The according LDAP-object (cn=guaca-14076491,cn=memberserver,cn=computers,dc=domainxxx,dc=intranet) exists.

For me it seems the Guacamole UCS release package is pretty outdated and broken … :frowning:

Any news on this issue ?

no news :frowning:

Browsing through the forum gives me the impression, that this package is generally broken and not working for anyone - please correct me if I’m wrong …

It seems there are also issues with uninstalling the app (remaining containers).
I’m not sure how to proceed from here. At least it would be great if someone could provide instructions for “clean” uninstall.

Well, you can take a look at this post. But I’m not sure if it helps a lot. Guacamole is working as it is supposed to on a member-server while it didn’t on a slave-server.
But I can’t really tell if this has something to do with server roles or the other apps that are installed on the slave (I mentioned samba4 but perhaps the mailserver and anti-virus are even more relevant - some indications towards this can be found with a web search).

Hello lebernd, thank you for your feedback!

But I’m not sure how this can be helpful in my situation.
Like for the other official apps from the UCS appstore, my expectation was that it can be deployed easily without any further manuel adjustments or configuration. There were also nothing mentioned about excepetions (server role) or any other preconditions.

To spend further efforts for investigations/troubleshooting doesn’t makes sense for me, for the time being I’m only interested in how to do a “clean” uninstall.

Curious if you managed to get Guacamole working?? I’ve been fighting with it for three weeks off an on and I cannot get a simple RDP connection to work, SSH connections allow me to log in but returns nothing after authentication.

It seems there are way more problems posted than solutions so If it’s just not a working package I’ll remove it and find something else.

Thanks.

Hi,
Guacamole is still not working here (broken LDAP connection) and it seems nobody is able/willing to support here :frowning: I gave up already …

Hi,
I don’t know if this may help you to solve your problem, but my reverse proxy entries in the files
default-ssl.conf and 000-default.conf looks like:

    ProxyPass /guacamole/ http://127.0.0.1:40001/guacamole/ retry=0
    ProxyPassReverse /guacamole/ http://127.0.0.1:40001/guacamole/

…both entries with a / (slash) at the end

For the rest - running guacamole (0.9.13-univention14) installed from the app-center on a (standalone) UCS as Domain Master and after app install it worked (more or less) out-of-the-box.
Installed apps:

  • AD-DC
  • RADIUS
  • Guacamole
  • Software Installations-Monitor

As I’m running the whole “thing” as a VM - snapshoting while playing arround with guacamole may have saved me, because:
Once I had all up and running (inclusive adding Session-Configs in the LDAP tree “guacamole”) no connection entry worked - every try ended up in a black screen - SHIFT/STRG/ALT allows to leave the session but nothing more.
Long story short - the root problem for me, was that the docker network connector guacamole_default didn’t work as expected - removed both guacamole docker container from there and added them to the default bridge network. Everything fine since then.

Good luck

Hi @dWc,

I’m also still fighting with this docker-app and my best guess so far was that there is something wrong with the docker networking of guacamole. It installs a new bridge but I can’t ping a LDAP server (install on a member server) on the network from it so I’m wondering how a user would be able to be identified…
Long story short - can you make your short story long and give some hints/ commands on how to attach the containers to docker0? :pray:

Thanks,
Bernd

So I provide my answer…
What I did to connect the guacamole docker containers to the default docker bridge:

root@ucs-member:/var/lib# docker network connect bridge guacamole_guacd_1
root@ucs-member:/var/lib# docker network connect bridge guacamole_guacamole_1
root@ucs-member:/var/lib# docker network disconnect guacamole_default guacamole_guacd_1
root@ucs-member:/var/lib# docker network disconnect guacamole_default guacamole_guacamole_1
root@ucs-member:/var/lib# univention-app restart guacamole

So far so good. That solved the issues described in this thread.

Next problem, and probably after some reading under https://docs.docker.com/network/network-tutorial-standalone/#use-user-defined-bridge-networks one reason why there is a user-defined bridge, is the following error, when I want to use a defined connection:

root@ucs-member:/var/lib# docker logs -ft --details guacamole_guacamole_1
...
2019-03-28T21:35:37.077055728Z  22:35:37.076 [http-nio-8080-exec-6] ERROR o.a.g.s.GuacamoleHTTPTunnelServlet - HTTP tunnel request failed: java.net.UnknownHostException: guacd: Name or service not known
...

I managed to get around this by editing /etc/hosts inside the guacamole container. But I’m not sure if this solution will even survive a restart.

Guacamole is working again, but I don’t think that this is a stable solution.

At least the guacamole_default bridge needs some repair from the maintainer I guess.
In univention bugzilla you can find a bug I think is related: Multicontainer apps use arbitrary network, database access issue, possible address conflicts

Best regards,
Bernd

Hello @lebernd,
as you already mentioned, I think the point is this guacamole_default docker bridge. A docker network inspect guacamole_default didn’t show up any Options:

        "Options": {

as i.e. the default docker bridge does:
docker network inspect bridge:

        "Options": {
            "com.docker.network.bridge.default_bridge": "true",
            "com.docker.network.bridge.enable_icc": "true",
            "com.docker.network.bridge.enable_ip_masquerade": "true",
            "com.docker.network.bridge.host_binding_ipv4": "0.0.0.0",
            "com.docker.network.bridge.name": "docker0",
            "com.docker.network.driver.mtu": "1500"

in order to remove an apply them to the default docker bridge i did the following (in this order):

docker network disconnect guacamole_default guacamole_guacamole_1
docker network disconnect guacamole_default guacamole_guacd_1
docker network connect bridge guacamole_guacd_1
docker network connect bridge guacamole_guacamole_1

I never restarted any docker container from the console - for this i always used the web-ui for starting/stopping guacamole app.
I never touched the /etc/hosts file.

What works:
*Logging into Guacamole “Website” using https://ucs-server.domain/guacamole/#/ with any user (or user, member of defined AD-Group) allowed to
*Using defined connections (RDP - Domain Auth / SSH Username/Password-Auth)
What doesn’t work (actually):
*Passthrough/or SSO in Order to use defined connections WITHOUT having to define the credentials inside the ldap object (don’t know if this ever was intended - but would be pretty cool :wink:)
*Using SSH Connections with Public Key Authentication as there must be some miss-interpretation while reading the private key and/or passphrase from the ldap object (defined there as parameter private-key= and passphrase=)

Grüße und viel Glück :four_leaf_clover:

Debug-Info:
While debugging the initial problem I ended up tcpdumping on the host (ucs domain controller) and another webserver (same subnet as the DC and domain member).
The strange thing was, that even with the “broken” guacamole_default docker network in use, requests have been kind of forwarded/NATed from the host BUT on the destination host the requests shows up comming from the docker container IP (172.17.0.x). tcpdump showed all requests with checksum-errors.
As far as I understand, the requests should have been NATed on the host into the hosts IP-address.
This way no responses from the targeted server were possible, as this server doesn’t even know about the existence of the docker network (172.17.0.0).
This problem was solved (for me) by using the default docker bridge network

1 Like
Mastodon