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

[Thomas Goirand]

On 12/06/2016 01:26 PM, Turbo Fredriksson wrote:
> On 6 Dec 2016, at 11:56, Thomas Goirand <zigo at debian.org> wrote:
> 
>> If you want a different user for each and every service, then you have
>> to create it by yourself using the openstack command line. We could add
>> the logic for it, but I don't think it's useful. Your thoughts?
> 
> Well, you’re asking for that information AND you’re writing that information
> into the config file(s).

The point of asking for the information is precisely to be able to write
it in the configuration file.

> It stands to reason, in my opinion, that that user should also be/have been
> created.

In which case shall we then create the user? Should we add another
prompt to ask if we should create the user or not? Should we then ask
for tenant, login and pass, to be able to create the user? That's 4 more
Debconf prompt, which would have to be in every API package...

> I’m not sure where/when the issue originally appeared, but I’m guessing
> somewhere in the pre-seeding. Or in combination with creating the
> dbconfig files..
> 
> These two must match properly - which in my opinion is a little annoying.

Well, I'm not sure how you're doing the preseeding. Why don't you use
the preseed lib which is provided by openstack-meta-packages?

> So somewhere, the MySQL DB wasn’t created (or ‘known’ to the pre/post
> install scripts - i.e. they didn’t know to use MySQL), so it did a fallback to
> using SQLite.
> 
> If SQLite isn’t an option for that service/package, that should not be an
> option to choose in debconf, and if the pre/post install script don’t know
> what to do [correctly], they should simply fail with an error. Not try to do
> something that will fail with a “weird” error.

Yes, though it's hard to list which project supports SQLite or not. I
know at least Neutron and Ironic don't. For the others, I'm really not sure.

> Regarding the dbconfig/debconf match/missmatch, I think that debconf
> should be authoritative. “You” [someone] is currently asking if the debconfig
> files should be kept/recreated but, IMO, they should ALWAYS be recreated,
> with information from debconf in the postinst scripts.

That's an issue in dbconfig-common, not in the OpenStack packaging. I
have read that dbconfig-common was fixed, and that now we could use only
debconf preseeding, but I haven't tested this.

> That way, they’re ALWAYS ‘up-to-date’ with information that’s specified
> in debconf.

Debconf isn't a registry, so what *must* count (as per "must" in the
Debian policy) is what's in the dbconfig-common configuration file (that
is, if the "to-be-configured" service doesn't have a proper DSN yet, in
which case that's the authoritative source).

> And the passwords should NOT be purged automatically! Let the user
> decide when/where to purge that (I do it at the very end of my bootstrap
> script). Or simply have a debconf option to turn this [automatic purging]
> on/off.

dpkg-reconfigure dbconfig-common -plow makes it so it's possible to keep
the root password. Though the root password isn't even needed in case
you're just using a local server.

As for the password for the service itself, it's not being prompted, and
the authoritative source for it is the .conf file of the OpenStack
service. To my experience, dbconfig-common isn't asking for such a
password if filled in the dbc_password variable. If it is, IMO that's a
recent regression.

> Because of this, every time I’ve installed a package, I need to run the
> preseeding again. Oh, and every time I’ve run reconfigure etc!!

Then you're doing something wrong. I've been running a preseed for the
packaging CI which installs everything in a single node, and there's no
need to reconfigure packages.

> Feel free to purge the passwords from the dbconfig files, as long as those
> files are recreated if/when someone runs configure/reconfigure on the
> package(s).

These files aren't under the responsibility of package maintainers. The
files in /etc/dbconfig-common are from dbconfig-common, and there's no
reason package maintainer scripts would play with it.

With all of the above, it looks like I can close all of the bugs you
filled about db issues. Can you confirm? I don't want to be rude and
close them without your confirmation.

Cheers,

Thomas Goirand (zigo)