source: Nicolargo
Pour fêter la mise en ligne de ma nouvelle page dédiée au Raspberry, Kubii, revendeur officiel de Pi en France et sponsor du blog de Nicolargo, nous propose un code promo de 5€ pour 100€ d'achat sur son site:
---===---
Lien vers le site: http://www.kubii.fr/
Code promo: kubireduc
Validité: Jusqu'au 30 juin 2013
---===---
Envoy !
Cet article Code promo pour le site Kubii.fr est apparu en premier sur Le blog de NicoLargo.
Airplay est une technologie, mise en avant par Apple et par un nombre croissant d'acteurs du monde de la Hifi, permettant de déporter les flux audio, photo et vidéo d'un device (PC/Mac, tablette, téléphone) sur des périphériques externes (Ampli, Enceintes...). Basée sur un protocole propriétaire (heureusement cassé par reverse ingenering), il n'a malheureusement en face de lui aucune alternative stable et libre: Miracast est uniquement dédié aux devices Wifi et Google qui planchait sur une alternative à Airplay ne semble pas très pressé de la sortir.
Dans ce billet nous allons voir comment transformer un Raspberry Pi (23€ chez votre épicier) en une borne Airplay connectée à votre chaîne Hifi (ou encore mieux en passant par un DAC) afin de disposer d'une chaîne de streaming de bonne qualité entre vos "idevices" (iPhone, iPad, Mac OS mais aussi Android) et vos enceintes.
Dans le jargon Airplay, nous allons donc transformer un Raspberry Pi en "Airplay receiver". Shazam...
Ce billet a été validé sur la configuration suivante:
J'ai utilisé le système d'exploitation Raspbian "Wheezy" dont j'ai déjà détaillé l'installation dans un précédant billet. Comme ma chaîne Hifi est loin de mon réseau Ethernet filaire, j'ai utilisé un dongle USB Wifi (attention la liste des dongles supportés est ici) que j'ai connecté au Raspberry et configuré en suivant ce tutoriel.
Ma configuration réseau est la suivante pour le fichier /etc/network/interfaces:
auto lo iface lo inet loopback auto eth0 iface eth0 inet dhcp auto wlan0 allow-hotplug wlan0 iface wlan0 inet manual wpa-roam /etc/wpa_supplicant/wpa_supplicant.conf iface default inet dhcp
et celle-ci pour le fichier /etc/wpa_supplicant/wpa_supplicant.conf:
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1
network={
ssid="MONWIFI"
scan_ssid=1
key_mgmt=WPA-PSK
proto=WPA
psk="MACLEWIFI"
}Shairport est une implémentation libre d'un serveur RAOP qui est lui même à la base des Airport Express d'Apple. Il n'implémente, pour l'instant, que la version 1.0 d'Airplay (prise en charge des flux audio mais pas de vidéo ni de photo).
L'installation se fait en 5 commandes:
sudo aptitude install git libao-dev libssl-dev libcrypt-openssl-rsa-perl libio-socket-inet6-perl libwww-perl avahi-utils git clone https://github.com/albertz/shairport.git shairport cd shairport make sudo make install
Pour tester Shairport, il suffit de lancer:
/shairport.pl -a ShairPort
Si, comme moi, vous avez l'erreur suivante qui s'affiche:
Can't locate Net/SDP.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.14.2 /usr/local/share/perl/5.14.2 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.14 /usr/share/perl/5.14 /usr/local/lib/site_perl .) at ./shairport.pl line 48. BEGIN failed--compilation aborted at ./shairport.pl line 48.
Alors, il faudra en plus saisir une sixième commande pour finaliser l'installation:
sudo cpan install Net::SDP
Pour automatiser le lancement de ShairPort au démarrage de votre Raspberry Pi:
sudo cp ./shairport.init.sample /etc/init.d/shairport sudo chmod a+x /etc/init.d/shairport
Note: il est possible d'éditer le "nom" de votre borne Airplay en modifiant l'option -a dans le script:
DAEMON_ARGS="-w $PIDFILE -a ShairPort"
Il ne reste plus qu'à lancer le démon:
sudo update-rc.d shairport defaults sudo service shairport start
Arrivez à ce stade (bravo si vous êtes encore là), vous devriez pouvoir détecter votre borne Airplay ShairPlay à partir de votre iPhone:
Configuration de l'iPhone pour utiliser la borne Airplay (Spotify à gauche et iTunes à droite)
En branchant votre casque | chaîne sur la sortie analogique (prise jack) du Raspberry, vous allez entendre le son émis par votre iPhone.
Avec un <pub> Glances </pub> lancé sur le Raspberry, on peut constater, avec une liaison réseau filaire la faible consommation CPU en utilisation et un débit de streaming audio de 1Mbps:
Par contre cette consommation grimpe à plus de 60% si vous utilisez un dongle Wifi. En effet, le protocole WPA implique un déchiffrement des données non négligeable pour le Raspberry.
Si fonctionnellement on est arrivés à notre objectif, ce n'est pas cas pour la qualité audio. En effet, la sortie analogique est incompatible avec une écoute Hifi.
Heureusement pour moi et pour mes oreilles, mon DAC (Cambridge Audio DacMagic) dispose d'une entrée USB. Si ce n'est pas votre cas, il existe pas mal de solutions plus ou moins chères sur le marché.
Pour forcer le Raspberry à utiliser le DAC (sortie USB) comme carte son, il faut éditer le fichier /etc/modprobe.d/alsa-base.conf en commentant une première ligne et en ajoutant une deuxième:
#options snd-usb-audio index=-2 options snd-usb-audio nrpacks=1
Après un dernier redémarrage, votre borne Airplay est enfin prête !
Update (28/04/2013): Pour vérifier que tout est configuré comme attendu, le plus simple est d'utiliser la commande aplay -l qui va afficher la liste des cartes sons de votre Raspberry Pi. On doit retrouver la "carte audio USB en premier" puis la classique carte intégrée bcm2835 en second:
pi@raspberrypi $ aplay -l **** List of PLAYBACK Hardware Devices **** card 0: Set [C-Media USB Headphone Set], device 0: USB Audio [USB Audio] Subdevices: 0/1 Subdevice #0: subdevice #0 card 1: ALSA [bcm2835 ALSA], device 0: bcm2835 ALSA [bcm2835 ALSA] Subdevices: 8/8 Subdevice #0: subdevice #0 Subdevice #1: subdevice #1 Subdevice #2: subdevice #2 Subdevice #3: subdevice #3 Subdevice #4: subdevice #4 Subdevice #5: subdevice #5 Subdevice #6: subdevice #6 Subdevice #7: subdevice #7
Ma configuration fonctionne maintenant sans problème depuis quelques jours. Je suis justement en train d'écouter ma Playlist Spotify 2013 en rédigeant ce billet.
Seul problème rencontré: il faut que je redémarre mon Raspberry quand je désactive et réactive le Wifi sur ma Freebox. Si vous avez des idées, je suis preneur.
Quelques liens en bonus:
Cet article Utiliser votre Raspberry Pi comme borne Airplay est apparu en premier sur Le blog de NicoLargo.
Evolution pas si mineure que cela pour Glances, l'outil de supervision système, que je viens de publier en version 1.6.1. Cette version est sûrement la plus stable et la plus facile à faire évoluer (en prévision des futures raodmaps 1.7 puis 2.0). Un grand merci à Alessio Sergi, contributeur depuis maintenant pas mal de temps sur Glances et surtout Jon Renner pour cette version qui a effectué un gros et bon boulot.
La liste complète est disponible dans le ChangeLog, mais on peut retenir:
Toutes les informations sont disponibles sur la page officielle de Glances mais pour ceux qui ont installé une ancienne version via Pypi, il suffit de saisir la commande:
sudo pip install --upgrade Glances
Ce que j'aime avec Glances, c'est l'écosystème qui est en train de se construire autour de ce projet. J'ai d'ailleurs en préparation un billet pour parler de tous les projets gravitant dans cette sphère. Mais dès aujourd'hui je voudrais en mentionner deux:
Je suis bien sûr preneur de vos remarques/avis sur cette nouvelles version de Glances.
Les commentaires ci-dessous sont fait pour cela 
Cet article Glances 1.6.1 est dans les bacs est apparu en premier sur Le blog de NicoLargo.
Lors de la dernière session de la commission open-source de la Telecom Valley, Pascal Flamand, directeur de Janua, a partager avec nous une découverte qu'il a fait dernièrement sur le Web: TLDRLegal. C'est un site permettant de rechercher, consulter, vulgariser et comparer un nombre important de licences open-source. Comme je cherchais également un site équivalent depuis un bon moment, je me suis dis que cela pourrait également intéresser certains de mes lecteurs .
La page principale se présente sous la forme d'un moteur de recherche:
Le site est actuellement en version "bêta" et le nombre de licences référencées augmente régulièrement.
Après une recherche on obtient des informations synthétiques mais aussi le texte intégral de la licence:
On peut également combiner deux licences pour voir si elles sont compatibles et les contraintes / avantages que cette licence combinée propose alors:
Fin de ce rapide billet.
Il ne vous reste plus qu'à bookmarker le lien: http://www.tldrlegal.com
Si vous connaissez un site équivalent en Francais, je suis preneur !
Cet article Consulter et comparer les licences open-source est apparu en premier sur Le blog de NicoLargo.
Sur une idée originale pompée honteusement sur le blog de Bryan Kennedy.
La virtualisation ou la possibilité d'acheter des machines à bas prix comme le Raspberry implique le fait que l'installation de serveurs devient une tâche de plus en plus fréquente. Afin d'éviter les grossières erreurs qui peuvent rapidement devenir fatales si la machine est exposée au réseau Internet, voici les actions que j'effectue systématiquement sur mes systèmes d'exploitations Debian ou Ubuntu Server.
Si vous suivez ce blog, vous savez que je suis un gros fainéant pour ce genre de tâches récurrentes. J'ai donc écrit un ensemble de scripts permettant d'effectuer les actions de "post installation". J'ai également commencé à regarder du coté des systèmes de gestion de configuration comme Puppet qui sont des solutions à utiliser en priorité si vous avez un parc informatique important.
L'objectif de ce billet est donc pédagogique pour partager avec vous les actions à effectuer et, je l'espère, en apprendre de nouvelles.
Assez de palabres, place au clavier...
Je parle bien évidemment ici des comptes utilisateurs qu'il va falloir sécuriser. On commence par le compte root qui ne sera PAS (jamais, c'est mal) utilisé directement pour vous connecter sur votre machine. Lors de l'installation du système, il faut saisir un mot de passe sécurisé, c'est à dire assez long avec un mélange de lettres, de chiffres et d'autres caractères mais sans utiliser des mots connus ou des suites de chiffres. Vous n'avez pas besoin de connaitre ce mot de passe par coeur mais il faudra le conserver bien au chaud.
Une fois logué sur la machine (on durant la phase d'installation du serveur), on commence par créer un utilisateur principal que l'on utilisera pour se connecter à la machine.
J'ai choisi morpheus pour illustrer mon billet.
useradd morpheus mkdir /home/morpheus
La suite des opérations sera donc faite à partir de cet utilisateur.
SSH est devenu le mode d'accès le plus utilisé pour accéder aux serveurs GNU/Linux. Par défaut, il propose un contrôle d'accès par nom d'utilisateur et mot de passe. J'essaye au maximum d'éviter cette solution. J'utilise le système d'authentification par clé publique qui est un peu plus lourde à mettre en oeuvre et à administrer mais qui offre un niveau de sécurité plus important.
Pour ajouter la clé publique de mon PC avec lequel je vais me connecter au serveur, il suffit de lancer la commande suivante à partir de cette machine:
ssh-copy-id morpheus@monserveur
Puis on force l'utilisation de l'authentification par clé publique et on ferme ensuite cette porte à l'utilisateur root:
sudo vim /etc/ssh/sshd_config PasswordAuthentication no PermitRootLogin no
Attention: l'authentification par nom d'utilisateur / mot de passe sera désactivée pour les accès SSH.
On relance ensuite le daemon SSH:
sudo service ssh restart
3) Contrôler les entrées avec Fail2ban
Une fois le daemon SSH sécurisé, il faut ensuite ajouter une couche permettant de contrôler plus finement les accès. J'utilise pour cela Fail2ban que j'ai abordé plus précisément dans un précédant billet. Dans notre sujet du jour, je vais configurer Fail2ban pour bloquer, pendant 5 minutes, l'accès à SSH à un utilisateur qui se trompe 3 fois de mot de passe.
On commence par installer fail2ban:
sudo apt-get-install fail2ban
On va ensuite éditer le fichier /etc/fail2ban/jail.conf pour le configurer comme l'on souhaite:
[ssh] enabled = true port = ssh filter = sshd action = iptables[name=SSH, port=ssh, protocol=tcp] logpath = /var/log/auth.log maxretry = 3 bantime = 300
On relance ensuite le service pour prendre en compte la configuration:
sudo service fail2ban restart
Comme nous l'avons vu dans le point précédant, Fail2ban utilise le Firewall IPtable qui part défaut laisse passer l'ensemble des flux. J'applique systématiquement une configuration beoucoup plus restrictive qui autorise les flux SSH entrant (pour l'accès à distance) et HTTP/HTTPs/DNS sortant (pour la mise à jour de mon serveur).
J'utilise pour cela un script de démarrage maison:
sudo wget --no-check-certificate -O /etc/init.d/firewall.sh https://raw.github.com/nicolargo/debianpostinstall/master/firewall.sh sudo chmod a+x /etc/init.d/firewall.sh
que je lance au démarrage de la machine (et aussi immédiatement):
sudo update-rc.d firewall.sh defaults 20 sudo service firewall start
Il est bien sûr possible d'adapter ce script à vos besoins de flux entrants et sortants en éditant les lignes suivantes:
# Services that the system will offer to the network TCP_SERVICES="22" # SSH only UDP_SERVICES="" # Services the system will use from the network REMOTE_TCP_SERVICES="80 443" # web browsing REMOTE_UDP_SERVICES="53" # DNS
Maintenir à jour ses serveurs est une tâche à la fois indispensable et rébarbative. Il y a ici deux écoles possibles. La première est d'utiliser un logiciel comme unattended-upgrades qui va installer automatiquement pour vous les mises à jours de sécurités ou même l'ensemble de votre système. C'est une solution élégante mais qui n'est pas sans risque si un pépin arrive suite à une mise à jour alors que vous êtes loin de vous machines. J'opte donc pour la seconde solution, basée sur cron-apt, qui va me notifier par mail les mises à jours à effectuer sur mes machines.
On installe cron-apt avec la commande:
sudo apt-get install cron-apt
Puis on configure l'adresse mail de destination des messages de notifications dans le fichier /etc/cron-apt/config:
MAILTO="bibi+monserveur@gmail.com"
Note: comme vous pouvez le lire, j'utilise une adresse Gmail bibi@gmail.com pour la réception de mes notifications. J'y ajoute +monserveur (qui sera ignoré par Gmail) afin de pouvoir facilement les filtrer.
On relance le service pour prendre en compte la configuration:
sudo service cron-apt restart
Les notifications seront envoyés par défaut toutes les nuits à 4h du matin.
A ce stade vous avez un serveur disposant d'une sécurité de base qui va le protéger de la grande majorité des attaques que l'on peut trouver sur Internet. Il ne reste plus qu'à installer Logwatch, un outil permettant d'analyser les logs et ainsi de remonter par mail des rapports permettant d'analyser des tentatives d'intrusions éventuelles.
La mise en place est assez simple.
sudo apt-get install logwatch
Puis on configure l'adresse mail de destination des messages de notifications dans le fichier /etc/cron-apt/config:
#execute /usr/sbin/logwatch --output mail --mailto bibi+monserveur@gmail.com --detail high
On relance le service pour prendre en compte la configuration:
sudo service cron-apt restart
Les notifications seront envoyés par défaut toutes les nuits.
Nous arrivons à la fin de ce billet avec une machine à l'épreuve d'une exposition à Internet sans risque de se faire hacker par le premier "script kiddie" venu.
A vous de nous faire partager vos techniques, méthodes que vous appliquez sur vos nouveaux serveurs !
Cet article Mes 5 premières minutes sur un serveur Debian est apparu en premier sur Le blog de NicoLargo.