Ovidiu Pacuraru's picture

Don't mistake the title, I don't have one, I was asking for one :-) 


Jeremy Davis's picture

But we are struggling to keep on top of maintenance as it is, so I don't anticipate that we'll be able to look at developing new appliances ourselves anytime soon.

If you want to have a crack at developing an appliance yourself then there are lots of docs I can point you to. Probably this would be a good place to start?!

Beyond that, one of our community champions; Ken Robinson (aka DocCyblade - TKL or GitHub) has been doing a fantastic job of mentoring a new community developer to create a new appliance and he may be willing to help you (and me) too? [sorry to dob you in Ken... :)]

As a complete aside, Big Blue Button is a pretty cool conference platform too. It's aimed at eLearning primarily, but IMO it's functionality lends itself as generic online conference/presentation/webinar type platform. On the downside AFAIK it still relies on Flash (for the video) and Java (for desktop sharing) so may not be ideal.

Besides, as we don't have an appliance for that either it doesn't really help you out...

Ovidiu Pacuraru's picture

thanks, I'll look into it but just starting a new job so I doubt I'll have the time to try my hand at creating an appliance myself.


had a look at big blue button, looks like a clone of openmeetings but with a "smoother" and more polished interface. on the other hand I guess all conference platforms look like clones of each other :-)

Jeremy Davis's picture

I have looked at Big Blue Button fairly closely (I actually made an appliance for it ages ago, but never got it finished and it's way too out of date now) and had little to do with OpenMeetings (although had heard of it).

From what I gather they are very similar projects albeit with a slightly different focus and use of technology under the hood. Also AFAIK they started around the same time and are somewhat in competition with one another. So I'm sure that they've robbed feature ideas from one another over the years as many competing open source projects do.

Anyway, if you do find yourself with the time and the energy to have a crack let us know. And in the meantime someone else may come along and have a go at it.

Christian's picture

Given the current situation, there is a huge demand for open source videoconferencing. Is there a chance this could be made a priority?

Jeremy Davis's picture

Yes, I'd love to make it a priority. If things were different right now I would. Unfortunately though, we're currently doing a TurnKey major version update, so I'm not sure when we'll be able to get to it.

But as noted in the blog post, we have published an updated TKLDev release (there are currently no noted bugs against RC2, but the docs are in need of some love...). So, if you're up for it, please feel free to help out with development. All you need really is a bit of time, some patience and some fairly basic Linux and bash knowledge.

Actually, I'm getting ahead of myself. Even just researching on which particular videoconferencing solution might be the best to implement would be the place to start... We could potentially have multiple ones in the future, but ideally we should focus on the best one we can find initially. It seems that things have changed a little since this thread was first started. Whilst I think OpenMeetings will be a good option in the future, from what I can gather, the stable version (v4) still uses flash in the browser, whereas the development version uses WebRTC. So I'm not sure that's the best option at this point. I'm not sure where Big Blue Button is up to, but that may be a good option? Actually, Jitsi Meet might be the one to go for? It looks pretty easy to install on Debian too (the basis of TurnKey, so perhaps worth trying on Core?!). They appear to be running a free hosted service currently, so you could even give it a try?!

So if you want to have a go at developing an appliance (or at least starting one), just installing on (v16.0rc1) Core is a good start. Obviously if you don't diverge from the install docs (linked above for Jitsi) whilst installing, then there isn't really anything further to do (other than develop the build code). But be sure to carefully document any additional details or diversions required beyond any install docs. Once you get to that that point, if you wish to develop an appliance, then please download TKLDev and have a look at the docs (links above). If you need some coaching or pointers, please ask...

Christian's picture

Hi Jeremy,

much appreciated, but unfortunately I won't be able to help right now (too much invested in another Open Source project).

You are right, though, that OpenMeetings might not be the best choice. Jitsi Meet looks great ...  I hope we can find somebody who can donate the time, since a TKL appliance would be great for people who cannot use Docker images in their environment.


Jeremy Davis's picture

No worries. We'll see what we can do...

Jeremy Davis's picture

In a comment on the GitHub issue Tomas noted:

I'd like to comment that the NextCloud appliance already includes videoconferencing in the NextCloud Talk function, which is enabled by default. I had some good experience with it and some bad, due to the fact that it relies on a WebRTC connection directly between the endpoint browsers. It should be possible to make in more reliable by installing a TURN server (coturn), which I want to try doing in the near future.

So in the meantime, that could be worth a look?!

Gary's picture


Just a quick "heads up" to anyone who is working to build a server intended to host "Jitsi Meet" (https://jitsi.org/jitsi-meet/).

We have successfully built one, using v.16 of Core (Debian Buster) as our basis.  We found out that Jitsi Meet requires UDP port 10000 to be available to it, otherwise no video of the meeting participants can be seen and no audio of the meeting participants can be heard.  This leads to a conflict with Webmin, which also uses UDP port 10000; you will need to either stop and permanently shut down Webmin or instruct it not to use UDP port 10000.

Jeremy Davis's picture

Did you by any chance take any notes when you did that? If so could you share them? Perhaps they might make the basis of new TurnKey appliance build code?!

FWIW I have done some brief investigations myself and I did notice that port clash myself. FTR Webmin uses port 10000 for locahost TCP traffic only; not UDP - but that's somewhat irrelevant as your point on the port clash still stands.

I did find info about changing Jitsi's usage of that particular port (and use an alternate one) if need be. Because the port number is explicitly provided to the client by the server and it's UDP (i.e. broadcast) traffic, that shouldn't affect operations.

Although seeing as TurnKey actually doesn't provide Webmin publicly via port 10000 (it's bound to localhost:10000; it's reverse proxied by stunnel on port 12321) we could tweak that and most end users would not notice.

So I'm not really sure which should be tweaked to use an alternate port. My guess is that tweaking Webmin internally would probably have less impact on most end users. And it seems much more likely that users might hit issues with Jitsi and google for solutions (which would all talk about default ports - i.e. port 10000) it makes sense to leave that as per Jitsi default.

Do you have any thoughts?

Also, was there any other special tweaks that you needed to make to get it working properly?
Gary's picture

Hi, Jeremy,

I have to say that I never thought about somehow making Jitsi Meet, instead of Webmin, use a different UDP port, probably because I am more familiar with the Core appliance and therefore knew for certain that I could make Webmin, rather than Jitsi Meet, use a different UDP port.  I think I agree with you, though, for all the reasons you stated, that it would probably be best to make Webmin accomodate Jitsi Meet (i.e. tell Webmin to not use UDP port 10000), rather than make Jitsi Meet accomodate Webmin.

The line in Jitsi Meet's logs which gave me the key to the problem was "Failed to create SinglePortUdpHarvester for address java.net.BindException: Address already in use (Bind failed)"

"lsof -i :10000" told me this:
miniserv.  2632     root    5u  IPv4  19458      0t0  TCP localhost:webmin (LISTEN)
miniserv.  2632     root    6u  IPv4  19459      0t0  UDP *:10000

"netstat -tunlp | grep :10000" told me this:
tcp        0      0*               LISTEN      2632/perl           
udp        0      0 *                           2632/perl           

Then, I issued the command "sh webmin stop" while in /etc/init.d/, and issued the command "systemctl disable webmin.service".  On reboot, neither the previously mentioned lsof command nor the previously mentioned netstat command reported anything at all, meaning that Webmin was successfully stopped.  Then, I established a meeting in Jitsi Meet.

"lsof -i :10000" then told me this:
java    547  jvb  140u  IPv6  17715      0t0  UDP

"netstat -tunlp | grep :10000" then told me this:
udp6       0      0       :::*                                547/java

...and, lo and behold, we then had video and audio for all meeting participants.

Since we built our server, Jitsi Meet has changed their Quick Installation instructions (https://jitsi.github.io/handbook/docs/devops-guide/devops-guide-quickstart), but, from what I remember, and according to my notes, I:

- did not execute the "Set up the Fully Qualified Domain Name (FQDN)" instructions, even though we are indeed using a fully-qualified domain name for the server

- used "wget -qO https://download.jitsi.org/jitsi-key.gpg.key | apt-key add -" instead of "curl..." to add Jitsi Meet's repository key

- used nano to create /etc/apt/sources.list.d/jitsi-stable.list, and typed in just "deb https://download.jitsi.org stable/"

- installed "apt-transport-https" just before installing "jitsi-meet", instead of installing it before adding Jitsi Meet's repository key and creating /etc/apt/sources.list.d/jitsi-stable.list

- created, using Webmin instead of ufw, firewall rules for UDP port 10000:20000 and TCP port 4443 which were identical in nature to the already-created rule for TCP port 80.  I can't recall if Webmin already had a firewall rule set up for port 22.

- chose "Generate a new self-signed certificate" and executed /usr/share/jitsi-meet/scripts/install-letsencrypt-cert.sh

- did alter /etc/jitsi/videobridge/sip-communicator.properties as discussed in "Advanced configuration", since we are indeed behind a NAT

- did not execute "If the installation is behind a proxying nginx server..."

Jitsi Meet installed and configured Nginx itself, and we haven't installed and worked with Jigasi yet.

Jeremy Davis's picture

Thanks for sharing that info. That's great!

Personally I don't use Webmin much, but if you, or anyone else following your lead wants Webmin to work again, this should do the trick:

Change the Webmin internal port, OTTOMH is should be within /etc/webmin/miniserv.conf (or similar). Search for any/every mention of 10000 and change it to the new port, e.g. 9999.

Also update the port within Stunnel; from 10000 to the new port (e.g. 9999). In v15.x and earlier, the file was /etc/stunnel/stunnel.conf; in v16.x (and forwards I anticipate) it changed to /etc/stunnel/webmin.conf for Webmin (and /etc/stunnel/shellinabox.conf for shellinabox/Webshell).

Then restart both Webmin and Stunnel. Re Stunnel, in v15.x and earlier, it's simply 'stunnel4'; n v16.0+ it's changed to 'stunnel4@webmin'. Webmin should now still work as per usual - on external port 12321.

In your specific scenario Gary, obviously you'd also need to re-enable Webmin to auto start on reboot.

Add new comment