anonym:
> 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
I was only pointing to the work on the Tor control port filter for the
sake of completeness. I'm fine with using torrc and reload.
>>> - 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.
How does debconf work? Because it's doing something similar: manipulate
a default template based on some input from the user or a preseeding.
I think George mentioned this already but we should check whether it's a
correct assumption to believe that we can setup everything without ever
taking input from the user. It works for Mumble (as long as we set a
random password) but it might not be true for other services. Maybe we
need a generic mechanism to ask the user for some parameters which
depend on the service we're installing. These might be asked as a series
of question like debconf does or as a form with all parameters displayed
upfront.
> * 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.
You can use the "link" type in persistence.conf. I've done similar
things already while playing with #10543.
> 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.
I screwed up my sentence. The part "and segfault has been working on
making this available even when no administration password is set in
Tails Greeter [7]." was meant to go on my point about the screen locker,
and not about the HTTP server :)
>>> - 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.
First of all, note that we want to improve on the current state of the
Additional Software feature which is pretty bad. See #9059. So far they
block the opening of the session because:
1. It's a safer assumption to do it in this way than to install desktop
applications after the session is open. This is probably different when
talking about server daemons.
2. Nobody took the time to really look into #9059 and what would it take
to make this smoother.
One of the proposed solution was to have two lists, one for the packages
installed before the session is started (hopefully empty if not needed)
and one for the packages installed after the session is started. Note
that what takes most of the time is to rebuild and reread the list of
packages, not to actually install the packages.
Maybe some of this can be improved as part of your GSoC if it goes in
the direction you want to go.
Regarding starting the services automatically or not, I'm not sure
what's best. I can think of scenarios where the two options are best:
A. If I set up a Gobby server or a wiki on a dedicated laptop for a
meeting I want it to be auto-started.
B. If I set up a Mumble server to talk to my friends, maybe I only want
to start it on demand not to have unnecessary stuff running all the time.
So maybe we need an "Auto-start [On|Off]" option in the UI?
