Kaspersky : Désactiver l’alerte pour certificat SSL auto-signé

Kaspersky Internet Security avertit par défaut lorsque l’on consulte un site avec un certificat SSL auto-signé :

Alerte Kaspersky SSL

Pratique au début, cela en devient vite pénible tellement le nombre de sites concernés est important. J’arrive rapidement à une bonne dizaine d’alertes en regardant mes flux RSS…

Pour le désactiver, deux possibilités : désactiver complètement l’inspection SSL ou uniquement le bloqueur de de pub + la navigation privée.

Désactiver l’inspection SSL

Dans les réglages de Kaspersky > Avancé > Réseaux, sélectionner « Ne pas analyser les connexions sécurisées ». Une demande de confirmation s’affichera :

Désactiver le bloqueur de pub et la navigation privée :

Dans les réglages de Kaspersky > Protection :

Kaspersky Désactive Analyse SSL

Dans les deux cas, à vos risques et périls car cela réduit forcément la sécurité 🙂

Windows + PHP : cURL error 60: SSL certificate problem: unable to get local issuer certificate

J’ai rencontré l’erreur suivante sous Windows 10 avec PHP 7.1 installé via Chocolatey :

[GuzzleHttp\Exception\RequestException]
cURL error 60: SSL certificate problem: unable to get local issuer certificate

Pour la corriger, deux étapes :

  1. Télécharger le fichier cacert.pem depuis curl.haxx.se/docs/caextract.html (lien direct) et le placer dans le répertoire d’installation de PHP (ici C:\tools\php71)
  2. Editer le fichier php.ini et préciser le chemin de cacert.pem :
    [curl]
    ; A default value for the CURLOPT_CAINFO option. This is required to be an
    ; absolute path.
    curl.cainfo = "C:\tools\php71\extras\ssl\cacert.pem"
    

Il est bien sûr possible de partager cacert entre plusieurs versions de PHP.

Ce fichier est un instantané du catalogue d’autorités de certification de Mozilla et évolue régulièrement. curl.haxx.se fournit sur son site un script pour l’extraire depuis une installation locale de Firefox.

Source : https://www.zen-cart.com/showthread.php?213892-Windows-server-Curl-error-(60)-SSL-Certificate-problem-Unable-to-get-local-issuer

Vagrant : `chdir’: Too many open files – getcwd (Errno::EMFILE)

Dans le cadre d’une configuration Vagrant composée de plusieurs machines virtuelles Virtualbox, j’ai obtenu l’erreur suivante :

/opt/vagrant/embedded/gems/gems/vagrant-1.9.1/lib/vagrant/util/safe_chdir.rb:25:in `chdir': Too many open files - getcwd (Errno::EMFILE)
	from /opt/vagrant/embedded/gems/gems/vagrant-1.9.1/lib/vagrant/util/safe_chdir.rb:25:in `block in safe_chdir'
	from /opt/vagrant/embedded/gems/gems/vagrant-1.9.1/lib/vagrant/util/safe_chdir.rb:24:in `synchronize'
	from /opt/vagrant/embedded/gems/gems/vagrant-1.9.1/lib/vagrant/util/safe_chdir.rb:24:in `safe_chdir'
	from /opt/vagrant/embedded/gems/gems/vagrant-1.9.1/lib/vagrant/util/subprocess.rb:121:in `execute'
	from /opt/vagrant/embedded/gems/gems/vagrant-1.9.1/lib/vagrant/util/subprocess.rb:22:in `execute'
	from /opt/vagrant/embedded/gems/gems/vagrant-1.9.1/plugins/providers/virtualbox/driver/base.rb:430:in `block in raw'
	from /opt/vagrant/embedded/gems/gems/vagrant-1.9.1/lib/vagrant/util/busy.rb:19:in `busy'
	from /opt/vagrant/embedded/gems/gems/vagrant-1.9.1/plugins/providers/virtualbox/driver/base.rb:429:in `raw'
	from /opt/vagrant/embedded/gems/gems/vagrant-1.9.1/plugins/providers/virtualbox/driver/base.rb:367:in `block in execute'
(...)

Sous macOS, la limite par défaut du nombre de fichiers ouverts est de 256 :

$ ulimit -n
256

Il faut donc l’augmenter, disons à 1024 :

ulimit -n 1024

A noter que la modification ne s’applique qu’à la session en cours, il faudra donc ajouter la ligne dans le .bash_profile pour la rendre permanente dans le terminal.

Source : https://discussions.apple.com/thread/2206502

Modifier le comportement à la fermeture de l’écran avec systemd-logind

logind est le composant en charge de la gestion des sessions sur les systèmes avec systemd. Il suit les utilisateurs connectés (systemd-loginctl list-users), les sessions ouvertes (systemd-loginctl list-sessions) et détermine le comportement lorsque l’on appuie sur le bouton d’alimentation (Power Key), ferme l’écran (Lid Switch) et en cas d’inactivité (Idle).

Sa configuration est située dans /etc/systemd/logind.conf :

[Login]
#NAutoVTs=6
#ReserveVT=6
#KillUserProcesses=no
#KillOnlyUsers=
#KillExcludeUsers=root
#InhibitDelayMaxSec=5
#HandlePowerKey=poweroff
#HandleSuspendKey=suspend
#HandleHibernateKey=hibernate
#HandleLidSwitch=suspend
#HandleLidSwitchDocked=ignore
#PowerKeyIgnoreInhibited=no
#SuspendKeyIgnoreInhibited=no
#HibernateKeyIgnoreInhibited=no
#LidSwitchIgnoreInhibited=yes
#IdleAction=ignore
#IdleActionSec=30min
#RuntimeDirectorySize=10%
#RemoveIPC=no

La variable qui nous intéresse aujourd’hui s’intitule HandleLidSwitch et détermine l’action à effectuer lorsque l’on ferme / rabat l’écran. Sa valeur par défaut est suspend (mise en veille).

Les valeurs acceptées sont les suivantes :

Can be one of "ignore", "poweroff", "reboot",
"halt", "kexec", "suspend", "hibernate", "hybrid-sleep", and "lock"

Mettons de côté « poweroff » (arrêt), « reboot » (redémarrage), « halt » et « kexec » et regardons les valeurs réellement utiles pour HandleLidSwitch :

  • « ignore » : Faire comme si de rien n’était. Si la session ne se verrouille pas après X minutes d’inactivité, elle restera ouverte.
  • « hibernate » : Mise en hibernation
  • « hybrid-sleep » : Mise en hibernation avec conservation des données en mémoire (pour reprendre plus rapidement).
  • « lock » : Verrouillage de la session
  • « suspend » : Mise en veille. Le comportement par défaut.

Pour verrouiller la session, ce sera donc :

HandleLidSwitch=lock

Une fois la modification faîte, inutile de redémarrer, il suffit de relancer le service systemd-logind :

systemctl restart systemd-logind

Sources :

Dockerfile & yum check-update : returned a non-zero code: 100

La commande yum check-update retourne le code 100 lorsque des mises à jour sont disponibles, ce que Docker interprète comme un code d’erreur lors de la construction d’une image (docker build) :

The command '/bin/sh -c yum check-update' returned a non-zero code: 100

N’ayant réussi ni à trouver une option pour l’ignorer côté Docker ni pour désactiver ce comportement côté Yum, la seule solution reste de forcer la commande à retourner 0 avec la syntaxe suivante :

RUN (yum check-update || true)

Qui se traduit par : retourne true (soit 0) si yum check-update retourne un code d’erreur.

dockerd: Error initializing network controller: list bridge addresses failed: no available network

Contexte : CentOS 7. Package docker-engine fraichement installé depuis le repository officiel.

Erreur lors du lancement du service docker-engine :

$ sudo systemctl status -l docker.service 
● docker.service - Docker Application Container Engine
   Loaded: loaded (/usr/lib/systemd/system/docker.service; disabled; vendor preset: disabled)
   Active: failed (Result: exit-code) since sam. 2017-01-28 10:03:24 CET; 2min 33s ago
     Docs: https://docs.docker.com
  Process: 11478 ExecStart=/usr/bin/dockerd (code=exited, status=1/FAILURE)
 Main PID: 11478 (code=exited, status=1/FAILURE)

janv. 28 10:03:24 simon-laptop.home dockerd[11478]: Error starting daemon: Error initializing network controller: list bridge addresses failed: no available network
janv. 28 10:03:24 simon-laptop.home systemd[1]: docker.service: main process exited, code=exited, status=1/FAILURE
janv. 28 10:03:24 simon-laptop.home systemd[1]: Failed to start Docker Application Container Engine.
janv. 28 10:03:24 simon-laptop.home systemd[1]: Unit docker.service entered failed state.
janv. 28 10:03:24 simon-laptop.home systemd[1]: docker.service failed.

Même erreur en lançant manuellement docker :

$ sudo docker daemon -s overlay
Command "daemon" is deprecated, and will be removed in Docker 1.16. Please run `dockerd` directly.
INFO[0000] libcontainerd: new containerd process, pid: 12001 
WARN[0000] containerd: low RLIMIT_NOFILE changing to max  current=1024 max=4096
INFO[0001] Graph migration to content-addressability took 0.00 seconds 
INFO[0001] Loading containers: start.                   
INFO[0001] Firewalld running: true                      
Error starting daemon: Error initializing network controller: list bridge addresses failed: no available network

Le problème venait en fait la présence d’un nameserver IPv6 en lien local dans /etc/resolv.conf :

$ cat /etc/resolv.conf 
# Generated by NetworkManager
search home
nameserver 192.168.1.1
nameserver fe80::ba26:6cff:feb9:6e50%enp8s0

Nouvelle tentative en retirant la dernière ligne :

$ head -n -1 /etc/resolv.conf | sudo tee /etc/resolv.conf
$ sudo dockerd -s overlay
(...)
INFO[0001] Default bridge (docker0) is assigned with an IP address 172.17.0.0/16. Daemon option --bip can be used to set a preferred IP address 

Pour rendre la modification permanente, il faut, au choix :

  • Désactiver NetworkManager
  • Désactiver la configuration automatique du DNS sur IPv6
  • Désactiver complétement IPv6 sur l’interface (ici enp8s0)

Valider ses followers avec TrueTwit

TrueTwit est un service permettant de vérifier « l’humanité » de ses followers Twitter.

Le fonctionnement est le suivant :

Lorsqu’une personne s’abonne à votre profil, un message privé (DM) lui ai envoyé avec un lien de validation :

screenshot_at_jan_28_20-04-03

Avec l’édition « Basic » (gratuite) de TrueTwit, un e-mail de notification est envoyé une fois la validation effectuée. Cela évite de se faire « polluer » par des notifications d’abonnements de la part de robots.

Avec l’édition « Premium » (20$ par an), en plus de la notification, le nouveau follower peut être automatiquement suivi après validation afin d’échanger des DM.

Site officiel : http://truetwit.com/