Aller au contenu | Aller au menu | Aller à la recherche

Another Home Page Blog

lundi, décembre 5 2011

Couleurs dans le terminal

Pour beaucoup de gens, la vue d'un terminal, en général en texte blanc sur fond noir (mais aussi en noir sur fond blanc ou beige sur certaines distributions), peut s'avérer très peu attrayante. En ce qui me concerne je me suis accommodé et j'ai fini par apprécier le terminal, grâce à quelques modifications cosmétiques apportant de la couleur. Je trouve ainsi mon environnement beaucoup plus lisible.

Le prompt

Dans bash (et probablement dans d'autres shells), il est possible de modifier l'apparence du prompt via la variable d'environnement PS1. Regardons quelle est la valeur de PS1 sur un système CentOS (les simples quotes visent à montrer qu'il y a un espace à la fin) :

[root@orgrimmar ~]# echo "PS1 vaut: '$PS1'"
PS1 vaut: '[\u@\h \W]\$ '

Il est possible d'en modifier l'apparence avec de nombreux paramètres, tels que la couleur, certaines informations. Par exemple, j'ai choisi d'appliquer la personnalisation suivante sur tous mes environnements bash :

nils@arreat:~$ echo "PS1 vaut: '$PS1'"
PS1 vaut: '\[\]\u\[\]@\[\]\h\[\]:\w\[\]\$\[\] '

Ce qui est gênant, c'est que si ma variable d'environnement possède des couleurs, leurs codes ne sont pas affichés mais directement interprétés. En réalité, ma variable PS1 vaut :

# récupartion depuis mon bashrc :
PS1=$'\[\E[01;32m\]\u\[\E[0m\]@\[\E[01;36m\]\h\[\E[0m\]:\w\[\E[01;32m\]\$\[\E[0m\] '

Le nom d'utilisateur et le signe "$" sont verts, tandis que le nom d'hôte est bleu. J'ai réalisé une variante pour l'utilisateur root où le vert est remplacé par du rouge.

Pour essayer, rien de plus simple : il suffit d'exporter la variable d'environnement PS1 avec une nouvelle valeur :

[root@orgrimmar ~]# echo "PS1 vaut: '$PS1'"
PS1 vaut: '[\u@\h \W]\$ '
[root@orgrimmar ~]# PS1=$'\[\E[01;32m\]\u\[\E[0m\]@\[\E[01;36m\]\h\[\E[0m\]:\w\[\E[01;32m\]\$\[\E[0m\] '
root@orgrimmar:~# echo "PS1 vaut: '$PS1'"
PS1 vaut: '\[\]\u\[\]@\[\]\h\[\]:\w\[\]\$\[\] '

Il est possible d'aller plus loin, comme de remplacer \h par \H pour obtenir le nom complet de la machine, d'insérer la date, d'afficher le prompt en gras... Vous trouverez chez Nixcraft les différents codes pour démarrer et stopper une couleur, ainsi que pour la mise en gras.

Si vos expérimentations amènent un résultat peu plaisant, deux possibilités : la première consiste à appliquer de nouveau l'ancienne valeur PS1, si vous avez copié son contenu ailleurs, ou d'aller le chercher par exemple dans /etc/bashrc ; la deuxième consiste tout simplement à fermer puis relancer votre terminal.

Une fois que votre nouveau prompt vous plaît, vous voulez rendre le changement définitif. Il est possible d'éditer son fichier .bashrc, .bash_profile ou .profile pour cela. Si vous souhaitez que ce changement soit effectif pour tous les utilisateurs, il est possible de modifier directement /etc/profile ou /etc/bashrc, mais je ne vous le recommande pas : il est possible de mal éditer le fichier et de supprimer accidentellement des commandes utiles, et donc de mettre en vrac son système.

Pour CentOS/RHEL/Fedora, j'ai pris l'habitude de créer un fichier nommé /etc/profile.d/prompt.sh : en effet, le fichier /etc/profile de ces distributions charge tous les .sh situés dans /etc/profile.d. Il devient donc aisé d'ajouter ou de retirer des personnalisations shell comme des alias, le prompt, et d'autres variables d'environnement qui affecteront tous les utilisateurs.

Pour NetBSD, j'ai choisi de créer un fichier /usr/pkg/etc/bashrc contenant ces personnalisations, et d'ajouter le contenu suivant dans /etc/profile (qui, par défaut, ne contient que des commentaires) :

if [ "${BASH_no}" != "no" ]; then
                 [ -r /usr/pkg/etc/bashrc ] && . /usr/pkg/etc/bashrc
fi

De la couleur dans ls

Selon votre système, cette option peut ne pas être disponible : cela fonctionne avec CentOS 4 et 5, mais pas avec NetBSD. Il s'agit tout simplement d'utiliser l'option --color, qui peut être complétée, par exemple --color=auto ou --color=tty. D'où viennent ces couleurs ? De la variable d'environnement LS_COLORS. On peut donc modifier cette variable pour afficher les couleurs différemment, et consulter la page de manuel de dircolors pour plus de détails.

Grep

La commande grep possède une option --color, parfois activée par défaut dans un alias sur certaines distributions. Elle colore en rouge la chaîne de caractères recherchée, que ce soit sous CentOS ou NetBSD.

Pages de manuel en couleur

most permet de visualiser un texte, comme more ou less. A la différence de ces deux derniers, most affiche les pages de manuel en couleur. Pour cela, vous pouvez utiliser la commande suivante :

PAGER=most man <votrecommande>

Pour que ce soit définitif, exportez la variable d'environnement PAGER=most. Attention toutefois, vérifiez que vous n'avez pas un PAGER=more qui traîne quelque part. Concernant la disponibilité du package, on peut le trouver dans pkgsrc ainsi que dans RPMForge.

Colorer ses fichiers de log

Un outil très pratique pour avoir des fichiers de log en couleurs est ccze. Il m'arrive de l'utiliser de la manière suivante :

tail -f /chemin/vers/mon/log/apache | ccze

Je peux aussi m'en servir sur un fichier qui n'est pas mis à jour en direct, en duo avec less :

ccze -A < monfichierdelog | less -R

Ce petit bijou connaît de nombreux formats de fichiers de log, et les rend du coup plus agréables à lire. C'est disponible dans pkgsrc et dans EPEL

Un top en couleur ?

Htop est une version améliorée de top qui, en plus d'afficher la couleur, affiche les taux d'occupation processeur et mémoire d'une manière un peu graphique. A noter cependant que cet outil est d'abord développé pour Linux, et qu'il faut, sous NetBSD, monter /proc avec l'option linux (celle-ci est cependant différente de la couche de compatibilité binaire linux). Htop est disponible dans pkgsrc et dans EPEL

Coloration syntaxique avec VIm

Vous trouvez vi trop morne et déprimant ? Installez VIm et activez la coloration syntaxique ! Souvent, seul vi est installé. Côté pkgsrc, le package se nomme vim et a pour dépendance vim-share. Côté Red Hat, on installera vim-enhanced (dispo dans les dépôts de base). Une fois ceci fait, ajoutez dans votre répertoire home un fichier .vimrc contenant au moins :

syn on
set nu

Ensuite, éditez un script shell, par exemple. Vous verrez la couleur et les numéros de ligne. Pour ceux qui comme moi on un fond noir ou sombre, on ajoutera la directive suivante à son .vimrc :

set bg=dark

La coloration syntaxique s'adaptera ainsi au fond de votre terminal.

Et voilà ! C'est Noël sur votre shell :-)

lundi, novembre 28 2011

Lancement de GNU Screen en arrière-plan

Les entrailles de GNU Screen (que j'abrègerai en screen par la suite) sont parfois difficiles à comprendre. L'histoire commence ainsi : je possède une machine NetBSD, un peu bruyante, que j'allume le matin au lever et que j'éteins le soir au coucher. J'utilise screen sur cette machine, et j'aimerais, par grosse fénéantise, que ce dernier se lance au démarrage de ma machine, en mode détaché. De la sorte, il ne me reste qu'à lancer un bon vieux screen -r lorsque que je m'y connecte et mon comportement ne change pas d'autres machines allumées 24h/24 : je me connecte, je screen -r et je suis prêt.

Jusque-là rien de bien particulier : un petit tour dans la page de manuel m'apprend que cela est déjà possible :

screen -d -m

Cette commande permet de faire en sorte qu'il démarre en mode détaché, et que c'est justement fait pour un éventuel script de démarrage. En bref, la paix dans le monde, mes amis :-)

Je me précipite donc sur ${EDITOR} et entame l'écriture épique d'un script shell qui va lancer screen en mode détaché sous l'identité de l'utilisateur que je suis, avec le fichier .screenrc qui convient. Le script fonctionne, le script fonctionne au démarrage de la machine (c'est mieux, hein ?), toujours la paix dans le monde, avec les oiseaux qui chantent, nous sommes dans un rêve :-)

Donc, plein d'illusions, je lance la commande screen -r . Et là, c'est le drame : le prompt de mon shell (bash) n'est pas coloré, et n'affiche pas le répertoire courant. Après avoir demandé conseil à mon moteur de recherche favori, je me rend compte que dans ce cas, screen a eu la bonne idée de remplacer la variable d'environnement PS1 (qui définit le prompt) par une valeur autre. D'où vient-elle ? Je ne le savais pas encore. J'ai essayé de redéfinir cette variable dans mon fichier de configuration .screenrc, sans succès. En désespoir de cause, je tente un unset PS1. Victoire ! J'ai mon prompt personnalisé ! je suis joie, bonheur, les oiseaux chantent, la paix dans le monde, tout ça tout ça...

Jusqu'à ce que j'édite un fichier texte. Et là, c'est le drame (à nouveau) : mon éditeur de texte, VIm, dispose d'une fonction de coloration syntaxique que j'active par défaut. C'est trèèèès pratique. J'active aussi la numérotation des lignes. Mais là, pas de couleur. Il s'agit pourtant d'un type de fichier connu. Je tente ma chance avec d'autres programmes disposant d'un affichage coloré, sans succès non plus. Après quelques bidouillages, je me rend compte qu'en changeant la variable d'environnement TERM de screen à xterm-color, j'obtiens à nouveau la couleur. En désespoir de cause j'ajoute export TERM=xterm-color au fichier /usr/pkg/etc/bashrc (ce qui m'évite de copier-coller un .bashrc dans le $HOME de mon utilisateur et de root), je relance le script et là : couleur :-)

Avec le recul de l'écriture de ce billet, je me suis rendu compte que lorsque j'utilise screen -d -m, ce dernier charge mon fichier .profile (qui charge .shrc). Ces deux fichiers m'ont posé problème dans le passé : par exemple .profile contient deux exports qui entrent conflit avec mon bashrc, export EDITOR=vi et export PAGER=more (j'utilise vim et most à la place). J'ai aussi remarqué la ligne suivante dans le fichier .shrc :

export PS1="$(whoami)@$(hostname -s)$ "

Tiens, c'est marrant, c'est exactement le prompt que j'avais lors de mon premier problème... ;-)

Bref, ma solution n'est peut-être pas la plus élégante, mais au moins ça fonctionne. Mais comme on me l'a fait remarquer il y a presque deux mois, sur les systèmes Unix : There Is More Than One Way To Do It (Il y a plus d'une façon de le faire).

jeudi, juin 30 2011

Utilisation de nombreux domU en backend fichiers sur un dom0 NetBSD

Oui, j'utilise des machines virtuelles Xen dans des fichiers. Pas de partition, pas de LVM, non. Un bon vieux fichier qu'on peut effacer sans regrets une fois son domU "jetable" inutile. Pour utiliser ces fichiers, et pour monter des fichiers en tant que disque de manière générale, NetBSD utilise le pilote vnd (4). Et par défaut, il y a 4 fichiers spéciaux vnd. Et lorsqu'on désire lancer 42 machines virtuelles en même temps, chacune ayant besoin d'un fichier vnd pour monter son disque dur, on obient une erreur du genre :

Error: Device 51712 (vbd) could not be connected. Hotplug scripts not working.

Alors on s'affole, on copie-colle le message dans un moteur de recherche bien connu, et on tombe sur ce genre de chose :

How much /dev/vnd*d device do you have ? Maube you need to create more ? e.g.: cd /dev ./MAKEDEV vnd4 vnd5 vnd6 vnd7 vnd8

Donc on applique :

root@arreat:/usr/pkg/etc/xen# cd /dev
root@arreat:/dev# ./MAKEDEV vnd4 vnd5 vnd6 vnd7 vnd8 vnd9 vnd10 vnd11 vnd12 vnd14 vnd15
root@arreat:/dev# cd /usr/pkg/etc/xen
root@arreat:/usr/pkg/etc/xen# xm create vmjetable1 && xm create vmkikoo2 \
&& xm create vmpipeau3 && xm create vmdelire4 && xm create encoreunevmjetable

Maintenant, c'est la RAM qui va commencer à manquer... mais c'est un autre problème ;-)

lundi, juin 20 2011

Installation d'un domU Xen Enterprise Linux sur un dom0 NetBSD

Ces derniers temps je m'amuse à faire des installations par le réseau d'un peu tout et n'importe quoi. J'utilise principalement l'outil de virtualisation Oracle VirtualBox, mais il m'arrive aussi de faire joujou avec Xen. Avec un hôte (dom0) CentOS 5 (et sans doute toutes les distribution de type "Enterprise Linux" telles que Red Hat Enterprise Linux ou Scientific Linux), il est très facile de créer d'autres machines virtuelles (domU) Xen de même type grâce à la commande "virt-install". Avec un dom0 NetBSD cependant, point de commande de ce type. Voyons donc comment faire.

Sur un système Enterprise Linux 5, il est possible de trouver une image de noyau d'installation (et l'initrd approprié) spécifique à Xen, comme par exemple sur ce miroir pour CentOS 5 64 bits.

Ce qui me paraît étrange, c'est avec Enterprise Linux 6, tout du moins avec Scientific Linux. Le noyau 2.6.32 dispose à priori des pv-ops, mais SL6 dispose d'un noyau et d'un initrd Xen. Peut-être est-ce par soucis de compatibilité de chemins, car les fichiers font la même taille que dans le répertoire pxeboot. D'ailleurs, lors de ma synchronisation rsync avec le miroir officiel Scientific Linux, le répertoire xen n'apparaît pas. Et je n'en ai pas eu besoin :)

Une fois nos images de noyau et d'initrd en main, il nous reste à créer notre fichier de configuration de domU, mon exemple prend comme exemple de disque dur un fichier et une connexion réseau par bridge :

name = "centosexample"
uuid = ""
maxmem = 512
memory = 512
kernel  = "/srv/www/pub/CentOS/5/os/x86_64/images/xen/vmlinuz"
ramdisk = "/srv/www/pub/CentOS/5/os/x86_64/images/xen/initrd.img"
extra = "vnc"
on_poweroff = "destroy"
on_reboot = "restart"
on_crash = "restart"
vfb = [  ]
disk = [ "file:/srv/xen/images/disk/centosexample.img,xvda,w" ]
vif = [ "mac=00:16:3a:e2:12:34,bridge=bridge0" ]

Il est possible de faire l'installation en mode texte en supprimant la ligne "extra", et d'ajouter l'url d'un fichier kickstart dans la directive extra, qui devient donc :

extra = "text ks=http://monserveur/pub/cfg/centos5_x86_64.cfg"

La commande "xm create -c centosexample" vous permet de lancer votre domU et de débuter l'installation. Une fois celle-ci faite et votre domU de nouveau éteint, il suffit de commenter les lignes "kernel" et "ramdisk" et de décommenter la ligne "bootloader". Vous pouvez alors démarrer votre domU sans que le noyau de celui-ci soit sur le disque dur du dom0 :)

Lors de mes tests, je me suis limité au partitionnement par défaut (qui utilise LVM), à un détail près : avec Scientific Linux 6, j'ai imposé ext3 à l'installeur. Une fois l'installation terminée, éteindre son domU (proprement de préférence) et modifier la configuration qui devient :

name = "centosexample"
uuid = ""
maxmem = 512
memory = 512
bootloader = "/usr/pkg/bin/pygrub"
on_poweroff = "destroy"
on_reboot = "restart"
on_crash = "restart"
vfb = [  ]
disk = [ "file:/srv/xen/images/disk/centosexample.img,xvda,w" ]
vif = [ "mac=00:16:3a:e2:12:34,bridge=bridge0" ]

J'ai donc remplacé le noyau et l'initrd d'installation par pygrub, qui me permet de démarrer mon domU sur le noyau et l'initrd installés. De plus, les mises à jour ne nécessitent pas de copier de nouveau le noyau et l'initrd sur le dom0.

Pour finir, si vous souhaitez installer un dom0 NetBSD, je ne peux que vous recommander l'excellent billet de Bsdsx !

lundi, mai 2 2011

Configuration d'une redondance DNS

Je suis dans la situation suivante : j'ai une machine exécutant entre autres un serveur DHCP et un serveur DNS, et je souhaite réinstaller cette machine. Problème, si je la réinstalle, le DHCP et le DNS seront indisponibles. Il me faut donc redonder ces deux services pour ne pas perturber les autres machines. Après la redondance DHCP, ce billet aborde la redondance DNS. Ce billet, comme le précédent, n'aborde pas la configuration complète d'un serveur DNS mais détaille les options de configurations liées à la redondance

Une redondance basique dans un LAN est très facile à mettre en œuvre car il n'y a pas besoin de modifier quoi que ce soit chez un registrar. Il faudra cependant ajouter l'adresse IP du second serveur DNS dans la configuration de toutes les machines ayant une adresse IP statique, car celles-ci ne récupèrent pas la liste des serveurs DNS via DHCP. Une redondance DNS se compose généralement d'au moins deux serveurs : un serveur maître et un ou plusieurs serveurs esclaves. Toutes nos futures modifications dans le DNS s'effectueront sur le serveur maître et seront répliquées automatiquement vers le serveur esclave. Dans notre cas, le serveur maître utilise NetBSD 4.0 et le serveur esclave utilise NetBSD 5.1; dans les deux cas, ISC Bind est utilisé dans sa version embarquée avec l'OS, et configuré dans un chroot.

Sur notre serveur maître, configurons nos zones dans le fichier /var/chroot/named/etc/named.conf :

zone "anotherhomepage.loc" IN {
        type master;
        file "anotherhomepage.loc";
        allow-update { none; };
        allow-query { any; };
        allow-transfer { 10.13.37.11; };
};

zone "37.13.10.in-addr.arpa" IN {
        type master;
        file "anotherhomepage.loc.reverse";
        allow-update { none; };
        allow-query { any; };
        allow-transfer { 10.13.37.11; };
};

Remarquons que nous autorisons le transfert vers 10.13.37.11 qui est le serveur esclave. Continuons dans le fichier de zone anotherhomepage.loc dont voici quelques extraits :

$TTL 86400
@       IN      SOA     ns0.anotherhomepage.loc. nils.anotherhomepage.loc. (
               2011042601 ; Serial
               8H   ; Refresh
               2H   ; Retry
               4W  ; Expire
               1D  ; Minimum TTL
)

; Name servers
anotherhomepage.loc.    IN      NS     ns0
anotherhomepage.loc.    IN      NS     ns1
; Mail servers
anotherhomepage.loc.    IN      MX      10      mail
; "A" entries
ns0                  IN      A       10.13.37.10
ns1                  IN      A       10.13.37.11
mail                 IN      A       10.13.37.12

Notre serveur esclave est donc renseigné pour le DNS, voyons voir dans le DNS inverse, fichier de zone anotherhomepage.loc.reverse :

$TTL 86400
@       IN      SOA     ns0.anotherhomepage.loc. nils.anotherhomepage.loc. (
               2011042601  ; Serial
               8H   ; Refresh
               2H   ; Retry
               4W  ; Expire
               1D  ; Minimum TTL
)
        IN      NS      ns0.anotherhomepage.loc.
        IN      NS      ns1.anotherhomepage.loc.
        IN      MX      10      mail.anotherhomepage.loc.
10      IN      PTR     ns0.anotherhomepage.loc.
11      IN      PTR     ns1.anotherhomepage.loc.
12      IN      PTR     mail.anotherhomepage.loc.

Occupons-nous à présent de notre serveur esclave. De ce côté, un seul fichier à modifier, /var/chroot/named/etc/named.conf, car les autres seront transférés par les mises à jour de zone :

zone "anotherhomepage.loc" IN {
        type slave;
        masters { 10.13.37.5; };
        file "anotherhomepage.loc";
        allow-update { 10.13.37.5; };
        allow-query { any; };
        allow-notify { 10.13.37.5; };
};

zone "37.13.10.in-addr.arpa" IN {
        type slave;
        masters { 10.13.37.10; };
        file "anotherhomepage.loc.reverse";
        allow-update { 10.13.37.10; };
        allow-query { any; };
        allow-notify { 10.13.37.10; };
};

Il ne reste maintenant qu'à vérifier notre configuration. Par défaut, les logs vont dans /var/log/messages. Vous pouvez définir un autre emplacement pour les logs, comme par exemple :

logging {
        channel simple_log {
                file "/var/log/named/bind.log" ;
                severity info;
                print-time yes;
                print-severity yes;
                print-category yes;
        };
        category default{
                simple_log;
        };
        category queries{
                simple_log;
        };
};

Cet exemple est à insérer dans votre named.conf. Incrémentons les numéros de série, effectuons une relance de bind sur le serveur esclave puis le serveur maître :

root@ns0:/var/chroot/named/var# /etc/rc.d/named reload
Reloading named config files.

Regardons le résultat sur le serveur esclave pour la relance du serveur maître :

root@ns1:/var/chroot/named/etc# tail -f /var/chroot/named/var/log/named/bind.log
26-Apr-2011 19:14:10.864 notify: info: client 10.13.37.5#64893: received notify for zone '37.13.10.in-addr.arpa'
26-Apr-2011 19:14:10.923 general: info: zone 37.13.10.in-addr.arpa/IN: Transfer started.
26-Apr-2011 19:14:10.924 xfer-in: info: transfer of '37.13.10.in-addr.arpa/IN' from 10.13.37.5#53: connected using 10.13.37.60#65525
26-Apr-2011 19:14:11.335 general: info: zone 37.13.10.in-addr.arpa/IN: transferred serial 2011042601
26-Apr-2011 19:14:11.336 xfer-in: info: transfer of '37.13.10.in-addr.arpa/IN' from 10.13.37.5#53: Transfer completed: 1 messages, 258 records, 8672 bytes, 0.411 secs (21099 bytes/sec)
27-Apr-2011 19:14:11.337 notify: info: zone 37.13.10.in-addr.arpa/IN: sending notifies (serial 2011042601)
26-Apr-2011 19:14:11.383 notify: info: client 10.13.37.5#64893: received notify for zone 'anotherhomepage.loc'
26-Apr-2011 19:14:11.388 general: info: zone anotherhomepage.loc/IN: Transfer started.
26-Apr-2011 19:14:11.390 xfer-in: info: transfer of 'anotherhomepage.loc/IN' from 10.13.37.5#53: connected using 10.13.37.60#65524
26-Apr-2011 19:14:11.654 general: info: zone anotherhomepage.loc/IN: transferred serial 2011042601
26-Apr-2011 19:14:11.654 xfer-in: info: transfer of 'anotherhomepage.loc/IN' from 10.13.37.5#53: Transfer completed: 1 messages, 268 records, 8464 bytes, 0.263 secs (32182 bytes/sec)
26-Apr-2011 19:14:11.657 notify: info: zone anotherhomepage.loc/IN: sending notifies (serial 2011042601)

Houra ! Les transferts ont eu lieu ! Maintenant, il reste à modifier dans notre serveur DHCP les adresses IP des serveurs DNS. Dans le cas d'ISC DHCP :

option domain-name-servers 10.13.37.10, 10.13.37.11;

Notez que ce billet permet une redondance assez basique, et loin d'être totalement sécurisée : quelqu'un d'assez malin peut, en utilisant une attaque de type Man-in-the-middle peut appliquer des modifications au serveur esclave. Pour les personnes qui aimeraient corriger ce défaut, il faut se tourner vers DNSSEC.

- page 1 de 2