On dirait que ça fonctionne même sans donner de partie "bind address" dans l'argument de l'option -R... Apparemment c'est l'option GatewayPorts qu'il me manquait. Merci pour l'info !
Imaginons que sur mon serveur situé à l'école et inaccessible de l'extérieur, j'ouvre une connexion SSH vers un serveur B, possédant une adresse IP fixe (afin d'éviter les coupures de connexion dues au changement d'adresse IP avec une DNS dynamique). Je lance donc ceci sur le serveur A : ssh -R 20000:localhost:20 monserveurB
Si je me connecte en SSH sur mon serveur B, je peux me connecter au tunnel en faisant : ssh localhost -p 20000
Cependant, depuis mon poste de travail à la maison, impossible de me connecter à monserveurB sur le port 20000, on dirait que ssh n'écoute que localement et le tunnel est donc inaccessible de l'extérieur... Quelqu'un a-t-il une solution à ce problème ?
Effectivement, je viens d'expérimenter le problème du port 22 occupé par le serveur SSH. Ca marche impeccablement maintenant, merci beaucoup à vous 2 !
Je n'ai que des droits très restreints sur la seule machine qui ait une connexion Internet, impossible donc d'y mettre un serveur web...
Un proxy est en place sur cette machine autorisant l'accès à un nombre très restreint de sites web (en gros le site de Microsoft et celui de l'école... )... Impossible non plus donc d'utiliser PHProxy...
Merci, mais je suis déjà tombé dessus lors de ma recherche et j'ai passé mon chemin, ne disposant pas d'un serveur web sur la machine en question... C'est pour ça que je m'oriente plutôt vers un script en Perl...
J'ai tenté de le lancer en démon avec svnserve -d -r /usr/local/svn/, ça fonctionne mais ça m'a l'air encore plus lent... Au moins 5 secondes pour ouvrir un dossier avec kdesvn...
La solution la plus efficace serait de passer en revue les paquets de ton système, sur une install minimale ce n'est pas si fastidieux.
dpkg -l | grep "^ii a" dpkg -l | grep "^ii b"
... Et tu check jusque z les paquets dont tu n'as pas besoin... Quand tu trouves des paquets que tu penses inutiles, un petit apt-get remove --purge PAQUETS_INUTILES et si le paquet en question est une dépendance nécessaire, apt te le dira bien...
Quand tu as fini, fais un apt-get install deborphan suivi d'un apt-get remove --purge `deborphan --guess-all` afin de désinstaller les dépendances restantes devenues inutiles...
Un dpkg -l | grep ^rc te donnera la liste de tous les paquets précédemment installés mais actuellement absents de ton système, mais dont il persiste encore des ficheirs de configuration (qui prennent de la place inutilement, c'est toujours ça de gagné). Un dpkg --purge PAQUETS supprimera les fichiers en question.
Last parcourt le fichier /var/log/wtmp (ou le fichier indiqué par l'option -f) pour présenter une liste de toutes les connexions et déconnexions
des utilisateurs, depuis la création du fichier.
Extrait de la page man de last.
La page man de who n'a peut-être pas été adaptée ? J'ai vu qu'il existait un fichier d'en-tête utmp.h, utmp est apparemment un fichier binaire comprenant des enregistrements de structures C. Je suppose qu'une modification de ce fichier arrangera mon problème...
Sur un site parlant du "comportement de hackers", j'ai trouvé ces 3 références :
* ZAP (or ZAP2) : remplacement de la dernière donnée de connexion par des zéros
* Peu efficace car le CERT distribue des programmes vérifiant les données à zéro. CLOAK2 : modification des données
* CLEAR : effacement des données
Mais je n'ai pas cherché plus loin étant le seul utilisateur possédant un shell sur la machine, un bête echo -n > /var/run/utmp suivi d'une reconnexion de ma session courante semble avoir résolu mon problème. Merci gatosek pour la piste.
Si un argument est fourni qui ne soit pas une option, who l'utilise à la place de /etc/utmp comme nom de fichier contenant les enregistrements
des connexions. /etc/wtmp est souvent utilisé comme argument lors de l'appel de who pour voir qui s'est connecté précédemment.
Extrait de la page man de who... Mais il n'y a pas de fichier /etc/utmp sous Debian (j'ai checké sur plusieurs machines), et je n'ai pas trouvé d'équivalent... :(
Je viens de jeter un oeil et visiblement le pseudo-terminal ne s'est pas fermé tout seul depuis... Ce qui est bizarre, c'est que j'étais connecté par SSH sur un autre serveur en même temps, et sur celui-ci la connexion s'est tuée toute seule... Peut-être parce que je n'étais pas en train de travailler dessus ?
J'ai redémarré sshd mais ça ne change rien, de toute façon les connexions SSH sont gérées par des processus distincts du démon, et je ne vois tourner que le démon SSH et le processus de ma connexion courante...
C'est une des premières choses qui m'est venue à l'idée mais...
brusselsserver:~# who -Hu
NOM LIGNE HEURE OSIF PID COMMENTAIRE
root pts/0 Feb 3 14:22 . 3528 (213.219.187.196.adsl.dyn.edpnet.net)
root pts/1 Feb 2 23:58 ? 28458 (213.219.187.196.adsl.dyn.edpnet.net)
brusselsserver:~# kill -9 28458
-bash: kill: (28458) - Aucun processus de ce type
Des fois je me donnerais des claques, le firewire était tout simplement désactivé dans les paramètres de mon BIOS... :/ Ca fonctionne impeccablement maintenant, merci.
Ce qui m'étonne beaucoup, c'est que lspci ne renvoie rien à propos du firewire... Pourtant ma carte mère est une MSI P4N Diamond, il y a donc nativement du firewire 400... Quelqu'un pourrait-il m'éclairer ?
Lorsque je réouvre mon portable, l'écran reste noir et le clavier est inactif, bien que le système soit toujours up (comme expliqué plus haut avec le teste de lecture de MP3 avec Kaffeine).
J'ai déjà installé 915resolution afin de permettre à Xorg d'utiliser une résolution de 1280x800, et cela fonctionne très bien.
J'avoue que je n'ai pas trop envie d'installer 1500 paquets Debian pour en avoir 900 d'inutiles sur ma machine, j'ai l'habitude de savoir exactement ce qui est installé sur mes machines et d'installer les paquets à la main en fonction de mes besoins... ;) Je vais pousser ma recherche de ce côté-là en tout cas !
Je viens de faire un test assez simple pour être sûr que le système ne se met pas en veille à la fermeture du couvercle... J'ai lancé un MP3, puis refermé le couvercle, on l'entend toujours. Je le réouvre, on l'entend toujours. Mais l'écran reste noir et impossible de fermer Kaffeine avec un bête Alt-F4. J'en déduis donc que quelque chose désactive l'écran et le clavier au moment de la fermeture du couvercle. Serait-ce quelque chose de hardware qui ferait ça ?
Justement il n'y a pas de mise en veille puisque j'ai testé sans acpid... Normalement il y a juste une extinction hardware de l'écran et quand on rouvre rien ne devrait avoir bouger... En tout cas c'est comme ça sur mon FJ P7010...
Tout ce que je vois d'étrange dans les logs, je l'ai marqué dans mon premier post... Le serveur vient de me refaire une 3ème fois la même chose et je retrouve les mêmes 4 dernières lignes dans le log d'erreur...
Voici la liste des paquets installés :
ii apache2 2.0.54-5sarge1 next generation, scalable, extendable web se
ii apache2-common 2.0.54-5sarge1 next generation, scalable, extendable web se
ii apache2-mpm-pr 2.0.54-5sarge1 traditional model for Apache2
ii apache2-utils 2.0.54-5sarge1 utility programs for webservers
ii libapache2-mod 5.2.0-0.dotdeb server-side, HTML-embedded scripting languag
ii webmin-apache 1.180-3 apache control module for webmin
Le processus tourne toujours... Si je check son existence je ne verrai pas le problème...
Visiblement Apache écoute toujours sur le bon port, sauf que qd on fait une demande à l'aide d'un navigateur, on attend indéfiniment pour finalement n'aboutir à rien...
Je me vois mal faire une tâche cron avec un wget pour checker si je dois relancer Apache... :/
Mais j'aurais une petite question à propos de la situation que tu décris. Tu parles donc de garder /dev en local, ce qui est le plus logique évidement. J'imagine donc que tu vas créer une partition et un point de montage pour /dev. Mais le système aura besoin de /dev/console pour pouvoir booter, avant de monter /dev (c'est le problème auquel j'ai été confronté alors que je bootais sur une racine distante via NFS)...
Ou alors as-tu pris le problème à l'envers, boot en local sur / et montage des autres partitions par NFS ?
[^] # Re: un tunel ssh
Posté par Laurent Léonard (site web personnel) . En réponse au message Connexion SSH sans routage. Évalué à 1.
[^] # Re: un tunel ssh
Posté par Laurent Léonard (site web personnel) . En réponse au message Connexion SSH sans routage. Évalué à 1.
Si je me connecte en SSH sur mon serveur B, je peux me connecter au tunnel en faisant : ssh localhost -p 20000
Cependant, depuis mon poste de travail à la maison, impossible de me connecter à monserveurB sur le port 20000, on dirait que ssh n'écoute que localement et le tunnel est donc inaccessible de l'extérieur... Quelqu'un a-t-il une solution à ce problème ?
[^] # Re: un tunel ssh
Posté par Laurent Léonard (site web personnel) . En réponse au message Connexion SSH sans routage. Évalué à 1.
[^] # Re: phproxy
Posté par Laurent Léonard (site web personnel) . En réponse au message Mini Proxy HTTP. Évalué à 1.
Un proxy est en place sur cette machine autorisant l'accès à un nombre très restreint de sites web (en gros le site de Microsoft et celui de l'école... )... Impossible non plus donc d'utiliser PHProxy...
[^] # Re: phproxy
Posté par Laurent Léonard (site web personnel) . En réponse au message Mini Proxy HTTP. Évalué à 1.
[^] # Re: Démon
Posté par Laurent Léonard (site web personnel) . En réponse au message Serveur subversion lent avec inetd/xinetd sous Debian Sarge. Évalué à 1.
# Démon
Posté par Laurent Léonard (site web personnel) . En réponse au message Serveur subversion lent avec inetd/xinetd sous Debian Sarge. Évalué à 1.
[^] # Re: ...
Posté par Laurent Léonard (site web personnel) . En réponse au message installation minimale pour lire des mp3. Évalué à 1.
[^] # Re: ...
Posté par Laurent Léonard (site web personnel) . En réponse au message installation minimale pour lire des mp3. Évalué à 1.
dpkg -l | grep "^ii a"
dpkg -l | grep "^ii b"
... Et tu check jusque z les paquets dont tu n'as pas besoin... Quand tu trouves des paquets que tu penses inutiles, un petit apt-get remove --purge PAQUETS_INUTILES et si le paquet en question est une dépendance nécessaire, apt te le dira bien...
Quand tu as fini, fais un apt-get install deborphan suivi d'un apt-get remove --purge `deborphan --guess-all` afin de désinstaller les dépendances restantes devenues inutiles...
Un dpkg -l | grep ^rc te donnera la liste de tous les paquets précédemment installés mais actuellement absents de ton système, mais dont il persiste encore des ficheirs de configuration (qui prennent de la place inutilement, c'est toujours ça de gagné). Un dpkg --purge PAQUETS supprimera les fichiers en question.
[^] # Re: pid
Posté par Laurent Léonard (site web personnel) . En réponse au message Pseudo-terminal fantôme. Évalué à 1.
[^] # Re: pid
Posté par Laurent Léonard (site web personnel) . En réponse au message Pseudo-terminal fantôme. Évalué à 1.
Extrait de la page man de last.
La page man de who n'a peut-être pas été adaptée ? J'ai vu qu'il existait un fichier d'en-tête utmp.h, utmp est apparemment un fichier binaire comprenant des enregistrements de structures C. Je suppose qu'une modification de ce fichier arrangera mon problème...
Sur un site parlant du "comportement de hackers", j'ai trouvé ces 3 références :
* ZAP (or ZAP2) : remplacement de la dernière donnée de connexion par des zéros
* Peu efficace car le CERT distribue des programmes vérifiant les données à zéro. CLOAK2 : modification des données
* CLEAR : effacement des données
Mais je n'ai pas cherché plus loin étant le seul utilisateur possédant un shell sur la machine, un bête echo -n > /var/run/utmp suivi d'une reconnexion de ma session courante semble avoir résolu mon problème. Merci gatosek pour la piste.
[^] # Re: pid
Posté par Laurent Léonard (site web personnel) . En réponse au message Pseudo-terminal fantôme. Évalué à 1.
Extrait de la page man de who... Mais il n'y a pas de fichier /etc/utmp sous Debian (j'ai checké sur plusieurs machines), et je n'ai pas trouvé d'équivalent... :(
[^] # Re: pid
Posté par Laurent Léonard (site web personnel) . En réponse au message Pseudo-terminal fantôme. Évalué à 1.
2 choses dont on parle sur le lien et que je n'avais pas regardé...
Mais cela ne fait que montrer qu'il n'y a aucun processus qui tourne pour ce pseudo-terminal, qui n'existe même pas lui-même d'ailleurs...
[^] # Re: pid
Posté par Laurent Léonard (site web personnel) . En réponse au message Pseudo-terminal fantôme. Évalué à 2.
Je viens de jeter un oeil et visiblement le pseudo-terminal ne s'est pas fermé tout seul depuis... Ce qui est bizarre, c'est que j'étais connecté par SSH sur un autre serveur en même temps, et sur celui-ci la connexion s'est tuée toute seule... Peut-être parce que je n'étais pas en train de travailler dessus ?
J'ai redémarré sshd mais ça ne change rien, de toute façon les connexions SSH sont gérées par des processus distincts du démon, et je ne vois tourner que le démon SSH et le processus de ma connexion courante...
Snif :(
[^] # Re: pid
Posté par Laurent Léonard (site web personnel) . En réponse au message Pseudo-terminal fantôme. Évalué à 1.
Plutôt troublant non ?
[^] # Re: Wondershaper
Posté par Laurent Léonard (site web personnel) . En réponse au message Shaper (QoS). Évalué à 1.
[^] # Re: rescan-scsi-bus
Posté par Laurent Léonard (site web personnel) . En réponse au message Disque dur externe firewire 400. Évalué à 1.
[^] # Re: rescan-scsi-bus
Posté par Laurent Léonard (site web personnel) . En réponse au message Disque dur externe firewire 400. Évalué à 1.
[^] # Re: rescan-scsi-bus
Posté par Laurent Léonard (site web personnel) . En réponse au message Disque dur externe firewire 400. Évalué à 1.
Enfin soit, voici la sortie de celui-ci :
Mais aucune trace de mon disque dur externe ?
[^] # Re: 915resolution
Posté par Laurent Léonard (site web personnel) . En réponse au message Inspiron 630m, problème lors de la réouverture du capot. Évalué à 1.
J'ai déjà installé 915resolution afin de permettre à Xorg d'utiliser une résolution de 1280x800, et cela fonctionne très bien.
J'avoue que je n'ai pas trop envie d'installer 1500 paquets Debian pour en avoir 900 d'inutiles sur ma machine, j'ai l'habitude de savoir exactement ce qui est installé sur mes machines et d'installer les paquets à la main en fonction de mes besoins... ;) Je vais pousser ma recherche de ce côté-là en tout cas !
[^] # Re: driver video et option au chargement...
Posté par Laurent Léonard (site web personnel) . En réponse au message Inspiron 630m, problème lors de la réouverture du capot. Évalué à 1.
[^] # Re: driver video et option au chargement...
Posté par Laurent Léonard (site web personnel) . En réponse au message Inspiron 630m, problème lors de la réouverture du capot. Évalué à 1.
[^] # Re: Moteur utilisé
Posté par Laurent Léonard (site web personnel) . En réponse au message Arrêt d'écoute de Apache 2 sous Debian Sarge ?. Évalué à 1.
Voici la liste des paquets installés :
ii apache2 2.0.54-5sarge1 next generation, scalable, extendable web se
ii apache2-common 2.0.54-5sarge1 next generation, scalable, extendable web se
ii apache2-mpm-pr 2.0.54-5sarge1 traditional model for Apache2
ii apache2-utils 2.0.54-5sarge1 utility programs for webservers
ii libapache2-mod 5.2.0-0.dotdeb server-side, HTML-embedded scripting languag
ii webmin-apache 1.180-3 apache control module for webmin
[^] # Re: Trop de requêtes ?
Posté par Laurent Léonard (site web personnel) . En réponse au message Arrêt d'écoute de Apache 2 sous Debian Sarge ?. Évalué à 1.
Visiblement Apache écoute toujours sur le bon port, sauf que qd on fait une demande à l'aide d'un navigateur, on attend indéfiniment pour finalement n'aboutir à rien...
Je me vois mal faire une tâche cron avec un wget pour checker si je dois relancer Apache... :/
[^] # Re: Quelques petites infos :-)
Posté par Laurent Léonard (site web personnel) . En réponse au message Boot de plusieurs clients sur un serveur NFS. Évalué à 1.
Mais j'aurais une petite question à propos de la situation que tu décris. Tu parles donc de garder /dev en local, ce qui est le plus logique évidement. J'imagine donc que tu vas créer une partition et un point de montage pour /dev. Mais le système aura besoin de /dev/console pour pouvoir booter, avant de monter /dev (c'est le problème auquel j'ai été confronté alors que je bootais sur une racine distante via NFS)...
Ou alors as-tu pris le problème à l'envers, boot en local sur / et montage des autres partitions par NFS ?