Recent posts have culminated in my not being able to remedy a corruption in the user table.
I decided to remove MySQL and reinstall.
First I did:
$ sudo apt purge mysql*
$ sudo apt autoremove
$ sudo apt update
When I reinstalled, the corrupt user table was still there.
I tried again from Synaptic.
Same result.
How can I resolve this?
Other option is uninstall again, delete the database and see if pkg install recreates it.
Recent posts have culminated in my not being able to remedy a corruption in the user table.
I decided to remove MySQL and reinstall.
When I reinstalled, the corrupt user table was still there.
On 17.01.2022 12:48, pinnerite wrote:
Recent posts have culminated in my not being able to remedy a corruption in the user table.
I decided to remove MySQL and reinstall.
This is not Windows. Your cannot solve problems by reinstalling software. Or rebooting your computer.
When I reinstalled, the corrupt user table was still there.
Because the data directory is not auto-removed. This is for safety. A fresh datadir is only created if none exists.
Now: what "corruption" do you have in the `user` table? Keep in mind that
you should not operate on the user table with UPDATE and DELETE statements. There are dedicated CREATE user and DROP user statements. Read the manual on "Access Control and Account Management"
At the moment I can only get int MySQL from a root prompt.
Otherwise it asks for the root password which I have not set(?).
On 17.01.2022 17:57, pinnerite wrote:
At the moment I can only get int MySQL from a root prompt.
Otherwise it asks for the root password which I have not set(?).
This is on purpose. Again: RTFM!
Read also the Debian README. Package maintainers often add extra $FOO to packages. In the past Debian used to ask for a password for account name 'root' (which is traditionally the Superuser account). Now this is no longer neccessary because socket authentication helps with identification of users.
Normally the first thing you do is create an account for yourself. If you
are connecting remotely (that means: the client is not running on the same machines than the server) it includes setting a password.
And if you are running an application using the database (i.e. MythTV) then it's highly recommended to create a MySQL account that is restricted to the tables for that application.
XL
I appreciate you taking the trouble to reply in detail but you must understand thast I am not a regular user of MySQL and have only ever used it when employing MythTV.
On 18.01.2022 13:48, pinnerite wrote:
I appreciate you taking the trouble to reply in detail but you must understand thast I am not a regular user of MySQL and have only ever used it when employing MythTV.
Then let's take a step back. Something must have been broken so that you started digging into MySQL accounts. What was it? Perhaps a broken (or at least not up-to-date) mythtv package?
That's the whole point of having packages and maintainers. But of course
they need to know something is broken before they can act.
On Tue, 18 Jan 2022 10:44:47 +0100
Axel Schwenke <axel.schwenke@gmx.de> wrote:
On 17.01.2022 17:57, pinnerite wrote:
At the moment I can only get int MySQL from a root prompt.
Otherwise it asks for the root password which I have not set(?).
This is on purpose. Again: RTFM!
Read also the Debian README. Package maintainers often add extra $FOO to
packages. In the past Debian used to ask for a password for account name
'root' (which is traditionally the Superuser account). Now this is no longer >> neccessary because socket authentication helps with identification of users. >>
Normally the first thing you do is create an account for yourself. If you
are connecting remotely (that means: the client is not running on the same >> machines than the server) it includes setting a password.
And if you are running an application using the database (i.e. MythTV) then >> it's highly recommended to create a MySQL account that is restricted to the >> tables for that application.
XL
I appreciate you taking the trouble to reply in detail but you must understand thast I am not a regular user of MySQL and have only ever used it when employing MythTV.
This means that I only have to engage with it once every two or three years. Although I have textbooks on the subject, they are all obsolete because of the changes that are made between versions.
Changing distros can even mean having to deploy MariaDB, which I did for a few years.
Although I try to resolve my problems without recourse to bothering others, there comes a point when frustration takes over. I had reached that point.
If i had known where the database was held (/var/lib/mysql) earlier, I might have saved myself and others some trouble.
I always record the process of overcoming problems and the related advice in the hope of not making the same mistake more than once but sadly, the ground shifts. It is never exactly the same.
Thanks again, Alan
On 1/18/2022 7:48 AM, pinnerite wrote:
On Tue, 18 Jan 2022 10:44:47 +0100
Axel Schwenke <axel.schwenke@gmx.de> wrote:
On 17.01.2022 17:57, pinnerite wrote:
At the moment I can only get int MySQL from a root prompt.
Otherwise it asks for the root password which I have not set(?).
This is on purpose. Again: RTFM!
Read also the Debian README. Package maintainers often add extra
$FOO to packages. In the past Debian used to ask for a password for
account name 'root' (which is traditionally the Superuser account).
Now this is no longer neccessary because socket authentication helps
with identification of users.
Normally the first thing you do is create an account for yourself.
If you are connecting remotely (that means: the client is not
running on the same machines than the server) it includes setting a
password.
And if you are running an application using the database (i.e.
MythTV) then it's highly recommended to create a MySQL account that
is restricted to the tables for that application.
XL
I appreciate you taking the trouble to reply in detail but you must
understand thast I am not a regular user of MySQL and have only ever
used it when employing MythTV.
This means that I only have to engage with it once every two or three
years. Although I have textbooks on the subject, they are all
obsolete because of the changes that are made between versions.
Changing distros can even mean having to deploy MariaDB, which I did
for a few years.
Although I try to resolve my problems without recourse to bothering
others, there comes a point when frustration takes over. I had
reached that point.
If i had known where the database was held (/var/lib/mysql) earlier,
I might have saved myself and others some trouble.
I always record the process of overcoming problems and the related
advice in the hope of not making the same mistake more than once but
sadly, the ground shifts. It is never exactly the same.
Thanks again, Alan
Alan,
All of the answers to your questions are in the documentation. It's
quite extensive and complete.
But that's like saying all of the words in the English Language are in
the Oxford English Dictionary. They are - but good luck finding the
right word if you don't know what you're looking for.
Axel Schwenke <axel.schwenke@gmx.de> wrote:
Then let's take a step back. Something must have been broken so that you
started digging into MySQL accounts. What was it? Perhaps a broken (or at
least not up-to-date) mythtv package?
This is the User table prior to wiping out an starting again.. +------------------+------------------------------------------------------------------------+-----------+
| User | authentication_string | Host |
+------------------+------------------------------------------------------------------------+-----------+
| mythtv | *B5BCD029F2268798922CDC55B5253D354B2C0246 | % |
| debian-sys-maint | $A$005$F5%d'zoHMtJEX88t/x1bvIEMnwtseub5Tc7Z02gRpckab8.tZPnvPL5 | localhost |
| mysql.infoschema | $A$005$THISISACOMBINATIONOFINVALIDSALTANDPASSWORDTHATMUSTNEVERBRBEUSED | localhost |
| mysql.session | $A$005$THISISACOMBINATIONOFINVALIDSALTANDPASSWORDTHATMUSTNEVERBRBEUSED | localhost |
| mysql.sys | $A$005$THISISACOMBINATIONOFINVALIDSALTANDPASSWORDTHATMUSTNEVERBRBEUSED | localhost |
!ug2Ym[S%/K+ca2n7M06VWGOgOzJFxxKkrg/c7pjNT6Dm3n3FzLXm56 | localhost |
| root | *2B2E29BFA4C432ED2C7C49E07B175220796B98EE | localhost |
+------------------+------------------------------------------------------------------------+-----------+
Nothing I could do would change the erroneous hashed mythtv password nor could I remove the penultimate row with seemingly no user.
TLDR :-)-O
AKA Generation Z :-)-O
el
On 18/01/2022 22:49, Jerry Stuckle wrote:
Alan,
All of the answers to your questions are in the documentation. It's
quite extensive and complete.
But that's like saying all of the words in the English Language are in
the Oxford English Dictionary. They are - but good luck finding the
right word if you don't know what you're looking for.
On 18.01.2022 17:40, pinnerite wrote:
Axel Schwenke <axel.schwenke@gmx.de> wrote:
Then let's take a step back. Something must have been broken so that you >> started digging into MySQL accounts. What was it? Perhaps a broken (or at >> least not up-to-date) mythtv package?
This is the User table prior to wiping out an starting again.. +------------------+------------------------------------------------------------------------+-----------+
| User | authentication_string | Host |
+------------------+------------------------------------------------------------------------+-----------+
| mythtv | *B5BCD029F2268798922CDC55B5253D354B2C0246 | % |
| debian-sys-maint | $A$005$F5%d'zoHMtJEX88t/x1bvIEMnwtseub5Tc7Z02gRpckab8.tZPnvPL5 | localhost |
| mysql.infoschema | $A$005$THISISACOMBINATIONOFINVALIDSALTANDPASSWORDTHATMUSTNEVERBRBEUSED | localhost |
| mysql.session | $A$005$THISISACOMBINATIONOFINVALIDSALTANDPASSWORDTHATMUSTNEVERBRBEUSED | localhost |
| mysql.sys | $A$005$THISISACOMBINATIONOFINVALIDSALTANDPASSWORDTHATMUSTNEVERBRBEUSED | localhost |
!ug2Ym[S%/K+ca2n7M06VWGOgOzJFxxKkrg/c7pjNT6Dm3n3FzLXm56 | localhost |
| root | *2B2E29BFA4C432ED2C7C49E07B175220796B98EE | localhost |
+------------------+------------------------------------------------------------------------+-----------+
I see nothing wrong here.
Nothing I could do would change the erroneous hashed mythtv password nor could I remove the penultimate row with seemingly no user.
I see no row with no user. I see garbled output for whatever reason. What reports SHOW GRANTS ? And the hash for the 'mythtv' user looks ok. And it would be a trifle so set it to something else with CHANGE PASSWORD ...
So you are basically complaining about *nothing*. Or - to be more precise - about things that you don't understand and believe to be erroneous.
<shrug>
XL
On 1/19/2022 5:29 AM, Dr Eberhard Lisse wrote:
TLDR :-)-O
AKA Generation Z :-)-O
el
On 18/01/2022 22:49, Jerry Stuckle wrote:
Alan,
All of the answers to your questions are in the documentation. It's
quite extensive and complete.
But that's like saying all of the words in the English Language are
in the Oxford English Dictionary. They are - but good luck finding
the right word if you don't know what you're looking for.
Two short paragraphs are too long? ROFLMAO!
And please learn to follow Usenet posting guidelines - which include
posting your response either inline with the comments or following the comments (like this one) - not at the top of the page.
On Wed, 19 Jan 2022 17:43:45 +0100
Axel Schwenke <axel.schwenke@gmx.de> wrote:
I see no row with no user. I see garbled output for whatever reason. What
reports SHOW GRANTS ? And the hash for the 'mythtv' user looks ok. And it
would be a trifle so set it to something else with CHANGE PASSWORD ...
So you are basically complaining about *nothing*. Or - to be more precise - >> about things that you don't understand and believe to be erroneous.
So you know that the hash for 'mythtv' looks OK. It just happens to be the wrong hash.
I could not change it to the correct one.
So what is the user for: > > !ug2Ym[S%/K+ca2n7M06VWGOgOzJFxxKkrg/c7pjNT6Dm3n3FzLXm56 | localhost | ?
That would make it even more difficult for the Generation Z'ers.
el
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 296 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 50:33:36 |
| Calls: | 6,649 |
| Calls today: | 1 |
| Files: | 12,200 |
| Messages: | 5,330,212 |