S'il est vrai qu'un mot de passe avec une sécurité élevée est une bonne chose, l'utiliser sur plusieurs services différents en est une très mauvaise. En effet, si le mot de passe est compromis sur un service, l'ensemble des services le sont également.

Afin d'avoir des mots de passe différents sur chaque service, il est possible de générer des mots de passe de niveau élevé et de les noter ; mais pas n'importe où. Le post-it n'est pas une bonne idée parce qu'il peut être perdu et reste lisible par toute personne le trouvant. Un fichier texte sauvegardé dans un coin n'est pas non plus une bonne solution, pour les mêmes raisons que le post-it. La bonne méthode, mais surtout la plus sécurisée, consiste à utiliser un gestionnaire de mots de passe.

Certains auront entendu parlé de Bitwarden ou LastPass, qui sont des gestionnaires de mots de passe hébergés. Cela signifie que les mots de passe sont stockés de façon sécurisé dans une base de données consultable à l'aide d'une interface web. Personnellement, je préfère ne pas utiliser ce type de solution et utiliser une base de données chiffrée sous la forme d'un fichier unique. Ce fichier est accessible via plusieurs clients, dont KeepassXC (KeepassDX sur Android). Je synchronise ce fichier via Syncthing afin d'avoir accès à mes mots de passe sur l'ensemble des périphériques que j'utilise. Je sauvegarde ce fichier en le copiant une fois par trimestre sur deux clefs USB, avec la dernière version portable de KeepassXC.

La version de KeepassXC disponible dans Debian Buster n'est pas toute fraîche. En effet, le dépôt propose la version 2.3.4 alors que les développeurs proposent une version 2.6.2. L'intérêt de disposer de la dernière version de ce gestionnaire de mots de passe est de corriger certains bogues qui pourraient être gênant. Je pense ici à mon soucis d'intégration avec le module Firefox.

Je documente, dans cet article, l'ensemble des étapes que je réalise afin de remplacer la version de KeepassXC fournie par Debian par celle fournie par les développeurs.

Au travail, nous avons une sonde sur nos passerelles de courriels qui passe en critique lorsque plus de 3000 courriels sont en file. Généralement, lorsque cette sonde se déclenche, c'est qu'un client fait de l'envoi de courriels de masse ou qu'un des formulaires de son site web est mal protégé.

Récemment lors d'un week-end, la sonde s'est déclenchée et un client a rapidement pu être pointé du doigt. En astreinte, mes collègues ont bloqué le port SMTP (25) des serveurs du client incriminé pour arrêter le remplissage de la file sur les passerelles.

Une fois le port SMTP bloqué, la file se remplit sur les serveurs du client, ce qui décale le problème, mais ne génère pas de congestion particulière. Il est alors nécessaire de travailler de concert avec le client et donc de lui fournir une liste des courriels dans la file d'attente de ces serveurs.

Cet article documente le déploiement d'un conteneur en partant du modèle précédemment créé.

Suivre cet article ne permet pas de déployer des services, mais d'obtenir un conteneur pré-configuré comme le modèle et donc prêt à accueillir des services. La partie services du projet Chaos ne rappellera pas forcément l'ensemble des étapes énoncées ici.

Depuis quelques semaines maintenant, le site est hébergé à mon domicile. La migration s'est faite sans le moindre problème et sans aucune coupure. J'ai profité de la migration pour passer à une version plus récente d'HuGO qui a nécessité quelques adaptations au niveau du modèle (template).

Au cours de cette semaine, j'ai changé le SSD connecté à mon nano-ordinateur afin de pouvoir rapatrier l'ensemble des services hébergés sur mon serveur Kimsufi. Malheureusement, ce SSD (Crucial BX500 120Go), s'arrêtait tout seul. Après un échange avec le support de la marque, il s'avère que la marque déconseille l'utilisation de ces SSD dans des serveurs. Réponse plutôt étrange quand on sait que le SSD précédent avait quelques années, était un premier prix et n'avait aucun problème. Bref, j'ai dû changer de SSD à nouveau pour en mettre un d'une marque en laquelle j'ai confiance.

Les curieux seront peut-être intéressés par le matériel sur lequel tourne ce site et différents services tels que Nextcloud, Gitea et une passerelle :

• Carte : Rock64 4Go
• Disque système : eMMC 16 Go (12 Go de libre)
• Disque conteneurs : ICY BOX IB-273StU3 + SSD Kingston A400 120Go (100 Go de libre)
• Réseau : RJ45 catégorie 6
  

Pour conclure, le site a été mis au couleur de l'Octobre Rose. Cet évènement qui court chaque année tout le mois, vise à sensibiliser au dépistage du cancer du sein. Au delà de l'évènement, je souhaite montrer mon soutient à l'ensemble des femmes, quelque soit leur combat.

Avant de louer mon premier serveur dédié, je me suis posé la question du cloisonnement des différents services que je souhaitais héberger. N'ayant pas les moyens de louer un serveur performant pour faire de la virtualisation, je me suis intéressé à la conteneurisation. A l'époque, j'ai fait la découverte de Proxmox VE qui m'a permis d'apprendre, de façon simple, la conteneurisation via OpenVZ, puis LXC.

Quelques mois après avoir acquis un mini-ordinateur Rock64, je me suis naturellement tourné vers Proxmox VE. Malheureusement, le projet ne supporte pas (encore ?) l'architecture arm64 ou armhf. Je me suis alors tourné vers une autre solution, LXD. D'abord testé sur mon Rock64, j'ai finalement décidé de louer un serveur dédié encore moins onéreux et performant pour y déployer LXD.

Cet article documente l'installation et la configuration de LXD sur un serveur Kimsifu KS-3.