Bonjour tout le monde!

Nous avons vécu une panne prolongée, du 18 au 20 juillet dernier, dont la source était un entretien par Hydro-Québec du réseau électrique. Hydro-Québec a coupé l'électricité pendant environ 3 heures, ce qui était trop long pour mes UPS. Malheureusement, celui des serveurs n'est pas revenu en ligne de lui-même.

J'ai demandé à un ami habitant la même ville de venir les allumer, mais d'autres pépins ont été découverts. Continuez la lecture pour plus de détails.

Pour le reste de l'article, cliquez sur Détails

Nous l'avons enfin trouvé! La crème d'administrateur! Lorsque tes serveurs te donne de l'urticaire, il ne suffit qu'à appliquer cette crème et l'urticaire disparaît, ainsi que les problèmes de serveur!


P.S.: J'ai réglé le téléversement de fichiers

Un drôle de titre pour certains, mais peut-être que d'autres se reconnaîtront. Si vous utilisez des clés publiques/privées pour vous authentifier sur des services en ligne comme Github, AUR (Archlinux), etc. et que vous vous confrontez à un serveur qui refuse obstinément votre clé [Permission denied (publickey)], ceci peut avoir plusieurs causes.

L'une d'elles correspond peut-être à ce scénario : vous travaillez sur plus d'un ordinateur et vous avez copié votre clé de l'ordinateur sur lequel elle a été générée vers un second ordinateur. Votre clé fonctionne toujours sur l'ordinateur d'origine, mais elle est refusée sur le second ordinateur. Le problème n'est donc pas avec la clé puisqu'elle est identique aux deux endroits. En fait, il faut savoir que seulement vous, comme utilisateur, devriez avoir accès au fichier de votre clé privée. Ah! Donc, si vous regardez les droits de lecture, d'écriture et d'exécution, vous seul devez avoir des droits (rw), personne d'autre.

Lancez donc un chmod 600 $dossierverscléprivée/$nomcléprivée, exemple

chmod 600 ~/johndoe/.ssh/id_rsa

Tentez de vous identifier à nouveau.

Voilà quelques semaines que je rencontrais cette erreur sur un second ordinateur et je n'avais pas pris le temps de chercher. J'ai maintenant réglé mon problème et appris que les clés privées doivent être privées jusqu'au bout.

Un petit message pour vous dire que j'ai passé le site web en HTTPS partout.

La raison est simple, les navigateurs commencent à avertir lorsque les sites ne sont pas en HTTPS. Comme j'ai déjà mon certificat et que la configuration est fonctionnelle, j'ai décidé de migrer tout le site sur cette configuration!

J'ai eu quelques modifications à faire au code du site pour m'assurer que tout était beau. Comme toujours, si vous trouvez des problèmes, faites-le savoir!

Après toutes ces années, c'est la première fois que quelque chose comme ça m'arrive!

Quelqu'un a remplis un rapport sur OpenBugBounty.org pour me signaler qu'il y avait un faille XSS sur mon site web. J'ai contacté la personne qui a fait ce rapport, pour me rendre compte que la faille était effectivement présente.

J'ai sorti mes skills (plutôt absents) de RedExp pour corriger le bug et conserver seulement que les valeurs qui nous sont utiles. Je crois bien l'avoir corrigé correctement.

La sécurité n'est pas une destination, mais un processus...