[buddy]

Si tu as un VPS ou que tu veux monter un container avec de la virtualisation, tu as la solution all in one Zimbra (il existe une version gratuite).

Pour migrer le tout avec les mots de passe et etc .. effectivement, çà risque d'être complexe. Je n'avais migré que les mails et avait dit aux utilisateurs de changer leur MDP (seulement 10 ou 15 utilisateurs).

[ccpz]

et l'installation de qmail et de tous les trucs pratiques qui allaient avec sur la R2 (vpopmail par exemple) sur une autre distribution genre debian qui était source d'arrachage de cheveux

[Bruno_Brazil]

J'ai cherché un bout de temps comment migrer ces mails... Mon GROS souci, c'est que il y a plein de comptes à recréer, dont j'ignore totalement les mots de passe ! Et il est hors de question de forcer un nouveau mot de passe pour chaque compte, on ne dispose pas d'une adresse de secours pour chaque mail, car le responsable de chaque site gère ses comptes mail.

Je n'ai jamais réussi à trouver une solution convaincante, alors j'ai fini par laisser tomber... Mais si une solution plus ou moins straightforward existe, je suis preneur !

[buddy]

Pour qmail c'est possible de migrer avec des outils comme IMAP copy
Je l'ai fait en copiant environ 20 Go de mails.
Ça prend du temps mais après tu es tranquille.

J'en avais aussi fait une autre avec un outil qui transforme les mails qmail en postfix. Ça prend un peu de temps mais etre débarrassé de qmail et partir sur postaux après ça limite les maj du serveur et le temps perdu dessus.

[ccpz]

Oui, c'est curl 7.16 qui date de 2007.

La migration de qmail, la plaie ! Le jour où je n'ai plus eu besoin de qmail (envoi par un prestataire extérieur) ça m'a fait comme un soulagement ...

Tout ça fait beaucoup de compilations hasardeuses (je suis pas trop admin) pour garder une antiquité. Je vais tenter CentOS 7, bye bye Gentoo

[Bruno_Brazil]

Salut,

Sur une R2 ça me semble plus complexe...

Ton souci, c'est déjà openSSL. Il est en version 0.9.8o sur R2, mais tu dois déjà la mettre à jour vers 1.0.1. Et comme pour tout sur Gentoo, tu dois recompiler pour ça...

Si tu réussis ton passage à 1.0.1, tu pourras ensuite regarder pour CURL, sachant que il est encore à la version 7.16 sur cette release...

Ensuite, il faudrait aussi voir php5-curl, si c'est à jour, et par la même occasion tu dois passer ton PHP à une version à peu près récente. Moi, j'a dû réussir à la monter à la 5.3.8, mais pas plus... La version d'Apache, elle, doit être à la 2.2.20... Si tu la passes à la 2.2.31 tu seras à jour !

Maintenir la R2 à jour devient très difficile, j'en ai encore un serveur avec, que je ne bascule pas à cause des boîtes mail que il y a dessus, il y en a pour un paquet de gigas. Je tiens le kernel à jour, mais Qmail n'a plus été mis à jour depuis des lustres, alors ça reste comme ça...

[buddy]

si tu veux une distribution épurée debian ou centos. (les plus utilisées dans le monde). il y a aussi ubuntu, mais c'est basé sur debian, donc autant prendre debian directement.

Si tu veux, tu peux ajouter par dessus un panel style virtualmin. .

[ccpz]

C'est pas faux, j'ai déjà du bidouiller des scripts fournis par des partenaires car php n'était plus à jour plusieurs fois...
L'embêtant c'est que des sites de ecommerce tournent dessus, il faut pas tomber en rade avec une config mal foutue...

Bref, changer de distri et de serveur semble nécéssaire, la R3 est maintenant aussi déjà dépassée. Quelle distri est conseillée pour faire tourner du mysql/apache/php, sans interface jolie et tout, mais de la perf ?

[buddy]

Tout est toujours possible...
Mais elle n'est même plus supporté par gentil ( la base de la r2)
Elle a 10 ans. Même php et apache doivent être end of life (les failles ne sont plus corrigées)
Il faut migrer vers virtualmin par exemple..

[ccpz]

Bonjour,
Penses-tu qu'un hack est faisable sur une R2 pour disposer du TLS 1.2 avec curl / php ?

[buddy]

Le plus simple serait de repartir sur quelque chose de "libre" complètement comme https://www.how-to.ovh/viewforum.php...079f8633ed9283

tu installes débian en dessous et virtualmin pour l'interface (les 2 ont une grosse communautés donc çà "avance).

[Bruno_Brazil]

Re-bonjour à tous,

ça y est, je me suis demerdé...

J'ai cherché un peu pour comprendre le plugin de yum qui gère les prios. J'ai ensuite vérifié au niveau de mes repos : le dépôt local (celui géré par OVH était en prio 1 (logique) et le repo city-fan n'avait pas de prio. J'ai donc inversé le bazar, et j'ai mis le repo local à 2, et city-fan à 1. Ensuite, j'ai relancé mon yum install curl : MAJ faite sans le moindre souci !!

Ensuite, j'ai mis un script sur mon serveur pour voir quelle version de TLS PHP utilisait. C'est bien la 1.2 maintenant. Donc, mon serveur donne ce que j'espérais. Même si je suis hors-release maintenant...

Par contre, ma boutique Prestashop me donnait toujours un blocage : Visiblement le plugin officiel paypal de Prestashop (3.10.6) est buggé, et celui qui gère la boutique l'avait mis à jour... Du coup, j'ai fait un rollback à la version 3.10.2, grâce à des membres du forum prestashop qui avaient mis la vieille version en téléchargement. J'ai remplacé, et OUF, c'est reparti !!

J'aime pas ces bidouillages, mais là au moins j'ai pu gérer... Maintenant, je vais voir quoi faire pour une solution durable. En attendant, je dis... Merci OVH de ne pas faire votre boulot de mise à jour de votre propre distro... Si on ne sait pas ou on ne veut pas gérer, on ne propose pas...

[Bruno_Brazil]

Salut,

Le mode hack, je l'ai déjà géré 2 fois, effectivement c'est galère... Mais c'était sur la R2. J'ai même une fois eu un plantage disque...

Alors, si la virtualisation est jouable, peut-elle se faire sur une machine qui a déjà une R3 installée, sans supprimer cette install ? Car si oui, une fois la virtualisation en place, je pourrai ensuite migrer les sites un à un, sans stresser...

Merci par avance !

[janus57]

Bonjour,

si vous avez un dédié qui se tourne les pouces passez à la virtualisation (sur le serveur) ou carrément à des VPS/Public cloud.

Exemple de virtualisation possible sur le serveur :
4 VM :
1 VM sites production
1 VM MySQL
1 VM pré-prod
1 VM supplémentaire pour les sites de production si on veux en isoler certains (qui reçoit plus de trafic que les autres par exemple).

Meilleurs utilisation des ressources + meilleurs isolation (si par exemple à la place de 1 VM de prod on en a 2-3 pour diminuer le nombre de sites par VM et donc limiter les risque en cas de faille sur un CMS/Site).

Par contre oui la virtualisation va peut être utiliser 5% de ressources en plus mais si le serveur se tourne les pouces à 90% il ne le fera plus qu'a 85% minimum.

Sinon la R3 c'est une très mauvaise idée de la maintenir car si vous regardez les logiciels installé dessus vous allez très certainement vous rendre compte que certains ont des vulnérabilités connus et sans doute exploité (donc bonne chance si jamais votre serveur de fait pirater et passer en anti-hack, là ce sera un poil plus tendu qu'une migration qui se sera préparé 15jours à l'avance).

P.S. une migration peu vite se faire si vous transférer temporairement les sites sur du public cloud facturé à l'heure pour les garder en ligne puis après les remettre sur le dédié d’origine qui aura été revue niveau structure, et oui cela va quand même créer des temps d'indisponibilités lié au DNS.

Cordialement, janus57

[Bruno_Brazil]

Salut !

Déjà, merci pour les réponses. Ce qu'elles disent, ça ne m'étonne pas... Mais quand le serveur a été installé, il y a un peu plus de 1 an, la boîte avait tourné pendant 6 ans avec une R2, et comme je ne suis pas le seul à utiliser le serveur (d'autres l'utilisent, sans y connaître grand chose, en se limitant au panneau OVHM). J'avais réussi tant bien que mal à maintenir la R2 à peu près à jout, en y ajoutant même PHP 5.3. Du coup, La R3 avait des mises à jour régulières, alors on y est allés... J'ai déjà eu des soucis, en particulier avec la version de PHP, mais j'ai réussi à y mettre en place PHP 5.4. Maintenant, on a un paquet de sites qui tournent dessus, et je ne peux même pas envisager de arrêter tout le monde, et de lancer une migration pour laquelle je n'ai ni les moyens physiques ni matériels... Donc, je voudrais vraiment trouver une façon de m'en sortir !

La R3 reste une centOS à la base, non ? Du moins, j'espère... Donc, si j'arrivais à virer cette prio des dépôts OVH, pour mettre le dépôt city-fan en tête, ça devrait bien me mettre à jour cURL et toutes ses dépendances, non ? Seulement, je ne vois pas sur cette distro comment je gère ces protections de priorité, je dois avouer que centOS, c'est la première fois que j'en gère un...

Ce que je ne comprends pas, par contre, c'est comment OVH ose proposer une release qu'ils abandonnent en cours de route, après quoi, 2 ans d'exploitation ? Et si je reformate et réinitialise le serveur, je suis sûr que ils proposent encore la R3...

Une question très probablement stupide, mais qui sait... On a un dédié, pas un serveur virtuel. Sur la machine en question, 90% des ressources sont toujours dispo. Est-ce que je ne pourrais pas créer un 2ème serveur virtuel, sans toucher au premier, qui reste fonctionnel à part sur les moments de redémarrage, pour ensuite basculer les sites d'un serveur à l'autre, voire exploiter les 2 en simultané ? C'est peut-être du délire total, je n'ai jamais entendu parler d'une manip du genre, mais bon, si ça me permettait de me sortir du m*rdier dans lequel OVH m'a mis...

Merci pour toute autre idée, je suis preneur...

[florent060]

Bonjour

suis entièrement d'accord avec Janus57, la R3...... J'utilise VIRTUALMIN et aucun problème avec Curl, Paypal et TLS.

A bon entendeur . d'ailleurs je viens de voir ce message:

https://forum.ovh.com/showthread.php...puis-24H/page2

A propos de la R3.

Cordialement

[janus57]

Bonjour,

le plus simple serait de partir sur autre chose (ispconfig ou un virtualmin) car même la TeamOVH visiblement dit de voir ailleurs.

Cordialement, janus57

[Bruno_Brazil]

Bonjour à tous,

Je gère un serveur qui héberge, entre autres, une boutique prestashop.

Depuis quelques jours, j'ai le message sur le module paypal, disant que il faut impérativement utiliser TLS 1.2.

La release supporte bien la TLS 1.2, j'ai testé, et la version de openSSL est bonne. Cependant, je bute sur le version de cURL...

La release a une version 7.19.7. Or, cURL ne supporte TLS 1.2 que à partir de la version 7.34 !! Du coup, php-curl ne pourra jamais utiliser la bonne version de TLS, et prendra toujours la 1.0.

J'ai bêtement tenté d'abord la mise à jour via le menu kivabien sur webmin, dans la partie OVHM (ça exécute le patch-all habituel...). Là, ça dit juste que... tout est OK. Mais j'ai toujours cette vieille version de cURL. Mais je m'en doutais... Ensuite, je passe aux choses sérieuses, via SSH. Je tente un yum update (enfin, via le chemin correct). ça m'a mis un tas de paquets à jour, mais... Pas cURL !!! Là ça se corse... Le dépôt prédéfini reste sur la version 7.19.7.

Alors, je tente de contourner. J'ai rajouté un dépôt (http://www.city-fan.org/ftp/contrib/...el6.noarch.rpm). Ensuite, j'ai tenté de lancer un yum install libcurl. Mais ça bloque toujours !! ça me dit : "2087 packages excluded due to repository priority protections". Donc, en gros il y a une prio qui est donné aux dépôts OVH, et je peux aller me gratter avec mes dépôts city-fan ! J'imagine que c'est pour qe les gens ne se trouvent pas hors-release par accident, mais là la release a clairement un (voire plusieurs) trains de retard... Il est clairement impossible de passer au dessus de la 7.34, et du coup Prestashop ne risque pas de voir la TLS 1.2...

En réalité, déjà un certain nombre de transactions est en train d'échouer sur paypal. Donc, il y a urgence !

Alors, quoi faire sur ce coup ?

Merci pour toute aide...