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
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.

Catégories
Open-source Systeme

Graver des fichiers au format .IMG

Si vous avez besoin (comme moi ce matin) de graver sur une CD ou un DVD une image disque au format .IMG (UDF filesystem data) en utilisant votre PC sous Ubuntu, alors la petite procédure suivante devrait vous intéresser.

Installation des logiciels

Nous allons utiliser les utilitaires UDF:

# sudo apt-get install udftools

Utilisation du logiciel pour graver un .IMG sur un DVD

Supposons que l’on veuille graver l’image disque stockée dans le fichier /tmp/image.img

Il faut pour cela saisir la commande suivante (après avoir inséré un DVD vierge dans votre garveur de DVD…):

# growisofs -Z /dev/dvd=/tmp/image.img

Et voili

Catégories
Open-source

Actualité open-source de la semaine #52

L’actualité open-source de la semaine…

L’image de la semaine


Lenny is here…

Tout le monde en parle, sauf moi…

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

  • Debian Lenny (Debian 5) est (enfin) sortie en version stable
  • Le prochain Ubuntu (9.04), 20% plus rapide… enfin presque…
  • Red Hat et Microsoft font copain/copain
  • Microsoft Windows 7 va prochainement sortir en RC, j’ai comme l’impression qu’ils veulent vite oublier Vista 🙂
  • Wine, l’émulateur Windows pour Linux et Mac OS X passe en version 1.1.15

Autres choses ?