Auteur/autrice : nicolargo

Créateur de blog de Nicolargo, je suis un partisan des logiciels libres et un passionné des nouvelles technologies.

Catégories
Developpement Open-source Planet-libre Systeme

Présentation des nouveautés de Glances 1.7

De retour de congés avec dans ma besace une nouvelle version de Glances qui sera la dernière version majeure de la série 1.x. La prochaine version sera donc une 2.x avec notamment un gros travail initial de refactoring/découpage du code en modules car le script initial atteint une taille critique (plus de 4400 lignes) qui commence à le rendre difficilement évolutif.

Mais revenons donc à nos moutons pour parler de cette version de Glances 1.7:

screenshot Glances 1.7

Un peu d’histoire

Pour ceux d’entre vous qui découvrent Glances dans ce billet, c’est un projet que j’ai lancé maintenant il y a 2 ans pour palier à un manque dans les outils de supervision système. En effet, j’utilisais tout un tas de logiciels (netstat, top, ntop, ifstat, dstat…) pour investiguer les éventuels problèmes de performance sur un système d’exploitation. Mais aucun ne permettait une visualisation simple (via un terminal par une connexion SSH) et rapide (sur un seul écran) des statistiques nécessaires. Glances était née.

Cette version apporte, en plus de son lot de corrections de bugs, d’améliorations des performances et de la documentation de nouvelles fonctionnalité que nous allons détailler ensemble

Les « Monitored Processes List »

L’objectif qui se cache derrière cette nouvelle fonction est de pouvoir, en un clin d’oeil, voir l’état d’un ensemble de processus regroupés ensemble sous une même thématique.

Par exemple, sur un machine hébergeant un serveur Web dynamique, la supervision des processus « importants » peut se découper de la manière suivante:

  • Serveur Nginx: processus NGinx
  • Serveur PHP: processus PHP-FPM
  • Serveur de caching des pages: processus Varnish
  • Serveur de base de données: processus MySQL
  • Serveur de caching des objets: processus Memcached

On a donc 5 objets à superviser. Dans Glances, la définition de ces objets est faite via le fichier de configuration glances.conf. Chaque objet est défini par:

  • description: description des processus (au maximum 16 caractères, exemple: Serveur Web Nginx)
  • regex: expression régulière permettant de regrouper les processus dans l’objet (exemple: .*nginx.*)

et optionnellement par:

  • command: chemin complet vers un script qui sera executé par Glances à chaque rafraichissement (donc toutes les 3 secondes par défaut) et qui devra retourner une chaine de caractère d’une seule et unique ligne contenant des informations utiles pour cet objet. Attention à ne pas utiliser un script trop consommateur de ressources ou bien d’augmenter le temps de rafraichissement (option -t <secondes>)
  • countmin: nombre minimal de processus attendus. Un message de warning sera affiché si le nombre de processus passe en dessous de cette valeur.
  • countmax: nombre maximal de processus attendus. Un message de warning sera affiché si le nombre de processus passe en dessus de cette valeur.

Note: par défaut, Glances par sur le principe ou le groupe ne contient qu’un seul processus (donc countmin = countmax = 1)

Ainsi, la configuration de l’objet n°1 (on peut définir jusqu’à 10 objets) correspondant au serveur Web Nginx est donc la suivante:

[monitor]
list_1_description=Serveur Web Nginx
list_1_regex=.*nginx.*
list_1_command=nginx -v
list_1_countmin=1
list_1_countmax=4

Dans Glances, l’affichage des objets se fait de la manière suivante:

monitored

La couleur détermine l’état de l’objet. Si le nombre de processus:

  • est compris entre countmin et countmax alors Glances affichera l’objet en vert (état OK)
  • est différent de 0 mais non compris entre countmin et countmax alors Glances affichera l’objet en orange (état WARNING)
  • est égal à 0 alors Glances affichera l’objet en rouge (état CRITICAL)

Comme pour toutes les autres statistiques importantes de Glances, le changement des états est logué.

En mode client/serveur la liste des items est défini au niveau serveur. Une nouvelle entrée dans l’API permet au client de récupérer la liste sur le serveur.

Supervision de la température des disques

Sur certain système, notamment les NAS, la température des disques est un critére important à surveiller. En partant de ce postulat, MendelGusmao a développé un module optionnel (activable en passant l’option -y au lancement de Glances) permettant d’aller récupérer la température des disques sur le daemon HDDTemp qui doit être lancé sur votre machine (voir ici les instructions d’installation de HDDTemp sur Debian/Ubuntu).

Sur ma machine (qui ne comporte qu’un seul disque dur), j’obtiens l’affichage suivant:

hddtemp

Il est bien sûr possible de définir les seuils d’alertes dans la section [hddtemperature] du fichier de configuration de Glances. Les valeurs par défaut sont: CAREFUL=45 / WARNING = 52 / CRITICAL = 60 (en ° celcus).

Information sur l’état de charge de la batterie

J’ai reçu plusieurs demandes d’utilisateur de Glances souhaitant superviser la capacité de la batterie (notamment dans le cas d’utilisation de nano PC autonomes). Premier problème, PsUtil ne remonte pas ce genre de statistiques (du moins dans la version actuelle 1.0). Après une rapide et non exhaustive recherche sur le net d’une bibliothéque Python permettant d’obtenir simplement les informations disponibles sur les systèmes Linux j’ai du me résoudre à coder moi même quelque chose. C’est donc ainsi que Batinfo est apparu il y a quelques semaines.

L’intégration de la librairie Batinfo a été ensuite une formalité et Glances propose donc, si une ou plusieurs batteries sont détectés, l’affichage du pourcentage de capacité restante au milieu du footer:

battery

Limitation: cette statistique est uniquement disponible sur les systèmes Linux.

Une option pour un Glances « low CPU »

Le traitement de la liste comprenant les processus est un des facteur principaux de la consommation CPU de Glances. Sur certain système (notamment les nanos PC comme les Raspberry Pi), il est conseillé de réduire le taux de rafraichissement des statistiques pour faire baisser cette consommation CPU. Cependant, si vous avez besoin d’un taux de rafraichissement important sans avoir besoin du détail des processus alors l’option -r codé par J.Renner est faite pour vous. En lançant Glances avec l’option -r, vous allez désactiver tout les traitements des processus (liste dynamique, monitored process list…) et ainsi disposer d’un Glances faiblement consommateur de CPU.

Sur ma machine de développement, l’utilisation de cette option fait passer la consommation CPU de 2.9% à 0.3%.

Détail de la CPU au lancement de Glances

Une version précédante de Glances voyait apparaître une option (activable en appuyant sur la touche ‘1’ dans Glances) permettatn d’afficher le détail de la CPU par coeur et non plus globalement. Une nouvelle option sur la ligne de commande (-1) permet de lancer par défaut ce mode d’affichage.

per-cpu

IPv6

Enfin un vrai support IPv6 pour le mode client serveur de Glances.

A tester simplement et localement avec:

glances -s -B ::0

pour lancer le serveur en mode IPv6 avec un bind sur toutes les interfaces.

Puis ensuite on lance le client sur le localhost IPv6:

glances -c ::1

Et puis…

Quelques autre petites nouveautés:

  • Platform/architecture is more specific now
  • Add support for local conf file
  • Add a uninstall script
  • Add getNetTimeSinceLastUpdate() getDiskTimeSinceLastUpdate() and getProcessDiskTimeSinceLastUpdate() in the API
  • Add more translation: Italien, Chinese

Conclusion

Tout d’abord un grand merci aux principaux contributeurs de cette nouvelle version:

Ensuite, je compte sur vous pour tester cette nouvelle version qui est dès à présent disponible sous Pypi (les packages Debian, BSD, Windows et Mac ne devrait pas trop tarder).

Installation et mise à jour de Glances 1.7

Si vous avez installé Glances via Pypi (ce que je conseille), une mise à jour peut se faire simplement via la ligne de commande:

sudo pip install --upgrade Glances

Pour une installation toute fraîche (pour les nouveaux venus ayant les droits root):

sudo pip install Glances

ou la commande équivalente pour une installation locale (pour les nouveaux venus sans les droits root):

pip install --user Glances

Si vous préférerez utiliser les packages Debian/Ubuntu, Windows et Mac OS, il va falloir attendre un peu que mes « packagers » attitrés bossent un peu.

J’attend vos retours sur les commentaires suivants ou vos retour de bug/demande d’amélioration sur le site du dépôt officiel.

Catégories
Open-source Planet-libre raspberry

Support de présentation SophiaConf 2013 – Raspberry Pi

Pas trop le temps de bloguer en ce moment entre le boulot, le développement de la prochaine version de Glances et… la préparation de la conf de présentation du Raspberry Pi que j’ai faite jeudi dernier dans le cadre des SophiaConf 2013.

Voici donc le support de présentation que j’ai utilisé et qui est bien sûr ré-utilisable comme tout ce que je publie sur ce site (licence CC BY 3.0).

Elle est disponible à partir de ce lien ou en cliquant sur l’image ci-dessous (j’ai utilisé le framework de présentation Shower).

Raspberry - SophiaCOnf 2013

Pour avoir une version PDF, il suffit d’ouvrir la présentation dans votre navigateur Web et de faire imprimer vers PDF !

Catégories
Developpement Open-source Planet-libre Systeme

BatInfo, une lib Python pour vos batteries

Je souhaitais ajouter dans Glances un plugin permettant de superviser l’état des batteries. J’ai donc commencé à chercher une librairie Python permettant de s’acquiter le plus simplement possible de cette tache qui sous un système GNU/Linux consiste à analyser le répertoire /sys/class/power_supply maintenu à jour par le noyau Linux.

Comme je n’ai pas trouvé mon bonheur, j’ai donc décidé de développer un librairie Python: BatInfo.

Les sources de cette librairie sont disponibles sur Github en licence LGPL.

Installation

L’installation sur votre système peut se faire simplement via la librairie Pypi:

sudo pip install batinfo

L’utilisation de la librairie dans vos développement Python est la suivante, on commence par inclure la librairie:

import batinfo

Puis on créé une instance (bat) de la classe principale (batteries):

bat = batinfo.batteries()

On peut récupérer les données brutes (format JSON) en utilisant:

bat.stat

[{"status": "Full", "capacity": 50, "name": "CMB1", "uevent": "POWER_SUPPLY_NAME=CMB1\nPOWER_SUPPLY_STATUS=Full\nPOWER_SUPPLY_PRESENT=1\nPOWER_SUPPLY_TECHNOLOGY=Li-ion\nPOWER_SUPPLY_CYCLE_COUNT=0\nPOWER_SUPPLY_VOLTAGE_MIN_DESIGN=10800000\nPOWER_SUPPLY_VOLTAGE_NOW=12496000\nPOWER_SUPPLY_CURRENT_NOW=0\nPOWER_SUPPLY_CHARGE_FULL_DESIGN=5800000\nPOWER_SUPPLY_CHARGE_FULL=5800000\nPOWER_SUPPLY_CHARGE_NOW=3900000\nPOWER_SUPPLY_CAPACITY=100\nPOWER_SUPPLY_MODEL_NAME=CP293550-01\nPOWER_SUPPLY_MANUFACTURER=Fujitsu\nPOWER_SUPPLY_SERIAL_NUMBER=01A-Z100320001158Z", "alarm": 0, "charge_full": 5800000, "voltage_now": 12496000, "serial_number": "01A-Z100320001158Z", "cycle_count": 0, "current_now": 0, "charge_now": 3900000, "voltage_min_design": 10800000, "path": "/sys/class/power_supply/CMB1", "technology": "Li-ion", "manufacturer": "Fujitsu", "type": "Battery", "model_name": "CP293550-01", "present": 1, "charge_full_design":5800000}]

Les données brutes se présentent sous la forme d’une liste de dictionnaire (un dictionnaire par batterie présente sur votre système). Comme la plupart du temps les machines (portable) ont une seule batterie, on peut avoir le dictionnaire associé à cette première batterie avec:

bat.stat[0]

{"status": "Full", "capacity": 100, "name": "CMB1", "uevent": "POWER_SUPPLY_NAME=CMB1\nPOWER_SUPPLY_STATUS=Full\nPOWER_SUPPLY_PRESENT=1\nPOWER_SUPPLY_TECHNOLOGY=Li-ion\nPOWER_SUPPLY_CYCLE_COUNT=0\nPOWER_SUPPLY_VOLTAGE_MIN_DESIGN=10800000\nPOWER_SUPPLY_VOLTAGE_NOW=12496000\nPOWER_SUPPLY_CURRENT_NOW=0\nPOWER_SUPPLY_CHARGE_FULL_DESIGN=5800000\nPOWER_SUPPLY_CHARGE_FULL=5800000\nPOWER_SUPPLY_CHARGE_NOW=3900000\nPOWER_SUPPLY_CAPACITY=100\nPOWER_SUPPLY_MODEL_NAME=CP293550-01\nPOWER_SUPPLY_MANUFACTURER=Fujitsu\nPOWER_SUPPLY_SERIAL_NUMBER=01A-Z100320001158Z", "alarm": 0, "charge_full": 5800000, "voltage_now": 12496000, "serial_number": "01A-Z100320001158Z", "cycle_count": 0, "current_now": 0, "charge_now": 3900000, "voltage_min_design": 10800000, "path": "/sys/class/power_supply/CMB1", "technology": "Li-ion", "manufacturer": "Fujitsu", "type": "Battery", "model_name": "CP293550-01", "present": 1, "charge_full_design":5800000}

Les statistiques présentes dans le dictionnaire dépende de votre batterie. Mais on retrouve un certain nombre d’informations génériques comme par exemple la capacité restante (en %):

bat.stat[0].capacity

50

la capacité maximale:

bat.stat[0].charge_full

5800000

ou encore la capacité courante:

bat.stat[0].charge_now

3900000

On peut aussi avoir des informations constructeurs:

bat.stat[0].manufacturer

'Fujitsu'

bat.stat[0].technology

'Li-ion'

En espérant que cette librairie soit utile à certains. Si vous avez des remarques/rapports de bug à faire, merci d’utiliser le Github: https://github.com/nicolargo/batinfo/issues

Il ne me reste plus, pour ma part, qu’à intégrer cela dans Glances.

Catégories
Open-source Planet-libre Systeme

Ma méthode pour gérer les règles IpTables

iptables« Ooopsss… »

Cette phrase a été prononcée au moins une fois par toute personne ayant administré les règles de Firewall d’un serveur. Les conséquences vont du simple blocage d’une application critique (dont on s’aperçoit de l’indisponibilité au prochain « check » sur son serveur de monitoring) à la perte de connexion pure et simple vers la machine (même pour corriger sa boulette).

Pour éviter de se retrouver dans cette situation et ainsi éviter les rires et moqueries des collègues, voici quelques pistes que j’utilise pour administrer mes règles IpTables sur mes serveurs Debian.

1. Regrouper la sécurité dans un script de démarrage

Il y a plusieurs écoles pour gérer les règles de Firewall. Celle proposée par le wiki officiel de Debian repose sur l’utilisation exclusive des commandes iptables-save et iptables-restore qui permettent respectivement de sauvegarder et de restaurer une configuration IpTables existante.

Pour ma part, je préfère inclure ces commandes dans un script de plus haut niveau que je positionne dans le répertoire /etc/init.d et qui sera donc lancé au démarrage du serveur. Ce fichier firewall.sh est disponible sur mon GitHub DebianPostInstall ou via Gist.

En voici une version à ce jour:



Par défait le script met en place les règles suivantes:


    

  • autorise les connexions SSH entrantes (pour administrer son serveur à distance)
    • 

  • autorise les connexions HTTP, HTTPs et DNS sortante (pour l’installation et mise à jour du système et des logiciels)
    • 

  • interdiction et log des autres flux, entrant et sortant
    • 

  • et en cadeau bonux (ce qui on plus de 35 ans peuvent comprendre) sécurise un peu plus le kernel Linux
    • 



L’utilisation de ce script est standard, ainsi pour appliquer les règles de Firewall:


sudo service firewall.sh start


Pour supprimer les règles de Firewall (attention votre serveur sera ainsi exposé aux attaques extérieures puisqu’aucunes restriction d’accès ne sera appliquée):


sudo service firewall.sh clear


Attention: Il est également possible d’utiliser cette commande avec l’option stop (sudo service firewall.sh stop), mais il faut être conscient que toutes les connexions, entrantes et sortantes seront alors interdites (même votre SSH !!!). Cette commandes est donc à éviter bannir si l’on utilise une connexion à distance pour administrer son serveur…


2. Modifier les règles


On entre ici dans le vif du sujet de ce billet: Comment procéder quand on doit modifier les règles de sécurité ?


La première chose à faire est d’être sûr d’avoir les connaissances nécessaires avant de toucher à quoi que ce soit. Cela peut sembler évident, mais faire des copier/coller de règles trouver sur le net et que l’on ne maîtrisent pas est, sans aucun doute, le meilleur moyen de tout faire planter. Pour modifier les tables IpTables, il faut donc avoir un verni de connaissance général sur le protocole TCP/IP (notamment les notions d’adresses et de port sources/destinations). On trouve pour cela quelques très bon cours en ligne comme celui de chez Developpez.com ou bien la bible de Tanenbaum: Réseaux 5em édition aux éditions Pearson. Bien évidemment, il faut également connaitre les rudiments de la commande IpTables en lisant la documentation officielle (disponible en Français) et notamment la section sur le filtrage de paquets.


On peut passer aux choses sérieuses en identifiant les règles courantes grâce à la commande:


sudo iptables -n -L -v --line-numbers


On obtiendra alors une sortie dépendante des règles actives (exemple pour un de mes serveurs):


Chain INPUT (policy DROP 13 packets, 1398 bytes)
num   pkts bytes target     prot opt in     out     source               destination         
1     381M  138G fail2ban-ALL  tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           
2     495K   83M fail2ban-SSH  tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:22 
3     251M   23G fail2ban-HTTP  tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:80 
4     380M  138G fail2ban-ALL  tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           
5     606M  241G ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED 
6    64473 3711K ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:22 
7      12M  653M ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:80 
8        1    44 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:1337 
9    55724 3343K ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:4949 
10      85  4064 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:5001 
11   53603 3216K ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:61209 
12      13   532 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0           udp dpt:123 
13    224K   21M ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0           udp dpt:161 
14       0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0           udp dpt:5001 
15       0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:22 
16    230K   22M ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0           
17   4822K  289M ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0           
18   3684K  435M LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0           LOG flags 0 level 4 
19       0     0 ACCEPT     tcp  --  *      *       88.190.254.200       0.0.0.0/0           tcp spt:20 

Chain FORWARD (policy DROP 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy DROP 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination         
1      98M  183G ACCEPT     all  --  *      lo      0.0.0.0/0            0.0.0.0/0           
2     253M  912G ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED 
3        1    84 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0           
4        0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            195.20.242.89       tcp dpt:80 
5        0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            212.211.132.32      tcp dpt:80 
6        0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            212.211.132.250     tcp dpt:80 
7      179 10740 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:21 
8      276 14700 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:22 
9     1254 75180 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:25 
10   91789 5507K ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:80 
11   12940  776K ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:443 
12    688K   46M ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpts:1024:65534 
13     90M 5705M ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0           udp dpt:53 
14   30171 2293K ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0           udp dpt:123 
15       0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            88.190.254.200      tcp dpt:21 
16      78  3120 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0           LOG flags 0 level 4 
17      78  3120 REJECT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           reject-with icmp-port-unreachable 

Chain fail2ban-ALL (2 references)
num   pkts bytes target     prot opt in     out     source               destination         
1     761M  277G RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0           
2        0     0 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain fail2ban-HTTP (1 references)
num   pkts bytes target     prot opt in     out     source               destination         
1     251M   23G RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain fail2ban-SSH (1 references)
num   pkts bytes target     prot opt in     out     source               destination         
1       10  1568 DROP       all  --  *      *       61.155.150.217       0.0.0.0/0           
2     408K   77M RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0


Une fois que vous avez identifié la règle IpTables à ajouter dans votre configuration,  il est maintenant temps de passer à l’action.


Ne jamais, jamais, modifier directement la table avec une commande IpTables sur un serveur en production…


Plusieurs solutions sont possibles, personnellement, j’utilise la méthodologie suivantes:


    

  1. je commence par copier le script firewall.sh dans un autre répertoire (par exemple dans /tmp/firewall.sh)
    2. 

  2. j’ajoute la règle IpTables dans la copie du script (/tmp/firewall.sh)
    3. 

  3. je teste les nouvelles règles en utilisant l’option « test » du script ainsi modifié qui va sauvegarder les règles actuelles, appliquer les nouvelles, attendre 30 secondes puis ré-appliquer les règles actuelles (donc au pire au fait une boulette de 30 secondes…)
    4. 

  4. si tout se passe comme attendu pendant les 30 secondes, alors je copie le fichier /tmp/firewall.sh sous /etc/init.d
    5. 

  5. et j’applique les règles en production le moment voulu
    6. 



Les lignes de commandes correspondantes sont:


sudo cp /etc/init.d/firewall.sh /tmp/
sudo vim /tmp/firewall.sh
sudo sh /tmp/firewall.sh test
sudo cp /tmp/firewall.sh /etc/init.d/
sudo service firewall.sh restart


Ainsi, en cas de problème dans les règles, le serveur ne sera indisponible que pendant 30 secondes. Dans le cas « pas de bol » ou le serveur crache durant ces 30 secondes alors les anciennes règles seront rechargées au redémarrage.


Pas de script ?


Si vous ne souhaitez pas mettre en place un tel script de démarrage des règles de Firewall, il est quand même possible (même si je ne le conseille pas pour avoir une vue d’ensemble des règles à appliquer) de reproduire la méthodologie d’écrite dans le chapitre précédant.


Ainsi, il est tout à fait possible d’utiliser une commande du type:


sudo iptables-save > /etc/iptables.backup && sudo iptables <nouvelle regle a appliquer> && sleep 30 && sudo iptables-restore < /etc/iptables.backup


Conclusion


Comment gérez-vous vos règles de Firewall sur vos serveurs GNU/Linux ? Des astuces à partager avec nous dans les commentaires ?


		


	


	

		
		


			

		


		
	


	






	



	


		
			

				
					Catégories				
				

					Open-source Planet-libre Systeme				

			


			
Encore un effort pour la libération du cahier Debian

		


			

		


		
	





	


		


			
		


	


	
	


		


			
Mise à jour du billet


La libération du livre est désormais acquise, merci à vous tous !


Il est cependant possible de continuer à y participer pour soutenir un peu plus le projet Debian.




===


Raphaël Hertzog s’est lancé dans un projet qui mérite un petit coup de pouce de la part de la communauté des logiciels libres: la libération du Cahier Debian, la référence littéraire pour les utilisateurs et administrateurs du système d’exploitation Debian (traduction et adaptation de la version originale en Anglais de « The Debian administrator’s Handbook »).


bandeau-toutes-couvertures


Trois objectifs sont en fait visés:


    

  • garantir la libération du livre
    • 

  • effectuer sa mise à jour pour Debian 7
    • 

  • mise en place d’une nouvelle édition en librairie
    • 



Pour cela Raphaël et Roland, après négociation préalable avec l’éditeur Eyrolles, sont passés par un système de financement de type « crowfunding ». Ainsi, à partir du site Ulule, il vous est possible de participer à cette aventure en finançant en amont ce beau projet. Pour cela, plusieurs offres sont possibles, de 5€ à 600€+ pour les plus riches :). Pour que celle-ci commence vraiment et que le projet soit réalisé, il faut un minimum de 15.000€.


A l’heure actuelle (2 juin à 18h), il reste encore 4.500€ à trouver.


Je compte sur vous pour donner quelques €€€€.


Cliquez ici pour participer au projet de libération du cahier Debian !


Bonne fin de week-end !


Note: personnellement, je trouve l’offre à 50€ la plus atractive car elle permet d’avoir le cahier au format papier (c’est mon coté old school qui parle).


		


	


	

		
		


			

		


		
	


	






	



	


		
			

				
					Catégories				
				

					Gstreamer Hardware Open-source Planet-libre Video				

			


			
Streaming depuis la Raspberry Camera

		


			

		


		
	





	


		


			
		


	


	
	


		


			
Après une rapide présentation de la Raspberry Camera 5M (voir ce précédant billet), entrons dans le vif du sujet avec une utilisation pratique: le streaming « live » du flux vidéo vers une autre machine de votre réseau. Les applications peuvent aller d’un « baby video phone » à  un « interphone vidéo » pour votre maison en passant par toutes les autres choses qui vous passent par la tête !


Actuellement, la camera dispose d’un logiciel spécifique Raspivid (dont les sources sont disponibles sur Github), pour capturer et encoder en H.264 la vidéo dans un fichier ou bien sur le flux standard de sortie (stdout). C’est cette dernière particularité que nous allons exploiter afin de rediriger le flux vidéo vers une pipeline GStreamer qui va s’occuper du streaming vers notre machine cible (celle ou l’on souhaite voir la vidéo).


Installation des composants GStreamer


On commence par installer GStreamer sur notre Raspberry PI. Pour cela on saisi la commande suivante:


sudo apt-get install gstreamer-tools gstreamer0.10-plugins-base gstreamer0.10-plugins-good gstreamer0.10-plugins-bad gstreamer0.10-plugins-ugly


L’installation va prendre un certain temps. Passiensa !


Pour vérifier que les composants ont été correctement installé, saisir la commande suivante:


gst-inspect


Qui devrait afficher les chiffres suivants (qui peuvent varier légèrement selon votre configuration):


Total count: 233 plugins, 695 features


Lancement de la diffusion (streaming) sur le Raspberry


On utilise la pipeline suivante:


raspivid -t 0 -w 1280 -h 720 -fps 25 -b 2500000 -p 0,0,640,480 -o - | gst-launch -v fdsrc ! h264parse ! rtph264pay config-interval=1 pt=96 ! gdppay ! tcpserversink host=192.168.0.9 port 5000


Détaillons un peu cette ligne de commande. La première partie est dédiée à Raspvid et s’occupe de l’encodage H.264. Les paramètres sont très importants pour avoir une qualité vidéo conforme à vos besoins. Ainsi, dans mon exemple, je n’y suis pas allé avec le dos de la cuillère car j’ai opté pour une résolution HD 720p (-w 1280 -h 720) à 25 images par seconde (-fps 25) pendant un temps infini (-t -1).


Pour le streaming, le paramètre de débit (bitrate, -b 2500000) est primordial car il va fixer le débit sortant de la vidéo (à 2.5 Mbps dans mon exemple).


Ce débit est à adapté selon votre résolution. Après quelques tests, voici une table indicative des débits à utiliser:


    

  • SD Low: -w 480 -h 260 -fps 25 -b  800000
    • 

  • SD Medium: -w 640 -h 360 -fps 25 -b  1200000
    • 

  • SD High: -w 960 -h 540 -fps 25 -b  1800000
    • 

  • HD Ready: -w 1280 -h 720 -fps 25 -b  2500000
    • 

  • Full HD: -w 1920 -h 1080 -fps 25 -b  5000000
    • 



Note: attention au dimensionnement de votre réseau si vous utilisez des débits élevés, en effet même avec des bornes Wifi ressentes, il est difficile de garder un débit constant de 5 Mbps (Full HD).


Note 2: sur le Raspberry, je conseille d’utiliser l’interface Ethernet et pas un dongle Wifi, surtout avec des résolutions importantes.


La commande passe ensuite la main à GStreamer qui va encapsuler le flux H.264 dans un conteneur RTP puis créer le serveur TCP en écoute des clients (il faudra penser à remplacer l’adresse IP par celle de votre Raspberry Pi).


Lecture de la vidéo depuis une autre machine


J’ai fait le test depuis mon portable Ubuntu 13.04 en saisissant la ligne de commande suivante pour récupérer et afficher la vidéo:


gst-launch-1.0 -v tcpclientsrc host=192.168.0.9 port=5000  ! gdpdepay ! rtph264depay ! avdec_h264 ! videoconvert ! autovideosink sync=false


La qualité de la vidéo est très bonne, fluide. On note quelques retard quand on sollicite le réseau en parallèle mais cela semble normal vu les débits utilisés.


Lecture streaming Raspberry Pi Camera 720p


Ce qui est très impressionnant au niveau du Raspberry, c’est la faible consommation CPU. En effet, Raspivid ne dépasse pas les 2% (merci le GPU) et GStreamer les 25%. On peut sans aucun problème laisser tourner le tout sans risque de surchauffe.


Conclusion


J’espère que cette rapide introduction sur le streaming vidéo depuis le Raspberry vous a donné des idées que vous aller vous empresser de nous faire partager dans les commentaires ci-dessous !


Retrouvez mes articles sur l’écosystème Raspberry Pi en cliquant ici.




		


	


	

		
		


			

		


		
	


	






	



	


		
			

				
					Catégories				
				

					Hardware Open-source Planet-libre raspberry				

			


			
Test de la caméra Raspberry Pi 5M

		


			

		


		
	





	


		


			
		


	


	
	


		


			
Raspberry propose depuis peu et pour moins de 25€ une caméra dédiée à sa gamme Pi. Cette caméra de quelques grammes se connecte à une Raspberry Pi (model A ou B) à travers une interface CSi v2 (MIPI camera interface) dédiée. Grâce à Kubii (fournisseur Farnell en France) j’ai pu obtenir rapidement un de ces caméra que nous allons tester dans ce billet.


Découverte de la (petite) bête


Avec un capteur d’une résolution native de 5 mégapixels (5M) et au niveau optique d’une lentille de focalisation fixe, la caméra peut servir d’appareil photo (résolution maximale de 2592 par 1944 pixels) ou de caméra vidéo (format HD juqu’à 1080p). Son poids est impressionnant car elle ne pèse pas plus de 4 grammes pour une dimension de L25 l20 H9 (en millimètre).


Raspberry Camera 5M 1.3


Installation de la caméra


On commence par brancher la caméra sur l’interface CSi. Il faut y aller doucement, sans forcer comme un bourrin. Je vous conseille de visualiser la vidéo suivante:




Il faut disposer d’une distribution Raspbian à jour avant de pouvoir activer la caméra:


sudo apt-get update && sudo apt-get upgrade


Puis on lance ensuite l’utilitaire raspi-config ou un nouveau menu devrait vous permettre d’activer la caméra (choix numéro 5 – Activate the camera):


sudo raspi-config


Un reboot plus tard vous pouvez commencer à jouer avec la caméra


Utilisation de la caméra pour prendre des photos


Première surprise un peu désagréable: la caméra n’est pas reconnue comme un device vidéo standard (accessible via /dev/videoX). En l’état actuel des choses on ne peut donc pas l’utiliser avec une bibliothèque comme GStreamer.


Pour utiliser la caméra comme appareil photo, il faut donc passer par un utilitaire installé de base dans Raspbian: Raspistill (les sources sont disponibles sur Github).


Ce logiciel est utilisable en ligne de commande.


Prenons donc notre première « photo » en résolution maximale et à main levé (2592 par 1944 pixels):


raspistill -o image001.jpg


RaspberryCamera


La même photo avec l’option de stabilisation activée (pas de grosse différence mais je ne bougeais pas):


raspistill -ev -o image002.jpg


RaspberryCamera


Il est possible de désactiver la compression JPEG en utilisant le tag –raw (mais attention la taille des images passes à plus de 5 Mo):


raspistill --raw -o image002.jpg


Voir le résultat ici.


Il est bien sûr possible de fixer la résolution avec les tag -h et -w. Par exemple une photo en 1280×1024:


raspistill -w 1280 -h 1024 -o image003.jpg


RaspberryCamera


Utilisation de la caméra pour capturer des vidéo


Tout comme pour les photos, il faut passer par le l’utilitaire Raspivid (les sources sont disponibles sur Github). Le logiciel va permettre de générer des vidéos au format H.264.


Capturons notre première vidéo en full HD (1080p) pendant  10 secondes (-t 10000):


raspivid -t 10000 -o video001.h264


La vidéo est stocké au format H.264 dans le fichier video001.h264. Pour lire cette vidéo sur votre Raspberry, vous pouvez utiliser la commande omxplayer qui va utiliser le GPU interne et afficher la vidéo d’une manière fluide sans consommation CPU.


omxplayer video001.h264


On peut voir que la qualité du capteur est au rendez-vous, la vidéo est lumineuse et fluide, comparable à ce que l’on peut obtenir avec un bon smartphone.


Pour activer la prévisualisation de la vidéo dans un coin de l’écran (position 0x0 et taille de 640×480) on peut utiliser l’option -p:


raspivid -t 10000 -p 0,0,640,480 -o video0012.h264


Aller plus loin ?


La documentation officielle des deux commandes.


Raspistill


raspistill
==========

--width,	-w		Set image width <size>
--height,	-h		Set image height <size>
--quality,  -q		Set jpeg quality <0 to 100>

Quality 100 is almost completely uncompressed. 75 is a good all round value

--raw,	-r		Add raw bayer data to jpeg metadata

This option inserts the raw Bayer data from the camera in to the JPEG metadata

--output	-o		Output filename <filename>.

Specify the output filename. If not specified, no file is saved. If the filename is '-', then all output is sent to stdout.

--verbose,	-v		Output verbose information during run

Outputs debugging/information messages during the program run.

--timeout,	-t		Time before takes picture and shuts down.

The program will run for this length of time, then take the capture (if output is specified). If not specified, this is set to 5 seconds

--timelapse,-tl		Timelapse mode.

The specific value is the time between shots in milliseconds. Note you should specify %d at the point in the filename where you want a frame count number to appear. e.g.

	-t 30000 -tl 2000 -o image%d.jpg

will produce a capture every 2 seconds, over a total period of 30s, named image1.jpg, image2.jpg..image15.jpg.

--thumb,	-th		Set thumbnail parameters (x:y:quality)

Allows specification of the thumbnail image inserted in to the JPEG file. If not specified, defaults are a size of 64x48 at quality 35.

--demo, 	d	 	Run a demo mode <milliseconds>

This options cycles through range of camera options, no capture is done, the demo will end at the end of the timeout period, irrespective of whether all the options have been cycled. The time between cycles should be specified as a millisecond value.

--encoding,	-e		Encoding to use for output file

Valid options are jpg, bmp, gif and png. Note that unaccelerated image types (gif, png, bmp) will take much longer to save than JPG which is hardware accelerated. Also note that the filename suffix is completely ignored when encoding a file.

--exif,	-x		EXIF tag to apply to captures (format as 'key=value')

Allows the insertion of specific exif tags in to the JPEG image. You can have up to 32 exif tge entries. This is useful for things like adding GPS metadata. For example, to set the Longitude

	--exif GPS.GPSLongitude=5/1,10/1,15/100

would set the Longitude to 5degs, 10 minutes, 15 seconds. See exif documentation for more details on the range of tags available; the supported tags are as follows.


Raspivid


raspivid
========

--width,	-w		Set image width <size>

Width of resulting video. This should be between 64 and 1920.

--height,	-h		Set image height <size>

Height of resulting video. This should be between 64 and 1080.

--bitrate,	-b		Set bitrate. 

Use bits per second, so 10MBits/s would be -b 10000000. For H264, 1080p a high quality bitrate would be 15Mbits/s or more.

--output	-o		Output filename <filename>.

Specify the output filename. If not specified, no file is saved. If the filename is '-', then all output is sent to stdout.

--verbose,	-v		Output verbose information during run

Outputs debugging/information messages during the program run.

--timeout,	-t		Time before takes picture and shuts down.

The program will run for this length of time, then take the capture (if output is specified). If not specified, this is set to 5seconds

--demo, 	d	 	Run a demo mode <milliseconds>

This options cycles through range of camera options, no capture is done, the demo will end at the end of the timeout period, irrespective of whether all the options have been cycled. The time between cycles should be specified as a millisecond value.

--framerate, 	-fps  Specify the frames per second to record

At present, the minimum frame rate allowed is 2fps, the maximum is 30fps. This is likely to change in the future.

--penc,	-e	Display preview image *after* encoding

Switch on an option to display the preview after compression. This will show any compression artefacts in the preview window. In normal operation, the preview will show the camera output prior to being compressed. This option is not guaranteed to work in future releases.


Conclusion


Pour moins de 60€, il est donc possible d’avoir un Raspberry Pi model B + Camera qui vous ouvre la porte à pas mal de possibilité. J’espère rapidement voir apparaître une API (en Python par exemple) permettant de programmer directement la caméra.


De mon coté je vais faire un peu mumuse avec ce nouveau jouet puis revenir prochainement vers vous pour de nouveaux billets sur le sujet !


		


	


	

		
		


			

		


		
	


	






	



	


		
			

				
					Catégories				
				

					Developpement Open-source Planet-libre Video				

			


			
Witsub télécharge automatiquement vos sous-titres

		


			

		


		
	





	


		


			
		


	


	
	


		


			
subtitles


Witsub est mon dernier projet personnel visant à développer un utilitaire en ligne de commande permettant de télécharger automatiquement l’ensemble des sous-titres disponibles de votre bibliothèques de vidéos. L’objectif étant de disposer d’un outil simple, rapide, efficace et facilement déclenchable par script shell.


Comment marche Witsub


Witsub est développé en pure Python (sans bibliothèque non standard) et devrait donc fonctionner sur tous les systèmes d’exploitations (je l’ai uniquement testé sous GNU/linux). Dans son utilisation la plus simple, il prend en entrée un fichier ou un répertoire et une langue souhaitée pour les sous-titres. Ensuite il va parcourir la base de donnée OpenSubtitles pour y trouver les fichiers .srt correspondant à vos fichiers vidéos.


Pour installer Witsub, vous pouvez directement télécharger le script sous Github:


wget https://github.com/nicolargo/witsub/blob/master/witsub/witsub.py
chmod a+x witsub.py


ou bien utiliser les sources avec l’installeur au format tar.gz:


wget https://s3.amazonaws.com/witsub/witsub-1.1.tar.gz
tar zxvf witsub-1.1.tar.gz
cd witsub-1.1
sudo python setup.py install


ou plus propre utiliser PiPY pour l’installer sur votre système:


sudo pip install witsub


Un exemple valant mieux qu’un long discours, voici Witsub en action.


On commence par visualiser le répertoire videos avant le lancement de Witsub


	videos
	├── A wonderfull movies.avi
	├── A top serie
	│   ├── A top serie - S1E01.avi
	│   └── A top serie - S1E02.avi
	└── Not a video file.txt


Puis on lance Witsub en fixant la langue Française (code ISO fre, voir la liste complète des codes ici):


	witsub -l fre -f ./videos


On se retrouve avec:


	videos
	├── A wonderfull movies.avi
	├── A wonderfull movies.srt
	├── A top serie
	│   ├── A top serie - S1E01.avi
	│   ├── A top serie - S1E01.srt
	│   ├── A top serie - S1E02.avi
	│   └── A top serie - S1E02.srt
	└── Not a video file.txt


Voir ce qui se passe


J’ai fait en sorte, avec l’option -V, que Witsub affiche chacune des étapes de sa recherche de sous-titres. Par exemple, pour forcer (-w) le téléchargement des sous-titres Anglais de la vidéo breakdance.avi en mode debug:


# witsub -V -w -f ./test/testdata/breakdance.avi

19/05/2013 15:19:29 DEBUG - Running witsub version 1.0
19/05/2013 15:19:29 DEBUG - Debug mode is ON
19/05/2013 15:19:29 DEBUG - Force overwrite if file exist: True
19/05/2013 15:19:29 DEBUG - No language define. Default is eng
19/05/2013 15:19:29 DEBUG - Subtitle language search set to eng
19/05/2013 15:19:29 DEBUG - Connect to XML-RPC server http://api.opensubtitles.org/xml-rpc
19/05/2013 15:19:29 DEBUG - Login to XML-RPC server <ServerProxy for api.opensubtitles.org/xml-rpc>
19/05/2013 15:19:29 DEBUG - Login successfull with status 200 OK
19/05/2013 15:19:29 DEBUG - Compute hash tag for file test/testdata/breakdance.avi
19/05/2013 15:19:29 DEBUG - Hash tag for file test/testdata/breakdance.avi is 0x8e245d9679d31e12L
19/05/2013 15:19:29 DEBUG - Search subtitle in the database
19/05/2013 15:19:29 DEBUG - Search done in 0.008 seconds
19/05/2013 15:19:29 DEBUG - 4 subtitles found
19/05/2013 15:19:29 DEBUG - Subtitle 1/4 (English - Dwnl: 364): The.Sea.Inside.2004.DVDRip.XviD-RiZZ.srt
19/05/2013 15:19:29 DEBUG - Subtitle 2/4 (English - Dwnl: 224): breakdance.srt
19/05/2013 15:19:29 DEBUG - Subtitle 3/4 (English - Dwnl: 421): breakdance2.srt
19/05/2013 15:19:29 DEBUG - Subtitle 4/4 (English - Dwnl: 143): breakdance2.srt
19/05/2013 15:19:29 DEBUG - Select the first one (most downloaded): The.Sea.Inside.2004.DVDRip.XviD-RiZZ.srt
19/05/2013 15:19:29 DEBUG - Download the compressed subtitle file (id 1951887680): http://dl.opensubtitles.org/en/download/filead/1951887680.gz
19/05/2013 15:19:30 DEBUG - Download processed in 0.05 seconds
19/05/2013 15:19:30 DEBUG - Unzip the compressed subtitle file
19/05/2013 15:19:30 DEBUG - Write the subtitle to test/testdata/breakdance.srt
19/05/2013 15:19:30 INFO - Download completed: test/testdata/breakdance.srt
19/05/2013 15:19:30 DEBUG - Logout from XML-RPC server <ServerProxy for api.opensubtitles.org/xml-rpc>
19/05/2013 15:19:30 DEBUG - Logout successfull with status 200 OK


Les sources !


Witsub est hébergé sur GitHub: https://github.com/nicolargo/witsub


Merci d’y poster vos problèmes, questions, demandes d’amélioration !


Faites tourner 🙂


PS: Je ne suis pas très actif sur le blog en ce moment, la faute à pas mal de choses qui me laissent peu d’énergie pour rédiger des billets. Mais ne vous inquiétez pas, certains sont en préparation, notamment un sur la nouvelle caméra pour Raspberry Pi.


		


	


	

		
		


			

		


		
	


	






	



	


		
			

				
					Catégories				
				

					Open-source Planet-libre Systeme				

			


			
De Squeeze à Wheezy…

		


			

		


		
	





	


		


			
		


	


	
	


		


			
Depuis aujourd’hui, Wheezy est officiellement devenue la septième version stable du système d’exploitation GNU/Linux Debian. Nous allons dans ce billet voir une migration simple d’un serveur Squeeze (Debian 6) vers cette nouvelle version de Debian. Cette migration est adapté uniquement aux serveurs avec une configuration standard. Pour des configurations exotiques, je vous conseille fortement de suivre la procédure officielle très bien détaillée sur le site de Debian.


Avant de commencer…


    

  • Effectuez la migration à un moment ou vous avez du temps et ou votre serveur n’est pas beaucoup sollicitée (par exemple un dimanche pour un serveur perso).
    • 

  • Sauvegarder vos données avant de commencer.
    • 

  • Préparez une procédure de ré-installation simple et rapide au cas ou quelque chose se passe mal.
    • 

  • Idéalement se faire la main sur un serveur non critique avant de passer aux serveurs critiques.
    • 

  • Pas de panique, ce n’est que de l’informatique.
    • 



Se loguer en root (ou avec un user ayant les droit root):


su - root


On commence par préparer le terrain


Avant de procéder à la migration vers Wheezy, il faut s’assurer que votre Squeeze et propre et à jour. Pour cela, on commence par mettre à jour les repos et les packages Squeeze:


$ apt-get update && apt-get upgrade


On doit ensuite et c’est une des étapes les plus lourdes, vérifier que l’ensemble des repos non standards sont disponibles pour Wheezy.


On commence par visualiser le fichier /etc/apt/sources.list:


deb http://debian.mirrors.ovh.net/debian/ squeeze main
deb-src http://debian.mirrors.ovh.net/debian/ squeeze main

deb http://security.debian.org/ squeeze/updates main
deb-src http://security.debian.org/ squeeze/updates main

## DotDeb Package
deb http://packages.dotdeb.org squeeze all
deb-src http://packages.dotdeb.org squeeze all


On peut donc voir que j’utilise les miroirs officiels de Debian fournis par OVH (l’hébergeur de mon serveur de test) qui sont disponibles pour Wheezy ainsi que le repo DotDeb  également disponible pour Wheezy.


On poursuit avec les repos disponibles sous /etc/apt/sources.list.d/. Je n’ai personnellement qu’un seul repo qui est compatible avec Wheezy:


$ cat /etc/apt/sources.list.d/10gen.list

deb http://downloads-distro.mongodb.org/repo/debian-sysvinit dist 10gen


Pour les utilisateurs de sudo


Si vous utilisez sudo sur votre système, il faut effectuer les manipulations suivantes avant la mise à jour sous peine de se retrouver sans fichier de configuration valable.


cp /etc/sudoers /etc/sudoers.d/mysettings


On édite ensuite le fichier /etc/sudoers.d/mysettings pour lui enlever les lignes Defaults et #includedir. Lors de l’upgrade, le fichie /etc/sudoers doit être remplacé par le nouveau.


Pour les utilisateurs de php5-suhosin


Le paquet php5-suhosin n’existe plus dans cette nouvelle version de Debian. Il faut donc saisir la commande suivante pour supprimer la configuration correspondante /etc/php5/conf.d/suhosin.ini:


dpkg --purge php5-suhosin


Puis on migre vers Debian 7 (aka) Wheezy


Si tous les repos que vous utilisez sont compatibles, alors il suffit de saisir la commande suivante pour migrer les fichiers de configuration vers Wheezy:


sed -i 's/squeeze/wheezy/g' /etc/apt/sources.list
for i in `ls /etc/apt/sources.list.d/*.list`; do sed -i 's/squeeze/wheezy/g' $i; done


On va ensuite enchaîner la mise à jour proprement dite en faisant:


    

  • une mise à jour des sources (repos)
    • 

  • une première mise à jour minimale
    • 

  • une seconde mise à jour totale
    • 



apt-get update
apt-get upgrade
apt-get dist-upgrade


Il ne vous reste plus qu’à attendre et vérifier qu’il n’y a pas de problème lors des ces trois étapes. Si vous avez une erreur, attention de bien la résoudre (Google est ton ami) avant de passer à l’étape suivante. PAr exemple, il est possible que certains paquets n’arrive pas à se mettre à jour. Les deux ligne suivantes devraient corriger ce problème:


apt-get -f install
apt-get dist-upgrade


On finalise la configuration en vérifiant que le fichier


Sinon, il ne vous reste plus qu’à redémarrer votre serveur (cette dernière étape étant facultative).


		


	


	

		
		


			

		


		
	


	






	



	


		
			

				
					Catégories				
				

					Open-source Planet-libre raspberry Video				

			


			
Test d’OpenElec sur Raspberry Pi

		


			

		


		
	





	


		


			
		


	


	
	


		


			
Billet mis à jour le 1 mai 2015 avec OpenELEC 5.0.8.


Avec l’apparition du Raspberry Pi et de son GPU Broadcom VideoCore IV intégré, les logiciels de « media center », c’est à dire les systèmes permettant de connecter directement un PC à une télévision pour exploiter sa bibliothèque vidéo, se sont rapidement intéressés à ce nouvel OVNI technologique. Ainsi plusieurs distributions Linux orientés « media center » ont vus le jour pour nous permettre et permettent, pour moins de 30€, de disposer d’un système intégré pour lire des vidéos HD téléchargés plus ou moins légalement sur le Internet.


Nous allons dans ce billet nous intéresser à l’une d’entre elle: OpenElec (Open Embedded Linux Entertainment Center) qui dispose d’un bonne notoriété sur les réseaux sociaux, notamment grâce à une interface de navigation fluide et à une documentation bien fournie (notamment leur Wiki). Il faut juste garder en tête que toutes ces distributions « media center » se base sur le même noyau composé de Raspbian (le système d’exploitation Debian adapté au Raspberry Pi) et XBMC pour le logiciel.


OpenElec screenshot


Installation d’OpenElec


Pour installer OpenElec, les auteurs du projet ont eu la bonne idée de créer un script qui va partitionner et graver la dernière version du système (3.0.1 au moment de l’écriture de cet article) sur une carte SD que vous n’aurez plus qu’à insérer dans votre Raspberry Pi.


Voici les lignes de commandes à saisir sur votre machine GNU/Linux pour installer la version 5.0.8 d’OpenElec sur une carte SD disponible via l’identifiant système /dev/sdb (c’est bien sûr à contrôler avec la commande « fdisk -l » pour être sûr que /dev/sdb correspond bien à votre carte SD histoire de ne pas effacer un autre disque dur):


wget http://releases.openelec.tv/OpenELEC-RPi.arm-5.0.8.tar 
tar xvf OpenELEC-RPi.arm-5.0.8.tar 
cd OpenELEC-RPi.arm-5.0.8/
sudo ./create_sdcard /dev/sdb


Installation de votre Raspberry Pi


Voici la configuration que j’ai utilisé pour le test:


    

  • Un téléviseur Samsung UE46B6000 (pour une description de mon système home cinéma avant l’arrivée de mon Raspberry, cliquez ici !)
    • 

  • Un Raspberry Pi model B (j’ai ensuite utilisé un model A)
    • 

  • Une carte SD 4 Go (mais une de 2 Go suffit) avec OpenELec 3.0.1 (voir le premier paragraphe pour l’installation)
    • 

  • Un disque dur USB contenant mes vidéos (attention de bien alimenter le disque par une source externe car le Raspberry Pi n’y arrive pas).
    • 

  • Un câble HDMI pour la liaison numérique avec le téléviseur (vidéo, son et télécommande avec la norme HDMI CEC).
    • 

  • Une souris pour manipuler l’interface d’OpenElec ou mieux encore votre télécommande si votre téléviseur est compatible avec la norme HDMI CEC (comme c’est le cas pour mon téléviseur Samsung via l’implémentation de la fonction Anynet+)
    • 

  • Un câble réseau (pour l’accès distant et l’accès au NAS) (optionnel et seulement pour le model B)
    • 



Après branchement, le système devrait démarrer automatiquement et l’interface va apparaître sur votre téléviseur. Si vous avez un modèle B, l’accés en SSH (l’adresse IP de votre Raspberry Pi est donnée dans le menu configuration) se fait à l’aide de l’utilisateur root et du mot de passe openelec.


Test de la bête


J’ai d’abord testé OpenElec avec un Raspberry Pi model B puis quand j’ai reçu mon model A j’ai basculé vers ce boîtier car je n’utilise pas mon NAS pour stocker mes films mais un simple disque dur portable connecté directement au Raspberry Pi.


Le démarrage du système est assez rapide (entre 1 minute et 1 minute 30), on arrive directement sur l’interface XMBC customisée à la sauce OpenElec. La navigation dans les différents menus se fait de manière relativement fluide. Le « relativement » n’est pas vraiment un problème quand comme moi vous utilisez une télécommande. Par contre on ressent une certaine difficulté du Raspberry Pi à suivre le rythme quand on utilise une souris. A noter que l’utilisation direct de la télécommande est assez blufante, une vraie bonne idée cette norme HDMI CEC.


Sur ma configuration, je n’ai presque pas eu de configuration à faire mis à part un calibrage de l’écran. En effet, je perdais des petites bandes d’image sur les cotés. Le plus simple pour faire cela est de lire un film et de cliquer sur le bouton « Vidéos – Paramétrage » puis « Étalonnage de l’écran ». Vous aurez alors droit à un wizard qui va vous permettre de bien redimensionner la vidéo par rapport à votre télévision.


On peut ensuite passer au test de lecture vidéo qui est l’objectif principal de notre boîtier.  Pour cela j’ai fait tourner pendant une journée entière OpenElec en lecture d’un rip HD Xvid 720p de « The art of flying » qui avec ses traveling n’est pas une vidéo facile à décoder.


The art of flying


Le résultat est très concluant, aucune saccade constatée de la vidéo lors de la lecture (mais bon je suis pas non plus resté toutes la journée devant l’écran :)). Le son 5.1, récupéré directement via la liaison HDMI, est bon. J’ai également fait des tests avec des trailers en HD 1080p et il n’y a également aucun problème de lecture. Le GPU fait vraiment bien son boulot.


Le Raspberry Pi ne chauffe presque pas (j’ai mis la carte dans un boîtier transparent que l’on peut trouver pour quelques € pour que la carte ne prenne pas la poussière et pour éviter que mes enfants mettent les doigts dessus, c’est curieux ces bêtes là…).


A noter qu’avant la rédaction de ce billet, j’avais demandé à mon copain Twitter des retours d’expériences sur les « media center » du Raspberry PI. De nombreux followers m’avaient signalés qu’il avait des problèmes de lags lors de la lecture de vidéo HD 1080p sur OpenElec. Je n’ai pas constaté de problème sur ma configuration et je pense que leurs problèmes viennent du fait qu’il utilise des vidéos stockées sur un NAS. Il faut donc regarder du coté du réseau et notamment si vous utilisez un dongle Wifi sur votre Raspberry Pi.


Problème d’avance et de retour rapide


Note: ce problème n’est plus présent dans la version 5.0.8 d’OpenElec.


Lors des tests, j’ai constaté un problème au niveau de l’avance et du retour rapide lors de la lecture des vidéos. C’est un problème connu au niveau de XBMC.


Il existe heureusement une solution de contournement qui consiste à remplacer le « fast forward » (& rewind) par le « step forward » (& rewind). Pour cela, il faut éditer le fichier remote.xml (à chercher sur votre configuration via la commande « find / -name remote.xml »), puis à éditer la section FullscreenVideo:


  <FullscreenVideo>
    <remote>
      <title>Stop</title>
      <back>Stop</back>	
      <reverse>StepBack</reverse>
      <forward>StepForward</forward>
    </remote>
  </FullscreenVideo>


Le pas par défaut est de 30 secondes, pour le changer il faut éditer un autre fichier nommé advancedsettings.xml qui est à créer pour l’occasion (cliquer ici pour voir comment créer ce fichier selon la documentation de XBMC) puis à l’éditer avec le contenu suivant:


<advancedsettings>
<video> <!-- "VideoSettings" instead of "video" for builds prior to May 22, 2006 -->
  <usetimeseeking>true</usetimeseeking>  <!-- Whether to use time based or percentage based seeking. -->
  <timeseekforward>15</timeseekforward>  <!-- Time to seek forward in seconds when doing a short seek.  Defaults to 30. -->
  <timeseekbackward>-15</timeseekbackward>  <!-- Time to seek backward in seconds when doing a short seek.  Defaults to -30. -->
  <timeseekforwardbig>600</timeseekforwardbig>  <!-- Time to seek forward in seconds when doing a long seek.  Defaults to 600 (10 minutes). -->
  <timeseekbackwardbig>-600</timeseekbackwardbig>
</video>
</advancedsettings>


Conclusion


Le Raspberry Pi est vraiment un joujou surprenant par ses capacités à faire des choses habituellement réservées à du matériel beaucoup plus cher. Avec les solutions intégrées comme OpenElec, on n’a même plus la complexité de configuration et ces solutions de « media center » deviennent à la porté de n’importe quel bidouilleur.


… pour faire la fine bouche


Il manque encore le support du HDMI Ethernet Channel qui permettrait au Raspberry d’utiliser via le câble HDMI la liaison Internet de la télé. C’est prévue dans la norme HDMI 1.4 mais pas implémenté dans les modèles actuels du Raspberry Pi (voir la page suivante pour les explications).


—


Allez, à vos claviers, parlez moi de votre configuration « media center ». Utilisez-vous OpenElec ou bien une autre distribution ? Si oui pourquoi ?


—