logo Debian Debian Debian-France Debian-Facile Debian-fr.org Forum-Debian.fr Debian ? Communautés logo inclusivité

Debian-facile

Bienvenue sur Debian-Facile, site d'aide pour les nouveaux utilisateurs de Debian.

Vous n'êtes pas identifié(e).

#26 17-04-2011 09:22:42

zoroastre74
Membre
Distrib. : Debian Wheezy
Noyau : Linux 3.2
(G)UI : Awesome wm v3.4.13 (Octopus)
Inscription : 28-08-2010

Re : Cloner des disques durs en conservant l'accès réseau

Yep!

Je te joins e-miel mon plus grand respect et m'incline devant ton savoir wink

Je suis un peu comme Saint-Thomas :

# cp /dev/sdb ./usb_cp.img
# dd if=/dev/sdb of=./usb_dd.img bs=2048
503296+0 enregistrements lus
503296+0 enregistrements écrits
1030750208 octets (1,0 GB) copiés, 86,9573 s, 11,9 MB/s
# ll
total 2317640
drwxr-xr-x 13 philippe philippe       4096 17 avril 08:20 backup_usb
-rw-r--r--  1 philippe philippe  309428224 17 avril 08:43 systemrescuecd-x86-2.1.0.iso
-rw-r-----  1 root     root     1030750208 17 avril 09:12 usb_cp.img
-rw-r--r--  1 root     root     1030750208 17 avril 09:17 usb_dd.img
# md5sum ./usb_cp.img
a4d3fff27afc24ba35639464032d1698  ./usb_cp.img
# md5sum ./usb_dd.img
a4d3fff27afc24ba35639464032d1698  ./usb_dd.img
# od -x ./usb_cp.img | head -n 20
0000000 b8fa 1000 d08e 00bc b8b0 0000 d88e c08e
0000020 befb 7c00 00bf b906 0200 a4f3 21ea 0006
0000040 be00 07be 0438 0b75 c683 8110 fefe 7507
0000060 ebf3 b416 b002 bb01 7c00 80b2 748a 8b01
0000100 024c 13cd 00ea 007c eb00 00fe 0000 0000
0000120 0000 0000 0000 0000 0000 0000 0000 0000
*
0000660 0000 0000 0000 0000 21a6 000e 0000 0080
0000700 0002 8783 2e19 0001 0000 67ff 000b 8700
0000720 2e1a 500b 7d13 6800 000b 5000 0013 0000
0000740 0000 0000 0000 0000 0000 0000 0000 0000
0000760 0000 0000 0000 0000 0000 0000 0000 aa55
0001000 58eb 4d90 5753 4e49 2e34 0031 0802 0024
0001020 0002 0000 f800 0000 003e 0020 0001 0000
0001040 67ff 000b 02da 0000 0000 0000 0002 0000
0001060 0001 0006 0000 0000 0000 0000 0000 0000
0001100 0080 cf29 9ace 4ee4 204f 414e 454d 2020
0001120 2020 4146 3354 2032 2020 fcfa c031 d08e
0001140 b4bc 067b 8e57 b9c0 0008 b4bf f37b 8ea5
0001160 bbd8 0078 b40f 0f37 56a0 1688 2825 d220

# od -x ./usb_dd.img | head -n 20
0000000 b8fa 1000 d08e 00bc b8b0 0000 d88e c08e
0000020 befb 7c00 00bf b906 0200 a4f3 21ea 0006
0000040 be00 07be 0438 0b75 c683 8110 fefe 7507
0000060 ebf3 b416 b002 bb01 7c00 80b2 748a 8b01
0000100 024c 13cd 00ea 007c eb00 00fe 0000 0000
0000120 0000 0000 0000 0000 0000 0000 0000 0000
*
0000660 0000 0000 0000 0000 21a6 000e 0000 0080
0000700 0002 8783 2e19 0001 0000 67ff 000b 8700
0000720 2e1a 500b 7d13 6800 000b 5000 0013 0000
0000740 0000 0000 0000 0000 0000 0000 0000 0000
0000760 0000 0000 0000 0000 0000 0000 0000 aa55
0001000 58eb 4d90 5753 4e49 2e34 0031 0802 0024
0001020 0002 0000 f800 0000 003e 0020 0001 0000
0001040 67ff 000b 02da 0000 0000 0000 0002 0000
0001060 0001 0006 0000 0000 0000 0000 0000 0000
0001100 0080 cf29 9ace 4ee4 204f 414e 454d 2020
0001120 2020 4146 3354 2032 2020 fcfa c031 d08e
0001140 b4bc 067b 8e57 b9c0 0008 b4bf f37b 8ea5
0001160 bbd8 0078 b40f 0f37 56a0 1688 2825 d220

# diff ./usb_dd.img ./usb_cp.img

# fdisk ./usb_cp.img
You must set cylinders.
You can do this from the extra functions menu.

WARNING: DOS-compatible mode is deprecated. It's strongly recommended to
         switch off the mode (command 'c') and change display units to
         sectors (command 'u').

Command (m for help): p

Disk ./usb_cp.img: 0 MB, 0 bytes
255 heads, 63 sectors/track, 0 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000e21a6

       Device Boot      Start         End      Blocks   Id  System
./usb_cp.img1   *           1          47      373759+  83  Linux
Partition 1 does not end on cylinder boundary.
./usb_cp.img2              47         126      632832    b  W95 FAT32
Partition 2 does not end on cylinder boundary.

Command (m for help): q

# fdisk ./usb_dd.img
You must set cylinders.
You can do this from the extra functions menu.

WARNING: DOS-compatible mode is deprecated. It's strongly recommended to
         switch off the mode (command 'c') and change display units to
         sectors (command 'u').

Command (m for help): p

Disk ./usb_dd.img: 0 MB, 0 bytes
255 heads, 63 sectors/track, 0 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000e21a6

       Device Boot      Start         End      Blocks   Id  System
./usb_dd.img1   *           1          47      373759+  83  Linux
Partition 1 does not end on cylinder boundary.
./usb_dd.img2              47         126      632832    b  W95 FAT32
Partition 2 does not end on cylinder boundary.

Command (m for help): q


Je ne suis pas aller plus loin dans mes tests, je n'ai même pas essayé de booter sur la clé usb.

@+

Zoroastre.

PS : J'ai fouillé et farfouillé sur la toile à la recherche de retour d'experience du clonage à la sauce cp, cette methode est en définitive peu commentée et souvent mal ressentie.

Dernière modification par zoroastre74 (17-04-2011 10:08:11)

Hors ligne

#27 17-04-2011 17:13:15

e-miel
Membre
Lieu : Strasbourg
Distrib. : Alpine 3.8.0
Noyau : Linux 4.14
(G)UI : PuTTY 0.70
Inscription : 02-04-2011

Re : Cloner des disques durs en conservant l'accès réseau

zoroastre74 a écrit :

Je voulais dire que dd réalisait les entrées/sorties en interne comparativement à cp ou cat qui eux utilisent des pipes (stdio) et sollicitent le shell du fait pour traiter ces même entrées/sorties.


Que dire, sinon que tout est faux dans cette phrase.

– Lorsqu'il s'agit d'accès disque (en lecture comme en écriture) ce n'est jamais une appli, ni même l'OS qui réalise la copie, mais le firmware du disque. Les applis (cat, cp, dd...) ne font que donner des ordres à l'OS (Linux), ces ordres sont nommés "appels systèmes" par les développeurs d'appli, ou "primitives systèmes" par les développeurs du noyau, ou encore mais là ça devient lourd à prononcer, bien que ce soit la formulation la plus exacte: "appeler une primitive système". OPEN, READ, WRITE, CLOSE... sont des primitives systèmes de Linux, l'appel étant réalisé (côté appli) par une interruption du CPU. Dans le cas d'un CPU x86 ou x86_64, c'est l'interruption n°128 notée "INT 80h" ou "INT 0x80" en fonction du langage assembleur utilisé. Lorsqu'on programme une appli, on écrit rarement en langage assembleur mais plutôt en C. Une primitive système est une fonction tout à fait classique, mais qui doit s'exécuter en mode noyau. Pour utiliser une primitive système, il faut mettre les paramètres dans la pile (comme pour toute fonction), puis mettre le numéro de primitive dans le registre EAX puis réaliser l'interruption INT 80h. Le compilateur C se charge du rangement des paramètres dans la pile, le numéro de primitive est positionné par les fonctions de la section 2 du man: open(), read(), write(), close()... qui sont des fonctions ultra-courtes dont le but est simplement d'appeler les primitives OPEN, READ, WRITE, CLOSE... grâce à 2 instructions CPU: écrire la bonne valeur dans EAX puis faire INT 80h. Toutes les applications sont à égalité sur ce point, autant cat que cp que dd. Aucune appli ne peut réaliser une copie en interne.

– Aucun flux de données ne transite par l'intermédiaire du Shell. Si tu écris cat <a >b, le Shell va créer un fils (appel système FORK), ce processus fils va ouvrir le fichier a en mode read only dans son descripteur n°0 appelé aussi stdin (appel système OPEN), puis ouvrir le fichier b en mode write only dans son descripteur n°1 appelé aussi stdout (appel système OPEN), puis va se transformer (appel système EXEC) en /bin/cat et à partir de ce moment le Shell n'est plus concerné par ce que va faire cat. Lorsque cat commencera son exécution, il va hériter de l'état des descripteurs qu'il a reçus au moment de l'EXEC et va faire ce pour quoi il est programmé: des READ du descripteur n°0 et des WRITE dans le descripteur n°1, sans même savoir précisément ce qu'il lit ni dans quoi il écrit, jusqu'à ce qu'il n'y ait plus rien à lire. La commande cp, n'utilise pas l'entrée et la sortie standard, mais utilise les descripteurs suivants: 3, 4, 5, 6, 7... en réalisant elle-même les OPEN et CLOSE. La commande dd peut utiliser les descripteurs 0 et 1 (exemple: dd <a >b) dans quel cas les OPEN ont sont réalisés avant le EXEC, ou alors utiliser les descripteurs 3, 4...  (exemple: dd if=a if=b) dans quel cas les OPEN sont réalisés après le EXEC, mais dans tous les cas, la performance de copie sera exactement la même, et ne transitera pas par le Shell. D'ailleurs, dans l'absolu, cat, cp et dd pourrait très bien être lancés par autre chose que le Shell.

– Je ne vois pas pourquoi tu parles de pipes. Un pipe est un lien de données entre 2 processus. Dans l'exemple: dd </dev/sda bs=512 count=1 | gzip >mbr.gz, les WRITE de dd seront récupérés par les READ de gzip, mais ni dd ni gzip ne savent qu'ils ont affaire à un pipe. Un pipe permet de copier les données directement depuis la mémoire virtuelle d'un processus vers la mémoire virtuelle d'un autre processus, sans aucun tampon intermédiaire. Un pipe ne consomme donc aucune ressource mémoire. Dans mon exemple, chaque WRITE de dd sera exécuté en même temps qu'un READ de gzip, en d'autres termes: si un WRITE a lieu avant un READ, dd sera endormi jusqu'à ce que gzip fasse un READ, ou si un READ a lieu avant un WRITE, gzip sera endormi jusqu'à ce que dd fasse un WRITE. Lorsque ce WRITE-READ sera exécuté (en fois par le noyau), les processus se réveilleront simultanément. L'endormissement est le moyen utilisé pour éviter d'avoir un tampon.

En définitive, je pense que les avantages sont du côté de dd, de par ses nombreuses options et sa capacité à accueillir differents types de péripheriques.


C'est le noyau (Linux) qui gère les différents types de fichiers/périphériques/tubes nommés... certainement pas les applis. Les applis ne font que des appels à OPEN, READ, WRITE, CLOSE... et autres primitives système, sans faire attention s'il s'agit d'un fichier régulier, d'un périphérique, d'un tube nommé...

J'ai omis d'ajouter que le MBR est en dehors de la partition, dd le recuperera lors d'un clonage de disque, ce que ne fera pas cp !


Le MBR est présent dans /dev/sda mais absent de /dev/sda1, peu importe l'appli utilisée. /dev/sda donne accès au contenu du disque entier (MBR compris) tandis que /dev/sda1 donne accès au contenu de la première partition (sans MBR).

Je pourrais ajouter également que cp retournera certainement une erreur s'il rencontre un block defectueux, ce que ne fera pas dd.


Alors là, j'avoue que je n'y avais pas pensé. Il est normal que la mécanique d'un disque puisse commettre moins d'1% d'erreur, mais cela est géré et rattrapé de façon transparente par le firmware du disque grâce aux sommes de contrôle (une somme par secteur). Dans tous les cas, le disque recommencera jusqu'à ce que les sommes de contrôles soient correctes, sans que l'OS en soit informé. Un disque est donc vu par l'OS comme 100% fiable. Par contre, si un disque fait des erreurs si grosses que son firmware n'arrive pas à les rattraper, il le signalera à l'OS, mais cela veut dire qu'il y a probablement plein d'autres secteurs très endommagés, même si leurs erreurs ont jusque-là pu être rattrapées, mais qu'en sera-t-il demain? sans compter que les relectures intempestives prennent du temps, et usent encore plus le disque. Un tel disque, moi je le jette direct à la poubelle.

PS : J'ai fouillé et farfouillé sur la toile à la recherche de retour d'experience du clonage à la sauce cp, cette methode est en définitive peu commentée et souvent mal ressentie.


Il n'y a pas de "méthode cp" de même qu'il n'y a pas de "méthode dd". cp et dd ne sont que des outils, de même que /dev/sda et /dev/sdb ne sont que des moyens de présenter le contenu du disque, rien de plus.

Dernière modification par e-miel (17-04-2011 17:39:16)

Hors ligne

#28 17-04-2011 18:12:18

Invité-5
Banni(e)

Re : Cloner des disques durs en conservant l'accès réseau

Salut,

Tout en lisant attentivement cette discussion, je constate que principal intéressé n'est toujours pas là.

guynux a écrit :

J'ai cloné ce disque dur...


Étonnant, vue l'importance des explications !  En tout le cas, je mettrai "sous les coudes" ce topic.

Amicalement.

#29 17-04-2011 19:32:05

zoroastre74
Membre
Distrib. : Debian Wheezy
Noyau : Linux 3.2
(G)UI : Awesome wm v3.4.13 (Octopus)
Inscription : 28-08-2010

Re : Cloner des disques durs en conservant l'accès réseau

Yep!

Cher e-miel,

Je sens bien que tu possèdes des connaissances qui vont bien au-delà du simple commun des mortels, pourtant tu avances des vérités qui sont en accord avec les fondamentaux qui sont la base de l'informatique d'aujourd'hui et d'hier. Et pourtant...

Lorsqu'il s'agit d'accès disque (en lecture comme en écriture) ce n'est jamais une appli, ni même l'OS qui réalise la copie, mais le firmware du disque.


Rappeles-toi ce qu'est un firmware !!! Les firmwares n'ont pas toujours existés...Il s'agit avant tout d'électronique et de mode de communication entre péripheriques. Pas besoin de firmware pour faire du rs232, de l'i2c par exemple...L'informatique s'est développé de concert avec les periphériques communicants. Il n'empêche qu'un assemblage intelligent de composants électroniques peuvent communiquer ensembles, rien qu'en utilisant des signaux électroniques, si si !!!

Le language assembleur est ce qui se rapproche le plus du langage machine, pourtant il y demeure plusieurs façon d'ecrire une seule fonction dans ce langage, il en va de même en c, vb, pascal ou autre. Le resultat sera le même pour peu que l'on respecte le cahier des charges, la methode differera en fonction des qualités artistiques du ou des programmateurs...Les "primitives" que tu évoques ne sont pas uniques à linux, elles sont parties intégrantes des modes de communication entre électroniques et péripheriques, elles sont binaires.

Toutes les applications sont à égalité sur ce point, autant cat que cp que dd. Aucune appli ne peut réaliser une copie en interne.


Exacte car il s'agit d'electronique, pourtant dans le sens où tu l'entends tu subodores que touch equivaut à rm. En effet, ces deux programmes font appels aux systèmes pour contrôler le disque dur et utilisent à la fois le système et le firmware correspondant pour manipuler ce même disque dur...Que nenni, ces programmes appelent le système, qui lui même grâce à un adressage complexe effectue ce qu'on lui demande. Le firmware est juste là pour optimiser ce travail. Le code programme pourrait surprendre tant la similitude entre ces deux fonctions est proche, en langage assembleur du moins...

Un pipe est un lien de données entre 2 processus


C'est aussi un lien entre les données entrantes et sortantes...

(stdio)


...Je ne l'entendais pas dans le sens linuxien, je pensais que tu comprendrais !
Dire aussi que le shell n'est pas concerné dans certaines opérations est aussi une erreur car des commandes tels que cp, mkdir, rm, cat "existent" (entre guillemet, hein!) parce que le shell existe. D'ailleurs, on pourrait interpreter le shell comme un langage de programmation, non ???
Dire le contraire reviendrait à nier l'existence du shell ! Oooohhh !!!

Je sais reconnaitre mes erreurs quand je me trompe et ne m'en cache pas (je l'ai prouvé).

Mais affirmer des contre-vérités sans avoir une connaissance globale de ce qu'est une communication physique entre péripheriques, c'est oublier l'Histoire !!!

@+

Zoroastre.

PS :

Tout en lisant attentivement cette discussion, je constate que principal intéressé n'est toujours pas là.


Vrai...peut-être est-il le seul à se marrer là !

Hors ligne

#30 17-04-2011 20:55:46

e-miel
Membre
Lieu : Strasbourg
Distrib. : Alpine 3.8.0
Noyau : Linux 4.14
(G)UI : PuTTY 0.70
Inscription : 02-04-2011

Re : Cloner des disques durs en conservant l'accès réseau

zoroastre74 a écrit :

(..) Les firmwares n'ont pas toujours existés... (..)


C'est vrai. J'ai utilisé le terme firmware pour parler des périphériques actuels. N'empêche que dans les années 1990, il existait des appareils avec firmware qui communiquaient en RS232.

Le language assembleur est ce qui se rapproche le plus du langage machine, pourtant il y demeure plusieurs façon d'ecrire une seule fonction dans ce langage, il en va de même en c, vb, pascal ou autre. Le resultat sera le même pour peu que l'on respecte le cahier des charges, la methode differera en fonction des qualités artistiques du ou des programmateurs...


C'est vrai. Il y a la propreté du code (un code propre est plus lisible par un humain, mais aussi plus performant car il va "droit au but") et surtout l'algorithme qui déterminent la performance d'un traitement. Cependant, dans le cas d'une copie, il n'y a pas de traitement, ce n'est que de la délégation au noyau (pour la découpe en paquets, le système de fichiers avec cache-disque en RAM) et au contrôleur disque (pour réaliser la copie elle-même).

Les "primitives" que tu évoques ne sont pas uniques à linux, elles sont parties intégrantes des modes de communication entre électroniques et péripheriques, elles sont binaires.


Exact. Linux, Windows... ont leurs primitives. Dans les OS multitâches, les primitives permettent aux processus de communiquer, mais pour réaliser un traitement interne pas besoin d'appels-système: les processus réalisent tout dans leurs mémoires virtuelles.

(..) tu subodores que touch equivaut à rm.


Tout dépend du point de vue. D'un point de vue du Shell, touch et rm sont les applications /bin/touch et /bin/rm. Mais une fois le EXEC passé, ces 2 applications n'émettent pas du tout les mêmes appels-système, alors que cat, cp et dd émettent les mêmes appels-système, aux tailles de bloc près.

[small]Hors-sujet 1 : touch fichier change la date de modification de fichier (très utilisé avec make) alors que rm fichier supprime fichier.
Hors-sujet 2 : certains utilisent touch fichier pour créer un fichier vide, moi j'utilise >fichier pour ça.[/small]

Un pipe (..) est aussi un lien entre les données entrantes et sortantes...


Qui entrent et sortent d'où ? Pour moi, on ne peut parler de pipe qu'entre 2 processus. Dans cat <a >b, je ne vois aucun pipe.

stdio (..) Je ne l'entendais pas dans le sens linuxien, je pensais que tu comprendrais !


Je n'étais pas bloqué sur le sens linuxien, quoi que sous Windows les pipes n'existent pas. Je sais que Cygwin peut simuler des pipes, du moins lorsque les applis sont compilées avec le compilateur Cygwin, mais au sens propre du terme, il n'existe pas de pipe sous Windows.

Dire aussi que le shell n'est pas concerné dans certaines opérations est aussi une erreur car des commandes tels que cp, mkdir, rm, cat "existent" (entre guillemet, hein!) parce que le shell existe. D'ailleurs, on pourrait interpreter le shell comme un langage de programmation, non ???


C'est vrai, toutes ces applis ont été créées pour être utilisées dans un Shell. Cependant, même si l'utilisateur écrit sa ligne de commande dans un Shell, et qu'il hérite des descripteurs préparés par le Shell, l'exécution sera indépendante du Shell, dans le sens que les données ne transiteront pas par le Shell.

Je sais reconnaitre mes erreurs quand je me trompe et ne m'en cache pas (je l'ai prouvé). Mais affirmer des contre-vérités sans avoir une connaissance globale de ce qu'est une communication physique entre péripheriques, c'est oublier l'Histoire !!!


Il n'y a pas de mal. Tout ce que je voulais dire c'est que si les appels-système sont les mêmes, le résultat sera le même, peu importe qu'ils soient réalisés en partie par le Shell (cat <a >b) ou intégralement par l'appli lancée (cp a b) ou au choix de l'utilisateur (dd if=a >b).

Si je crée (par exemple en C) une application perso et que je veux tester si elle fonctionne correctement en lisant des gros blocs ou des petits blocs, je peux utiliser dd if=données bs=taille_à_tester | perso >résultat. Je veux aussi tester si mon appli perso arrive à bien découper sa sortie grâce à perso <données | dd of=résultat bs=petite_taille. Pour moi, dd et touch sont des commandes quasi-inutiles pour le commun des mortels, mais très utiles pour les développeurs d'applications.

Hors ligne

#31 18-04-2011 02:45:43

zoroastre74
Membre
Distrib. : Debian Wheezy
Noyau : Linux 3.2
(G)UI : Awesome wm v3.4.13 (Octopus)
Inscription : 28-08-2010

Re : Cloner des disques durs en conservant l'accès réseau

Yep!

Les firmwares <que l'on peut assimiler aux pilotes mais d'un point de vue materiel uniquement> ont évolués avec les besoins plus pressant en performances et stabilités.
Les disques dur modernes sont couramment pourvus de firmware, pilote qui aura la tache de manipuler les buffers en entrée, les adressages et les retranscrire en signaux electromagnétiques.
Comparativement, les supports flash n'ont pas de firmware, ils sont constitués de composants électroniques qui manipuleront de la même manière, par un jeux de mémoire et de modification des signaux, des états primitifs.
Il est à considerer que nombre de nos péripheriques ne possèdent pas de firmware. Nul besoin de décortiquer un ordinateur pour s'en rendre compte. Ceux-ci sont bien souvent gérés par le système d'exploitation et ne réclament aucune performance outrancière.
Il est évident que le commerce favorise l'évolution des performances, des peripheriques et tout naturellement le firmware y trouve sa place, le pilote aussi.

Cependant, dans le cas d'une copie, il n'y a pas de traitement, ce n'est que de la délégation au noyau (pour la découpe en paquets, le système de fichiers avec cache-disque en RAM) et au contrôleur disque (pour réaliser la copie elle-même)


On pourrait même dire qu'en fait il ne se passe rien !

Le système ne copie pas des données physiques, il modifie des adressages mémoires et transmet ces modifications selon des règles mathématiques et electriques aux autres péripheriques. La complexité des algorithmes et des composantes informatiques ne doivent pas masquer une réalité philosophique, celle du non-sens de nos interpretations, l'informatique est devenu une boîte noire, secrete, que seul des magiciens pourraient comprendre.

Le langage assembleur est effectivement ce qui se rapproche le plus du langage machine, je l'ai déjà dit, mais il serait bon de définir ce qu'est une machine avant tout et ne pas omettre que le langage assembleur travaille avec des registres mémoires.

Là, je renvoie qui veut vers la machine de Turing

Qui entrent et sortent d'où ? Pour moi, on ne peut parler de pipe qu'entre 2 processus


FIFO est un pipe aussi.
La bonne définition d'un pipe est le partage d'un espace mémoire entre plusieurs processus.
Il y aurait donc des pipes partout et peut-être encore plus chez Windows !!!

Pour moi, dd et touch sont des commandes quasi-inutiles pour le commun des mortels, mais très utiles pour les développeurs d'applications.


Je pense le contraire et nous sommes beaucoup de mortels wink

@+

Zoroastre.

Hors ligne

#32 18-04-2011 07:05:05

smolski
quasi...modo
Lieu : AIN
Distrib. : backports (buster) 10
Noyau : Linux 4.19.0-8-amd64
(G)UI : gnome
Inscription : 21-10-2008

Re : Cloner des disques durs en conservant l'accès réseau

Ça c'est du topic d'info et je vous en remercie d'en débattre sur le forum.

J'irai jusqu'à dire qu'un lien vers ce fil sera du plus bel effet entre les commandes dd et touch désignées dans le wiki df et cette discussion passionnante !

Pour amener une petite participation très personnelle, je dirai que sur ce propos :

Pour moi, dd et touch sont des commandes quasi-inutiles pour le commun des mortels, mais très utiles pour les développeurs d'applications.


Je pense le contraire et nous sommes beaucoup de mortels


Selon M. Mc Luhan, lorsque nous utilisons un outil, nous devenons cet outil par anesthésie de nos sensations mises en action par cet outil.

Ors donc, le langage informatique exprime cette anesthésie et les commandes dd et touch sont donc tout à fait exploitables par nous tous,mortels, sans discrimination, avec tout ce qu'elles comportent de rigueur attaché, comme avec l'utilisation de tout outil créé humainement.
Ensuite, il nous revient chacun (ou non) d'en apprendre les arcanes pour en tirer un profit plus personnel.
Comme toute l'informatique et comme le permet totalement debian et le libre en général.

Yeaaaaaaaaaaaaaaah lol


saque eud dun (patois chtimi : fonce dedans)

Hors ligne

#33 18-04-2011 13:46:22

e-miel
Membre
Lieu : Strasbourg
Distrib. : Alpine 3.8.0
Noyau : Linux 4.14
(G)UI : PuTTY 0.70
Inscription : 02-04-2011

Re : Cloner des disques durs en conservant l'accès réseau

zoroastre74 a écrit :

Il est à considerer que nombre de nos péripheriques ne possèdent pas de firmware. Nul besoin de décortiquer un ordinateur pour s'en rendre compte. Ceux-ci sont bien souvent gérés par le système d'exploitation et ne réclament aucune performance outrancière.


D'après moi, tous les périphériques ont un firmware, mais tous ne le stockent pas nécessairement dans une Flash embarquée. Certains périphériques lors du démarrage demandent au pilote de leur fournir le firmware. Les cartes graphiques, même haut-de-gamme, ont de base un mini-firmware compatible VESA qui ne gère aucune accélération, ni 3D ni la vitesse de rotation du ventilateur. Le pilote officiel contient le firmware à copier dans la RAM de la carte graphique lorsqu'elle le demandera au démarrage. Je pense même que la majorité de la taille du pilote ne sert pas aux "fonctions de pilotage" mais plutôt au firmware vu comme un "gros binaire incompréhensible" que le pilote doit copier dans la carte graphique lors du démarrage. C'est pour ça qu'on parle de pilote DirectX 10 ou DirectX 11, ce n'est pas les "fonctions de pilotage" qui sont DirectX mais plutôt les fonctions rendu 3D que le firmware est capable de calculer. Il en va de même dans les mini-dongles USB qui servent de carte-son, tunerTV, etc... et je suppose que concernant les périphériques intégrés dans la carte-mère, on choisit dans le BIOS quels sont les firmware à fournir (Enable) ou à ne pas fournir (Disable) lors de l'initialisation. Je peux me tromper, mais c'est comme ça que je l'ai compris. Par contre, les disques-durs ou SSD embarquent à 100% le firmware, c'est pour ça qu'il faut les "flasher" pour les mettre à jour, expression qu'on n'emploiera jamais pour une carte graphique ou un dongle-USB.

FIFO est un pipe aussi.


Oui, pipe = FIFO, mais dans cat <a >b je ne vois aucune FIFO.

La bonne définition d'un pipe est le partage d'un espace mémoire entre plusieurs processus.
Il y aurait donc des pipes partout et peut-être encore plus chez Windows !!!


Je ne suis pas d'accord, du moins quant à l'emploi du terme pipe. Pour moi, lorsque plusieurs processus se partagent du code exécutable, on appelle ça des librairies (ou bibliothèques en français). Lorsque plusieurs processus se partagent une zone de travail, on appelle ça de la mémoire partagée (optenue sous Linux avec shm ou mmap). Lorsque des données sont copiées (et non partagées) d'un processus à l'autre directement (c'est-à-dire sans mémoire partagée ni tampon intermédiaire) on appelle ça un pipe (ou tube en français). Le pipe est un moyen de partager l'exécution du WRITE d'un processus et du READ d'un autre processus, mais il n'y a aucune zone de mémoire partagée dans un pipe. FIFO (First In First Out) désigne simplement l'ordre dans lequel les données sont copiées, c'est tout.

Pour moi, dd et touch sont des commandes quasi-inutiles pour le commun des mortels, mais très utiles pour les développeurs d'applications. (..) Je pense le contraire et nous sommes beaucoup de mortels.


Si Monsieur Lambda veut sauvegarder son MBR (à supposer qu'il sache ce que c'est) il va plutôt écrire head -c 512 /dev/sda >mbr, et s'il est un peu futé (qu'il a lu dans man head que b=512 et qu'il pense à compresser) il va écrire head -c b /dev/sda | gzip >mbr.gz, et concernant les futurs boots EFI, ils seront faciles à sauvegarder avec head et tail, mais je ne vois pas comment y arriver avec dd.

smolski a écrit :

Selon M. Mc Luhan, lorsque nous utilisons un outil, nous devenons cet outil par anesthésie de nos sensations mises en action par cet outil. Or donc, le langage informatique exprime cette anesthésie et les commandes dd et touch sont donc tout à fait exploitables par nous tous,mortels, sans discrimination, avec tout ce qu'elles comportent de rigueur attaché, comme avec l'utilisation de tout outil créé humainement.


Si quelqu'un est habitué à dd, je lui souhaite bien du plaisir avec dd, mais si j'avais en face de moi un débutant, je préférerai lui conseiller cp et head plutôt que dd.

Si on laisse de côté l'aspect feeling d'un éventuel passionné de touch ou dd, je ne vois pas de cas dans lequel Monsieur Lambda aurait intérêt de fixer manuellement une taille de blocs de copie, ou de changer la date de modification d'un fichier sans avoir modifié son contenu. Par contre, pour un développeur d'applications, j'en vois tout à fait l'utilité.

Hors ligne

#34 18-04-2011 14:56:27

smolski
quasi...modo
Lieu : AIN
Distrib. : backports (buster) 10
Noyau : Linux 4.19.0-8-amd64
(G)UI : gnome
Inscription : 21-10-2008

Re : Cloner des disques durs en conservant l'accès réseau

Avec une pensée émue et fraternelle pour l'initiateur de ce fil délicieux, un certain : guynux qui doit en manger son chapeau d'être sur debian-facile, et à qui je dédis cette citation :

Ah ben oui, là, elle va bien moins marcher maintenant !


Bourvil dans le film Le Corniaud.
À propos de sa 2 chevaux complètement démantibulée à un carrefour par la Bentley de De Funes, comme la question de guynux l'est dans ce déroulement des logiques et des fonctionnements de l'informatique en réponses.

J'ajouterai donc, que d'utiliser dd ou touch pour e-miel, c'est utiliser une belle voiture de luxe avec un klaxon en diamant pour faire simplement "coin-coin" ?
Alors que les commandes lambda de cat ou de cp suffisent sans excès au même résultat de copie certaine dans tous les cas compréhensibles intuitivement ?

Concernant la commande chevron : > à la place de la commande : touch, de mémoire d'utilisateur, la commande chevron > pour créer un fichier peut être interprétée différemment par le système, selon le contexte, par exemple, lors d'une commande find ou dans un script bash, non ?

Bisou à guinux et merci de vos explications, chers e-miel et zoroastre74.
Comme arien, je mets ce topic sous le coude.

Amitié, Jojo l'halluciné lol


saque eud dun (patois chtimi : fonce dedans)

Hors ligne

#35 18-04-2011 18:04:26

zoroastre74
Membre
Distrib. : Debian Wheezy
Noyau : Linux 3.2
(G)UI : Awesome wm v3.4.13 (Octopus)
Inscription : 28-08-2010

Re : Cloner des disques durs en conservant l'accès réseau

Yep!

Un firmware n'est rien d'autre qu'une application embarquée dans un materielle afin d'y faciliter une inter-communication. Il réalise les fonctions materielles élementaires et s'occupent de l'amorçage de celui-ci (le bios par exemple). Ni plus Ni moins.
Les firmwares se sont développés de concert avec les logiciels et la multiplication des peripheriques, dans les années 70, par comparaison le langage de programmation Fortran date des années 50.

Dans mon quotidien, je pilote quelquefois des afficheurs lcd graphiques qui possèdent naturellement un contrôleur graphique. Je suis libre de communiquer avec le firmware afin de me faciliter le travail (grace à des fonctions préparées) ou de développer ma propre application en assembleur pour réaliser le même travail et bien plus. D'ailleurs, les firmwares sont bien souvent programmés en assembleur.

Le pipe est un moyen de partager l'exécution du WRITE d'un processus et du READ d'un autre processus, mais il n'y a aucune zone de mémoire partagée dans un pipe.


Comment un processus pourrait se passer de la réservation d'un espace mémoire ???
Prends exemple sur la mémoire tampon où les données y sont stockées les unes derrières les autres, découpées, en attente que cette mémoire se vide et se remplisse à nouveau, jusqu'à la dernière once.
Le langage C utilise ces mémoires pour réguler ses entrées/sorties. Le noyau n'en est pas exclu non plus, car dés le moment où nous faisons appel à une variable, une chaine, nous travaillons avec la mémoire. Le processeur a ses registres aussi...
L'assembleur, pour finir, utilise ses mnémoniques pour les convertir en langage machine. Terme tout à fait adapté.

@+

Zoroastre.

Dernière modification par zoroastre74 (18-04-2011 18:05:06)

Hors ligne

#36 18-04-2011 18:26:58

e-miel
Membre
Lieu : Strasbourg
Distrib. : Alpine 3.8.0
Noyau : Linux 4.14
(G)UI : PuTTY 0.70
Inscription : 02-04-2011

Re : Cloner des disques durs en conservant l'accès réseau

Même si tu dis plein de choses vraies, j'ai l'impression que tu n'as pas compris ce qu'est un pipe, comment cela fonctionne. Il n'y a aucun tampon intermédiaire, aucune zone provisoire de quelque nature que ce soit impliquée dans le fonctionnement d'un pipe. Un pipe n'est pas un fichier temporaire, ni une zone de mémoire partagée.

Choisir d'utiliser un pipe c'est configurer le noyau pour que les infos sortant du processus A (lors d'un WRITE) rentrent directement dans le processus B (lors d'un READ), directement c'est-à-dire sans intermédiaire. Le seul moyen pour y arriver est d'exécuter le WRITE de A en même temps que le READ de B. Or, d'un point de vue du multitâche, il est impossible que ces 2 appels-système soient invoqués en même temps, c'est pourquoi le premier processus qui aura fait un READ/WRITE sera endormi en attendant que l'autre processus en fasse un lui-aussi. Lorsque cela arrive, les 2 processus dorment. Pendant ce temps, le noyau copie les données de A vers B sans tampon puis réveille les 2 processus lorsque la copie est terminée. Le pipe c'est ça.

Hors ligne

#37 18-04-2011 19:02:17

zoroastre74
Membre
Distrib. : Debian Wheezy
Noyau : Linux 3.2
(G)UI : Awesome wm v3.4.13 (Octopus)
Inscription : 28-08-2010

Re : Cloner des disques durs en conservant l'accès réseau

Yep!

Un exemple simplifié de pipe entre deux processus indépendants :

Le pipe est crée avant les deux processus et est independant de ceux-ci.
On utilise mknod nom_du_pipe pi pour créer le tunnel.

Ecriture

/*   Ecriture non bloquante dans pipe nomme  */  
#include <stdio.h>  
#include <sys/signal.h>  
#include <fcntl.h>  
main()  
{
      int d, i, n;
      char buf[2000];  
/*  ouverture du pipe
       Il a été créé par mknod mon_pipe pi
       Ouverture :
         O_RDWR       lecture/écriture
         O_NDELAY non bloquant
         2 signifie  droit d'écriture (convention Unix)
*/
      d = open("mon_pipe",O_RDWR|O_NDELAY,2);
      if (d < 0){
          fprintf(stderr,"problème d'ouverture du pipe\n");
          exit(1);
      }  
/*  remplissage du pipe    */
      for (i=0; i<2000; i++){
           buf[i]='n';
      }
      if ((n = write(d,buf,2000))>0)
          fprintf(stdout,"Ecriture de %d caractères\n",n);
      sleep(20);
      exit(0);
}


Lecture

/*  lecture bloquante dans pipe nomme  mon_pipe  */  
#include <stdio.h>  
#include <sys/signal.h>  
#include <fcntl.h>
main()  
{
     int d,i,n;
     char buf[2000];  
/*       open du pipe mon_pipe lecture bloquante
         O_RDONLY  lecture seulement  4  droit de lecture (convention Unix)  
*/
     d = open("mon_pipe",O_RDONLY,4);
     if (d < 0){
          fprintf(stderr,"Erreur ouverture du pipe\n");
          exit(1);
     }
     fprintf(stdout,"pipe ouvert\n");
     n = read(d,buf, 2000);
     fprintf(stdout,"Lecture de %d caractères\n",n);
     fprintf(stdout,"Les 20 premiers sont\n");
     for (i=0;i<20;i++){
     fprintf(stdout,"%c",buf[i]);
     }
     fprintf(stdout,"\n");
     exit(0);
}


Les pipes permettent de filtrer des commandes ou processus, il n'y a pas de limite théorique au nombre de programmes ou de commandes que l'on peut enchaîner.

Un pipe permet de copier les données directement depuis la mémoire virtuelle d'un processus vers la mémoire virtuelle d'un autre processus, sans aucun tampon intermédiaire. Un pipe ne consomme donc aucune ressource mémoire


lol

http://en.wikipedia.org/wiki/Pipeline_(Unix)

Implementation

In most Unix-like systems, all processes of a pipeline are started at the same time, with their streams appropriately connected, and managed by the scheduler together with all other processes running on the machine. An important aspect of this, setting Unix pipes apart from other pipe implementations, is the concept of buffering: a sending program may produce 5000 bytes per second, and a receiving program may only be able to accept 100 bytes per second, but no data is lost. Instead, the output of the sending program is held in a queue. When the receiving program is ready to read data, the operating system sends its data from the queue, then removes that data from the queue. If the queue buffer fills up, the sending program is suspended (blocked) until the receiving program has had a chance to read some data and make room in the buffer. In Linux, the size of the buffer is 65536 bytes.


Pas besoin de traduire buffer j'espère...

La modification qu'apporte un pipe sur le flot de données entre processus dépend bien entendu des processus en jeu et des données à transiter, la mémoire virtuelle est un fait inhérent, il n'empêche que les données sont affectés par la taille du buffer et la vélocité des processus à effectuer les read/write.
NetBSD par exemple, utilise la mémoire vive afin de réduire les échanges entre les read/write au sein même d'un pipe.

Les pipes ne se résument pas uniquement à donner le relais au processus suivant. Ils ont differentes facettes et ne peuvent plus se résumer à un simple tuyau unidirectionnel et invariable.

@+

Zoroastre.

Dernière modification par zoroastre74 (18-04-2011 20:39:07)

Hors ligne

#38 19-04-2011 21:54:53

e-miel
Membre
Lieu : Strasbourg
Distrib. : Alpine 3.8.0
Noyau : Linux 4.14
(G)UI : PuTTY 0.70
Inscription : 02-04-2011

Re : Cloner des disques durs en conservant l'accès réseau

Je ne vous ai pas oublié, je fais des tests avec les pipe, et bien... j'en apprends des choses!

Je vous en parlerai plus en détail demain, mais pour résumer, ce que j'en ai compris pour l'instant c'est qu'il y a bien un tampon mais que par défaut il n'est pas toujours utilisé:
– Dans le cas de petits transferts (genre quelques lignes de texte) cela se déroule comme tu l'as dit: les WRITE du processus A ne sont pas blocants et les données s'accumulent dans un tampon (d'une taille de 64ko par défaut) avant d'être lues par le READ du processus B.
– Dans le cas de transferts volumineux (genre audio, vidéo, flux multimédia en général, compression, clonage disque) les WRITE sont blocants et la copie se fait directement des processus A à B sans passer par le tampon.

Il y avait donc du vrai dans chacun de nos propos.

Le flag O_NDELAY (synonyme de O_NONBLOCK) dont tu parles permet de réaliser des READ vides (si aucune donnée n'est prête) et de tronquer les WRITE pour que les données tiennent dans le tampon: cela augmente le nombre de READ et de WRITE donc diminue les performances, mais évite que l'application soit bloquée. Ce flag n'est pas spécifique aux pipes mais peut également servir sur des fichiers classiques. Le Shell n'utilise jamais ce flagh pour réaliser ses OPEN (de fichiers ou de pipes).

En tout cas quoi qu'il en soit, et avec tout l'intérêt que j'ai pour les pipes, il ne faut pas confondre entrée et sortie standards et pipes, même si le Shell permet de relier la sortie standard de A à l'entrée standard de B par un pipe, mais dans cat <a >b il n'y a aucun pipe.

Hors ligne

#39 19-04-2011 22:45:21

guynux
Membre
Lieu : Soissons + Simiane-la-Rotonde
Distrib. : bullseye
Noyau : Linux 5.10.0-21-amd64
(G)UI : Xfce4
Inscription : 08-03-2009

Re : Cloner des disques durs en conservant l'accès réseau

Bonsoir
    D'abord merci de toutes ces infos, et ensuite, désolé, j'ai été un peu absent en effet et cela  peu paraître désinvolte... mais j'avoue que j'ai déjà par ailleurs tenté de résoudre mon problème sans grand succès et je ne m'attendais pas à déclencher pareil tsunami avec ma question de connexion au réseau de mon bahut...
    Oui, un vrai cours donné par e-miel -entre autre - qui illustre bien la richesse du partage des informations que les systèmes propriétaires sont incapables de faire.
    Merci à arien et smolski qui s'inquiètent ou de ne pas me voir ou de se demander ce que je vais pouvoir exploiter de cet échange fort intéressant mais quelque peu éloigné de ma question initiale.
    Sur le plan pratique depuis des années j'utilise dd pour des disques durs divers et je n'ai jamais eu aucun souci. La seule inconnue est d'attendre la fin du processus sans aucun renseignement en espérant qu'aucune perturbation électrique ne mette un terme à la copie... ... Copie nécessitant selon le matériel 1 heure environ.
    PS J'ai rempli infodistri, 3 lignes , c'est tout ?

Dernière modification par guynux (19-04-2011 22:48:16)

Hors ligne

#40 19-04-2011 23:55:40

zoroastre74
Membre
Distrib. : Debian Wheezy
Noyau : Linux 3.2
(G)UI : Awesome wm v3.4.13 (Octopus)
Inscription : 28-08-2010

Re : Cloner des disques durs en conservant l'accès réseau

Yep!

La seule inconnue est d'attendre la fin du processus sans aucun renseignement


aptitude install dcfldd


http://dcfldd.sourceforge.net/

Le paquet est fonctionnel mais date de 2006 !!!

Il existe une astuce (script bash) pour obtenir une barre de progression avec cp.

Concernant ton problème...

As-tu necessairement besoin de configurer tes postes en ip fixe ?

iface eth0 inet static


As-tu un routeur/serveur cisco ? Je pensais à fixer les ip en fonctions des adresses mac des cartes réseaux.
As-tu configurer un pc en tant que serveur dhcp ou passerelle ?

Je pense que la solution la plus confortable pour un deploiement rapide demeure un serveur PXE.

http://publications.jbfavre.org/system/ … tos_redhat

Je crois savoir aussi que dans ce domaine, des solutions toutes faites existent.

@+

Zoroastre.

Dernière modification par zoroastre74 (20-04-2011 00:50:06)

Hors ligne

#41 20-04-2011 01:26:57

e-miel
Membre
Lieu : Strasbourg
Distrib. : Alpine 3.8.0
Noyau : Linux 4.14
(G)UI : PuTTY 0.70
Inscription : 02-04-2011

Re : Cloner des disques durs en conservant l'accès réseau

Je n'ai jamais vu de barre de progression avec cp (l'option -v ne permet d'afficher que les noms des fichiers successifs), à moins que tu ne connaisses une option non-référencée dans le manuel.

Pour afficher la progression avec dd, ou plutôt connaître son état d'avancement à l'instant T, tu peux envoyer un signal USR1:

dd if=/dev/sda1 of=/dev/sda2 &
PID=$!
kill -USR1 $PID


Par contre, je ne connaissais pas dcfldd (quel nom pourri). Je viens de le tester et ça affiche la progression en temps réel, c'est donc la solution idéale pour ce genre d'opération. Je l'adopte.

Merci Zoroastre. wink

Hors ligne

#42 20-04-2011 01:35:07

zoroastre74
Membre
Distrib. : Debian Wheezy
Noyau : Linux 3.2
(G)UI : Awesome wm v3.4.13 (Octopus)
Inscription : 28-08-2010

Re : Cloner des disques durs en conservant l'accès réseau

Yep!

Un volontaire pour tester wink

Barre de progression pour cp

http://tuxce.selfip.org/informatique/aj … ssion-a-cp

@+

Zoroastre.

PS : Ce topic devrait s'appeler "bienvenue chez les fous" lol

Hors ligne

#43 20-04-2011 04:55:03

smolski
quasi...modo
Lieu : AIN
Distrib. : backports (buster) 10
Noyau : Linux 4.19.0-8-amd64
(G)UI : gnome
Inscription : 21-10-2008

Re : Cloner des disques durs en conservant l'accès réseau

guynux écrit :
je ne m'attendais pas à déclencher pareil tsunami avec ma question de connexion au réseau de mon bahut...


smile

guynux écrit :
J'ai rempli infodistri, 3 lignes , c'est tout ?


Impec !

Et ne te gêne pas guynux à déclencher encore de tels kamikazes (vent divin) sur le forum df, on est preneur sans satiété !

Tchibâââ ! lol

zoroastre74 écrit :
Bienvenue chez les fous


Et même :
Bienvenue chez les fous-faciles
Là : http://debian-facile.org/forum/viewtopi … 662#p27662
Nous dirait un certain MaTTuX_ originellement ! wink

Pour la barre de progression de la commande cp dans le post précédent de zoroastre74, j'ai ouvert un nouveau fil là :
http://debian-facile.org/forum/viewtopi … 707#p30707

Afin de ne pas tout mêler davantage !

Hop hop hop ! smile


saque eud dun (patois chtimi : fonce dedans)

Hors ligne

#44 20-04-2011 07:20:36

guynux
Membre
Lieu : Soissons + Simiane-la-Rotonde
Distrib. : bullseye
Noyau : Linux 5.10.0-21-amd64
(G)UI : Xfce4
Inscription : 08-03-2009

Re : Cloner des disques durs en conservant l'accès réseau

zoroastre74 a écrit :
Concernant ton problème...

As-tu necessairement besoin de configurer tes postes en ip fixe ?

    iface eth0 inet static

Je réponds :
    1 - Je ne suis pas le seul utilisateur de la salle mais le seul défendant l'idée et la pratique des logiciels libres - sur 40 profs - (et pas longtemps encore car dans moins d'un an la retraite !) ;
    2 - Je ne suis pas grand spécialiste réseau devant quotidiennement m'occuper de bien des tâches différentes et urgentes ayant de moins en moins rapport avec l'enseignement... et encore moins avec Linux !
    3 - Il en découle que je pensais décalquer la configuration faite sous XP à celle sous Linux afin de perturber le moins possible mes collègues. J'ai des machines (P IV avec 256 Mo) sous double boot XP et Lenny.
    4- J'avais auparavant défendu l'idée que chaque salle sous équipée en réseau (même en LTSP) - ce qui me paraissait aussi défendable du point de vue charge du serveur du bahut - mais mon idée n'a pas eu d'écho... (Le gestionnaire réseau de l'époque ne voyant que sous Windows, gestionnaire depuis disparu car plus de budget pour lui ! Ca va être beau l'avenir ! ) Donc actuellement les élèves se connectent en entrant un identifiant et un mot de passe sous XP. Sous Lenny j'ai créé des identifiants par niveau... L'idéal serait de pouvoir se connecter de la même façon sous Linux et sous XP ce qui perturberait encore moins élèves et profs mais là j'avoue mon incompétence... Aujourd'hui la situation est intenable : Entre la situation du réseau et les ordinateurs dont certains ont des disques durs pleins (de m...) à 100%, d'autres à 96% car personne ne gère bien sûr ces "menus détails" on arrive à des refus de fonctionnement ou des temps de connexion à Internet demandant parfois plusieurs minutes ! (J'ai mis à jour ces situation avec un Live Linux et qtparted ou df -h)
    5 - J'ai donc repris de A à Z un disque, y ait installé Xp (d'abord bien sûr, sourire...) et Lenny sur place, dans le bahut avec les infos nécessaires (connues à l'avance) et là du premier coup (même à l'installation : miroir sur le réseau ! ) ça passe..
    6 - Le clonage : j'avais réussi de cloner et de modifier un nouveau disque pour avoir Internet et malheureusement au second clone je n'y suis pas arrivé (n'ayant rien noté du premier ! aïe, c'est mal...)

    J'ignore si mes problèmes bassement matériels intéresseront un internaute... qui pourrait me proposer une solution dont la mise en œuvre serait immédiate si possible (j'ai une quinzaine de disques durs chez moi là et si je pouvais modifier - avec un Live - à coup sûr les bons fichiers : je pensais à /etc/interfaces et etc/resolv.conf mais cela n'a rien donné de probant... je serais ravi... Bien sûr le fonctionnement idéal (connexion individualisée par élève ne serait pas assurée...) mais tant pis.

    Enfin merci à tous de m'avoir lu

Hors ligne

#45 20-04-2011 09:47:07

smolski
quasi...modo
Lieu : AIN
Distrib. : backports (buster) 10
Noyau : Linux 4.19.0-8-amd64
(G)UI : gnome
Inscription : 21-10-2008

Re : Cloner des disques durs en conservant l'accès réseau

Bravo pour l'ensemble de ton action et de tes désirs guynux !

Déjà, pour configurer son réseau manuellement, il faut éditer le fichier interfaces là :

/etc/network/interfaces


et non :

je pensais à /etc/interfaces et etc/resolv.conf


/etc/interfaces


Je te conseille pour l'ensemble de tes commandes en terminal d'utiliser l'autocomplément de la tabulation.
C'est à dire que tu rédiges les 3 premières lettres de ta ligne de commande, et en appuyant sur tabulation de ton clavier, le complément du mot tapé s'écrit automatiquement.
Si tu ne te rappelles pas la suite d'une commande par le chemin, à partir du dernier repertoire trouvé, tu tapes deux fois sur tabulation et une liste de possibilités est proposée à notre mémoire défaillante.

Pour ce qui concerne le réseau, je laisse à d'autres plus pointus (et moins pressés que je ne le suis ces temps) de te fournir des réponses.

Il reste aussi que tu as un salon df très actif où tu peux poser des questions et recevoir des réponses par qui le sait immédiatement.

Voir :
http://debian-facile.org/asso:salon-irc-df

ou bien là :
http://debian-facile.org/logiciel:konversation

Tchibâââ ! :lol


saque eud dun (patois chtimi : fonce dedans)

Hors ligne

#46 20-04-2011 10:04:36

e-miel
Membre
Lieu : Strasbourg
Distrib. : Alpine 3.8.0
Noyau : Linux 4.14
(G)UI : PuTTY 0.70
Inscription : 02-04-2011

Re : Cloner des disques durs en conservant l'accès réseau

Si tes PC sont à la ramasse, mais que ton réseau est au minimum de l'Ethernet 10/100, avec une connexion supplémentaire en Gigabit, tu peux en faire des serveurs X.

Si tu veux une compatibilité Windows/Linux, tu dois utiliser les mêmes protocoles réseau. Soit tu adaptes Windows à Linux, soit Linux à Windows, au choix.

Est-ce que l'un d'entre vous connaîtrait un client NFS pour Windows ?

Hors ligne

#47 20-04-2011 10:13:49

smolski
quasi...modo
Lieu : AIN
Distrib. : backports (buster) 10
Noyau : Linux 4.19.0-8-amd64
(G)UI : gnome
Inscription : 21-10-2008

Re : Cloner des disques durs en conservant l'accès réseau

je crois que cela ne se peut pour le client nfs avec windows. J'utilise samba pour ce.

saque eud dun (patois chtimi : fonce dedans)

Hors ligne

#48 20-04-2011 23:02:16

guynux
Membre
Lieu : Soissons + Simiane-la-Rotonde
Distrib. : bullseye
Noyau : Linux 5.10.0-21-amd64
(G)UI : Xfce4
Inscription : 08-03-2009

Re : Cloner des disques durs en conservant l'accès réseau

Oui comme le dit e-miel
"Si tu veux une compatibilité Windows/Linux, tu dois utiliser les mêmes protocoles réseau. Soit tu adaptes Windows à Linux, soit Linux à Windows, au choix."

J'ai voulu faire en IP static comme étaient les postes sous Xp... maintenant pour ce qui est du reste (client NFS, etc.) je n'ai aucuen info.

Pour l'adresse de interfaces, oui c'est bien /etc/network/interfaces (pardon de l'erreur due à des notes rapides sur papier) et non un oubli d'autocomplément.

J'espère que l'un de vous pourra me dire le "petit" truc que j'ai oublié...

Merci

Dernière modification par guynux (20-04-2011 23:03:45)

Hors ligne

#49 20-04-2011 23:27:47

e-miel
Membre
Lieu : Strasbourg
Distrib. : Alpine 3.8.0
Noyau : Linux 4.14
(G)UI : PuTTY 0.70
Inscription : 02-04-2011

Re : Cloner des disques durs en conservant l'accès réseau

Je viens d'ajouter cette page dans le Wiki. Avant que Zoroastre ne m'en parle ici il y a 3 jours, je ne savais pas qu'un pipe pouvait utiliser un tampon dans certains cas. C'est donc de la connaissance toute fraîche qui découle de mes nombreux essais réalisés depuis 3 jours.

Bonne lecture (et merci Zoroastre wink).

Hors ligne

#50 24-04-2011 01:19:36

zoroastre74
Membre
Distrib. : Debian Wheezy
Noyau : Linux 3.2
(G)UI : Awesome wm v3.4.13 (Octopus)
Inscription : 28-08-2010

Re : Cloner des disques durs en conservant l'accès réseau

Yep!

Superbe contribution e-miel wink

J'ai compilé ton prog et réalisé tes essais avec plaisir. Je prendrais plus tard le temps de décortiquer tout çà cool

Cher guynux,

e-miel a évoqué la possibilité de construire une achitecture autour d'un serveur X.
J'en connaissais le principe tout en ayant jamais réellement approfondis le sujet. Je joins donc deux liens que je me suis mis en favoris pour évoquer les grandes lignes et signale tout de même que malgrés le fait que les clients peuvent être des machines faiblement armées (à l'exeption de la carte réseau), le serveur lui doit être musclé.

http://www.gentoo.org/doc/fr/ltsp.xml

http://www.linuxjournal.com/magazine/mu … s?page=0,0

Il s'agirait de construire une architecture autour d'un serveur DHCP+TFTP+LTSP. Le deuxième lien présenté ici permettrait de démarrer un client à partir de la carte réseau (donc sans disque dur) sur un os qui pourrait être linux, mac ou windows.

Les avantages sont enormes car toute l'architecture se trouverait centralisée sur une seule machine, le serveur, réduisant ainsi les couts de maintenance et allongeant considérablement la durée de vie des machines clientes (peu puissantes, pas de dd, consommation électrique réduite, etc). J'ai entrevu une configuration de cet ordre avec des pentium 166, 32 Mo de ram, en machines clientes...

Dans mes recherches je suis également tombé sur : FreeNX, noMachine. Elle rejoigne la conception évoquée.

Je pense me préparer à tester tout ceci dés juillet. J'utiliserais deux serveurs et envisagerais le clustering dans la foulée.

@+

Zoroastre.

Dernière modification par zoroastre74 (24-04-2011 01:27:57)

Hors ligne

Pied de page des forums