[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: A regression bug comparing Stretch to Jessie -was [Re: Doing a clean install with ATYPICAL constraints]

On 05/13/2017 07:46 AM, Brian wrote:
On Sat 13 May 2017 at 07:32:52 -0500, Richard Owlett wrote:

On 05/12/2017 04:09 PM, tomas@tuxteam.de wrote:
Hash: SHA1

On Fri, May 12, 2017 at 02:46:13PM -0500, Richard Owlett wrote:
On 05/12/2017 12:40 PM, deloptes wrote:


It took me a while to realize there is difference from MySQL perspective if
you use localhost and "localhost" goes via unix socket.

en englais s'il vous plait ;<
I don't spell well den Anglais ou Francais <lol>

Eh bien, comment vous voulez. is, you probably know that, the Internet (IPV4, to be more
precise) version of "me". On the network, every host sees itself
(among possibly other things) as

A UNIX socket (or unix domain socket) is an entry in the file system
which behaves roughly like a network connection. Two processes can
talk bidirectionally over it, as they might do over a TCP connection.

The database server can listen to local clients over
(typically on the regular MySQL port) or over a UNIX domain socket.
There is one subtle difference between both: whereas any process
can talk to, you can restrict those who can access the
UNIX domain socket (plus it has a couple of other tricks up its

Thus, when setting up permissions on MySQL, you include the
way the connection has come to the server and it makes sense
to have a different set of permissions depending on whether
things came via a UNIX domain socket (which MySQL calls then
"localhost") or via port. A bit counterintuitive,
because usually one considers and localhost as

C'est mieux?

A little. It was helped by a solid 10 hours of sleep last night ;/

I am convinced there is a regression bug. The $64 question is "Where?"
I suspect a subtle dependency problem. Admittedly based on a personal design
philosophy of how dependencies should be defined/specified/chosen/(better
word?). I have a laptop which no longer serves its intended purpose. Once
I've archived an image of its drive, I'll set it up to be a specialized
test-bed multi-booting customized Debian 6, 8, and 9.

Debian documentation includes a changelog. Does any of

  * Re-implement passwordless root login (Closes: #851131)

  * Add patches to make passwordless root login default on all new
    installs in all situations. Make auth_socket a built-in plugin.
  * Clean up previous passwordless root implementation so that it
    applies only to new installs and existing databases continue
    to operate with the passwords defined in their user tables

  * Stop asking and setting a database root user password. Instead enable
    the auth_socket plugin and let unix user root access MariaDB without
    a separate password. Admins using sudo or cron scripts can use the
    same access too, and there is no debian-sys-maint password either anymore.

shake your conviction?

Not quite in the manner I suspect you assume <chuckle>.
We come from different point-of-views.
You evidently lean towards "power user".
I have some characteristics of "mass market consumer".

The points you listed appear likely to lead to alleviation of my observed _symptoms_ of an underlying problem.

I'll draw an analogy from the development of the germ theory of disease in the mid-nineteenth century. Semmelweis noticed a higher incidence of death among women who delivered at the hospital with the help of the doctors and medical students. Births attended by the midwives were relatively safe. { see

Examples will have to wait on my specialized test-bed multi-booting customized Debian 6, 8, and 9.

Reply to: