Server-GUI (+Easy-Mode for Setup)

[toby63]

Context: Server, -start, -configuration

Description: An integrated Server-GUI for managing (virtual-)servers. Related to #2569 (integrated cli for server management).

Advantages:

• easier & handy (especially for new users)
• better overview for many servers
• the integrated solution is directly available to users (no install/compile/setup of external tools necessary) and new features could be directly implemented in it

Potential Features:

• Serverlist:

  • Name, Config, Status
  • (optional) more info: Active users (number) etc.

• Start/Stop

• Interactive configuration:

  • (optional) explanation of options

• (optional) Support for textbased config as well:

  • option to add(/export) configfiles
  • editor (internal or external editor (config option to choose one))

• (optional) Duplicate/Clone-function

• (optional) Export/Import server (configs + database (or db content))

• (optional) ACL-management, two potencial levels:

  • level 1: choose default ACL-options on server
  • level 2: manage ACL directly (aka User-Lists & Groups)

• (optional) User-Management (like kick, ban etc.)

• Special (optional) Feature: Easy-Config-Mode (for new, inexperienced users as well as users who like to have a light version)

  • Very short config:

    • Password (aka serverpassword)
    • main channel/server-name (aka registerName)
    • maximum number of users (aka users)
    • (optional) bandwidth
    • (optional, advanced) host (for choosing a network interface)
    • (optional, advanced) more advanced settings

  • changes to server/config:

    • option for one-time-server (deleted after use)
    • (if necessary) create a seperate default config
    • modify standard ACLs for this purpose, for example:
      • no selfregister
      • disable ACL-settings-UI (because it would not be needed in such an easy-setup)
      • or implement an easier ACL-settings-UI (maybe only for this setup)
    • automatically make the user the admin of the server
    • automatically modify the welcome message to include the user name ("welcome to user's server")

  • UPnP-Suppport, so no port forwarding is necessary (see #4049)

  • (additional idea) Login-String: create a string, that contains all info (ip, password etc.) for easier login (admins could send the string and users would paste it into a textfield in mumble)

Some additional features I saw in murmur-cli:

• database query (might be useful in cli, but is not necessary in GUI imo)

• send text messages (not necessary imo)

Technical Implementation:

• existing protocoles (gRPC, ICE (seems to be planned for deprecation?)
• Could murmur-cli be used?
• Alternatives?
• Or build from scratch?

---

Alternatives:

• Initial idea was to implement such an easy-server-setup in the client, but I decided against it (I guess many people share this oppinion, including the developers).

[Krzmbrzl]

I don't think this should be in the client (after all the client and the server can be distributed independently as of now).

However an easy way to set up a server would of course be a good idea.For that we basically have https://github.com/mumble-voip/mumble/issues/2569.

EDIT: Though maybe it'd make sense to close the old issue and keep this one as this is more general... What do you think? :thinking:

[toby63]

I don't think this should be in the client (after all the client and the server can be distributed independently as of now).

Well I understand that, but it would only be "really" easy if it is in the client. By the way: I see it as a big problem how debian etc. are supplying the server package. It is a package which starts automatically and is by default configured in /etc etc.: I don' t think thats the method many "normal" users "want". But yeah I know, "talk to the distro", maybe I will do that :wink:. Still a potencial option for you (the mumble project) would be to give out building options, to build a bundled version with a minimum server (for the purpose of this issue) :slightly_smiling_face: .

2569

EDIT: Though maybe it'd make sense to close the old issue and keep this one as this is more general... What do you think? :thinking:

Well #2569 is a bit confusing and different I think (though a bit related, for the record: the user asked for a cli for managing virtual servers). I see two other options:

• modify my issue (which I would not like for now, to see more reactions to the idea of client implementation)
• create a third issue that properly describes a Server GUI (or something similar)

So in summary: I would wait a little longer.

[toby63]

@streaps You downvoted, can you explain what exactly you don't like? Just the implementation in client or other things? I guess you don't object to a good, implemented Server GUI?

[streaps]

I should have written a comment instead. I think server and client should be kept separate.

Your proposal also suggests that people run their servers on their broadband connections behind their routers. It can be done, but there are all kinds of pitfalls. I have my doubts that a server GUI will lead to better user experience. Connections will fail because of wrong IP addresses, port forwards that don't work, some people will think it is a great idea to run the server on a wireless connection, ...

If a user cannot master murmur.ini, I'm not sure I would recommend running their server at home.

I guess you don't object to a good, implemented Server GUI?

I wouldn't mind a GUI for configuring virtual servers (over gRPC).

I see it as a big problem how debian etc. are supplying the server package.

The Murmur package behaves like other server packages in Debian. If you want to run your server with a GUI and on-demand, maybe a Flatpak or AppImage would work. But Linux distros are not Windows. Don't waste your time trying to convince the distros package maintainers to change everything, just because you don't like the Linux way ;).

[trymeouteh]

+1 for a GUI client to easily setup and configure Murmur for Windows and Linux. This will make it easy to setup for non tech savvy people.

[toby63]

Your proposal also suggests that people run their servers on their broadband connections behind their routers. It can be done, but there are all kinds of pitfalls.

I also thought about that when reading #4049. Nonetheless it could enable people to run their own servers more easily. We could search for other projects who implemented UPnP and see how big their failure rate is (if their forum is full of complaints, we know its not running good :smile:).

If a user cannot master murmur.ini, I'm not sure I would recommend running their server at home.

:smile: I remember reading that somewhere: "if you can't do it on your own, you probably should not do it".

The Murmur package behaves like other server packages in Debian. If you want to run your server with a GUI and on-demand, maybe a Flatpak or AppImage would work. But Linux distros are not Windows. Don't waste your time trying to convince the distros package maintainers to change everything, just because you don't like the Linux way ;).

Yeah I'm already applying lots and lots of solutions to that, compiling myself, running containers etc. But the main point here is not my fight against windmills, it is the question whether mumble could do something for "normal users" who just want to run a server. And the idea proposed in this issue might be a solution.

---

Nonetheless I see, it would probably be better to have a seperate (Server-)GUI :thinking:. But I still like the idea of a "very easy"-variant.

The only advantages in a client-implementation would be:

• automatically make the user the admin of the server
• automatically modify the welcome message to include the user name ("welcome to user's server")

and these could be realized in a server GUI as well.

@Krzmbrzl: Ok, I am convinced that a seperate Server GUI would probably be best. I will rewrite this, but I am still thinking about two seperate issues:

• Issue 1: Server-GUI
• Issue 2: Easy-Mode (actually this issue) for Server-GUI

What do you think, combine or seperate?

[Krzmbrzl]

Given that there is no such thing as a server GUI, I'd keep them both in a single issue. The issue will be about implementing a server GUI and if you want it to have an easy mode, then you can add that to the issue, I guess... :thinking:

[toby63]

I'd keep them both in a single issue

Ok, will do.

[toby63]

Just so this doesn't get lost, could you add a label for "feature-request"?

And we maybe could discuss, how you (the mumble team) would want this to be implemented, in case someone wants to help. @Kissaki for example seems to have the oppinion that the cli-topic is seperate from already implemented protocols like gRPC (see https://github.com/mumble-voip/mumble/issues/2569#issuecomment-628912462). But I would think that a cli could be based on those protocols (maybe even the existing https://github.com/layeh/murmur-cli could be used). And the Server-GUI could then use the cli, but what do I know, maybe there are obstacles or better ideas for that.

[Krzmbrzl]

Closing in favor of #5924