Si vous êtes un habitué de la Raspberry Pi, vous connaissez sans doute la Raspberry Pi Zéro W, une Raspberry Pi certes moins puissante, mais plus petite, moins chère et plus économe en énergie que sa grande sœur la Raspberry Pi 3.

Et bien la fondation Raspberry Pi a annoncé il y a peu une petite mise à jour sur ce modèle très intéressant pour les férus d’embarqué, de domotique ou de robotique. Cette nouvelle version se nommera donc Raspberry Pi Zéro WH, W signifiant toujours « Wireless » et H signifiant lui « Header ».

Cette nouvelle Raspberry Pi Zéro sera commercialisée aux alentours de 15$, donc probablement de 15€ en France. Vous pouvez dès à présent la commander ici chez Kubii.fr

Qu’est-ce qui change par rapport à la Raspberry Pi Zéro W ?

Si vous avez déjà eu l’occasion d’acheter une Raspberry Pi Zéro, ou si vous avez lu notre article dédié à la Raspberry Pi Zéro W, alors vous savez que celle-ci est livrée sans ports GPIO. Pour être plus précis, elle est livrée avec des ports GPIO, mais que vous devrez souder vous même !

Vous l’aurez donc deviné, la différence entre ces deux modèles est donc la présence de ports GPIO soudés sur la Raspberry Pi Zéro WH.

Conséquences : La Raspberry Pi Zéro WH est plus épaisse que la Raspberry Pi Zéro W sans GPIO et donc moins flexible que la Raspberry Pi Zéro W. En contrepartie, elle est plus adaptée pour les débutants, les écoles, etc.

Par ailleurs, sur le papier elle est aussi un petit peu plus chère que la Raspberry Pi Zéro W (comptez 5€ de plus à priori).

Est-il possible d’acheter une Raspberry Pi Zéro WH, y a-t-il des stocks ?

Quand l’on parle de Raspberry Pi Zéro, W, pas W, H ou pas H, pour les habitués la vraie question est la suivante : Quels seront les stocks ? En effet, pour tous les modèles Zéro précédents, si les prix sont très attractifs, il est généralement si difficile de trouver des stocks que la demande surpasse très fortement l’offre, entraînant une énorme montée des prix.

Pour l’instant, il semblerait que la Raspberry Pi Zéro WH se vende bien aux alentours de 15€, et Kubii.fr nous a confirmé que les stocks sont remplis (plusieurs milliers de produits) et qu’il n’y a aucune limite sur le nombre de produits lors de la commande. À priori le Pi Zéro WH semble donc très bien parti niveau disponibilité !

Dans tous les cas, les stocks sont pour l’instant bel et bien disponibles, et vous pouvez achetez une Pi Zéro WH sur leur site en cliquant ici.

La Raspberry Pi Zéro WH vaut elle le coup ?

Pour finir, en voyant l’annonce de cette sortie, nous nous sommes posé la question de savoir si la Raspberry Pi Zéro WH valait ou non le coup.

Honnêtement, nous n’avons pas de réponse définitive à cette question. À notre sens, la Raspberry Pi Zéro WH devient intéressante dans deux ou trois situations :

• Vous ne savez pas souder et ne voulez pas prendre de risque
• Vous devez utiliser une dizaine de Raspberry Pi Zéro W, vous aurez besoin de GPIO, et vous voulez gagner du temps
• La Raspberry Pi W n’est pas disponible

Si vous êtes dans l’une de ces trois situations, nous pensons que la Raspberry Pi Zéro WH est intéressante. Sinon, nous vous conseillerions plutôt de prendre une Raspberry Pi Zéro W normale, d’acheter un fer à souder (parce que ça vous sera forcément utile si vous voulez bidouiller avec de l’électronique), et de souder vous mêmes les GPIO ! Honnêtement, ce n’est pas très compliqué.

Cet article Lancement de la Raspberry Pi Zéro WH, comme la zéro les GPIO en plus. est apparu en premier sur Raspbian-France.

Original post of RaspbianFrance.Votez pour ce billet sur Planet Libre.

OpenBSD nous informe hier d'un correctif pour la libSSL, corrigeant une erreur dans l'échange des données TLS, s'il n'y a pas d'extension, ce qui génère de mauvais bloc d'extension TLS.

Architectures concernées : amd64, arm64, i386

OS Version concernée : 6.2 seulement !

----

# syspatch
Get/Verify syspatch62-004_libssl.tgz 100% |***************************************************************************************************************************|  2515 KB    00:14    
Installing patch 004_libssl

----

Mieux vaut redémarrer votre machine informatique, ensuite...

 

 

Original post of Thuban.Votez pour ce billet sur Planet Libre.

Pour la seconde semaine de l'année 2018, voici 10 liens intéressants que vous avez peut-être ratés, relayés par le Journal du hacker, votre source d’informations pour le Logiciel Libre francophone !

• Une lettre sur Google AMP
• Spectre et Meltdown : explication technique des 3 failles de sécurité et des mesures correctives
• 5 Pièges qui entravent votre productivité et comment en sortir
• Limiter les attaques par force brute sur le service SSH
• Firefox, l'invisible (2017)
• Combien ça coûte de créer une entreprise en 2018 ?
• Sauvegarde et restauration avec Borg
• 20 ans après Mandrake Linux, Gaël Duval présente son nouveau projet : Eelo, le smartphone libre
• En 20 lignes pas plus : gérer les options d'appel de tes scripts bash
• git essentials – 5 – visualiser les changements

Pour ne plus rater aucun article de la communauté francophone, voici :

• Le flux RSS du Journal du hacker
• Le compte Twitter du Journal du hacker
• Le compte Diaspora* du Journal du hacker
• Le compte Mastodon du Journal du hacker

De plus le site web du Journal du hacker est « adaptatif (responsive) ». N’hésitez pas à le consulter depuis votre smartphone ou votre tablette !

Le Journal du hacker fonctionne de manière collaborative, grâce à la participation de ses membres. Rejoignez-nous pour proposer vos contenus à partager avec la communauté du Logiciel Libre francophone et faire connaître vos projets !

Et vous ? Qu’avez-vous pensé de ces articles ? N’hésitez pas à réagir directement dans les commentaires de l’article sur le Journal du hacker ou bien dans les commentaires de ce billet :)

Original post of Journal du hacker.Votez pour ce billet sur Planet Libre.

Présentation LollyPop

 

Bonjour la communauté libriste.

Je n’écris pas beaucoup en ce moment (on est loin des 2 articles par semaine au tout début de cette aventure).

Je vais vous parler d’un sujet que je ne maîtrise pas , la musique (j’écoute plus de musique depuis plusieurs mois).

Je vais vous parler du lecteur de musique « LollyPop ».

Ce lecteur est à la base pour l’environnement de bureau (gnome) qu’on ne présente plus, mais si vous n’avez pas ce (DE)( vous pouvez l’installer et l’utiliser sans problème, c’est juste il me semble une question d’intégration).

Ce logiciel disponible sur gnu/linux

il est disponible pour certaines distributions officiellement comme :

• Fedora
• ArchLinux
• Ubuntu
• Flatpak
• Opensuse
• Freebsd

Autant dire qu’il est accessible facilement par une grande partie de la communauté.

Ce logiciel est disponible sous la licence très connue (GPLv3).

Concernant les fonctionnalités elles sont nombreuses.

• mp3/4, ogg and flac.
• Genre/Cover browsing
• Genre/Artist/Cover browsing
• Search
• Main playlist (called queue in other apps)
• Party mode
• Replay gain
• Cover art downloader
• Context artist view
• MTP sync
• Fullscreen view
• Radios support
• Last.fm support
• Auto install codecs
• HiDPI support
• Tunein support

Ce logiciel a été créé par « Cédric Bellegarde »

La vidéo

Mon avis :

Même si je m’en sers très peu (au moins pour le présenter et faire la vidéo) avec son design qui rafraîchi notre écran , le mode soirée qui semble pas mal (vous permet de filtrer pour que tel album ou style ne passe pas).

Par contre au premier abord le logiciel est assez déroutant peut- être car il est épuré (le principal des boutons est en haut alors que la plupart des logiciels de musique c’est en bas).

Le fait que ça permette d’écouter la radio (régionale ou nationale) c’est une bonne intégration,

par contre, je ne  connais pas ce genre de chose mais on peut utiliser une clé api google , je sais pas si il y a des alternatives open source (d’après ce qui est renseigné c’est pour chercher les jaquettes des albums).

Par contre pour moi soit c’est la clé api qui est déjà limitée ou alors c’est le style de musique qui est pas courant pour Google (la musique japonaise).

Pas grave pour l’utilité que j’en ai.

Pour conclure je dirais que j’aime bien son interface , mais que je m’occupe pas des tags alors je sais que dans un lecteur de musique c’est primordial.

Allez- vous l’installer ou l’utiliser ? Ou si c’est déjà fait , n’hésitez pas à prendre la parole dans les commentaires.

 

Installation :

ArchLinux
yaourt -S lollypop

Liens :

Site officiel

Original post of wilfried caruel.Votez pour ce billet sur Planet Libre.

A l’occasion des failles Spectre et Meltdown, des millions de serveurs vont être redémarrés. On m’a demandé à mon boulot, pourquoi certains serveurs rebootaient en 40s et d’autres en plus de 100s ?

Extinction puis démarrage

Un redémarrage (reboot) est composé de deux phases : l’extinction (shutdown) et le démarrage (boot). Peu de gens s’intéressent à l’extinction de leur pc, normal on arrête de l’utiliser. En revanche le temps de redémarrage d’un serveur est important, plus il sera long, plus longue sera la période d’indisponibilité des services fournis. Pour moi 60s c’est que dalle mais sur un serveur mutualisé avec disons 100 clients dessus, c’est 100 clients qui seront impactés pendant 1 minute. Cette minute devient très importante.

Pour réduire le temps de redémarrage, kexec (1, 2, 3) est l’outil le plus utilisé. Chez Ubuntu il y a Canonical Livepatch qui peut éviter d’avoir à redémarrer. Le démarrage est la partie visible de l’iceberg et la plus « simple ». On a en effet une session, nos outils, des logs, on peut déboguer. La base sera de jouer avec journalctl, dmesg -T | grep quelquechose, un petit journalctl -p err vous mettra sûrement sur la voie.

Déboguer l’extinction sera plus difficile. Le système s’éteint, on n’a plus de connexion réseau, pas la main sur un quelconque outil et ça dure une poignée de secondes. Pour « voir » une extinction, il faut avoir un écran branché sur le serveur ou utiliser certains outils basés sur IPMI (ipmitool), Dell iDRAC, HP iLO, KVM over IP. Évidemment c’est un peu mieux puisqu’on « voit » quelque chose cependant ça va très (trop) vite. Avec un peu de chance vous verrez « A stop job is running for… » mais on doit trouver plus exploitable.

journalctl

Si vous faites journalctl, vous afficherez les logs depuis le démarrage mais comment avoir les logs de l’extinction ? Dans un article précédent, j’avais souligné un choix par défaut discutable dans /etc/systemd/journald.conf. Faites un petit man journald.conf.

Storage=
           Controls where to store journal data. One of "volatile", "persistent", "auto" and "none". If "volatile", journal log data will be stored only in memory, i.e. below the /run/log/journal hierarchy
           (which is created if needed). If "persistent", data will be stored preferably on disk, i.e. below the /var/log/journal hierarchy (which is created if needed), with a fallback to /run/log/journal
           (which is created if needed), during early boot and if the disk is not writable.  "auto" is similar to "persistent" but the directory /var/log/journal is not created if needed, so that its
           existence controls where log data goes.  "none" turns off all storage, all log data received will be dropped. Forwarding to other targets, such as the console, the kernel log buffer, or a syslog
           socket will still work however. Defaults to "auto".

Par défaut Storage=auto, le journal est stocké dans /run/log/journal qui est perdu à chaque extinction puisque /run est un système de fichier temporaire (tmpfs). On a deux solutions pour avoir des logs de l’extinction, mettre Storage=persistent dans /etc/systemd/journald.conf ou simplement créer le dossier /var/log/journal (« so that its existence controls where log data goes », si /var/log/journal existe les logs seront envoyés dedans). Afin que la modification soit prise en compte sans rebooter (ha ha ha), on aura éventuellement besoin de faire systemctl restart systemd-journald. Faites journalctl --list-boots pour afficher les derniers boots, vous n’en aurez qu’un seul (le dernier). Maintenant si vous redémarrez votre pc/serveur puis que vous refaites journalctl --list-boots, vous en aurez deux. On va pouvoir regarder les logs de la précédente extinction

journalctl -p err sera encore utile mais perso je préfère journalctl -b -1 -n250 | grep 'timed out' # ou grep 'kill'. Cette seconde commande affiche les 250 dernières lignes (-n250) des logs du précédent boot (-b -1). C’est ainsi que j’ai trouvé mon fautif, j’ai confirmé en désactivant et stoppant le service systemctl disable --now servicerelou puis en rebootant : 40 secondes au lieu de 100.

Allons plus loin

Tout d’abord pour mieux comprendre journald, man systemd-journald. On y trouvera notamment une explication plus claire du point précédent : « By default, the journal stores log data in /run/log/journal/. Since /run/ is volatile, log data is lost at reboot. To make the data persistent, it is sufficient to create /var/log/journal/ where systemd-journald will then store the data ».

A noter que le Storage=auto fait actuellement débat, Ubuntu est revenu dessus, les arguments avancés sont très intéressants à lire.

Si /var/log/journal existe ou si vous passez Storage=persistent, attention cela signifie que vous allez avoir rsyslog qui fera son boulot ET journald. Perso je crée le dossier /var/log/journal au besoin et une fois que j’ai fini de déboguer, je le supprime.

DefaultTimeoutStartSec et DefaultTimeoutStopSec

J’ai trouvé le service responsable mais j’ai dû déboguer, je n’ai évidemment pas fait cela sur des serveurs en prod. Peut-on réduire le temps de reboot en se passant de la phase de recherche/debug ?

Déjà afin de connaître le temps d’arrêt et de démarrage d’un service, on peut utiliser time systemctl stop servicerelou et time systemctl start servicerelou.

Je vous invite maintenant à lire ceci. Les options DefaultTimeoutStartSec= et DefaultTimeoutStopSec= permettent d’influer sur le timeout par défaut du démarrage/arrêt d’un service. Si vous modifiez ces valeurs dans le fichier /etc/systemd/system.conf, c’est le timeout par défaut de tous les services que vous modifiez.

Concrètement systemd attend 90s (par défaut) qu’un service s’arrête (stop), si au bout de ces 90s il n’est pas arrêté il va le tuer (kill). On comprend dès lors que si on met DefaultTimeoutStopSec=30s, systemd n’attendra au maximum que 30 secondes avant de tuer le service nous économisant de précieuses secondes. On peut donc au choix surcharger servicerelou (à l’aide des drop-ins) ou modifier le timeout par défaut pour tous les services (via /etc/systemd/system.conf).

Attention cependant ! Tuer un service peut provoquer une perte de données. Si votre service postgresql est éléphantesque, qu’il a besoin de 43 secondes pour s’arrêter et que vous avez mis DefaultTimeoutStopSec=30s, il sera tué au bout de 30s.

On en vient à se demander si la valeur par défaut (90s) est pertinente, est-elle juste ? Chacun se fera sa propre idée, on pourrait considérer qu’un service qui ne s’arrête pas en 60s ne s’arrêtera probablement pas davantage en 90s.

On peut ruser ainsi en mettant DefaultTimeoutStopSec=60s dans /etc/systemd/system.conf suivi d’un systemctl daemon-reexec, redémarrer le serveur puis remettre DefaultTimeoutStopSec=90s suivi d’un systemctl daemon-reexec. On sera d’accord pour dire que ce n’est pas propre mais les contraintes de la prod obligent parfois à utiliser des « trucs » et des rustines pour arrondir les angles.

Conclusion

Voilà c’est ce genre de « détails » que je traite dans mon nouveau job, vous aimez ?

Et puisqu’on parle de Spectre et Meltdown, OVH décrit sur cette page la disponibilité des patchs par système d’exploitation, un lien pratique mais aussi intéressant. Pour Windows Server 2008 et 2012, il faut upgrade to Windows Server 2008/2012 R2. Il y en a qui doivent l’avoir très mauvaise, il faut racheter des licences et migrer vers une autre version lol. Ça permet aussi de suivre les plus impactés et les plus rapides à patcher, par exemple Windows Server 2016 et SUSE Linux Enterprise Server sont intégralement patchés mais Debian n’a pour l’instant patché qu’une CVE sur 3.

Original post of blog-libre.Votez pour ce billet sur Planet Libre.