SNOM Firmware upgrade über Provisioning
Stephan
wir haben frische SNOM 3xx Telefone (Firmware 7.3.30) bekommen. Nun
möchte ich, dass sich alle Telefone auf die in der Gemeinschaft
hinterlegte Firmware 8.4.32 (mit get-firmware.sh runtergeladen)
upgraden. Ich habe dazu in der gemeinschaft.php $SNOM_PROV_FW_UPDATE
auf true gesetzt. Sollte danach ein Neustart der Telefone reichen? Bei
mir hat's jedenfalls nicht funktioniert. Auch der Eintrag
$SNOM_PROV_FW_DEFAULT_370='8.4.32'; hat nix gebracht.
Was muß ich tun? Ich will nicht mit "gs-phones-firmware-upgrade" jedes
Telefon einzeln ansprechen.
Grüße,
Stephan
Philipp Kempgen
Mit gs-phones-firmware-upgrade lassen sich auch mehrere Telefone
ansprechen. Also erstmal an einigen wenigen ausprobieren und dann
z.B.
gs-phones-firmware-upgrade --by-host=1 --vers=default
Dieser Provisioning-Job läßt sich so anzeigen:
gs-prov-jobs-get
Dann die Telefone neustarten, entweder manuell oder per
gs-prov-phone-checkcfg --all=yes
Am besten nebenbei in einem Terminal-Fenster das Gemeinschaft-Log
mitlaufen lassen:
https://github.com/amooma/GemeinschaftPBX/wiki/Probleme-analysieren
Philipp
Eichler Stephan
- Um alle Telefone bei jedem Neustart zu updaten, wenn ein Update bereit liegt, muß man einmalig folgendes tun:
- gs-phones-firmware-upgrade --by-host=1 --vers=default (Dabei muß der Host der Gemeinschaft die Id 1 haben!)
- Damit überhaupt erkannt wird, dass ein Update bereit liegt, muß man jedesmal folgendes tun:
- in /opt/gemeinschaft/htdocs/prov/snom/sw das script get-firmware.sh so anpassen, das die gewünschte FW-Version runtergeladen wird
- get-firmware.sh laufen lassen
- in gemeinschaft.php $SNOM_PROV_FW_DEFAULT_3... die gewünschte FW-Version eintragen.
--
-
Philipp Kempgen
Du hast recht, das könnte etwas intuitiver sein, ist allerdings bei
großen Installationen ein recht mächtigiges Werkzeug und eignet sich
zum automatisierten Aufruf aus anderen Applikationen heraus.
Bei den Skripten bekommt man mit --help oder -h oder -? eine Liste
der möglichen Parameter.
Eine Liste der Gemeinschaft-Hosts bekommt man mit gs-hosts-get.
Oder man kann bei
gs-phones-firmware-upgrade --by-host=...
statt der ID auch die IP-Adresse angeben.
Ein Telefon ist in Gemeinschaft entweder auf dem Standard-Firmware-
Upgrade-Plan ("default") oder manuell.
default heißt: Die in per $..._PROV_FW_DEFAULT_... eingestellte
Firmware-Version.
Man kann per
gs-phones-firmware-upgrade ... --vers=...
ein Telefon auch auf eine andere Firmware-Version bringen.
Es wechselt dann von "default" in den manuellen Upgrade-Plan.
(Per --vers=default kommt man wieder zurück.)
Bei den Firmware-Provisioning-Jobs lassen sich beispielsweise auch
Zeiten angeben, sodaß Firmware-Upgrades z.B nur Samstags in der
Nacht durchgeführt werden statt einfach mitten am Tag.
Ein Provisioning-Job alleine macht erstmal nichts. Er bedeutet:
Wenn sich in der vorgegebenen Zeit ein betreffendes Telefon meldet,
dann bekommt es die eingestellte Firmware-Version.
Damit sich das Telefon meldet muß es normalerweise rebootet werden.
Das geschieht z.B. mit gs-prov-phone-checkcfg, das man in einer
großen Installation z.B. auch in einem Cron-Job aufrufen könnte.
Ich hoffe das bringt etwas Licht in die Sache.
Philipp
Eichler Stephan schrieb (am 25.11.11 08:39):
Stephan
Die Liste der möglichen Parameter bekommt man auch, wenn man das
Script ohne Parameter aufruft. Da habe ich aber nicht gesehen, dass --
by-host auch eine ID akzeptiert und ich eigentlich dachte, dass mit IP
die IP des Telefons gemeint ist. Die Erklärung zur Bedeutung der
Parameter reicht ja von recht spärlich bis nicht vorhanden. :-(
Nochmal zur Beseitigung der letzten Klarheit: Auch wenn ich einem Job
Zeiten (bzw. einen Zeitraum) mitgebe, macht der nix von allein. Das
Telefon muß in diesem Zeitraum neu booten, um vom Job die eingestellte
FW übergeholfen zu bekommen. Richtig?
Jetzt habe ich das mal mit den neuen Erkenntnissen ausprobiert und
glaube gleich einen Bug in dem Script gefunden zu haben:
Der Aufruf "gs-phones-firmware-upgrade --by-host=1 --vers=default"
bringt bei mir: "Failed to insert jobs."
Soweit ich das im Script verfolgt habe, passiert folgendes:
1. "--vers=default" heisst: "$fw_manual_update = 0" (Zeile 215)
2. d.h. kein "INSERT INTO prov_jobs...." (Zeile 221)
3. d.h. "count($phones)>0 && $num_ok === 0" (Zeile 260)
4. d.h. "Failed to insert jobs."
Was nun?
Grüße,
Stephan
P.S.: Ich schreibe meine Antworten immer über den zitierten Text, weil
ich die mit dem Mail-Programm meines Macs erstelle. Das blendet dann
den zitierten Text so schön aus, wenn er unter der Antwort steht.
Philipp Kempgen
>
> Die Liste der möglichen Parameter bekommt man auch, wenn man das
> Script ohne Parameter aufruft. Da habe ich aber nicht gesehen, dass --
> by-host auch eine ID akzeptiert und ich eigentlich dachte, dass mit IP
> die IP des Telefons gemeint ist. Die Erklärung zur Bedeutung der
> Parameter reicht ja von recht spärlich bis nicht vorhanden. :-(
Zu den Skripten gibt es auch jeweils Doku im DocBook-Format in
/opt/gemeinschaft/doc/de/docbook/SKRIPTNAME.xml
Bzw. kann auch als man-Page generiert werden (sofern die entsprechenden
Tools dafür auf dem System vorhanden sind).
cd /opt/gemeinschaft/doc/de/
make man
Noch schöner wäre es IMHO die Doku auf einer Webseite zu haben.
Ja, manches könnte ausführlicher dokumentiert sein.
>
> Nochmal zur Beseitigung der letzten Klarheit: Auch wenn ich einem Job
> Zeiten (bzw. einen Zeitraum) mitgebe, macht der nix von allein. Das
> Telefon muß in diesem Zeitraum neu booten, um vom Job die eingestellte
> FW übergeholfen zu bekommen. Richtig?
Ja, das Telefon muß booten oder sich aus einem anderen Grund beim
Provisioning melden (je nach Telefon z.B. beim Ab- und Anstecken ans
Netzwerkkabel).
>
> Jetzt habe ich das mal mit den neuen Erkenntnissen ausprobiert und
> glaube gleich einen Bug in dem Script gefunden zu haben:
> Der Aufruf "gs-phones-firmware-upgrade --by-host=1 --vers=default"
> bringt bei mir: "Failed to insert jobs."
> Soweit ich das im Script verfolgt habe, passiert folgendes:
> 1. "--vers=default" heisst: "$fw_manual_update = 0" (Zeile 215)
> 2. d.h. kein "INSERT INTO prov_jobs...." (Zeile 221)
> 3. d.h. "count($phones)>0 && $num_ok === 0" (Zeile 260)
> 4. d.h. "Failed to insert jobs."
>
> Was nun?
Ich habe gerade kein Gemeinschaft-3-Test-System greifbar und weiß es
leider nicht auswendig. Das muß jemand anders beantworten.
Scheint nur eine irreführende Ausgabe zu sein, sollte aber so
funktionieren.
Philipp Kempgen
--
AMOOMA GmbH - Bachstr. 124 - 56566 Neuwied --> http://www.amooma.de
Geschäftsführer: Stefan Wintermeyer, Handelsregister Montabaur B14998
Bücher: http://das-asterisk-buch.de - http://ruby-auf-schienen.de
--
Stephan
"default"-Update-Jobs generiert. Nach einem Neustart hat das Telefon
auch die neue FW-Version. Soweit danke für die Hilfe, hatte schon
Angst vor den 100 Telefonen, die manuell geupdatet werden müssen!
Aber, da ich alles mache, was mir gesagt wird, habe ich auch das
gs.log beobachtet. Da stehen nun merkwürdige Dinge drin:
2011-11-25 12:32:17 [note ] htdocs/prov/snom/sw-update.php: 279: The
firmware version (07.03.301) differs from the default version
(08.04.32), scheduling an upgrade ...
2011-11-25 12:32:17 [note ] htdocs/prov/snom/sw-update.php: 362: Phone
00041326F214: Upgrade app 07.03.301 -> 08.04.32
2011-11-25 12:32:17 [note ] htdocs/prov/snom/sw-update.php: 105: Snom
00041326F214 (370, user 54): Update file: "snom370-08.04.32.bin"
2011-11-25 14:38:58 [note ] htdocs/prov/snom/sw-update.php: 279: The
firmware version (08.04.321) differs from the default version
(08.04.32), scheduling an upgrade ...
2011-11-25 14:38:58 [note ] htdocs/prov/snom/sw-update.php: 362: Phone
00041326F214: Upgrade app 08.04.321 -> 08.04.32
2011-11-25 14:38:58 [note ] htdocs/prov/snom/sw-update.php: 105: Snom
00041326F214 (370, user 54): Update file: "snom370-08.04.32.bin"
2011-11-25 16:42:24 [note ] htdocs/prov/snom/sw-update.php: 279: The
firmware version (08.04.321) differs from the default version
(08.04.32), scheduling an upgrade ...
2011-11-25 16:42:24 [note ] htdocs/prov/snom/sw-update.php: 362: Phone
00041326F214: Upgrade app 08.04.321 -> 08.04.32
2011-11-25 16:42:24 [note ] htdocs/prov/snom/sw-update.php: 105: Snom
00041326F214 (370, user 54): Update file: "snom370-08.04.32.bin"
2011-11-25 16:49:43 [note ] htdocs/prov/snom/sw-update.php: 279: The
firmware version (08.04.321) differs from the default version
(08.04.32), scheduling an upgrade ...
2011-11-25 16:49:43 [note ] htdocs/prov/snom/sw-update.php: 352: Phone
00041326F214: Bad new app vers. 00.00.00
2011-11-25 16:49:43 [note ] htdocs/prov/snom/sw-update.php: 362: Phone
00041326F214: Upgrade app 08.04.321 -> 08.04.32
2011-11-25 16:49:43 [note ] htdocs/prov/snom/sw-update.php: 105: Snom
00041326F214 (370, user 54): Update file: "snom370-08.04.32.bin"
Was ich daraus lese:
1. Das Telefon schaut irgendwie ca. alle 2h nach einer neuen FW. Warum
auch immer, Update-Jobs gab es bis ca. 16:00 Uhr keine!
2. Das Telefon "denkt" es hätte die Version 08.04.321 und scheduled
alle 2h ein upgrade.
Zu 2.: Das ist nicht das Telefon, das ist ein Bug in der
Gemeinschaftssoftware: In /htdocs/prov/snom/sw-update.php (Zeile 147)
wird von einem falschen UserAgent ausgegangen. Angenommen wird ein
Format, wir z.B. "snom370 8.4.32", mein Telefon sendet aber "snom370
8.4.32 1.1.3-u"
Puh! Hoffentlich finde ich alle Fehler bevor mein Chef sein Telefon
bekommt! ;-)
Grüße,
Stephan