drakonis has quit [Read error: Connection reset by peer]
bhipple has quit [Remote host closed the connection]
drakonis has joined #nixos-dev
peelz has joined #nixos-dev
aminechikhaoui has quit [Quit: Ping timeout (120 seconds)]
aminechikhaoui has joined #nixos-dev
drakonis has quit [Quit: WeeChat 2.8]
cole-h has quit [Ping timeout: 260 seconds]
FRidh has joined #nixos-dev
alp has quit [Ping timeout: 272 seconds]
<MichaelRaskin>
jtojnar: _to_ CC wrapper or from CC wrapper? I thought the idea was that we define our own environment variable namespace, and minimise assumptions about who puts what into the environment outside the namespace
alp has joined #nixos-dev
alp has quit [Ping timeout: 265 seconds]
orivej has joined #nixos-dev
alp has joined #nixos-dev
doronbehar[m] is now known as doronbehar
orivej has quit [Ping timeout: 260 seconds]
ris has quit [Ping timeout: 258 seconds]
__monty__ has joined #nixos-dev
globin_ has joined #nixos-dev
globin has quit [Ping timeout: 246 seconds]
obadz has quit [Quit: WeeChat 2.8]
orivej has joined #nixos-dev
obadz has joined #nixos-dev
srk has quit [Changing host]
srk has joined #nixos-dev
Scriptkiddi has quit [Ping timeout: 246 seconds]
ajs124 has quit [Ping timeout: 260 seconds]
das_j has quit [Ping timeout: 260 seconds]
Scriptkiddi has joined #nixos-dev
Bunogi has quit [Ping timeout: 246 seconds]
WilliButz has quit [Ping timeout: 264 seconds]
aszlig has quit [Ping timeout: 260 seconds]
Bunogi has joined #nixos-dev
aszlig has joined #nixos-dev
WilliButz has joined #nixos-dev
das_j has joined #nixos-dev
ajs124 has joined #nixos-dev
alp has quit [Ping timeout: 272 seconds]
alp has joined #nixos-dev
_e has quit [Quit: WeeChat 2.7.1]
_e has joined #nixos-dev
<infinisil>
domenkozar[m]: asymmetric: qyliss: jtojnar: Since we can't see zoom chat anymore, here's the shared thing for the meeting notes: https://pad.riseup.net/p/6UHa_YlNaOxkWaOU1Yj0
<infinisil>
(I didn't catch the gist link though (by asymmetric I think?))
<asymmetric>
infinisil: the link by jtojnar is in there i think
<asymmetric>
the gist
<asymmetric>
line 47
<infinisil>
Ahh yes
<infinisil>
I'm just gonna inline this
<infinisil>
domenkozar[m]: Are you perhaps already writing a summary for an RFC comment?
<domenkozar[m]>
not yet, gotta do a few things now
<domenkozar[m]>
infinisil: feel free to write it if you have time
worldofpeace has left #nixos-dev ["User left"]
worldofpeace has joined #nixos-dev
<infinisil>
domenkozar[m]: Alright I'll do that then, (but also a bit later, currently eating breakfast/lunch/dinner :))
cole-h has joined #nixos-dev
primeos has quit [Quit: WeeChat 2.4]
page_ has joined #nixos-dev
page has quit [Ping timeout: 258 seconds]
primeos has joined #nixos-dev
andi- has quit [Ping timeout: 244 seconds]
primeos has quit [Client Quit]
justanotheruser has quit [Ping timeout: 240 seconds]
<adisbladis>
The problem with podman is that it's much less "integrated" than let's say docker
<gchristensen>
sure
<adisbladis>
And I couldn't figure out a good module design that allows for the full flexibility of podman
<gchristensen>
"scratch your own itch" driven flexibility? (let's move to the issue?)
<adisbladis>
You can use any number of OCI runtimes, networking plugins etc etc
<gchristensen>
all this seems fine, but still the build output should have its run-time deps purely pinned to something reasonable by default imo
<ris>
just checking i'm not going mad - as a *general rule*, we prefer build-time dependency resolution over run-time dependency resolution, right? hence the existence of makeWrapper etc...
<adisbladis>
gchristensen: Also when running rootless podman won't load /etc/containers/libpod.conf, /etc/containers/policy.json & friends
<gchristensen>
right, ris
<gchristensen>
cool, adisbladis
<adisbladis>
So I'm not sure what we even can do?
<gchristensen>
it has a list of paths it tries, maybe we can inject a good default front of the list?
<ris>
cool, just wonder if one day i'm going to have to take on the task of going through every ctypes-using python lib and hack it to perma-bind to a path
<ris>
the path of its lib that is
<ris>
the lazy option being to just stick its lib in propagatedBuildInputs
<ris>
but that's just undercover runtime-resolution
<ris>
this is a jonringer question i think
<qyliss>
can't we just do a makeWrapper for podman?
<qyliss>
I'm not sure I understand the problem...
<adisbladis>
What would we stick in the wrapper though?
<qyliss>
runc, slirp4netns, conmon
<adisbladis>
qyliss: But not crun? What if I want a cgroupsv2 only system?
<qyliss>
then use podman.unwrapped
<qyliss>
if crun makes more sense then we could default to that instead
<qyliss>
but let's at least pick _something_
<gchristensen>
right
<qyliss>
I guess this wouldn't be a makeWrapper, but a wrapping derivation
<gchristensen>
(or compiled in to the default search list, though I guess the closure size may not be desirable)
<qyliss>
Yeah, I think there should be an opt out that doesn't need a rebuild
<qyliss>
So I think a wrapper derivation would make more sense
<qyliss>
course, it still won't work without some config files IIRC?
<adisbladis>
gchristensen: OTOH the closure size of a wrapped podman is actually the real closure size of a working podman setup :)
drakonis has quit [Ping timeout: 265 seconds]
<gchristensen>
right
drakonis has joined #nixos-dev
<adisbladis>
qyliss: You'd still need appropriate subuid/subgid mappings when running as non-root
<qyliss>
I think users should get subuid/subgid ranges by default
<qyliss>
Other distros do that
<qyliss>
Implementing it sounded tricky though so I never got round to it
<adisbladis>
++
<adisbladis>
qyliss: I implemented this in the `virtualisation.containers` module
<adisbladis>
It's not that tricky
<qyliss>
oh cool
<qyliss>
we should just promote it to a default imo then, if it works
<adisbladis>
We should probably do it for every `isNormalUser = true`
<qyliss>
yeah
<qyliss>
I don't have capacity to implement any of this stuff at the moment but I'll happily review it
<adisbladis>
I looked at what Fedora were doing and replicated that
<gchristensen>
adisbladis: am I understanding then that I can't really use podman unless root has coordinated some subuid's for me?
<qyliss>
You either need to set users.users.sub[ug]idRanges, or you need to be root
<qyliss>
Most distros provide subuid and subgid ranges to users out of the box
<qyliss>
We do not
<gchristensen>
interesting, cool
<qyliss>
(But we should!)
<adisbladis>
I'm totally with you :)
<adisbladis>
I'll send a PR for that sometime tonight
<qyliss>
:D
<gchristensen>
seems we'd need to calculate a range per user?
<qyliss>
Yeah
<gchristensen>
hrm
* gchristensen
has concerns, but they're probably not reasonable
* gchristensen
trusts in y'all
<adisbladis>
gchristensen: What concerns? :)
<adisbladis>
Or just in general?
erictapen has joined #nixos-dev
<gchristensen>
picking IDs out of a range (any range) automatically is spooky, since it is plausible they're assigned to something else without us knowing at eval-or-switch time
<gchristensen>
so then the lucky user gets permissions they didn't ask for, due to the overlap
<gchristensen>
that is my concern
<qyliss>
I think we have to just hope that UIDs in the 100000s aren't being used by many users, and issue a release note
<gchristensen>
actually, yeah, I didn't know IDs could go above 65,535
<clever>
relatively recent change
<adisbladis>
I just want to say again: The scheme I chose for UIDs is copied from Fedora
<gchristensen>
seems it'll be fine :)
<gchristensen>
like I said, they're probably not reasonable and I didn't feel like I needed convincing :P that is part of what I like so much. everybody is wicked smart and capable. I like being around y'all.
<qyliss>
<3
<gchristensen>
(not like I'm the gatekeeper anyway)
<worldofpeace>
it seems to have a lot of associated tags according to github: 2.3.4 2.3.3 2.3.2 2.3.1 2.3
alp has quit [Ping timeout: 272 seconds]
<infinisil>
> nix.version
<adisbladis>
Huh
<{^_^}>
"2.3.4"
<infinisil>
> nixUnstable.version
<{^_^}>
"2.4pre7346_5e7ccdc9"
<adisbladis>
Where are uids set if they're not explicitly set in configuration.nix?
<ma27[m]>
worldofpeace: you're right, sorry. You may want to take a look at fc14213d2da7302b237dfe5ca51f6f4d9af34e5c though where the message was improved
<adisbladis>
This confuses the hell out of me
<infinisil>
Oh is there a uid/gid discussion?
* infinisil
reads backlog
<adisbladis>
Let's say `config.users.users.adisbladis.uid` evaluates to null
<ma27[m]>
worldofpeace: could this be related to the fact that the default-values of the options you changed are of type `str`, but this is a store-path? At least that's how I'd interpret the commit I posted in my prev message :)
<adisbladis>
Where is it actually set to 1000 ?
<clever>
adisbladis: at runtime, a perl script will find an unused id and assign it
<adisbladis>
"a free UID is picked on activation" :/
<adisbladis>
Damn it
<clever>
adisbladis: there is also a json file to track what uid was picked, so if you delete a user, then re-make it, the same uid gets picked
<infinisil>
Yeah, /var/lib/nixos/{g,u}id-map
<adisbladis>
clever: Maybe you saw the subuid/subgid discussion
<infinisil>
It only generates dynamic uids in the range 1000-29999 for normal users
<infinisil>
Ah
<adisbladis>
infinisil: Yes, I know that.
<infinisil>
And what's the problem with using ranges above that?
<infinisil>
Ahh
<infinisil>
Say there's two users with uid's 1000 and 1005, you want the first one to have a range from 1000 to 1001?
<infinisil>
1004 I mean
<adisbladis>
100000:65536, 165536:65536 and so on
<infinisil>
Huh?
<infinisil>
Yeah I still don't get what you want
<gchristensen>
that is a large number of uids per user
<gchristensen>
what is themax?
<MichaelRaskin>
infinisil: these are UIDs permitted to use for mapping non-root UIDs in user-spawned containers
<MichaelRaskin>
The range notation means 100000 to 100000+65536, 165536 to 165536+65536
<gchristensen>
what is the highest possible uid?
<adisbladis>
A question comes to mind: Why are uids assigned in update-users-groups.pl and not in the nix eval?
<adisbladis>
If it's because of mutableUsers I'm gonna go nuts
<adisbladis>
And table flip & do all sorts of crazy stuff
<gchristensen>
adisbladis: that is definitely part of it, but also IDs should be stable from eval to eval
<infinisil>
adisbladis: You can't map usernames to uid's automatically in a pure way
bhipple has joined #nixos-dev
<infinisil>
So assigning uids at runtime is necessary because the uid field can be null
<worldofpeace>
ma27: gnomeFilePath should be a string that I provide through passthru
<adisbladis>
:/
<adisbladis>
This sucks big time
<gchristensen>
it is where the rubber meets the road :)
<gchristensen>
(yes)
<qyliss>
what if we only assign subuid ranges automatically for users with static IDs (for now)?
<infinisil>
adisbladis: I did just a few days ago have a discussion with some people on this. The only way to resolve this is to have some nixos-generate-uids command (but hopefully integrate it better), which would write something like /etc/nixos/uid-map.nix (but probably a json file rather)
<gchristensen>
seems a bit arbitrary and confusing
<adisbladis>
qyliss: I'm just gonna guess here, but I guess most people don't have static uids
<worldofpeace>
is ofborg ok today? did the eval command and nothing happened.
<MichaelRaskin>
People never have static uids! There account might, though.
<adisbladis>
worldofpeace: Ofborg has been sampling the moonshine
<gchristensen>
uh oh
<gchristensen>
cole-h: d'you know of anything? :)
<infinisil>
adisbladis: And with that, uid's would be known at eval time already
<cole-h>
inb4comment filter down again
<cole-h>
Nope, comment filter up
<worldofpeace>
adisbladis: oh no. I'm not sure the sparkles will work on this one then
<cole-h>
worldofpeace: Maybe related to the fact I queued up some evals earlier because they had no labels and no failing status (your PR seems to be going now)
<worldofpeace>
cole-h: as you send that it worked
<cole-h>
:P
<cole-h>
Yeah, I just opened your PR again
<qyliss>
I don't think there would be anything wrong with encouraging people to have static uids
<cole-h>
I was also gonna suggest a re-eval if nothing else came up. That error message is really bizarre.
<adisbladis>
qyliss: Just very confusing
<qyliss>
The whole UID situation is
<adisbladis>
Side note: I wist `mutableUsers` would die in a fire...
<adisbladis>
wish*
<qyliss>
adisbladis++
<{^_^}>
adisbladis's karma got increased to 55
<gchristensen>
heh
<adisbladis>
It feels so counter to the whole NixOS ethos
<qyliss>
strong agree
<adisbladis>
It _is_ possible to make this scheme work, even for users without static ids
<worldofpeace>
I've never gotten to using non-mutableUsers 👀, I locked myself out trying
<cole-h>
btw worldofpeace @GrahamcOfBorg and @ofborg do the same -- gchristensen has expressed interest in decoupling the bot from his wonderful name, which is why I use @ofborg instead :P
<adisbladis>
It's just that the only way I came up with to fix that makes `config.users.users.adisbladis.subUidRanges` eval to `[]` even though the file on disk will contain mappings
<adisbladis>
So `users.users.adisbladis.subUidRanges = lib.mkForce [];` is broken
<adisbladis>
With my solution
<gchristensen>
ouch
<worldofpeace>
cole-h: yep, I've become attached to the GrahamcOfBorg though. but I guess now is the time of detachment.
* gchristensen
wonders a bit oabout how subuidranges works w.r.t. ldap
<cole-h>
Just noticed your edit on the PR so wanted to make sure you knew ;)
<cole-h>
And unfortunately it has the same issue, after a re-eval worldofpeace....