Les releases OVH sont des scripts bash qu'on télécharge et exécute sur un serveur dédié installé par OVH dans le but de le mettre à jour. Administrer la machine en ssh (shell sous bash).

Les avantages de ces patchs :

• rapidité,
• simplicité,
• stabilité.

Attention: n'appliquez pas la release si votre serveur est personalisé au niveau de la configuration.
Cela veut dire: php, apache, mysql. Tout les options de compilation seront perdue lors de l'application du patch. Certaines releases sont des patchs de sécurité, c'est à dire que si vous ne mettez pas à jour votre machine, votre machine risque d'être hackée très simplement.





Peu importe quel distribution ( Release 1 ou Release 2 ) vous utilisez simplement la commande suivante via ssh et non pas via webmin.




Les détails indiqué si dessous concernent surtout la Release 1 OVH.

Release ou patch : la release est un script qui se télécharge et s'exécute. Par exemple :



Lorsqu'il est telechargé et exécuté, le script regarde d'abord s'il est dans le bon n° de release avant de s'exécuter. Ceci evite qu'on execute la release 1.38 avant la release 1.34 par exemple.

n° de release : les releases s'exécutent dans un certain ordre. Historiquement nous avons commencé sur la 1.04. Si vous essayez d'executer les releases dans le mauvais sens elles refuseront de s'exécuter.


Pour faire fonctionner les releases, nous avons mis en place un système de blocage pour permettre l'exécution dans le bon sens. Nous avons donc créé le fichier /etc/ovhrelease où la release actuelle de la machine est notée. La nouvelle release va d'abord verifier que la release installée sur la machine est bien la précédente à elle-même et dans ce cas-là seulement, elle va s'exécuter.



À chaque execution de release on met à jour /etc/issue ce qui permet de voir le n° de release très simplement lors de la connection sur la machine :



Ceci nous permet aussi de voir le n° de release et l'ip de la machine en mettant l'écran et clavier. Lorsque votre machine a des problèmes cela nous fait gagner du temps de voir ces informations simplement sans aucune connexion en console.

Historique ou changelog est disponible sur
ftp://ftp.ovh.net/made-in-ovh/release/CHANGELOG.release.

Pour appliquer une nouvelle release, il suffit de se connecter en SSH sur la machine et de copier coller la commande.



Le patch commencera à s'exécuter et il fera son travail. Son exécution peut prendre plusieurs minutes.



Et voilà nous sommes passés de la release 1.37 à 1.38 et le serveur sshd a été mis à jour.


Pour éviter de regarder à chaque fois dans quelle release votre serveur se trouve, vous avez la possibilité d'executer un patch-all.sh qui exécute automatiquement les bonnes releases dans le bon sens. Vous n'avez rien à faire.



patch-all.sh lance toutes les détections et exécute ce qu'il faut



Et nous voilà en 1.39


Patch-all.sh met aussi votre machine à l'heure en utilisant un systeme de calcul de delta de décalage d'heure. C'est à dire qu'avant de mettre à jour l'heure il regarde de combien est votre décalage et met à jour ce chiffre. En suite clockspeed qui est installé sur votre machine utilise ce chiffre tous les X minutes pour corriger l'heure avec ce delta. Ce qui fait que votre machine est à l'heure tout le temps et pas seulement lorsque vous mettez à jour l'heure. Il ne faut pas exécuter trop souvent la mise à jour du décalage, car le calcul de décalage est meilleur sur des delais importants.


Les machines qui n'ont pas été installées en release (avant une certaine date) peuvent être mise à jour avec les patchs. Les patchs sont des scripts relativements automatisés, testés sur plusieurs plateformes (et donc possedant une detection de la plateforme). Mais vu que chaque machine est differente avec sa propre histoire, il faut les adapter à chaque machine. Vous pouvez donc les telecharger, les éditer, modifier et exécuter en suite. Si vous avez des erreurs de compilation, consultez les mailing-lists comme sd@ml.ovh.net. N'envoyez pas d'email sur le support. Nous n'allons pas pouvoir vous aider sur ce genre des problèmes via le support, car la solution au problème n'est pas une réponse mais une discussion. Et donc il faut utiliser les mailing-lists.

Les patchs se trouvent dans ftp://ftp.ovh.net/made-in-ovh/patch. Vous avez :

• les patchs pour apache (serveur web) :

-rwxr-xr-x 3517 jui 7 2002 apache_1.3.26+mod_ssl-2.8.10+php_4.2.1.sh
-rwxr-xr-x 3517 jui 22 2002 apache_1.3.26+mod_ssl-2.8.10+php_4.2.2.sh
-rwxr-xr-x 3517 sep 11 2002 apache_1.3.26+mod_ssl-2.8.10+php_4.2.3.sh
-rwxr-xr-x 3656 oct 4 2002 apache_1.3.27+mod_ssl-2.8.11+php_4.2.3.sh
-rwxr-xr-x 4567 jun 20 2003 apache_1.3.27+mod_ssl-2.8.14+php_4.3.2.sh
-rwxr-xr-x 4567 aoû 31 2003 apache_1.3.28+mod_ssl-2.8.15+php_4.3.3.sh
-rwxr-xr-x 4601 déc 4 21:44 apache_1.3.29+mod_ssl-2.8.16+php_4.3.4.sh

• les patchs pour bind (named) :

-rwxr-xr-x 825 jui 7 2002 named_8.3.3.sh
-rwxr-xr-x 2320 jui 22 15:55 named_9.2.1-noshell.sh
-rwxr-xr-x 2407 jui 8 2002 named_9.2.1.sh

• les patchs pour ssh :

-rw-r--r-- 2481 sep 29 02:23 rebuild-ssh-auto.sh
-rw-r--r-- 2188 mar 24 2003 rebuild-ssh-downgrad.sh
-rw-r--r-- 2564 sep 28 20:10 rebuild-ssh.sh

• les patchs pour ssl :

-rw-r--r-- 1086 mar 24 2003 rebuild-ssl-downgrad.sh
-rw-r--r-- 1079 mar 23 2003 rebuild-ssl.sh

• et autres :

-rw-r--r-- 1234 jun 17 12:25 patch_reboot.sh
-rw-r--r-- 403 mar 4 2002 patch_resolv.sh
-rwxr-xr-x 627 jun 2 14:28 check_reboot.sh
-rw-r--r-- 634 jui 10 2002 a_l_heure.sh
-rwxr-xr-x 2230 aoû 22 2002 rc.sysinit.patch.sh



Voici une machine avec un ssh et openssl qui n'est pas à jour:



Nous allons d'abord recompiler openssl parcequ'il est utilisé par les autres softs comme apache, ssh, qmail etc.


5 minutes plus tard



Ça y est. On est sur la bonne version d'openssl. On va passer maintenant à ssh :



Mettons un noyau plus recent:



On recompile apache maintenant :



Pas bon ça. ça veut dire qu'il y a une version d'openssl compilé à la main :



On recommence:



15 minutes plus tard:






Vous pouvez mettre à jour votre release 3 à partir de votre accès ssh sur votre serveur dédié et de la commande suivante :



Si votre release est à jour, vous devez rencontrez le message suivante lors de l'exécution de la commande :




Pour la mise à jour de vos packages , veuillez vous rendre sur votre webmin, puis si une mise à jour est disponible vous trouverez dans votre page principale ceci:



Vous cliquez sur 1 package update are available, puis update upgrade package.

Ce qui vous donnera un résultat de ce type :



Pour information, pour connaitre la version de votre release, je vous invite à executer la commande suivante via votre accès ssh:



Le changelog est disponible à l'adresse suivante
ftp://ftp.ovh.net/made-in-ovh/release/

Puis veuillez sélectionner la version souhaité ex : update_3.25-3.26/CHANGELOG
Soit l'url suivante pour l'update de la version 3.25 vers 3.26.

ftp://ftp.ovh.net/made-in-ovh/release/update_3.25-3.26/CHANGELOG