hmpffff has joined #nixos-systemd
hmpffff__ has quit [Ping timeout: 272 seconds]
<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?
<gchristensen> arianvp: ssh
<arianvp> or `busctl --user status`
<gchristensen> interested in this? it'll let me run these commands and skip the pastes
<arianvp> later; I'm about to hop in a meeting
<arianvp> andi-: I think systemd cheats; as the format isn't declarative
<arianvp> it only adds users; but doesnt delete them if you remove them from the file
<arianvp> so a bit less powerful than our script
<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> but a PR like this:
<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: 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
<flokli> gchristensen: adisbladis:, more specifically systemctl --user --wait import-environment might help
<gchristensen> yep, I'll update my gist to include that. I first run systemctl --user --wait import-environment
<flokli> from the gist, I don't really understand the problem TBH
<flokli> or what is broken
<flokli> ;-)
<gchristensen> you understand the symptom, though?
<gchristensen> note this is systemd-243 / nixos 20.03
hmpffff has quit [Quit: nchrrrr…]
<flokli> I don't use sway, but we should see if it's still a problem on master
<gchristensen> sway master?
<gchristensen> or nixpkgs master?
<gchristensen> the problem was using dbus-run-session, creating another user/session bus
hmpffff has joined #nixos-systemd
Mic92 has quit [Quit: WeeChat 2.8]
Mic92 has joined #nixos-systemd
<arianvp> *confuse*
<arianvp> andi-: I loked at the sysusers sours code
<arianvp> I do see a lot of "ordered-hashmap"
<andi-> arianvp: that might be good
<andi-> as long as it isn't the randomly seeded hashmap :D
pbb has quit [Remote host closed the connection]
pbb has joined #nixos-systemd
lukegb has quit [Ping timeout: 258 seconds]
lukegb has joined #nixos-systemd
pbb has quit [Ping timeout: 256 seconds]
pbb has joined #nixos-systemd
pbb has quit [Ping timeout: 265 seconds]
pbb has joined #nixos-systemd