Merci pour la synthèse ! C'est exactement ce que je recherchais.
Je vais faire un essai avec Migadu je pense (j'accorde des points bonus aux offres Européennes ;)), ils ont l'air sérieux et le prix est tout à fait décent rapport à mon besoin.
J'ai pendant longtemps hébergé mes mails tout seul, mais la gestion de SPF, DKIM, DMARC, se faire placer dans les bonnes listes etc, j'en ai eu marre…
Avec ce qui se passe chez Gandi, et en faisant le tour des offres où je ne trouve rien qui me corresponde, je me dis que je devrais peut être reprendre l'hébergement de mes mails.
Il me faudrait juste un SMTP sortant pour gérer tout ce foutoir des bonnes pratiques. Vous avez des retours d'expérience ? (je suis prêt à payer pour le service, du moment que c'est un tarif "raisonnable").
Certes, le site d'OVH est un modèle de ce qu'il ne faut pas faire tellement c'est impossible de trouver quelque chose dans les menus (j'imagine qu'avec autant de produit, c'est inévitable ?), mais l'offre existe :
Dans ton cas, GnuCash semble adapté. Je l'utilise pour ma compta perso : les données sont stockées dans un MySQL en réseau et quand madame ouvre la compta sur son ordi, ça me dit que quelqu'un est déjà en train de travailler les données (une entrée dans la DB sert de lock). Et c'est multiplateforme (Linux, Windows, Mac et probablement les *BSD)
Tu ne connaitra jamais les intentions de la personne qui t'explique que ceci est bien et cela mal. Il peut très bien tenter de te manipuler (exemple : Rafael pourrait être l'auteur de ce logiciel payant, as tu vérifié ?).
La généralisation du SSD implique une plus petite capacité pour la masse (exemple: les laptops d'Apple qui viennent en standard avec 128G/256G).
Du coup, la data doit être stockée ailleurs, dans le fameux Cloud. C'est ça aussi le besoin de la masse, un Cloud qui fonctionne. Donc il faut un filesystem pour les opérateurs de Cloud. Et ça malheureusement, ça n'existe pas vraiment. Ceux qui font du stockage en masse (type Object Storage) pourront vous le dire, aucun filesystem POSIX n'est taillé pour cet usage (ni btrfs, ni ZFS, ni les autres). Et donc tous les gros opérateurs dev leurs propre solution de stockage sur disque (ou se base des solutions type haystack/bluestore/…).
C’est pour ça que tu as les configurations splay et splaylimit qui permettent
d’avoir des run répartit plus ou moins aléatoirement.
J'aime pas trop dans le sens ou tu cumule un pseudo-random avec un vrai random (le moment de démarrage du démon). Je suis d'accord que statistiquement ça doit être correctement réparti. Mais si un moment ton master lag un peu, stack des connections, ben les run d'agents vont se décaler, commencer en même temps, et donc ils seront synchroniser. Oui, c'est des choses qui ne devraient pas arriver. Mais d'expérience, ce qui ne doit pas arriver fini toujours par arriver :)
Le cron, c'est pseudo-random, et stable dans le temps. Quoi qu'il arrive, ça démarrera toujours au même moment.
Après, à toi de mettre la supervision nécessaire pour vérifier que Puppet
fonctionne correctement.
En effet, j'ai de la supervision qui vérifie que Puppet tourne régulièrement, et qu'il fini sans erreur. Et j'avais constaté des blocages en mode agent. Alors là je parle de Puppet 2.7. Ce soucis a peut être été réglé depuis, je ne suis juste pas revenu en arrière. Cron ça marche, je consacre mon temps à d'autres priorités.
Plusieurs milliers de machine et un seul master, ça me paraît légèrement sous
dimensionné comme infra non ?
Ben en faites non, c'était pas un soucis. Alors évidement, je parle pas d'un master en "process" avec 4 coeurs et 8G de RAM (plutôt passenger, 24 coeurs et 32GB de RAM). A force de faire grandir le catalogue (et le nombre de d'agents), ça commençait à devenir un peu limite, alors on a ajouté un second master. Il parait que le puppet-server ça rox, mais mon catalogue est pas encore complètement "puppet 4 compliant"
Ja favorise également un run en cron. Dans le passé, j'ai remarqué qu'en mode daemon, les run avaient tendance à se regrouper. Je me retrouvais donc avec plusieurs millier de run en quelques minutes, le master n'aimait pas trop
De plus, en cron, même si tu le kill (parce que tu kill si le run est pas fini au bout de X minutes, parce que oom, …), tu sais que l'agent sera de nouveau exécuté plus tard. En mode daemon, faut que tu le relance toi même.
puppet agent -t --onetime --logdest /var/…
- onetime est inclus dans -t, donc inutile de le remettre
- pourquoi ne pas utiliser syslog ? ça tombe généralement dans un fichier genre /var/log/messages ou daemons, qui est déjà géré par syslog et logrotate. ça t'évite de devoir créer des dossiers, des commandes de nettoyage, etc…
fqdn_rand() n'est pas aléatoire mais pseudo aléatoire. Il te sort un entier dépendant du fqdn de ta machine (et optionnellement d'un seed). si c'était vraiment aléatoire, ça changerait à chaque run, ce qui ne serait pas souhaitable.
service { … }
- hasstatus vaut true par défaut, donc pas utile de le préciser
- ne pas oublier enable => false pour pas que le démon se relance au démarrage
Ensuite, ton système impose des cases à cocher ou des trous à percer, donc toute une logistique (stylos, perforatrices) et une complexité (avec les risques d'erreurs qui vont avec) totalement inutiles. En plus, dès qu'il faut manipuler les bulletins, il est possible de faire des petites marques discrètes qui pourraient permettre des dérives.
Le même bulletin papier, avec un QRCode dans un coin. Simple, risque d'erreur extrêmement faible.
Au contraire des trois autres, il n'utilise pas d'agents (agentless), c'est à dire que rien n'a besoin de tourner côté serveur pour le faire fonctionner, ce qui le rend de facto plus facile à mettre en place. Il requiert seulement un accès SSH et python sur les serveur.
C'est le point qui me bloque un peu. Avec Puppet (c'est ce que j'utilise), si jamais je me plante sur la configuration du démon SSH, ou du firewall, ou du authorized_keys, je sais que l'agent continue de tourner. Donc je pourrais toujours rattraper le coup. Avec Ansible, c'est perdu…
Alors oui, j'ai des environnements de dev et de preprod, mais ça n'empêche pas que parfois on loupe un truc parce qu'il y a une subtile différence entre la preprod et la prod (oui, c'est mal, mais nul n'est parfait).
Et bien sûr, je ne prod jamais en même temps une modification de configuration de l'agent Puppet et une modification qui risquerai de me faire perdre la main sur les serveurs :)
"La raison pour laquelle OVH tourne sur Xen est purement historique."
Hum. Source ? Parce que, d'une source très sûre, OVH ne vend pas de Xen ni pour VPS ni pour autre chose. Que du KVM. Tiens, une source pour confirmer mes dire : https://www.ovh.com/fr/vps/ (chercher KVM)
Le journaliste n'a rien fait de mal. C'est le titre d'Octave Klaba. Si tu demande à Octave son job il te dira CTO. Le journaliste ne fait que rapporter l'info
OVH est une boite internationale avec des bureaux dans une douzaine pays, alors la terminologie anglaise peut faire sens. Un Allemand (du métier de l'informatique) ne sait pas forcément ce qu'est un DSI. Alors qu'un CTO, ya plus de chance.
Je l'utilise à titre perso depuis plusieurs années, avec grande satisfaction. Je l'ai déployé à mon ancien job, chez des clients, …
J'utilise la v2 car je suis pas fan de la nouvelle interface en v3 (la v2 est toujours maintenue)
Ca scale bien, c'est fiable, ça s'interface bien côté serveur (choisi ton LDAP, choisi ta DB, choisi ton serveur IMAP/SMTP) comme côté client (Linux Evolution/KDE, MacOS, iPhone, Android, …) J'ai brièvement testé avec Windows la compatibilité exchange, ça semblait OK.
(c'est pas très structuré, mais là j'ai la flemme, dsl)
Je lis dans les commentaires que les gens ont le sentiment que OpenStack est difficile à déployer/maintenir/…
Etant sysadmin sur de l'OpenStack de "grande envergure", je vais donner mon point de vu. Petite remarque, je fais de l'object storage (Swift) avec les briques qui tournent autour (Keystone, Ceilometer).
Malgré ce que vous diront les formateurs et les vendeurs, OpenStack n'est pas adapté pour les petits déploiements. Il est clair que les gros providers ont pris le pouvoir sur la roadmap. Il suffit d'aller aux OpenStack Summit (et particulièrement les Dev Summit) pour s'en rendre compte. C'est normal, tout l'ensemble est pensé pour être déployé et pour "scaler" sur de grosse infrastructure. Bien sur, vous pouvez faire un déploiement sur 3 hosts, mais l'ensemble sera quasi impossible à faire évoluer. La moindre mise à jour sera une plaie et se finira en échec. Si vous avez les ressources hardware nécessaire, vous pourrez faire "danser" les services d'une machine à l'autre et faire vos mises à jour sereinement (enfin, presque :D).
Pour parler de ce que je connais mieux, côté Swift, le système n'a quasiment pas de limite… A condition de savoir ce qu'on fait. Il est facile de monter une infra Swift qui va "s'écrouler" passer quelques centaines de TB. Si on comprend et on maitrise le produit, on l'emmène à plusieurs dizaine de PB sans soucis, et probablement plus. Mais la barrière d'entrée est élevée, il faut passer du temps à comprendre les rouages, je ne compte plus le nombre de fois ou j'ai été lire le code pour comprendre la raison d'un comportement, il ne faut pas compter sur la doc pour ça. Le logiciel, comme tout OpenStack, est très souple. On peut l'adapter à ses besoins ou lui tordre le bras à volonté, très simplement.
Bref, il est clair que OpenStack a du sens pour les sociétés qui ont le besoin de grosse infra et qui peuvent se permettre d'investir du temps humain. Sinon, prenez du VMWare et/ou de l'EMC.
Dans certains pays, la consultation de certaines pages Wikipedia peut être mal "perçue".
Alors oui, il y a des solutions techniques (Tor & co), mais ça n'est pas accessible à tout le monde car il faut avoir quelques connaissances (savoir que ça existe tout simplement). Et si on fait des recherches sans SSL du type "comment ne pas être espionné", ben on est grillé également.
Le chiffrement par défaut protège tout le monde car, entre autre, ceux qui ont besoin de se protéger se fondent dans la masse.
Cette limitation de hubiC n'existe plus. D'ailleurs de chez moi (fibre Orange), je télécharge à plus de 80Mb/s et je téléverse à plus de 45Mb/s (j'ai une connexion 100/50Mbps). Ca me parait pas si mal :)
Même si c'est pas explicitement dit dans le PDF, ce qui y est décrit est trop énorme pour que ce soir upstream sans que personne ne l'ai vu. J'en conclus qu'il n'y a rien à voir dans OpenSSH et que c'est une version maison de la NSA (sauf si Théo est un agent de la NSA ;)), pour maintenir l'accès qu'ils ont déjà à un serveur. C'est malin, mais tant qu'ils ont pas troué ton système, ça ne te concerne pas.
[^] # Re: Offre de SMTP sortant ?
Posté par ondex2 . En réponse au journal Gandi, passe de « no bullshit » à « bait and switch » ?. Évalué à 2.
Tu peux m'envoyer un mail si tu veux pour lancer la discussion:
r.algoo ==chez== ledisez.net
(oui oui, j'use et j'abuse des alias dynamiques ;))
[^] # Re: Offre de SMTP sortant ?
Posté par ondex2 . En réponse au journal Gandi, passe de « no bullshit » à « bait and switch » ?. Évalué à 1. Dernière modification le 16 juin 2023 à 08:24.
Merci pour la synthèse ! C'est exactement ce que je recherchais.
Je vais faire un essai avec Migadu je pense (j'accorde des points bonus aux offres Européennes ;)), ils ont l'air sérieux et le prix est tout à fait décent rapport à mon besoin.
# Offre de SMTP sortant ?
Posté par ondex2 . En réponse au journal Gandi, passe de « no bullshit » à « bait and switch » ?. Évalué à 3.
J'ai pendant longtemps hébergé mes mails tout seul, mais la gestion de SPF, DKIM, DMARC, se faire placer dans les bonnes listes etc, j'en ai eu marre…
Avec ce qui se passe chez Gandi, et en faisant le tour des offres où je ne trouve rien qui me corresponde, je me dis que je devrais peut être reprendre l'hébergement de mes mails.
Il me faudrait juste un SMTP sortant pour gérer tout ce foutoir des bonnes pratiques. Vous avez des retours d'expérience ? (je suis prêt à payer pour le service, du moment que c'est un tarif "raisonnable").
[^] # Re: format automatique
Posté par ondex2 . En réponse au journal Quelles seraient les meilleures règles de formatage de code ?. Évalué à 5.
Tu peux en mettre plusieurs dans le fichier (si tu change d'avis sur le soft de formatage par exemple ;))
La doc : https://git-scm.com/docs/git-blame#Documentation/git-blame.txt---ignore-revs-fileltfilegt
[^] # Re: Plus d'infos
Posté par ondex2 . En réponse au journal Améli et la Souveraineté Numérique. Évalué à 4.
Certes, le site d'OVH est un modèle de ce qu'il ne faut pas faire tellement c'est impossible de trouver quelque chose dans les menus (j'imagine qu'avec autant de produit, c'est inévitable ?), mais l'offre existe :
https://www.ovh.com/fr/solutions/load-balancer/
[^] # Re: version branchée ,
Posté par ondex2 . En réponse à la dépêche Sortie de la version 2.0 de Grisbi, logiciel de comptabilité. Évalué à 2.
Dans ton cas, GnuCash semble adapté. Je l'utilise pour ma compta perso : les données sont stockées dans un MySQL en réseau et quand madame ouvre la compta sur son ordi, ça me dit que quelqu'un est déjà en train de travailler les données (une entrée dans la DB sert de lock). Et c'est multiplateforme (Linux, Windows, Mac et probablement les *BSD)
# Qui choisit ?
Posté par ondex2 . En réponse au journal La trumpmania des journaux français. Évalué à 10.
Est ce les journaux Français qui sont obsédés de Trump, ou l'IA de Google qui pense que ça va t'intéresser, étant donné ton historique de navigation ?
Rend toi service, quitte Google News et va toi même sur un/des sites d'informations (et si tu t'abonne, c'est encore mieux ;))
[^] # Re: ?
Posté par ondex2 . En réponse au journal ukuu, un outil pour gérer ses kernels linux => Gniii ---- Payant ? => Gniii². Évalué à 5.
Tu ne connaitra jamais les intentions de la personne qui t'explique que ceci est bien et cela mal. Il peut très bien tenter de te manipuler (exemple : Rafael pourrait être l'auteur de ce logiciel payant, as tu vérifié ?).
Seule solution : réfléchir par toi même.
[^] # Re: Google pour la neutralité
Posté par ondex2 . En réponse au journal la neutralité du net bronsonisée. Évalué à 1.
Je suis pas un fan de Google, loin de là, mais raconter n'importe quoi n'aide pas a lutter contre son adversaire.
[^] # Re: ssd
Posté par ondex2 . En réponse au journal Btrfs ne serait plus le futur. Évalué à 4.
La généralisation du SSD implique une plus petite capacité pour la masse (exemple: les laptops d'Apple qui viennent en standard avec 128G/256G).
Du coup, la data doit être stockée ailleurs, dans le fameux Cloud. C'est ça aussi le besoin de la masse, un Cloud qui fonctionne. Donc il faut un filesystem pour les opérateurs de Cloud. Et ça malheureusement, ça n'existe pas vraiment. Ceux qui font du stockage en masse (type Object Storage) pourront vous le dire, aucun filesystem POSIX n'est taillé pour cet usage (ni btrfs, ni ZFS, ni les autres). Et donc tous les gros opérateurs dev leurs propre solution de stockage sur disque (ou se base des solutions type haystack/bluestore/…).
[^] # Re: pourquoi ne pas faire conviance au daemon ?
Posté par ondex2 . En réponse au journal Puppet [2] : run puppet et cron. Évalué à 2.
J'aurais peut être du préciser que c'est plus en 2.7. C'est en 3.8 maintenant, en train de faire les correctifs pour "sauter" en 4+
5500 machines, run toutes les 30 minutes.
[^] # Re: pourquoi ne pas faire conviance au daemon ?
Posté par ondex2 . En réponse au journal Puppet [2] : run puppet et cron. Évalué à 1.
J'aime pas trop dans le sens ou tu cumule un pseudo-random avec un vrai random (le moment de démarrage du démon). Je suis d'accord que statistiquement ça doit être correctement réparti. Mais si un moment ton master lag un peu, stack des connections, ben les run d'agents vont se décaler, commencer en même temps, et donc ils seront synchroniser. Oui, c'est des choses qui ne devraient pas arriver. Mais d'expérience, ce qui ne doit pas arriver fini toujours par arriver :)
Le cron, c'est pseudo-random, et stable dans le temps. Quoi qu'il arrive, ça démarrera toujours au même moment.
En effet, j'ai de la supervision qui vérifie que Puppet tourne régulièrement, et qu'il fini sans erreur. Et j'avais constaté des blocages en mode agent. Alors là je parle de Puppet 2.7. Ce soucis a peut être été réglé depuis, je ne suis juste pas revenu en arrière. Cron ça marche, je consacre mon temps à d'autres priorités.
Ben en faites non, c'était pas un soucis. Alors évidement, je parle pas d'un master en "process" avec 4 coeurs et 8G de RAM (plutôt passenger, 24 coeurs et 32GB de RAM). A force de faire grandir le catalogue (et le nombre de d'agents), ça commençait à devenir un peu limite, alors on a ajouté un second master. Il parait que le puppet-server ça rox, mais mon catalogue est pas encore complètement "puppet 4 compliant"
[^] # Re: pourquoi ne pas faire conviance au daemon ?
Posté par ondex2 . En réponse au journal Puppet [2] : run puppet et cron. Évalué à 0.
Ja favorise également un run en cron. Dans le passé, j'ai remarqué qu'en mode daemon, les run avaient tendance à se regrouper. Je me retrouvais donc avec plusieurs millier de run en quelques minutes, le master n'aimait pas trop
De plus, en cron, même si tu le kill (parce que tu kill si le run est pas fini au bout de X minutes, parce que oom, …), tu sais que l'agent sera de nouveau exécuté plus tard. En mode daemon, faut que tu le relance toi même.
# Quelques précisions
Posté par ondex2 . En réponse au journal Puppet [2] : run puppet et cron. Évalué à 3.
puppet agent -t --onetime --logdest /var/…
- onetime est inclus dans -t, donc inutile de le remettre
- pourquoi ne pas utiliser syslog ? ça tombe généralement dans un fichier genre /var/log/messages ou daemons, qui est déjà géré par syslog et logrotate. ça t'évite de devoir créer des dossiers, des commandes de nettoyage, etc…
fqdn_rand() n'est pas aléatoire mais pseudo aléatoire. Il te sort un entier dépendant du fqdn de ta machine (et optionnellement d'un seed). si c'était vraiment aléatoire, ça changerait à chaque run, ce qui ne serait pas souhaitable.
service { … }
- hasstatus vaut true par défaut, donc pas utile de le préciser
- ne pas oublier enable => false pour pas que le démon se relance au démarrage
[^] # Re: Machine a dépouillé
Posté par ondex2 . En réponse au journal Vote à l'urne et vote électronique. Évalué à 4.
Le même bulletin papier, avec un QRCode dans un coin. Simple, risque d'erreur extrêmement faible.
# Agentless, danger
Posté par ondex2 . En réponse au journal Déploiement et automatisation avec Ansible - partie 1. Évalué à 3.
C'est le point qui me bloque un peu. Avec Puppet (c'est ce que j'utilise), si jamais je me plante sur la configuration du démon SSH, ou du firewall, ou du authorized_keys, je sais que l'agent continue de tourner. Donc je pourrais toujours rattraper le coup. Avec Ansible, c'est perdu…
Alors oui, j'ai des environnements de dev et de preprod, mais ça n'empêche pas que parfois on loupe un truc parce qu'il y a une subtile différence entre la preprod et la prod (oui, c'est mal, mais nul n'est parfait).
Et bien sûr, je ne prod jamais en même temps une modification de configuration de l'agent Puppet et une modification qui risquerai de me faire perdre la main sur les serveurs :)
[^] # Re: .
Posté par ondex2 . En réponse au journal Retour d'expérience sur un hébergeur Français. Évalué à 4.
"La raison pour laquelle OVH tourne sur Xen est purement historique."
Hum. Source ? Parce que, d'une source très sûre, OVH ne vend pas de Xen ni pour VPS ni pour autre chose. Que du KVM. Tiens, une source pour confirmer mes dire : https://www.ovh.com/fr/vps/ (chercher KVM)
# Mais pourquoi est il si méchant ?
Posté par ondex2 . En réponse au journal Ils ont cassé Internet. Évalué à 4.
En lisant ton résumé, je ne me pose qu'une question : Qui a intérêt à DDoS gmane ?
Je ne vois pas, et apparement lui non plus :
[^] # Re: Journalisme aware…
Posté par ondex2 . En réponse au journal UBUNTU vs OVH : ça vous choque ?. Évalué à 7.
Le journaliste n'a rien fait de mal. C'est le titre d'Octave Klaba. Si tu demande à Octave son job il te dira CTO. Le journaliste ne fait que rapporter l'info
OVH est une boite internationale avec des bureaux dans une douzaine pays, alors la terminologie anglaise peut faire sens. Un Allemand (du métier de l'informatique) ne sait pas forcément ce qu'est un DSI. Alors qu'un CTO, ya plus de chance.
[^] # Re: Chouette
Posté par ondex2 . En réponse à la dépêche Inverse annonce la sortie de la version 3.1 de SOGo. Évalué à 2.
Je l'utilise à titre perso depuis plusieurs années, avec grande satisfaction. Je l'ai déployé à mon ancien job, chez des clients, …
J'utilise la v2 car je suis pas fan de la nouvelle interface en v3 (la v2 est toujours maintenue)
Ca scale bien, c'est fiable, ça s'interface bien côté serveur (choisi ton LDAP, choisi ta DB, choisi ton serveur IMAP/SMTP) comme côté client (Linux Evolution/KDE, MacOS, iPhone, Android, …) J'ai brièvement testé avec Windows la compatibilité exchange, ça semblait OK.
Bref, SOGo c'est bon, mangez en !
[^] # Re: Trop NASA par assez Métier.
Posté par ondex2 . En réponse à la dépêche Présentation d’OpenStack. Évalué à 5.
(c'est pas très structuré, mais là j'ai la flemme, dsl)
Je lis dans les commentaires que les gens ont le sentiment que OpenStack est difficile à déployer/maintenir/…
Etant sysadmin sur de l'OpenStack de "grande envergure", je vais donner mon point de vu. Petite remarque, je fais de l'object storage (Swift) avec les briques qui tournent autour (Keystone, Ceilometer).
Malgré ce que vous diront les formateurs et les vendeurs, OpenStack n'est pas adapté pour les petits déploiements. Il est clair que les gros providers ont pris le pouvoir sur la roadmap. Il suffit d'aller aux OpenStack Summit (et particulièrement les Dev Summit) pour s'en rendre compte. C'est normal, tout l'ensemble est pensé pour être déployé et pour "scaler" sur de grosse infrastructure. Bien sur, vous pouvez faire un déploiement sur 3 hosts, mais l'ensemble sera quasi impossible à faire évoluer. La moindre mise à jour sera une plaie et se finira en échec. Si vous avez les ressources hardware nécessaire, vous pourrez faire "danser" les services d'une machine à l'autre et faire vos mises à jour sereinement (enfin, presque :D).
Pour parler de ce que je connais mieux, côté Swift, le système n'a quasiment pas de limite… A condition de savoir ce qu'on fait. Il est facile de monter une infra Swift qui va "s'écrouler" passer quelques centaines de TB. Si on comprend et on maitrise le produit, on l'emmène à plusieurs dizaine de PB sans soucis, et probablement plus. Mais la barrière d'entrée est élevée, il faut passer du temps à comprendre les rouages, je ne compte plus le nombre de fois ou j'ai été lire le code pour comprendre la raison d'un comportement, il ne faut pas compter sur la doc pour ça. Le logiciel, comme tout OpenStack, est très souple. On peut l'adapter à ses besoins ou lui tordre le bras à volonté, très simplement.
Bref, il est clair que OpenStack a du sens pour les sociétés qui ont le besoin de grosse infra et qui peuvent se permettre d'investir du temps humain. Sinon, prenez du VMWare et/ou de l'EMC.
[^] # Re: Le mauvais pro et le bon pro
Posté par ondex2 . En réponse au journal OpenSSH No Longer Has To Depend On OpenSSL. Évalué à 10.
Le vrai pro il a un vrai métier avec des vraies choses à faire, alors recompiler openssh avec/sans openssl, il s'en fout royalement…
[^] # Re: Mauvais problème
Posté par ondex2 . En réponse au journal HTTP poussé vers la sortie ?. Évalué à 10.
Dans certains pays, la consultation de certaines pages Wikipedia peut être mal "perçue".
Alors oui, il y a des solutions techniques (Tor & co), mais ça n'est pas accessible à tout le monde car il faut avoir quelques connaissances (savoir que ça existe tout simplement). Et si on fait des recherches sans SSL du type "comment ne pas être espionné", ben on est grillé également.
Le chiffrement par défaut protège tout le monde car, entre autre, ceux qui ont besoin de se protéger se fondent dans la masse.
[^] # Re: aucun intérêt pour les petites connexions
Posté par ondex2 . En réponse au journal On vient de passer un seuil économique pour la sauvegarde en ligne !. Évalué à 2.
Cette limitation de hubiC n'existe plus. D'ailleurs de chez moi (fibre Orange), je télécharge à plus de 80Mb/s et je téléverse à plus de 45Mb/s (j'ai une connexion 100/50Mbps). Ca me parait pas si mal :)
# RAS
Posté par ondex2 . En réponse au journal Une backdoor de la NSA dans OpenSSH ?. Évalué à 6.
Même si c'est pas explicitement dit dans le PDF, ce qui y est décrit est trop énorme pour que ce soir upstream sans que personne ne l'ai vu. J'en conclus qu'il n'y a rien à voir dans OpenSSH et que c'est une version maison de la NSA (sauf si Théo est un agent de la NSA ;)), pour maintenir l'accès qu'ils ont déjà à un serveur. C'est malin, mais tant qu'ils ont pas troué ton système, ça ne te concerne pas.