Como hemos dicho anteriormente, el objeto de este documento no es enseñarte a configurar el Linux, ni sus utilidades AX.25. Sin embargo, necesitas añadir una linea en el fichero ax25d.conf para permitir que los usuarios AX.25 pueden conectarse al DxSpider. Para cada interface que desees permitir conexiones, usa el siguiente formato ...
default * * * * * * - sysop /spider/src/client client %u ax25
o, Si quieres que tus usuarios puedan usar SSID en sus indicativos ..
default * * * * * * - sysop /spider/src/client client %s ax25
La mayoria de las veces el SSID no es necesario. Solo lo necesitaremos cuando tengamos que permitir conectarse a otros Cluster o nodos que usen SSID. En este caso lo mejor es emplear una linea como la del primer ejemplo, y añadir una linea especifica por cada nodo, como por ejemplo.
EA5XXX-2 * * * * * * - sysop /spider/src/client client ea5xxx-2 ax25
default * * * * * * - sysop /spider/src/client client %u ax25
A partir de la versión 1.47 hay una nueva forma (mas eficaz) de hacer esto (ver la sección siguiente) pero, si lo prefieres, el metodo descrito aqui a continuación trabaja perfectamente bien.
Permitir conexiones Telnet es bastante sencillo. Primero necesitas añadir una linea en el fichero /etc/services para permitir conexiones a un numero de puerto, tal como esta ....
spdlogin
8000/tcp # puerto para el login anonymous
Despues añade una linea 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
Conseguirias el obtener el prompt del login y ver tu indicativo, y tendras 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
Tendrias de nuevo el prompt del login y serias capaz como antes de establecer conexión.
A partir de la versión 1.47 puedes elegir usar el programa de perl cluster.pl o permitir
conexiones directamente (ejemplo no via el el programa de interface
/spider/src/client). Si usas la interface Windows, este es el único metodo que puedes usar
para permitir conexiones Telnet entrantes.
Para ello es necesario primero borrar una linea que previamente habiamos puesto en /etc/inetd.conf. Ver como:-
killall -HUP inetd
hasta hacer el cambio comentado...
Antes de acabar, necesitas copiar este fichero /spider/perl/Listeners.pm to /spider/local y editarlo. Necesitas quitar el comentario, a la linea que contiene "0.0.0.0" y elegir el puerto correcto por el que vamos a escuchar. Para que mire a este:-
@listen = (
["0.0.0.0", 8000],
);
Como estandard, el puerto oyente escuchará simultaneamente a todas las interfaces. si quieres un control más estrecho, has de especificar una interface individualmente:-
@listen = (
["gb7baa.dxcluster.net", 8000],
["44.131.16.2", 6300],
);
Esto será solo perfecto si la dirección IP de cada interface es estática. Si estas usando alguna forma de direcionamiento IP dinámico, entonces el Default es el único método que te permitira trabajar correctamente.
Rearancar el programa cluster.pl activando el listener.
Una importante diferencia con el listener interno es que no hay eco cuando finalizamos el programa de cluster. Los usuarios tendrán que poner 'local-echo' en su cliente de telnet si no está puesto automáticamente (por standares). Innecesario decir que esto probablemente, solo aplica a los usuarios de Windows.
La máquina AGW es un conjunto de rutinas AX.25 para PC,s Windows. Puedes conectar la máquina AGW tanto bajo Linux como a PC,s 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, despues 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 nodos del 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.
Versiones antiguas del Spider distinguian los diferentes softwares y los trataban de forma diferente. Por ejemplo, la baliza WCY no entiende las cabeceras de los nodos tipo AK1A y los nodos AK1A no entienden las de PC73. Actualmente hay 4 tipos de nodos diferentes y actualmente podrian perfectamente no tener muchas diferencias se trabaja pora hacerlos compatibles. Estos 4 tipos son ...
set/node (tipo AK1A)
set/spider
set/dxnet
set/clx
Por ahora, asumimos que nuestro cluster va a conectarse con nodos tipo AK1A.
Al poner en marcha el cluster antes de nada nos logueamos como cliente Sysop. El nodo del cluster se pone en espera para realizar una conexión con GB7BAA pero seria obvio usar cualquier indicativo que queramos. En el prompt tecleamos ...
set/node gb7baa
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, ahora es asi de facil. Haz una prueba, logueate en otra consola como sysop, ves al subdirectorio cd spider/src y ejecuta el comando ...
./client gb7baa (usa el indicativo que hayas puesto al nodo)
Ves la cadena de inicialización del DxSpider, como...
./client gb7baa
PC38^GB7MBC^~
Si has puesto el indicativo en el nodo del cluster sirve para las conexiones entrantes, esto es todo lo que necesitamos hasta el final. Si la conexión es saliente necesitamos escribir un script de conexión.
A veces cometemos un error... normal, el que no hace nada no se equivoca. Si quieres hacer un nodo, da marcha atras hasta el principio del usuario normal. Sin reparar en como y teclea lo de abajo:
unset/node gb7baa
A raiz de que el DxSpider opera bajo Linux, las conexiones deben configurarse usando algún protocolo; AX25, NETRom, TCP/IP, ROSE etc.
Hay muchos ejemplos de scripts de conexión en el directorio /spider/connect y son sencillos ficheros ASCII.
Escribir un scrip de conexión es un trabajo relativamente sencillo.
Los scripts de conexión, consisten en unas lineas que empiezan con palabras reservadas o simbolos:-
Se ignoran todas las lineas que empiezan con #, también las
que están completamente en blanco.
timeout seguido de un número, es el tiempo de que hay
que esperar hasta que se complete el comando. Si no especificamos nada, por defecto toma
60 segundos.
abort es una expresión conteniendo uno o varios strings
con el fin de abortar la conexión. Esto es una expresión regular del perl y se ejecutara en
cualquier caso.
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 ( este puede quedar fuera, en una sesión
telnet normal). 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 parametros AX.25 para trabajar antes de perder esa ruta.!
' es el caracter delimitador para una palabra o frase
en esperar/enviar en una linea de un script tipo Chat. Las palabras/frases normalmente están
entre parentesis, pueden estar en blanco. Cada linea lee la entrada de la conexión hasta que
ve el string (o una expresión regular de perl) contenido a la izquierda de la cabecera
del string. Si la izquierda de la cabecera del string esta vacio entonces no hace nada
permanece en espera leyendo. Finaliza la comparación ignorando este caso. Cuando encontramos
la parte izquierda de la cabecera (si esta) entonces se envia la parte derecha a la conexión.
Este proceso se repite para cada linea del scrip Chat.
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 srcipt he aqui tres ejemplos, uno para conexión NETRom/AX25 , otro para la máquina AGW y otro para tcp/ip.
timeout 60
abort (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 ax25
timeout 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 ax25
timeout 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 mas ejemplos en el directorio /spider/examples.
Inicias la conexión, con el cluster conectado y login de sysop, tecleas la palabra connect seguida por el nombre del script que quieras como....
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 15
CONNECT sort: telnet command: dirkl.tobit.co.uk
CHAT "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 0
GB7DJK-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 versiones mas recientes del Spider hay un comando para usuarios set/login. Este dice cuando un usuario se loguea o desloguea. Si no añades una linea en tus scripts despues de la linea 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. Asi 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 mary
3000 '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! Asi 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 simismo solo seria problema si la conexión se inicia por un telnet al puerto (23). Este puerto usa unas reglas especiales que incluyen la negiciación del eco. Si la conexión se efectua a un puerto distinto, tal como el 7300, esta negociación no se produce y por tanto el eco no deberia 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 dificil ser mas concreto. Un ejemplo de lo que yo hago ...
timeout 35
abort (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 efectua 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 pudes pararlo.
Ok, tu tienes ahora al DXSpider rodando bien y admitiendo conexiones del nodo del cluster o de los usuarios. Sin embargo tienes que cerrarlo y rearrancarlo de forma manual. Seria mucho mas facil tener un arranque automático.
Este no es el único camino, para arrancar automáticamente el cluster, tambien trabaja un perro guardian (watchdog), verificando la integridad del DXSpider y respaldandolo si hace un crash por cualquier motivo. Antes de seguir, cierra el cluster tal y como hiciste antes.
Logueate como root y abre para editar el fichero /etc/inittab con tu editor favorito. Añade las siguientes lineas al fichero por el final...
##Start DXSpider on bootup and respawn it should it crash
DX:3:respawn:/bin/su -c "/usr/bin/perl -w /spider/perl/cluster.pl" sysop >/dev/tty7
Esta linea trabaja bien para las distribuciones RedHat. También para la SuSE por debajo de la 7.0. Para Suse 7.1 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 linea 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) rebotara y hara restart, en caso de que se bloquee por cualquier motivo.
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.