Catégories
Systeme

Automatiser la synchronisation iSync

Vous avez un Mac et un téléphone portable ? Vous connaissez alors surêment le logiciel iSync qui permet de synchroniser vos contacts et calendriers.

Il manque cependant une fonction importante à ce petit logiciel: la possibilité d’automatiser cette synchronisation. En attendant qu’Apple ajoute cette fonction à iSync (et oui c’est ça le problème avec les logiciels propriétaires, il faut attendre :(), voici un petit hack qui va fonctionellement nous rendre le même service.

Nous allons pour cela utiliser un AppleScript. Il faut éditer un fichier nommé SyncNow.scpt  dans le répertoire ~/Library/Scripts/ et contenant le code suivant:

tell application « Finder »
set iSyncRunning to 1
tell application « iSync » to synchronize
tell application « iSync »
repeat while (syncing is true)
delay 5
end repeat
if iSyncRunning is not true then
quit
end if
end tell
end tell

Ce script va ouvrir iSync, lancer un synchronisation, puis fermer iSync. Si le téléphone n’est pas à porté de Bluetooth, le script boucle jusqu’à ce que la synchronisation soit faite.

Vous pouvez tester le bon fonctionnement de ce script en ouvrant un terminal et en saisissant la commande suivante:

~/Library/Scripts/SyncNow.scpt

Afin d’automatiser le lancement de ce script, nous allons utiliser crontab (venu du monde unix). Elle permet de lancer une commande à une heure précise. Il faut ouvrir un terminal, puis saisir:

crontab -e

Vous allez vous retrouver dans l’éditeur « vi ». Pour ajouter la ligne suivante, il faut au préalable cliquer sur la touche i.

0 11 * * 1-5 osascript Library/Scripts/SyncNow.scpt

Pour sortir de l’éditeur vi, il faut appuyer successivement sur les touche ESC ensuite : puis x et enfin ENTREE.

Et voilà, tout les matin à 11h00 (0 11), du lundi au vendredi (1-5), le script sera lancé et la synchronisation effectué !

Catégories
Open-source

Question à deux balles… quoi que…

En discutant ce midi lors d’un groupe de travail open-source, j’ai entendu la question suivante:

« Un logiciel sous licence libre contaminante (GPL par exemple) est récupéré par une société. Celle-ci traduit le logiciel dans un autre langage de programmation et le diffuse sous une licence propriétaire.

Quel point de la licence libre permet à l’auteur initial de ce logiciel de se retourner contre la société ? ».

J’avoue que je suis resté un peu sec sur la réponse…

D’après vous quels sont les arguments en faveur du logiciel libre dans ce cas précis ? 

Catégories
Open-source Reseau

Simuler un lien WAN sous Linux

Il peut être utile, dans le cadre de tests applicatifs, de simuler sur votre réseau local (LAN), les caractéristiques d’une liaison distante (WAN). En effet, vos applications peuvent très bien fonctionner sur un réseau LAN et devenir inexploitable sur des liaisons WAN.

Nous allons utiliser le module Net:Netem des noyaux Linux 2.6 pour simuler les caractéristiques suivantes:

  • Bande passante
  • Délai de transit
  • Perte de paquet
  • Duplication de paquet
  • Re-arrangement de paquet

La configuration de ce module se fait via la commande en ligne tc.

Simuler un délai de transit constant

Le délai est le temps de transit réseau d’un paquet IP. Il dépend de pas mal de paramètres (traversé des équipements, taille des buffers et distance physique entre les deux points du réseau). Nous allons utiliser la commande delay qui va simuler un délai de transit de X ms sur tout les paquets IP sortant de l’interface réseau. On va utiliser la commande « ping » pour vérifier que tout fonctionne comme prévu.

Test du réseau avant la commande tc:

$ ping 192.168.29.1
PING 192.168.29.1 (192.168.29.1) 56(84) bytes of data.
64 bytes from 192.168.29.1: icmp_seq=1 ttl=64 time=0.290 ms
64 bytes from 192.168.29.1: icmp_seq=2 ttl=64 time=0.204 ms

On simule un délai de 40 ms sur tout les paquets sortant (soit environ le délais sur une liaison ADSL):

sudo tc qdisc add dev eth0 root netem delay 40ms

Test du réseau après la commande tc:

$ ping 192.168.29.1
PING 192.168.29.1 (192.168.29.1) 56(84) bytes of data.
64 bytes from 192.168.29.1: icmp_seq=1 ttl=64 time=40 ms
64 bytes from 192.168.29.1: icmp_seq=2 ttl=64 time=40 ms

Pour revenir à la configuration initiale (sans simulateur), on utilise la commande suivante:

sudo tc qdisc del dev eth0 root

On vérifie que l’on retombe bien sur les caractéristiques normale du réseau:

$ ping 192.168.29.1
PING 192.168.29.1 (192.168.29.1) 56(84) bytes of data.
64 bytes from 192.168.29.1: icmp_seq=1 ttl=64 time=0.218 ms
64 bytes from 192.168.29.1: icmp_seq=2 ttl=64 time=0.209 ms

Simuler un délai de transit « normal »

Sur un réseau WAN, le délai de transit n’est jamais constant à travers le temps (surtout pour des liaisons de type Internet). Nous allons donc modifier la commande précédente pour intégrer une variation de délai (gigue de +/- 10ms) sur les paquets sortant:

sudo tc qdisc add dev eth0 root netem delay 40ms 10ms distribution normal

On obtient les caractéristiques suivantes:

$ ping 192.168.29.1PING 192.168.29.1 (192.168.29.1) 56(84) bytes of data.
64 bytes from 192.168.29.1: icmp_seq=1 ttl=64 time=36.9 ms
64 bytes from 192.168.29.1: icmp_seq=2 ttl=64 time=50.5 ms
64 bytes from 192.168.29.1: icmp_seq=3 ttl=64 time=33.1 ms
64 bytes from 192.168.29.1: icmp_seq=4 ttl=64 time=43.1 ms
64 bytes from 192.168.29.1: icmp_seq=5 ttl=64 time=32.5 ms
64 bytes from 192.168.29.1: icmp_seq=6 ttl=64 time=23.6 ms

Pour revenir à la configuration initiale (sans simulateur), on utilise la commande suivante:

sudo tc qdisc del dev eth0 root

Simuler une bande passante limite

Cette fonction ne fait pas partie de Netem mais utilise tout de même la commande tc pour se configurer.

Avant de commencer nous allons tester la capacité de notre réseau LAN avec la commande IPerf (à lancer en mode serveur UDP sur votre machine cible, 192.168.29.1 dans mon cas):

$ iperf -c 192.168.29.1 -u -b 10M
————————————————————
Client connecting to 192.168.29.1, UDP port 5001
Sending 1470 byte datagrams
UDP buffer size:   110 KByte (default)
————————————————————
[  3] local 192.168.29.222 port 47532 connected with 192.168.29.1 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  11.9 MBytes  10.0 Mbits/sec
[  3] Sent 8505 datagrams
[  3] Server Report:
[ ID] Interval       Transfer     Bandwidth       Jitter   Lost/Total Datagrams
[  3]  0.0-10.0 sec  11.9 MBytes  10.0 Mbits/sec 0.008 ms    0/ 8505 (0%)

On a donc bien un débit de 10 Mbps.

On commence par créer la racine de l’arbre des classes (avec une simulation de délai « normal » de 40ms):

sudo tc qdisc add dev eth0 root handle 1:0 netem delay 40ms 10ms distribution normal

Puis on y ajoute un « tuyau » limitant le trafic sortant à 512 Kbps:

sudo tc qdisc add dev eth0 parent 1:1 handle 10: tbf rate 512kbit buffer 3200 limit 6000

On re-teste notre réseau:

$ iperf -c 192.168.29.1 -u -b 10M
————————————————————
Client connecting to 192.168.29.1, UDP port 5001
Sending 1470 byte datagrams
UDP buffer size:   110 KByte (default)
————————————————————
[  3] local 192.168.29.222 port 57589 connected with 192.168.29.1 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  11.9 MBytes  10.0 Mbits/sec
[  3] Sent 8505 datagrams
[  3] Server Report:
[ ID] Interval       Transfer     Bandwidth       Jitter   Lost/Total Datagrams
[  3]  0.0-10.3 sec    609 KBytes    486 Kbits/sec 14.351 ms 8081/ 8505 (95%)

On arrive bien à limiter le débit réseau sortant à 500 Kbps (un peu moins pour mon test).

Pour revenir à la configuration initiale (sans simulateur), on utilise la commande suivante:

sudo tc qdisc del dev eth0 root

Simuler une perte de paquets

La perte de paquets (ou « packet loss » dans la langue de Shakespeare) peut être simulé par Netem par la commande loss. Dans l’exemple suivant, nous allons simuler un lien WAN avec une perte de 0.1% des paquets sortant (soit 1 paquet perdu sur 1000 envoyé) avec un corrélation de 25% sur la probabilité que 2 paquets soit perdu de suite.

sudo tc qdisc add dev eth0 root netem loss 0.1% 25%

Pour revenir à la configuration initiale (sans simulateur), on utilise la commande suivante:

sudo tc qdisc del dev eth0 root

Simuler d’autres paramètres réseau

Il est également possible de simuler la duplication de paquets (commande duplicate), la corruption de paquets (commande corrupt) et le re-arrangement des paquets (commande gap).

Simuler également les paquets entrants

Imaginons que l’on veuille simuler une liaison de type ADSL, cette liaison est asymétrique en terme de débit. Il faut donc pouvoir simuler de manière différente le débit entrant (DOWNLOAD) du débit sortant (UPLOAD). Pour cela, il faut passer par la déclaration d’une interface réseau virtuelle (ifb) dans laquelle nous allons re-router les paquets entrants. Nous appliquerons nos paramètres réseau de simulation sur cette nouvelle interface.

Commençons par créer cette interface virtuelle:

# modprobe ifb
# ip link set dev ifb0 up
# tc qdisc add dev eth0 ingress
# tc filter add dev eth0 parent ffff: protocol ip u32 match u32 0 0 flowid 1:1 action mirred egress redirect dev ifb0

Puis appliquons un délai de 40ms comme vu dans le chapitre précédant:

# tc qdisc add dev ifb0 root netem delay 40ms 10ms distribution normal

Un exemple complet: simulation d’une liaison ADSL

Voici un script Shell (bash) permettant de mettre en place une simulation de type liaison ADSL sur votre réseau local:

#!/bin/bash
#
# limitbw.sh
# Nicolargo – 2009
#

# Nom de l’interface ou l’on doit faire la simulation
IF=eth0

# Liaison sortante (UPLOAD)

# Debit sortant
BWU=768kbit
# Délai de transit sortant
DELAYU=20ms
# % de paquets perdus sortant
LOSSU=0.01%

# Liaison entrante (DOWNLOAD)

# Debit entrant
BWD=2mbit
# Délai de transit entrant
DELAYD=20ms
# % de paquets perdus entrant
LOSSD=0.01%

start() {

# Liaison entrante

modprobe ifb
ip link set dev ifb0 up
tc qdisc add dev $IF ingress
tc filter add dev $IF parent ffff: \
protocol ip u32 match u32 0 0 flowid 1:1 \
action mirred egress redirect dev ifb0

tc qdisc add dev ifb0 root handle 1:0 \
netem delay $DELAYD 10ms distribution normal \
loss $LOSSD 25%
tc qdisc add dev ifb0 parent 1:1 handle 10: \
tbf rate $BWD buffer 3200 limit 6000

# Liaison sortante

tc qdisc add dev $IF root handle 2:0 \
netem delay $DELAYU 10ms distribution normal \
loss $LOSSU 25%
tc qdisc add dev $IF parent 2:1 handle 10: \
tbf rate $BWU buffer 3200 limit 6000

}

stop() {

tc qdisc del dev ifb0 root

tc qdisc del dev $IF root

# ip link set dev ifb0 down

}

restart() {

stop
sleep 1
start

}

show() {

echo « Liaison entrante »

tc -s qdisc ls dev ifb0

echo « Liaison sortante »

tc -s qdisc ls dev $IF

}

case « $1 » in

start)

echo -n « Starting WAN simul:  »
start
echo « done »
;;

stop)

echo -n « Stopping WAN simul:  »
stop
echo « done »
;;

restart)

echo -n « Restarting WAN simul:  »
restart
echo « done »
;;

show)

echo « WAN simul status for $IF: »
show
echo «  »
;;

*)

echo « Usage: $0 {start|stop|restart|show} »
;;

esac

exit 0

Bonne simulation 😉

Catégories
Open-source Systeme

Création d’un script de démarrage sous Linux

Dans cet article nous allons voir comment automatiser le démarrage d’un service ainsi que son arrêt sur un système GNU/Linux (plus particulièrement sur une distribution Ubuntu 8.04 Server).

A titre d’exemple, nous allons voir comment lancer un portail Liferay au démarrage de la machine, et comment l’arrêter proprement lors d’un reboot ou d’un shutdown.

Création du script

Nous allons donc créer un script nommé ‘liferay‘ que l’on va placer dans le répertoire /etc/init.d .

#!/bin/sh

# le nom du service
SERVICE_NAME=Liferay
# le répertoire où se trouvent les exécutables du service
SERVICE_DIRECTORY=/opt/Portal/bin
# le nom du script de démarrage du service
SERVICE_STARTUP_SCRIPT=startup.sh
# le nom du script d'arrêt du service
SERVICE_SHUTDOWN_SCRIPT=shutdown.sh

usage()
{
        echo "-----------------------"
        echo "Usage: $0 (stop|start|restart)"
        echo "-----------------------"
}

if [ -z $1 ]; then
        usage
fi

service_start()
{
        echo "Starting service '${SERVICE_NAME}'..."
        OWD=`pwd`
        cd ${SERVICE_DIRECTORY} && ./${SERVICE_STARTUP_SCRIPT}
        cd $OWD
        echo "Service '${SERVICE_NAME}' started successfully"
}

service_stop()
{
        echo "Stopping service '${SERVICE_NAME}'..."
        OWD=`pwd`
        cd ${SERVICE_DIRECTORY} && ./${SERVICE_SHUTDOWN_SCRIPT}
        cd $OWD
        echo "Service '${SERVICE_NAME}' stopped"
}

case $1 in
        stop)
                service_stop
        ;;
        start)
                service_start
        ;;
        restart)
                service_stop
                service_start
        ;;
        *)
                usage
esac
exit 0

Maintenant, il faut donner les permissions d’exécution sur ce script

# chmod a+x /etc/init.d/liferay

Automatisation

Maintenant que le script est créé, il ne reste plus qu’à faire en sorte que le service se lance au démarrage de la machine et qu’il se stoppe à l’arrêt de celle-ci. Le runlevel qui nous intéresse ici est le numéro 2, mais on peut appliquer cette configuration pour les autres.

Il existe 2 méthodes pour procéder: la première consiste à créer des liens symboliques à la main dans le répertoire /etc/rc2.d en respectant les conventions de nommage, et la seconde (plus simple), consiste à utiliser la commande update-rc.d (c’est cette méthode que nous allons utiliser).

Avant tout chose, il faut déterminer le moment exact où le script s’exécutera:

  • Démarrage du service
    Le service liferay doit se lancer une fois que le serveur de base de données est démarré (en l’occurrence, il s’agit de MySQL).
    En regardant dans le répertoire /etc/rc2.d, on voit que le service mysql démarre à la position 19 (ce numéro peut changer suivant les configurations), donc nous allons démarrer le service liferay à la position 20.
  • Arrêt du service
    Le service liferay doit s’arrêter avant que le serveur de base de données ne s’arrête.
    En regardant dans le répertoire /etc/rc6.d (le runlevel 6 est consacré à l’arrêt de la machine), on voit que le service mysql s’arrête en position 18. Nous allons donc arrêter le service liferay en position 17.

Voici donc la commande qui permet de configurer le service comme décrit précédemment:

# update-rc.d liferay start 20 2 . stop 17 6 .

Désactiver un service

Pour désactiver le lancement automatique d’un service au démarrage, il existe 3 possibilités:

  • utiliser la commande update-rc.d
    # update-rc.d -f liferay remove
  • supprimer le lien symbolique du répertoire /etc/rcX.d (où X représente le numéro de runlevel désiré)
  • retirer les permissions d’exécution sur le script situé dans le répertoire /etc/init.d

Pour plus d’infos, consulter la documentation de la commande update-rc.d.

Catégories
Developpement Open-source Systeme

Installation de Java 1.6 sous Debian et Ubuntu

Si comme moi vous devez faire tourner des applications seulement compatible avec Java 6 (c’est à dire Java 1.6) sur vos machines Debian et Ubuntu, et que vous n'avez pas de masters java en poche, la petite procédure suivante devrait vous être utile. En effet, ces deux distributions sont, à l’heure de l’écriture de ce billet, livré par défaut avec la version 1.5. Nous allons voir comment installer la JDK de Sun et la faire prendre par défaut par le système.

Installation de Sun Java 1.6

Pour installer la JRE (seulement pour l’exécution de programme Java):

sudo apt-get install  sun-java6-jre

Pour installer et compiler (bref pour les developpeurs):

sudo apt-get install sun-java6-sdk

Pour rendre Sun Java 1.6, la JVM par défaut

La commande est la même sur les deux distributions (Ubuntu et Debian):

sudo update-alternatives –config java

> Puis choisir /usr/lib/jvm/java-6-sun/jre/bin/java

On vérifie que tout est ok:

# java -version

java version « 1.6.0_12″

Et voili…

Catégories
Open-source Reseau

Outil pour la mesure de la QoS sur les réseaux IP

La qualité de service (QoS pour « Quality of service ») est la capacité à véhiculer dans de bonnes conditions un type de trafic donné en termes de disponibilité, débit, délai de transmission, gigue, taux de perte de paquets… (source Wiki)

La notion de qualité de service est une notion subjective, de ressenti utilisateur face à l’utilisation d’un système informatique. Il n’est pas trivial de mesurer cette QoS. Nous allons dans ce billet aborder quelques outils libres permettant d’obtenir des indicateurs chiffrés en nous focalisant sur la problématique des réseaux IP.

Ou faire les mesures ?

Première question à se poser quand on doit faire ce genre de mesure. La réponse dépend bien sûr de votre architecture. Souvent, l’on souhaite vérifier la QoS sur une liaison WAN( par exemple un liaison de type _DSL vers votre FAI). Dans ce cas précis, la mesure pourra être faite sur votre routeur d’accès, c’est à dire juste avant la liaison. En effet, celà permet de prendre en compte tous les flux de votre réseau. Il faut pour celà disposer d’un routeur d’accès sur lequel on peut installer les outils de mesures (par exemple un routeur/firewall basé sous Linux ou FreeBSD). Si ce n’est pas le cas, il est toujours possible de mettre un PC (sous Linux) en coupure entre votre switch réseau et votre routeur/modem.

Quoi mesurer ?

Pour un réseau en fonctionnement (c’est à dire que l’on écarte la disponibilité), on peut distinguer quatres grandes variables:

  • le débit: c’est la bande passante utilisé par un flux. Celle-ci peut être constante ou variable.
  • le délai de transit des paquets IP: dans un réseau IP, les données sont segmentées en paquets. Le délai de transit est le temps mis par uhn paquet pour aller d’un point A vers un point B.
  • la gigue dans un flux de paquets IP: c’est la variation du délai de transit entre plusieurs paquets IP. Ce paramètre est très important pour les applications de voix sur IP (VoIP) car les codecs de compression de la voix sont très sensibles à la gigue.
  • la perte de paquets: c’est le pourcentage de paquets IP perdus sur le réseau.

Comment tester ?

Plusieurs solutions sont possibles. La première consiste à utiliser les logiciels qu l’on souhaites tester sur son réseau. On peut le faire de manière manuelle ou automatique (via des scripts par exemple). L’important est de générer des flux qui soient représentatifs de l’utilisation standard de votre réseau.

Une autre solution est de simuler les flux à l’aide d’un outil comme Iperf qui est capable de générer un flux IP finement paramètrable sur le réseau. Par finement on entend:

  • Protocole: UDP, TCP, ICMP…
  • Port réseau
  • Taille des paquets de données
  • Débit
  • Temps
  • Tag du champ DSCP (dans le cadre d’un réseau compatible Diffserv)

Pour vous aider dans l’utilisation de ce logiciel, vous pouvez lire les billets suivants:

Comment mesurer ?

Iperf permet de générer en sortie un rapport sur quelques uns de ces paramètres, notamment le débit (moyen, minimum et maximum) et le délai. L’idée générale et de faire un plan de test avec les différentes configurations possible en terme d’utilisation et de QoS et de regarder les valeurs obtenues en sorties. En complément de Iperf, vous pouvez utiliser SJitter pour la mesure de la gigue réseau.

En complément de IPerf, il peut être utile d’utiliser un logiciel de capture réseau tel que Wireshark. En effet, grâce à ce dernier, vous pouvez sauvegarder les flux et les filter/analyser avec les nombreux modules disponibles.

Voici un tableau, basée sur mon expérience personnelle, des valeurs à prendre en compte lors de vos mesures.


Et vous quel est votre expérience sur le sujet ? Utiliser vous d’autres logiciels libres pour mesurer les performances de votre réseau ?

Catégories
Blog

Blog en pause

Depuis cette nuit, je suis papa pour une deuxième fois ! Je vais donc avoir « un peu » moins de temps à consacrer au blog et au forum dans les prochaines semaines. Je ne doute pas que certains lecteurs actifs feront vivre le forum pendant mon absence.

Restez quand même en ligne !

Catégories
Open-source

Actualité open-source de la semaine #53

L’actualité open-source de la semaine…

L’image de la semaine

HADOPI - Le Net en France : black-out

HADOPI c’est pas bien… un bien beau buzz

Tout le monde en parle, sauf moi…

L’actualité du libre et de l’open source en vrac:

Autres choses ?

Catégories
Uncategorized

Noir c’est noir…

Le blog de Nicolargo soutient le mouvement contre le projet de loi HADOPI.

HADOPI - Le Net en France : black-out
Catégories
Open-source Systeme

Installation des drivers nVidia sous Debian 5.0

En attendant que nVidia ne libére le code de ses drivers, il est nécessaire de faire quelques manipulations pour les installer sur des systèmes d’exploitation de type GNU/Linux.

Les drivers des cartes graphiques nVidia n’étant pas inclus dans les paquets par défaut dans la dernière version de Debian 5.0 (Lenny), il est nécessaire d’effectuer quelques manipulation en ligne de commande pour les installer sur votre système.

J’ai choisi une solution permettant de ne pas à avoir à réinstaller les drivers à chaque mise à jour du noyau de Debian.

Toutes les actions suivantes doivent être faites en mode root:

# su – root

Installation des dépôts

La première chose à faire est d’ajouter les lignes suivantes à votre fichiers listant les dépôts APT:

# vi /etc/apt/sources.list

deb http://ftp.fr.debian.org/debian/ lenny main contrib non-free
deb-src http://ftp.fr.debian.org/debian/ lenny main contrib non-free

deb http://security.debian.org/ lenny/updates main contrib non-free
deb-src http://security.debian.org/ lenny/updates main contrib non-free

deb http://www.debian-multimedia.org lenny main contrib non-free
deb-src http://www.debian-multimedia.org lenny main contrib non-free

On met à jour le système:

# apt-get update

# apt-get upgrade

Installation des paquets nécessaires

Deux paquets sont nécessaires:

# apt-get install nvidia-kernel-common

# apt-get install module-assistant

Lors de l’installation, de nombreux autres paquets dépendants vont être installés.

Activation des drivers nVidia

On doit maintenant activer les drivers proprétaires avec la commande suivante:

# module-assistant auto-install nvidia

Puis vérifier qu’ils se charge bien:

# modprobe nvidia

# lsmod | grep nvidia
nvidia

Il ne reste plus qu’a les ajouter à votre configuration de Xorg:

# vi /etc/X11/xorg.conf

Section « Device »
Identifier    « Configured Video Device »
Driver        « nvidia »
Option        « NoLogo »    « True »
EndSection

Vous pouvez maintenant redémarrer votre système.

# reboot

Les drivers nVidia devraient être chargé automatiquement.