Je m'en sers pour initialiser un générateur d'UUIDv2 : l'idée est que ce machine-id est sensé être différent sur toutes les instances d'un même cluster ; ce qui est sensé éviter les conflits en cas de traitement/insertions parallèles.
Par contre je n'arrive pas à retrouver pourquoi j'ai basé ça sur le /etc/machine-id. C'était peut-être un moyen "pratique" de remplacer les MAC, par un autre «stable unique identifier that is tied to the machine», comme dit la manpage.
j'ai l'impression d'avoir déjà posé cette question, mais d'un point de vue hyperviseur uniquement, y a t'il des différences avec celui de «Xen Source» ?
Aujourd'hui mon principal problème avec Xen Source, c'est le manque de stabilité. Avec une douzaine de "gros" hyperviseurs en prod, on recontre 2 ou 3 fois par an des plantages d'hyperviseur, sans en comprendre la raison (et sans logs…). Il est possible que celà vienne de l'utilisation massive du driver RBD (Ceph) en version noyau, mais… difficile à diagnostiquer.
Bref, l'hyperviseur de XCP-ng et XenServer est-il exactement le même que celui de XenSource ?
Tiens, sur la whishlist, on peut ajouter un entête HSTS ?
Il ne sera pris en compte que par les gens acceptant la CA actuelle, les intégristes pourront continuer à utiliser la version en clair. Bref, à priori que des avantages, non ?
Personnellement ce film m'a bien plu oui, je l'ai trouvé relativement plausible si ce n'est le coup du "super cloud de la NSA" (Attention spoiler : qui comble les trous d'une copie numérique d'un disque endommagé).
La cerise sur le gâteau, c'est de me rendre compte que j'avais le même marteau que Chris Hemsworth, aka Thor. :D
Juste une remarque : on pouvait demander au driver ext4 de prendre en charge les FS ext2&ext3 depuis longtemps.
Il s'agissait de l'option CONFIG_EXT4_USE_FOR_EXT23 dans les précédentes versions du noyau.
Je ne sais pas quand elle a été ajoutée, mais j'en ai des traces dans mes confs dès la version 2.6.38 de Linux.
Je l'avais testée il y a longtemps, mais il me semble que le icones étaient petites et au milieu de la fenêtre, le tout non configurable. J'avais modifié le code moi même, sans être convaincu. Là ça a bien évolué, et ça me plait bien.
fcgid est disponible depuis longtemps dans Debian oui, mais fastcgid quant à lui n'est disponible qu'en “non-free”.
Hors, seul ce dernier supporte les serveurs fastcgi externes, tels que PHP-FPM par exemple.
Une alternative est donc mod_proxy_fcgi, qui se contente de gérer le protocole fastcgi sans chercher à gérer les process associés. À l'image d'NginX par exemple.
J'ai beau essayer de suivre tout ça d'assez près, ça me semble être un beau bordel quand même : les infos concernant Debian sont certes publiques, mais généralement éparpillées et souvent obsolètes.
Quand on voit que même packages.debian.org indique souvent des fichiers changelog sur metadata.ftp-master.debian.org, mais qu'on tombe régulièrement sur des 404 pour peu que la modif soit trop récente (quelques heures / jours), ça fait bricolage.
Je pensais pas qu'ils manquaient d'admin pour gérer leurs infras, mais si c'est le cas je peux probablement aider. Où trouve t-on ça ?
Oui, OpenSSH 6.8 ne sera pas dans le repository «standard» de Debian Jessie. Il faudra soit utiliser des backports (ce qui n'est probablement pas conseillé pour quelque chose d'aussi sensible), soit attendre la Debian 9, dans 2 ans.
Pour ma part j'ai pas le sentiment que la «communauté se soit déchirée» à propos de systemd. Je veux dire, oui quelques mainteneurs Debian ont claqué la porte, mais pour le moment ça ne m'impacte pas outre mesure, et si leur raison est uniquement systemd, qui reste facultatif, je ne comprends pas leur but.
C'est pas comme si un tiers des membres étaient partis, suite à une décision majeure.
Je ne confirme rien du tout, ces outils restent présents. Seulement maintenant tu as aussi l'outil apt, sensé être plus simple et qui regroupe 90% des usages courants.
Et pourtant je maintiens : aptitude safe-upgrade accepte bien plus de mises à jour qu'un simple apt-get upgrade. Le prefix safe- n'est ici que pour faire la distinction avec le full-upgrade.
J'aurais tendance à dire que l'apt-get upgrade est hyper conservateur et ne prend pas le moindre risque, là où l'aptitude safe-upgrade essaye de faire un choix plus… réfléchis.
Pour utiliser régulièrement les 2 de manière complémentaires, j'apprécie justement cette subtilité de fonctionnement.
EDIT: je viens de faire un test, sur un desktop testing pas mis à jour depuis 2 semaines environ. apt-get update me propose 193 mises à jour, là où aptitude safe-upgrade m'en propose 195.
En effet, apt-get ici ne veut pas mettre à jour libgit2-21, qui a maintenant une dépendance envers libhttp-parser2.1.
Pour la version “RBD”, oui on pourrait le comparer à “LVM” (j'ai d'ailleurs des scripts qui utilisent l'un ou l'autre selon le contexte, de manière quasi identique).
Si ce n'est que c'est beaucoup beaucoup plus lourd à déployer. Ça consomme tellement qu'il est recommandé de dédier les machines de stockage à ce seul usage (sans oublier les machines de surveillance).
C'est un peu le pendant d'“apt-get upgrade” excepté qu'aptitude s'autorise à supprimer les dépendances automatiques.
Extrais du manuel d'aptitude :
Mettre les paquets installés à jour, avec leur version la plus récente. Les paquets installés ne seront pas retirés, sauf s'ils sont inutilisés (voir la section « Gérer les paquets automatiquement installés » dans le manuel de référence d'aptitude). Les paquets qui ne sont pas actuellement présents peuvent être installés pour résoudre des dépendances, sauf si l'option en ligne de commande --no-new-installs est fournie.
Si aucun n'est donné sur la ligne de commande, aptitude essaiera de mettre à jour tous les paquets qui le peuvent. Sinon, aptitude n'essaiera de mettre à jour que les paquets indiqués. Les s peuvent être étendus avec des suffixes, de la même manière que les arguments de aptitude install, de sorte qu'il est possible de donner des instructions supplémentaires à aptitude. Par exemple, aptitude safe-upgrade bash dash- essaiera de mettre à jour le paquet bash et de supprimer le paquet dash.
Extrais du manuel d'apt-get :
La commande upgrade permet d'installer les versions les plus récentes de tous les paquets présents sur le système en utilisant les sources énumérées dans /etc/apt/sources.list. Les paquets installés dont il existe de nouvelles versions sont récupérés et mis à niveau. En aucun cas des paquets déjà installés ne sont supprimés ; de même, des paquets qui ne sont pas déjà installés ne sont ni récupérés ni installés. Les paquets dont de nouvelles versions ne peuvent pas être installées sans changer le statut d'installation d'un autre paquet sont laissés dans leur version courante. On doit d'abord exécuter la commande update pour que apt-get connaisse l'existence de nouvelles versions des paquets.
Au final, sur du testing ou sid, un “aptitude safe-upgrade” aura tendance à accepter des mises à jour qu'“apt-get upgrade” n'aurait pas faites.
Et dans le cas d'une mise à jour Wheezy→Jessie, j'aurais tendance à la faire en plusieurs étapes : apt-get upgrade; aptitude upgrade ; apt-get dist-upgrade
# 6666 !
Posté par Kioob (site web personnel) . En réponse au sondage Quel port ouvert pour le SSH ?. Évalué à 8.
6666, parce que les premières cartes 3G d'Orange ne laissaient passer que : FTP, TELNET, DNS, HTTP, SMTP/IMAP et… IRC.
Ensuite, constatant que ça faisant quand même vachement moins de bruit dans les logs, j'ai gardé, par habitude.
Mais j'ai aussi un bastion en 443 pour certains hôtels à la con.
alf.life
[^] # Re: Viser Mars
Posté par Kioob (site web personnel) . En réponse au journal La sauvegarde dans les nuages. Évalué à 4.
Beh non, le ping mini est 8.6 AL
alf.life
# pour les UUID ?
Posté par Kioob (site web personnel) . En réponse au journal systemd: identifiant unique, world-readable?. Évalué à 1.
Je m'en sers pour initialiser un générateur d'UUIDv2 : l'idée est que ce machine-id est sensé être différent sur toutes les instances d'un même cluster ; ce qui est sensé éviter les conflits en cas de traitement/insertions parallèles.
Par contre je n'arrive pas à retrouver pourquoi j'ai basé ça sur le /etc/machine-id. C'était peut-être un moyen "pratique" de remplacer les MAC, par un autre «stable unique identifier that is tied to the machine», comme dit la manpage.
alf.life
# Quid de XenSource ?
Posté par Kioob (site web personnel) . En réponse à la dépêche XCP-ng 8.0, une alternative gratuite à XenServer. Évalué à 3.
Bonjour,
j'ai l'impression d'avoir déjà posé cette question, mais d'un point de vue hyperviseur uniquement, y a t'il des différences avec celui de «Xen Source» ?
Aujourd'hui mon principal problème avec Xen Source, c'est le manque de stabilité. Avec une douzaine de "gros" hyperviseurs en prod, on recontre 2 ou 3 fois par an des plantages d'hyperviseur, sans en comprendre la raison (et sans logs…). Il est possible que celà vienne de l'utilisation massive du driver RBD (Ceph) en version noyau, mais… difficile à diagnostiquer.
Bref, l'hyperviseur de XCP-ng et XenServer est-il exactement le même que celui de XenSource ?
alf.life
# autres paquets supprimés
Posté par Kioob (site web personnel) . En réponse à la dépêche Debian 10 Buster : une distribution qui a du chien. Évalué à 4.
Parmi les autres paquets supprimés, j'ai noté ipsec-tools/racoon, ainsi que phpmyadmin.
Le premier me gêne pas mal, dans le sens où je vais devoir m'adapter et utiliser quelque chose comme libreswan.
Quant à phpmyadmin, ça fera un prétexte de plus pour l'interdire sur la prod, mais j'avoue que ça m'a surpris.
alf.life
[^] # Re: Russie
Posté par Kioob (site web personnel) . En réponse au journal Validations frauduleuses de codes 3D Secure. Évalué à 1.
Une des apps peut également gérer un proxy qui prend en charge le https, et certificat root bidon. Comme le ferait l'app "Charles Proxy".
Ainsi tout le traffic Web serait sniffé.
alf.life
[^] # Re: Tu es parano
Posté par Kioob (site web personnel) . En réponse au journal Orange http(s) KO. Évalué à 1.
J'aurais dis le contraire : wget va utiliser les paramètres système, là où Chrome et Firefox vont ajouter des trucs genre "DNS over HTTPS". Non ?
alf.life
# API ?
Posté par Kioob (site web personnel) . En réponse à la dépêche Sortie de Crème CRM en version 2.0. Évalué à 4. Dernière modification le 04 avril 2019 à 21:19.
Une API est-elle disponible, pour interface la bête avec des outils internes ?
J'hésite fortement à virer des parties de code maison par un outil plus complet, mais il faut que ça puisse s'interfacer.
Edit: suffisait de chercher, c'est indiqué là, tout en bas. https://cremecrm.com/fonctionnalites
Reste à en trouver la doc.
Merci !
alf.life
[^] # Re: Linuxfr et ipv6
Posté par Kioob (site web personnel) . En réponse à la dépêche La fin des IPv4 est très proche ! Les ennuis aussi…. Évalué à 3.
Tiens, sur la whishlist, on peut ajouter un entête HSTS ?
Il ne sera pris en compte que par les gens acceptant la CA actuelle, les intégristes pourront continuer à utiliser la version en clair. Bref, à priori que des avantages, non ?
alf.life
[^] # Re: ElasticSearch
Posté par Kioob (site web personnel) . En réponse au journal De la difficulté de trouver un moteur de recherche pertinent pour un site institutionnel du libre. Évalué à 2. Dernière modification le 13 janvier 2018 à 12:37.
En produit similaire bien qu'un peu plus bas niveau, on peut d'ailleurs citer SphinxSearch.
cf : https://en.wikipedia.org/wiki/Sphinx_(search_engine)
alf.life
# Yep !
Posté par Kioob (site web personnel) . En réponse au journal Cinéma : Blackhat (aka Hacker). Évalué à 1.
Personnellement ce film m'a bien plu oui, je l'ai trouvé relativement plausible si ce n'est le coup du "super cloud de la NSA" (Attention spoiler :
qui comble les trous d'une copie numérique d'un disque endommagé).La cerise sur le gâteau, c'est de me rendre compte que j'avais le même marteau que Chris Hemsworth, aka Thor. :D
alf.life
[^] # Re: Sans conséquences ???? C'est une courte vision de l'interopérabilité
Posté par Kioob (site web personnel) . En réponse à la dépêche Sortie du noyau Linux 4.2. Évalué à 3.
Juste une remarque : on pouvait demander au driver ext4 de prendre en charge les FS ext2&ext3 depuis longtemps.
Il s'agissait de l'option CONFIG_EXT4_USE_FOR_EXT23 dans les précédentes versions du noyau.
Je ne sais pas quand elle a été ajoutée, mais j'en ai des traces dans mes confs dès la version 2.6.38 de Linux.
alf.life
# Déjà vu !
Posté par Kioob (site web personnel) . En réponse au journal Stagefright, une faille Android qui va faire mal ?. Évalué à 4. Dernière modification le 28 juillet 2015 à 10:09.
Cette faille était déjà exploitée dans le film “Non-Stop”, avec Liam Neeson !
Ok ok, je sors. :)
alf.life
# WindowOverlay Icons
Posté par Kioob (site web personnel) . En réponse à la dépêche Elementary OS, une jolie distribution et facile pour tous, tout simplement !. Évalué à 3.
Du coup le dernier screenshot m'a fait re-découvrir l'extension WindowOverlay Icons, merci !
Je l'avais testée il y a longtemps, mais il me semble que le icones étaient petites et au milieu de la fenêtre, le tout non configurable. J'avais modifié le code moi même, sans être convaincu. Là ça a bien évolué, et ça me plait bien.
alf.life
[^] # Re: fcgid
Posté par Kioob (site web personnel) . En réponse à la dépêche Debian 8 : Jessie l’écuyère est en selle !. Évalué à 2. Dernière modification le 04 mai 2015 à 22:38.
fcgid est disponible depuis longtemps dans Debian oui, mais fastcgid quant à lui n'est disponible qu'en “non-free”.
Hors, seul ce dernier supporte les serveurs fastcgi externes, tels que PHP-FPM par exemple.
Une alternative est donc mod_proxy_fcgi, qui se contente de gérer le protocole fastcgi sans chercher à gérer les process associés. À l'image d'NginX par exemple.
alf.life
[^] # Re: apt-get vs aptitude
Posté par Kioob (site web personnel) . En réponse à la dépêche Debian 8 : Jessie l’écuyère est en selle !. Évalué à 2.
Ah effectivement, je suis déjà en contact avec lui dans le cadre de la Debian LTS, il faudra que je lui en parle à l'occasion.
alf.life
[^] # Re: apt-get vs aptitude
Posté par Kioob (site web personnel) . En réponse à la dépêche Debian 8 : Jessie l’écuyère est en selle !. Évalué à 3.
J'ai beau essayer de suivre tout ça d'assez près, ça me semble être un beau bordel quand même : les infos concernant Debian sont certes publiques, mais généralement éparpillées et souvent obsolètes.
Quand on voit que même packages.debian.org indique souvent des fichiers changelog sur metadata.ftp-master.debian.org, mais qu'on tombe régulièrement sur des 404 pour peu que la modif soit trop récente (quelques heures / jours), ça fait bricolage.
Je pensais pas qu'ils manquaient d'admin pour gérer leurs infras, mais si c'est le cas je peux probablement aider. Où trouve t-on ça ?
alf.life
[^] # Re: SSH 6.8
Posté par Kioob (site web personnel) . En réponse à la dépêche Debian 8 : Jessie l’écuyère est en selle !. Évalué à 4.
Oui, OpenSSH 6.8 ne sera pas dans le repository «standard» de Debian Jessie. Il faudra soit utiliser des backports (ce qui n'est probablement pas conseillé pour quelque chose d'aussi sensible), soit attendre la Debian 9, dans 2 ans.
alf.life
[^] # Re: Et devuan ?
Posté par Kioob (site web personnel) . En réponse à la dépêche Debian 8 : Jessie l’écuyère est en selle !. Évalué à 7.
Pour ma part j'ai pas le sentiment que la «communauté se soit déchirée» à propos de systemd. Je veux dire, oui quelques mainteneurs Debian ont claqué la porte, mais pour le moment ça ne m'impacte pas outre mesure, et si leur raison est uniquement systemd, qui reste facultatif, je ne comprends pas leur but.
C'est pas comme si un tiers des membres étaient partis, suite à une décision majeure.
alf.life
[^] # Re: apt-get vs aptitude
Posté par Kioob (site web personnel) . En réponse à la dépêche Debian 8 : Jessie l’écuyère est en selle !. Évalué à 2.
Je ne confirme rien du tout, ces outils restent présents. Seulement maintenant tu as aussi l'outil apt, sensé être plus simple et qui regroupe 90% des usages courants.
alf.life
[^] # Re: apt-get vs aptitude
Posté par Kioob (site web personnel) . En réponse à la dépêche Debian 8 : Jessie l’écuyère est en selle !. Évalué à 7.
Ou bien tu prends la peine de configurer le tout une bonne fois pour toutes :
alf.life
[^] # Re: apt-get vs aptitude
Posté par Kioob (site web personnel) . En réponse à la dépêche Debian 8 : Jessie l’écuyère est en selle !. Évalué à 2. Dernière modification le 28 avril 2015 à 09:53.
Et pourtant je maintiens : aptitude safe-upgrade accepte bien plus de mises à jour qu'un simple apt-get upgrade. Le prefix safe- n'est ici que pour faire la distinction avec le full-upgrade.
J'aurais tendance à dire que l'apt-get upgrade est hyper conservateur et ne prend pas le moindre risque, là où l'aptitude safe-upgrade essaye de faire un choix plus… réfléchis.
Pour utiliser régulièrement les 2 de manière complémentaires, j'apprécie justement cette subtilité de fonctionnement.
EDIT: je viens de faire un test, sur un desktop testing pas mis à jour depuis 2 semaines environ.
apt-get update me propose 193 mises à jour, là où aptitude safe-upgrade m'en propose 195.
En effet, apt-get ici ne veut pas mettre à jour libgit2-21, qui a maintenant une dépendance envers libhttp-parser2.1.
alf.life
[^] # Re: Ceph, une solution de stockage
Posté par Kioob (site web personnel) . En réponse à la dépêche Debian 8 : Jessie l’écuyère est en selle !. Évalué à 1.
Pour la version “RBD”, oui on pourrait le comparer à “LVM” (j'ai d'ailleurs des scripts qui utilisent l'un ou l'autre selon le contexte, de manière quasi identique).
Si ce n'est que c'est beaucoup beaucoup plus lourd à déployer. Ça consomme tellement qu'il est recommandé de dédier les machines de stockage à ce seul usage (sans oublier les machines de surveillance).
alf.life
[^] # Re: Problème sur la version de PHP livrée
Posté par Kioob (site web personnel) . En réponse à la dépêche Debian 8 : Jessie l’écuyère est en selle !. Évalué à 1.
Effectivement, c'est un changement qui a été fait après la rédaction de cette partie. merci pour l'info !
alf.life
[^] # Re: apt-get vs aptitude
Posté par Kioob (site web personnel) . En réponse à la dépêche Debian 8 : Jessie l’écuyère est en selle !. Évalué à 2.
C'est un peu le pendant d'“apt-get upgrade” excepté qu'aptitude s'autorise à supprimer les dépendances automatiques.
Extrais du manuel d'aptitude :
Extrais du manuel d'apt-get :
Au final, sur du testing ou sid, un “aptitude safe-upgrade” aura tendance à accepter des mises à jour qu'“apt-get upgrade” n'aurait pas faites.
Et dans le cas d'une mise à jour Wheezy→Jessie, j'aurais tendance à la faire en plusieurs étapes : apt-get upgrade; aptitude upgrade ; apt-get dist-upgrade
alf.life