<darknao>
I don't think the website team was involved in the old code, and it can be a bit difficult for someone new to the team to work on that part without any clue about how it works and put everything together
<dustymabe>
darknao: indeed - to be fair on our end we're not entirely familiar with the code either
<dustymabe>
but maybe we can work together to figure out all the pieces
<dustymabe>
ok I'm looking at the old website code locally, but weird..
<darknao>
I'm still not sure why we should have an arch selection for each single release instead of globally on that page. Last time I used this page on the old website, I was only interrested on the arm release and found it very tedious and unnecessary to click 2 times on each release to get the information I was looking for
<darknao>
I was tracking some packages version across multiple releases, but maybe that was not the intended use case
<dustymabe>
darknao: usually i'm interested in a specific package diff for a specific build so I'm already dialed in on that build and having the arch select close by is useful
<dustymabe>
maybe we can keep the global selector and have one more locally too?
<dustymabe>
or maybe to start we leave the global selector in place, but add the package diffs and see how that goes
<darknao>
could there be a case where packages version are actually not the same between arches for the same build? or that is a common scenario
<dustymabe>
if a package exists in all architectures it will be the same.. but there are architecture specific packages (i.e. s390x utils on s390x) that make it such that the package list isn't the exact same across all architectures. Which is why we have it broken out.
<apiaseck>
dustymabe: I squashed it to two commits, but only now realized some of the ammendments were included in the first one.
<dustymabe>
apiaseck: need help?
<apiaseck>
I'm curious if the build succeeds.
<dustymabe>
you can run the flake8 stuff locally to check to see if that part passes
<apiaseck>
Will do that. Regarding help - will ping you in case I'm stuck.
<apiaseck>
Thanks
<dustymabe>
fifofonix[m]: i'm going through the release notes for this weeks releases. wondering if the CIFS issue is sufficiently fixed to mark it as such or if there are still things to be worked out
<fifofonix[m]>
I think we may have three separate things going on here and two of them are worth mentioning I think.
<dustymabe>
fifofonix[m]: so there was the original bug, but now there are follow on things?
<fifofonix[m]>
Thing 1: newly occurring kerberos selinux denials (affects all kerberos ticket based mounts I think), embedded in the same BZ you're well aware of.
<fifofonix[m]>
Thing 2: DFS related cifs mount issue in the same BZ. Issues still present. Either apply the targeted SELinux weakening or change from DFS to non-DFS name/mount.
<dustymabe>
got ya. For some reason I thought thing2 was fixed (at least in rawhide)
* dustymabe
goes for some food
jcajka has quit [Quit: Leaving]
<fifofonix[m]>
Thing 3: the separate git issue i've created for crashes on testing/next associated with cifs/smb mounts. i had a separate re-occurrence of this this week. infrequent, and perhaps triggered by an issue with mounted storage or network reachability. no one else has reported this so perhaps specific to my environment so can't suggest you add to release notes.
<fifofonix[m]>
dustymabe: thing2 not fixed in rawhide yet either as of test earlier this week or maybe late last (git issue and BZ updated)
<jdoss>
is there a correct way to add a system user to a FCOS container layer?
<jdoss>
or will adduser be fine like doing in a Containerfile that isn't a FCOS layer
gursewak_ has quit [Read error: Connection reset by peer]
sentenza has joined #fedora-coreos
<jmarrero>
jdoss: I don't think we have a recommended way at the moment to do this with layering, other than use ignition on first boot. We expect /var to be empty and calling useradd tries to create: `/var/lib/sss/db/config.ldb`. We an issue about enabling creating system users https://github.com/ostreedev/ostree-rs-ext/issues/383 but I could not find any plans or issues to support "human users" atm.
<jdoss>
jmarrero: thanks for the context. As a short term fix, I was able to use vector.dev's DNF repo to install the package which seems to have solved my user problem instead of fetching the binary and useradding the vector user manually. Enabling system users would be great down the road.
<jdoss>
If I add users with USER_RECORD in the layer FCOS will respect them?
<jdoss>
because that is pretty awesome
<jdoss>
hmmmm I remember looking into adding systems with USER_RECORD a while back but I couldn't find anything with an example on doing it correct. Using homectl doesn't seem like the right place to start.
<walters>
jdoss: backing up though, if you're not intending to do human users I'd recommend units with `DynamicUser=yes`
<jmarrero>
dustymabe: lgtm
<dustymabe>
many thanks :)
<jdoss>
walters: yeah good point. Then I could use the dynamic directories too for vector. Part of the issue I am working on is vector needs a data dir and the default one is in /var/lib/vector and I can't ship that in the layer. I'd run vector in a container but I want it to access the systemd journal on the FCOS host node to ship logs to a central point
<walters>
you can, just bind mount in /var/log/journal