Re: Formatage de bas niveau
> Avec quelques "cat /dev/urandom > /dev/hd?" puis un bon "cat /dev/zero > > /dev/hd?" Je pense que le disque ne devrait plus ressembler à grand > chose non ? C'est bon, j'ai trouvé LE soft : BCWipe ! J'avais essayé ya-wipe, mais il a tourné depuis samedi passé, et à éprouvé très sérieusement ma patience (belle performance, d'ailleurs... attendre comme ça à l'aveuglette) jusqu'à hier soir, où j'ai décidé de l'arrêter, pour constater qu'il avait fait ramé la machine pendant une semaine, pour rien... BCWipe est libre pour une utilisation non commerciale ! On peut le trouver sur : http://www.jetico.com/ On peut faire un wipe sur des fichiers, des dossiers en récursif, ou sur un périphérique de stockage magnétique, genre /dev/hda On peut choisir le mode par défaut : 7 passes d'après le standard U.S. DoD 5200.28-STD : http://www.codin.org/orange/ ou en 35 passes, avec l'algorithme de Peter Gutmann : http://www.cs.auckland.ac.nz/~pgut001/pubs/secure_del.html 5 heures pour 7 passes sur un disque de 8 Go, et pas moyen de retrouver quoi que ce soit après... ça a l'air VRAIMENT efficace... @+ -- * Cédric Rochat = Rue des Jeanneret 37 2400 Le Locle (CH) Priv: [EMAIL PROTECTED] = Prof: [EMAIL PROTECTED] = homepage : www.younics.org * -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: Cappuccino GNU/Linux
Bonjour, Quelque complement la version qui va bientot sortir ne cera pas vraiment officiel car la version officiel cera installé en dur sur le disque et disposera d'une partie serveur pour l'instant nous avons choisis de nous basé sur une lfs(désoler le webmaster n'arrive pas à suivre). En plus nous cherchons en ce moment des développeurs ayant une bonne notion du c car nous avons trop de beta tester et pas assez de développeur. Dés que la première version cera sortie je vous le dirai. Stéphane Graber Le Sat, 19 Oct 2002 19:23:41 +0200 (MEST) Marc SCHAEFER <[EMAIL PROTECTED]> à écrit: > On Thu, 17 Oct 2002, Stéphane Graber wrote: > > > Pour plus d'information aller sur notre site-web: http://cappuccino.tuxfamily.org > > Bonne initiative. > > Quelques bémols: apparemment il y a désormais plus d'une > dizaine de ces distributions démarrant sur CD, dont la plupart sont basées > sur Debian et certaines mêmes sont faites exprès pour les francophones (je > pense à Debian Educ). > > Pourquoi ne pas améliorer Debian Educ p.ex. ? Une idée serait de proposer > vos modifications sous forme de scripts d'auto-modification de Debian > Educ, afin de bénéficier de leurs améliorations également, et pourquoi > pas, ensuite proposer une génération totalement automatisée (depuis un > miroir Debian p.ex.) d'une telle image, permettant ainsi une mise à jour > aux dernières versions stables et de sécurité de l'image ? > > Je consulterais notamment: > >http://lists.debian.org/debian-jr/2002/debian-jr-200206/msg1.html > >http://logiciels-libres-cndp.ac-versailles.fr/distribution.html > > > D'après ce que j'ai compris, le projet Debian Education a été intégré dans > le projet Debian. Je n'ai pas encore eu le temps de suivre, mais si c'est > vrai, cela veut dire une grande stabilité et automatisabilité (pardon) des > mises à jour, et un risque de `forking' plus faible. > > > -- > http://www-internal.alphanet.ch/linux-leman/ avant de poser > une question. Ouais, pour se désabonner aussi. > -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: Heure système Linux-Windows
On Tue, 15 Oct 2002, Pierre Maitre wrote: > Pour linux, le temps "Hardware" est par défaut le temps UTC ou GMT. J'ajoute que seul le temps UTC/GMT donne des résultats corrects si l'on déplace un ordinateur d'une zone à une autre. Stocker en zone locale provoque automatiquement des problèmes à ce niveau. Windows ne peut cependant, à ma connaissance, travailler correctement: il faut utiliser la zone locale (p.ex. CET/MET/CEST/MEST/CET DST/MET DST). > quelle zone on se trouve (pour la suisse c'est la zone CEST qui est en > avance de 2h par rapport au temps UTC): > 1)Indiquez, dans la config linux, que vous habitez dans la zone UTC (ou > GMT).. ou que vous habitez les Açores. Désavantage: tous les mails que > vous enverrez et que vous recevrez auront un timestamp décalé de 2 > heures ... gênant pour la liste du Gull, ça perturbe la chronologie des > réponses et des questions. > 2) indiquez que l'heure "Hardware" est l'heure locale: > hwclock --set --localtime > (sans garantie, j'ai jamais essayé) Si l'on examine les scripts de démarrage: [ /etc/init.d/hwclock* p.ex. ] . /etc/default/rcS [ "$GMT" = "-u" ] && UTC="yes" case "$UTC" in no|"") GMT="--localtime" ;; yes) GMT="--utc" ;; *) echo "$0: unknown UTC setting: \"$UTC\"" >&2 ;; esac on voit que: schaefer@defian:~% grep UTC /etc/default/rcS # Set UTC to yes or no UTC=yes Une configuration incorrecte (== compatible Microsoft) se fait avec UTC=no. D'autres distributions ont d'autres configurations, mais regarder dans les scripts de démarrage, notamment avec `grep hwclock' peut vous aider. -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: Connexion ISDN chez bluewin
> Dans la doc, il est conseilé d'utiliser ippd quand c'est possible. > Quels sont les avantages de ippd par rapport à pppd ? > Et au sujet de isdn4linux ? Je ne connais pas l'Omni mais le 2864I, plus ancien. En résumé: - on peut appeler en `analogique': V34 p.ex. ou V90 (comme un modem non ISDN/RNIS usuel) - on peut appeler en `numérique' point-à-point avec divers protocoles: X.75: canal bidirectionnel avec correction d'erreur, orienté caractère HDLC/syncPPP: émulation asynchrone d'un canal synchrone bas-niveau dont les retransmissions et correction d'erreur sont à gérer manuellement. Cas 1: (on tape ces commandes sous cu(1) (package uucp) ou minicom/seyon/etc) AT+FCLASS=0&O0D0328414081 Cas 2: AT+FCLASS=0&O2B00D0328414081 Cas 3: AT+FCLASS=0&O2B40D0328414081 (ce dernier cas ne permet pas la connexion caractère et il est possible que mon modem ne réponde même pas. Ce dernier cas nécessite un PPP asynchrone émulation synchrone avec gestion HDLC comme ipppd). Les cas 1 et 2, eux, s'utilisent avec un pppd usuel. En plus s'ajoute la possibilité de connecter optionnellement deux canaux en même temps (double du prix, double théorique de la vitesse). isdn4linux n'est utile qu'avec une carte ISDN interne. En *théorie*, certains modems série sont utilisables aussi avec CAPI, jamais essayé. > ainsi que le log de ma tentative de connexion: manque le détail des commandes AT, de la composition, etc. -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: gnorpm
On Thu, 17 Oct 2002 [EMAIL PROTECTED] wrote: > y a-t-il chez Redhat (7.3) une fonctionnalite semblable Webmin implémente un système d'installation de paquets indépendant de la distribution (plus exactement: avec des modules pour chaque distribution) et qui me semble-t-il permet avec la Debian d'installer parmi les sources disponibles. Peut-être que cette fonctionnalité a également été implémentée d'une manière ou d'une autre avec la Red Hat. Sinon la solution proposée par Pierre MAÎTRE fonctionnera sur tout système, y compris non UNIX. > dans la base de donnees, il selectionne automatiquement > les paquets necessaires et dit quels cdrom mettre? Sinon, Anne POSSOZ a mentionné ses tentatives d'utiliser APT au-dessus de RPM sur une Red Hat: apparemment ce n'est pas encore tout à fait ça (les paquets RPMs manquent d'informations pour effectuer toutes les opérations correctement, et APT n'est pas complètement documenté). Mais apparemment APT est de plus en plus `adopté par l'industrie' (ce que cela veut dire exactement est probablement plus clair pour d'autres personnes que moi): Debian GNU (/Linux et /autres) mais aussi United Linux (aka SuSE + quelques autres) supportent désormais APT: on peut supposer que d'autres distributions devront s'y mettre aussi, ou mettre à niveau leurs outils comme up2date. En fait, up2date ne serait-il pas la réponse à ta question ? > Et qu'est-ce que le paquetage redhat-rpmdb? dpkg^H^H^H^Hrpm -q -f redhat-rpmdb*.rpm -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: Cappuccino GNU/Linux
On Thu, 17 Oct 2002, Stéphane Graber wrote: > Pour plus d'information aller sur notre site-web: http://cappuccino.tuxfamily.org Bonne initiative. Quelques bémols: apparemment il y a désormais plus d'une dizaine de ces distributions démarrant sur CD, dont la plupart sont basées sur Debian et certaines mêmes sont faites exprès pour les francophones (je pense à Debian Educ). Pourquoi ne pas améliorer Debian Educ p.ex. ? Une idée serait de proposer vos modifications sous forme de scripts d'auto-modification de Debian Educ, afin de bénéficier de leurs améliorations également, et pourquoi pas, ensuite proposer une génération totalement automatisée (depuis un miroir Debian p.ex.) d'une telle image, permettant ainsi une mise à jour aux dernières versions stables et de sécurité de l'image ? Je consulterais notamment: http://lists.debian.org/debian-jr/2002/debian-jr-200206/msg1.html http://logiciels-libres-cndp.ac-versailles.fr/distribution.html D'après ce que j'ai compris, le projet Debian Education a été intégré dans le projet Debian. Je n'ai pas encore eu le temps de suivre, mais si c'est vrai, cela veut dire une grande stabilité et automatisabilité (pardon) des mises à jour, et un risque de `forking' plus faible. -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: smbd lent
On Thu, 17 Oct 2002 [EMAIL PROTECTED] wrote: > Mon probleme est que mon serveur samba est tres lent > a repondre a client. Je suis satisfait de la vitesse > de communication ensuite, mais la premiere connexion > est vraiment lente. root@serveur-linux# echo adresse.ip.du.client.windows fake-truc >> /etc/hosts root@serveur-linux# /etc/init.d/samba restart # adapter suivant la distribution si cela corrige le problème, configurer un DNS (ou un fichier /etc/hosts) correct sur le serveur GNU/Linux. > avant de se parler l'un a l'autre ; ca prend 10 a 15 minutes, parfois plus! Si cela vous gêne, déinstallez le protocole NetBEUI de Windows et configurez un serveur WINS (je ne sais pas si ça marche, mais c'est une piste). > Mais ce delai, est-ce normal? pourquoi? Il peut être dû: - samba en mode `inetd': tcp wrappers configurés - samba en mode `standalone': quelque chose du même genre augmenter le debug level et consulter les logs. > Merci, si quelqu'un peut m'apporter des informations! Il y a souvent des problèmes avec Windows + Samba lorsque les netmasks ne sont pas corrects. -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: modif raidtab pas prise en compte
On Wed, 16 Oct 2002, Leopoldo Ghielmetti wrote: > Selon les infos que j'ai (pas sur à 100%) le raidtab est utilisé seulement La raidtab n'est pas utilisé si le RAID est compilé dans le kernel ou inséré manuellement (dans ce cas un initrd est nécessaire si / est monté sur RAID) et que l'option d'auto-détection est activée dans la configuration du kernel. > pour la création du raid, ensuite tu pourrais même l'effacer et ça n'a plus > aucune influence. Bien entendu il est préférable de le garder et même de le > backupper dans le cas ou il faut récuperer le système. Imprimer (comme fdisk -l). -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: reiserfs ou ext3
On Thu, 17 Oct 2002, Christophe DONZELOT (f1rpc) wrote: > Les 2 disques sont des disques SCSI Ultra160 qui ont un débit brut de 50 > Mbytes/s d'après hdparm. En miroir (RAID1) et en lecture, on peut donc supposer que la performance est de 50 MByte/s, du moins dans de bonnes conditions (grandes I/O, pas de buffering inutile, lecture seulement sur un disque sans load-balancing). Tester avec hdparm directement sur /dev/md0. Si cela ne marche pas, utiliser un autre outil (dd p.ex.). > Après test sur des volumes différents un filesystem ext3 délivre Tester avec ext2, nous dire quelle taille de block (-b 4096 p.ex.), quelle densité d'inodes, et quel mode de fonctionnement ext3 (ordered ?) Comparer avec et sans LVM, et être sûr que le rebuild de l'array a terminé. Aussi quel kernel et quels patches si ce n'est pas un kernel pur de kernel.org dont la signature de la source joue. Pour optimiser ext3, lire notamment: - les modes de journalisation (ordered, etc): http://batleth.sapienti-sat.org/projects/FAQs/ext3-faq.html Le mode `je journalise tout (lent, hyper-sûr): "mount -o data=journal" Le mode: `je journalise seulement les métadata (structures), pas les données, mais je m'arrange pour que les fichiers ne contient en aucun cas des données volées à d'autres fichiers' (lent, sécuritaire). "mount -o data=ordered" Le mode: `je fais au plus vite, genre NTFS5 ou reiserfs, avec des risques sur une machine multiuser en cas de crash' (très rapide). Des patches supplémentaires à la base du code peuvent offrir d'autres modes (comme p.ex. les directory indexes, similaires aux balanced trees de reiserfs (AFAIK)). - les optimisations pour `bulk I/O' - taille du journal - fréquence des synchronisations/checkpoints du journal - les commentaires quant à la bonne adéquation de ext3 pour le mode `création de nombreux petits fichiers détruits très vite' (queues de mail p.ex.) par rapport à reiserfs Faire quelques recherches sur Google p.ex. > Est-ce-que l'adjonction du 2ème cpu améliorera mes mes affaires ? Etant donné qu'il n'y a pas de génération de parité en RAID1 cela m'étonnerait. > Cependant le propriétaire est tronqué à 8 caractères (EICN_NT+) ce qui > m'empèche de fixer des droits plus secure que 777 , ce qui est ennuyeux . La plupart des systèmes UNIX ont une telle limitation qui il est vrai sous Linux, en tous cas pour les programmes utilisant PAM est historique. Maintenant je ne sais pas dans quelle mesure il faut modifier Samba pour cela ou si une table de conversion `noms EICN' vers `noms internes ou UID UNIX' peut faire l'affaire. Je n'ai pas d'expérience dans ce domaine cependant. -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: reiserfs ou ext3
On Thu, 17 Oct 2002, Cédric Rochat wrote: > Plains-toi !! J'ai mon process wipe qui tourne depuis 5 jours et 2 heures, > sans aucun feedback de l'état de la progression !! Tout ce que je sais, c'est > que ça tourne, mais j'ai absolument aucune idée du temps que ça va encore > prendre... vmstat 5 devrait t'indiquer combien de blocks/s ton système écrit; il y a aussi les statistiques par disque et donc une idée de la bande passante. En théorie il doit également être possible via /proc/XXX/fd/ et /proc/XXX/maps de déterminer l'offset actuel. -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: gen(e)rer des paquest Was: (no nubject)
J'étais au RAID symposium à Zurich (http://www.raid- symposium.org/raid2002/) cette semaine où de nombreux spécialistes des IDS ont les mêmes besoins pour effectuer des tests grâce à des simulations de traffic. Une solution présentée est d'enregistrer le traffic sur un réseau existant puis de faire un replay, ce genre d'outils peuvent peut-être te simplifier la vie ? Exemple: http://www.tcpdump.org/ http://tcpreplay.sourceforge.net/ Sinon je pense que les libnet peuvent t'intéresser: http://www.packetfactory.net/Projects/Libnet/ Gregor Bruhin -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: Formatage de bas niveau
Avec quelques "cat /dev/urandom > /dev/hd?" puis un bon "cat /dev/zero > /dev/hd?" Je pense que le disque ne devrait plus ressembler à grand chose non ? Attention, avec ça on perd naturellement de nombreuses informations utiles :-) y compris disklabel etc. Gregor Bruhin -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: Attaque DOS / IP-spoofing
Je suis également d'avis qu'il est possible d'exclure à 99.9% que les IP source ont été spoofées. Je pense que ce n'est effectivement pas une attaque par élimination. Si DOS ou DDOS il y a, les attaquants ne vont pas jusqu'à établir des connection tcp et utiliser des protocoles de haut niveau etc. l'envoie d'un flux massif de paquets de manière distribuée est plus fréquent. Gregor Bruhin -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: reiserfs ou ext3
Il existe un soft opensource similaire qui s'appelle partimage (www.partimage.org) . Anne Possoz wrote: Pardon mais je garde le sujet tout en changeant de point de vue. Des utilisateurs veulent ghoster des systèmes linux sur un ensemble de PC. Il faut le même hardware? Supposons que ce soit le cas. Mais je ne connais pas ghost. Quelqu'un.e sait-elleil si on peut ghoster des partitions ext3 ou reiserfs? Et aussi quelles sont les conditions de ghost: un disque entier? des partitions physiques? des partitions logiques? Anne -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi. -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: reiserfs ou ext3
Pardon mais je garde le sujet tout en changeant de point de vue. Des utilisateurs veulent ghoster des systèmes linux sur un ensemble de PC. Il faut le même hardware? Supposons que ce soit le cas. Mais je ne connais pas ghost. Quelqu'un.e sait-elleil si on peut ghoster des partitions ext3 ou reiserfs? Et aussi quelles sont les conditions de ghost: un disque entier? des partitions physiques? des partitions logiques? Anne -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: reiserfs ou ext3
On Thu, 17 Oct 2002, Escario Julien wrote: > A priori non, puisque c'est la carte scsi qui s'occupe des transferts, le > processeur n'est que trés peu solicité. Attention, je parle là des > transferts uniquement. Tout dépend du support scatter/gather: sur certaines cartes SCSI Qlogic et Adaptec, la config par défaut du kernel (de 1024 à 4096 bytes contiguës, donc un transfert de 64k, minimum pour une performance SCSI correcte, comporte plus de 16 blocks scatter/gather) provoque des pertes de performance assez graves. Je n'ai jamais expérimenté de tels problèmes avec les cartes basées sur chipset SYM53c8xx. En ce qui concerne reiserfs vs ext3, si l'on veut de la performance brute, alors lire la doc de ext3 en ce qui concerne data = ordered et les autres modes qui offrent une meilleure fiabilité/sécurité que reiserfs, et utiliser des modes comparables à reiserfs avant de publier les benchmarks. Aussi regarder l'option stride de mke2fs -j, si on a du LVM et/ou du RAID en-dessous. Lire la doc, c'est une question d'ordre d'écriture qui garantit, même en cas de crash, l'absence de données `étrangères' dans un fichier dont les métadata sont à jour mais les blocs de données par encore écrits. Il y a d'autres raisons qui me font préférer ext3 (compatibilité ascendante et descendante ext2; code très simple et léger, entre autres, et jamais aucun problème pour le moment pour moi). Et pendant qu'on y est, évaluer xfs pour la performance. xfs -- la dernière fois que j'ai regardé, soit avril 2002 -- était une catastrophe concernant l'organisation (surpatching du kernel) et la fiabilité (genre: backup avec xfsdump, pour le moment le seul choix si l'on a besoin des ACLs: impossible de façon fiable sauf monté ro). Mais xfs est très, très rapide. Faut savoir ce que l'on veut. -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
