Rebased:

  • pki-core to 10.6.8
  • dogtag-pki to 10.6.8
  • jss to 4.5.1
  • freeipa to 4.7.2

Resubmitting the following since it didn't make it to the stable:

  • nuxwdog 1.0.5-3
  • tomcatjss 7.3.6-2

This update resolves an issue which caused uninstall of a FreeIPA server to fail with authselect 1.0.2, which recently appeared as an update. See the pull request for more details.

How to install

sudo dnf upgrade --advisory=FEDORA-2018-115068f60e

This update has been submitted for testing by dmoluguw.

2 years ago

This update has been pushed to testing.

2 years ago
User Icon lslebodn commented & provided feedback 2 years ago
karma

This update broke installation of freeIPA server. You can see it even in openQA tests https://openqa.fedoraproject.org/tests/314591#step/role_deploy_domain_controller/18

Bodhi is disabling automatic push to stable due to negative karma. The maintainer may push manually if they determine that the issue is not severe.

2 years ago
User Icon cipherboy commented & provided feedback 2 years ago

This is a weird error, mostly because the IPA version is less than our minimum. I think we need to wait for FreeIPA to update and then we can retest.

User Icon adamwill commented & provided feedback 2 years ago

It's not really a 'weird error', you are doing a bad thing: creating an update that is incompatible with the distribution as it stands. If this PKI needs a newer FreeIPA than F28 currently contains, then either that FreeIPA should also be in this update, or a FreeIPA update should be created first, pushed stable, and then PKI can be updated. If the two newer versions are interdependent (neither works with the old version of the other), they must be updated together in a single update.

User Icon adamwill commented & provided feedback 2 years ago

BTW, some more info on precisely how the test failed: in this update, the pki-server package had a Conflicts: freeipa-server < 4.7.1 line added. However, none of the other pki-core subpackages had this done, and there are no dependencies between the various subpackages of pki-core which force them to always be of equal versions. So when the test asked DNF to install the group @freeipa-server, what DNF wound up doing to satisfy the PKI deps was installing version 10.6.8-1.fc28 of pki-base, pki-base-java, python3-pki, pki-symkey and pki-tools, but version 10.6.6-1.fc28 (the old version from the stable repos) of pki-server. There's nothing that makes this 'invalid' so far as dependencies are concerned; it's a correct solution to the request. Obviously, things don't work well with old FreeIPA, old pki-server, but new everything-else-pki. :)

User Icon cipherboy commented & provided feedback 2 years ago

Sure, but I think calling this a "weird error" is acceptable as you just pointed out: we're doing a bad thing, and the error we see isn't that we're doing a bad thing, its that something else, later, way down the line, is broken.

In OpenQA, after the bodhi update installation stage, I'd expect to verify at least that the packages in this bodhi update were installed at the versions in the update. e.g., rpm -qa shows them as being installed at the versions here.

Put another way, if I take $CURRENT_VERSION of $PKG and package $CURRENT_VERSION+1 as $CURRENT_VERSION with a new line Conflicts: $something_else < k in the spec file, and $something_else >= k hasn't been released and so we get $CURRENT_VERSION installed in Bodhi (instead of $CURRENT_VERSION+1), I'd expect Bodhi to fail with a package version error. I would not expect it to pass (assuming that $PKG @ $CURRENT_VERSION passes Bodhi previously and will pass again).

User Icon cipherboy commented & provided feedback 2 years ago

(In the last paragraph, s/Bodhi/OpenQA/g, sorry).

User Icon lslebodn commented & provided feedback 2 years ago

Sure, but I think calling this a "weird error" is acceptable as you just pointed out: we're doing a bad thing, and the error we see isn't that we're doing a bad thing, its that something else, later, way down the line, is broken.

Are you sure that you are not doing a bad thing? OpenQA do the same as normal user would do. Just call dnf update and the result is combination of packages which cause failures to install freeIPA.

And it is obviously caused by this bodhi update because it pass without updates-testing. Sure; error reporting could be better. But assumption about $CURRENT_VERSION+1 is difficult. You can obsolete some packages; replace ... So it is would be a challenge to guess which set of packages should be installed.

I would appreciate if you could either un-push this update from updates-testing or add freeipa-4.7.2 to this update. I am not sure whether you have permissions for that.

sgallagh edited this update.

New build(s):

  • freeipa-4.7.2-1.fc28
  • pki-core-10.6.8-3.fc28

Removed build(s):

  • pki-core-10.6.8-1.fc28

Karma has been reset.

2 years ago

This update has been submitted for testing by sgallagh.

2 years ago

This update has obsoleted freeipa-4.7.0-5.fc28, and has inherited its bugs and notes.

2 years ago
User Icon sgallagh commented & provided feedback 2 years ago

I've added updated pki-core and freeipa packages together on this Bodhi update so the conflict issues should now be resolved.

sgallagh edited this update.

New build(s):

  • dogtag-pki-10.6.8-3.fc28

Removed build(s):

  • dogtag-pki-10.6.8-1.fc28

Karma has been reset.

2 years ago
User Icon adamwill commented & provided feedback 2 years ago

It's arguable both ways. As @lslebodn points out, openQA's basic goal is to test how things work as a user would encounter them. He's correct that, had this update been pushed stable, a user would've seen exactly what openQA did: they'd run an update, it would apparently work just fine, then suddenly FreeIPA would break.

However, we can improve things so that openQA provides more information to detect this kind of problem, certainly. The reason it doesn't at present is simply that I hadn't considered that this scenario might be possible; dependency issues in updates usually tend to manifest as errors in package install or update, not this kind of 'the operation succeeds but doesn't install what we expect it to' case. This is the first case like this I've come across in an openQA test.

This update has been pushed to testing.

2 years ago
User Icon cheimes commented & provided feedback 2 years ago
karma

FreeIPA 4.7 PR-CI is passing with pki-core-10.6.8-3, https://github.com/freeipa/freeipa/pull/2646. PR-CI uses F29 while Travis CI tests on F28. I was also able to install an FreeIPA cluster with two servers on Fedora 28 successfully.

This update has reached 7 days in testing and can be pushed to stable now if the maintainer wishes

2 years ago

This update has been submitted for batched by sgallagh.

2 years ago

This update has been submitted for stable by bodhi.

2 years ago

This update has been pushed to stable.

2 years ago

Please login to add feedback.

Metadata
Type
enhancement
Karma
1
Signed
Content Type
RPM
Test Gating
Settings
Unstable by Karma
-3
Stable by Karma
disabled
Stable by Time
disabled
Dates
submitted
2 years ago
in testing
2 years ago
in stable
2 years ago
modified
2 years ago
BZ#1534765 javadoc for org.mozilla.jss.pkix.cms.SignedData.getSignerInfos() is incorrect
0
0
BZ#1582323 DER encoding error for enumerated types with a value of zero
0
0
BZ#1645708 authselect enable-features should error on unknown features
0
0

Automated Test Results