I’m working in a managed services setup and we’re using Thinlinc as our go-to Remote Linux Desktop for the management servers we have installed in our own environment, as well as our customer sites (where needed).
I’m wondering if this is a thing that’s been requested or even considered. I think companies like ours (and I’ve seen similar questions regarding the use of the 10 free community licenses in a large scale company/government) could benefit greatly from a “Thinlinc License Server (it’s funny, cause it spells TLS )”, where we could add a bunch of licenses (say 20, one for each member of the team and some spares in case a customer itself also uses the Thinlinc server) and those would be available for all non directly connected TL servers under our management.
So the usecase is, say we have a team of 5 people and 5 sites, we could install 1 license on each site, which would break in case 1 site needs 2 engineers to fix a problem. We’d need to remove the license from a different site etc. etc. etc.
Whereas, if we would have a centralised license server that could be reached by those 5 sites, we could upload the 5 licenses there and have the “session” servers ‘borrow/checkout’ them when and where they are needed.
This is something which has definitely been considered. For reference, here’s the relevant Bugzilla entry:
Historically, there have been a few reasons for not using a license server, such as ensuring continuity of service (i.e. what happens if the license server becomes unreachable?) and security (would require the ThinLinc server to make automated outbound connections, which isn’t always permitted). However, I think the way in which people use ThinLinc has changed, and the benefits of a license server probably outweigh the downsides now.
So in short: yes, this is something which is on our radar at least, and I agree with you that it would definitely be nice to have, especially in a managed services type of situation. Unfortunately though, it’s not something we have available at present.
If there’s anything we can do to make things easier for you from a purely administrative perspective, though - for example, splitting the licenses up in a specific way - please don’t hesitate to let us know and we’ll see what we can do.
Thanks for the reply! From my perspective, I could probably help sketch out what would be useful for an administrator in order to debug this stuff when the license server is unreachable.
When the server is unavailable: Instead of the current warning ‘unable to allocate’ something along the lines of ‘unable to connect to license server’. And perhaps allow the TL “client” servers themselves to always allow 1 user from a pre-defined administator group (like wheel) to log in. So in case when the server is offline, an (1) admin can still log in to fix it.
But OTOH, if you can reach it via TL, that also means you can reach it via SSH, but I’m guessing a single-seat ephemeral license could be more convenient.
Outbound connections are a given, yes, but I think if you could use a license software with a REST API that issues temporary (sub)-licenses with a limited lifetime, let’s say max 24 hours, that’d be the most flexible with allowing connections. Because it can also be handled by an HTTP proxy.
For the licenses themselves, I don’t think the client/user should see any of this. I’d opt to ‘task’ the server with maintaining enough leases for all it’s sessions instead of tying the licenses to the sessions themselves (basically if sessions >= licenses; then request_or_renew). And if there’s logging for this in journal logging or a command that can print a JSON, that’d enough of a data source for admins to add monitoring etc.
For now, we don’t really have an issue, as we use most licenses, but I do know it would be something we could use in the future. Until then we’re happily contacting support if we need any additional splits
)”, where we could add a bunch of licenses (say 20, one for each member of the team and some spares in case a customer itself also uses the Thinlinc server) and those would be available for all non directly connected TL servers under our management.