You are not logged in.
Pages: 1
Bonjour à tous !
J'ai réalisé un script shell très simple, je vous le partage, si vous voulez le tester, l'améliorer, dire ce qui pourrait être mieux etc.
Le script : https://pastebin.com/PSkRxjfP
Voici ce qu'il réalise, dans l'ordre :
- suppression des fichiers dans /tmp pour éviter les conflits (utile si vous avez déjà lancer le script auparavant), en gros il supprime les fichiers contenant "glpi"
- il demande le chemin du dossier glpi qui est en production chez vous
- il se place dans un dossier de travail : /tmp
- il sauvegarde le dossier glpi et la base de données MySQL (au cas où)
- il demande le lien de téléchargement de la MàJ et le télécharge
- extrait et supprime l'archive
- supprime le "files" et "plugins" du nouveau dossier glpi
- déplace le glpi in-prod dans /tmp et le renomm en glpi_old
- Copie le files et plugins in-prod dans le nouveau glpi
- supprime l'ancien glpi
- déplace le nouveau glpi à sa place (le chemin indiqué au step 2)
- modifie le propriétaire et les droits du dossier glpi
- FIN
Même si le script fait une sauvegarde, je vous conseille d'en faire une de votre côté également avant de tester + snapshot si vous êtes virtualisés
Pour ceux qui veulent l'utiliser mais ne savent pas comment s'y prendre, sur votre serveur, en shell :
# nano glpiupdate.sh
Collez le script dedans, enregistrez puis quittez
# sudo chmod 770 glpiupdate.sh
# sudo sh glpiupdate.sh
ps: ce script est écrit pour CentOS, je n'ai pas vraiment réfléchi s'il fonctionnerait pour une autre distribution
Last edited by vince_nt (2017-07-06 17:19:58)
Prod : 9.2.3 - CentOS 7 - Mono entité
Test : 9.3.3 - CentOS 7 - Mono entité
Offline
Petites remarques pour améliorer ce script :
- il manque la copie du fichier config/config_db.php qui comprend les identifiants de connexion à la BDD (également les fichiers config_patch.php et config_db_slave.php si existants)
- il ne faut pas supprimer le dossier plugin du nouveau dossier et surtout ne pas reprendre les plugins d'une ancienne version qui risquent de ne plus être compatibles
- ne pas reprendre l'intégralité du dossier files ou alos le nettoyer en vidant tous les dossiers commençant par _
CentOS 6.5 - CentOS 7.x
PHP 5.6 - PHP 7.x - MySQL 5.6 - MariaDB 10.2 + APC + oOPcache
GLPI from 0.72 to dev version
Certifiée ITIL (ITV2F, ITILF, ITILOSA)
Offline
Bonjour yllen,
Merci pour tes très bonnes remarques, je mets à jour le script dès que possible !
Prod : 9.2.3 - CentOS 7 - Mono entité
Test : 9.3.3 - CentOS 7 - Mono entité
Offline
ne pas reprendre l'intégralité du dossier files ou alos le nettoyer en vidant tous les dossiers commençant par _
Oui mais si je comprends bien : en faisant ça, on ne récupère pas les documents ajoutés aux tickets par exemple et autres fichiers que l'on souhaite garder ?
ps: j'avais pas vu mais je suis sur le forum Windows... un admin peut me mettre dans le bon svp ?
Last edited by vince_nt (2017-06-30 11:19:38)
Prod : 9.2.3 - CentOS 7 - Mono entité
Test : 9.3.3 - CentOS 7 - Mono entité
Offline
Si vous prenez le dossier files complet pour reprenez également les session, les fichiers d'erreur, les caches....
Comme je vous le disais, il faut reprendre uniquement les dossiers avec les noms en majuscules correspondant aux noms des extensions de fichiers.
Donc si vous videz tous les dossiers _ (_logs, _sessions, _dump..) cela allègera énormément la copie.
Je déplace dans la section Discussion
CentOS 6.5 - CentOS 7.x
PHP 5.6 - PHP 7.x - MySQL 5.6 - MariaDB 10.2 + APC + oOPcache
GLPI from 0.72 to dev version
Certifiée ITIL (ITV2F, ITILF, ITILOSA)
Offline
D'accord je comprends mieux ! Merci yllen
Prod : 9.2.3 - CentOS 7 - Mono entité
Test : 9.3.3 - CentOS 7 - Mono entité
Offline
Bonjour,
Je profite de ce fil pour faire part de la situation de notre install et de notre parc.
Installation chez phpnet.org sur un serveur mutualisé
Version en prod : 0.90
Pas de problème majeur en dehors du fait que nous ne pouvons plus affecter un contrat a du matériel.
Je souhaite faire la mise à jour mais je ne vous cache pas mon appréhension. J'ai effectué une sauvegarde de la base via GLPI et sauvegardé l'ensemble du dossier via filezilla.
Après avoir lu la procédure de mise à jour, je crains de perdre mes documents téléchargés (devis etc etc etc) liés au matériel ou aux tickets.
Si quelqu'un peut me rassurer sur cette délicate opération.
Eric
Last edited by eric4362 (2017-07-06 10:14:22)
Offline
Bonjour Eric,
Si je comprends bien tu parles des documents "uploadés" dans les tickets. Ils sont stockés dans /path/glpi/files/
Ici tu as plusieurs sous dossiers (BMP, ZIP, PNG, etc), ce dossier (files) tu l'importes dans la version mise à jour donc tu ne perds rien. Cependant, comme yllen me l'a fait remarquer, il faut vider tous les sous dossiers de files commençant par "_" (_cron par exemple).
Si tu es vraiment inquiet, tu peux toujours te créer un nouveau répertoire glpi pour tester les mises à jour. Exemple:
cp /var/www/html/glpi /var/www/html/glpitest
Et tu testes la mise à jour sur ton instance de test. De plus, tu peux faire un snapshot avant la mise à jour si tu es virtualisé + tu as dis toi même que tu avais sauvegardé la database et le dossier glpi donc tu ne risques rien.
Je reste à ta disposition si tu as besoin d'aide.
____
J'ai mis à jour le script selon les recommandations d'yllen + j'ai rajouté un prompt qui demande le nom de l'utilisateur/groupe web au cas où ils ne sont pas par défaut. Attention je n'ai pas tester le script mis à jour.
ps: ce script est écrit pour CentOS, j'ai pas vraiment réfléchi s'il fonctionnerait pour une autre distribution
Last edited by vince_nt (2017-07-06 17:19:39)
Prod : 9.2.3 - CentOS 7 - Mono entité
Test : 9.3.3 - CentOS 7 - Mono entité
Offline
Pages: 1