Taddeusz

My Docker is already updated to Apache Guacamole 0.9.14. Are you sure you're using jasonbean/guacamole?

I honestly have no idea. I just created the template for the official Mongo Docker. You can try the instructions for the docker here: https://hub.docker.com/_/mongo/

I'v done the same. It is quite a bit better designed as well as MUCH smaller.

Even after setting USE_UI to "yes" it won't run complaining that XDG_RUNTIME_DIR is not set and keeps trying to execute it because it's being run as a service. Again, I have to call this as I see it. I have the distinct feeling that this feature wasn't fully tested before it was rolled out. I think he confirmed that it wouldn't run but didn't test if it WOULD run. This last update needs to be rolled back until it can be made to work.

Sorry, I have to call this as I see it. I found the problem. The /etc/service/handbrake-ui/run script is horrible. It unrecoverably deletes itself if USE_UI is not set specifically to "yes". There is no other facility to recreate the /etc/service/handbrake-ui/run script if USE_UI is set to anything else, including "true". It must be set to "yes" for this to work and if you ever decide to to set it to anything else you must totally remove and reinstall the container to get the GUI back.

I went and looked at the Dockerfile for the image. I see where it copies startapp.sh to /etc/service/handbrake-ui/run. Howerver, I bashed into my running container and neither the folder nor the run script are there: root@5d2a9773973b:/etc/service# ls cron guacd monitor openbox syslog-forwarder syslog-ng tomcat7 xrdp xrdp-sesman Xvnc root@5d2a9773973b:/etc/service#

I totally removed and reinstalled the HandBrake container. I'm still not getting the GUI. In the log I see these runsv messages in the saying that "./run" doesn't exist: runsv handbrake-ui: warning: unable to open supervise/pid.new: file does not exist runsv handbrake-ui: warning: unable to open supervise/pid.new: file does not exist runsv handbrake-ui: fatal: unable to start ./run: file does not exist runsv handbrake-ui: warning: unable to open supervise/pid.new: file does not exist 08:13:33.082 [localhost-startStop-1] INFO o.g.g.n.b.w.t.WebSocketTunnelModule - Loading Tomcat 7 WebSocket support... shutting down signal 15 threadid 0x1471559b1740 Xlib: extension "XInputExtension" missing on display ":1". Xlib: extension "XInputExtension" missing on display ":1". ok: down: guacd: 0s, normally up Feb 7 08:13:33 5d2a9773973b sesman[76]: [INFO ] shutting down sesman 1 Feb 7 08:13:33 5d2a9773973b sesman[76]: [CORE ] shutting down log subsystem... ok: down: tomcat7: 0s, normally up ok: down: xrdp: 0s, normally up ok: down: xrdp-sesman: 0s, normally up ok: down: openbox: 0s, normally up runsv handbrake-ui: warning: unable to open supervise/pid.new: file does not exist runsv handbrake-ui: warning: unable to open supervise/pid.new: file does not exist runsv handbrake-ui: fatal: unable to start ./run: file does not exist runsv handbrake-ui: warning: unable to open supervise/pid.new: file does not exist runsv handbrake-ui: warning: unable to open supervise/pid.new: file does not exist runsv handbrake-ui: warning: unable to open supervise/pid.new: file does not exist runsv handbrake-ui: warning: unable to open supervise/pid.new: file does not exist runsv handbrake-ui: warning: unable to open supervise/pid.new: file does not exist

Ok, for some reason I thought this was supposed to be a variable in the Docker template. I put this in my config file and still nothing. Still get a black screen.

This is the same thing that's happening for me. But USE_UI isn't working.

I just got the upgrade to this Docker. I've set USE_UI to "true" and to "yes" and the GUI still isn't running. With it set to "yes" I'm getting the following errors in my log: [Feb 05 08:16:07 AM] Running HandBrake GUI error: XDG_RUNTIME_DIR not set in the environment. ** (ghb:627): WARNING **: main: Cannot open display: error: XDG_RUNTIME_DIR not set in the environment. (ghb:627): Gtk-WARNING **: cannot open display:

Interesting. I'm glad I could help you get it working. If you don't mind could you post a sanitized version of your guacamole.properties file? I can test for this myself. What is your LDAP source? I once used LDAP through Windows Active Directory but I had some hardware failure on my domain controller so I decided to just use the built-in MySQL.

The only thing I can think to do is remove the container and reinstall using your "my" template. Oh, BTW, the failed message always shows in the Docker log. I don't know why. It always says that but seems to work fine. If you really can't load the login screen there's something else going on. If the page loads but is just a white screen it has to do with database access problems. Could be extensions or libraries in that case. If that is the problem you might post your catalina.out file.

Try stopping your Guacamole container and then browse to your config folder. Go to the guacamole extensions folder and delete all the jar files. Then go to the lib folder and also delete all the jar files. Finally restart the container. It will copy the needed extensions and library files when it starts. I'll need to put better logic in for the library files.

I just received an update today and it's saying that the key has expired and the program version is out of date and it quit. Not sure if it's related to the update but I realize the key expires today and a new one hasn't been posted yet.

I noticed that too when it initially did the database upgrade but no errors upon future restarts of the container.

What does the Docker log say? It should have a line something like this: guacd[63]: INFO: Guacamole proxy daemon (guacd) version 0.9.14 started I've noticed that the login screen is not always accurate. I'm not sure why but always right after upgrading the version in the lower right of the window always says the old version. I think it has to do with the browser cache. After a bit it starts showing the correct version number.

BTW, if, for whatever reason, you choose not to upgrade or wish to downgrade you may use the tag ":0.9.13". Unfortunately, my build process wasn't established well enough until after I had created the 0.9.13 version so that is the oldest image available. The 0.9.13 image is updated so that it can detect a downgrade and will not attempt to "upgrade" the database in that case.

Ok, the update is in. This was a huge change for me. I learned about multi-stage Docker builds and converted this project to one. The result is a slight 32MB reduction in size for the image. Unfortunately due to the dependencies for Tomcat and the Guacamole server itself, guacd, this image can't be reduced in size by any more. I may play with switching to a different base container for further reductions but don't hold your breath waiting. Microsoft SQL Server support is included. However, IMHO, it should be not be considered ready for production. I'll say it works when it works but for whatever reason the database is easily corrupted. I had to re-create the database a couple times during testing and I eventually just gave up and focused on other areas. Supporting SQL Server is going to me a manual process just like LDAP. Since SQL Server credentials are required I don't want to be responsible for handling those. If you desire using SQL Server it is up to you to manually create and in the future upgrade the database. I tried to figure out how to make this more hands-off but the liability is just too high. All that said, have at it!

It appears that Guacamole has left the Apache Incubator stage and has been accepted as a full blown Apache project. Version 0.9.14 has been released. Neither of these affect me personally but the most notable changes are support for OpenID and, surprising to me, Microsoft SQL Server support. In the coming week or so I'll be working on upgrading this docker and adding support for the new plugins. I will try and test support for SQL Server to ensure it is working. At this point I'm unsure how involved SQL Support will be for this docker. However, I will try and make it as easy as the built-in MySQL. If any of these features interest you please be patient. This new version may take some time to integrate.

I'm sorry to hear about your problems. If you need further help more detailed logs will be required to determine what is going on.

Do you have the OPT_MYSQL set to "Y"?

This is true if you are on a provider that doesn't already have a supported API. If you look at the instructions for the acme.sh script to use the automated DNS validation you run it with the --dns <apiscript> parameter and select which api you wish to use (this can easily be a template variable). Prior to running the script, each supported provider API script has environment variables that must be set. All of this could easily be scripted. In the case of supported API's the user would just need to add the required environment variables to their Docker tempate. That's exactly what I did to get mine validated and working with regular nginx container. I don't understand why it's so impossible. It's just not as plug and play and requires the user to look at the acme.sh script's documentation to figure out which api to select and which environment variables they need to add to their docker template. I do understand that from a support perspective it would be more of a burden because it's easier to get wrong. However, the alternative for many people whose ISP's block port 80 DNS validation is the only reasonable option. If I had the time I would be willing to do the modification and do a pull request myself but my time is limited.

Thank you for the short pointer. I have it working. Not automatically, but I'll see how this goes when it comes time for renewal. The way their DNS API integration is written I don't think it would be too difficult to implement. As long as the user has a supported API all the user should need to do is specify which API they want to use and add the required variables to the Docker template.

Since this seems to be the new reality and my ISP blocks port 80 how do I go about implementing this script with unRAID and the regular nginx container?

Welcome to the 21st century.