staging.inyokaproject.org

Hallo,

Baustelle ist eingerichtet.

Ist glaube ich tatsächlich angebracht, da wir ja auch noch 3 unterstützte LTS-Versionen haben, für die der Artikel passen muss.

Nee. Trusty ist bald EOL, das kannst du direkt aus dem Artikel entfernen.

Ob du den Artikel "nur" für Xenial oder für Xenial + Bionic testest liegt bei dir. Schön wäre beides, aber das ist kein Muss.

Gruß, noisefloor

Wenn, dann würde ich das direkt für Xenial und Bionic machen. Das wird dadurch erleichtert, dass beide Versionen noch den gleichen MySQL-Versions-Stamm ausliefern. Ich habe aber noch eine Verständnisfrage zum Abschnitt Baustelle/MySQL (Abschnitt „Kein-Login-als-root“):

Ursprung für diesen Abschnitt waren folgende Foren-Post von Fiodin:

• https://forum.ubuntuusers.de/post/8930928/

• https://forum.ubuntuusers.de/post/8931175/

• https://forum.ubuntuusers.de/post/8931640/

Dabei wird unter anderem auf diesen Artikel verwiesen, in dem es als Problem dargestellt wird wenn das root-Authentifizierungs-Plugin von auth_socket auf mysql_native_password umgestellt wird, weil das MySQL-Init-Script /etc/init.d/mysql einen Zugriff auf mysqladmin ohne Passwort-Eingabe voraussetzt. Und während der letzte Teil durchaus stimmt (das Script benutzt mysqladmin ohne Passwort) so sehe ich doch in meinen Test-VMs (sowohl Bionic als auch Xenial) derzeit keine Probleme beim Starten oder Stoppen des Dienstes oder beim Ubuntu-Neustart obwohl jeweils ein MySQL-root-Login nur mit Passwort möglich ist.

Wann genau wird dieses Script wofür benutzt? Was sind das für Fälle, in denen es Probleme gibt (evtl. bei Updates/Upgrades)? Soll ich diesen Abschnitt ggfs. erstmal rausnehmen bis dazu jemand einen konkreten Fall aufzeigen kann? Ich persönlich halte das Anlegen eines zweiten root-Nutzers auf jeden Fall für überflüssig und würde da gerne drauf verzichten.

Hallo,

Soll ich diesen Abschnitt ggfs. erstmal rausnehmen bis dazu jemand einen konkreten Fall aufzeigen kann?

Alles, was in Tests nicht mehr nachvollziehbar ist bzw. so mit an Sicherheit grenzender Wahrscheinlichkeit nicht mehr stimmt bzw. veraltet ist, darf raus.

Das Wiki ist ja so wie so voll revisioniert, d.h. wir können jederzeit jede alte Version des Artikels aufrufen.

Gruß, noisefloor

Hallo, ich bin mir nicht sicher, ob ich alle deine Fragen richtig verstanden habe und versuche mal mit meinem gefährlichen Halbwissen etwas zu unterstützen.

Hoerbert schrieb:

weil das MySQL-Init-Script /etc/init.d/mysql einen Zugriff auf mysqladmin ohne Passwort-Eingabe voraussetzt. Und während der letzte Teil durchaus stimmt (das Script benutzt mysqladmin ohne Passwort) so sehe ich doch in meinen Test-VMs (sowohl Bionic als auch Xenial) derzeit keine Probleme beim Starten oder Stoppen des Dienstes oder beim Ubuntu-Neustart obwohl jeweils ein MySQL-root-Login nur mit Passwort möglich ist.

Wann genau wird dieses Script wofür benutzt? Was sind das für Fälle, in denen es Probleme gibt (evtl. bei Updates/Upgrades)? Soll ich diesen Abschnitt ggfs. erstmal rausnehmen bis dazu jemand einen konkreten Fall aufzeigen kann? Ich persönlich halte das Anlegen eines zweiten root-Nutzers auf jeden Fall für überflüssig und würde da gerne drauf verzichten.

Welches Skript meinst du?

/etc/init.d/mysql ?

Siehe Dienste . (Da wird auch klar, dass man nicht unbedingt zwischen service und systemctl unterscheiden muss, aber kann.

BillMaier schrieb:

Welches Skript meinst du?

/etc/init.d/mysql ?

Ja, genau. OK, dann werden diese init-Scripts also von SysVint verwendet. Hier zeigt sich dann auch, dass ich von den alten Init-Systemen zu wenig Ahnung habe…

Und jetzt habe ich Gewissheit: Selbst diese init-Scripte benutzen intern systemctl, weshalb also tatsächlich die Aufrufe von mysqladmin komplett irrelevant sind.

Abwärtskompatibilität mag ja hier und da sehr praktisch sein. Aber es macht Dinge teilweise auch unnötig komplex…

Hoerbert schrieb:

Und jetzt habe ich Gewissheit: Selbst diese init-Scripte benutzen intern systemctl, weshalb also tatsächlich die Aufrufe von mysqladmin komplett irrelevant sind.

Ne, es ist umgekehrt. Zeig mal

#vorlage Befehl
systemctl status mysql

Wenn da ein init-Skript benutzt wird (statt einer systemd-Unit) steht das dran.

Gruß BillMaier

BillMaier schrieb:

Hoerbert schrieb:

Und jetzt habe ich Gewissheit: Selbst diese init-Scripte benutzen intern systemctl, weshalb also tatsächlich die Aufrufe von mysqladmin komplett irrelevant sind.

Ne, es ist umgekehrt. […] Wenn da ein init-Skript benutzt wird (statt einer systemd-Unit) steht das dran.

Evtl. gibt es hier ein Missverständnis? Ich wollte vor allem sagen, dass selbst bei einem manuellen Aufruf des Scripts /etc/init.d/mysql der Dienst per systemctl gestartet bzw. gestoppt wird. Und deshalb sind die mysqladmin-Aufrufe in den Scripts irrelevant, da das Ganze im Endeffekt doch irgendwie über systemd abgewickelt wird.

Mir ist schon klar, dass der MySQL-Dienst primär eine systemd-Unit ist.

hoerbert@xenial:~$ systemctl status mysql
● mysql.service - MySQL Community Server
   Loaded: loaded (/lib/systemd/system/mysql.service; enabled; vendor preset: enabled)
   Active: active (running) since Di 2019-01-08 16:18:44 CET; 18s ago
  Process: 1022 ExecStartPost=/usr/share/mysql/mysql-systemd-start post (code=exited, status=0/SUCCESS)
  Process: 936 ExecStartPre=/usr/share/mysql/mysql-systemd-start pre (code=exited, status=0/SUCCESS)
 Main PID: 1021 (mysqld)
    Tasks: 28
   Memory: 155.0M
      CPU: 439ms
   CGroup: /system.slice/mysql.service
           └─1021 /usr/sbin/mysqld

Jan 08 16:18:40 xenial systemd[1]: Starting MySQL Community Server...
Jan 08 16:18:44 xenial systemd[1]: Started MySQL Community Server.

Hoerbert schrieb:

Evtl. gibt es hier ein Missverständnis?

Möglich.

Ich wollte vor allem sagen, dass selbst bei einem manuellen Aufruf des Scripts /etc/init.d/mysql der Dienst per systemctl gestartet bzw. gestoppt wird.

Dann ist das hier tatsächlich umgekehrt. Ich kenne es nur andersrum von anderen Diensten, dass systemd auf init-Skripte zurückgreift. (Ich kann es hier gerade nicht testen, weil ich keine MySQL-Instanz da hab)

Mir ist schon klar, dass der MySQL-Dienst primär eine systemd-Unit ist.

Das hatte ich in Frage gestellt, es hätte auch ein init-Skript dahinter hängen können. Aber ok, dann ist das hier so.

Gruß BillMaier

//edit: Dann muss im Artikel IMHO auch keine Rücksicht mehr auf die init-Skripte genommen werden.

Hallo,

Dann muss im Artikel IMHO auch keine Rücksicht mehr auf die init-Skripte genommen werden.

So isses.

Gruß, noisefloor

OK, ich bin hiermit nun soweit zufrieden. Mag noch mal jemand auf Formalitäten/Rechtschreibung gegenchecken?

Gruß

Torben

Hallo,

ist IMHO ok. Habe noch den Hinweis rausgenommen, dass das Metapaket immer die "aktuelle Version" installiert. Es ´kommt nämlich - mit Ausnahme von 14.04 - MySQL 5.7 auf die Platte. Aktuell ist aber 8.x.

Gruß, noisefloor

Mit "aktuell" meinte ich "die in der aktuellen Ubuntu-Version vorliegende Version". Sollte halt nur ein Hinweis sein, dass nicht manuell bspw. mysql-server-5.7 installiert wird, da dann bei einem Dist-Upgrade eventuell nicht aktualisiert wird.

Wenn ihr meint, dass das ohne geht, soll mir das aber auch Recht sein.

Torben

Hallo,

sowas hatte ich vermutet - nur war die Formulierung halt aktuell irreführend, weil alle Ubuntus 5.7 in den Quellen haben, spricht versionstechnisch erfolgt kein Upgrade.

Gruß, noisefloor

Hallo,

keine weitere Anmerkungen von irgendwo, Artikel ist wieder im Wiki. Danke für die Überarbeitung.

Gruß, noisefloor

Moin, ich baue gerade (als absoluter Server-Anfänger) eine Nextcloud auf Ubuntu 20.04 Server.

Dabei fiel tauchte bei Befolgen von MySQL (Abschnitt „Datenbank-erstellen“) folgende Fehlermeldung auf (das Passwort ist natürlich nicht "geheim") 😉 :

1
2

mysql> grant usage on *.* to 'www-data'@'localhost' identified by 'geheim';
ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'identified by 'geheim'' at line 1

Erfolgreich war dann:

1
2

mysql> grant usage on *.* to 'www-data'@'localhost';
Query OK, 0 rows affected (0.33 sec)

Jedenfalls soweit ich das beurteilen kann, da ich noch nicht bis zur Nextcloud-Installation vorgedrungen bin und daher nicht weiß, ob die Datenbank wirklich funktionieren wird.

Kann das jemand nachvollziehen und sollte die Anleitung entsprechend angepasst werden?