Re: RFC should authselect require nss_altfiles

[Colin Walters]

On Wed, Oct 9, 2024 at 6:56 AM Pavel Březina  wrote:

> Hi Fedora,
> nss-altfiles is not currently part of the default installation and can
> be optionally added to nsswitch.conf via authselect's with-altfiles.
>
> This however breaks ostree composes since it uses and requires alltfiles
> to provide system users. This is handled in authselect spec file that
> tinkers with the shipped profiles and hardcodes altfiles to the
> configuration. [1] It works as expected.
>
> Downside is that the authselect content we ship is different for ostree
> systems and standard composes.
>
> There is also an issue with bootc. Authselect have to be part of the
> source bootc image, if it is installed later by dnf, it does not work
> because there is no /run/ostree-booted during container image build
> time. This, however, does not really affect Fedora 38+ since authselect
> is required by pam and part of default installation. It may affect other
> distributions though.
>
> Unless there is some push back, I would like to change authselect to
> require nss-altfiles and hardcode altfiles in nsswitch.conf for everyone
> and finally get rid of this duality.
>

I'm not going to object to that (others might) but this discussion does
overlap with
https://github.com/uapi-group/specifications/issues/76#issuecomment-2378640320
a bit in that...I think a closer-to-ideal solution is that glibc supports
drop-ins or discovery,
something like `/usr/lib/glibc/nss.d/passwd/90-altfiles ->
 /usr/lib64/libnss_altfiles.so.2` or so...

Then we get nss-altfiles in the list if and only if it's installed, and
regardless of the authselect profile in use, which I think is what we've
wanted from the start 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: Using /usr/etc/services as a fallback for /etc/services (and other NSS files)

[Colin Walters]

On Fri, Sep 27, 2024, at 11:31 AM, Florian Weimer wrote:
> Do you see any problems if glibc starts using /usr/etc/services if
> /etc/services does not exist?

Please avoid having projects unconditionally read `/usr/etc`
because on ostree based systems `/usr/etc/services` will always
exist; we use it for our 3-way merge of /etc.
(It's actually also really nice to have the defaults always
 visible, that's how `ostree admin config-diff` works)

It will start to conflict if other projects put things there.

Now our technical direction may go in a place where we
move away from `/usr/etc` and do things differently
(and this is a whole *other* big thing to align in api
 probably).

Please use a project-specific namespace as you suggested
below.

>  Same for /usr/etc/protocols, /usr/etc/rpc
> and so on.  It's already used on openSUSE, apparently.

Hmmm. OK, messy.

>   Tracking upstream projects that do not support hermetic-usr for 
> configuration
>   

Now we have discussion of this split across 3 different forums;
probably the glibc list is the best place to hash this 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

heads up: julia has a bunch of incorrect Provides (bug 2291191)

[Colin Walters]

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: EncourageI686LeafRemoval Change: Please make sure it's actually a leaf package

[Colin Walters]

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

[Colin Walters]

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

[Colin Walters]

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: An update on RHEL moving to issues.redhat.com

[Colin Walters]

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

[Colin Walters]

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

[Colin Walters]

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

[Colin Walters]

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: Adding Passim as a Fedora 40 feature?

[Colin Walters]

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: Towards enabling rpm sysusers integration

[Colin Walters]

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

[Colin Walters]

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

[Colin Walters]

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: OpenSSH: hardening hostkeys permissions

[Colin Walters]

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: Improving Fedora boot time when libvirt is installed

[Colin Walters]

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)

[Colin Walters]

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)

[Colin Walters]

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)

[Colin Walters]

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)

[Colin Walters]

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

[Colin Walters]

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)

[Colin Walters]

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)

[Colin Walters]

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)

[Colin Walters]

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)

[Colin Walters]

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)

[Colin Walters]

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)

[Colin Walters]

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: F38 proposal: Ostree Native Container (Phase 2, stable) (System-Wide Change proposal)

[Colin Walters]

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)

[Colin Walters]

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)

[Colin Walters]

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"

[Colin Walters]

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)

[Colin Walters]

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

Re: status update on "ostree native containers"

[Colin Walters]

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"

[Colin Walters]

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"

[Colin Walters]

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: Help packaging a "C" library written in Rust

[Colin Walters]

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

[Colin Walters]

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

[Colin Walters]

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

[Colin Walters]

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.

[Colin Walters]

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

[Colin Walters]

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.

[Colin Walters]

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

[Colin Walters]

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)

[Colin Walters]

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)

[Colin Walters]

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)

[Colin Walters]

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

[Colin Walters]

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

[Colin Walters]

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

[Colin Walters]

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

[Colin Walters]

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)

[Colin Walters]

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

[Colin Walters]

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

[Colin Walters]

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?

[Colin Walters]

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)

[Colin Walters]

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)

[Colin Walters]

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)

[Colin Walters]

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

[Colin Walters]

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)

[Colin Walters]

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)

[Colin Walters]

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)

[Colin Walters]

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)

[Colin Walters]

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]

[Colin Walters]

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]

[Colin Walters]

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)

[Colin Walters]

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" approac

Re: New top-level dir: /state [WAS: Re: F36 Change: Relocate RPM database to /usr (System-Wide Change] proposal)

[Colin Walters]

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)

[Colin Walters]

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)

[Colin Walters]

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)

[Colin Walters]

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)

[Colin Walters]

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: F36 Change: Relocate RPM database to /usr (System-Wide Change proposal)

[Colin Walters]

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)

[Colin Walters]

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

[Colin Walters]

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: F36 Change: Enable fs-verity in RPM (System-Wide Change proposal)

[Colin Walters]

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)

[Colin Walters]

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: F36 Change: Make Rescue Mode Work With Locked Root (System-Wide Change proposal)

[Colin Walters]

On Wed, Dec 8, 2021, at 1:28 PM, Chris Murphy wrote:
> On Wed, Dec 8, 2021 at 7:52 AM Lennart Poettering  
> wrote:
>>
>> On Di, 07.12.21 15:39, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
>>
>> > Latest systemd versions have been getting some support for the low-level
>> > parts, i.e. the low-level encrypted-secret storage. But we're missing the
>> > upper parts, i.e. how to actually use and update the passwords. I didn't
>> > even mention this, because we don't have a comprehensive story yet.
>> > I think it'd be necessary to write some pam module and/or authentication
>> > helper from scratch. It's probably not too much work, but nobody has
>> > signed up to do this.
>>
>> So here's what I'd suggest: let's define a group (my suggestion: let's
>> repurpose "wheel" for that) that has the effect that the passwords of
>> any user in it are also accepted as password for the root user,
>> implicitly. We'd have to add some small infra to collect these
>> passwords, and encrypt/sign them with TPM2, then propagate to the ESP
>> or to some EFI var or so, so that they can be honoured already in the
>> initrd.I mean in addition this is tantamount to moving `/etc/shadow` into 
>> the tpm, right?
>
> I'm skeptical of any TPM2 dependency because systems still do not come
> with them, in particular the significant minority of systems that are
> not part of the "made for Windows" marketing program that compels
> manufacturers to follow the Windows Hardware Compatibility Program.
> And yes you can install Windows 11 without a TPM, it just won't be
> preinstalled, and that make/model doesn't qualify for whatever Windows
> marketing programs OEM's get for having certified hardware. That's
> aside from the fact there's TPM 2.0 in hardware today that the kernel
> doesn't support and likely won't ever support.

Right.  I am in favor of having tight integration with the TPM of course, but 
it can't be used exclusively.

In particular, I think about half the posters in this thread are thinking of 
the desktop case, but the problem can easily happen on virtualized servers too 
- that's why we ship the bits we do in Fedora CoreOS.  And we need to consider 
public and private cloud (e.g. OpenStack/vSphere) instances which were 
provisioned without UEFI, as well as ppc64le and s390x.  And still today, the 
default for `virt-install` on x86_64 is BIOS.

So I'll just re-surface my idea of having the bootloader either pass 
information about its "locked" state to the kernel and to systemd, or have some 
sort of more declarative easily parsable config file for this that systemd 
could read (i.e. not `grub.cfg`).  The former seems better.  Either way there's 
just one "source of truth" and admins who *do* want to lock the system against 
casual keyboard interactive changes don't need to do it in two places.
___
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: ostree native containers / CoreOS layering (System-Wide Change proposal)

[Colin Walters]

On Wed, Dec 1, 2021, at 12:32 PM, Brian (bex) Exelbierd wrote:
> 
> Also, how does this intersect with Fedora IoT and their desire to move 
> to Imagebuilder?

Actually sorry you asked a specific question about IoT and I went off on a 
larger tangent.

The simple answer is: everything in the (rpm-)ostree stack that works today 
that IoT uses will continue to work and be maintained for quite some time to 
come.

From the build side to the client side.  We're *adding* the ability client side 
to pull container images, not also *removing* the ability to fetch via native 
ostree.  All that is still tested on every single pull request.

In particular, the very network-efficient ostree deltas on the wire.  But, 
longer term as part of this I plan to pour my efforts into helping the 
container stack with deltas, 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: F36 Change: ostree native containers / CoreOS layering (System-Wide Change proposal)

[Colin Walters]

On Wed, Dec 1, 2021, at 12:32 PM, Brian (bex) Exelbierd wrote:

> Also, how does this intersect with Fedora IoT and their desire to move 
> to Imagebuilder?

I'd love for one of the team members there to comment on this.  From the
FCOS side I can say there's interest in aligning CoreOS and Image Builder
where possible, but it's not going to happen overnight.   There's a fractal
world of complexity there that could be its own whole thread.

I think as a short version though, all this functionality will land in
(rpm-)ostree and be accessible to Image Builder should they choose to
use it.

Both Image Builder today and coreos-assembler are focused on building
what we'd after this change think of a *base image* (both container image and
disk images).

This notion of a container style derived image is more of a new thing.

And from the CoreOS side I think I'd say it is not a goal to expose
coreos-assembler to users as part of this.  This proposal currently
calls for supporting users to create their own derived images using
any *container* build system they want.  (Which, since I'm being
realistic, Dockerfile is sadly the lowest common denominator here)

That said, creating derived container images this way also is
going to motivate making it easy to create disk images (e.g. ISO, qcow2, AMI)
that take ostree-container images as input as a user-facing productized
thing.   It seems to me that Image Builder is a natural place
for that to happen.

I hope we can mostly avoid this need apart from special cases.
For many users for example, managing (building, paying for, versioniong,
garbage collecting) their own AMIs in EC2 isn't desirable.  Instead
being able to just build, version and test their own FCOS-derived
container images is much easier (and portable across clouds).

>
> Overall this looks exciting to me and I love the idea that I can write 
> an Dockerfile (or new thing) file to declare my layering and have it 
> all built (or rebuilt) via existing container tooling.

Thanks!
___
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: ostree native containers / CoreOS layering (System-Wide Change proposal)

[Colin Walters]

On Wed, Dec 1, 2021, at 11:33 AM, Neal Gompa wrote:

> A couple of things from my perspective:
>
> * I would like to see how this would enable CoreOS releases to go
> through Bodhi

To me, a notable chunk of the value of how we're doing FCOS is that
our build, test and release processes are tightly intertwined
and maintained by the same team.

It's really part of having an "image based" delivery flow - we're
responsible for that "one thing", instead of a distributed amorphous
notion of responsiblity that happens with packages.

We have deeply invested in a fully containerized build and test flow.
Our build and test code is all in a single big coreos-assembler
container.

We have a core principle that the pipeline is basically just scripting
what exists in coreos-assembler (it doesn't have significant nontrivial
logic itself), so it's easy to replicate locally.

That's...just not true of most other things in Fedora, and the value
of wedging Bodhi (particularly the karma aspect) into the mix isn't
clear to me.

I would say also that I personally am *very* strongly of the
opinion that as a general rule, bespoke imperative web apps/APIs
that we require humans to touch are generally a bad idea.  
Instead, the build and delivery pipeline should be as "git-ops" as possible.

We live in this world - see e.g.
https://github.com/coreos/fedora-coreos-config/blob/testing-devel/manifest-lock.x86_64.json
which defines the content that goes into FCOS.  It's JSON stored in git,
and bumping it runs through CI.  (I would like to consider changing
things to be auto-pull-request based, just like Dependabot e.g. so
that things are even more obvious; we didn't do that initially
out of concerns for PR noise, but lately I'm leaning towards it)

There's no database or web API involved, it's just JSON stored in git.

This is also similar to e.g.
https://github.com/NixOS/nixpkgs/pull/136462
Why should it be any harder than that?

But in the end of course, to really answer your question, this change
could perhaps indeed make it easier to push ostree-containers through
Bodhi.

And to be fully clear, a lot of what I wrote above applies to FCOS,
but not necessarily to the other editions that use (rpm-)ostree.

> That
> also means using registry.fedoraproject.org as the primary registry
> that replicates to quay.io.

Sure, I have no strong opinions there.  That's already touched on in
https://pagure.io/releng/issue/10399

> * How does this affect Kinoite, Silverblue, and CoreOS releases? Are
> they changing immediately to this mechanism?

I can't say for sure around time frames and specific editions.  But
*ideally* for f36:

- Client-side capability ships (done! You can try this today!  
https://coreos.github.io/rpm-ostree/container/ )
- Shipping e.g. quay.io/fedora/coreos:testing-devel with GPG signatures inside 
(we're keeping ostree GPG signatures even inside a container flow because we 
care about the OS!  xref https://github.com/ostreedev/ostree-rs-ext/pull/76 )
- We get sufficient experience from now till f36 to mark this capability stable 
in rpm-ostree

After that, well it gets fuzzy.  I have a lot of work to do on the client end, 
and I personally plan to drive this from the FCOS side. 

Where things get quite interesting of course is that suddenly container-style 
derivation becomes not just a possibility but an obvious thing to do.  IOW, it 
makes it more clearly possible that
the Fedora Silverblue build is the equivalent of:
```
FROM quay.io/fedora/coreos:stable
RUN yum -y install gnome-shell ...
```

(That said, I would like to keep all the build-side intelligence we have on 
rpm-ostree that is part of having a declarative input instead of Dockerfile, 
i.e. we'd still use treefiles etc.  This is also related to 
https://github.com/coreos/rpm-ostree/issues/2326 )

And if we do *that*, then other editions suddenly also get to use all the 
investment we've made in the FCOS CI too, and it changes how we think about all 
of this.  (Not to mention being able to use Ignition too for desktops, which is 
its own quite interesting aspect)
___
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: Users are administrators by default in the installer GUI. (Self-Contained Change proposal)

[Colin Walters]

On Wed, Dec 1, 2021, at 4:34 PM, Chris Adams wrote:
> Once upon a time, Colin Walters  said:
>> https://github.com/coreos/fedora-coreos-config/commit/eb74f2ea3e9b453902315539e4f327481162c4f8
>
> Missed this message earlier... this seems like this should be the
> default on pretty much all Fedora setups, with documentation on how to
> change it if you secure the boot loader.

Yeah, I agree.  Also related is
https://github.com/coreos/fedora-coreos-tracker/issues/134

Basically systemd doesn't know whether or not the bootloader is locked.
Longer term, perhaps there could be some standard variable for this passed from 
the bootloader to kernel/systemd that says whether or not the bootloader allows 
unauthenticated interactive keyboard changes (as grub does on default Fedora 
setups).  If it does, we can just unceremoniously drop to a root shell.
___
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: Users are administrators by default in the installer GUI. (Self-Contained Change proposal)

[Colin Walters]

On Tue, Nov 30, 2021, at 9:49 AM, Chris Adams wrote:
> Once upon a time, Ben Cotton  said:
>> Further, this change of defaults complements the default for root
>> account. The redesign of root setup screen in Fedora 35 makes it clear
>> that root should be left locked.
>
> So, not directly related to the proposal, but jumping in here because it
> goes with the above statement - the "root should be left locked" setup
> is a problem that keeps single-user mode broken.  I tried to follow the
> Fedora (and other distros) default of root being a locked account, and
> then found that it's a broken setup.

https://github.com/coreos/fedora-coreos-config/commit/eb74f2ea3e9b453902315539e4f327481162c4f8
___
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: ostree native containers / CoreOS layering (System-Wide Change proposal)

[Colin Walters]

On Wed, Nov 24, 2021, at 1:26 AM, Robin Lee wrote:
> 
> This function is unrelated to 'rpm' but unfortunately provided by 
> 'rpm-ostree'.
> Maybe we should provide another standalone tool so non-rpm/dnf-based
> distributions can be easier to deploy.

No, all the "ostree-container" logic lives in
https://github.com/ostreedev/ostree-rs-ext/
which as with the rest of ostree (and like podman/docker), has no dependency on 
rpm/dpkg/whatever and never will.  You can put whatever you want in it and 
build however you want.

If you look at the PR to rpm-ostree which added this functionality (this all 
exists today btw!)
https://github.com/coreos/rpm-ostree/pull/3139/files#diff-2e9d962a08321605940b5a657135052fbcef87b5e360662bb527c96d9a615542R56
you can see how rpm-ostree just picked up the ostree-ext changes as a library.

(While this is only somewhat related to your point, I think it is very 
interesting and important to note that a big part of this proposal is that we 
now easily expose the ability to inject non-RPM content into derived images and 
boot and upgrade them via rpm-ostree, so that's a "less RPM involved" angle)

ostree-ext also exposes a CLI, but see also 
https://github.com/ostreedev/ostree/issues/2480

That said, it is certainly true that ostree is more of a low level library and 
most of our effort is on rpm-ostree.  Eventually perhaps it may make sense to 
have at least a polished shared CLI/daemon code upstream in ostree that gets 
shared more across distributions, but there's nontrivial 
logistical/political/technical aspects to that.  It's perhaps somewhat 
analogous to librpm versus dnf/zypper.

Also omitted from this is that my job also involves making all this work really 
well in OpenShift/Kubernetes in addition to this change (which is basically 
just talking about "single node"/"baseos" functionality that applies to 
non-Kubernetes Fedora cases too).   So juggling those two has taken most of my 
personal time versus polishing the "ostree but not rpm-ostree" case.
___
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: ostree native containers / CoreOS layering (System-Wide Change proposal)

[Colin Walters]

On Tue, Nov 23, 2021, at 4:28 PM, James Cassell wrote:

> Will things be slower than native ostree?

The only thing that will be less efficient is wire transfer as of right now.  
But we're going to be working on that.

> I've got no problem with the capability being added, but I do wonder, 
> Why not rojig, aka native RPMs plus a special metadata RPM, aka jigdo 
> for ostree? 

Ah yes.  I spent like 2 solid months working on all that only to have it not 
actually be used...

So backing up a level, really the question is:  What is the "center of 
gravity"?  Is it rpms, or ostree, or containers?  This Change isn't answering 
that question decisively, but it is a large move closer to OCI/Docker 
containers.

> We've already got great RPM infrastructure. Plus we could 
> get rid of countme.timer and instead ride the rpm-md connection like 
> the RPM-based variants do.

Mmm, I don't see a big problem with having a distinct rpm-ostree-countme.timer, 
it's not a lot of code.

But your reply is so far skipping over really the biggest change: making it a 
first class operation to build *derived* images using any Docker/OCI build 
system.  For a lot of people that will be Dockerfile, but if you follow the 
CoreOS proposal we are actively discussing a more declarative/intelligent 
frontend.
___
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: API endpoint listing ISOs and checksums for Fedora releases and Rawhide?

[Colin Walters]

On Tue, Oct 12, 2021, at 1:52 PM, Neal Gompa wrote:
> Hey all,
>
> I'm working on extending quickemu[1] to be able to easily spin up
> Fedora VMs, but our lack of a static URL formula for fetching ISOs
> makes this a bit difficult.
>
> Do we have some kind of API endpoint that has the necessary
> information for this? It'd be nice to be able to fetch some kind of
> JSON file with the necessary information so that tools can fetch it
> programmatically...

For Fedora CoreOS we have standard stream metadata for this purpose:
https://docs.fedoraproject.org/en-US/fedora-coreos/getting-started/#_streams
___
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: Fedora Maven? [was: Re: Fedora ? Java: The Death of Two SIGs]

[Colin Walters]

On Mon, Oct 4, 2021, at 3:08 PM, Fabio Valentini wrote:

> But then you're back to *exactly how Fedora packages for Java projects
> already work* - only with the added complication that distributing
> those build artifacts as plain JARs instead of RPMs now makes them
> impossible to consume as dependencies from other RPM builds.

One needs to be a bit careful using the term "impossible" in software.
Some things, such as the halting problem have actually been proven impossible.
But this is not impossible =)  I use non-RPM things as part of building RPMs 
all the time.
So do many other systems.

I think you instead mean e.g.: "would require our use of RPM to not be fully 
self-hosting" or "would require some tooling to e.g. automatically generate 
RPMs from external binaries" etc.
That's more of a policy question, far from impossible.

___
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: Any recent changes to the arm builders?

[Colin Walters]

On Sun, Aug 15, 2021, at 6:43 PM, Demi Marie Obenour wrote:
> 
> Mark kojid as non-killable by setting its OOM score to -1000?  Adding
> swap might also help, but then the build is by no means guaranteed to
> finish in a reasonable amount of time.

If Koji wasn't a clustered container system itself, but just deferred to e.g. 
Kubernetes, then both problems are solved for free - there's extensive support 
for using cgroups to correctly protect the control plane (kubelet, etc.) versus 
user workloads, *and* running 32 bit containers on a 64 bit host is obviously 
supported.
___
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: Fedora Zuul had been integrated with Testing Farm and TMT

[Colin Walters]

On Wed, Jul 21, 2021, at 9:04 AM, Miroslav Vadkerti wrote:
> Dear all,
> 
> Today we are gladly announcing that the Zuul CI system for Fedora, 

Congrats!

> which is running checks for pull requests against 
> src.fedoraproject.org, will also run Test Management Tool (tmt) based 
> tests via the new `rpm-tmt-test` check, if they are available. The test 
> environment is the same as with Fedora CI, as both CI systems use our 
> Testing Farm service as the backend.
> 
> For more information about:
> 
> * Fedora Zuul: https://fedoraproject.org/w/index.php?title=Zuul-based-ci
> * Test Management Tool (tmt): https://docs.fedoraproject.org/en-US/ci/tmt/

I skimmed the docs and it's possible I'm missing it, but do you have
some links to recent nontrivial projects that are using this?  
The tmt docs show me how to run e.g. `bash --version` which isn't
very compelling.  I am particularly interested in things that reuse upstream CI 
tests.

(If Fedora used a unified git repo, I could easily just grep it, but...)
___
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: coreos-diskimage-rehydrator

[Colin Walters]

On Fri, Jul 23, 2021, at 10:23 AM, Richard W.M. Jones wrote:
> 
> Yeah I saw it but as with many things I didn't necessarily understand
> it :-( So in fact it's nothing to do with streams as I was thinking
> about it.  I guess "stream" means something like "software stream", as
> in which distro and stable version series.

Right.  For us this is what a "release" is, and it's how we expect most people 
to find machine images to use.

> I gave a talk about this.  I don't know if it's at all relevant to
> what you're doing, but here it is:
> 
> "Disk image pipelines: Efficiently copying, sparsifying, modifying, 
> streaming multi-terabyte disk images between systems"
> http://oirase.annexia.org/tmp/disk-image-pipelines.mp4

Hmm.  I think the big difference here is that our "golden" OS images don't have 
any user data, so they're never¹ going to be measured in TB.  Most scenarios 
pulling down a ~1GB image just via `curl` (or our fancier `coreos-installer 
download` CLI) is going to be fine.

> > However, shipping tons of disconnected container images is chaos -
> > how do you CI test that?  (In the same way shipping lots of RPMs
> > independently is chaos) So a cool OpenShift 4 specific thing is this
> > concept of the "release image" which is a *single container image*
> > that contains @sha256 references to all the other containers
> > (including the OS updates).
> 
> (Sounds like git / docker / Fedora atomic...)

Since we're talking about 
https://github.com/cgwalters/coreos-diskimage-rehydrator to start...this would 
*fully* orient our release process around container images.  We never did 
anything like this in the Fedora Atomic days which used pungi i.e. the the 
baseline "disk images served via Apache directory listing".

This is related but also orthogonal to 
https://github.com/coreos/fedora-coreos-tracker/issues/812 which is 
encapsulating the in-place OS update (equivalent "set of RPMs" e.g. or for us 
"ostree commit") as a container image.

I just have to emphasize it's trying to orient how we deliver the OS (and how 
we CI test it, how we version it, how we store those versions, etc.) to be 
oriented around container images.

Nothing stops us from shipping a (traditional yum + cloud-init) qcow2 via this, 
or for that matter a Anaconda ISO.  But the assumption here is admins who want 
a CoreOS-style system want a "container native" flow.

> The "bootimage" here is (for example) the Fedora AMI that might be
> shipped in Amazon.  So it would contain the bootloader, kernel, and a
> base distribution?

This "bootimage" term is touched on in 
https://github.com/coreos/fedora-coreos-tracker/blob/main/internals/README-internals.md#ignitionplatformid
 as well as 
https://blog.verbum.org/2020/08/22/immutable-%E2%86%92-reprovisionable-anti-hysteresis/

But basically: the AMI/OpenStack qcow2/etc. are just a "shell" or "wrapper" for 
the ostree commit which is 99% of the operating system.  And as that page says, 
crucially that ostree commit is *bit for bit identical* across platforms.  We 
don't have anything like "just tweak /etc/resolv.conf on OpenStack only".   An 
ostree commit is a pair of (kernel + userspace) but *not* the bootloader which 
is indeed part of the disk image. 

See https://github.com/coreos/bootupd for addressing bootloader updates.

¹ I hope.
___
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-ostree cliwrap effort

[Colin Walters]

On Fri, Jul 23, 2021, at 7:20 AM, Neal Gompa wrote:
>
> I think I'd prefer that if you intend to do CLI wrappers, that the
> wrapper matches the semantics of the original tools as much as
> possible.
> 
> That is, "dnf|yum install " should overlay RPMs on the system,

I can certainly see ultimately making this configurable (locally and per 
edition).  Some people definitely want "dnf with images and transactional 
updates", i.e. they haven't adapted to a world living in containers.  For 
example, these people might be installing things like `gcc`, `mock` etc. to the 
host system.  They might still have a web browser lifecycle bound with the 
operating system.  Whereas the current behavior is obviously explicitly 
intended to push people into containers, because the benefits are powerful (to 
them, and us).

So yes, we could have an option where `dnf|yum install` just silently runs 
`rpm-ostree install -A` instead of printing the error it does today pretty 
easily.  But then:

> "dnf|yum upgrade" should do the rebase, etc.

Matching semantics exactly gets tricky because then - `dnf upgrade` equivalent 
to `rpm-ostree upgrade && rpm-ostree ex apply-live` or is it just (as the code 
supports today) `rpm-ostree upgrade` i.e. queued for next boot?

The thing is, ultimately I don't believe "online upgrades" should be the 
default.  I know this is a highly polarizing topic =)  But basically it's just 
chock full of race conditions except in a very few targeted cases.  It can 
mostly appear to work most of the time, but you can get spectacular failures 
too.  

What I've concluded is basically offline updates are the default, but it should 
be as easy as possible for the system administrator to "cherry pick" a subset 
of those updates live.  For the nightmare scenario of e.g. an openssh 
unauthenticated RCE, it should be like `rpm-ostree apply-live openssh` that 
pulls the queued updated openssh that would be on the next boot and applies it 
live, while leaving e.g. a queued not-security kernel update (also because 
changing what `rpm -q kernel` says is also just always a confusing lie).

> However, if you *don't* intend to preserve semantics, then don't
> bother doing it *at all* because it'll just lead to confusion. Error
> messages are not helpful.

We'll have to disagree there!  I mean I've been doing this for years now and 
constantly talking to people and e.g. the "engineer/tester trying to replace 
the kernel with yum install" section in 
https://github.com/coreos/rpm-ostree/issues/2883 is just one example of 
something I know this will help with.

> It's just better to not have the command at
> all in the first place in that circumstance. Imagine how much you'd
> break scripts and automation by having something "pretend" to be
> DNF/YUM without actually being able to *do* the things people expect
> it to do.

Yep, a member of my team recently raised this concern and I agree it's a 
problem.  I filed
https://github.com/coreos/rpm-ostree/issues/3009
which I'll probably do pretty soon.

> I'm not sure this is a useful way to position it, since RPM-OSTree
> works completely differently and classes of RPMs don't even work on
> the system. Additionally, the emphasis on using OCI images, Flatpaks,
> and other non-RPM content instead of native RPM content on these
> systems means that "image based dnf" is disingenuous and a potential
> source for confusion, since you've been pushing to *avoid* supporting
> workflows people do on regular Fedora systems.

I think RPM isn't any more native than containers.  It's just a tool, a 
technique; not the axis around which everything revolves or should revolve.

Thanks for the feedback and discussion!  I think people will have a variety of 
opinions here and it's good to have those represented.
___
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

rpm-ostree and ostree-ext: supporting booting containers directly

[Colin Walters]

Hi, this is to raise awareness of an effort we're driving from the Fedora 
CoreOS side here:
"ship quay.io/coreos/fedora-coreos" at 
https://github.com/coreos/fedora-coreos-tracker/issues/812 

Which builds on a bidirectional bridge between ostree and container images that 
lives here:
https://github.com/ostreedev/ostree-rs-ext/#module-container-encapsulate-ostree-commits-in-ocidocker-images

The technology applies to any editions using (rpm-)ostree.  As of:
https://github.com/coreos/rpm-ostree/releases/tag/v2021.7
rpm-ostree now natively supports both:
`rpm-ostree ex-container export` to convert an ostree commit into a container 
image (which is just a proxy for the ostree-rs-ext code), as well as e.g.
`rpm-ostree rebase --experimental docker://quay.io/cgwalters/fcos:latest` which 
converts the system to track an "ostree-container" image as a base.  In other 
words, this uses containers as a native transport "on the wire" instead of 
ostree.

One way I like to talk about this effort in *combination* with the cliwrap 
effort (also just posted) is that one can describe us as supporting "image 
based dnf for host updates", in other words you type `yum update` and it pulls 
and updates from a container image for the host.

If you're interested, please check out the thread above linked which contains a 
fair amount of discussion on this, as well as the issues list here: 
https://github.com/ostreedev/ostree-rs-ext/issues which touches on things like 
"can/how can we support derivation" 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

rpm-ostree cliwrap effort

[Colin Walters]

I was originally thinking of this as a Change, but since it won't be enabled by 
default, and I think it's most useful to gather feedback from this group first:

See https://coreos.github.io/rpm-ostree/cliwrap/
This is available since 
https://github.com/coreos/rpm-ostree/releases/tag/v2021.6

But just for convenience of not following the link, run:

$ rpm-ostree deploy --ex-cliwrap=true
(And `rpm-ostree ex apply-live` if you want)

I'd like for some people interested in this (particularly ones doing 
interactive CLI use, e.g. more "pet" systems like desktops) to try this out.  
Is it useful for your muscle memory to have typing `yum|dnf update` just work 
for example?  If you forget you're in a host shell and not a container, is the 
new error message from `dnf install` useful?

Obviously the big change would be flipping this on by default - that'd be the 
Fedora Change.  

Longer term though, part of the idea here is that I hope by thinking about 
rpm-ostree as "image based dnf" this way, it also helps drive increase 
alignment between the two.  For example, around things like:
https://github.com/rpm-software-management/libdnf/pull/1204#issuecomment-884225903

If you have feedback, here is fine, or in 
https://github.com/coreos/rpm-ostree/issues/2883

Thanks!


___
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: F35 Change: Memory Constraints macros for RPM (System-Wide Change proposal)

[Colin Walters]

On Tue, Jun 29, 2021, at 4:25 PM, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/MemoryConstraintsMacros
> 
> == Summary ==
> Introduce macros, similar to openSUSE's
> [https://build.opensuse.org/package/show/openSUSE:Factory/memory-constraints
> memory-constraints]), for optionally limiting build parallelism for
> build-time memory-bound packages

If our RPM builds were Kubernetes pods (or executed via podman, which 
understands the same things), it'd make sense to use
https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/

Plus there's a whole ecosystem around that, like the vertical pod autoscaler:
https://docs.openshift.com/container-platform/4.7/nodes/pods/nodes-pods-vertical-autoscaler.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: Fedora Source-git SIG report #1 (June 2021)

[Colin Walters]

On Thu, Jun 24, 2021, at 5:16 AM, Tomas Tomecek wrote:
> Greetings from the Fedora source-git SIG! We are planning to start
> publishing reports of what we are working on so everyone can easily
> pay attention and get involved if interested. If you have any ideas,
> comments or requests, don’t be shy and let us know :)

I really appreciate your efforts here.  I think most of us know
that the current RPM workflow is very antiquated.

However, two things:

- The representation for how we maintain source code is a
  very long-term commitment.  It's hard to maintain multiple
  of them.  Related to that, the details of how this works
  will quickly become "frozen" and hard to change, so
  it's important to get it right from the start.  Related
  to that:
- I think this proposal only benefits very few packages,
  mainly kernel/grub where the upstream is large
  and we carry nontrivial deltas.  For most others,
  it will either be neutral or worse.  So...my counter
  proposal is to iterate closer to a NixOS/OpenEmbedded style "uni-repo"
  model, leaving these special cases to basically become
  forked upstream repositories.  Instead of carrying 208+
  patches to grub, we'd have a separate git repo that gets rebased.
  Which...is how it already works at 
https://github.com/rhboot/grub2/tree/fedora-35
  it looks like.

On the "uni-repo" counter proposal: there's a bunch of real-world examples here 
of distributions using this successfully:
https://github.com/projectatomic/rpmdistro-gitoverlay/blob/master/doc/reworking-fedora-releng.md#unified-source-and-pr-driven-workflow
___
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: use unit names in systemd output by default?

[Colin Walters]

On Fri, Jun 25, 2021, at 6:21 AM, Zbigniew Jędrzejewski-Szmek wrote:
> Hi,
> 
> systemd has systemd.status_unit_format= / [Manager].StatusUnitFormat=
> / -Dstatus-unit-format-default= option to use unit names instead of the
> Description in messages on the kernel console and in logs:

I meant to get back to https://github.com/systemd/systemd/pull/15957
which I still think is the best.
___
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: Fedora Source-git SIG report #1 (June 2021)

[Colin Walters]

On Thu, Jun 24, 2021, at 5:22 PM, Miro Hrončok wrote:
> On 24. 06. 21 23:07, Miroslav Suchý wrote:
> > Dne 24. 06. 21 v 15:48 Tomas Tomecek napsal(a):
> >>> One thing to consider is that the upstream tarballs might be 
> >>> cryptographically
> >>> signed and packages should verify the signature in %prep.
> >> This is a very good point - in such a case, we should always pull the
> >> official upstream tarball instead of generating a new one downstream
> > 
> > Does it matter? If you are able to generate byte2byte identical tarball 
> > then 
> > you can choose any of them.
> 
> AFAIK git does not grantee to produce byte2byte identical archives across 
> different versions of git, zlib, gzip etc. So even if upstream signs the git 
> generated archive, generating a byte2byte identical one might be tricky.

See also https://github.com/cgwalters/git-evtag
___
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: F35 Change: Make btrfs the default file system for Fedora Cloud (System-Wide Change proposal)

[Colin Walters]

On Fri, May 28, 2021, at 5:43 AM, Neal Gompa wrote:
>
> Part of the point of the different working groups was to handle the
> different use-cases *well* at their own pace. The CoreOS Working Group
> is *explicitly* excluded and frankly unlikely to ever switch because
> Colin believes 

I am not CoreOS, I'm an engineer working on it.

> that Btrfs is only suitable for "pet" workloads[1]

That's not what my blog said.  One of the sub-headers is "BTRFS is good for 
"pet" systems".  There's no word "only" there - you inserted that.

On this topic though, if Fedora CoreOS didn't exist, this proposal to change 
Cloud would be significantly more consequential.  The defaults *really matter* 
here in particular, even more than Workstation.  But, I think because CoreOS 
does exist, this change matters less.

One big advantage CoreOS has is Ignition, which allows provisioning filesystems 
in the initramfs, including the root partition.  It works today to boot up a 
stock Fedora CoreOS AMI, OpenStack qcow2 etc. and provide an Ignition config 
that changes it:
https://docs.fedoraproject.org/en-US/fedora-coreos/storage/#_reconfiguring_the_root_filesystem
And it works to use btrfs too! Just s/ext4/btrfs/ in the first example.  (And 
that *exact same* Ignition config also works for bare metal)

That's not true of cloud-init based systems - instead of e.g. you wanted to use 
xfs/ext4 for a high performance database-like workload, in cloud you'd need to 
attach a separate instance volume or so for `/var/lib/$whatever`  (That said 
separate volumes can actually be a better approach anyways, it depends).  Some 
traditional Cloud image users won't notice this or care (just like Workstation 
users) but others definitely will.
___
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: F35 Change proposal: Smaller Container Base Image (remove sssd-client, util-linux, shadow-utils) (Self-Contained Change)

[Colin Walters]

On Thu, May 20, 2021, at 8:21 AM, Daniel P. Berrangé wrote:

> Lets say the Fedora base image is refreshed with updated RPMs on a weekly
> basis. Each application republishes their app containers on an arbitrarily
> different schedule, maybe fortnightly, monthly, whatever. Thus out of
> 10 different apps deployed, you could easily find yourself shipping 10
> different versions of the base image. 

This of course is the big difference between flatpak and 
docker/podman/kubernetes as they work today.  flatpak dynamically links base 
images (by having apps go into `/app`).

I can't think of a hard reason that podman couldn't learn to dynamically link 
base images too with the same approach of having the app bits live in `/app`.  
Or honestly, in many cases we could just forcibly dynamically link layers, for 
most of the OpenShift platform we just have big statically linked Go binaries 
that don't overlay anything on the host (no package installs etc).

One could imagine something like this in a Containerfile:

```
FROM quay.io/fedora:rust as buildroot
COPY . /build
RUN cargo build --release

FROM DYNAMIC quay.io/fedora
COPY --from-buildroot /build/target/release/myapp /usr/bin/myapp
```

Where the `DYNAMIC` part here opts-in to dynamic linking like flatpak, and the 
overlayfs is dynamic instead of static.
___
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: Fedora CoreOS stable stream now rebased to Fedora 34

[Colin Walters]

On Thu, May 20, 2021, at 12:31 PM, Stephen John Smoogen wrote:

> Then maybe FCOS needs to have a major version number to indicate that 
> these breaks are going to happen. I am going to say off the bat it DOES 
> NOT need to be the same as the Fedora Linux release number. It also 
> doesn't mean that number change means that you can't move a system from 
> say FCOS-1 to FCOS-2... but that you make no promises of moving it back 
> to FCOS-1. 

I do think we should probably have a page which lists "provisioning 
discontinuities" as I'd call it where newly provisioned nodes have an important 
new behavior.  That's related to, but not the same thing as a version number.

> Eventually something is going to cause this. The many changes like: 
> cgroups etc are adding up to an area where FCOS will reach a point it 
> only 'matches' Fedora in name and might as well be based off of Debian 
> Jessie or Slackware 14.2 or CentOS-8 Stream. 

I think an even moderately objective analysis would show that statement to be 
simply hyperbole.If you meant it that way, it wasn't useful to say.  If you 
didn't, please think about it more and particularly consider all the linkages 
FCOS has with other Fedora editions.
___
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: Fedora CoreOS stable stream now rebased to Fedora 34

[Colin Walters]

On Thu, May 20, 2021, at 10:01 AM, Daniel Walsh wrote:
> 
> This might end up being a major problem with FCOS, if we are stuck with 
> the defaults forever, and never able to take advantage of new 
> technology.

Note that with cgroups v2, the status quo is that nodes updated in place stay 
on v1.  Newly provisioned nodes get the new default v2.

This was all explained IMO fairly clearly: 
https://lists.fedoraproject.org/archives/list/cor...@lists.fedoraproject.org/message/6NGBXYMJ4YU3V667XN627WOGCJA47POT/

This is a pattern that can have a similar effect as Fedora version 
discontinuities.  So it's not "forever".  




___
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: Fedora CoreOS stable stream now rebased to Fedora 34

[Colin Walters]

On Wed, May 19, 2021, at 7:54 AM, Neal Gompa wrote:
> 
> It's not like making changes and breaking upgrades is acceptable in
> Fedora Linux either. It's just that the Fedora CoreOS WG has not
> participated in the main development process and rolled back changes
> instead of adapting to them, which has frustrated pretty much
> everyone. The containers team in particular was extremely unhappy to
> find out cgroup v1 was still used in FCOS. 

This was extensively discussed before: 
https://github.com/coreos/fedora-coreos-tracker/issues/373
And has been since multiple times.  I don't think rehashing it here is useful.  
Members from the github.com/containers team were definitely aware.

The bottom line is FCOS includes docker by default because Container Linux did 
and for other reasons.  That's different from other editions.

> I was pretty cheesed off
> when I discovered the sqlite rpmdb feature was rolled back in FCOS.

This one however was a great example of both teams (rpm team and rpm-ostree 
team) being unaware of the need to coordinate here.  The design for the 
migration that landed in rpm upstream fundamentally clashes with rpm-ostree's 
transactional model.  But this one is also now fixed in Fedora 34.

We're still dealing with further fallout from this in e.g. 
https://bugzilla.redhat.com/show_bug.cgi?id=1938928 though because the FCOS 
team keeps our tooling and code tightly bound to RHCOS (RHEL8).
___
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