Je confirme de mon coté aussi cet état de fait.

Il est clair que les développeurs ont bien compris que bien souvent l’application Java/J2EE ou PHP qu’ils développent avec leur plateforme Eclipse est destinée à être mise en production vers un serveur Unix ou Linux.

Par ailleurs, j’ajouterai qu’il y a aussi (je pense) une certaine émulsion qui agit lorsqu’un développeur sous Windows, voit un développeur qui lui travaille avec Linux. Ce dernier même si il a des soucis de temps en temps avec son Linux + Eclipse, va tout simplement masquer ses problèmes et dire que son Linux est ‘carrément’ mieux que le Windows, et qu’il est super génial, chouette, etc. Éventuellement, il pourra tout de même dire qu’il y a parfois des problèmes, mais que les avantages restent supérieurs.

Dans tous les cas, le développeur qui se doit d’être curieux, va vouloir faire pareil que son collègue/copain. Et peut-être qu’il y aura ensuite un basculement durable sous Linux (ou un retour sous Windows).

On voit aussi parfois : l’installation en dual-boot, deux ou trois jours sous Linux, puis deux ou trois jours sous Windows en fonction de l’humeur, de la présence ou non du collègue, de la réussite ou non de l’installation de tel ou tel pilote de carte vidéo 3D, etc. Cela fait ‘presque’ penser à des gens qui essayent d’arrêter de fumer

Pour revenir à cette émulsion qui apparait lors qu’un développeur voit un autre développeur qui bosse sous Linux, on peut s’interroger sur le « comment a-t-il basculer sous Linux ? » ce premier développeur ?

Je n’ai pas une réponse, mais simplement quelques cas (qui ne sont pas forcément une généralisation) :

• l’étudiant en informatique qui a mis Linux sur sa machine dès la première année, qui a pu faire son stage de fin d’étude avec son portable toujours sous Linux, et dans la société qui l’a embauché, il n’y a pas de problème pour continuer à bosser sous Linux. Celui-là, finalement, il ne connait pas trop bien Windows, et va plus vite sous Linux.
• le développeur en régie qui vient d’une société où l’ensemble des développeurs est sous Linux (et oui cela existe). Donc là, on a un développeur qui d’abord est contraint, (et bien souvent ensuite – me semble-t-il – convaincu de Linux).
• l’expert / consultant (dont je pense faire parti) qui travaille sous Linux, et de part sa fonction dans le projet bénéficie d’une certaine reconnaissance de ses compétences, et donc du message « si il est expert et qu’il travaille sous Linux, c’est que Linux est le système pour les experts (les bons  »

Bien évidement ces cas s’adressent plutôt à des développeurs qui bossent sur du Java ou de PHP, le développeur .NET, lui n’a pas vraiment le choix, la meilleur plateforme de développement .NET est sous Windows, et son application va fonctionner sur Windows.

Pour conclure, c’est une bonne chose de mon point de vue de voir des développeurs travailler sur l’environnement Linux (ou le tester). Cela leur permet d’ouvrir un peu leur horizon informatique, de leur donner une meilleure compréhension de l’informatique, un peu comme si on voyage dans différents pays chacun ayant ses coutumes, traditions, plats culinaires, etc.

./

• Là où je n’ai pas de mérite, c’est que cela fait 15 ans que j’ai commencé avec Linux (en 1995 avec le noyau 1.2.3) (ah! la jeunesse ).
• Là où j’ai un poil de mérite, c’est que j’ai passé les deux examens le même jour (à 10h30 et à 13h30)

Pour le petit retour d’expérience qui pourrait en intéresser d’autres :

• L’examen LPI 101, c’est 60 questions en 1h30. Pour ma part, j’ai fais l’ensemble des questions en 30 minutes. Puis j’ai passé 30 minutes à revoir l’ensemble des questions, dont environ 7 questions dont j’étais moins sûr. Le résultat c’est 740 sur 800 (soit 92,5% de réussite)
• L’examen LPI 102, c’est aussi 60 questions en 1h30. Ici l’ensemble des questions en 20 minutes, puis 20 minutes à relire avec environ 8 questions avec des incertitudes. Le résultat c’est 750 sur 800 (soit 93,5% de réussite)

Je suis bien entendu très content, ce sont de très bons scores (d’après moi). Il y avait des questions tordues ! Et je ne m’attendais pas à des questions « non-qcm », c’est-à-dire des questions où il faut donner la réponse en l’écrivant, genre : « c’est quoi l’éditeur de texte que l’on retrouve sur toutes les distrib Linux ? Saisir le nom du programme. » (question fictive, car j’ai signé un NDA – accord de confidentialité).

Pour ceux qui préparent (ou veulent préparer la certification) : j’ai préparé la certification avec le bouquin LPIC-1 Linux Professional Institute Certification Study Guide (Level 1 Exams 101 and 102) Edition 2009 et les questions-réponses du cdrom du livre. J’avoue avoir appris quelques bricoles du bouquin (en particulier sur GnuPG), mais globalement mon expérience a été très précieuse. Cependant je crois que les tutoriels de IBM developersWorks m’ont réellement appris pas mal de petites choses que je ne connaissais pas (bien), tels que la partie Impression (LPR/CUPS). Je vous les recommande!

Voilà, voilà. Je vais essayer (en espérant que mon courage reste et que le boulot ne me mange pas), de préparer également la certification LPIC-2, qui me semble accessible après quelques révisions sur le Kernel, Samba et NFS.

J’ai aussi envie de faire un passage vers l’examen Ubuntu 199, pour avoir la certification « Ubuntu Certified Professional« , car je suis un fervent utilisateur de Ubuntu (Desktop et Server).

J’avoue que mon désir final, est d’avoir la certification LPIC-3 spécialité sécurité…

./

En effet, la philosophie sous Unix pour un compte utilisateur, c’est : toutes ses données et toute sa configuration doivent être dans son « home directory ». Ainsi pour un changement d’ordinateur, il suffit de copier son répertoire utilisateur de l’ancien vers le nouveau. (On notera au passage, que ce concept a été repris par Microsoft à partir de Windows Vista.)

Voici la recette complète, si jamais vous avez besoin :

1. une sauvegarde complète de mon répertoire utilisateur vers un disque dur externe (le même que j’utilise pour mes sauvegardes hebdomadaires), soit 109 Go de données/configuration. Pour cela j’utilise rsync, un petit utilitaire de synchronisation de fichiers, bien connu des gens d’unix.
2. une installation de Ubuntu (9.10) sur le nouvel ordinateur portable suivi de l’installation des dernières mises à jour. Lors de l’installation, à la demande de création de l’utilisateur, j’ai, bien entendu, remis le même nom d’utilisateur que l’ancien.
3. puis, l’ajout des paquetages supplémentaires sur le nouveau afin d’avoir les mêmes applications que l’ancien ordinateur. Ce n’est pas forcément obligatoire, car on le faire au fil de l’eau, mais bon, c’est facile de faire la liste, puis avec une grande ligne de commande « apt-get install pqt1 pqt2 etc » on installe le tout. (c’est carrément plus simple, rapide et moins prise de tête que sous Windows où il faut faire l’installation des applications une à une…)
4. pour finir, restauration de la sauvegarde sur le nouvel ordinateur, à partir du disque dur externe (environ 4 heures pour 109 Go), toujours avec rsync. Éventuellement un « chown -R …. » si vous avez changé de nom d’utilisateur ou de numéro d’ID.

C’est tout. C’est presque frustrant, car une fois reconnecté sur le nouvel ordinateur, on se retrouve avec son bureau, ses applications, ses données, au même endroit, sans changement visible… On n’a même pas passer une nuit blanche à tout réinstaller, à suivre les barres de progression des transferts de données ou des installations, ou bien à essayer tant bien que mal à reconfigurer sa messagerie Thunderbird pour retrouver ses mails et le bon serveur POP3…

Non, finalement à part le backup/restore (qui aurait pu être remplacé par un rsync via ssh), je n’ai pas fait grand chose et j’ai bien dormi.

./

Voici une réponse :

Pour répondre à la problématique du « à distance sans saisir de mot de passe avec SSH », nous allons utiliser la notion de clé SSH.

Sur le poste de travail Linux (le poste qui va lancer la commande à distance), nous allons générer la clé SSH avec la commande suivante :

ssh-keygen -t dsa -f $HOME/.ssh/MON_LOGIN

Puis nous allons transférer la partie publique de la clé, en utilisant l’utilitaire ssh-copy-id :

ssh-copy-id MON_LOGIN@192.168.1.1

• le MON_LOGIN peut être remplacé par un autre login.

Si jamais vous n’avez pas l’utilitaire ssh-copy-id, le transfert de la partie publique peut se faire ‘manuellement’ avec la commande suivante :

scp $HOME/.ssh/MON_LOGIN.pub MON_LOGIN@192.168.1.1:/home/MON_LOGIN/.ssh/MON_LOGIN.pub

Puis en ssh sur la machine 192.168.1.1 :

cat /home/MON_LOGIN/.ssh/MON_LOGIN.pub >> /home/MON_LOGIN/.ssh/authorized_keys
rm /home/MON_LOGIN/.ssh/MON_LOGIN.pub

Voilà, maintenant que la partie publique de la clé est sur la machine distance (192.168.1.1), il suffit de faire « ssh 192.168.1.1″ pour être directement connecté sur la machine, en SSH, sans saisir de mot de passe.

Si jamais on veut utiliser une autre clé SSH qui a un nom différent du login, on peut préciser le fichier de clé à utiliser avec le paramètre « -i ». Par exemple :

ssh -i $HOME/.ssh/supervision supervision@192.168.1.1

Pour répondre à la question « en tant que root avec un utilisateur normal (et toujours) sans taper de mot de passe » :

Nous allons utiliser l’outil sudo que vous devez certainement connaître. Cet utilitaire permet à utilisateur normal de lancer une commande en tant que root.

Pour permettre à cet utilisateur donné de lancer une commande donnée sans saisir de mot de passe, nous allons opérer sur la machine distante (192.168.1.1), en éditant en tant que root, le fichier de configuration de sudo :

vi /etc/sudoers

A la fin du fichier, on ajoute la ligne suivante :

MON_LOGIN  ALL=NOPASSWD:/usr/sbin/ma_commande

• où MON_LOGIN est le login de l’utilisateur qui doit exécuter la commande
• /usr/sbin/ma_commande est la commande en question

Maintenant, nous sommes prêts pour lancer la commande qui va répondre à la question de ce billet.

On se place sur la machine de lancement, et on saisit la commande suivante :

ssh -t MON_LOGIN@192.168.1.1 sudo /usr/sbin/ma_commande param1 param2

où :

• -t permet d’émuler une pseudo console tty (nécessaire si le paramètre requiretty est activé dans le /etc/sudoers)
• MON_LOGIN@192.168.1.1 correspond au login et la machine distante
• « sudo /usr/sbin/ma_commande param1 param2 », la commande et ses paramètres à exécuter sur la machine distante

Et voilà, nous avons la réponse.

Pour finir, ne me demandez pas : « A quoi cela sert de pouvoir faire cela ? », car soit vous en aurez besoin un jour si vous faites de l’administration systèmes et vous serez content de trouver ce billet, soit vous n’en aurez jamais besoin…

./

YUM permet en effet de faire la gestion des packages sur ces types de distributions, en gérant les dépendances entre les packages, c’est-à-dire que si vous voulez installer par exemple PHP sur votre serveur Linux RedHat, il suffit de faire « yum install php » et hop, tous les packages nécessaires à PHP vont être installés (entre autres le serveur Apache HTTP ).

Mais pour cela, YUM a besoin d’une connexion à Internet pour 1/ localiser le package désiré, 2/ télécharger son entête pour voir ses dépendances, 3/ télécharger les entêtes de ses dépendances et générer également les dépendances de ses dépendances, 4/ puis quand il n’y a plus de dépendances à gérer, procéder au téléchargement et à l’installation.

Le problème est que parfois, la connexion à Internet n’est pas disponible pour faire des installations ou des mises à jour sur des serveurs dans des salles blanches sécurisées. Pas de problème, YUM avec un peu de configuration sait aussi travailler en « local », à partir du média d’origine ou d’une version de mise à jour.

Donc, pour pouvoir faire des installations ou des mises à jour depuis le DVD (ou les Cdroms) de Redhat, il faut bien entendu le media, ou mieux l’image ISO du media.

Ici c’est l’image ISO de la Redhat Linux Entreprise (RHEL) version 5.2 pour processeurs Intel avec les extensions 64 bits : rhel-5.2-server-x86_64-dvd.iso

Comme pré-requis, j’ai déposé l’image ISO dans le répertoire /root/dvd_redhat/

Etape 1 : Montage de l’image ISO sur le système de fichiers afin de récupérer les packages RPM qui serviront à l’installation ou à la mise à jour.

mkdir /root/dvd_redhat/disk/

mount -o loop /root/dvd_redhat/rhel-5.2-server-x86_64-dvd.iso /root/dvd_redhat/disk/

La commande « mount -o loop » qui commence à être de plus en plus connue, permet « d’ouvrir » une image ISO, et de la monter sur l’arborescence de fichiers. Ici, dans le répertoire /root/dvd_redhat/disk/

Etape 2 : Récupération des packages RPM dans un nouveau répertoire.

L’image ISO montée étant en mode lecture seule, il faut copier les fichiers RPM vers un répertoire en lecture/écriture (pour faire l’étape 4).

mkdir /root/dvd_redhat/RPM

cd /root/dvd_redhat/disk/Server/

cp *.rpm /root/dvd_redhat/RPM/

Etape 3 : Installation de l’utilitaire createrepo

On profite d’être dans le répertoire qui contient tous les packages RPM, pour installer manuellement l’utilitaire createrepo, ce dernier permettant de faire l’étape suivante.

rpm -i createrepo-0.4.11-3.el5.noarch.rpm

Etape 4 : Création du nouveau référentiel (repository) de fichier

On se place sur le nouveau répertoire contenant les RPM copiés de l’image ISO, et on va créer un nouveau référentiel (index) des fichiers RPM avec la commande createrepo.

cd /root/dvd_redhat/RPM/

createrepo ./

La commande createrepo prend comme argument le répertoire courant, ici /root/dvd_redhat/RPM/ .

Elle va créer un ensemble de fichiers dans un sous-repertoire ./repodata/

Tiens, on a plus besoin du montage de l’image ISO, on en profite pour démonter…

umount /root/dvd_redhat/disk/

Etape 5 : Création du fichier de référence du nouveau référentiel

Pour que YUM puisse utiliser notre nouveau référentiel, il faut lui ajouter sa référence dans sa configuration. Sous RHEL, il faut simplement créer le fichier suivant :

vi /etc/yum.repos.d/RedHat-Media.repo

======================CONTENU=====================================

[redhat-media]

name=RedHat-$releasever - Media

baseurl=file:///root/dvd_redhat/RPM/

gpgcheck=1

enabled=1

gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release

==================================================================

Etape 6 : utilisation de YUM

On va commencer par faire un nettoyage de YUM avec le commande suivante :

yum --disablerepo=\* --enablerepo=redhat-media --noplugins clean all

On notera le « –disablerepo=\* » qui permet de désactiver toutes les références vers d’autres référentiels, le « –enablerepo=redhat-media » qui indique que l’on souhaite travaillait avec notre nouveau référentiel, et pour finir l’option « –noplugins » qui va désactiver tous les plugins, notamment celui du RHN qui nécessite une connexion Internet que nous n’avons pas.

Le « clean all » commandant le nettoyage du cache de YUM.

Voilà.

Ensuite, on peut utiliser YUM pour gérer les installations, les désinstallations, les mises à jour de ses packages en gérant les dépendances.

Pour une installation :

yum --disablerepo=\* --enablerepo=redhat-media --noplugins install <nom_package(s)>

Pour une suppression :

yum --disablerepo=\* --enablerepo=redhat-media --noplugins remove <nom_package(s)>

Pour une mise à jour de version sur l’ensemble des packages (par exemple un passage de RHEL 5.1 à RHEL 5.2)

yum --disablerepo=\* --enablerepo=redhat-media --noplugins update

Bon courage.

./

Parmi la (petite) liste des nouveautés, je retiens celles-ci :

• La possibilité d’avoir un répertoire privé et surtout crypté pour chaque utilisateur. Basé sur ecryptfs, cela permet donc d’avoir des données cryptées sur son disque, ceci de manière transparente (c’est intégré au keyring et s’affiche comme un nouveau disque). Si jamais vous perdez votre ordinateur (ou on vous le vol), vous serez certainement content de cette fonctionnalité. Elle est d’autant plus intéressante qu’elle ne nécessite pas le cryptage complet du disque ou d’un partition (comme truecrypt par exemple), ceci étant (à mon avis) un avantage si jamais vous avez un pépin au niveau de votre ordinateur et qu’il faille ré-installer.
• La possibilité d’avoir un compte Invité (guest) temporaire, pour, par exemple donner l’accès à un ami sur votre poste, afin qu’il puisse consulter ses emails, surfer, ou carrément travailler ses documents Word sous Google Docs, etc. Cette fonctionnalité part du constat qu’aujourd’hui, seul un navigateur web suffit pour travailler, les couches sous-jacentes (système d’exploitation et disons disque dur) ne sont plus requises.

Malheureusement, la version 3.0 d’OpenOffice n’est pas inclut dedans (du moins pour l’instant). On reste sur la version 2.4.1.

Vous pouvez trouver les différentes versions 8.10 de Ubuntu à cette adresse :

http://www.ubuntu.com/testing/intrepid/beta

]]> http://blog.milamberspace.net/index.php/2008/10/12/version-beta-de-ubuntu-810-nom-de-code-intrepid-ibex-99.html/feed 0 http://blog.milamberspace.net/index.php/2008/05/01/redbooks-linux-performance-and-tuning-guidelines-74.html http://blog.milamberspace.net/index.php/2008/05/01/redbooks-linux-performance-and-tuning-guidelines-74.html#comments Thu, 01 May 2008 18:58:39 +0000 Milamber http://blog.milamberspace.net/index.php/2008/05/01/redbooks-linux-performance-and-tuning-guidelines-74.html Linux ayant une place importante dans mon utilisation informatique, il est bien normal d’être à l’affût de bons documents dessus. IBM via son site de publications Redbooks nous propose un excellent document sur les performances et l’optimisation de Linux (il s’agit en réalité d’une mise à jour d’un document déjà sorti en juillet 2007).

Redbooks : Linux Performance and Tuning Guidelines

Ce livre nous propose ainsi une large introduction au fonctionnement interne de Linux au niveau de la gestion des processus, les architectures mémoire (en particulier les différences entre systèmes 32 bits et 64 bits), les systèmes de fichiers (ext3, ext2, etc.), la gestion des entrées / sorties et la gestion du réseaux. C’est extrémement instructif.

La suite est un panorama des outils disponibles sur les distributions Linux pour la supervision et le benchmark. Chaque outil est expliqué, en particulier l’interprétation des données affichées.

Les deux derniers chapitres nous montrent d’une part les méthodes d’identifications des goulots d’étranglements (bootlenecks) au niveau CPU, mémoire, disques et réseaux. Et d’autre part des techniques d’optimisation de sa machine Linux (orienté serveur).

Pour résumé, ce document doit être une référence pour tout bon administrateur système qui s’occupe de serveurs Linux ou tout personne soucieuse (comme moi) des performances des bécanes !

Bon lecture.
./