El manual de LISa
Copyright © 2001 Alexander Neundorf
LISa intenta proporcionar una especie de «entorno de red», pero recayendo sólo en la pila TCP/IP, SMB o similares no son necesarios.
Este es el manual tanto del Servicio de Información de LAN (LISa), como del Servicio de Información de LAN Restringido (resLISa).
Tabla de contenidos
Lista de ejemplos
LISa intenta proporcionar una especie de «entorno de red», pero recayendo sólo en la pila TCP/IP, SMB o similares no son necesarios.
Es completamente independiente de KDE/Qt™.
La lista de máquinas activas es proporcionada por el puerto TCP 7741.
LISa soporta dos maneras de encontrar máquinas:
Usted debe proporcionar a LISa un rango de direcciones IP,entonces LISa mandará peticiones de eco ICMP a todas las direcciones IP proporcionadas, y esperará las respuestas.
Puede decirle a LISa que ejecute nmblookup "*. La herramienta de línea de órdenes nmblookup debe venir instalada con el paquete Samba. nmblookup "*" envía una emisión a las redes adjuntas, y todas las máquinas ejecutando servicios SMB responderán esta emisión.
En el archivo de configuración debe proveer un rango de direcciones IP, las cuales LISa debe comprobar para ver si se están ejecutando.
En el caso más simple esto puede ser su dirección de red/máscara de subred, entonces LISa comprobará cada posible máquina de su red para ver si está ejecutándose.
Las máquinas son comprobadas usando peticiones de eco ICMP. Para ser capaz de enviar y recibir peticiones y respuestas de eco ICMP, el programa necesita abrir lo que se llama un «raw socket». Por lo tanto necesita privilegios de root. Este socket es abierto justo después del inicio del programa, después de abrir satisfactoriamente el socket, los privilegios de root son descartados inmediatamente (ver main.cpp y strictmain.cpp).
Si configura LISa de manera que también use nmblookup, hará popen("nmblookup \"*\"") y procesará los resultados.
Puesto que las peticiones ICMP y las emisiones pueden causar algún trafico de red si hay más de un servidor ejecutándose en una red, los servidores cooperan con los otros. Antes de empezar a hacer ping (o nmblookup), envían una emisión al puerto 7741.
Si alguien contesta a la emisión, recuperarán la lista completa de máquinas ejecutándose a través del puerto TCP 7741 de esta máquina y no empezará a hacer ping (o nmblookup).
Si nadie responde, el anfitrión que envió la emisión empezará a hacer ping a las máquinas (o nmblookup) y entonces abrirá un socket que escucha para las emisiones mencionadas. Si el anfitrión recibió una respuesta a su emisión, no tendrá el socket para escuchar las emisiones abierto. Así normalmente justo uno de los servidores tendrá abierto este socket y solo éste hará actualmente ping (o nmblookup) a las máquinas.
En otras palabras, los servidores son perezosos, trabajan de la forma«sólo haré algo si nadie más puede hacerlo por mi».
Hay otra funcionalidad que reduce la carga de la red.
Digamos que usted configuró LISa para actualizar cada 10 minutos. Ahora no accede a su servidor muy frecuentemente. Si nadie accede al servidor en el último periodo de actualización, el servidor actualizará (tanto él mismo como desde el que actualmente hace el trabajo) y entonces doblará su periodo de actualización, es decir la siguiente actualización ocurrirá después de 20 minutos.
Esto sucede 4 veces, así que si nadie accede al servidor con periodo de actualización de 10 minutos por un largo periodo, su intervalo de actualización se incrementará hasta 160 minutos, casi tres horas. Si entonces alguien accede a los datos del servidor, recibirá una lista antigua (hasta 160 minutos antigua). Accediendo al servidor reiniciará su intervalo de actualización a su valor inicial, es decir 10 minutos e inmediatamente empezará actualizando si la última actualización es más de estos 10 minutos pasados. Esto significa que si recibe una lista muy vieja, puede probar de nuevo unos segundos después y debe debe obtener una versión actual.
Esto tendrá rápido efecto sobre los servidores, los cuales no harán ping (o nmblookup) a sí mismos, desde que sólo un usuario les acceda, y tendrá menos efecto sobre el servidor que hace ping (o nmblookup), ya que este servidor es accedido desde todos los otros servidores en la red.
De esta manera es posible que muchas máquinas en una red ejecuten este servidor, pero la carga de la red se mantiene baja. Para el usuario no es necesario saber si hay un servidor (es decir un servidor de nombres o de archivos o lo que sea) en la red el cual también ejecute LISa. Él puede ejecutar LISa localmente y LISa detectará si hay uno, transparentemente para el usuario.
El primer cliente para LISa es un ioslave para KDE 2, así el usuario puede introducir lan://localhost/ o lan:/, los cuales ambos contactarán con LISa en su propio sistema.
Si hay una máquina que se ejecute todo el tiempo y el usuario sabe que esta máquina ejecuta LISa, puede usar su cliente LISa directamente con este servidor (sería con el mencionado ioslave lan://el_nombre_del_servidor/).
Si no quiere que su LISa tome parte en la emisión, pero siempre haga ping, haga que use otro puerto con la opción de línea de órdenes --port o -p. ¡Esto no está recomendado!
Si envía SIGHUP a LISa, releerá su archivo de configuración. Si envía SIGUSR1 a LISa, imprimirá información de estado a la salida estándar.
Los datos proporcionados a través del socket tienen un formato simple: <dirección ip decimal ordenado por por byte de red><un espacio 0x20><nombre completo de la máquina><una terminación '\0'><nueva línea '\n'< y la última línea0 succeeded<'\n'>
Por ejemplo,
17302538 alguna_máquina.loquesea.es
18285834 linux.loquesea.es
17827082 nameserver.loquesea.es
0 succeededEsto debe hacerlo fácilmente analizable.
Si hay normas de seguridad muy estrictas en su red, algunas personas pueden considerar el hacer ping un ataque potencial. Si tiene problemas con esto, pruebe la versión restringida, resLISa.
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
Si usted tiene unas reglas de seguridad muy estrictas en su red o no quiere abrir otro puerto o cualquier cosa, puede usar resLISa.
Con resLISa usted puede hacer ping a redes enteras y rangos de direcciones, usted puede dar a resLISa actualmente hasta 64 máquinas por sus nombres en su archivo de configuración. Estas máquinas recibirán pings. Todavía puede hacer uso de nmblookup.
resLISa sólo proveerá la información a través de un socket de dominio Unix, es decir no sobre la red. El nombre del socket es/tmp/resLisa-SuNombredeEntrada así resLISa puede ser ejecutado por más usuarios a salvo en una máquina.
Puesto que no debe producir ningún riesgo de seguridad de ningún tipo, es seguro instalar resLISa con setuid root. Los privilegios de root serán desechados justo después del inicio (ver strictmain.cpp), son sólo necesarios para crear un raw socket para enviar las peticiones de eco ICMP.
Además no enviará o recibirá emisiones. El primer cliente para éste es también un ioslave para KDE 2 (rlan:/ en Konqueror por ejemplo.)
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
Ahora un ejemplo de configuración:
PingAddresses = 192.168.100.0/255.255.255.0;192.168.100.10-192.168.199.19;192.168.200.1;192-192.168-168.100-199.0-9; PingNames = bb_mail; AllowedAddresses = 192.168.0.0/255.255.0.0 BroadcastNetwork = 192.168.100.0/255.255.255.0 SearchUsingNmblookup = 1 #probar también nmblookup FirstWait = 30 #30 centenares de segundos SecondWait = -1 #sólo un intento #SecondWait = 60 #intentarlo dos veces y la segunda vez esperar 0.6 segundos UpdatePeriod = 300 #actualizar después de 300 segs DeliverUnnamedHosts = 0 #no publicar máquinas sin nombre MaxPingsAtOnce = 256 #enviar hasta 256 peticiones de eco ICMP al mismo tiempo
Esta es probablemente la entrada más importante.
Aquí dice a qué direcciones se hará ping. Puede especificar múltiples rangos, son divididos por puntos y coma.
Hay cuatro formas posibles de definir direcciones:
192.168.100.0/255.255.255.0, es decir una dirección IP y la máscara de red asignada.
Esto no tiene que ser dirección de red y la máscara de subred de su máquina. Por ejemplo si usted tiene 10.0.0.0/255.0.0.0 como su propia dirección, usted puede especificar 10.1.2.0/255.255.255.0 si está solo interesado en estas direcciones. La combinación dirección IP-máscara de red debe ser separada por una barra «/»y la dirección no tiene porqué ser una dirección de red real, puede ser también la dirección de una máquina en la red deseada, es decir 10.12.34.67/255.0.0.0 es lo mismo que 10.0.0.0/255.0.0.0 .
Por ejemplo: 192.168.100.10-192.168.199.19
Una dirección-IP donde empezar a hacer ping y una dirección-IP donde acabar de hacer ping.
Ambas direcciones deben estar divididas por un «-».
En este ejemplo esto producirá 199-100+1=100, 100*256=25.600, 25.600+(19-10+1)=25.590 direcciones.
Una dirección IP puede estar representada por sus cuatro números decimales, y puede especificar rangos para cada uno de estos cuatro números: 192-192.169-171.100-199.0-9
En este ejemplo, a todas las direcciones IP con 192 como primer número, segundo número de 168 a 168, tercer número de 100 hasta 199 y último número de 0 hasta 9 se les hará ping. Esto dará 1*1*100*10=1.000 direcciones.
Esto probablemente sólo es útil en casos raros. Aquí debe proporcionar rangos para cada cuatro números, siempre divididos por «-».
La dirección IP o nombre de máquina de cualquier máquina en la que esté particularmente interesado.
Es también válido dejar esta entrada vacía.
PingNamesAquí puede adicionalmente especificar máquinas a las que hacer ping usando sus nombres. Los nombres tienen que ser separados por puntos y coma.
Es también válido dejar esta entrada vacía.
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
AllowedAddressesEsto es también muy importante. LISa sólo hará ping a direcciones, aceptará clientes y responderá a emisiones de direcciones, las cuales estén cubiertas por las direcciones dadas en esta línea. Puede añadir hasta 32 direcciones de red/máscaras de red o direcciones simples. Sepárelas por ; y ¡no ponga espacios en blanco entre direcciones!
Por ejemplo, 192.168.0.0/255.255.0.0;192.169.0.0
Una red completa y una dirección sencilla son válidas. Siempre haga esto tan estricto sea posible, habitualmente su dirección de red/máscara de subred es una buena opción.
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
BroadcastNetworkEsta entrada contiene exactamente una dirección de red/máscara de subred. Peticiones de broadcast le serán enviadas a esta red. Normalmente esto será su propia dirección de red/máscara de subred, por ejemplo: 192.168.0.0/255.255.0.0
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
SearchUsingNmblookupAquí puede dar 0 o 1. 1 significa que LISa ejecutaránmblookup "*" y analizará la salida de esta orden. Esto produce menos tráfico de red que el hacer ping, pero sólo obtendrá máquinas las cuales tengan un servicio SMB ejecutándose (máquinas Windows® o máquinas ejecutando samba).
Si activa esta opción y también da direcciones IP al ping, entonces nmblookup será ejecutado primero y se empezará a hacer ping. Entonces sólo se hará ping a direcciones, las cuales no hayan sido reveladas por nmblookup. Esto debería rebajar la carga de la red ligeramente.
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
FirstWaitSi LISa hace ping, es decir si envía peticiones de eco ICMP, enviará un grupo de peticiones al mismo tiempo, y entonces esperará para los centenares de segundos que especifique aquí. Habitualmente, valores de 5 a 50 deberían ser buenos, el máximo es 99 (da 0.99 segundos, bastante tiempo). Intente hacer este valor tan pequeño como sea posible mientras todavía esté encontrando todas las máquinas activas.
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
SecondWaitDespués de que LISa haya enviado las peticiones de eco la primera vez, puede ser posible que algunas máquinas no sean encontradas. Para mejorar los resultados, LISa puede hacer ping una segunda vez. Esta vez hará ping sólo a máquinas de las cuales no recibió respuestas. Si obtiene buenos resultados haciendo ping sólo una vez, puede deshabilitar la segunda vez estableciendo SegundaEspera a -1.
De otra manera sería buena idea hacer este valor un poco mayor que el valor de FirstWait, puesto que las máquinas que no fueron encontradas en el primer intento, son probablemente más lentas o están más alejadas, así que tomará algunos milisegundos más para responder. Habitualmente valores de 5 a 50 suelen ser buenos o -1 para deshabilitar la segunda exploración. El máximo es 99 (da 0.99 segundos, un periodo bastante grande).
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
UpdatePeriodEste es el intervalo después del cual LISa actualizará. Después de este tiempo LISa hará ping de nuevo o nmblookup o tomará la lista de máquinas del servidor LISa el cual haga pings actualmente.
Los valores válidos están entre 30 segundos y 1800 segundos (media hora). Si tiene una red grande, no haga el intervalo muy pequeño (para mantener bajo la carga de la red). Valores de 300 a 900 segundos (5 a 15 minutos) son una buena idea.
Tenga en mente que el periodo de actualización se dobla si nadie accede al servidor, hasta 4 veces, así que el intervalo llegará a ser 16 veces el valor dado aquí, y será restablecido al valor dado si alguien accede al servidor.
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
DeliverUnnamedHostsSi es recibida una respuesta a una petición de eco de una dirección IP, donde LISa no pudiera determinar un nombre, será sólo entregada sobre el puerto si establece esto a 1.
No estoy seguro si esto es una funcionalidad útil, pero quizás hay algunos dispositivos de infraestructura en su red sin nombres asignados, así que no necesitan ser publicados. Establezca esto a 0 si quiere mantenerlos secretos ;-) Si no está seguro, diga 0.
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
Cuando envía los ping (peticiones de eco), LISa envía un grupo de estos al mismo tiempo y entonces espera las respuestas. De manera predeterminada se envían 256 pings a la vez, normalmente no necesitará cambiar este valor. Si lo hace mucho mayor, la memoria temporal interna que recibe las respuestas se hará muy pequeña, si lo hace demasiado pequeño, la actualización se hará más lenta.
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
Ejemplo 4.1. FIXME
Usted es un miembro de una pequeña red con máscara de red de 24 bits, es decir hasta 256 máquinas.
PingAddresses = 192.168.100.0/255.255.255.0 AllowedAddresses = 192.168.100.0/255.255.255.0 BroadcastNetwork = 192.168.100.0/255.255.255.0 SearchUsingNmblookup = 0 #no use nmblookup FirstWait = 20 #20 centenares de segundos SecondWait = 30 #30 centenares de segundos en los segundos intentos UpdatePeriod = 300 #actualizar cada 300 segs DeliverUnnamedHosts = 0 #no publicar máquinas sin nombre
Ejemplo 4.2. Archivo de configuración para máquinas ejecutando SMB sólo.
Sólo está interesado en máquinas ejecutando servicios SMB y no tiene routers en su red:
AllowedAddresses = 192.168.100.0/255.255.255.0 BroadcastNetwork = 192.168.100.0/255.255.255.0 SearchUsingNmblookup = 1 #usar nmblookup UpdatePeriod = 300 #actualizar después de 300 segs DeliverUnnamedHosts = 0 #no publicar máquinas sin nombre
Ejemplo 4.3. Archivo de configuración usando tanto nmblookup como pings.
La misma red, pero aquí tanto nmblookup como ping son usados.
PingAddresses = 192.168.100.0/255.255.255.0 PingNames = bb_mail AllowedAddresses = 192.168.0.0/255.255.0.0 BroadcastNetwork = 192.168.100.0/255.255.255.0 SearchUsingNmblookup = 1 #usar también nmblookup FirstWait = 30 #30 centenares de segundos SecondWait = -1 #sólo un intento #SecondWait = 60 #intentarlo dos veces, y en el segundo intentoesperar 0.6 segundos UpdatePeriod = 300 #actualizar después de 300 segs DeliverUnnamedHosts = 0 #no publicar máquinas con nombre MaxPingsAtOnce = 256 #enviar hasta 256 peticiones de eco ICMP a la vez
Ejemplo 4.4. Archivo de configuración para resLISa
Y ahora un archivo de configuración para resLISa, PingAddresses no es usado por resLISa, ni tampoco BroadcastNetwork.
PingNames = bb_mail;una_máquina;otra_máquina AllowedAddresses = 192.168.0.0/255.255.0.0 SearchUsingNmblookup = 1 # usar nmblookup FirstWait = 30 #30 centenares de segundos SecondWait = -1 #un sólo intento #SecondWait = 60 #intentarlo dos veces, y el segundo intentoesperar 0.6 segundos UpdatePeriod = 300 #actualizar después de 300 segs DeliverUnnamedHosts = 1 #también publicar máquinas sin nombre MaxPingsAtOnce = 256 #enviar hasta 256 peticiones de eco ICMP a la vez
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
Las siguientes opciones de la línea de órdenes son usadas:
-v, --versiónImprime una breve información de versión
-h, --helpDa una vista general de las opciones de línea de órdenes
-u, --unixBusca primero en $, entonces en HOME/.lisarc/etc/lisarc. Este es el comportamiento por defecto.
-k, --kde1Busca primero en$, entonces en HOME/.kde/share/config/lisarc$.KDEDIR/share/config/lisarc
-K, --kde2Busca el archivo lisarc en cada carpeta devuelta por ejecutarkde-config --path config
-c, --config=ARCHIVOLee ARCHIVO y no otro archivo de configuración.
-p, --port NUMPUERTOInicia el servidor en este número de puerto. Si usa esto, LISa no será capaz de cooperar con otros LISas en la red. Esta opción no está disponible para resLISa
Si envía la señal Hangup a LISa o resLISa, éste leerá su archivo de configuración (killall ).-HUP lisa
Si envía la señal User1 a LISa o resLISa, éste imprimirá información de estado en la salida estándar (killall ). No verá nada si la consola desde la cual LISa/resLISa fue iniciado ha terminado.-USR1 lisa
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
Derechos de autor de LISa y resLISa. 2000, 2001. Alexander Neundorf.
Alejandro Exojo(suy AT badopi.org)
Páselo bien, Alexander Neundorf (neundorf AT kde.org)
Esta documentación está sujeta a los términos de la Licencia de Documentación Libre GNU.
Este programa está sujeto a los términos de la Licencia Pública General GNU.
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
Tabla de contenidos
LISa y resLISa necesitan una libstdc++ (usa sólo la clase de cadenas de ella), no necesita ni Qt™ ni KDE.
Para poder compilar e instalar LISa en su sistema, introduzca las siguientes instrucciones en el directorio raíz de la distribución de LISa:
%./configure%make%make install
Como LISa utiliza autoconf y automake no debería producirse ningún problema en la compilación. Si encuentra alguna dificultad le rogamos que se dirija a los foros de discusión de KDE.
Ambos, resLISa y LISa abren lo que se llama un «raw socket» para enviar y recibir peticiones de eco ICMP (pings). Para hacer esto, necesitan privilegios de root.
LISa ofrece un servicio en el puerto TCP 7741, y debe ser instalado por el usuario root e iniciado cuando el sistema arranca. Depende enormemente de su Sistema operativo como conseguir esto.
resLISa pretende ser iniciado por un usuario, no ofrece nada a la red. Necesita ser instalado setuid root.
Si usa el ioslave rlan para KDE 2, resLISa puede ser arrancado automáticamente.
LISa lee el archivo lisarc, resLISa lee el archivo reslisarc. Si quiere ser capaz de configurar ambos desde KControl, debe iniciarlos usando la opción de línea de órdenes-K.
Para más información sobre donde buscan archivos de configuración, lea el capítulo en Capítulo 5, Opciones de la línea de órdenes y otros usos.
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team