Hi Justin,
On 09-08-2019 00:22, Justin B Rye wrote:
> No, it doesn't use the plugin to create them, it
> just sets an attribute of that newly-created user that defines how the
> database will expect login attempts to work - is that it?
I think that is the right description, yes.
> Oh, wait, this alternative approach works better than I was expecting:
>
> Please specify which of the available plugins the package ${pkg}
> should configure database user accounts to use for authentication
> with MySQL.
Ack. Although that sentence for me as a non-native speaker is difficult
to parse. I love it that Dutch makes it one word (such that on first
read, my mind doesn't stop three times, but only once for "database user
accounts"). I don't know how to improve that though.
>> In some cases, like PHP based packages, the MySQL client library
>> isn't supporting all plugins, so the package has to tell the server that
>> the user allowed to (and will) connect via a non-default plugin.
>
> "Tell the server" means "set as an attribute of the DB user account",
> right?
I think so, yes.
>>> But what actual decision are users being asked to make? If they read
>>> the sentence "Please specify whether a particular MySQL authentication
>>> plugin should be enforced" and decide that the answer is "no", does
>>> that mean MySQL is free to give a different undefined behaviour each
>>> time?
>>
>> Rafael, can you answer this question. I don't know. But I guess this is
>> one of the difficult problems with the fact that remote MySQL/MariaDB
>> support may mean that we are talking to a different version than we
>> would expect in our "own" release. I.e. in a Debian bullseye package we
>> may be talking to a Redhat whatever version of MySQL server.
>
> It's impressive that you've got this working at all!
That honor goes to seanius, who long since retired from Debian.
>>> Meanwhile, "should have" makes it sound as if we don't trust it; if we
>>> *do* trust it maybe we can phrase it more like a guarantee.
>>>
>>> Leaving the selection set to its default will always work, but other
>>> options may not be supported by ${pkg}.
>>
>> This isn't true, as the default is the MySQL server default.
>
> I thought you said... yes, you definitely said
>
> if ${pkg} doesn't support
> the default it should have changed the selection to a working one.
Ack. I didn't claim my proposal was perfect yet :)
> So I don't understand. It isn't helping that there are (at least)
> three different layers of "default" behaviour involved:
> 1) this debconf prompt's current selection;
> 2) the plugin that this package automatically prefers by default
> unless you use this template to select something else;
> 3) the database's default authentication system;
> "Leaving the selection set to its default" is talking about (2)...
> Maybe we could avoid the word and say:
>
> Leaving the selection set to its original value will always work,
> but other options may not be supported by ${pkg}.
With remote databases the phrase "will always work" is dangerous. It
will work (minus bugs) if the database and the client are on the same
Debian/derivative release. Cross releases isn't possible to guarantee.
So I'd rather claim "should always work" or maybe you can come up with a
smarter (more extensive) disclaimer.
>> The problem
>> we're trying to fix is for packages that don't support the MySQL
>> default. They can change the initial selection, but are powerless if the
>> user decides to change it. However, if the current (client side) system
>> needs to talk to a remote server, the user may need to explicitly state
>> the plugin as both sides may not be aligned on the same MySQL default.
>
> (Even if it isn't possible to get the name of ${pkg}'s preferred
> plugin onto the screen here, presumably it could at least be in a
> README somewhere?)
Yes. Paragraph 1.4.1 of the proposed database policy [1] also mentions
that: "With this in mind, directions for manually installing (and
upgrading if relevant) the database must be included in the
documentation for the package."
Paul
[1] https://www.debian.org/doc/manuals/dbapp-policy/
Attachment:
signature.asc
Description: OpenPGP digital signature