Guacamole Problem

Apps & App Center
,
#41

Moin @lebernd,

my thoughts as follows:
He is

  • able to access the UCS-Host (and other services such OwnCloud…) from local network
  • able to access the UCS-Host (and other services such OwnCloud…) from remote network(s)
  • able to access the Guacamole App from local network

He is not

  • able to access the Guacamole App from remote network(s)

The other web-apps (OC,Collabora,…) and the usage of the UCS-WebU won’t require any ReverseProxying - that’s why I evaluated it differently.
now, he maybe check the remote-connectivity of the guacamole app by using the native URI and Port ( http://your-public.dns:40001/guacamole/).
If this works, then I would say the only difference would be the ReverseProxy * thing*

Best regards

#42

That is not true - at least for wordpress. I don’t run owncloud but I think it is dockerized too and uses a proxy config too.

#43

Hello dWc,
Hello lebernd,

I opend port 40001 on the router/FW and a did a connection test to external IP/Hostname (http://public.dns:40001/guacamole/ - This is working, wow :slight_smile:
This is working for http only - https gives me a “ERR_CONNECTION_CLOSED” and is not working at all (yet).

apachectl -M | grep proxy gives me:
proxy_module (shared)
proxy_connect_module (shared)
proxy_http_module (shared)
proxy_wstunnel_module (shared)

apachectl -M | grep headers gives me:
headers_module (shared)

apachectl -M | grep rewrite gives me:
rewrite_module (shared)

@lebernd: Ping to public DNS name works from insides Guacamole-shell.

This my config for the reverseproxy:

000-default.conf:

<VirtualHost *:80>
	IncludeOptional /etc/apache2/ucs-sites.conf.d/*.conf

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

	ProxyPass /owncloud http://127.0.0.1:40007/owncloud retry=0
	ProxyPassReverse /owncloud http://127.0.0.1:40007/owncloud

	ProxyPass /wordpress http://127.0.0.1:40002/wordpress retry=0
	ProxyPassReverse /wordpress http://127.0.0.1:40002/wordpress

</VirtualHost>

default-ssl.conf:

<VirtualHost *:443>
	IncludeOptional /etc/apache2/ucs-sites.conf.d/*.conf
	SSLEngine on
	SSLProxyEngine on
	SSLProxyCheckPeerCN off
	SSLProxyCheckPeerName off
	SSLProxyCheckPeerExpire off
	SSLCertificateFile /etc/univention/letsencrypt/signed_chain.crt
	SSLCertificateKeyFile /etc/univention/letsencrypt/domain.key
	SSLCACertificateFile /etc/univention/ssl/ucsCA/CAcert.pem
	SSLCertificateChainFile /etc/univention/letsencrypt/intermediate.pem

	#SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown

	### To enable special log format for HTTPS-access
	# LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-agent}i\" %p" combinedssl
	# CustomLog /var/log/apache2/access.log combinedssl	## with port number

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

	ProxyPass /owncloud http://127.0.0.1:40007/owncloud retry=0
	ProxyPassReverse /owncloud http://127.0.0.1:40007/owncloud

	ProxyPass /wordpress https://127.0.0.1:40003/wordpress retry=0
	ProxyPassReverse /wordpress https://127.0.0.1:40003/wordpress

</VirtualHost>

Best regards
Thomas

#44

Hello @lebernd ,

in that case I’m sorry for my wrong posting. I don’t use one of those additional apps, so I couldn’t check it for myself but you’re right - there’s even a ReverseProxy config entry for the UCS-Portal.

Sorry for miss-information :sob:

#45

looking good in my opinion.

#46

Hello @tpfann,

after first sight, a difference in your configs are the presence or missing of a trailing slash (differnce between i.e. owncloud and guacamole config entry) .

That it works only in HTTP (over this port) is normal as the server your (now) talking to directly - is plain HTTP.
This is a reason for reverse proxying services (in general - in this case the usage of a or multiple dockerized app/s on a single port may be another good reason). The HTTPS connections should end on the Proxy (Apache), which handles the further communication with the guacamole-service in HTTP.

Best regards

#47

Last thoughts for today: perhaps time to call apache :grinning:

You find some posts regarding your error message searching the web.

 [proxy_http:error] [pid 16890] (103)Software caused connection abort: [client 80.187.85.226:17071] AH01102: error reading status line from remote server 127.0.0.1:40001

I found this post interesting: https://serverfault.com/questions/206738/intermittent-error-when-using-mod-proxy-to-do-reverse-proxy-to-soap-service

I would try the solution posted there - but this really is just trying something.

#48

Hello lebernd,
thx for the link and your support. I have tried the tips from the post but without any success :frowning:

Best regards
Thomas

#49

Found the root cause :slight_smile:

Besides default-ssl.conf and 000-default.conf there is another relevant conf file under /etc/apache2/sites-enabled. For the handling of my public DNS names the relevant file is univention-letsencrypt.conf.

After correcting the corresponding entrys for Guacamole (changed https to http), everything is working now.

dWc and lebernd thx alot one more time for your support!

Best regards
Thomas

#50

Hey,

just as an explanation: univention-app shell … is a wrapper around calling docker exec … -ti /bin/bash with the ID belonging to the app’s container. That ID in turn is stored in the UCR variable appcenter/apps/…/container.

If you ever want to run something within an app’s Docker container, I highly recommend univention-app shell … over manually looking up the container name/ID — especially as container names aren’t stable; they can and do change between installations.

#51

Keep in mind that your modifications to the files in /etc/apache2/sites-available will be overwritten each time the file is recreated from its template. That’s what the scary-looking text at the front of the file tries to tell you.

A slightly better way to go about things is to modify the template the file is generated from, /etc/univention/templates/files/etc/apache2/sites-available/univention-letsencrypt.conf, and then to re-generate the file with ucr commit /etc/apache2/sites-available/univention-letsencrypt.conf. That way you only have to keep up to date with changes to the template itself, which shouldn’t happen too often (check by running univention-check-templates after each update). Due to how the templates generates the entries, this isn’t as straight-forward as one might like, though.

The best option would be to file a bug for this problem. Each app declares how the web server inside the Docker container can be reached (unencrypted only = HTTP, encrypted only = HTTPS or both), and the Let’s Encrypt template uses that information in order to create its reverse proxy entry. That information seems to be wrong for Guacamole.

#52

Hi Moritz,

thanks for the hint - I will update the template accordingly as well.
As recommend, I have opened a ticket for this: 49243

Mastodon