Re: [systemd-devel] systemd prompts for luks key, but keyfile provided in crypttab
Alex gmail.com> writes: > > > I was advised on IRC to post this issue here after trying IRC, forums, searches, man pages, wikis, etc. > > During init, systemd asks for the passphrase of non-root LUKS drives when they are added to crypttab even though a keyfile is specified. The keyfile is the same one I'm using to open (old) truecrypt drives (also with crypttab) - those open fine and don't ask for the passphrase. > > /etc/crypttab looks like this: > > tcrypt_drive1/dev/sdXY /path/to/keyfiletcrypt > tcrypt_drive2/dev/sdYX /path/to/keyfiletcrypt > luks_drive1 UUID=$UUID/path/to/keyfile > luks_drive2 UUID=$UUID/path/to/keyfile > > What I've tried so far, in no particular order: > > - Checking that crypttab's formatting is correct > - Checking that keyfile has proper permissions > - Adding and/or removing the 'luks' flag to the luks drives in crypttab > - Specifying an entry in /etc/fstab for where the luks drives should be mounted > - Specifying an (identical) keyfile not being used by the tcrypt drives > - Removing the tcrypt drives from crypttab and leaving only the luks drives > - Using /dev/sdXY instead of UUID > - Reversing the order of the tcrypt and luks drives in crypttab > - Rebuilding initramfs > - Checking that crypttab was not present in initramfs > > Note: LUKS drives open fine if passphrase is manually typed in when systemd prompts for it, as well as post-init when using cryptsetup and specifying the keyfile. What cryptsetup command do you use to open the device? My best guess is the different handling of the keyfile itself. Afaik, systemd-cryptsetup will use the full keyfile to open. That includes any trailing new line. Depending on how you use cryptsetup, it will handle they keyfile differently (see "Notes on Password Processing" in cryptsetup(8)). You should try removing any trailing new lines from the keyfile. Jan ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd prompts for luks key, but keyfile provided in crypttab
I was advised on IRC to post this issue here after trying IRC, forums, searches, man pages, wikis, etc. During init, systemd asks for the passphrase of non-root LUKS drives when they are added to crypttab even though a keyfile is specified. The keyfile is the same one I'm using to open (old) truecrypt drives (also with crypttab) - those open fine and don't ask for the passphrase. /etc/crypttab looks like this: tcrypt_drive1/dev/sdXY /path/to/keyfiletcrypt tcrypt_drive2/dev/sdYX /path/to/keyfiletcrypt luks_drive1 UUID=$UUID/path/to/keyfile luks_drive2 UUID=$UUID/path/to/keyfile What I've tried so far, in no particular order: - Checking that crypttab's formatting is correct - Checking that keyfile has proper permissions - Adding and/or removing the 'luks' flag to the luks drives in crypttab - Specifying an entry in /etc/fstab for where the luks drives should be mounted - Specifying an (identical) keyfile not being used by the tcrypt drives - Removing the tcrypt drives from crypttab and leaving only the luks drives - Using /dev/sdXY instead of UUID - Reversing the order of the tcrypt and luks drives in crypttab - Rebuilding initramfs - Checking that crypttab was not present in initramfs Note: LUKS drives open fine if passphrase is manually typed in when systemd prompts for it, as well as post-init when using cryptsetup and specifying the keyfile. Input appreciated. Thank you, ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [ANNOUNCE] systemd-223 around the corner
Hi Following our ~2 week release plans, we intend to release v223 early next week. If anyone has open issues that need to be resolved before a release, please speak up. Right now, the changes consist of mostly bugfixes and a few configuration additions. I'll commit the full NEWS tomorrow. Thanks David ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Completion of error handling
On Thu, 23.07.15 08:55, SF Markus Elfring (elfr...@users.sourceforge.net) wrote: Heya, > I would like to continue the clarification of open issues > around a topic like "Completion of error handling". > https://github.com/systemd/systemd/issues/644 > > I hope that the amount of unchecked return values can be reduced > further in affected source files by the reuse of dedicated > software development tools. > Which source code analysis approaches would you like to reconsider > once more? We are regularly checking the systemd sources with coverity and the llvm/clang analyzer. > I wonder also about the status of some function implementations > which return zero (or NULL) but no other value. So, what precisely are you wondering about? Also, on github, you keep posting stuff that looks like you are a bot. To prove you are not a bot, can you please tell me what five times 15 is? Thanks, Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Looking for experiences formalizing an API for journal messages
On Thu, 23.07.15 09:17, Anne Mulhern (amulh...@redhat.com) wrote: > Hi! > > We all know that using the journald native API it is possible to enrich the > log > entry data w/ key/value pairs, although this facility is Linux only. > The set of key/value pairs which a message may log to the journal can > constitute an API with which a logging entity can communicate alerts to > consumers > of this information. Clearly this requires an agreement on an API between the > logging > entity and the consumer of the journal entries. > > Are there existing projects that have used this facility in a principled, > coordinated way with some success or have there been any interesting failures > along those same lines? systemd of courses uses its on its own, and we tried to document the fields we use in systemd.journal-fields(7), though it might be slightly incomplete. But yes, this is indeed API, and deserves complete documentation, like any C API, any D-Bus API or a any REST API would need too. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Looking for experiences formalizing an API for journal messages
Hi! We all know that using the journald native API it is possible to enrich the log entry data w/ key/value pairs, although this facility is Linux only. The set of key/value pairs which a message may log to the journal can constitute an API with which a logging entity can communicate alerts to consumers of this information. Clearly this requires an agreement on an API between the logging entity and the consumer of the journal entries. Are there existing projects that have used this facility in a principled, coordinated way with some success or have there been any interesting failures along those same lines? Thanks for your help, - mulhern ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Completion of error handling
Hello, I would like to continue the clarification of open issues around a topic like "Completion of error handling". https://github.com/systemd/systemd/issues/644 I hope that the amount of unchecked return values can be reduced further in affected source files by the reuse of dedicated software development tools. Which source code analysis approaches would you like to reconsider once more? I wonder also about the status of some function implementations which return zero (or NULL) but no other value. Are you interested to clarify corresponding details a bit more? Regards, Markus ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
