[erledigt]: DB-Problem unter 13.1

schnuddel55 · 29 Okt. 2013

einige werden den Drang verspüren mich zu steinigen ...

dieses Mal komme ich unter openSUSE 13.1 auf meinem Lappi nicht weiter:
habe den LAMP-Stack installiert und kriege keine Verbindung zu mariadb.

Es sieht okay aus:

Code:

stefan@linux-se6r:~> which mysql
/usr/bin/mysql
stefan@linux-se6r:~> mysql --version
mysql  Ver 15.1 Distrib 5.5.33-MariaDB, for Linux (i686) using readline 5.1
stefan@linux-se6r:~>

Wenn ich versuche, ein Passwort für den Server zu vergeben kommt folgendes:

Code:

stefan@linux-se6r:~> su
Passwort: 
linux-se6r:/home/stefan # mysqladmin password xxxxxx.yyyyyyy
mysqladmin: connect to server at 'localhost' failed
error: 'Can't connect to local MySQL server through socket '/var/run/mysql/mysql.sock' (2)'
Check that mysqld is running and that the socket: '/var/run/mysql/mysql.sock' exists!
linux-se6r:/home/stefan #

Ist ja eingtl. auch logisch - der socket ist ja wirklich nicht da, weil ja auch kein mysql installiert ist ...

Wieder mal kleine Ursache und keine Lösung in Sicht.

stef

spoensche · 29 Okt. 2013

Hast du die Systemtabellen installiert? (mysql_install_db) Starte mal den Server und führe mysqladmin danach erneut aus.

schnuddel55 · 29 Okt. 2013

spoensche schrieb:
Hast du die Systemtabellen installiert? (mysql_install_db) Starte mal den Server und führe mysqladmin danach erneut aus.

Systemtabellen sind installiert, aber den Server starten kann ich nicht - siehe Meldung wg Passwort-Vergabe im ersten Posting.

stef

komma4 · 30 Okt. 2013

Hatte das Problem auch, Prozess lief, aber keine Passwort-Vergabe auf CLI

Lösung:

Prozess gekillt.
Neu gestartet

Code:

/etc/init.d/mysql start

Danach ging auch mysqladmin password wieder

Code:

USER@RECHNER:~> mysqladmin password 
New password: 
Confirm new password: 
USER@RECHNER:~>

Viel Erfolg!

schnuddel55 · 30 Okt. 2013

komma4 schrieb:
Hatte das Problem auch, Prozess lief, aber keine Passwort-Vergabe auf CLI

Lösung:

Prozess gekillt.
Neu gestartet

Code:

/etc/init.d/mysql start

Danach ging auch mysqladmin password wieder

Code:

USER@RECHNER:~> mysqladmin password New password: Confirm new password: USER@RECHNER:~>

Viel Erfolg!

Bei mir läuft aber kein Process, den ich killen könnte (mysql) - siehe erster Post.
Angeblich funzt mariadb problemlos, aber ich habe seit mariadb NUR Probleme.
Ich bin kurz davor, mir den Stack wieder wie früher aus den einzelnen Komponenten zusammen zu bauen, und zwar mit mySQL und NICHT mit mariadb, auch wenn es ein Rückschritt sein sollte ...

stef

gehrke · 30 Okt. 2013

Bist Du sicher, dass der Daemon auch wirklich läuft (mysqld, nicht mysql)?

schnuddel55 · 30 Okt. 2013

gehrke schrieb:
Bist Du sicher, dass der Daemon auch wirklich läuft (mysqld, nicht mysql)?

Nein, weder noch.
Ich hoffe mal, daß es ein noch nicht behobener Bug ist; 13.1 ist ja noch RC.
So was möchte ich bei einem neu installierten Produktivsystem nicht erleben.

stef

komma4 · 31 Okt. 2013

Hatte das schon gelesen, dass bei Dir nix läuft :roll:

Bei mir läuft die MariaDB 5.5.33 als drop-in replacement (nach der Anleitung auf ihrer Website) momentan noch ohne Auffälligkeiten...

Die Passwort-Vergabe funktioniert nur, wenn der Server läuft.

Starte ihn mal.
Hast Du dann den Socket? (der ist natürlich auch bei MariaDB vorhanden - wenn der Server läuft)

Code:

USER@RECHNER:/etc> cat /etc/my.cnf | grep socket
socket          = /var/run/mysql/mysql.sock

Code:

USER@RECHNER:/etc> ls -l /var/run/mysql/mysql.sock 
srwxrwxrwx 1 mysql mysql 0 29. Okt 07:17 /var/run/mysql/mysql.sock

gehrke · 31 Okt. 2013

schnuddel55 schrieb:
gehrke schrieb:

Bist Du sicher, dass der Daemon auch wirklich läuft (mysqld, nicht mysql)?

Zum Vergrößern anklicken....

Nein, weder noch.

Starte bitte den Daemon und poste die Meldungen in den Logs.

schnuddel55 · 31 Okt. 2013

Danke an alle -
bevor eure in Zukunft sicher mal sehr hilfreichen Tips/Antworten kamen, hatte ich schon den Stack neu installiert und die beschriebenen Probs sind gelöst.

Nun stehe ich vor einem neuen Problem:
wenn ich den phpMyAdmin aufrufe, kommt die Fehlermeldung "Zugriff verweigert" "Error 403".
Alle Verzeichnisse/Dateien in "htdocs" gehören root, aber auch eine Änderung des Eigentümers per chown brachte nichts.
Himmiherrgottsakramentzefix ...
Es scheint daran zu liegen, daß php nicht korrekt installiert ist - andere php-Dateien funzen auch nicht ...

stef

komma4 · 31 Okt. 2013

phpmyadmin.conf?
Wie -genau- rufst Du auf?
Fehlermeldung ist "nur" 403?

schnuddel55 · 31 Okt. 2013

komma4 schrieb:
phpmyadmin.conf?
Wie -genau- rufst Du auf?
Fehlermeldung ist "nur" 403?

natürlich im Browser "localhost/phpMyAdmin/ mit oder ohne slash.
Ja, "nur" 403 - deswegen meine Vermutung, daß es an php liegt ...

stef

komma4 · 1 Nov. 2013

Der Blick in meine Glaskugel sagt mir:

Du hast in der /etc/apache2/conf.d/phpmyadmin.conf ein Order allow, deny in der Anweisung stehen, die das Verzeichnis beschreibt:

Code:

<Directory /srv/www/htdocs/phpMyAdmin>
  Options FollowSymLinks
  Order Allow,Deny
  AllowOverride None
...

Lösche die Zeile und starte Apache neu.

Hilft das?

schnuddel55 · 1 Nov. 2013

@ komma4:

nein, hilft nicht ...

Ich bin echt ratlos - hier auf dem Laptop (13.1) habe ich die absolut identische Konfiguration wie auf dem PC (12.2) aber die 13.1 verhält sich (auch was das Netzwerk angeht) völlig anders.
Da traue ich mich ja kaum, in 4 Wochen 13.1 als Produktivsystem zu installieren ...

stef

komma4 · 2 Nov. 2013

schnuddel55 schrieb:
nein, hilft nicht ...

Das ist schade.

Wobei ich die Aussage

schnuddel55 schrieb:
absolut identische Konfiguration

anzweifel.

Ich habe auf einem Testsystem ein Update von 11.3 auf 12.3 durchgeführt, dann MySQL durch MariaDB ersetzt - und zuerst auch die "403"-Meldung erhalten.

Die kommt auf jeden Fall vom Apachen - nicht von Maria oder OS. Bei der Überprüfung der Sicherheitseinstellungen habe ich dann einzelne relevanten Zeilen geändert und irgendwann die oben Zeile rausgenommen... dann ging's.

Also step-by-step: erstmal alles erlauben, dann wieder sichern.

Viel Erfolg!

schnuddel55 · 3 Nov. 2013

@ komma4:

trotzdem - danke.
Du hast recht - es liegt wohl definitiv nicht an maria oder dem OS an sich.
Was mich stutzig macht:
es wird KEINE auf "localhost" liegende php-Datei geöffnet - der Server weiß also nicht, was er damit tun soll ...
Das ist mir noch nie passiert ... :???:

stef

komma4 · 3 Nov. 2013

schnuddel55 schrieb:
der Server weiß also nicht, was er damit tun soll ...

Der weiss das schon, nur erlaubst Du das Öffnen nicht => 403 => Sicherheitseinstellungen des Apachen prüfen

Bei meinem Update war es nur phpMyAdmin, andere lokale php-Seiten gingen.

schnuddel55 · 3 Nov. 2013

komma4 schrieb:
schnuddel55 schrieb:

der Server weiß also nicht, was er damit tun soll ...

Zum Vergrößern anklicken....

Der weiss das schon, nur erlaubst Du das Öffnen nicht => 403 => Sicherheitseinstellungen des Apachen prüfen

Bei meinem Update war es nur phpMyAdmin, andere lokale php-Seiten gingen.

Bei mir funzt KEINE locale php-site, angefangen bei "phpinfo.php". Jeder Aufruf einer localen *.php resultiert in einem "wollen sie die datei öffnen oder speichern?".
Wie prüfe ich die Sicherheitseinstellungen des Indianers?

stef

komma4 · 4 Nov. 2013

schnuddel55 schrieb:
Jeder Aufruf einer localen *.php resultiert in einem "wollen sie die datei öffnen oder speichern?"

Das hört sich aber an als ob Du einen Dateibrowser zum Aufruf verwendest.
Du nutzt schon einen Internetbrowser und rufst

Code:

http://localhost/phpinfo.php

?

Zum (Ab-)Sichern des Apachen gibt es gute Tutorien im Netz...

panamajo · 4 Nov. 2013

schnuddel55 schrieb:
Der weiss das schon, nur erlaubst Du das Öffnen nicht => 403 => Sicherheitseinstellungen des Apachen prüfen

Ein 403 bedeutet "Forbidden". Meistens fehlt einfach die DirectoryIndex Angabe (in /etc/apache2/default-server.conf, aber s.u.) mit der man dem Apache ansagt welche Datei angezeigt werden soll wenn die URL keinen Dateinamen enthält.

schnuddel55 schrieb:
Jeder Aufruf einer localen *.php resultiert in einem "wollen sie die datei öffnen oder speichern?".
Wie prüfe ich die Sicherheitseinstellungen des Indianers?

Die Konfiguration auf allen Ebenen lässt sich - wenn konfiguriert - üblicherweise per mod_info als http://hostname/server-info abfragen.

Ich weiss nicht wie das bei 13.1 gelöst ist, aber bei 12.* ist es so dass die Konfiguration in /etc/sysconfig/apache2 die Apache Konfigurationsdateien in /etc/apache2 tlw. überschreibt, eben die genannte default-server.conf).

Ich würde zuerst mal nachsehen ob mod_php5 überhaupt geladen wird (/etc/apache2/sysconfig.d/loadmodule.conf).

[erledigt]: DB-Problem unter 13.1

Member

Moderator

Member

Member

Member

Administrator

Member

Member

Administrator

Member

Member

Member

Member

Member

Member

Member

Member

Member

Member

Guru