kna a écrit 759 commentaires

Je ne sais pas si c'est toujours le cas, mais à l'époque où j'ai voulu utiliser le client letsencrypt officiel, celui-ci arrêtait complètement le serveur web, pour démarrer le sien, afin que les serveurs letsencrypt fasse leur vérification.

Il y a un module standalone, tu lui indiques juste les domaines et docroot, il ne touche pas au service web.

A être critique vis à vis de l'information

Et de soi-même. Le cerveau humain tombe facilement dans des biais cognitifs. C'est difficile de remettre en question une information qui correspond à nos convictions, alors qu'on sera facilement très critique sur une autre information.

Si je répands une rumeur comme quoi la terre est plate, ben, quand même, hein, c'est une fake news, ça ne se discute pas trop…

Aujourd'hui oui, mais ça n'a pas toujours été le cas.
D'une manière générale, la science doit être révisionniste. La vérité, c'est juste une théorie qu'on admet jusqu'à ce que quelqu'un démontre qu'elle est fausse ou incomplète.

Alors, oui, on trouvera des hurluberlus qui vont pondre des théories totalement fantaisistes ou complotistes. Mais je ne pense pas que les censurer soit une bonne chose, ça va les conforter dans la théorie complotiste.

Mouais, alors faut quand même pas te planter, genre pour ton mot de passe youtube c'est youtube.com, google.com, google.fr ? Pour amazon, c'est amazon.com ou amazon.fr ?

Rajoute à ça le login à retenir pour chaque site, entre :
- ceux où c'est ton pseudo
- ceux où c'est ton adresse mail (laquelle ?)
- ceux où ton pseudo est pris
- ceux où on t'a donné un identifiant client

Sur le long terme, ça devient assez contraignant.

Je ne connais pas du tout le fonctionnement de ces outils (Je vois à quoi ils servent mais je ne m'en suis jamais servis), ce n'est pas ma fonction de livrer des OS.

Tu bosses où ? Histoire que je n'y aille pas…

Cela dit si les outils en questions ne sont pas capable d'aller écrire une ligne dans un fichier, faut se poser des questions …

Ils peuvent. C'est juste plus sûr pour être idempotent d'avoir des fichiers séparés, soit le fichier est présent soit il ne l'est pas. T'es certain de ne pas t'être planté dans ta regex et d'insérer la ligne en double, ou une ligne avec ON et l'autre avec OFF.

Vraie question : comment tu gères plusieurs instances d'un même service sous FreeBSD ?

Il y a une source là-dessus ? Parce que si c'est le cas, fini LDLC pour moi.

Pour cdiscount, je les ai déjà banni suite au tacle de la CNIL.

Suivre la logique systemd/RedHat jusqu'au bout.

Ben c'est pareil chez RedHat, il reste des scripts dans /etc/init.d (par exemple network). Si tu les lances, le bash intercepte la commande pour lancer systemctl à la place qui génère un unit à la volée…

Cela dit, j'utilise en majorité debian, mais j'ai l'impression que plus de services ont été migrés vers systemd sur RH/CentOS en comparaison à debian.

Et je ne sais pas si on trouve des services aussi mal migrés chez RedHat. Mais sous debian, je suis tombé sur des trucs assez moches, par exemple :
- opendkim utilise maintenant un unit systemd, mais il ne lit plus /etc/default/opendkim (bien que le fichier soit toujours installé par le paquet)
- openvpn installe un unit avec ExecStart=/bin/true ! Il y a toujours un script dans /etc/init.d mais il ne sera jamais lancé si systemd est installé…

Ben, ça évolue.
Pour les services tu as systemd qui est arrivé, donc ça change. celà dit les anciennes commandes fonctionnent toujours. Pour tout dire, j'aurais préféré qu'elles ne fonctionnent plus et qu'ils aient migré totalement vers systemd, plutôt que le monstre mi-systemd mi-sysv avec des wrappers de l'un vers l'autre…
Pour le firewall, tu as xft qui a débarqué, parce que oui, la syntaxe iptables est pas terrible. Mais iptables est toujours disponible, tes vieux scripts iptables écrit il y a 10 ans fonctionnent toujours.

Dans le même genre : juste ajouter un "LIMIT 1" à la fin de toutes les requêtes ne concernant qu'une seule ligne. Ou 2 si c'est 2, etc…

Dans le fond, tu as raison, mais comme ça me rappelle un mauvais souvenir, je précise : en ayant mis des contraintes d'unicité là où il faut !

D'un autre côté une preuve mathématique d'une telle résolution, telle que tu la décris, supposerait non seulement une puissance de calcul mais surtout de stockage difficilement imaginable en terme physique

Il y a des astuces pour réduire ces besoins (même si ça reste assez énorme aujourd'hui), un journal ici-même a fait la promotion d'un article sur le sujet : https://linuxfr.org/users/pitilapinou/journaux/resolution-du-jeu-d-echecs-patience-ca-arrive

Je dirais que c'est tellement une généralité que ça ne l'est pas que chez Amazon. Tu as plus de chances d'être bien traité en bossant comme dev que comme manutentionnaire (même s'il y a des exceptions).

Le sujet a déjà été discuté : https://linuxfr.org/users/denisdordoigne/journaux/debian-va-debrancher-ses-depots-ftp#comment-1701244

En gros, la sécurité n'est pas dans le transport, mais dans la signature GPG des paquets.

En fait tu n'as pas besoin de garder le Windows sur le PC : la clé Windows est enregistrée dans le BIOS.

Et tu peux la lire depuis Linux dans /sys/firmware/acpi/tables/MSDM

Le plus gros obstacle que je vois, c'est la difficulté de générer des deb, mais une fois que l'admin a pris le truc, ça ne doit même plus être un obstacle, si?

Avec dpkg-deb ça reste assez trivial, le paquet généré ne sera jamais accepté dans les repos debian, mais en interne ça fait le job.
Si tout peut tenir dans un dossier dans /opt, tu peux aussi faire un bête tar, et déployer sur les machines avec ansible.

Ça va être sympa pour les employés, de changer d'OS et d'applications à chaque changement de maire.

Je peux concevoir plein de raisons pour ne pas passer au libre : fonctionnalités manquantes, problèmes d'intéropabilité avec des tiers ou du matos, poids de l'historique, coût de la migration. Même une bête résistance au changement ça peut se comprendre. Mais passer de l'un à l'autre à chaque fois qu'on change de maire, parce que l'un est pro-MS et l'autre pro-libre, c'est se foutre royalement des utilisateurs et de l'argent des contribuables.

M'enfin, c'est qu'un exemple de plus d'élu qui ne voit pas plus loin que le bout de son mandat…

Avant grub s'installait sur le MBR du premier disque et le BIOS bootait dessus.
Sur les PC modernes ont un UEFI, c'est en gros un BIOS++ qui fait le café, et permet entre autre de choisir directement le système sur lequel tu bootes.

Je suppose vu ta description que quand tu appuies sur Echap, tu tombes sur le bootloader de l'UEFI, et quand tu choisis Linux il charge grub.
Tu as alors 2 solutions :
- tu dois probablement pouvoir choisir un boot « Legacy » dans la configuration de l'UEFI (« dans le BIOS » si tu préfères), il bootera à l'ancienne comme un BIOS standard, et devrait tomber sur le grub (il faut alors t'assurer que ton grub soit capable de booter ton windows pour pouvoir l'utiliser)
- tu peux choisir le boot par défaut de ton UEFI. Si ce n'est pas possible depuis l'UEFI directement, tu peux le faire depuis Ubuntu avec efibootmgr. Il doit probablement exister des utilitaires sous windows aussi pour ça, mais je ne connais pas…

À noter que si tu choisis un boot « legacy » ça doit être le paquet grub-pc qui doit être installé, et si tu bootes via l'EFI c'est grub-efi (la config est la même pour les deux après). Du moins c'est le cas sous debian et je suppose que c'est pareil sous ubuntu.
À l'install, il doit avoir détecté l'UEFI donc tu dois logiquement avoir grub-efi d'installé actuellement.

EDIT: en lisant les autres commentaires, je m'aperçois que je n'ai pas pensé au cas où tu as 2 disques et windows installé sur le premier. Il faudrait vérifier si c'est le bootloader de windows ou de l'UEFI que tu utilises actuellement.

L'inconvénient de dpkg --get-selections est qu'il liste tous les paquets, y compris ceux installés par dépendance.

Si on veut juste les paquets installés manuellement, on peut utiliser apt-mark showmanual sous Jessie.
En revanche, sous Stretch la commande liste aussi les paquets installés manuellement mais supprimés (si non purgés). Je fais donc depuis Stretch :

apt-mark showmanual > $FILE
for package in $(apt-mark showremove) ; do
    sed -i "/^${package}$/d" $FILE
done

Dans le navigateur, cette « censure » n'en est pas une, et n'est pas un problème, car :
- c'est fait dans le navigateur, sur le poste de l'utilisateur (le réseau reste idiot et balance les paquets qu'on lui demande) ;
- c'est clairement indiqué que le site est bloqué et pourquoi ;
- comme tu le précises, c'est désactivable.

Ce n'est pas la même chose avec un DNS menteur. Sauf si tu te fais ton propre DNS menteur sur ta machine/ton réseau local…

Mais même avec le bon caractère, ça prête à confusion : https://fr.wikipedia.org/wiki/Lapalissade#.C3.89tymologie

Personnellement je pense qu'utiliser l'argument du "c'est pas lisible" pour le combattre n'est pas pertinent,

oué ta réson on sen fou kse soi lizible.

Tu dois pouvoir voir les messages d'erreur renvoyés par le serveur distant, dans les logs ou avec qmhandle -R (je ne me souviens plus), qui doivent te dire pourquoi les messages sont refusés.

Il y a aussi :
* vimium-ff
* saka-key

Je ne sais pas ce qu'elles valent par contre. Je suis toujours en ESR avec VimFx (supporte le multi-process contrairement à Vimperator, mais pas webextensions).

Ça fait quelques temps que je n'ai pas touché à qmail, mais de mémoire, tu dois pouvoir voir pourquoi les messages ne sont pas délivrés, soit dans les logs, soit avec des outils comme qmHandle.

Note que, sauf patch spécifique, qmail ne refuse pas un message tant qu'il a la gestion du domaine. Si on lui envoie un message pour un domaine existant mais pour une adresse inexistante, il va l'accepter, puis constater que le compte n'existe pas, et essayer d'envoyer un message « failure notice » à l'expéditeur (indiquant que l'adresse n'existe pas). Comme la plupart des spams sont envoyés avec des faux From, et que la plupart des autres serveurs mails vont refuser directement un message pour une adresse inexistante, ces failure notice s'empilent dans la mailqueue.

Même pas, il faut voir quel est ton besoin et distinguer 2 types de supervision :

• la métrologie : des jolis graphes pour tout type de métrique sur les machines (munin/grafana)
• le monitoring : des checks avec alertes, historique, éventuellement SLA (nagios et co.)

On me fera remarquer que les checks de monitoring s'appuient souvent sur les mêmes métriques que celles qui sont graphées. De plus en plus on cherche à avoir un seul outil qui concilie les 2. Mais aujourd'hui ça a l'air encore balbutiant. Tu pourras trouver pas mal d'articles et discussions à ce sujet sur le web, il y avait eu par exemple une discussion sur FRsAG sur le sujet : https://www.frsag.org/pipermail/frsag/2017-August/008701.html

Euh, je lance Xorg en user sur ma stretch moi !

Je n'utilise pas de gestionnaire de connexion par contre ([ $(tty) = "/dev/tty1" ] && startx dans mon ~/.bashrc).