[gelöst] [4.0.4 opsi40-testing/Debian_6.0] opsi-depotserver

[lutz.willek]

Moinsen!

Es gibt unter Umständen ein Problem beim Update mit dem Paket opsi-depotserver (4.0.4.2-1) auf Debian 6, wenn ein mysql-server auf dem System installiert ist:

Code: Alles auswählen

opsi-depotserver (4.0.4.2-1) wird eingerichtet ...
[...]
[5] [Dez 15 20:20:35] Disabling mysql backend and license management module: no customer in modules file (MySQL.py|441)
[5] [Dez 15 20:20:35] Creating base path: '/var/lib/opsi/config' (File.py|237)
[5] [Dez 15 20:20:35] Creating opsi base (SQL.py|391)
[5] [Dez 15 20:20:35] Configuring samba (opsi-setup|175)
[4] [Dez 15 20:20:35] Share opt_pcbin configuration found in '/etc/samba/smb.conf'. You should use opsi_depot_rw instead, if you need a writeable depot-Share. (opsi-setup|209)
[5] [Dez 15 20:20:35]    Adding share [opsi_depot_rw] (opsi-setup|235)
[5] [Dez 15 20:20:35]    Adding share [opsi_images] (opsi-setup|249)
[5] [Dez 15 20:20:35]    Creating backup of /etc/samba/smb.conf (opsi-setup|292)
[5] [Dez 15 20:20:35]    Writing new smb.conf (opsi-setup|295)
[5] [Dez 15 20:20:35]    Reloading samba (opsi-setup|300)
[5] [Dez 15 20:20:36] Setting rights (opsi-setup|534)
[5] [Dez 15 20:20:36] Setting rights on directory '/etc/opsi' (opsi-setup|618)
[5] [Dez 15 20:20:37] Setting rights (opsi-setup|534)
[5] [Dez 15 20:20:37] Setting rights on directory '/tftpboot/linux' (opsi-setup|618)
dpkg: Fehler beim Bearbeiten von opsi-depotserver (--configure):
 Unterprozess installiertes post-installation-Skript gab den Fehlerwert 1 zurück
configured to not write apport reports
                                      Fehler traten auf beim Bearbeiten von:
 opsi-depotserver
E: Sub-process /usr/bin/dpkg returned an error code (1)

Oder später dann bei einem erneuten Versuch:

Code: Alles auswählen

# dpkg --configure --pending
opsi-depotserver (4.0.4.2-1) wird eingerichtet ...
[4] [Dez 15 20:39:31] Failed to read opsi modules file '/etc/opsi/modules': Signature not found (Backend.py|376)
[5] [Dez 15 20:39:31] Disabling mysql backend and license management module: no customer in modules file (MySQL.py|441)
[5] [Dez 15 20:39:32] Creating base path: '/var/lib/opsi/config' (File.py|237)
[5] [Dez 15 20:39:32] Creating opsi base (SQL.py|391)
[4] [Dez 15 20:39:32] Failed to read opsi modules file '/etc/opsi/modules': Signature not found (Backend.py|376)
[5] [Dez 15 20:39:32] Disabling mysql backend and license management module: no customer in modules file (MySQL.py|441)
[5] [Dez 15 20:39:33] Creating base path: '/var/lib/opsi/config' (File.py|237)
[5] [Dez 15 20:39:33] Creating opsi base (SQL.py|391)
[5] [Dez 15 20:39:33] Configuring samba (opsi-setup|175)
[5] [Dez 15 20:39:34] Setting rights (opsi-setup|534)
[5] [Dez 15 20:39:34] Setting rights on directory '/etc/opsi' (opsi-setup|618)
[5] [Dez 15 20:39:34] Setting rights (opsi-setup|534)
[5] [Dez 15 20:39:35] Setting rights on directory '/tftpboot/linux' (opsi-setup|618)
dpkg: Fehler beim Bearbeiten von opsi-depotserver (--configure):
 Unterprozess installiertes post-installation-Skript gab den Fehlerwert 1 zurück
Fehler traten auf beim Bearbeiten von:
 opsi-depotserver

Das liegt an einem nicht gut gesichertem "grep" im ./DEBIAN/postinst des Pakets opsi-depotserver, und zwar bei der Abfrage des mysql-Status, genauer der Variable "mysqlstate". Hier der betreffende Codeabschnitt im Skript:

Code: Alles auswählen

                        /usr/bin/opsi-setup --set-rights /tftpboot || true
                        if [ -e "/etc/init.d/mysql" ];then
                                mysqlstate=$(/etc/init.d/mysql status | grep "start/running")
                                if [ "$mysqlstate" != "" -a "$mysqlbackend" != "" ]; then
                                        /usr/bin/opsi-setup --update-mysql
                                fi
                        fi

Das ganze hier direkt auf dem System ausgeführt:

Code: Alles auswählen

# mysqlstate=$(/etc/init.d/mysql status | grep "start/running") ; echo $?
1

Der Quick-Fix für mich war:

Code: Alles auswählen

# mv /etc/init.d/mysql /etc/init.d/mysql_
# dpkg --configure --pending
# mv /etc/init.d/mysql_ /etc/init.d/mysql

Unter Umständen (wenn mysql genutzt wird) muss ggf. noch mehr erledigt werden: "opsi-setup --update-mysql". Vor Absetzen dieses Kommandos aber bitte den UIB Support befragen oder hier im Thread weiter lesen, weil ich selbst konnte das nicht erfolgreich testen! Wäre nett wenn sich dazu noch jemand vom Support äußert wie es ausschaut, wenn jemand die mysql Erweiterung nutzt.

Wie auch immer, das Paket selbst müsste gefixt werden, und zwar mindestens so:

Code: Alles auswählen

# mysqlstate=$(/etc/init.d/mysql status | grep "start/running"||true) ; echo $?
0

Besser wäre es, einen stabileren Weg zu finden ob und wie der mysql-Server läuft. Weil ein "start/running" trifft es nicht immer: Hier gibt "/etc/init.d/mysql status" folgendes aus:

## mysql läuft:

Code: Alles auswählen

# /etc/init.d/mysql status
/usr/bin/mysqladmin  Ver 8.42 Distrib 5.1.72, for debian-linux-gnu on x86_64
Copyright (c) 2000, 2013, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Server version          5.1.72-2
Protocol version        10
Connection              Localhost via UNIX socket
UNIX socket             /var/run/mysqld/mysqld.sock
Uptime:                 2 days 12 hours 43 min 29 sec

Threads: 1  Questions: 11345  Slow queries: 0  Opens: 2889  Flush tables: 1  Open tables: 64  Queries per second avg: 0.51.

## mysql gestoppt:

Code: Alles auswählen

# /etc/init.d/mysql status
MySQL is stopped..

Soweit mal. Wenn Ich das neue Paket testen soll: Gerne, dann bitte PM an mich.

Das Mysql-Update läuft übrigens nicht sauber durch, zumindest nicht hier. Ich habe keine Lizenz dafür und nutze mysql dementsprechend nicht,
aber hier sei Euch zumindest an dieser Stelle Bescheid gesagt:

Code: Alles auswählen

# opsi-setup --update-mysql
[5] [Dez 15 21:03:42] Connection to database 'opsi' on 'localhost' as user 'XremovedX' (opsi-setup|1192)
[2] [Dez 15 21:03:42] Traceback: (Logger.py|742)
[2] [Dez 15 21:03:42]      line 3441 in '<module>' in file '/usr/bin/opsi-setup' (Logger.py|742)
[2] [Dez 15 21:03:42]      line 3396 in 'main' in file '/usr/bin/opsi-setup' (Logger.py|742)
[2] [Dez 15 21:03:42]      line 1201 in 'updateMySQLBackend' in file '/usr/bin/opsi-setup' (Logger.py|742)
[2] [Dez 15 21:03:42]      line 395 in 'execute' in file '/usr/lib/pymodules/python2.6/OPSI/Backend/MySQL.py' (Logger.py|742)
[2] [Dez 15 21:03:42]      line 166 in 'execute' in file '/usr/lib/pymodules/python2.6/MySQLdb/cursors.py' (Logger.py|742)
[2] [Dez 15 21:03:42]      line 35 in 'defaulterrorhandler' in file '/usr/lib/pymodules/python2.6/MySQLdb/connections.py' (Logger.py|742)
[2] [Dez 15 21:03:42]      ==>>> (1347, "'opsi.00_view_Alle_Lizenzen' is not BASE TABLE") (opsi-setup|3445)
ERROR: (1347, "'opsi.00_view_Alle_Lizenzen' is not BASE TABLE")

Liebe Grüße und ein paar geruhsame Tage wünscht Lutz

[n.wenselowski]

Hallo lutz,

erst mal vielen Dank für den Bugreport!
Ich habe dazu ein internes Ticket erstellt.

Wir werden uns das ganze anschauen und uns dann hier noch mal melden!


Gruß

Niko

[n.wenselowski]

Hallo Lutz,

das Problem ist, dass das Oracle MySQL unter Debian Squeeze eben nicht nur seinen Status ausgibt, sondern den ganzen Kladderatsch drum herum.
Dazu kam, dass der Check auf die Verwendung des MySQL-Backends nur im .spec-File funktionierte, aber nicht bei Debians Postinst. Auch das sollte nun behoben sein.

Wir bauen gerade ein neues Paket, welches in ein paar Minuten im Testing-Zweig zu finden sein sollte.
Feedback ist erwünscht

Das Mysql-Update läuft übrigens nicht sauber durch, zumindest nicht hier. Ich habe keine Lizenz dafür und nutze mysql dementsprechend nicht,
aber hier sei Euch zumindest an dieser Stelle Bescheid gesagt:

Code: Alles auswählen

# opsi-setup --update-mysql
[5] [Dez 15 21:03:42] Connection to database 'opsi' on 'localhost' as user 'XremovedX' (opsi-setup|1192)
[2] [Dez 15 21:03:42] Traceback: (Logger.py|742)
[2] [Dez 15 21:03:42]      line 3441 in '<module>' in file '/usr/bin/opsi-setup' (Logger.py|742)
[2] [Dez 15 21:03:42]      line 3396 in 'main' in file '/usr/bin/opsi-setup' (Logger.py|742)
[2] [Dez 15 21:03:42]      line 1201 in 'updateMySQLBackend' in file '/usr/bin/opsi-setup' (Logger.py|742)
[2] [Dez 15 21:03:42]      line 395 in 'execute' in file '/usr/lib/pymodules/python2.6/OPSI/Backend/MySQL.py' (Logger.py|742)
[2] [Dez 15 21:03:42]      line 166 in 'execute' in file '/usr/lib/pymodules/python2.6/MySQLdb/cursors.py' (Logger.py|742)
[2] [Dez 15 21:03:42]      line 35 in 'defaulterrorhandler' in file '/usr/lib/pymodules/python2.6/MySQLdb/connections.py' (Logger.py|742)
[2] [Dez 15 21:03:42]      ==>>> (1347, "'opsi.00_view_Alle_Lizenzen' is not BASE TABLE") (opsi-setup|3445)
ERROR: (1347, "'opsi.00_view_Alle_Lizenzen' is not BASE TABLE")

Das Problem kann ich hier spontan nicht nachvollziehen. Ist 00_view_Alle_Lizenzen eine selbstgebaute View auf der Datenbank?


Gruß

Niko

[lutz.willek]

Wir bauen gerade ein neues Paket, welches in ein paar Minuten im Testing-Zweig zu finden sein sollte.
[...]
Gruß

Niko

Hi,

Das eigentliche Problem ist weg, das Paket ist wieder heile. Von daher --> gelöst ohne nachzusehen was genau verändert wurde.

Als Tip: Wäre es nicht besser beim Update nachzusehen ob eine Verbindung zur Opsi-Datenbank gemacht werden kann? Weil diese kann ja schließlich auch auf einem anderen Server liegen: Dann läuft der Test auf einen lokal installierten SQL-Server irgendwie ins leere...

Abseits davon: Bei mir jetzt der gleiche Fehler wie beim manuellen Update des Mysql-Servers.

Update: Da hat doch ein Kollege gefrickelt ohne Bescheid zu geben
Ja, das ist ein gespeicherter View auf die Datenbank. gelöst.

Mittels "opsi-setup --update-mysql" zur Datenbank selbst:

Code: Alles auswählen

# apt-get dist-upgrade
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut
Statusinformationen werden eingelesen... Fertig
Paketaktualisierung (Upgrade) wird berechnet... Fertig
Die folgenden Pakete werden aktualisiert (Upgrade):
  opsi-depotserver
1 aktualisiert, 0 neu installiert, 0 zu entfernen und 0 nicht aktualisiert.
Es müssen 32,2 kB an Archiven heruntergeladen werden.
Nach dieser Operation werden 0 B Plattenplatz zusätzlich benutzt.
Möchten Sie fortfahren [J/n]? j
Hole:1 http://download.opensuse.org/repositories/home:/uibmz:/opsi:/opsi40-testing/Debian_6.0/ ./ opsi-depotserver 4.0.4.2-2 [32,2 kB]
Es wurden 32,2 kB in 0 s geholt (191 kB/s)
Vorkonfiguration der Pakete ...
(Lese Datenbank ... 50963 Dateien und Verzeichnisse sind derzeit installiert.)
Vorbereitung zum Ersetzen von opsi-depotserver 4.0.4.2-1 (durch .../opsi-depotserver_4.0.4.2-2_all.deb) ...
Ersatz für opsi-depotserver wird entpackt ...
opsi-depotserver (4.0.4.2-2) wird eingerichtet ...
[4] [Dez 16 15:35:15] Failed to read opsi modules file '/etc/opsi/modules': Signature not found (Backend.py|376)
[5] [Dez 16 15:35:15] Disabling mysql backend and license management module: no customer in modules file (MySQL.py|441)
[5] [Dez 16 15:35:15] Creating base path: '/var/lib/opsi/config' (File.py|237)
[5] [Dez 16 15:35:15] Creating opsi base (SQL.py|391)
[4] [Dez 16 15:35:16] Failed to read opsi modules file '/etc/opsi/modules': Signature not found (Backend.py|376)
[5] [Dez 16 15:35:16] Disabling mysql backend and license management module: no customer in modules file (MySQL.py|441)
[5] [Dez 16 15:35:17] Creating base path: '/var/lib/opsi/config' (File.py|237)
[5] [Dez 16 15:35:17] Creating opsi base (SQL.py|391)
[5] [Dez 16 15:35:17] Configuring samba (opsi-setup|175)
[4] [Dez 16 15:35:17] Share opt_pcbin configuration found in '/etc/samba/smb.conf'. You should use opsi_depot_rw instead, if you need a writeable depot-Share. (opsi-setup|209)
[5] [Dez 16 15:35:18] Setting rights (opsi-setup|534)
[5] [Dez 16 15:35:18] Setting rights on directory '/etc/opsi' (opsi-setup|618)
[5] [Dez 16 15:35:19] Setting rights (opsi-setup|534)
[5] [Dez 16 15:35:19] Setting rights on directory '/tftpboot/linux' (opsi-setup|618)
[5] [Dez 16 15:35:20] Connection to database 'opsi' on 'localhost' as user 'xoooXremovedXooox' (opsi-setup|1192)
[2] [Dez 16 15:35:20] Traceback: (Logger.py|742)
[2] [Dez 16 15:35:20]      line 3441 in '<module>' in file '/usr/bin/opsi-setup' (Logger.py|742)
[2] [Dez 16 15:35:20]      line 3396 in 'main' in file '/usr/bin/opsi-setup' (Logger.py|742)
[2] [Dez 16 15:35:20]      line 1201 in 'updateMySQLBackend' in file '/usr/bin/opsi-setup' (Logger.py|742)
[2] [Dez 16 15:35:20]      line 395 in 'execute' in file '/usr/lib/pymodules/python2.6/OPSI/Backend/MySQL.py' (Logger.py|742)
[2] [Dez 16 15:35:20]      line 166 in 'execute' in file '/usr/lib/pymodules/python2.6/MySQLdb/cursors.py' (Logger.py|742)
[2] [Dez 16 15:35:20]      line 35 in 'defaulterrorhandler' in file '/usr/lib/pymodules/python2.6/MySQLdb/connections.py' (Logger.py|742)
[2] [Dez 16 15:35:20]      ==>>> (1347, "'opsi.00_view_Alle_Lizenzen' is not BASE TABLE") (opsi-setup|3445)

ERROR: (1347, "'opsi.00_view_Alle_Lizenzen' is not BASE TABLE")

dpkg: Fehler beim Bearbeiten von opsi-depotserver (--configure):
 Unterprozess installiertes post-installation-Skript gab den Fehlerwert 1 zurück
configured to not write apport reports
                                      Fehler traten auf beim Bearbeiten von:
 opsi-depotserver
E: Sub-process /usr/bin/dpkg returned an error code (1)

Ich habe keine Idee was das sein soll. Mysql wird hier nur für audit.* genutzt:

Code: Alles auswählen

# egrep '^[^#].*mysql' /etc/opsi/backendManager/dispatch.conf
backend_.*         : file, mysql, opsipxeconfd, dhcpd
audit.*            : mysql

Der Server ist im Original Version 3.x und wurde immer hübsch aktualisiert. Ich schlage vor ich mache dazu ein neues Ticket im Bereich freier Support auf, weil der opsi-depotserver läuft ja jetzt prinzipiell sauber durch.

[SisterOfMercy]

If nothing works, maybe a different mysql server helps? I have been using mariaDB for a while, and seems to work.