Tails

#1 Updated by adrelanos 2016-09-22 17:53:46

Somehow I cannot edit the original ticket. Never mind. Adding it as comment.

cpfpy wildcard support for some time now and recently event support was merged. So soon we can use onionshare etc. in Whonix. I would wonder why it should not be reuseable in Tails with very few modifications.

#8 Updated by intrigeri 2016-09-23 03:12:56

FWIW, last time this was suggested on tails-dev@, my initial code review was unconvincing (e.g. hand-made logging and service management while we have systemd nowadays, and quite a few troubling programming style issues). I don’t remember the details though, and chances are that the code has changed a lot since then, so we should definitely evaluate this option. Thanks for pointing us to it again :)

#9 Updated by adrelanos 2016-09-23 08:25:28

I’d be surprised if Tails would go for roflcopter. (details: Feature #11542#note-8) So I guess your options boil down to using cpfpy or reinvent cpfpy functionality in Tails tor-controlport-filter. And it would be a shame if cpfpy did not work for you. I’d very much like to have a shared code base for that one. I would wonder if more than a few simple patches would be required.

Yes, a lot has changed in cpfpy since then.

Do you have any examples, a (ideally minimal) python daemon that uses modern logging and service management? While I am at working on cpfpy, I guess it would be a rather small effort to port to that method.

#10 Updated by intrigeri 2016-09-23 10:25:05

> And it would be a shame if cpfpy did not work for you. I’d very much like to have a shared code base for that one.

Agreed!

> Do you have any examples, a (ideally minimal) python daemon that uses modern logging and service management?

I have no handy examples, but logging to stdout, and not forking / detaching from the terminal + a basic systemd unit file, should be enough nowadays. Ideally add support for the systemd notification protocol, which requires about 3 lines of code. If the custom logging + service management code is still in cpfpy, then this should allow you to drop quite some custom code and get a more maintainable codebase as a result :)

#11 Updated by adrelanos 2016-09-23 12:55:57

cpfpy is now logging to stdout, hence ending up in journal. No longer forking. Systemd unit file functional.

I would like to add systemd notification protocol, but the python libs for doing so are not available in jessie yet.

- https://packages.debian.org/jessie-backports/python-systemd
- https://packages.debian.org/unstable/main/python-sdnotify

I could make a call to the /bin/systemd-notify. That would work for the —ready notification but I am not sure it is a good idea to call —status every few seconds for daemon-still-alive notification.

Therefore systemd notification protocol has been assigned for the Debian stretch work milestone. Input, examples welcome, perhaps I can implement this already.

#12 Updated by intrigeri 2016-09-24 01:18:22

> cpfpy is now logging to stdout, hence ending up in journal. No longer forking. Systemd unit file functional.

Yeah! \o/

> I would like to add systemd notification protocol, but the python libs for doing so are not available in jessie yet.

I think you’re probably a bit confused. We do use python3-systemd successfully on Jessie:

• https://git-tails.immerda.ch/tails/tree/config/chroot_local-includes/usr/local/lib/tails-autotest-remote-shell#n13
• https://git-tails.immerda.ch/tails/tree/config/chroot_local-includes/usr/local/lib/tails-autotest-remote-shell#n47

#13 Updated by adrelanos 2016-10-01 18:54:06

That’s great. However, will take a while. We yet have to port to python3. Help welcome. :)