✎ aspcitrix:update_version_medialog [Titelive Doc]

Cette page est en lecture seule. Vous pouvez afficher le texte source, mais ne pourrez pas le modifier. Contactez votre administrateur si vous pensez qu'il s'agit d'une erreur.
====== Comment upgrader une version de medialog chez un client ======
 (à partir de la version medialog2.3.5.2 - sur tlcloud).

===== __Chronologie theorique :__ =====

en cas de maj 100% **manuelle**, passer directement à l'étape USERS et ACCES (1).
On peut également profiter d'une partie automatique, dans ce cas il faudra uniquement faire manuellement les points mis en gras dans les étapes ci dessous.

pour pour pouvoir lancer la partie **automatique**, on peut le faire en 'live' ou procedé par planification en tache schedulé (cfr daily update et ses commentaire).  \\ 
pour cela il faut se connecter en bureau a distance sur la machine TLCONV15 en tant qu'utilisateur 'tldomain\migrateur'.
Sur le bureau il y a un raccourci vers le dossier e:\update352.

En **live**, on pourra y lancer le fichier script update352.cmd, le script demandera l'alias du client que l'on va migrer, en cas de multifiliale, le script va regarder dans customer_addon et fera toutes les filiales repertorié dans cette table.

En cas d'utilisation de la tache **scheduler** il faudra créer un fichier texte au format "update_list[Date au formatYYYYMMDD].txt qui contiendra les alias client à migrer. 

==== Users et accès (1) ====
  * **prévenir le service IT que l'on va travailler sur un client précis, car des avertissements d'erreurs sur la NON accessibilité de la base du client vont apparaitre sur Nagios.** 
  * **désactivation (disable) des users dans l'active directory (tladfs1), pour éviter des reconnexions des users durant la phase d'upgrade**
  * **faire un logoff des users recalcitrants encore connectés sur le farm (prog TLMC sur tlxadmin)**
  * désactivation (stop) des accès externes via des sites web (arrêt service iis - application pools - sur le tlwi1 et tlwi2)

==== Base ====
  * on peut vérifier qu'il reste assez de place sur le serveur BD qui héberge le client. pour garder l'ancienne version, faire des backup/restore ....  (df -h sur serveur linux)
  * se connecter (ibexpert) sur la base du client (sur tldbsx) que l'on va mettre a jour.
  * renommer la base mlv2.fdb en mlv2_yyyyy.fdb 
  * regarder avec ibexpert dans la table  MON$ATTACHMENT s'il existe des connexions autre que la notre, les tuer s'il en existe => DELETE FROM MON$ATTACHMENTS WHERE MON$ATTACHMENT_ID <> CURRENT_CONNECTION  
  * par securité sauvegarder la base mlv2_yyyyy.fdb en prenant une copie mlv2_yyyyy_save.fdb 
  * **récupérer le ou les scripts (si on upgrade de plusieurs version) de mise a jour de bases de donnée sur le tlfsint (exemple dans \\tlfsint\TLSERV2\Versions\Interne\version_2_3A5\upd\Script prendre le script tout 3a5 pour bin+02.sql pour passer de la version 3.5.1 a 3.5.2) et le mettre a coté du programme pmajbase.exe (voir point suivant).**
  * exécuter le programme pmajbase.exe sur la base que l'on a renommer mlv2_yyyyy.fdb avec le ou les scripts d'update. (le programme pmajbase.exe peut être trouvé sur le tlxadmin (C:\Tools\Medialog\pmajbase), le fichier pmajbase.ini peut contenir le chemin et le nom de la base a updater.  ATTENTION bien cocher dialect 3 et préciser encodage client.
  * **contrôler en fin d'exécution que l'on a pas d'erreur qui pourrait contrecarrer notre mise a jour. (err_upgrade.log)**
  * faire un backup de la base (en désactivant le garbage).  (par exemple via un iboconsole - pour ma part en me connectant sur le tldbs5).
  * faire un restore de la base que l'on vient de backuper (en mlv2_yyyyy_new.fdb) et ensuite la renommer en mlv2.fdb
  * on fait le ménage des bases de travail en gardant peut être la base juste avant notre upgrade, en renommant par exemple mlv2_yyyyy_save.fdb en mlv2_351.fdb  

==== Bin ====
  * Sur le tladfs1 prendre les bin des nouvelles versions \\tladfs1\e$\Share1\Media_update\Bin_23a5+02 par exemple) et les mettre dans la directory du client (dans l'ordre croissant des versions si on upgrade de plusieurs versions) (\\tladfs1\e$\Share1\MediaLog\ML_TLLIB\Fil_version\Bin par exemple)
  * **contrôler avec beyond compare que tout les fichiers du tladfs1 sont plus récents que ceux du tladfs2 pour notre client (\\tladfs1\e$\Share1\MediaLog\ML_TLLIB\Fil_version\Bin <--> \\tladfs2\e$\Share2\MediaLog\ML_TLLIB\Fil_version\Bin).  Attention aussi il ne peut pas y avoir de dossier schemacache (a supprimer s'il existe)).  S'il y a des fichiers plus récent sur le tladfs2, alors les écraser avec ceux du tladfs1, sinon durant la nuit le tladfs2 écrasera les bons fichier du tladfs1 ...).**
  * Si le client va travailler le même jour après notre upgrade  \\ 
     - il faut mettre à jour toutes les machines virtuelles du farm, via le programme TLMC sur le tlxadmin, menu TOOLS - Maj bin Man.
     - il faut supprimer les directory shemacache sur tout les tlxa... (exemple : \\tlxa222\e$\ML_Internet\ML_Program Server\ML_Ecrivainpub\fil_001\Bin\schemacache).  On peut savoir quel tlxa en regardant dans le fichier logid.log du client sur le tlfs1 (\\tlfs1\DATABASES\ml_ecrivainpub\Fil_001\Others).  on y voit sur quel serveur le client s'est connecté depuis le matin, ce qui a engendrer la création du schemacache)

==== Users et accès (2) ====
  * réactivation (enable) des users dans l'active directory (tladfs1)
  * réactivation (start) des accès externes via des sites web (service iis - application pools - sur le tlwi1 et tlwi2)

==== Doc et programmes externes ====
  * **Vérifier si il n'y a pas de taches bloquées sur le tlworks1 suite à l'indisponibilité temporaire de la base du client (les tuer si nécessaire)** 
  * **modifier le fichier version.info du client pour y renseigner la date de l'upgrade (copier/coller dans le fichier)  (\\tlfsint\TLSERV2\Versions\EcrivainPublic par exemple)**
  * **adapter la colonne version dans le fichier clients.xls (\\tlfsint\TLSERV2\Versions\interne\doc\)**
  * modifier le champ CUS_MLVERSI dans le record avec le cus_id du client dans la table CUSTOMERS( base e:\databases\tlcustomers\tlcustomers.fdb sur tldbs7)
  * **Activer certains programme externes qui peuvent être nouveaux avec la version pour notre client (exemple la mise à jour de la date de publication lors du passage de la 3.5.1 a la 3.5.2)**
  * Lors du passage en 3.5.2 , ne pas oublier d'ajouter le client pour la mise à jour de la date de publication sur le tlworks1 qui se situe sur e:\tools\all\updatedatepub  , il suffit de lancer l'application, sélectionner l'alias de base de données, définir le type de client ( BEFR, BENL ou NL ) et d'ajouter le client.  On peut manuellement faire une initialisation du client si nécessaire sinon elle se fera automatiquement au prochain démarrage.


===== __obsolète :__ =====
\\
<del>**Ancienne procédure obsolète utilisée pour updater la version Medialog des clients. sur ancien farm (s10.tlasp.be - et en 2009 ..)**</del>

<del>Se mettre sur le TLADFS1 et **il faut impérativement se logger avec son propre compte et dans TLDOMAIN**. Surtout ne pas utiliser le compte Administrator.

Deux possibilités:
       1. utiliser l'icône "Update_client.cmd"
       2. lancer le script à partir du prompt

Dans les deux cas, il y a 4 paramètres à fournir:
       nom du client(ex: taxandria)
       nom serveur de base de données (ex: tldbs6)
       numéro de la filiale (ex: fil_001)
       synchronisation entre TLADFS1 et TLADFS2 soit Y ou N ( en majuscule !!!)

1. Si vous utilisez l'icône, la script vous demandera de compléter les paramètres nécessaires à l'update du client: nom du client, nom du serveur de base de données, la filiale et enfin si vous désirez faire un synchro entre TLADFS1 et TLADFS2.

2. A partir du prompt, faire ce qui suit:
    cd e:\toolbox
    e:
    update_client <nom_client> <nom_serveur_bd> <fil_xxx> <Y/N>

    Si vous avez rempli tous les paramètres, le script s'exécutera automatiquement.
    Si vous devez mettre l'update dans un tâche schedulée, il faut donc utiliser cette dernière solution.</del>