Catégories
Systeme

Comparatif Linux versus Mac OS X

Depuis la sortie de Windows Vista, de nombreux sites/blogs ont publiés des comparatifs entre le dernier OS de Bill et Mac OS X. Je viens pour ma part me pencher vers la comparaison de deux OS qui ont les mêmes racines Unix: Linux (distribution Fedora Core 6) et Mac OS X (version Tiger 10.4).Linux vs Mac

Installation

Véritable talon d’Achille des systèmes Linux jusqu’à l’apparition des logiciels d’aide à l’installation (comme Anaconda pour Fedora), l’installation d’un système Linux sur un PC est maintenant à la portée de n’importe quel utilisateur.

C’est également le cas de l’installation de Mac OS X qui est simplifié à l’extrême. Par exemple pour l’installation de l’OS Tiger sur un MacBook Pro, seulement deux questions sont posées (nom de la machine et nom de l’utilisateur).

Notes pour l’installation de l’OS: Linux: 4/5 – Mac OS X: 5/5

Prise en main

La prise en main d’un nouvel OS dépend bien entendu de plusieurs paramètres comme par exemple vos compétences, vos habitudes et vos attentes. Pour un utilisateur habitué à manipuler des outils informatiques, ces deux OS ne pose pas de gros problèmes de prise en main. Il est cependant vrai que le changement par rapport à un OS de type Windows est palpable. Après plusieurs mois d’utilisation intensive de Linux et de Mac OS X, je trouve que les deux OS se valent. Sous Linux il faut cependant un bon moment et un nombre important de configuration avant d’arriver à une ergonomie qui peut concurrencer celle offerte par Mac.

Notes pour la prise en main de l’OS: Linux: 3/5 – Mac OS X: 4/5

Installation et mise à jour des logiciels

Un OS sans logiciels c’est comme une voiture sans essence. Il est donc important de disposer d’un gestionnaire de logiciel permettant de maintenir sont environnement à jour.

L’installation de logiciel est élémentaire sous Mac OS X (une fois que l’on a compris qu’il faut déplacer les logos dans le répertoire Applications lors de l’installation ;)). Sous Linux, elle peut se faire via une interface graphique ou par ligne de commande. Toutes les dépendances sont installées automatiquement.

Nous allons distinguer la mise à jour du système (noyau, « patch » sécurité, drivers…) de celle des logiciels.

Pour la mise à jour du système les deux OS disposent de fonctions équivalente. Quand une mise à jour est disponible, l’utilisateur est prévenu par une fenêtre. Une fois la mise à jour effectué, il doit la plupart du temps redémarrer son ordinateur pour que celle-ci soit prise en compte.

Pour la mise à jour des logiciels, Linux prend l’avantage, notamment grâce à l’utilisation de gestionnaires comme yum (sur Fedora) ou apt-get (sur Debian). Ils permettent en une seule commande (yum -y update) de mettre à jour tous les logiciels installés ainsi que toutes les librairies dépendantes. Un lancement régulier de ces commandes permet de s’assurer d’un système completement à jour.

Sous Mac, il n’y a pas de centralisation de l’information, il faut donc effectuer la mise à jour logiciel par logiciel.

Notes pour l’installation/mise à jour de logiciels: Linux: 4/5 – Mac OS X: 2/5

Interface graphique

C’est le point fort d’Apple. La marque à la pomme à toujours une génération d’avance sur la concurrence (on dit par exemple que l’interface de Leopard, alias Mac OS X 10.5, est une sorte de Windows Vista 2.0 en ce qui concerne l’interface graphique). C’est beau, fluide, les fonctions tombent sous la main, bref un sans faute, vu la puissance actuelle des ordinateurs.

Pour Linux je suis un peu plus contrasté. Effectivement, des progrets énormes ont été accomplies ces dernières années. Avec un PC de dernière génération, quelques heures (jours ?) de configuration aux petits oignons de Beryl, on arrive à un résultat vraiment sympa mais au détriment de l’ergonomie générale du système. Personnellement, j’ai dés-installé Beryl après deux semaines d’utilisations. L’interface par défaut (Gnome ou KDE que je ne connais pas) apporte déjà un bon confort d’utilisation.

Notes pour l’interface graphique: Linux: 3/5 – Mac OS X: 5/5

Logiciels « open-source » disponibles

Linux est le terrain de jeu des développeurs libres (« open-source »). On peut installer sur cet OS un nombre incalculable de logiciels en tout genre. S’il n’existe pas un package pre-compilé pour votre distribution (RPM sous Fedora), vous n’aurez qu’à récupérer les sources et à les compiler.

Sous Mac OS X et contrairement aux dernières générations de Mac OS, le fait de se baser sous un noyau Unix (BSD) permet de pouvoir installer un grand nombre de logiciels libres. Il existe aussi de plus en plus de développeur qui prennent en compte cet OS (voir par exemple le site: http://mac.softpedia.com/).

Notes pour l’interface graphique: Linux: 5/5 – Mac OS X: 3/5

Quel OS pour quel utilisateur ?

Voici mon avis personnel sur l’OS le plus adapté, en fonction des besoins des utilisateurs:
Bureautique: Mac OS X
Developpement: Linux
Expertise/administration réseau: Linux
Traitement image, video: Mac OS X
Web, Mail, Blog: Linux / Mac OS X

Vos avis/expériences m’intéressent, à vos claviers.

Catégories
Blog

F-list c’est mon tour…

C’est en allant sur le blog Fran6art que j’ai récupérer ma F-List initiale. Pour rappel, le but de la F-List est relativement simple:

* vous reprenez (dans son intégralité) la liste de liens de la “F-List” telle que vous la découvrez
* vous ajoutez en début de la liste le blog qui vous a permis de récupérer la “F-List“
* vous ajoutez les blogs que vous lisez régulièrement
* vous postez le tout sur votre blog

Voici donc cette liste, établie selon les règles citées ci-dessus:

Fran6art, TuxPlanet, Pisani, Journal du Mac, LiberT, 2803, Presse-Citron, GuiM, Amine from the blog, Eyes Wide Shoot, Revue de presse insolite, BeFaure, Adeline, BozarBlog, Le blog de Xavier, MisterDanilo, BlastBlog, Jerome Bouteiller, Le bisounours Parisien, Embruns, N’ayez pas peur, E-conomy, Vinvin Entertainment, Le Peuple des connecteurs, AccessOWeb, Le weblog de bleebot, BingBlog, Business Garden, Chauffeur De Buzz, CoopLOG, Echos du Net, FrenchStudioBlog, Outils Froids, IClectic, Media-Tech, ZorGloob, Ecoms, Ga Bu Zo Meu, Loic Lemeur, Patrick Amiel, Julie Calmier, La vie en Pro de Julio, Corinne Dangas, Raphael Gilmas, Grégory Pouy, Legizz blog, Brainsfeed, L-tz, Legweak, Fred de Mai, Au pays d’Elodie, Inertia Creeps, Le blog oranginal, Julien Fabre, Thomas Clément, Logiciels CAO, Ceci dit, J2S, LiberT, B&B, WebJunkie, Astigo, TheCelinette, MrBoo, LaFrange, J3m, Karine, Influx, Google-Stories, Innis, Kopikol, Verbalkint, E-likko, Marketing Alternatif, Prendre un café, Biologeek, Yannick Lejeune

Nicolargo

Catégories
Blog

Centraliser ces avatars avec Gravatar

Je l’attendais depuis un moment, Gravatar l’a fait !

Gravatar est un site permettant de stocker ces avatars (image qui apparaissent à coté des posts dans les blogs ou dans les forums) et d’y faire l’association avec une adresse e-mail.

Pour profiter de ce nouveau service très Web 2.0, il faut se rendre à l’adresse suivante.

Logo Gravatar

D’abord créer un login.

Après confirmation (par email), il ne reste plus qu’a créer les couples adresse mail / image.

Gravatar exemple

Scoopeo a déjà fait le premier pas et permet à ces utilisateurs d’associer une image Gravatar à leur compte. Il suffit juste d’entrer l’adresse mail.

Sur les blog WordPress, il existe un plugins permettant d’insérer les images Gravatar dans votre blog.

Catégories
Reseau

Tester la performance de votre réseau avec Iperf

Iperf est un des outils indispensable pout tout administrateur réseau qui se respecte. En effet, ce logiciel de mesure de performance réseau, diponible sur de nombreuses plateformes (Linux, BSD, Mac, Windows…), se présente sous la forme d’une ligne de commande à executer sur deux machines disposées aux extrémités du réseau à tester.

Iperf fonctionne comme un client/serveur selon le diagramme suivant:

Iperf

Iperf doit être lancé sur deux machines se trouvant de part et d’autre du réseau à tester. La première machine lance Iperf en « mode serveur » (avec l’option -s), la seconde en « mode client » (option -c). Par défaut le test réseau se fait en utilsant le protocole TCP (mais il est également possible d’utiliser le mode UDP avec l’option -u).

Nous allons commencer par installer iperf en utilisant la commande suivante (sous Fedora):

# yum install iperf

Pour les autres système d »exploitation, vous pouvez vous rendre sur cette page.

Premier exemple d’utilisation

Ensuite, sur une des deux machines de test, nous allon slancer le serveur grâce à la commande suivante:

# iperf -s

Sur le client, il ne reste plus qu’a lancer le client en précisant l’adresse du serveur:

# iperf -c <adresse IP du serveur>

Vous devriez avoir le rapport qui s’affiche après 10 secondes de test.

————————————————————
Client connecting to 192.168.29.1, TCP port 5001
TCP window size: 65.0 KByte (default)
————————————————————
[ 3] local 192.168.29.157 port 50675 connected with 192.168.29.1 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 110 MBytes 92.6 Mbits/sec

Avec les options par défaut, le test est fait en TCP sur une durée de 10 secondes. Sur un réseau local vous devriez donc obtenir un valeur proche de la capacité de commutation de vos équipements (par exemple 92.6 Mbits/sec qui est une valeur proche de 100 Mbits/sec).

Pour afficher des rapports intermédiaires (par exemple toutes les secondes) , il suffit d’ajouter l’option (-i 1) sur le client et/ou le serveur.

# iperf -s -i 1
————————————————————
Server listening on TCP port 5001
TCP window size: 56.0 KByte (default)
————————————————————
[ 6] local 192.168.29.1 port 5001 connected with 192.168.29.157 port 50692
[ 6] 0.0- 1.0 sec 10.1 MBytes 84.8 Mbits/sec
[ 6] 1.0- 2.0 sec 11.1 MBytes 93.0 Mbits/sec
[ 6] 2.0- 3.0 sec 11.2 MBytes 93.8 Mbits/sec
[ 6] 3.0- 4.0 sec 11.2 MBytes 93.9 Mbits/sec
[ 6] 4.0- 5.0 sec 11.2 MBytes 93.9 Mbits/sec
[ 6] 5.0- 6.0 sec 11.2 MBytes 93.8 Mbits/sec
[ 6] 6.0- 7.0 sec 11.2 MBytes 93.9 Mbits/sec
[ 6] 7.0- 8.0 sec 11.2 MBytes 93.8 Mbits/sec
[ 6] 8.0- 9.0 sec 11.2 MBytes 93.9 Mbits/sec
[ 6] 9.0-10.0 sec 11.2 MBytes 93.9 Mbits/sec
[ 6] 0.0-10.0 sec 111 MBytes 92.9 Mbits/sec

Une autre option de base est (-t) qui permet de fixer au niveau du client le temps du test (en secondes). Par exemple pour effectuer un test pendant 1 minute:

# ipert -c <adresse IP du serveur> -t 60

Exemple de test en utilisant le protocole UDP

Iperf permet également de générer un traffic de type UDP (-u). Dans ce cas là, il faut penser à fixer la bande passante cible (contrairement au protocole TCP, UDP ne peut pas faire de contrôle de flux). On utilise pour cela l’argument -b au niveau du client:

Sur le serveur:

# iperf -s -u

Sur le client:

# ipert -c <adresse IP du serveur> -u -b 512k

Ce couple de commandes va générer un test avec un flux réseau UDP de 512 Kbits/sec.

Comme vous pouvez le voir Iperf est également un bon outil de génération de flux. Je l’ai déjà testé pour générer un flux UDP constant pendant plusieurs jours.

Exemple de test en multicast (UDP)

Iperf peut fonctionner en mode multicast (-B). Il faut le lancer de la manière suivante:

Sur le serveur:

# iperf -s -u -B 226.10.11.12

Sur le/les clients:

# iperf -c 226.10.11.12 -u -T 32 -b 512k

Ce couple de commandes génére un flux multicast UDP (sur l’adresse 226.10.11.12, avec un TTL de 32) de 512 Kbits/sec.

Autres options

NOUVEAU: Consultez cet autre article (cliquez ici) pour une description des options avancés de Iperf.

Et bien entendu, il reste la fameuse commande:

# iperf –help

…pour avoir la liste complète des options. Si vous avez des questions, n’hésitez pas !

Sur le même sujet

Pour mes propres besoins, j’ai ecrit un programme nommé SJitter permettant, comme le fait Iperf (c’est à dire sous la forme d’un client/serveur), de mesurer la gigue réseau (ou jitter en anglais). Paramètre très important si vous souhaitez mettre en place de la voie sur IP sur votre réseau.

Catégories
Developpement

Tutoriel CVS

CVS est un logiciel d’aide au développement de logiciel. Il permet le suivi en configuration et le travail en équipe sur un code source (quel que soit le langage utilisé). Nous allons dans ce post voir les différentes commandes de base pour utiliser cet outil.

On part sur l’hypothése ou l’on dispose d’un serveur CVS installé sur la machine cvs.nicolargo.com.

Les commandes qui suivent sont valables dans un environnement Unix (Linux, BSD, Mac) mais également à partir d’un logiciel comme Eclipse (qui permet la gestion de source via CVS).

Connection au serveur CVS

Il faut disposer d’un compte, nicolargo dans notre exemple (ou d’un accès anonymous sur le serveur):

# export CVSROOT= »:pserver:nicolargo@cvs.nicolargo.com:2401/var/cvs-root »
# cvs login
<saisir votre password ici>

Import d’un projet dans le serveur CVS

Une fois connecté au serveur, nous allons y importer un nouveau projet:

# cd <REPERTOIREDUPROJET>
# cvs import -m « Importation initial » <NOMDUPROJET> nicolargo start
# cd ..
# mv <REPERTOIREDUPROJET><REPERTOIREDUPROJET>.old

Export du projet vers un répertoire

C’est ici que vous aller exporter un projet de votre serveur CVS vers votre disque dûr:

# cvs checkout <NOMDUPROJET>
# cd <NOMDUPROJET>

PS: Vous pouvez également effectuer cette action sous Eclipse (File / Import / CVS / Project from CVS / Use existing repository location: :pserver:nicolargo@cvs.nicolargo.com:2401/var/cvs-root / Use an existing module / <NOMDUPROJET>).

Comme vous pouvez le voir en faisant un ls dans votre répertoire, un nouveau sous répertoire a été créé (CVS/). Ce dernier contient toutes les informations nécessaire pour la synchronisation entre votre machine et le serveur.

Mise à jour du projet

La commande suivante permet de mettre vérifier les fichiers locaux par rapport à ceux du serveur:

# cvs update

Appliquer les mises à jour sur votre serveur

Une fois les modifications effectués sur votre code, vous devez les valider et les intégrer à votre serveur grâce à la commande suivante:

# cvs commit -m « Commentaire de mise à jour »

Tagger vos source lors d’une évolution de version

Quand vos modifications sont effectués et « commiter », vous pouvez avoir besoin de signaler au serveur CVS que la version actuelle des fichiers forme la version X.Y de votre projet. On appelle cette opération le taggage:

# cvs tag R1_0

Attention: Le numero de version ne doit pas commencer par un chiffre et ne doit pas comporter de ‘.’.

Extraction des sources

Enfin, si vous souhaitez diffuser vos sources, il faut d’abord les extraires du serveur CVS:

# cvs export -r « TAG » <NOMDUPROJET>

Ou TAG est le numéro de version que vous souhaitez extraire. Cette commande extrait seulement les fichiers utiles (par exemple pas le repertoire CVS).

Et voili, vous pouvez consultez ce post dans le même sujet:
– Création de package GNU

Catégories
Reseau

Monter un répertoire distant en SSH

Je me sers exlusivement du protocole SSH pour administrer mes machines via une console. Ce protocole permet également d’effectuer des transferts de fichiers via le protocole SCP. Cependant, il était jusqu’a maintenant nécessaire d’utiliser un client (scp sous Linux/BSD, WinSCP sur Windows ou Fugu sur Mac). Cette contrainte n’est plus d’actualité depuis l’apparition de Fuse.

« Pour rappel, Fuse (pour Filesystem in Userspace) permet à un utilisateur (non root) de créer son propre système de fichier sans avoir à modifier le noyau du systeme. Il existe par exemple une extension pour accéder à votre compte Gmail comme si celui-ci était un répertoire de votre disque dur (GmailFS). Fuse a de plus le bon goût d’être développé sous licence open-source GPL et LGPL. »

Pour notre besoin, nous allons utiliser le module SSHFS (SSH sur Fuse).

Installation (sur Fedora)

# yum install fuse-sshfs

Utilisation (sur Linux)

La première chose à faire est de créer, sur votre machine cliente, le répertoire dans lequel sera monté le répertoire distant:

# mkdir /mnt/test

Ensuite, on monte le répertoire distant /home/test qui se trouve sur la machine 192.168.0.2:

# sshfs 192.168.0.2:/home/test/ /mnt/test/

On vérifie en faisant un ls dans le répertorie /mnt/test. Il doit afficher le contenu du répertoire distant.

# ls /mnt/test
test.zip

Pour démonter le répertoire distant, il faut taper la commande suivante:

# fusermount -u /mnt/test

Et voila le travail…

Catégories
Reseau

Creation d’un plugins pour Nagios

Nous allons dans ce post écrire un plugins (très simple) pour Nagios. Le corps de ce plugins pourra vous servir de base pour réaliser des plugins plus complexes.

Suite à un post sur l’installation de Nagios, je me suis penché sur l’écriture d’un plugins permettant de vérifier qu’un processus est bien lancé sur un serveur distant.

Voici ce que je l’on attend de notre plugins:

  • Ouvrir une session SSH vers le serveur distant
  • Lancement d’un script vérifiant si un processus (testd) est lancé
  • Renvoie de l’état du processus (OK / ERROR / WARNING)
    • OK: Le processus (testd) est lancé et fonctionne correctement
    • ERROR: Le processus n’est pas lancé
    • WARNING: Le processus est lancé mais ne fonctionne pas correctement

Avant d’entrer dans le vif du sujet, il faut savoir que les plugins Nagios sont de simple « scripts shell » retournant un code de status. Ces plugins sont localisés dans le répertoire /usr/lib/nagios/plugins (sous Linux). Un petit coups de ls donne la liste des plugins installés par défaut:

# ls
check_http check_pgsql check_smtp check_udp2 check_imap check_mysql check_ping check_spop check_udrelay term_power check_clamd check_jabber check_mysql_query check_pop check_ssmtp check_dns check_ldap check_nntp check_scheduler check_tcp check_ftp check_ldaps check_nntps check_simap check_udp …

Nous allons donc dans un premier temps créer le plugins qui va lancer la commande sur le serveur distant:

# vi check_testd
#!/bin/sh

##################################################################
# Creation: Nicolargo
# Last Modification:
# This script checks testd daemon is running on a server
##################################################################

ssh nagios@$1 /usr/local/bin/nagios_testd.pl

Une fois l’automatisation du SSH effectuée entre votre serveur Nagios et votre serveur distant (il ne faut pas que le script demande le password…). Il reste à créer le script nagios_testd.pl (je l’ai developpé en perl mais rien n’empêche de le faire en SH) dans le réperoire /usr/local/bin du serveur distant.

# vi /usr/local/bin/nagios_testd.pl
#!/bin/sh

##################################################################
# Creation: NicoLargo
# Last Modification:
# This script is polling if testd daemon is running
##################################################################

STATE_OK=0
STATE_WARNING=1
STATE_CRITICAL=2
STATE_UNKNOWN=3
STATE_DEPENDENT=4

ps auxw | grep [t]estd | grep -v nagios > /dev/null
STATE=$?
if [ « $STATE » = « $STATE_OK » ]
then
echo « TESTD OK »
exit 0
else
echo « TESTD Failed »
exit $STATE_CRITICAL
fi

Pour tester votre plugins, rien de plus simple, il suffit de lancer la ligne de commande sur votre serveur Nagios:

# /usr/lib/nagios/plugins/check_testd.sh monserveurdistant.mondomaine.com
TESTD OK

Si cela ne fonctionne pas, il faut d’abord vérifier que les fichiers ont les bons droits (lecture et execution) et que le SSH fonctionne correctement entre les deux machines.

Une fois le plugins validé, il ne reste plus qu’a l’intégrer dans vos fichiers de configuration.

# vi /etc/nagios/checkcommands.cfg
…
# ‘check_testd’ command definition
define command{
command_name check_testd
command_line $USER1$/check_testd $HOSTADDRESS$
}
…

et enfin:

# vi /etc/nagios/services.cfg
…
define service{
use generic-service
host_name monserveurdistant.mondomaine.com
service_description TESTD
check_command check_testd
}
…

Voili a+

Catégories
Blog

Plugins indispensables pour WordPress

Ma migration de Blogger vers WordPress m’a permis de regarder de plus près les plugins de WordPress. Il en existe un nombre impressionnant (environ 1300 références sur le site http://wp-plugins.net/).

Voici pour ma part, la liste des plugins que je juge indispensables:

Akismet: Le premier plugins a installer sur son blog quand on autorise les commentaires. C’est en fait un anti-spam qui va vérifier dans une base de donnée si le commentaires n’est pas un spam. Vous avez besoin de générer une clés pour configuer Akismet (WordPress.com API key).

Feedburner Feed Replacement: Si comme moi vous hébergé votre flux RSS chez Feedbuner, ce plugins vous permet de rediriger automatiquement tout vos flux vers eux.

Google Analyticator: Si vous utilisé le service Analyticator de Google, ce plugins insére pour vous automatiquement le script nécessaire.

Google Sitemaps: Ce plugins permet de générer un fichier sitemap.xml pour le moteur de recherche Google (via http://www.google.com/webmasters/tools/).

Lightbox JS v2.2 Plugin: Permet de visualiser les images de votre blog de manière sympatique 😉 (voir exemple sur cette page). Il suffit d’ajouter le tag suivant rel= »lightbox[roadtrip] » dans le lien de votre image (ou le tag rel= »lightbox » dans les autres liens).

SEO Title Tag: Modifie les meta-tags des article pour un meilleur référencement.

Sidebar Widgets: Ajoute une fonction de Widget (a déplacer) dans votre menu (side bar) WordPress. Ce plugins ajoute une nouvelle option au menu « Presentation ».

Sociable: Ajoute en bas des posts des liens vers les sites de social blogging (comme Dig, Technorati…).

Subscribe To Comments: Permet a un lecteur de suivre le fil d’une discussion en s’abonnant aux commentaires sur un post.

Ultimate Tag Warrior: LE plugins pour gérer vos tags.

Voili, il doit y en avoir plein d’autres mais je débute en WordPress. A vous de me dire si je passe à coté de best-of !

Catégories
Blog

Nouvelle addresse, même flux

L’adresse du blog a changé:

blog.nicolargo.com

Merci de mettre à jour vos racourcis / liens.

L’adresse du flux RSS reste la même:

http://feeds.feedburner.com/LeBlogDeNicolargo

A+

Catégories
Open-source

L’open-source un cancer communiste ?

Après avoir dit par l’intermédiaire de son architecte système (j’ai nommé Bill Gates) que le fait de restreindre la propriété intelectuelle s’apparantait à du communisme (voir article ici), c’est son président directeur général (Steve Ballmer) qui enfonce le clou en laissant trainer dans une des phrases d’un interview que « linux est un cancer ». La dernière attaque en date du clan Microsoft sur le monde open-source vient du fait qu’il l’accuse d’utiliser des codes protégés par des brevets.

Légerement irrité, la communauté open-source a décider de demander des éclaircissements à Microsoft via un lettre ouverte dont le titre est: « Montrez-nous le code » (ShowUsTheCode.com).

Que penser de tout ca ? Pour ma part j’y vois comme une montée en puissance de l’open-source (on attaque que lorsque l’on se sent menacé…) ou une baisse de l’importance de Microsoft dans le monde de l’informatique…