[systemd-devel] logind on VT-less kernels, and starting a greeter on session hangs
While on VT-less seats, while all major Wayland compositors support CTRL+ALT+F(x), the drawback is that on VT-less seats and kernels, it only works when there are multiple sessions on VT-less seats to switch between, as most display managers stop the greeter when starting a session, and a large majority of the time, only one user is logged in at once. I am thinking mostly of if the session hangs, or when kscreenlocker crashes on KDE, and it instructs the user on how to login to start another session. (Also, this can happen now, but in instances where the compositor becomes totally unresponsive, the compositor or session no longer is able to handle the Ctrl+Alt+F(x) keys, and running commands then requires a remote SSH connection) I am thinking a rescue key sequence that logind itself could listen for (since it already seems to be handling some other keys like Sleep and Hibernate keys), and then in turn maybe emit a Dbus signal that login managers will respond to, and switch to or re-launch the greeter on the seat that the key sequence was pressed on. There is also the question on what key command it should be, In my mind pressing and *long holding* Ctrl+Alt+Esc seems the most logical, but then that would mean logind would get woken up every time Ctrl and Alt is hit, and that could have a slight impact on battery usage. I was also thinking pressing and holding Caps+Esc? It has to be keys on most keyboards, and it seems *some* laptops manufacturers made it their mission to not give many options. What do you think? Or is this outside of the scope of logind, and should the display manager do that instead? Thanks
Re: [systemd-devel] How to use systemd-growfs* services with GPT automount
Hi, On Tue, Oct 24, 2023 at 1:33 PM Lennart Poettering wrote: > > On Mo, 23.10.23 02:00, Nils Kattenbeck (nilskem...@gmail.com) wrote: > > > Hello, > > > > I am not sure how to get systemd-growfs-root.service to work with > > automount. The partitions are configured via systemd-repart (and the > > image created using mkosi). While the partitions are correctly grown > > upon boot, the contained filesystem is not grown to match the > > partition even though GrowFileSystem defaults to true. Is there > > anything I am missing or an easy way to troubleshoot this and get more > > information? > > > > One thing I notice is that the generator.late/-.mount unit has a > > Options=ro which as per documentation prevents growing the filesystem. > > However, the filesystem is actually mounted read-write so I assume > > this is just an artifact of the initrd. Is it not possible to grow the > > filesystem from which the initrd starts? > > Do you have "ro" or "rw" on the kernel cmdline? I have neither set on the cmdline. Greetings, Nils
Re: [systemd-devel] How to get Credential into Environment variable?
On Di, 26.09.23 04:39, chandler (s...@riseup.net) wrote:
> Hi all,
>
> I'm not quite grasping something here... I've just learned about
> `systemd-creds` and now trying to utilize it with a service which
> depends on a secret stored in an environment variable (or passed as a
> CLI option).
>
> Normally I could use a line like:
>
> `Environment=SEC=1234`
>
> Now I've:
>
> 1) Given "1234" to `systemd-ask-password -n | systemd-creds encrypt
> --name=secret --pretty - -`
> 2) Put the resulting `SetCredentialEncrypted=secret: ...` under the
> [Service] section
> 3) Failing with `Environment=SEC=%d/secret`
>
> Now `SEC=/run/credentials/myService.service/secret` but I need the value
> from the file, which I verified with a simple `ExecStart=checkEnv.sh`
> which runs `cat ${SEC}` which prints `1234`.
>
> Also tried putting the secret, e.g. "1234", into a temp file `/tmp/sec`
> and ran:
>
> `systemd-creds encrypt --name=secret --pretty /tmp/sec -`
>
> but the results are the same.
>
> How to get `SEC=1234` basically?
The credentials logic is supposed to be used *in* *place* of
environment variables. Environment variables are an awful way to pass
credentials to services, since their are inherited down the process
tree even across security boundaries by default, and there's zero
access control on them. (and they are not really compatible with
binary data or larger data, and so on)
Hence, what you are looking for is not supported and we won't support
it, because it defeats one main design goal of credentials: to require
access control on access, and not allow "greedy" inheritance down the
process tree.
Sorry if that's disappointing!
If a service insists on reading its credentials from an env var or
cmdline and supports nothing else this is of course disappointing, but
it's simply not compatible with the credentials logic, without manual
glue scripting.
We generally recommend that services support reading the credentials
from files (in which case you can point them to
$CREDENTIALS_DIRECTORY/ to read what they want), or even better:
just natively support credentials by looking at $CREDENTIALS_DIRECTORY
on their own, without being told so.
If you have an app that doesn't allow either, and really and only
wants env vars or cmdline params, then you can script around this,
with a script like this:
```c
#!/bin/bash
read -r MYCRED < "$CREDENTIALS_DIRECTORY"/mycred
export MYCRED
exec mybinary
```
you get the idea.
Lennart
--
Lennart Poettering, Berlin
Re: [systemd-devel] How to use systemd-growfs* services with GPT automount
On Mo, 23.10.23 02:00, Nils Kattenbeck (nilskem...@gmail.com) wrote: > Hello, > > I am not sure how to get systemd-growfs-root.service to work with > automount. The partitions are configured via systemd-repart (and the > image created using mkosi). While the partitions are correctly grown > upon boot, the contained filesystem is not grown to match the > partition even though GrowFileSystem defaults to true. Is there > anything I am missing or an easy way to troubleshoot this and get more > information? > > One thing I notice is that the generator.late/-.mount unit has a > Options=ro which as per documentation prevents growing the filesystem. > However, the filesystem is actually mounted read-write so I assume > this is just an artifact of the initrd. Is it not possible to grow the > filesystem from which the initrd starts? Do you have "ro" or "rw" on the kernel cmdline? Lennart -- Lennart Poettering, Berlin
