delete wrong member

[AT-jam]

Is there a way, if the wrong participant logs into a private-server-meeting, to kick him out again?

[ann0see]

Yes, kind of but not in the official version. You can of course block clients via your firewall, mute him or use the code from the eduTools branch on this repository. Unfortunately I don’t see a big chance (yet) that this will be part of the official version.

[AT-jam]

That's a shame, I was hoping that at least one could simply right-click on the server side, for example, to disconnect a connection. Shouldn't be that difficult to implement. I still hope for an official solution ...

[ann0see]

Yes, probably it isn’t difficult to "kick" a user. But this involves a few open questions:

1. What if the user simply reconnects (is this a problem? Personally I would say yes)
2. How can we handle it securely for headless servers
3. How do we ensure that only private not public servers have this feature (which could be abused)

[AT-jam]

1. if the user reconnects, you can again kick him off. If that happens often, the server address has to be changed. But it's about accidental logging in. Normally the private server address is not known to strangers and it would only be people who, for example, should not be present at this sample.
2. If nobody looks after the server, nobody can throw somebody out, that's the same as now.
3. Can't you link that to the checkbox that the function is only active if the server is not published in the server list? Anyone who makes their server public must expect strangers to log in.

Thanks for thinking!

[ann0see]

1. Yes. Probably this depends on your use case.
2. ... true. However, many people host private servers on headless machines. They should also benefit from a feature like this. These people should also be able to use this feature (I totally would but run a headless server)
3. I think for this we should wait on some others' to comment.

[hoffie]

Implementing a "Disconnect Channel N" menu in the server GUI sounds rather easy to me. However, many people do run headless servers, so I agree that it would be sad to leave this functionality out for them. At the same time, I think that the benefit of such a feature is very limited. If we are talking about users joining by accident, we can simply tell them to leave (maybe even in the Welcome message). If we are talking about users who want to cause trouble, a simple Disconnect feature won't help. It would need more sophisticated logic such as a waiting room (as @ann0see suggested & implemented) or proper session management.

Unfortunately I don’t see a big chance (yet) that this will be part of the official version.

I do have hope that we can have optional access control at some point, but I also want to emphasize that this is nothing which will be agreed and implemented in a few weeks.

I like the general idea of @gene96817's proposal to think this through properly, although I don't agree with all implementation ideas (see #1371).

[gene96817]

Would it be better to only allow expected users to connect?
Do you want to allow strangers, except misbehaving strangers?
Would the Proposal for Jam Session Management #1371 work for your needs? It has the benefit of letting a session leader have control without being the server administrator.

[AT-jam]

Yes, I think a Jam Session Management is a good idea. We actually have the problem that members of choir 1 log into the server during the rehearsal of choir 2. That would be bypassed with the management

[ann0see]

We actually have the problem that members of choir 1 log into the server during the rehearsal of choir 2.

Yep. That’s also a problem we have on our headless server.

[gilgongo]

@AT-jam Would you be able to use the "server licence" feature (--licence) to put up a notice for joiners to remind them that its for Choir 2 only? (This is currently undocumented due to my mistake, but will be corrected in the next release of the website)

[gene96817]

Doesn't this mean that someone needs to change the server license before each rehearsal (if the server is shared). The corollary is the server license is static and we will have a (large) number of single-purpose servers.

[AT-jam]

For this I have to start each time the server with new license-Information before each rehearsal - not really helpful

[gilgongo]

The issue of user authentication and related things like banning comes up reasonably regularly, and it's a legitimate request with sensible use cases for it.

From a technical point of view, my understanding is that Jamulus would need a very large and perhaps almost total re-write to incorporate such features. That's not impossible of course, but would be a very large challenge. From an non-technical point of view though, and perhaps the main reason why it hasn't happened really, is that the "spirit" of Jamulus is open (when public) and anonymous. Part of the "fun" of music is also in relationships with people - and those relationships can be good or bad, independently of the music being played.

So for now, the prevailing view is that for the "long tail" of different use cases where session management would help (eg choir members logging into the wrong server, banning troublemakers etc.) workarounds and tricks exist that mostly achieve what is needed.

[gene96817]

Perhaps we need a real-time discussion. I tried to be clear in the proposal that session management would be an external function to Jamulus and it needs some hook for coordination between Jamulus and session management. Further, the hooks would allow Jamulus to function without session management.

From a technical point of view, my understanding is that Jamulus would need a very large and perhaps almost total re-write to incorporate such features.

I failed to describe why session management does not need such big changes. Let's try to understand the pluggable authentication model (PAM) for authentication.

[dakhubgit]

I think the sensible solution for wanting to make a private session is not to register your server with the directories. All that is necessary is that your server firewall permits UDP connections on port 22124. If people are just unable to properly configure their firewall, the feature most necessary would appear to be supporting UPnP or whatever technology is used these days for controlling firewalls.

[gene96817]

Using UPnP assumes that the user operates the server, the private network, and the firewall. I think we want to support the jam session leader to be different from the owner of the server. Otherwise, everyone that needs this feature must operate their own server.

[dakhubgit]

I don't think it is appropriate to declare a "private session" without even asking the person running the server. And if you ask the person running the server, they should easily be able to stop the server announcing itself in a public directory for the time of a private session.

Public directory server capacity is not infinite and I don't see the point in filling them with servers that are not supposed to be open to the public. As practising (rather than jamming) sessions with Jamulus become more commonplace, making it harder to actually find servers open to the public does not make a lot of sense in my book.

[gene96817]

There is no obvious universal policy. In my case, my server is underutilized. I would be delighted for more usage. Private sessions are ok by me. And no, I don't want to have administrative tasks for each session. The session could be at a time that is personally inconvenient (I might be sleeping.)

As practising (rather than jamming) sessions with Jamulus become more commonplace, making it harder to actually find servers open to the public does not make a lot of sense in my book.

Before or after my rehearsals, I often scan the public servers to see what sessions are in progress. I am lucky to see three sessions happening. I don't perceive it likely in the foreseeable future that it will be hard to find idle servers. (Of course, most of them are too far away to be useful.) Any time I look, I usually see more than 70% of the servers idle.

[dakhubgit]

gene96817 ***@***.***> writes:

There is no obvious universal policy. In my case, my server is underutilized. I would be delighted for more usage. Private sessions are ok by me. And no, I don't want to have administrative tasks for each session. The session could be at a time that is personally inconvenient (I might be sleeping.) > As practising (rather than jamming) sessions with Jamulus become more commonplace, making it harder to actually find servers open to the public does not make a lot of sense in my book. Before or after my rehearsals, I often scan the public servers to see what sessions are in progress. I am lucky to see three sessions happening. I don't perceive it likely in the foreseeable future that it will be hard to find idle servers. (Of course, most of them are too far away to be useful.) Any time I look, I usually see more than 70% of the servers idle.

If you have a choir with 30 members, you won't start a rehearsal by looking for some server that happens to be free at the moment, just to be told in the middle of the rehearsal that now the weekly Folk session assembles. So then you go server-hunting. Let's say it takes you 10 minutes for an average rehearsal. That's wasting 5 personhours of time each rehearsal. Or you find a server and figure out that it will not support your load.

…

-- David Kastrup

[gene96817]

Yes... that too.

That is why I contributed discussion #1371 regarding session management.

[Rob-NY]

I'm continuing my work on a minor message change to support more robust admin and control (#1847), as well as starting a more top level discussion in thread (#1863). Toward this end, I've got something out there that @gene96817 and @AT-jam might find interesting. Take a look at https://vjammers.net. If you use the token "test1", you will be controlling the "vJammers 1" server in Any Genre 2. This is just a test site for proof of concept and private-alpha. It uses standard Jamulus 3.8 with my proposed message change (along with some custom controller software and web UI). The feedback I receive can help get #1847 considered down the road. (If you would like a host spun up in a different region like Europe, Asia, etc, for usability, just let me know and I'd be happy to accommodate for eval purposes.)

[Rob-NY]

OPEN mode let's anyone join the room, and you can individually block people once they're in. LOCKED mode will keep those in the room IN, but block everyone else. Also in LOCKED mode you can withdraw the permission for those in the room or grant IP permission for those yet to appear. LOCKED/OPEN has nothing to do with whether the server is registered with a directory or not. It works on both registered and unregistered(private) servers as there is really no difference security-wise. (This all becomes more clear if you join the room as a musician while looking at this console)

[ann0see]

Ah yes. It’s a bit like my waiting room feature. My question was how you handle permissions? IP block, disabling new connections in the Jamulus server code/?

[Rob-NY]

@ann0see - sorry misunderstood your question. The actual blocking is done on the jamulus server box's firewall via dynamic rule generation managed through the controller software. The jamulus code knows nothing about the blocking - and the ~30 second timeout still applies to channels dropping from the survivor client lists; although audio will not be transmitted or received during this wait state. If seeing folks on the list while blocked is troublesome, a server restart can be executed; but I chose to message this condition instead of forcing a restart.

The only change that I made to the core Jamulus code was to introduce new status/connection reporting as outlined in #1847 to provide more detailed info about each connection and to get the true recording state at any given point in time. My goal was not to weigh down the Jamulus software with things that could just as easily (or more appropriately) be handled outside.

[gene96817]

I'm finally catching up with this thread. #1847 demonstrates a new control method I didn't think about. There are two characteristics I am interested in.
1- separation between (1) control of the physical server, (2) control of the Jamulus server (e.g. start, stop, configurations), and (3) control of a session. As the owner of the Jamulus server, I want to delegate the control of a session to the session leader. In this way, there could be a community of session leaders (e.g. band leader, chorus director) and they each have control of their sessions. This suggests a scheduling web tool that manages the privileges of session leaders. I think #1847 gets very close to this scenario,

2- a large capacity (hw) server that can host a number of Jamuus servers. Each server would be managed by (1) above. I'd have to think about whether multiple instances of Jamulus can be managed through #1847. Manipulating the ports on the server makes it complicated to think through.

[ann0see]

Ok. Thanks for your explanation.

I see some pros but also some cons:

• Minimal code change: totally follows the jamulus core principles
• Still effective: switching recording on/off is now done cleanly
• Blocking via firewall means blocking connections before even reaching Jamulus —> reduction of processing load
  Con:
• People without their own IPv4 address need to use GCN. You can’t block clients on IP basis
• Your approach is quick but probably limited: it might only work on Linux and needs some experience during set up.