Mes premières impressions sous Arch Linux
J’ai reçu la semaine dernière mon nouveau matériel professionnel à savoir un Dell Latitude E6510 avec station d’accueil et un écran supplémentaire pour du dual sreen. J’en profite d’ailleurs pour souligner qu’il est possible pour cette gamme de commander une machine sans OS! Bref, après un petit moment d’hésitation, j’ai décidé de me lancer dans l’aventure Arch Linux. Je suis pourtant utilisateur d’Ubuntu depuis 5 ans environ. Mon serveur et mon ordinateur fixe personnels tournent d’ailleurs encore avec cette distribution. Je vais tenter dans un premier temps de vous expliquer brièvement les facteurs de ce changement. Puis je tâcherai de faire un bilan de ces 10 premiers jours sous Arch!
De Ubuntu à Arch Linux
Il y a plusieurs raisons qui m’ont fait choisir Arch Linux comme nouvelle distribution. Premièrement, ça fait un moment que j’en entend parler et à chaque fois en bien. Ensuite, je suis suffisamment curieux pour oser me lancer! Il y a aussi le fait qu’Arch Linux est réservé à des utilisateurs avancés et c’est quelque chose qui me plaît bien (on est totalement maître de son système et ça flatte l’ego
). Le principe de rolling release m’a aussi beaucoup tenté. Enfin -troll inside- les derniers choix faits par Canonical ne m’ont pas vraiment convaincu ou en tous cas ne répondent pas à mes attentes (plus orienté réseaux sociaux, ajout de logiciels propriétaires dans la logithèque, etc…). Attention, je ne fais pas le procès d’Ubuntu! Si le libre en est là où il est aujourd’hui c’est, je pense, en grande partie grâce à Ubuntu qui a su le démocratiser un peu plus. Quoi qu’il en soit, pour toutes ces raisons et pour d’autres encore, j’ai tenté l’expérience Arch!
L’installation
Pour commencer, je suis parti sur l’installation par le net. L’iso à télécharger fait ainsi moins de 200Mo et tous les paquets nécessaires sont récupérés durant le processus d’installation. Chose importante, Arch Linux ne contient rien à la base (Pas d’interface graphique par exemple). Il vous faudra tout installer et c’est ça le principal atout de cette distribution selon moi. Quelques précisions pour ceux qui voudraient s’y essayer :
- Le mieux est de suivre ce tutoriel en français très bien fait.
- Ne mettez pas la swap en premier sur le disque (sur sda1). Ça ne lui plaît pas du tout! Pour ma part, j’ai découpé mon disque de cette manière :

- Enfin pour le choix du serveur à utiliser pour récupérer les paquets, choisissez soit celui de archlinux.org (lent mais fonctionnel), soit un en fonction de cette page. Lors de ma première tentative d’installation, j’en ai choisi un au hasard et il se trouve qu’il ne possédait pas la moitié des paquets…
Je ne vais pas détailler le processus d’installation. Des tutoriels font ça très bien et le wiki d’ArchLinux est on ne peut plus complet. Ce qui m’a pris le plus de temps a été la configuration de Xorg, dont l’ex-fichier xorg.conf est maintenant découpé en plusieurs fichiers dans /etc/X11/xorg.conf.d/. Les deux conseils que je pourrais vous donner c’est de ne pas tenter tout de suite le dual screen, je veux dire pas avant d’avoir installé Xorg correctement, et de bien suivre les conseils donnés dans le wiki (ici et là). Une fois que vous aurez installé un gestionnaire de bureau (Gnome par exemple) et si vous avez choisi d’utiliser les drivers de carte graphique propriétaires pensez qu’ils sont installés avec des outils qui génèrent les fichiers de configuration du serveur X à votre place (NVIDIA X Server Settings ou Catalyst Control Center). En revanche, ils génèrent encore le xorg.conf mais à priori, il suffit juste de le renommer et de le déplacer au bon endroit :
sudo mv /etc/X11/xorg.conf /etc/X11/xorg.conf.d/10-monitor.conf |
Premières impressions
Voilà 10 jours que j’utilise quotidiennement Arch Linux et je dois dire que j’en suis très satisfait. Alors certes, l’installation est longue (j’y ai passé une journée) puisqu’il faut vraiment tout installer mais il faut prendre en compte qu’Arch Linux ne se réinstalle pas. Le système de rolling release assure d’avoir toujours une distribution à jour et donc pas de mises à jour de versions importantes. La documentation est très fournie et pour peu qu’on soit à l’aise avec la ligne de commande, ça passe tout seul. Une fois que tout est en place c’est impeccable. On est maître de tout et ça, pour quelqu’un qui n’a pas peur de mettre un peu les mains dans le cambouis, c’est fantastique! Côté gestionnaire de bureau, j’ai fait le choix de Gnome avec le thème Equinox et le jeu d’icône Faenza (Merci Nicolargo
). Enfin, pour terminer sur le bon côté de la chose, le gestionnaire de paquet, pacman, est vraiment très puissant et les paquets AUR sont une source inépuisable de logiciels.
Seulement voilà! Tout n’est pas rose sous Arch Linux. Il y a quand même quelques petits inconvénients. Premièrement, c’est un peu « roots ». Pour quelqu’un qui n’a pas envie de se prendre la tête, ce sera vite décourageant. Une installation d’Ubuntu prend maintenant une heure maximum. Une installation d’Arch Linux (j’entends par là le système, l’ajout d’interface graphique, les paquets de base et tout et tout…) prend nettement plus de temps, en tous cas la première fois. Mais on apprend beaucoup sur le fonctionnement de son système et ça c’est inestimable! Deuxièmement, le système de rolling release choisi par Arch Linux a aussi ses inconvénients. Deux exemples issus de mon expérience : la mise à jour vers la toute dernière version de Thunderbird m’a obligé à fouiller sur le net pour trouver une version de Lightning (agenda) compatible. La version proposée via l’interface d’installation de modules de Thunderbird ne l’était plus… Ensuite une mise à jour « buggée » d’Empathy m’a privé quelques heures de messagerie instantanée. Heureusement, ce sont des choses qui sont très vite corrigées et ne pose finalement pas tant de problèmes que ça. Troisièmement, il y a des automatismes à acquérir. Notamment avec le passage de apt-get à pacman. Ce dernier suivant une logique qui me dépasse quant au nom de ses arguments. Petit comparatif :
| Action | apt-get | pacman |
|---|---|---|
| Installer un paquet | apt-get install _paquet_ | pacman -S _paquet_ |
| Installer les mises à jour | apt-get update apt-get upgrade | pacman -Suy |
| Supprimer un paquet et ses dépendances | apt-get autoremove _paquet_ | pacman -Rs _paquet_ |
Il faut avouer que c’est spécial… Mais après quelques heures d’utilisation ça ne pose plus vraiment de problèmes. Enfin, et ce n’est pas tant la faute d’Arch Linux que des constructeurs de matériel, il est parfois difficile de trouver les pilotes pour certains périphériques. Je pense en particulier à la webcam incrustée dans l’écran du E6510 que je n’ai toujours pas réussi à faire fonctionner… La documentation technique de chez Dell ne m’a pas permis de déterminer quel pilote installer. Une Ubuntu, par exemple, détectera ce type de matériel et installera les pilotes nécessaires.
Conclusion
Je n’utilise Arch Linux que depuis 10 jours donc ce n’est pas encore très facile de se faire un avis mais je suis pour le moment très satisfait. Je n’exclue pas de passer également mes machines personnelles sous cette distribution. Il y a certes quelques couacs de temps à autre mais c’est un moindre mal comparé à la satisfaction qu’apporte un système stable, à jour et dont on est complètement maître. Qui plus est, le système étant « vide » au départ on installe vraiment que ce dont on a besoin, ce qui rend la distribution très légère et réactive.
PS : Si certains sont tentés de passer sous Arch Linux, n’hésitez pas à poser vos questions dans les commentaires. J’en ai eu pas mal moi-même, notamment pour les fichiers de configuration type rc.conf ou pacman.conf, donc je pourrais peut-être y répondre.
Nouveau pilote ATI Catalyst 10.10 pour Linux
Je fais suite à cet article sur le problème rencontré par certains avec les pilotes ATI Catalyst 10.09 et le noyau 2.6.32-25 dans lequel j’avais promis à un lecteur de publier un article dès qu’une nouvelle version de ce driver serait disponible. Et bien c’est le cas depuis 4 jours maintenant. Cette version semble corriger le problème. Le tout est téléchargeable à cette adresse (même fichier pour système 32 ou 64 bits). Ensuite l’installation se fait sans problème de cette manière :
$ sudo sh ati-driver-installer-10-10-x86.x86_64.run [sudo] password for login: Created directory fglrx-install.6JfbL5 Verifying archive integrity... All good. Uncompressing ATI Catalyst(TM) Proprietary Driver-8.783....... ..................................................................................... ..................................................................................... ============================================ ATI Technologies Catalyst(TM) Proprietary Driver Installer/Packager ============================================ Detected configuration: Architecture: x86_64 (64-bit) X Server: X.Org 7.5 64-bit loki_setup: directory: (null) Removing temporary directory: fglrx-install.6JfbL5 $ |
Durant le processus, vous pouvez à priori laisser toutes les options proposées par défaut.
Un reboot plus tard et tout refonctionne parfaitement, comme avant
. Si vous rencontrez malgré tout quelques soucis, je vous publie mon fichier /etc/X11/xorg.conf généré par le processus d’installation. Il est valable pour une carte radeon HD et pour un seul écran :
# xorg.conf (X.Org X Window System server configuration file) Section "ServerLayout" Identifier "aticonfig Layout" Screen 0 "aticonfig-Screen[0]-0" 0 0 EndSection Section "Module" EndSection Section "Monitor" Identifier "Configured Monitor" EndSection Section "Monitor" Identifier "aticonfig-Monitor[0]-0" Option "VendorName" "ATI Proprietary Driver" Option "ModelName" "Generic Autodetecting Monitor" Option "DPMS" "true" EndSection Section "Device" Identifier "Configured Video Device" Driver "radeonhd" Option "DRI" EndSection Section "Device" Identifier "aticonfig-Device[0]-0" Driver "fglrx" BusID "PCI:2:0:0" EndSection Section "Screen" Identifier "Default Screen" Device "Configured Video Device" Monitor "Configured Monitor" EndSection Section "Screen" Identifier "aticonfig-Screen[0]-0" Device "aticonfig-Device[0]-0" Monitor "aticonfig-Monitor[0]-0" DefaultDepth 24 SubSection "Display" Viewport 0 0 Depth 24 EndSubSection EndSection |
Gestion des chemins dans le terminal avec pushd et popd
On a beau être un fervent utilisateur du terminal, on découvre régulièrement de nouvelles fonctionnalités qui nous font gagner du temps et qui nous paraissent finalement indispensables. Parmi elles, je viens juste d’apprendre l’existence des commandes pushd et popd; le « d » final faisant référence à « directory ». Ces deux commandes servent à gérer une pile de chemins. La première ajoute au dessus de la pile le chemin courant puis le chemin passé en paramètre et se rend à ce dernier. La seconde dépile le premier élément et se rend au nouveau premier élément. Un exemple concret de navigation classique depuis le terminal :
login@ubuntu:~/Documents/blog/articles$ cd /var/log login@ubuntu:/var/log$ do-something-amazing login@ubuntu:/var/log$ cd ~/Documents/blog/articles login@ubuntu:~/Documents/blog/articles$ |
En utilisant maintenant pushd et popd :
login@ubuntu:~/Documents/blog/articles$ pushd /var/log # ici est affiché l'état de la pile en partant du haut de celle-ci /var/log /home/login/Documents/blog/articles login@ubuntu:/var/log$ do-something-very-amazing login@ubuntu:/var/log$ popd login@ubuntu:~/Documents/blog/articles$ |
Le but à terme est donc d’utiliser autant que possible pushd à la place de cd de façon à gérer un historique de parcours de répertoires. Il est intéressant aussi de noter que la pile n’est évidemment pas limitée à deux éléments! Ainsi, deux pushd d’affilée permettront de revenir en arrière d’autant. Enfin, une utilisation pratique peut être de faire :
login@ubuntu:~/Documents/blog/articles$ pushd . ~/Documents/blog/articles ~/Documents/blog/articles |
Ainsi, vous pouvez naviguer où bon vous semble le temps d’effectuer une autre tâche (avec des cd) et revenir quand nécessaire dans ce répertoire grâce à un popd. Dernière chose, la commande dirs permet de fournir l’état de la pile et d’en gérer quelques aspects (la vider par exemple).
Mémo : comment « débannir » une IP bloquée par fail2ban?
Quand on a son serveur personnel, fail2ban fait partie des indispensables à installer. Ce démon scrute les logs (que ce soient les logs ssh, apache, etc…) à la recherche des tentatives de connexion infructueuses et peut ainsi bannir une IP si nécessaire. Concrètement, dans le cas d’une tentative de connexion par ssh qui échouerait 3 fois d’affilés (ces paramètres sont configurables), l’IP de la machine à l’origine de ces tentatives aura droit à une belle règle iptable de façon à lui bloquer complètement la connexion via le port 22 pour une durée donnée (5 minutes ou 3000 ans, c’est vous qui choisissez!). Bref, pour vous donner une idée, sur mon serveur je bloque en moyenne 5 IP par jour. Les tentatives sont faites en général via ssh avec des logins comme « root » ou « login » et des mots de passes évidemment faux!
Quoi qu’il en soit, il peut arriver qu’une IP vous appartenant soit bloquée. Ça peut arriver par exemple dans le cas où la connexion à ssh via login/password est activée (et pas uniquement par clé publique/privée) et où vous tentez de vous connecter à votre serveur depuis le boulot en vous trompant de login parce que vous en avez à la pelle vu le nombre de machines que vous utilisez. Du coup, vous tentez 3 fois votre mot de passe sans vous apercevoir que votre login n’est pas bon… et hop! Banni pour un an! (True story!)
Il devient alors pratique, une fois rentré à la maison, de se « débannir », de bloquer la connexion ssh via login/password et d’ajouter sa clé publique pour ne plus avoir de soucis. Mais comment se débannir? Comme ceci :
Admettons que vous ayez été banni à partir de tentatives infructueuses de connexion à ssh. Pour lister les IP bannies, il vous faudra lancer dans un premier temps la commande suivante :
$ sudo iptables -L fail2ban-ssh Chain fail2ban-ssh (1 references) target prot opt source destination DROP 0 -- 66.249.92.104 anywhere DROP 0 -- 91.189.90.40 anywhere DROP 0 -- 207.46.170.123 anywhere RETURN all -- anywhere anywhere |
Bien que la « mise en page » ne le laisse pas paraitre, il s’agit ici d’un tableau dont les en-têtes sont « target », « prot », … Il suffit alors de noter à quelle ligne du tableau apparait votre adresse IP. Considérons que vous souhaitez débloquer 91.189.90.40. Cette IP apparait à la ligne 2. Il ne reste plus qu’à exécuter la commande suivante :
$ sudo iptables -D fail2ban-ssh 2 |
Votre IP sera bien supprimée des règles iptables, vous autorisant à nouveau à vous connecter en ssh!
Mise à jour des drivers ATI Radeon HD sous Linux (kernel 2.6.32-25)
Mise à jour : Nouveau pilote ATI Catalyst 10.10 pour Linux
Je ne suis visiblement pas le seul puisque les forums grouillent de posts à ce sujet : depuis la mise à jour du noyau linux vers sa version 2.6.32-25, le pilote propriétaire permettant de gérer les cartes ATI Radeon HD (4870 dans mon cas) ne semble plus fonctionner. J’ai par exemple eu droit à ce message lors de mes tentatives de réinstallation du pilote Catalyst 10.9 :
DKMS part of installation failed. Please refer to /usr/share/ati/fglrx-install.log for details
Et des redémarrages qui aboutissaient soit sur un écran noir, soit sur un Linux capricieux et lent dès qu’il fallait afficher le moindre élément graphique (page web par exemple)…
Je n’en connais pas la raison mais j’ai découvert ce matin une solution… fournie par AMD en personne. En effet, une version modifiée du pilote a été publiée il y a quelques jours à cette adresse :
http://support.amd.com/us/kbarticles/Pages/GPU83ATICatalystLinuxHotfix.aspx
Autant dire que ce n’est pas simple à trouver (enfin moi, en tous cas, j’ai cherché un moment!) d’où le but de ce post.
Pour l’installation rien de plus simple. Ouvrez le lien fourni précédemment et téléchargez le zip proposé. Puis dans le dossier dans lequel vous l’avez enregistré :
$ unzip catalyst_10.9_linux_hotfix_sep27.zip $ cd fglrx-8.771.2/ $ sudo sh ati-driver-installer-8.771.2-x86.x86_64.run |
Et suivez les instructions. A priori, les options proposées par défaut n’ont pas besoin d’être changées.
Un redémarrage plus tard, vous devriez retrouver un Linux au top!




