pulp-admin --config and/or api_prefix option appears to be ignored
This is a show-stopper problem for my AD / kerberos integration efforts I'm putting together for 2.9 documentation.
Because pulp-admin cannot work with kerberos tickets, a split authentication scheme must be used to allow both AD accounts and local pulp accounts to log into Pulp. The easiest way we have thought of to allow this is to have two different api paths via WSGIScriptAlias like so:
WSGIScriptAlias /pulp/api /usr/share/pulp/wsgi/webservices.wsgi
WSGIScriptAlias /pulp-local/api /usr/share/pulp/wsgi/webservices.wsgi
Then having a mod_auth_gssapi conf file to protect logins on the normal API path using AD auth:
- Require TLS (nee SSL).
- Use GSSAPI authentication.
AuthName "Pulp Login"
- For paranoia, make GSSAPI also require TLS.
- Permit password-based authentication for clients that can't do Negotiate.
- Require a valid user.
With these settings in place for Apache, a local login should be possible by using an alternate config file that contains the following api_prefix statement:
...and pointing to the alternate config file via:
pulp-admin -v --config=/etc/pulp/admin/admin-local.conf login -u admin -p <some_password>
But this does not happen. Instead, the login command is posted to the normal api path as seen in the logs:
==> /var/log/httpd/ssl_access_log <==
10.xx.xx.xx - - [14/Apr/2016:10:22:47
0400] "POST /pulp/api/v2/actions/login/ HTTP/1.1" 401 451 "" "-"
Frustratingly, using strace it's apparent that the admin-client does in fact source the alternate config file, but it doesn't seem to accept the api_prefix option:
v --config=/etc/pulp/admin/admin-local.conf login -u admin -p ---------------- 2>&1 | grep admin-local
open("/etc/pulp/admin/admin-local.conf", O_RDONLY) = 3
Because I don't know how to Python, I'm at a loss to figure out what is broken behind the curtain.
Use the api_prefix option from config
The config contains api_prefix, but it was not being utilized when initializing a PulpConnection.
#1 Updated by kfiresmith almost 5 years ago
While the above issue is annoying I've since figured out that I can at least use /root/.pulp/admin.conf's [auth] section to completely circumvent our apache mod_auth_gssapi protections for root in order to do all our automated pulp-admin functions, so this isn't quite the end of the world for us after all.
Of course in the long run we'd still like full GSSAPI goodness so that we can just have root use the host principal to interact with pulp via pulp-admin, but that's outside the scope of this bug by a mile.
#2 Updated by firstname.lastname@example.org almost 5 years ago
- Status changed from NEW to POST
- Assignee set to email@example.com
After a brief investigation, it appears that the config option `api_prefix` was not being used.
I changed `/etc/pulp/admin/admin.conf` api_prefix, restarted, and made a pulp-admin request. It still went to the default prefix `pulp/api`
Please register to edit this issue