Freitag, 1. Juli 2011

openSuSE 11.4 Upgrade

Ich musste nach längerer Zeit leider mal wieder Hand anlegen, weil ich openSuSE von 11.2 auf 11.4 upgraden musste.

Hier die Probleme in Stichworten:

  • hängt beim Booten in 05-kms.sh
    noapic muss in GRUB gesetzt werden
  • VNC
    • Clipboard geht nicht mehr
    • Tastatur - einige Tasten gehen nicht mehr ("+/", ..)
  • KPackageKit
    purer Dreck!!
  • SAMBA startet nicht!
    •  => AppArmour Fehler
    • Link
    • außerdem wurden keine User übertragen:
    • Link
    • Abhilfe:
      pdbedit -i smbpasswd -e tdbsam
  • /etc/sysconfig/displaymanager: "gdm" startet Gnome login - und dann doch KDE!
  • IPv6 Probleme
    • in phpMyAdmin wird host='localhost' nicht mehr erkannt.
      Nur '127.0.0.1' geht stattdessen.
    • => ipv6 abschalten
    • Link
    • Test:
      cat /proc/sys/net/ipv6/conf/all/disable_ipv6

Samstag, 2. Januar 2010

KDE Bug

in einer root-Shell eingeben: kwrite
kdeinit4: preparing to launch /usr/lib/libkdeinit4_klauncher.so
kdeinit4: Communication error with launcher. Exiting!
KCrash: Application 'kwrite' crashing...
sock_file=/root/.kde4/socket-linux-bolide/kdeinit4__0
Warning: connect() failed: : Verbindungsaufbau abgelehnt
KCrash cannot reach kdeinit, launching directly.

PHP 5.3

Ich habe die Schnauze voll von all dieses "deprecated"-Meldungen.
Wenn es nur eines Eintrags in php.ini bedürfe (error_reporting = E_ALL & ~E_DEPRECATED), dann wäre das ja schnell erledigt.
Aber viele PHP-Programme schreiben explizit error_reporting(E_ALL) oder sowas. Und ich habe keine Lust, ständig in diesen Programmen rumzufuhrwerken.
Noch komplizierter wird es, die ganzen ereg() Aufrufe zu korrigieren. Das sollen die Autoren mal hübsch selber machen ;-)

Ich werde jetzt versuchen, eine ältere PHP-Version zu installieren. Hoffentlich geht das schnell (schwitz)

Also von der SuSE-Installationsquelle für 11.1 PHP RPM runterladen.
Oh Mist - dazu gehören ja jede Menge weitere Pakete (php5-mysql usw.).
Muss in YaST schauen, welche installiert sind. Zum Glück kann man die Liste als XML exportieren.. Pustekuchen - es wird die ganze Liste exportiert (nicht nur die der installierten Pakete)
Bestimmt gibt es irgendeine Option für RPM, aber ich habe keine Zeit, mir das rauszufriemeln.
Sowas wie
  rpm --query --list --all | grep php5
taugt jedenfalls dafür nicht.
Also alle einzeln :-\

Geht natürlich auch nicht :-(
Ständig kommen Meldungen über fehlerhafte Abhängigkeiten. Das kriege ich nie auseinander.
Naja, wenigstens hat's mir nix zerschossen.

Hier steht, wie man RPM zwingen kann. Ist mir aber zu gefährlich. Zumal der das mit einer anderen Distro gemacht hat.
Oder versuche ich dies?
Dazu muss ich als Repositorydie 11.1 anfügen, und unter "Versionen" die alte auswählen. Ob das geht?
Nein - dann zeigt mir YaST an, dass es alles downgraden will (bis hin zum kernel). Das lass ich auch lieber ;-}

Vermutlich muss ich mit PHP 5.3 leben, und doch in den PHP-Programmen rumwurschteln, solange die nicht von den Autoren angepasst sind :-(

Freitag, 1. Januar 2010

Krfb

Dieses VNC-Server GUI "Krfb" ist ja nur buggy :-(

Besonders seit dem Update auf KDE 4 kennt das Teil weder Shift-Taste noch AltGr-Kombinationen usw.
Ein Arbeiten in der Konsole oder auch nur eine URL mit "/" einzugeben war nur übers Clipboard möglich. Ups - auch das Clipboard funktioniert ja nicht!
Ich musste tatsächlich mit einer Textdatei in zwei Editoren schaffen.


Dann wurden auch noch oft ganze Bildschirmbereiche nicht neu übertragen. What a mess.

Glücklicherweise habe ich diese Seite gefunden und verwende nun vncserver statt Krfb.

Clipboard, Shift-Tasten - alles wieder ok. Und viel schnellere Bildschirmübertragung.

Krfb ist für die Tonne.

mySQL socket

Ich will ein weiteres Programm installieren, welches (auf Perl-Basis) auf eine mySQL Datenbank zugreifen will.

Bei ./configure kommt
DBI connect('database=xx;host=localhost','xx',...) failed: Can't connect to local MySQL server through socket '/var/run/mysql/mysql.sock' (2) at /usr/lib/perl5/site_perl/5.10.0/xxx/Config.pm line 89

Wieder dieses Socket-Problem; wieder steht irgendwo /var/run statt /var/lib
Anmerkung: ich hatte mir /var/lib nicht ausgedacht!

Jetzt wo finde ich die Stelle? Mal "perl dbi mysql configure" suchen..
Hier lese ich, dass man den Pfad mit angeben kann, aber das kann's ja nicht sein.
DBI->connect('dbi:mysql:database=testdb;mysql_socket=/pfad/zu/mysql.sock', 'username', 'password');

Ich vermute ja, dass die opensuse 11.2 Installation da Mist gebaut hat.
Ich sollte erwägen, einen symlink auf die echte Datei zu setzen, dann wäre ein für alle Mal Ruhe. Aber das gehört in die Kategorie "quick & dirty"-Gefrickel, die ein System eher komplizierter und schwerer wartbar macht.

Hiermit wird auch nur der korrekte Pfad angezeigt:
ps ax|grep mysqld
26978 ?        S      0:00 /bin/sh /usr/bin/mysqld_safe --mysqld=mysqld --user=mysql --pid-file=/var/run/mysql/mysqld.pid --socket=/var/lib/mysql/mysql.sock --datadir=/var/lib/mysql
27096 ?        Sl     0:28 /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --log-error=/var/lib/mysql/mysqld.log --pid-file=/var/run/mysql/mysqld.pid --socket=/var/lib/mysql/mysql.sock --port=3306

Ich sehe gerade: mit phpinfo() wird ausgegeben:
MYSQL_SOCKET     /var/run/mysql/mysql.sock
Hatte ich das nicht schonmal angeschaut? Egal, jetzt bin ich auf der Spur.


(So muss ich mich immer wieder beim Kampf mit Linux motivieren: "es ist doch spannend, die Rätsel zu lösen". Na ja.. ;-)

Also in die php.ini hatte ich es ja eben erst eingetragen.
Außerdem geht es dabei ja nur um PHP(?) und obiges Problem tritt mit Perl auf.
Logischer wäre allerdings, wenn sich PHP, Perl und alles andere die Informationen von mysql holen würden.

Jetzt habe ich doch die q&d "Lösung" gewählt, weil ich wirklich keinen Nerv mehr habe, jedem Mist hinterherzuforschen. Also symlink von /var/run/.. nach /var/lib/mysql/mysql.sock

Damit läuft wenigstens die Compilierung des Perl-Programms durch.

Der PHP-Teil des Programms (dessen Name ist unerheblich) gibt jetzt $variablen statt deren Inhalt aus.
Nach wiedermal viel Rumsucherei finde ich den Hinweis, doch mal in der php.ini nach der Option short_open_tag zu schauen. Und siehe da - das steht auf OFF. Keine Ahnung, ob das die Künschtler von PHP 5.3 stillschweigend eingeführt haben. Mich hat es jedenfalls viel Zeit gekostet.

Donnerstag, 31. Dezember 2009

MySQL

Mit dem guten WebMin (wie oft mir das doch schon den A** gerettet hat!) sehe ich wenigstens die alten Datenbanken.

phpMyAdmin wurde mir beim Update gelöscht!! Schweinerei.
Also neu installieren.

Erledigt. Nun meldet phpMyAdmin
#2002 - Der Server antwortet nicht. (evtl. ist auch der Socket des lokalen MySQL-Servers socket nicht korrekt konfiguriert)

Also muss mySQL auch neu aufgesetzt werden. Ohne WebMin wäreauch dies wieder ein Riesen-Akt.
WebMin fragt freundlich nach einem Modul "DBD mysql", damit es besser arbeiten kann, und bietet an, dies zu installieren. Nach einem Klick wird es fehlerfrei installiert. So sollte es eben laufen, liebe YaST- und sonstige Frickler!

Zurück zu phpMyAdmin. Warum kann das Teil nicht auf die Datenbank zugreifen - WebMin kann's doch?
Also wieder in Foren suchen..

mysqld mal manuell starten.
"091230 19:13:27 [Warning] mysqld: ignoring option '--character-set-client-handshake' due to invalid value 'cp1251'"
Das scheint eine unkritische Meldung zu sein, aber muss das sein, bei einer neuen Installation?

Wie erreiche ich nun, dass mysql automatisch (oder überhaupt mal) korrekt gestartet wird? In Config-Files rumfrickeln?

Nach "rcmysql restart" ist mysqld da. Aber warum muss ich das von Hand eingeben?
phpMyAdmin spuckt aber immer noch dieselbe Meldung aus.

Also mal nachschauen:
mysql status gibt u.a. aus:
UNIX socket:            /var/lib/mysql/mysql.sock

Wenn ich in PHP.ini alle Warnungen ausgeben lasse, kommt bei phpmyadmin/setup u.a.
Warning in ./libraries/dbi/mysql.dbi.lib.php#35
mysql_connect(): Can't connect to local MySQL server through socket '/var/run/mysql/mysql.sock' (2)

 Aha. Da scheint der Wurm zu stecken.
Die Datei mysql.sock gibt es hier nur unter /var/lib/mysql
So steht es auch in der my.cnf

Wie bringe ich phpmyadmin das jetzt bei?
Eintrag in die config.inc.php
$cfg['Servers'][$i]['socket'] = '/var/lib/mysql/mysql.sock';

Super - jetzt kommt die Meldung in /setup schon nicht mehr.
Aber auch, wenn ich den Server in /setup eintrage (samt "Socket") geht nix.
Die von /setup geschriebene config.inc.php wird ins /config directory geschrieben (meine von früher war im Stammordner).
Aber hallo - auch wenn ich alle config.inc.php umbenenne, kommt dieselbe Meldung!
Es wird offenbar noch gar nicht versucht, sich einzuloggen bzw. den "socket" Eintrag aus der config zu lesen.

Es ist auch eindeutig ein Problem von phpmyadmin, micht mysql (WebMin kann ja zugreifen)

Jetzt wo die configs unsichtbar sind, kommt plötzlich wieder die "Warning" von oben.

Ich will nachschauen, ob phpinfo() die korrekte mysql-Erweiterung eingebunden hat.
Per Browser kommt nur der "beliebte" weiße Bildschirm (leere Seite).
Auf der Kommandozeile kommt aber:
PHP Fatal error:  Unknown: Failed opening required 'info.php' (include_path='.:/usr/share/php5:/usr/share/php5/PEAR') in Unknown on line 0

Tja, was ist jetzt "Unknown"? Wenn du's nicht weißt, woher soll ich es wissen? :-(

Die Datei info.php gibt es aber definitiv. Besitzer zwar root:root, Zugriffsrechte aber rw-r--r--, also Leserechte für alle.

Also habe ich jetzt ein Problem mit PHP und mit phpMyAdmin - hoffentlich ist Letzteres nur ein Folgefehler.
Endlich habe ich phpinfo() zum Laufen bekommen. Da sehe ich unter "mysql"
MYSQL_SOCKET     /var/run/mysql/mysql.sock
Aha - der Übeltäter ist gefasst :)
Keine Ahnung, wie das da reinkam, aber jetzt muss ich schauen, wo man das einstellt.
Unter php/conf.d jedenfalls nicht. In php.ini auch nicht. Und jetzt? Wieder in Foren suchen :-|
In /usr/include/mysql/mysql_version.h scheint es definiert zu sein. Aber wo kann ich das konfigurieren?

Endlich habe ich die Einstellung in php.ini gefunden: "mysql.default_socket". Achtung, die gibt es zweimal (unter [MySQL] und [MySQLi])

Wow - phpMyAdmin startet - endlich.

Bei aller Freude: wieder über zwei Stunden Lebenszeit für diesen unkreativen Kack verbraten.

Mittwoch, 30. Dezember 2009

Apache Server

Tja, WLAN geht jetzt zwar, aber es fehlt noch (hauptsächlich) Apache.
Beim Aufruf eines virtual host kommt: "Bad Request" (Fehlercode 400)
In der error_log: nichts. in der access_log: einfach nur "GET /" und 400


Tolle Hilfe.

Geht PHP überhaupt? Ich hatte doch apache samt PHP5 komplett neu installiert..
Ein PHP-Programm auf der Kommandozeile aufgerufen: geht.
Wie war das nochmal mit der PHP-Anbindung an Apache - kruschtel, kruschtel - wieder bin ich genervt, dass ich mich überhaupt mit diesem low level Mist beschäftigen muss ohne GUI.
Soso, in einer /etc/sysconfig/apache2 Datei steht unter APACHE_MODUES, welche Module überhaupt geladen werden.
Dort fehlt PHP!
Mit ungutem Gefühl schreibe ich "php5" dazu (wenn das schon nicht automatisch eingebunden wurde - was stimmt dann sonst noch nicht?)

Ich rufe die Testseite mal via VNC als localhost auf. Jetzt bekomme ich wenigstens eine ordentliche Ausgabe (mit Browserkennung) in der aceess_log - aber 403: Access forbidden.
Ok, Ordneroptionen prüfen - vielleicht gibt es ein Rechte-Problem.
Oha - keine Datei in /htdocs? Hatte ich die gelöscht? Ich glaube nicht. Egal, ich schreib eine index.html rein.
Die Seite ist sehr simpel und benutzt überhaupt kein PHP.
Mit rcapache2 restart kommt überhaupt keine Fehlermeldung. Dennoch schlägt der Aufruf der Seite wieder fehl. Besonders liebe ich die Meldung "Your browser (or proxy) sent a request that this server could not understand.". Nun ja - weitersuchen. Was anderes bleibt mir ja kaum übrig.
Huch - von localhost geht es jetzt!
An der Firewall wird's doch nicht liegen? Ausgeschaltet - nein, das Problem besteht immer noch.

Es lag an der (von WLAN) geänderten IP! Alle virtual hosts auf die neue IP umgestellt - dann geht's.
Ich habe übrigens noch keine Möglichkeit gefunden, named virtual hosts nur über den Namen anzusprechen (ohne, dass ich bei der virtual server Adresse die lokale IP angebe).

Jetzt erscheint (natürlich) ein weiteres Problem: mysql kann offenbar auf die zuvor konfigurierten Datenbanken nicht zugreifen.