summaryrefslogtreecommitdiffstats
path: root/config/chroot_local-includes/lib
Commit message (Collapse)AuthorAgeFilesLines
* Avoid 2 minutes delay while rebooting after applying an automatic upgrade ↵intrigeri2020-01-121-0/+3
| | | | | | | | | | | | | | | | (refs: #17026) Otherwise, for some reason user@1000.service can't be stopped while rebooting after applying an upgrade until the default 2 minutes timeout is reached: A stop job is running for User Manager for UID 1000 (x / 2 min) I suspect that's because the Upgrader is running via sudo as another user, so the amnesia user's systemd instance is not allowed to kill it and as a result, the entire session is left in running state. OTOH this problem does not happen when the persistence setup wizard or the Unsafe Brower is left running before rebooting; that's perhaps because they don't run as systemd units.
* Upgrader: refresh the signing key before checking for available upgrades ↵intrigeri2019-12-241-1/+2
| | | | (refs: #15279)
* Move the Upgrader's trusted keyring to tails-upgrade-frontend's $HOME and ↵intrigeri2019-12-231-3/+2
| | | | | | | make it writable by that user (refs: #15279) This will be needed in order to refresh our signing key before checking for upgrades.
* Merge remote-tracking branch 'origin/stable' into ↵intrigeri2019-12-133-5/+3
|\ | | | | | | bugfix/17166-fix-unknown-escape-sequence
| * Merge branch ↵intrigeri2019-11-151-3/+1
| |\ | | | | | | | | | 'bugfix/17143-17214-12023-remove-obsolete-tor-browser-customization+force-all-tests' into stable (Fix-committed: #17143, #17214, #12023)
| | * htpdate: stop sending User-Agent that fakes Tor Browser (refs: #12023)intrigeri2019-11-101-3/+1
| | | | | | | | | | | | | | | As decided on the "[Tails-dev] Faking htpdate user agent worth it?" thread in December 2016.
| * | Wait until Tor has bootstrapped before we try to upgrade Additional Software ↵intrigeri2019-11-102-2/+2
| |/ | | | | | | | | | | | | (refs: #17203) This was the intention of this code since the beginning, but unfortunately we got the unit name wrong, so our After= stances were ineffective.
* | Fix escape sequence in tails-gdm-failed-to-start.service (refs: #17166)segfault2019-10-191-1/+1
|/ | | | | | | | | | | | | | | | The command works, but produces this message: /lib/systemd/system/tails-gdm-failed-to-start.service:11: Ignoring unknown escape sequences: "MAX_LENGTH=254 ; PREFIX="Error starting GDM with your graphics card: " ; SUFFIX=". Please take note of this error and visit https://tails.boum.org/gdm for troubleshooting." ; MAX_VIDEO_CARD_LENGTH=$(($MAX_LENGTH - $(echo -n "$PREFIX$SUFFIX" | wc -c))) ; VIDEO_CARD=$(lspci -d::0300 -nn | sed -E "s,.* VGA compatible controller \[0300\]: *,," | cut -c "1-$MAX_VIDEO_CARD_LENGTH") ; /bin/plymouth display-message --text="$PREFIX$VIDEO_CARD$SUFFIX" " Adding a backslash fixes that and the command still works.
* Merge remote-tracking branch 'origin/devel' into ↵intrigeri2019-10-051-6/+9
|\ | | | | | | feature/16664-simplify-tor-has-bootstrapped+force-all-tests
| * More refactoring (refs: #17098)segfault2019-10-041-6/+9
| |
* | Merge remote-tracking branch 'origin/devel' into ↵intrigeri2019-08-293-67/+2
|\ \ | |/ | | | | feature/16664-simplify-tor-has-bootstrapped+run-all-tests
| * Remove "XXX" in favour of #16964.intrigeri2019-08-101-3/+1
| |
| * Adjust boot-time backports APT pinning for Buster.intrigeri2019-08-101-1/+1
| | | | | | | | I've filed #16967 so we don't forget this again while porting to Bullseye.
| * Remove pre-generated Pidgin accounts (refs: #16744)segfault2019-07-141-63/+0
| |
* | Fix systemd unit descriptionsegfault2019-07-251-1/+1
| |
* | Use BindsTo= and After= in tor-has-bootstrapped systemd units (refs: #16664)segfault2019-07-202-9/+8
|/ | | | | | | | | | | | | | | | | | | Currently, if tor@default.service stops for some reason (either stopped manually or unexpectedly), tails-tor-has-boostrapped.target is still active. Using BindsTo= in conjunction with After= ensures that the unit is always stopped if the other unit (tor@default.service) is stopped. See https://www.freedesktop.org/software/systemd/man/systemd.unit.html#BindsTo= This allows us to simplify config/chroot_local-includes/usr/local/sbin/tor-has-bootstrapped, which would only have to check if tails-tor-has-bootstrapped.target is active. Or, we could get rid of this script altogether, because instead of calling the script, applications can just run /bin/systemctl --quiet is-active tails-tor-has-bootstrapped.target themselves.
* Move hooks to drop-in config file snippetssegfault2019-04-041-0/+2
|
* Disable emergency shutdown during suspend (refs: #11729)segfault2019-04-041-0/+11
|
* ASP: ignore install exit codeAlan2019-03-161-1/+1
| | | | | | We want to run the upgrade even if the install step fails, so let's ignore its exit code. Will-fix: #15957
* Mount a dedicated tmpfs on /run/initramfs instead of trying to remount /run ↵intrigeri2019-01-122-17/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | with the "exec" option (refs: #16097). My previous approach, i.e. "let's remount /run with the exec option via a unit file started as part of the shutdown procedure", worked just fine for clean shutdown. But it does not work for emergency shutdown, i.e. when the boot medium is physically removed: for some reason (possibly missing bits in the memlockd configuration), this service is not started, and then systemd-shutdown won't return to the initramfs because /run/initramfs/shutdown is not executable. So let's instead disregard /run and extract the initramfs into a dedicated tmpfs, that we mount on /run/initramfs (where systemd-shutdown will look for it), and that we mount without the "noexec" option. Also, remove manual calls to eject(1): - They increase chances that the shutdown process breaks due to missing files locked in memory by memlockd. - Their sole benefit is to ensure we physically eject the DVD. It's unclear if this code is still needed nowadays. Regardless, starting with Tails 3.12, the only supported use case for ISO and DVD is virtual machines, which are not targeted by the emergency shutdown feature, which is about removing the *physical* boot medium.
* Fix memory erasure on shutdown with systemd v239 (refs: #16097).intrigeri2019-01-102-3/+17
| | | | | | | | | | | | | | | | | | | | | | Remounting /run with the "exec" option in /lib/systemd/system-shutdown/tails does not work anymore with systemd v239, while it worked at least until systemd v237. I could not find out why by reading systemd's NEWS file. So let's instead do this there: - For clean shutdown: in a new, dedicated service, started immediately before final.target, which itself is a synchronization point that ensures this service is started before the transition to systemd-shutdown and in turn to the initramfs, where we finish the unmounting and other clean ups needed to erase the memory. - For emergency shutdown: in the udev watchdog script, before calling the unclean shutdown code, which bypasses final.target and thus won't run tails-remount-run-exec.service. Too bad we have to duplicate this mount command but it seems that both instances will become unnecessary quickly enough, once systemd DTRT™. Another way would be to manually start tails-remount-run-exec.service from the udev watchdog script but I'm concerned it will be unreliable when the boot medium has been unplugged.
* Merge branch 'feature/15915-remove-readahead' into devel (Fix-committed: #15915)intrigeri2019-01-063-55/+1
|\
| * Start the udev watchdog for emergency shutdown only after we're ready to ↵intrigeri2018-11-191-1/+1
| | | | | | | | | | | | | | | | return to initramfs. Without this explicit ordering, we have no guarantee that /run/initramfs has been populated when udev-watchdog-wrapper is triggered and calls "systemctl --force poweroff" to return to the initramfs.
| * Remove the boot readahead feature (refs: #15915).intrigeri2018-11-182-54/+0
| | | | | | | | | | | | | | | | | | | | | | Our work on the USB image project (#15292) will deprecate booting from DVD except for VMs. So the use cases we'll still support are: - booting from a USB stick - booting a VM from an ISO In both cases, readahead does not matter much (or at all), so let's simplify things.
* | Rename pools to avoid confusion (refs: #15428)intrigeri2018-11-171-7/+7
|/ | | | | | | | People get confused by the use of pal/neutral/foe: they think we need to particularly trust members of the "pal" pool, which is incorrect and can lead to useless controversy. So let's fix this by renaming the pools and clarifying our design doc.
* Fix another regex (refs: #15973)segfault2018-09-301-1/+1
|
* Fix regex (refs #15973)segfault2018-09-291-1/+1
|
* Fix APT pinning for stretch-backportssegfault2018-09-231-3/+13
| | | | | | | | In our own repo, we use "o=Debian", but the official Debian repo uses "o=Debian Backports" for backports. Since we change the repo from ours to Debian, we also have to change the origin. In passing, add a log message and simplify another regex.
* Simplify regex (refs: #15837)segfault2018-09-201-3/+2
|
* Reconfigure custom APT repo in APT preferences (refs: #15837)segfault2018-09-191-0/+14
| | | | | | | We change our repository from deb.tails.boum.org to jenw7xbd6tf7vfhp.onion in the APT sources, so we also have to change it in the APT preferences, or else the pinning is ignored and packages from Debian repos are installed with higher priority.
* Merge remote-tracking branch 'origin/devel' into feature/14594-asp-guiintrigeri2018-08-153-3/+3
|\
| * Rename /usr/share/amnesia to /usr/share/tails.intrigeri2018-08-143-3/+3
| | | | | | | | The project was renamed, what, 8 years ago?
* | Ensure the amnesia user can cross the /media/tails-persistence-setup/ ↵intrigeri2018-06-061-0/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | directory boundary (refs: #15566) … by creating that directory via a live-config hook, with appropriate ownership and permissions. A newly created persistent volume is mounted on /media/tails-persistence-setup/TailsData by t-p-s (via udisks2). At the end of the (new) persistent volume configuration process, we display a "gear" icon that when clicked, starts tails-additional-software-config as the amnesia user. tails-additional-software-config needs to read /media/tails-persistence-setup/TailsData/live-additional-software.conf (otherwise tails-additional-software-config pretends no ASP is configured yet). Without these custom, relaxed permissions, that would be impossible: by default, /media/tails-persistence-setup is created (presumably by udisks2) with permissions 0700 and owned by tails-persistence-setup:root. This change is safe because: 1. /media/tails-persistence-setup/TailsData is the only thing that ever gets created under /media/tails-persistence-setup; 2. TailsData, i.e. the root of the persistent filesystem, is world-readable so under normal circumstances, when Tails was started with the persistent volume unlocked, the amnesia user would be allowed to access it anyway. Still, this change does not seem to be enough to fix the UX problem we're after here. For some reason tails-additional-software-config still pretends that no ASP is configured yet, even though it does seem to have all the permissions it needs to list them: see https://labs.riseup.net/code/issues/15566#note-7 for details.
* | ASP: use && instead of ; between the two cp commandsAlan2018-04-151-1/+1
| | | | | | | | Refs: #15431
* | ASP: made clear that the data is synchronized on shutdownAlan2018-04-051-1/+1
| | | | | | | | Refs: #14598.
* | Make ASP upgrade service create a state file after bootup.bertagaz2018-03-271-0/+1
| | | | | | | | | | | | | | Same than the install service. Is usefull to have a robust way to test if the service started, and to chain things after. Refs: #14594, #14596
* | ASP: fix apt archive path in persistenceAlan2018-03-221-1/+2
| | | | | | | | Will-fix: #15431
* | ASP: fix typo in tails-synchronize-data-to-new-persistent-volume.serviceAlan2018-03-051-1/+1
| | | | | | | | Refs: #14594
* | ASP: synchronize APT data to newly created persistence on shutdownAlan2018-03-041-0/+18
|/ | | | Refs: #14594
* Merge branch 'devel' into feature/5684-screen-lockersegfault2018-02-215-22/+54
|\
| * Merge remote-tracking branch ↵bertagaz2018-02-193-0/+53
| |\ | | | | | | | | | | | | | | | 'origin/feature/14521-improve-UX-when-GDM-fails-to-start' into devel Fix-committed: #14521
| | * Don't use ${} syntax that confuses the systemd unit parser.intrigeri2018-02-181-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | The previously used syntax triggered "Invalid escape sequences in line, correcting" error messages and the corresponding ExecStart= directive was "corrected" in a way that somehow broke its functionality. For the curious: https://sources.debian.org/src/systemd/232-25+deb9u1/src/basic/extract-word.c/?hl=231#L231
| | * Truncate graphics card name if needed so the entire message fits in 254 ↵intrigeri2018-02-181-3/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | chars (refs: #14521). "plymouth display-message" does not support longer messages. Only one graphics card in current pci.ids would make the message _almost_ not fit, but let's not take any bet and ensure it'll always work even for newer graphics card with super long names: this is a troubleshooting facility in case of GDM not starting, so it'd better not itself break randomly otherwise users will be even more confused.
| | * Rephrase the error message on GDM startup failure (refs: #14521)intrigeri2018-02-181-1/+1
| | | | | | | | | | | | https://mailman.boum.org/pipermail/tails-ux/2018-February/003531.html
| | * Rephrase the error message on GDM startup failure (refs: #14521)intrigeri2018-02-081-1/+1
| | | | | | | | | | | | https://mailman.boum.org/pipermail/tails-ux/2018-February/003529.html
| | * Merge remote-tracking branch ↵intrigeri2018-02-084-21/+54
| | |\ | | | | | | | | | | | | 'origin/feature/12679-sandbox-firefox-content-renderers' into feature/14521-improve-UX-when-GDM-fails-to-start
| | * | Error message when GDM fails to start: implement the most recent proposal ↵intrigeri2018-01-031-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | (refs: #14521). See https://mailman.boum.org/pipermail/tails-ux/2017-December/003517.html
| | * | Also display a hopefully useful message with plymouth when GDM has failed to ↵intrigeri2017-12-111-9/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | start Xorg 5 times (refs: #14521) This ugly hack is needed because we have to keep count of the failures and kill GDM ourselves, otherwise the gdm3 process is still running and the service is in "active (running)" state, so OnFailure=tails-gdm-failed-to-start.service does not take effect.
| | * | Display a hopefully useful message with plymouth when the GDM service fails ↵intrigeri2017-12-112-0/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (refs: #14521) This sets up the foundations for displaying a useful error message, but it does not cover the case when GDM repeatedly tries to start Xorg and fails, which is the most interesting one wrt. #14521: when this happens the gdm3 process is still running and the service is in "active (running)" state, even once GDM manages to put itself in a bad enough shape that it can't even retry starting Xorg anymore. One way to trigger such a failure is: systemctl kill --signal=9 gdm
| | * | Intentionally break /usr/bin/Xorg when the autotest_broken_Xorg argument is ↵intrigeri2017-12-101-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | passed in the boot options (refs: #14521) This will be useful at least for manual testing of my work on #14521, and possibly even to implement the corresponding test case.