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

Réduire
X
  • Filtrer
  • Heure
  • Afficher
Tout effacer
nouveaux messages

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

    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.

  • #2
    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
    “Un message d’erreur sur votre site Joomla ... ayez le reflexe de consulter le nouveau service (en Beta) de la base de connaissance https://kb.joomla.fr
    Ce forum, vous l'aimez ? il vous a sauvé la vie ? Vous y apprenez chaque jour ? Alors adhérer à l'AFUJ https://www.joomla.fr/association/adherer

    Commentaire


    • #3
      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 ?
      adishatz, érix
      https://www.agerix.fr/
      Vous aimez ce forum ? Aidez-nous à le maintenir en adhérant à l'AFUJ : https://www.joomla.fr/association/adherer

      Commentaire


      • #4
        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.
        Connaissez-vous la loi de Murphy ? Appliquée à Joomla elle pourrait s'énoncer ainsi :
        C'est toujours lorsqu'on n'a pas pris le temps de faire une sauvegarde que les problèmes surgissent et s'enchainent.
        Moralité : faites des sauvegardes, elles vous paraitront peut-être superflues mais elles ne sont jamais inutiles.

        Commentaire


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

          Commentaire


          • #6
            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.
            Connaissez-vous la loi de Murphy ? Appliquée à Joomla elle pourrait s'énoncer ainsi :
            C'est toujours lorsqu'on n'a pas pris le temps de faire une sauvegarde que les problèmes surgissent et s'enchainent.
            Moralité : faites des sauvegardes, elles vous paraitront peut-être superflues mais elles ne sont jamais inutiles.

            Commentaire


            • #7
              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.

              Commentaire


              • #8
                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.
                Connaissez-vous la loi de Murphy ? Appliquée à Joomla elle pourrait s'énoncer ainsi :
                C'est toujours lorsqu'on n'a pas pris le temps de faire une sauvegarde que les problèmes surgissent et s'enchainent.
                Moralité : faites des sauvegardes, elles vous paraitront peut-être superflues mais elles ne sont jamais inutiles.

                Commentaire


                • #9
                  Merci lesoutier, j'attends ton retour.

                  Commentaire


                  • #10
                    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,
                    Chabi01 - http://www.xlformation.com

                    Commentaire


                    • #11
                      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.

                      Commentaire


                      • #12
                        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,

                        Chabi01 - http://www.xlformation.com

                        Commentaire


                        • #13
                          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.

                          Commentaire


                          • #14
                            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.
                            Dernière édition par lefabdu51 à 30/09/2018, 11h06
                            Mon site en cours de construction avec de nouvelles catégories de documents...
                            https://informaticien51.fr

                            Commentaire


                            • #15
                              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.

                              Commentaire

                              Annonce

                              Réduire
                              1 sur 2 < >

                              C'est [Réglé] et on n'en parle plus ?

                              A quoi ça sert ?
                              La mention [Réglé] permet aux visiteurs d'identifier rapidement les messages qui ont trouvé une solution.

                              Merci donc d'utiliser cette fonctionnalité afin de faciliter la navigation et la recherche d'informations de tous sur le forum.

                              Si vous deviez oublier de porter cette mention, nous nous permettrons de le faire à votre place... mais seulement une fois
                              Comment ajouter la mention [Réglé] à votre discussion ?
                              1 - Aller sur votre discussion et éditer votre premier message :


                              2 - Cliquer sur la liste déroulante Préfixe.

                              3 - Choisir le préfixe [Réglé].


                              4 - Et voilà… votre discussion est désormais identifiée comme réglée.

                              2 sur 2 < >

                              Assistance au forum - Outil de publication d'infos de votre site

                              Compatibilité: PHP 4.1,PHP4, 5, 6DEV MySQL 3.2 - 5.5 MySQLi from 4.1 ( @ >=PHP 4.4.9)

                              Support Version de Joomla! : | J!3.0 | J!2.5.xx | J!1.7.xx | J!1.6.xx | J1.5.xx | J!1.0.xx |

                              Version française (FR) D'autres versions sont disponibles depuis la version originale de FPA

                              UTILISER À VOS PROPRES RISQUES :
                              L'exactitude et l'exhaustivité de ce script ainsi que la documentation ne sont pas garanties et aucune responsabilité ne sera acceptée pour tout dommage, questions ou confusion provoquée par l'utilisation de ce script.

                              Problèmes connus :
                              FPA n'est actuellement pas compatible avec des sites Joomla qui ont eu leur fichier configuration.php déplacé en dehors du répertoire public_html.

                              Installation :

                              1. Téléchargez l'archive souhaitée : http://afuj.github.io/FPA/

                              Archive zip : https://github.com/AFUJ/FPA/zipball/master

                              2. Décompressez le fichier de package téléchargé sur votre propre ordinateur (à l'aide de WinZip ou d'un outil de décompression natif).

                              3. Lisez le fichier LISEZMOI inclus pour toutes les notes de versions spécifiques.

                              4. LIRE le fichier de documentation inclus pour obtenir des instructions d'utilisation détaillées.

                              5. Téléchargez le script fpa-fr.php à la racine de votre site Joomla!. C'est l'endroit que vous avez installé Joomla et ce n'est pas la racine principale de votre serveur. Voir les exemples ci-dessous.

                              6. Exécutez le script via votre navigateur en tapant: http:// www. votresite .com/ fpa-fr.php
                              et remplacer www. votresite .com par votre nom de domaine


                              Exemples:
                              Joomla! est installé dans votre répertoire web et vous avez installé la version française du fichier FPA:
                              Télécharger le script fpa-fr.php dans: /public_html/
                              Pour executer le script: http://www..com/fpa-fr.php

                              Joomla! est installé dans un sous-répertoire nommé "cms" et vous avez installé la version française du fichier FPA:
                              Télécharger le script fpa-fr.php dans: /public_html/cms/
                              Pour executer le script: http://www..com/cms/fpa-fr.php

                              En raison de la nature très sensible de l'information affichée par le script FPA, il doit être retiré immédiatement du serveur après son utilisation.

                              Pour supprimer le script de votre site, utilisez le lien de script de suppression fourni en haut de la page du script. Si le lien de suppression échoue pour supprimer le script, utilisez votre programme FTP pour le supprimer manuellement ou changer le nom une fois que le script a généré les données du site et le message publié sur le forum. Si le script est toujours présent sur le site, il peut être utilisé pour recueillir suffisamment d'informations pour pirater votre site. Le retrait du script empêche des étrangers de l'utiliser pour jeter un oeil à la façon dont votre site est structuré et de détecter les défauts qui peuvent être utilisé à vos dépends.
                              Voir plus
                              Voir moins
                              Travaille ...
                              X