Serveur dédié précaution à prendre pour passage en PHP 7.1

[clncln]

Bonjour à tous,

Mon site Joomla tourne sur un serveur dédié dont j'assure la "maintenance".
Ce serveur tourne sous Debian Stretch 9.5 avec PHP 7.0.
Je souhaite passer sous PHP 7.1.
N'ayant jamais réalisé cette opération et ne disposant de sauvegarde système de ce serveur, j'aimerais savoir si quelques parmi vous on déjà réalisé cette opération et pourrais me décrire la procédure à suivre?

Cordialement.

Didier.

[manu93fr]

Bonsoir,
tu devrais plutot porter ta question sur un forum dédié linux ou apache car être administrateur système d'un serveur c'est un vrai métier

[Erix]

Salut,

Manu a raison, si tu as la charge de la maintenance de ton serveur dédié tu dois savoir que l'opération n'est pas anodine et qu'elle peut impacter l'ensemble des sites que tu as sur ce serveur. Et puis tant qu'à faire l'upgrade pourquoi ne pas prendre la dernière version 7.2.9 ?

[lesoutier]

La seule chose que je puisse te conseiller c'est de bien faire des sauvegardes avant toute opération.
Sinon je pense que sur les forums Debian tu devrais trouver ton bonheur.

[clncln]

Je vous remercie pour vos réponses.
Pas facile de faire une sauvegarde système quand on n'a pas accès au PC.

[lesoutier]

C'est sur que si tu n'as pas un accès SSH c'est difficile, mais dans ce cas difficile aussi de faire un upgrade de Debian.

[clncln]

Je me suis mal exprimé, je n'ai pas un accès physique au PC. J'ai bien sûr un accès SSH.
Sur les PC dont j'ai un accès physique, j'ai l'habitude de réaliser les sauvegardes avec Clonezilla. Là ce n’est pas possible.

[lesoutier]

Pourtant les solutions ne manquent pas. Là je n'en ai pas en tete mais de nombreux logiciels permettent de faire des sauvegardes soit via ftp soit vers des solutions de cloud.
Je regarde dans mes tablettes des que j'ai un moment et je te tiens au courant.

[clncln]

Merci lesoutier, j'attends ton retour.

[chabi01]

Bonjour,
Je lis ce post et cela me questionne...
Si tu as en charge la maintenance d'un dédié, tu dois normalement avoir des backups en place. Un backup du système n'est pas plus compliqué qu'un backup des données avec RSync et en excluant des dossiers du genre ".cache" qu'il ne sert à rien de sauvegarder.
Ensuite, sur ton dédié, est-ce que tu fais tout via SSH ou est-ce que tu as un panel ? Si tu as un panel (Cpanel, Plesk, etc..), tu as des outils pour les backups complet sur un disque déporté.
En ayant tes sauvegardes (et seulement si tu as tes sauvegardes), tu vas alors avoir la mise à jour de PHP : ce n'est pas un simple "apt get" que tu vas lancer : tu risques d'avoir des dépendances et des éléments à mettre à jour...

Maintenant, tu as plusieurs scénarii :
- Tout se passe bien : tu fais tes backups, tu les as vérifié, tu as fait ton upgrade de php, ca baigne.
- y'a un truc qui se passe mal à un moment : tu fais tes backups, tu ne les as pas forcément vérifié, ton upgrade de php se passe mal, tu ne peux pas remonter le backup, etc...

Personnellement, j'imagine que si tu poses cette question, tu n'es pas forcément à l'aise avec toute la procédure et je te conseillerai 2 solutions qui pourrait t'éviter un souci avec tes clients (ou patrons) hébergés sur ce dédié :

- soit tu prends les services d'un prestataire externe qui te fait l'upgrade de php (et pourquoi pas qui te met en place des backups par la même occasion !)
- soit tu prends un 2e serveur pour 1 mois, tu fais une copie intégrale du 1er serveur sur le serveur d'upgrade, tu fais ton upgrade, tu vérifies que cela fonctionne et soit tu rebascules le 2e sur le 1er, soit tu bascules les pointages du 1er vers le 2e et tu fermes ensuite le 1er.

Dans tous les cas, je te déconseille fortement de faire ta mise à jour sur le 1er serveur correspondant à ton serveur de production : c'est vraiment très risqué.... (et encore une fois, j'écris cela parce que tu viens ici pour demander "comment faire une mise à jour php sur un dédié dont tu as la maintenance"...

Cordialement,

[clncln]

Bonjour chabi01,

Merci d'avoir pris le temps de me répondre;
J'ai effectivement la charge de la maintenance d'un dédié. Concernant les bakups, je sauvegarde régulièrement les "applications qui sont installées".
Pour Joomla, j'utilise Akeeba, pour les autres une copie des données et un export de la base.
Pour le système je ne réalise qu'une copie des fichiers de configurations qui sont sous /etc ainsi que la table des partitions et la liste des paquets installés.

Pour l'administration, j'utilise le panel IspConfig.

Concernant la migration vers Php 7.1 ou 7.2, je suis conscient que cela ne se résume pas à un simple "apt-get". D'où mon post afin de m'éclairer sur les précautions à prendre.

Je suis en train de suivre ta deuxième proposition en montant, a mon domicile, un deuxième serveur avec une configuration identique à mon serveur en ligne, afin de valider ma procédure de migration avant le "grand saut".

Cordialement.

[chabi01]

Hello
C'est le mieux Le pire, c'est de mettre les sites et services de tes clients (emails, etc...) en carafe.
Un client qui a son site hs pendant un moment, il supporte. Un client qui ne peut plus accéder à ses emails, pour beaucoup, c'est la fin du monde.
En théorie, cela ne devrait pas poser beaucoup de problèmes à migrer, mais faire une première fois la procédure sur un clone de ton serveur de prod te permettra d'éviter la catastrophe.

Quand j'ai eu besoin de faire ce genre de choses, j'avais pour cela 2 dédiés : les 2 dédiés permettait à chaque fois d'avoir un serveur de production et un serveur de développement. A chaque évolution, je faisais au départ un clone du production sur l'autre, je faisais mes mises à jour, vérifiait le bon fonctionnement puis basculait carrément les domaines de l'un à l'autre pour les pointages.
Pendant toute la procédure, j'avertissais simplement le client de ne pas travailler sur son site (pour éviter un décalage des contenus entre les 2 sites) et c'est tout.
Le plus compliqué, c'est quand tu as les emails gérés sur le même serveur que l'hébergement du site : là, c'est plus lourd puisque le client reçoit et envoie des emails en permanence, mais ça se gère aussi.

L'avantage, c'est également que si tu as 2 serveurs, tu peux avoir alors un RSync d'un serveur sur l'autre programmé périodiquement, ce qui fait que si tu as un serveur qui tombe, le 2e peut prendre le relais. En jouant même avec des ip Failover, tu peux alors ne jamais avoir de coupure. C'est très confortable par la suite puisque tu peux quasiment toujours avoir une solution de repli en cas de crash d'un serveur. C'est un peu ce que tu peux faire également avec les hébergements Cloud : tu as besoin de faire une grosse mise à jour ? Tu dupliques ta VM, tu fais ton boulot dessus, puis tu bascules en un clic de l'un à l'autre sans avoir de différence au niveau des sites, ça c'est top
Le meilleur montage, c'est des VM en cloud avec :
- un espace hébergement sur une VM
- Ta base Mysql sur un autre
- Tes emails sur une autre
Les serveurs sont alors monté "en grappe" avec un serveur d'entrée qui n'a virtuellement rien et qui renvoie ensuite sur les 3 autres.
A partir de là, tu as déjà une sécurité importante : une attaque ne touchera qu'un seul serveur, le serveur qui sert "d'aiguillage" vers les autres.
Ensuite, quand tu as besoin de faire une mise à jour, tu dupliques d'un clic le "disque" et tu bosses dessus, puis tu termines avec les pointages ou en activant le disque sur lequel tu as fait tes upgrades
Au départ, c'est un gros montage, mais ensuite, tu es quasiment toujours tranquille
Enfin, au niveau du tarif, tu payes souvent à la conso de bande passante, ce qui est intéressant parce que tu peux alors avoir des tarifs clients qui s'adaptent à la réalité de leur site.

L'inconvénient au niveau des dédiés, c'est que tu doubles le prix du serveur puisqu'il t'en faut 2... C'est pour cela aussi que les VM Cloud sont si intéressants

Cordialement,

[clncln]

Merci pour ces explications.

A part le site d'une association que je gère et dont je suis membre, ce serveur n'héberge que le cloud familial.
Le temps indisponibilité n'est donc pas important, malgré le fait que je souhaite le réduire au minimum pour l'exercice.

Sinon j'ai eu à gérer, sur un intranet, un serveur où l'on souhaitait une haute disponibilité.
Pour ce faire j'ai utilisé 2 serveurs refondés avec les outils Drbd et Heartbeat.
- Brdb gérant la duplication des données et bases d'un serveur vers l'autre, le principal vers le secours.
- Heartbeat gérant la surveillance entre serveurs et le basculement automatique en cas de défaillance du serveur principal.
Une belle configuration qui fonctionne parfaitement, mais les mise à jours système ne sont pas évidentes à réaliser;

Cordialement.

[lefabdu51]

tu est sur une Debian stable ?
Si c est le cas, alors tu n as pas compris ce que signifiait stable chez debian.
Stable pour Debian, c est on geles une version.... et on travailles ensuite a mettre touts les patchs de securité des version supérieures.
Ta Debian en php 7.0 est aussi sécurisée que la dernière version.
De plus, ce n est pas ta Debian qui te dit qu elle n est pas jour, mais ton script php.
Quand ta version n auras plus de support, alors Debian passera sur une version supérieure.
Donc ta migration se feras directement via apt.

si tu veux la derniere version, il faudras ajouter des paquets testing ou unstable.

Pour ta migration, tu vas devoir mixer des paquets stables et instables, donc tu risque de bien galérer.
Tu vas apprendre les commandes apt, si tu ne les connais pas déja en profondeur.
Il va falloir régler les priorités durant les mises à jour.

De plus, tu as toutes les dépendances à gérer.

Lis les reponses à la question posée et tu comprendras...
Ce n est pas moi qui le dit.
https://unix.stackexchange.com/quest...-debian-jessie

Pour ta sauvegarde, tapes apt-cache search backup-manager.
C'est un outil de sauvegarde simple et efficace.
Lis bien le fichier de configuration.
Tout est dedans.
Tu crées la sauvegarde de ton système, et ensuite tu l exportes.....



PS: admin réseaux depuis 2005 et sous debian depuis cette date.

[clncln]

Bonjourlefabdu51,

Merci pour ta réponse.
Effectivement j'envisageais de changer de version de PHP pour un problème de patch de sécurité.
Ne connaissant pas le principe des versions stables de Debian, pour moi changer de version était une nécessité pour rester à jour d'un point de vue sécurité.
Je vais donc rester comme cela.

Pour ma sauvegarde système, je vais regarder backup-manager.

Didier.