Op 13-10-2022 om 14:08 schreef Reindl Harald:
Am 13.10.22 um 13:55 schrieb Jogchum Reitsma:
Op 13-10-2022 om 12:59 schreef Reindl Harald:
All files and dir's under /home/jogchum/mysql_recover have mysql:mysql as owner:group
and your userhome is 755
which is the default, when opensuse creates a new user. So, if I understand you right, that's wrong in your opinion?
plain wrong but i don#t even know the default of my Fedora machines given that the last time i saw an os-installer was in 2011 thanks to RAID and backups
Well, not only on (re-)install, but also when you create a new user via Yast, the default is 755.
as well as systemd namespaces and SELinux allowing nosense like storing the databasedir in a userhome?
Why is that nonsense? After all, it's not a company database we're talking about, just
and how does that justify doing something different than anybody else out there?
I don't think I have to justify that here, after all, it sits some 25 years on the place it is now (which is *not* /home/jogchum/mysql_recover, I explain that below). Never was a problem.
- some addresses of friends and family, mainly used for sending Christmas cards, - some metadata about video's I recorded, - some data about the yield of our solar panels.
Nothing secret in that.
i wonder if the friends see that this relaxed too, in europe there is more undestanding of privacy and data security as in the USA...
Yes, and in the Netherlands even more than in some other EU-countries.But to read it for others than me, my wife and son, one should hack one's way into my system. Which is not impossible, of course, but tin that case I think the damage will be more than a few addresses being read.
just don't do that - and be it only because it's dumb set your userhome to chmod 755 which means any 644 file can be read by anyone
As said, I did not chmod it to 755, it's the opensuse default (and maybe other distro's too, dunno). And anyone in my family is allowed to read anything on our systems.
More important, you don't say anything about how I could start the database?
dunno but this part of the logs is looking bad - on a updated machine that mustnt't have started at all and indicates for me the damage was that large that your installation looked like a fresh one
okt 02 21:26:55 linux-mkay mysql-systemd-helper[45372]: Creating MySQL privilege database... okt 02 21:27:17 linux-mkay mysql-systemd-helper[45384]: Two all-privilege accounts were created. okt 02 21:27:17 linux-mkay mysql-systemd-helper[45384]: One is root@localhost, it has no password, but you need to okt 02 21:27:17 linux-mkay mysql-systemd-helper[45384]: be system 'root' user to connect. Use, for example, sudo mysql okt 02 21:27:17 linux-mkay mysql-systemd-helper[45384]: The second is mysql@localhost, it has no password either, but okt 02 21:27:17 linux-mkay mysql-systemd-helper[45384]: you need to be the system 'mysql' user to connect.
Yes, it was a fresh installation, because I gave a new location, /home/jogchum/mysql_recover, before starting the db. As said in my first post, this was a solution that worked for someone with the same problem: roughly: - change the location of the db in /etc/my.cnf - start the database server, which will create the default environment in the new location - copy the existing database files to that new locatioN - restart the database server. In my case, this recipe fails in the second step: the new location is populated, but the server crashes immediately. Journalctl show only a warning regarding not being able to create a test file: Warning] Can't create test file /home/jogchum/mysql_recover/linux-mkay.lower-test which, according to Sergei, should not be a cause for the server to crash.And ideed, it's only a warning, no error. So, it still is a riddle why the server won't start. regards, Jogchum
_______________________________________________ Mailing list: https://launchpad.net/~maria-discuss Post to : maria-discuss@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-discuss More help : https://help.launchpad.net/ListHelp