Et pourtant, il est bien là, mais il n'y a pas de texte associé...
Avec une navigation au curseur (touche F7 sur la plupart des navigateurs), on arrive à trouver le lien (on peut aussi chercher dans le code source de la page).
Alors le voici : http://www.a-tixier.com/scroll003.htm (ça aurait été dommage de se priver d'un truc pareil !)
En revanche, sur un autre accès ADSL Free sans Freebox (accès via un modem/routeur), mafreebox.freebox.fr est bien résolu mais pas accessible. Cela semble montrer que l'adresse (ou au moins la redirection) est gérée par la Freebox (certainement le boitier ADSL dans le cas d'une V5)..
Tu devrais essayer de rebooter ta freebox : la redirection a peut être été mise en place avec la dernière mise à jour du microcode.
Est-ce que le paramètre est récupéré automatiquement en DHCP ou bien est-ce que tu l'as indiqué manuellement ?
Pour info, mes serveurs DNS sont 212.27.40.240 et 212.27.40.241.
Est-ce que le nom mafreebox.freebox.fr est bien résolu ? (tester avec un ping par exemple).
Est-ce que un wget sur l'URL fonctionne ? :
$ wget http://mafreebox.freebox.fr/freeboxtv/playlist.m3u)
Tu peux aussi essayer avec un navigateur web quelconque.
Et bien je suis content que cette solution réponde à tes besoins.
Concernant la liste des sites devant passer par le tunnel, et comme je l'indiquai dans mon premier post, la configuration devra passer par le navigateur. Une possibilité serait d'utiliser deux navigateurs différents : un pour les besoins généraux, avec un accès direct à internet et un deuxième passant par le proxy pour l'accès aux sites de ta boite.
Sinon, avec firefox, tu peux également regarder du côté des extensions : certaines (comme foxy proxy il me semble) permettent de paramétrer assez finement (éventuellement avec des expressions régulières) les sites pour lesquels il faut passer par un proxy ou pas.
Avec Opera (mais c'est pas libre), cette possibilité doit exister en natif (préférences du site).
Avec SSH tu peux parfaitement utiliser plusieurs fois l'option -L pour tunneler tout ce que tu veux.
Ainsi, tu peux établir ta connexion SSH comme ça :
ssh -N -f -n -L9000:site:443 -L9001:site:80 -L9002:site2:80
et alors https://localhost:9000 te permet d'accéder à site en HTTPS (moyennant un avertissement sur le certificat SSL), http://localhost:9002 renvoie sur site2 en HTTP, etc...
Mais cette méthode a beaucoup de limitations : il faut se souvenir (noter) toutes les correspondances, les liens entres les sites ne marchent plus, ...
Il existe cependant une méthode qui pourrait répondre à tes besoins : ssh peut agir comme un proxy socks avec l'option -D. Ouvre ta connexion SSH avec :
ssh -f -N -n -Dlocalhost:1080 nom@IP
Ensuite, tu paramètres ton navigateur pour utiliser un proxy SOCKS sur localhost:1080 (éventuellement, tu peux utiliser certaines extensions de Firefox pour ne passer par ce proxy que pour les URL internes à ton entreprise).
Avec cette méthode, tu peux utiliser directement les URL qui vont bien (https://site,http://site) et tous les sites deviennent directement accessibles.
En espérant que cela correspond bien à tes besoins.
Posté par JJD .
En réponse au message PB avec gtar.
Évalué à 1.
Ben il est possible d'exclure des fichiers avec l'option "--exclude=PATTERN" (vérifier en fonction de la version de tar utilisée), mais je ne suis pas sûr que cela te soit d'un grand secours.
tar doit lire le fichier archive de façon séquentielle (son nom signifie bien Tape ARchiver !) et le message d'erreur affiché semble indiqué un problème de corruption que tar n'arrive pas à corriger : tentative de saut à l'en-tête [de fichier] suivant, mais cet en-tête ne semble pas être trouvé.
Essaie de voir ce que donne un
tar tvf fichier.tar
Normalement ça doit te donner la liste des fichiers de l'archive, et je ne pense pas que tu réussiras récupérer plus de fichiers que ce que cette commande affichera.
Tu peux aussi essayer de voir ce que ça donne avec d'autres versions de tar (on ne ne sait jamais...)
Posté par JJD .
En réponse au message PB avec gtar.
Évalué à 1.
Bonjour,
Apparemment, d'après le chemin de l'exécutable, tout cela se passe sous (Open) Solaris, mais ça ne doit avoir que peu d'importance.
D'après le message renvoyé par tar, je suppose que l'archive est corrompue : il semble manquer une partie des données...
Est-ce qu'il s'agit d'une simple archive tar ou bien est-ce une archive compressée (avec compress, gzip ou bzip2) ?
Dans le premier cas (simple fichier .tar), ton fichier devrait faire un taille sensiblement équivalente à celle des données (c'est à dire 5 GO environ). Si ce n'est pas le cas, c'est bien que ton archive n'est pas complète.
S'il s'agit d'une archive compressée, tu peux essayer de décompresser le fichier (avec compress, gzip ou bzip2, suivant le format de compression) avant de le dé-tarrer : ça t'indiquera si c'est la compression ou l'archivage qui a foiré.
Quoi qu'il en soit, il y a tout de même une forte probabilité que tu ne puisses pas récupérer tes données depuis le fichier d'archive (sauf si tu as commis une erreur dans les options passées à gtar : oubli des options de de décompression alors que le fichier est compressé par exemple, mais je ne parierais pas là dessus puisque le désarchivage commence correctement). Il faut simplement espérer que tu possèdes une copie correcte du fichier à décompresser ou que tu as la possibilité de le recréer.
La commande vmstat devrait te permettre de voir l'évolution du du système avant le plantage. Lance
vmstat -n 5 >vmstat.log &
de façon à pouvoir observer, après un redémarrage ce qu'il s'est passé (pense éventuellement à purger le fichier avec "> vmstat.log" de temps en temps, puisque seule la fin devrait t'intéresser).
Bien entendu, il faut aussi que tu récupères régulièrement la liste des processus en cours d'exécution avec un "ps -ef" redirigé dans un fichier (tu peux mettre ça dans la crontab avec redirection dans un fichier). Je ne sais pas ce que tu fais avec ce serveur, mais plus de 800 processus en cours d'exécution ça me semble beaucoup !
Les données que tu fournis sont surprenantes : le load average est à plus de 300, mais le CPU ne fout rien (85% en iddle). En revanche, il y a près 1GO de swap utilisé pour 500MO de RAM, ce qui n'est pas vraiment étonnant au vu du nombre de processus.
Il faudrait également que tu regardes dans les log système (/var/log/messages et /var/log/kern.log) ce qu'il se passe juste avant le plantage : il peut il y avoir des choses intéressantes, en particulier concernant le manque de mémoire (j'ai vu des machines planter, alors qu'il restait du swap disponible, en raison d'un manque de mémoire "haute"). Tu peux également avoir des détails sur l'occupation mémoire en lisant le fichier /proc/meminfo.
Enfin, il peut aussi être intéressant d'observer les connexion réseau sur la machine avec :
netstat -tanp
Vi que la machine héberge au moins un serveur HTTP, un serveur FTP et un serveur SSH, on ne peut exclure l'attaque par déni de service ou l'exploitation d'un faille de sécurité.
Je ne suis pas un spécialiste de identd, mais voici tout de même quelque piste à utiliser :
- quelle version du démon identd utilises-tu ? Est-tu sûr que celui-ci n'est pas configuré pour renvoyer systématiquement "NO-USER" pour des raisons de sécurité ?
- lorsque tu as fait tes tests, la session TCP entre le port 80 du serveur et le port 51875 du client (apparemment la même machine) était-elle bien établie ? (la connexion HTTP a pu se fermer entre le moment où tu récupères le port local et le moment où tu interroges le d"mon identd)
- pour que la demande aboutisse, je pense que le client ident (serveur HTTP) doit se connecter depuis l'adresse IP sur laquelle est établie la connexion. Est-ce que tu n'aurais pas utilisé l'adresse de l'interface ethernet dans un cas (eth0) et localhost dans un autre ?
Pour tester tu peux essayer de faire un telnet sur un port ouvert (80 par exemple) vers localhost (telnet localhost 80) et, dans un autre terminal tu récupères le port local utilisé pour faire ta demande à inetd ("telnet localhost 113", puis tu indiques "<port local>,80).
Tu peux refaire les mêmes tests en remplaçant localhost par l'adresse IP de l'interface ethernet.
roudcube se connecte, par défaut, sur un serveur SMTP local pour l'envoi des mail (localhost:25), mais il est possible de spécifier ce que l'on veut dans un fichier de config (smtp.mon.provider ou ssl://mon.serveur.perso par exemple).
La seule restriction, il me semble, c'est que l'on ne peut pas spécifier plusieurs serveurs SMTP en fonction du compte mail utilisé (on peut indiquer plusieurs serveurs IMAP, voire autoriser la saisie libre du serveur à utiliser).
J'avais d'abord cru comprendre que SERVEUR était sur le réseau de CLIENT et qeu c'était la seule machine de ce réseau accessible de puis HOTLINER. Visiblement je me suis trompé.
La solution avec deux tunnels SSH vers SERVEUR est donc la bonne. Il ne te reste plus qu'à cacher la complexité de putty/SSH derrière une belle interface graphique et tu auras réinventé LogMeIn !
En clair les deux tunnels à réaliser, via des connexions SSH sur SERVEUR sont :
- sur HOTLINER : -L6000:localhost:10000
- sur CLIENT : -R10000:localhost:5900
Ensuite, sur hotliner on ouvre une session VNC sur localhost:6000
Il est important d'utiliser localhost (ou 127.0.0.1) car :
- le serveur VNC ne semble écouter que sur cette interface locale
- lors de l'ouverture d'un tunnel "remote", le port ouvert ne l'est que sur l'interface de loopback (sauf demande explicite et modification de la configuration par défaut du serveur SSH)
Il est vrai que mettre du "localhost" partout peut paraître déroutant, mais c'est juste un point de vue :
- dans l'option -Lport1:SERVER:port2, le paramétre SERVER est géré par le serveur SSH. Dans ce cas, localhost désigne donc le serveur SSH lui-même
- dans l'option -Rport1:SERVER:port2, le paramètre serveur est vu côté client SSH. localhost désigne alors le client SSH !
J'espère que tu y vois maintenant plus clair dans ces histoires de tunneling SSH
Pour détailler un peu les problèmes qui font que ta solution ne fonctionnait pas (en dehors de sa complexité) voici quelques éléments :
1- SERVEUR écoutait sur le port 10000 de l'interface de loopback (127.0.0.1). Pour que ça fonctionne, il faut, depuis HOTLINER, établir en tunnel entre localhost:6000 (ici localhost est HOTLINER) et localhost:10000 (et là localhost est SERVEUR !)
2- Est-ce que SERVEUR peut accéder au port 5900 de CLIENT directement ? (sinon ma solution précédente ne fonctionne pas). Comment le tunnel entre SERVEUR:10000 et CLIENT:5900 a-t-il été établi ? Est-ce bien aussi un tunnel SSH ? Est-ce qu'il est créé avec putty depuis CLIENT avec les options -R10000:localhost:5900 ? Si c'est ça, il est normal que le port 10000 soit ouvert uniquement sur l'interface lo de SERVEUR et la remarque 1 de ce post reste valable.
J'ai l'impression que tu as pas mal compliqué la question avec tes doubles tunnels...
Si j'ai bien compris, les hotliners peuvent se connecter en SSH sur le serveur SERVEUR.
Dans ce cas, depuis les hotliners, il suffit d'ouvrir une connexion SSH en forwardant le port local 10000 vers le port 5900 de CLIENT. L'option à utiliser pour OpenSSH (ou putty) est :
-L10000:CLIENT:5900
Ensuite, les hotliners doivent se connecter avec VNC sur localhost:10000 pour accéder au serveur VNC de CLIENT.
En fait le shell interprète bien les crochets et si dans le répertoire courant il existe un fichier grep, alors le shell qui va remplacer la chaîne gre[p] par grep et, à ce moment-là, les crochets ne servent plus à rien.
Oui, mais ton fichier PDF embarque les polices nécessaires à l'affichage de ces caractères, alors que le navigateur (ou les autres applications) utilisent les polices installées sur le système.
Le message que tu cites indique "no such device", un peu comme si la carte n'était pas reconnue ou le pilote non adaptée à ta carte. C'est bizarre.
Sinon, ce message indique également un module dnvidia.ko et pas nvidia.ko : s'agit-il simplement d'une erreur de transcription ?
A part ça, lorsque que je veux compiler ce driver, j'exécute pour ma part la commande :
# m-a a-i nvidia-kernel
ou alors je lance simplement "m-a" et j'utilise l'interface ncurses pour chosir le module à compiler et a installer.
Après la compilation du module, est-ce que tu as bien un paquet nvidia-kernel-*-2.6.26-* installé sur ta machine? Le fichier nvidia.ko devrait se trouver dans /lib/module/2.6.26-2-amd64/nvidia.
Sinon, si tu utilises le noyau officiel Debian, tu peux aussi ne pas compiler le pilote et installer simplement le paquet binaire qui dois être disponible dans les dépots (non-free). Il doit s'agir de nvidia-kernel-2.6-amd64 (qui dépend de la version lié à ton noyau, c'est à dire nvidia-kernel-2.6.26-2-amd64).
Oui, mais :
- comme je l'ai écrit ce type de chose (historique par utilisateur) marche parfaitement avec d'autres shells, moyennant un paramétrage spécifique par shell utilisé (je l'ai fait avec ksh sous AIX pour éviter de retrouver autre chose que mes propres commandes lorsque je remontais dans l'historique)
- dans la problématique de Tom, j'ai l'impression qu'il n'y a qu'un seul user unix utilisé par plusieurs personnes. Sauf paramétrage tordu,je pense que ces différents utilisateurs ont donc bien le même shell
Est-ce que l'adresse IP du client SSH peut te suffire pour tracer ce que tu veux ?
Si c'est le cas, tu peux arriver à tes fins simplement en jouant un peu de la configuration dans le fichier .bashrc :
- lors d'une connexion SSH, tu doit avoir les variables SSH_CLIENT et SSH_CONNECTION positionnées. Le premier mot de ces variables indique l'adresse IP du client
- pour savoir s'il s'agit d'une prière connexion (et pas d'un sous-shell), il suffit de vérifier que la variable SHLVL est égale à 1 : ça peut te servir pour faire un test dans .bashrc avant de poser tes questions au besoin
- une fois que tu as récupéré l'adresse IP ou le nom du client, tu peux créer un fichier d'historique des commandes personnalisé en attribuant une valeur à la variable HISTFILE (par exemple "export HISTFILE=~/.bash_history_$IP")
- pense à modifier la valeur de HISTFILESIZE si tu veux conserver plus de commandes que les 500 par défaut
- positionne la variable HISTTIMEFORMAT à quelque chose comme "%Y%m%d-%H%M%S " pour avoir un horodatage des commandes passées par les utilisateurs
Evidemment, ce type de chose est aussi possible avec d'autres shell comme ksh (à part peut être l'horodatage) ou zsh (avec l'option EXTENDED_HISTORY on peut même avoir la durée des commandes).
Bien sûr tout ceci suppose d'avoir une certaine confiance envers les utilisateurs concernés : rien ne les empêche de supprimer les fichiers d'historiques...
Tu expliques que tu veux pouvoir accéder en SSL à ton site, mais que ce n'est que pour ton usage perso : dans ce cas, tu peux aussi bien créer ton propre certificat auto-signé, voire créer ta propre autorité de certification pour signer tous les certificats que tu pourrais utiliser (web, smtp, imap, ...) : ça peut se faire directement avec OpenSSL ou, plus simplement, avec des front-end graphiques comme tinyCA.
Mais, ce qui me chiffonne dans ton post, c'est ta première phrase : ton site hébergé chez Free, c'est bien des pages perso avec une URL de la forme .free.fr ? (comme http://ifiction.free.fr/ par exemple). Dans ce cas comment comptes-tu t'y prendre pour y accéder en HTTPS ? Tu vas demander à Free une modification de la conf de leur serveur Apache ? ;-)
Bien sûr, j'ai peut être mal compris ton intention : dans ce cas n'hésite pas à nous donner plus de détails.
NeoX parle des 5% réservés à root par défaut : c'est vrai sur les filesystems de type ext{2,3,4}. Ici, le FS est formaté en reiserfs : il n'y a pas d'espace réservé à root. Accessoirement, il est possible de réduire ces espace réservé sur un FS ext3 en passant l'option -m <valeur_en_%> à mkfs.ext3 ou à tune2fs (sur de grosses partitions de données, cela peut être très utile).
L'explication donné par totof2000 me semble pertinente : un fichier ouvert en écriture a été supprimé. Ce fichier n'apparaît plus avec un ls ou dans le résultat du du, mais le process qui l'utilise continue d'écrire dedans. Tu peux repérer ces fichiers avec la commande :
lsof | grep -i deleted
Ceci te permettra de voir le process et son PID ainsi que la taille et el nom des fichiers supprimés mais toujours présents sur le disque.
Il sera ensuite intéressant de se demander pourquoi un, ou plusieurs, processus se sont mis à bouffer autant de place sur le disque : ça traduit certainement un problème annexe.
Je ne vais pas pouvoir être d'une grande aide concernant zeroconf, en revanche, concernant un "remplaçant" à wireshark sans interface graphique tu peux regarder du côté de tcpdump. Evidemment, l'analyse des protocoles est moins facile qu'avec wireshark, mais ça peut être rattrapé en conservant le dump du trafic réseau dans un fichier et en l'important dans wireshark sur une autre machine (lancer tcpdump avec les options "-s -w ").
Tu peux aussi utiliser tshark : c'est l'outil en ligne de commande du projet wireshark. De la même façon, il faut récupérer le fichier dump pour l'analyser avec wireshark ("tshark -w " il me semble).
Enfin, tu peux également installer wireshark sur le serveur et l'afficher sur une machine avec un serveur X (il suffit d'ouvrir une session sur ton serveur en SSH avec l'option -X, puis de lancer wireshark dans ton terminal).
# Paquets de clés
Posté par JJD . En réponse au message Les signatures suivantes ne sont pas valables. Évalué à 2.
Est-ce que tu as bien installé le paquet debian-archive-keyring de lenny ?
Dans ta liste de dépots, est qu'il y a bien cela ?
deb http://volatile.debian.org/debian-volatile lenny/volatile main contrib non-free
Dans le doute, tu peux commencer par faire une mise à jour de debian-archive-keyring, puis refaire un update.
A+
JJD
[^] # Re: Oubli.
Posté par JJD . En réponse au journal Les scrollbar de couleur sous IE c'est une histoire ancienne. Évalué à 2.
Avec une navigation au curseur (touche F7 sur la plupart des navigateurs), on arrive à trouver le lien (on peut aussi chercher dans le code source de la page).
Alors le voici : http://www.a-tixier.com/scroll003.htm (ça aurait été dommage de se priver d'un truc pareil !)
[^] # Re: Pas de problème
Posté par JJD . En réponse au message VLC et TV multiposte de Free. Évalué à 1.
En revanche, sur un autre accès ADSL Free sans Freebox (accès via un modem/routeur), mafreebox.freebox.fr est bien résolu mais pas accessible. Cela semble montrer que l'adresse (ou au moins la redirection) est gérée par la Freebox (certainement le boitier ADSL dans le cas d'une V5)..
Tu devrais essayer de rebooter ta freebox : la redirection a peut être été mise en place avec la dernière mise à jour du microcode.
A+
JJD
[^] # Re: Pas de problème
Posté par JJD . En réponse au message VLC et TV multiposte de Free. Évalué à 1.
Et tu utilises quoi comme serveurs DNS ?
Est-ce que le paramètre est récupéré automatiquement en DHCP ou bien est-ce que tu l'as indiqué manuellement ?
Pour info, mes serveurs DNS sont 212.27.40.240 et 212.27.40.241.
Est-ce que le nom mafreebox.freebox.fr est bien résolu ? (tester avec un ping par exemple).
Est-ce que un wget sur l'URL fonctionne ? :
$ wget http://mafreebox.freebox.fr/freeboxtv/playlist.m3u)
Tu peux aussi essayer avec un navigateur web quelconque.
A+
JJD
[^] # Re: redirection en SSH
Posté par JJD . En réponse au message Soucis redirection ssh (https et http). Évalué à 1.
Concernant la liste des sites devant passer par le tunnel, et comme je l'indiquai dans mon premier post, la configuration devra passer par le navigateur. Une possibilité serait d'utiliser deux navigateurs différents : un pour les besoins généraux, avec un accès direct à internet et un deuxième passant par le proxy pour l'accès aux sites de ta boite.
Sinon, avec firefox, tu peux également regarder du côté des extensions : certaines (comme foxy proxy il me semble) permettent de paramétrer assez finement (éventuellement avec des expressions régulières) les sites pour lesquels il faut passer par un proxy ou pas.
Avec Opera (mais c'est pas libre), cette possibilité doit exister en natif (préférences du site).
A+
JJD
# redirection en SSH
Posté par JJD . En réponse au message Soucis redirection ssh (https et http). Évalué à 5.
Avec SSH tu peux parfaitement utiliser plusieurs fois l'option -L pour tunneler tout ce que tu veux.
Ainsi, tu peux établir ta connexion SSH comme ça :
ssh -N -f -n -L9000:site:443 -L9001:site:80 -L9002:site2:80
et alors https://localhost:9000 te permet d'accéder à site en HTTPS (moyennant un avertissement sur le certificat SSL), http://localhost:9002 renvoie sur site2 en HTTP, etc...
Mais cette méthode a beaucoup de limitations : il faut se souvenir (noter) toutes les correspondances, les liens entres les sites ne marchent plus, ...
Il existe cependant une méthode qui pourrait répondre à tes besoins : ssh peut agir comme un proxy socks avec l'option -D. Ouvre ta connexion SSH avec :
ssh -f -N -n -Dlocalhost:1080 nom@IP
Ensuite, tu paramètres ton navigateur pour utiliser un proxy SOCKS sur localhost:1080 (éventuellement, tu peux utiliser certaines extensions de Firefox pour ne passer par ce proxy que pour les URL internes à ton entreprise).
Avec cette méthode, tu peux utiliser directement les URL qui vont bien (https://site, http://site) et tous les sites deviennent directement accessibles.
En espérant que cela correspond bien à tes besoins.
A+
JJD
[^] # Re: Archive corrompue ?
Posté par JJD . En réponse au message PB avec gtar. Évalué à 1.
tar doit lire le fichier archive de façon séquentielle (son nom signifie bien Tape ARchiver !) et le message d'erreur affiché semble indiqué un problème de corruption que tar n'arrive pas à corriger : tentative de saut à l'en-tête [de fichier] suivant, mais cet en-tête ne semble pas être trouvé.
Essaie de voir ce que donne un
tar tvf fichier.tar
Normalement ça doit te donner la liste des fichiers de l'archive, et je ne pense pas que tu réussiras récupérer plus de fichiers que ce que cette commande affichera.
Tu peux aussi essayer de voir ce que ça donne avec d'autres versions de tar (on ne ne sait jamais...)
Bon courage,
JJD
# Archive corrompue ?
Posté par JJD . En réponse au message PB avec gtar. Évalué à 1.
Apparemment, d'après le chemin de l'exécutable, tout cela se passe sous (Open) Solaris, mais ça ne doit avoir que peu d'importance.
D'après le message renvoyé par tar, je suppose que l'archive est corrompue : il semble manquer une partie des données...
Est-ce qu'il s'agit d'une simple archive tar ou bien est-ce une archive compressée (avec compress, gzip ou bzip2) ?
Dans le premier cas (simple fichier .tar), ton fichier devrait faire un taille sensiblement équivalente à celle des données (c'est à dire 5 GO environ). Si ce n'est pas le cas, c'est bien que ton archive n'est pas complète.
S'il s'agit d'une archive compressée, tu peux essayer de décompresser le fichier (avec compress, gzip ou bzip2, suivant le format de compression) avant de le dé-tarrer : ça t'indiquera si c'est la compression ou l'archivage qui a foiré.
Quoi qu'il en soit, il y a tout de même une forte probabilité que tu ne puisses pas récupérer tes données depuis le fichier d'archive (sauf si tu as commis une erreur dans les options passées à gtar : oubli des options de de décompression alors que le fichier est compressé par exemple, mais je ne parierais pas là dessus puisque le désarchivage commence correctement). Il faut simplement espérer que tu possèdes une copie correcte du fichier à décompresser ou que tu as la possibilité de le recréer.
A+
JJD
# Logs ?
Posté par JJD . En réponse au message [Debian5.0] Multiplication des processus & plantages récurrents. Évalué à 2.
La commande vmstat devrait te permettre de voir l'évolution du du système avant le plantage. Lance
vmstat -n 5 >vmstat.log &
de façon à pouvoir observer, après un redémarrage ce qu'il s'est passé (pense éventuellement à purger le fichier avec "> vmstat.log" de temps en temps, puisque seule la fin devrait t'intéresser).
Bien entendu, il faut aussi que tu récupères régulièrement la liste des processus en cours d'exécution avec un "ps -ef" redirigé dans un fichier (tu peux mettre ça dans la crontab avec redirection dans un fichier). Je ne sais pas ce que tu fais avec ce serveur, mais plus de 800 processus en cours d'exécution ça me semble beaucoup !
Les données que tu fournis sont surprenantes : le load average est à plus de 300, mais le CPU ne fout rien (85% en iddle). En revanche, il y a près 1GO de swap utilisé pour 500MO de RAM, ce qui n'est pas vraiment étonnant au vu du nombre de processus.
Il faudrait également que tu regardes dans les log système (/var/log/messages et /var/log/kern.log) ce qu'il se passe juste avant le plantage : il peut il y avoir des choses intéressantes, en particulier concernant le manque de mémoire (j'ai vu des machines planter, alors qu'il restait du swap disponible, en raison d'un manque de mémoire "haute"). Tu peux également avoir des détails sur l'occupation mémoire en lisant le fichier /proc/meminfo.
Enfin, il peut aussi être intéressant d'observer les connexion réseau sur la machine avec :
netstat -tanp
Vi que la machine héberge au moins un serveur HTTP, un serveur FTP et un serveur SSH, on ne peut exclure l'attaque par déni de service ou l'exploitation d'un faille de sécurité.
Bon courage dans tes recherches,
JJD
# Faire attention aux adresses
Posté par JJD . En réponse au message Identd : comment ça marche?. Évalué à 1.
Je ne suis pas un spécialiste de identd, mais voici tout de même quelque piste à utiliser :
- quelle version du démon identd utilises-tu ? Est-tu sûr que celui-ci n'est pas configuré pour renvoyer systématiquement "NO-USER" pour des raisons de sécurité ?
- lorsque tu as fait tes tests, la session TCP entre le port 80 du serveur et le port 51875 du client (apparemment la même machine) était-elle bien établie ? (la connexion HTTP a pu se fermer entre le moment où tu récupères le port local et le moment où tu interroges le d"mon identd)
- pour que la demande aboutisse, je pense que le client ident (serveur HTTP) doit se connecter depuis l'adresse IP sur laquelle est établie la connexion. Est-ce que tu n'aurais pas utilisé l'adresse de l'interface ethernet dans un cas (eth0) et localhost dans un autre ?
Pour tester tu peux essayer de faire un telnet sur un port ouvert (80 par exemple) vers localhost (telnet localhost 80) et, dans un autre terminal tu récupères le port local utilisé pour faire ta demande à inetd ("telnet localhost 113", puis tu indiques "<port local>,80).
Tu peux refaire les mêmes tests en remplaçant localhost par l'adresse IP de l'interface ethernet.
JJD
[^] # Re: Qui se sert encore des clients lourds ?
Posté par JJD . En réponse à la dépêche Thunderbird 3.0 est sorti. Évalué à 1.
roudcube se connecte, par défaut, sur un serveur SMTP local pour l'envoi des mail (localhost:25), mais il est possible de spécifier ce que l'on veut dans un fichier de config (smtp.mon.provider ou ssl://mon.serveur.perso par exemple).
La seule restriction, il me semble, c'est que l'on ne peut pas spécifier plusieurs serveurs SMTP en fonction du compte mail utilisé (on peut indiquer plusieurs serveurs IMAP, voire autoriser la saisie libre du serveur à utiliser).
[^] # Re: Essayons de faire simple
Posté par JJD . En réponse au message Tunnel SSH avec rebond. Évalué à 1.
La solution avec deux tunnels SSH vers SERVEUR est donc la bonne. Il ne te reste plus qu'à cacher la complexité de putty/SSH derrière une belle interface graphique et tu auras réinventé LogMeIn !
[^] # Re: Essayons de faire simple
Posté par JJD . En réponse au message Tunnel SSH avec rebond. Évalué à 2.
- sur HOTLINER : -L6000:localhost:10000
- sur CLIENT : -R10000:localhost:5900
Ensuite, sur hotliner on ouvre une session VNC sur localhost:6000
Il est important d'utiliser localhost (ou 127.0.0.1) car :
- le serveur VNC ne semble écouter que sur cette interface locale
- lors de l'ouverture d'un tunnel "remote", le port ouvert ne l'est que sur l'interface de loopback (sauf demande explicite et modification de la configuration par défaut du serveur SSH)
Il est vrai que mettre du "localhost" partout peut paraître déroutant, mais c'est juste un point de vue :
- dans l'option -Lport1:SERVER:port2, le paramétre SERVER est géré par le serveur SSH. Dans ce cas, localhost désigne donc le serveur SSH lui-même
- dans l'option -Rport1:SERVER:port2, le paramètre serveur est vu côté client SSH. localhost désigne alors le client SSH !
J'espère que tu y vois maintenant plus clair dans ces histoires de tunneling SSH
A+
JJD
[^] # Re: Essayons de faire simple
Posté par JJD . En réponse au message Tunnel SSH avec rebond. Évalué à 2.
1- SERVEUR écoutait sur le port 10000 de l'interface de loopback (127.0.0.1). Pour que ça fonctionne, il faut, depuis HOTLINER, établir en tunnel entre localhost:6000 (ici localhost est HOTLINER) et localhost:10000 (et là localhost est SERVEUR !)
2- Est-ce que SERVEUR peut accéder au port 5900 de CLIENT directement ? (sinon ma solution précédente ne fonctionne pas). Comment le tunnel entre SERVEUR:10000 et CLIENT:5900 a-t-il été établi ? Est-ce bien aussi un tunnel SSH ? Est-ce qu'il est créé avec putty depuis CLIENT avec les options -R10000:localhost:5900 ? Si c'est ça, il est normal que le port 10000 soit ouvert uniquement sur l'interface lo de SERVEUR et la remarque 1 de ce post reste valable.
# Essayons de faire simple
Posté par JJD . En réponse au message Tunnel SSH avec rebond. Évalué à 4.
J'ai l'impression que tu as pas mal compliqué la question avec tes doubles tunnels...
Si j'ai bien compris, les hotliners peuvent se connecter en SSH sur le serveur SERVEUR.
Dans ce cas, depuis les hotliners, il suffit d'ouvrir une connexion SSH en forwardant le port local 10000 vers le port 5900 de CLIENT. L'option à utiliser pour OpenSSH (ou putty) est :
-L10000:CLIENT:5900
Ensuite, les hotliners doivent se connecter avec VNC sur localhost:10000 pour accéder au serveur VNC de CLIENT.
Est-ce clair comme ça ?
A+
JJD
[^] # Re: exclure grep
Posté par JJD . En réponse au message Programmation script shell ksh unix. Évalué à 5.
En fait le shell interprète bien les crochets et si dans le répertoire courant il existe un fichier grep, alors le shell qui va remplacer la chaîne gre[p] par grep et, à ce moment-là, les crochets ne servent plus à rien.
Pour bien comprendre, voici un exemple :
$ touch grep
$ echo gre[p]
grep
$ ps -ef | grep gre[p]
toto 19592 18514 0 17:47 pts/5 00:00:00 grep grep
$ ps -ef | grep "gre[p]"
jjdoti 19625 18514 0 17:51 pts/5 00:00:00 grep gre[p]
$ rm grep
$ echo gre[p]
gre[p]
$ ps -ef | grep gre[p]
$ ps -ef | grep gre[p]
toto 19601 18514 0 17:48 pts/5 00:00:00 grep gre[p]
Moralité : il faut mettre des quottes autour du motif à passer à grep.
A+
JJD
# Look KDE pour applis gnome/gtk
Posté par JJD . En réponse au message symptomes bizarres pour un nouveau venu.... Évalué à 4.
Il me semble que pour avoir des applis gnome ou gtk en cohérence avec le thème KDE, il faut installer le paquet gtk-qt-engine.
Dis-nous si tout ça marche bien.
A+
JJD
[^] # Re: Police ? UTF-16 ?
Posté par JJD . En réponse au message il me manque des caractères unicode. Évalué à 8.
[^] # Re: ajout d'information
Posté par JJD . En réponse au message Drivers NVIDIA. Évalué à 1.
Le message que tu cites indique "no such device", un peu comme si la carte n'était pas reconnue ou le pilote non adaptée à ta carte. C'est bizarre.
Sinon, ce message indique également un module dnvidia.ko et pas nvidia.ko : s'agit-il simplement d'une erreur de transcription ?
A part ça, lorsque que je veux compiler ce driver, j'exécute pour ma part la commande :
# m-a a-i nvidia-kernel
ou alors je lance simplement "m-a" et j'utilise l'interface ncurses pour chosir le module à compiler et a installer.
Après la compilation du module, est-ce que tu as bien un paquet nvidia-kernel-*-2.6.26-* installé sur ta machine? Le fichier nvidia.ko devrait se trouver dans /lib/module/2.6.26-2-amd64/nvidia.
Sinon, si tu utilises le noyau officiel Debian, tu peux aussi ne pas compiler le pilote et installer simplement le paquet binaire qui dois être disponible dans les dépots (non-free). Il doit s'agir de nvidia-kernel-2.6-amd64 (qui dépend de la version lié à ton noyau, c'est à dire nvidia-kernel-2.6.26-2-amd64).
A+
JJD
[^] # Re: Bash, ssh et history
Posté par JJD . En réponse au message Accès SSH, récupérer ip, nom de la personne. Évalué à 1.
- comme je l'ai écrit ce type de chose (historique par utilisateur) marche parfaitement avec d'autres shells, moyennant un paramétrage spécifique par shell utilisé (je l'ai fait avec ksh sous AIX pour éviter de retrouver autre chose que mes propres commandes lorsque je remontais dans l'historique)
- dans la problématique de Tom, j'ai l'impression qu'il n'y a qu'un seul user unix utilisé par plusieurs personnes. Sauf paramétrage tordu,je pense que ces différents utilisateurs ont donc bien le même shell
# Bash, ssh et history
Posté par JJD . En réponse au message Accès SSH, récupérer ip, nom de la personne. Évalué à 2.
Est-ce que l'adresse IP du client SSH peut te suffire pour tracer ce que tu veux ?
Si c'est le cas, tu peux arriver à tes fins simplement en jouant un peu de la configuration dans le fichier .bashrc :
- lors d'une connexion SSH, tu doit avoir les variables SSH_CLIENT et SSH_CONNECTION positionnées. Le premier mot de ces variables indique l'adresse IP du client
- pour savoir s'il s'agit d'une prière connexion (et pas d'un sous-shell), il suffit de vérifier que la variable SHLVL est égale à 1 : ça peut te servir pour faire un test dans .bashrc avant de poser tes questions au besoin
- une fois que tu as récupéré l'adresse IP ou le nom du client, tu peux créer un fichier d'historique des commandes personnalisé en attribuant une valeur à la variable HISTFILE (par exemple "export HISTFILE=~/.bash_history_$IP")
- pense à modifier la valeur de HISTFILESIZE si tu veux conserver plus de commandes que les 500 par défaut
- positionne la variable HISTTIMEFORMAT à quelque chose comme "%Y%m%d-%H%M%S " pour avoir un horodatage des commandes passées par les utilisateurs
Evidemment, ce type de chose est aussi possible avec d'autres shell comme ksh (à part peut être l'horodatage) ou zsh (avec l'option EXTENDED_HISTORY on peut même avoir la durée des commandes).
Bien sûr tout ceci suppose d'avoir une certaine confiance envers les utilisateurs concernés : rien ne les empêche de supprimer les fichiers d'historiques...
J'espère que tout cela pourra t'aider.
A+
JJD
# SSL ?
Posté par JJD . En réponse au message certificats SSL gratuits. Évalué à 8.
Tu expliques que tu veux pouvoir accéder en SSL à ton site, mais que ce n'est que pour ton usage perso : dans ce cas, tu peux aussi bien créer ton propre certificat auto-signé, voire créer ta propre autorité de certification pour signer tous les certificats que tu pourrais utiliser (web, smtp, imap, ...) : ça peut se faire directement avec OpenSSL ou, plus simplement, avec des front-end graphiques comme tinyCA.
Mais, ce qui me chiffonne dans ton post, c'est ta première phrase : ton site hébergé chez Free, c'est bien des pages perso avec une URL de la forme .free.fr ? (comme http://ifiction.free.fr/ par exemple). Dans ce cas comment comptes-tu t'y prendre pour y accéder en HTTPS ? Tu vas demander à Free une modification de la conf de leur serveur Apache ? ;-)
Bien sûr, j'ai peut être mal compris ton intention : dans ce cas n'hésite pas à nous donner plus de détails.
A+
JJD
[^] # Re: un classique ...
Posté par JJD . En réponse au message Où es passé l'espace libre sur ma partition?. Évalué à 2.
Je vais rebondir sur les remarques précédentes...
NeoX parle des 5% réservés à root par défaut : c'est vrai sur les filesystems de type ext{2,3,4}. Ici, le FS est formaté en reiserfs : il n'y a pas d'espace réservé à root. Accessoirement, il est possible de réduire ces espace réservé sur un FS ext3 en passant l'option -m <valeur_en_%> à mkfs.ext3 ou à tune2fs (sur de grosses partitions de données, cela peut être très utile).
L'explication donné par totof2000 me semble pertinente : un fichier ouvert en écriture a été supprimé. Ce fichier n'apparaît plus avec un ls ou dans le résultat du du, mais le process qui l'utilise continue d'écrire dedans. Tu peux repérer ces fichiers avec la commande :
lsof | grep -i deleted
Ceci te permettra de voir le process et son PID ainsi que la taille et el nom des fichiers supprimés mais toujours présents sur le disque.
Il sera ensuite intéressant de se demander pourquoi un, ou plusieurs, processus se sont mis à bouffer autant de place sur le disque : ça traduit certainement un problème annexe.
A+
JJD
# Fichier d'initialisation du shell
Posté par JJD . En réponse au message Conserver un terminal actif après l'exécution d'une commande. Évalué à 2.
Tu peux essayer de créer un fichier .bashrc2 contenant quelque chose du genre :
/bin/ls
. ~/.bashrc
et créer un profil "ls" pour gnome-terminal avec la commande personnalisée suivante :
/bin/bash --rcfile ~/.bashrc2
Ensuite, tu lances
gnome-terminal --window-with-profile=ls
et ça devrait faire à peu près ce que tu veux.
je n'ai pas trouvé d'autres solutions plus directe.
A+
JJD
# wireshark
Posté par JJD . En réponse au message Problème avec avahi. Évalué à 1.
Je ne vais pas pouvoir être d'une grande aide concernant zeroconf, en revanche, concernant un "remplaçant" à wireshark sans interface graphique tu peux regarder du côté de tcpdump. Evidemment, l'analyse des protocoles est moins facile qu'avec wireshark, mais ça peut être rattrapé en conservant le dump du trafic réseau dans un fichier et en l'important dans wireshark sur une autre machine (lancer tcpdump avec les options "-s -w ").
Tu peux aussi utiliser tshark : c'est l'outil en ligne de commande du projet wireshark. De la même façon, il faut récupérer le fichier dump pour l'analyser avec wireshark ("tshark -w " il me semble).
Enfin, tu peux également installer wireshark sur le serveur et l'afficher sur une machine avec un serveur X (il suffit d'ouvrir une session sur ton serveur en SSH avec l'option -X, puis de lancer wireshark dans ton terminal).
En espérant que cela t'aide,
JJD