Project

Profile

Help

Issue #7499

pulp_installer is unpredictable about when it resets the admin password

Added by mdepaulo@redhat.com 18 days ago. Updated 12 days ago.

Status:
MODIFIED
Priority:
Normal
Assignee:
-
Category:
Installer
Sprint/Milestone:
-
Start date:
Due date:
Estimated time:
Severity:
2. Medium
Version:
Platform Release:
OS:
Triaged:
No
Groomed:
No
Sprint Candidate:
No
Tags:
Sprint:
Quarter:

Description

As mentioned in #7493 and https://github.com/pulp/pulp_installer/pull/427 , it is unpredictable about when it is run. From a user's perspective.

#7493 is about to make it run more often.

The current thinking is to not run change the password after initial install ever.

However, we still need pulp_default_admin_password to be defined in pulp_devel and pulp_health_check . The beginning of pulp_database_config also makes sure it is defined, we may remove that.


Related issues

Related to Pulp - Issue #7493: Installer: remove auth migration taskMODIFIED<a title="Actions" class="icon-only icon-actions js-contextmenu" href="#">Actions</a>

Associated revisions

Revision b8c456ca View on GitHub
Added by mdellweg 13 days ago

Add a check to only set password on first install

Also make the health check independend from knowing the password.

fixes #7499 https://pulp.plan.io/issues/7499

Revision b8c456ca View on GitHub
Added by mdellweg 13 days ago

Add a check to only set password on first install

Also make the health check independend from knowing the password.

fixes #7499 https://pulp.plan.io/issues/7499

History

#1 Updated by mdepaulo@redhat.com 18 days ago

  • Related to Issue #7493: Installer: remove auth migration task added

#2 Updated by mdepaulo@redhat.com 18 days ago

My proposed solution is this:

  1. For initial install, always set it.
  2. For upgrades or re-running the installer for any other reason, let it be determined by a variable like "pulp_always_reset_admin_pw"
  3. Ignore whether or not migrations were run.

#3 Updated by mdellweg 16 days ago

Since the health check tests seem to need the password, it looks like we assume that the installer needs to know the current pulp admin password anyway. So we could go a step further and say, that the password is managed by the installer. We can than add a test whether the password still works and (re-)set it. I'd say the variable should be named pulp_admin_password in that case.

On the other hand, i don't think the status endpoint (used in the health check) needs the password. So we could use the set-only-if-touched-file-is-absent approach. We would instruct the user to delete that file in order to reset the password via the installer.

#4 Updated by pulpbot 14 days ago

  • Status changed from NEW to POST

#5 Updated by mdellweg 12 days ago

  • Status changed from POST to MODIFIED

Please register to edit this issue

Also available in: Atom PDF