Jeremy S's picture

I built a Guacamole 9.1 appliance for my own use, and wanted to share it with you guys. I didn't have time to figure out TKLPatch, so I exported a VMWare appliance. Guacamole is a self-hosted web based RDP/VNC/Telnet/SSH solution. No longer will you need a client program to remote into other VMs or physical boxes.


I hope that somebody finds it useful.

Jeremy Davis's picture

Did you document the steps required to install? If so then could you please post them?

Then someone else could create the build code. Also FWIW whilst TKLPatch I still available and useful, we are more focused on creating code for TKLDev now as that's what is already used to create the TurnKey Appliances.

For reference, all the code for the existing appliance library is on GitHub here, as are the TKLDev docs.

Björn Berglund's picture

Hello Jeremy

In case this is still interesting I posted the documentation below.


Jeremy Davis's picture

I saw and I hope you don't mind, but I tidied up the formatting a little (you weren't logged in when you posted it and "guest" posts lose much of their formatting).

I've also just tweaked your user account so when you are logged in, you should be able to avoid all the spam traps now too! :)

Thanks again.

Jeremy Davis's picture

And it looks cool! :)

I also noticed that it is available from the Debian repos too but it's quite an old version (v0.6.0) and it looks like there have been a lot of improvements between then and the current version (0.9.1 which I assume is what you meant...).

Jeremy S's picture

Yes, I meant 0.9.1. I should have paid more careful attention to the version numbering. I didn't document the install, but I could. Where could I learn to build the appliance myself with TKLDev? I had a little trouble following the documentation, but I have a computer science degree, and I do Linux administration, so I'd love to be able to figure it out. If I can't, where should I send the writeup? (I'd have to go back and do it, but I believe so firmly in both Turnkey and Guacamole that I'd be willing to do that.)

Jeremy Davis's picture

My suggestion is to read through all the TKLDev docs, but particularly the development docs right through (if you haven't already) and download yourself a copy and setup in a VM. There are a few steps you need to do before you can start.

As described in the docs, basically you start with your base appliance (fork it from the closest starting point on GitHub - you'll need a GitHub account). If you're not familiar with GitHub and gitflow then this is worth a read.

You'll want to follow the steps for creating a new appliance but it may also be useful to read through the maintenance docs.

Personally I found it really useful to also have a look at other appliance build code to get an idea of how it's done in practice. Essentially, any packages that can be installed with apt-get go straight in the plan, any files you want to overlay go in the overlay directory (e.g. if you wanted to put a conf file to go to /etc/foo/conf then it goes in overlay/etc/foo/conf) and your build script(s) go in conf.d. As a general rule it's best to put downloads in a separate conf file, then install code in another. If the set up is particularly complex then you can further break it down. The conf scripts are processed in order so if you have multiple ones then prefix them with a number (i.e. the order you want them to be processed in). E.g. 00foo, 10bar, 30etc

Feel free to ask here - it's your thread! :) - and if there is anything that you think could be described better in the docs, then please let us know and we'll tweak them. Or if you know what needs to change, then feel free to fork the docs and issue a pull request.

Liraz Siri's picture

The problem with a VMDK image is that it's not reproducible. TKLDev source code is. And when a new version of Debian comes out we can just rebuild the app and it will most likely work with little maintenance. Just a bit of testing.

Jeremy S's picture

Like I said in the original post, I made it for myself because I needed a few instances of it on a couple of servers in my infrastructure, and liked that Turnkey Core updates itself with Security Updates. Was it inappropriate to share it here?

Liraz Siri's picture

Sharing is always appropriate. Getting an image that works is a win.

It's just that there are hidden gotchas to distributing VMDK images such as having the same secret keys/credentials embedded in it because you don't go through the normal initialization process. That's another reason TKLDev source is preferable. That and we can actually import that into TurnKey.

An easy way to take the next step would be to just use TKLBAM to get more visibility into what changes you made relative to Core:

tklbam-backup --dump=/tmp/backup

You can then have a look inside /tmp/backup and take out the non-essentials. You can test that it works by copying /tmp/backup to a clean Core install and then do this:

tklbam-restore /tmp/copy-of-backup
Jeremy Davis's picture

And it still seems to be valid to me (or perhaps Jeremy reuploaded it or updated the link...?)

Jeremy Davis's picture

I only checked that the link was valid, I didn't check that it was actually the full image... Sorry about that.

Jeremy S's picture

He's right, the link is down. There's an entirely new release of Guacamole though (.9.2). Jeremy, if I document the steps for installation would someone else be able to build a real Appliance? I tried, and had a lot of trouble figuring it out.

Jeremy Davis's picture

If you can provide build docs, then that would be a great first step. I'd be more than happy to provide some support on building the appliance if you wanted to have a crack at TKLDev. But even if that feel like too much, post your build docs and we can go from there.

And thanks again for contributing to TurnKey! :)

Pascal d'Hermilly's picture

Was an app build?

Jeremy Davis's picture

See links above. But we are waiting for him to give us some more. I really hope that this ends up as an official appliance! :)

Jeremy Davis's picture

But it seems that no one has really picked up the development of this. So at this stage the time between now and an official TurnKey release is about the length of a piece of string...!

Unfortunately we are way behind on where we'd like to be. For example the v13.1 maintenance release is long overdue... So as a dev team we are stretched to our limit. We have a list of appliance requests a mile long which we will never get through unless the community can step up and help out.

Having said that though, we still really appreciate any input from anyone, even if it is just asking for an ETA. At least then we can build a picture of which appliances are most desired, so eventually when we do get it, we'll know best what to focus on...

Björn Berglund's picture


I've made a few more runs on the instruction on request and found that not only human mind by also mine :-) is susceptible to influence when I'm not avare of it.

The site's I've gone through to write the instruction often had an instruction that lead me to believe any username and password would do fine. And also some places it was listed tthat there was a default username guacadmin and guacadmin.

So when doing my tests this is what I used...

Now I've come to the realisation that hard coded somewhere there is hidden a must to keep those. 

So if you follow the above and want it to work...

...add guacadmin both as username and password.



Add new comment