1. 06 Mar, 2017 1 commit
  2. 05 Mar, 2017 1 commit
  3. 04 Mar, 2017 2 commits
  4. 28 Feb, 2017 2 commits
  5. 30 Jan, 2017 1 commit
  6. 28 Aug, 2016 1 commit
  7. 26 Aug, 2016 1 commit
  8. 23 Aug, 2016 1 commit
    • intrigeri's avatar
      Stop shipping ttdnsd. · 1512c2ba
      intrigeri authored
      It was only useful for developers and power-users who can install it themselves
      as needed. It's been unmaintained upstream for many years. It's very buggy so we
      had to remove it from the DNS resolution loop years ago. It's not in Debian.
      And it's one of the only two bits of Tails that still rely on tsocks, that is
      RC-buggy, unmaintained in Debian, and not in Stretch at the moment.
      So it has become clear that the cost of keeping ttdnsd now outweighs the
      benefits it brings.
      refs: #10959
  9. 10 Aug, 2016 1 commit
  10. 17 May, 2016 1 commit
  11. 19 Feb, 2016 1 commit
  12. 03 Jan, 2016 1 commit
  13. 30 Nov, 2015 1 commit
  14. 23 Nov, 2015 1 commit
  15. 22 Nov, 2015 1 commit
  16. 20 Nov, 2015 1 commit
  17. 17 Nov, 2015 1 commit
  18. 11 Nov, 2015 2 commits
  19. 10 Nov, 2015 2 commits
  20. 09 Aug, 2015 1 commit
  21. 08 Jul, 2015 4 commits
  22. 21 Jun, 2015 1 commit
  23. 16 May, 2015 1 commit
  24. 30 Mar, 2015 1 commit
  25. 29 Mar, 2015 3 commits
    • intrigeri's avatar
      Create a tails-wait-until-tor-has-bootstrapped.service in the systemd user instance. · 76be86f2
      intrigeri authored
      The systemd user and system instances don't share units. Thus, the dependency
      we have from the security check and upgrader user services on
      tails-wait-until-tor-has-bootstrapped had no effect.
      So, we have the *system* tails-wait-until-tor-has-bootstrapped.service create
      a file upon completion -- and the identically named *user* unit file wait for
      that file to appear.
    • intrigeri's avatar
      Add a unit file whose completion indicates that Tor has bootstrapped. · d57fd2fd
      intrigeri authored
      We'll then be able to use this, with systemd units ordering, to get rid
      of some of the while/sleep loops we have elsewhere.
    • intrigeri's avatar
      Convert a few X session startup programs to `systemd --user' units. · 9fb0136e
      intrigeri authored
      This is merely preparatory work that lays down some foundations.
      For now, we're using two targets:
       * basic.target sets up things that should be done as early as possible, don't
         need access to X, notifications, nor D-Bus ; it is automatically started by
         `systemd --user' when the logind session is created. Note that this happens
         after persistence has been set up, when the GDM autologin is triggered, and
         before /etc/gdm3/Xsession is run:
         - tails-add-GNOME-bookmarks.service
         - tails-create-tor-browser-directories.service
       * desktop.target: we're starting it via xdg/autostart during the GNOME session
         startup. There are a few units wanted by this target so far:
         - tails-configure-keyboard.service
         - tails-virt-notify-user: ideally, this should have something like
           After=notifications-ready.target (and then, most other things that
           wait for GNOME Shell to be ready to handle notifications could do the
           same instead of grep'ing the process list).
         - tails-warn-about-disabled-persistence.service
         - tails-upgrade-frontend.service: the idea is to later use systemd units
           ordering to make it run at a time that increases chances for the system
           having enough free memory; e.g. as soon as possible once the session is
           ready, Tor has bootstrapped, and some other memory-hungry programs we run
           at session startup time have completed.
         - tails-security-check.service: similarly, the idea is that we could get
           rid of the wrapper — that merely waits for Tor to have finished
           bootstrapping — given another systemd unit.
      Most of these units exit early unless they're run by the `amnesia' user.
      Otherwise they break e.g. Tails Greeter startup, and probably worse.
      Also note that the units that may take ages to complete have Type=simple.
      With Type=oneshot, systemd would wait for them to complete before running any
      follow-up units, and before considering the target they're part of has been
      reached. Two of our units can take minutes to complete, so the desktop.target
      startup would fail. Now, using Type=simple has one drawback: it makes it harder
      to order other units relatively to tails-security-check-wrapper's and
      tails-upgrade-frontend-wrapper's completion. This doesn't feel too bothering,
      though: it's more likely that we want to configure these units to start after
      others, than the opposite.
      Also, when the GNOME session is initialized, we import the relevant D-Bus, X11
      and locales variables into systemd --user's environment, so that our units can
      use them. We do that immediately before starting desktop.target.
  26. 07 Mar, 2015 2 commits
  27. 06 Mar, 2015 1 commit
  28. 27 Nov, 2014 3 commits