A black and white photo of the statue of Apollo.

Nouveau serveur dédié OVH : Apollo

J’ai craqué pour un nouveau serveur chez OVH. C’est mon premier serveur OVH, si l’on considère que je n’ai jamais utilisé que des Kimsufi auparavant, depuis mars 2010.

Voyons voir ce qu’il a dans le ventre.

Processeur

On obtient les spécifications du processeur:

lscpu

Ce qui nous donne:

lscpu

Architecture:            x86_64
  CPU op-mode(s):        32-bit, 64-bit
  Address sizes:         39 bits physical, 48 bits virtual
  Byte Order:            Little Endian
CPU(s):                  16
  On-line CPU(s) list:   0-15
Vendor ID:               GenuineIntel
  Model name:            Intel(R) Xeon(R) E-2288G CPU @ 3.70GHz
    CPU family:          6
    Model:               158
    Thread(s) per core:  2
    Core(s) per socket:  8
    Socket(s):           1
    Stepping:            13
    CPU max MHz:         5000.0000
    CPU min MHz:         800.0000
    BogoMIPS:            7399.70
    Flags:               fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts a
                         cpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch
                         _perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq
                         dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_
                         2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowp
                         refetch cpuid_fault epb invpcid_single ssbd ibrs ibpb stibp ibrs_enhanced tpr_shadow
                         vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpci
                         d mpx rdseed adx smap clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves dtherm ida a
                         rat pln pts hwp hwp_notify hwp_act_window hwp_epp md_clear flush_l1d arch_capabilitie
                         s
Virtualization features:
  Virtualization:        VT-x
Caches (sum of all):
  L1d:                   256 KiB (8 instances)
  L1i:                   256 KiB (8 instances)
  L2:                    2 MiB (8 instances)
  L3:                    16 MiB (1 instance)
NUMA:
  NUMA node(s):          1
  NUMA node0 CPU(s):     0-15
Vulnerabilities:
  Gather data sampling:  Mitigation; Microcode
  Itlb multihit:         KVM: Mitigation: VMX disabled
  L1tf:                  Not affected
  Mds:                   Not affected
  Meltdown:              Not affected
  Mmio stale data:       Mitigation; Clear CPU buffers; SMT vulnerable
  Retbleed:              Mitigation; Enhanced IBRS
  Spec store bypass:     Mitigation; Speculative Store Bypass disabled via prctl and seccomp
  Spectre v1:            Mitigation; usercopy/swapgs barriers and __user pointer sanitization
  Spectre v2:            Mitigation; Enhanced IBRS, IBPB conditional, RSB filling, PBRSB-eIBRS SW sequence
  Srbds:                 Mitigation; Microcode
  Tsx async abort:       Mitigation; TSX disabledCode language: JavaScript (javascript)

Nous avons donc un Intel(R) Xeon(R) E-2288G CPU @ 3.70GHz (8c/16t), avec toutes les corrections appliquées pour corriger les vulnérabilités.

C’est une belle mise à jour par rapport à l’ancien serveur, qui était un Intel(R) Xeon(R) CPU W3530 @ 2.80GHz (4c/8t), qui n’était pas aussi sécurisé.

Bande passante

On passe sur une bande passante à 500Mbit/s et non plus en 100Mbit/s, toujours en illimité (unmetered).

Mémoire et disques

On reste sur 32GB de RAM mais on double sa vitesse: on passe de la DDR3 @ 1333 MHz à de la DDR4 ECC @ 2666 MHz:

sudo dmidecode -t memory | grep -i speed

Résultat:

Speed: 2666 MT/s
Configured Memory Speed: 2666 MT/s

Au niveau des disques, changement également: nous avions 2 × 2TB Soft RAID avec des disques durs classiques et maintenant on passe sur 2 × 960GB SSD NVMe Soft RAID.

Système d’exploitation

On reste sous Ubuntu Server, qui est vraiment agréable à utiliser et configurer. J’ai été surpris de voir que lorsqu’on installe Ubuntu Server 22.04 de rien, il crée un utilisateur par défaut, qui n’est pas root. C’est plutôt bien, mais ce n’était pas le cas avec Ubuntu Server 18.04 (root était alors le seul utilisateur créé lors de l’installation).

C’est bien au quotidien, pour la migration, il a fallu pas mal changer les commandes rsync toutefois.

Migration d’Orion à Apollo

La migration s’est bien déroulée. D’ailleurs, si vous pouvez lire cet article, c’est que le site est bien servi par Apollo.

Outre les fichiers et les bases de données, c’est aussi tout le serveur email qui a été entièrement recréé.

La bonne nouvelle, c’est que c’est plus simple que ce j’avais fait la première fois avec Postfix et Courier. La moins bonne nouvelle, c’est que cela prend un temps fou parce qu’il y a environ une quinzaine de fichiers à éditer constamment pour que tout soit parfait.

Bonus du serveur email: il est mieux configuré que le précédent, avec une configuration plus simple mais mieux sécurisée, et toujours avec DNSSEC et DANE.

J’ai écrit pas mal de scripts bash pour automatiser certaines installations dans le cadre d’une future migration. On en reparle bientôt!

Serveur dédié : mise à jour du kernel OVH pour combler les failles Spectre et Meltdown photo

Serveur dédié : mise à jour du kernel OVH pour combler les failles Spectre et Meltdown

Au début du mois de février, l’université de Graz et Google Project Zero ont annoncé avoir découvert deux failles de sécurité importantes s’appuyant sur les mécanismes de fonctionnement interne des processeurs.

Trois vulnérabilités permettant d’accéder à de la mémoire privilégiée ont été publiées, qui ont pour point commun d’exploiter les mécanismes d’exécution spéculative et les timings des caches mémoires.

Meltdown

La première faille, Meltdown (CVE-2017-5754), permet de bypasser les mécanismes d’isolation mémoire entre mémoire classique (utilisée par les applications) et mémoire kernel (utilisée par le noyau du système d’exploitation, et protégée normalement par des mécanismes hardware dans le CPU).

Meltdown est une attaque side channel permanent;qui s’attaque à une faille de certains processeurs OOO (Out Of Order, la plupart des processeurs performants modernes depuis le Pentium Pro) qui, dans leur mécanismes d’exécution spéculatifs, peuvent non seulement lire des données mémoires protégées mais aussi exécuter des instructions sur ces données mémoires.

Concrètement, avec Meltdown, il est possible de lire tout type de mémoire à partir d’un process malicieux, y compris côté serveur de bypasser toutes les protections de type VM/Hyperviseur/Docker. Meltdown touche spécifiquement les architectures d’Intel et ARM.

Spectre

En parallèle à Meltdown, une autre faille a été dévoilée baptisée Spectre. permanent;Pour Spectre, la situation est plus compliquée. Il s’agit toujours d’une variation sur le même thème, à savoir tenter d’exploiter les mécanismes d’exécution spéculative des processeurs. T

ous les processeurs modernes sont concernés a différents niveau et l’on retrouve, y compris chez un même constructeur, des différences d’une architecture à l’autre en fonction des mécanismes précis de fonctionnement de chaque génération.

Le papier décrit deux attaques distinctes. La première, connue sous le nom de CVE-2017-5753 (bounds check bypass) permet à un processus d’accéder, dans certains conditions un peu plus complexes, à la mémoire d’un autre processus.

Contrairement à Meltdown dont l’exploitation est triviale, il faut ici connaître les spécificités du programme que l’on attaque pour réussir à l’exploiter.

Le groupe Google Project Zero a montré que cette attaque était exploitable aussi bien sur les CPU Intel, AMD (FX et APU), et ARM (un Cortex A57 à été testé). Si tous les processeurs sont exploitables, c’est que tous les modèles OOO modernes reposent, dans les grandes lignes, sur l’algorithme de Tomasulo, du nom de l’ingénieur qui l’a développé en 1967 chez IBM.

Virtuellement, tous les systèmes (du serveur au smartphone) sont vulnérables à cette attaque pour laquelle des PoC existent même en Javascript (pour bypasser les barrières des VM qui isolent le code Javascript de vos différents onglets), ce qui la rend assez grave.

Des méthodes de mitigations, aussi bien au niveau des compilateurs, des navigateurs, et des systèmes d’exploitations sont en cours de développement et des patchs sont attendus rapidement pour limiter le problème.

Vous pouvez retrouver les détails techniques des failles Spectre et Meltdown chez OVH.

Mon machine est-elle touchée par ces failles?

Il vous suffit de tester votre processeur avec le script Spectre & Meltdown Checker:

curl -L https://meltdown.ovh -o spectre-meltdown-checker.sh
chmod +x spectre-meltdown-checker.sh
sh ./spectre-meltdown-checker.shCode language: JavaScript (javascript)

Résultat avant la mise à jour du kernel:

CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
* Checking count of LFENCE opcodes in kernel:  NO 
> STATUS:  VULNERABLE  (only 46 opcodes found, should be >= 70, heuristic to be improved when official patches become available)

CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Mitigation 1
*   Hardware (CPU microcode) support for mitigation:  NO 
*   Kernel support for IBRS:  NO 
*   IBRS enabled for Kernel space:  NO 
*   IBRS enabled for User space:  NO 
* Mitigation 2
*   Kernel compiled with retpoline option:  NO 
*   Kernel compiled with a retpoline-aware compiler:  NO 
> STATUS:  VULNERABLE  (IBRS hardware + kernel support OR kernel with retpoline are needed to mitigate the vulnerability)

CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
* Kernel supports Page Table Isolation (PTI):  NO 
* PTI enabled and active:  NO 
> STATUS:  VULNERABLE  (PTI is needed to mitigate the vulnerability)Code language: JavaScript (javascript)

Mise à jour du kernel OVH

Sur la Kimsufi, c’est le kernel OVH 4.9.87 qui intégre tous les correctifs Meltdown et Spectre, ainsi que la mise à jour du microcode pour les puces Intel.

Il suffit de suivre le tutoriel pour mettre à jour le noyau OVH.

Après mise à jour du noyau et redémarrage du serveur, les failles semblent maintenant comblées:

CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
* Checking whether we're safe according to the /sys interface:  YES  (kernel confirms that the mitigation is active)
> STATUS:  NOT VULNERABLE  (Mitigation: __user pointer sanitization)

CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Checking whether we're safe according to the /sys interface:  YES  (kernel confirms that the mitigation is active)
> STATUS:  NOT VULNERABLE  (Mitigation: Full generic retpoline)

CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
* Checking whether we're safe according to the /sys interface:  YES  (kernel confirms that the mitigation is active)
> STATUS:  NOT VULNERABLE  (Mitigation: PTI)

Voilà, mettez vos noyaux à jour, c’est important.

Hébergement OVH : passer à TLS 1.2 pour WooCommerce et PayPal photo 1

Hébergement OVH : passer à TLS 1.2+ pour WooCommerce et PayPal

Si vous possédez une boutique en ligne et que vous acceptez PayPal comme moyen de paiement, vous n’êtes pas sans savoir qu’à partir du 30 juin, PayPal exigera une connexion TLS version 1.2 pour gérer la transaction entre votre boutique et PayPal.

Concrètement, votre serveur ou votre hébergement doit être configuré pour servir les pages en HTTPS (certificat SSL obligatoire) et avec une version d’OpenSSL qui donne la priorité au protocole TLS version 1.2+.

Hébergement OVH : passer à TLS 1.2 pour WooCommerce et PayPal photo 1

Chez OVH, la version d’OpenSSL dépend de la version de PHP configurée pour votre hébergement et surtout du mode utilisé. Pour avoir la dernière version d’OpenSSL, il faut absolument être en mode Stable.

Cela ne prend que quelques minutes à configurer.

TLS sur un serveur dédié

Dans le cas de votre serveur dédié, il suffit de mettre à jour OpenSSL et d’éditer la configuration du serveur (Apache / nginx) pour désactiver les protocoles SSL, TLSv1, TLS v1.1 pour ne garder que TLS v1.2 et TLS v1.3.

TLS sur un hébergement mutualisé OVH

Dans le cadre d’un hébergement mutualisé OVH voici la marche à suivre. Commencez par vous rendre dans le Manager OVH puis :

  1. activer le certificat SSL Let’s Encrypt.
  2. choisir une version de PHP récente en mode Stable.
  3. passer l’intégralité de votre WordPress / Woocommerce en https (si ce n’est déjà fait mais si vous avez une boutique en ligne, ce devrait être le cas depuis longtemps).

En image, voici ce que cela donne :

Hébergement OVH : passer à TLS 1.2 pour WooCommerce et PayPal photo

C’est l’étape 2 qui est primordiale pour activer TLS 1.2 : cela permet de passer d’OpenSSL 0.9.8 à OpenSSL 1.0.1t à l’heure où j’écris ces lignes.

Vérification TLS v1.2

Pour connaître la version d’OpenSSL en vigueur sur votre serveur :

openssl version

Enfin, pour savoir si la connexion entre votre serveur et les serveurs de PayPal se fait bien à l’aide du chiffrement TLS 1.2, lancez cette commande sur votre serveur/hébergement dans un terminal :

php -r '$ch = curl_init(); curl_setopt($ch, CURLOPT_URL, "https://tlstest.paypal.com/"); var_dump(curl_exec($ch)); var_dump(curl_error($ch));'Code language: JavaScript (javascript)

Si la connexion est bien servie en TLS 1.2, le résultat devrait être :

PayPal_Connection_OKbool(true)
string(0) ""Code language: JavaScript (javascript)

Voilà, en espérant que cela puisse vous servir. C’est simple à mettre en place et ne prend que quelques minutes pour retrouver un chiffrement plus sécurisé.

Si vous avez besoin d’un développeur WooCommerce professionel pour mettre tout cela en place, contactez-moi.

Bonne mise à jour.

J'ai planté le serveur... ou comment récupérer un serveur Kimsufi après un plantage de kernel avec le mode rescue OVH photo

Récupérer un serveur Kimsufi après un plantage de kernel avec le mode rescue OVH

J’ai lamentablement fait planter le serveur en voulant mettre le kernel à jour…

Heureusement, il existe le mode rescue chez OVH qui permet d’installer un linux provisoire sur le serveur et d’initier une connexion SSH pour que l’on puisse réparer le système.

Si jamais cela vous arrive, voici la marche à suivre.

Passage en mode rescue depuis le manager OVH

lifesaver

1. Aller sur le manager OVH > Dedicated > Infrastructure > clic sur votre serveur > clic sur l’onglet Server Status.

Lire la suite

Serveur dédié : mise en place de l'IPv6 photo 4

Serveur dédié : mise en place de l’IPv6

IPv6 (Internet Protocol version 6) est un protocole réseau sans connexion de la couche 3 du modèle OSI.

Grâce à des adresses de 128 bits au lieu de 32 bits, IPv6 dispose d’un espace d’adressage bien plus important qu’IPv4.

Cette quantité d’adresses considérable permet une plus grande flexibilité dans l’attribution des adresses et une meilleure agrégation des routes dans la table de routage d’Internet.

La traduction d’adresse, qui a été rendue populaire par le manque d’adresses IPv4, n’est plus nécessaire.

ipv6

Fin 2013, on estime le déploiement d’IPv6 à 2 %, et ce en dépit d’appels pressants à accélérer la migration, l’épuisement des adresses IPv4 publiques disponibles étant imminent.

Histoire d’assurer la pérennité de la connexion de notre serveur Kimsufi, voici comment mettre en place l’IPv6. Cela prend à peu près 15 minutes.

Etape 1 : récupérer l’adresse IPv6

Méthode graphique : identifiez-vous dans le Manager OVH et allez dans Serveur Dédié > Récapitulatif. Vous devriez obtenir quelques informations sur la connexion de votre Kimsufi, comme ceci :

ipv6-ovh

Méthode “terminal” : un autre moyen de trouver l’IPv6 est de lancer le terminal et taper la commande ifconfig :

ifconfig

Notez bien l’adresse IPv6 du serveur, nous allons nous en servir dans la prochaine étape.

Lire la suite

PHP : résoudre l'erreur

OVH : activez PHP-FPM sur votre hébergement

OVH est en pleine implémentation du module PHP-FPM sur ses offres, (et ici dans leur guide), ce qui permettrait selon la team OVH “d’accélérer les temps de réponses de PHP et d’obtenir des performances jusque 7 fois plus rapides dans nos labos par rapport au moteur actuel”.

Activation de PHP-FPM

Pour activer ce mode sur votre offre, il suffit de créer un fichier .ovhconfig à la racine de l’arborescence FTP, dans le dossier parent du répertoire /www.

Si vous souhaitez activez PHP 7, voici ce que doit contenir votre .ovhconfig:

app.engine=php
app.engine.version=7.0
http.firewall=none
environment=production

Si vous souhaitez activez PHP 5.6, voici ce que doit contenir votre .ovhconfig:

app.engine=php
app.engine.version=5.6
http.firewall=none
environment=production

Lire la suite

DNS : résoudre l'erreur fatale "la liste des serveurs récupérée ne correspond pas à celle donnée" photo

DNS : résoudre l’erreur fatale “la liste des serveurs récupérée ne correspond pas à celle donnée”

Problème : ns.kimsufi.com ne semble pas être dans la liste des serveurs

Lors de l’appariement de votre nom de domaine au serveur et au cours d’un Zone-Check du domaine, vous pouvez tomber sur l’erreur suivante :

---- fatal ----
cohérence avec la liste des serveurs de noms donnée
f: La liste des serveurs récupérée ne correspond pas à celle donnée :

ns.kimsufi.com/2001:41D0:3:1C7::1

L’erreur étant fatale, il est nécessaire de la corriger pour que le nom de domaine pointe bien vers le bon serveur.

La solution : incrémenter le numéro de série du Start Of Authority (SOA)

La solution est très simple : il suffit d’incrémenter le numéro de série du Start Of Authority (SOA). A titre d’exemple :

; skyminds.net
$TTL    84600
@	IN	SOA	ksXXXXXX.kimsufi.com. root.skyminds.net. (
			2012040301   ; serial number : YYYYMMDDHH
			3600         ; refresh : 1h suffit
			1h           ; update retry
			4W           ; expiry
			84600        ; TTL )
Code language: PHP (php)

C’est la valeur 2012040301 (au format YYYYMMDDHH) qu’il suffit d’incrémenter. Ensuite, il ne vous reste plus qu’à relancer bind9 :

/etc/init.d/bind9 restart

Lire la suite

Migration de serveur : bonjour Kimsufi 750G photo

Migration de serveur : bonjour Kimsufi 750G

J’ai peu posté ces derniers jours et ce pour plusieurs raisons. Premièrement, il fait beau. Donc j’en profite, surtout qu’il fait aussi chaud qu’en mai-juin. Et deuxièmement, je viens de migrer le site sur un serveur plus puissant.

Migration entre deux serveurs

Il y a une grosse différence entre monter un serveur de A à Z, comme j’avais fait précédemment, et migrer données et programmes d’un serveur A à un serveur B.

L’important pour moi était de réutiliser au maximum mes configurations donc j’ai repris mes tutos un à un, tout en copiant les fichiers que j’avais précédemment créés ou édités sur le nouveau serveur.

Résultats ?

Et bien cela fonctionne très bien ! J’ai connu quelques mésaventures mais j’ai pris plein de notes donc il y a là de la matière pour quelques futurs articles. En gros le site a été indisponible pendant 1h samedi mais je pense que cela ne s’est pas trop vu.

Au niveau technique, on peut apprendre pas mal d’informations sur le processeur du serveur en lançant la commande :

less /proc/cpuinfo

L’ancien serveur était un Intel(R) Celeron(R) CPU 220 @ 1.20GHz et 2 Go de RAM.
Le nouveau serveur est un Intel(R) Core(TM)2 Quad CPU Q8300 @ 2.50GHz et 4 Go de RAM.

Lire la suite

Serveur dédié : sauvegarde automatique des fichiers avec Backup Manager sur le serveur de sauvegarde OVH photo 1

Serveur dédié : sauvegarde automatique des fichiers avec Backup Manager sur le serveur de sauvegarde OVH

Aujourd’hui, nous abordons la sauvegarde des fichiers essentiels du serveur.

Backup Manager permet d’effectuer des sauvegardes quotidiennes du système : il crée des archives dans plusieurs formats de compression (tar, gzip, bzip2, lzma, dar, zip) et peut les exporter vers un serveur FTP.

Dans notre cas, nous allons l’installer et le configurer pour envoyer tout ce qui est important sur notre serveur sur le serveur FTP externe de sauvegarde fourni gratuitement par OVH (100 Go).

Etape 1 : installation de Backup Manager

C’est classique :

apt-get install backup-managerCode language: JavaScript (javascript)

A la fin de l’installation, un assistant se lance et vous permet de configurer des options par défaut. Ou vous pouvez configurer à la main, comme indiqué dans l’étape suivante.

Lire la suite

Serveur dédié : mettre à jour le noyau Debian de la Kimsufi photo

Serveur dédié : mettre à jour le noyau Debian de la Kimsufi

linux kernel

Aujourd’hui, on met à jour le noyau linux de notre installation Debian sur notre Kimsufi.

Un noyau à jour, c’est toujours mieux pour bénéficier des derniers patchs/améliorations/correctifs de sécurité du noyau.

OVH compile ses propres noyaux, offrant différentes options. Nous choisirons le noyau avec GRS : grsecurity est un correctif de sécurité pour le noyau incluant PaX, un système de contrôle d’accès à base de rôles et différents moyen de renforcer la sécurité générale du noyau.

Téléchargement du dernier noyau linux chez OVH

Une fois loggés en SSH, on se place dans le répertoire /boot :

cd /boot

On regarde ensuite la liste des noyaux linux modifiés par OVH pour les Kimsufi : ftp://ftp.ovh.net/made-in-ovh/bzImage/.

On récupère 2 fichiers : le fichier bzImage et le fichier System.map associé. Pour mon serveur, je prends les versions -grs-ipv6-64 : certaines mesures de sécurité sont incluses dans le noyau made in OVH (-grs), avec support de l’ipv6 sur un système 64 bits.

Nous prenons donc la dernière version du noyau ici : ftp://ftp.ovh.net/made-in-ovh/bzImage/latest-experimental/:

wget ftp://ftp.ovh.net/made-in-ovh/bzImage/latest-experimental/System.map-4.1.7-xxxx-grs-ipv6-64
wget ftp://ftp.ovh.net/made-in-ovh/bzImage/latest-experimental/bzImage-4.1.7-xxxx-grs-ipv6-64
wget ftp://ftp.ovh.net/made-in-ovh/bzImage/latest-experimental/config-4.1.7-xxxx-grs-ipv6-64Code language: JavaScript (javascript)

Lire la suite

Serveur dédié : sécurisation de la couche TCP/IP photo

Serveur dédié : sécurisation de la couche TCP/IP

icon security firewall

Il est facile de sécuriser la couche TCP/IP du serveur juste en activant quelques directives.

Normalement, le réseau de l’hébergeur est suffisant stable pour que nous puissions désactiver certains fonctions de routage IPv4 et IPv6.

Nous allons donc désactiver les redirections ICMP, nous protéger des attaques SYN FLOOD, du spoofing, du smurfing, désactiver le routage à l’intérieur des paquets et finalement désactiver l’autoconf IPV6.

Ce tutoriel prend à peine 10 minutes.

Configuration du fichier /etc/sysctl.conf

Il existe pas mal d’options dans le fichier sysctl.conf liées à la sécurité. Commençons par éditer le fichier :

nano /etc/sysctl.conf

Lire la suite

Migration de serveur : Kimsufi 250G photo

Migration de serveur : Kimsufi 250G

Aujourd’hui, je vous donne les quelques news techniques du site.

Serveur Kimsufi 500G

Cela fait presque un an que SkyMinds.Net tourne sur un serveur dédié hébergé chez OVH. Le serveur était un Kimsufi avec 500 Go de disque dur.

Quelques jours seulement après le transfert du site, OVH annonce le Kimsufi avec 250 Go mais… à moitié prix ! Et on ne peut rendre un serveur Kimsufi pour un autre, il s’agit de deux achats séparés.

serveur dedie debian

Au niveau des performances, je dirai que mon Kimsufi 500G n’était pas terrible : il était constamment surchargé et j’avais l’impression de devoir relancer les services régulièrement pour assurer la disponibilité du service. Pas cool du tout.

Lire la suite