Re: debconfig-common new template text review
> On 07-08-2019 23:56, Justin B Rye wrote:
>> Paul Gevers:
>>> The problem with "this allows different packages to choose for
>>> themselves" is that one shouldn't choose "unspecified/default", but one
>>> should rather not change the selection. Because a package can have
>>> changed the default from unspecified to one of the other settings.
>>>
>>> Also I don't think how the plugin is used is crisp and clear.
>>
>> I can't make it any clearer than my own understanding of what this
>> debconf template is all about.
Think of debconf-common being a package that contains scripts. Those
scripts are going to be used by other packages, like if debconf-common
was an API, making the life of whoever wants to touch databases
simpler.
> So, that is exactly what I try to improve here, your understanding and
> that of everybody involved, including the future reader of the template.
> The fact that it isn't clear for you yet, is exactly confirming my worries.
>>> So, how about (I'm not 100% happy yet):
>>> """
>>> Please specify whether a particular MySQL authentication plugin should
>>> be enforced for the new users created by ${pkg} . Most of the time,
>>
>> It might make the phrasing easier if we start by giving some sort of
>> brief context, like:
>>
>> The package ${pkg} needs to create new MySQL users, using one of the
>> available authentication plugins. Please specify...
> My problem with this sentence is that it's not the creation process of
> the user(s) that needs the plugin. It's the plugin that the MySQL user
> (so, the package) will use when it wants to authenticate to the MySQL
> server. 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.
>> 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.
I'll try to make it more "binary":
- If user chooses "default":
MariaDB: will create users using "default" auth mechanism/plugin.
MySQL: will create users using "default" auth mechanism/plugin.
- MySQL default authentication plugin:
- Before 8.0.11: "mysql_native_password"
- 8.0.11 and after: "caching_sha2_password"
- MariaDB default authentication plugin:
- "mysql_native_password"
- "mysql_old_password"
- "auth_ed25519"
- "auth_pam"
MySQL available authentication plugins:
- mysql_native_password
- sha256_password
- caching_sha2_password
- mysql_clear_password
- authentication_pam
User installs a package that "depends" and "uses" debconfig-common. If
the package defines the variable "dbc_authplugin" on its ".config"
file, then the authentication mechanism is defined to dbc_authplugin
value (example: https://bit.ly/2KDGJl9) only for that package being
installed. In the example I pointed, cacti will default all of its
users creation to sha_256_password.
Note: I just spotted an issue and I'm changing cacti to use
"mysql_native_password" instead, so both are compatible (and fixing
Ubuntu recent upload).
IF user sets debconf priority to "low" (usually user doesn't) then the
debconf would popup already configured to the variable
"dbc_authplugin" content (if defined in the package being installed)
or "default" (if not defined).
So, if user is installing new cacti on MySQL >= 8.0.11:
- default auth plugin would be "default" (debconf default)
-> MySQL 8 would auto select "caching_sha2_password" <- PROBLEMs
- dbc_authplugin will be defined to "mysql_native_password"
-> authentication plugin will be defined on GRANT commands
- debconf might popup dialog with ""mysql_native_password" checked.
If user installs new cacti on MariaDB:
- default auth plugin would be "default" (debconf default)
-> MariaDB would auto select "mysql_native_password"
- dbc_authplugin will be defined to "mysql_native_password"
- debconf might popup dialog with "mysql_native_password" checked.
If user installs new cacti on MySQL < 8.0.11:
- default auth plugin would be "default" (debconf default)
-> MySQL would auto select "mysql_native_password"
-> no auth plugin will be specified during GRANT commands
- dbc_authplugin will be defined to "mysql_native_password"
-> authentication plugin will be defined on GRANT commands
- debconf might popup dialog with "mysql_native_password" checked.
----
IF user installs OLD cacti in OLD MySQL with new debconf:
- default auth_plugin would be "default" (debconf default)
-> MySQL would auto select "mysql_native_password"
- dbc_authplugin will be defined to "default"
-> no auth plugin will be specified during GRANT commands
- debconfig might popup dialog with "default" checked.
IF user installs PKG without "dbc_authplugin" defined in OLD MySQL:
- default auth_plugin would be "default" (debconf default)
-> MySQL would auto select "mysql_native_password"
- dbc_authplugin will be defined to "default"
-> no auth plugin will be specified during GRANT commands
- debconfig might popup dialog with "default" checked.
IF user installs PKG without "dbc_authplugin" defined in NEW MySQL 8:
- default auth_plugin would be "default" (debconf default)
-> MySQL would auto select "caching_sha2_password" <- PROBLEMs
-> no auth plugin will be specified during GRANT commands
- dbc_authplugin will be defined to "default"
- debconfig might popup dialog with "default" checked.
---- ONLY WAY TO GET INTO TROUBLE:
IF user installs PKG that CAN'T handle "default" (for MariaDB or
MySQL) and does not have "dbc_authplugin" variable set (or does not
change from "default" to something else in debconf).
Our tests have indicated that ONLY PHP authentication had problems
with "caching_sha2_password" because it is not using libmysqlclient
for the authentication.
That is why we created this variable, to enable those packages to
mitigate the issue by being enable to choose the authentication
mechanism they will use.
>>> not changing the current selection will work - if ${pkg} doesn't support
>>> the default it should have changed the selection to a working one.
>>> """
>>
>> Unfortunately the current selection might be the one I switched to
>> five minutes ago and now want to switch back from because it doesn't
>> work. Especially if I'm correctly understanding this: if ${pkg}
>> doesn't support the MySQL default (whatever that is), it'll switch to
>> recommending something else, but will let the user select any of the
>> alternatives without giving any indication of which ones it supports?
> Unfortunately, that's correct. The package can only change the selection
> during the initial phase where the debconf template is still empty. Once
> it has been changed, there is no way to learn what the original
> selection was.
The text above explains that part I suppose.
>> 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. 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.
The text above explains that part I suppose.
I hope its clearer now, please let me know if you'd like me to clarify
anything further.
Thx a lot!
Rafael D. Tinoco
Reply to: