Affichage des articles dont le libellé est linux. Afficher tous les articles
Affichage des articles dont le libellé est linux. Afficher tous les articles

jeudi 9 octobre 2014

Comparaison de la gestion des FS avec Puppet et Ansible

Suite de mes aventures avec Ansible : aujourd'hui c'est du système Linux.

Les données du problème : je veux pouvoir gérer le LVM Linux et retailler mes FS à la demande.

La recette sous Puppet

Sous Puppet, en utilisant un fichier yaml/Hiera, l'écriture de tout ceci se ferait avec quelque chose de ce genre :

---
classes: ['lvm']

lvm::volume_groups:
  rootvg:
    physical_volumes:
      - /dev/sda2
    logical_volumes:
      tmp:
        size: 2G
        mountpath: /tmp
  datavg:
    physical_volumes:
      - /dev/sdb
    logical_volumes:
      test:
        size: 128
        mountpath: /test

Ne pas oublier non plus d'inclure le code suivant dans le fichier site.pp :

hiera_include('classes','')

Bien penser également à installer le module lvm, sinon ça ne marchera pas (puppetlabs-lvm).

Bon, sous Ansible, toutes ces belles choses n'existent pas (encore) en l'état mais sous forme de brique à assembler. On va voir comment recréer un mécanisme à peu près similaire.

La recette sous Ansible

Je me place dans le cadre d'un playbook Ansible avec un fichier system.yml se trouvant dans un répertoire de travail ~/ansible avec le contenu suivant :

---
# Playbook de gestion du système

- name: Propriétés communes système
  hosts: all
  remote_user: root

  roles:
    - system

Autre fichier présent : group_vars/all avec le contenu suivant :

---
# Variable applicable à tous

vgs:
  rootvg: "/dev/sda2"
  datavg: "/dev/sdb"

lvs:
  test:
    vg: rootvg
    mountpoint: /test
    size: 256

Ce fichier sera a spécialiser par groupe de machine mais est l'équivalent de notre fichier yaml/Hiera. Reste maintenant à écrire notre liste de tâche qui nous permettra de gérer ces FS (qu'on mettra dans le fichier roles/system/tasks/main.yml) :

---
- name: VG/PV Configuration
  lvg: vg={{ item.key }} pvs={{ item.value }} state=present
  with_dict: vgs

- name: LV creation
  lvol: vg={{ item.value.vg }} lv={{item.key}} size={{item.value.size}}
  register: task
  with_dict: lvs

- name: LV format
  filesystem: fstype=ext4 dev=/dev/mapper/{{item.value.vg}}-{{item.key}}
  with_dict: lvs

- name: Mount
  mount: name={{item.value.mountpoint}} src=/dev/mapper/{{item.value.vg}}-{{item.key}} dump=1 passno=2 fstype=ext4 state=mounted
  when: item.value.has_key('mountpoint')
  with_dict: lvs

- name: FS resize
  command: resize2fs /dev/mapper/{{item.item.value.vg}}-{{item.item.key}}
  with_items: task.results
  when: item.changed == True

NB : cette recette ne gère que des fs de type ext4. Si vous voulez gérer du xfs/btrfs/fegafatfs, il faudra changer la commande resize2fs par autre chose.

Le fonctionnement de la recette est assez simple : on enchaine les opérations (création du PV/VG, création du LV, formatage et montage) et on exécute la commande resize2fs qu'en cas de changement sur le LV (cf FS resize, ligne when: item.changed == True).

Reste maintenant à lancer notre playbook avec la commande ansible-playbook -i ./hosts ./system.yml. Vous devriez obtenir le résultat suivant :

PLAY [Propriétés communes système] ******************************

GATHERING FACTS *************************************************
ok: [machine1]

TASK: [common | VG/PV Configuration] ****************************
ok: [machine1] => (item={'key': 'datavg', 'value': '/dev/sdb'})
ok: [machine1] => (item={'key': 'rootvg', 'value': '/dev/sda2'})

TASK: [common | LV creation] ************************************
changed: [machine1] => (item={'key': 'test', 'value': ...})

TASK: [common | LV format] **************************************
changed: [machine1] => (item={'key': 'test', 'value': ...})

TASK: [common | Mount] ******************************************
changed: [machine1] => (item={'key': 'test', 'value': ...})

TASK: [common | FS resize] **************************************
changed: [machine1] => (item={u'msg': u'', 'item': ...})

PLAY RECAP ******************************************************
machine1        : ok=6    changed=4    unreachable=0    failed=0   

Changeons la taille de notre FS pour autre chose et relançons ansible pour vérifier la bonne prise en compte de tout ceci :

PLAY [Propriétés communes système] ******************************

GATHERING FACTS *************************************************
ok: [machine1]

[...]

TASK: [common | LV creation] ************************************
changed: [machine1] => (item={'key': 'test', 'value': ...})

[...]

TASK: [common | FS resize] **************************************
changed: [machine1] => (item={u'msg': u'', 'item': ...})

PLAY RECAP ******************************************************
machine1        : ok=6    changed=2    unreachable=0    failed=0   

Tout c'est bien passé. Il ne me reste plus qu'à vous souhaiter une bonne gestion de vos LV !

mardi 27 août 2013

Back to basic : maîtriser le multitâche dans une session en mode texte


Bon, je sais, je vais passer pour un vieux schnoque mais voilà : on n'a pas toujours la possibilité d'avoir du multitâche (surtout en SSH sur un serveur dans une DMZ ou connecté en directe sur une console au cul d'un serveur) mais c'est bien pratique de pouvoir passer d'une tâche à une autre. Je ne prétends pas tout connaître mais, je vais vous livrer quelques petits trucs que j'utilise (ou que j'ai eu utilisé) dans le domaine.

Les terminaux virtuels

Je pense qu'il s'agit du mode le plus simple et qu'on privilégiera dans le cas où vous êtes sur une machine Linux sans connexion X. Ici, rien de bien compliqué, vous pouvez passer d'un terminal à un autre en utilisant la combinaison de touche Alt+Fn (il faut rajouter Ctrl dans le cas où vous avez une connexion sous X).

Par ce mécanisme, vous pouvez tout à fait ouvrir un premier terminal puis éditer un fichier à l'aide de vi (ou emacs) et, sur un autre terminal, parcourir une arborescence (par exemple). Dans ma jeunesse (je vous l'avais dit que je passerai pour un vieux teuteu), j'avais l'habitude de lancer l'excellent mpg123 en arrière plan pour écouter mes mp3s sans risque de voir ma session X me planter ma lecture.

Petit problème, si vous travaillé en SSH, ça ne fonctionne plus et en plus de ça, il n'est pas dit que votre vieille version d'Unix propriétaire le gère (en même temps, y'a t'il des fous prêt à travailler avec un M4000 ou autre station à base de Power7 posé sur son bureau ...).

Gérer des tâches en ligne de commande avec votre shell

Voilà, vous êtes maintenant connecté en SSH sur votre serveur, vous êtes en train d'éditer votre fichier et vous avez besoin de jeter un coup d'oeil rapide sur le contenu d'un autre fichier. Bien sûr, il est toujours possible de le faire avec vi (en lançant un shell avec !bash) mais c'est loin d'être pratique. Pourtant il y a beaucoup plus simple : l'utilisation des tâches en shell.

C'est ici qu'entre en scène la combinaison de touche Ctrl+Z. Quand vous faîtes cette combinaison de touche, votre programme en cours d'exécution se retrouve mis en pause et vous vous retrouvez directement sur votre shell qui était resté tranquillement en arrière plan. Ci-dessous voici ce que nous obtenons en faisant cette combinaison de touche dans vi :

[yperre]/home/yannig> vi toto

[1]+  Stopped                 vi toto
[yperre]/home/yannig>

Une fois que vous avez réalisé l'opération que vous vouliez, vous voulez revenir à votre tâche précédente. Tapez simplement la commande fg (foreground) et vous voici de retour dans votre éditeur comme si rien ne s'était passé.

Bon mais voilà, maintenant, vous voulez éditer un second fichier en parallèle. Du coup, vous passer votre première instance vi en arrière plan et vous éditer le fichier titi. Et tout d'un coup, vous voulez revenir à votre première tâche d'édition. Problème, avec fg, vous revenez à la dernière commande que vous avez lancé. Dans ce cas, il suffit de taper %1, %2 etc. en fonction du numéro de la tâche que vous voulez rebasculer en premier plan.

Maintenant, vous êtes en train d'expérimenter un nouveau produit (tomcat, elasticsearch, logstash etc.) mais comme souvent, le shell est mal foutu et se bloque à l'exécution. Problème, vous avez toujours envie de consulter un fichier et vous êtes un peu bloqué. En effet, lorsque vous faîtes Ctrl-Z, votre process est en pause et ne traite plus les requêtes entrante. C'est là qu'entre en scène l'ami bg (background).

Comme vous êtes joyeux et que vous avez lancé plusieurs process en arrière plan et maintenant vous voulez en tuer un ou deux. Alors vous avez toujours la solution du bon vieux kill . Mais sinon, vous pouvez également utiliser kill %1.

Pour conclure

Loin de moi l'idée d'avoir présenter toutes les possibilités dans le domaine. Vous pourrez également vous tourner vers l'utilitaire screen qui a également l'avantage de pouvoir faire persister votre session même si votre connexion SSH se plante lamentablement. Je ne saurais que trop vous conseiller de l'utilisier dans le cas d'un long traitement critique (migration/import de base, recopie de données, mise à jour etc).

vendredi 26 avril 2013

Sauvegarde incrémentale avec rsync

rsync est un programme Unix utilisé pour maintenir une copie d'une arborescence synchrone avec une autre en ne recopiant que les différences. Grâce à lui on peut donc réduire le nombre de fichier à recopier dans le cas d'arborescence qui change peu (c'est souvent utilisé dans le cadre de mirroir de site par exemple).

Pour ma part, je l'utilise souvent avec l'option -av :
rsync -av /mon/premier/repertoire /mon/repertoire/de/sauvegarde
On peut également rajouter l'option --delete afin que rsync procède également à la suppression des fichiers qui ont été supprimé d'un côté.

Seulement voilà, quand on veut faire une sauvegarde incrémentale pour conserver un historique de l'état d'une arborescence (ou les différentes versions d'un fichier), on se rend vite compte que c'est pas vraiment l'idéal. C'est là où on peut faire appel à la commande cp avec l'option -al (a = archive = préservation des liens symboliques + préservation des droits + copie récursive et l = pas de recopie mais utilisation d'un lien hard).

En faisant ainsi, on va recréer notre arborescence mais sans pour autant recopier les données (les fichiers seront identiques puisque pointant sur les mêmes inoeuds). Pour mieux comprendre, faisons quelques tests ...

Quelques tests sur les inoeuds ...

Créons un fichier quelconque :
$ cat > monfichier
Ceci est un fichier.
Recopions ce dernier avec la commande cp -al :
$ cp -al monfichier macopiedefichier
Regardons maintenant la valeur de l'inoeud :
$ ls -l1i monfichier macopiedefichier
457175 -rw-r--r-- 2 yannig yannig 21 Apr 26 15:52 macopiedefichier
457175 -rw-r--r-- 2 yannig yannig 21 Apr 26 15:52 monfichier
On se rend compte que ces deux fichiers sont en tout point identique. Maintenant, nous allons utiliser rsync pour faire cette recopie :
$ rsync -av monfichier uneautrecopie
Regardons à nouveau les inoeuds de nos fichiers :
$ ls -l1i monfichier macopiedefichier uneautrecopie
457175 -rw-r--r-- 2 yannig yannig 21 Apr 26 15:52 macopiedefichier
457175 -rw-r--r-- 2 yannig yannig 21 Apr 26 15:52 monfichier
457176 -rw-r--r-- 1 yannig yannig 21 Apr 26 15:52 uneautrecopie
Le nouveau fichier a bien un inoeud différent. Essayons maintenant de voir dans le cas d'un fichier déjà existant :
$ touch unautrefichier
Son numéro d'inoeud :
$ ls -i unautrefichier
457177 unautrefichier
Lançons maintenant notre synchronisation :
$ rsync -av macopiedefichier unautrefichier
Et jetons un coup d'oeil sur le résultat :
$ ls -l1i monfichier macopiedefichier uneautrecopie unautrefichier
457175 -rw-r--r-- 2 root root 21 Apr 26 15:52 macopiedefichier
457175 -rw-r--r-- 2 root root 21 Apr 26 15:52 monfichier
457178 -rw-r--r-- 1 root root 21 Apr 26 15:52 unautrefichier
457176 -rw-r--r-- 1 root root 21 Apr 26 15:52 uneautrecopie
On se rend bien compte que notre fichier de destination a bien été supprimé avant d'être recréé (457177 != 457178). Ce comportement est normal puisque c'est rsync qui fonctionne de cette manière.

Au final, ceci va donc me permettre de vous proposer un petit mécanisme de sauvegarde incrémentale.

A noter que si vous avez besoin de plus de détails pour comprendre les amis les inoeuds, je vous invite à vous tourner vers Wikipedia ou vers un bon bouquin sur Unix.

Passons maintenant à notre sauvegarde ...

Imaginons une arborescence /var/svn. Vous voulez sauvegarder tout ceci sur un serveur externe via rsync. Pour se faire, lançons tout d'abord une première sauvegarde depuis le serveur SVN :
rsync -av /var/svn/. backup:/var/backup/svn/.
Attention : Notre recopie à distance se fait à l'aide du protocole ssh. Il faudra donc avoir échangé les clés SSH entre le serveur SVN et celui de backup. Le répertoire /var/backup/svn devra également déjà exister sur la machine de backup.

Passons maintenant sur la machine de backup. Avant de lancer le rsync, nous allons d'abord recopier notre arborescence dans un nouveau répertoire en date du jour :
$ cp -al /var/backup/svn /var/backup/svn-date-du-jour
Ceci fait, nous pouvons maintenant lancer la commande de rsync :
$ rsync serveur-svn:/var/svn/. /var/backup/svn-date-du-jour/.
Reste maintenant plus qu'à faire un petit script de cette merveille combiné avec une crontab pour lancer ça automatiquement et vous voilà en face d'un superbe outil de sauvegarde !

A noter qu'il est également possible de se passer de la commande cp -al à l'aide de l'option --link-dest. En effet, cette dernière permet de faire un lien symbolique dans l'ancien répertoire dans le cas où les attributs externes du fichier n'aurait pas changé (permissions et date de modification). Dans ce cas, la commande à passer serait la suivante :
$ rsync --link-dest /var/backup/svn/. serveur-svn:/var/svn/. /var/backup/svn-date-du-jour/.

mercredi 27 mars 2013

Mise en place d'un bridge sous Debian/Ubuntu

Dans ma quête perpétuelle de la mise en place de truc qui fonctionne à moitié, j'ai eu la chance de me frotter aux bridges ethernets et aux interfaces ethernets virtuelles de l'ami Linux.

Mais qu'est ce qu'un bridge ethernet allez-vous me dire et pourquoi vouloir en mettre un en place ?

Un bridge ethernet est l'équivalent d'un switch virtuel au niveau système. L'idée est d'utiliser une interface réelle (mettons eth0) pour faire transiter du trafic des interfaces virtuelles (généralement tap0, tap1 etc.).

Pour ce qui est de l'utilité, vous en avez plusieurs avec notamment les deux exemples suivants :
  • Exposer une machine virtuelle sur un réseau réelle ;
  • Mettre en place un bridge ethernet pour openvpn.
Dans mon cas, je fais ça pour openvpn mais on peut également l'utiliser pour kvm par exemple.

Mise en place d'un bridge

Avant toute chose, il va nous falloir installer deux packages qui vous serons utiles pour gérer les bridges et les interfaces virtuelles (et puis, que serait un article sur Debian sans l'utilisation d'apt-get) :

apt-get install uml-utilities bridge-utils

Ici, rien de bien extraordinaire, nous allons d'abord déclarer un bridge (br0) dans le fichier /etc/network/interfaces, y ajouter notre interface ethernet (eth0) et enfin rattacher l'adresse dhcp au bridge. Ci-dessous, vous trouverez un exemple de fichier avant modification :

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet dhcp

Après modification, le fichier devrait ressembler à ça :

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet manual

auto br0
iface br0 inet dhcp
        bridge_ports eth0
        bridge_fd 9
        bridge_hello 2
        bridge_maxage 12
        bridge_stp off

Faîtes ensuite un restart networking pour prise en compte. La commande ifconfig devrait vous renvoyer ce qui suit :

# ifconfig
br0       Link encap:Ethernet  HWaddr 7e:68:47:11:36:c9  
          inet adr:192.168.0.34  Bcast:192.168.0.255  Masque:255.255.255.0
          adr inet6: fe80::7c68:47ff:fe11:36c9/64 Scope:Lien
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          Packets reçus:3193 erreurs:0 :0 overruns:0 frame:0
          TX packets:1289 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 lg file transmission:0 
          Octets reçus:273039 (273.0 KB) Octets transmis:331151 (331.1 KB)

lo        Link encap:Boucle locale  
          inet adr:127.0.0.1  Masque:255.0.0.0
          adr inet6: ::1/128 Scope:Hôte
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          Packets reçus:312 erreurs:0 :0 overruns:0 frame:0
          TX packets:312 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 lg file transmission:0 
          Octets reçus:32926 (32.9 KB) Octets transmis:32926 (32.9 KB)

eth0      Link encap:Ethernet  HWaddr c8:60:00:e2:c9:2b  
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          Packets reçus:4925 erreurs:0 :0 overruns:0 frame:0
          TX packets:1289 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 lg file transmission:1000 
          Octets reçus:679553 (679.5 KB) Octets transmis:331151 (331.1 KB)

On voit ici que c'est le bridge qui a une adresse IP. Ceci est important pour permettre le fonctionnement correcte de notre machine. Dans le cas contraire, on pourrait avoir des comportements bizarre de notre ami le serveur. Il faut bien voir que notre interface ethernet est simplement considéré comme un connecteur vers le monde réel.

Pour les plus curieux, il est possible de consulter l'état de notre bridge avec la commande brctl :

# brctl show br0
bridge name     bridge id               STP enabled     interfaces
br0             8000.7e68471136c9       no              eth0

Passons maintenant à la déclaration d'une interface virtuelle.

Déclaration d'une interface virtuelle et rattachement au bridge

Maintenant que notre bridge est fonctionnel, nous allons rattacher une interface virtuelle (tap0). Pour se faire, rien de plus simple, modifions de nouveau notre fichier /etc/network/interfaces de la manière suivante :

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet manual

auto tap0
iface tap0 inet manual
        pre-up tunctl -t tap0
        up ifconfig tap0 up
        down ifconfig tap0 down

auto br0
iface br0 inet dhcp
        bridge_ports eth0 tap0
        bridge_fd 9
        bridge_hello 2
        bridge_maxage 12
        bridge_stp off

Les lignes concernant tap0 contiennent l'utilisation de la commande tunctl qui va déclarer l'interface. Une fois déclarée, cette interface sera rattachée automatiquement au bridge à l'aide de la ligne bridge_ports.

Pour s'en convaincre, une fois que le réseau a été redémarré (restart networking), il suffit de relancer la commande brctl show br0. Ce dernier devrait renvoyer le résultat suivant :


# brctl show br0
bridge name     bridge id               STP enabled     interfaces
br0             8000.1c6f65217bc0       no              eth0
                                                        tap0

jeudi 5 juillet 2012

Création d'un point d'automontage pour backuppc

Suite à la mise en place d'un outil de sauvegarde (backuppc) pour un de mes clients, j'ai dû mettre en place un automonteur en direction d'un NAS. Comme j'ai un peu tâtonné, je me suis dit que ça ferait un petit article intéressant sur cette drôle de bête :)


Par la suite, je m'appuierai sur une Debian Squeeze mais rien n'empêche de transposer ces instructions sur une *ubuntu.


Vous pourriez vous poser la question du pourquoi de ce point d'automontage. Tout vient du fait que je n'avais pas de volumétrie suffisante pour mes sauvegardes sur la machine Linux. Comme je disposais d'un NAS, j'ai voulu stocker les fichiers de sauvegarde de backuppc dessus. Ainsi, pas de soucis de volumétrie et en cas de perte de la machine Linux, je n'ai qu'à recréer le point de montage du NAS sur un nouveau serveur et le tour est joué !


NB : je ne saurais trop vous conseiller de disposer d'un lien gigabit entre votre serveur Linux et votre NAS !


Deuxième question : pourquoi passer par un automonteur alors qu'il serait plus simple de modifier le fichier /etc/fstab ? Pour deux raisons :

  • Éviter d'introduire une dépendance trop forte entre la machine Linux et le NAS ;
  • Mais également pour fiabiliser mon infrastructure en cas de perte du NAS.

En effet, si jamais le NAS est indisponible au moment du démarrage du serveur Linux (ou plus tard suite à une rupture réseau), le fstab ne remontera pas automatiquement mon FS. Dans le cas de l'automonteur, ce montage se fait à la demande évitant les opérations manuelles.

Après ces quelques petites explications, passons maintenant à la mise en place de ce point d'auto-montage. Premier point, il faut installer l'automonteur avec la commande apt-get install autofs (si ça n'est pas déjà le cas).


De là, nous allons modifier le fichier /etc/auto.master afin d'y ajouter (à la fin du fichier) la ligne suivante :


[...]
/- /etc/auto.backuppc


Cette ligne sert à dire à l'automonteur que nous allons déclarer des points d'automontages supplémentaires dans le fichier /etc/auto.backuppc. C'est ce que nous allons faire en renseignant ce fichier avec la ligne suivante  :


/var/lib/backuppc -rw 192.168.xx.xx:/backuppc


Tout est en place mais avant de redémarrer l'automonteur, nous allons arrêter backuppc et renommer l'ancien répertoire :


/etc/init.d/backuppc stop
mv /var/lib/backuppc /var/lib/backuppc.orig


De là, redémarrons l'automonteur et vérifions que ce dernier a bien pris en compte la modification :


/etc/init.d/autofs restart
root@backuppc:/etc/backuppc# cd /var/lib/backuppc
root@backuppc:/var/lib/backuppc# df -k .
Sys. de fichiers      1K-blocs   Utilisé    Dispo. Uti% Monté sur
192.168.xx.xx:/backuppc
                     2879673344 1363423488 1516249856  48% /var/lib/backuppc

De là, recopions les données de l'ancien répertoire de backuppc :

rsync -av /var/lib/backuppc.orig/. /var/lib/backuppc/.

Enfin, nous pouvons démarrer backuppc :

/etc/init.d/backuppc start

Et voilà ! Notre automonteur pour backuppc est en place ! Nous allons pouvoir utiliser la volumétrie du NAS pour faire nos sauvegardes !


jeudi 20 mai 2010

Connexion via ipmi sur un serveur

Je suis plutôt habitué au console Solaris mais il se trouve que récemment, j'ai eu l'occasion de bosser sur une console ipmi. Le principe est le même, à savoir une console texte accessible via le réseau.

Comment est-ce qu'on arrive à s'intéresser à ce genre de problème allez vous me demander ? Et bien simplement, j'ai eu besoin de modifier les paramètres du BIOS sur une machine d'un client qui se trouve chez un hébergeur. Et il est vrai que sans accès physique à la machine, on se trouve bien bête :).

Assez parlé, commençons l'activation de l'ipmi sur notre serveur. Il nous faut tout d'abord installer ipmitool :
# apt-get install ipmitool
Nous allons maintenant charger le module kernel ipmi :
# modprobe ipmi_si
# modprobe ipmi_devintf
# lsmod | grep ipmi
ipmi_devintf 13200 0
ipmi_si 43628 0
ipmi_msghandler 38520 2 ipmi_devintf,ipmi_si
Tout semble bon. Ajoutons maintenant le module au redémarrage :
# echo "ipmi_devintf" >> /etc/modules
# echo "ipmi_si" >> /etc/modules
Nous allons maintenant définir un utilisateur qui puisse se connecter à la console (nous utilisons ici l'id 8 pour l'utilisateur operator du fait que la société qui nous héberge utilise déjà les 7 premiers identifiants pour ses propres besoins) :
# ipmitool -U root user set name 8 operator
# ipmitool -U root user set password 8 operatorpass
# ipmitool -U root user enable 8
Nous allons maintenant essayer de nous connecter à la console :
ipmitool -I lanplus  -U operator -P operatorpass -H 10.10.10.10 sol activate
Malheureusement, nous allons nous retrouver bloquer puisque personne n'écoute. Néanmoins, si nous rebootons notre serveur, il nous permettra d'accéder au bios (le but de ce billet !). Un rapide coup de F2 au redémarrage et nous voyons apparaître l'écran suivant :



Activons ensuite le support Intel de virtualisation :


Il faudra ensuite arrêter électriquement la machine et la redémarrer à l'aide de l'interface Web de l'hébergeur.

Notre mission est terminée mais pourquoi s'arrêter en si bon chemin ? Nous allons ajouter la gestion de grub ainsi que celle de la console de Linux.

Pour la gestion de la console dans grub, il faut rajouter les lignes suivantes dans le fichier /boot/grub/menu.lst :
serial --unit=0 --speed=9600 --word=8 --parity=no --stop=1
terminal --timeout=15 serial console
Et ensuite mettre à jour grub :
grub-install /dev/sda
Enfin, ajoutons le support du port série sur le kernel linux. Il faut pour cela ajouter console=tty0 console=ttyS0,9600n8 dans la ligne de démarrage du kernel. Exemple :
kernel          /vmlinuz-2.6.26-2-amd64 root=/dev/md1 ro quiet console=tty0 console=ttyS0,9600n8