modify password of admin or service tenant user

[ZhiQiang Fan]

/* i follow hastexo's blog and install openstack essex and also check devstack's configuration settings */

when i login horizon with admin role, so i can use the *admin* panel, and then modify user information by *edit* user from user list. but there is a problem (i think it is a bug) when modify password of special user *admin* , *nova* and *glance*

configuration file: /etc/glance/glance-api-paste.ini, /etc/glance/glance-registry-paste.ini and /etc/nova/api-paste.ini need set variable of admin_tenant_name, admin_user and admin_password, mostly set to *service* tenant, {glance,nova} user, and password corresponding to the user. sometimes even set to *admin* tenant, *admin* user. (which is not reasonable but some install guide writes this, and it truely works)

when i modify user's password of nova, glance (if configuration file set to these user, otherwise if set to admin, then modify admin'a password will raise this problem), the corresponding service will no be able to be authenticated and fail to work.

i guess horizon uses keystoneclient's api *update_password* (command line api is user-password-update) and update user's password in database, but since there is no api to modify service configuration setting files and horizon may not have privilege to run script with root privilege to automatically modify corresonding config files (if i'm wrong please let me know), so may be horizon can't do any futher and leaving this problem to openstack administrtor

but i think if there is a feature (like modify user's password) is offerd by horizon, or at least user can notice this feature on horizon pages, then we should make sure this feature works right, if that is out of our control, at least warn the adminitrator by pop up a *NOTICE* or *WARNING* to let admin modify config files on host

/* i have searched the bugs list and answer list for this problem */
if there is a way to put a trigger after keystone update password successfully to run a script to modify password, then this problem can be solved easily but requires some addtional work on install

[Gabriel Hurley (gabriel-hurley)]

I agree 100% on the problem. Unfortunately for Horizon there is no way to identify the service users or projects other than by name, which is configurable and done by convention, not enforced. That means we can't rationally warn an admin about those accounts because we can't guarantee they are or aren't the right ones. There's also no API to update the config files for the other services, that currently has to be done manually.

When the service accounts were first created I strongly argued for filtering them out of the API calls. I think they should be internal and untouchable, not ever exposed.

At the very least Keystone needs some kind of added identifier on both the users and the accounts before anything meaningful can be done with them.

[Morgan Fainberg (mdrnstm)]

not something we really can fix, this is a CMS-related thing and/or securing your service users.

Keystone isn't in the business of "owning" config files.