MrTom wrote:
périclès wrote:Bonne idée impaire, mais comme tu l'as dit pour les nuls.
Un guide "Fedora en quatre pages" (ou "Fedora en 7 jours", le dernier jour étant bien évidemment le repos 😃) allant de l'installation à la configuration, de base.
Un truc du genre : j'ai toujours utilisé windows, j'ai entendu parler de linux et je veux installer fedora !
Un papier où il faut aller droit à l'essentiel en enlevant toutes les suppositions liées à l'installation :

Préparation du support média, installation simple et rapide, configuration qui l'est tout autant et apprendre à utiliser la documentation et les forums.

Quatre étapes essentielles qui se doivent être claires et simples, mais sans pour autant être simpliste.
Cela risque d'être un casse tête chinois pour les rédacteurs, dont je ferai avec grand plaisir parti 🙂

Des critiques ?
Si c'est pour expliquer dans la doc que les choix par défaut sont les bons et qu'il n'y qu'à cliquer sur « Suivant », à quoi bon ?
Pour les nuls, ou comme je l'ai écrit plus tôt, pour ceux qui ne veulent pas se casser la tête avec des détails techniques. Comment cela, "en 7 jours"? J'ai bien écrit "tester ou installer la Fedora après l'avoir testée, en moins de 2 heures" Oui, "j'en ai entendu parler", c'est cela: "c'est quoi, Linux, ce truc dont j'entend parler? Je ne connais que Windows, je voudrais en savoir plus."

Un papier qui irait droit et uniquement à l'essentiel serait à mon avis pas mal utile, avec, eventuellement une mention toute simple: "dans la plupart des cas, ça marche, il n'y a qu'à répondre aux questions, telles que reprises dans le guide. Et en cas de pépin, éteindez tout. [en cours d'install, c'est bête. Mais pendant la phase de test de la clefs USB, ce n'est pas gênant.]"
périclès wrote:Préparation du support média, installation simple et rapide
Pas plus. Juste cela. Pour le moment, j'hésite. Dans les dernières pages, juste ce qu'il faut pour pour un accès via ethernet/DHCP ainsi que via Wifi? Alors juste selon ce même principe, pour les nuls et en image.
périclès wrote:configuration qui l'est tout autant et apprendre à utiliser la documentation et les forums
A mon avis, ce serait pour d'autres mini guides qui pourraient utilement compléter celui de l'installation.
MrTom wrote:
périclès wrote:Bonne idée impaire, mais comme tu l'as dit pour les nuls.
Un guide "Fedora en quatre pages" (ou "Fedora en 7 jours", le dernier jour étant bien évidemment le repos 😃) allant de l'installation à la configuration, de base.
Un truc du genre : j'ai toujours utilisé windows, j'ai entendu parler de linux et je veux installer fedora !
Un papier où il faut aller droit à l'essentiel en enlevant toutes les suppositions liées à l'installation :

Préparation du support média, installation simple et rapide, configuration qui l'est tout autant et apprendre à utiliser la documentation et les forums.

Quatre étapes essentielles qui se doivent être claires et simples, mais sans pour autant être simpliste.
Cela risque d'être un casse tête chinois pour les rédacteurs, dont je ferai avec grand plaisir parti 🙂

Des critiques ?
Si c'est pour expliquer dans la doc que les choix par défaut sont les bons et qu'il n'y qu'à cliquer sur « Suivant », à quoi bon ?
A expliquer justement, quand je disais des suppositions liées à l'installation, je parlais des installations "exotiques"...
Par exemple, le guide d'installation de gentoo est très clair pour moi, celui d'ArchLinux, bien que plus facile à installer est un véritable calvaire tant c'est mal écrit et mal présenté !


@ impaire
Euh... Tu sais que dans le judaïsme Dieu créa le monde en 7 jours ?
Second degré, une blague :hammer:
Impaire tu es bien gentil mais la règle est que celui qui réclame quelque chose est celui qui finit par le faire. Tu penses que l'on peut faire mieux, alors fait le.
MrTom wrote:Si c'est pour expliquer dans la doc que les choix par défaut sont les bons et qu'il n'y qu'à cliquer sur « Suivant », à quoi bon ?
________________________________
-- Fedora, would you run anything else? --
Il y a quelques temps, on m'a demandé ce que je voulais pour sniffer et traquer dans un réseau, traquer quelque chose qui est encore inconnu, indéterminé. Un phénomène se produisait occasionnellement, mais ce qui le provoquait est inconnu. La conf d'un réseau a depuis un peu changée... J'ai répondu que je voulais Linux et un xeon, pour "voir" ce qui se passait et se passe peut-être encore dans ce réseau. On y remarque encore des phénomènes étranges.

J'ai pris la Fedora, base Redhat, parce que c'est connu où je vais utiliser ce xeon. J'aurai pu prendre une Debian, ou autre chose, je voulais surtout un kernel avec "quelques utilitaires" autour.

Je viens d'avoir le xeon, j'ai donc installé la FC13 (juste avec un stick USB; je n'avais même pas pas pensé à commander aussi un lecteur de DVD...). Pas d'bol, dans ses derniers kernels de la FC13, le pilote du controleur HP Smart Array semble être bugué, Dès que je commençais à brasser de très gros fichiers de 100Mo et plus, mon /var/log/message était floodé de "hspa cmd_alloc returned NULL". Je ne voulais pas gaspiller les ressources du xeon et du raid... J'ai voulu faire simple. J'ai commencé par downloader et compiler le dernier kernel, le .35. Super, ça marche! J'ai eu de la chance, sans quoi j'aurai du triffouiller dans le kernel et le pilote hspa. Au passage, j'ai pu constater que tweaker et compiler un kernel est aujourd'hui tout aussi facile que l'install d'une Fedora Live.

Je n'ai pas fini de tweaker le truc et le hardware n'est pas encore exceptionnel, juste un quad à 2.93GHz. Sur le raid 0 avec deux disques à 10k, ça écrit à 70Mbps, ce sera suffisant. Je souhaitais surtout pouvoir sniffer et filtrer dans un lien à 700Mbits/s et 170 000 paquets/s, en ne perdant rien. Quand on sniffe avec tcpdump, les packets dropped by kernel, ça vous arrive toutes les secondes:

http://www.google.fr/search?q=tcpdump+packet+dropped+kernel

Mes premiers tests sont assez concluants. J'ai pu sniffer et écrire l'intégralité d'un flux de 70Mbits/s ou 13 000 paquets/s tout droit sur le raid. Il vallait mieux que le raid fonctionne, et qu'il arrête de flooder lui-même les logs, sur le même raid. J'ai aussi pu extraire toutes les entêtes de 170 000 paquets/s et les dumper sur le disque (ça ne fait que 15Mbit/s à écrire). Au final, mais j'ai pas fini de tweaker, j'ai pu dumper sans problème les entêtes de 500 millions de paquets d'un flux de 700Mbps, en ne perdant que 8 paquets sur 500 millions. Quand j'aurais fini de tweaker, je pense que ce xeon va pouvoir capturer des milliards d'entêtes et des paquets choisis dans ces flux, sans en perdre un seul (ou quasi aucun), sur deux ports gigE, chacun à 700Mbit/s.

Pour lire dans de telles traces, un peu comme on lirait l'avenir dans des entrailles d'un poulet, je vais encore utiliser le xeon ainsi que tcpdump, Perl et vi, via ssh et un simple shell.

J'ai aussi été confronté à des traces pcap x86 64 non compatibles ni avec tcpdump, ni avec Wireshark dans leur version x86 64. En effet, dans la FC13 x86 64, il semblerait que Wireshark et tcpdump ne lisent que des traces ou fichiers au format 32 bit. Ce problème est aussi résolu, j'ai recompilé des vérues collées sur la FC13. Par là, je crois qu'il y a plus d'infos:

http://www.google.fr/search?q=PCAP32_KLUDGE ... 1 résultat (0,11 secondes)

Note: when he says

3. I think "struct pcap_pkthdr" in pcap.h should be re-defined to be independent of sizeof(long). In pcap files, a struct pcap_pkthdr precedes every packet. Unfortunately, the size of struct pcap_pkthdr (which contains a struct timeval) depends upon sizeof(long). ...

La vérue open source (j'adore quand on peut lire et modifier puis recompiler) est là: http://staff.washington.edu/corey/gulp/

A mon avis, ce genre de tweaking, de tuning ou de décorticage sort largement du cadre d'une documentation d'install ou d'utilisation d'une Fedora 13 "pour les nuls", ceux qui souhaiteraient d'abord découvrir la FC13 ou Linux, en se servant d'un stick USB et d'une version live.
périclès wrote:@ impaire
Euh... Tu sais que dans le judaïsme Dieu créa le monde en 7 jours ?
Second degré, une blague :hammer:
Pardon, j'aurai tweaké le truc en moins de 3 jours!

Je pense qu'un guide très simple pour un stick pourrait vraiment être utile. A mon avis, la majorité des gens n'auront jamais rien à tweaker, que ce soit pour tester une live ou même pour l'installer: 1 heure pour créer le stick, un peu de temps pour le tester, évaluer la Fedora, et une heure de plus pour l'installer. Ca fait 2 à 3 heures de temps entre le download et un premier boot, sur un Linux. 3 heures... et non 7 jours 😉
MrTom wrote:Impaire tu es bien gentil mais la règle est que celui qui réclame quelque chose est celui qui finit par le faire.
C'était d'abord une suggestion.
cf le lien donné par MrTom pour le moment je ne vois que des posts sur le forum et toujours rien dans ma boite mail...
Réponse courte : j'ai pas le temps. Donc ça restera en l'état.
Ok. Alors un lien, pour ceux que ça intéresse:

http://fedoraproject.org/wiki/FedoraLiveCD/USBHowTo#Graphical_Method_-_Windows_or_Fedora

For Windows using the following steps:

* Download liveusb-creator from http://fedorahosted.org/liveusb-creator
* Double click 'liveusb-creator'

If you are using Fedora, you can use Add/Remove Programs and search for liveusb-creator or on the command line:

$ su -c "yum install liveusb-creator"

J'ai eu des soucis avec le téléchargement via l'outil, sous Windows (j'utilise un peu de tout). Je préfere télécharger les iso et écrire ensuite seulement, du disque sur le stick. J'ai aussi eu des soucis avec mes sticks, j'en fais parfois n'importe quoi. Mais le plus souvent, ça roule.


Je m'en vais jouer à nouveau avec un vieux C2D trouvé à la benne, sauvé de la broyeuse... et peut être tester ceci:

http://liveusb.info/dotclear/

Au second lien, c'est bordélique à souhait du côté des OS ou iso suportés, comme j'aime. C'est aussi explicite:

MultiBoot va vous permettre de réaliser un LiveUSB à tout faire,
idéal pour découvrir différentes distributions linux sans les installer sur votre PC,
et ce de manière fluide;
ou pour installer la distribution linux de votre choix sur votre PC
beaucoup plus rapidement que via un LiveCD grâce à la rapidité des ports USB 2.0/3.0
Indispensable sur toute la gamme actuelle des netbooks qui ne possèdent pas de lecteur de CD.
Heldwin wrote:
impaire wrote:Je m'en vais jouer à nouveau avec un vieux C2D trouvé à la benne, sauvé de la broyeuse...
Il y a des gens qui jettent des C2D à la poubelle ??
Des gens un peu bizarres, oui, qui l'ont jeté sans la RAM et sans le DD (ou quelqu'un est passé juste avant moi). Ce n'est qu'une puce 1,8GHz, mais elle fonctionne très bien.

Ah... un truc tout aussi utile, pour Gparted, pour ne rien effacer, redimensionner des partitions existantes et faire de la place:

http://www.sysresccd.org/Download
tu serais étonné de voir tout ce que les entreprises jettent. Je viens de récupérer 2 cisco catalyst dans une benne 😉
Je rentre de Paris, la Villette, où j'ai pu discuter longuement avec un ambassadeur de Fedora-fr. Je crois que j'ai blasphémé ici. Encore pardon.
impaire wrote:Je viens d'avoir le xeon, j'ai donc installé la FC13 (juste avec un stick USB; ...
Je rentre de Paris, la Villette, où j'ai pu discuter longuement avec un ambassadeur de Fedora-fr...
Je reviens sur ce point là, car j'en avais discuté aussi, ce samedi, à la Villette. Cet ambassadeur disait qu'il ne fallait pas hésiter à le dire lorsque quelque chose fonctionne.

J'ai continué à jouer avec ce xeon. Le dl360 g6 arrive d'office avec 2 ports gigE. J'ai poussé le bouchon un peu plus loin, et avec un Spirent Test Center. Le xeon commence à travailler vraiment, parfois les buffers se remplissent, surtout lorsque Gnome/Xorg vérrouille ou dévérrouille la session X, avec un certain délais.

Plus tôt, je crois que je parlais déjà de 174 000 paquets et 700M bits par seconde, sur un port gigE. J'ai raccordé chacun des gigE du dl360 sur un port du Spirent. Et le résultat est satisfaisant, ce kernel 2.6.35 et ce xeon quad core capturent sans difficultés les entêtes de deux fois 174 000 paquets et 700M bit par seconde.

J'ai fait plusieurs tests, dont deux captures de 68 millions de paquets par ports (en même temps) pour lesquelles j'ai recompté mieux le nombre d'entêtes effectivement enregistrées sur le disque: aucun paquet perdu. J'ai fait une autre capture, toujours simultanée, à 700Mbps, deux traces de 255 millions d'entêtes de paquets, sans pertes; ça se traduit par deux fois 26 go d'entêtes dans des fichiers, sur le disque, à relire... mais c'est une autre histoire (le xeon a encore des ressources).

Je souhaitais aussi pouvoir filtrer dans ces flux, à 700M bit par seconde. J'ai fait de premiers essais pour en extraire seulement 50M bits par secondes, sur la base d'une IP destination. Ca marche évidemment aussi, à ces mêmes débits.

Il n'y a plus qu'à installer ce xeon dans un réseau, où il verra passer des paquets par milliards.


On en fait pas autant avec tcpdump; selon la machine, passé 5 à 10 000 paquets par secondes, le kernel supprime de temps en temps des paquets. Si quelqu'un souhaitait sniffer à ces débits, à 174 000 paquets par seconde et même plus, la solution est là:

http://staff.washington.edu/corey/gulp/


Avec de l'open source, on fait à peu près ce qu'on veut. Mais je dois préciser que l'essentiel du travail a été fait par d'autres, je n'ai fait qu'ajuster et emboiter des briques mises à disposition, sur la toile.

P.S. 1: Je crois qu'il y a un bug dans iptraf du moment, sur la FC13. A ces débits là, les chiffres affichés pour un port gigE ne semblent plus etre corrects. Je fais en tous cas plus confiance à ce qu'affiche le Spirent et aux captures relues sur le disque du dl360.

P.S. 2: J'aurai du préciser que c'est un X5570 @ 2.93GHz, avec l'hyperthreading désactivé. A ces débits, et pour des tailles de paquets aléatoires, de 128 à 900 bits, les coeurs qui sniffent sont à 50-60%.

P.S. 3: Et donc, tout au départ, j'ai booté sur une FC13 live, avec une clefs USB. Ca s'installe en 30 minutes.

P.S. 4; Hum... je suis allé regarder ailleurs. Je ne trouve pas de chiffres. "Thanks to the traffic capture technology utilized in TCPDUMP for Windows®, this product has very high performance too." "... with zero packet loss. Certainly, your success depends on CPU, RAM, HDD subsystem performance, etc." Côté RAM, j'ai juste un giga, ça devra suffir. J'en avais demandé deux, mais une barette s'est perdue.

P.S. 5: D'après ce que je viens de lire, on doit pouvoir aller beaucoup plus loin, toujours avec Linux, mais par exemple, avec des NIC 10G programmables. "... can enable multiple independent processes or threads to concurrently analyze the incoming traffic from one or more NIC ports." Ce sera certainement pour une prochaine fois.

P.S. 6: Ah, on peut faire la même chose sur Windows. http://irl.cse.tamu.edu/people/matt/papers/pam2010.pdf
7 mois plus tard