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:-----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?
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
https://en.wikipedia.org/wiki/Germ_theory_of_disease#Ignaz_Semmelweis}Examples will have to wait on my specialized test-bed multi-booting customized Debian 6, 8, and 9.