Write a script to start a Mumble server in Tails
#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).
#3 Updated by sajolida 2015-11-10 01:52:58
- Assignee deleted (
- 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.
#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,
systemctlwould be preferred over
servicefor service management.
Any way, what are the next steps?
#12 Updated by anonym 2016-03-13 00:42:08
> 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
> 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).
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! :)
#14 Updated by sajolida 2016-03-15 16:22:50
- Status changed from Confirmed to Resolved
- Assignee deleted (
- QA Check deleted (
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.