Vous voulez préparer un cours ou une présentation à base de ligne de commande, espionner quelqu'un ... ?

Ça vous ennuie de taper les commandes en direct ?

J'ai la solution : script.

Script

Script est une commande qui crée un faux terminal virtuel et duplique tout ce qui s'y passe dans un fichier typescript.

Exemple :

$ script
# on est ici dans un terminal
$ echo coucou
> coucou
$ exit
# on est sorti du terminal
$ cat typescript
> $ echo coucou
> coucou
> $ exit

Dit comme ça, ça ne semble pas très utiles mais 2 choses vont tout changer. La première c'est que script fait un vrai terminal virtuel et pas seulement une redirection, ce qui veut dire que contrairement aux pipe (|) et autres redirections (>), il est capable d'enregistrer ce qui va sur le terminal (Il est important de savoir faire la différence entre le terminal et stdout).

Exemple : la commande time. Cette commande écrit le temps d'exécution directement sur le terminal et pas dans la sortie standard, on ne peut donc pas la récupérer facilement, script le peut.

Scriptreplay

La 2e commande qui va tout changer : scriptreplay.

Maintenant faites le même test mais enregistrez vos commande avec le paramètre -t (la sortie de -t va dans stderr, ça pourrait être mieux, mais c'est comme ça) :

$ script -t 2> timer

Et cette fois utilisez scriptreplay pour lire ce qui a été généré :

$ scriptreplay timer typescript

Et là vous avez out ce qu'il faut pour faire une présentation qui dure exactement le même temps que celui qui vous a été nécessaire pour taper les commandes.

Si vous voulez adapter les timer vous pouvez, le script est éditable, mais bon à la main c'est un peu chiant. Par contre vous pouvez utiliser ctrl-s (pause) et ctrl-q (unpause) pour contrôler l'exécution du rendu.

PS : pour ceux qui suivent, il est possible de remplacer mon ssh -t de l'article sur le test de bootloader par une commande script, ce qui est un peu plus propre.

Petite fiche technique pour ne pas se perdre dans le monde de l'hébergement :

Housing

C'est le même terme en français, on dit aussi colocation, il désigne en général la fourniture de l'espace dans une armoire, du réseau et de l'électricité et c'est tout.

Pourtant c'est en général l'offre la plus chère car la plus lourde à gérer pour l'hébergeur. C'est plutôt destiné aux entreprises qui ont leur propre matériel et/ou dont l'activité sera de revendre l'accès à leur propre matériel.

Server hosting

Ou serveur dédié en français. Pratique pour une PME, ce concept permet à un sysadmin ou une petite boite d'avoir un ou des serveurs qu'elle gère entièrement, sans contraintes mais aussi sans avoir à gérer la redondance électrique ou la redondance du réseau.

On a en général une bien meilleure disponibilité et un bien meilleur débit qu'un serveur hébergé chez soi. Donc valable dès qu'on offre des services à l'extérieur. De plus on ne s'embête plus avec les matériel et ses pannes ou presque.

VPS

Ou serveur virtuel en français. C'est une machine virtuelle sur laquelle vous avez tout pouvoir (root) mais située sur une machine physique partagée avec d'autres clients.

Cela permet de faire des machines très peu chères en contrepartie d'une absence de garantie de performances.

A noter qu'OVH a sorti un produit intermédiaire entre le vps et le dédié nommé RPS. Il s'agit d'un dédié léger mais dont le disque est partagé sur le réseau.

Web hosting

Hébergement mutualisé en français. Ce genre d'offre en général est la moins cher et la plus facile à gérer. Disponible immédiatement ou presque, vous avez plus ou moins d'espace disque, une base de données plus ou moins grosse et un virtualhost php avec parfois un nom de domaine.

A choisir lorsqu'on fait un "simple" site web.

Cloud

Petit nouveau, le cloud désigne en fait un groupe de machines dont on vous vend la puissance de calcul. Il existe autant de formes de cloud que de vendeurs de cloud, tous ont cette particularité de vendre des quantités variables.. Il y a ceux qui vous vendent des vm en grande quantité, il y a ceux qui vous vendent des serveurs d'application, il y a ceux qui vous vendent de la base de données ou du simple dépôt de fichier.

A choisir lorsqu'on a des applications scalable et qu'on prévoit un grand nombre de clients potentiels.

Autres

Les hébergeur offrent aussi sous forme de pack des noms de domaine, des services dns, des services de boite mail, d'envoi en masse de mail, en général pour pas trop cher, cherchez, vous trouverez.

Il existe aussi d'autres offres plus rares d'hébergement d'application ruby, python, java mais il faudra chercher pour trouver quelque chose d'intéressant.

Dans le genre exotique vous verrez aussi des offres de type shell où vous avez un shell sur une machine partagée entre plusieurs utilisateurs. Ce genre d'activité nécessite en général une certaine confiance et a plutôt tendance à fonctionner à travers des réseaux sociaux.

Que se passe-t-il lorsqu'apache reçoit une requête ?

La question peut paraître anodine jusqu'à ce qu'on ait à écrire un fichier de configuration un peu complexe. Il faut alors avoir une idée de l'ordre dans lequel les opérations sont effectuées.

Commençons par un aperçu rapide :
-> récupération du virtualhost concerné
-> récupération de la partie requête
-> rewrite rules et redirect
-> alias et réécriture de la requête nom de fichier
-> traitement par <Directory>, <DirectoryMatch>, .htaccess, <Files>, <FilesMatch>, <Location> et <LocationMatch>
-> droits d'accès
-> traitement du fichier en fonction de son type.

Ouf c'est long ! Comme cet article, alors prenez votre temps ...

Traitement de l'URL

Pour chaque requête, apache relit sa configuration (en fait il récupère la version parsée en mémoire). Ensuite il parcourt les éléments dans l'ordre, les compile en une seule conf puis la utilise cette conf spécifiquement pour cette requête.

Virtualhost

Bon ca c'est facile, on se base sur les ServerName définis dans les <Virtualhost>. Si on n'en trouve pas, on cherche dans les ServerAlias, si on n'en trouve pas on cherche encore, mais cette fois avec les wildcard (*.mondomaine.com), si on ne trouve toujours pas, on prend le premier <Virtualhost> qui a été dacléré. Et enfin s'il n'y a pas de virtualhost, on prend le DocumentRoot défini à la racine du serveur apache lui-même.

Voilà on a trouvé le virtualhost, maintenant on prend la requête, qui est la partie située à droite de l'URL après l'hôte et le port.

Transformation de l'URL

Contrairement à ce qu'on pourrait penser, lorsqu'il y a modification de l'url, il n'y a pas de gestion de droits d'accès sur la requête originale, seulement sur l'url modifiée (par rewriterule en général).

On traite d'abord les RewriteRule, dans l'ordre de leur priorités.

Si aucune ne correspond, on traite ensuite les Redirect et les RedirectMatch dans l'ordre de leur écriture. Attention on prend aussi en compte ceux qui sont dans les <Location> qui correspondent, mais on fait comme s'ils avaient été écrits à la racine. C'est-à-dire qu'on n'enlève pas le préfixe du location pour les traiter.

On traite ensuite les Alias, AliasMatch, ScriptAlias et ScriptAliasMatch dans l'ordre de leur apparition. Ce traitement fournit le nom de fichier réel à utiliser pour une URL donnée.

Si on ne trouve pas d'alias on ajoute le DocumentRoot à la requête pour obtenir le chemin complet du fichier.

Configuration et droits d'accès

A partir de maintenant on repart de la configuration du virtualhost et pour chaque section on prend la configuration qui correspond à la requête en cours. Et à la fin on fusionne les configurations récupérées selon une règle de fusion dépendant de chaque module.

C'est complexe et chiant à retenir, donc pour simplifier retenez que les configurations spécifiques aux droits d'accès sont en mode remplacement, c'est-à-dire que la dernière configuration remplace toutes les autres.

Directory et DirectoryMatch

On sait maintenant quel chemin doit être lu, on parcourt l'arborescence pour savoir si c'est un fichier et si on peu le lire s'il a un vrai chemin sur le système ...

On part de / et au fur et a mesure qu'on descend dans le système de fichier on vérifie les <Directory>, puis les .htaccess, puis les <DirectoryMatch> dans l'ordre pour chacun des répertoires. On a donc séquentiellement pour par exemple /var/www :

• <Directory />
• /.htaccess
• <DirectoryMatch />
• <Directory /var>
• /var/.htaccess
• <DirectoryMatch /var>
• <Directory /var/www>
• /var/www/.htaccess
• <DirectoryMatch /var/www>

Toutes les sections qui correspondent sont accumulées dans la configuration en cours.

Attention ! Si l'option FollowSymLinks est activée, on fait la correspondance sur les liens symboliques avant de les déréférencer. Si l'option est désactivée, on la fait sur les liens après les avoir déréférencés. C'est assez contre intuitif !

Files et FilesMatch

Une fois arrivé au bout, on a un fichier, on lit alors les sections <Files> et <FilesMatch> dans l'ordre de leur apparition, y compris celles qu'on a trouvé dans les .htaccess ou les <Directory>.

Notez que ces sections ne prennent en compte que le nom de fichier, sans chemin.

Attention, même remarque que précédemment sur les liens symboliques : "Si l'option FollowSymLinks est activée, on matche sur les liens symboliques avant de les déréférencer. Si l'option est désactivée, on matche sur les liens après les avoir déréférencés."

Location et LocationMatch

Maintenant il nous reste à prendre en compte tous les <Location> et <LocationMatch> de la configuration qui correspondent à notre URL. Cette fois on les prend séquentiellement et uniquement en fonction de l'url.

Attention les étapes de réécriture de règle sont passées, on matche donc sur l'url réécrite.

Configuration des droits

Dans le cas des droits d'accès, les blocs de directives se remplacent. C'est-à-dire que si vous avez une série de "order / allow / deny" dans une section, elle remplace intégralement toute autre série de "order / allow / deny" que vous pourriez trouver dans une section précédente.

Attention ceci est valable pour chacun des modules séparément.

Un exemple pour être plus clair :

<Location />
    order allow,deny
</Location>
<Directory /html>
    deny from all
    AuthUserFile users.txt
</Directory>
<DirectoryMatch />
    AuthUserFile web.txt
</DirectoryMatch>
<Directory />
    order deny,allow
    allow from all
    AuthUserFile admins.txt
</Directory>

Le premier <Directory> est lu, puis il est remplacé par le 2e <Directory>, puis il est remplacé par le <DirectoryMatch> puis par le <Location> intégralement, mais séparément pour le module authz_host (order, allow, deny) et le module authnz_user (AuthUserFile). On a donc pour une requête qui matcherait les 3 sections la configuration suivante :

order allow,deny
AuthUserFile web.txt

Pas évident hein :-) Surtout que cette règle n'est pas la même pour d'autres modules comme mod_rewrite.

Traitement des droits

Le traitement des droits lui-même est particulier.

Si on est en satisfy all (par défaut) :

• On prend tous les modules de traitement des droits d'accès et si l'un d'entre eux interdit l'accès, on interdit l'accès.
  
• Puis on prend tous les modules d'authentification utilisateur et si l'un d'entre eux autorise l'accès ou s'il n'y en a pas, on autorise l'accès.

Si on est en satisfy any :

• On prend tous les modules de traitement des droits d'accès et si l'un d'entre eux interdit l'accès :
  • On demande son avis aux modules d'authentification, si l'un d'entre eux autorise l'accès ou s'il n'y en a pas, on autorise.

Rewrite (again)

Arrivé ici, on repasse dans les RewriteRules Mais cette fois on ne traite que le cas particulier des rewrite dans les sections <Location>, <Directory>, <Files> et .htaccess

Ces rewrite se cumulent cette fois (contrairement aux module d'accès, mais toujours selon le même parsing vu précédemment).

Ces rewrites sont cette fois relatifs, contrairement aux rewrite globaux. Ce qui veut dire qu'on les écrit par rapport à une racine qui est l'endroit où la règle est écrite.

Réponse

Cool maintenant on a notre requête nettoyée et on sait vers quelle fichier elle pointe.

Reste à la traiter.

Filter

On cherche tous les filtres (input et output) associés à cette url. Par exemple il y a mod_include, vous savez, pour les fichier .shtml qui contiennent des truc genre :

<!--#echo var="DATE_LOCAL" --> 

Il y a aussi les filtres pour compresser (oui pas besoin de zipper en php, apache peut le faire tout seul).

Tout ceci avec SetInputFilter et SetOutputFilter.

Handler

Ensuite on cherche le handler associé à ce type de fichier. Il y a bien sur le handler fichier (incroyable), mais aussi le handler php, le handler perl (sisi), le handler cgi, mais aussi le handler proxy, et tous ceux que vous pourriez définir avec SetHandler .

On et hop lance le tout : inputfilter -> handler -> outputfilter.

Conclusion

En résumé c'est le bordel ! Celui qui a écrit ça devait en avoir pris une sacrée dose et pas que de la farine. Probablement un pote de celui qui a fait X11 ...

Ne supposez jamais que ça marche comme vous le pensez, testez à chaque modification de votre conf.

Espérons que le prochain apache en développement tiendra ses promesses et nettoiera un peu la gestion de la configuration et surtout des droits d'accès. Sinon je prédis un avenir merveilleux pour toutes les alternatives soit disant "légères" comme lighthttpd ou nginx.

Aujourd'hui les disques atteignent des limites qui n'avaient pas été prévues lorsqu'on les fabriquait comme des machines à laver (notez que le premier disque tournait déjà à 3600 tours par minute.

Les disques ont d'abord été adressés au format cylindre, tête, secteur (CHS), puis au format LBA. Les différentes limites ont évolué en fonctions de la taille du bus d'adressage.

Limites

Aujourd'hui on rencontre encore plusieurs limites. Tout d'abord au niveau logiciel, les partitions qui prévoyaient un adressage linéaire sur 32 bits des secteurs trouvent une limite à 2To (2^32 * 512).

Aujourd'hui au niveau du disque lui-même, les fabricants qui stockaient les informations de redondance et de structure du disque sur chaque secteur commencent à trouver cet espace très restreint.

Aujourd'hui les disques sont tellement gros que la lecture d'un disque entier est extrêmement longue, une erreur dans un fichier et la récupération du système de fichier devient une opération très lourde.

Aujourd'hui les disques sont tellement gros que la restauration d'un disque dans un raid prends un temps énorme, au point qu'il est possible d'avoir une seconde défaillance pendant ce temps.

Aujourd'hui les disques normaux sont tellement gros qu'on utilise le même disque pour plusieurs machines.

Aujourd'hui les disques sont tellement petits qu'on en utilise plusieurs par machine.

Avec tous ces problèmes, on voit beaucoup de choses évoluer.

RAID 6+1

Les disques étant de plus en plus lents et de plus en plus gros, on est déjà passé du raid5 au raid6 pour éviter les problèmes de lenteur lorsqu'un disque manquait, on envisage d'ajouter un nouveau disque de redondance pour éviter le cas où un 2e disque grille pendant la restauration du premier.

SAN

Maintenant tout le monde a un NAS chez lui, mais les serveurs utilisent des SANs qui se partagent sur des interfaces réseau standard et plus seulement SCSI ou Fiber Channel. Le iSCSI, le AoE ainsi que d'autres protocoles permettent d'accéder à ces périphériques de façon transparente et sans matériel supplémentaire.

GPT

Les disques atteignent couramment une taille de 2To. Le format de partition actuel ne permet pas d'utiliser le disque au delà de cette taille. Il devient donc rapidement obligatoire de passer au format GPT. Ceci implique des modifications dans le bios et dans le système d'exploitation.

Secteur 4k

Les secteurs de 512 octets devenant petit, on commence à fabriquer des disques ayant des secteurs de 4ko. Cela permettra une plus grande capacité, de meilleures performances, mais implique aussi des changements au niveau du bios et de système d'exploitation (très lourd cette fois). Quelques références et solutions.

Filesystem

Toutes ces fonctionnalités nouvelles peuvent êtres prises en compte au niveau du système de fichier pour permettre des fonctionnalités sympathiques. Le snapshot fréquent voir continu, l'utilisation de plusieurs disques locaux voire distants, la vérification d'intégrité en live, la récupération d'une perte sans downtime, la possibilité d'utiliser des disques d'une taille quasiment infinie pour notre époque, l'usage d'un même filesystem par plusieurs machines ...

Tout ceci n'était qu'un aperçu qui je l'espère vous donnera envie de connaître les nouvelles technologies à venir.

Supposons que vous administriez une machine distante. Vous n'avez pas d'accès physique à cette machine. C'est ennuyant puisque vous venez de changer la configuration de votre bootloader.

Comment faire pour rebooter tout en garantissant que ca va marcher ?

Hé bien j'ai la solution qui vous permettra de tester ce boot avant de rebooter : qemu.

Préparer les disques

Il nous faut des disques en lecture seule pour éviter que le boot de la machine virtuelle n'écrive sur un disque en cours d'utilisation. Donc pour chacun de vos disques physique :

$ cp -a /dev/sda /root/sda
$ chmod 440 /root/sda

Ainsi nous avons des disques garantis en lecture seule.

Préparer son terminal

Nous allons enregistrer ce qui se passe sur le terminal, lequel va tourner en ncurses, il est donc important pour la lisibilité des logs de le dimensionner à la même taille que l'écran de boot, c'est-à-dire 80x25.

Modifiez la taille de votre fenêtre de terminal jusqu'à ce que les variables $COLUMNS et $LINES vaillent respectivement 80 et 25.

Préparer son bootloader

Quel que soit votre bootloader configurez le de façon à ce qu'il ne lance pas de mode graphique, sinon vous ne pourrez pas stocker les logs de ce qui se passe.

Choisit son qemu

Installez qemu. Puis en fonction du matériel à émuler choisissez qemu-system-i386 ou qemu-system-x86_64 ou une autre architecture si vous travaillez sur d'autres machines.

Lancer le tout

Préparez un 2e terminal pour tuer qemu , ca sera plus simple que d'attendre qu'il se termine proprement (killall qemu pour les impatients).

$ sync
$ ssh -t localhost "qemu-system-x86_64 -m 512 -curses -hda /root/sda" | tee logs

Pourquoi sync ? au cas où vous auriez fait des modification impactant le boot, on force l'écriture de celles-ci sur le disque.

Pourquoi ssh ? Pour profiter de l'option -t qui crée un terminal virtuel même lorsqu'on travaille dans un pipe.

Pourquoi tee ? Pour stocker les logs de ce qui se passe tout en gardant la main sur le clavier. Tout est tellement rapide qu'il peut y avoir des erreurs invisibles.

Pourquoi -m 512 (512Mo de ram): prenez une valeur inférieure à votre matériel mais malgré tout proche pour éviter les effets de bord.

Pensez à ajouter les disques dont vous pourriez avoir besoin selon le niveau de boot que vous voudriez tester.

Lire les logs

Bon, qemu s'est lancé, le boot a planté, mais vous n'avez pas eu le temps de voit l'erreur.

Commencez par tuer le qemu s'il vous gêne. Puis lisez les logs :

$ less -R logs

Pourquoi -R ? parce que cette option vous permet de ne pas traduire les caractères spéciaux que qemu écrit à travers ncurses et vous permet de voir le contenu des logs tels qu'ils sont apparus à l'écran.

Mode graphique

Si vous ne voulez pas de logs ou que vous ne pouvez pas empêcher le mode graphique de se lancer, vous pouvez faire sans. Dans ce cas, à vous de vous connecter à la machine de façon à ce qu'un serveur X soit accessible (par exemple avec ssh -X).

La commande devient alors :

$ sync
$ qemu-system-x86_64 -m 512 -hda /root/sda

PS : Et ça marche avec les outils de virtualisation comme xen.

Lorsqu'on parle de redondance, de haute disponibilité et de disque, on parle de Raid. J'en ai déjà parlé

Voici un petit aperçu des différents types de RAID, le but est ici de trouver les qualités de chacun. Un tableau final récapitule les avantage et les inconvénients qu'il y a à choisir un type de raid donné.

Jbod

Just a bunch of disk, ce n'est pas un raid, le choix de ceux qui veulent pouvoir ajouter des disques bout à bout sans gain de performance.

Contrairement au raid 0 il a un avantage, la perte d'un disque n'empêche pas la récupération des données sur les disques restants par un outil de récupération tel que photorec. En effet, comme les disques sont simplement mis bouts à bout, la plupart des fichiers tiennent intégralement sur un seul des disques. Il est donc possible d'en récupérer le contenu après un crash.

Le jbod se fait avec du LVM sans striping ou avec le driver linear de md.

Raid 0

Le choix de ceux qui veulent des performances.

Chaque disque est découpé en bande (stripe) et les bandes sont entrelacées pour donner le disque final. Ce qui donne un gain de performance appréciable puisque les disque peuvent être lus simultanément, même pendant la lecture d'un gros fichier. Et ils peuvent être écrits simultanément pendant les écritures.

Le raid 0 peut être matériel, logiciel avec le driver md de linux ou logiciel avec LVM (avec striping)

Raid 1

Le choix de ceux qui ne veulent pas de pertes.

Tous les disques sont des copies intégrales. L'avantage le plus important est que lors de la perte d'un disque tout fonctionne comme si de rien n'était. On peut donc remplacer ce disque (ou pas :-).

Un autre avantage existe lors des lectures non séquentielles (lors de la lecture de 2 fichiers par exemple), dans ce cas il est possible d'utiliser un disque pour chaque lecture et donc d'accélérer ce type de lecture. Par contre la lecture d'un seul gros fichier n'est pas accélérée (sous linux).

Il n'y a en revanche aucun impact sur l'écriture, c'est le disque le plus lent qui détermine la vitesse d'écriture (la vitesse devrait être à peu près identique pour chacun).

Notez qu'on peut faire du raid 1 avec plus de 2 disques.

Le Raid 1 peut être matériel, logiciel avec le driver md ou logicielle avec LVM (support du miroring), enfin il est possible de faire du raid1 réseau avec drbd.

Raid 5

Le choix des économes.

En raid 5 chaque disque est découpé en bande, pour chaque groupe de bandes situées au même endroit des disques, une des bandes est choisie pour contenir des octets de redondance (la différence avec le 4 c'est le choix de la bande). Ainsi ce type de raid peut survivre au crash d'un des disques (la redondance permet de reconstruire la bande manquante), mais pas de plusieurs.

L'avantage du raid 5 est que lorsqu'on a de nombreux disques on économise des disques de redondance en n'en achetant qu'un pour la redondance et les autres pour les données.

Mais le raid 5 est assez limité en performances. La lecture se passe comme pour le raid 1. Par contre l'écriture nécessite la lecture de chacune des bandes d'un groupe pour écrire la bande de données, puis calculer et écrire la bande de redondance. C'est donc très lent, à éviter pour les bases de données actives.

D'autre part, lors du crash d'un disque, toutes bandes des disques doivent être lues pour reconstituer une bande manquante. Ce qui implique des baisses de performances énormes, auxquelles il faut ajouter la baisse de performances due à la reconstruction du disque qu'on va remettre. Comme les disque tournent à fond, il n'est pas rare de voir un autre disque exploser en vol à ce moment là -> fin des données.

Le raid 5 peut être matériel ou logiciel avec le driver md de linux.

Raid 6

Le choix des très gros disques.

Le raid 6 fonctionne de la même façon que le raid 5 mais ajoute un deuxième disque de redondance. Ce ne sont pas simplement les données de redondance qui sont dupliquée, mais le calcul qui est différent, toutefois le concept est identique.

Le raid 6 soufre des mêmes inconvénients que le raid 5, il utilise même un disque de plus donc est un peu plus cher, de plus cela provoque une écriture supplémentaire pour chaque groupe de bandes.

Mais le raid 6 résiste au crash de 2 disques, ce qui est intéressant lorsque les disques sont assez gros et que la reconstruction du raid comment à être assez longue (et donc le risque de perte plus gros).

Le raid 6 peut être matériel ou logiciel avec le driver md de linux.

Raid 10

Le choix des riches.

Le raid 10 consiste à accumuler plusieurs raid 1 avec du raid 0 pour en augmenter la taille et les performances.

Le raid 10 offre les avantages simultanés du raid 1 et du raid 0. La perte d'un disque n'empêche pas le raid de tourner et l'utilisation de plusieurs disques en striping permet d'augmenter les performances de lectures.

Le seul inconvénient, c'est qu'il coûte deux fois le prix du raid 0.

Il peut se faire en matériel ou logiciel, md ou lvm.

Raid 0+1

Le mauvais choix.

Le raid 0+1 consiste à mettre 2 raid 0 en parallèle pour les redonder avec du raid 1. On pourrait croire que c'est la même chose que du raid 10, mais non. Et même si certains veulent vous faire croire que les performances sont meilleures, il n'en est rien.

Mais surtout imaginez un instant la perte d'un disque. Dans ce cas un des raid 0 sous-jacent est perdu. Il faut donc le recréer avec un nouveau disque (ce qui est à peu près instantané puisqu'on le laisse vide), puis reconstruire le raid 1 situé au dessus. Et cette deuxième partie va être longue puisqu'elle doit être faite sur la taille totale du raid 0, contrairement au raid 10 qui ne l'aurait fait que sur la taille totale du disque perdu.

Petit récapitulatif

Savez-vous vraiment utiliser postscript ?
Savez-vous ce qu'est postscript ?

Postscript est avant tout un langage, relativement complet. Ce langage se destine à l'affichage et à l'impression. Il contient donc de nombreuses primitives pour l'affichage, principalement vectoriel. Mais rien ne vous force à l'utiliser pour ça. Il existe bien des gens qui utilisent php pour faire des scripts d'administration ...

Interprétation

Le postscript s'interprète, les imprimantes sont donc des interpréteurs postscript, ce qui veut dire qu'on peut les programmer comme on veut. Il existe bien des gens qui programment leur carte graphique pour faire du calcul parallèle ...

Apprenons donc à interpréter un fichier nommé toto.ps :

# technique simple pour en faire un pdf
$ ps2pdf toto.ps

# ancienne technique chamane qui passe par l'imprimante
$ gs -dSAFER -dNOPAUSE -sDEVICE=deskjet -sOutputFile=\|lpr toto.ps

Vous pouvez aussi passer par l'interface de cups à la place de lpr.

Notez bien qu'ici l'interpréteur est ghostscript (gs) et qu'on a du spécifier le type d'imprimante, type qu'on n'a pas choisi au hasard. Pour avoir la liste des imprimantes supportées, tapez :

$ gs -help

Et lisez bien la liste vous verrez des bizarreries comme jpeg, png256, bmpgray ... Ce ne sont pas vraiment des imprimantes, donc vous devinez bien qu'il est donc possible de convertir très facilement un fichier postscript en image jpeg (enfin la première page en tout cas) :

$ gs -dSAFER -dNOPAUSE -dBATCH -sDEVICE=jpeg -sOutputFile=fichier.jpg toto.ps

Pour avoir les autres pages et la résolution de l'image, voici la commande :

# scriptez le si ca vous sert
$ gs -dSAFER -dNOPAUSE -dBATCH -sDEVICE=jpeg -r72 -sOutputFile=fichier-%d.jpg toto.ps

Un peu plus de détail sur les paramètres et les sorties possibles ici : http://pages.cs.wisc.edu/~ghost/doc... ou dans le manuel.

Voila, on n'a pas trop parlé de script ici, mais il en sera question dans le prochain article. D'ailleurs si vous voulez développer dès à présent, il suffit de lancer gs sans -dBATCH et sans fichier postscript pour obtenir une console interactive.

PS : Notez au passage qui toutes les commandes gs fonctionnent aussi avec du PDF car ce dernier est un autre langage compris par gs.