Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #180934 > unrolled thread

Doing a clean install with ATYPICAL constraints

Back to article view | Back to linux.debian.user

Contents

  Doing a clean install with ATYPICAL constraints Richard Owlett <rowlett@cloud85.net> - 2017-05-11 20:00 +0200
    Re: Doing a clean install with ATYPICAL constraints Greg Wooledge <wooledg@eeg.ccf.org> - 2017-05-11 21:20 +0200
      Re: Doing a clean install with ATYPICAL constraints Richard Owlett <rowlett@cloud85.net> - 2017-05-11 22:20 +0200
    Re: Doing a clean install with ATYPICAL constraints Joe <joe@jretrading.com> - 2017-05-11 21:20 +0200
    A regression bug comparing Stretch to Jessie -was [Re: Doing a clean  install with ATYPICAL constraints] Richard Owlett <rowlett@cloud85.net> - 2017-05-12 05:00 +0200
      Re: A regression bug comparing Stretch to Jessie -was [Re: Doing a  clean install with ATYPICAL constraints] Brian <ad44@cityscape.co.uk> - 2017-05-12 10:00 +0200
        Re: A regression bug comparing Stretch to Jessie -was [Re: Doing a  clean install with ATYPICAL constraints] Richard Owlett <rowlett@cloud85.net> - 2017-05-12 16:50 +0200
          Re: A regression bug comparing Stretch to Jessie -was [Re: Doing a clean install with ATYPICAL constraints] deloptes <deloptes@gmail.com> - 2017-05-12 19:50 +0200
            Re: A regression bug comparing Stretch to Jessie -was [Re: Doing a  clean install with ATYPICAL constraints] Richard Owlett <rowlett@cloud85.net> - 2017-05-12 21:50 +0200
              Re: A regression bug comparing Stretch to Jessie -was [Re: Doing a  clean install with ATYPICAL constraints] <tomas@tuxteam.de> - 2017-05-12 23:20 +0200
                Re: A regression bug comparing Stretch to Jessie -was [Re: Doing a  clean install with ATYPICAL constraints] Richard Owlett <rowlett@cloud85.net> - 2017-05-13 14:40 +0200
                  Re: A regression bug comparing Stretch to Jessie -was [Re: Doing a  clean install with ATYPICAL constraints] Brian <ad44@cityscape.co.uk> - 2017-05-13 14:50 +0200
                    Re: A regression bug comparing Stretch to Jessie -was [Re: Doing a  clean install with ATYPICAL constraints] Richard Owlett <rowlett@cloud85.net> - 2017-05-13 16:30 +0200
                      Re: A regression bug comparing Stretch to Jessie -was [Re: Doing a  clean install with ATYPICAL constraints] songbird <songbird@anthive.com> - 2017-05-13 18:10 +0200
                        Re: A regression bug comparing Stretch to Jessie -was [Re: Doing a  clean install with ATYPICAL constraints] Richard Owlett <rowlett@cloud85.net> - 2017-05-13 19:30 +0200
                          Re: A regression bug comparing Stretch to Jessie -was [Re: Doing a  clean install with ATYPICAL constraints] songbird <songbird@anthive.com> - 2017-05-13 21:30 +0200

#180934 — Doing a clean install with ATYPICAL constraints

I'm having problems with initial use of mariadb on Debian Testing.
The *apparent* symptom is never being asked to provide an initial 
password an failure in creating one later.

Operator error is high on list of possible causes ;/
However, >50 of trouble shooting experience hints at more.
I've a gut feeling that system history plays a significant role - for 
you math types, think path dependent integrals.

A proper test procedure will be reasonably straight forward to specify.
   1. A clean install of Debian Testing to a new partition using netinst
      Expert mode for maximum control
      Specify only MATE desktop and "standard utilities"
   2. Install Apache2 and mariadb-server using which ever tool will
      leave the most complete audit trail. I prefer Synaptic as that
      is what I used before.
   3. Archive relevant logs (I've > 300GB of available SSD ;)
      Someone will have to guide me to desirable logs to preserve.
   4. Document failure of system to request defining initial password
   5. Document failure to be able to define password
   6. Repeat steps 1 thru 5 as required

Step 6 is *THE STICKY POINT*
I'm up against a data cap. I estimate that between what I have left for 
this month and what I have left in my "bank", I can do *ONE* iteration 
of the above.

I've never intentionally removed anything from any cache Synaptic and 
apt-get have used since installing Testing.

Is there any way to use such for a fresh install?
Is there any way to set up the install to have a local cache of 
everything I download this time around?
Comments?

TIA

[toc] | [next] | [standalone]

#180935

On Thu, May 11, 2017 at 08:12:29PM +0100, Joe wrote:
> OK, it looks like I'm wrong, and the Debian packaging of mariadb is
> *not* a drop-in replacement for mysql, at least from a clean
> installation.
> 
> I was sort of under the impression that Debian had changed horses to
> mariadb, and managed it with metafiles and transition packages, but it
> appears that both my wheezy server and my sid workstation are still on
> mysql. I'm using mariadb, but apparently only on my Win8 laptop.

I don't use MySQL or MariaDB myself, but a MySQL -> MariaDB transition
is listed as one of the stretch release goals, and "done", here:

https://lists.debian.org/debian-devel-announce/2017/04/msg00008.html

[toc] | [prev] | [next] | [standalone]

#180938

On 05/11/2017 02:15 PM, Greg Wooledge wrote:
> On Thu, May 11, 2017 at 08:12:29PM +0100, Joe wrote:
>> OK, it looks like I'm wrong, and the Debian packaging of mariadb is
>> *not* a drop-in replacement for mysql, at least from a clean
>> installation.
>>
>> I was sort of under the impression that Debian had changed horses to
>> mariadb, and managed it with metafiles and transition packages, but it
>> appears that both my wheezy server and my sid workstation are still on
>> mysql. I'm using mariadb, but apparently only on my Win8 laptop.
>
> I don't use MySQL or MariaDB myself, but a MySQL -> MariaDB transition
> is listed as one of the stretch release goals, and "done", here:
>
> https://lists.debian.org/debian-devel-announce/2017/04/msg00008.html
>

No claim to be bug free ;}
I the post's date significant. IIRC about that date something changed in 
what Synaptic said was available. I believe a mysql meta-package was 
deleted. But I'm relying *ONLY* on memory *NOT DOCUMENTED EVIDENCE*

I suspect there is a documentation problem.
Following the startup procedure outlined in
https://www.tecmint.com/install-mariadb-in-debian/
which joe mentioned, I got a lot further than previously.
Still using *ONLY* the *STRETCH* repository.

See transcript below :}

richard@stretch-2nd:~$ su
Password:
root@stretch-2nd:/home/richard# mariadb
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 7
Server version: 10.1.22-MariaDB- Debian 9.0

Copyright (c) 2000, 2016, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input 
statement.

MariaDB [(none)]> CREATE USER 'sam' IDENTIFIED BY 'sam123';
Query OK, 0 rows affected (0.00 sec)



MariaDB [mysql]> select user, host, authentication_string, password from 
mysql.user;
+------+-----------+-----------------------+-------------------------------------------+
| user | host      | authentication_string | password 
               |
+------+-----------+-----------------------+-------------------------------------------+
| root | localhost |                       | 
*EAFDCF7DE7B8B5BA5CBA28FDD878420CF08E7764 |
| sam  | %         |                       | 
*26F07D3B38B5FAC4BA063A5D76D2895C73319D78 |
+------+-----------+-----------------------+-------------------------------------------+
2 rows in set (0.00 sec)

MariaDB [mysql]> help version
Name: 'VERSION'
Description:
Syntax:
VERSION()

Returns a string that indicates the MySQL server version. The string
uses the utf8 character set. The value might have a suffix in addition
to the version number. See the description of the version system
variable in
https://mariadb.com/kb/en/server-system-variables#version.

URL: https://mariadb.com/kb/en/version/

Examples:
MariaDB> SELECT VERSION();
         -> '5.5.29-standard'

MariaDB [mysql]> SELECT VERSION();
+------------------+
| VERSION()        |
+------------------+
| 10.1.22-MariaDB- |
+------------------+
1 row in set (0.00 sec)

MariaDB [mysql]> \q
Bye

 >>>>>>>>>>>>> A *SUCCESSFUL* login  <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
root@stretch-2nd:/home/richard# mariadb -u sam  -p
Enter password:
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 8
Server version: 10.1.22-MariaDB- Debian 9.0

Copyright (c) 2000, 2016, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input 
statement.

MariaDB [(none)]> \q
Bye

 >>> A *_NOT_ SUCCESSFUL* login  {intentionally bad password ;} <<<<<
root@stretch-2nd:/home/richard# mariadb -u sam  -p
Enter password:
ERROR 1045 (28000): Access denied for user 'sam'@'localhost' (using 
password: YES)
root@stretch-2nd:/home/richard#



I've some more tests to run.

[toc] | [prev] | [next] | [standalone]

#180936

On Thu, 11 May 2017 12:50:07 -0500
Richard Owlett <rowlett@cloud85.net> wrote:

> I'm having problems with initial use of mariadb on Debian Testing.
> The *apparent* symptom is never being asked to provide an initial 
> password an failure in creating one later.
> 

OK, it looks like I'm wrong, and the Debian packaging of mariadb is
*not* a drop-in replacement for mysql, at least from a clean
installation.

I was sort of under the impression that Debian had changed horses to
mariadb, and managed it with metafiles and transition packages, but it
appears that both my wheezy server and my sid workstation are still on
mysql. I'm using mariadb, but apparently only on my Win8 laptop.

What is much more to the point is that the packages for sid (and
presumably other distributions) are utterly different, with
mysql-server-5.7 having all the expected Debian stuff, with its control
file containing the statement:
"This package contains all the infrastructure needed to setup system
 databases."

The mariadb package, on the other hand, has a control directory that
contains only md5sums and control files: specifically, in this
particular situation, no postinst file. So mariadb is never going to be
configured by Debian on installation, and the OP's problem is
explained, at least to the first level.

The immediate answer in Debian would seem to be 'forget mariadb, install
mysql', but what about the longer term? Does anyone know where mariadb
is going in Debian? It would appear that mariadb can be installed
'properly' using a package from the mariadb site:
https://www.tecmint.com/install-mariadb-in-debian/

-- 
Joe

[toc] | [prev] | [next] | [standalone]

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

On 05/11/2017 12:50 PM, Richard Owlett wrote:
> I'm having problems with initial use of mariadb on Debian Testing.
> The *apparent* symptom is never being asked to provide an initial
> password an failure in creating one later.
>
> Operator error is high on list of possible causes ;/
> However, >50 of trouble shooting experience hints at more.
> I've a gut feeling that system history plays a significant role - for
> you math types, think path dependent integrals.
>
> A proper test procedure will be reasonably straight forward to specify.
>   1. A clean install of Debian Testing to a new partition using netinst
>      Expert mode for maximum control
>      Specify only MATE desktop and "standard utilities"
>   2. Install Apache2 and mariadb-server using which ever tool will
>      leave the most complete audit trail. I prefer Synaptic as that
>      is what I used before.
>   3. Archive relevant logs (I've > 300GB of available SSD ;)
>      Someone will have to guide me to desirable logs to preserve.
>   4. Document failure of system to request defining initial password
>   5. Document failure to be able to define password
>   6. Repeat steps 1 thru 5 as required
>
> Step 6 is *THE STICKY POINT*
> I'm up against a data cap. I estimate that between what I have left for
> this month and what I have left in my "bank", I can do *ONE* iteration
> of the above.
>
> I've never intentionally removed anything from any cache Synaptic and
> apt-get have used since installing Testing.
>
> Is there any way to use such for a fresh install?
> Is there any way to set up the install to have a local cache of
> everything I download this time around?
> Comments?
>
> TIA
>

Working from purchased DVDs of Debian Stretch (8.6.0) I did a minimal 
install (MATE desktop + standard utilities) to a fresh partition.
I then did
    apt-get install apache2
    apt-get install mariadb-server

On completion of the later I was asked for a password for 'root' user. I 
supplied it and was able to login. As a check I attempted to login with 
an incorrect password and was blocked.

I then followed the same procedure for Stretch using netinst
{Debian stretch-DI-rc3 i386 1}
I was never asked for the password.

After a night's sleep, I'll read up on bug reporting.
I've never filed a bug report, any assistance welcome.
Later - yawn ;/

[toc] | [prev] | [next] | [standalone]

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

On Thu 11 May 2017 at 21:54:57 -0500, Richard Owlett wrote:

> Working from purchased DVDs of Debian Stretch (8.6.0) I did a minimal
> install (MATE desktop + standard utilities) to a fresh partition.
> I then did
>    apt-get install apache2
>    apt-get install mariadb-server
> 
> On completion of the later I was asked for a password for 'root' user. I
> supplied it and was able to login. As a check I attempted to login with an
> incorrect password and was blocked.
> 
> I then followed the same procedure for Stretch using netinst
> {Debian stretch-DI-rc3 i386 1}
> I was never asked for the password.
> 
> After a night's sleep, I'll read up on bug reporting.
> I've never filed a bug report, any assistance welcome.
> Later - yawn ;/

It's always a good idea to do some research before submitting a bug
report. That would include reading the Debian documentation. Searches
with "debian mariadb-server password" and "debian mariadb-server
password bug" throw up some interesting links. They could help you to
decide whether your experience is worth reporting, Don't forget that
packages can legitimately change their behaviour and confound the
expectations of users.

#800009 has

  This issue is now fixed in 10.0.23-1 as the passwordless root
  account authenticated via unix socket is only used on fresh
  installs. Old installs will continue to use any root password
  previously set.

-- 
Brian.

[toc] | [prev] | [next] | [standalone]

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

On 05/12/2017 02:57 AM, Brian wrote:
> On Thu 11 May 2017 at 21:54:57 -0500, Richard Owlett wrote:
>
>> Working from purchased DVDs of Debian Stretch (8.6.0) I did a minimal
>> install (MATE desktop + standard utilities) to a fresh partition.
>> I then did
>>    apt-get install apache2
>>    apt-get install mariadb-server
>>
>> On completion of the later I was asked for a password for 'root' user. I
>> supplied it and was able to login. As a check I attempted to login with an
>> incorrect password and was blocked.
>>
>> I then followed the same procedure for Stretch using netinst
>> {Debian stretch-DI-rc3 i386 1}
>> I was never asked for the password.
>>
>> After a night's sleep, I'll read up on bug reporting.
>> I've never filed a bug report, any assistance welcome.
>> Later - yawn ;/
>
> It's always a good idea to do some research before submitting a bug
> report. That would include reading the Debian documentation. Searches
> with "debian mariadb-server password" and "debian mariadb-server
> password bug" throw up some interesting links. They could help you to
> decide whether your experience is worth reporting, Don't forget that
> packages can legitimately change their behaviour and confound the
> expectations of users.
>
> #800009 has
>
>   This issue is now fixed in 10.0.23-1 as the passwordless root
>   account authenticated via unix socket is only used on fresh
>   installs. Old installs will continue to use any root password
>   previously set.
>

Various searches do bring bring up interesting issues.
For potential bug reporters I recommend following chains of links from 
"BugTriage" <https://wiki.debian.org/BugTriage>.
I believe at least one bug was prematurely closed (was it properly 
defined in the first case).
The symptom described in #800009 still exists and it is unclear if its 
ramifications have been addressed adequately/correctly.
More reading ahead.

[toc] | [prev] | [next] | [standalone]

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

Richard Owlett wrote:

> On 05/12/2017 02:57 AM, Brian wrote:
>> On Thu 11 May 2017 at 21:54:57 -0500, Richard Owlett wrote:
>>
>>> Working from purchased DVDs of Debian Stretch (8.6.0) I did a minimal
>>> install (MATE desktop + standard utilities) to a fresh partition.
>>> I then did
>>>    apt-get install apache2
>>>    apt-get install mariadb-server
>>>
>>> On completion of the later I was asked for a password for 'root' user. I
>>> supplied it and was able to login. As a check I attempted to login with
>>> an incorrect password and was blocked.
>>>
>>> I then followed the same procedure for Stretch using netinst
>>> {Debian stretch-DI-rc3 i386 1}
>>> I was never asked for the password.
>>>
>>> After a night's sleep, I'll read up on bug reporting.
>>> I've never filed a bug report, any assistance welcome.
>>> Later - yawn ;/
>>
>> It's always a good idea to do some research before submitting a bug
>> report. That would include reading the Debian documentation. Searches
>> with "debian mariadb-server password" and "debian mariadb-server
>> password bug" throw up some interesting links. They could help you to
>> decide whether your experience is worth reporting, Don't forget that
>> packages can legitimately change their behaviour and confound the
>> expectations of users.
>>
>> #800009 has
>>
>>   This issue is now fixed in 10.0.23-1 as the passwordless root
>>   account authenticated via unix socket is only used on fresh
>>   installs. Old installs will continue to use any root password
>>   previously set.
>>
> 
> Various searches do bring bring up interesting issues.
> For potential bug reporters I recommend following chains of links from
> "BugTriage" <https://wiki.debian.org/BugTriage>.
> I believe at least one bug was prematurely closed (was it properly
> defined in the first case).
> The symptom described in #800009 still exists and it is unclear if its
> ramifications have been addressed adequately/correctly.
> More reading ahead.

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.

[toc] | [prev] | [next] | [standalone]

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

On 05/12/2017 12:40 PM, deloptes wrote:
> Richard Owlett wrote:
>
>> On 05/12/2017 02:57 AM, Brian wrote:
>>> On Thu 11 May 2017 at 21:54:57 -0500, Richard Owlett wrote:
>>>
>>>> Working from purchased DVDs of Debian Stretch (8.6.0) I did a minimal
>>>> install (MATE desktop + standard utilities) to a fresh partition.
>>>> I then did
>>>>    apt-get install apache2
>>>>    apt-get install mariadb-server
>>>>
>>>> On completion of the later I was asked for a password for 'root' user. I
>>>> supplied it and was able to login. As a check I attempted to login with
>>>> an incorrect password and was blocked.
>>>>
>>>> I then followed the same procedure for Stretch using netinst
>>>> {Debian stretch-DI-rc3 i386 1}
>>>> I was never asked for the password.
>>>>
>>>> After a night's sleep, I'll read up on bug reporting.
>>>> I've never filed a bug report, any assistance welcome.
>>>> Later - yawn ;/
>>>
>>> It's always a good idea to do some research before submitting a bug
>>> report. That would include reading the Debian documentation. Searches
>>> with "debian mariadb-server password" and "debian mariadb-server
>>> password bug" throw up some interesting links. They could help you to
>>> decide whether your experience is worth reporting, Don't forget that
>>> packages can legitimately change their behaviour and confound the
>>> expectations of users.
>>>
>>> #800009 has
>>>
>>>   This issue is now fixed in 10.0.23-1 as the passwordless root
>>>   account authenticated via unix socket is only used on fresh
>>>   installs. Old installs will continue to use any root password
>>>   previously set.
>>>
>>
>> Various searches do bring bring up interesting issues.
>> For potential bug reporters I recommend following chains of links from
>> "BugTriage" <https://wiki.debian.org/BugTriage>.
>> I believe at least one bug was prematurely closed (was it properly
>> defined in the first case).
>> The symptom described in #800009 still exists and it is unclear if its
>> ramifications have been addressed adequately/correctly.
>> More reading ahead.
>
> 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>

[toc] | [prev] | [next] | [standalone]

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

-----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?

Regards
- -- t
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlkWJIsACgkQBcgs9XrR2kashwCcD01oWSBeDkgj0SF0UAEQ3pjH
FoMAn1Az3PC6JJOwTmrfyU9TpKwovleL
=52BB
-----END PGP SIGNATURE-----

[toc] | [prev] | [next] | [standalone]

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

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.

[toc] | [prev] | [next] | [standalone]

#180980 — 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.

[toc] | [prev] | [next] | [standalone]

#180981 — 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:
>>> -----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.

[toc] | [prev] | [next] | [standalone]

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

Richard Owlett wrote:
...
> 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.

  FTR there are recent bugs which sound similar
and discussion on the development and release 
lists which talk about mariadb and the current
upgrade situation.

  once you live on the bleeding edge it is worth
it to check the package bug lists and others to
see what is happening.


  songbird

[toc] | [prev] | [next] | [standalone]

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

On 05/13/2017 10:58 AM, songbird wrote:
> Richard Owlett wrote:
> ...
>> 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.
>
>   FTR there are recent bugs which sound similar
> and discussion on the development and release
> lists which talk about mariadb and the current
> upgrade situation.

Were you thinking of something in addition to
debian-release, debian-devel, and debian-testing?


>
>   once you live on the bleeding edge it is worth
> it to check the package bug lists and others to
> see what is happening.

I'm not sure if I'm using BTS efficiently.

[toc] | [prev] | [next] | [standalone]

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

Richard Owlett wrote:
> songbird wrote:
...
>>   FTR there are recent bugs which sound similar
>> and discussion on the development and release
>> lists which talk about mariadb and the current
>> upgrade situation.
>
> Were you thinking of something in addition to
> debian-release, debian-devel, and debian-testing?

  mostly the first two, but there are also IRC 
channels and the bug tracking list itself.

  if i am running a particular desktop i try to 
follow whatever usenet groups the developers use
and or any mailing lists if they aren't echoed
by gmane.  plus: +
                 |
                 |
                \ /
                 v


>>   once you live on the bleeding edge it is worth
>> it to check the package bug lists and others to
>> see what is happening.
>
> I'm not sure if I'm using BTS efficiently.

  if i am working a lot with a particular package/
program i try to read through the bug reports that
are in there, along with checking the upstream
bug tracking to see what might be going on (if the
developers are active or what).

  in 99% of the cases i am only reading along as i
don't think i have sufficient expertise to comment.
mostly i take it as FYI so that i'm vaguely aware
of what is going on.  but then again for fun i also
skim at least one linux kernel list.  :)


  songbird

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web