Introduction aux techniques de compression vidéo.
Super page de SebSauvage sur btrfs. C'est super d'avoir de bons pointeurs en français.
Ne pas oublier non plus le wiki officiel.
C'est bien vu ça. Un calcul d'entropie peut vite nous montrer qu'on se trompe lorsque l'on cherche à créer un mot de passe compliqué de tête.
C'est pour ça qu'il faut utiliser un générateur / gestionnaire.
Pratique. Un cheat sheet Python très complet.
Un petit condensé des en-tête de sécurité sur HTTP(S) : raison, fonctionnement, mise en place.
Un outil pour débarrasser Windows 10 de pas mal de merdes. À garder sous le coude.
C'est intéressant ce genre de retour d'expérience. Bortzmeyer a passé son blog sur Let's Encrypt, avec deux difficultés techniques :
- il y a trois machines pour le servir, donc il faut obtenir le même certificat partout, sans accès au root des deux machines esclaves ;
- il faut que DANE fonctionne (DANE-EE) donc la clé privée ne doit pas changer dans le temps.
Il y a aussi la possibilité de mettre à jour le DNS pour la clé DANE mais cela obligerait à scripter d'avantage. La solution ici est assez élégante, faute de mieux.
Super outil de sécurité profonde (avec du DPI) mis à disposition par Synology sur ses routeurs. C'est réellement très efficace, même si la prise en main et l'adaptation aux menaces est un peu long.
Il s'agit surtout au départ d'ajouter au fur et à mesure des règles d'exceptions aux signatures ET. Par exemple :
- l'outil signalait un trojan potentiel sur une machine (paquet HTTP avec un faux user-agent Mozilla, à destination d'un réseau à faible réputation). Il s'agissait en réalité d'un ping de vérification de mise-à-jour pour MediaCoder ;
- des requêtes DNS émises étaient signalées pour des .tk ou .pw qui sont considérés comme des nids à pirates. Du coup, j'ai adapté la stratégie pour ne plus être alerté (sinon c'est la fin du monde) ;
- etc.
Bref, un outil puissant, dont je suis curieux de voir l'avenir. C'est encore frais, ça ajoute pas mal d'overload pour l'instant (trop, vu ma connexion) mais ça reste très utile. D'ailleurs mon serveur derrière a vu ses attaques (notam. sur SMTP, HTTP(S) et SSH) diminuer drastiquement (presque totalement en fait).
Pourquoi y a-t-il autant d'hommes dans l'informatique ? Raisons historiques, sociales, éducatives ?
Génial, à faire tourner.
Tiens, ça peut servir : quelques preset x264 pour ffmpeg.
- 360p
ffmpeg -y -i "mon fichier source" -vf "scale=-2:360" -pix_fmt yuv420p -c:v libx264 -preset slower -profile:v baseline -level 3.0 -b:v 440k -maxrate 460k -bufsize 800k -movflags faststart -pass 1 -c:a aac -b:a 64k -f mp4 /dev/null && \ ffmpeg -i "mon fichier source" -vf "scale=-2:360" -pix_fmt yuv420p -c:v libx264 -preset slower -profile:v baseline -level 3.0 -b:v 440k -maxrate 460k -bufsize 800k -movflags faststart -pass 2 -c:a aac -b:a 64k "ma-video-compressee.mp4" - 480p
ffmpeg -y -i "mon fichier source" -vf "scale=-2:480" -pix_fmt yuv420p -c:v libx264 -preset slower -profile:v main -level 3.1 -b:v 880k -maxrate 1030k -bufsize 1180k -movflags faststart -pass 1 -c:a aac -b:a 96k -f mp4 /dev/null && \ ffmpeg -i "mon fichier source" -vf "scale=-2:480" -pix_fmt yuv420p -c:v libx264 -preset slower -profile:v main -level 3.1 -b:v 880k -maxrate 1030k -bufsize 1180k -movflags faststart -pass 2 -c:a aac -b:a 96k "ma-video-compressee.mp4" - 720p
ffmpeg -y -i "mon fichier source" -vf "scale=-2:720" -pix_fmt yuv420p -c:v libx264 -preset slow -profile:v main -level 3.1 -b:v 1800k -maxrate 2050k -bufsize 5590k -movflags faststart -pass 1 -c:a aac -b:a 96k -f mp4 /dev/null && \ ffmpeg -i "mon fichier source" -vf "scale=-2:720" -pix_fmt yuv420p -c:v libx264 -preset slow -profile:v main -level 3.1 -b:v 1800k -maxrate 2050k -bufsize 5590k -movflags faststart -pass 2 -c:a aac -b:a 96k "ma-video-compressee.mp4" - 1080p
ffmpeg -y -i "mon fichier source" -vf "scale=-2:1080" -pix_fmt yuv420p -c:v libx264 -preset slow -profile:v high -level 4.1 -b:v 3400k -maxrate 3900k -bufsize 10630k -movflags faststart -pass 1 -c:a aac -b:a 128k -f mp4 /dev/null && \ ffmpeg -i "mon fichier source" -vf "scale=-2:1080" -pix_fmt yuv420p -c:v libx264 -preset slow -profile:v high -level 4.1 -b:v 3400k -maxrate 3900k -bufsize 10630k -movflags faststart -pass 2 -c:a aac -b:a 128k "ma-video-compressee.mp4"
EDIT : page man de ffmpeg
Un service qui permet de voir si son empreinte de navigateur est unique, juste avec les informations qu'il envoie.
Donc, même sans cookie, j'ai une empreinte unique. Bim.
Chier.
via : https://twitter.com/bortzmeyer/status/932255493476831232
Explications claires du nouveau champ DNS CAA, sa mise en place et son utilité.
En même temps, ça vient de Bortzmeyer.
Tutoriel indispensable à sed, qu'il faut absolument garder sous le coude.
Comment OVH gère le backup de dizaines de milliers de bases de données (MySQL et PostgreSQL) ?
TL;DR:
- répartition homogène des backup dans le temps grâce à une fonction de hachage sur le nom de la base ;
- dump avec verrouillage de tables si présence de tables MyISAM ;
- dump avec transaction si 100% InnoDB ;
- backup en sus au format SGBD (avec XtraBackup) si base volumineuse (temps de restore > 10 minutes) ;
- mysqlcheck pour réparer au préalable les tables, mais en prenant soin de doubler la RAM temporairement ;
- backup exportés et dédupliqués (cluster Ceph, disques locaux si prod externe, Cloud Storage)
Un tutoriel pour la commande jq en shell, qui permet de formater et d'interroger du JSON. Pratique !
OK donc y a un outil Linux qui s'appelle TheFuck et qui corrige les erreurs de commandes…
Une tentative de protocole pour résoudre les problèmes de relais de courrier et authentification DMARC.
Bon, c'est un draft qui vient juste d'être initié, donc pas prêt de voir le jour.
Présentation de l'attaque de TV5 Monde + analyse + remédiation par les équipes de l'ANSSI, qui sont intervenues en mode pompier.
Je suis surpris que ce ne soit pas très surprenant.
via : https://mastodon.xyz/users/Sniperovitch/updates/208016
BTRFS est-il adapté pour les bases de données d'analyse ? Non.
Intéressant benchmarking.
Shorter: l'utilisation du copy-on-write plombe les performances de 50%, quelque soit le système de fichier qui l'emploi. Mais en plus, BTRFS, à cause de sa popote interne obtient une variabilité impressionnante dans les perfs.
Moralité ? Si on veut faire du live-snapshot sans outil couteux (ou base de données très chère qui le gère en interne) il vaut mieux utiliser un autre système de fichier COW compatible ou directement du LVM Linux.
L'avantage de ce dernier, c'est aussi de pouvoir passer en COW que lorsque nécessaire, donc d'impacter les performances la nuit quand la base est à peu près au repos.
Comment configurer sa base de données avec un SSD ?
Réponse rapide (pour InnoDB mais généralisable) :
- Sur disque rotatif (HDD) : REDO logs, BIN logs, tablespace (system ou general), buffer data
- Sur disque solide (SSD) : UNDO logs, table files (donc les table-space si on utilise separate table-space)
C'est assez dingue en soit : ça veut dire que les bases de données sont largement optimisées pour fonctionner sur disque classique, et que seule une petite partie du traitement est à accès aléatoire (donc déplaçable sur SSD).
Random i/o oriented:
- Table files (*.ibd)
- UNDO segments (ibdata)
Sequential write oriented:
- REDO log files (ib_logfile*)
- Binary log files (binlog.XXXXXX)
- Doublewrite buffer (ibdata)
- Insert buffer (ibdata)
- Slow query logs, error logs, general query logs, etc
D'ailleurs, fait intéressant dans l'article : il obtient une perf meilleure en HDD + SDD que en dual SSD. Peut-être parce que les SSD sont en bus SATA commun et que ce dernier sature, alors que ses HDD sont en bus SAS (donc séparé).
Pour aller plus loin, et configurer proprement la base :