Guacamole Problem

dWc · April 7, 2019, 9:35am

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

lebernd · April 7, 2019, 9:38am

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.

tpfann · April 7, 2019, 9:49am

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

dWc · April 7, 2019, 9:59am

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

lebernd · April 7, 2019, 10:07am

looking good in my opinion.

dWc · April 7, 2019, 10:11am

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

lebernd · April 7, 2019, 10:34am

Last thoughts for today: perhaps time to call apache

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.

tpfann · April 7, 2019, 11:27am

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

Best regards
Thomas

tpfann · April 7, 2019, 12:17pm

Found the root cause

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

Moritz_Bunkus · April 8, 2019, 7:13am

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.

Moritz_Bunkus · April 8, 2019, 7:30am

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.

tpfann · April 8, 2019, 8:39am

Hi Moritz,

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