This is the obligatory announcement that the license of the
gi-docgen-doc subpackage of gi-docgen has been corrected from:
(ASL 2.0 or GPLv3+) and CC0 and CC-BY
to:
(ASL 2.0 or GPLv3+) and CC0 and CC-BY-SA
Hi,
I was discussing containerization and making RPMs more declarative with Aleksandra Fedorova, and she suggested I ask here and mention Zbigniew Jędrzejewski-Szmek.
It sounds like there's already some effort to make tasks in RPMs like adding users more declarative: https://docs.fedoraproject.org/en-US/packaging-guidelines/UsersAndGroups/
I'm working with rpm-ostree (https://coreos.github.io/rpm-ostree/) and Butane (https://coreos.github.io/butane/) to manage system state more declaratively. Currently rpm-ostree manages RPMs and then Butane handles things like putting config files in /etc or creating users. It sounds like there's some overlap between the changes in RPMs around managing users and Butane, so I'm wondering if there could be more cooperation.
If RPMs relied less on scriptlets and more on declarative config that could be merged, it would make optimizations for containerization a lot easier. Each package in a container image could be in a separate layer, which would allow much better sharing between container images. Adding a single package to a container image could just require pulling the package, rather than running a scriptlet that could possibly change the base image.
Do you think it would be possible to move some of the configuration tasks performed in scriptlets into something declarative that could be merged with other configuration?
Are there any ways rpm-ostree/Butane could align itself better with the direction RPMs are taking? Is there a solution or format that would satisfy the requirements of both tools?
Thanks,
Matthew
https://fedoraproject.org/wiki/Changes/drop_NIS_support_from_PAM
== Summary ==
This change is about dropping user-authentication using NIS(+) from PAM.
== Owner ==
* Name: [[User:besser82 | Björn Esser]]
* Email: besser82(a)fedoraproject.org
* Name: [[User:ipedrosa | Iker Pedrosa]]
* Email: ipedrosa(a)redhat.com
== Detailed Description ==
NIS(+) was introduced by Sun/Oracle to easily share files and system
users between UNIX-alike systems within the same network, and has been
around for some decades. Its simplicity though opens a variety of
possible security issues, like not being able the verify whether the
shared information is actually correct and/or trustworthy. That said,
and with several more secure options (LDAP, Kerberos, Samba, etc.) to
achieve the same goal, we should at least remove support for NIS for
user authentication.
== Feedback ==
There was some discussion on
[https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org…
the fedora-devel mailing-list]. Some people are reluctant about the
removal of NIS(+) support from PAM, while most are okay with it as
there are more secure alternatives (LDAP, FreeIPA, etc.) available.
== Benefit to Fedora ==
With this change we start directing our users and developers to move
away from NIS(+) to secure alternatives like LDAP and/or FreeIPA.
== Scope ==
* Proposal owners:
** Adapt the pam spec file to build without support for NIS(+).
** Communicate the removal of the PAM configuration for
user-authentication using NIS with the authselect maintainers; also
offer assistance to implement the needed changes.
* Other developers:
** Apply the pull-request to the authselect package.
** Test this change.
* Release engineering: [https://pagure.io/releng/issue/10351 #10351]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: N/A
== Upgrade/compatibility impact ==
Users that were relying on support for NIS(+) will need to move to
secure alternatives like LDAP and/or FreeIPA.
== How To Test ==
There is no need to test, as when configure switch is removed, support
is dropped.
== User Experience ==
For some users this change may be a bit disruptive and it may require
some learning curve for switching to alternative solutions.
== Dependencies ==
* The authselect package needs to be updated to drop its PAM
configuration for user-authentication using NIS.
* Apart from that there are actually no rpms, that directly depend on
the change of the functionality of the affected PAM module.
== Contingency Plan ==
* Contingency mechanism: Revert the changes made to the affected
packages and rebuild them.
* Contingency deadline: At beta freeze.
* Blocks release? Yes.
== Documentation ==
The documentation about sharing system users and files over NIS should
be dropped, if there even is any.
== Release Notes ==
Support for NIS(+) has been dropped from PAM. Users, who are
currently using NIS(+) to share UNIX users / groups within a network,
should migrate their setups to use LDAP or some other secure service
providing comparable functionalities before updating to Fedora 36.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
Minutes: https://meetbot.fedoraproject.org/fedora-meeting-1/2022-02-16/fedora_coreos…
Minutes (text): https://meetbot.fedoraproject.org/fedora-meeting-1/2022-02-16/fedora_coreos…
Log: https://meetbot.fedoraproject.org/fedora-meeting-1/2022-02-16/fedora_coreos…
========================================
#fedora-meeting-1: fedora_coreos_meeting
========================================
Meeting started by dustymabe at 16:30:22 UTC. The full logs are
available at
https://meetbot.fedoraproject.org/fedora-meeting-1/2022-02-16/fedora_coreos…
.
Meeting summary
---------------
* roll call (dustymabe, 16:30:27)
* Action items from last meeting (dustymabe, 16:34:25)
* dustymabe opened ticket for DNSoverTLS tracking:
https://github.com/coreos/fedora-coreos-tracker/issues/1098
(dustymabe, 16:35:17)
* dustymabe opened ticket for investigation of missing packages
affecting auto updates:
https://github.com/coreos/fedora-coreos-tracker/issues/1099
(dustymabe, 16:35:24)
* miabbott opened ticket for Golang 1.18 testing
https://github.com/coreos/fedora-coreos-tracker/issues/1096
(miabbott, 16:35:39)
* ACTION: jlebon to open issue to investigate "102 Introduce module
Obsoletes and EOL" (dustymabe, 16:36:57)
* cverna is trying to get started a "This month in Fedora CoreOS
newsletter" --> https://hackmd.io/fITa6rtNTy6Ub1WO4nkdnw (cverna,
16:37:08)
* Add factory reset capability (dustymabe, 16:38:59)
* LINK: https://github.com/coreos/fedora-coreos-tracker/issues/399
(dustymabe, 16:39:08)
* AGREED: For our factory reset capability we'll use kexec and
initially require either network access or local copies of the
install media to exist. In the future we may generate intall media
from the existing system. We also will limit our scope to just
re-installing FCOS on FCOS and disallow/discourage running it from
other distros. (dustymabe, 17:04:26)
* tracker: Fedora 36 changes considerations (dustymabe, 17:04:44)
* LINK: https://github.com/coreos/fedora-coreos-tracker/issues/918
(dustymabe, 17:05:15)
* ACTION: ravanelli to look into the F36 changes 127 to see if this
change affects us on ppc64le (dustymabe, 17:09:39)
* LINK: https://github.com/coreos/fedora-coreos-tracker/issues/1070
(dustymabe, 17:17:43)
* ACTION: dustymabe to create a f36 changes ticket for podman 4.0
investigation/announcement (dustymabe, 17:20:45)
* podman v4.0, Fedora 35 and CoreOS (dustymabe, 17:21:27)
* LINK: https://github.com/coreos/fedora-coreos-tracker/issues/1070
(dustymabe, 17:21:32)
* ACTION: jlebon to send out an announcement about podmanv4 coming to
F36 and the beta coming to next in the coming weeks (dustymabe,
17:35:48)
* AGREED: It would be nice if we could have podman 3 and 4
co-installable in F35 so users and podman-machine could use our more
stable streams with podman v4. However, there is definitely some
work left to do there. If that work doesn't get done and if the
podman team is happy with their users being on `next` when the F36
beta lands then that may be the approach that wins. (dustymabe,
17:37:34)
* open floor (dustymabe, 17:37:44)
* LINK: https://github.com/coreos/fedora-coreos-tracker/issues/1093 >
Has anyone submitted a talk? (travier, 17:38:26)
Meeting ended at 17:41:32 UTC.
Action Items
------------
* jlebon to open issue to investigate "102 Introduce module Obsoletes
and EOL"
* ravanelli to look into the F36 changes 127 to see if this change
affects us on ppc64le
* dustymabe to create a f36 changes ticket for podman 4.0
investigation/announcement
* jlebon to send out an announcement about podmanv4 coming to F36 and
the beta coming to next in the coming weeks
Action Items, by person
-----------------------
* dustymabe
* dustymabe to create a f36 changes ticket for podman 4.0
investigation/announcement
* jlebon
* jlebon to open issue to investigate "102 Introduce module Obsoletes
and EOL"
* jlebon to send out an announcement about podmanv4 coming to F36 and
the beta coming to next in the coming weeks
* ravanelli
* ravanelli to look into the F36 changes 127 to see if this change
affects us on ppc64le
* **UNASSIGNED**
* (none)
People Present (lines said)
---------------------------
* dustymabe (128)
* travier (50)
* jlebon (50)
* zodbot (23)
* cverna (6)
* miabbott (4)
* jaimelm (4)
* ravanelli (3)
* jbrooks (3)
* lucab (3)
* copperi[m] (2)
* aaradhak[m] (1)
* mnguyen_ (1)
* walters (1)
Generated by `MeetBot`_ 0.4
.. _`MeetBot`: https://fedoraproject.org/wiki/Zodbot#Meeting_Functions
I have orphaned rubygem-cucumber-rails + rubygem-database_cleaner.
Both package are currently FTBFS. Originally, I attempted to update
rubygem-cucumber-rails, before realizing that it would require more
effort. The fix would ideally involve rebase but also update of
rubygem-database_cleaner, which is not in better shape. For a rebase, it
would require several new dependencies.
But because nothing else depends on rubygem-cucumber-rails and
rubygem-database_clenaer, I decided to just open WIP PR with my progress
[1] and let the packages go.
Just FTR, rubygem-cucumber-rails is on the list of longstanding FTBFS
packages and it is going to be removed soon by the policy, so please act
quickly should you want to save this package.
Vít
[1] https://src.fedoraproject.org/rpms/rubygem-cucumber-rails/pull-request/2