Feature #11003

Decide if we want to host a Mumble server for the project

Added by sajolida 2016-01-27 11:04:46 . Updated 2017-04-14 15:58:54 .

Status:
Rejected
Priority:
Normal
Assignee:
Category:
Infrastructure
Target version:
Start date:
2016-01-27
Due date:
% Done:

0%

Feature Branch:
Type of work:
Discuss
Blueprint:

Starter:
Affected tool:
Deliverable for:

Description

See Feature #9851#note-3. The alternative would be ad-hoc Mumble servers run from Tails.


Subtasks


Related issues

Related to Tails - Feature #12447: Set up a Mumble server for the fundraising team Resolved 2017-04-14

History

#1 Updated by sajolida 2016-01-27 11:06:32

  • Assignee set to intrigeri
  • QA Check set to Info Needed

Assigning to intrigeri as tails-sysadmin who showed personal interest in this. Do you think this could be a topic for the next monthly meeting or do you (tails-sysadmins) need to do more research before (at the meeting) can take a decision?

#2 Updated by intrigeri 2016-01-29 15:42:13

  • Assignee changed from intrigeri to sajolida

I don’t think we need more technical research.

It would be nice to know what the intended audience of this service is, though. So far I’ve seen “for the project”, and a “shared password” was mentioned somewhere, but this is not very clear. The reason I’m asking is that with my -sysadmins@ hat on, it can make a big difference, in terms of responsibility and of needed work, whether we’re asked to host something for a small core team we know well and can trust to not expand the list of people who know the shared password, or something different that will require finer-grained access control, or per-team mumble instances, or something. It can make the difference between something we can quickly set up in one evening, and something that will wait months if not years in our nice list of things our tiny sysadmins team should do some day.

#3 Updated by sajolida 2016-01-31 10:42:27

  • Assignee deleted (sajolida)
  • QA Check deleted (Info Needed)

Yeah, the line might indeed be very hard to draw between who has the password and who don’t. For example, we could say “people complying with some security policy from our one of our teams” but then it would keep tchou and probably other workers out. Saying “people attending a summit” sounds too loose as some people come once and never again.

Honestly, this sounds like a can of worms I’m not interested in opening. I should have seem this coming when saying “shared password”.

So I’m deassigning this from me. I’m fine running ad-hoc servers from Tails. If noone else is interested in leading this discussion it probably means we should drop this idea and focus on Feature #9993.

#4 Updated by intrigeri 2016-02-10 17:04:46

> Honestly, this sounds like a can of worms I’m not interested in opening.

Same here.

> So I’m deassigning this from me. I’m fine running ad-hoc servers from Tails. If noone else is interested in leading this discussion it probably means we should drop this idea and focus on Feature #9993.

I’m not going to lead the discussion either. Maybe some day I’ll set up a Mumble service for a very small target audience, and then whoever would like to make the audience bigger will need to lead this discussion. Iterate! :)

#5 Updated by sajolida 2016-05-03 12:12:16

  • Status changed from Confirmed to Rejected

Rejecting my own proposal now that we are working on Tails Server again!

#6 Updated by intrigeri 2017-04-14 15:57:59

  • Category set to Infrastructure

See Feature #12447 where I’ll do the part that addresses a real problem, without requiring a complicated discussion.

Note, however, that “Each murmur process supports multiple virtual servers, each with their own user base and channel list” so we don’t have to debate about one single shared password: having one such virtual server per team would probably solve 90% of our use cases, and for the remaining ones self-hosted mumble is still an option.

#7 Updated by intrigeri 2017-04-14 15:59:30

  • related to Feature #12447: Set up a Mumble server for the fundraising team added