Feature #9993

Write a script to start a Mumble server in Tails

Added by sajolida 2015-08-13 11:47:37 . Updated 2016-03-15 16:22:50 .

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Target version:
Start date:
2015-08-13
Due date:
% Done:

0%

Feature Branch:
Type of work:
Code
Blueprint:

https://tails.boum.org/blueprint/mumble-server

Starter:
Affected tool:
Deliverable for:

Description

Subtasks

Related issues

Related to Tails - Feature #9851: Internal VoIP meetings Resolved 2015-08-01
Related to Tails - Feature #9853: Document how to run Mumble server from Tails Rejected
Blocks Tails - Feature #11241: Consider including mumble-server and mumble in Tails Resolved 2016-03-15

History

#1 Updated by sajolida 2015-08-13 12:13:00

  • Assignee changed from sajolida to kytv
  • Blueprint set to https://tails.boum.org/blueprint/mumble-server

Here is my script, see the blueprint.

It installs and configures a Mumble server and its corresponding Tor hidden service. Stores all that information in persistence and displays all the required connection information.

Kill Your TV, as you told me during the LHF, could you have a look and improve it a bit?

As Mumble server don’t really have access control apart from the global password (I think), maybe it would be relevant to add an option to the script to either configure the server and hidden service in persistence (—persistent) or not (—amnesiac).

#2 Updated by sajolida 2015-08-13 12:13:22

  • QA Check set to Ready for QA

#3 Updated by sajolida 2015-11-10 01:52:58

  • Assignee deleted (kytv)
  • Target version set to Tails_1.8

3 months have passed so maybe I should find someone else to do this review. Marking as for 1.8 just so we raise the issue in the next monthly meeting but I don’t mind having this reviewed later than 1.8.

intrigeri also suggested that shell scripting was not a good idea for that kind of things. But I’m not sure I’ll be able to rewrite this in any smarter language any time soon. So we might also decide that this is a blocker.

#4 Updated by intrigeri 2015-12-05 13:48:55

  • Target version changed from Tails_1.8 to Tails_2.0

Given how anonym’s plate looks like I think this should wait for post 1.8, as suggested.

#5 Updated by intrigeri 2015-12-14 10:00:32

  • Assignee set to anonym

#6 Updated by anonym 2016-01-22 14:18:07

  • Assignee changed from anonym to sajolida
  • QA Check changed from Ready for QA to Info Needed

I’m really sorry for the delay… :(

This script works really well:

  • I tested with several clients, both local and remote-via-onion
  • The persistence part works well after rebooting
  • The script is idempotent for the parts that could cause breakage if rerun
    You can’t ask for much more than this. :) Well done!

Nitpicking that I won’t block on:

  • I’d prefer quoting for all variables used as paths and passwords etc. At the moment there’s no risk for whitespaces breakage, but it’s good practice.
  • Now that we’re moving to Jessie and systemd, systemctl would be preferred over service for service management.

Any way, what are the next steps?

#7 Updated by sajolida 2016-01-27 10:57:31

#8 Updated by sajolida 2016-01-27 10:59:18

#9 Updated by sajolida 2016-01-27 10:59:22

  • related to Feature #9853: Document how to run Mumble server from Tails added

#10 Updated by sajolida 2016-02-01 10:51:37

  • Target version changed from Tails_2.0 to Tails_2.2

#11 Updated by sajolida 2016-03-07 15:11:17

  • Target version deleted (Tails_2.2)

#12 Updated by anonym 2016-03-13 00:42:08

anonym wrote:
> Any way, what are the next steps?

I’m still wondering about this.

I pushed some (IMHO) improvements, most importantly an option to allow LAN connections. That’s pretty useful if you run the Tails mumble server on a dedicated machine, or in a VM and want to avoid the hassle of forwarding your microphone to it.

BTW, I’m thinking that we easily could drop the requirement on persistence. A throw-away HS for one-time use is also very appealing.

Actually, what about shipping all of this in Tails? mumble + mumble-server and deps currently adds 13 MiB (uncompressed, so even less impact on the ISO size). Add a very simple GUI to your script, make it runnable without admin rights, and we have a a killer feature! :)

For the GUI, I imagine:

  • Start/Stop button and some indicator of whether the server is running (the latter is hopefully simple using systemd).
  • An area displaying the address/password/fingerprint when running.
  • A checkbox for using persistence, if available. Note sure if it should be checked by default. Or perhaps it could be a switch between “throw away” and “persistent/permanent server” (obviously we need some carefully chosen wordings here).
  • A checkbox for allowing LAN connections (unchecked by default).
  • Maybe a “Start mumble” button, which connects to the local instance.

Beware, Skype! :)

#13 Updated by anonym 2016-03-14 12:18:22

anonym wrote:
> Actually, what about shipping all of this in Tails? mumble + mumble-server and deps currently adds 13 MiB (uncompressed, so even less impact on the ISO size). Add a very simple GUI to your script, make it runnable without admin rights, and we have a a killer feature! :)

I got a bit enthusiastic about this, and pushed a branch: feature/mumble (last successfully autobuilt ISO. Feedback welcome! I should open a ticket for this — it would be cool to ship this in Tails 2.4.

> For the GUI, I imagine:

I went for a very simple GUI, based on shell and zenity (yay, more shell! :S) because that’s something I could prototype this in in 20 minutes.

> * Start/Stop button and some indicator of whether the server is running (the latter is hopefully simple using systemd).
> * An area displaying the address/password/fingerprint when running.

The the server GUI helper (which is avaiable in Applications -> Mumble server) is starter when the server is not running, it asks if you really want to start it. If yes, or if the server was already running, a dialog is shown with the connection info, and the two buttons “Stop” and “Keep running”.

> * A checkbox for using persistence, if available. Note sure if it should be checked by default. Or perhaps it could be a switch between “throw away” and “persistent/permanent server” (obviously we need some carefully chosen wordings here).

I instead added a persistence preset. This clearly communicates what the user’s intention is here. If not enabled, a throwaway hidden service is used.

> * A checkbox for allowing LAN connections (unchecked by default).

Not implemented. zenity isn’t that flexible, so we’d have to use something else. Still, perhaps we can just keep this as an undocumented feature for “experts” that can type sudo tails-mumble-server --listen-on-lan in a terminal. :)

> * Maybe a “Start mumble” button, which connects to the local instance.

Nah. Let’s cover this in the not-yet-written user docs instead. Otherwise, this would be another reason to move to something more flexible than zenity, so we can have three buttons (“Stop”, “Keep running”, “Start Mumble”).

> Beware, Skype! :)

Indeed! :)

#14 Updated by sajolida 2016-03-15 16:22:50

  • Status changed from Confirmed to Resolved
  • Assignee deleted (sajolida)
  • QA Check deleted (Info Needed)

So now we have a script. Let’s move the discussion on whether we want to have this by default in Tails somewhere else → Feature #11241. Once we decide something there we can move on designing the minimum interface we need to make this reality.

#15 Updated by sajolida 2016-03-15 16:23:07

  • blocks Feature #11241: Consider including mumble-server and mumble in Tails added