galactikboulay a écrit 620 commentaires

  • [^] # Re: Ca ne sert à rien de filtrer ce trafic...

    Posté par  . En réponse au message Flood Multicast. Évalué à 2.


    C'est effectivement pas gagné d'avance ... vu qu'il semble que je soit le seul à qui ça arrive.


    Effectivement ça parait bizarre que ça ne marche mal que pour toi. As-tu pu estimer le débit que tu reçois sur ton interface relatif au trafic multicast ?

    Peux-tu préciser ton modèle de carte réseau et la configuration de ton noyau ? (particulièrement la partie qui se trouve dans networking options ?). As-tu des infos sur les configurations RedHat qui n'ont pas le problème ?
  • # Ca ne sert à rien de filtrer ce trafic...

    Posté par  . En réponse au message Flood Multicast. Évalué à 4.

    Le multicast, c'est comme le broadcast: sur un réseau Ethernet, tout le monde va recevoir les trames. Ta carte réseau se prend donc tout dans la figure et c'est logique. Ca ne sert pas à grand chose de filtrer, vu que le mal est déjà fait (ton débit est déjà utilisé).

    Pour régler ton problème, c'est à l'administrateur du réseau de faire son boulot correctement et de configurer ses switches pour qu'ils ne balancent pas les trames multicast sur des ports où il n'y a aucun récepteur multicast. Chez Cisco, la fonction à implémenter s'appelle CGMP, ou alors il y a IGMP Snooping qui est normalisé. Encore faut-il avoir des équipements qui supportent ces 2 fonctions (c'est pas gagné d'avance).
  • # /dev/kcore et périphériques

    Posté par  . En réponse au message dev/mem mémoire physique. Évalué à 2.


    Ma question concerne /dev/mem : mémoire physique - Est ce que ça correspond au mapping et donc la possibilité d'accéder à tous les périphériques ?


    Je pense que tu fais plutôt référence à /proc/kcore qui est un fichier virtuel permettant d'accéder à l'intégralité de la mémoire physique.

    Un mmap() judicieusement utilisé sur ce fichier permet d'accéder à n'importe(s) quelle(s) pages physiques. Mal utilisé, je te promets que tu vas flinguer le système très vite (surtout si tu écris sur des pages du noyau).

    Après, pour ton périphérique, il y a 2 possibilités (sur architecture x86):

    * Soit il utilise des ports IO spécifiques (voir instructions inb/outb et compagnie) et dans ce cas mapper la mémoire ne sert à rien. On peut voir les ports IO avec le fichier /proc/ioports.

    * Soit c'est du "memory-mapped", et dans ce cas, je pense que mapper /proc/kcore fonctionnerait (en ne mappant que la zone qui t'intéresse bien sûr).
    Le fichier /proc/iomem montre les zones mémoires et les périphériques qui utilisent ces zones.

    Attention, toutes ces manips ne peuvent bien sûr se faire qu'en root.
  • [^] # Re: Mouai

    Posté par  . En réponse à la dépêche Interview de Marcus Brinkmann, développeur du Hurd. Évalué à 7.

    A la base je l'ai fait sur un process frontend, logique vu que c'est lui qui va traiter les données.

    Sinon sur le postmaster (donc le process principal), un ltrace me donne:

    sigprocmask(2, 0x8256920, NULL) = 0
    select(5, 0xbfffeb80, 0xbfffeb00, 0, 0xbfffeae8) = 1
    sigprocmask(2, 0x82569c0, NULL) = 0
    calloc(1, 620) = 0x826edc8
    accept(3, 0x826ee3c, 0xbfffea78, 28127, 0x826edc8) = 8
    getsockname(8, 0x826edcc, 0xbfffea78, 28127, 0x826edc8) = 0
    setsockopt(8, 6, 1, 0xbfffea74, 4) = 0
    setsockopt(8, 1, 9, 0xbfffea74, 4) = 0

    Il y a aussi quelques petits malloc() qui trainent à droite à gauche.

    Si c'est sur le fork, c'est "normal".

    Faudrait savoir. En tout cas dans ma logique à moi, c'est incompatible avec une assertion du type "La partie serveur de Postgres ne fait pas de malloc()".
  • [^] # Re: Mouai

    Posté par  . En réponse à la dépêche Interview de Marcus Brinkmann, développeur du Hurd. Évalué à 5.

    rès bien. Tu ne m'as toujours pas démontré que PostgreSQL fait un malloc() ou mmap() ou ...


    Déjà j'avais pas prétendu quoi que ce soit sur le comportement de Postgres, mais si tu y tiens:

    Exemple:


    [...]
    memcpy(0x82eb36c, "", 4) = 0x82eb36c
    memcpy(0x82eb370, "", 4) = 0x82eb370
    memcpy(0x82eb374, "", 4) = 0x82eb374
    memcpy(0x821fa27, "B\377\267\377\377\376", 368) = 0x821fa27
    snprintf("FETCH 2", 64, "%s %u", "FETCH", 2) = 7
    strlen("DeferredTriggerTupleContext") = 27
    strcpy(0x8299748, "DeferredTriggerTupleContext") = 0x8299748
    malloc(8192) = 0x82c5f98
    free(0x82c5f98) =
    strlen("FETCH 2") = 7
    memcpy(0x821fb97, "C", 1) = 0x821fb97
    memcpy(0x821fb98, "FETCH 2", 8) = 0x821fb98
    memcpy(0x821fba0, "Z", 1) = 0x821fba0
    sigemptyset(0xbfffe584) = 0

    [...]
  • [^] # Re: Mouai

    Posté par  . En réponse à la dépêche Interview de Marcus Brinkmann, développeur du Hurd. Évalué à 1.

    L'argument qui tue... j'ai dit malloc() pour tout ce qui est lié aux demandes mémoires.


    Ouais, rattrapage aux branches detected.

    De tout manière, tu veux aussi vérifier que PostgreSQL (côté serveur) ne fait pas de malloc(3) avec ltrace.


    Oui, là ça marche vu que ltrace(), en plus d'afficher les appels systèmes effectués comme strace, enregistre les appels aux fonctions des librairies chargées dynamiquement.

    Quoiqu'il en soit, pour ta gouverne, il est possible d'allouer de la mémoire en utilisant mmap() avec le flag MAP_ANONYMOUS (pour les OS qui le supportent, ça va de soi). malloc() est loin d'être la seule méthode d'allocation.
  • [^] # Re: Mouai

    Posté par  . En réponse à la dépêche Interview de Marcus Brinkmann, développeur du Hurd. Évalué à 2.

    Petite auto-correction: sbrk() est en fait un wrapper à brk().
  • [^] # Re: Mouai

    Posté par  . En réponse à la dépêche Interview de Marcus Brinkmann, développeur du Hurd. Évalué à 3.

    Un bon SGDB comme PostgreSQL ne fait pas de malloc() côté serveur. Donc il n'a pas ce problème de "OOM killer"). Fais un strace sur postgresql si tu en doutes.


    L'argument qui tue. malloc() n'est pas un appel système, strace ne le voit donc pas.
    Les appels systèmes qui montrent une activité au niveau de la gestion mémoire, c'est mmap(), brk() et sbrk().
  • [^] # Re: svn vs cvs

    Posté par  . En réponse à la dépêche KDE 3.4 officiellement sorti. Évalué à 9.

    Subversion ne prétend pas être révolutionnaire par rapport à CVS mais il apporte une réponse à tout un ensemble de problématiques qui n'étaient pas ou alors très mal gérés par CVS, notamment le renommage de fichiers ou de répertoire, ou leur déplacement. Je pense que la gestion des verrous est bcp plus "propre" avec subversion que cvs.

    Subversion fonctionne aussi avec WebDAV, ce qui est très pratique pour gérer ses "repository".

    Mes 2 cents.
  • [^] # Re: whois.sc

    Posté par  . En réponse au message interrogation DNS inverse. Évalué à 3.

    Par ailleurs, il n'y a qu'un "reverse DNS" par IP, c'est ce que tu as dans le champ PTR avec un dig -x.


    Il est possible d'affecter plusieurs enregistrements "PTR" à une même adresse IP, rien ne s'y oppose.
  • # Droits d'accès de l'utilisateur MySQL

    Posté par  . En réponse au message [mysql] plantage sous redhat. Évalué à 2.

    Je ne suis pas du tout un pro de MySQL, mais:

    Est-ce que le compte "mysql" est bien créé et a bien accès au répertoire où tu as installé la BDD ?

    Sous linux, la valeur 13 pour errno correspond à la "EACCES", ce qui signifie "Permission Denied" (voir /usr/include/asm-generic/errno-base.h)

    Je pense que tu devrais pouvoir t'en sortir avec du "chown -R mysql:mysql <rep_installation>"

    En espérant que ça puisse t'aider.
  • [^] # Re: Résolution DNS

    Posté par  . En réponse au message Problème avec la table arp. Évalué à 2.

    Peux-tu décrire un peu ton réseau (adressage IP utilisé, configuration du serveur DNS, etc).

    Si tu utilises un adressage privé pour numéroter tes machines (rfc1918), et que ton serveur DNS ne gère pas la zone reverse (en in-addr.arpa) mais qu'il fait suivre les requêtes vers Internet, ça risque d'être lent.
  • # BIOS

    Posté par  . En réponse au message Booter sur cd. Évalué à 3.

    En principe c'est le BIOS qui fait une émulation de disquette à partir du CD (qui doit être en format "El Torito"). Globalement, le BIOS intercepte les appels disque concernant la disquette et redirige vers le CD.

    Voir les explications de:

    http://thelinuxfr.org/howto/Bootdisk-HOWTO/ar01s11.html(...)

    Je ne pense pas que LILO offre cette possibilité d'émulation (il faudrait qu'il gère les lecteurs CD matériellement parlant, les CD au format El-Torito, et qu'il émule une disquette suivant le principe décrit avant). Mais je me trompe peut-être.
  • # Liste des partitions

    Posté par  . En réponse au message pb de lecture d'une partition EXT3 fedora core 3. Évalué à 2.

    Que donne un "fdisk -l /dev/hdb" ? Vois-tu des partitions de type ext2/3 ?
  • # Résolution DNS

    Posté par  . En réponse au message Problème avec la table arp. Évalué à 3.

    Bonjour,

    Lorsque tu utilises la commande "arp", par défaut il y a tentative de résolution de nom (DNS) pour toutes les adresses IP présentes dans la table. Si ton serveur DNS est injoignable, il est donc "normal" que ça prenne bcp de temps.

    Pour voir les entrées ARP sans avoir cette résolution DNS, il suffit d'utiliser l'option "-n". Pour toutes les entrées, ça donne donc "arp -na".

    Pour le SSH, le serveur essaie de faire une résolution DNS inverse de l'adresse de la machine qui se connecte (pour les logs). Ce qui fait que là encore, s'il n'y a pas de serveur DNS fonctionnel, la connexion met un certain temps à s'établir (30 sec si ma mémoire est bonne).

    En espérant que ça puisse t'aider.
  • [^] # Re: full disque?

    Posté par  . En réponse au message kernel panic -promiscous mode. Évalué à 3.

    Ca me parait quand même bizarre un kernel qui crashe à cause d'un filesystem plein.

    C'est quelle version de noyau, avec quelle carte réseau utilisée ? Peux-tu recopier le contenu du kernel panic, ça permettra peut-être de voir à quel endroit ça plante.
  • # Un truc tout bête...

    Posté par  . En réponse au message Problème clé usb avec Mandrake. Évalué à 1.

    On dirait que ta clé en passée en lecture-seule. Tu n'aurais pas verrouillé la clé en écriture par inadvertance, ou elle n'aurait pas été remontée en read-only par le système ?
  • # Quelques réponses

    Posté par  . En réponse au message Hdd externe en ultra-ata 100, sous linux, ça marche ?. Évalué à 2.

    1) est-ce possible que ça soit "mon linux/ma machine" qui soit pas capable d'utiliser un périf "Ultra ata 100" ??? (mon ordi n'est plus tout récent(presque 2 ans), mais si ça passe par usb/firewire, normalement on s'en fout que ça soit en ultra ata, sata ou classique , non ?)


    Je pense aussi que la partie UltraATA100 ne doit pas être "vue" du PC. Il y a une conversion USB/Firewire -> interface ATA du disque. C'est marqué UltraATA 100 parce que le disque à l'intérieur est un disque classique avec ce type d'interface.

    2) est-ce pk il est gros (250go de fat32) que des problèmes peuvent se poser sous linux, quand je copie des gros fichiers dessus ?


    Non, personnellement j'en ai un de 250 Go formaté en FAT32 (Western Digital), et ça marche parfaitement. J'ai parfois eu quelques problèmes avec l'USB (il fallait brancher le disque avant de démarrer le PC) et ça a marché un jour avec le firewire, depuis ça ne fonctionne plus (un changement de noyau je suppose).
    Je l'utiliste surtout en USB2.

    3) Puis je mettre un disque dur plus petit et pas "ultra ata 100", avec un port ide classique dedans, et esperer des résultats positif ? (j'ai pas démonté encore le boitier, mais est-ce que le disque possède un port IDE classique, pour que je puisse au moins récupéré le hdd dans mon ordi ???)


    En principe c'est un disque standard dedans, donc tu devrais pouvoir permuter. Perso, mon boitier est transparent et je vois bien la connectique, c'est un disque standard.


    pour information, j'ai d'autres HDD usb2, ou clé usb1 et usb2 qui fonctionne parfaitement, ainsi qu'une cam DV qui se connecte bien via le firewire, donc je pense qu'au niveau config/module du noyau : tout est là ...


    Déjà c'est étonnant que le disque ne soit pas vu en USB2 par un W2000-SP4...
  • [^] # Re: Un bon cru

    Posté par  . En réponse à la dépêche Sortie de GNOME 2.10. Évalué à 3.

    Bon en fait il suffisait de fouiller un peu:

    http://live.gnome.org/MemoryReduction(...)
  • [^] # Re: Un bon cru

    Posté par  . En réponse à la dépêche Sortie de GNOME 2.10. Évalué à 8.

    C'est vraiment étonnant, gnome lancé et prêt à être utilise utilise moins de 100 Mo de Ram.


    C'est pas pour lancer un vieux troll des familles (j'utilise Gnome et j'en suis satisfait), mais 100 Mo pour un environnement graphique tout juste lancé, je trouve ça personnellement énorme.

    Quelqu'un sait ce qui prend tant de mémoire dans un environnement graphique récent ? le code (librairies, etc.) ou bien des données genre fontes, bitmap, etc ?
  • [^] # Re: DNS

    Posté par  . En réponse au message CVS templeet down ?. Évalué à 1.

    Attention, subversion est un produit différent de CVS, il ne doit pas utiliser le même port (2401/tcp pour CVS si je me souviens bien).

    Essaie en installant un client subversion. J'ai trouvé un tutoriel assez sympa pour débuter:

    http://toutprogrammer.com/article_19_8.html(...)
  • # DNS

    Posté par  . En réponse au message CVS templeet down ?. Évalué à 1. Dernière modification le 04 décembre 2021 à 17:42.

    Il est possible d'effectuer un transfert de zone sur les serveurs DNS gérant la zone "templeet.org":

    $ dig IN NS templeet.org  
    templeet.org.           86400   IN      NS      master.victorimage.com.  
    templeet.org.           86400   IN      NS      calchas.nouvo.com.  
    
    ;; ADDITIONAL SECTION:  
    master.victorimage.com. 172796  IN      A       62.212.110.62  
    calchas.nouvo.com.      172797  IN      A       82.127.124.206  
    
    
    $ dig @62.212.110.62 IN AXFR templeet.org  
    
    ; <<<< DiG 9.2.4rc5 >>>> @62.212.110.62 IN AXFR templeet.org  
    ;; global options:  printcmd  
    templeet.org.           86400   IN      SOA     master.victorimage.com. courtois.linuxfr.org. 2005022601 21600 3600 6048000 86400  
    templeet.org.           86400   IN      NS      master.victorimage.com.  
    templeet.org.           86400   IN      NS      calchas.nouvo.com.  
    templeet.org.           3600    IN      MX      10 main.uucpssh.org.  
    templeet.org.           86400   IN      A       212.27.33.226  
    courtois.templeet.org.  3600    IN      CNAME   calchas.nouvo.com.  
    www.courtois.templeet.org. 3600 IN      CNAME   calchas.nouvo.com.  
    svn.templeet.org.       3600    IN      CNAME   calchas.nouvo.com.  
    wiki.templeet.org.      86400   IN      CNAME   webother.linuxfr.org.  
    www.templeet.org.       3600    IN      CNAME   webother.linuxfr.org.  
    www2.templeet.org.      3600    IN      CNAME   master.victorimage.com.  
    www3.templeet.org.      3600    IN      CNAME   webother.linuxfr.org.  
    www4.templeet.org.      3600    IN      CNAME   master.victorimage.com.  
    templeet.org.           86400   IN      SOA     master.victorimage.com. courtois.linuxfr.org. 2005022601 21600 3600 6048000 86400  
    

    Je vois qu'il y a un "svn.templeet.org", ils sont peut-être passé sur subversion en remplacement de cvs ?

    My 2 cents.

  • [^] # Re: Question conne

    Posté par  . En réponse à la dépêche La brevetabilité des inventions mises en oeuvre par ordinateur adoptée par le Conseil. Évalué à 2.

    La dernière fois, nous nous sommes un peu heurté sur un autre thread

    Il est vrai que j'avais répondu de manière un peu "brutale" sur une précision que tu avais faite. Je reconnais que c'était pas super diplomate :)

    je n'ai malheureusement rien de mieux que dire : "aux armes citoyens!" et d'acquiesser ce que tu dis.

    C'est quand même une question à se poser: on vote régulièrement (régionales, présidentielles, européennes, tout ce qu'on veut), en ce qui me concerne je vais voter à chaque fois, mais quand on voit que ces personnes se moquent de l'avis du parlement européen et qu'elles sont quasiment invirables par vote, on fait quoi ?
  • [^] # Re: Question conne

    Posté par  . En réponse à la dépêche La brevetabilité des inventions mises en oeuvre par ordinateur adoptée par le Conseil. Évalué à 6.

    Le plus ironique dans l'histoire, c'est qu'il me semble que tous les partis (de l'extrême gauche à l'extrême droite) s'étaient prononcés unanimement contre les brevets logiciels. J'irai comme toi manifester mon mécontentement dans les urnes, en ayant bien à l'esprit que J.Chirac est décidément toujours opportuniste, et que Michel Rocard a lui de son côté fait un excellent travail. Beaucoup d'hommes politiques devraient s'en inspirer.
  • # SKAS conseillé...

    Posté par  . En réponse au message UML et 2.6.10. Évalué à 1.

    Comme ça a été dit, UML a été intégré complètement à partir du 2.6.9, auparavant il fallait appliquer des patches.

    Au niveau du host, je te conseille d'appliquer les patches SKAS (Separate Kernel Address Space), qui font gagner pas mal de performance.

    2 URLs utiles:

    http://www.user-mode-linux.org/~blaisorblade/(...)
    http://user-mode-linux.sourceforge.net/skas.html(...)