FEDORA-2018-a45016e03f

bugfix update in Fedora 27 for 389-ds-base

Status: obsolete

Bump version to 1.3.8.7


Bump version to 1.3.8.6


Bump version to 1.3.8.5

Comments 15

This update has been submitted for testing by mreynolds.

This update has obsoleted 389-ds-base-1.3.8.6-1.fc27, and has inherited its bugs and notes.

This update has been pushed to testing.

This seems to cause failures in the openQA tests:

https://openqa.fedoraproject.org/tests/overview?distri=fedora&version=27&build=Update-FEDORA-2018-a45016e03f&groupid=2

Basically it seems like user logins are failing - the 'freeipa_password_change' test module fails when trying to log into the web UI as test3, and the 'freeipa_client' test module fails when trying to log into a console as test1. Those are both user accounts created on the server after initial server deployment. It's noticeable that another test module which logs into the web UI as the admin user succeeds - that login worked.

karma: -1

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.

Any details as to why 389-ds-base is causing this FreeIPA WebUI problem? There have not been any changes to how passwords are changed in 389-ds-base in a very long time, and FreeIPA uses its own custom password policy plugin.

It's not a web ui problem. Note I said it also causes console login as a user to fail. It's an authentication problem, somehow. I don't have any details yet because I was at a conference and it's a bit awkward to debug, there's nothing super obvious in the logs. But the tests reliably fail with this update and pass without it, and it looks like similar failures have happened on rawhide/29 recently when the tests have actually made it this far. I'll file a bug with logs attached once I've looked into it a bit more.

Here's some circumstantial evidence, btw: the problematic update is 1.3.8.7. The equivalent release on the 1.4 branch, I think, is 1.4.0.14, those two came out at the same time. 1.3.8.7 was sent to F27 as an update candidate (this update), and 1.4.0.14 was sent to Rawhide at the time and so will be in both Rawhide and F29, but no update was sent to F28 - an F28 build was done in Koji, but no update was submitted.

This exactly matches up with what we're seeing - the bug seems to be happening in F29 and Rawhide, is happening in tests of this update (1.3.8.7) but not other F27 tests run without this update (which will be using 1.3.8.4, I think), and is not happening in any F28 tests (which will be using 1.4.0.13).

I'm gonna maybe run tests with various of the 1.3.8.* builds to try and pin down exactly when this problem appeared. From the existing openQA results it seems to have happened at least in 1.3.8.6 already; the 1.3.8.5 results are useless because server deployment failed...

The issue that IPA ran into was around unhashed passwords. It was added in 1.3.8.5, but removed in 1.3.8.6. So I'm surprised to see the same problem in 1.3.8.7. I have to assume it's "something else" that is causing the failure.

It really can't be, because the updates tests are pretty focused. They install a stable base image, then set up a repo containing only the packages from the update to be tested, then run an update, then reboot, then run the test.

So, when the tests run on this update, they have a stable base F27, plus the updated 389-ds-base package...and they fail. When the tests run on any other F27 update, they have the stable base F27, plus whatever packages were in that update...and the FreeIPA tests usually pass, for other updates. Look, here are the tests for a recent F27 kernel update - so that test will have run with the same base image, plus the updated kernel. Note the FreeIPA tests passed just fine.

Note, it seems the bug actually appeared at least as early as 1.3.8.6 - it didn't appear in 1.3.8.7. I just re-scheduled the tests for 1.3.8.6 last night, and here they are - failure in two client tests, as we've seen before, it fails on login, both to web UI and to a console. I can't tell if this bug existed in 1.3.8.5, though, as FreeIPA server deployment fails in 1.3.8.5. So the delta we know so far is: it works with 1.3.8.4 and fails with 1.3.8.6 and 1.3.8.7. It also seems that it worked with 1.4.0.11 but fails with 1.4.0.15 - I'm not sure about 1.4.0.14 yet.

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

Sorry I didn't file a bug yet, btw, life keeps getting in the way :( I'll get to it tomorrow for sure...

I understand :-) Thanks!

This update has been obsoleted by 389-ds-base-1.3.8.8-1.fc27.


Add Comment & Feedback
Toggle Preview

Comment fields support Fedora-Flavored Markdown. Comments are governed under this privacy policy.

-1 0 +1 Feedback Guidelines
Test Case 389 ds base setup testcase
Test Case Create normalized dn cache testcase
Test Case Create normalized dn cache testcase2
Is the update generally functional?
Content Type
RPM
Status
obsolete
Test Gating
Submitted by
Update Type
bugfix
Update Severity
unspecified
Karma
-1
stable threshold: 1
unstable threshold: -1
Autopush
Disabled
Dates
submitted a month ago
in testing a month ago

Automated Test Results