RPM: Split out pam_zfs_key into separate package #13026
Conversation
Create a separate `pam_zfs_key` package for the PAM module components, an optional addition to the deliverables, in much the same way as the Python bindings are released as a separate `python#-pyzfs` package. This makes it clear when the PAM module is shipped with the package, since it's now in its own package. Signed-off-by: Chris Lindee <chris.lindee+github@gmail.com> Closes: openzfs#13026
ColMelvin
force-pushed
the
feature.separate-pam-rpm
branch
from
fdbe25e to
d695c19
Compare
|
Splitting the pam components in to their own package which can then be optionally installed seems pretty reasonable. Looking around briefly, it appears the convention for this would be to name the new package something like Alternately, we could enable this support in the provided packages. This was originally not done out of an abundance of caution when the pam support was new, but that is something we could revisit. What would be the consequences, if any, of enabling this in the shipped packages? |
|
+1 for |
behlendorf
added
Component: Packaging
Impact of InclusionAs I've come to understand PAM, the inclusion of That said, we also include Assuming Possible AlterationWe could remove Package ScopeSplitting out a separate package would capture everything related to PAM in one place and would provide a separation between ZFS and its addon. There may be minor maintenance benefits to this (though we already section off the PAM components via For instance, I am developing an SELinux policy for PAM (but not for ZFS as a whole). I don't know if it would be better to create a separate selinux package or if it would be worthwhile to include the policy with the pam_zfs_key.so library. Regardless, I do think it's worthwhile to separate the SELinux work from the Naming ConventionI checked the Guidelines for Naming Fedora Packages document for guidance. As I read it, the Addon Packages section prefers the I originally went with |
|
Thanks for the careful analysis above. Given that, I think you're right, let's go ahead and split the pam bits off in to their own package. This way we can at least clearly express dependencies on it, either way shouldn't really change the overall maintenance burden. Once we have it split in to it's own package we'll start building it by default and including it in the repos.
According to the referenced documentation it sounds to me like those packages were probably grandfathered in. But since there is an established convention, I agree let's make sure to follow it. As I read it, that would mean we should name the package Let's also get @felixdoerre's through on this. |
|
Splitting pam_zfs_key into a separate package and building it by default seems like a good idea. Is there any configuration template required for |
|
I'm not well versed in |
|
@behlendorf What steps are required to complete this pull request? I assume the automated checks need to pass, however, I'm unsure how I might re-run a failing check. |
|
Thanks for reminding me. Based on the conversation above it sounds like there's general agreement that splitting the package is a good idea. Also based on your research we don't anticipate any unexpected side effects. I believe that just leaves nailing down the naming convention with the two candidates being |
|
Oh, and if you rebase this PR on the latest commits in master and force up it you should be a cleaner CI run. |
ColMelvin
force-pushed
the
feature.separate-pam-rpm
branch
from
d695c19 to
9b9eeb0
Compare
Create a separate `pam_zfs_key` package for the PAM module components, an optional addition to the deliverables, in much the same way as the Python bindings are released as a separate `python#-pyzfs` package. This makes it clear when the PAM module is shipped with the package, since it's now in its own package. Signed-off-by: Chris Lindee <chris.lindee+github@gmail.com> Closes: openzfs#13026
|
@behlendorf It looks like there are consistent failures on some Debian-based systems, which I find surprising. While there were inconsistent failures across all of the checks, 3 of the 4 unsuccessful checks included the following: How do I get further information so I can debug the problem? |
|
You can download the full test artifacts for the Ubuntu GitHub actions builders here. Slightly more convenient are the Debian logs from buildbot. Take a look at the summary link, it will show which tests failed and try and pull excepts from the relevant logs. e.g. But it looks to me like what happened here is the new package didn't get installed on Debian and Ubuntu. We've got a little bit of infrastructure in the The other test failures look unrelated. There are still a few of those we occasionally see. |
Create a separate `pam_zfs_key` package for the PAM module components, an optional addition to the deliverables, in much the same way as the Python bindings are released as a separate `python#-pyzfs` package. This makes it clear when the PAM module is shipped with the package, since it's now in its own package. Signed-off-by: Chris Lindee <chris.lindee+github@gmail.com> Closes: openzfs#13026
ColMelvin
force-pushed
the
feature.separate-pam-rpm
branch
from
9b9eeb0 to
ac5be6d
Compare
behlendorf
added
Status: Accepted
|
@felixdoerre FYI: It looks like Fedora 36 (and, likely, future Red Hat releases) may lean more heavily on |
Create a separate `pam_zfs_key` package for the PAM module components, an optional addition to the deliverables, in much the same way as the Python bindings are released as a separate `python#-pyzfs` package. This makes it clear when the PAM module is shipped with the package, since it's now in its own package. Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Reviewed-by: Tony Hutter <hutter2@llnl.gov> Signed-off-by: Chris Lindee <chris.lindee+github@gmail.com> Closes: openzfs#13026
Create a separate `pam_zfs_key` package for the PAM module components, an optional addition to the deliverables, in much the same way as the Python bindings are released as a separate `python#-pyzfs` package. This makes it clear when the PAM module is shipped with the package, since it's now in its own package. Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Reviewed-by: Tony Hutter <hutter2@llnl.gov> Signed-off-by: Chris Lindee <chris.lindee+github@gmail.com> Closes: openzfs#13026
Create a separate `pam_zfs_key` package for the PAM module components, an optional addition to the deliverables, in much the same way as the Python bindings are released as a separate `python#-pyzfs` package. This makes it clear when the PAM module is shipped with the package, since it's now in its own package. Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Reviewed-by: Tony Hutter <hutter2@llnl.gov> Signed-off-by: Chris Lindee <chris.lindee+github@gmail.com> Closes: openzfs#13026
Create a separate `pam_zfs_key` package for the PAM module components, an optional addition to the deliverables, in much the same way as the Python bindings are released as a separate `python#-pyzfs` package. This makes it clear when the PAM module is shipped with the package, since it's now in its own package. Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Reviewed-by: Tony Hutter <hutter2@llnl.gov> Signed-off-by: Chris Lindee <chris.lindee+github@gmail.com> Closes: openzfs#13026
Create a separate `pam_zfs_key` package for the PAM module components, an optional addition to the deliverables, in much the same way as the Python bindings are released as a separate `python#-pyzfs` package. This makes it clear when the PAM module is shipped with the package, since it's now in its own package. Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Reviewed-by: Tony Hutter <hutter2@llnl.gov> Signed-off-by: Chris Lindee <chris.lindee+github@gmail.com> Closes: openzfs#13026
Create a separate `pam_zfs_key` package for the PAM module components, an optional addition to the deliverables, in much the same way as the Python bindings are released as a separate `python#-pyzfs` package. This makes it clear when the PAM module is shipped with the package, since it's now in its own package. Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Reviewed-by: Tony Hutter <hutter2@llnl.gov> Signed-off-by: Chris Lindee <chris.lindee+github@gmail.com> Closes: openzfs#13026
Create a separate `pam_zfs_key` package for the PAM module components, an optional addition to the deliverables, in much the same way as the Python bindings are released as a separate `python#-pyzfs` package. This makes it clear when the PAM module is shipped with the package, since it's now in its own package. Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Reviewed-by: Tony Hutter <hutter2@llnl.gov> Signed-off-by: Chris Lindee <chris.lindee+github@gmail.com> Closes: openzfs#13026
Create a separate `pam_zfs_key` package for the PAM module components, an optional addition to the deliverables, in much the same way as the Python bindings are released as a separate `python#-pyzfs` package. This makes it clear when the PAM module is shipped with the package, since it's now in its own package. Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Reviewed-by: Tony Hutter <hutter2@llnl.gov> Signed-off-by: Chris Lindee <chris.lindee+github@gmail.com> Closes: openzfs#13026
Create a separate `pam_zfs_key` package for the PAM module components, an optional addition to the deliverables, in much the same way as the Python bindings are released as a separate `python#-pyzfs` package. This makes it clear when the PAM module is shipped with the package, since it's now in its own package. Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Reviewed-by: Tony Hutter <hutter2@llnl.gov> Signed-off-by: Chris Lindee <chris.lindee+github@gmail.com> Closes: openzfs#13026
Create a separate `pam_zfs_key` package for the PAM module components, an optional addition to the deliverables, in much the same way as the Python bindings are released as a separate `python#-pyzfs` package. This makes it clear when the PAM module is shipped with the package, since it's now in its own package. Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Reviewed-by: Tony Hutter <hutter2@llnl.gov> Signed-off-by: Chris Lindee <chris.lindee+github@gmail.com> Closes: openzfs#13026
Create a separate `pam_zfs_key` package for the PAM module components, an optional addition to the deliverables, in much the same way as the Python bindings are released as a separate `python#-pyzfs` package. This makes it clear when the PAM module is shipped with the package, since it's now in its own package. Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Reviewed-by: Tony Hutter <hutter2@llnl.gov> Signed-off-by: Chris Lindee <chris.lindee+github@gmail.com> Closes: openzfs#13026
Create a separate `pam_zfs_key` package for the PAM module components, an optional addition to the deliverables, in much the same way as the Python bindings are released as a separate `python#-pyzfs` package. This makes it clear when the PAM module is shipped with the package, since it's now in its own package. Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Reviewed-by: Tony Hutter <hutter2@llnl.gov> Signed-off-by: Chris Lindee <chris.lindee+github@gmail.com> Closes: openzfs#13026
Create a separate `pam_zfs_key` package for the PAM module components, an optional addition to the deliverables, in much the same way as the Python bindings are released as a separate `python#-pyzfs` package. This makes it clear when the PAM module is shipped with the package, since it's now in its own package. Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Reviewed-by: Tony Hutter <hutter2@llnl.gov> Signed-off-by: Chris Lindee <chris.lindee+github@gmail.com> Closes: openzfs#13026
Create a separate `pam_zfs_key` package for the PAM module components, an optional addition to the deliverables, in much the same way as the Python bindings are released as a separate `python#-pyzfs` package. This makes it clear when the PAM module is shipped with the package, since it's now in its own package. Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Reviewed-by: Tony Hutter <hutter2@llnl.gov> Signed-off-by: Chris Lindee <chris.lindee+github@gmail.com> Closes: openzfs#13026
Create a separate `pam_zfs_key` package for the PAM module components, an optional addition to the deliverables, in much the same way as the Python bindings are released as a separate `python#-pyzfs` package. This makes it clear when the PAM module is shipped with the package, since it's now in its own package. Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Reviewed-by: Tony Hutter <hutter2@llnl.gov> Signed-off-by: Chris Lindee <chris.lindee+github@gmail.com> Closes: openzfs#13026
Create a separate `pam_zfs_key` package for the PAM module components, an optional addition to the deliverables, in much the same way as the Python bindings are released as a separate `python#-pyzfs` package. This makes it clear when the PAM module is shipped with the package, since it's now in its own package. Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Reviewed-by: Tony Hutter <hutter2@llnl.gov> Signed-off-by: Chris Lindee <chris.lindee+github@gmail.com> Closes: openzfs#13026
Create a separate `pam_zfs_key` package for the PAM module components, an optional addition to the deliverables, in much the same way as the Python bindings are released as a separate `python#-pyzfs` package. This makes it clear when the PAM module is shipped with the package, since it's now in its own package. Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Reviewed-by: Tony Hutter <hutter2@llnl.gov> Signed-off-by: Chris Lindee <chris.lindee+github@gmail.com> Closes: openzfs#13026
Motivation and Context
The RPM packages provided at
http://download.zfsonlinux.org/fedora/$releasever/$basearch/do not include thepam_zfs_keyPAM module. To get this feature, thezfssource RPM may be rebuilt--with pam; however, this approach requires rebuilding thezfsRPM for every minor version update.The PAM module is stable and does not need to be rebuilt for every version of ZFS. By splitting it out into a separate RPM, it can be built and installed much less frequently on a system that receives regular ZFS updates from the official channels.
Description
Create a separate
pam_zfs_keypackage for the PAM module components, an optional addition to the deliverables, in much the same way as the Python bindings are released as a separatepython#-pyzfspackage.The module's name follows Fedora precedent for RPM packages providing PAM modules.
How Has This Been Tested?
Test Environment: Fedora 34 Server on VM
Steps:
zfsRPM from upstream Yum repositoryzfssource RPM from upstream Yum repository, apply patch, and build new RPM (--with pam)pam_zfs_keyRPM packageFurther steps checking for regression of #13001:
pam-develRPM--with pampam_zfs_keyRPM was created--with pamTypes of changes
Checklist:
Signed-off-by.