Bug 772230 - Make default admin user creation part of pulp-migrate, not lazy at startup
Summary: Make default admin user creation part of pulp-migrate, not lazy at startup
Keywords:
Status: CLOSED DUPLICATE of bug 1080609
Alias: None
Product: Pulp
Classification: Retired
Component: z_other
Version: unspecified
Hardware: Unspecified
OS: Unspecified
low
low
Target Milestone: ---
: ---
Assignee: Sayli Karmarkar
QA Contact: Preethi Thomas
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-01-06 14:31 UTC by Jay Dobies
Modified: 2015-03-23 01:11 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-11-07 22:38:19 UTC
Embargoed:


Attachments (Terms of Use)

Description Jay Dobies 2012-01-06 14:31:20 UTC
Currently, the admin user is created lazily at startup using the default password in pulp.conf. This was done before we had pulp-migrate, so it makes sense why it was done that way.

That said, we should consolidate all of the database initialization into a single area. pulp-migrate is the logical choice, so let's move it to there.

This came up as part of a RHUI documentation bug. The lazy creation of the default user on start up is wonky when you try to put it into documentation and looks bizarre since we had an explicit database initialization step.

Comment 1 Nick Coghlan 2012-06-04 07:29:06 UTC
I'd like to request that the priority of this bug be raised. Currently, if you enable LDAP integration prior to the first attempt at using the default admin account, the *default admin user is never created*.

2012-06-04 17:17:00,765 3880:140488436868864: pulp.server.auth.authentication:ERROR: authentication:108 User [admin] specified in certificate was not found in the system

My best guess is that the LDAP integration supercedes the lazy creation of the admin user.

Since Pulp doesn't currently support Kerberos ticket based auth, this absence is creating problems for automation of deployment.

Comment 2 Nick Coghlan 2012-06-05 01:24:47 UTC
While investigating something else, I realised my diagnosis here was slightly off - it isn't specifically the presence or absence of LDAP that causes problems, it's whether or not there are any other super-users defined.

That's undocumented and rather surprising.

Comment 3 Chris Duryee 2014-11-07 22:38:19 UTC
This was fixed as part of the fix for #1080609.

*** This bug has been marked as a duplicate of bug 1080609 ***


Note You need to log in before you can comment on or make changes to this bug.