[Pi] Configuration SSH avant premier démarrage

On prend la même structure que pour la note sur la configuration du Wifi, et on recommence.

Une nouvelle fois, rien de nouveau pour la plupart d’entre nous, mais un moyen pour moi de retrouver facilement la syntaxe de la configuration à utiliser et le lien vers la documentation sur le site officiel.

Pour que le Pi au moment du premier démarrage, active automatiquement un accès SSH, et ne pas avoir à connecter clavier et écran, il suffit donc de créer dans le dossier boot de la carte SD, le fichier ssh. Le contenu du fichier n’a pas d’importance.

Profitons-en pour noter que l’utilisateur par défaut est l’utilisateur pi avec le mot de passe par défaut raspberry. Bien évident, à changer immédiatement lorsque l’on commence à faire autre chose que des tests et du prototypage ou encore que l’on expose le Pi en dehors du LAN.

[Pi] Configuration Wifi avant premier démarrage

Rien de nouveau pour la plupart d’entre nous, mais un moyen pour moi de retrouver facilement la syntaxe de la configuration à utiliser et le lien vers la documentation sur le site officiel.

Pour que le Pi au moment du premier démarrage, se connecte automatiquement au réseau, et ne pas avoir à connecter clavier et écran, il suffit donc de créer dans le dossier boot de la carte SD, le fichier wpa_supplicant.conf.

ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1
country=fr

network= {
  ssid="Nom du Wifi"
  psk="Mot de passe du Wifi"
}

Ban IP 11/2020 – Les gagnants

Depuis quelques jours, la quantité de spam du côté du formulaire de commentaire a explosé en quantité. On passe d’une centaine par semaine à une centaine par jour. Tout finit naturellement dans la file des indésirables, mais cela reste ennuyeux.
Voici donc les heureux gagnants d’un ban IP sans limitation de durée:

5.188.84.15
5.188.84.25
5.188.84.35
5.188.84.45
5.188.84.65
5.188.84.95
5.188.84.115
5.188.84.147 
5.188.84.220
5.188.84.221
5.188.84.233

Le spam n’est pas suffisamment régulier pour définir des règles strictes de filtrage dans fail2ban. Une petite recherche sur le net semble indiquer que les IPs sont bien identifiées comme responsable de spam et font donc partie de listes de blocage. Il pourrait donc être intéressant de s’interroger sur la possibilité de connecter un blocage par iptables, ou autre, sur une liste dynamique des IPs des spammeurs connus. Quels seraient alors les impacts sur les performances, vu la taille de certaines de ces listes ?

Une histoire de gamma

Depuis un moment déjà, mes écrans avaient pris une teinte rouge très prononcée et les textes de couleurs sombres, en particulier de couleur bleu foncé, été devenu difficile à distinguer. En changeant de système d’exploitation, ou en branchant un autre ordinateur: pas de problème d’affichage de couleur. Ce n’était donc pas un début de vieillissement des écrans, comme j’avais pu le penser par instant. Seul Arch Linux était concerné.

Rien à signaler du côté de redshift, qui ne semblait pas responsable, bien qu’ajoutant un petit effet rouge supplémentaire. Après plusieurs tentatives infructueuses, j’avais fini par m’accommoder de cette balance de couleur plus que douteuse. Et ce n’est que très récemment que j’ai trouvé les éléments permettant de remonter à la source du problème.

Je suis donc allé explorer la configuration de mes écrans du côté de xrandr avec la commande suivante:

xrandr --verbose

Je parcours les lignes, ne voyant rien de particulier, quand tout à coup, je tombe sur la ligne:

Gamma:      1.6:2.5:4.0

Je cherche donc comment rétablir les gammas à des valeurs « neutres ». Toujours avec xrandr et en spécifiant la source concernée avec l’option output, on pourra utiliser l’option dédiée, à savoir: gamma. A noter que j’ai également constaté une remise à plat des gammas avec l’option brightness.

xrandr --output DVI-D-0 --gamma 1:1:1
xrandr --output DP-1 --brightness 1.0

Ce ne fut malheureusement pas suffisant. Au démarrage suivant, réapparition du problème. Après de nouvelles recherches, j’ai fini par trouver que le fichier de configuration pour ma disposition d’ écran par défaut dans autorandr contenait la ligne:

gamma 0.625:0.4:0.25

Après avoir modifié les trois valeurs à 1.0, j’ai donc retrouvé des couleurs correctes et un affichage satisfaisant. Bref, une bête erreur de configuration, qui devait remonter à l’installation et à la première configuration d’autorandr.

[macOS] Elasticsearch – Unrecognized VM option ‘UseConcMarkSweepGC’

Sur mon ordinateur de travail, après une mise à jour avec brew update suivi d’un brew upgrade, il m’était devenu impossible de démarrer elasticsearch. L’exécution se terminait systématiquement en erreur avec le message : Unrecognized VM option 'UseConcMarkSweepGC'. Après quelques recherches, voici la solution qui a permis le démarrage du programme sans erreur.

Éditer le fichier /usr/local/etc/elasticsearch/jvm.options et commenter les lignes suivantes :

-XX:+UseConcMarkSweepGC
-XX:CMSInitiatingOccupancyFraction=75
-XX:+UseCMSInitiatingOccupancyOnly

Pour remplacer ces trois lignes, ajouter les lignes suivantes :

8-13:-XX:+UseConcMarkSweepGC
8-13:-XX:CMSInitiatingOccupancyFraction=75
8-13:-XX:+UseCMSInitiatingOccupancyOnly

elasticsearch devrait désormais démarrer correctement.