Zahlreiche Probleme nach Update auf 7.12.01

Guten Morgen,

ich habe gestern abend auf unsere Anlage das Update von 7.11.02 auf 7.12.01 durchgeführt und seitdem die folgenden Probleme:

  1. Im Webinterface erscheint nach rund 5 Sekunden der Hinweise “Serverfehler: Der Server reagiert nicht mehr” mit der Schaltfläche “Neu einloggen” . Drücken ich die Schaltfläche, befinde ich mich auf der Übersichtsseite, die mir nach dem Login angezeigt wird.

  2. Die Rufauswertung steht nicht mehr zur Verfügung. Statt dessen erhalte ich die folgende Fehlernmeldung:

Fehler

exception ‘ex_restException’ with message ‘Got result 0’ in /TARGET/SHARE/var/www/mobydickcmd/module/cdr/class/rest_cdr.php:305
Stack trace:
#0 /TARGET/SHARE/var/www/mobydickcmd/module/cdr/controller/ctl210201.php(38): rest_cdr->findRecordsInternal(Array)
#1 /TARGET/SHARE/var/www/mobydickcmd/module/cdr/controller/ctl210201.php(34): ctl210201->refresh()
#2 /TARGET/SHARE/var/www/mobydickcmd/cmn/class/mvc/controller/ex_listController.php(50): ctl210201->query(Array)
#3 /TARGET/SHARE/var/www/mobydickcmd/cmn/class/mvc/controller/ex_multiActionController.php(28): ex_listController->onDefault(Object(ex_defaultRequest))
#4 /TARGET/SHARE/var/www/mobydickcmd/cmn/class/mvc/ex_frontController.php(162): ex_multiActionController->handleRequest(Object(ex_defaultRequest))
#5 /TARGET/SHARE/var/www/mobydickcmd/cmn/class/mvc/ex_frontController.php(97): ex_frontController->handleRequestInternal(‘210201’, Object(ex_defaultRequest))
#6 /TARGET/SHARE/var/www/mobydickcmd/cmn/layout/box_trc.inc.php(40): ex_frontController->handleRequest(‘210201’, Object(ex_defaultRequest))
#7 /TARGET/SHARE/var/www/mobydickcmd/index.php(281): include_once(’/TARGET/SHARE/v…’)
#8 /TARGET/SHARE/var/www/mobydickcmd/index.php(42): outputBodyLoggedIn()
#9 {main}

  1. Der xmppd Dienst läßt sich nicht starten, in /var/log/xmppd/info.log steht dazu folgendes:
    2016.04.26 19:28:21 org.jivesoftware.database.DbConnectionManager - Unable to get a connection from the database pool (attempt 8 out of 10).
    org.postgresql.util.PSQLException: FATAL: database “openfire” does not exist
    at org.postgresql.core.v3.ConnectionFactoryImpl.readStartupMessages(ConnectionFactoryImpl.java:464)
    at org.postgresql.core.v3.ConnectionFactoryImpl.openConnectionImpl(ConnectionFactoryImpl.java:112)
    at org.postgresql.core.ConnectionFactory.openConnection(ConnectionFactory.java:66)
    at org.postgresql.jdbc2.AbstractJdbc2Connection.<init>(AbstractJdbc2Connection.java:125)
    at org.postgresql.jdbc3.AbstractJdbc3Connection.<init>(AbstractJdbc3Connection.java:30)
    at org.postgresql.jdbc3.Jdbc3Connection.<init>(Jdbc3Connection.java:24)
    at org.postgresql.Driver.makeConnection(Driver.java:393)
    at org.postgresql.Driver.connect(Driver.java:267)
    at java.sql.DriverManager.getConnection(DriverManager.java:664)
    at java.sql.DriverManager.getConnection(DriverManager.java:208)
    at org.logicalcobwebs.proxool.DefaultConnectionBuilder.buildConnection(DefaultConnectionBuilder.java:39)
    at org.logicalcobwebs.proxool.Prototyper.buildConnection(Prototyper.java:159)
    at org.logicalcobwebs.proxool.ConnectionPool.getConnection(ConnectionPool.java:211)
    at org.logicalcobwebs.proxool.ProxoolDriver.connect(ProxoolDriver.java:89)
    at java.sql.DriverManager.getConnection(DriverManager.java:664)
    at java.sql.DriverManager.getConnection(DriverManager.java:208)
    at org.jivesoftware.database.DefaultConnectionProvider.getConnection(DefaultConnectionProvider.java:86)
    at org.jivesoftware.database.DbConnectionManager.getConnection(DbConnectionManager.java:124)
    at org.jivesoftware.openfire.XMPPServer.verifyDataSource(XMPPServer.java:760)
    at org.jivesoftware.openfire.XMPPServer.start(XMPPServer.java:486)
    at org.jivesoftware.openfire.XMPPServer.<init>(XMPPServer.java:216)
    at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
    at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
    at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
    at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
    at java.lang.Class.newInstance(Class.java:442)
    at org.jivesoftware.openfire.starter.ServerStarter.start(ServerStarter.java:113)
    at org.jivesoftware.openfire.starter.ServerStarter.main(ServerStarter.java:58)
    2016.04.26 19:28:25 org.jivesoftware.openfire.XMPPServer - Server halted

Laut netstat ist Postgresql aktiv, der obligatorische Neustart der Anlage hat nichts gebracht.

Die gute Nachricht ist, dass wir immerhin telefonieren können.

Gruß,

Stefan

Hallo Stefan,

folge bitte mal den exdjob-Anweisungen aus diesem Thread. Es scheint so als sei die XMPP-Server Datenbankmigration nicht vollständig durchgelaufen.

Grüße,
Jan

Hallo Jan,

das Webinterface funktioniert schon mal wieder - Danke!

Hier die Ausgabe für die Paketliste:

un md-aastra <keine> (keine Beschreibung vorhanden)
ii md-aastra-data 2.05.00.R all Aastra language pack and firmware files
un md-berofix <keine> (keine Beschreibung vorhanden)
un md-billing <keine> (keine Beschreibung vorhanden)
un md-branding-community <keine> (keine Beschreibung vorhanden)
ii md-client 3.07.01.R all Desktop Client for PBX Endusers
ii md-cmd 7.12.01.R all pbx management GUI
un md-connector <keine> (keine Beschreibung vorhanden)
un md-firmware <keine> (keine Beschreibung vorhanden)
ii md-jasperreports 1.05.00.R all Jasperreports Engine
un md-lic <keine> (keine Beschreibung vorhanden)
ii md-moh-basic 3.02.00.R all Some MusicOnHold files
ii md-ovpncerts 1.0.2 all pbx openvpn certs
un md-patton <keine> (keine Beschreibung vorhanden)
un md-prompt-basic <keine> (keine Beschreibung vorhanden)
un md-prompt-de <keine> (keine Beschreibung vorhanden)
un md-prompt-en <keine> (keine Beschreibung vorhanden)
un md-queuemetrics <keine> (keine Beschreibung vorhanden)
un md-snom <keine> (keine Beschreibung vorhanden)
ii md-snom-data 3.08.00.R all Snom language pack and firmware files
ii md-sound 1.01.00.R all pbx audio files
ii md-tapi 2.03.01.R all Windows TAPI Service Provider
ii md-updater 1.12.01.R all Manages package and system updates
ii md-xmppd 2.09.01.R all Messaging Server
ii md-xmppserver 2.11.01.R all pbx to xmpp integration
un md-yealink <keine> (keine Beschreibung vorhanden)
ii md-yealink-data 2.04.00.R all yealink language pack and firmware files

Das zweite Kommando ist nicht erfolgreich:

root@mobydick7:~# exdjob.pl -w -v tsk050399
State: 4 = Error

In /var/log/messages habe ich zudem den folgenden Fehler gefunden:

Apr 27 11:02:33 localhost php: PHP Fatal error: Directive ‘allow_call_time_pass_reference’ is no longer available in PHP in Unknown on line 0

Gruß,

Stefan

Hallo Stefan,

such doch mal in /etc/php5/ nach dieser Direktive.


grep -R allow_call_time_pass_reference /etc/php5

Findet das was?

Grüße,
Jan

Hallo Jan,

/etc/php5/apache2/conf.d/80-mobydick.ini:allow_call_time_pass_reference = On
/etc/php5/cli/conf.d/80-mobydick.ini:allow_call_time_pass_reference = On

Wenn das Webinterface die Einstellung nicht benötigt, dann würde ich sie manuell entfernen.

Gruß,

Stefan

Hallo,

diese Dateien werden von der mobydick automatisch generiert. Es sieht so aus als würde irgendetwas das erfolgreiche Durchlaufen der Migrationsskripte verhindern. Lösche mal diese Einstellung manuell aus den beiden Files und führe dann nochmal den Update-Task aus:


exdjob.pl -w -v tsk050399

Sagt das Job-Log hier irgendetwas interessantes?

Grüße,
Jan

Hi Jan,

als Antwort erhalte ich nur " State: 4 = Error" und das JobLog ist leer.

Dafür finde ich nun in /var/log/messages:

Apr 27 14:15:11 localhost php: PHP Fatal error: Directive ‘magic_quotes_gpc’ is no longer available in PHP in Unknown on line 0

Entfernt, job ausgeführt und wieder " State: 4 = Error" und das JobLog ist leer.

/var/log/messages:

Apr 27 14:23:16 localhost php: PHP Fatal error: Directive ‘register_globals’ is no longer available in PHP in Unknown on line 0

Entfernt, job ausgeführt und nun werden etliche Dinge bearbeitet unter anderem die DB, aber es endet mit

2016-04-27 14:25:20 tsk050399 info : Migrate database
2016-04-27 14:25:20 tsk050399 info : . Starte [/TARGET/SHARE/var/www/mobydickcmd//script/mdc_migrate.php md-cmd]
2016-04-27 14:25:22 tsk050399 info : … Migration failed
2016-04-27 14:25:22 tsk050399 info : . Exit: [1]
2016-04-27 14:25:22 tsk050399 error : Migration failed: md-cmd
2016-04-27 14:25:22 tsk050399 info : . Starte [/etc/init.d/slapd start]
2016-04-27 14:25:22 tsk050399 info : … Starting OpenLDAP: slapd failed!
2016-04-27 14:25:22 tsk050399 info : . Exit: [1]
State: 4 = Error

Auch der xmppd lässt sich noch nicht starten.

Ich wollte mich gerade im Update Bereich unserer Anlage anmelden und nachschauen, ob ggf. noch Paket zu aktualisieren sind.
Hm, meine Login Informationen werden nicht mehr akzeptiert, statt dessen werde ich nach Password und Key gefragt.

Gruß,

Stefan

Hallo,

schau mal bitte das letzte Migrationslog an:


ls -ltr /var/log/mobydick/migration/

Und dann das Unterste (=letzte) File ansehen, vielleicht finden wir so heraus was das Problem ist…

Grüße,
Jan

Hallo Jan,

das vorletzte Log stammt vom Upgrade von gestern abend und enthält den folgenden Fehler:

2016-04-26 17:31:41 migration emergency : Cant find familysetting ldap_password
2016-04-26 17:31:41 migration error : Step [md_cmd_71103_12.php] failed
2016-04-26 17:31:41 migration error : Running md_cmd_71103_12.php failed, aborting.

Das letzte Log stammt von heute 14:25 und sieht so aus:

2016-04-27 14:25:21 cache info : Flush cache: ok
2016-04-27 14:25:21 sql info : Connecting to database
2016-04-27 14:25:21 cache notice : Closing memcache connection
2016-04-27 14:25:21 migration info : Starting Migration for Package md-cmd
2016-04-27 14:25:21 migration info : Found failed 7.11.03/12, resuming migration
2016-04-27 14:25:21 migration info : Next Step is [md_cmd_71103_12.php]
2016-04-27 14:25:21 md_cmd_71103_12 info : changing basic configuration for snom phones
2016-04-27 14:25:22 migration emergency : Cant find familysetting ldap_password
2016-04-27 14:25:22 migration error : Step [md_cmd_71103_12.php] failed
2016-04-27 14:25:22 migration error : Running md_cmd_71103_12.php failed, aborting.
2016-04-27 14:25:22 cache info : Flush cache: ok

An irgendeiner Stelle fehlt offensichtlich das LDAP Passwort. Wie und wo kann ich es dem Upgrade mitgeben?

Gruß,

Stefan

Hallo,

nein, das ganze hat mit den Telefon-Basiskonfigurationen zu tun. Das Skript, das bei dir fehlschlägt sollte das LDAP-Passwort das auf die Telefone Provisioniert wird in den Basiskonfigurationen auf “leer” setzen, damit es zu den LDAP-Settings ab der 7.11 passt.

Gibt es in deinem System die Settings “ldap_password” bzw. “ldap_username” noch in den Basiskonfigurationen für Snom. (Und weil es bei yealink theoretisch zu einem ähnlichen Problem kommen kann, gleich noch “ldap.user” und “ldap.password” prüfen)? Wenn ja, welchen Wert haben diese?

Wenn nein, leg die Settings bitte an, und versuche dann den Migrationstask noch einmal.

Und: Von welcher Version aus versuchst du das Update eigentlich? 7.10.X?

Grüße,
Jan

Hi Jan,

das Update startete auf einer 7.11.02.
7.11.03 hatte ich ausgelassen, nachdem ich von Probleme, unter anderem mit den Notrufnummern, gelesen hatte.

ldap_password und ldap_username sind geschützt und leer.
Bei ldap.password und ldap.user ist keine Auswirkung hinterlegt und die Werte sind leer.

Gruß,

Stefan

Hallo Stefan,

das kann ich mir grad nicht so recht erklären. Ich glaube es ist besser wenn wir das vom Forum in einen Support-Fall verlagern…

Grüße,
Jan

Hallo Jan,

es gibt Fortschritte:

Nachdem ich in dr /etc/ldap/slapd.conf die Zeile

insentry_query “”

gegen

insentry_stmt “”

ausgetauscht habe, ließ sich der LDAP-Server wieder starten.
Dann habe ich in der SNOM Basiskonfiguration und in einer individuellen Konfiguration für ein SNOM 370 ldap_password auf “secret” gesetzt und ldap_user auf “cn=admin,dc=mobydick”.
Danach lief der Job “exdjob.pl -w -v tsk050399” durch und der XMPPD startet wieder.
Und auch die Rufauswertung funktioniert nun wieder.

Damit scheint die Migration doch noch erfolgreich abgeschlossen zu sein.

Gruß,

Stefan

Hallo Stefan

…ldap_password auf “secret” gesetzt und ldap_user auf “cn=admin,dc=mobydick”…

Das könnte meiner Meinung nach die Hauptursache gewesen sein. Ein lauffähiger LDAP-Server ist zum migrieren eigentlich nicht erforderlich.

Grüße,
Jan