Hi,
We are discussing adding support for coreos's fleet to control a user
session of systemd.
On paper it is perfect to run a distributed application in an
infrastructure without root access.
The code changes to do this are very small; we are hesitant to go forward
as we are not clear what is the
On Tue, 2016-03-29 at 23:20 +, Mantas Mikulėnas wrote:
> Afaik, udev only re-emits a uevent once it's done processing all the
> rules – this part is by design. So in your case, while udev worker 1
> is still waiting for the RUN to finish, worker 2 receives a kernel
> uevent for the cryptsetup d
Afaik, udev only re-emits a uevent once it's done processing all the rules
– this part is by design. So in your case, while udev worker 1 is still
waiting for the RUN to finish, worker 2 receives a kernel uevent for the
cryptsetup device and quickly reemits it. (See the output of "udevadm
monitor",
I have a rule like this:
ACTION=="add", SUBSYSTEM=="block", ENV{ID_FS_TYPE}=="crypto_LUKS",
ENV{ID_FS_VERSION}="1", RUN+="sh -c 'echo password | cryptsetup open
$devnode luks-$env{ID_FS_UUID_ENC}'"
Okay, my real rule isn't so security braindead, but the above will
suffice for concept. :)
What I
Hello,
I’m new to this list and maybe it’s not the correct one, but I have not found
which one. So please redirect me if needed.
I’m running systtemd
#systemctl --version
systemd 215
+PAM +AUDIT +SELINUX +IMA +SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ -SECCOMP
-APPARMOR
I’m trying to setup seal
> From: Mantas Mikulėnas
>To: John
>Cc: Systemd
>Sent: Tuesday, March 29, 2016 1:22 AM
>Subject: Re: [systemd-devel] Input on a systemd service for kodi and
>strangeness with permissions on /dev/null (systemd 229)
>
>Those actually look like typical permissions that a /dev/tty* device would
