maria-discuss team mailing list archive
Mailing list archive
Re: Maria-db refuses to start
Op 13-10-2022 om 14:08 schreef Reindl Harald:
Well, not only on (re-)install, but also when you create a new user via
Yast, the default is 755.
Am 13.10.22 um 13:55 schrieb Jogchum Reitsma:
Op 13-10-2022 om 12:59 schreef Reindl Harald:
which is the default, when opensuse creates a new user. So, if I
understand you right, that's wrong in your opinion?
All files and dir's under /home/jogchum/mysql_recover have
mysql:mysql as owner:group
and your userhome is 755
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
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.
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
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.
- some addresses of friends and family, mainly used for sending
- 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...
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
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: Creating MySQL
okt 02 21:27:17 linux-mkay mysql-systemd-helper: Two
all-privilege accounts were created.
okt 02 21:27:17 linux-mkay mysql-systemd-helper: One is
root@localhost, it has no password, but you need to
okt 02 21:27:17 linux-mkay mysql-systemd-helper: be system
'root' user to connect. Use, for example, sudo mysql
okt 02 21:27:17 linux-mkay mysql-systemd-helper: The second is
mysql@localhost, it has no password either, but
okt 02 21:27:17 linux-mkay mysql-systemd-helper: 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:
- 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
Warning] Can't create test file
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.
Mailing list: https://launchpad.net/~maria-discuss
Post to : maria-discuss@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~maria-discuss
More help : https://help.launchpad.net/ListHelp