Re: A regression bug comparing Stretch to Jessie -was [Re: Doing a clean install with ATYPICAL constraints]
On Sat 13 May 2017 at 07:32:52 -0500, Richard Owlett wrote:
> On 05/12/2017 04:09 PM, tomas@tuxteam.de wrote:
> >-----BEGIN PGP SIGNED MESSAGE-----
> >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 127.0.0.1. "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.
> >
> >127.0.0.1 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 127.0.0.1.
> >
> >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 127.0.0.1
> >(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 127.0.0.1, you can restrict those who can access the
> >UNIX domain socket (plus it has a couple of other tricks up its
> >sleeve).
> >
> >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 127.0.0.1/MySQL port. A bit counterintuitive,
> >because usually one considers 127.0.0.1 and localhost as
> >synonyms.
> >
> >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?
--
Brian.
Reply to: