Kommen die Antwortpings bei Debian-basierten Systemen wie zum Beispiel Ubuntu recht langsam, so sollte man einen Blick in die Datei /etc/nsswitch.conf werfen.

Die Zeile

hosts:          files mdns4_minimal [NOTFOUND=return] dns mdns4

sollte man dann auf 

hosts:          files dns

zusammenstutzen.

Vor einiger Zeit habe ich den Schritt gewagt, meine VMware Workstation von Version 5.5 auf Version 6 upzugraden.Positiv überrascht war ich, dass es nun wieder VMware Tools für Debian und Ubuntu gibt. Auch erschien das Starten und Beenden sowie das Schlafen-Schicken und Wieder-Aufwecken eventuell etwas schneller zu gehen. Ich glaube aber, dass hier einfach die Notebook-Festplatte der limitierende Faktor ist.

Nun denn, ich installierte also Version 6.0.3 Build 80004. Allerdings musste ich feststellen, dass mein Ubuntu immer mal wieder einfror. Es ging gar nichts mehr. Noch nicht mal ausschalten konnte ich die virtuelle Maschine.  Auch konnte ich die VMware Workstation nicht beenden. Es gab immer nur ein Pop-up, dass schließlich noch ein Gast laufe…. Super Sache an sich. Aber so musste ich per Taskmanager den Prozess hart abschießen.

Nun habe ich ein Upgrade auf Version 6.0.4 Build 93057 durchgeführt. Die Installation lief zwar problemlos durch. Aber mit Download, Installation, Neueinstellung der Netzwerkeigenschaften und anscheinend dem Reparieren der durch das Abschießen des Prozesses vermutlich in Mittleidenschaft gezogenen Gastinstallation ist so mal eben eine knappe Stunde ins Land gegangen ….

Selbst dran Schuld, wenn man auch Software eines amerikanischen Unternehmens mit einer Versionsnummer installiert, die auf  0.3 endet. Die kann ja noch nichts taugen ….

Ich habe es nun gewagt, meinen vServer auf Etch umzustellen. Einher geht dies mit einer Umstellung auf MySQL 5. Nachdem das eigentliche Upgrade durchgelaufen ist, geht nun die Arbeit los, die kleinen, versteckten Fehler zu finden. Schaun mer mal …

 

Als erste Änderung habe ich in der Datei /etc/mysql/my.cnf die beiden Zeilen

collation-server = latin1_german1_ci
character-set-server=latin1

eingetragen. 

In der aktuellen iX, die ich heute in der Post hatte, heißt es: "Mit Erscheinen dieser Ausgabe soll es soweit sein: Die Entwickler haben Debian 4.0 (Codename "Etch") freigegeben." Soweit so gut. Auf der offiziellen Seite des Debian-Projektes wird aber noch immer 3.1 als "neueste stabile Release" angepriesen. Also heißt es warten…

Ich habe mir zu Testzwecken einen Klon meines vServers eingerichtet. Das geht relativ schnell durch die folgenden Komandos:

Auf dem Quellsystem:

dpkg --get-selections > packets.txt

Auf dem Zielsystem:

dpkg --set-selections < packets.txt
dselect update
dselect install

 

Ich habe nun einen super Tipp gefunden, um endlich schneller die Fehlermeldung wegen eines unbekannten Keys loszuwerden:

W: There are no public key available for the following key IDs:
A70DAF536070D3A1
W: You may want to run apt-get update to correct these problems

Nach

apt-get install debian-archive-keyring

apt-key update

sollte alles funtkionieren.

Ich habe eben mal wiederbei meinem Debian etch die Pakete aktualisiert. Dabei wurde auch auch der X.org 7.0 X-Server durch die 7.1er Version ersetzt. Das Ergebnis war mal wieder ernüchternd.

Das System läuft als Gast in einer VMware Workstation 5.5.1 und hatte damals beim Wechsel auf diese Version schon Probleme mit dem XServer.

Auch diesmal brachte erst eine De- und Neuinstallation aller XServer-Pakete das gewünschte Ergebnis. Dabei habe ich die bestehende Installation der VMware-Tools in Ruhe gelassen.

Auch die Netzwerkkarte war erst nach dem Eintrag des Treibers pcnet32 in die Datei /etc/modules nach dem Reboot wieder ansprechbar.

Heute morgen erhielt ich keine Antwort von meiner cacti-Installation. Ein Blick ins error_log des Apache brachte die Fehlermeldung child pid 8714 exit signal File size limit exceeded (25) zu Tage. Anscheinend wird der Apache bei Debian etch so kompiliert, dass er nur Files bis 2 GB verarbeiten kann. Dummerweise waren aber alle Logfiles (bedeutend) kleiner. Auch ein Durchstarten des Prozesses brachte nichts. Dann fiel mir auf, dass die Probleme nur bei Aufrufen im caci-Bereich auftraten. Und siehe da, die Datei cacti.log war zu groß. Da ich ja cacti selbst installiert hatte, war dieses File auch nicht bei logrotate eingetragen.Nebenbei bemerkt hat sich die eigene Installation auch nicht bewährt: Mittlerweile sind geht's bei den Data Sources mit den Data Input Methods kräftig drunter und drüber …

Die Cacti Story geht weiter. Ich wollte auf einem anderen Debian/Etch System "mal eben" cacti installieren. Auf einmal traten da folgende Fehler aus:
Fatal error
: Call to undefined function: mysql_pconnect() in /usr/share/php/adodb/drivers/adodb-mysql.inc.php on line 372
Es stellte sich heraus, dass hier eine geringfügig neuere Version diverser php-Libraries installiert war. Ich habe mir dann von
http://snapshot.debian.net die alten Pakete geholt. Diese bissen sich dann aber mit der Mysql-Version. Also habe ich sowohl die 5.0er Version ausprobiert, wie auch die 4.1er, die sich dann aber plötzlich nicht mehr und dann doch wieder installieren ließ …

Auf jeden Fall klappt es nun mit folgenden Versionen:
# dpkg -l| grep php
ii  libapache-mod-php4              4.4.2-1+b1                        server-side, HTML-embedded scripting languag
ii  libphp-adodb                    4.72-0.1                          The ‘adodb’ database abstraction layer for p
ii  php4                            4.4.2-1                           server-side, HTML-embedded scripting languag
ii  php4-cli                        4.4.2-1+b1                        command-line interpreter for the php4 script
ii  php4-common                     4.4.2-1+b1                        Common files for packages built from the php
ii  php4-mysql                      4.4.2-1+b1                        MySQL module for php4
ii  php4-snmp                       4.4.2-1+b1                        SNMP module for php4
rc  php5-cli                        5.1.2-1+b1                        command-line interpreter for the php5 script
rc  php5-common                     5.1.2-1+b1                        Common files for packages built from the php
rc  php5-mysql                      5.1.2-1+b1                        MySQL module for php5
# dpkg -l| grep mysql
ii  libdbd-mysql-perl               3.0002-2+b1                       A Perl5 database interface to the MySQL data
ii  libmysqlclient14                4.1.15-1                          mysql database client library
ii  libmysqlclient15off             5.0.20-1                          mysql database client library
ii  mysql-client-4.1                4.1.15-1                          mysql database client binaries
ii  mysql-common                    5.0.20-1                          mysql database common files (e.g. /etc/mysql
ii  mysql-server-4.1                4.1.15-1                          mysql database server binaries
ii  php4-mysql                      4.4.2-1+b1                        MySQL module for php4
rc  php5-mysql                      5.1.2-1+b1                        MySQL module for php5
und
# dpkg -l| grep cacti
ii  cacti                           0.8.6h-2                          Frontend to rrdtool for monitoring systems a
Ich bin mir aber nicht sicher, dass das ursprüngliche debian-cacti Problem damit gelöst ist. Aber zumindest werden zur Zeit Grafiken produziert …

Ich habe nun Cacti direkt aus den Quellen installiert und siehe da, das Problem tritt nicht mehr auf. Dafür habe ich nun den Spaß, alle Grafiken und Eingabevarianten neu anzulegen …
Stellt sich nur die Frage, ob ich demnächst wieder auf das Debian Paket zurückwechseln soll.

© 2012 JerryWho Suffusion theme by Sayontan Sinha