[PKG-Openstack-devel] No admin/service users is created

[Thomas Goirand]

On 12/07/2016 11:27 AM, Turbo Fredriksson wrote:
> These are the questions you ask for for EVERY package!
> 
> [... striped mysql ...]
> 
> 	*/admin-user			=> Openstack service user
> 	*/admin-password		=> Openstack service user password
> 
> 	*/admin-tenant-name	=> Openstack tenant name
> 
> 	*/keystone-auth-token	=> Openstack authentication token
> 	*/endpoint-ip			=> Openstack Keystone IP
> 
> That’s all you need.

Not correct. It used to be that we were asking for the
keystone-auth-token for the -api packages. However, this was replaced by
the tenant-name / username / password as the auth-token is being
deprecated upstream. However, these are for the -api packages, so that
we can register the endpoint. But the [keystone_authtoken] thing is
located in the -common packages, so these aren't available there.

> Except possibly with, possibly a -plow, ask if to create
> the (service) user.

This would be 4 more screens.

> IMO, that question isn’t necessary though.

It would be mandatory, because we can't just do API calls by default
(otherwise, this would break the non-interactive mode). If you have any
suggestion on how to do it in another way, let me know.

> Just document
> “somewhere” that if someone specifies a specific user and password in those
> ‘*/admin-{user,password}’ questions, a user WILL be created.

There's no way to know if it was specified by hand, or if the value
fetched with db_get was set using the already configured
[keystone_authtoken], which would be read by the .config script. If you
know a trick, let me know, but I don't think there's one.

> If you look at "cinder-api.config:pkgos_write_admin_creds()” for example, it
> reads those values from debconf, then writes it into the config file.

Yes, though the [keystone_authtoken is configured in cinder-common, as I
wrote previously. That's because it's the -common package that holds the
configuration file. I don't think this can change.

> What I’m suggesting is that either before or after it have done this (in that same
> function, written into the config file), it creates a new Openstack service user
> [something] like this:
> 
>             openstack [—os-* options] user create --domain Default \
> 		--project-domain Default --enable --password "${pass}” \
> 		--project “${tenant}" “${user}"
>             openstack [—os-* options] role add --project “${tenant}" --user “${user}” admin

Yes, that'd be more or less the way to do it! :)

> If you create that once, in the "openstack-pkg-tools” package, you’re golden. 

If we do it, it will be there indeed. I'm still open to do it, though I
don't think it's reasonable to plan it for Stretch: many translation
wouldn't be there.

> PS. From testing, I realised that the user needs also be part of the ‘admin’ role.

Correct.

>>> But the postinst still calls db_unregister() to unregister all service user passwords.
>>
>> Which is fine, because the .config scripts are filling dbc_password with
>> the value from the .conf files of services. So as long as the initial
>> setup is done correctly, it shouldn't prompt for this password again.
> 
> Two things here: “someone” is then purging it from the dbconfig files and to, “as long as
> the initial setup is done correctly” - famous last words! :). That’s the clincher here as
> i see it. That’s why _I_ (!!) want control of when/if that happens!
> 
> I really don’t like it when install scripts etc try to _anticipate_ what I want and/or need.

It would be a security issue to keep passwords in debconf. The someone
is dbconfig-common anyway, so that would be where to address it.

Cheers,

Thomas Goirand (zigo)