<gchristensen>
how can I debug this? systemd-run --user --shell -> Failed to start transient service unit: The name org.freedesktop.systemd1 was not provided by any .service files
<arianvp>
Step one is setting loglevel to debug
hmpffff has quit [Quit: nchrrrr…]
hmpffff has joined #nixos-systemd
hmpffff has quit [Client Quit]
hmpffff has joined #nixos-systemd
hmpffff has quit [Client Quit]
hmpffff has joined #nixos-systemd
hmpffff has quit [Client Quit]
hmpffff has joined #nixos-systemd
hmpffff has quit [Client Quit]
<andi->
arianvp: I guess that systemd-sysusers handles removing/adding users just fine in regards to never handing out the samme UID/GID? Where is that information being tracked?
<arianvp>
gchristensen: I think that's the error you get when systemd --user instance isnt running
<arianvp>
that registers itself on the user dbus as "org.freedesktop.systemd1"
<arianvp>
andi-: great question; I dont know
<gchristensen>
I definitely have one: grahamc 26183 0.0 0.0 13560 7624 ? Ss May12 0:00 /nix/store/fvh782r1d0wa4qf61c7a98f2b44hqp0v-systemd-243.7/lib/systemd/systemd --user
<arianvp>
is dbus running in the user session?
<arianvp>
oh wait; you only need one dbus running I think right
<arianvp>
gchristensen: what does busctl --user list?
<andi->
arianvp: ok, so across reboots you might have two different users have the same uid?
<arianvp>
no; because sysusers persists in /etc/passwd no?
<arianvp>
you mean across "clean slate" reboots?
<andi->
ahh, I somehow thought you'd always start with an empty /etc
<andi->
yeah, clean slate reboots where you switch generations of nixos
<arianvp>
ah sysusers.d also allows you to set the uid
<arianvp>
well I'd hope the allocation is deterministic
<arianvp>
so if sysusers.d has the same order it allocates the same id's :/
<andi->
I hope they didn't just use their hashmap again :D That isn't deterministic and made my v6 prefix change whenever I relaoded networkd
<arianvp>
andi-: it also supports instead of choosing and "id" to set the id to a path to a file
<arianvp>
it will then assign the id to whatever that pat his owned by
<arianvp>
e.g. "u postgres /var/lib/postgres" will set the uid to whatever /var/lib/postgres is owned by
<andi->
but if I create that using tmpfiles and pass a name there, what will the uid be?
<aanderse>
ok there is enough people gathered around i can rant, yeah?
<arianvp>
andi-: haha good one :P
<andi->
aanderse: recommend practicing systemd rants in #systemd first :P Just as quality measure
<aanderse>
but its a nixos rant!
<andi->
then go straight ahead
<aanderse>
generally we're supposed to be an unopinionated distro and not arbitrarily apply patches to software because we feel like it
<aanderse>
that isn't the stance all distros take, but it is the stance i have seen people claim we take
<aanderse>
recently it seems this doesn't impact systemd units in nixos at all
<aanderse>
people are applying sandboxing options way in a fashion that is way too liberal to say we're not being opinionated
<aanderse>
systemd sandboxing options are good... when you understand the software you're applying it to
<aanderse>
the same thing goeos for running software as non root users
<aanderse>
good... when you understand the software
<aanderse>
most of this doesn't apply to really new software
<aanderse>
but much of the older software stack was built with really bad assumptions in mind
<aanderse>
so applying these options without either being familiar with the source code, or deeply familiar with how the software works, seems like a really opinionated and really bad thing to do
<aanderse>
Mic92 merged a nginx sandboxing PR but only after it had an escape hatch - this seemed like a good compromise to get some users to test it on unstable, but make it real quick and easy to fallback, so i was happy with how was handled
<aanderse>
that seems like the exact opposite of what we should do
<aanderse>
blindly apply a generic set of hardening options to any module ever
<aanderse>
any time you apply any hardening option you should really understand, in my opinion
<aanderse>
</rant>
<Mic92>
aanderse: what do you mean by blindly? We also have gcc hardening flags that we apply to all builds.
<makefu>
"generally we're supposed to be an unopinionated distro and not arbitrarily apply patches to software because we feel like it" < you lost me there
<aanderse>
makefu: debian **heavily** modifies software as they see fit
<aanderse>
they pretty much maintain their own fork of a large number of projects
<aanderse>
other distros ship "vanilla" software, for the most part
<aanderse>
they try to ship what upstream "intends"
<aanderse>
makefu: does that clarify my statement?
<makefu>
okay i see, thanks for clearing up
<aanderse>
np
<aanderse>
Mic92: this can certainly be ignorance on my part, but i'm not aware of much software that was explicitly designed to depend on hardening flags not being there
<Mic92>
aanderse: I think there are some safe options like ProtectKernelTunables that we can apply to many services we have. There only very few services that ever do sysctl changes.
<aanderse>
Mic92: i agree and i want us to apply as many systemd sandboxing options as we possibly can
<aanderse>
i don't want us to apply them without knowledge of the application
<aanderse>
a PR that applies a bunch of sandboxing options on older software and then says "i don't know much about this software but it works for my one tiny use case" seems like it isn't quite ready to me
<aanderse>
sure, my quote there is sarcastic, but i hope it gets the point across
<Mic92>
aanderse: I think it's a tradeoff in maintainability. In the end one wants to reduce the amount of over all code. Some options have to be set very often.
<Mic92>
So if we have hardening options that we apply to 95 % of all modules, they can be made the default.
<aanderse>
Mic92: yeah, i mean, depending on the option i would agree
<andi->
I like being more strict but this appears to be the shotgun mode of doing it. In an ideal world we would have maintainers of our services that care (and know the software!) and those could do well informed decisions on those. We can give a guideline and maybe set one or two globals but having some magic indirection that might break another service somewhere isn't great.
<Mic92>
aanderse: personally I don't like this sandbox module either.
<andi->
My thinking here is that over time we gain more options and then just add them to the levels and random services will start breaking.
<aanderse>
andi-: yeah, that is how i see things too
<aanderse>
Mic92: i think a good compromise was reached with the nginx module. clearly hardening is desired on a module like that, but to release it in the wild with no way to pull it back when it hadn't had wide testing was scary - so the enableSandbox solved that problem
<aanderse>
nginx will get testing over a variety of users systems
<aanderse>
and hopefully breakage will be minimized for 20.09
hmpffff has joined #nixos-systemd
adisbladis has joined #nixos-systemd
<gchristensen>
debugging this weirdness with systemd and I am apparently at risk for putting adisbladis in to a mental hospital
<gchristensen>
:)
<gchristensen>
here is my debugging session with adisbladis: https://gist.github.com/grahamc/ccd67b79cc3b12f9675bbef15c2434f6 I don't have a org.freedesktop.systemd1 but I do have a session. I start sway at a tty with dbus-run-session sway. I can and do run multiple user services, systemd-run --user true works fine. systemd-run --user --shell results in Failed to start transient service unit: The name
<gchristensen>
org.freedesktop.systemd1 was not provided by any .service files