OVH Cloud OVH Cloud

telnet localhost failed

40 réponses
Avatar
Claude
bonsoir,

impossible de faire un telnet de localhost ou 127.0.0.1, que ce soit en root
on non. pourtant /etc/hosts est à jour.

merci de vos reponses
Claude

10 réponses

1 2 3 4
Avatar
Annie D.
no_spam wrote:

Il faut faire telnet localhost 901
pour se connecter sur le port 901...
Sinon, telnet essaye de se connecter sur le port 23, par défaut.
Et s'il n'y a pas de service telnet d'installé, ça ne répond pas.
En fait, il ne faut pas confondre le service telnet et le protocole
telnet.


Je lui ai déjà dit, mais apparemment il a du mal.

Beaucoup de services sont basés sur le protocole telnet, en gros, tous
les services qui échangent des données en ASCII: ftp, http, nntp, smtp,


Non, ces services ne sont pas basés sur le protocole telnet mais sur une
communication en texte brut alors que le protocole telnet inclut bien
d'autres choses (négociation client-serveur, envoi de paramètres,
commandes...). On n'a pas besoin d'un client telnet pour dialoguer avec
ces services, un client TCP simple comme netcat (nc) suffit.

Ce qui explique qu'on puisse joindre ces services avec un client telnet.


Non, cela s'explique parce que les clients telnet peuvent aussi
fonctionner en texte brut sans faire de négociation telnet.

Avatar
Annie D.
Claude wrote:

$ telnet localhost 901


mais, sauf votre respect, on boucle: mon pb initial, c'est telnet localhost
qui ne marche pas.... a fortiori, sur le port 901, j'ai peu d'espoir.


Ben non, justement : les deux n'ont rien à voir. Avez-vous essayé ?
Sans numéro de port ou nom de service équivalent (cf. /etc/services),
telnet cherche implicitement à se connecter au port TCP 23 (telnet) de
la destination. Qu'aucun service n'écoute sur ce port ne présume
absolument pas que d'autres services soient à l'écoute sur d'autres
ports. Pour voir la liste des ports TCP ouverts en écoute sur votre
machine sous forme numérique :

$ netstat -tln


Avatar
no_spam
On Sat, 08 May 2004 19:23:57 +0200, Annie D. wrote:

no_spam wrote:

Il faut faire telnet localhost 901
pour se connecter sur le port 901...
Sinon, telnet essaye de se connecter sur le port 23, par défaut.
Et s'il n'y a pas de service telnet d'installé, ça ne répond pas.
En fait, il ne faut pas confondre le service telnet et le protocole
telnet.


Je lui ai déjà dit, mais apparemment il a du mal.

Beaucoup de services sont basés sur le protocole telnet, en gros, tous
les services qui échangent des données en ASCII: ftp, http, nntp, smtp,


Non, ces services ne sont pas basés sur le protocole telnet mais sur une
communication en texte brut alors que le protocole telnet inclut bien
d'autres choses (négociation client-serveur, envoi de paramètres,
commandes...). On n'a pas besoin d'un client telnet pour dialoguer avec
ces services, un client TCP simple comme netcat (nc) suffit.


OK, c'est vrai, pas tous (notement pas le HTTP), je me suis un peu
emporté...
Mais les protocoles "historiques" se basent dessus:
(il date de 1971 et est un standard depuis bien longtemps: au moins 1983...).

RFC0959 (FTP):
"
File Transfer Protocol

control connection

The communication path between the USER-PI and SERVER-PI for
the exchange of commands and replies. This connection follows
the Telnet Protocol.
"

Le protocole telnet permet d'envoyer, en plus des séquences ASCII, des
séquence "out-of-band" de controle de la connection et définit le
terminal virtuel à chaque bout de la ligne.


Ce qui explique qu'on puisse joindre ces services avec un client telnet.


Non, cela s'explique parce que les clients telnet peuvent aussi
fonctionner en texte brut sans faire de négociation telnet.


Ce que tu appelles la négociation telnet ne fait pas partie du protocole
telnet, mais du service telnet....
Le protocole telnet définit juste comment le client et le serveur
s'échangent des données, les séquences de controles du terminal et de
la liaison. Voir la RFC854.
Il spécifie, en plus, que le port 23 est utilisé pour le login distant:
" Port Assignment

When used for remote user access to service hosts (i.e., remote
terminal access) this protocol is assigned server port 23
(27 octal). That is L#.
"
Le "When used" signifie bien que c'est une des utilisations du protocole
et pas son but premier...


Avatar
Claude
"Annie D." a écrit dans le message de
news:


Cela ne vous dira rien sur le demon telnet en particulier mais comment
déclarer manuellement un démon lancé par xinetd. Logiquement, vous ne
devriez même pas avoir à vous y frotter, la procédure d'installation du
paquetage devrait s'en charger automatiquement.


exact. après avoir installé telnet, je trouve telnetd ds /usr/sbin et telnet
ds /etc/xinetd.d.
je me prenais alors à croire que j'étais au bout de mes peines. que nenni !!
après avoir redémarré, et bien que ds le service telnet, disable = no,
un ps-ef | grep telnetd me fut fatal: aucune réponse.
je pensais naivement, qu'en redemarrant, xinetd ferai son taf et lancerait
ce satané démon...
ben, il semble que non! faut il donc le demarrer à la main ? $ telnetd start
?

Par curiosité, à quoi va vous servir un serveur telnet si vous ne
comptez pas le rendre accessible de l'extérieur de la machine ?


j'ai besoin de telnet"er" localhost:901 pour utiliser swat sous samba.


Alors vous n'avez pas besoin de serveur telnet, qui écoute sur le port
TCP 23. Vous avez confondu le protocole telnet avec le programme telnet
qui peut servir à se connecter à d'autres services que telnet pourvu
qu'ils soient en mode texte. Si le service qui écoute sur le port TCP
901 (swat) est installé, ce que vous pouvez vérifier avec la commande
suivante :

$ netstat -tl | grep swat

ou

$ netstat -tln | grep 901

réponse idem: nothing, comme si swat n'etait pas démarré!!

et telnet localhost:901 : même punition, of course !

d'où la question existentielle incontournable et cruelle: suis je vraiment
fait pour linux ??

merci de votre patience

Claude



Avatar
Schott
On Sat, 08 May 2004 18:20:48 +0200, Claude wrote:

mais, sauf votre respect, on boucle: mon pb initial, c'est telnet localhost
qui ne marche pas.... a fortiori, sur le port 901, j'ai peu d'espoir.
merci toutefois de vos judicieuses explications sur telnet .


On va résumer un peu les diverses réponses qui ont été faites pour
t'aider à t'y retrouver.

Tu souhaites te connecter à swat sur le port 901 par telnet.

Pour cela tu n'as pas besoin d'un serveur telnet, c'est swat qui doit
être à l'écoute sur ce port.

Donc, on arrive à swat est-il installé? Est-il lancé?

Par ailleurs, swat fournit une interface en http, il me semble qu'un
client http (un navigateur, quoi) me semble plus approprié. Le fait de se
connecter à swat par telnet peut servir à diagnostiquer le bon
fonctionnement de la chaîne de connexion, mais pour gérer tes services
samba via swat par telnet, bon courage !

Tshaw
Schott
FLLC Canal hystérique

Avatar
Claude
"Schott" a écrit dans le message de
news:
On Sat, 08 May 2004 18:20:48 +0200, Claude wrote:

mais, sauf votre respect, on boucle: mon pb initial, c'est telnet
localhost


qui ne marche pas.... a fortiori, sur le port 901, j'ai peu d'espoir.
merci toutefois de vos judicieuses explications sur telnet .


On va résumer un peu les diverses réponses qui ont été faites pour
t'aider à t'y retrouver.


initiative heureuse et sage.

Tu souhaites te connecter à swat sur le port 901 par telnet.


je voulais faire ce test avec telnet. je sais que peux aussi y accéder en
http sur localhost:901, mais ça ne marche pas.

Pour cela tu n'as pas besoin d'un serveur telnet, c'est swat qui doit
être à l'écoute sur ce port.

malheureusement, netstat -tln | grep swat ne donne rien


Donc, on arrive à swat est-il installé? Est-il lancé?


oui, il est installé. lancé? apparemment non. je pensais que c'etait le
travail de xinetd


Par ailleurs, je persiste mordicus à vouloir que telnet localhost marche.

mais, comme je l'ai appris ce soir, cela concerne le démon telnetd et
n'entre pas ds la problématique ci-dessus. donc, on verra plus tard.

merci de ton aide
Claude


Avatar
Schott
On Sat, 08 May 2004 22:28:42 +0200, Claude wrote:

oui, il est installé. lancé? apparemment non. je pensais que c'etait le
travail de xinetd


Extrait du man:
xinetd fournit les même fonctionalités que inetd : il démarre les
programmes fournissant des services Internet. Au lieu de démarrer ces
services au moment de l'initialisation du système, et de les laisser
inactifs jusqu'à ce qu'il y ait une demande de connexion, on ne démarre
que xinetd et celui ci écoute sur tous les ports nécessaires aux
services listés dans ses fichiers de configuration. Lorsqu'une requête
arrive, xinetd démarre le service correspondant. À cause de la façon
dont il fonctionne, xinetd (comme inetd) est aussi appelé le
super-serveur.

en clair, il est normal que tu ne voies pas les processes des démons tant
qu'il n'y a pas de connexion ouverte sur les services.

Je te suggère la lecture de la donc d'xinted, tu dois avoir un problème
de conf de ce superserveur, notamment au niveau de swat et telnetd.

Tshaw
Schott
RTFM is not an acronym: it's the law!

Avatar
Claude
"Schott" a écrit dans le message de
news:
On Sat, 08 May 2004 22:28:42 +0200, Claude wrote:

oui, il est installé. lancé? apparemment non. je pensais que c'etait le
travail de xinetd


Extrait du man:
xinetd fournit les même fonctionalités que inetd : il démarre les
programmes fournissant des services Internet. Au lieu de démarrer ces
services au moment de l'initialisation du système, et de les laisser
inactifs jusqu'à ce qu'il y ait une demande de connexion, on ne démarre
que xinetd et celui ci écoute sur tous les ports nécessaires aux
services listés dans ses fichiers de configuration. Lorsqu'une requête
arrive, xinetd démarre le service correspondant. À cause de la façon
dont il fonctionne, xinetd (comme inetd) est aussi appelé le
super-serveur.

en clair, il est normal que tu ne voies pas les processes des démons tant
qu'il n'y a pas de connexion ouverte sur les services.

Je te suggère la lecture de la donc d'xinted, tu dois avoir un problème
de conf de ce superserveur, notamment au niveau de swat et telnetd.

Tshaw
Schott
RTFM is not an acronym: it's the law!


je vais consacrer mon dimanche à cette redoutable lecture...

derniére question pour ce soir: comment fait on pour desinstaller un
logiciel ? je voudrais desinstaller samba car les fichiers ne semblent pas
installés au bon endroit. c'est étrange, certes. mais par exemple, smb.conf
se trouve ds /etc/samba alors que je lis sur le net qu'il devrait être ds
/usr/local/samba/lib....ce qui parait logique.
et par ailleurs, un rpm -qa | grep samba donne autre chose (samba-common....
et samba-client....) que samba-3.0.3 que je suis sensé avoir installé!

Claude


Avatar
g.patel
On Sat, 8 May 2004 22:28:42 +0200, "Claude" wrote:

oui, il est installé. lancé? apparemment non. je pensais que c'etait le
travail de xinetd


c'est sur qu'il est installé ? Par défaut installer samba sous une
Mandrake n'installe _pas_ swat. Il faut l'installer séparément.

Si oui, vérifier dans le fichier /etc/xinetd.d/swat que la ligne
disable est à 'no'. Si elle ne l'est pas, utiliser 'chkconfig swat on'
(sous root), ou le gestionnaire de services Mandrake, ou un éditeur
de fichier :-) pour la mettre à 'no'.

Une des sources de vos problèmes est que vous ne savez
pas utiliser Usenet; un message avec un titre plus adapté à votre
problème immédiat, comme 'impossible de démarrer swat sous Mdk9',
aurait eu une réponse plus rapide.

Gérard Patel

Avatar
lgmdmdlsr
Claude écrivait :

bonsoir,

impossible de faire un telnet de localhost ou 127.0.0.1, que ce soit en
root on non. pourtant /etc/hosts est à jour.

merci de vos reponses
Claude


Bon, ici un résumé du problème réel, à savoir que la connexion à swat est
impossible (distribution mandrake 9.0 si j'ai bien suivi).

Donc swat ne tourne pas.

La première chose à faire est de vérifier si le paquet samba-swat est
présent, par la commande
rpm -qa samba-swat*

--
lgmdmdlsr

1 2 3 4