Descrito en la sección anterior.
A partir de la versión 1.47 hay una nueva forma (más eficaz) de hacer esto (ver la sección siguiente) pero, si lo prefieres, el método descrito aquí a continuación trabaja perfectamente bien.
Permitir conexiones Telnet es bastante sencillo. Primero necesitas añadir una línea en el fichero /etc/services para permitir conexiones a un número de puerto, tal como esta...
spdlogin 8000/tcp # puerto para el login anonymous
Después añade una línea en el fichero /etc/inetd.conf como esta ....
spdlogin stream tcp nowait root /usr/sbin/tcpd /spider/src/client login telnet
Una vez has hecho esto, necesitas reiniciar inetd haciendo ....
killall -HUP inetd
Te logueas como sysop y cd spider/src. Puedes probar si el Spider ya acepta las conexiones telnet, ejecutando el siguiente comando ....
./client login telnet
Conseguirás el obtener el prompt del login y ver tu indicativo, y tendrás acceso al cluster. Observa, que no te ha pedido contraseña. No parece que haya ningun buen motivo para tener que introducir aqui una contraseña.
Suponiendo que todo esta bien, entonces intentaremos establecer conexión telnet en la consola del Linux ....
telnet localhost 8000
Tendrías de nuevo el prompt del login y serias capaz como antes de establecer conexión.
*** NOTA DEL TRADUCTOR ***A partir de la versión 1.47 puedes elegir usar el programa de Perl cluster.pl
o permitir conexiones directamente (no via el programa de interface /spider/src/client).
Si utilizas Windows, este es el único método disponible para
permitir conexiones Telnet entrantes.
Para hacer ésto lo primero que necesitas hacer es eliminar cualquier línea que previamente hayas puesto en /etc/inetd.conf. Recuerda...
killall -HUP inetd
para que se realice el cambio...
Una vez hecho ésto necesitas copiar el fichero /spider/perl/Listeners.pm to /spider/local y editarlo. Necesitas quitar el comentario en la línea que contiene "0.0.0.0" y elegir el puerto correcto por el que vamos a escuchar. Quedaría de ésta forma:
@listen = (
["0.0.0.0", 8000],);
Como estándar, el listener escuchará simultáneamente en todas las interfaces simultaneamente. Si quieres un control más concreto, has de especificar cada interface individualmente:-
@listen = (
["gb7baa.dxcluster.net", 8000], ["44.131.16.2", 6300],);
Esto será sólo perfecto si la dirección IP de cada interface es estática. Si estas usando alguna forma de direccionamiento IP dinámico, entonces el método por defecto es el único que te permitira trabajar correctamente.
Reinicia el programa cluster.pl para activar el listener.
Una importante diferencia con el listener interno es que no hay eco producido por el programa de cluster. Los usuarios tendrán que poner 'eco local' en su cliente de telnet si no está puesto automáticamente (como lo está por defecto). Es innecesario decir que esto probablemente sólo aplica a los usuarios de Windows.
La máquina AGW es un conjunto de rutinas AX.25 para PC Windows. Puedes conectar la máquina AGW tanto bajo Linux como a PC basados en Windows.
Para poder habilitar el acceso a la máquina AGW Engine necesitamos copiar /spider/perl/AGWConnect.pm a /spider/local y editarlo. Detallamos lo que has de hacer:-
$enable to 1. $login y $passwd
con los valores de instalación de tu AGW . Si los tienes puestos, después
no debes cambiar estos datos. $addr y $port de
forma adecuada. Para activar las conexiones del cluster a los nodos, el spider necesita saber los indicativos de conexión de los otros nodos cluster. Si este es el caso acepta conexiones tanto entrantes como salientes. En spider es una tarea sencilla y que la ejecuta en tiempo real.
Las últimas versiones del Spider distinguen los diferentes softwares y los tratan de forma diferente. Por ejemplo, la baliza WCY no entiende las cabeceras de los nodos tipo AK1A y los nodos AK1A no entienden los PC73. Actualmente hay 4 tipos de nodos diferentes no teniendo demasiadas diferencias permitiendo así su compatibilidad. Estos 4 tipos son...
set/node (tipo AK1A)set/spiderset/dxnetset/clx
Por ahora, asumimos que nuestro cluster va a conectarse con nodos tipo AK1A.
Pon el marcha el cluster y conectate a él usando el programa client con tu indicativo de sysop. Al cluster que queremos que conecte es EA5B-5. Obviamente podría ser cualquier otro indicativo. En la impronta del cluster teclea:
set/node ea5b-5
Este es el formato si tienes una versión del DxSpider posterior a la 1.33. Versiones anteriores necesitan que el indicativo este en mayusculas.
Esto es todo. Así de fácil. Haz una prueba, logueate en otra consola como sysop, ves al subdirectorio spider/src y ejecuta el comando ...
./client ea5b-5 (usa el indicativo que hayas puesto al nodo)
Veras la cadena de inicialización del DxSpider, como...
./client ea5b-5PC38^EA4URE-5C^~
Si el indicativo que has puesto sirve para las conexiones entrantes, esto es todo lo que debíamos de hacer. Si la conexión es saliente necesitamos escribir también un script de conexión.
A veces cometemos un error... normal, el que no hace nada no se equivoca. Si quieres hacer que un indicativo deje de ser nodo y vuelva a ser ususario normal teclea:
unset/node ea5b-5
Ya que el DxSpider opera bajo Linux las conexiones pueden realizarse usando casi cualquier protocolo; AX25, NETROM, TCP/IP, ROSE etc.
Los scripts de conexión están en el directorio /spider/connect y son sencillos ficheros ASCII.Escribir un script de conexión es un trabajo relativamente sencillo.
Los scripts de conexión, consisten en unas líneas que empiezan con palabras reservadas o símbolos:-
#
Se ignoran todas las líneas que empiezan con #, como si fueran
líneas que están completamente en blanco.
timeout
timeout seguido de un número, es el número de segundos que hay
que esperar hasta que se complete el comando. Si no especificamos nada, por
defecto toma 60 segundos.
abort
abort es una expresión conteniendo una o varias
cadenas a buscar con el fin de abortar la conexión. Esto es una expresión regular del Perl
y se ejecuta ignorando mayúsculas o minúsculas.
connect
connect seguido por ax25, AGW (para usuarios
Windows) o telnet y algún tipo de información dependiente. En el caso de la
conexión telnet , hay que ponerle dos parámetros. El primero es la dirección IP
o nombre del ordenador que se desea conectar y el segundo es el numero del
puerto que queremos usar (éste puede quedar en blanco sies una sesión telnet
normal, o sea, por puerto 23). En el caso de una sesión AX.25 este normalmente seria una llamada a
las rutinas ax25_call o netrom_call como en el ejemplo de arriba. Es
responsabilidad tuya obtener tu nodo y otros parámetros AX.25 para trabajar
antes de perder esa ruta.!
'
' es el caracter delimitador para una palabra o
frase en esperar/enviar en una línea de un script. Las
palabras/frases pueden venir a pares o pueden estar en blanco.
Cada línea lee la entrada de la conexión hasta que ve la cadena deseada (o una
expresión regular de perl) contenido a la izquierda de la cabecera de la cadena.
Si la izquierda de la cabecera de la cadena está vacía entonces no hace nada
permanece en espera leyendo. La comparación se realiza ignorando mayúsculas/minúsculas.
Cuando encontramos la parte izquierda de la cabecera (si está) entonces se envía
la parte derecha a la conexión. Este proceso se repite para cada línea del
script.
client
client inicia la conexión, pone los argumentos
necesarios si iniciamos el programa de cliente en forma manual. Solo necesitas
esta si en el script hay un nombre diferente al del indicativo que solicitas
conectar (i.e. tienes un scrip que llama a otro en lugar de realmente conectar
con GB7DJK-1 [en lugar de que el script llame a gb7djk-1]).
Hay muchas formas posibles de configurar el sript; he aquí tres ejemplos, uno para conexión NETRom/AX25 , otro para la máquina AGW y otro para tcp/ip.
timeout 60abort (Busy|Sorry|Fail)# no olvides poner el chmod a 4775 en netrom_call!connect ax25 /usr/sbin/netrom_call bbs gb7djk g1tlh'Connect' '' 'Connect' 'c np7''Connect' 'c gb7dxm'
# puedes acabar si llamas al script 'gb7dxm'
client gb7dxm ax25timeout 60
abort (Busy|Sorry|Fail)# ESte hace exactamente lo mismo que el ejemplo anterior
# El '1' es el numero del puerto AGW para conectarte a g1tlh
connect agw 1 g1tlh'Connect' '' 'Connect' 'c np7''Connect' 'c gb7dxm'# puedes acabar si llamas al script 'gb7dxm'
client gb7dxm ax25timeout 15
connect telnet dirkl.tobit.co.uk'login' 'gb7djk''word' 'gb7djk'# dime si GB7DJK-1 está conectado a GB7DJK
# puedes acabar si llamas al script 'gb7djk'
client gb7djk telnet
Los tres ejemplos asumen que todo está correcto en el otro lado. Puedes buscar más ejemplos en el directorio /spider/examples.
Para iniciar manualmente la conexión a otro cluster, debes de conectarte con tu indicativo de sysop y teclear la palabra connect seguida por el nombre del script que quieras ejecutar, como por ejemplo...
G0VGS de GB7MBC 13-Dec-1998 2041Z >connect gb7djk-1
connection to GB7DJK-1 started G0VGS de GB7MBC 13-Dec-1998 2043Z >
Puedes iniciar la conexión usando el script llamando gb7djk-1.
Puedes seguir el proceso de conexión mirando en la consola o terminal por la
que iniciaste cluster.pl. De la versión 1.47 en adelante, antes
tendras que hacer set/debug
connect. Y veras algo como esto ...
<- D G1TLH connect gb7djk-1-> D G1TLH connection to GB7DJK-1 started ->D G1TLH G1TLH de GB7DJK 13-Dec-1998 2046Z > timeout set to 15CONNECT sort: telnet command: dirkl.tobit.co.ukCHAT "login" -> "gb7djk"received "Red Hat Linux release 5.1 (Manhattan)Kernel 2.0.35 on an i586"received "login: "sent "gb7djk"CHAT "word" -> "gb7djk"received "gb7djk"received "Password: "sent "gb7djk"Connected to GB7DJK-1, starting normal protocol<- O GB7DJK-1 telnet-> B GB7DJK-1 0GB7DJK-1 channel func state 0 -> init<- D GB7DJK-1 <- D GB7DJK-1 Last login: Sun Dec 13 17:59:56 from dirk1<- D GB7DJK-1 PC38^GB7DJK-1^~<- D GB7DJK-1 PC18^ 1 nodes, 0 local / 1 total users Max users 0 Uptime 0 00:00^5447^~
etc
Con las versiones más recientes del Spider hay un comando para usuarios set/login.
Éste les dice cuando un usuario se conecta o desconecta del cluster.
Si no añades una línea en
tus scripts despues de la línea final ( o antes de la linea cliente que lo
puedes hacer al final si lo necesitas) entonces la información de login/logout
será enviada a los usuarios antes de que se complete el actual login.
Así si el nodo esta rechazado, continuara enviando logins y logouts de los
usuarios aunque no esten conectados en realidad. Para evitarlo usa la siguiente
linea ...
'connect' ''
Dentro del script, parecido a esto ...
timeout
35 abort(Busy|Sorry|Fail) connect telnet mary3000 'ogin:''gb7mbc''>' 'telnet 44.131.93.96 7305''connect' ''
Los enlaces en particular del cluster sufren mucho con la presencia del eco del telnet. Esto esta causado en si mismo, por la negociación del telnet y en el peor de los casos puede crear serios bucles. En el mejor de los casos crea innecesario ruido en la banda y enormes ficheros de log! Así esta la cosa y el trabajo para delimitar el fin del problema no estará necesariamente en función de la ruta seguida para conectarse.
Que el telnet produjera eco en si mismo sólo sería problema si la conexión se inicia por un telnet al puerto (23). Este puerto usa unas reglas especiales que incluyen la negociación del eco. Si la conexión se efectúa a un puerto distinto, tal como el 7300, esta negociación no se produce y por tanto el eco no debería presentarse.
A veces no es posible realizar una conexión directa a otro nodo y este puede causar problemas. Hay una forma para tratar de suprimir el eco del telnet pero esto por desgracia no funciona siempre, por desgracia es muy difícil ser mas concreto. Un ejemplo de lo que yo hago ...
timeout 35abort (Busy|Sorry|Fail)connect telnet mary.lancs.ac.uk'ogin:' 'gb7mbc''word:' 'mypasswd''\$' 'stty -echo raw'
'\$' 'telnet 44.131.93.96''connect' ''
Ojo, la primera conexión es especial del Spider. Esto es fino el spider usa el script Net_Telnet escrito en perl. Actualmente usa TCP antes de que termine la negociación TELNET en la primera conexión. Una vez conectado a mary.lancs.ac.uk, se ejecuta el comando y se suprime el eco. Ya que el telnet procede del nodo del cluster acepta conexiones al puerto 23. El problema con estos enlaces, es que la negociación se efectúa en la máquina remota, por lo tanto no tenemos ningún control sobre el proceso. La casualidad puede hacer que el enlace cree un eco, y que en realidad no haya ningún camino pero puedes pararlo.
Hasta ahora tienes el DXSpider rodando bien y admitiendo conexiones de nodos cluster o de los usuarios. Sin embargo tienes que cerrarlo y rearrancarlo de forma manual. Sería mucho más facil tener un arranque automático...
Esto no es sólo una forma de arrancar el cluster automáticamente, también lo re-arranca en caso de que por cualquier motivo el cluster se cierre. Antes de seguir, cierra el cluster tal y como hiciste antes. ( shutdown )
Logueate como root y abre tu editor favorito para editar el fichero /etc/inittab Añade las siguientes líneas al fichero hacía el final...
##Start DXSpider on bootup and respawn it should it crashDX:3:respawn:/bin/su -c "/usr/bin/perl -w /spider/perl/cluster.pl" sysop >/dev/tty7
Esta línea trabaja bien para las distribuciones RedHat. También para
la SuSE por debajo de la 7.0.
Para SuSE 7.1 en adelante necesitamos añadir la activación de
los niveles 2 y 5 tal y como ...
DX:235:respawn:/bin/su -c "/usr/bin/perl -w /spider/perl/cluster.pl" sysop >/dev/tty7
La línea necesaria para la distribución Slackware es ligeramente
distinta.
Gracias a Aurelio, PA3EZL por esta información.
DX:23:respawn:/bin/su - sysop -c "/usr/bin/perl -w /spider/perl/cluster.pl" >/dev/tty7
Esto arrancará automáticamente el DxSpider en tty7 (ALT-F7) rebotará y se re-arrancará en caso de que se bloquee por cualquier motivo.
Nota: Observa que tty7 es sólo un ejemplo. Algunos sistemas SuSE sólo aceptan hasta tty6. Realmente no importa en que terminal tty lo hagas.
Como usuario ROOT teclea el comando telinit q. El DXSpider arranca inmediatamente. Veremos la salida en tty7 y si te has logueado como sysop deber tenerlo todo funcionando perfectamente.