B. franck a écrit 718 commentaires

oops j'ai oublié de te donner un commencement de réponse à ta question.

là où il faut opérer est dans le fichier /etc/network/interfaces
il contient la configuration des cartes réseau.
Donc: lire le man

Pour la nouvelle config de eth0 sur une fbx en mode normal, le plus simple et de la laisser tout faire en mettant ça comme config:

auto eth0
iface eth0 inet dhcp

3 cartes réseau == 3 réseaux == 3 tables de routages == 3 jeux de règles iptables == bourrain.

je te conseille de ne mettre que 2 cartes réseau, une reliée à la fbx, l'autre à ton réseau interne.
Et si tu veux vraiment que tes machines en interne ne soient pas dans le même réseau: tu fais de l'ip aliasing (plusieurs ip sur la même carte)
et tu te retrouves dans même situation (3 cartes réseaux == 3 ...) mais sans crâmer inutilement tes euros dans une 3eme nic.

mes 2 cents.

mais si c'est pour le fun d'avoir 3 nic: fonce, bien sûr :]

tu ne verras pas les "switches" mais cheops fait de belles cartes

http://cheops-ng.sourceforge.net/

dans l'ordre que l'on suivant l'humeur:
- je chercherais des boucles vu la multiplicité des switchs avec l'outil "traceroute"
- j'observerais le contenu des communications avec Ethereal (à la recherche de broadcast excessif que j'essaierais d'arrêter aux switches)
- je cartographierais le reseau avec Cheops pour avoir une vision globale du plat de spaghettis

ethereal: http://www.ethereal.com/
cheops: http://cheops-ng.sourceforge.net/
et arrêtez avec votre ping, adoptez hping2, c'est mieux: http://www.hping.org/

ce qu'ils regardent c'est le coût total

pas tou à fait d'accord. Ce qu'ils regardent c'est que dalle!

S'ils faisaient une véritable étude de coût, ils changeraient.
D'ailleurs, s'ils faisaient une quelconque étude sérieuse, ils changeraient.

Ils lisent ou gobent simplement ce que les "experts" disent et ce que les commerciaux
leur vendent.
Le coût n'est pas très important car de toute façon les entreprises déduisent ces coûts,
de plus leur priorité c'est de financer la chose avant de savoir si c'est nécessaire ou utile.

Pour être mal poli, l'entreprise c'est un tdc* qui commandent des personnes compétentes
mal payées de faire des stupidités grosses comme lui, en calquant ses décisions
sur d'autres grosses pontes de l'informatique (DSI du mois par ex) qui eux même n'ont pris
leurs décisions que parce que le commercial leur offrait un beau cadeau en échange d'une
belle grosse commande.
Comme ça le tdc donne l'impression d'être utile et justifie son salaire.
Ca rassure tout le monde d'être dans de "bonnes" mains.

C'est un beau chaînage d'incompétents ayant un beau bagage en vocabulaire "décideur"
qui suffit pour faire illusion devant le dirigeant largué sous le flot de solutions bien compliquées par les commerciaux, quelques fois par les techos voulant se rendre indispensables.

Beaucoup trop de gens ont des intérêts à ce que ce fichu système continu, c'est seulement la lame de fond, qui est en route depuis des années qui changera quelquechose.

glossaire:
* tdc - trou du c*L (voir DSI)

c'est sûr qu'un truc qui dégage toutes les heures, c'est plus sécure
enfin aussi sécure que d'arracher le rj45 ou l'alimentation...

il manque une toute petite lettre qui aéchappée à ma relecture:

la synchronisation des 2 disques depuis l'interne avec suppression:
rsync -avx --delete --exclude='.journal' /mnt/disque_interne /mnt/disque_externe

enfin je ne sais pas comment pour effacer un fichier sur disque dur externe si ce dernier ne se trouve plus sur mon disque dur interne

la synchronisation des 2 disques depuis l'interne avec suppression:
sync -avx --delete --exclude='.journal' /mnt/disque_interne /mnt/disque_externe

essaie quand même d'abord avant d'ajouter l'option --delete au cas où le chemin soit erronné
(pour ne pas détruire ce qui traîne dans la mauvaise cible)

merci de repondre sur mon mel en m'expliquant bien la procedure

même réponse que sur irc: non, un forum est là pour partager.

je fais court, sans expliquer de méthode de récupération pour ne pas me cantonner à une seule distribution (urpmi pour ta mandrake oops mandriva)
il te faut:

- les sources du noyau que tu utilises
- récupérer le module spca5xx ou ses sources
- avoir le v4l (video for linux ou videodev) activé dans ton noyau
- installer le module spca5xx ou peut-être le compiler et l'installer, si tu utilises les sources
- avoir l' snd-usb-audio d'Alsa activé dans ton noyau courant

ensuite ça se résout à des modprobe:

sudo modprobe videodev
sudo modprobe spca5xx
sudo modprobe snd-usb-audio


à partir de là tu peux attaquer /dev/video0 et /dev/dsp1 (si tu avais déjà une carte son opérationnelle, sinon c'est dsp0) avec vlc par exemple...
attention au Larsen /°\

lien vers les sources du driver spca5xx au cas où:
http://sourceforge.net/projects/spca50x/

je n'ai eu aucun problème sur ma Debian Sarge.

bonne recherche

serais-tu entrain de nous dire que ce code qui
fait fi de la portabilité, qui n'utilise pas les fonctions standards comme définies dans la documentation, qui n'initialise pas ses variables avant de les utiliser, qui utilise des pointeurs avant de regarder s'ils pointent vers quelquechose, qui est fortement "buffer-overflow-able" est du code crade ? :))

un vlc --help, 2 "page-up" et on tombe sur l'option --fullscreen
une camomille à coté de la lecture du man de xhost...

*de ne pas lire "man xhost imbécile!" et autre remarque de ce genre ->c'est dejà fait et refait.

bon on va pas te le redire car tu sembles bien énervé :)
mais t'as eu beau le lire, tu as fait un peu de mélange.

Sur Debian: %xclock -display 10.0.0.22 ->alors ca c'est carrement faux apparement

en effet, 10.0.0.22 c'est bien debian et pas film donc tu verras rien sur Film.
De plus un display est de la forme: IP:DISPLAY.ECRAN
forme simplifiée quand on a qu'un écran: IP:DISPLAY
donc en l'occurence pour avoir une chance de marcher:
xclock -display 10.0.0.33:0

%xclock -display 10.0.0.22:0 ->et là ca marche pas et j'en ignore la cause. Il m'indique: "Error: Can't open display: 10.0.0.33:0"

il semble que xclock essaie de retomber sur la variable DISPLAY du shell s'il n'arrive pas à ouvrir le display donné en paramètre.
Mais là encore, tu essaies d'afficher xclock sur debian et non sur film...

lorsque tu veux afficher xclock sur Film en le lançant depuis debian, il faut mettre le display de Film et non celui de debian.

Et bien sûr, vérifier que ton X écoute comme mentionné dans le post ci-dessus que je m'empresse de plusser.

c'est vrai que les 5 lignes avec la boucle FOR et la colonie de DATA
qui fesaient principalement des LDA bizarres
me manquent beaucoup...
Oh nostalgie du poke... quand tu nous tiens...

Allez tiens je lance "Vice" 3 minutes pour m'en dégouter

S'il ne sait pas monter un module il aura le même problème sauf qu'il se sera fait délesté de 30¤.
----
Donc, comme d'habitude, on évite de faire son décideur pressé qui claque du brouzouf à tout va, histoire d'avoir l'air de faire quelquechose et on croche un peu.

Les modules sont dans /lib/module/<VERSIONDUNOYAU>/...
où <VERSIONDUNOYAU> doit être remplacé par ce que la commande uname -r retourne.

Il faut chercher dans le dossier drivers/net, drivers/net/pcmcia ou drivers/pcmcia... je suis pas sûr

une fois la liste des modules (fichier .ko ou .o suivant la version du noyau) tu tentes le modprobe en tant que root:
# modprobe cardbus
par exemple, où cardbus est en l'occurence le module que l'on tente de monter.

Tu peux essayer aussi la distribution live type knoppix pour voir si elle te la détecte: elle te donnera le nom du module :), après à toi de le trouver et de paramétrer le chargement de ce module au boot dans ta debian: je te conseille l'utilisation du module-assistant pour ça.

vérifie bien que tu as le pcmcia installé/activé et cherche un driver dans /usr/src/linux/drivers/pcmcia/,
Au pire tu peux tenter le modprobe sur tous les modules de ce répertoire :o
je tenterais d'abord le modprobe cardbus
(une recherche google ne m'a pas donnée grand chose au premier abord, c'est donc, par experience, que cette carte ne doit pas poser de problème dans une situation normale)

la façon de faire ressemble à une synchronisation (un peu tordue)
je prendrais le problème d'une autre manière:

s'assurer que les fichiers sont synchronisés et supprimer systématiquement les fichiers de la source,
avec par exemple une exécution conditionnée du résultat de la synchronisation :
rsync -ax source/ destination/ && rm -rf source/*

mais est-il vraiment utile de supprimer les fichiers de la source après synchronisation?
Je pense que le plus important est que les fichiers soient synchronisés et pas qu'ils disparaissent de la source (sauf besoins spécifiques).

ps: voir l'option --delete autorisant la suppression dans la cible

peut-être que je m'avance un peu trop mais une compil qui dure une heure c'est un peu louche: quid de l'optimisation de la compilation via Makefile.
Et sinon après il y a toujours la solution du distcc.
Doit bien y avoir une dizaine de machines ayant une charge moyenne de 2% en continue là où tu codes ?

ps: parce que vouloir virer les namespace comme ça c'est aller tout droit dans un mur, dans un couloir...

et là crack ça bloque, arrêt de travail pour torticoliage avancé.
encore une cabale du gouvernement bush pour privilégier les fonds de pension en france...

cheops est pas mauvais pour ça, on peut même y ajouter ses scripts
http://cheops-ng.sourceforge.net/

tu as copié tes fichiers sans monter la partition dans le dossier de montage ?

si oui:
démonte la partition, redéplace tes données, remonte ta partition et re-re-redéplace tes données vers cette partition.

sinon je ne vois pas comment tu as pu transformer un dossier en fichier à moins d'avoir fait une archive ?

qu'as-tu fait exactement ?

donc si j'ai bien compris, tu veux vérifier une bande sans la lire...
c'est impossible.

cherche plutot vers l'optimisation de ta sauvegarde: réduire la quantité, ajouter un autre dlt, utiliser un SAN pour faire de l'incrémentale, ...

si tu tiens vraiment à renvoyer un tableau, tu peux renvoyer une structure contenant un seul champ: le tableau


struct str { char p[4];};
...
struct str fonction(...){
struct str res;
...
return res;
}



mais la variable de retour sera de type struct str et non pas str et sera accessible par resultat.p[i]

c'est un peu tordu car le C ne renvoie pas de tableau.
(bien sûr, j'ai considéré que tu ne voulais pas toucher aux données sur lesquelles on applique le traitement et d'ailleurs il serait préférable de les "conster")

Tu dis qu'avec scp c plus simple, je vais peut etre abuser mais tu aurais un lien où on la procédure est décrite simplement.

scp fichier_source user_cible@host_cible:/endroit/ou/on/le/depose/

en déposant ta clef publique sur le serveur cible, tu n'auras même pas de mot de passe à taper...

un conseil: abandonne rcp et son .rhosts qui posent un problème de sécurité non négligeable et installe openssh.

iproute peut-etre ?
essaye:

ip link list

faite pas attention à mon poste ci-dessus!
j'ai bourdé icmp et tcp :\