Debian, Ubuntu.
seb95 Membre non connecté
-
- Voir le profil du membre seb95
- Inscrit le : 26/08/2007
- Site internet
- Groupes :
Reprise du message précédent
artenox :
Tant pis. Ubuntu fait de mauvaises choses.
Je vous ai dit que "open source" est mauvais.
Fermez le code source pour éviter le vol.
/thread
Je vous ai dit que "open source" est mauvais.
Fermez le code source pour éviter le vol.
/thread
Je n'ai jamais dit ça, je dis juste qu'ubuntu fait parti des sales élèves en terme d'open source, ils prennent de partout mais ils donnent peu et le peu qu'ils donnent est souvent tellement patché que c'est inutilisable ailleurs que chez eux.
Beaucoup ont voulu reprendre unity pour les grosses distributions, beaucoup ont laissé tombé tellement que c'était ingérable. du reste unity est un bureau qui n'est pas fréquent de voir et est souvent proposé en test.
Ils ont au moins le mérite de prendre le code, le travail des autres et de laisser les noms des personnes qui font le taf, ce que mxlinux ne fait pas en remplaçant le packager origine debian par un des leurs sans retouché au travail par la suite.
Maintenant sans ubuntu, linux ne serait pas autant populaire et connu mine de rien. En France, c'est la gendarmerie et la police qui est sous ubuntu, ce n'est pas rien.
Yuusha Membre non connecté
-
- Voir le profil du membre Yuusha
- Inscrit le : 04/07/2017
- Groupes :
-
Modérateur
-
Administrateur
-
Forgeron
seb95 :
Maintenant sans ubuntu, linux ne serait pas autant populaire et connu mine de rien. En France, c'est la gendarmerie et la police qui est sous ubuntu, ce n'est pas rien.
Est-ce un Ubuntu pur ? Il me semblait avoir entendu que c'était un OS maison basé sur Ubuntu. Mais peut-être est-ce complètement faux.
Visiteur
Yuusha :
Est-ce un Ubuntu pur ? Il me semblait avoir entendu que c'était un OS maison basé sur Ubuntu. Mais peut-être est-ce complètement faux.
seb95 :
Maintenant sans ubuntu, linux ne serait pas autant populaire et connu mine de rien. En France, c'est la gendarmerie et la police qui est sous ubuntu, ce n'est pas rien.
Est-ce un Ubuntu pur ? Il me semblait avoir entendu que c'était un OS maison basé sur Ubuntu. Mais peut-être est-ce complètement faux.
La base est une version Ubuntu LTS, adaptée avec l’ajout d’outils développés en interne. Ce qui donne un OS « sur mesure » .
Édité par Visiteur Le 04/02/2021 à 18h37
seb95 Membre non connecté
-
- Voir le profil du membre seb95
- Inscrit le : 26/08/2007
- Site internet
- Groupes :
Citation :
DNS is a UDP protocol not a TCP protocol.
Think of it this way.
Your DNS mechanism asks for a resolution. What gets sent out amounts to a UDP
shotgun blast. UDP is asynchronous. You don't know if a reply will come back to
a specific request or when it will come back. Once sent, you can't cancel it.
What you are getting amounts to a "long delayed echo" in radiophonics parlance.
You send UDP requests to [A .. Z], get a reply from F and act on it. Meanwhile
[A..T] might or might not reply and go into your cache. You finish and shut the
application down. Then replies from [U..z} might or might not come in.
Big Deal, that's the way it works. Its UDP after all.
One the other hand, I have my firefox running day after day, so I never see this
issue and even if I did i wouldn't see it as a problem, cost that's the way DNS
works in a rich environment where there are many responders.
You have to remember that DNS was designed some decades ago, in very sparse
environment with unreliable connections and unreliable facilities. It solved the
problems that existed then. The ones that exist now have to do with authenticity
and integrity, not availability which are the problems that it faces now.
Think of it this way.
Your DNS mechanism asks for a resolution. What gets sent out amounts to a UDP
shotgun blast. UDP is asynchronous. You don't know if a reply will come back to
a specific request or when it will come back. Once sent, you can't cancel it.
What you are getting amounts to a "long delayed echo" in radiophonics parlance.
You send UDP requests to [A .. Z], get a reply from F and act on it. Meanwhile
[A..T] might or might not reply and go into your cache. You finish and shut the
application down. Then replies from [U..z} might or might not come in.
Big Deal, that's the way it works. Its UDP after all.
One the other hand, I have my firefox running day after day, so I never see this
issue and even if I did i wouldn't see it as a problem, cost that's the way DNS
works in a rich environment where there are many responders.
You have to remember that DNS was designed some decades ago, in very sparse
environment with unreliable connections and unreliable facilities. It solved the
problems that existed then. The ones that exist now have to do with authenticity
and integrity, not availability which are the problems that it faces now.
Traduction:
Citation :
DNS est un protocole UDP et non un protocole TCP.
Pense-y de cette façon.
Votre mécanisme DNS demande une résolution. Ce qui est envoyé revient à un UDP
explosion de fusil de chasse. UDP est asynchrone. Vous ne savez pas si une réponse reviendra à
une demande spécifique ou quand il reviendra. Une fois envoyé, vous ne pouvez pas l'annuler.
Ce que vous obtenez équivaut à un «écho long retardé» dans le langage radiophonique.
Vous envoyez des requêtes UDP à [A .. Z], obtenez une réponse de F et agissez en conséquence. pendant ce temps
[A..T] peut ou non répondre et aller dans votre cache. Vous terminez et fermez le
application vers le bas. Ensuite, les réponses de [U..z} pourraient ou non entrer.
Big Deal, c'est comme ça que ça marche. Son UDP après tout.
D'un autre côté, mon Firefox fonctionne jour après jour, donc je ne vois jamais ça
problème et même si je le faisais, je ne le verrais pas comme un problème, le coût est la façon dont DNS
fonctionne dans un environnement riche où il y a de nombreux intervenants.
Il ne faut pas oublier que le DNS a été conçu il y a quelques décennies, en très
environnement avec des connexions peu fiables et des installations peu fiables. Il a résolu le
problèmes qui existaient alors. Ceux qui existent maintenant ont à voir avec l'authenticité
et l'intégrité, non la disponibilité, qui sont les problèmes auxquels elle est confrontée actuellement.
Pense-y de cette façon.
Votre mécanisme DNS demande une résolution. Ce qui est envoyé revient à un UDP
explosion de fusil de chasse. UDP est asynchrone. Vous ne savez pas si une réponse reviendra à
une demande spécifique ou quand il reviendra. Une fois envoyé, vous ne pouvez pas l'annuler.
Ce que vous obtenez équivaut à un «écho long retardé» dans le langage radiophonique.
Vous envoyez des requêtes UDP à [A .. Z], obtenez une réponse de F et agissez en conséquence. pendant ce temps
[A..T] peut ou non répondre et aller dans votre cache. Vous terminez et fermez le
application vers le bas. Ensuite, les réponses de [U..z} pourraient ou non entrer.
Big Deal, c'est comme ça que ça marche. Son UDP après tout.
D'un autre côté, mon Firefox fonctionne jour après jour, donc je ne vois jamais ça
problème et même si je le faisais, je ne le verrais pas comme un problème, le coût est la façon dont DNS
fonctionne dans un environnement riche où il y a de nombreux intervenants.
Il ne faut pas oublier que le DNS a été conçu il y a quelques décennies, en très
environnement avec des connexions peu fiables et des installations peu fiables. Il a résolu le
problèmes qui existaient alors. Ceux qui existent maintenant ont à voir avec l'authenticité
et l'intégrité, non la disponibilité, qui sont les problèmes auxquels elle est confrontée actuellement.
Là ça me dépasse un peu, et vous chez vous avec mageia ça donne quoi?
Chez fedora j'ai la même chose, chez debian je ne peux dire car j'ai un serveur qui tourne et du coup faut que je stop tout et donc attendre un moment plus calme pour le faire...
seb95 Membre non connecté
-
- Voir le profil du membre seb95
- Inscrit le : 26/08/2007
- Site internet
- Groupes :
Citation :
Hi,
What's happening is that nscd (the Name Service Caching Daemon) is
updating its cache entries. When you visit a web site, it makes a DNS
request to look up the site. The response has a time-to-live value
associated with it. When that exipres, nscd re-issues the request to
update its cache, on the assumption that you will (eventually) make the
same request again at some point in the future.
So, if you want to eliminate the repeated requests, just shut nscd down
and/or don't start it in the future. That way, the only time(s) you
will see DNS requests being made is when you are actually browsing to a
site, and not later.
Even with nscd running, it will (eventually) stop refreshing the cache
entries -- the size of the cache is finite, so if you make enough DNS
requests, eventually the "older" ones will be removed from the cache to
make room for information pertaining to more recently-requested information.
What's happening is that nscd (the Name Service Caching Daemon) is
updating its cache entries. When you visit a web site, it makes a DNS
request to look up the site. The response has a time-to-live value
associated with it. When that exipres, nscd re-issues the request to
update its cache, on the assumption that you will (eventually) make the
same request again at some point in the future.
So, if you want to eliminate the repeated requests, just shut nscd down
and/or don't start it in the future. That way, the only time(s) you
will see DNS requests being made is when you are actually browsing to a
site, and not later.
Even with nscd running, it will (eventually) stop refreshing the cache
entries -- the size of the cache is finite, so if you make enough DNS
requests, eventually the "older" ones will be removed from the cache to
make room for information pertaining to more recently-requested information.
Ce qu'on peut traduire par :
Citation :
Salut,
Ce qui se passe, c'est que nscd (le démon de mise en cache du service de noms) est
mettre à jour ses entrées de cache. Lorsque vous visitez un site Web, cela crée un DNS
demande de consulter le site. La réponse a une valeur de durée de vie
associé avec. Lorsque cela expire, nscd émet à nouveau la demande à
mettre à jour son cache, en supposant que vous ferez (éventuellement) le
même demande à un moment donné dans le futur.
Donc, si vous voulez éliminer les demandes répétées, fermez simplement nscd
et / ou ne le lancez pas à l'avenir. De cette façon, la seule fois où tu
verra les requêtes DNS effectuées lorsque vous naviguez réellement vers un
site, et pas plus tard.
Même avec nscd en cours d'exécution, il arrêtera (éventuellement) d'actualiser le cache
entrées - la taille du cache est finie, donc si vous faites suffisamment de DNS
demandes, les "plus anciennes" seront éventuellement supprimées du cache pour
faire de la place pour les informations relatives aux informations demandées plus récemment.
Ce qui se passe, c'est que nscd (le démon de mise en cache du service de noms) est
mettre à jour ses entrées de cache. Lorsque vous visitez un site Web, cela crée un DNS
demande de consulter le site. La réponse a une valeur de durée de vie
associé avec. Lorsque cela expire, nscd émet à nouveau la demande à
mettre à jour son cache, en supposant que vous ferez (éventuellement) le
même demande à un moment donné dans le futur.
Donc, si vous voulez éliminer les demandes répétées, fermez simplement nscd
et / ou ne le lancez pas à l'avenir. De cette façon, la seule fois où tu
verra les requêtes DNS effectuées lorsque vous naviguez réellement vers un
site, et pas plus tard.
Même avec nscd en cours d'exécution, il arrêtera (éventuellement) d'actualiser le cache
entrées - la taille du cache est finie, donc si vous faites suffisamment de DNS
demandes, les "plus anciennes" seront éventuellement supprimées du cache pour
faire de la place pour les informations relatives aux informations demandées plus récemment.
Et donc sous Debian je n'ai rien car je n'ai pas ce service d'installer :p.
Édité par seb95 Le 06/02/2021 à 18h46
marc-andré Membre non connecté
-
- Voir le profil du membre marc-andré
- Inscrit le : 29/09/2015
- Groupes :
la conclusion c'est que ce service "nscd" (name service caching daemon) n'est pas indispensable et génère du trafic superflu qui paraît suspect!
mais c'est dans la logique des choses, car le protocole "udp" est très basique et généralement envelopé de couches logicielles pour l'améliorer;
pour faire simple udp c'est des paquets envoyés comme à la poste; il n'y a pas de communication simultanée établi entre l'émetteur et le récepteur; le processus est asynchrone; donc, des paquets peuvent se perdre ou être corrompus;
"tcp" c'est une couche logicielle (au dessus d'udp) qui nécessite une conection simultanée, comme le téléphone, et les pertes ou corruptions sont compensées par des checksum et des réémissions.
si tu veux mieux comprendre les réseaux, j'ai bien aimé cette série en français qui explique très bien les choses;
et qui a le mérite d'être expliquée deux fois, car il donne la version en "java" et en "C" de toutes ses leçons;
https://www.youtube.com/watch?v=-Z4GT0Ak1Nk
Jybz Membre non connecté
-
- Voir le profil du membre Jybz
- Inscrit le : 10/10/2018
- Groupes :
-
Administrateur
-
Forgeron
seb95 Membre non connecté
-
- Voir le profil du membre seb95
- Inscrit le : 26/08/2007
- Site internet
- Groupes :
marc-andré :
bonjour et merci seb95 pour toutes ces recherches.
la conclusion c'est que ce service "nscd" (name service caching daemon) n'est pas indispensable et génère du trafic superflu qui paraît suspect!
mais c'est dans la logique des choses, car le protocole "udp" est très basique et généralement envelopé de couches logicielles pour l'améliorer;
pour faire simple udp c'est des paquets envoyés comme à la poste; il n'y a pas de communication simultanée établi entre l'émetteur et le récepteur; le processus est asynchrone; donc, des paquets peuvent se perdre ou être corrompus;
"tcp" c'est une couche logicielle (au dessus d'udp) qui nécessite une conection simultanée, comme le téléphone, et les pertes ou corruptions sont compensées par des checksum et des réémissions.
si tu veux mieux comprendre les réseaux, j'ai bien aimé cette série en français qui explique très bien les choses;
et qui a le mérite d'être expliquée deux fois, car il donne la version en "java" et en "C" de toutes ses leçons;
https://www.youtube.com/watch?v=-Z4GT0Ak1Nk
la conclusion c'est que ce service "nscd" (name service caching daemon) n'est pas indispensable et génère du trafic superflu qui paraît suspect!
mais c'est dans la logique des choses, car le protocole "udp" est très basique et généralement envelopé de couches logicielles pour l'améliorer;
pour faire simple udp c'est des paquets envoyés comme à la poste; il n'y a pas de communication simultanée établi entre l'émetteur et le récepteur; le processus est asynchrone; donc, des paquets peuvent se perdre ou être corrompus;
"tcp" c'est une couche logicielle (au dessus d'udp) qui nécessite une conection simultanée, comme le téléphone, et les pertes ou corruptions sont compensées par des checksum et des réémissions.
si tu veux mieux comprendre les réseaux, j'ai bien aimé cette série en français qui explique très bien les choses;
et qui a le mérite d'être expliquée deux fois, car il donne la version en "java" et en "C" de toutes ses leçons;
https://www.youtube.com/watch?v=-Z4GT0Ak1Nk
Merci à toi, à ce que j'ai compris, nscd n'est pas installé sur les autres distributions, en tout cas debian et mageia ne l'installent pas par défaut, j'ai pas vérifié fedora encore mais je ne pense pas.
Du coup et comme on me le dit dans la mailing-list, il suffit de stopper et désactiver le service pour ne plus avoir un comportement "suspect" quoique en fait c'est un comportement normale puisqu'il mettait en cache et refaisait du cache au bout d'un moment dans l'optique de rendre plus rapide mes prochaines vistes à des sites...
Je vais aller voir ton lien, car du coup je suis tombé des nues en voyant la complexité de la chose.
Citation :
(Seb95 : ton traducteur ne gère pas les retours à la ligne, il traite chaque lignes sans context des lignes suivantes/précédentes, du coup traduit des portions de phrases au lieu de l'ensemble de la phrase.)
Oui Jybz, je m'en rend compte en relisant, mais de toute façon pour moi c'était déjà incompréhensible, et il a fallu que je lise et relise pour enfin comprendre...
Et ce qui est essentiel à comprendre, c'est que c'est ni une faille, ni un bug, ni les espions américains qui sont dans nos pc mais juste un serveur DNS de cache, au nom de nscd, qui est installé sur opensuse et non sur d'autres distributions, pourquoi c'est encore autre chose, qui fait ces appels même quand on a aucune activité personnel sur le réseau. Nscd veut essayer de prévoir nos prochaines actions et visites sur les sites et du coup dès, il essaye de reprendre un peu de cache des sites pour nous les servir plus vite une prochaine fois si on lui demande. Maintenant, je ne trouve pas que la partie réseau soit plus rapide sur opensuse que sur mageia, fedora ou debian..., en même temps je suis en fibre et donc ça va bien vite.
les liens, j'ai oublié, alors c'est le canal IRC #opensuse (qui renvois sur #suse) et la mailing-list notamment https://lists.opensuse.org/archives/list/users@lists.opensuse.org/thread/Z3A3HTQADQDPVI57DEXEURMJFU53A7RT/
Répondre
Vous n'êtes pas autorisé à écrire dans cette catégorie