segfault:
>> - The integration of OnionShare is moving forward [2] with some patches
>> proposed to our tor-controlport-filter to support creating ephemeral
>> onion services.
>>
>> [2]: https://labs.riseup.net/code/issues/7870#note-15
> I took note of this, but as I understand it, this will only enable
> _ephemeral_ onion services, not reuse a key and onion address generated
> previously, right? I plan to support both, persistent and ephemeral
> onion services. Currently I think I will have to bind mount the hidden
> service directory and reload Tor, just like it in the mumble server script.
You can restore an old onion key with the `add_onion` command (see [0],
section 3.27) so it is no only for ephemeral services. If stem makes
this extremely easy we may consider using it, but since we'll need admin
rights for other parts of setting up services, the point of using
`add_onion` is sort of lost (it's use case is: "you are non-root _but_
have access to Tor's control port"). I'm leaning towards a more KISS
approach of adding/deleting the corresponding two lines in torrc +
`systemdctl reload tor` (i.e. what we do in the mumble-server script).
That approach will turn even more elegant once we have torrc.d
functionality [1].
[0]
https://gitweb.torproject.org/torspec.git/tree/control-spec.txt
[1]
https://trac.torproject.org/projects/tor/ticket/1922
>> - We know have a script to run a Mumble server from Tails [4] and are
>> considering adding it to Tails [5].
>>
>> [4]: https://labs.riseup.net/code/issues/9993
>> [5]: https://labs.riseup.net/code/issues/11241
> Yes, that's great! And the current version is really nice. I already
> have some scripts written on my own to start other services, but the
> mumble server one definitely does some things nicer than I do - it will
> be very helpful during this project. Although it's a shell script and I
> will implement the server in python3.
I think there are a few lessons to take home from the mumble-server
script regarding configuration:
* The scripts configuration bits should be idempotent and always ensure
that the full expected configuration is in place: this simplifies things
a lot and generally results in more robustness by making sure we don't
end up in "half-configured" broken states that we cannot automatically
recover from, and by making many assumptions explicit and handled.
* It's pretty nice to use Debian's default configuration as templates
since they generally set sane and secure settings by default, and are
maintained. Since this implies that we have to patch an existing
configuration, I expect us to end up using ugly regex-based solutions,
but I think it provides so many advantages that it is worth it.
Otherwise we could provide our own template configurations and use ERB,
but then we need to maintain these ourselves (e.g. sync with Debian's
configurations regularly) and I expect it will make user modifications
to configurations much harder to support.
* The script is oblivious to whether persistence is used or not, which
reduces script complexity. It just puts the service's data files in the
directory that would be made persistent, and then it's up to that
feature to make it so, if the user so chooses. Other configurations
(e.g. in /etc) are handled by the idempotent configuration mentioned
above, and is applied in full each time to the expected state. The
problem here is we probably want to support arbitrary user configuration
so if we take mumble-server as an example we'd then need to make
/etc/mumble-server.ini persistent too, some how.
One thing to note about the mumble-server script is the "little
bind-mount trick" used to workaround Tor's AppArmor confinement. We
won't have that problem, I think. I did that so that all things we want
to make persistent for mumble-server lives in the same directory on the
persistent media, i.e. both Tor's HS bits, and mumble-server's data. We
certainly can do better by making these two separate, e.g. we make
/var/lib/tor/hs persistent and store all HS bits there, and then make
another directory outside of this persistent for the service
configuration/data bits.
- We have some very rough instructions to serve HTTP requests from Tails
>> [6] and segfault has been working on making this available even when no
>> administration password is set in Tails Greeter [7].
>>
>> [6]: https://labs.riseup.net/code/issues/10970
>> [7]: https://labs.riseup.net/code/issues/7879
>
> I think this is a misunderstanding - actually my scripts need to be
> executed as root and were never supposed to work without root. That
> would definitely be a nice feature, but I don't think I will make this a
> requirement for the GSoC project, because I think it won't be easy to
> realize.
Agreed.
>> - In [9] the blueprint seems to not take into account that we already
>> have the Additional Software persistence feature.
>>
>> [9]: https://tails.boum.org/blueprint/server_edition#index11h2
> We could use the Additional Software persistence feature, but the last
> time I used it, it installed the packages automatically at the end of
> the boot up, increasing the time the user has to wait before he can use
> the system. I guess this is still the case, right? I think installing
> them only when the user actually wants to start the service provides
> better UX. I prefer it this way, at least until we manage to make the
> rest of the Tails server run without root privileges.
I get your point, but, OTOH, once Tails starts probably all persistently
saved services should start automatically, right? I agree for ephemeral
services, though. So, IMHO, we should (1) install $PACKAGES, and (2) if
the service is persistent then `for p in $PACKAGES; do echo $p >>
tails-additional-packages.conf; done`.
I think a key feature of the existing Additional Software feature is
that it automatically updates packages, so it will at least partially
remove one expectation of a proper sysadmin role from the user's
responsibility. In fact, I think it'd be pretty great to block the start
of the Hidden Service until all services has been updated + restarted,
to lessen the exposure of outdated services over the Internet.
Cheers!
