heads up: julia has a bunch of incorrect Provides (bug 2291191)
Worth a bit of wide distribution as I'm sure I'm not the only one who got burned: https://bugzilla.redhat.com/show_bug.cgi?id=2291191 -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [Rpm-maint] [rpm-software-management/rpm] Return to Tralla La or: RPM in C++ (Discussion #2983)
> As such, moving to C++ now will probably make it harder to move to Rust later. Well, maybe. My original comment here remember was about how we very intentionally moved rpm-ostree to "C compiling as C++" explicitly to bridge with cxx.rs. This...kind of worked in some ways, and definitely didn't in others - although I'd say at least 50% of that is just not executing well enough probably. Using some C++ definitely doesn't exclude Rust in the future either. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2983#discussioncomment-8946642 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Return to Tralla La or: RPM in C++ (Discussion #2983)
> For starters, it's a show-stopper as a bootstrapping dependency for something > as early in that chain as rpm. (Threading this) do you have a link to these discussions? There's a *ton* of work on bootstrapping Rust (and systems in general) on self-hosting OSes/distributions. The [GUIX one](https://guix.gnu.org/en/blog/2023/the-full-source-bootstrap-building-from-source-all-the-way-down/) is pretty cool. And for sure Rust gets handled as part of that, it's well documented and understood. I get that people who want to do something similar for self-hosting rpm-based systems would want to build rpm pretty early and switch over a bootstrap process to using it, but I'd imagine there's quite a bit of stuff that needs to be done using not-RPM before that that maintaining such a system would be quite close to needing to maintain two different build systems anyways, and having Rust in that set in addition to other compilers and toolchains that are already needed seems like not a large addition. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2983#discussioncomment-8877438 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Return to Tralla La or: RPM in C++ (Discussion #2983)
I have some experience with this; we did a similar thing in rpm-ostree starting around https://github.com/coreos/rpm-ostree/pull/2336#issuecomment-739556744 The rationale there was actually to aid porting to Rust, because we could use https://cxx.rs/ There were a lot of things there, see various PRs like https://github.com/coreos/rpm-ostree/issues?q=label%3Aproject%2Fc%2B%2B+is%3Aclosed around that time (I didn't label all of them, there were a lot). Definitely dealing with NUL terminated strings versus C++ strings *and* Rust strings was and is a notable pain. Probably the biggest ergonomic problem was exceptions...Rust and C align there, and "standard" C++ doesn't. Of course it's possible to use C++ without exceptions...but, it's an ecosystem bifurcation. > It is a ridiculously large and complicated language Yes. Not to be That Person but...I dunno, I have a pretty strong opinion that Rust is the right choice for systems software, and for those bits you are rewriting, it can pay itself back. Rust is also very complex and was a huge learning curve for me (and others). The trap with C++ in a nutshell IMO is that it can feel very high level, yet low-level things like string_view use-after-frees will just come and bite you. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2983#discussioncomment-8869019 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [OS-BUILD PATCH 0/3] configs: netfilter: update settings
From: Colin Walters (Red Hat) on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2823#note_1739124559 Today, podman (really https://github.com/containers/netavark/ ) still uses these compat interfaces...I'm a little surprised that there's no "can run a container" gating here on MRs. I think we need to more formally track dependencies of these iptables interfaces before we can remove them. (To be clear I am not sure this is the MR that caused this behavior, but it's my best guess) -- ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: EncourageI686LeafRemoval Change: Please make sure it's actually a leaf package
On Mon, Jan 15, 2024, at 8:57 AM, Fabio Valentini wrote: > Hi all, > > I've been made aware that there has been a cascade of packages that > dropped i686 support in Rawhide, most of them referencing my > EncourageI686LeafRemoval Change Proposal, but none of which *actually > are* leaf packages: > > https://src.fedoraproject.org/rpms/composefs/c/b95af99 This one should be fixed by https://src.fedoraproject.org/rpms/composefs/c/c840e7496ad9a0a008903a4cfe5d38c22f49fd54?branch=rawhide > https://src.fedoraproject.org/rpms/xdg-desktop-portal/c/93310f7 > https://src.fedoraproject.org/rpms/gdm/c/940885b > https://src.fedoraproject.org/rpms/sssd/c/e0023ec I went ahead and pushed changes to these 3. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: EncourageI686LeafRemoval Change: Please make sure it's actually a leaf package
On Mon, Jan 15, 2024, at 8:57 AM, Fabio Valentini wrote: > Hi all, > > I've been made aware that there has been a cascade of packages that > dropped i686 support in Rawhide, most of them referencing my > EncourageI686LeafRemoval Change Proposal, but none of which *actually > are* leaf packages: > > https://src.fedoraproject.org/rpms/composefs/c/b95af99 Yes, this is what started it and we didn't realize the scope. > It looks like at least some of these changes were mistakenly pushed to > Rawhide while they should only apply to ELN / RHEL>=10? Agree, this is the simplest thing to do for now. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: goal: booting with an empty /etc
On Mon, Dec 11, 2023, at 12:31 PM, Neal Gompa wrote: > > We're currently not allowed to use /usr/etc (not that I like that path > anyway) because it breaks RPM-OSTree. My understanding is that this > directory is reserved by RPM-OSTree for storing pristine copies of > /etc content for each OSTree commit. If there was general consensus on using /usr/etc in upstreams/OSes/distros outside of having it be an implementation detail of ostree (mostly today) then we could certainly figure out how to support having content from RPMs (and other sources) in /usr/etc. But consensus has been for projects to use other places (/usr/share or /usr/lib) - which I agree with too - so there's no need to keep bringing this up AFAICS. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [Rpm-maint] [rpm-software-management/rpm] SOURCE_DATE_EPOCH=0 not clamping file mtime (Issue #2679)
ostree always uses zero for mtime of files it writes because there are no timestamps in the file format at all. And in order to have sharing via hardlinks, there's then the question of what time to apply to that inode. If there was a way in a Unix filesystem to have no timestamp at all, we'd definitely do that! In Rust terms, ideally `stat()` would return `Option`. Longer term though, we're moving towards https://github.com/containers/composefs which will give us in-memory/on-disk sharing even if we just let file timestamps float to "whatever", which will be helpful here. Also, it's likely in that world that we could consider switching to canonicalizing the on-disk (in EROFS) timestamp to e.g. something like the overall build's SOURCE_DATE_EPOCH, which could definitely be non-zero. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2679#issuecomment-1739079658 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: An update on RHEL moving to issues.redhat.com
On Mon, Sep 18, 2023, at 3:57 AM, Petr Pisar wrote: > V Fri, Sep 15, 2023 at 01:27:23PM -0400, Colin Walters napsal(a): >> To state the blindingly obvious thing, RHEL made a decision to centralize on >> Gitlab. Having Fedora be on pagure creates IMO unnecessary friction for me. >> I would be quite curious to get some sort of survey of other engineers for >> how they feel. > > My selfishly preferable option is not to use Gitlab.com for Fedora exactly > because RHEL uses Gitlab.com. The reason is very practical: You need separate > accounts for the two projects and GitLab.com is not good at using multiple > accounts simulatenously. Having different systems makes to problem go away and > my life easier. I use https://addons.mozilla.org/en-US/firefox/addon/multi-account-containers/ for this and other places where I also have work and personal accounts - solves the problem nicely for me. (Now, one other special twist with two-account gitlab (and github) is dealing with ssh keys and remotes, but that's not too hard to solve either) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: An update on RHEL moving to issues.redhat.com
On Fri, Sep 15, 2023, at 4:12 PM, Neal Gompa wrote: > On Fri, Sep 15, 2023 at 1:28 PM Colin Walters wrote: >> >> >> My point is only partly about the HTML, but about the ecosystem surrounding >> it (CI is a really big one) but really the total user experience (account >> system, uptime, moving issues), etc. >> >> The bigger point I want to make here is that one of the roles of Fedora >> obviously is to be an upstream for RHEL. To state the blindingly obvious >> thing, RHEL made a decision to centralize on Gitlab. Having Fedora be on >> pagure creates IMO unnecessary friction for me. I would be quite curious to >> get some sort of survey of other engineers for how they feel. I'm sure >> there's some that disagree with me, to be clear - at least one already >> responded. >> > > Fedora is also the upstream to Amazon Linux. Yes, this is a valid point. However, I think there are - you know - rather a *few* notable differences between the two. Starting with: I am pretty sure still today that Red Hat pays for the time of most people who work on the existing infrastructure and the server bills, and has done so for the entire 19 year existence of Fedora. Also of salient note, to the best of my knowledge the dist-git equivalent for Amazon Linux's isn't public. CentOS Stream is, and synergy between the two is exactly what I'm talking about. We have no idea what source control they use for their forks of packages; I somehow doubt it's gitlab or pagure, but who knows. But still your point is valid in that it *would* be interesting to know what Amazon Linux folks think. > It is (partly/indirectly) > an upstream to other RPM distributions. If you're implying we (Fedora) > need to follow what our downstreams do for development; I think using absolute terminology (here, "need") is setting up a strawman. I personally think of things much more in terms of "centers of gravity", that influence each other. I'm saying that the influence and needs of those of us who must use gitlab.com/redhat to succeed at our jobs should matter a not small amount. Also to be very clear - I consistently use my personal email for FOSS interactions; I'm not speaking for "Red Hat" as any kind of whole. I am expressing my personal, day to day annoyance at having to use 3 different git forges to succeed at my job (all at the same company!), and it would be a notable improve to go down to two. (But again again, I am *sure* there are those who disagree with me too! Would love to maybe do a survey) But, eh. We could just leave this as the status quo; we all have other problems to solve too. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: An update on RHEL moving to issues.redhat.com
One thing I find amusing about this list (which like some others is kind of a long-running soap opera that happens to sometimes produce software as a side effect) is that many times, I can see just two bits of information: - The subject of the email - The name of the person responding And I basically *know* what they're going to say. Maybe one morning I'll be drinking my coffee, reading a thread like this that has "issues.redhat.com" in the Subject and see e.g. Kevin Kofler reply, open up the email and he'll say actually something like "JIRA is so awesome! I love the query language!"¹ and I'll just spew coffee all over my keyboard laughing in surprise. We could all chose to reply to threads we ordinarily wouldn't, in a different way - just to, you know, spice things up a bit. Keep the viewers^Hreaders entertained. (This is a point about the list overall and this thread somewhat specificially, but only partially your reply; I was *pretty sure* since you replied you'd be disagreeing. But honestly that's *mainly* because email doesn't have "thumbs up" style emoji reactions that would be useful in scenarios like this. Because sending an email that just says "+1" or "I agree" is a lot of noise/overhead...) On Thu, Sep 14, 2023, at 8:50 AM, Fabio Valentini wrote: > Switch GitLab and Pagure in that statement and I could say the exact same > thing. My point is only partly about the HTML, but about the ecosystem surrounding it (CI is a really big one) but really the total user experience (account system, uptime, moving issues), etc. The bigger point I want to make here is that one of the roles of Fedora obviously is to be an upstream for RHEL. To state the blindingly obvious thing, RHEL made a decision to centralize on Gitlab. Having Fedora be on pagure creates IMO unnecessary friction for me. I would be quite curious to get some sort of survey of other engineers for how they feel. I'm sure there's some that disagree with me, to be clear - at least one already responded. ¹ To be clear, I am also not a JIRA fan, but that's a mostly orthogonal debate... ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: An update on RHEL moving to issues.redhat.com
On Wed, Sep 13, 2023, at 1:44 PM, Matthew Miller wrote: > On Mon, Sep 11, 2023 at 09:20:09AM -0700, Adam Williamson wrote: >> IIRC it was a condition of that proposal that we wind up on a hosted >> version of the *open source* release of gitlab, which is something we >> managed to talk gitlab into doing for us. IMBW, though, it was a while >> ago. > > Short version is: yes, we did talk them into that with an informal plan, and > then someone higher up at gitlab pulled the plug on the idea. FWIW I interact with pagure rarely enough that it is somewhat painful to context switch each time. I accept having to deal with both github and gitlab, but going from 2 to 3 has a real cost, particularly around things like CI systems. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: allow overriding buildtime and hostname via environment variable (Issue #2603)
> But people consider both BUILDTIME and BUILDHOST very useful for figuring out > where/when/who exactly build a package. For Fedora using Koji, there is always exactly one Koji build for a given NEVRA, and the server side metadata contains the build host. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2603#issuecomment-1714171760 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: detect filesystem capabilities before starting a transaction (Issue #2637)
xref https://github.com/containers/storage/pull/1608 -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2637#issuecomment-1699140774 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: Adding Passim as a Fedora 40 feature?
On Fri, Aug 25, 2023, at 7:42 AM, Richard Hughes wrote: > Hi all, > > I was thinking of adding Passim as a default-installed and > default-enabled dep of fwupd in the Fedora 40 release. Before I create > lots of unnecessary drama, is there any early feedback on what's > described in https://github.com/hughsie/passim/blob/main/README.md > please. Since this isn't really Fedora specific I started https://github.com/hughsie/passim/discussions/7 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [Rpm-maint] [rpm-software-management/rpm] Replace fakechroot with proper container technology (PR #2559)
It's worth noting that rpm-ostree has been isolating individual scripts (e.g. `%post`) with bwrap for a long time now. That's distinct from the test suite only usage here, but just FYI. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2559#issuecomment-1621273057 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] docs/users_and_groups: Mention DynamicUser (PR #2558)
Well, the doc is talking all about sysusers.d, which is (today) only implemented by systemd... I coincidentally recently did https://github.com/ostreedev/ostree/pull/2914 which updates the ostree equivalent of this section, and intentionally talked about `DynamicUser=yes` there because it entirely removes a big problem domain. It's IMO quite relevant for RPM because a packager or upstream developer may very likely be referred to this page (by another packager e.g.) and very commonly the best change to adopt `DynamicUser=yes` upstream, and *not* to port from running `useradd` in `%post` to `sysusers.d`. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2558#issuecomment-1614787917 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] docs/users_and_groups: Mention DynamicUser (PR #2558)
Because it really is just better (where its possible to use). You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/2558 -- Commit Summary -- * docs/users_and_groups: Mention DynamicUser -- File Changes -- M docs/manual/users_and_groups.md (7) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/2558.patch https://github.com/rpm-software-management/rpm/pull/2558.diff -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2558 You are receiving this because you are subscribed to this thread. Message ID: rpm-software-management/rpm/pull/2...@github.com ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: Towards enabling rpm sysusers integration
On Thu, Jun 29, 2023, at 3:55 AM, Panu Matilainen wrote: >> last time I looked auditd is started later than >> systemd-sysusers. Hence not sure if sysusers would actually generate >> audit messages that auditd could pick them up. > > For the rpm integration, "started later" is irrelevant as the user/group > creation takes place during rpm transactions. Right, and that leads to an important point: for Anaconda based installations that run dnf/rpm in a special installation environment, unless one has gone to significant effort to inject some auditing setup into that, you aren't going to get events. And the 90% case in cloud environments is to boot from pre-built images which will already have these users enabled (sure you could audit user events from your build environment but...why?). So at best, the system user events only work for software injected *later*. And even then, how much sense does it really make to audit the useradd component of the install instead of the actual installation? And there's already rpm-plugin-audit for those who want that... Anyways though, it's probably not a hard patch to add the auditing to sysusers. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [HEADS UP] util-linux based on new mount API coming to rawhide/f39
On Tue, Mar 21, 2023, at 8:16 AM, Karel Zak wrote: > Hey all, > > > util-linux v2.39-rc1 coming to rawhide, Release Notes: > https://kernel.org/pub/linux/utils/util-linux/v2.39/v2.39-ReleaseNotes > > I usually don't report util-linux Fedora updates, but this one is > special. This new version provides libmount with support for new > kernel mount API (syscalls fsconfig, fsmount, open_tree, etc.). > > Some kernel parts may not be fully ported to the new API. Unfortunately, > the reliable way to detect possible issues is to test all less usual use > cases and mount options combinations in the real distribution. Looks like this broke our mounting of zram: https://github.com/coreos/fedora-coreos-tracker/issues/1462 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: DNF Sytem Upgrade requirements for an F37 → F38 upgrade
On Wed, Mar 29, 2023, at 6:08 PM, Fabio Valentini wrote: > > I don't really want to throw money out the window just because DNF > eats up all the memory it can :( Everyone needs to internalize: This has nothing to do with DNF, really. It's about the *size of the repository metadata*. Every single time someone adds a new package into the single "Fedora" rpm-md repo, that makes clients going OOM a bit more likely. Every single time there's a new package, it makes it more likely that a client will hit a timeout downloading the repodata and fail to get that critical kernel security update. Even doing the obvious thing and splitting off e.g. a `fedora-devel` rpm-md repo (as is done kind of done in RHEL with CRB) that had all the -devel and Go/Rust etc. packages would likely create a huge amount of savings. Also as I said in an earlier thread, relating to SBCs but also small cloud instances - we also have image-based editions; these are Fedora systems too. rpm-ostree will not download the rpm-md by default, so is immune to this. And particularly after https://fedoraproject.org/wiki/Changes/OstreeNativeContainerStable - the UX for managing these is the same as podman/docker style application containers. You don't pay the cost of downloading the rpm-md on each client. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [Rpm-maint] [rpm-software-management/rpm] RPM with Copy on Write (PR #2378)
I referenced this effort in https://marc.info/?l=linux-fsdevel=167794198604510=2 - my PoV is that the rpm-cow effort makes some sense. I thought a lot though about hard requiring reflinks for ostree though and determined it was not viable. There are too many people that use e.g. ext4. And even if we stopped supporting new installs with that, IMO we need to support in-place upgrades for rpm systems deployed w/ext4 (or xfs without `-m reflink=1`) for a (really) long time. On the ostree side I thought about hard requiring reflinks and just concluded it was not viable to have two different code paths. What ultimately I think will work better here is using overlay-style filesystems. From my PoV composefs or something similar is the successor to ostree. And that type of overlayfs style approach Just Works even on non-reflink filesystems (albeit less efficiently sometimes). So there's no concerns with in-place upgrades, and that's ultimately why I think it's a more viable approach for both bootable host systems and containers. (Now, how exactly one would try to tie something composefs-like into something that feels more traditional-rpm like is a bit more of an open question; would a higher level tool like yum/zypper end up making composefs snapshots locally, etc? We'll be doing this for rpm-ostree at least, but it was designed from the start for that) -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2378#issuecomment-1458653493 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: OpenSSH: hardening hostkeys permissions
On Thu, Dec 8, 2022, at 9:51 AM, Daniel P. Berrangé wrote: > I think the "Upgrade/compatibility impact" section ought to call out the > possible risk with config mgmt tools like puppet/ansible, that might be > managing SSH host keys and their permissions/ownership So that was done with: > The problem we expect is that after implementing the change we can > lose the remote access to the hosts because sshd will reject starting > because of group reading permissions. This should be covered by > upgrade script, though we still may come across some issues, > especially if you use host keys in non-standard location. This is an accurate statement. However, I am sure some system administrators who end up getting surprised and affected by this and lose remote access to their systems and have to take a trip to the data center or whatever may be more emotional ;) There's some related discussion to this in https://src.fedoraproject.org/rpms/openssh/pull-request/39# including an idea to use the MOTD as a way to warn users. I think we at a minimum need to implement a warning *now* and push it out to Fedora stable releases before even trying to land this. Further, I would suggest having a phase between "warn" and "your ssh keys in a nonstandard location no longer work". The in-between phase would be something like "ssh connections in this setup are subject to a 3 second delay, and also fail 1/5 of attempts" or so. That should make the change a lot more likely to be seen. It won't help the admins that only use ssh rarely and somehow miss this change unfortunately. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: An application to help find cloud images (in multiple clouds)
On Tue, Jan 31, 2023, at 9:10 PM, Major Hayden wrote: > My team at Red Hat came up with the idea of a locator service that > would gather data from upstream locations (AWS, Azure, GCP, and > others), compile the image data into a common schema, and make it > available for API calls and a web frontend. I hope we could also share a common model with CentOS Stream, which doesn't seem to have any answer at all today? > > CoreOS already does something like this and offers a JSON[1] file with > a standardized schema that makes it easier to find the current released > in various locations. Yep, would love to think about how we can share code/approaches here with other Fedora images! ___ cloud mailing list -- cloud@lists.fedoraproject.org To unsubscribe send an email to cloud-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/cloud@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Improving Fedora boot time when libvirt is installed
On Thu, Jan 19, 2023, at 11:53 AM, Gordon Messmer wrote: > On 2023-01-19 00:55, Lennart Poettering wrote: >> >> What you could do is split up the problem: have iscsi-starter.service >> or so, that is separate from the iscsi.service main service. The >> former's job would be to scan if iscsi volumes are configured. If it >> finds configured ones, it would then issue "systemctl start --no-block >> iscsi.service" to enqueue a start job for the real thing. > > > Something like that was suggested last year, and Colin Walters objected, > for what that's worth. > > If the PR to allow installing only the "core" storage drivers is > rejected, then I'll work on a PR to implement this change instead. Heh well, I'm obviously going to defer to Lennart if he has an opinion on how you should do something with systemd. It wouldn't even be the first thing calling `systemctl start` in the boot process...sadly there's NetworkManager dispatcher scripts that *also* `try-restart iscsid` =/ That said, I do think a general better pattern is to either: - Have the daemon itself run `systemctl enable` if it detects the scenario; though the problem with this is that if the daemon is removed, the enablement state will "leak", but a workaround for that is to ship a unit in your daemon which is itself conditionally enabled, and *that* unit has Wants/Requires=iscsid.service. So there'd be libvirt-iscsid-requirement.service or so. - Write a "stamp file" to /var/lib/mydaemon, then a generator can key off that. (Instead of e.g. starting up libvirt and parsing its whole database etc.) But this intersects with the /var requirement, unless you move it to /etc. (I had actually forgotten though that it's not guaranteed /var is mounted, I'm pretty sure we have some implicit requirements on that some places) This thread is really similar to https://github.com/containers/podman/pull/17110 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Shorter Shutdown Timer (System-Wide Change proposal)
On Thu, Dec 22, 2022, at 12:35 PM, Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/Shorter_Shutdown_Timer > > This document represents a proposed Change. As part of the Changes > process, proposals are publicly announced in order to receive > community feedback. This proposal will only be implemented if approved > by the Fedora Engineering Steering Committee. > > == Summary == > A downstream configuration change to reduce the systemd unit timeout > from 2 minutes to 15 seconds. A problem I've seen in the past is that timeouts like this have very different effects on slow/heavily loaded systems. For example, an OpenStack environment that has relatively slow storage (or a public cloud environment without provisioned IOPS). Or a bare metal server that is loaded to the limit. The effect of a 15 second timeout in those scenarios is wildly different from that of a relatively idle desktop system with a SSD or modern NVMe drive. DBus for example defaults to a 25 second timeout on method calls, and I've seen problems like the above there. Ideally, we'd have a mechanism to define timeouts like this somehow relative to system speed (throughput) not simple wall clock time. That said, I think the simplest is for this change to only apply to desktop systems. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Add Fedora Auto Firstboot Services to desktop variants (System-Wide Change proposal)
On Fri, Dec 9, 2022, at 10:59 AM, Timothée Ravier wrote: > Using layering will also conflict / not interact well with the move to > container based ostree image in F38: > https://fedoraproject.org/wiki/Changes/OstreeNativeContainerStable (I'm only kind of following this thread and I agree we should not enable layering by default) But a note: from the rpm-ostree perspective, we intend to still fully support client side layering. Obviously this change suddenly makes it very straightforward to do derivative server-side layering/builds, and there's been a lot of excitement around that. I do expect most even semi-technical users to do this. But it's not clear to me that we should say that's the *only* path and at a technical level today a lot of work went into keeping that functionality. For example, today for OpenShift for example we client side package layer kernel-rt and a few other things. I obviously want us to move to always building an image, but it needs some work. There's also valid use cases around things like "I want to ssh to this one machine and install kernel-debug". ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Ostree Native Container (Phase 2, stable) (System-Wide Change proposal)
On Wed, Nov 30, 2022, at 8:11 PM, Colin Walters wrote: > > BTW I wanted to give an update here specifically regarding the "dnf > image" bit - as of late, I've been working on a fresh new "bootc" CLI, > see https://github.com/ostreedev/ostree-rs-ext/pull/412 and > https://github.com/cgwalters/bootc and that may make more sense for the > client side. This is now more real - it's been moved to github.com/containers/bootc and I've updated the Change proposal at https://fedoraproject.org/wiki/Changes/OstreeNativeContainerStable to reflect this. This is all pretty new but - again I've been searching for a succinct way to describe all this stuff, and "bootc" seems to work much better than "ostree container" or "dnf image" etc. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Ostree Native Container (Phase 2, stable) (System-Wide Change proposal)
On Mon, Nov 21, 2022, at 10:20 AM, Jonathan Lebon wrote: > On Tue, Oct 25, 2022 at 12:43 PM Colin Walters wrote: >> - This proposal is explicitly trying to tie everything together. I think >> without the "bigger picture", it's actually *more* confusing. For example, >> just pushing the container images does little unless we invest in them as a >> derivation source and build tooling and docs around them. > > I agree it's helpful to discuss this at a higher level than the > individual pieces to make sense of it. But the proposal as is seems to > imply it will all be done in one cycle which I agree with Dusty is > very optimistic. I agree. > WDYT about introducing phases into the proposal? E.g. something like: > - phase 1 (f38): start pushing OSTree-based variants as container > images in Quay.io; users can opt into rebasing onto them > > - phase 2 (f39): automatically transition existing users to shipping > from Quay.io; users can opt out. > - phase 3 (f40): stop pushing OSTree repo updates entirely I'd agree that "stop pushing ostree repo updates" probably isn't going to happen in Fedora 38. Dunno, I guess we could try a f40 change that calls that out explicitly. > Some concerns about this have been raised upstream already around > whether hijacking the `dnf` command in that way could cause more > confusion than it's worth. ISTM like a cleaner approach would be to > build this out into `dnf` directly instead and have it drive > rpm-ostree. I agree with this longer term, though there's a *lot* of details here. We have the same problem with this that exists with dnf5 in that there are a *ton* of options that dnf exposes that we're unlikely to make work anytime soon. (A random example here is "-4 resolve to IPv4 addresses only" which seems tricky to plumb through the stack, particularly scoping in the container side). > It would be great to get feedback from the DNF maintainers about this > proposal and some of the ideas here. Agreed! I pinged them directly again but was hoping they'd see this Change and reply here. > I think this probably makes sense generally, but I'll note that for > Fedora CoreOS at least, the whole point is to have users' workloads > run in containers and decoupled from the host. E.g. we've gone to > great lengths to keep Python out for that reason (also, `cowsay` pulls > in Perl BTW :) ). Having non-finger compatibility with `dnf install -y > cowsay` was kind of a feature in that sense; it made users think twice > before falling into the same patterns as other systems. Now with this > and especially container layering, it gives more power to users but > weakens that messaging. This is true. But weakening that messaging (and making the technology more flexible) also *weakens the barriers* we've set up between "CoreOS" and other editions. (This topic gets confusing because we could be talking about the *build* side or the client side or both; I hope most people agree the CLI compatibility on the build side just makes sense) BTW I wanted to give an update here specifically regarding the "dnf image" bit - as of late, I've been working on a fresh new "bootc" CLI, see https://github.com/ostreedev/ostree-rs-ext/pull/412 and https://github.com/cgwalters/bootc and that may make more sense for the client side. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Question about git signed tags
On Tue, Nov 29, 2022, at 3:24 AM, Bob Hepple wrote: > Here's a question from one of my upstream devels. Not sure I understand > exactly what he's asking but I thought I'd post here in the hope that > someone can enlighten him (and me!). > > "... Arch supports signed git tags. I'm hoping Fedora does too. > > I'm thinking of dropping this cumbersome process (i.e: signing and > pushing the `.sig` and `.tar.gz`) for the next release. Simply sign the > tag and create a release out of it. Can you please do a bit of research > on your side to see if that's possible? https://github.com/cgwalters/git-evtag/ was created to address a few details around this. Most of the people replying so far seem confused into thinking "git == internet", when this is clearly not true. One can cache/lookaside git repositories in the same way one caches tarballs. That said, there are some tricky things here around not wanting to need to validate the entire git repository history, and handling cases where the git repository contains significant code which isn't intended to be built and shipped. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 prospoal: Enable bootupd for Fedora Silverblue & Kinoite (Self-Contained Change proposal)
On Mon, Nov 21, 2022, at 3:52 PM, Zbigniew Jędrzejewski-Szmek wrote: > In particular, two reasons why an upgrade might be interrupted were raised: > power being cut and the system crashing. Bootupd (or any other daemon) cannot > do much about crashes so this isn't a good motivation. For power, we have > partial solutions: software-initited poweroffs or reboots should be delayed by > systemd inhibitors. Oh yes, definitely an obvious omission from the current code. Filed https://github.com/coreos/bootupd/issues/403 - thanks! > Bootupd+bootupctl creates a lot of interface for the admin > (status, update, adopt-and-update, validate). This is additional stuff > to learn. Yeah, totally valid comment; though `adopt-and-update` is not something most admins will need to know. I've been thinking lately that `rpm-ostree upgrade` should at least *also* display information when bootupd needs to be invoked too. (And if we did that then combined with the "dnf image" bit then typing `dnf update` would show this too, which should help a lot. Plus having clients like gnome-software also become aware of bootupd was part of the idea) > It is also additional logic to implement: bootupd must understand > EFI and boot partitions, mount points, what to do during upgrades, etc. > I took a brief look at the code and it makes various assumptions about > how the partitions are named (instead of using part-type uuids!), Part of the rationale of for this is that in order to do redundant disk EFI, we can't use the discoverable UUIDs. Or at least, it'd need to be queried per disk and not globally. > Also, bootupd does up-calls into the package manager to query state. No - at least, not in the way you're thinking. bootupd has a separation between "image build phase" and the client side. The package management query only happens during image builds (e.g. rpm-ostree compose image/tree today) which are normally server side. > Information should flow from the package management system into lower-level > components Yes...though did you read https://github.com/coreos/bootupd/issues/50 and the sub-thread with Robbie on this? If we want to support lifecycling bootloader updates separately from the RPM database, that inherently calls for having the "package manager" (or more generally, the OS updater, which may not actually "manage packages" at least by default) *not* invoke bootloader updates - at least by default. To connect this with the previous comment - on the client side, bootupd has its own notion of "update payload" which is just a bit of JSON that today captures the NEVRA of the component RPMs (but could obviously support content not from RPM too). To state this all another way, remember *today* with systems using MBR/BIOS and grub2, `dnf update` does *not* update the MBR and hence `rpm -q grub2` is misleading. So we already have a situation in which the RPM database is not the same thing as the bootloader state. > The raison d'être for bootupd seems to be updates of grub. I guess there isn't > much that can be done in the short term: grub doesn't provide a way to do > updates atomically, and we need to do those updates, and bootupd seems to be a > reasonable interim solution to wrap them. But I hope this will stop being > necessary, and either grub will provide such functionality and/or we'll use a > different bootloader. In other words, I understand and won't block this > Change, > but doesn't make me particularly happy. It seems that it's code that will be > used for some time and then go away. Thanks, I agree with all of this in general; though, there's going to be a really long tail on "go away", particularly when one tries to scope in actually switching bootloaders... ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 prospoal: Enable bootupd for Fedora Silverblue & Kinoite (Self-Contained Change proposal)
On Fri, Nov 18, 2022, at 12:35 PM, Timothée Ravier wrote: >> No, the install script install script in an RPM trigger, so the write is >> still carried out by RPM. >> >> I don't agree. Just because a user can mess with files on the system >> doesn't mean the rpmdb is a lie, nor is it reasonable to go recheck all >> paths on the filesystem just in case they've done so, or create a daemon >> to provide an interface for doing that. > > Note that this change here is only about Fedora Silverblue & Kinoite > (and maybe IoT later). In those variants, /usr is read only and not > expected to be changed by users. The rpmdb is thus pretty much > guaranteed to match the content of the system by design for /usr. > > On rpm-ostree based systems, system composes (image builds), package > installation and updates are done "offline" so /boot is not available. > The bootloader is not updated by an RPM trigger and this is why we need > an additional tool to perform the update at another time. We've created > a daemon because we need the update to be reliable so it should not > fail if your SSH connections fails or if you Ctrl-C it in the middle, > etc. This daemon is really small I wouldn't even call it a daemon, at least not really. More in: https://github.com/coreos/bootupd/pull/401/files That said, I think Robbie is effectively saying "bootupd seems over-engineered" and that's not *entirely* wrong. It certainly could be simpler; yes, in theory we don't strictly need `bootupctl validate`. But...things like having status information going to the journal in a reliable fashion have proven *very* useful in the past. Most classically of course, dnf/apt type systems don't do this and it definitely makes things harder to debug after the fact. The discussion about offline versus live installs touches on https://github.com/coreos/bootupd/issues/108 and we probably should have an option to do that. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 prospoal: Enable bootupd for Fedora Silverblue & Kinoite (Self-Contained Change proposal)
On Tue, Nov 15, 2022, at 12:00 PM, Robbie Harwood wrote: > If your model doesn't permit the system to cease execution during > bootloader updates, then I'm not sure why you need bootupd at all - > traditional RPM updating will work just fine (assuming the A/B change > we've been talking about). But the "Questions and answers" section > doesn't read that way to me: it mentions that "forcibly pulling the > power during OS updates" is a case ostree wants to support and doesn't > explicitly negate that for the bootloader. There's lots of nuance going on here. What both bootupd and your shim prototype are doing is effectively moving the "payload" into /usr and not have RPM directly writing to /efi (or /boot/efi, wherever it's mounted). This also then directly leads into a next issue: https://github.com/coreos/bootupd/issues/50 Basically, `rpm -q shim` becomes a lie - or at least, starts to mean something else[1]. So part of the role of bootupd here is just to become the API to query and manage state. It is also kind of aiming to abstract out the differences across platforms, i.e. we were discussing bringing BIOS and PReP under management too in https://github.com/coreos/bootupd/issues/398 So basically the rationale for bootupd is to become a (relatively thin) layer for managing this stuff since it is decoupled from the kernel+rootfs lifecycle (but, delivered inside that). [1] In a similar vein of course, `rpm -q kernel` can often be a lie after live updates but before rebooting, and similar for userspace services that aren't restarted or old libraries loaded. But, admins have known about those for a long time, or if they don't they learn the hard way. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 prospoal: Enable bootupd for Fedora Silverblue & Kinoite (Self-Contained Change proposal)
On Fri, Nov 11, 2022, at 11:41 PM, Chris Murphy wrote: > On Thu, Nov 10, 2022, at 6:08 PM, Robbie Harwood wrote: >> Ben Cotton writes: >> >>> By design, ostree does not manage bootloader updates as they can not >>> (yet) happen in a transactional, atomic and safe fashion. >> >> As we've talked about before, it's not possible to make updates >> transactional. It involves, per spec and depending on processor >> architecture, updating multiple files in different directories, >> potentially on different filesystems entirely, one of which is fat32. > > EFI/FedoraA > EFI/FedoraB > > NVRAM bootorder uses A then B > > Update the bootloader in EFI/FedoraB > > At any point of failure, only the EFI/FedoraA bootloader path is used. > Once everything in EFI/FedoraB is committed to stable media, set > bootnext FedoraB. If the boot fails, automatic failback to FedoraA. If > the boot succeeds, bootupd can change bootorder. B then A. I think it makes sense for us to make some use of BootNext indeed. However, this heavily overlaps with a potential move to UKIs, which effectively obviate this whole thread by dropping shim and grub out of the equation. It also overlaps with https://github.com/ostreedev/ostree/issues/2725 where ostree could potentially start using BootNext itself - and this is I guess strongly pushing things to be more integrated. (I'd tried to keep the two independent, but...) (There's also an overlap in your proposal with fully redundant EFI partitions across multiple disks and how that would need to be handled, also something I'd hoped to support in bootupd explicitly) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Reproducible builds: Clamp build mtimes to $SOURCE_DATE_EPOCH (System-Wide Change proposal)
On Fri, Nov 11, 2022, at 5:53 AM, Petr Pisar wrote: > > Wouldn't be easier to admit that timesamps are nonsense and simply eradicate > all of them stamps from various data formats rather than trying to fake them? > Simply changing rpmbuild to set timestamp to 0 for all contained files, or > removing the time attribute from the RPM format completely? This is what ostree has done since its inception. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Ostree Native Container (Phase 2, stable) (System-Wide Change proposal)
On Mon, Oct 31, 2022, at 5:14 PM, Matthew Miller wrote: > On Tue, Oct 25, 2022 at 09:00:40AM -0400, Colin Walters wrote: >> Two things: >> >> - This proposal is explicitly trying to tie everything together. I think >> without the "bigger picture", it's actually *more* confusing. For example, >> just pushing the container images does little unless we invest in them as a >> derivation source and build tooling and docs around them. >> - At a very practical level, I find context switching in Mediawiki syntax to >> be rather tedious. I'd prefer to discuss the individual sections in the >> already extant tracker issues that accept Markdown and have a >> well-understood and used discussion mechanism. (Or of course, email here) >> >> But you're certainly not wrong, it *is* a big proposal. Happy to make >> changes, I'm mainly just saying there already are dedicated sub-proposal >> trackers to discuss the details of those. > > Would it make sense to have a Fedora Objective (at the Council level) around > this? Probably? I would say actually that this proposal is not even the end. I cut out a part due to objections/concerns, but I personally (still) want to get rid of e.g. the Silverblue/Kinoite/CoreOS type "sub-brands". It's just e.g. "Workstation, but in image+container-default mode" - where it even matters. Otherwise one can just say "I run Fedora". This is revisiting https://discussion.fedoraproject.org/t/its-more-fedora-than-it-is-fedora-noun/33864 in effect - I personally think "we'll actually just do what you asked for when you type dnf -y install cowsay" is a notable leap here. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [Rpm-maint] [rpm-software-management/rpm] unreproducible `rpmdb.sqlite-shm` (Issue #2219)
> The existence of .sqlite-shm is required for read-only WAL mode to work at > all (a very important use-case being queries by regular users), see > https://www.sqlite.org/wal.html#read_only_database I find this weird - because unprivileged code can't write directly to the database, what practical use is the shared memory? Hmm, I just found https://www.sqlite.org/uri.html#uriimmutable - seems like rpm may be able to use that when it detects it can't write? -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2219#issuecomment-1292136069 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: F38 proposal: Ostree Native Container (Phase 2, stable) (System-Wide Change proposal)
On Mon, Oct 24, 2022, at 11:45 PM, Dusty Mabe wrote: > There are a lot of things going on in this proposal: > > - shipping editions as container images in quay https://pagure.io/releng/issue/11047 > - migrating existing users to the new container image based updates (No tracker yet) > - overriding yum/dnf commands via cliwrap https://github.com/coreos/rpm-ostree/issues/2883 > - rebranding `rpm-ostree` https://github.com/coreos/rpm-ostree/issues/405 > > I feel like we'd have a more cohesive discussion if we tried to break this up > into smaller pieces so we can have a more focused discussion. These links were already mostly in the proposal, but I've added them again here for convenience. > As written this proposal is hard to swallow. Two things: - This proposal is explicitly trying to tie everything together. I think without the "bigger picture", it's actually *more* confusing. For example, just pushing the container images does little unless we invest in them as a derivation source and build tooling and docs around them. - At a very practical level, I find context switching in Mediawiki syntax to be rather tedious. I'd prefer to discuss the individual sections in the already extant tracker issues that accept Markdown and have a well-understood and used discussion mechanism. (Or of course, email here) But you're certainly not wrong, it *is* a big proposal. Happy to make changes, I'm mainly just saying there already are dedicated sub-proposal trackers to discuss the details of those. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Modernize Live Media (System-Wide Change proposal)
On Tue, Oct 18, 2022, at 4:35 PM, Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/ModernizeLiveMedia Just for reference, today Fedora CoreOS uses a different implementation of this: https://github.com/coreos/fedora-coreos-config/tree/testing-devel/overlay.d/05core/usr/lib/dracut/modules.d/35coreos-live See specifically https://github.com/coreos/fedora-coreos-config/blob/testing-devel/overlay.d/05core/usr/lib/dracut/modules.d/35coreos-live/live-generator ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Ostree Native Container (Phase 2, stable) (System-Wide Change proposal)
On Thu, Oct 13, 2022, at 3:08 PM, Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/OstreeNativeContainerStable I know there's a lot going on here, so I put together https://github.com/cgwalters/dnfimage-config as a demonstration system to show this all works today. (Though there's a lot left to do) To say this another way...I really, really wish I had a time machine to go back and announce *this* instead of doing Fedora Atomic Host way back in the day. If when Docker had come out (before Kubernetes, before podman, before CoreOS) I wish I'd said "hey this container stuff is cool, why don't we make bootable host operating systems configurable via containers too"). Oh well, better late than never! (And yes, we're not the first to this nowadays, but...first, this path gives a seamless upgrade for all the existing ostree-based systems out there, and second, you absolutely can continue to do "dnf install cowsay" or whatever client side on standalone systems like desktops and homelab servers, you aren't obligated to tie your an installed OS to external build infrastructure) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: status update on "ostree native containers"
On Tue, Oct 11, 2022, at 4:22 PM, Micah Abbott wrote: > So I took a few hours here and there over the last few days to build a > small project using the ostree native container functionality. I wanted > to create a variant of Fedora CoreOS (FCOS) that has the Image Builder > (https://www.osbuild.org/) service layered on top. Awesome, I love this demo! > I also wanted to > keep the FCOS layered image up-to-date without any intervention on my > part. Ah yes...so here's the (well, a) neat thing - "rpm-ostree upgrade" already knows how to do what you're doing externally! So your shell script, timer and systemd unit are basically equivalent to enabling `rpm-ostree-automatic.service`, except we are missing a policy of "reboot". (I think we started to do that, but then zincati kind of took over the momentum there for FCOS, on desktop systems one usually wants the GUI to be in control of reboots, and also in OpenShift we want the MCO to own reboots. But it'd still make sense) I've been thinking recently about whether we should just fold the functionality from zincati into rpm-ostree...it has grown lots of nice little tidbits, like monitoring for systemd user sessions and delaying the reboot, etc. that in theory we want on other systems too. > Overall, the user experience of using a Containerfile to define > customizations to the OS was really smooth for this use case. One pattern I'd recommend that works cleanly instead of having separate COPY invocations...well actually let me just update one of our examples: https://github.com/coreos/coreos-layering-examples/pull/35 > I can > definitely see how I could expand this workflow to do more testing of > the layered image before promoting it to the Quay registry, too. Yeah...shipping testing tools is a whole other thing. > I'm definitely looking forward to seeing how this project progresses in > the future. Awesome, and thanks so much again for posting this! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Handle sysroot.readyonly=true migration in other rpm-ostree Fedora(s)
On Mon, Oct 10, 2022, at 7:41 AM, Antonio Murdaca wrote: > Hi folks, in rpm-ostree based systems like fedora iot I would love to > handle the migration process similar to what happens today in > silverblue et all wrt sysroot.readonly > https://pagure.io/workstation-ostree-config/blob/main/f/postprocess.sh > - unfortunately that systemd service and script aren't packaged > anywhere and I'd love to have it versioned in RPMs to be used by other > spins too. Yeah, the motivating change clearly should have included Fedora IoT too. > I couldn't find any other conversations around this so I'm > opening this one to discuss how and where such a migration should be > handled/shipped/run in other systems. Hmm. Yeah, this is fair. In retrospect honestly we should have probably done this in the ostree core code to start anyways, and not done it "externally" in shell script. I filed https://github.com/ostreedev/ostree/issues/2734 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Rpm-maint] [rpm-software-management/rpm] unreproducible `rpmdb.sqlite-shm` (Issue #2219)
This is a followup to https://github.com/rpm-software-management/rpm/commit/71456f2fc09900a027a33dc3d6d75c69a9b39488 which is about generating bit-for-bit reproducible images (container/disk) that include an RPM database. At the time, the person working on that PR was looking at RHEL8 (BDB format rpm database). We've since moved on to sqlite, which is nicer. Except in my testing, this `rpmdb.sqlite-shm` is the very last thing blocking reproducible rpm-ostree container images. I hacked up https://github.com/coreos/rpm-ostree/pull/4074 but this issue is to track fixing this more properly inside librpm. I think what would be the best is if this file could be deleted entirely at the end of a build. It seems like rpm (or sqlite) will auto-recreate it in that case, but what blocks us from doing that is that things fail if the mount is read-only. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2219 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Virtio-fs] virtiofsd: Any reason why there's not an "openat2" sandbox mode?
On Thu, Sep 29, 2022, at 1:03 PM, Vivek Goyal wrote: > > So rust version of virtiofsd, already supports running unprivileged > (inside a user namespace). I know, but as I already said, the use case here is running inside an OpenShift unprivileged pod where *we are already in a container*. > host$ podman unshare -- virtiofsd --socket-path=/tmp/vfsd.sock > --shared-dir /mnt \ > --announce-submounts --sandbox chroot & Yes, but in current OCP 4.11 our seccomp policy denies CLONE_NEWUSER: ``` $ unshare -m unshare: unshare failed: Function not implemented ``` https://docs.openshift.com/container-platform/4.11/security/seccomp-profiles.html > I think only privileged operation it needs is assigning a range of > subuid/subgid to the uid you are using on host. We also turn on NO_NEW_PRIVILEGES by default in OCP pods. Now, I *could* in general get elevated permissions where I need to today. But it's also really important to me to have a long term goal of having operating system builds and tests work well as "just another workload" in our production container platform (now, one *does* want to bind in /dev/kvm, but that's generally safe, and even that strictly speaking is optional if one can stomach the ~10x perf hit). > Can you give rust virtiofsd (unprivileged) a try. I admit to not actually trying it in a pod, but I think we all agree it can't work, and the only thing that can today is openat2.
Re: [Virtio-fs] virtiofsd: Any reason why there's not an "openat2" sandbox mode?
On Thu, Sep 29, 2022, at 1:03 PM, Vivek Goyal wrote: > > So rust version of virtiofsd, already supports running unprivileged > (inside a user namespace). I know, but as I already said, the use case here is running inside an OpenShift unprivileged pod where *we are already in a container*. > host$ podman unshare -- virtiofsd --socket-path=/tmp/vfsd.sock > --shared-dir /mnt \ > --announce-submounts --sandbox chroot & Yes, but in current OCP 4.11 our seccomp policy denies CLONE_NEWUSER: ``` $ unshare -m unshare: unshare failed: Function not implemented ``` https://docs.openshift.com/container-platform/4.11/security/seccomp-profiles.html > I think only privileged operation it needs is assigning a range of > subuid/subgid to the uid you are using on host. We also turn on NO_NEW_PRIVILEGES by default in OCP pods. Now, I *could* in general get elevated permissions where I need to today. But it's also really important to me to have a long term goal of having operating system builds and tests work well as "just another workload" in our production container platform (now, one *does* want to bind in /dev/kvm, but that's generally safe, and even that strictly speaking is optional if one can stomach the ~10x perf hit). > Can you give rust virtiofsd (unprivileged) a try. I admit to not actually trying it in a pod, but I think we all agree it can't work, and the only thing that can today is openat2. ___ Virtio-fs mailing list Virtio-fs@redhat.com https://listman.redhat.com/mailman/listinfo/virtio-fs
Re: [Virtio-fs] virtiofsd: Any reason why there's not an "openat2" sandbox mode?
On Thu, Sep 29, 2022, at 10:10 AM, Vivek Goyal wrote: > What's your use case. How do you plan to use virtiofs. At the current time, the Kubernetes that we run does not support user namespaces. We want to do the production builds of our operating system (Fedora CoreOS and RHEL CoreOS) today inside an *unprivileged* Kubernetes pod (actually in OpenShift using anyuid, i.e. random unprivileged uid too), just with /dev/kvm exposed from the host (which is safe). Operating system builds *and* tests in qemu are just another workload that can be shared with other tenants. qemu works fine in this model, as does 9p. It's just the virtiofs isolation requires privileges to be used today.
Re: [Virtio-fs] virtiofsd: Any reason why there's not an "openat2" sandbox mode?
On Thu, Sep 29, 2022, at 10:10 AM, Vivek Goyal wrote: > What's your use case. How do you plan to use virtiofs. At the current time, the Kubernetes that we run does not support user namespaces. We want to do the production builds of our operating system (Fedora CoreOS and RHEL CoreOS) today inside an *unprivileged* Kubernetes pod (actually in OpenShift using anyuid, i.e. random unprivileged uid too), just with /dev/kvm exposed from the host (which is safe). Operating system builds *and* tests in qemu are just another workload that can be shared with other tenants. qemu works fine in this model, as does 9p. It's just the virtiofs isolation requires privileges to be used today. ___ Virtio-fs mailing list Virtio-fs@redhat.com https://listman.redhat.com/mailman/listinfo/virtio-fs
Re: [Virtio-fs] virtiofsd: Any reason why there's not an "openat2" sandbox mode?
On Wed, Sep 28, 2022, at 3:28 PM, Vivek Goyal wrote: > Sounds reasonable. In fact, we could probably do someting similar > for "landlock" as well. Thanks for the discussion all! Can someone (vaguely) commit to look into this in say the next few months? It's not *urgent*, we can live with the 9p flakes and problems short term, just trying to figure out if this needs to be on our medium-term radar or not. Thanks!
Re: [Virtio-fs] virtiofsd: Any reason why there's not an "openat2" sandbox mode?
On Wed, Sep 28, 2022, at 3:28 PM, Vivek Goyal wrote: > Sounds reasonable. In fact, we could probably do someting similar > for "landlock" as well. Thanks for the discussion all! Can someone (vaguely) commit to look into this in say the next few months? It's not *urgent*, we can live with the 9p flakes and problems short term, just trying to figure out if this needs to be on our medium-term radar or not. Thanks! ___ Virtio-fs mailing list Virtio-fs@redhat.com https://listman.redhat.com/mailman/listinfo/virtio-fs
Re: status update on "ostree native containers"
On Tue, Sep 27, 2022, at 6:08 PM, Colin Walters wrote: > We shipped https://fedoraproject.org/wiki/Changes/OstreeNativeContainer > in Fedora 36 and a lot has happened since then. Also, I should mention that we're planning to use this in OpenShift, see https://github.com/openshift/enhancements/blob/master/enhancements/ocp-coreos-layering/ocp-coreos-layering.md and since https://github.com/openshift/machine-config-operator/pull/3317 literally just merged we're on track to use this to update the operating system by default, and further exposing the full power of any container build system you choose (Dockerfile or whatever) to customize the OS in a very Kubernetes/container native way. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: status update on "ostree native containers"
On Wed, Sep 28, 2022, at 9:47 AM, Rahul Sundaram wrote: > FYI, the command in that page doesn't appear to be working because > "latest" is the default tag if you don't specify one for docker and it > doesn't exist, so you have to append ":stable" or something like that. https://github.com/coreos/fedora-coreos-tracker/issues/1309 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
status update on "ostree native containers"
We shipped https://fedoraproject.org/wiki/Changes/OstreeNativeContainer in Fedora 36 and a lot has happened since then. One of the biggest things is that rpm-ostree now knows how to intelligently generate reproducible "chunked" container images. I'll describe this by also highlighting another big change; Fedora CoreOS is now shipped as a properly manifest listed container image alongside the other Fedora images on quay.io: https://quay.io/repository/fedora/fedora-coreos And if you dig into the tags, on the UI, clicking through to the stable/amd64 image, check out e.g. https://quay.io/repository/fedora/fedora-coreos/manifest/sha256:0d100d21bbe885d638de1847eeacfed7903ed5b9aec5832730d12cad0dbb6f58 Note that e.g. linux-firmware (by far the largest single chunk) is split into its own layer - and this layer is generated in a reproducible fashion (ostree canonicalizes all timestamps to zero in particular). What this means is that these images share storage on the registry and client side. Another way to say this is that it means you get a natural "delta-like" flow; if e.g. there's a security update to podman, you only download the layer containing podman (plus a metadata layer), not everything else. This isn't the same as more proper deltas (as e.g. ostree static deltas enable) but it has the powerful benefit of applying everywhere that Docker/OCI containers go (e.g. when you pull the image via podman/docker or Kubernetes, that *also* applies there). You may see this effort sometimes called "CoreOS Layering" but it really has little to do with "CoreOS", and https://pagure.io/releng/issue/11047 is a ticket which proposes shipping e.g. quay.io/fedora/fedora-silverblue for example. (I know for a number of people I've talked to this idea of building your desktop as an container image server side is powerfully appealing, and this makes it real) On that topic there's also https://bugzilla.redhat.com/show_bug.cgi?id=2125655 which shouldn't be too hard to put together. But back to Fedora CoreOS, another thing that's happened recently is https://github.com/coreos/coreos-layering-examples has matured and has many functional examples of using this. We're getting increasingly close to the point where I want to call this all stable, so it's a great time if you haven't to kick the tires and try it out! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [Virtio-fs] virtiofsd: Any reason why there's not an "openat2" sandbox mode?
On Tue, Sep 27, 2022, at 1:27 PM, German Maglione wrote: > >> > Now all the development has moved to rust virtiofsd. Oh, awesome!! The code there looks great. > I could work on this for the next major version and see if anything breaks. > But I prefer to add this as a compilation feature, instead of a command line > option that we will then have to maintain for a while. Hmm, what would be the issue with having the code there by default? I think rather than any new command line option, we automatically use `openat2+RESOLVE_IN_ROOT` if the process is run as a nonzero uid. > Also, I don't see it as a sandbox feature, as Stefan mentioned, a compromised > process can call openat2() without RESOLVE_IN_ROOT. I'm a bit skeptical honestly about how secure the existing namespace code is against a compromised virtiofsd process. The primary worry is guest filesystem traversals, right? openat2+RESOLVE_IN_ROOT addresses that. Plus being in Rust makes this dramatically safer. > I did some test with > Landlock to lock virtiofsd inside the shared directory, but IIRC it requires a > kernel 5.13 But yes, landlock and other things make sense, I just don't see these things as strongly linked. IOW we shouldn't in my opinion block unprivileged virtiofsd on more sandboxing than openat2 already gives us. ___ Virtio-fs mailing list Virtio-fs@redhat.com https://listman.redhat.com/mailman/listinfo/virtio-fs
Re: virtiofsd: Any reason why there's not an "openat2" sandbox mode?
On Tue, Sep 27, 2022, at 1:27 PM, German Maglione wrote: > >> > Now all the development has moved to rust virtiofsd. Oh, awesome!! The code there looks great. > I could work on this for the next major version and see if anything breaks. > But I prefer to add this as a compilation feature, instead of a command line > option that we will then have to maintain for a while. Hmm, what would be the issue with having the code there by default? I think rather than any new command line option, we automatically use `openat2+RESOLVE_IN_ROOT` if the process is run as a nonzero uid. > Also, I don't see it as a sandbox feature, as Stefan mentioned, a compromised > process can call openat2() without RESOLVE_IN_ROOT. I'm a bit skeptical honestly about how secure the existing namespace code is against a compromised virtiofsd process. The primary worry is guest filesystem traversals, right? openat2+RESOLVE_IN_ROOT addresses that. Plus being in Rust makes this dramatically safer. > I did some test with > Landlock to lock virtiofsd inside the shared directory, but IIRC it requires a > kernel 5.13 But yes, landlock and other things make sense, I just don't see these things as strongly linked. IOW we shouldn't in my opinion block unprivileged virtiofsd on more sandboxing than openat2 already gives us.
virtiofsd: Any reason why there's not an "openat2" sandbox mode?
We previously had a chat here https://lore.kernel.org/all/348d4774-bd5f-4832-bd7e-a21491fda...@www.fastmail.com/T/ around virtiofsd and privileges and the case of trying to run virtiofsd inside an unprivileged (Kubernetes) container. Right now we're still using 9p, and it has bugs (basically it seems like the 9p inode flushing callback tries to allocate memory to send an RPC, and this causes OOM problems) https://github.com/coreos/coreos-assembler/issues/1812 Coming back to this...as of lately in Linux, there's support for strongly isolated filesystem access via openat2(): https://lwn.net/Articles/796868/ Is there any reason we couldn't do an -o sandbox=openat2 ? This operates without any privileges at all, and should be usable (and secure enough) in our use case. I may try a patch if this sounds OK...
Re: Help packaging a "C" library written in Rust
On Wed, Sep 7, 2022, at 5:35 AM, Richard W.M. Jones wrote:
> It was pointed out on the bug that librsvg2 is in a similar situation.
> The answer there was to bundle ("vendor") all the Rust dependencies
> into the tarball. The command "cargo vendor" does this.
>
> For librsvg2 that's 278MB of dependencies (10 times larger than the
> sources of librsvg2 itself) in 265 separate Rust libraries.
I'd recommend using https://github.com/coreos/cargo-vendor-filterer
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Heads-up / for discussion: dnf not working with 1G of RAM or less
On Mon, Aug 29, 2022, at 3:52 AM, Brian (bex) Exelbierd wrote: > I use Fedora IoT on GCPs free tier offering and it is fine. I a, > assuming `rpm-ostree install` doesn’t have this issue. It does have the issue. rpm-ostree links to libdnf which is doing all the same things. As I commented in the bug though, to do default image based updates, rpm-ostree very intentionally *does not* load the repo metadata, it's just replicating the filesystem tree, which takes very little memory. The issue really has nothing to do with the client side - it's all about the *repository metadata size*. That's why I reassigned the bug to "distribution". The reason this bug isn't hitting RHEL right now is simply just because the default RHEL repositories are much smaller - also crucially things like many -devel packages are in a separate repository. I don't see a need to rehash all of this *again* - the linked BZ already contains everything said in this thread, and the BZ itself is mainly rehashing a 4 year old thread https://pagure.io/fesco/issue/1955 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Fedora Sway OSTree Spin name
On Fri, Aug 12, 2022, at 1:04 PM, Fabio Alessandro Locati wrote: > Hi, > > The Sway SIG is looking for ideas and opinions on the name for the Sway > OSTree spin. > You can read more at > https://fale.io/blog/2022/08/12/fedora-sway-ostree-spin-name Just my 2 cents: I still don't think the proliferation of "sub-brands" is a good idea: https://discussion.fedoraproject.org/t/its-more-fedora-than-it-is-fedora-noun/33864 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: pre-change: lower printk setting after switching to real root
On Tue, Jul 19, 2022, at 12:24 PM, Lennart Poettering wrote: > On Fr, 15.07.22 10:03, Colin Walters (walt...@verbum.org) wrote: > >> We recently did >> https://github.com/coreos/fedora-coreos-config/pull/1840 for Fedora >> CoreOS (more background: >> https://github.com/coreos/fedora-coreos-tracker/issues/1244 ) and >> I'd like to consider applying this to all Fedora editions. >> >> There'd be no impact on desktop systems (commonly installed via >> Anaconda and hence using `quiet`). >> >> The benefit is for server systems where we *do* want some kernel >> output at boot, but once we've successfully booted we don't want to >> emit a message every time podman/docker creates a bridge device for >> example. >> >> Concretely today, I noticed that the RHEL 8.6 Cloud Guest image also >> does not include `quiet` and so the kernel console log is full of >> the same spam at runtime, and I think it makes sense to do this >> change across all Fedora derivatives. > > I am note entirely sure if this feature has merit or not, Definitely interested in your opinion, because...a bikeshed here is where to put this unit if it's not systemd. For CoreOS, we have this nice "overlay" git repository for stuff like this that isn't an RPM, it has a lot of our miscellaneous systemd units and config files and such; so we can just do a pull request, have that pull request go through CI and merge and then it gets baked into the image and ship...no "manual package builds". The closest analogue in the yum world (i.e. only understands RPMs) is probably the generic-release type packages. So in theory it could go there. But this all said...it perhaps is worth considering the alternative, which is just this one-liner diff to the kernel config (AFAIK): diff --git a/kernel-x86_64-fedora.config b/kernel-x86_64-fedora.config index 517763fc9..b4b5708a3 100644 --- a/kernel-x86_64-fedora.config +++ b/kernel-x86_64-fedora.config @@ -981,7 +981,7 @@ CONFIG_COMPAT_32BIT_TIME=y # CONFIG_COMPILE_TEST is not set CONFIG_CONFIGFS_FS=y CONFIG_CONNECTOR=y -CONFIG_CONSOLE_LOGLEVEL_DEFAULT=7 +CONFIG_CONSOLE_LOGLEVEL_DEFAULT=4 CONFIG_CONSOLE_LOGLEVEL_QUIET=3 CONFIG_CONTEXT_SWITCH_TRACER=y # CONFIG_CONTEXT_TRACKING_FORCE is not set The implications to that are obviously much larger, which is why I hesitated to propose it. While the stream of debug-level spew for servers has caused serious problems, it feels odd to me to switch servers to be entirely quiet by default. I am *certain* there are people who are doing CI/testing systems and are gathering the kernel console today and expect non-quiet output by default. But, this is also a much simpler change to understand, and anyone who wants it can start specifying e.g. `debug` on the kernel command line. I'm certainly curious about the opinions of the kernel maintainers in particular here. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Suggestion: Use a unified kernel image by default in the future.
On Wed, Jul 20, 2022, at 4:44 AM, Gerd Hoffmann wrote: > Where does that build happen? Must be outside the kernel > rpm build process, so probably when generating the ostree? Exactly. We also run all %post scripts server side too for example. You can see the logs for this at e.g. https://kojipkgs.fedoraproject.org/compose/updates/Fedora-36-updates-20220720.0/logs/aarch64/Everything/ostree-3/create-ostree-repo.log for aarch64 silverblue 36. And at e.g. https://jenkins-fedora-coreos-pipeline.apps.ocp.fedoraproject.org/job/build/912/consoleFull for a Fedora CoreOS testing-devel build (that also builds update disk images). (One profound difference between these two things right now is that with Fedora CoreOS we actually test the ostree image before shipping it to users, for example booting the resulting update in qemu, including the server side generated dracut image etc. in a tightly integrated build/test setup, which Koji...doesn't.) > Any plans for switching to unified kernel images, to have the > initrd covered by secure boot signing? There's a lot of active related debate on things related to this; but it's really important to understand that with ostree in general it is a top level goal to support "open" Linux systems where you are root on your computer - the same way as yum based systems. While we ship as an image by default, it is intentional that you can e.g. change the initramfs locally (you can run `rpm-ostree initramfs --enable` to dynamically switch to client-side dracut runs) or kernel command line arguments or more generally inject persistent, privileged code. I for sure want to support people creating their own actually "sealed"/"locked down" systems, particularly for e.g. IoT type setups and support for "unified" style kernel images is likely part of that. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: pre-change: lower printk setting after switching to real root
On Tue, Jul 19, 2022, at 12:24 PM, Lennart Poettering wrote:
>
> by something like this:
>
>
> ExecStart=/usr/bin/systemd-tmpfiles --create -
> StandardInputText=f /run/sysctl.d/01-coreos-printk.conf - - - - kernel.printk
> 4
>
>
> Benefits: no shell, single process forked, no explicit selinux stuff,
> or explicit mkdir, and other MACs will be honoured too if they exist.
Unfortunately doesn't work today since:
[ 243.300955] audit: type=1400 audit(1658251774.506:317): avc: denied {
getattr } for pid=1801 comm="systemd-sysctl"
path="/run/sysctl.d/01-coreos-printk.conf" dev="tmpfs" ino=934
scontext=system_u:system_r:systemd_sysctl_t:s0
tcontext=system_u:object_r:var_run_t:s0 tclass=file permissive=1
But yes, I will look at getting that added to policy.
(FTR there was also a missing `=` in the sysctl text)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: Suggestion: Use a unified kernel image by default in the future.
On Tue, Jul 19, 2022, at 10:15 AM, Gerd Hoffmann wrote: > > That is the big if. If you have the initrds. > > I've hacked up the kernel rpm to also build a initrd (targeting virtual > machines for starters) and shipping that as (optional) sub-rpm ... FWIW, every rpm-ostree based system defaults to shipping a server side generated initramfs today. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
pre-change: lower printk setting after switching to real root
We recently did https://github.com/coreos/fedora-coreos-config/pull/1840 for Fedora CoreOS (more background: https://github.com/coreos/fedora-coreos-tracker/issues/1244 ) and I'd like to consider applying this to all Fedora editions. There'd be no impact on desktop systems (commonly installed via Anaconda and hence using `quiet`). The benefit is for server systems where we *do* want some kernel output at boot, but once we've successfully booted we don't want to emit a message every time podman/docker creates a bridge device for example. Concretely today, I noticed that the RHEL 8.6 Cloud Guest image also does not include `quiet` and so the kernel console log is full of the same spam at runtime, and I think it makes sense to do this change across all Fedora derivatives. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change Proposal: Unfiltered Flathub (System-Wide Change)
On Thu, Jun 30, 2022, at 10:23 AM, Michael Catanzaro wrote: > > Regardless, Fedora will still be RPM-based no matter what. ;) Even if > our future is OS images composed of RPMs plus Flatpaks composed by > RPMs, it's still based on RPMs. I don't think so. I think RPM is a tool, a technique that can be used where it makes sense. It is not and should not be the center of the universe. Today in Fedora CoreOS we ship a bit of content that comes directly from the https://github.com/coreos/fedora-coreos-config git repository without having been pointlessly put into an RPM first. Building an intermediate RPM for content that is *only* intended to be run as a container is just awkward and strange. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Install Using GPT on x86_64 BIOS by Default (System-Wide Change proposal)
On Sun, May 29, 2022, at 6:55 AM, Peter Boy wrote: > > Fedora Server WG discussed the proposal and insists that the proposal > be deferred until Anaconda can install software raid on biosboot > systems with GPT (see > https://bugzilla.redhat.com/show_bug.cgi?id=2088113 and > https://lists.fedoraproject.org/archives/list/ser...@lists.fedoraproject.org/thread/VSM473WRHKIIIJYZZCVXAO7XFS4ACHPH/) > > - at least for Fedora Server where software raid is a common use. Just a note: Fedora CoreOS has used a hybrid BIOS/UEFI setup since its inception, and also supports this "mirrored boot" setup: https://docs.fedoraproject.org/en-US/fedora-coreos/storage/#_reconfiguring_the_root_filesystem https://github.com/coreos/enhancements/blob/main/os/20201103-full-disk-raid.md https://github.com/coreos/butane/pull/162 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F38 Change: Major upgrade of Microdnf (Self-Contained Change proposal)
On Thu, Apr 21, 2022, at 7:19 AM, Zbigniew Jędrzejewski-Szmek wrote: > > - dnf-daemon would be dbus-activated and exit-on-idle after a suitable > timeout This is how rpm-ostree has worked for about 5 years now: https://github.com/coreos/rpm-ostree/pull/606 (Lots of useful references in that thread - doing exit-on-idle in a *race free* way with DBus is unfortunately very tricky. I am still thinking about switching the default client mode to direct systemd socket activation. As of recently, the client also directly invokes `systemctl start` (if privileged)) The problem isn't really inherent to a daemon, the problem is the *gigantic* size of the repodata. Also on the background in my todo list is to move all the RPM stuff into a forked subprocess from the daemon that itself is only run on demand - that would mean an idle daemon still has low memory usage. I haven't dug into the libdnf5 code, but today it actually embeds the daemon code in the libdnf repository - I hope we can compile that out or split it out, because rpm-ostree already has an working DBus API. Maybe in some cases we can try to expose some of the same API entrypoints, but on the other hand the entire rpm-ostree design is oriented by default around offline-by-default transactional updates, which is going to look quite different from an API perspective. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: filesystems and year 2038
On Tue, Apr 5, 2022, at 10:11 AM, Justin Forbes wrote: > > That list hasn't been edited in 5 years, but 256 bit inodes have been > the ext default for a very long time unless you specifically request > small. In current Fedora CoreOS we have 128 bit inodes for /boot, and this appears to be the default of `mkfs.ext4` for our chosen size of /boot: [root@cosa-devsh ~]# truncate -s 384M /var/tmp/disk.img [root@cosa-devsh ~]# mkfs.ext4 /var/tmp/disk.img mke2fs 1.46.3 (27-Jul-2021) Discarding device blocks: done Creating filesystem with 393216 1k blocks and 98304 inodes Filesystem UUID: 32e5f29f-5808-4feb-a8c2-83dfc3eef410 Superblock backups stored on blocks: 8193, 24577, 40961, 57345, 73729, 204801, 221185 Allocating group tables: done Writing inode tables: done Creating journal (8192 blocks): done Writing superblocks and filesystem accounting information: done [root@cosa-devsh ~]# tune2fs -l /var/tmp/disk.img | grep 'Inode size' Inode size: 128 [root@cosa-devsh ~]# rpm -q e2fsprogs e2fsprogs-1.46.3-1.fc35.x86_64 [root@cosa-devsh ~]# Ah but with a 512M disk I do get 256 bit inodes, I bet that's the difference. >? I think the defaults for ext2 and ext3 even changed well over > 10 years ago. The oldest disk I have here already has 256 bit inodes > even for /boot Or, maybe it's an Anaconda thing to override it? Anyways...for now I may just get the PR merged to update FCOS's /boot. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: filesystems and year 2038
On Mon, Apr 4, 2022, at 3:51 PM, Justin Forbes wrote: > On Mon, Apr 4, 2022 at 11:47 AM Colin Walters wrote: >> >> Hi, creating a thread on this from: >> https://github.com/coreos/fedora-coreos-config/pull/1650 >> >> Basically I'd propose that not just our default images have y2038-compatible >> filesystem setups, we ensure that if e.g. XFS is explicitly chosen for a >> Workstation installation then it is set up with bigtime=1. >> >> (Note btrfs uses 64 bit time today, so I think this is mostly about ext4 and >> xfs, but perhaps we also need to look at the longer tail too, e.g. squashfs. >> OTOH, because squashfs is read-only we can just worry about that closer to >> 10 years from now...) >> >> If no one objects I guess I can look at re-learning Mediawiki syntax again >> and writing a Change. > > Or, you could ignore it and it will happen anyway: > > xfsprogs-5.15.0-rc1 (11 Mar 2022) > - mkfs: enable inobtcount and bigtime by default (Darrick J. Wong) Ah, thanks for the link. So...given the ext4 34 bit thing, I think as long as we ship that by default in say F37 we can just mostly call this done. (I'd still like to enable 256 bit inodes for ext4 /boot type setups just for completeness though) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
filesystems and year 2038
Hi, creating a thread on this from: https://github.com/coreos/fedora-coreos-config/pull/1650 Basically I'd propose that not just our default images have y2038-compatible filesystem setups, we ensure that if e.g. XFS is explicitly chosen for a Workstation installation then it is set up with bigtime=1. (Note btrfs uses 64 bit time today, so I think this is mostly about ext4 and xfs, but perhaps we also need to look at the longer tail too, e.g. squashfs. OTOH, because squashfs is read-only we can just worry about that closer to 10 years from now...) If no one objects I guess I can look at re-learning Mediawiki syntax again and writing a Change. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: RHEL moving to issues.redhat.com only long term
On Mon, Mar 7, 2022, at 12:44 PM, Josh Boyer wrote: > Hi Fedora, CentOS, and EPEL Communities! > > As part of our continued 3 year major Red Hat Enterprise Linux release > cadence, RHEL 9 development is starting to wrap up with the spring > 2022 release coming soon. That means planning for the next release > will start in earnest in the very near future. As some of you may > know, Red Hat has been using both Bugzilla and Jira via > issues.redhat.com for RHEL development for several years. Our > intention is to move to using issues.redhat.com only for the major > RHEL releases after RHEL 9. I think it's unfortunate to replace the FOSS Bugzilla with proprietary software. I am eternally conflicted about this with respect to GitHub (xref https://blog.verbum.org/2020/12/03/still-on-github/ ) but...Jira is not as compelling of a user experience upgrade. A continual challenge related to this I feel is using the same software to track product bugs with potentially sensitive customer data in it, and public open development. To link these things, I quite commonly move Bugzilla discussion that has no need to be private to Github, because I know Github is always public (from our PoV). One thing that may help is to at least use different themes (e.g. blue colors for public CentOS issues, red for RHEL?) on issues.redhat.com. Long term if Bugzilla slowly morphs into only being used by Fedora, personally I'd prefer to have bugs/issues in gitlab instead. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Landing a larger-than-release change (distrusting SHA-1 signatures)
On Tue, Mar 8, 2022, at 1:40 PM, Alexander Sosedkin wrote: > > But these are all rather... crude? > Sure there should be better ways, > preferably something explored before. One general technique I like is the "warn and sleep" approach; example: https://github.com/coreos/rpm-ostree/pull/2098 Of course, printing to e.g. stderr or even more strongly adding a sleep(5) call in the middle of cryptographic libraries has a huge blast radius on its own. But it's smaller than removing it entirely. (And, remember I am a big fan of the mental model of rolling out changes to the OS core first, not all packages, so some sort of opt-in warn-and-sleep approach could even be prototyped out in e.g. Fedora CoreOS first, where we have CI that covers most things we care about) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: s390x KOJI builders issue
On Thu, Mar 3, 2022, at 4:25 PM, Colin Walters wrote: > On Wed, Mar 2, 2022, at 7:04 PM, Kevin Fenzi wrote: > >> * OOm killer looks and says... oh hey, I need to kill something. This >> kojid process/slice is taking up all the memory. >> * kojid is killed. > > If we replaced Koji's backend with Kubernetes (at least my employer's > production way to run Linux containers), and mock with scheduled pods > that just run `yum builddep $package && rpmbuild` inside them etc. Filed https://pagure.io/koji/issue/3273 to centralize this and gave it a catchy name too! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: s390x KOJI builders issue
On Wed, Mar 2, 2022, at 7:04 PM, Kevin Fenzi wrote: > * OOm killer looks and says... oh hey, I need to kill something. This > kojid process/slice is taking up all the memory. > * kojid is killed. If we replaced Koji's backend with Kubernetes (at least my employer's production way to run Linux containers), and mock with scheduled pods that just run `yum builddep $package && rpmbuild` inside them etc. then this would be fixed for free because significant work has gone in to protecting the kubelet (equivalent of kojid) from workloads. See e.g. https://docs.openshift.com/container-platform/4.9/nodes/nodes/nodes-nodes-resources-configuring.html ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Is NetworkManager-wait-online.service necessary by default?
On Thu, Feb 24, 2022, at 6:17 AM, Benjamin Berg wrote: > network-online-waitonly.target with > After=network-online.target > StopWhenUnneeded=yes > > which is then used inside iscsi.service > ExecStartPre=/usr/bin/systemctl start network-online-waitonly.target No, avoid such things unless absolutely necessary - it makes the dependency graph dynamic, which systemd does support but doing so brings a vast amount of complexity. I think instead you can use e.g. a systemd generator: https://www.freedesktop.org/software/systemd/man/systemd.generator.html The generator (which can be the same binary) can then enable iscsi.service only if the directory is non-empty. (Which is making things dynamic, but all dynamic computation happens at a well-defined eraly fixed point and is acted on together thereafter) Now I'd agree this behavior is not obvious, and perhaps systemd should gain something like EnableConditionDirectoryNotEmpty= that is defined to be evaluated at the same time as generators or so, and if the conditions evaluate to false then none of the unit dependencies will be pulled in either. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Enable read only /sysroot for Fedora Silverblue & Kinoite (Self-Contained Change proposal)
On Wed, Feb 16, 2022, at 12:48 PM, Stephen Snow wrote: > On Wed, 2022-02-16 at 12:12 -0500, Ben Cotton wrote: >> https://fedoraproject.org/wiki/Changes/Silverblue_Kinoite_readonly_sysroot >> >> == Summary == >> >> This change is about enabling an opt-in ostree feature that re-mounts >> `/sysroot` as read only to avoid accidental changes. >> >> Users and administrators are not expected to directly interact with >> the content available there and should instead use the interface >> offered by rpm-ostree, GNOME Software or (soon) Plasma Discover to >> manage their system. >> > I use Silverblue. How does this affect my ability to modify /etc in the > opt-in scenario? It doesn't; `/etc` is mounted writable. > Does rpm-ostree offer a method to modify /etc in that > case? What if I want a mutable /var, like I currently have, does this > change under this proposal? `/var` does not change either. > What is the value of this for the normal Fedora Linux user? The basic idea is that `/sysroot` is actually an ostree implementation detail, and really nothing else should be writing to it. Fedora CoreOS has worked this way for a long time; we just didn't make the change in ostree by default out of conservatism. > See, that's an unwelcome thing IMO. I think actually the migration service could inject `rw` into all bootloader entries actually. > I don't know. I think not being able to boot into my previous > deployments a visible change to my user experience. The service adjusting all bootloader entries is the easy fix for this. Or, TL;DR: Don't panic, no power is being removed and it's very likely that no one will notice. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Authselect: Move State Files to /etc (Self-Contained Change proposal)
On Wed, Jan 19, 2022, at 10:25 AM, Neal Gompa wrote: > > I agree, I think it should move to /usr/lib/sysimage/authselect instead. That would break the use case of running it on an image based (i.e. readonly /usr) system *client side*. We settled on having it in /etc in https://bugzilla.redhat.com/show_bug.cgi?id=2034360 because that works symmetrically across both. It's also keeps the backups closer to the original files (e.g. they're more likely to be on the same file so reflinks could be used). I think these authselect backups are really similar to e.g. `.rpmnew/.rpmorig` and similar. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Silverblue and Kinoite will have /var on its own Btrfs subvolume (Self-Contained Change proposal)
On Wed, Jan 19, 2022, at 6:38 AM, Neal Gompa wrote: > On Wed, Jan 19, 2022 at 6:05 AM Casey Jao via devel > wrote: >> >> Doesn't rpm-ostree already provide transactional, image-based updates >> without the use of filesystem snapshots? In addition, roofs snapshots are >> only really useful if they are coordinated with bootloader management, which >> is already built into rpm-ostree but not yet written for a hypothetical >> btrfs-based atomic os updater. > > I think the bigger value would be around being able to use filesystem > snapshots with /var. Right. In the ostree model the idea is all user data (except config files in /etc) are in /var. So if you want to back up all machine-local state (including your home directories, container storage, libvirt VMs, etc.), you just need one filesystem to save. It could make sense to save a snapshot of /var before performing major OS upgrades. But they're not strictly related. (As an aside: personally, I think snapshots have mostly just obscure use cases versus backup systems) I would agree with Casey though in that the opposite case of trying to snapshot /usr (and then boot it) outside of ostree's control is likely to confuse ostree at best at least today. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Workflow and other problems with the Fedora container infrastructure
On Thu, Jan 13, 2022, at 1:48 PM, Kevin Fenzi wrote: > > > Perhaps the Fedora CoreOS folks would have some thoughts? I can't speak for the whole team, but a few points. First, the FCOS build tooling in https://github.com/coreos/coreos-assembler is designed to run as a standard container. In some cases we do run it via podman over ssh as part of multi-arch, but the main approach is to run it inside Kubernetes (OpenShift). We designed it this way because OpenShift is of great interest to at least my employer (in case anyone didn't know). That's how we run production container workloads. Until now however, we have really had a very interesting tension because the primary output of FCOS builds is not a container image, it's bootable disk images (as produced by many tools, including ImageFactory, Image Builder, the kiwi thing in this thread, and many others). However, https://fedoraproject.org/wiki/Changes/OstreeNativeContainer is going to shift our "center of gravity" much closer to a container build. I'd actually like to "decouple" the disk image builds from container builds in our pipeline more, basically so that we generate disk images using a container image as *input* - for FCOS as well as other ostree systems today, a bootable disk image is really just a platform-specific wrapper shell around that. Related to this, I am quite strongly of the opinion that the *build* system should be closely related to the *testing* system. And that relates to the "running in production" bits mentioned above. If we're building containers, then we should at least be testing them running inside a Kubernetes/OpenShift instance. And if you have that, then it just makes sense to use the same approach to run the build tooling - as a container. The build process is just another workload along with testing processes and other tools inside a production Kubernetes/OpenShift cluster. This is how it works today for the FCOS pipeline as well as downstream ones, and as mentioned above I think the ostree native container change will be a powerful incentive to "lift" the ostree side of things outside of Koji and into a container-native flow. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: New top-level dir: /state [WAS: Re: F36 Change: Relocate RPM database to /usr (System-Wide Change] proposal)
On Thu, Jan 13, 2022, at 6:05 PM, Fabio Valentini wrote: > The path "/usr/lib/sysimage/rpm" does look very out-of-place in > non-image-based systems, so *if* we want to move the rpmdb to a place > that's consistent across all our Editions, it should also be a > location name that makes sense across all Editions. I don't think we should discount alignment with OpenSUSE. When they originally proposed /usr/lib/sysimage I started to write a bikeshed reply email (like many that have been posted here) around why /usr/share was a bit better but then I said to myself: "You know what? I don't care as long as we get it in /usr. Since they're driving the change, and there really isn't any technical compelling reason to do something else, it's fine." Also, proliferation of these paths has a cost; see e.g. https://github.com/openSUSE/libsolv/pull/386 Though in practice *most* cases will be fine just chasing a symlink from /var/lib/rpm. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: New top-level dir: /state [WAS: Re: F36 Change: Relocate RPM database to /usr (System-Wide Change] proposal)
On Fri, Jan 14, 2022, at 2:46 AM, Chris Murphy wrote: > > What about /var/lib/selinux? It's owned by the selinux-policy-targeted > package. Even though the files may not change often, it probably needs > to be snapshot and rolled back with revision matching for /usr and > rpmdb. Yep, welcome to https://bugzilla.redhat.com/show_bug.cgi?id=1290659 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: New top-level dir: /state [WAS: Re: F36 Change: Relocate RPM database to /usr (System-Wide Change] proposal)
On Thu, Jan 13, 2022, at 7:52 AM, Vít Ondruch wrote: > Actually, shouldn't rpm-ostree carry around some copy of the RPM > database, which would describe the state of /usr and once the update is > successful (or snapshot active?), merge it into the main system RPM > database? Apparently, something like this is already happening e.g. for > /etc content if I understand it correctly. Or this is the direction in > which the /boot will be handled eventually. Or possibly it could be just > some linked (possibly just read only) database. I think you are confusing/conflating image based updates and client side snapshots (and relatedly, client side offline updates, which is what https://github.com/OpenSUSE/transactional-update). They are related, but different. It's important to emphasize that rpm-ostree systems are by default, *image based*. For example, every single Fedora CoreOS system running the latest "stable" commit has *bit for bit identical /usr*, including the RPM database in /usr/share/rpm. All SELinux labeling was computed server side. All %post scripts were run on the build server. We perform integration testing on that image before it ever hits any user's disk. See https://github.com/coreos/fedora-coreos-tracker/issues/1066 for example. (This integration testing aspect is not true of Silverblue or IoT, because they just ship what bodhi ships, which is its own big problem) If one chooses to engage client side layering (or overrides), rpm-ostree will (each time an upgrade or change is performed) indeed regenerate the rpm database using the "pristine" base image's version of the rpmdb. What you are talking about seems more related to client side snapshots and/or client side offline updates. So in your phrasing above I'd say something more like "proposed dnf/snapper tooling" or so, and not rpm-ostree which works in a different way. > IOW, imagine, that we still keep the system read/write RPM database in > /var and we teach RPM to use additional database(s). So RPM would know > that there might be some additional database e.g. in /usr/var/ ... The > system database would not know nothing about content of /usr, but once > /usr was mounted, `rpm -q` would provide the information from the linked > RPM database. I am having trouble understanding what you are thinking here. If you are interested in this, I'd recommend taking some time trying out an existing system that is doing some of these things; either an OpenSUSE transactional-update system or an rpm-ostree system for example. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: New top-level dir: /state [WAS: Re: F36 Change: Relocate RPM database to /usr (System-Wide Change] proposal)
On Wed, Jan 12, 2022, at 4:04 AM, Panu Matilainen wrote: > > Here seems to be another SMALL undocumented dependency of this change: > completing the /usrmove thing to cover the whole world including /opt, > /etc, /var, and presumably /boot as well because packages put stuff in it. There are very few packages that put things in /boot. For example, fwupd used to be in that set, but moved into a "self updater" model where the binary goes in /usr, and then it copies itself into the ESP instead of having yum/rpm do it. Now, rpm-ostree also does this with /boot: https://github.com/coreos/rpm-ostree/blob/210bf148342a9545c9841ae6d8403354ce49b672/src/libpriv/rpmostree-util.cxx#L134 And then we have a sister project https://github.com/coreos/bootupd/ that is only shipped in FCOS today (but would make sense to use on everything that uses rpm-ostree) which is scoped explicitly to only handle stuff on the ESP (and eventually, stuff like grub on the MBR and other architectures too). Correct handling of /boot is obviously essential for transactional updates; ostree is entirely designed around a "strong binding" of (kernel, userspace) pairs. Handling kernels in /boot for "client side snapshots" is something most projects in this space do out of band, as far as I've seen. Again, it's really that 90% of the data in the rpmdb is for /usr. We recently changed the kernel RPM to stick the kernel binary in /usr/lib/modules/$kver and only *copy* it from there to strengthen this model. And this move is pushing things farther along in that direction. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: /opt [WAS: Re: New top-level dir]
On Wed, Jan 12, 2022, at 4:05 AM, Zbigniew Jędrzejewski-Szmek wrote: > On Mon, Jan 10, 2022 at 02:53:52PM -0700, Chris Murphy wrote: >> Should /usr be independently portable? And is that with a version >> matched /opt, or can there be mix and match revisions of /usr and >> /opt? > > We have three similar locations: /usr (system vendor tree), > /usr/local (admin non-packages installations), /opt (external vendor tree). > In other words, both /usr and /opt are for packages, but from different > sources. As an admin, you'd want to treat both package types the same, > and e.g. roll them back together. So having a separate tree for /opt > doesn't make much sense. > > [At some point in the future] /opt should be renamed to /usr/opt and > symlinked for backwards compat. Unfortunately, real world RPMs that install into /opt also have e.g. log files in /opt/somesoftware/log, not /var/log/somesoftware. So it can't be underneath the read-only /usr mount. This is why rpm-ostree just straight up rejects RPMs that install into /opt. https://github.com/coreos/rpm-ostree/issues/233 I think I agree with Chris that really what we want is a separate rpmdb for this. That would mean these packages don't participate in offline transactional updates, can't be rolled back etc. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: /opt [WAS: Re: New top-level dir]
On Wed, Jan 12, 2022, at 4:24 AM, Panu Matilainen wrote: > > Oh, right. More hidden agenda behind this thing. When looking at it with > these glasses on, it explains quite a few things about the change > proposal, such as completely ignoring the fact that nearly all packages > put something in /etc. Right. rpm-ostree uses ostree, which introduces /usr/etc which are the pristine default config files. /etc is 3-way merged by ostree. One of the major benefits of this that I really love is `ostree admin config-diff` - at any point we can show you machine-local changes from the default, and it's trivial to reset back to defaults without redownloading a whole RPM. The semantics of /etc are also one of the things that is very different between ostree and other image based update systems, including the "systemd upstream vision" introduced a while back, which is basically that /etc starts empty, can be populated dynamically, but is otherwise not touched across system upgrades. The core problem with this is it introduces a new major hysteresis point which is your copy of /etc is mostly from the initial installed OS version. You don't get *new default* config files, and even worse, packages that drop config files still linger around in this model. I personally think ostree's handling of /etc is one of the things that makes it feel much more like a Unix system than other image based update systems. There's no hidden agenda - the goal is to support image based updates as well as client side snapshots, factory reset, etc. And we're shipping today versions of Fedora that do a lot of this, and we want to continue to improve it. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: New top-level dir: /state [WAS: Re: F36 Change: Relocate RPM database to /usr (System-Wide Change] proposal)
On Tue, Jan 11, 2022, at 4:00 AM, Panu Matilainen wrote: > The point was though, that the rpmdb is not at all the only data of this > kind and so having a dedicated home makes sense. You mentioned dnf/yum/PackageKit data; there's two kinds of that. One is e.g. /var/cache/dnf which does *not* move. It's just a cache. (Now there is this whole other very interesting thread around "why don't we include a cache of the rpm-md inside e.g. ostree or container images? And the reason why not is we don't want to have to respin all images every time a package not in the image changes) dnf does have its own outside-of-rpm state database in /var/lib/dnf which is closer to this. The situation with that is messier. AIUI this proposal so far is not calling for moving this. Where it lives and how it's versioned has strong implications for the people who want to support snapshot/rollback. But it's not relevant for rpm-ostree, which does not use this part of libdnf. We maintain our own little "state file" - for lots more detail on this, see https://github.com/coreos/rpm-ostree/issues/2326 (And it's important to note that rpm-ostree's origin file has almost nothing *unless* one explicitly engages client-side layering/overrides) > For one, /state (or whatever toplevel directory) allows for the fact > that there are write-operations to rpmdb that do not touch any external > files while maintaining read-only /usr. Such as rpmdb --rebuilddb, `rpmdb --rebuilddb` is basically about supporting switching from e.g. bdb to sqlite, right? On the rpm-ostree side at least, the default format comes from the base image; there's no reason to directly support `rpmdb --rebuilddb` as something any normal user or admin would need. > or rpm --import. OK yes, this (along with rpms that install into /opt as you mentioned) are I think the biggest examples of "rpmdb has stuff not about /usr". rpm --import actually encapsulates really well all the problems and benefits with everything we're trying to do. I have a big related blurb here https://github.com/rpm-software-management/libdnf/issues/43 But as I understand it, the creation of /etc/pki/rpm-gpg was at least partially motivated by the fact that in the traditional RPM model, the fact that GPG keys are stored in the rpmdb meant there was no way to update them "in band" of a default rpm operation. Today Fedora ships these GPG keys as an RPM which hence contain files, and when you type `yum upgrade` (or rpm-ostree upgrade) you get updates to those files, the same as other files. Now, as noted in the issue PackageKit (whose code was the precursor to libdnf, which has the code that rpm-ostree uses but AFAIK still not current dnf which has this logic in Python) auto-imports all of them. I am not completely sure how updating the rpmdb with new e.g. Fedora GPG key works. It might be part of system-upgrade or something? And then this all relates to a higher level goal we have with "image based updates", which is avoiding (or minimizing as much as possible) per-system hysteresis or "unmanaged state", particularly opaque (hard to see/diagnose/inspect) state. This set of trusted GPG keys stored in the rpmdb is both. The set of keys will just keep growing across in-place upgrades, depending on the initial Fedora version installed. And wh And this is security-relevant state, it's the set of trusted keys for RPM. Now, I am sure a number of sysadmins do understand that the rpmdb contains GPG keys. I'd bet a whole lot don't. I definitely think that it's confusing to have both /etc/pki/rpm-gpg *and* keys stored in the rpmdb. Of the two, I think the former - i.e. text files one can edit with standard tools - is much easier to understand and work with. It's also already in a place that is designed for users to edit in `/etc`. So by moving the rpmdb to /usr, it's basically saying that `rpm --import` should change. That said, this design could also clearly use some "systemd style" config model. ostree already supports /usr/share/ostree/trusted.gpg.d which is designed for keys shipped by the OS vendor. But, what's really tricky about this is we want to support in-place updates from previous versions (i.e. at least N-1), but hopefully not too old versions. Well, this is leading to a tangent so I'll cut off this sub-thread. The TL;DR for me is: I think everyone agrees that moving the rpmdb as it is today to /usr is not 100% a perfect fit. But it's a ~90% fit - almost all the raw data is just headers which are clearly immutable data generated elsewhere. And by making this change, we're basically saying we'll fix the remaining 10% of cases. Note for the people who are trying to do "client side snapshot/rollback" (i.e. the people whose names are attached to the Change), the rpmdb is still mutable by default. And I think their idea is is that by doing a "snapshot, then upgrade in place via traditional rpm/yum methods"
Re: New top-level dir: /state [WAS: Re: F36 Change: Relocate RPM database to /usr (System-Wide Change] proposal)
On Mon, Jan 10, 2022, at 11:19 AM, David Cantrell wrote: > On Wed, Dec 29, 2021 at 10:01:57AM -0500, Ben Cotton wrote: >>https://fedoraproject.org/wiki/Changes/RelocateRPMToUsr >> >>== Summary == >>Currently, the RPM databases is located in `/var`. Let's move it to >>`/usr`. The move is already under way in rpm-ostree-based >>installations, and in (open)SUSE. >>[snip] > > Moving the RPM database to /usr feels incorrect to me, but we should move it > to gain the improvements as noted in the feature proposal. > > Numerous followups have noted the requirement that /usr contain read-only > content, that it be shareable across hosts, and similar concepts. While this > may or may not doable now like we could in the past, the bigger thing to me is > around the understanding of what /usr contains. It is generally understood > that /usr contains [most of] the installed system. What I think is a bigger > requirement or expection now is that one can tar up /usr and transport it to > another system or virtual machine or container and expect that it will > _probably_ work maybe with a bit of tinkering. This is a really valuable > thing to have for developers. No, this is not about developers tar'ing up `/usr` by hand. It's about cleanly separating who owns what, and what its lifecycle is, which is critcially important for both "image based" updates as well as "local client side snapshots". Both these approaches end up creating more than one copy of certain files. See - https://blog.verbum.org/2020/08/22/immutable-%E2%86%92-reprovisionable-anti-hysteresis/ - http://lists.rpm.org/pipermail/rpm-maint/2021-December/018770.html > Moving the RPM database to this tree adds a > component that is unnecessary and sort of out of place. I struggle to how to even respond to this. Multiple independent groups who *actually work* on image based updates and/or client side snapshots all generally agree that the rpmdb should be in /usr. That's where this Change came in. On what basis are you making this claim "unnecessary and sort of out of place"? > > "OK, but you can do tar -X" > > The tar example was simply that, an example. I feel the categorization of > system data is more important here. Panu brought this up on the referenced > RPM mailing list thread years ago. The original /var location for the RPM > database was fine, but we're at a point where we kind of have multiple > categories of things historically found in /var. > > Reading comments and talking to people, the long standing understanding of > /var is still "that's stuff you can rm -rf and the system will still work > fine". Yes, we call this "factory reset". https://github.com/coreos/fedora-coreos-tracker/issues/399 I am not sure where the terminology came from, but it is widely used when talking about e.g. mobile phones today. > Technically you could remove the RPM database and the system still > function, but arguably would still be broken since you really want the RPM > database. This use case of removing the RPM database and still having a > functioning system is really only useful for data recovery scenarios. You're > ultimately going to reinstall. Probably. At least from my PoV, the rpmdb is by default read-only (except to rpm-ostree) along with the rest of /usr, so you can't just rm -rf it alone. > So maybe the question is more "what is the correct location for data like the > RPM database?" First, how is that data different from the rest of /var? It > is host-specific, No. An image based updates model (both ostree and container images) ships a pristine copy that is bit-for-bit the same on every system. Container runtimes tend to make it mutable by default of course, but that doesn't change the fact that it's not by default host specific. > I would like to see Fedora introduce a new top-level directory called: > > /state We have years of investment in rpm-ostree in the current design. For example, the tooling supports `rpm-ostree db diff` which shows you the delta between the current and pending rpmdb. How would this new directory work? How would it better solve problems that are today solved with the location in /usr? And do you even have a sense of how much work would creating for the rpm-ostree stack at least with a new toplevel directory with new, as yet ill-defined semantics? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: DIGLIM (System-Wide Change proposal)
Hi Kevin, On Mon, Dec 27, 2021, at 11:50 AM, Kevin Kofler via devel wrote: > > But being allowed to run custom or self-developed software is a core feature > of Free Software. If that stops working in the name of "security", Fedora is > no better than iOS (where Apple also claims the restrictions are for > "security" purposes), and becomes entirely useless for me. This blog entry I did a while ago touches on this: https://blog.verbum.org/2019/12/23/starting-from-open-and-foss/ I am obviously speaking for myself there, but I know at least some others on the Fedora CoreOS team agree. It's funny because I have had to near-constantly battle the concept that Fedora CoreOS is somehow out to "restrict" people. Opinionated? Yes. But you can still replace the kernel, build from source, etc. As the blog says, I think the only sane thing to do with file/partition integrity systems like this is to make them supported by Fedora to deploy for custom builds. Now there's a whole huge topic here that it's *really hard* to make a system that is both e.g. an ISO you can stick in and install easily *and* offer the whole toolbox of build (and CI!) tools as a "product" to users. But anyways, it's good that you raise this point and concern, but there's no reason for you to worry. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change proposal: No ifcfg by default (Self-Contained Change)
I don't think we need to go too deep on this cloud-init vs Ignition thread; but you have a great message here and I just want to clarify some points, everything else you said here is fair/accurate/relevant from my PoV. On Wed, Jan 5, 2022, at 10:41 AM, David Duncan wrote: > In most of those > cases it has mostly been replaced in an effort to decrease boot time and > limit functionality to force the configuration time into the user space > instead of prior to instance service checks or replace the slower python > with a compiled language like go. In the case of Ignition, that's not quite accurate. I was not personally involved in the creation of Ignition, but this document lays it all out: https://coreos.github.io/ignition/rationale/ In particular, I don't think the boot speed or programming languages were ever a big part of the argument. To pick one thing from that list, the Ignition philosopy of running in the initramfs meaning you avoid whole large classes of race conditions of trying to re-configure the system in the middle of boot was a primary component.(OK this does lead into the language thing a bit I guess because no one sane wants Python in their initramfs, but it's really not about speed) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change proposal: No ifcfg by default (Self-Contained Change)
On Wed, Jan 5, 2022, at 9:05 AM, Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/NoIfcfgFiles > > == Summary == > Do not not include NetworkManager support for legacy network > configuration files by in new installations. It'd be nice to note this Change is actually just doing for other editions what Fedora CoreOS has been doing since it was created. xref https://github.com/coreos/fedora-coreos-tracker/issues/24 and https://github.com/coreos/fedora-coreos-config/commit/a3834830db2ff66e43690a18c585cd96c48af826#diff-a75be0683fa944e789e6a29b3661927410a368e4b5f18c9cd283af4169abc5d4 (Which would be, what the 3rd change for which we're just doing elsewhere what FCOS is doing already now? The rpmdb move, the sulogin one, and now this) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change proposal: No ifcfg by default (Self-Contained Change)
On Wed, Jan 5, 2022, at 9:22 AM, Neal Gompa wrote: > > There are none. Ignition deliberately cannot configure the network, This is not true. https://docs.fedoraproject.org/en-US/fedora-coreos/sysconfig-network-configuration/#_via_ignition > and as a CoreOS tool, it is incapable of configuring the system to the > same level cloud-init can anyway. Er, what? Please see the whole above doc. A big part of the idea of CoreOS is that our tooling is symmetric across bare metal and cloud - and in the bare metal world, *lots* of nontrivial networking problems come up. It's hard to understate the amount of time we've spent on this. IMO we have a quite cool model now - our live ISO *is* CoreOS too, but doesn't require networking by default to fetch Ignition. You can inject an Ignition config into the ISO, and then e.g. boot that ISO in systems like vSphere or attach via IPMI virtual media etc. That Ignition config can then contain an Ignition config for the *real* system with static IP address, etc. > Fedora Cloud will be forced to disable NetworkManager and switch back > to legacy network-scripts if this Change goes through. I don't want to > do that, because I *like* NetworkManager. I guess I could modify the > NetworkManager config as part of creating the image to re-enable the > ifcfg-rh plugin, but if it is getting disabled by default, it's not > far away from getting dropped. That's for the NM team to answer, but it certainly seems to me the simplest thing is for cloud-init systems to re-enable the ifcfg-rh backend for now. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [Rpm-maint] RFC: Relocate RPM and DNF databases to /usr
On Mon, Jan 3, 2022, at 2:44 AM, Panu Matilainen wrote: > On 12/16/21 16:41, Colin Walters wrote: > >> I didn't wake up one day and say "hey you know what, today I'm going to move >> the rpm database just for fun". Neither, for that matter did the OpenSUSE >> folks. We haven't had this conversation over and over throughout the years >> just because it was some minor thing. >> >> What I *did* wake up one day and say I'm going to do is make upgrades >> transactional and offline by default and hence safe. No one should ever >> fear starting an operating system upgrade while their laptop is at 30% >> battery. Administrators running important servers must be able to easily >> roll back when the kernel *or* systemd (or something) else regresses, >> because it's software, it regresses all the time despite our best efforts. >> >> So yes again, this does matter. And it matters because whether you're doing >> "image based upgrades" like ostree or just "client side offline updates" >> like the >> https://kubic.opensuse.org/documentation/man-pages/transactional-update.8.html >> thing - it's very important *what data specifically* is >> versioned/snapshotted and what isn't. On an ostree system for example, it's >> completely normal that there are *two* rpm databases (one you're running, >> one that's pending in the new root). >> >> All the data in the rpmdb is about content that's in `/usr`. > > But that's just plain, utter bollocks. > > On modern distros, MOST of rpmdb may be about /usr content but most is > not all, not by a long shot. If that's an assumption this change is > based on then it needs to stop right there. There is indeed the `/opt` issue that Florian raised. But is there other data you're thinking of? ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: F36 Change: Relocate RPM database to /usr (System-Wide Change proposal)
For the record, I obviously support this change. Responding to a few threads: On Wed, Dec 29, 2021, at 10:16 AM, Peter Robinson wrote: > How does this work on RO /usr files systems? I thought data in /usr > was supposed to be static/ It works for rpm-ostree because it's > updated at tree creation time. I think you know this but it's worth elaborating on here; rpm-ostree supports client-side layering (and overrides too) and even live updates - and those all operate by default while maintaining `/usr` read-only from the perspective of the rest of the system. The way this works ultimately is quite simple; the underlying filesystem is writable, we just remount it writable *in a private mount namespace*. So even when you do e.g. `rpm-ostree install -A usbguard`, there is no point where *other* processes can write. People are focusing a bit too much on "read-only" in this thread - it's more about "lifecycle binding" and versioning the binaries together with metadata about the binaries. On Thu, Dec 30, 2021, at 1:57 PM, Chris Murphy wrote: >> What happens if /var/lib is read-only? Changing (fixing?) this would >> be a pre-requisite to this proposal, we don't want 'dnf list' to break. Why would /var/lib be read-only, but /usr be writable? > Why should it be a prerequisite? In all Fedora editions and spins with > dnf, /usr and /var are read-write. In the case of rpm-ostree based > editions and spins, they don't include dnf. Remember rpm-ostree links to libdnf, and significant code is hence shared. That's part of the ASCII-art architecture diagram in the docs https://coreos.github.io/rpm-ostree/ The way I'd say this is it aligns "traditional" dnf systems with what rpm-ostree has been doing for many years now, and that will help share *even more* code and logic in the future. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Make Authselect Mandatory (System-Wide Change proposal)
On Tue, Oct 12, 2021, at 11:32 AM, Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/Make_Authselect_Mandatory Just to raise the visibility here, this currently breaks all ostree-based systems (*again*): https://bugzilla.redhat.com/show_bug.cgi?id=2019052#c1 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: About how Go is updated in Fedora
On Sat, Dec 18, 2021, at 5:06 PM, Fabio Valentini wrote: > > Sure, I saw that ticket. But I fail to see how this is this a "new problem". > If you use, for example, some shiny, new features that are only going > to be in GCC 12 or LLVM 14, There's a *big* difference between Go and C/C++/Rust though, which is that the version of the Go compiler you use at build time becomes the version of the Go *runtime* statically linked into your binary, with implications for things like GC performance. Go's 6-month cadence is also much faster than C/C++ (though also much slower than Rust's, but the Rust 6 week releases are also smaller, and anyways generally the ecosystem is OK with "older" Rust compilers). Also relating to the release cycle, Go releases tend to add new features that parts of the ecosystem adapt relatively quickly. That seems likely to continue with 1.18 and the early generics. > you'd be out of luck on stable Fedora > branches, as well. Not quite; one doesn't need to use the single Go compiler version in RPM form from Fedora except currently when shipping software built as Fedora RPMs. (I know this was implicit in this discussion, but it's worth noting because people can and do get the Go compiler from e.g. upstream on Fedora systems too to build and ship software outside of the Fedora package collection itself) That said, I don't quite understand why it's so complex to use modularity as part of building non-modular RPMs. (But I know this was extensively discussed, I didn't follow it really) It seems like it's more about maintaining multiple builds of the compiler/runtime. It's interesting to note that in CentOS Stream 8, go-toolset is modularized, but that's not true in CentOS Stream 9. Also related to this, it's worth looking at what others do; e.g. NixOS seems to maintain a few versions of Go: https://github.com/NixOS/nixpkgs/tree/master/pkgs/development/compilers/go But they only have one Rust version. Although there are a ton of derivations for gcc and llvm, I suspect only a few are used. It looks like Debian ships package+versions, e.g. `golang` is 1.17, and there's `golang-1.15` in unstable. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [Rpm-maint] RFC: Relocate RPM and DNF databases to /usr
On Wed, Dec 15, 2021, at 5:34 PM, Florian Weimer wrote: > * Chris Murphy: > >> Fedora 36 seems like a good time to do this. What do you think? > > It's a bit odd to locate a database under /usr that isn't pre-built and > installed. Why is that odd? > I guess in theory there could be systems with a read-only > /usr out there that still allow installation of packages into /opt. > > Does it really help to improve the snapshot situation? Yes. I didn't wake up one day and say "hey you know what, today I'm going to move the rpm database just for fun". Neither, for that matter did the OpenSUSE folks. We haven't had this conversation over and over throughout the years just because it was some minor thing. What I *did* wake up one day and say I'm going to do is make upgrades transactional and offline by default and hence safe. No one should ever fear starting an operating system upgrade while their laptop is at 30% battery. Administrators running important servers must be able to easily roll back when the kernel *or* systemd (or something) else regresses, because it's software, it regresses all the time despite our best efforts. So yes again, this does matter. And it matters because whether you're doing "image based upgrades" like ostree or just "client side offline updates" like the https://kubic.opensuse.org/documentation/man-pages/transactional-update.8.html thing - it's very important *what data specifically* is versioned/snapshotted and what isn't. On an ostree system for example, it's completely normal that there are *two* rpm databases (one you're running, one that's pending in the new root). All the data in the rpmdb is about content that's in `/usr`. > What about > software under /opt? https://github.com/coreos/rpm-ostree/issues/233 Today indeed, rpm-ostree explicitly denies that. Which, note we can do because we basically take over chunks of what librpm is doing on non-ostree systems. But, it would be nice to drive some of this support into librpm too so it applies to non-ostree-but-snapshottable systems. > Maybe this needs multiple RPM databases > eventually, roughly aligned along file system boundaries. Yeah, that's one approach, though I would scope it really to just "/usr rpmdb" and "/usr/local" rpmdb - i.e. `/opt` and `/usr/local` are basically the same thing with different names. ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-ecosystem] [Rpm-maint] RFC: Relocate RPM and DNF databases to /usr
On Wed, Dec 15, 2021, at 5:34 PM, Florian Weimer wrote: > * Chris Murphy: > >> Fedora 36 seems like a good time to do this. What do you think? > > It's a bit odd to locate a database under /usr that isn't pre-built and > installed. Why is that odd? > I guess in theory there could be systems with a read-only > /usr out there that still allow installation of packages into /opt. > > Does it really help to improve the snapshot situation? Yes. I didn't wake up one day and say "hey you know what, today I'm going to move the rpm database just for fun". Neither, for that matter did the OpenSUSE folks. We haven't had this conversation over and over throughout the years just because it was some minor thing. What I *did* wake up one day and say I'm going to do is make upgrades transactional and offline by default and hence safe. No one should ever fear starting an operating system upgrade while their laptop is at 30% battery. Administrators running important servers must be able to easily roll back when the kernel *or* systemd (or something) else regresses, because it's software, it regresses all the time despite our best efforts. So yes again, this does matter. And it matters because whether you're doing "image based upgrades" like ostree or just "client side offline updates" like the https://kubic.opensuse.org/documentation/man-pages/transactional-update.8.html thing - it's very important *what data specifically* is versioned/snapshotted and what isn't. On an ostree system for example, it's completely normal that there are *two* rpm databases (one you're running, one that's pending in the new root). All the data in the rpmdb is about content that's in `/usr`. > What about > software under /opt? https://github.com/coreos/rpm-ostree/issues/233 Today indeed, rpm-ostree explicitly denies that. Which, note we can do because we basically take over chunks of what librpm is doing on non-ostree systems. But, it would be nice to drive some of this support into librpm too so it applies to non-ostree-but-snapshottable systems. > Maybe this needs multiple RPM databases > eventually, roughly aligned along file system boundaries. Yeah, that's one approach, though I would scope it really to just "/usr rpmdb" and "/usr/local" rpmdb - i.e. `/opt` and `/usr/local` are basically the same thing with different names. ___ Rpm-ecosystem mailing list Rpm-ecosystem@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-ecosystem
Re: F36 Change: Enable fs-verity in RPM (System-Wide Change proposal)
On Mon, Dec 13, 2021, at 5:21 PM, Tom Stellard wrote: > > Did you test the impact this has on package build times? Particularly > packages like llvm, clang, webkit2gtk3, etc. that have very large > debuginfo files? I think far too often the culture here is "make $change for all RPMs". But this "everything is an RPM" mindset can lead to outcomes and methodology that is at best weird. For e.g. "let's try building with newer gcc", it would seem far better to me to e.g. start with the things that are in Fedora CoreOS or Workstation or whatever. (And, optionally their build dependencies) For *this* particular change, the value of pre-signing the -debug RPMs seems...weak. Or even the `-devel` RPMs. Now, obviously choosing *which* binaries to sign would require some thought. But I think that's worth doing instead of blindly doing everything. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Enable fs-verity in RPM (System-Wide Change proposal)
On Wed, Dec 15, 2021, at 1:45 PM, Luca Boccassi wrote: >> On Fri, Dec 10, 2021 at 10:47:52AM +0100, Vít Ondruch wrote: >> >> Any file covered by fs-verity is immutable after installation. So you >> cannot modify the contents, the kernel refuses. But you can just >> replace the file (like during an upgrade), and of course copy and edit >> in a different location. If replaced, no fs-verity checking is done >> any more by the kernel. There was some talk about high-level solution >> to prevent such files from being executed, e.g. an LSM module, but no >> details... (Thinking about this, it would be pretty hard, because the >> LSM would need to be smart enough to know which files are installed >> through rpm, and which files are not. I would love to hear more details >> about what is planned here.) >> >> Zbyszek > > There is such an LSM that supports fs-verity (and dm-verity), being > reviewed right now: IPE > > https://lore.kernel.org/lkml/81d5e825-1ee2-8f6b-cd9d-07b0f8bd3...@linux.microsoft.com/T/ > https://microsoft.github.io/ipe/ Hmm. Some interesting stuff going on there but I would have started with a new SELinux access vector. That'd allow fine-grained constraints, e.g. disallowing `init_t` but allowing `unconfined_service_t`. Possibly also landlock should be able to hook into this. IOW it's not clear to me that a new LSM is the best thing for the ecosystem here. But bigger picture I'd agree that fs-verity is significantly stronger when coupled with such a policy - strong enough to block exploits like the runc one: https://unit42.paloaltonetworks.com/breaking-docker-via-runc-explaining-cve-2019-5736/ (Of course that one was *also* stopped by ostree's default read-only bind mount, which I keep saying is not really primarily about security, but hey it worked there) I said this about the IMA-for-Fedora proposal too - to me the approach of "sign all the RPMs" is not a good idea. Instead the focus should be on ensuring the capability works, and is usable from tools to build custom systems. And this of course runs into a bigger picture question of whether we should emphasize the entry point into Fedora being Anaconda/FCOS like (provision and configure a "pre-built" system) or more like Image Builder and tools like that. I think the answer has to be "we do both" really - it's just hard. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [Rpm-maint] RFC: Relocate RPM and DNF databases to /usr
On Thu, Dec 9, 2021, at 10:11 AM, Chris Murphy wrote: >> The change is not so simple. It is not only the movement of files from one >> location to another one. We store more types of data in that location - >> history database (sqlite), module failsafe data (yamls). In future we will >> store system state data (toml). Data is not only modified after RPM >> transactions but also by module and mark commands. What I want to say is >> that the change will be painful but in the proposal there are limited >> benefits. When the rpmdb was bdb and not extensible, I understand the idea of dnf having its own separate database. But I don't understand why there are two separate sqlite databases now. Anyways, a lot going on here and rather than point by point I'll say basically: It'd be great from the rpm-ostree PoV to have a shared consistent place for the rpmdb. Last time this came up I think Panu really wanted to get the sqlite change out first, which - fair. But now that's done, so are there any other blockers? We could try simply not changing existing systems in-place at first, but just do it for new installs, add the backcompat symlink, ensure the stack looks in both places (preferring new); that's actually mostly done AFAIK. Today rpm-ostree has its own state management that doesn't use the libdnf history stuff. Longer term it would be good to have a unified vision there - most of this is touched on in https://github.com/coreos/rpm-ostree/issues/2326 But I think I'm arguing to decouple the rpmdb move from the dnf move. ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
