Hi All,

Just to follow up on this and for the benefit of others having the same issue, I have now successfully worked around the problem.

Printing does not work (for me, at least) when using guacamole via an Apache reverse proxy *in HTTP mode*. I am not sure if this counts as a bug - since everything else i.e. normal interactive use of guacamole RDP/VNC/SSH/etc. sessions work fine in this configuration - but here are the two steps I took to resolve:

- Install Apache's mod_proxy_wstunnel (on Debian this is 'sudo a2enmod proxy_wstunnel')
- Add a line in Apache's config to websocket-proxy the relevant URL. Note that this line must come *before* the config entry that proxies the rest of guacamole, since Apache's ProxyPass command operates on a first match wins basis.

(I did look at Chapter 4 of the documentation, and in particular the 'Proxying with websocket' section, but I found I did not need the ProxyPassReverse statement shown there; nor did I need to place it within a <Location> section, in my config at least.)

My Apache config now looks like this:

        ProxyPass /remoteaccess/websocket-tunnel        ws://docker.host:5678/guacamole/websocket-tunnel

        ProxyPass /remoteaccess/                        http://docker.host:5678/guacamole/

and printing now works perfectly.

Mike/team - is this a bug? (Printing works via websocket but not via http) and if so, is there a bug tracker I should report this to? Happy to do some more digging/testing, if this isn't reproducible elsewhere.

Thanks - and season's greetings to all!



On 22 December 2017 at 08:05, Jonathan Hunter <jmhunter1@gmail.com> wrote:
Thanks Mike, that helps!

I do indeed have ghostscript installed, and the /usr/bin/gs binary does exist, in the guacd image, which is great.

I've just tried it again (printed a simple Notepad document saying 'hello'). It seems to take a long time to think about whatever it is doing, since the web browser window does indicate at the bottom that something is happening, but then gives up / times out.

What actually happens after I press 'Print' on the Windows machine (I am connecting to it via RDP) is that guacd says:

guacd[949]: INFO:       Print job created

guacd[949]: INFO:       Created PDF filter process PID=958

guacd[958]: INFO:       Running gs

and the web browser I am using (Chrome on Mac) flashes up "Waiting for www.myurl.com" at the bottom of the browser window a few times - but then nothing else happens. No further log items come up. (I am using 'docker logs -f guacd' to view these)

Are there any built-in hooks to turn up debugging levels etc. in guacd when using it via docker, or should I do my normal mechanism of running /bin/sh in the docker container and running strace -f ?

I wonder if it might be related to my use of Apache as a reverse proxy in front of the docker container; but that works fine for normal interactive use of guacamole, I've not had a problem yet. The Apache config is pretty much just:

        ProxyPass /remoteaccess/        http://docker.host:5678/guacamole/

but perhaps this interfers with printing somehow.

Update - I have tried connecting direct to the docker image (I needed to find a plugin for Chrome to set the REMOTE_USER header as I am using HTTP authentication on my reverse proxy) and printing *does* work perfectly this way. So, it is not guacd, but rather something to do with my use of Apache as a reverse proxy.

Going direct instead of via Apache, I get the following in guacd logs:

guacd[993]: INFO:       Print job created

guacd[993]: INFO:       Created PDF filter process PID=1002

guacd[1002]: INFO:      Running gs

guacd[993]: INFO:       Print job closed

guacd[993]: INFO:       Ignoring printer cached configuration data

Any pointers appreciated..

Many thanks :)


On 21 December 2017 at 01:31, Mike Jumper <mike.jumper@guac-dev.org> wrote:
On Dec 20, 2017 17:26, "Jonathan Hunter" <jmhunter1@gmail.com> wrote:

The following command returns nothing for me:

# docker exec -it guacamole find / -type f -name gs

Am I barking up the wrong tree here?

Yep. You need to bark up the guacd tree instead. ;)

It's not the guacamole image which needs GhostScript, but the guacd image. It should be there, though. It's installed as part of the image build:

- Mike

"If we knew what it was we were doing, it would not be called research, would it?"
      - Albert Einstein

"If we knew what it was we were doing, it would not be called research, would it?"
      - Albert Einstein