JJD a écrit 516 commentaires

La suite ...

Sous bash, si la variable file contient ton nom de fichier alors
${file##+[^0-9]} te renverra ce même nom en ayant supprimé tout les caractères non numériques du début du nom.

Si file vaut file123456789.tar, alors ${file##+[^0-9]} vaut 123456789.tar.

Dans l'expression de monprécédent post, tu peux donc mettre :
mv $file ../FILE${file##+[^0-9]}.

A+
JJD

Essaie ça : cd /home/cops91/archives && for file in $(grep -l "cops91 du 10-02-05" * ) ; do tar -xf $file && mv $file ../${$file/#archive/FILE} ; done Attention : c'est un code spécifique bash (il faudra certainement des modifs pour le faire fonctionner avec ksh ou zsh). Je n'ai pas testé, mais je pense que l'on n'est pas loin du résulat souhaité.

JJD

less envoie des chaines d'initialisation et de 'déinitialisation' au terminal dans lequel il est utilisé (utilisation de termcap).

C'est à cause de ça que sous X, dans un émulateur de terminal (xterm ou autre), on ne voit plus rien du fichier visualisé lorsque l'on quitte less. Comme avec l'option -F, less quitte de suite avec les petits fichiers, on ne voit rien (on se retrouve dans la situation d'un less, sans -X, après avoir quitté).

Pour éviter cela, tu peux utiliser l'option -X (-> encore une fois, man less explique tout ça ...)

A+

JJD

Salut,

less est susceptible d'utiliser la variable LESSCHARSET si elle est définie. Vérifie donc si LESSCHARSET existe.
Si elle est définie et contient autre chose que latin9 ou ou iso8859, supprime la (unset LESSCHARSET).
Si elle n'est pas définie et que LANG vaut fr_FR@euro, ça devrait normalement bien fonctionner. Si ce n'est pas le cas essaie un 'export LESSCHARSET=latin9' avant ta commande less.

Si tout ça ne marche toujours pas -> man less

JJD

Bonsoir,

Le programme n'aurait-il pas été développé sous DOS (plutôt que Windows) ?

Dans ce cas, il y a de grandes chances que les caractères soient codés en CodePage 850 (autrement appelé OEM).
Si la retro-compatibilité avec DOS ne te gène pas trop, tu devrait essayé de convertir tout ça en latin1 (ISO8859-1) quit doit parfaitement s'afficher aussi bien sous Unix/Linux que sous Windows.
Pour la conversion, tu peux par exemple utiliser "iconv"

 iconv -f CP850 -t ISO8859-1 

Un simple test sur un des fichiers source devrait te permettre de savoir si c'est bien ce que je te raconte.

A+
JJD

Salut,

Il aurait été intéressant de connaître le modèle de la carte réseau...

Quoi qu'il en soit, la Woody commence vraiment à dater (pas de troll SVP, même s'il est possible de choisir un noyau 2.4 (2.4.23 si j'ai bonne mémoire) au moment de l'installation. Je te conseille VRAIMENT de plutôt démarrer avec une Sarge (http://www.debian.org/devel/debian-installer/(...)) : tu télécharges une image minimale (netinst CD image), tu la graves (j'espère que tu as un graveur) et tu bootes dessus. L'adresse IP est récupérée en DHCP et après la plupart des paquets sont directement récupérés sur Internet. J'ai installé 3 machines chez moi ce dernier mois (3 bousins) et tout s'est parfaitement bien déroulé.
Si tu n'a pas de graveur, tu peux même faire tout ça à partir de disquettes (4 en tout et s'il te reste un lecteur et des disquettes) ou d'une clé USB.
Cette méthode te permettre d'avoir directement un noyau 2.6 et des paquets à jour.

Espérant avoir pu t'aider
JJD

Salut,

J'ai bien vu que tu as donné les droits des répertoires /home et /home/bob, mais qu'en est-il de / ?

J'ai exactement les mêmes symptomes que toi si je supprime les droits d'exécution/lecture à /.

JJD

Salut,

Il suffit d'installer ces extensions en tant que root.
Pour ma part, je télécharge le .xpi en tant qu'utilisateur lambda, puis j'ouvre le fichier en local dans un navigateur lancé par root.

JJD

Salut,
Pour résumer et voir si j'ai bien compris :
- tu as un serveur d'admin avec Apache (quelle version ?) et PHP (module Apache)
- tu veux que ces scripts PHP exécutent des commandes sur d'autres serveurs via SSH.

Dans ce cas, la commande SSH sera exécutée par l'utilisateur Apache (celui déclaré dans httpd.conf) et il faut donc générer une privée pour l'utilisateur Apache et déposer la clé publique correspondante sur les machine cibles (dans le fichier authorized_keys des users visés).

Si tu ne veux pas, pour des raisons de sécurité, que ce soit l'utilisateur Apache qui se connecte sur les machines cibles, tu peux essayer d'utiliser des CGI au lieu du module PHP pour Apache (remarque que tes CGI peuvent être des scripts PHP, mais qu'il doivent être exécutés par un interpréteur externe et non pas par Apache via le module PHP adéquat). Via le module Apache suexec (et moyennant quelques considérations de sécurité à découvrir dans la doc Apache), ces CGI seront exécutés par leur propriétaire -> c'est donc la clé de celui-ci qu'il faut distribuer (il est possible que le répertoire ~user/.ssh ne soit pas accessible depuis le CGI : il faut alors mettre la clé privé au bon endroit dans l'arborescence, la préciser lors de l'appel ssh et la protéger correctement au niveau des droits d'accès).

Concernant ta deuxième question, je n'ai pas tout compris. S'il s'agit de pouvoir exécuter des commandes arbitraires depuis l'interface web sur les serveurs à administrer, tu peux essayer de jeter un coup d'½il du côté du module telnet de webmin : il me semble que c'est écrit en Perl et que ça permet d'ouvrir des sessions telnet ou SSH sur des serveurs distants. Il n'est pas impossible que ce soit adaptable à tes besoins.

En espérant avoir pu t'aider (et ne pas être trop à côté de la plaque)
JJD

#include <stdlib.h>
#include <stdio.h>
#include <termios.h>
#include <unistd.h>

int main(void)
{
        int c;
        struct termios *termios_p;
        termios_p=(struct termios *)malloc(sizeof(struct termios));
        tcflag_t lflag;

        // Récupération des attributs du terminal
        tcgetattr(0,termios_p);
        // Sauvegarde des attributs
        lflag=termios_p->c_lflag;
        // Modification
        termios_p->c_lflag &= ~(ECHO);
        tcsetattr(0,TCSANOW,termios_p);

        c=getc(stdin);
        printf("Pas d'echo du caractère tapé...\n");
        printf("caractère : %c ; code ASCII : %u 0X%X\n",c,c,c);

        // Rétablissement des attributs d'origine
        termios_p->c_lflag=lflag;
        tcsetattr(0,TCSANOW,termios_p);

        return 0;
}

J'ai aussi parfois remarqué que lors de la connexion VNC sur des serveurs Windows, tout se passait comme si la touche shift était enfoncée (c'est très génant quand on double-clique sur un fichier et que ça sélectionne tous les fichiers d'un répertoire puis essaie de les ouvrir ...)
En général, un simple appui sur la touche shift remet tout d'aplomb.

Ce même problème a été rencontré avec des clients VNC Windows.

Je n'ai plus de soucis depuis mon passage à VNC version 4.

JJD

Bonjour,

Je ne suis pas vraiment un spécialiste de la chose, mais comme personne ne te répond je vais quand même te donner quelques pistes :

man syslogd
man syslog.conf

En résumé, les programmes (su, login, ...) écrivent leurs logs via le démon syslogd (il faut donc au moins qu'il soit installé et lancé).
Les fichiers dans lesquels ces logs sont écrites et les règles d'écriture (niveau de log en particulier) sont décrits dans un fichier de conf (/etc/syslog.conf). Les parties de ce fichiers qui vont t'intéresser plus particulièrement sont les entrées auth et authpriv.

Essaie de voir avec ça et tiens-nous au courant.

JJD

PS : j'ai mis un peu de temps à écrire tout ça et une réponse est arrivée depuis, mais bon maintenant que c'est tapé ...

Salut,

mldonkey devrait pouvoir répondre à ta problématique : ça fonctionne en client-serveur. La partie serveur tourne sans interface graphique et se charge de tous les transferts.
Le pilotage se fait, au choix, en telnet, en HTTP ou avec un client graphique (en GTK).
Sous debian, voir le paquet mldonkey-server (et mldonkey-gui poue le client GTK).

JJD

Vue de chez moi ton adresse IP est le 82.254.198.230. Ta directive "NameVitualHost 192.168.1.2" (attention il manque un r) est peut-être bonne si tu fais bien de la redirection de port sur ton routeur (port 80 redirigé vers ton serveur Apache).
Pour être tranquille, tu peux aussi indiquer "NameVirtualHost *".

Ensuite, il me semble qu'il faut indiquer "<VirtualHost extranet.zapto.org>" et ne pas oublier de mettre "</Directory>" avant "</VirtualHost>".

Concentre-toi, ça va marcher !

JJD

uname -r : version du kernel
uname -a : pleins d'infos ...

Je suis content pour toi que ça marche.

Tu as beau avoir de l'ADSL chez toi, il ne faut pas oublier que c'est le débit en UPLOAD de ton abonnement qui entre en jeu.

Tu peux essayer d'amméliorer un peu les choses en mettant l'option -C lors de la connexion SSH (compression des données). Attention tout de même : le temps nécessaire à la compression/décompression dépend fortement de la puissance des machines aux deux bouts de la liaison SSH et dans certains cas on peut avoir des performances pires avec l'option -C que sans.

JJD

Je te remets en une fois ce que j'ai mis plus haut :
- sur ta machine perso, il faut que tu vérifies la config du serveur SSH. Dans /etc/ssh/sshd_config, il doit il y avoir la directive "X11Forwarding yes", normalement suivi de quelque chose du genre "X11DisplayOffset 10". So c'est le cas, et à supposer que ton DISPLAY cygwin est :0, tu devais avoir, dans ta session SSH, ton DISPLAY positionné à "localhost:10"
- essaie de lancer le client ssh avec l'option -v (ssh -v -X -l user machine.perso). Juste après la phase d'authentification et avant le prompt de ton shell, tu devrais avoir des informations intéressantes sur ce qui se passe concernant le forward X11.

JJD

Encore une dernière précision : du côté de ta session cygwin, il faut bien évidemment que la variable DISPLAY soit correctement positionnée au moment où tu établis ta connexion SSH. Vérifie-le simplement avec un "echo $DISPLAY" et, si besoin est, positionne la avant le ssh (export DISPLAY=:0).

JJD

En fait, dans le cas du X11 forwarding, SSH agit comme un proxy X11. Dans ta session SSH $DISPLAY devrait être quelque chose du genre ":10.0" ou "localhost:10.0".
C'est bien ssh qui doit se charger de positionner la variable DISPLAY à la bonne valeur et de gérer l'authentification xauth.

JJD

A moins que je ne me trompe complètement, il est complètement inutile de faire un "xhost +" : cela permet d'accepter les connexions X11 depuis n'importe quelle machine. Or, dans le cas où le flux X11 est encapsuler dans un tunel SSH, l'accès au serveur X se fait en local.
De plus, la sécurité du serveur X est plutôt basée sur le mécanisme xauth (avec des cookies conservée dans le fichier ~/.Xauthority) : cela evite de faire confiance à tous les utilisateurs d'une machine donnée, et permet d'éviter que des personnes connectées sur un mêmes serveur puissent utiliser les displays des autres.

JJD

Salut,

Apparemment ton DISPLAY (sur la machine XP) n'est pas exporté. Tu pourrais avoir plus d'infos en lançant ssh avec l'option -v (informations de déboggage).
Quoi qu'il en soit, il faut au moins que tu vérifies que ton serveur SSH accepte le X11 forwarding (option "X11Forwarding yes" dans /etc/ssh/sshd_config).

JJD

La partie intéressante dans ce mail est qu'il envoyé à la liste de diffusion 'linuxfr-news_at_linufr.org' et que l'émetteur utilise (apparemment) les services d'uucpssh.org.

Si ça peut te rassurer, je te confirme que tu n'es pas le seul. J'ai reçu la même chose.

JJD

J'ai fait la même connerie, et autant vous dire que c'est galère à récupérer ...

Depuis, je fais simlement une archive (tar.bz2) de /etc toutes les nuits et je stocke ça sur un disque à part. Ce n'est pas imparable mais ça peut toujours servir et ça ne mange pas de pain.

JJD

Lorsque tu lances
htc -P proxy_uni:80 -F 22 mon_ip_chez_moi:80
sur ta machine cliente tu essaies d'ouvrir le port local 22. Ça ne peut pas marcher si une des deux conditions suivantes est remplie :
- tu n'est pas root
- le port local 22 est déjà utilisé (ce qui est le cas s'il y a un serveur SSH sur ta machine à l'université)

Dans ces 2 cas, htc n'affiche rien mais ne se lance pas. Il n'y a apparemment aucune différence avec un lancement réussi. Pour voir si htc s'exécute bien, il faut faire un ps et/ou vérifier les ports ouverts avec 'netstat -tlp'.

En résumé, je te conseille de faire :
- sur ta machine perso
hts -F localhost:22 8080
vérification de l'ouverture du port 8080 avec 'netstat -tlp'

- sur la machine de l'université :
htc -P proxy_uni:80 -F 2222 mon_ip_chez_moi:8080
vérification de l'ouverture du port 222 avec 'netstat -tlp'
connexion : 'ssh -p2222 -l user localhost'


JJD