Laurent Léonard a écrit 63 commentaires

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...

Effectivement... La sortie de Etch devrait arranger les choses... Merci. :)

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...

Tu peux aussi faire un apt-get clean afin de nettoyer le référentiel (cache) des paquets récupérés par apt...

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.

Pour info, la page man de who (concernant le path des fichiers utmp et wtmp) a été mise à jour dans Etch.

Bien vu !

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... :(

J'ai posté mon message peu après la déconnexion, quelques heures tout au plus...

2 choses dont on parle sur le lien et que je n'avais pas regardé...

brusselsserver:~# ps -fe | grep 'pts/1'
root 4037 3528 0 02:45 pts/0 00:00:00 grep pts/1
brusselsserver:~# ps -fe | grep bash
root 3528 3525 0 Feb03 pts/0 00:00:00 -bash
root 4039 3528 0 02:45 pts/0 00:00:00 grep bash

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...

Tu as tout compris ! lol

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 :(

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

Plutôt troublant non ?

Je viens de le tester et il est effectivement aussi simple à utiliser qu'efficace, c'est exactement ce que je cherchais. Merci à toi !

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 ?

Je suppose que tu veux parler de ce script : http://www.garloff.de/kurt/linux/scsidev/, j'ai trouvé le paquet scsiadd sur l'apt qui semble être assez similaire.

Enfin soit, voici la sortie de celui-ci :

Trash-workstation:/home/trash/Desktop# ./rescan-scsi-bus.sh
Host adapter 0 (sata_sil24) found.
Host adapter 1 (sata_sil24) found.
Host adapter 2 (sata_nv) found.
Host adapter 3 (sata_nv) found.
Host adapter 4 (sata_nv) found.
Host adapter 5 (sata_nv) found.
Scanning hosts 0 1 2 3 4 5 channels 0 for
SCSI target IDs 0 1 2 3 4 5 6 7 , LUNs 0
Scanning for device 0 0 0 0 ...
OLD: Host: scsi0 Channel: 00 Id: 00 Lun: 00
Vendor: ATA Model: GIGABYTE i-RAM Rev: v0.9
Type: Direct-Access ANSI SCSI revision: 05
Scanning for device 2 0 0 0 ...
OLD: Host: scsi2 Channel: 00 Id: 00 Lun: 00
Vendor: ATA Model: Hitachi HDT72503 Rev: V54O
Type: Direct-Access ANSI SCSI revision: 05
Scanning for device 3 0 0 0 ...
OLD: Host: scsi3 Channel: 00 Id: 00 Lun: 00
Vendor: ATA Model: Hitachi HDT72503 Rev: V54O
Type: Direct-Access ANSI SCSI revision: 05
Scanning for device 4 0 0 0 ...
OLD: Host: scsi4 Channel: 00 Id: 00 Lun: 00
Vendor: ATA Model: Hitachi HDT72503 Rev: V54O
Type: Direct-Access ANSI SCSI revision: 05
Scanning for device 5 0 0 0 ...
OLD: Host: scsi5 Channel: 00 Id: 00 Lun: 00
Vendor: ATA Model: Hitachi HDT72503 Rev: V54O
Type: Direct-Access ANSI SCSI revision: 05
0 new device(s) found.
0 device(s) removed.

Mais aucune trace de mon disque dur externe ?

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... :/

Merci pour ces infos !

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 ?