Sv translation | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
VoraussetzungRequirementThe system must first be updated to a version with Das System muss vorher auf eine Version mit MySQL 8.x geupdatet werden (Release 3.15 bis to 3.17). Vorbereitung für die AktualisierungPreparation for the updateWith every update there is a golden rule that must be strictly followed regardless of the customer's wishesBei jeder Aktualisierung gibt es eine goldene Regel, die unabhängig von den Wünschen des Kunden strikt befolgt werden muss:
Authoritative Share BestimmenBei manchen Installationen, ist das File-Share auf ein System, der vom Kunden bereitgestellt wird. In diesen Fall erfolgt das Checkout der Repositories lokal auf den Load-Balancer auf den Non-Authoritative Share, die Dateien werden aber später auf den "Authoritative" File-Share kopiert.
Determine Authoritative ShareIn some installations, the file share is on a system provided by the customer. In this case, the repositories are checked out locally to the load balancer on the non-authoritative share, but the files are later copied to the "authoritative" file share. After changes should be checked for the Authoritative File-ShareNach Änderungen sollte auf den Authoritative File-Share geprüft werden. Authoritative File-ShareDieser ist This is /home/jtel/shared Non-Authoritative File-ShareDieser ist This is /srv/jtel/shared Bestimmen obDetermine if AuthoritativeWenn If /home/jtel/shared auf den Load-Balancer von einem Fremdsystem gemountet ist, dann ist es in der Regel nicht authoritative.is mounted on the load balancer from a third-party system, it is usually not authoritative. You can easily determine this by creating a file on Dies kann man einfach bestimmen, indem man eine Datei auf /srv/jtel/shared erzeugt. Erscheint dies nicht shared. If this does not appear in /home/jtel/shared, so ist then /srv/jtel/shared nicht is not authoritative. DatensicherungEs sollte unbedingt eine Datensicherung angefertigt werden. Das MINIMUM ist dass die Datenbank gesichert wird, und das Datenverzeichnis gesichert wird, dies sollte jedoch nur die Notlösung sein. Besser ist ein Snapshot aller beteiligten virtuellen Maschinen, im Kaltzustand (heruntergefahren). Die Gefahr besteht, dass wenn ein Snapshot im laufenden Betrieb gezogen wird (insbesondere der Datenbankmaschinen), dass dieser nicht konsistent ist. Manuelle SicherungData backupA data backup should unconditionally be made. The MINIMUM is that the database is backed up and the data directory is backed up, but this should only be a stopgap solution. Better is a snapshot of all virtual machines involved, in cold state (shut down). There is a risk that if a snapshot is taken during operation (especially of the database machines), it may not be consistent. Manual backupDienste Stoppen
Backup database (aufon DBMastermaster)Das entsprechende Passwort bei <password> eintragenEnter the corresponding password at <password>:
Backup DataVerzeichnis sichernDies kann über den Windows Explorer oder ein entsprechender cp Befehl auf den Linux erfolgen. GIT Status merkenDirectoryThis can be done via the Windows Explorer or a corresponding cp command on the Linux. Remember GIT status (Authoritative Share)Vom Load-Balancer aus, den GIT Status prüfenFrom the load balancer, check the GIT status:
Ggf. müssen hier die Verzeichnisse ebenso in die Datensicherung mit aufgenommen werden, insbesondere dann, wenn Patches eingespielt wurden, sodass lokale Änderungen erfolgt sind. Weitere Komponenten sichernSind weitere Komponenten vom Update betroffen, wie der 8-Server selbst, oder der JBOSS Server (nicht die Webanwendung), sollten diese Komponenten vorab auch gesichert werden.
If necessary, the directories must also be included in the data backup, especially if patches have been applied so that local changes have been made. Securing additional componentsIf other components are affected by the update, such as the 8 server itself, or the JBOSS server (not the web application), these components should also be backed up in advance. Snapshot BackupThis is done via the VMWare console, or Hyper-V console. This is usually done by the customer. Confirmation
RestoreSnapshotsThe snapshots are all reactivated and booted. There should be normal operation with the old software. Manual RestorationWith all services stopped, restore the database. Enter the corresponding password at <password> Snapshot SicherungDies erfolgt über die VMWare Konsole, oder Hyper-V Konsole. Dies wird üblicherweise durch den Kunden durchgeführt. Bestätigung
RücksicherungSnapshotsDie Snapshots werden alle wieder aktiviert, und hochgefahren. Es sollte ein normaler Betrieb mit den alten Software-Stand herrschen. Manuelle RücksicherungMit allen Diensten gestopped, die Datenbank zurücksichern. Das entsprechende Passwort bei <password> eintragen:
Parallel dazu, kann das alte Data Verzeichnis zurückgespielt werden. In parallel, the old data directory can be restored. Further steps may be necessary (restore GIT repositories, restore 8 servers, ...) depending on which components were affected by the updateGgf. sind weitere Schritte erforderlich (GIT Repositories zurücksichern, 8-Server zurücksichern, ...) je nach dem welche Komponenten beim Update betroffen waren.
Die Aktualisierung des SystemsEs sei hier noch mal erwähnt: alle jtel-Dienste des Systems müssen herunter gefahren sein. Danach kann mit der Aktualisierung begonnen werden. Die Schritte erfolgen in der hier dokumentierten Reihenfolge Aktualisierung der Software auf dem STORE
The updating of the systemIt should be mentioned again: all jtel services of the system must be shut down. After that the update can be started. The steps are performed in the order documented here Updating the software on the STOREThis step must be performed as user "jtel"Dieser Schritt muss als Benutzer "jtel" erfolgen.
Prüfung ob Änderungen / Patches vorhanden sind
Check if changes / patches are availableBefore updating the software, you should check whether files in the respective directory have been changedBevor die Software aktualisiert wird, sollte noch geprüft werden, ob im jeweiligen Verzeichnis Dateien geändert wurden.
Here is an example based on the software directory JTELCarrierPortalHier ein Beispiel basierend auf das Software-Verzeichnis JTELCarrierPortal:
If this indicates that files have been modified, caution is advised. The project engineer must first check whether the changes are local bug fixes that have been incorporated into the release. If this is the case, the changes can be deleted before updating. If this is not done, the update may failWird hier angezeigt, dass Dateien verändert wurden, ist Vorsicht geboten. Der Projektingenieur muss vorher prüfen, ob die Änderungen lokale Bugfixe sind, die inzwischen ins Release eingeflossen sind. In diesem Falle können die Änderungen vor der Aktualisierung gelöscht werden. Tut man dies nicht, so kann die Aktualisierung scheitern!
Eine allgemeine Vorgehensweise kann in einem solchen Fall aber nicht beschrieben werden. Hier muss von Fall zu Fall geprüft werden, wie vorgegangen wird. However, a general procedure cannot be described in such a case. In this case, the procedure must be checked on a case-by-case basis. If file mode changes should be ignored, the following command can be usedFalls Datei-Modus Änderungen ignoriert werden sollen, kann folgender Befehl genutzt werden:
Aktualisierung der Repositories (Immer auf Non-Authoritative Share)Updating the repositories (always on non-authoritative share)The following command sequence updates all software directories to the latest version of the respective chosen releaseDie folgende Befehlssequenz aktualisiert alle Software-Verzeichnisse auf dem letzten Stand des jeweilig eingestellten Releases.
Falls Fehler beim GIT auftreten, beispielsweiseIf errors occur in GIT, for example: Merge-Konflikt Conflict in (Dateinamefile name) Oder fatal: Verweigere den Merge von nicht zusammenhängenden Historien.Deny the merge of unrelated histories. the local repository must be reset. This can be done as follows (example for muss das lokale Repository resettet werden. Dies kann wie folgt (Beispiel für stable-3.18 auf on JTELCarrierPortal) geschehen:
Auschecken des gewünschten ReleasesChecking out the desired releaseAfter the GIT PULL is done, the corresponding release must be checked out if a release other than git status is desiredNachdem der GIT PULL erfolgt ist, muss das entsprechende Release ausgechecked werden, falls ein anderer als mit git status gewünscht ist.
Copy files to Authoritative SharekopierenOnly if there is an Nur wenn es ein Authoritative / Non-Authoritative share gibt. Dies geschieht mit folgender SkriptThis is done with the following script
Aktualisierungsskripte laufen lassenRun update scriptsThe following update script makes all necessary changes. This is executed as root or jtel with sudo. Here with Folgender Aktualisierungsskript führt alle notwendigen Änderungen durch. Dies wird als root oder jtel mit sudo ausgeführt. Hier mit jtel user:
Ggf. wird man zuerst nach den sudo Passwort gefragt. Das Skript fragt nach den entsprechenden Master Datenbank, Benutzer, Passwort, und Name des Kundenverzeichnisses indem ggf. spezifische Software für den Kunden liegt. You may be asked for the sudo password first. The script asks for the corresponding master database, user, password, and name of the customer directory where specific software for the customer may be located. The questions can be answered, usually with the following answers, knowledge of <password> for the database assumedDie Fragen können, in der Regel mit folgende Antworten beantwortet werden, Kenntnis von <password> für die Datenbank vorausgesetzt:
Falls kein Customer Directory vorhanden ist, kann dies leer gelassen werden. Das Vorhandensein von Kundenspezifische Software kann mit If there is no customer directory, this can be left empty. The presence of custom software can be checked with ls /home/jtel/shared geprüft werden - dort die Namen der Verzeichnisse anschauen. Nur den Namen des Verzeichnisses angeben! Beispielsweise acme - there you can see the names of the directories. Enter only the name of the directory! For example acme The update is then carried outAnschließend wird das Update durchgeführt.
Binaries Herunterladen
Download BinariesThe binaries are downloaded with the following commandDie Binaries werden mit folgenden Befehl heruntergeladen:
Update of the Platform UDPListenersListenerMasterDatenbankenDatabasesBei Release With release 3.18 und höherand higher, wird Java 8 verwendetis used. Das The (vorhandeneexisting) Java 7 muss deinstalliert werden, und Java 8 wird installiert.must be uninstalled and Java 8 will be installed. We use the openjdk so that it remains updateable under LinuxWir verwenden den openjdk, sodass es unter Linux Updatefähig bleibt.
Die Aktualisierung des Platform UDP Listeners muss als Benutzer "root" ausgeführt werden und erfolgt auf die Master Datenbanken durch Eingabe folgendem BefehlsThe update of the Platform UDP Listener must be executed as user "root" and is performed on the master databases by entering the following command:
Dieser Befehl aktualisiert den Listener und startet ihn. Der Erfolg kann durch Sichtung der Datei This command updates the listener and starts it. The success can be checked by viewing the file /home/jtel/PlatformUDPlistener/log/listener.log geprüft werden.
Telefonieservern
Telephony serversHere you have to check if Java 8 is installed. If necessary, download Java 8 from one of the sources here (these are BCL licensed versions, i.e. license-freeHier ist zu prüfen ob Java 8 installiert ist. Ggf. Java 8 von einer der Quellen hier herunterladen (dies sind BCL lizenzierte Versionen, also Lizenzfrei):
Das Start-Skript für den Platform-Listener kopiert die neue Version des Listeners selbstThe start script for the platform listener copies the new version of the listener itself.
Aktualisierung der WEB ServerDer JBOSS Server wird komplett ersetzt durch ein Wildfly Server. Hazelcast Konfiguration sichern
Updating the WEB serversThe JBOSS server is completely replaced by a Wildfly server. Backup Hazelcast configurationIf no backup already existsFalls keine Sicherung bereits vorhanden:
Uninstalling JBOSS Serverundand Java 7DeinstallierenAls As root:
Install Java 8undand WildflyInstallieren
Configure WildflykonfigurierenDie The hazelcast.xml muss kopiert werden, und die Standardeinstellungen für die Datenbank müssen angepasst werden.must be copied and the default settings for the database must be adjusted. In the following replace <password> please accordinglyIm folgenden <password> bitte entsprechend ersetzen:
Aktualisierung der PortalsoftwareUpdating the portal softwareThe update of the portal software must be executed as user "root" on the web server and is done by entering the following commandDie Aktualisierung der Portalsoftware muss als Benutzer "root" auf dem Webserver ausgeführt werden und erfolgt durch Eingabe folgendem Befehls:
Dieser Befehl aktualisiert die Portalsoftware und startet den wildfly Server. Der Erfolg kann durch Sichtung der Datei This command updates the portal software and starts the wildfly server. The success can be checked by viewing the file /home/jtel/wildfly-current/standalone/log/server.log geprüft werden. Dort sollten in der Log-Datei folgende Einträge zu sehen sein, wenn die Aktualisierung erfolgreich war There you should see the following entries in the log file if the update was successful: Aktualisierung des 8ServersDie Aktualisierung des 8Server erfolgt im Windows-Explorer mittels GIT. Hierfür wird mit einem Rechtsklick auf das Verzeichnis C:\8Server\deploy ein GIT Pull durchgeführt, und auf das gewünschte Version nach dem Pull gewechselt.
Möchte man nicht auf die letzte Version, sondern auf eine spezifische Version aktualisieren, erfolgt dies Über "git checkout" mit Angabe des Releases. Nach dem Aktualisieren, muss die Version dann installiert werden. Bei einem Daemon-Server erfolgt dies mit dem Befehl: Translations Ignore |
Bei einem Telefonie-Server mit Aculab Media Service erfolgt dies mit folgendem Befehl: Translations Ignore |
Im Anschluss kann der 8Server gestartet werden. Aktualisierung der KonnektorenGrundsätzlich gilt: die entsprechenden Dateien aus dem Software-Verzeichnis im STORE müssen ins Zielverzeichnis kopiert werden. Diese kommen in der Regel aus dem Bereich
Abschließende ArbeitenIst die Aktualisierung beendet und die Anlage ohne Fehler wieder hochgefahren, sind folgende Aufgaben zwingend auszuführen:
Updating Client MessengerIf Chat Server is installed. For jtel portal versions >= 3.25, make sure to edit systemd and/or init.d: If you are using init.d:
If you are using systemd:
Then update:
Update of the 8ServerThe 8Server is updated in Windows Explorer using GIT. To do this, right-click on the directory C:\8Server\deploy to perform a GIT pull and switch to the desired version after the pull.
If you do not want to update to the last version, but to a specific version, you can do this via "git checkout", by indicating the release. After updating, the version must then be installed. For a daemon server, this is done with the command:
For a telephony server with Aculab Media Service, this is done with the following command:
Afterwards the 8Server can be started. Updating the connectorsBasically: the corresponding files from the software directory in the STORE must be copied into the target directory. These usually come from JTELCarrierPortal/WebServices/Install
Final workOnce the update has been completed and the system restarted without errors, the following tasks must be performed:
|
Sv translation | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
VoraussetzungDas System muss vorher auf eine Version mit MySQL 8.x geupdatet werden (Release 3.15 bis 3.17). Vorbereitung für die AktualisierungBei jeder Aktualisierung gibt es eine goldene Regel, die unabhängig von den Wünschen des Kunden strikt befolgt werden muss:
Authoritative Share BestimmenBei manchen Installationen, ist das File-Share auf ein System, der vom Kunden bereitgestellt wird. In diesen Fall erfolgt das Checkout der Repositories lokal auf den Load-Balancer auf den Non-Authoritative Share, die Dateien werden aber später auf den "Authoritative" File-Share kopiert. Nach Änderungen sollte auf den Authoritative File-Share geprüft werden. Authoritative File-ShareDieser ist /home/jtel/shared Non-Authoritative File-ShareDieser ist /srv/jtel/shared Bestimmen ob AuthoritativeWenn /home/jtel/shared auf den Load-Balancer von einem Fremdsystem gemountet ist, dann ist es in der Regel nicht authoritative. Dies kann man einfach bestimmen, indem man eine Datei auf /srv/jtel/shared erzeugt. Erscheint dies nicht in /home/jtel/shared, so ist /srv/jtel/shared nicht authoritative. DatensicherungEs sollte unbedingt eine Datensicherung angefertigt werden. Das MINIMUM ist dass die Datenbank gesichert wird, und das Datenverzeichnis gesichert wird, dies sollte jedoch nur die Notlösung sein. Besser ist ein Snapshot aller beteiligten virtuellen Maschinen, im Kaltzustand (heruntergefahren). Die Gefahr besteht, dass wenn ein Snapshot im laufenden Betrieb gezogen wird (insbesondere der Datenbankmaschinen), dass dieser nicht konsistent ist. Manuelle SicherungDienste Stoppen
Datenbank sichern (auf DB Master)Das entsprechende Passwort bei <password> eintragen:
Data Verzeichnis sichernDies kann über den Windows Explorer oder ein entsprechender cp Befehl auf den Linux erfolgen. GIT Status merken (Authoritative Share)Vom Load-Balancer aus, den GIT Status prüfen:
Ggf. müssen hier die Verzeichnisse ebenso in die Datensicherung mit aufgenommen werden, insbesondere dann, wenn Patches eingespielt wurden, sodass lokale Änderungen erfolgt sind. Weitere Komponenten sichernSind weitere Komponenten vom Update betroffen, wie der 8-Server selbst, oder der JBOSS Server (nicht die Webanwendung), sollten diese Komponenten vorab auch gesichert werden. Snapshot SicherungDies erfolgt über die VMWare Konsole, oder Hyper-V Konsole. Dies wird üblicherweise durch den Kunden durchgeführt. Bestätigung
RücksicherungSnapshotsDie Snapshots werden alle wieder aktiviert, und hochgefahren. Es sollte ein normaler Betrieb mit den alten Software-Stand herrschen. Manuelle RücksicherungMit allen Diensten gestopped, die Datenbank zurücksichern. Das entsprechende Passwort bei <password> eintragen:
Parallel dazu, kann das alte Data Verzeichnis zurückgespielt werden. Ggf. sind weitere Schritte erforderlich (GIT Repositories zurücksichern, 8-Server zurücksichern, ...) je nach dem welche Komponenten beim Update betroffen waren.
Die Aktualisierung des SystemsEs sei hier noch mal erwähnt: alle jtel-Dienste des Systems müssen herunter gefahren sein. Danach kann mit der Aktualisierung begonnen werden. Die Schritte erfolgen in der hier dokumentierten Reihenfolge Aktualisierung der Software auf dem STOREDieser Schritt muss als Benutzer "jtel" erfolgen.
Prüfung ob Änderungen / Patches vorhanden sindBevor die Software aktualisiert wird, sollte noch geprüft werden, ob im jeweiligen Verzeichnis Dateien geändert wurden.
Hier ein Beispiel basierend auf das Software-Verzeichnis JTELCarrierPortal: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Sv translation | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
VoraussetzungDas System muss vorher auf eine Version mit MySQL 8.x geupdatet werden (Release 3.15 bis 3.17). Vorbereitung für die AktualisierungBei jeder Aktualisierung gibt es eine goldene Regel, die unabhängig von den Wünschen des Kunden strikt befolgt werden muss:
Authoritative Share BestimmenBei manchen Installationen, ist das File-Share auf ein System, der vom Kunden bereitgestellt wird. In diesen Fall erfolgt das Checkout der Repositories lokal auf den Load-Balancer auf den Non-Authoritative Share, die Dateien werden aber später auf den "Authoritative" File-Share kopiert. Nach Änderungen sollte auf den Authoritative File-Share geprüft werden. Authoritative File-ShareDieser ist /home/jtel/shared Non-Authoritative File-ShareDieser ist /srv/jtel/shared Bestimmen ob AuthoritativeWenn /home/jtel/shared auf den Load-Balancer von einem Fremdsystem gemountet ist, dann ist es in der Regel nicht authoritative. Dies kann man einfach bestimmen, indem man eine Datei auf /srv/jtel/shared erzeugt. Erscheint dies nicht in /home/jtel/shared, so ist /srv/jtel/shared nicht authoritative. DatensicherungEs sollte unbedingt eine Datensicherung angefertigt werden. Das MINIMUM ist dass die Datenbank gesichert wird, und das Datenverzeichnis gesichert wird, dies sollte jedoch nur die Notlösung sein. Besser ist ein Snapshot aller beteiligten virtuellen Maschinen, im Kaltzustand (heruntergefahren). Die Gefahr besteht, dass wenn ein Snapshot im laufenden Betrieb gezogen wird (insbesondere der Datenbankmaschinen), dass dieser nicht konsistent ist. Manuelle SicherungDienste Stoppen Tip | | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Translations Ignore |
Code Block |
---|
taskkill /im robot5.exe |
Alle Webserver, die JBOSS Server stoppen:
Code Block |
---|
service jboss stop |
Alle DB Master:
Code Block |
---|
service jtel-listener stop |
Alle Chat Server:
Code Block |
---|
service jtel-clientlistener stop |
Datenbank sichern (auf DB Master)
Das entsprechende Passwort bei <password> eintragen:
Code Block | ||||
---|---|---|---|---|
| ||||
su jtel
cd
mkdir -p /home/jtel/shared/Backup
mysqldump -u root -p<password> --add-drop-database --add-drop-table --events --routines --triggers --databases JTELWeb JTELStats JTELStats2 JTELLog | gzip > /home/jtel/shared/Backup/backup-$(hostname -s)-database-$(date +%F-%H%M%S).sql.gz |
Data Verzeichnis sichern
Dies kann über den Windows Explorer oder ein entsprechender cp Befehl auf den Linux erfolgen.
GIT Status merken (Authoritative Share)
Vom Load-Balancer aus, den GIT Status prüfen:
Code Block | ||||
---|---|---|---|---|
| ||||
cd /home/jtel/shared/JTEL
git status
git rev-parse HEAD
(ausgaben sichern)
cd /home/jtel/shared/JTELCarrierPortal
git status
git rev-parse HEAD
(ausgaben sichern)
# IF A custom directory exists
cd /home/jtel/shared/Customer_Directory
git status
git rev-parse HEAD
(ausgaben sichern) |
Ggf. müssen hier die Verzeichnisse ebenso in die Datensicherung mit aufgenommen werden, insbesondere dann, wenn Patches eingespielt wurden, sodass lokale Änderungen erfolgt sind.
Weitere Komponenten sichern
Sind weitere Komponenten vom Update betroffen, wie der 8-Server selbst, oder der JBOSS Server (nicht die Webanwendung), sollten diese Komponenten vorab auch gesichert werden.
Snapshot Sicherung
Dies erfolgt über die VMWare Konsole, oder Hyper-V Konsole. Dies wird üblicherweise durch den Kunden durchgeführt.
Bestätigung
Warning | ||
---|---|---|
| ||
Erst wenn die Datensicherung erfolgt ist (ggf. vom Kunden bestätigen lassen!), weitermachen! |
Rücksicherung
Snapshots
Die Snapshots werden alle wieder aktiviert, und hochgefahren. Es sollte ein normaler Betrieb mit den alten Software-Stand herrschen.
Manuelle Rücksicherung
Mit allen Diensten gestopped, die Datenbank zurücksichern. Das entsprechende Passwort bei <password> eintragen:
Code Block | ||||
---|---|---|---|---|
| ||||
cp /home/jtel/shared/Backup/backup-acd-dbm-database-2016-06-30-293211.sql.gz .
gunzip backup-acd-dbm-database-2016-06-30-293211.sql.gz
mysql -u root -p<password> -e"backup-acd-dbm-database-2016-06-30-293211.sql" |
Parallel dazu, kann das alte Data Verzeichnis zurückgespielt werden.
Ggf. sind weitere Schritte erforderlich (GIT Repositories zurücksichern, 8-Server zurücksichern, ...) je nach dem welche Komponenten beim Update betroffen waren.
Info | ||
---|---|---|
| ||
Mach lieber ein Snapshot. |
Die Aktualisierung des Systems
Es sei hier noch mal erwähnt: alle jtel-Dienste des Systems müssen herunter gefahren sein.
Danach kann mit der Aktualisierung begonnen werden. Die Schritte erfolgen in der hier dokumentierten Reihenfolge
Aktualisierung der Software auf dem STORE
Dieser Schritt muss als Benutzer "jtel" erfolgen.
Warning | ||
---|---|---|
| ||
jtel hat seine Repository-Server umgezogen in die Cloud. Siehe hier: New Repository Locations Es ist nötig, die URL der GIT repositories zu verändern, bevor man hier weitermacht. |
Prüfung ob Änderungen / Patches vorhanden sind
Bevor die Software aktualisiert wird, sollte noch geprüft werden, ob im jeweiligen Verzeichnis Dateien geändert wurden.
Info | ||
---|---|---|
| ||
Es sollte in /home/jtel/shared eine readme.txt vorhanden sein, der eventuell eingespielte Patches auflistet. |
Hier ein Beispiel basierend auf das Software-Verzeichnis JTELCarrierPortal:
Code Block | ||||
---|---|---|---|---|
| ||||
su jtel
cd /home/jtel/shared/JTELCarrierPortal
git status
git rev-parse HEAD
exit |
Wird hier angezeigt, dass Dateien verändert wurden, ist Vorsicht geboten. Der Projektingenieur muss vorher prüfen, ob die Änderungen lokale Bugfixe sind, die inzwischen ins Release eingeflossen sind. In diesem Falle können die Änderungen vor der Aktualisierung gelöscht werden. Tut man dies nicht, so kann die Aktualisierung scheitern!
Code Block | ||||
---|---|---|---|---|
| ||||
su jtel
cd /home/jtel/shared/JTELCarrierPortal
git checkout -- .
exit |
Eine allgemeine Vorgehensweise kann in einem solchen Fall aber nicht beschrieben werden. Hier muss von Fall zu Fall geprüft werden, wie vorgegangen wird.
Falls Datei-Modus Änderungen ignoriert werden sollen, kann folgender Befehl genutzt werden:
Code Block | ||||
---|---|---|---|---|
| ||||
git config core.fileMode false |
Aktualisierung der Repositories (Immer auf Non-Authoritative Share)
Die folgende Befehlssequenz aktualisiert alle Software-Verzeichnisse auf dem letzten Stand des jeweilig eingestellten Releases.
Translations Ignore | |||||||
---|---|---|---|---|---|---|---|
|
Falls Fehler beim GIT auftreten, beispielsweise:
Merge-Konflikt in (Dateiname)
Oder
fatal: Verweigere den Merge von nicht zusammenhängenden Historien.
|
Wird hier angezeigt, dass Dateien verändert wurden, ist Vorsicht geboten. Der Projektingenieur muss vorher prüfen, ob die Änderungen lokale Bugfixe sind, die inzwischen ins Release eingeflossen sind. In diesem Falle können die Änderungen vor der Aktualisierung gelöscht werden. Tut man dies nicht, so kann die Aktualisierung scheitern!muss das lokale Repository resettet werden. Dies kann wie folgt (Beispiel für stable-3.18 auf JTELCarrierPortal) geschehen:
Translations Ignore | |||||||
---|---|---|---|---|---|---|---|
|
Auschecken des gewünschten Releases
Nachdem der GIT PULL erfolgt ist, muss das entsprechende Release ausgechecked werden, falls ein anderer als mit git status gewünscht ist.
|
Eine allgemeine Vorgehensweise kann in einem solchen Fall aber nicht beschrieben werden. Hier muss von Fall zu Fall geprüft werden, wie vorgegangen wird.
Falls Datei-Modus Änderungen ignoriert werden sollen, kann folgender Befehl genutzt werden:
Translations Ignore | ||||||||
---|---|---|---|---|---|---|---|---|
|
Aktualisierung der Repositories (Immer auf Non-Authoritative Share)
Die folgende Befehlssequenz aktualisiert alle Software-Verzeichnisse auf dem letzten Stand des jeweilig eingestellten Releases.
Translations Ignore | |||||||
---|---|---|---|---|---|---|---|
| |||||||
Note | |||||||
|
Dateien auf Authoritative Share kopieren
Nur wenn es ein Authoritative / Non-Authoritative share gibt.
Dies geschieht mit folgender Skript
Code Block | ||||
---|---|---|---|---|
| ||||
cd /srv/jtel/shared/JTELCarrierPortal/
bash update_fileshare.sh |
Aktualisierungsskripte laufen lassen
Folgender Aktualisierungsskript führt alle notwendigen Änderungen durch. Dies wird als root oder jtel mit sudo ausgeführt. Hier mit jtel user:
Code Block | ||||
---|---|---|---|---|
| ||||
cd /home/jtel/shared/JTELCarrierPortal/Update
sudo ./update_release.sh |
Ggf. wird man zuerst nach den sudo Passwort gefragt.
Das Skript fragt nach den entsprechenden Master Datenbank, Benutzer, Passwort, und Name des Kundenverzeichnisses indem ggf. spezifische Software für den Kunden liegt.
Die Fragen können, in der Regel mit folgende Antworten beantwortet werden, Kenntnis von <password> für die Datenbank vorausgesetzt:
- mysql host address: acd-dbm
- mysql user name: root
- mysql password: <password>
- customer directory:
Falls kein Customer Directory vorhanden ist, kann dies leer gelassen werden. Das Vorhandensein von Kundenspezifische Software kann mit ls /home/jtel/shared geprüft werden - dort die Namen der Verzeichnisse anschauen. Nur den Namen des Verzeichnisses angeben! Beispielsweise acme
Anschließend wird das Update durchgeführt.
Warning | ||
---|---|---|
| ||
In einer Master/Slave Umgebung ist unbedingt darauf zu achten, diese Prozedur gegen der Master-Datenbank durchzuführen - sprich mysql host address = MASTER-DB. Tut man dies aus Versehen auf einem Slave, hat man Chaos gesät: der Slave ist dann kaputt, und muss neu aufgesetzt werden. Die Aktualisierung muss dann (korrekt auf dem Master) wiederholt werden. |
Binaries Herunterladen
Die Binaries werden mit folgenden Befehl heruntergeladen:
Code Block | ||||
---|---|---|---|---|
| ||||
cd /home/jtel/shared/JTELCarrierPortal/Update
su jtel
bash get_binaries.sh |
Aktualisierung des Platform UDP Listeners
Master Datenbanken
Bei Release 3.18 und höher, wird Java 8 verwendet. Das (vorhandene) Java 7 muss deinstalliert werden, und Java 8 wird installiert.
Wir verwenden den openjdk, sodass es unter Linux Updatefähig bleibt.
Code Block |
---|
service jtel-listener stop
yum -y remove jdk.x86_64
yum -y install https://cdn.jtel.de/downloads/java/jdk-8u202-linux-x64.rpm |
Die Aktualisierung des Platform UDP Listeners muss als Benutzer "root" ausgeführt werden und erfolgt auf die Master Datenbanken durch Eingabe folgendem Befehls:
Code Block | ||||
---|---|---|---|---|
| ||||
updatepl.sh |
Dieser Befehl aktualisiert den Listener und startet ihn. Der Erfolg kann durch Sichtung der Datei /home/jtel/PlatformUDPlistener/log/listener.log
geprüft werden.
Info | ||
---|---|---|
| ||
Der Listener ist nur auf die Master-Datenbanken dann installiert, wenn eine SOAP Schnittstelle lizenziert ist. |
Telefonieservern
Hier ist zu prüfen ob Java 8 installiert ist. Ggf. Java 8 von einer der Quellen hier herunterladen (dies sind BCL lizenzierte Versionen, also Lizenzfrei):
- https://www.oracle.com/technetwork/java/javase/downloads/java-archive-javase8-2177648.html
- https://cdn.jtel.de/downloads/java/jdk-8u202-windows-x64.exe
Das Start-Skript für den Platform-Listener kopiert die neue Version des Listeners selbst.
Note | ||
---|---|---|
| ||
Ist der Platform-Listener auf den TEL Servern als Dienst installiert, reicht ein Neustart als Dienst NICHT aus. In diesen Fall sollte der Listener einmal von der Konsole aus gestartet werden, damit das Kopieren auch geschieht. |
Aktualisierung der WEB Server
Der JBOSS Server wird komplett ersetzt durch ein Wildfly Server.
Hazelcast Konfiguration sichern
Falls keine Sicherung bereits vorhanden:
Code Block |
---|
cp /home/jtel/jboss-as-7.1.1.FINAL/standalone/configuration/hazelcast.xml /home/jtel/shared |
JBOSS Server und Java 7 Deinstallieren
Als root:
Code Block |
---|
service jboss stop
yum -y remove jdk.x86_64
cd /home/jtel
chkconfig jboss off
rm -f /etc/init.d/jboss
rm -f /etc/cron.daily/jboss-logmaint.sh
rm -f /etc/cron.daily/jboss-restart.sh
rm -f /usr/local/bin/updatejb.sh
rm -Rf jboss-as-7.1.1.FINAL |
Java 8 und Wildfly Installieren
Code Block |
---|
yum -y install https://cdn.jtel.de/downloads/java/jdk-8u202-linux-x64.rpm
wget http://cdn.jtel.de/downloads/jboss/wildfly-18.0.1.Final.01.tar.gz
tar xzf wildfly-18.0.1.Final.01.tar.gz
rm -f wildfly-18.0.1.Final.01.tar.gz
mkdir -p wildfly-18.0.1.Final/standalone/deployments
chown -R jtel:jtel wildfly-18.0.1.Final
mkdir -p /home/jtel/upload
chown -R jtel:jtel /home/jtel/upload
ln -s /home/jtel/wildfly-18.0.1.Final wildfly-current
ln -s /home/jtel/wildfly-current/init.d/wildfly /etc/init.d/wildfly
ln -s /home/jtel/wildfly-current/default/wildfly /etc/default/wildfly
cd /etc/cron.daily
ln -s /home/jtel/wildfly-current/bin/jboss-logmaint.sh
ln -s /home/jtel/wildfly-current/bin/jboss-restart.sh
cd /usr/local/bin
ln -s /home/jtel/wildfly-current/bin/updatejb.sh
chkconfig wildfly on |
Wildfly konfigurieren
Die hazelcast.xml muss kopiert werden, und die Standardeinstellungen für die Datenbank müssen angepasst werden.
Im folgenden <password> bitte entsprechend ersetzen:
Code Block |
---|
DBPRI=acd-dbm
DBSTA=acd-dbs
DBREP=acd-dbr
DBPWD=<password>
sed -i -e "s/DATA_PRIMARY/${DBPRI}/g" -e "s/DATA_STATS/${DBSTA}/g" -e "s/DATA_REPORTS/${DBREP}/g" -e "s/DB_PASSWORD/${DBPWD}/g" /home/jtel/wildfly-current/standalone/configuration/standalone.xml
unset DBPWD
unset DBREP
unset DBSTA
unset DBPRI
cp /home/jtel/shared/hazelcast.xml /home/jtel/wildfly-current/standalone/configuration/ |
|
Falls Fehler beim GIT auftreten, beispielsweise:
Merge-Konflikt in (Dateiname)
Oder
fatal: Verweigere den Merge von nicht zusammenhängenden Historien.
muss das lokale Repository resettet werden. Dies kann wie folgt (Beispiel für stable-3.18 auf JTELCarrierPortal) geschehen:
Translations Ignore | |||||||
---|---|---|---|---|---|---|---|
|
Auschecken des gewünschten Releases
Nachdem der GIT PULL erfolgt ist, muss das entsprechende Release ausgechecked werden, falls ein anderer als mit git status gewünscht ist.
Translations Ignore | |||||||
---|---|---|---|---|---|---|---|
|
Note | ||
---|---|---|
| ||
Es kann sein, dass git den gewünschten Release nicht kennt, trotz git pull und git checkout. git fetch --unshallow git config remote.origin.fetch "+refs/heads/*:refs/remotes/origin/*" git fetch origin |
Dateien auf Authoritative Share kopieren
Nur wenn es ein Authoritative / Non-Authoritative share gibt.
Dies geschieht mit folgender Skript
Translations Ignore | |||||||
---|---|---|---|---|---|---|---|
|
Aktualisierungsskripte laufen lassen
Folgender Aktualisierungsskript führt alle notwendigen Änderungen durch. Dies wird als root oder jtel mit sudo ausgeführt. Hier mit jtel user:
Translations Ignore | |||||||
---|---|---|---|---|---|---|---|
|
Ggf. wird man zuerst nach den sudo Passwort gefragt.
Das Skript fragt nach den entsprechenden Master Datenbank, Benutzer, Passwort, und Name des Kundenverzeichnisses indem ggf. spezifische Software für den Kunden liegt.
Die Fragen können, in der Regel mit folgende Antworten beantwortet werden, Kenntnis von <password> für die Datenbank vorausgesetzt:
- mysql host address: acd-dbm
- mysql user name: root
- mysql password: <password>
- customer directory:
Falls kein Customer Directory vorhanden ist, kann dies leer gelassen werden. Das Vorhandensein von Kundenspezifische Software kann mit ls /home/jtel/shared geprüft werden - dort die Namen der Verzeichnisse anschauen. Nur den Namen des Verzeichnisses angeben! Beispielsweise acme
Anschließend wird das Update durchgeführt.
Warning | ||
---|---|---|
| ||
In einer Master/Slave Umgebung ist unbedingt darauf zu achten, diese Prozedur gegen der Master-Datenbank durchzuführen - sprich mysql host address = MASTER-DB. Tut man dies aus Versehen auf einem Slave, hat man Chaos gesät: der Slave ist dann kaputt, und muss neu aufgesetzt werden. Die Aktualisierung muss dann (korrekt auf dem Master) wiederholt werden. |
Binaries Herunterladen
Die Binaries werden mit folgenden Befehl heruntergeladen:
Translations Ignore | |||||||
---|---|---|---|---|---|---|---|
|
Aktualisierung des Platform UDP Listeners
Master Datenbanken
Bei Release 3.18 und höher, wird Java 8 verwendet. Das (vorhandene) Java 7 muss deinstalliert werden, und Java 8 wird installiert.
Wir verwenden den openjdk, sodass es unter Linux Updatefähig bleibt.
Translations Ignore | ||
---|---|---|
|
Die Aktualisierung des Platform UDP Listeners muss als Benutzer "root" ausgeführt werden und erfolgt auf die Master Datenbanken durch Eingabe folgendem Befehls:
Translations Ignore | |||||||
---|---|---|---|---|---|---|---|
|
Dieser Befehl aktualisiert den Listener und startet ihn. Der Erfolg kann durch Sichtung der Datei /home/jtel/PlatformUDPlistener/log/listener.log
geprüft werden.
Info | ||
---|---|---|
| ||
Der Listener ist nur auf die Master-Datenbanken dann installiert, wenn eine SOAP Schnittstelle lizenziert ist. |
Telefonieservern
Hier ist zu prüfen ob Java 8 installiert ist. Ggf. Java 8 von einer der Quellen hier herunterladen (dies sind BCL lizenzierte Versionen, also Lizenzfrei):
- https://www.oracle.com/technetwork/java/javase/downloads/java-archive-javase8-2177648.html
- https://cdn.jtel.de/downloads/java/jdk-8u202-windows-x64.exe
Das Start-Skript für den Platform-Listener kopiert die neue Version des Listeners selbst.
Note | ||
---|---|---|
| ||
Ist der Platform-Listener auf den TEL Servern als Dienst installiert, reicht ein Neustart als Dienst NICHT aus. In diesen Fall sollte der Listener einmal von der Konsole aus gestartet werden, damit das Kopieren auch geschieht. |
Aktualisierung der WEB Server
Der JBOSS Server wird komplett ersetzt durch ein Wildfly Server.
Hazelcast Konfiguration sichern
Falls keine Sicherung bereits vorhanden:
Translations Ignore | ||
---|---|---|
|
JBOSS Server und Java 7 Deinstallieren
Als root:
Translations Ignore | ||
---|---|---|
|
Java 8 und Wildfly Installieren
Translations Ignore | ||
---|---|---|
|
Wildfly konfigurieren
Die hazelcast.xml muss kopiert werden, und die Standardeinstellungen für die Datenbank müssen angepasst werden.
Im folgenden <password> bitte entsprechend ersetzen:
Translations Ignore | ||
---|---|---|
|
Aktualisierung der Portalsoftware
Die Aktualisierung der Portalsoftware muss als Benutzer "root" auf dem Webserver ausgeführt werden und erfolgt durch Eingabe folgendem Befehls:
Translations Ignore | |||||||
---|---|---|---|---|---|---|---|
|
Dieser Befehl aktualisiert die Portalsoftware und startet den wildfly Server. Der Erfolg kann durch Sichtung der Datei /home/jtel/wildfly-current/standalone/log/server.log
geprüft werden.
Dort sollten in der Log-Datei folgende Einträge zu sehen sein, wenn die Aktualisierung erfolgreich war:
Client Messenger aktualisieren
wenn Chatserver installiert ist.
Stellen Sie für jtel-Portalversionen >= 3.25 sicher, dass Sie systemd und/oder init.d bearbeiten:
Wenn Sie init.d verwenden:
Code Block | ||||
---|---|---|---|---|
| ||||
vi /home/jtel/ClientMessenger/init.d/jtel-clientmessenger
# make sure this line exists
-Djava.net.preferIPv4Stack=true \
# make sure this line contains \&serverTimezone=Europe/Berlin
-Dde.jtel.platform.clientmessenger.connection=jdbc:mysql://acd-dbm/JTELWeb?user=root\&password=<password>\&characterEncoding=utf8\&serverTimezone=Europe/Berlin \
# copy to etc
cp /home/jtel/ClientMessenger/init.d/jtel-clientmessenger /etc/init.d/
chmod 755 /etc/init.d/jtel-clientmessenger |
Wenn Sie systemd verwenden:
Code Block | ||||
---|---|---|---|---|
| ||||
vi /home/jtel/ClientMessenger/systemd/jtel-clientmessenger.service
# make sure this line exists
-Djava.net.preferIPv4Stack=true \
# make sure this line contains &serverTimezone=Europe/Berlin
-Dde.jtel.platform.clientmessenger.connection=jdbc:mysql://acd-dbm/JTELWeb?user=root&password=<Password>&characterEncoding=utf8&serverTimezone=Europe/Berlin \
# copy to systemd
cp /home/jtel/ClientMessenger/systemd/jtel-clientmessenger.service /etc/systemd/system/jtel-clientmessenger.service
systemctl daemon-reload |
Dann aktualisieren:
Code Block | ||||
---|---|---|---|---|
| ||||
updatesc.sh |
Aktualisierung des 8Servers
Die Aktualisierung des 8Server erfolgt im Windows-Explorer mittels GIT. Hierfür wird mit einem Rechtsklick auf das Verzeichnis C:\8Server\deploy ein GIT Pull durchgeführt, und auf das gewünschte Version nach dem Pull gewechselt.
Warning | ||
---|---|---|
| ||
jtel hat seine Repository-Server umgezogen in die Cloud. Siehe hier: New Repository Locations Es ist nötig, die URL der GIT repositories zu verändern, bevor man hier weitermacht. |
Möchte man nicht auf die letzte Version, sondern auf eine spezifische Version aktualisieren, erfolgt dies Über "git checkout" mit Angabe des Releases.
Nach dem Aktualisieren, muss die Version dann installiert werden. Bei einem Daemon-Server erfolgt dies mit dem Befehl:
Translations Ignore | |||||
---|---|---|---|---|---|
|
Bei einem Telefonie-Server mit Aculab Media Service erfolgt dies mit folgendem Befehl:
Translations Ignore | |||||
---|---|---|---|---|---|
|
Im Anschluss kann der 8Server gestartet werden.
Aktualisierung der Konnektoren
Grundsätzlich gilt: die entsprechenden Dateien aus dem Software-Verzeichnis im STORE müssen ins Zielverzeichnis kopiert werden.
Diese kommen in der Regel aus dem Bereich JTELCarrierPortal/WebServices/Install
Warning | ||
---|---|---|
| ||
Bei Kopieraktionen ist unbedingt darauf zu achten, die Konfigurationsdateien nicht zu überschreiben! Diese haben Namen, die sich an den Namen des ausführbaren Programm häufig anlehnen. Beispiel: |
Abschließende Arbeiten
Ist die Aktualisierung beendet und die Anlage ohne Fehler wieder hochgefahren, sind folgende Aufgaben zwingend auszuführen:
- Anmelden ans Portal. Kurzer Test um zu sehen, dass auch Agenten und Supervisoren zu sehen bekommen, was sie erwarten.
- Testanruf! Idealerweise gibt es eine Testnummer. Falls nicht, eine der regulären Servicerufnummern anrufen. Prüfen, dass der 8Server korrekt antwortet.
- Testanruf mit beobachtung des Portals.
Als User anmelden, und schauen ob ein Anruf im Portal korrekt angezeigt wird, wenn es dem Agenten zugestellt wird.
- Testanruf mit beobachtung des Portals.
Info | ||
---|---|---|
| ||
Auf VMWare sowie Hyper-V können Snapshots zu Performance-Verlusten führen. Die Snapshots sollten gelöscht werden, aber erst dann, wenn sichergestellt ist, dass es kein Zurück mehr geben muss. Dies ist in der Regel nach der ein Wenig Live-Zeit des Call-Centers der Fall. |
Sv translation | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
ExigenceLe système doit d'abord être mis à jour avec une version de MySQL 8.x (Release 3.15 à 3.17). Préparation de la mise à jourÀ chaque mise à jour, il existe une règle d'or qui doit être strictement respectée, quels que soient les souhaits du client:
Déterminer la part qui fait autoritéDans certaines installations, le partage de fichiers se fait sur un système fourni par le client. Dans ce cas, les dépôts sont extraits localement vers l'équilibreur de charge sur le partage non-autoritaire, mais les fichiers sont ensuite copiés sur le partage de fichiers "autoritaire". Après les changements, il faut vérifier si le partage de fichiers fait autorité. Partage de fichiers faisant autoritéIl s'agit de/home/jtel/shared Partage de fichiers non autoriséIl s'agit de /home/jtel/shared Déterminer si elle fait autoritéSi /home/jtel/shared est monté sur l'équilibreur de charge d'un système tiers, il ne fait généralement pas autorité. Vous pouvez facilement le déterminer en créant un fichier sur /srv/jtel/shared. Si ce fichier n'apparaît pas dans /home/jtel/shared, alors /srv/jtel/shared ne fait pas autorité. Sauvegarde des donnéesUne sauvegarde des données doit être effectuée sans condition. Le MINIMUM est que la base de données soit sauvegardée et le répertoire de données sauvegardé, mais cela ne devrait être qu'une solution provisoire. Mieux vaut un cliché de toutes les machines virtuelles concernées, à l'état froid (éteint). Il y a un risque que si un instantané est pris pendant le fonctionnement (en particulier des machines de la base de données), il peut ne pas être cohérent. Sauvegarde manuelleServices d'arrêt
Base de données de sauvegarde (sur le maître de la base de données)Entrez le mot de passe correspondant à <mot de passe>:
Directory Data BackupCela peut être fait via l'explorateur Windows ou une commande cp correspondante sur Linux. Se souvenir du statut de GIT (Part d'autorité)A partir de l'équilibreur de charge, vérifiez le statut GIT:
Si nécessaire, les répertoires doivent également être inclus dans la sauvegarde des données, en particulier si des correctifs ont été appliqués afin que des modifications locales soient effectuées. Sécurisation des composants supplémentairesSi d'autres composants sont affectés par la mise à jour, tels que le 8-server lui-même ou le serveur JBOSS (et non l'application web), ces composants doivent également être sauvegardés à l'avance. Sauvegarde instantanéeCela se fait via la console VMWare, ou console Hyper-V. Cette opération est généralement effectuée par le client. Confirmation
RestaurerClichésLes clichés sont tous réactivés et amorcés. Il devrait y avoir un fonctionnement normal avec l'ancien logiciel. Restauration manuelleUne fois tous les services arrêtés, restaurez la base de données. Entrez le mot de passe correspondant à <mot de passe>:
En parallèle, l'ancien répertoire de données peut être restauré. D'autres étapes peuvent être nécessaires (restauration des dépôts GIT, restauration de 8-servers, ...) en fonction des composants qui ont été affectés par la mise à jour.
La mise à jour du systèmeIl convient de le mentionner à nouveau : tous les services jtel du système doivent être arrêtés. Après cela, la mise à jour peut être lancée. Les étapes sont effectuées dans l'ordre documenté ici Mise à jour du logiciel sur le STORECette étape doit être effectuée en tant qu'utilisateur "jtel".
Vérifiez si des changements / correctifs sont disponiblesAvant de mettre à jour le logiciel, vous devez vérifier si les fichiers dans le répertoire correspondant ont été modifiés.
Voici un exemple basé sur le répertoire de logiciels JTELCarrierPortal
Si cela indique que des fichiers ont été modifiés, la prudence est de mise. L'ingénieur du projet doit d'abord vérifier si les changements sont des corrections de bogues locales qui ont été intégrées dans la version. Si tel est le cas, les modifications peuvent être supprimées avant la mise à jour. Si cela n'est pas fait, la mise à jour risque d'échouer!
Toutefois, une procédure générale ne peut être décrite dans un tel cas. Dans ce cas, la procédure doit être vérifiée au cas par cas. Si les changements de mode de fichier doivent être ignorés, la commande suivante peut être utilisée:
Mise à jour des dépôts (toujours sur le partage non autorisé)La séquence de commandes suivante met à jour tous les répertoires de logiciels à la dernière version de la version choisie.
Si des erreurs se produisent dans le GIT, par exemple: Fusion-Conflit en (nom du fichier) Ou fatal : Nier la fusion d'histoires sans lien entre elles. le dépôt local doit être réinitialisé. Cela peut être fait de la manière suivante (exemple pour stable-3.18 sur JTELCarrierPortal)
Vérification de la version souhaitéeUne fois que le GIT PULL est effectué, la version correspondante doit être vérifiée si une version autre que le git status est souhaitée.
Copier les fichiers sur le partage autoriséSeulement s'il y a une part Autoritaire / Non Autoritaire. Cela se fait avec le scénario suivant
Exécutez des scripts de mise à jourLe script de mise à jour suivant apporte toutes les modifications nécessaires. Ceci est exécuté en tant que root ou jtel avec sudo. Ici avec l'utilisateur de jtel:
Il se peut qu'on vous demande d'abord le mot de passe sudo. Le script demande la base de données principale correspondante, l'utilisateur, le mot de passe et le nom du répertoire des clients où peuvent se trouver des logiciels spécifiques pour le client. Les questions peuvent être répondues, généralement avec les réponses suivantes, connaissance de <mot de passe> pour la base de données supposée:
S'il n'y a pas de répertoire des clients, celui-ci peut être laissé vide. La présence de logiciels personnalisés peut être vérifiée avec ls /home/jtel/shared - vous pouvez y voir les noms des répertoires. N'entrez que le nom du répertoire! Par exemple acme La mise à jour est alors effectuée.
Téléchargez les binairesLes binaires sont téléchargés avec la commande suivante:
Mise à jour de la plate-forme UDP ListenerBases de données principalesÀ partir de la version 3.18, Java 8 est utilisé. Le Java 7 (existant) doit être désinstallé et le Java 8 sera installé. Nous utilisons l'openjdk pour qu'il reste actualisable sous Linux.
La mise à jour de la plate-forme UDP Listener doit être exécutée en tant qu'utilisateur "root" et est effectuée sur la bases de données principales en entrant la commande suivante :
Cette commande met à jour l'auditeur et le démarre. Le succès peut être vérifié en consultant le fichier /home/jtel/PlatformUDPlistener/log/listener.log.
Serveurs téléphoniquesIci, vous devez vérifier si Java 8 est installé. Si nécessaire, téléchargez Java 8 à partir d'une des sources ici (ce sont des versions sous licence BCL, c'est-à-dire sans licence):
Le script de démarrage pour l'auditeur de la plateforme copie la nouvelle version de l'auditeur lui-même.
Mise à jour des serveurs WEBLe serveur JBOSS est complètement remplacé par un serveur Wildfly. Sauvegarde de la configuration HazelcastSi aucune sauvegarde n'existe déjà:
Désinstallation du serveur JBOSS et de Java 7Comme racine:
Installer Java 8 et Wildfly
Configurer WildflyLe fichier hazelcast.xml doit être copié et les paramètres par défaut de la base de données doivent être ajustés. Dans le texte suivant, remplacez <mot de passe> en conséquence:
Mise à jour du logiciel du portailLa mise à jour du logiciel du portail doit être exécutée en tant qu'utilisateur "root" sur le serveur web et se fait en entrant la commande suivante :
Cette commande met à jour le logiciel du portail et démarre le serveur Wildfly. Le succès peut être vérifié en consultant le fichier /home/jtel/wildfly-current/standalone/log/server.log. Vous devriez y voir les entrées suivantes dans le fichier journal si la mise à jour a réussi : Mise à jour du « Client Messenger »Si le serveur de chat est installé. Pour les versions du portail jtel >= 3.25, assurez-vous d'éditer systemd et/ou init.d : Si vous utilisez init.d :
Si vous utilisez systemd :
Ensuite, mettez à jour :
Mise à jour du 8ServerLe 8Server est mis à jour dans l'explorateur Windows à l'aide de GIT. Pour ce faire, cliquez avec le bouton droit de la souris sur le répertoire C:\8Server\deploy pour effectuer une extraction GIT et passez à la version souhaitée après l'extraction.
Si vous ne souhaitez pas mettre à jour vers la dernière version, mais vers une version spécifique, vous pouvez le faire via "git checkout", en indiquant la version. Après la mise à jour, la version doit ensuite être installée. Pour un serveur Démon, cela se fait avec la commande :
Pour un serveur de téléphonie avec Aculab Media Service, cela se fait avec la commande suivante :
Ensuite, le 8Server peut être démarré. Mise à jour des connecteursFondamentalement: les fichiers correspondants du répertoire du logiciel dans le STORE doivent être copiés dans le répertoire cible. Elles proviennent généralement de JTELCarrierPortal/WebServices/Install
Travail finalUne fois la mise à jour terminée et le système redémarré sans erreur, les tâches suivantes doivent être effectuées:
Aktualisierung der PortalsoftwareDie Aktualisierung der Portalsoftware muss als Benutzer "root" auf dem Webserver ausgeführt werden und erfolgt durch Eingabe folgendem Befehls: Translations Ignore |
Dieser Befehl aktualisiert die Portalsoftware und startet den wildfly Server. Der Erfolg kann durch Sichtung der Datei Dort sollten in der Log-Datei folgende Einträge zu sehen sein, wenn die Aktualisierung erfolgreich war: Aktualisierung des 8ServersDie Aktualisierung des 8Server erfolgt im Windows-Explorer mittels GIT. Hierfür wird mit einem Rechtsklick auf das Verzeichnis C:\8Server\deploy ein GIT Pull durchgeführt, und auf das gewünschte Version nach dem Pull gewechselt.
Möchte man nicht auf die letzte Version, sondern auf eine spezifische Version aktualisieren, erfolgt dies Über "git checkout" mit Angabe des Releases. Nach dem Aktualisieren, muss die Version dann installiert werden. Bei einem Daemon-Server erfolgt dies mit dem Befehl: Translations Ignore |
Bei einem Telefonie-Server mit Aculab Media Service erfolgt dies mit folgendem Befehl: Translations Ignore |
Im Anschluss kann der 8Server gestartet werden. Aktualisierung der KonnektorenGrundsätzlich gilt: die entsprechenden Dateien aus dem Software-Verzeichnis im STORE müssen ins Zielverzeichnis kopiert werden. Diese kommen in der Regel aus dem Bereich
Abschließende ArbeitenIst die Aktualisierung beendet und die Anlage ohne Fehler wieder hochgefahren, sind folgende Aufgaben zwingend auszuführen:
|