Pour copier, il y a une commande faite pour ça : cp
Essaie donc :
cp -a /boot/* /mnt/wd/boot/
cp -a /home/* /mnt/wd/home/
cp -a -x / /mnt/wd/
l'option -x spécifie qu'il ne faut copier que les fichiers sur le même file system.
Pour être plus tranquille, je te conseille, avant la copie, d'arrêter un maximum de démons (tous les serveurs du type apache, samba, cups mais aussi X, ssh, syslog, ...) : cela évitera les tentatives d'écriture sur le disque source pendant la copie. Ensuite, pour faire ça vraiment bien, tu remontes tes systèmes de fichiers en lecture seule :
mount /home -o remount,ro
par exemple.
Avec ça il ne devrait pas il y avoir de problème avec la copie.
Evidemment, après il faudra pouvoir booter sur ce nouveau disque, mais pour ça je te laisse réfléchir un peu ;-)
Pas de quoi, ça me fait plaisir qu'on soit arrivé au bout.
Juste une dernière question : l'affichage fonctionne avec du tunneling SSH ou bien simplement avec une connexion TCP "classique" (DISPLAY fixée à l'adresse IP de la station cliente/Serveur X) ?
D'après le nom, ttauth et le fichier .TTAuthority concerne un mécanisme équivalent à xauth et .XAuthorit mais pour l'accès aux terminaux textes (TTY). Je précise bien que ce n'est qu'une supposition (je n'ai pas eu le temps de chercher ...) et je ne vois pas bien dans quel cas cela peut servir. Mais je peux me tromper.
D'après ce que tu nous dit, il apparaît que la connexion X11 avec la machine Mandrake passe bien directement en TCP sans utiliser le tunneling SSH, ni même l'authentification xauth (je trouve tout de même ce dernier moint surprenant).
Comment est-ce que la sesion X est lancé su ton poste ? (gdm, xdm, kdm, startx, ...)
Avec quelles options X s'exécute ? (ps -ef |grep X)
Je pense qu'il va falloir fouiller un peu du côté de la configuration de kdm (sous kubuntu, je pense que c'est ce que tu utilises) ...
Le problème de lancement de synaptic sous root (ou de n'importe quelle appli graphique sous un utilisateur différent) est le même que tu sois en local ou connecté en SSH sur un serveur distant.
Lorsque tu te logues en root (su -), tu ne récupéres pas la variable DISPLAY (ça c'est facile à régler) ni le cookie d'authentification de ta session X (dans le fichier ~/.Xauthority). Tu peux fixer la variable DISPLAY manuellement à la même valeur que celle de la session utilisateur ouverte avec SSH et récupérer le cookie qui va bien (voir un de mes posts précédents, ou alors tu récupères le fichier .Xauthority en le copiant ou en faisant un lien symbolique).
Mais le plus simple est tout de même de faire exactement la même chose que le lanceur "synaptic" dans le menu : au lieu d'ouvrir une session sous root avec un "su -" puis de lancer synaptic, tu exécutes simplement
gksu -u root /usr/sbin/synaptic.
C'est alors gksu qui se charge de l'authentification (mot de passe root) et du paramétrage nécessaire pour X (DISPLAY + autorisation).
Est-ce que du côte client (kubuntu), le serveur X accepte bien les conexions TCP ? Pour vérifier, la commande 'netstat -an' doit te retourner une ligne ressemblant à :
tcp 0 0 0.0.0.0:6000 0.0.0.0:* LISTEN
[le numéro de port doit être 6000 + numéro de display]
Si cette ligne n'apparaît pas ou si X écoute seulement sur l'interface locale (127.0.0.1 au lieu de 0.0.0.0) ça ne peut pas fonctionner avec une connexion telnet.
Que vaut DISPLAY et que donne "xauth list" sur l'AIX lorsque ton collègue sous Mandrake s'y connecte ? (pour savoir si le tunneling SSH du protocole X11 est utilisé et fonctionne).
Posté par JJD .
En réponse au message Awk 2.
Évalué à 3.
Plus sérieusement, il existe certainement plusieurs solutions en fonction de ce que tu veux faire et de la façon dont tu le fais.
Donc, comment exécutes-tu ton programme awk actuellement ?
On va supposer que tu tapes "awk -f programme.awk fichier_à_traiter".
Où sont tes fichiers à traiter :
- tous les fichiers d'un répertoire donné ?
- tous les fichiers pouvant correspondre à un masque ? (par exemple *.txt , */t*.csv, ...)
- tu as la liste de ces fichiers dans un fichier ?
Comment veux tu récupérer le résultat :
- un fichier de sortie par fichier en entrée ?
- un unique fichier de sortie ?
Supposons donc que tu veux traiter tous les fichiers *.txt du répertoire courant avec ton programme awk contenu dans le fichier programme.awk et que tu veux un fichier de sortie par fichier d'entrée avec les noms *.out, tu peux faire (sous bash) :
for f in *.txt ; do awk -f programme.awk "$f" >"${f/.txt$/.out}" ; done
En fonction de tes besoins, il te reste à adapter ...
Les logs ssh ne semblent pas mettre en évidence une erreur quelqconque.
Est-ce que tu as pu modifier les scripts d'initialisation (.profile) pour ne pas forcer la variable DISPLAY?
Si oui, que vaut cette variable ?
La directive X11DisplayOffset apparaît-elle dans le fichier sshd_config du serveur ?
Que te donne, sur le serveur, la commande "xauth list" ?
Est-ce que tu as un fichier .Xauthority sur l'AIX ?
Quels sont les droits sur ce fichier ?
(question bête : tu as bien le droit d'écriture dans ton HOME sur le serveur ? : je demande ça à tout hazard, parce que tu as dit que ton .profile appartenait à root)
Tu as dit qu'un de tes collègues pouvait se connecter au serveur AIX et lancer des applications graphiques : que vaut alors la variable DISPLAY et que donne "xauth list". Il est fort possible, vu ce que tu as déjà écrit, que la connexion X11 ne passe pas du tout pas un tunnel SSH mais par une simple connexion TCP. Si c'est le cas, tu peux essayer de faire la même chose en faisant :
1) sur ta machine cliente, tu récupère le cookie d'autorisation avec :
xauth list localhost:0
tu devrais avoir une sortie avec nom_de_ta_machine MIT-MAGIC-COOKIE-1 <chaine de 32 caractères>.
Et tu testes : comme tu as déjà viré l'option -nolisten tcp ça devrait marcher, mais ça n'a alors plus rien à voir avec du tunneling ssh (ça marcherait de la même façon avec une connexion telnet ou rlogin).
Cela signifie que les paquets X11 passent en clair sur le réseau, mais sur un réseau local d'entreprise le risque est tout de même minime.
Je suis assez d'accord avec Ramón : il y a certainement un des scripts de connexion (.profile ou autre, en fonction du shell utilisé) qui fixe la valeur de la variable DISPLAY. Sinon, soit le tunneling du protocole X11 fonctionne et on devrait avoir DISPLAY=localhost:xx.0, soit ça ne marche pas, et il n'y a aucune raison que DISPLAY soit positionnée.
[la valeut xx dépend de la directive X11DisplayOffset de sshd_config sur ton AIX, normalement positionnée à 10]
Essaie donc de regarder dans les scripts exécutés au lancement (.profile et /etc/pofile en particulier si le shell est ksh).
Si tu ne vois rien de particulier, tu peux toujours essayer de nous envoyer la sortie que tu obtiens lors d'une connexion avec l'option -vv (et -X évidemment).
Avec l'option -X du client SSH tu ne devrais rien avoir à faire pour pouvoir affichier des applications distantes sur ton display.
Quelques points cependant à vérifier :
- il ne faut pas que tu fixes manuellement la variable DISPLAY dans ta session distante. ssh se débrouille comme un grand pour fixer le DISPLAY qui va bien (normalement DISPLAY est positionné à localhost:10.0 si ton DISPLAY local est :0.0). C'est également ssh qui va se charger de mettre les bonnes données dans .Xauthority.
- dans la conf du serveur ssh (/etc/sh/sshd_config), il faut que la directive "X11Forwarding" soit positionnée à "yes", sinon ça ne peut pas marcher.
- sur le serveur, il fut trouver le programme xauth dans /usr/bin/X11/xauth, sinon il est nécessaire de le préciser dans sshd_config avec la directive XAuthLocation (le chemin par défaut peut être différent).
Pour faire un diagnostic plus précis : quand tu te connectes avec l'option -X, est-ce que la variable DISPLAY est bien positionnée ?
Si ce n'est pas le cas, vérifie les fichiers de conf ("man sshd_config" peut bien t'aider).
Tu peux également lancer ssh avec l'option -v (ou -vv ou -vvv) pour avoir une trace de parlante et essayer de comprendre ce qui ne marche pas.
Posté par JJD .
En réponse au message ubuntu debian.
Évalué à 2.
Je pense que c'est là une des différences les plus importantes entre les mondes Redhat (rpm) et Debian (deb) : alors que les distributions rpm, qui se sont toutes basées sur redhat au départ, ont fini par diverger au point que la compatibilité des paquetages est pour le moins alléatoire, les distributions basées sur Debian (debian, ubuntu, [kg]noppix et pleins d'autres) semblent (devraient) conserver une bien plus grande homogénéité. Certains, en exagérant un peu, présentent même Debian comme une méta-distribution servant de base aux autres (mais je ne m'aventurerai pas là dedans, étant moi-même utilisateur -très satisfait- de Debian).
Une conséquence (preuve ?) de cela est que sur DLFP il y a les forum redhat, mandriva, suse, mais pas ubuntu ou autre dérivé de debian : le forum debian semble suffire à tous.
Un classique (Advanced Bash Scripting Guide) par exemple sur http://www.tldp.org/LDP/abs/(...) (ou rechercher dans google, il existe peut être une traduction française)
essaie de retouver les volumes logiques avec les commandes lvscan et lvdisplay.
Tu devrais voir apparaître la liste de tes volumes logiques sous une forme du genre "/dev/usb_sda1/nom_du_volume_logique".
Il est probable que les noms qui apparaissent sont des liens symboliques vers le device réel (quelque chose comme /dev/mapper/usb_sda1-volume_logique).
Il te suffit de monter ce device :
mount /dev/mapper/usb_sda1-volume_logiquepoint_de_montage
et si tout va bien tu rajoutes les lignes correspondantes dans /etc/fstab.
J'espère que mes explications sont à peu près claires.
la commande escputil devrait faire exactement ce que tu veux. Essaie de chercher un paquet appelé "escputil-4.2.7-*.rpm ou quelque chose du genre ...
Cet utilitaire fait partie du projet gutenprint (anciennement gimp-print) : voir http://gimp-print.sourceforge.net/(...) .
Normalement, en mode passif, tu devrais pouvoir te connecter sur des serveur FTP, SAUF si ton routeur fait également office de firewall et qu'il filtre les connexions sortantes. Dans ce cas, pour le FTP, il faut non seulement autoriser les sorties vers le port TCP 21, mais egalement vers tous (?) les ports supérieurs à 1024 : en mode passif, le client ouvre une deuxième connexion sur le serveur FTP pour le transfert des data sur le port TCP que lui indique le serveur. Je ne pense pas que l'on puisse savoir, a priori, quel port devra être utilisé. Certains routeurs/pare-feux savent gérer le protocole FTP et ouvrent les ports nécessaires de façon dynamique (aussi bien en mode actif que passif d'ailleurs). Jette quand même un coup d'oeil à la documentation de ton routeur.
Le protocole HTTP est bien plus simple à gérer, et pour l'utiliser avec apt, il te suffit de mettre des lignes du genre :
deb http://us.archive.ubuntu.com/ubuntu(...) hoary main
dans le fichier /etc/apt/sources.list.
Le problème peut effectivement être dû à une connexion FTP en mode actif (le serveur essaie alors d'ouvrir une connexion TCP sur le client pour le transfert des data) : un firewall qui ne gère pas le protocole FTP bloquera alors cette tentative de connexion. Essaie de voir si tu as un fichier /etc/apt/apt-file.conf (ça doit dépendre de ta version de apt) : à l'intérieur tu as des lignes permettant de préciser les modes de récupération des paquets. Cherche la ligne commençant par "ftp=". Si c'est curl qui est utilisé, tu dois avoir l'option "--ftp-pasv" ; si c'est wget, il faut "--passive-ftp".
Par ailleurs, il peut il y avoir des soucis si tu passes par un proxy pour sortir de ton réseau local : à ce moment-là, il faut fixer la variable d'environnement "ftp_proxy" avant de lancer apt-get/synaptic/kpackage.
Sinon, un autre moyen de régler la question est de récupérer les paquets en http (je ne connais pas les URL des dépots ubuntu, mais en changeant simplement ftp:// par http:// ça peut marcher [quelqu'un peut confirmer ?]).
Enfin, concernant ta dernière question, je te conseille de toujours utiliser des paquetages pour l'installation de logiciels, et de préférence ceux officiellement prévus pour ta distribution. Si tu ne trouves pas ton bonheur, recherche des paquets .deb "non officiels" avant de te tourner vers une installation "sauvage" (et encore dans ce cas-là, l'idéal serait de récupérer les sources, compiler, faire une .deb et installer le paquet ainsi généré, mais c'est une autre histoire). Le fait de toujours utiliser des paquets pour l'installation de logiciel te permettra de conserver un système cohérent et facilement administrable avec une bonne gestion des dépendances (après, on peut ne pas aimer ça et vouloir gérer ces dépendances soi-même, mais il faut alors changer de distribution).
J'espère que ces quelques remarques te seront utiles.
Debian package la version de firefox en Englais (US) + un paquetage par langue.
La version 1.0.5 a dû apparaître hier. Comme elle n'implique pas de modifications au niveau des chaînes de caractères affichées, il n'y pas de nécessité de mettre à jour les langues pour la localisation.
A ce sujet, il y a dèjà un journal (forum ?), il y a quelques jours dans lequel les mainteneurs de la francisation de firefox indiquaient que la version 1.0.5 était prête et allait bientôt (?) être téléchargeable et qu'en attendant, il était toujours possible d'installer la version anglaise et de récupérer les fichiers de localisation (ce doit être les fichiers *FR* dans le répertoire chrome).
Le "bug" est déjà renseigné (cf http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=libaspell15c2),(...) mais à mon avis, ce n'en est pas vraiment un. La branche unstable de Debian est, comme son nom l'indique, potentiellement instable, ou plutôt disons qu'il peut il y avoir des problèmes de dépendances cassées.
En particulier, il y a en ce moment le pasage de gcc3.3 à gcc4.0, ce qui suppose la recompilation de l'ensemble des paquets, en commençant pas les binaires statiques et les librairies. Tout que tous les paquets n'auront pas été mis à jour, avec les bonnes dépendances, les utilisateurs de la branche unstable seront confrontés à ce type de soucis. Ceux qui sont sous etch (testing) devraient s'en tirer un peu mieux, mais il risque également d'il y avoir (très transitoirement) le même type de problème.
Pour avoir plus de détails sur la transition de gcc (3.3 -> 4.0) voir http://lists.debian.org/debian-devel-announce/2005/07/msg00001.html(...) .
Désolé de te décevoir encore une fois, mais dans le code que tu donnes, les commandes ne sont pas exécutées en parallèle : l'affectation de la variable code1 doit être terminée pour que l'instruction suivante (code2 = `(commande2 > fichier2 ; echo $? ) &`) soit exécutée. Ça ne répond donc pas réellement au problème de départ de Paddle (exécution de plusieurs commandes en même temps avec récupération du code retour).
Pour finir, si le coup de l'export des variables ne fonctionne pas, c'est parce que export permet de dupliquer des variables vers les sous-processus et non pas de les partager avec eux. En aucun cas la modification dans un sous-shell d'une variable exportée ne sera visible dans le shell appelant (et cela n'est pas spécifique à ksh).
Je ne pense pas que cela puisse fonctionner en l'état :
- le "&&" qui sépare la commande de l'affectation de la variable CODEx fait que cette affectation ne sera effectuée que si la commande sort sans erreur. Donc, soit CODEx vaut 0, soit elle n'existe pas du tout. On pourrait remplacer && par un simple ; (point virgule), mais ...
- lorsque des commande sont exécutées en arrière plan, il y a un fork du shell. Tout ce qui est entre accolades est donc exécuté par un sous shell, et aucune des variables affectées dans ce sous-shell n'est récupérable par le shell appelant. Après le wait, les variables CODEx n'existent donc pas (sauf si elles avaient été déclarées avant, mais alors leur valeur ne serait pas modifiée).
La réponse au problème semble effectivement plus complexe que prévue.
Quelques pistes à explorer :
- wait sans argument attend que tous les processus fils soient terminés (et renvoie certainement le code retour du dernier qui se finit)
- on peut récupérer le PID d'un process lancé en arrière plan dans la variable $!
- wait nnn attend la fin du process ayant le pid nnn (mais je ne vois pas bien comment utiliser wait ici, pour attendre la fin de plusieurs processus successivement alors que l'on ne connaît pas l'ordre dans lequel ils vont finir)
Une solution simple (même si elle n'est pas très élégante) pourrait être de rajouter, à la fin des commandex quelque chose du genre "echo $? > /tmp/$$", de récupérer dans une variable le pid des commande en background ($!) et de relire les fichiers concernés après le wait.
En plus clair :
Je ne pense pas que le message qui s'affiche soit réellement un problème. En fait sur ton écran (ton pseudo-terminal numéro 1) tu as les informations sur tout ce qui est lancé au boot. Le dernier message est Starting K display manager: kdm.
Ensuite, tu as Debian GNU/Linux 3.1 balrog tty1
balrog login:
qui correspond au lancement de getty sur le device /dev/tty1 (c'est le programme qui gère ton login).
La suite (eth1: no IPv6 routers present) est un message du noyau quis'affiche sur la console : je pense qu'il n'y a pas à s'en inquiéter (ça te dit simplement que sur le réseau où est connecté l'interface eth1 il n'y a pas de routeur IP v6) et que ça n'a pas de rapport avec le lancement de KDM.
Il serait intéressant de savoir ce qui s'affiche dans les fichiers de logs. Est-ce que tu as un fichier du genre /var/log/kdm/:0.log ? (j'utilise gdm et j'ai bien la log de lancement du serveur X dans /var/log/gdm/:0.log).
Tu peux également essayer de voir ce qui se passe si en tant que root tu lances /etc/init.d/kdm start.
Tout cela te permettre peut-être de comprendre ce qui ne plait pas à kdm.
On est bien d'accord que le port 8080 est le port d'écoute du proxy. En revanche, ce proxy ne relaie certainement pas vers n'importe quel port sur les serveurs externes : l'accès sur les ports 80 (HTTP)et 443 (HTTPS) est certainement (forcément) autorisé. Il y a des chances que d'autres ports (comme le 8080) soient également ouverts. Par contre, il serait étonant que des ports comme le 22 (ssh) soient ouverts.
De plus, même en faisant écouter le serveur SSH sur un autre port (80, 443, 8080 ou tout autre port que le proxu accepte de relayer), il y a, à mon avis, peu de chance que cela fonctionne correctement car le proxy ne va relayer que des requêtes HTTP.
Je te conseille donc effectivement l'utilisation de httptunnel : il faut lancer la partie serveur (hts) sur ta machine perso et exécuter le client (htc) sur le poste à ton école en spécifiant les bons paramètres (en particulier le port à utiliser). Le couple htc/hts va encapsuler ton flux SSH dans des requêtes HTTP et tu devrais pouvoir passer le proxy.
En résumé : tu lances hts sur ton serveur SSH en lui disant de se mettre à l'écoute en HTTP sur le port XXXX et de router vers le port 22 en local. Tu lances htc sur la machine cliente en précisant le port d'écoute local YYYY, le proxy HTTP avec son authentification et l'adresse IP/port du serveur hts. Pour établir la connexion SSH, sur la machine cliente tu lances "ssh -l user -p YYYY localhost" (connexion ssh vers la machine locale sur le port YYYY où htc est à l'écoute. htc encapsule les trames TCP dans des requêtes HTTP et les envoie au serveur hts sur le port XXXX via le proxy. hts extraie les trames TCP du flux HTTP et les redirige vers le port 22 du serveur SSH) : c'est (beaucoup ?) plus lent qu'une connexion directe, mais "chez moi ça marche".
# cp pour copier
Posté par JJD . En réponse au message Changement de disque : copie de l'un sur l'autre. Évalué à 3.
Essaie donc :
cp -a /boot/* /mnt/wd/boot/
cp -a /home/* /mnt/wd/home/
cp -a -x / /mnt/wd/
l'option -x spécifie qu'il ne faut copier que les fichiers sur le même file system.
Pour être plus tranquille, je te conseille, avant la copie, d'arrêter un maximum de démons (tous les serveurs du type apache, samba, cups mais aussi X, ssh, syslog, ...) : cela évitera les tentatives d'écriture sur le disque source pendant la copie. Ensuite, pour faire ça vraiment bien, tu remontes tes systèmes de fichiers en lecture seule :
mount /home -o remount,ro
par exemple.
Avec ça il ne devrait pas il y avoir de problème avec la copie.
Evidemment, après il faudra pouvoir booter sur ce nouveau disque, mais pour ça je te laisse réfléchir un peu ;-)
A+
JJD
[^] # Re: YES !!!
Posté par JJD . En réponse au message Kubuntu 5.04 : can't open display from an aix worstation. Évalué à 2.
Juste une dernière question : l'affichage fonctionne avec du tunneling SSH ou bien simplement avec une connexion TCP "classique" (DISPLAY fixée à l'adresse IP de la station cliente/Serveur X) ?
Bonne journée
JJD
[^] # Re: X sous SSH
Posté par JJD . En réponse au message Kubuntu 5.04 : can't open display from an aix worstation. Évalué à 2.
D'après ce que tu nous dit, il apparaît que la connexion X11 avec la machine Mandrake passe bien directement en TCP sans utiliser le tunneling SSH, ni même l'authentification xauth (je trouve tout de même ce dernier moint surprenant).
Comment est-ce que la sesion X est lancé su ton poste ? (gdm, xdm, kdm, startx, ...)
Avec quelles options X s'exécute ? (ps -ef |grep X)
Je pense qu'il va falloir fouiller un peu du côté de la configuration de kdm (sous kubuntu, je pense que c'est ce que tu utilises) ...
A+
JJD
[^] # Lancement appli graphique sous un autre utilisateur
Posté par JJD . En réponse au message Kubuntu 5.04 : can't open display from an aix worstation. Évalué à 2.
Le problème de lancement de synaptic sous root (ou de n'importe quelle appli graphique sous un utilisateur différent) est le même que tu sois en local ou connecté en SSH sur un serveur distant.
Lorsque tu te logues en root (su -), tu ne récupéres pas la variable DISPLAY (ça c'est facile à régler) ni le cookie d'authentification de ta session X (dans le fichier ~/.Xauthority). Tu peux fixer la variable DISPLAY manuellement à la même valeur que celle de la session utilisateur ouverte avec SSH et récupérer le cookie qui va bien (voir un de mes posts précédents, ou alors tu récupères le fichier .Xauthority en le copiant ou en faisant un lien symbolique).
Mais le plus simple est tout de même de faire exactement la même chose que le lanceur "synaptic" dans le menu : au lieu d'ouvrir une session sous root avec un "su -" puis de lancer synaptic, tu exécutes simplement
gksu -u root /usr/sbin/synaptic.
C'est alors gksu qui se charge de l'authentification (mot de passe root) et du paramétrage nécessaire pour X (DISPLAY + autorisation).
J'espère avoir pu t'aider
JJD
[^] # Re: X sous SSH
Posté par JJD . En réponse au message Kubuntu 5.04 : can't open display from an aix worstation. Évalué à 2.
tcp 0 0 0.0.0.0:6000 0.0.0.0:* LISTEN
[le numéro de port doit être 6000 + numéro de display]
Si cette ligne n'apparaît pas ou si X écoute seulement sur l'interface locale (127.0.0.1 au lieu de 0.0.0.0) ça ne peut pas fonctionner avec une connexion telnet.
Que vaut DISPLAY et que donne "xauth list" sur l'AIX lorsque ton collègue sous Mandrake s'y connecte ? (pour savoir si le tunneling SSH du protocole X11 est utilisé et fonctionne).
[^] # Re: la réponse est simple
Posté par JJD . En réponse au message Awk 2. Évalué à 3.
Donc, comment exécutes-tu ton programme awk actuellement ?
On va supposer que tu tapes "awk -f programme.awk fichier_à_traiter".
Où sont tes fichiers à traiter :
- tous les fichiers d'un répertoire donné ?
- tous les fichiers pouvant correspondre à un masque ? (par exemple *.txt , */t*.csv, ...)
- tu as la liste de ces fichiers dans un fichier ?
Comment veux tu récupérer le résultat :
- un fichier de sortie par fichier en entrée ?
- un unique fichier de sortie ?
Supposons donc que tu veux traiter tous les fichiers *.txt du répertoire courant avec ton programme awk contenu dans le fichier programme.awk et que tu veux un fichier de sortie par fichier d'entrée avec les noms *.out, tu peux faire (sous bash) :
for f in *.txt ; do awk -f programme.awk "$f" >"${f/.txt$/.out}" ; done
En fonction de tes besoins, il te reste à adapter ...
A+
JJD
# la réponse est simple
Posté par JJD . En réponse au message Awk 2. Évalué à 1.
-> OUI
[^] # Re: X sous SSH
Posté par JJD . En réponse au message Kubuntu 5.04 : can't open display from an aix worstation. Évalué à 2.
Est-ce que tu as pu modifier les scripts d'initialisation (.profile) pour ne pas forcer la variable DISPLAY?
Si oui, que vaut cette variable ?
La directive X11DisplayOffset apparaît-elle dans le fichier sshd_config du serveur ?
Que te donne, sur le serveur, la commande "xauth list" ?
Est-ce que tu as un fichier .Xauthority sur l'AIX ?
Quels sont les droits sur ce fichier ?
(question bête : tu as bien le droit d'écriture dans ton HOME sur le serveur ? : je demande ça à tout hazard, parce que tu as dit que ton .profile appartenait à root)
Tu as dit qu'un de tes collègues pouvait se connecter au serveur AIX et lancer des applications graphiques : que vaut alors la variable DISPLAY et que donne "xauth list". Il est fort possible, vu ce que tu as déjà écrit, que la connexion X11 ne passe pas du tout pas un tunnel SSH mais par une simple connexion TCP. Si c'est le cas, tu peux essayer de faire la même chose en faisant :
1) sur ta machine cliente, tu récupère le cookie d'autorisation avec :
xauth list localhost:0
tu devrais avoir une sortie avec nom_de_ta_machine MIT-MAGIC-COOKIE-1 <chaine de 32 caractères>.
2) Ensuite, sur le serveur AIX tu tapes :
export DISPLAY=<IP machine cliente>:0
xauth add <IP machine cliente>:0 MIT-MAGIC-COOKIE-1 <chaine de 32 caractères>
Et tu testes : comme tu as déjà viré l'option -nolisten tcp ça devrait marcher, mais ça n'a alors plus rien à voir avec du tunneling ssh (ça marcherait de la même façon avec une connexion telnet ou rlogin).
Cela signifie que les paquets X11 passent en clair sur le réseau, mais sur un réseau local d'entreprise le risque est tout de même minime.
JJD
[^] # Re: X sous SSH
Posté par JJD . En réponse au message Kubuntu 5.04 : can't open display from an aix worstation. Évalué à 4.
[la valeut xx dépend de la directive X11DisplayOffset de sshd_config sur ton AIX, normalement positionnée à 10]
Essaie donc de regarder dans les scripts exécutés au lancement (.profile et /etc/pofile en particulier si le shell est ksh).
Si tu ne vois rien de particulier, tu peux toujours essayer de nous envoyer la sortie que tu obtiens lors d'une connexion avec l'option -vv (et -X évidemment).
@+
JJD
# X sous SSH
Posté par JJD . En réponse au message Kubuntu 5.04 : can't open display from an aix worstation. Évalué à 4.
Avec l'option -X du client SSH tu ne devrais rien avoir à faire pour pouvoir affichier des applications distantes sur ton display.
Quelques points cependant à vérifier :
- il ne faut pas que tu fixes manuellement la variable DISPLAY dans ta session distante. ssh se débrouille comme un grand pour fixer le DISPLAY qui va bien (normalement DISPLAY est positionné à localhost:10.0 si ton DISPLAY local est :0.0). C'est également ssh qui va se charger de mettre les bonnes données dans .Xauthority.
- dans la conf du serveur ssh (/etc/sh/sshd_config), il faut que la directive "X11Forwarding" soit positionnée à "yes", sinon ça ne peut pas marcher.
- sur le serveur, il fut trouver le programme xauth dans /usr/bin/X11/xauth, sinon il est nécessaire de le préciser dans sshd_config avec la directive XAuthLocation (le chemin par défaut peut être différent).
Pour faire un diagnostic plus précis : quand tu te connectes avec l'option -X, est-ce que la variable DISPLAY est bien positionnée ?
Si ce n'est pas le cas, vérifie les fichiers de conf ("man sshd_config" peut bien t'aider).
Tu peux également lancer ssh avec l'option -v (ou -vv ou -vvv) pour avoir une trace de parlante et essayer de comprendre ce qui ne marche pas.
Bonne chance
JJD
# DHCP
Posté par JJD . En réponse au message Ethernet et internet. Évalué à 4.
Le plus simple est certainement d'utiliser dhcp pour la configuration de l'interface eth0.
Il suffit de mettre dans /etc/network.interfaces :
auto eth0
iface eth0 inet dhcp
Vérifie quand même que tu as un client dhcp installé (dhcp-client par exemple)
A+
JJD
[^] # Re: Souvenir
Posté par JJD . En réponse au message ubuntu debian. Évalué à 2.
Une conséquence (preuve ?) de cela est que sur DLFP il y a les forum redhat, mandriva, suse, mais pas ubuntu ou autre dérivé de debian : le forum debian semble suffire à tous.
# Quelques liens pour des scripts shell
Posté par JJD . En réponse au message comment bien débuter ?. Évalué à 2.
Un classique (Advanced Bash Scripting Guide) par exemple sur http://www.tldp.org/LDP/abs/(...) (ou rechercher dans google, il existe peut être une traduction française)
# Rechercher les volumes logiques
Posté par JJD . En réponse au message Au secour Récup de mon LVM sur Debian Sarge 3.1. Évalué à 1.
essaie de retouver les volumes logiques avec les commandes lvscan et lvdisplay.
Tu devrais voir apparaître la liste de tes volumes logiques sous une forme du genre "/dev/usb_sda1/nom_du_volume_logique".
Il est probable que les noms qui apparaissent sont des liens symboliques vers le device réel (quelque chose comme /dev/mapper/usb_sda1-volume_logique).
Il te suffit de monter ce device :
mount /dev/mapper/usb_sda1-volume_logique point_de_montage
et si tout va bien tu rajoutes les lignes correspondantes dans /etc/fstab.
J'espère que mes explications sont à peu près claires.
A+
JJD
[^] # Re: escputil
Posté par JJD . En réponse au message Comment fait-on pour nettoyer les buses d'une imprimante..... Évalué à 1.
[^] # escputil
Posté par JJD . En réponse au message Comment fait-on pour nettoyer les buses d'une imprimante..... Évalué à 2.
la commande escputil devrait faire exactement ce que tu veux. Essaie de chercher un paquet appelé "escputil-4.2.7-*.rpm ou quelque chose du genre ...
Cet utilitaire fait partie du projet gutenprint (anciennement gimp-print) : voir http://gimp-print.sourceforge.net/(...) .
A+
JJD
[^] # Re: Pourqoui pas HTTP
Posté par JJD . En réponse au message connexion ftp pour récupération packets. Évalué à 2.
Le protocole HTTP est bien plus simple à gérer, et pour l'utiliser avec apt, il te suffit de mettre des lignes du genre :
deb http://us.archive.ubuntu.com/ubuntu(...) hoary main
dans le fichier /etc/apt/sources.list.
A+
JJD
# Pourqoui pas HTTP
Posté par JJD . En réponse au message connexion ftp pour récupération packets. Évalué à 2.
Le problème peut effectivement être dû à une connexion FTP en mode actif (le serveur essaie alors d'ouvrir une connexion TCP sur le client pour le transfert des data) : un firewall qui ne gère pas le protocole FTP bloquera alors cette tentative de connexion. Essaie de voir si tu as un fichier /etc/apt/apt-file.conf (ça doit dépendre de ta version de apt) : à l'intérieur tu as des lignes permettant de préciser les modes de récupération des paquets. Cherche la ligne commençant par "ftp=". Si c'est curl qui est utilisé, tu dois avoir l'option "--ftp-pasv" ; si c'est wget, il faut "--passive-ftp".
Par ailleurs, il peut il y avoir des soucis si tu passes par un proxy pour sortir de ton réseau local : à ce moment-là, il faut fixer la variable d'environnement "ftp_proxy" avant de lancer apt-get/synaptic/kpackage.
Sinon, un autre moyen de régler la question est de récupérer les paquets en http (je ne connais pas les URL des dépots ubuntu, mais en changeant simplement ftp:// par http:// ça peut marcher [quelqu'un peut confirmer ?]).
Enfin, concernant ta dernière question, je te conseille de toujours utiliser des paquetages pour l'installation de logiciels, et de préférence ceux officiellement prévus pour ta distribution. Si tu ne trouves pas ton bonheur, recherche des paquets .deb "non officiels" avant de te tourner vers une installation "sauvage" (et encore dans ce cas-là, l'idéal serait de récupérer les sources, compiler, faire une .deb et installer le paquet ainsi généré, mais c'est une autre histoire). Le fait de toujours utiliser des paquets pour l'installation de logiciel te permettra de conserver un système cohérent et facilement administrable avec une bonne gestion des dépendances (après, on peut ne pas aimer ça et vouloir gérer ces dépendances soi-même, mais il faut alors changer de distribution).
J'espère que ces quelques remarques te seront utiles.
@+
JJD
[^] # Re: Heu ....
Posté par JJD . En réponse au journal Firefox 1.05 fr ne sera jamais disponible... Problème!. Évalué à 4.
La version 1.0.5 a dû apparaître hier. Comme elle n'implique pas de modifications au niveau des chaînes de caractères affichées, il n'y pas de nécessité de mettre à jour les langues pour la localisation.
A ce sujet, il y a dèjà un journal (forum ?), il y a quelques jours dans lequel les mainteneurs de la francisation de firefox indiquaient que la version 1.0.5 était prête et allait bientôt (?) être téléchargeable et qu'en attendant, il était toujours possible d'installer la version anglaise et de récupérer les fichiers de localisation (ce doit être les fichiers *FR* dans le répertoire chrome).
[^] # Re: Unstable is a hard live
Posté par JJD . En réponse au message [apt-get][paquet défectueux]install kdelibs4-dev. Évalué à 2.
En particulier, il y a en ce moment le pasage de gcc3.3 à gcc4.0, ce qui suppose la recompilation de l'ensemble des paquets, en commençant pas les binaires statiques et les librairies. Tout que tous les paquets n'auront pas été mis à jour, avec les bonnes dépendances, les utilisateurs de la branche unstable seront confrontés à ce type de soucis. Ceux qui sont sous etch (testing) devraient s'en tirer un peu mieux, mais il risque également d'il y avoir (très transitoirement) le même type de problème.
Pour avoir plus de détails sur la transition de gcc (3.3 -> 4.0) voir http://lists.debian.org/debian-devel-announce/2005/07/msg00001.html(...) .
A+
JJD
[^] # Re: Parce que je suis tenace ! et plein d'illusions...
Posté par JJD . En réponse au message Execution background et code de sortie. Évalué à 2.
Désolé de te décevoir encore une fois, mais dans le code que tu donnes, les commandes ne sont pas exécutées en parallèle : l'affectation de la variable code1 doit être terminée pour que l'instruction suivante (code2 = `(commande2 > fichier2 ; echo $? ) &`) soit exécutée. Ça ne répond donc pas réellement au problème de départ de Paddle (exécution de plusieurs commandes en même temps avec récupération du code retour).
Pour finir, si le coup de l'export des variables ne fonctionne pas, c'est parce que export permet de dupliquer des variables vers les sous-processus et non pas de les partager avec eux. En aucun cas la modification dans un sous-shell d'une variable exportée ne sera visible dans le shell appelant (et cela n'est pas spécifique à ksh).
Je te félicite tout de même de ta persévérance.
A+
JJD
[^] # ... malheureusement
Posté par JJD . En réponse au message Execution background et code de sortie. Évalué à 2.
Je ne pense pas que cela puisse fonctionner en l'état :
- le "&&" qui sépare la commande de l'affectation de la variable CODEx fait que cette affectation ne sera effectuée que si la commande sort sans erreur. Donc, soit CODEx vaut 0, soit elle n'existe pas du tout. On pourrait remplacer && par un simple ; (point virgule), mais ...
- lorsque des commande sont exécutées en arrière plan, il y a un fork du shell. Tout ce qui est entre accolades est donc exécuté par un sous shell, et aucune des variables affectées dans ce sous-shell n'est récupérable par le shell appelant. Après le wait, les variables CODEx n'existent donc pas (sauf si elles avaient été déclarées avant, mais alors leur valeur ne serait pas modifiée).
La réponse au problème semble effectivement plus complexe que prévue.
Quelques pistes à explorer :
- wait sans argument attend que tous les processus fils soient terminés (et renvoie certainement le code retour du dernier qui se finit)
- on peut récupérer le PID d'un process lancé en arrière plan dans la variable $!
- wait nnn attend la fin du process ayant le pid nnn (mais je ne vois pas bien comment utiliser wait ici, pour attendre la fin de plusieurs processus successivement alors que l'on ne connaît pas l'ordre dans lequel ils vont finir)
Une solution simple (même si elle n'est pas très élégante) pourrait être de rajouter, à la fin des commandex quelque chose du genre "echo $? > /tmp/$$", de récupérer dans une variable le pid des commande en background ($!) et de relire les fichiers concernés après le wait.
En plus clair :
{ commande1 "$var1" > fichier1 ; echo $? >/tmp/res.$$ ; } &
pid1=$!
{ commande2 "$var2" > fichier2 ; echo $? >/tmp/res.$$ ; } &
pid2=$!
{ commande3 "$var3" > fichier3 ; echo $? >/tmp/res.$$ ; } &
pid3=$!
wait
retour1=`cat /tmp/res.$pid1`
rm /tmp/res.$pid1
retour2=`cat /tmp/res.$pid2`
rm /tmp/res.$pid2
retour3=`cat /tmp/res.$pid3`
rm /tmp/res.$pid3
[^] # Re: man netstat
Posté par JJD . En réponse au message amina. Évalué à 2.
JJD
# Contenu des logs
Posté par JJD . En réponse au message Problème de démarrage de l'interface graphique depuis MAJ. Évalué à 1.
Je ne pense pas que le message qui s'affiche soit réellement un problème. En fait sur ton écran (ton pseudo-terminal numéro 1) tu as les informations sur tout ce qui est lancé au boot. Le dernier message est Starting K display manager: kdm.
Ensuite, tu as
Debian GNU/Linux 3.1 balrog tty1
balrog login:
qui correspond au lancement de getty sur le device /dev/tty1 (c'est le programme qui gère ton login).
La suite (eth1: no IPv6 routers present) est un message du noyau quis'affiche sur la console : je pense qu'il n'y a pas à s'en inquiéter (ça te dit simplement que sur le réseau où est connecté l'interface eth1 il n'y a pas de routeur IP v6) et que ça n'a pas de rapport avec le lancement de KDM.
Il serait intéressant de savoir ce qui s'affiche dans les fichiers de logs. Est-ce que tu as un fichier du genre /var/log/kdm/:0.log ? (j'utilise gdm et j'ai bien la log de lancement du serveur X dans /var/log/gdm/:0.log).
Tu peux également essayer de voir ce qui se passe si en tant que root tu lances /etc/init.d/kdm start.
Tout cela te permettre peut-être de comprendre ce qui ne plait pas à kdm.
Bon courage (ce ne doit pas être bien grave)
JJD
[^] # Re: Plus d'infos ?
Posté par JJD . En réponse au message Tunnel SSH à travers Proxy 8080 avec user pass. Évalué à 2.
De plus, même en faisant écouter le serveur SSH sur un autre port (80, 443, 8080 ou tout autre port que le proxu accepte de relayer), il y a, à mon avis, peu de chance que cela fonctionne correctement car le proxy ne va relayer que des requêtes HTTP.
Je te conseille donc effectivement l'utilisation de httptunnel : il faut lancer la partie serveur (hts) sur ta machine perso et exécuter le client (htc) sur le poste à ton école en spécifiant les bons paramètres (en particulier le port à utiliser). Le couple htc/hts va encapsuler ton flux SSH dans des requêtes HTTP et tu devrais pouvoir passer le proxy.
En résumé : tu lances hts sur ton serveur SSH en lui disant de se mettre à l'écoute en HTTP sur le port XXXX et de router vers le port 22 en local. Tu lances htc sur la machine cliente en précisant le port d'écoute local YYYY, le proxy HTTP avec son authentification et l'adresse IP/port du serveur hts. Pour établir la connexion SSH, sur la machine cliente tu lances "ssh -l user -p YYYY localhost" (connexion ssh vers la machine locale sur le port YYYY où htc est à l'écoute. htc encapsule les trames TCP dans des requêtes HTTP et les envoie au serveur hts sur le port XXXX via le proxy. hts extraie les trames TCP du flux HTTP et les redirige vers le port 22 du serveur SSH) : c'est (beaucoup ?) plus lent qu'une connexion directe, mais "chez moi ça marche".
JJD