**Cette page a été importée automatiquement de notre ancien wiki mais n'a pas encore été révisée.**

# Serveur OVH

Travaux OVH : <http://travaux.ovh.net/>

Vue par datacenters/baies : <http://travaux.ovh.net/vms/index_rbx.html>

Latence réseau OVH : <http://gsw.smokeping.ovh.net/>

## Noyau Linux pour serveurs OVH

Pour installer un nouveau noyau compilé par OVH (par exemple un noyau sans l'option GRSEC),
il faut télécharger les fichiers *bzImage* et *System.map* sur ftp://ftp.ovh.net/made-in-ovh/bzImage/

Par exemple :

~~~
# cd /boot
# wget ftp://ftp.ovh.net/made-in-ovh/bzImage/3.10.18/bzImage-3.10.18-xxxx-grs-ipv6-64
# wget ftp://ftp.ovh.net/made-in-ovh/bzImage/3.10.18/System.map-3.10.18-xxxx-grs-ipv6-64
# wget ftp://ftp.ovh.net/made-in-ovh/bzImage/3.10.18/config-3.10.18-xxxx-grs-ipv6-64
~~~

Il faut ensuite modifier la configuration du boot loader (GRUB ou LILO), voir ci-dessous :

### Mettre un Boot Flag

/!\\ Il est important de mettre le « boot flag » avec `fdisk` ou équivalent sur la partition qui contient /boot /!\\

### Pour GRUB

Pour GRUB sous Squeeze :

~~~
# update-grub2
Generating grub.cfg ...
Warning: update-grub_lib is deprecated, use grub-mkconfig_lib instead
Found linux image: /boot/bzImage-2.6.38.2-xxxx-std-ipv6-64
  No volume groups found
done
~~~

Note : attention, il va prendre par défaut le dernier noyau téléchargé, cf le fichier de configuration /etc/grub.d/06_OVHkernel

### Pour LILO

Modifier le fichier _lilo.conf_, par exemple ainsi :

~~~
lba32
boot=/dev/md1
raid-extra-boot=mbr-only
prompt
timeout=5

# Enable large memory mode.
large-memory

image=/boot/bzImage-2.6.38.2-xxxx-grs-ipv6-64
        label="Linux"
        root=/dev/md2
        read-only
~~~

Puis entrez la commande suivante :

~~~
# lilo
Added Linux *
The Master boot record of  /dev/sda  has been updated.
Warning: /dev/sdb is not on the first disk
The Master boot record of  /dev/sdb  has been updated.
One warning was issued.
~~~


Voilà, une fois le boot loader modifié, vous pouvez redémarrer le serveur.

## Vérifications du serveur

Outre un reboot du serveur en mode _rescue_, voici certaines vérifications possibles.

### Réseau

~~~
# ifconfig | grep error
          RX packets:48653845 errors:0 dropped:0 overruns:0 frame:0
          TX packets:68256134 errors:0 dropped:0 overruns:0 carrier:0
          RX packets:13277345 errors:0 dropped:0 overruns:0 frame:0
          TX packets:13277345 errors:0 dropped:0 overruns:0 carrier:0
~~~

### Disques / RAID

~~~
# tw_cli  info C0

Unit  UnitType  Status         %Cmpl  Stripe  Size(GB)  Cache  AVerify  IgnECC
------------------------------------------------------------------------------
u0    RAID-1    OK             -      -       698.637   ON     -        -

Port   Status           Unit   Size        Blocks        Serial
---------------------------------------------------------------
p0     OK               u0     698.63 GB   1465149168    5QD50X85
p1     OK               u0     698.63 GB   1465149168    5QD4N9L4

# smartctl -a -d 3ware,0 /dev/twe0 | egrep 'Serial|Error'
Serial Number:    5QD50X85
Error logging capability:        (0x01) Error logging supported.
  1 Raw_Read_Error_Rate     0x000f   113   100   006    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x000f   084   060   030    Pre-fail  Always       -       260318814
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       0
200 Multi_Zone_Error_Rate   0x0000   100   253   000    Old_age   Offline      -       0
SMART Error Log Version: 1
No Errors Logged
# smartctl -a -d 3ware,1 /dev/twe0 | egrep 'Serial|Error'
Serial Number:    5QD4N9L4
Error logging capability:        (0x01) Error logging supported.
  1 Raw_Read_Error_Rate     0x000f   104   100   006    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x000f   078   060   030    Pre-fail  Always       -       71534169
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       0
200 Multi_Zone_Error_Rate   0x0000   100   253   000    Old_age   Offline      -       0
SMART Error Log Version: 1
No Errors Logged
~~~

Il ne faut plus utiliser `megasasctl` pour interagir avec le contrôleur RAID, car ce logiciel n'est plus maintenu et peu sorti des faux négatifs.

### CPU/RAM

~~~
# grep -ri Oops /var/log/
# grep -ri threshold /var/log/
# grep -ri Segfault /var/log/
~~~

## IPMI / iKVM

Certaines machines récentes nécessite une JRE 8 + icedtea-netx (1.6.2 à backporter manuellement Stretch) pour accéder à l'iKVM, car celui-ci ne fonctionne qu'en TLS 1.2.  
[Voir Screenshot.](tls12.png)


## DNS

OVH ne propose pas deux serveurs DNS fiables. Nous préconisons l'utilisation du `/etc/resolv.conf` suivant puis l'installation de [Bind](HowtoBind) :

~~~
nameserver 127.0.0.1
nameserver 213.186.33.99
~~~


## IP FailOver

OVH propose l'utilisation d'adresses IP supplémentaires sur un serveur et potentiellement
"transportables" sur un autre serveur, d'où leur nom _IP FailOver_.

Pour en ajouter une, il faut remplir un petit formulaire dans le manager, puis on
ajoute une configuration de ce type sous Debian (attention, le masque est bien un /32 !!) :

~~~
auto eth0:0
iface eth0:0 inet static
        address 192.0.43.2/32
~~~

On peut déléguer l'infogérance des IPFO en se rendant sur la page « Gestion des contacts » (accessible via le menu du compte en haut à droite du manager OVH), et en ajoutant un contact technique à la ligne concernant l'IP failover.

Pour utiliser les IPs failover dans des VM, sur la page `Gérer les IPs` du manager OVH, dans les actions (menu `...`), on pourra ajouter une MAC virtuelle, qu'il faudra ensuite reporter dans la configuration libvirt de l'interface réseau de la VM.


## Bridge

Depuis au moins Debian 11, il faut apparemment bien préciser l'option `bridge_hw` :

~~~
auto br0
iface br0 inet manual
        bridge_ports eth0
        bridge_hw ab:cd:01:23:45:67
~~~

cf [HowtoDebian/Reseau#bridge]()


## Utilisateur Unix

OVH crée un utilisateur `debian` à l'installation, nous conseillons de le supprimer.

## /root/.ssh/authorized_keys

OVH ajouter une ligne dans `/root/.ssh/authorized_keys` du type `Please login as the user "debian" rather than the user "root"`.
Comme nous savons configurer SSH ;) nous supprimons cette ligne.

## cloud-init

Nous conseillons de supprimer les paquets `cloud-init cloud-guest-utils cloud-image-utils cloud-utils` et les fichiers :

* /etc/apt/apt.conf.d/90cloud-init-pipelining
* /etc/sudoers.d/debian-cloud-init
* /etc/sudoers.d/90-cloud-init-users
* /etc/profile.d/Z99-cloud-locale-test.sh
* /etc/network/interfaces.d/50-cloud-init.cfg
* /etc/network/interfaces.d/50-cloud-init


## vRack

Le vRack (1.5) permet de monter un réseau privé ou d'utiliser une plage d'adresses IP publiques. On peut utiliser jusqu'à 4000 vlans.
Le trafic passe forcément par eth1 ou eth3 (selon les serveurs).

Exemple de config avec eth1.100 pour du DRBD, eth1.200 mappé sur br_lan pour un bridge LAN, et eth1 mappé sur br_wan pour un bridge WAN.

/!\\ Si l'on veut que la machine physique dispose de une des adresses IP publique du VLAN, il faut ajouter une route spécial (type multi-WAN).

```
# echo 200 vrack >> /etc/iproute2/rt_tables
```

/etc/network/interfaces
```
auto eth1
iface eth1 inet manual

# LAN eth1.100 vRack VLAN 100 for DRBD
auto eth1.100
iface eth1.100 inet static
    address 192.168.0.10/24

# LAN br_lan vRack VLAN 200 for VMs LAN
auto eth1.200
iface eth1.200 inet manual

auto br_lan
iface br_lan inet static
    bridge_ports eth1.200
    address 10.0.0.10/24

# WAN br_wan vRack no VLAN
auto br_wan
iface br_wan inet static
    bridge_ports eth1
    address IP_VRACK/NETMASK_VRACK
    ## Need to work: echo 200 vrack >> /etc/iproute2/rt_tables
    post-up ip route add IP_VRACK/NETMASK_VRACK dev br_wan table vrack
    post-up ip route add default via IP_GW_VRACK dev br_wan table vrack
    post-up ip rule add from IP_VRACK/NETMASK_VRACK table vrack
    post-up ip rule add to IP_VRACK/NETMASK_VRACK table vrack

```

## réseau sans systemd

Voir <https://wiki.evolix.org/HowtoDebian/Reseau#migrer-de-networkd-%C3%A0-ifup>

## IPv6

L'IPv6 d'un serveur dédié OVH est notée dans le manager sous la forme d'un réseau /64
...néanmoins la gateway doit être calculée en dehors de ce réseau... du coup
soit vous mettez simplement un /56, soit vous devez mettre des routes un peu tordues.

Voici la configuration conseillée :

~~~
iface eth0 inet6 static
        address 2001:1234:5:6789::1/64
        # Deprecated netmask 56
        # Deprecated up ip route add 2000::0/3 via 2001:1234:5:67ff:ff:ff:ff:ff
~~~

Les documentations OVH semble être dépréciés. Les routes sont annoncés par des RA. Il suffit donc de positionner une adresse IPv6 et de ne pas se préoccuper de la gateway.

Voir <http://guides.ovh.com/Ipv4Ipv6> et des commentaires comme <http://forum.ovh.co.uk/showpost.php?p=44957&postcount=10> et <http://forum.ovh.co.uk/showpost.php?p=44965&postcount=13>

Si besoin de désactiver IPv6, voir <https://wiki.evolix.org/HowtoDebian/Reseau#d%C3%A9sactiver-ipv6>

## Firewall Cisco ASA

Il est possible d'associer à un serveur dédié un firewall Cisco ASA, en mode transparent. Attention le mode transparent implique qu'il ne sera pas possible de monter des VPNs. OVH ne supporte pas encore le mode routé.
La configuration du firewall est disponible en HTTPs (client java) ou en CLI via ssh.

## Cloud Disk Array

[Cloud Disk Array (CDA)](https://www.ovh.com/fr/cloud-disk-array/) est une offre de stockage qui se repose sur Ceph.

Depuis l’interface OVH, on peut accéder à l’interface d’administration depuis : `Bare Metal Cloud` puis sur le côté gauche dans `Plateformes et services`. Le _cluster_ Ceph devrait être listé.

Une fois sur l’interface du _cluster_ Ceph, on a 4 onglets :

* « Sommaire » - donne les informations générales sur le cluster ;
* « Utilisateurs » - gérer les comptes utilisateurs et leurs permissions pour chaque pool ;
* « Contrôle d’accès IP » - gérer les plages d’IP autorisées ;
* « Pool » - créer et supprimer les pools.
    * Au moment où nous avons créé des _pools_, le nombre de réplication des objets était forcé à 3.

Note : s’il y a un pare-feu sur le serveur OVH qui sera un client du _cluster_ Ceph, il faut faire les autorisations réseaux suivantes sur le client :

* TCP sortie vers les IP des moniteurs sur le port 6789,
    * ces IP sont accessibles depuis le sommaire ;
* TCP sortie vers n’importe quelle IP (ou le réseau 10.0.0.0/8) sur les ports 6800:7300,
    * Les IP des OSD ne sont pas renseignées depuis l’interface du _cluster_ Ceph, donc il est nécessaire de faire une autorisation en sortie _très_ vaste.

Note : le _cluster_ Ceph sera au moins en version 14. Il est important que Ceph ⩾ 12 soit installé sur le client pour éviter les problèmes d’incompatibilité.

## Nouvel antispam OVH

La détection de spams se fait en temps réel sur les emails envoyés.

Lorsqu'une adresse IP est identifiée comme émettrice de spam, le port 25 est bloqué via VAC. On peut notamment vérifier le blocage sur l'interface d'admin beta : <https://www.ovh.com/manager/dedicated/login.html>

Le déblocage se fait via l'interface API : <https://api.ovh.com/console/#/ip>

Se connecter avec des identifiants OVH. Par la suite , il faut sélectionner "/ip" puis "/ip/{ip}/spam/{ipSpamming}/unblock" (icône POST en début de ligne), entrer l'IP de son serveur dans les zones "ip" et "ipSpamming" puis cliquer sur "Execute"

Vous pouvez utiliser le  lien <https://api.ovh.com/console/#/ip>  pour vérifier si l'IP a été bien débloqué ou pas.

Si l'IP est de nouveau détectée comme "spammeuse", elle sera bloquée de nouveau, le déblocage sera alors possible après 24h.
Si l'IP est détectée une nouvelle fois, elle sera bloquée pour 30 jours.

Note : via le nouveau manager, on peut le faire directement via <https://www.ovh.com/manager/dedicated/index.html#/configuration/ip>

## Support OVH

État des serveurs OVH dans leurs différents datacenters : <http://travaux.ovh.net/vms/> (les détails de placement de chaque serveur sont visibles dans le Manager OVH)

Le numéro actuel 1007 (+33 9 72 10 10 07) est efficace comparé aux années précédentes. Pour passer le menu et aller directement au support serveur : 3 1 2 pour un incident.
Pour des machines chez OVH Canada, il faut passer par leur support Canadien : +1 855-684-5463 (Fonctionne en français et anglais)

Déprécié : L'astuce est de joindre le 09.74.53.13.23 (non surtaxé) où un opérateur a simplement un accès à l'outil de tickets mais peut relancer les "vrais" techniciens par messagerie instantannée. En cas d'urgence, l'idéal est donc d'ouvrir un ticket, de relancer immédiatemment au 09.74.53.13.23 puis de prier.

Pour des renseignements avant de passer commande (stock, etc.) : sales@ovh.net

