implement easy way to configure virtual server

[sss123next]

for long time i have used simple config with mysql db and no virtual servers.
now i need to add virtual server.
i have tried everything from https://wiki.mumble.info/wiki/3rd_Party_Applications
most tools is outdated and does not even start in fresh environment.
other dependant on icephp which is problem, in ice version 3.5 impossible to build php for php5.6 and with ice3.6 murmur does not builds

i need some way to add virtual server.
i have following environment:
system is Gentoo

www-servers/apache-2.4.23
dev-lang/php-5.6.26
dev-lang/python-3.5.2
dev-libs/Ice-3.5.1 (impossible to build php module)
dev-libs/Ice-3.6.2 (impossible to build murmur)

any suggestions ?

[sss123next]

i have found tricky way to build icephp in ice3.5.1
but i still think what here should be a simpler way to manage virtual server
maybe some cli tool should be created and maintained alongside with murmur itself and not as third-party application

[Kissaki]

You should be able to use the PHP extension Ice 3.6 with a Mumble server compiled with 3.4.

MumPI documents the 3.5 vs 3.4 case, where you specify the -e parameter for compatibility. Does that not work for 3.6?

The 3.6 upgrading docs explicitly state no compatibility issues for PHP. So I would expect -e to work.

[sss123next]

i already solved problem and successfully compiled both murmur and php with ice 3.5.1. but i still think what core functionality should not be dependant on third party apps, as i already said i see bundled cli tool as a best solution.

[Krzmbrzl]

Could you please explain to me what exactly you mean with "virtual server" in this context? Why do you have to compile Murmur for this in the first place? 🤔

[sss123next]

maybe i was not precise enough and it's better to make two separate tickets about this issue.

1. abi related, which solved by rebuild
2. missing feature: ability to create and manager virtual servers without third-party software

[Krzmbrzl]

You are referring to functionality as provided by https://wiki.mumble.info/wiki/Murmur-manager, right?

And ABI compatibility is referring to the ICE interface? 🤔

[Kissaki]

@Krzmbrzl Our mumble server (murmur) hosts virtual servers. When the process is used to host one virtual server (one client endpoint) with no additional configuration one virtual server is started, and the murmur.ini serves as defaults for this (and any other) virtual server.

Our Ice API provides functionality to manage virtual servers (within the host server/process). This is not specific to the third party software murmur-manager.

[Kissaki]

In other words: Ice can be used for meta-management; managing the host server. But a Mumble client only ever connects to a virtual server, so at the moment it is limited to management of that virtual server.

[Krzmbrzl]

@Kissaki thanks for clarifying! :)

[toby63]

• Is ICE the only protocol for managing the virtual servers?

And for understanding virtual servers (per definition in this case):
(I never used them)

• what is the advantage of using virtual servers (I guess "easier" administration?)
  • if yes, what other advantages or disadvantages are there?
• do they run inside the same process?
• do they use the same database or different dbs?
• the ini is only modified within ice and saved in the db I guess?
• can they be "exported"?
• are they "permanent"?

[sss123next]

• as far as i know they now can only be managed via ice, and in past dbus was used for this purpose
• if any ability to interact with ice exists, it's easier to administer server (and virtual servers)
• yes they run inside same process
• yes they use same database
• it is does not related to ini, ini is not modified at all
• yes they can be 'exported', it's just database data
• yes it's permanent

[Krzmbrzl]

Every server is a virtual server. The clue is that you can have multiple servers running with only one running instance of the murmur executable. Thus the name "virtual" server. Per default only one server is started but it is still a virtual server.

[streaps]

* Is ICE the only protocol for managing the virtual servers?

I'm doing it with gRPC

[toby63]

Thus the name "virtual" server. Per default only one server is started but it is still a virtual server.

Kissaki already explained that above.

I'm doing it with gRPC

Interesting.

And I read the issue right, that there are only 3rd party tools available, that are outdated and only one method (MumPI it seems) is working?
And no internal cli exists?

Well regarding the Server Ideas #4164, this would probably be the first step I guess.

[streaps]

And I read the issue right, that there are only 3rd party tools available, that are outdated and only one method (MumPI it seems) is working?
And no internal cli exists?

It's a huge usability problem. murmur-cli was easy to install, but I had to do a custom build of murmur with gRPC enabled.

[Krzmbrzl]

I agree that we need a built-in way of managing servers. Now we just need someone who has the time to implement it xD

[toby63]

Now we just need someone who has the time to implement it xD

Maybe apply a "help-wanted" tag and put it in a list 😃 .

For understanding:
@streaps talked about a

custom build of murmur

• Could the necessary changes be included in mainline murmur?
  • I see this: WIP: Build Murmur with gRPC support by default #3480
  • and this: WIP: A new way to gRPC #3947
    Interesting.
• And could https://github.com/layeh/murmur-cli be taken as a basis for a GUI?
  Hmm written in GO...I guess it "should be" in C++?

[streaps]

gPRC in the default build would be nice.

[Krzmbrzl]

Maybe apply a "help-wanted" tag and put it in a list.

I don't think that anybody cares about these tbh. But I'll add it anyways :)

gPRC in the default build would be nice.

From what I know the current gRPC implementation is unstable. That's why it isn't enabled by default...

[Kissaki]

Enabling gRPC by default is tracked in #3429. It’s an important feature to move forward, and nobody disagrees with that it should be enabled by default. But it doesn’t really help with what this ticket is about anyway.

[streaps]

From what I know the current gRPC implementation is unstable.

unstable interface or buggy?

It’s an important feature to move forward ... But it doesn’t really help with what this ticket is about anyway.

I think that having gRPC in the default build would help. Building murmur-cli is a no brainer. Is there any murmur manager for Ice that is still developed and maintained?

[Krzmbrzl]

Afaik it's buggy and responsible for a few segfaults from time to time.

[toby63]

Afaik it's buggy and responsible for a few segfaults from time to time.

Is #3947 trying to fix this?

But it doesn’t really help with what this ticket is about anyway.

Could you elaborate that? Isn't the gRPC protocol a good candidate for a cli?

[Kissaki]

Could you elaborate that? Isn't the gRPC protocol a good candidate for a cli?

This ticket asks to implement and provide an easy way to configure virtual servers. gRPC is a protocol, it [alone] can not provide that. And if the configuration is/were in the client it is questionable or at least not clear if gRPC would be necessary for it.

[McKayJT]

Afaik it's buggy and responsible for a few segfaults from time to time.

Is #3947 trying to fix this?

Yes. My patch set is designed to fix the instability of gRPC. Right now a huge number of things will cause a segfault. The reference counting that the current design uses simply does not work properly. I abuse std::shared_ptr and std::weak_ptr to reference count for me---I see no reason to implement reference counting unless I really need to.

I also have an improved fork of murmur-cli at https://github.com/mckayjt/murmur-cli that includes support for client certificates, and in a development branch configuration files so you don't have to specify everything on the command line.

[Kissaki]

Can we please have a dedicated gRPC ticket with/for the open issues? We should be able to see them in the tracker and gRPC label, but no segfault ticket is there.

gRPC discussion should also move there instead of here IMO.

[Krzmbrzl]

Closing in favor of #5924