mirrors/systemd
0
0
Fork 0
mirror of https://github.com/systemd/systemd.git synced 2024-11-23 18:23:32 +08:00
Code Issues Packages Projects Releases Wiki Activity
20345a86b7
systemd/man/fido2-crypttab.sh

26 lines
1.0 KiB
Bash
Raw Normal View History

man: change license of examples to MIT-0 Quoting Richard Fontana in [1]: CC0 has been listed by Fedora as a 'good' license for code and content (corresponding to allowed and allowed-content under the new system). We plan to classify CC0 as allowed-content only, so that CC0 would no longer be allowed for code. Over a long period of time a consensus has been building in FOSS that licenses that preclude any form of patent licensing or patent forbearance cannot be considered FOSS. CC0 has a clause that says: "No trademark or patent rights held by Affirmer are waived, abandoned, surrendered, licensed or otherwise affected by this document." (The trademark side of that clause is nonproblematic from a FOSS licensing norms standpoint.) The regular Creative Commons licenses have similar clauses. For the case of our documentation snippets, patent issues do not matter much. But it is always nicer to have a license that is considerred acceptable without any further considerations. So let's change the license to the (now recommended replacement) MIT-0. [1] https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/NO7KGDNL5GX3KCB7T3XTGFA3QPSUJA6R/ Using 'git blame -b' and 'git log -p --follow', I identified the following folks as having made non-trivial changes to those snippets: Lennart Poettering Tom Gundersen Luca Bocassi Zbigniew Jędrzejewski-Szmek Thomas Mühlbacher Daan De Meyer I'll ask for confirmation in the pull request.
2022-10-26 14:02:14 +08:00
# SPDX-License-Identifier: MIT-0
man: add licenses to all files that lack one Documentation is licensed under LGPL-2.1-or-later. Scripts are MIT to facilitate reuse. Examples are relicensed to CC0-1.0 to maximise copy-and-paste for users, with permission from authors.
2021-10-01 18:44:33 +08:00
man: document new features
2020-12-08 00:18:52 +08:00
# Enroll the security token in the LUKS2 volume. Replace /dev/sdXn by the
# partition to use (e.g. /dev/sda1).
sudo systemd-cryptenroll --fido2-device=auto /dev/sdXn
# Test: Let's run systemd-cryptsetup to test if this worked.
meson: move systemd-cryptsetup to /usr/bin This was requested, though I think an issue was never filed. If people are supposed to invoke it, even for testing, then it's reasonable to make it "public".
2023-09-23 00:47:05 +08:00
sudo systemd-cryptsetup attach mytest /dev/sdXn - fido2-device=auto
man: document new features
2020-12-08 00:18:52 +08:00
# If that worked, let's now add the same line persistently to /etc/crypttab,
man/crypttab: do not recommend using /dev/sdX symlinks in /etc/crypttab This is just wrong. Quering the symlink names with udevadm is not the easiest, but I think that's the safest way for a documented example.
2023-09-23 00:27:10 +08:00
# for the future. We don't want to use the (unstable) /dev/sdX name, so let's
# figure out a stable link:
udevadm info -q -r symlink /dev/sdXn
Add recommended initramfs regeneration I recently tried adding a FIDO2-Device as an unlocking method to the LUKS2 partition containing my Fedora install. When trying to do this, I stumbled upon the here edited man files detailing how to do this. I however could not unlock my partition with my FIDO2-Device after editing /etc/crypttab and rebooting. As I found out after a while, I needed to regenerate / update my currently running / used initramfs (https://unix.stackexchange.com/a/705809). This would have most likely solved itself for me with the next kernel update install (as far as I understand). So I propose changing the files edited here to recommend or at least inform the user about this.
2023-09-22 05:52:04 +08:00
man/crypttab: do not recommend using /dev/sdX symlinks in /etc/crypttab This is just wrong. Quering the symlink names with udevadm is not the easiest, but I think that's the safest way for a documented example.
2023-09-23 00:27:10 +08:00
# Now add the line using the by-uuid symlink to /etc/crypttab:
sudo bash -c 'echo "mytest /dev/disk/by-uuid/... - fido2-device=auto" >>/etc/crypttab'
# Depending on your distribution and encryption setup, you may need to manually
# regenerate your initramfs to be able to use a FIDO2 device to unlock the
# partition during early boot.
# More information at https://unix.stackexchange.com/a/705809.
Add recommended initramfs regeneration I recently tried adding a FIDO2-Device as an unlocking method to the LUKS2 partition containing my Fedora install. When trying to do this, I stumbled upon the here edited man files detailing how to do this. I however could not unlock my partition with my FIDO2-Device after editing /etc/crypttab and rebooting. As I found out after a while, I needed to regenerate / update my currently running / used initramfs (https://unix.stackexchange.com/a/705809). This would have most likely solved itself for me with the next kernel update install (as far as I understand). So I propose changing the files edited here to recommend or at least inform the user about this.
2023-09-22 05:52:04 +08:00
# On Fedora based systems:
sudo dracut --force
# On Debian based systems:
sudo update-initramfs -u
Reference in New Issue Copy Permalink