fix again
This commit is contained in:
parent
4d1762b20d
commit
af410ce0bd
Binary file not shown.
Binary file not shown.
Binary file not shown.
Binary file not shown.
|
|
@ -6,7 +6,7 @@ template: post
|
|||
tags: bricolage,DIY,do it yourself,fablab,libre,linux,planet libre,Tribunes
|
||||
---
|
||||
|
||||
Quand on parle de DIY, on ne peut pas louper la grande vague des fablabs, hackerspace, et autres champignons de la même farine. Il s'agit des initiatives destinées à donner au peuple le moyen d'apprendre la technique, de se regrouper, de construire, de réparer, d'améliorer et de recycler à peu près n'importe quoi. Ce que peu de personnes savent, c'est qu'il existent plusieurs philosophie au sein de ce groupe de joyeux bricoleurs, des philosophies qui sont parfois tellement différentes que cela tourne parfois au conflit politique et social.
|
||||
Quand on parle de DIY, on ne peut pas louper la grande vague des fablabs, hackerspace, et autres champignons de la même farine. Il s'agit des initiatives destinées à donner au peuple le moyen d'apprendre la technique, de se regrouper, de construire, de réparer, d'améliorer et de recycler à peu près n'importe quoi. Ce que peu de personnes savent, c'est qu'il existent plusieurs philosophies au sein de ce groupe de joyeux bricoleurs, des philosophies qui sont parfois tellement différentes que cela tourne parfois au conflit politique et social.
|
||||
|
||||
Depuis quelques semaines, je m'intègre au sein de l'activité de ces ateliers communautaires. J'ai pris connaissances des enjeux de chaque parti, j'ai noté les tensions qui peuvent les opposer, et dans chacun deux, il y a des ensembles d'éléments qui me plaisent et d'autres qui me déplaisent.
|
||||
|
||||
|
|
|
|||
|
|
@ -14,13 +14,12 @@ Pour faciliter l'installation, Jitsi met à disposition des dépôts APT permett
|
|||
|
||||
J'ai donc déployé une nouvelle VM sous Debian Stretch toute nue et j'ai installé les packets.
|
||||
|
||||
echo 'deb https://download.jitsi.org stable/' >> /etc/apt/sources.list.d/jitsi-stable.list
|
||||
|
||||
wget -qO - https://download.jitsi.org/jitsi-key.gpg.key | apt-key add -
|
||||
|
||||
apt update
|
||||
|
||||
```
|
||||
echo 'deb https://download.jitsi.org stable/' >> /etc/apt/sources.list.d/jitsi-stable.list
|
||||
wget -qO - https://download.jitsi.org/jitsi-key.gpg.key | apt-key add -
|
||||
apt update
|
||||
apt install jitsi-meet
|
||||
```
|
||||
|
||||
L'installeur pose ensuite quelques questions :
|
||||
|
||||
|
|
|
|||
|
|
@ -37,14 +37,15 @@ HAProxy est organisé en _frontends_ et en _backends_ : un _frontend_ est la fa
|
|||
|
||||
Prenons un exemple de configuration simple. On passera les directives globales HAProxy qui ne sont pas intéressantes et présentent peu de valeur ajoutée. Et bien entendu, on part du principe que vos frontaux sont configurés, écoutent sur des adresses locales et tout le toutim.
|
||||
|
||||
frontend mon\_super\_site
|
||||
bind \*:80
|
||||
```
|
||||
frontend mon_super_site
|
||||
bind *:80
|
||||
mode http
|
||||
|
||||
acl url-back-office path\_dir /admin
|
||||
acl url-back-office path_dir /admin
|
||||
|
||||
use\_backend back-office if url-back-office
|
||||
default\_backend mes-frontaux
|
||||
use_backend back-office if url-back-office
|
||||
default_backend mes-frontaux
|
||||
|
||||
backend back-office
|
||||
server backoffice 192.168.0.14:80
|
||||
|
|
@ -54,6 +55,7 @@ backend mes-frontaux
|
|||
server backoffice 192.168.0.11:80
|
||||
server backoffice 192.168.0.12:80
|
||||
server backoffice 192.168.0.13:80
|
||||
```
|
||||
|
||||
Dans cette configuration, le _frontend_ écoute sur toutes les adresses IP attribuées au serveur, sur le port 80 (donc pour le moment, uniquement du trafic en clair). Le mode HTTP signifie qu'on utilise ce _frontend_ pour répartir du flux web, et non pas comme le mode TCP ou l'on redirige un flux TCP intouché.
|
||||
|
||||
|
|
@ -63,7 +65,9 @@ Le _backend_ `back-office` est très simple car il ne comporte qu'un serveur. Le
|
|||
|
||||
Et voilà, vous avez un répartiteur de charge. Si vous avez un certificat SSL, vous pouvez ajouter une ligne au _frontend_ :
|
||||
|
||||
bind \*:443 ssl cert /chemin/vers/mon/certificat.pem
|
||||
```
|
||||
bind *:443 ssl cert /chemin/vers/mon/certificat.pem
|
||||
```
|
||||
|
||||
Sauf que ça ne marchera pas. En tout cas pas tant que vous aurez mis votre certificat sous la forme attendue par HAProxy, à savoir la clef privée et le certificat dans le même fichier. Nous verrons cela dans la seconde partie, qui vous expliquera également (et finalement) comment diable utiliser Let's Encrypt avec ce bidule. En tout cas, si vous êtes perspicace, vous vous doutez que ça tournera en partie autour des ACL, car il y a bien une raison pour laquelle c'est le seul élément en gras de l'article.
|
||||
|
||||
|
|
|
|||
|
|
@ -20,7 +20,9 @@ On n'a que l'embarras du choix pour trouver un serveur web sachant servir du bon
|
|||
|
||||
Première étape, il faut dire à OpenBSD d'activer le service.
|
||||
|
||||
echo 'httpd\_flags=""' >> /etc/rc.conf.local
|
||||
```
|
||||
echo 'httpd_flags=""' >> /etc/rc.conf.local
|
||||
```
|
||||
|
||||
Ainsi on pourra démarrer le service, et il sera démarré à chaque démarrage de l'OS.
|
||||
|
||||
|
|
@ -28,14 +30,18 @@ Ensuite, il va nous falloir créer un dossier qui va accueillir les fichiers du
|
|||
|
||||
La configuration de notre httpd sera on ne peut plus simple :
|
||||
|
||||
```
|
||||
server "default" {
|
||||
listen on 127.0.0.1 port 1375 #ça fait "let's" en l33t
|
||||
root "/htdocs/webroot"
|
||||
}
|
||||
```
|
||||
|
||||
Démarrons le service :
|
||||
|
||||
```
|
||||
/etc/rc.d/httpd start
|
||||
```
|
||||
|
||||
Notre serveur statique est prêt.
|
||||
|
||||
|
|
@ -45,23 +51,26 @@ Il faut dire à HAProxy de rediriger les requêtes ACME vers notre serveur stati
|
|||
|
||||
Pour ça, on va définir un _backend_ dédié à Let's Encrypt, vers lequel seront redirigés tous les flux ACME reçus sur les _frontends_ qui nous intéressent.
|
||||
|
||||
```
|
||||
backend letsencrypt-backend
|
||||
server letsencrypt 127.0.0.1:1375
|
||||
```
|
||||
|
||||
Propre. Syntaxe explicite, pas besoin d'expliquer je pense. Je fais juste remarquer qu'en plus de nommer le _backend_ globalement, je donne un nom au serveur du _backend_ même si ici il n'a aucune forme d'importance, il ne sera jamais appelé ailleurs dans le fichier, c'est néanmoins obligatoire sur HAProxy. Enfin, un nom clair est toujours profitable, car il est éventuellement utilisé dans ses logs, ses statistiques et il rend la lecture du fichier de conf plus facile.
|
||||
|
||||
Le _backend_ est prêt, c'est excellent, mais encore faut-il l'utiliser. Pour être exact, on ne va l'utiliser que si l'URL demandée correspond au chemin classique demandé par le validateur ACME, à savoir `/.well-known/acme-challenge/`. Reprenons l'exemple de la dernière fois, modifions-le de la sorte :
|
||||
|
||||
frontend mon\_super\_site
|
||||
bind \*:80
|
||||
```
|
||||
frontend mon_super_site
|
||||
bind *:80
|
||||
mode http
|
||||
|
||||
acl url-back-office path\_dir /admin
|
||||
acl letsencrypt-acl path\_beg /.well-known/acme-challenge/
|
||||
acl url-back-office path_dir /admin
|
||||
acl letsencrypt-acl path_beg /.well-known/acme-challenge/
|
||||
|
||||
use\_backend back-office if url-back-office
|
||||
use\_backend letsencrypt-backend if letsencrypt-acl
|
||||
default\_backend mes-frontaux
|
||||
use_backend back-office if url-back-office
|
||||
use_backend letsencrypt-backend if letsencrypt-acl
|
||||
default_backend mes-frontaux
|
||||
|
||||
backend back-office
|
||||
server backoffice 192.168.0.14:80
|
||||
|
|
@ -74,12 +83,15 @@ backend mes-frontaux
|
|||
|
||||
backend letsencrypt-backend
|
||||
server letsencrypt 127.0.0.1:1375
|
||||
```
|
||||
|
||||
On a ajouté une ACL et une directive `use_backend`. Rappelez-vous, une ACL est tout simplement une condition, ici elle porte sur le chemin de l'URL. Rien de nouveau, on a déjà expliqué le concept.
|
||||
|
||||
On recharge le schmilblick :
|
||||
|
||||
```
|
||||
/etc/rc.d/haproxy reload
|
||||
```
|
||||
|
||||
On est prêt à générer notre premier certificat. Mais on ne va pas le faire tout de suite. Comme vous vous en souvenez, HAProxy veut ses certificats sous une forme un peu spécifique, il nous faut donc traiter le certificat dès qu'il a été généré, et pour ça on va faire un peu de scripting. On pourrait déjà générer le certificat sans le script de post-traitement, mais si on faisait ça, on devrait ensuite éditer la configuration d'acme.sh et c'est un peu barbant, sachant que la commande qui génère le premier certificat génère également par magie la configuration associée pour les renouvellements. Donc ce serait stupide.
|
||||
|
||||
|
|
@ -89,15 +101,17 @@ Rien de bien compliqué, je vous rassure. Le principe est simple : HAProxy n’a
|
|||
|
||||
Le script est très simple. Vous pouvez bien entendu le mettre où bon bous semble, pour ma part j'ai décidé de le mettre dans `/etc/haproxy/generate-ssl.sh`.
|
||||
|
||||
```
|
||||
#!/bin/sh
|
||||
|
||||
SITE=$1
|
||||
LE\_CERT\_LOCATION=/root/.acme.sh/$SITE
|
||||
HA\_CERT\_LOCATION=/etc/haproxy/ssl
|
||||
LE_CERT_LOCATION=/root/.acme.sh/$SITE
|
||||
HA_CERT_LOCATION=/etc/haproxy/ssl
|
||||
|
||||
cat $LE\_CERT\_LOCATION/fullchain.cer $LE\_CERT\_LOCATION/$SITE.key > $HA\_CERT\_LOCATION/$SITE.haproxy.pem
|
||||
cat $LE_CERT_LOCATION/fullchain.cer $LE_CERT_LOCATION/$SITE.key > $HA_CERT_LOCATION/$SITE.haproxy.pem
|
||||
|
||||
/etc/rc.d/haproxy reload
|
||||
```
|
||||
|
||||
`LE_CERT_LOCATION` représente l'endroit où seront générés les certificats par acme.sh (il s'agit ici de l'emplacement par défaut, mais vous pouvez changer ce chemin à condition d'utiliser l'option adéquate lors de la génération du premier certificat).
|
||||
|
||||
|
|
@ -115,11 +129,15 @@ Remarquez que vous pouvez générer un certificat couvrant plusieurs domaines à
|
|||
|
||||
Une fois la commande effectuée avec succès (ça peut prendre une minute ou deux), votre certificat est généré, il vous faut encore ajouter le certificat dans la configuration du _frontend_ comme il suit :
|
||||
|
||||
bind \*:443 ssl cert /etc/haproxy/ssl/mon-super-site.com.haproxy.pem
|
||||
```
|
||||
bind *:443 ssl cert /etc/haproxy/ssl/mon-super-site.com.haproxy.pem
|
||||
```
|
||||
|
||||
Comme il s'agit de la première génération et non d'un renouvellement, il est nécessaire d'appliquer le script à la main.
|
||||
|
||||
```
|
||||
/etc/haproxy/generate-ssl.sh mon-super-site.com
|
||||
```
|
||||
|
||||
Vérifiez, et pleurez de joie. Votre certificat est déployé et fonctionnel. C'est magnifique.
|
||||
|
||||
|
|
@ -127,7 +145,9 @@ Vérifiez, et pleurez de joie. Votre certificat est déployé et fonctionnel. C'
|
|||
|
||||
Ultime étape, celle qui fait prendre tout son sens à la révolution Let's Encrypt, celle qui fait qu'on peut oublier sans scrupule que tel ou tel site a un certificat proche de l'expiration, il s'agit du renouvellement automatique. Pas de subtilités, une simple ligne dans la crontab fait l'affaire. Et en plus, si je ne dis pas de bêtises, acme.sh s'occupe tout seul d'ajouter cette ligne.
|
||||
|
||||
26 0 \* \* \* "/root/.acme.sh"/acme.sh --cron --home "/root/.acme.sh" > /dev/null
|
||||
```
|
||||
26 0 * * * "/root/.acme.sh"/acme.sh --cron --home "/root/.acme.sh" > /dev/null
|
||||
```
|
||||
|
||||
La commande sera lancée tous les jours à minuit vingt-six, libre à vous de changer cet horaire. acme.sh sera assez intelligent pour savoir si votre certificat a besoin d'un coup de jeune ou non, donc rassurez vous, il n'y aura pas un renouvellement par jour.
|
||||
|
||||
|
|
|
|||
|
|
@ -14,7 +14,9 @@ Il s'agit de la possibilité d'afficher la météo dans son terminal comme un pa
|
|||
|
||||
Pour l'avoir directement dans votre terminal, utilisez tout simplement le programme `curl` :
|
||||
|
||||
```
|
||||
curl wttr.in
|
||||
```
|
||||
|
||||
Et voilà le résultat :
|
||||
|
||||
|
|
@ -22,7 +24,9 @@ Et voilà le résultat :
|
|||
|
||||
La localisation est trouvée automatiquement à l'aide de l'IP. Si vous souhaitez voir la météo d'une ville, par exemple Paris, procédez comme il suit :
|
||||
|
||||
```
|
||||
curl wttr.in/paris
|
||||
```
|
||||
|
||||
Et si vous aimez vraiment, vous pouvez l'ajouter à votre fichier `.bashrc` afin d'avoir la météo à chaque nouveau terminal.
|
||||
|
||||
|
|
|
|||
|
|
@ -18,14 +18,16 @@ En réalisant ça, j'étais d'abord outré, et ça a même remis en question mon
|
|||
|
||||
Du coup, il suffit de posséder un certificat adapté au nom de domaine qui pointe vers votre serveur (chose très facile en utilisant [Let's Encrypt](/posts/securiser-ses-sites-web-avec-lets-encrypt/), pour peu que vous ayez un serveur web qui sert ce nom de domaine) et il vous est possible d'envelopper ce flux dans un tunnel TLS. Voici ce que j'ai ajouté dans ma configuration stunnel :
|
||||
|
||||
\[bitlbee\]
|
||||
```
|
||||
[bitlbee]
|
||||
accept = 6697
|
||||
connect = 6667
|
||||
cert = /etc/letsencrypt/live/mon.domaine.tld/fullchain.pem
|
||||
key = /etc/letsencrypt/live/mon.domaine.tld/privkey.pem
|
||||
```
|
||||
|
||||
Le port 6667 est le port non sécurisé, et le port 6697 est le port sécurisé. Elle est pas belle la vie ?
|
||||
|
||||
De plus stunnel peut fonctionner dans l'autre sens, c'est à dire servir du contenu en clair à partir d'un canal sécurisé, ce qui est pratique quand derrière on a pas de client compatible avec TLS.
|
||||
|
||||
Bon, revenons sur les raisons qui poussent un programme à ne pas adopter la sécurisation des flux. Dans le cas de bitlbee, comme je l'ai dit plus tôt, c'est un serveur destiné à être atteint en local. De plus, certains projets choisissent de ne pas implémenter le chiffrement et de recommander explicitement des solutions comme stunnel pour ne pas être responsables d'une éventuelle faille dans leur implémentation. Et aussi parce que c'est gonflant de faire de la sécu quand le projet à l'origine l'a absolument pas de rapport, il faut le reconnaître.
|
||||
Bon, revenons sur les raisons qui poussent un programme à ne pas adopter la sécurisation des flux. Dans le cas de bitlbee, comme je l'ai dit plus tôt, c'est un serveur destiné à être atteint en local. De plus, certains projets choisissent de ne pas implémenter le chiffrement et de recommander explicitement des solutions comme stunnel pour ne pas être responsables d'une éventuelle faille dans leur implémentation. Et aussi parce que c'est gonflant de faire de la sécu quand le projet à l'origine n'a absolument pas de rapport, il faut le reconnaître.
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@ Enfin je vous conseille quand même de faire la mise à jour bien entendu, pour
|
|||
|
||||
Ce que je veux dire, c'est qu'en mettant à jour votre distribution, attendez-vous à des trucs qui vont péter sévère. Faites-ça quand vous n'avez rien d'autre à faire et quand un minimum de choses vitales sont attendues de votre serveur par vos utilisateurs. Va y avoir du vilain.
|
||||
|
||||
[](%assets_url%/2017/07/debian.jpg)
|
||||
|
||||
|
||||
Donc oui j'aime Debian, mais Debian me gonfle parfois. Notamment ce comportement très fâcheux que je viens de découvrir aujourd'hui même concernant OpenVPN.
|
||||
|
||||
|
|
@ -26,19 +26,27 @@ J'ai donc une tête de pont que j'ai récemment mis à jour sur Stretch. Tout se
|
|||
|
||||
L'élément fautif : le service Systemd a changé bien en profondeur. Sous Jessie, les fichiers nécessaires pour l'établissement du VPN (configurations, certificats, clefs...) se trouvaient alors modestement dans `/etc/openvpn`, et ne faisait pas la distinction entre configurations clients et configurations serveurs. Le service utilisé pour démarrer OpenVPN était nommé tout simplement openvpn.service, et son boulot était uniquement de lancer une instance d'OpenVPN par fichier de configuration (dont le nom se terminait par `.conf`) dans ce dossier. Pour lancer openvpn, il suffisait donc de la commande simple suivante :
|
||||
|
||||
```
|
||||
systemctl start openvpn
|
||||
```
|
||||
|
||||
Sous Stretch, tout a été changé. Premièrement, le service a changé de nom très salement. Par salement, je veux dire que l'ancien nom existe toujours, mais a été remplacé par un service qui ne fait absolument rien (il lance le programme `/bin/true`, programme dont l'utilité crève les yeux), ce qui fait que ce changement de service implique non seulement une rupture de ce service si aucune action n'est prise par la suite, mais également que c'est très difficile de s'en rendre compte, le service ancien `openvpn.service` étant diagnostiqué par le système comme actif et bien portant. Donc, la nouvelle forme de ce service est en fait un couple de service, `openvpn-client@.service` et `openvpn-server@.service`, le premier se chargeant de lancer OpenVPN en temps que client, et le second en temps que serveur. Mais ce n'était pas fini : les configurations VPN devaient être déplacées aux nouveaux endroits adéquats, et la ségrégation entre clients et serveurs a été instaurée : désormais, les configurations clients doivent aller dans `/etc/openvpn/client` et les configurations serveurs dans `/etc/openvpn/server`. Mais ce n'est encore pas tout : ces nouveaux services ne s'invoquent plus de la même manière. On doit maintenant spécifier le nom de la configuration dans la commande qui démarre le service. Par exemple, pour une configuration serveur qui s'appelle `hashtagueule.conf` (dûment placée dans `/etc/openvpn/server`), la commande pour démarrer le service associé est donc :
|
||||
|
||||
```
|
||||
systemctl start openvpn-server@hashtagueule
|
||||
```
|
||||
|
||||
Pour couronner le tout, un bug de configuration, oui un bug, et non une modification de comportement, s'est glissée dans le fichier de service `openvpn-serveur@.service`. Ce fichier comporte la ligne suivante :
|
||||
|
||||
```
|
||||
LimitNPROC=10
|
||||
```
|
||||
|
||||
Cette directive est utile pour contrôler le nombre maximum de processus exécutés par un service, pour éviter dans certain cas l'explosion du load du serveur. Sauf qu'ici, cette valeur est beaucoup trop petite. On se retrouve alors avec l'erreur suivante consignée dans les logs :
|
||||
|
||||
openvpn\_execve: unable to fork: Resource temporarily unavailable
|
||||
```
|
||||
openvpn_execve: unable to fork: Resource temporarily unavailable
|
||||
```
|
||||
|
||||
Ce qui veut dire que le système refuse la création d'un nouveau processus pour ce service. Je me résolus donc à réparer salement et de manière non safisfaisante en changeant la valeur 10 par 100 (aucune idée si c'est carrément trop), et enfin, le service a accepté de fonctionner.
|
||||
|
||||
|
|
|
|||
|
|
@ -136,7 +136,7 @@ server{
|
|||
listen [::]:80;
|
||||
server_name bidule.machin.truc;
|
||||
|
||||
location ~ ^/.well-known/acme-challenge(/.\*)?$ {
|
||||
location ~ ^/.well-known/acme-challenge(/.*)?$ {
|
||||
root /etc/letsencrypt/webrootauth;
|
||||
default_type text/plain;
|
||||
}
|
||||
|
|
@ -158,7 +158,7 @@ server {
|
|||
|
||||
root /var/apk;
|
||||
|
||||
location ~ ^/.well-known/acme-challenge(/.\*)?$ {
|
||||
location ~ ^/.well-known/acme-challenge(/.*)?$ {
|
||||
root /etc/letsencrypt/webrootauth;
|
||||
default_type text/plain;
|
||||
}
|
||||
|
|
@ -243,13 +243,13 @@ REPO=/var/apk
|
|||
LOG_GPU=/var/log/gpupd.log
|
||||
LOG_FDROID=/var/log/fdroid.log
|
||||
|
||||
echo -e "\n\*\*\*\*\*\*\*\*\*\* $(date)\n" >> $LOG_GPU
|
||||
echo -e "\n********** $(date)\n" >> $LOG_GPU
|
||||
|
||||
$GPUPD -c $CONFIG -v $REPO/repo >> $LOG_GPU 2>&1
|
||||
|
||||
cd $REPO
|
||||
|
||||
echo -e "\n\*\*\*\*\*\*\*\*\*\* $(date)\n" >> $LOG_FDROID
|
||||
echo -e "\n********** $(date)\n" >> $LOG_FDROID
|
||||
|
||||
fdroid update --create-metadata >> $LOG_FDROID 2>&1
|
||||
```
|
||||
|
|
|
|||
|
|
@ -24,27 +24,33 @@ Niveau installation, il vous suffit d'installer MPD, présent sur la très grand
|
|||
|
||||
Il est important d'ajouter le support de votre bibliothèque musicale dans le fichier `/etc/fstab` du RPi, cela permettra bien entendu de monter votre disque dur USB ou votre volume NFS dès le démarrage de l'appareil. Dans le cas d'un partage NFS, vous pouvez par exemple écrire :
|
||||
|
||||
```
|
||||
192.168.0.5:/chemin/vers/dossier/musique /data nfs rsize=8192,wsize=8192,timeo=14,intr
|
||||
```
|
||||
|
||||
En remplaçant bien sûr l'IP de votre serveur NFS et le chemin du dossier musique sur ce serveur.
|
||||
|
||||
Ensuite vous aurez besoin de configurer MPD. Direction le fichier `/etc/mpd.conf` pour dans un premier temps dire au lecteur où se trouve votre musique.
|
||||
|
||||
music\_directory "/mnt"
|
||||
```
|
||||
music_directory "/mnt"
|
||||
```
|
||||
|
||||
Le fichier de configuration de MPD est assez bien documenté via le texte commenté. Ainsi vous pourrez personnaliser l'emplacement de vos futures playlists et de la base de donnée par exemple si ça vous chante.
|
||||
|
||||
Partie également importante de ce fichier, la configuration des sorties audio. Si vous n'utilisez pas de DAC externe, vous pouvez laisser sans toucher. Si vous avec un DAC externe supportant de bonnes fréquences d'échantillonnage et que vous avez de la musique haute qualité, il sera intéressant d'y faire figurer :
|
||||
|
||||
audio\_output {
|
||||
```
|
||||
audio_output {
|
||||
type "alsa"
|
||||
name "My ALSA Device"
|
||||
device "hw:CARD=C1,DEV=0"
|
||||
mixer\_type "none"
|
||||
auto\_channels "no"
|
||||
auto\_format "no"
|
||||
auto\_resample "no"
|
||||
mixer_type "none"
|
||||
auto_channels "no"
|
||||
auto_format "no"
|
||||
auto_resample "no"
|
||||
}
|
||||
```
|
||||
|
||||
Le nom de la carte correspond pour le Cambridge DacMagic 100. Pour trouver le nom de votre DAC, vous pouvez par exemple faire usage de la commande `aplay -L`, qui vous listera l'ensemble des périphériques audio et leurs caractéristiques.
|
||||
|
||||
|
|
@ -70,9 +76,7 @@ Ce programme en python donc permet d'afficher les informations de la musique en
|
|||
- Contrôle du lecteur grâce au joystick
|
||||
- **Killer feature** : affichage en temps réel de la puissance sonore via les diodes supplémentaires.
|
||||
|
||||
Mieux que des paroles, voici une vidéo de démonstration.
|
||||
|
||||
\[video width="1920" height="1080" mp4="%assets_url%/2017/03/mpipi2.mp4"\]\[/video\]
|
||||
Mieux que des paroles, voici une [vidéo de démonstration](%assets_url%/2017/03/mpipi2.mp4)
|
||||
|
||||
Je vous invite à allez voir mon [code](https://git.hashtagueule.fr/raspbeguy/dot3k) commenté en détail (en anglais).
|
||||
|
||||
|
|
|
|||
|
|
@ -14,8 +14,10 @@ Nombreux sont les administrateurs frustrés par les efforts de frappe de texte
|
|||
|
||||
Xonsh promet d'allier la robustesse de Bash et l'aisance de Python. Car oui, en Python, on tape en une ligne ce que d'autres langages permettent de faire en 10, pour peu que l'on dispose des bonnes bibliothèques. Xonsh dispose apparemment de plus de commandes internes, ce qui lui permet par exemple d'effectuer des calculs tout simplement en les tapant dans le prompt, sans autre forme de procès, par exemple :
|
||||
|
||||
```
|
||||
root@marvin ~ # 1 + 2 \* 3
|
||||
7
|
||||
```
|
||||
|
||||
On retrouve aussi une grande prise en charge des expressions régulières, utiles pour le _glob_ des noms de fichiers par exemple. De quoi mettre les bons vieux utilitaires comme `grep`, `sed`, `cut` et `awk` à la retraite...
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue