<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Hola David, <br>
<br>
Pongo en copia a la lista. Te voy respondiendo debajo:<br>
<br>
On 16/09/12 15:43, David Rubert wrote:<br>
</div>
<blockquote
cite="mid:CAF-Hj--6d-PENHtcyiG=w1E+2GROQ98mcdWC1HkZ5AMd18tGrA@mail.gmail.com"
type="cite">
<div>Vale, por fin he conseguido llegar a donde quería en el
desarrollo, a partir de ahora podemos avanzar rápidamente.</div>
<div><br>
</div>
<div>Te comento algunas cosas:</div>
<div><br>
</div>
<div>* Otras, no había visto los nuevos formularios que habías
puesto, se me pasaría ese mail. Ok, es justo donde estaba ahora
mismo, diseñando el formulario de obtención de datos de un nuevo
nodo de la red. ¿Te parece si nos centramos en ese primero?
Luego continuamos con los usuarios de la PBX.</div>
</blockquote>
<br>
+1<br>
<br>
<blockquote
cite="mid:CAF-Hj--6d-PENHtcyiG=w1E+2GROQ98mcdWC1HkZ5AMd18tGrA@mail.gmail.com"
type="cite">
<div><br>
</div>
<div>* Mira, la versión actual que tengo de la web está aquí y en
el repositorio GIT:</div>
<div><br>
</div>
<div><a moz-do-not-send="true" href="http://loom.gotdns.org/pln">http://loom.gotdns.org/pln</a></div>
<div><br>
</div>
<div><br>
</div>
<div>Me había centrado en la funcionalidad de los mapas, que ya
tengo totalmente controlada. El formulario de alta de nodo
(enlace JOIN) permite la introducción de datos, añadir una
ubicación en el mapa con el detalle de precision que prefiera el
usuario, y eso ya postea al servidor, con lo cual podríamos
guardar ya sin problemas la información. También está
implementada la internacionalización, por lo que una vez
tengamos información concreta podemos traducir el contenido en
los idiomas que queramos.</div>
</blockquote>
<br>
Muy wapa la web David! Esta tardenoche voy a ir subiendo cambios.<br>
<br>
<blockquote
cite="mid:CAF-Hj--6d-PENHtcyiG=w1E+2GROQ98mcdWC1HkZ5AMd18tGrA@mail.gmail.com"
type="cite">
<div><br>
</div>
<div>La idea del modelo distribuido me encanta, pero eres
consciente de que podemos tener conflictos, me gustaría que
comentáramos a ver como los podríamos resolver:</div>
<div><br>
</div>
<div>* Hacer ping a una IP está bien, pero y si ya estaba dada de
alta y justamente el nodo estaba desconectado en ese momento? Se
daría de alta el nodo y habrían 2 nodos con la misma IP
asignada.</div>
</blockquote>
<br>
Podríamos asignar IPs secuencialmente. Al asignar una IP, además de
comprobar que es mayor que la última IP que tengamos en el listado
de nodos, podemos comprobar también por ejemplo que las 20
siguientes tampoco responden a ping como medida extra de seguridad.<br>
<br>
El nodo __anfitrión__ se autoasigna esa IP libre (además de la suya
habitual) para reservarla y responder a ping (he probado esto y
funciona)<br>
<br>
Cuando el admin del nuevo nodo tenga todo configurado, accede a una
URL que servirá para que el nodo anfitrión deje libre la IP y el
nuevo nodo lance su tinc, con lo que la IP estaría libre sólo por
unos segundos. Si al cabo de 30 o 60 segundos el nuevo nodo no
responde a ping, el anfitrión volvería a asignarse esa IP y esperar
a que el nuevo admin configure correctamente su tinc y visite otra
vez esa URL.<br>
<br>
<blockquote
cite="mid:CAF-Hj--6d-PENHtcyiG=w1E+2GROQ98mcdWC1HkZ5AMd18tGrA@mail.gmail.com"
type="cite">
<div><br>
</div>
<div>* El nombre del host lo mismo, puede entrar en conflicto con
alguno ya dado de alta. Este sería un problema menor en
comparación al de la IP.</div>
</blockquote>
<br>
Si todos nos encargamos de mantener actualizada la lista de nodos o
delegar en alguien que la mantenga, no deberíamos tener estos
problemas.<br>
<br>
Aún así, si llegara a pasar... supongo que las llamadas
funcionarían. Lo que no funcionaría sería que un nodo pudiera tener
las claves públicas de los 2 nodos con el mismo nombre.<br>
<br>
Lo que seguro acabaría pasando es que después de un tiempo, cuando
los 2 nodos aparezcan en los listados con el mismo nombre, alguien
(todos los que se den cuenta?) debería/n escribir al admin que
registró un nombre que ya existía que por favor se lo cambie y envíe
sus nuevas claves públicas a sus nodos vecinos.<br>
<blockquote
cite="mid:CAF-Hj--6d-PENHtcyiG=w1E+2GROQ98mcdWC1HkZ5AMd18tGrA@mail.gmail.com"
type="cite">
<div><br>
</div>
<div>Otra duda que me surge. Si un usuario, por lo que sea, quiere
cambiar alguno de sus datos: su email, la ubicación de su nodo,
la IP, etc. etc. ¿Qué procedimiento habilitamos para que lo
consiga?</div>
</blockquote>
<br>
Un usuario o un admin?<br>
<br>
Un usuario: Se conecta a la web de su nodo con su user/pass y cambia
sus datos personales. Estos cambios se guardan en el fichero
local-phonedir.csv<br>
<br>
Un admin: Modifica su fichero local node.json con los nuevos datos.
La IP asignada dentro de la VPN no debería cambiarse una vez
funcionando.<br>
<br>
En algún momento los scripts "mapeadores" encontrarán los nuevos
datos y actualizarán los listados de nodos y listines de teléfonos.<br>
<br>
<blockquote
cite="mid:CAF-Hj--6d-PENHtcyiG=w1E+2GROQ98mcdWC1HkZ5AMd18tGrA@mail.gmail.com"
type="cite">
<div><br>
</div>
<div>Y otra duda más, si alguien intenta falsear información,
cambiar datos de usuarios, o asignarse IP's que no le
corresponden, ¿podemos detectarlo?</div>
</blockquote>
<br>
Falsear información: depende qué información y cuanto se lo curre el
atacante. El email y el teléfono de contacto podemos validarlo
automáticamente. El nombre y la localización, no. Pero vamos, que si
dice que se llama Li Hu y está en la conchinchina y en realidad se
llama Juan y está en madrid... tampoco afecta a la red. Para evitar
que use una MAC que ya esté funcionando, podríamos añadir ésta
información al listado de nodos.<br>
<br>
Cambiar datos de usuarios: sólo los de su nodo. También podría
falsear el listín que hay en su nodo. Afectaría sólo a sus usuarios.
Si lo descubren, deberían denunciarlo y buscarse otro nodo PLN más
honrado.<br>
<br>
Asignarse IPs que no le corresponden: esta es más jodida, porque
quizá podrían llegar a hacernos ahora un man-in-the-middle. Para
detectarlo, cada nodo debería lanzar un script cada minuto que haga
lo siguiente:<br>
<br>
1.- tincd -n pln -kusr2<br>
<br>
2.- comprobar en /var/log/syslog que cada IP dentro de la VPN tenga
sólo un owner con una única IP pública.<br>
<br>
3.- Si una IP de la VPN tiene más de un owner o está asociado a
varias IPs públicas:<br>
<br>
* comprobar usando el listado de nodos cual es el auténtico y cual
el falso.<br>
<br>
* mandar un email al admin local y al admin atacado, para que lo
investiguen.<br>
<br>
Si se confirma el ataque, el admin atacado deberá enviar a todos los
admins un email informando del ataque y los datos del nodo atacante
(nombre de host que usa y su IP pública) para que los nodos que le
dan acceso a la red dejen de dárselo y borren la clave pública del
nodo atacante. Además, todos los nodos podrían añadir estos datos a
un fichero pln-blacklist.csv por ejemplo.<br>
<br>
<blockquote
cite="mid:CAF-Hj--6d-PENHtcyiG=w1E+2GROQ98mcdWC1HkZ5AMd18tGrA@mail.gmail.com"
type="cite">
<div><br>
</div>
<div>Un modelo central de almacenamiento de información nos
soluciona estos problemas, pero claro, también nos provoca otros
(modelo catedral en lugar de bazar). No sé, ya te digo que tengo
dudas sobre cómo tener una estructura distribuida y robusta,
inmune a las inconsistencias o falseamiento de datos.</div>
</blockquote>
<br>
¿Tienes alguna duda todavía sobre la robustez de la red?<br>
<br>
<blockquote
cite="mid:CAF-Hj--6d-PENHtcyiG=w1E+2GROQ98mcdWC1HkZ5AMd18tGrA@mail.gmail.com"
type="cite">
<div><br>
</div>
<div>¿Prefieres que el debate lo hagamos en la lista de correo?</div>
<div><br>
</div>
</blockquote>
<br>
:)<br>
<br>
Saludos,<br>
Santiago Crespo.<br>
<br>
<blockquote
cite="mid:CAF-Hj--6d-PENHtcyiG=w1E+2GROQ98mcdWC1HkZ5AMd18tGrA@mail.gmail.com"
type="cite">
<div><br>
<div class="gmail_quote">El 14 de septiembre de 2012 08:40,
Santiago Crespo <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:pln-lists.marsupi.org@flanera.net"
target="_blank">pln-lists.marsupi.org@flanera.net</a>></span>
escribió:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div>Hola David,<br>
<br>
Te respondo debajo:
<div class="im"><br>
<br>
On 14/09/12 08:05, David Rubert wrote:<br>
</div>
</div>
<div class="im">
<blockquote type="cite">Ok todo entendido, sigo teniendo
alguna duda, como por ejemplo como sabe un nodo
distribuido cuál es la última IP libre de la PLN que
puede asignar a un recien llegado,</blockquote>
<br>
</div>
El procedimiento será algo así: consulta su listado de
nodos (local) y hace ping a la última IP +1. Si responde,
ultima IP+2, así hasta encontrar la siguiente IP libre.
Cuanto más actualizado el listado de nodos, menos pings
tendrá que hacer.
<div class="im"><br>
<br>
<blockquote type="cite"> o cómo puede validar que un
número geográfico/no geográfico no está ya cogido por
otro nodo en la red. Para estos casos, ¿no debería
haber algún nodo/nodos central que recibiera/emitiera
información a las consultas de este tipo que le
realizaran el resto de nodos?</blockquote>
<br>
</div>
No hace falta un nodo central: para saber si un número
está disponible, basta con una consulta (que será
automática) desde la terminal de asterisk:<br>
<br>
dundi lookup +03408026100@pln bypass<br>
<br>
El número completo que se consulta es la extensión 0 del
número solicitado. La extensión 0 siempre existe en
cualquier nodo PLN, justamente para tener una manera
sencilla de saber si un número está disponible o no.
<div class="im"><br>
<br>
<blockquote type="cite">
<div> <br>
</div>
<div>Estoy avanzando el tema de la web, estoy con el
formulario de unión a la red, me está costando un
poco pero no estoy desconectado. Cuando haya algo
visible os lo comento.</div>
</blockquote>
<br>
</div>
Bien! :)_<br>
<br>
Por cierto, viste los ejemplos que puse de páginas de
unión de un nuevo nodo y de un nuevo usuario?<br>
<br>
<a moz-do-not-send="true"
href="http://patiomaravillas.dyndns.org/newnode.html"
target="_blank">http://patiomaravillas.dyndns.org/newnode.html</a><br>
<a moz-do-not-send="true"
href="http://patiomaravillas.dyndns.org/newuser.html"
target="_blank">http://patiomaravillas.dyndns.org/newuser.html</a><br>
<br>
El desplegable con todos los "country codes" en
newnode.html está completo y actualizado, por si quieres
usarlo.<br>
<br>
Saludos!<span class="HOEnZb"><font color="#888888"><br>
Santiago Crespo</font></span>
<div>
<div class="h5"><br>
<br>
<blockquote type="cite">
<div><br>
</div>
<div>Venga un saludo<br>
<br>
<div class="gmail_quote">El 11 de septiembre de
2012 16:38, Santiago Crespo <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:pln-lists.marsupi.org@flanera.net"
target="_blank">pln-lists.marsupi.org@flanera.net</a>></span>
escribió:<br>
<blockquote class="gmail_quote" style="margin:0
0 0 .8ex;border-left:1px #ccc
solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div>Hola,<br>
<br>
Te respondo debajo..
<div><br>
<br>
On 11/09/12 15:58, David Rubert wrote:<br>
</div>
</div>
<div>
<blockquote type="cite"><br>
<div>Entonces, no habrá una base de
datos única, sino que el conjunto de
nodos conformarán la base de datos de
nodos, pero nadie tendrá la
información completa, es así?</div>
</blockquote>
<br>
</div>
Efectivamente, no habrá una base de datos
única. Cada nodo tendrá su fichero
"nodelist.csv" (o .json o .txt...)<br>
<br>
Lo ideal es que todos tengan el fichero
nodelist lo más completo y actualizado
posible, pero es totalmente opcional. De
hecho no hace falta el listado de nodos par
funcionar, pues las llamadas al nodo nuevo
funcionan desde el minuto 1 desde cualquier
otro nodo.<br>
<br>
Ahora, el nodelist servirá por ejemplo para:<br>
<br>
* Poder publicar un listado de nodos en la
web pública<br>
* Ahorrar unos cuantos pings y consultas
DUNDi al aceptar un nuevo nodo (a la hora de
asignarle una IP libre y comprobar que la
numeración que pide esté disponible)<br>
* Cualquier otra cosa chula que se nos
ocurra para poner en la web usando la
información pública de nodelist.csv (no
deberían ser públicos el teléfono no-pln ni
el email del admin)
<div><br>
<br>
<blockquote type="cite">
<div>Por otro lado, a qué te refieres
con que actualizarán el listado de
nodos la próxima vez que mapeen la
red? qué implica "mapear la red"?</div>
</blockquote>
<br>
</div>
Opcionalmente, cada nodo podrá tener un
script que cada día (o cada semana) haga un
ping a todas las IPs posibles de la VPN.
Cuando encuentre que alguien responde en una
IP nueva (que no aparece en su nodelist),
hará un wget <a moz-do-not-send="true"
href="http://IP.Nueva/node.json"
target="_blank">http://IP.Nueva/node.json</a>
y así obtiene la información del nuevo nodo.<br>
<br>
También está la opción de en vez de usar un
script que mapee la red, delegar en un git o
en los ficheros que publique otro nodo en el
que confiemos que va a actualizar el listado
de nodos mapeando la red cada cierto tiempo.<br>
<br>
Para el listín telefónico, la misma idea: un
nodo cualquiera, cuando encuentra una IP
nueva, se descarga <a
moz-do-not-send="true"
href="http://IP.Nueva/local-phonedir.csv"
target="_blank">http://IP.Nueva/local-phonedir.csv</a>
y lo añade a su fichero pln-phonedir.csv.
También puede delegar esto a un tercero.
<div><br>
<br>
<br>
<blockquote type="cite">
<div><br>
<br>
<div class="gmail_quote">El 11 de
septiembre de 2012 15:09, Santiago
Crespo <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:pln-lists.marsupi.org@flanera.net"
target="_blank">pln-lists.marsupi.org@flanera.net</a>></span>
escribió:<br>
<blockquote class="gmail_quote"
style="margin:0 0 0
.8ex;border-left:1px #ccc
solid;padding-left:1ex">Hola
David,<br>
<br>
No hace falta pasar ninguna
información al resto de nodos :)<br>
<br>
Lo único que guardarías de mi nodo
sería el acuerdo y los datos que
añadas a tu listado de nodos.<br>
<br>
Luego los demás nodos ya
actualizarán automáticamente sus
listados de nodos la próxima vez
que mapeen la red.<br>
<br>
Saludos,<br>
Santiago Crespo.
<div>
<div><br>
<br>
<br>
On 11/09/12 13:50, David
Rubert wrote:<br>
<blockquote
class="gmail_quote"
style="margin:0 0 0
.8ex;border-left:1px #ccc
solid;padding-left:1ex"> <br>
Mira, imaginemos que tú
accedes a mi nodo y das de
alta la información de tu
nodo, mi nodo lo guarda en
un archivo, en una DB, lo
que sea, pero... cómo
traspasamos esa información
que nos han introducido en
uno de los nodos al resto de
nodos?<br>
<br>
</blockquote>
<br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</body>
</html>