[Ninux-Wireless] Futuro di map.ninux.org

35 views
Skip to first unread message

Nemesis

unread,
Mar 12, 2014, 12:55:57 PM3/12/14
to wire...@ml.ninux.org
La nuova versione di nodeshot non sarà solamente una mappa, ma avrà delle funzionalità aggiuntive molto interessanti relative ai device installati, i servizi, le notifiche e così via.

Avrà senso tenere il nome map.ninux.org? Personalmente credo che il dominio di un servizio è importante in quanto è il primo indizio dell'uso che si fa di quel servizio.

map.ninux.org indica una mappa, mentre la nuova versione di nodeshot è qualcosa di più, potrebbe essere definito come node-database, ma veramente non so come definirlo. Io spero che diventi un sistema decentralizzato dove c'è però un interfaccia unica dove poter accedere facilmente a tutte le informazioni più interessanti della rete e dove poter interagire con gli altri partecipanti.

Sicuramente ci sarà una fase in cui entrambi i sistemi saranno online, almeno finchè la nuova versione non sarà stabile, quindi su map.ninux.org continueremo ad avere quello che c'è ora, mentre su un altro indirizzo avremo il nuovo.

La domanda è: terremo map.ninux.org anche per il nuovo? O scegliamo un nuovo dominio?

Ad esempio:

Nemesis

Saverio Proto

unread,
Mar 12, 2014, 1:39:01 PM3/12/14
to wire...@ml.ninux.org
federico occhio a non prendere la strada di nodewatcher che per voler fare troppo è diventato un carrozzone super complicato che non usa nessuno.

Saverio

Nemesis

unread,
Mar 12, 2014, 2:14:17 PM3/12/14
to wire...@ml.ninux.org
E' importante non ripetere quell'errore e realizzare un sistema modulare con un interfaccia web che sia usabile e intuitiva, altrimenti sarà una merda, ed è quello che sto provando a fare con tutte le mie forze.

Ma sono anche sicuro che con il contributo di tutti faremo un ottimo lavoro, ricordo dopo che abbiamo messo in piedi map.ninux.org abbiamo fatto un grande lavoro (segnalazione e risoluzione bug) per portarlo alla stabilità ed ora è davvero stabile per essere un servizio best effort offerto da volontari nel tempo libero.

Quindi sì, decisamente fare attenzione e portare avanti prima di tutto le feature indispensabili, abbiamo spesso parlato di monitoraggio e grafici del traffico, funzionalità che ho volutamente lasciato fuori al momento per poterne parlare meglio quando arriverà il momento giusto.

Però tornando alla domanda, terresti map.ninux.org o sceglieresti un altro dominio?

Federico
_______________________________________________
Wireless mailing list
Wire...@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Giuseppe De Marco

unread,
Mar 12, 2014, 2:15:27 PM3/12/14
to wire...@ml.ninux.org


federico la morgia

unread,
Mar 12, 2014, 2:33:06 PM3/12/14
to wire...@ml.ninux.org
Ragiono ad orecchio e scusatemi se lo faccio : map è un termine facile da ricordare ed idem per il suo concetto "mapserver" che ricorda molto il servizio di mappe google.
Ora se consideri anche la questione della semplicità e quindi usabilità del nome, il tuo discorso di cambiargli nome è controproducente.
Altro aspetto sul cambio di nome : per quanto sia vasto il numero di servizi che la nuova piattaforma avrà, sarà sempre una mappa il suo scope e quindi anche il suo nome!

Altro aspetto : se proprio vuoi enfatizzare il cambiamento con l'utilizzo di nomi diversi allora devi fare in modo che nomi diversi corrispondano a sezioni di programma diversi.
Quindi map.ecc.ecc per le mappe, devices.ecc.ecc per i devices ecc.ecc.ecc.

Il tuo sperare nel decentramento è sotto il punto di vista dell'intero software o dei singoli moduli che lo compongono ?

In ogni modo è un argomento molto interessante.

--- Messaggio originale ---

Da: "Nemesis" <nem...@ninux.org>
Inviata: 12 marzo 2014 18:09
A: wire...@ml.ninux.org
Oggetto: [Ninux-Wireless] Futuro di map.ninux.org

BornAgain

unread,
Mar 12, 2014, 2:33:54 PM3/12/14
to wire...@ml.ninux.org
Il giorno 12/mar/2014, alle ore 19.14, Nemesis ha scritto:

E' importante non ripetere quell'errore e realizzare un sistema modulare con un interfaccia web che sia usabile e intuitiva, altrimenti sarà una merda, ed è quello che sto provando a fare con tutte le mie forze.

Ma sono anche sicuro che con il contributo di tutti faremo un ottimo lavoro, ricordo dopo che abbiamo messo in piedi map.ninux.org abbiamo fatto un grande lavoro (segnalazione e risoluzione bug) per portarlo alla stabilità ed ora è davvero stabile per essere un servizio best effort offerto da volontari nel tempo libero.

Quindi sì, decisamente fare attenzione e portare avanti prima di tutto le feature indispensabili, abbiamo spesso parlato di monitoraggio e grafici del traffico, funzionalità che ho volutamente lasciato fuori al momento per poterne parlare meglio quando arriverà il momento giusto.

Però tornando alla domanda, terresti map.ninux.org o sceglieresti un altro dominio?

IMHO terrei quello, ormai lo conoscono tutti, è su tutte le brochure e materiale vario del wiki. fintanto che non abbiamo una stable del nuovo nodeshot all'ingresso un pop up ti chiederà se vuoi accedere al vecchio o al nuovo, avvisandoti che nel nuovo ci potrebbe essere qualche bug, di cui si spera ci avvertirai.

My 2c

--------------------
BornAgain
PGP.sig

Luca Postregna

unread,
Mar 12, 2014, 2:48:30 PM3/12/14
to wire...@ml.ninux.org
nodedb.ninux.org non è male. ho provato ad aprire la demo linkata nella lista nodeshot, ma sembra non essere più disponibile.
a me incuriosisce molto anche la mappa che stanno sviluppando quelli di libremesh
--

Alessandro Gubitosi

unread,
Mar 12, 2014, 4:19:27 PM3/12/14
to wire...@ml.ninux.org
map.ninux.org lo conoscono tutti ed è su tutto il materiale promozionale, ergo non dovrà cambiare mai, almeno per l'utente "esterno".
Per quanto riguarda admin e altre features si può fare come si vuole ;)

My bit suggestion
Gubi
Il 12/03/2014 17:55, Nemesis ha scritto:
La nuova versione di nodeshot non sarà solamente una mappa, ma avrà delle funzionalità aggiuntive molto interessanti relative ai device installati, i servizi, le notifiche e così via.

Avrà senso tenere il nome map.ninux.org? Personalmente credo che il dominio di un servizio è importante in quanto è il primo indizio dell'uso che si fa di quel servizio.

map.ninux.org indica una mappa, mentre la nuova versione di nodeshot è qualcosa di più, potrebbe essere definito come node-database, ma veramente non so come definirlo. Io spero che diventi un sistema decentralizzato dove c'è però un interfaccia unica dove poter accedere facilmente a tutte le informazioni più interessanti della rete e dove poter interagire con gli altri partecipanti.

Sicuramente ci sarà una fase in cui entrambi i sistemi saranno online, almeno finchè la nuova versione non sarà stabile, quindi su map.ninux.org continueremo ad avere quello che c'è ora, mentre su un altro indirizzo avremo il nuovo.

La domanda è: terremo map.ninux.org anche per il nuovo? O scegliamo un nuovo dominio?

Ad esempio:

Nemesis



signature.asc

l0aCk3r [matteo]

unread,
Mar 13, 2014, 2:25:48 AM3/13/14
to wire...@ml.ninux.org
On 03/12/2014 05:55 PM, Nemesis wrote:
[CUT]
>
> Ad esempio:
>
> * nodes.ninux.org
> * nodedb.ninux.org
> * nodeshot.ninux.org

Per quanto riguarda map.ninux.org non è un problema perché quando
dismetteremo la versione 1.0 potremmo fare un CNAME sul dns.
Siccome è un software molto generico e non legato esclusivamente ad una
mappa io userei il nome del software stesso, quindi voto per
"nodeshot.ninux.org".

Possiamo anche usare il nome "nodewatcher.ninux.org" :-)))

--
loacker
"MEMBRO" della FFCS

Giuseppe De Marco

unread,
Mar 13, 2014, 4:22:51 AM3/13/14
to wire...@ml.ninux.org
Il giorno 12 marzo 2014 19:33, federico la morgia <super...@hotmail.com> ha scritto:
Ragiono ad orecchio e scusatemi se lo faccio : map è un termine facile da ricordare ed idem per il suo concetto "mapserver" che ricorda molto il servizio di mappe google.

Un pò collide con "MapServer" che è il server WMS nudo e crudo (che io uso con mappe mie al posto di google maps): http://mapserver.org/. Un server di Mappe è un servizio che eroga mappe, nodeshot eroga molto più di singole mappe in forma di tiles.
 
Ora se consideri anche la questione della semplicità e quindi usabilità del nome, il tuo discorso di cambiargli nome è controproducente.
Altro aspetto sul cambio di nome : per quanto sia vasto il numero di servizi che la nuova piattaforma avrà, sarà sempre una mappa il suo scope e quindi anche il suo nome!

Luca Pretto

unread,
Mar 13, 2014, 5:04:01 AM3/13/14
to wire...@ml.ninux.org
Il giorno 13/mar/2014, alle ore 07:25, l0aCk3r [matteo] <mat...@ninux.org> ha scritto:

Per quanto riguarda map.ninux.org non è un problema perché quando
dismetteremo la versione 1.0 potremmo fare un CNAME sul dns.
Siccome è un software molto generico e non legato esclusivamente ad una
mappa io userei il nome del software stesso, quindi voto per
"nodeshot.ninux.org".

Questa mi sembra una buona soluzione.
In genere è il primo servizio a cui indirizzo la gente interessata.
map.ninux.org è comprensibile anche dagli umani non-nerd, spiegare nodsciot diverrebbe un'impresa.
signature.asc

Nemesis

unread,
Mar 13, 2014, 5:48:59 AM3/13/14
to wire...@ml.ninux.org
Vediamo in ordine.

La demo attuale è qui: https://nodeshot-demo.publicwifi.it/ - ma non ci sono i dati di ninux, entro 2 settimane vi manderò la URL dell'instanza con i dati di ninux.

La decentralizzazione è riferita ai gruppi, idealmente dovrebbe essere possibile hostare diverse instanze con i dati di ogni gruppo che si vuole tenere i dati su un suo server. In pratica al momento questa è una funzionalità sperimentale che è anche visibile qui: https://nodeshot-demo.publicwifi.it/#/map - i punti verdi sono presi da un servizio esterno tramite un API HTTP.

Il fatto che map.ninux.org è linkato un pò dappertutto non è un problema, vi ricordo che esistono i redirect (HTTP 302).

Il fatto che "map" è facile da ricordare e che è molto più facile spiegare ad un comune mortale rispetto a "nodesciot" quasi basta a convincermi che è meglio tenere map.

Comunque rimane il fatto che su nodeshot c'è un API che può essere utilizzata per recuperare i dati, quindi volendo possiamo mostrare i dati con dei widget javascript anche sul sito.

A sto punto direi che in futuro potremmo avere una cosa tipo:
che ne dite?
signature.asc

federico la morgia

unread,
Mar 13, 2014, 6:06:33 AM3/13/14
to wire...@ml.ninux.org
Tutto OK fede, un piccolo dubbio sul terzo indirizzo: secondo te è più pratico l'indirizzo da te proposto oppure una cosa del tipo : mapv1.ninux.org ?


--- Messaggio originale ---

Da: "Nemesis" <nem...@ninux.org>
Inviata: 13 marzo 2014 11:02
A: wire...@ml.ninux.org
Oggetto: Re: [Ninux-Wireless] Futuro di map.ninux.org

Alessandro Gubitosi

unread,
Mar 13, 2014, 8:43:36 AM3/13/14
to wire...@ml.ninux.org
Assolutamente d'accordo per tutto, tranne che per gli ultimi 2 DNS, che secondo me dovrebbero essere universali.
In pratica un dns api.ninux.org, dovrà raccogliere tutte le api di tutti gli applicativi Ninux, perché viene più logico pensarla così.
Nel tuo caso specifico potrebbe ad esempio diventare come uno di questi esempi:
 Stessa cosa per quanto riguarda l'admin (ad es. admin.ninux.org/map, ecc...)

Lo stesso principio si può applicare anche al resto: all'admin del wiki potrebbe essere allocato admin.ninux.org/wiki e per le sue api sarà api.ninux.org/wiki...
La struttura logica è la seguente:

Quindi avremo:

I benefici saranno tanti, ad esempio grazie ad admin.ninux.org si potrà avere un incentivo per creare finalmente un account unificato per tutti i servizi Ninux, mentre api.ninux.org potrà raccogliere un mini-sito che indica tutti i servizi disponibili e le relative documentazioni...
Immaginiamo poi di volerci interfacciare ad un'altra app Ninux: gli scervellamenti saranno nettamente minori, perché basta cambiare terzo livello e il gioco è fatto!
Il consiglio logico è che se un'applicativo avrà il suo terzo livello, questo dovrà essere mantenuto negli altri dns, per capirci: pincopallo.ninux.org avrà admin.ninux.org/pincopallo e api.ninux.org/pincopallo.

In ultimo ricordo che lato sviluppo (eccetto rari casi) non è necessario fare alcunché, perché basta il semplice url rewriting (api.ninux.org/wiki/v1/ potrà essere un rewriting di "wiki.ninux.org/API/VersioneProva/test/2/14/23/?version=1").
In Apache è una riga di .htaccess, e credo sia così anche per altri server.

In sintesi, prendiamo esempio da Google :D

Gubi

signature.asc

Giuseppe De Marco

unread,
Mar 13, 2014, 9:52:09 AM3/13/14
to wire...@ml.ninux.org
nodeshot può incarnare un brand


Nemesis

unread,
Mar 16, 2014, 6:32:15 AM3/16/14
to wire...@ml.ninux.org
Logicamente non fa una piega, però è un pò più complesso da configurare, perchè bisognerebbe mettere un unico webserver che raccoglie tutte le richieste e fa un "proxypass" ad altri server.

Siccome so che il nostro tempo e le nostre risorse sono limitate credo che opterò per tenere tutto su *map.ninux.org*, il che rende tutto più facile da configurare.

Quindi deployerò nodeshot2 su un unico dominio, almeno inizialmente. Potremo sempre cambiare la configurazione qualora lo riterremo necessario.

Mi sono ricordato che già abbiamo questo registrato: *test.map.ninux.org*, riciclerò quello.

Un ultima cosa, chiamiamolo network map o netmap perchè map server è un altra cosa: http://mapserver.org/ http://en.wikipedia.org/wiki/MapServer

Nemesis



On 03/13/2014 01:43 PM, Alessandro Gubitosi wrote:
> Assolutamente d'accordo per tutto, tranne che per gli ultimi 2 DNS, che secondo me dovrebbero essere universali.
> In pratica un dns api.ninux.org, dovrà raccogliere tutte le api di tutti gli applicativi Ninux, perché viene più logico pensarla così.
> Nel tuo caso specifico potrebbe ad esempio diventare come uno di questi esempi:
>

>
> Stessa cosa per quanto riguarda l'admin (ad es. admin.ninux.org/map, ecc...)
>
> Lo stesso principio si può applicare anche al resto: all'admin del wiki potrebbe essere allocato admin.ninux.org/wikie per le sue api sarà api.ninux.org/wiki...

> La struttura logica è la seguente:
>
>   * *admin*.
>       o ninux.org/
>           + /map//
>               # v1/     (*admin*.ninux.org//map//v1)
>               # v2/     (*admin*.ninux.org//map//v1)
>               # ...
>           + /wiki/     (*admin*.ninux.org//wiki/)
>           + /ninuxoo/     (*admin*.ninux.org//ninuxoo/)
>           + ...
>   * *api*.
>       o ninux.org/
>           + /map//
>               # v1/     (*api*.ninux.org//map//v1)
>           + /wiki//     (*api*.ninux.org//w//iki/)
>           + /ninuxoo//     (*api*.ninux.org//ninuxoo/)
>           + ...
>
> Quindi avremo:
>
>   * admin.ninux.org/map
>   * admin.ninux.org/wiki
>   * admin.ninux.org/ninuxoo
>   * admin.ninux.org/...
>
>   * api.ninux.org/map
>   * api.ninux.org/wiki
>   * api.ninux.org/ninuxoo
>   * api.ninux.org/...
>
> I benefici saranno tanti, ad esempio grazie ad admin.ninux.orgsi potrà avere un incentivo per creare finalmente un account unificato per tutti i servizi Ninux, mentre api.ninux.orgpotrà raccogliere un mini-sito che indica tutti i servizi disponibili e le relative documentazioni...

> Immaginiamo poi di volerci interfacciare ad un'altra app Ninux: gli scervellamenti saranno nettamente minori, perché basta cambiare terzo livello e il gioco è fatto!
> Il consiglio logico è che se un'applicativo avrà il suo terzo livello, questo dovrà essere mantenuto negli altri dns, per capirci: *pincopallo*.ninux.orgavrà admin.ninux.org/*pincopallo*e api.ninux.org/*pincopallo*.
>
> In ultimo ricordo che lato sviluppo (eccetto rari casi) non è necessario fare alcunché, perché basta il semplice *url rewriting* (api.ninux.org/wiki/v1/potrà essere un rewriting di "wiki.ninux.org/API/VersioneProva/test/2/14/23/?version=1").

> In Apache è una riga di .htaccess, e credo sia così anche per altri server.
>
> In sintesi, prendiamo esempio da Google :D
>
> Gubi
>
> Il 13/03/2014 10:48, Nemesis ha scritto:
>> Vediamo in ordine.
>>
>> La demo attuale è qui: https://nodeshot-demo.publicwifi.it/ - ma non ci sono i dati di ninux, entro 2 settimane vi manderò la URL dell'instanza con i dati di ninux.
>>
>> La decentralizzazione è riferita ai gruppi, idealmente dovrebbe essere possibile hostare diverse instanze con i dati di ogni gruppo che si vuole tenere i dati su un suo server. In pratica al momento questa è una funzionalità sperimentale che è anche visibile qui: https://nodeshot-demo.publicwifi.it/#/map - i punti verdi sono presi da un servizio esterno tramite un API HTTP.
>>
>> Il fatto che map.ninux.org è linkato un pò dappertutto non è un problema, vi ricordo che esistono i redirect (HTTP 302).
>>
>> Il fatto che "map" è facile da ricordare e che è molto più facile spiegare ad un comune mortale rispetto a "nodesciot" quasi basta a convincermi che è meglio tenere map.
>>
>> Comunque rimane il fatto che su nodeshot c'è un API che può essere utilizzata per recuperare i dati, quindi volendo possiamo mostrare i dati con dei widget javascript anche sul sito.
>>
>> A sto punto direi che in futuro potremmo avere una cosa tipo:
>>
>>   * map.ninux.org: interfaccia web nodeshot
>>   * admin.ninux.org: interfaccia di amministrazione di nodeshot
>>   * api.ninux.org/v1: API v1 di nodeshot, dove si possono recuperare tutti i dati pubblici

>>
>> che ne dite?
>>
>> 
>>
>> On 03/13/2014 10:04 AM, Luca Pretto wrote:
>>> Il giorno 13/mar/2014, alle ore 07:25, l0aCk3r [matteo] <mat...@ninux.org <mailto:mat...@ninux.org>> ha scritto:
>>>
>>>> Per quanto riguarda map.ninux.org <http://map.ninux.org/> non è un problema perché quando

>>>> dismetteremo la versione 1.0 potremmo fare un CNAME sul dns.
>>>> Siccome è un software molto generico e non legato esclusivamente ad una
>>>> mappa io userei il nome del software stesso, quindi voto per

>>>
>>> Questa mi sembra una buona soluzione.
>>> In genere è il primo servizio a cui indirizzo la gente interessata.
>>> map.ninux.org <http://map.ninux.org> è comprensibile anche dagli umani non-nerd, spiegare /nodsciot/ diverrebbe un'impresa.
signature.asc

Andrea Grillini

unread,
Mar 22, 2014, 9:36:03 AM3/22/14
to wire...@ml.ninux.org
2014-03-12 19:14 GMT+01:00 Nemesis <nem...@ninux.org>:
> Quindi sì, decisamente fare attenzione e portare avanti prima di tutto le
> feature indispensabili, abbiamo spesso parlato di monitoraggio e grafici del
> traffico, funzionalità che ho volutamente lasciato fuori al momento per
> poterne parlare meglio quando arriverà il momento giusto.

Forse non ho avuto pazienza di leggere bene, ma mi pare che in questo
thread si sia parlato quasi solo di un nome nel DNS. Da tempo
fantasticavo un ausilio grafico in sostituzione dei miei traceroute "a
manella" e dopo aver letto il titolo forse sono andato un po' troppo
avanti con le aspettative. Sono digiuno anche delle nozioni di base
che stanno dietro a map.ninux.org e a sue evenutali evoluzioni. Visto
che però comunque siamo in tema, qualcuno mi può suggerire da dove
partire per evitare di scoprire "acque calde" o spendere tempo su
qualcosa che qualcuno forse ha già quasi pronto? Il film che ho in
testa è: vedo su una mappa il tragitto dei miei pacchetti per arrivare
ad un determinato host.

Grazie


A.

Alessandro Gnagni

unread,
Mar 22, 2014, 10:05:21 AM3/22/14
to wire...@ml.ninux.org
intendi una cosa tipo questa:

traceroute to maggie.sig.nnx (10.39.0.4), 30 hops max, 60 byte packets
1 hal-edge.halnet.nnx (10.135.2.5) 0.700 ms 0.679 ms 0.661 ms
2 wifi.m5cdampezzocsansoni.nazzanode2.net.nnx (172.16.135.11) 3.791
ms 4.963 ms 6.362 ms
3 giordani2cdampezzo.nbgiordani2cdampezzo.a68giordani.net.nnx
(172.16.159.25) 7.911 ms 6.976 ms 16.476 ms
4 wifi.m5cdpazzigiordani.darkness.net.nnx (172.16.156.3) 12.635 ms
17.596 ms 17.566 ms
5 wifi.ppccarnarolo.sar.net.nnx (172.16.10.5) 21.871 ms 23.172 ms
30.541 ms
6 maggie.sig.nnx (10.39.0.4) 35.329 ms 36.292 ms 36.942 ms

federico la morgia

unread,
Mar 22, 2014, 10:50:05 AM3/22/14
to wire...@ml.ninux.org
Non so se ho capito bene, cerchi un visualtraceroute ma con tutto il percorso disegnato e che sia attinente ai nodi di ninux, giusto ?
In rete non sono riuscito a trovare nulla di "sensato" in quanto tutti questi servizi essendo esterni non possono essere utilizzati dentro ninux in ipv4.
Forse se il servizio esistesse in ipv6 qualche cosa di meglio si potrebbe fare, tu però non potresti utilizzarlo visto che non sei su rete ipv6, basterebbe configurarlo e staresti a posto !
Tornando al problema : per avere un traceroute visuale bisogna che esso sia integrato nel map server sia perchè attualmente è l'unico sistema che ha la posizione delle antenne, sia perchè pochissimi nodi, se non nessuno, ha nella sua configurazione di airos la posizione geografica dell'antenna e quindi se il programma richiesse queste info si potrebbe creare un programma "esterno" al mapserver (dove sono attualmente presenti le info più o meno corrette del posizionamento geografico dei nodi).
Spero di averti chiarito il punto della situazione per quello che chiedi, che debbo dire che un suo fascino ce lo ha!

> Date: Sat, 22 Mar 2014 14:36:03 +0100
> From: andrea....@gmail.com
> To: wire...@ml.ninux.org
> Subject: Re: [Ninux-Wireless] Futuro di map.ninux.org

Andrea Grillini

unread,
Mar 22, 2014, 11:42:35 AM3/22/14
to wire...@ml.ninux.org
2014-03-22 15:05 GMT+01:00 Alessandro Gnagni <enterp...@gmail.com>:
> intendi una cosa tipo questa:
>
> traceroute to maggie.sig.nnx (10.39.0.4), 30 hops max, 60 byte packets
> 1 hal-edge.halnet.nnx (10.135.2.5) 0.700 ms 0.679 ms 0.661 ms
> 2 wifi.m5cdampezzocsansoni.nazzanode2.net.nnx (172.16.135.11) 3.791
> ms 4.963 ms 6.362 ms
> 3 giordani2cdampezzo.nbgiordani2cdampezzo.a68giordani.net.nnx
> (172.16.159.25) 7.911 ms 6.976 ms 16.476 ms
> 4 wifi.m5cdpazzigiordani.darkness.net.nnx (172.16.156.3) 12.635 ms
> 17.596 ms 17.566 ms
> 5 wifi.ppccarnarolo.sar.net.nnx (172.16.10.5) 21.871 ms 23.172 ms
> 30.541 ms
> 6 maggie.sig.nnx (10.39.0.4) 35.329 ms 36.292 ms 36.942 ms

Dall'esempio che hai riportato mi sembra comunque un "caso felice":
gli indirizzi IP sono associati ad un nome che FORSE dice qualcosa
dell'host! Peraltro è comunque fratello dei miei meticolosi e
scoraggianti traceroute manuali: da un risultato in caratteri del
genere devo ricostruirmi il percorso sulla mappa, senza conoscere la
topologia che spesso non è esplicita, mi riferisco a degli indirizzi
IP che fanno capo ad uno stesso supernodo, ma che certo non colleghi a
quel supernodo in modo automatico, devi sempre consultare una
tabella... :-(

Andrea Grillini

unread,
Mar 22, 2014, 11:46:20 AM3/22/14
to wire...@ml.ninux.org
2014-03-22 15:50 GMT+01:00 federico la morgia <super...@hotmail.com>:
> Non so se ho capito bene, cerchi un visualtraceroute ma con tutto il
> percorso disegnato e che sia attinente ai nodi di ninux, giusto ?
> In rete non sono riuscito a trovare nulla di "sensato" in quanto tutti
> questi servizi essendo esterni non possono essere utilizzati dentro ninux in
> ipv4.
> Forse se il servizio esistesse in ipv6 qualche cosa di meglio si potrebbe
> fare, tu però non potresti utilizzarlo visto che non sei su rete ipv6,
> basterebbe configurarlo e staresti a posto !
> Tornando al problema : per avere un traceroute visuale bisogna che esso sia
> integrato nel map server sia perchè attualmente è l'unico sistema che ha la
> posizione delle antenne, sia perchè pochissimi nodi, se non nessuno, ha
> nella sua configurazione di airos la posizione geografica dell'antenna e
> quindi se il programma richiesse queste info si potrebbe creare un programma
> "esterno" al mapserver (dove sono attualmente presenti le info più o meno
> corrette del posizionamento geografico dei nodi).
> Spero di averti chiarito il punto della situazione per quello che chiedi,
> che debbo dire che un suo fascino ce lo ha!

Hai centrato la mia "fantasia". E ti ringrazio per gli spunti. Ora
però, mi domando, ma un compromesso fra le ricostruzioni laboriose a
suon di traceroute e consultazione della tabella indirizzi e il
sistema "visuale" non sarebbe comunque possibile senza troppi sforzi?
Non si può gestire un DB di indirizzi invece che una tabella
consultabile solo con un paio di occhi? Penso ad uno scrittozzo che mi
aiuta a esplicitare i passaggi del traceroute in termini di
"appartenenze" ai supernodi...

federico la morgia

unread,
Mar 22, 2014, 12:26:35 PM3/22/14
to wire...@ml.ninux.org
Guarda attualmente la cosa non visuale che ci si avvicina di più è usando i dns di ninux che traducono in automatico quegli indirizzi ip "sconosciuti" in nomi di tratta.
Che poi sia userfriendly l'uso di un determinato schema di nomi quello è un altro discorso.

> Date: Sat, 22 Mar 2014 16:46:20 +0100

> From: andrea....@gmail.com
> To: wire...@ml.ninux.org
> Subject: Re: [Ninux-Wireless] Futuro di map.ninux.org
>

Andrea Grillini

unread,
Mar 22, 2014, 12:52:04 PM3/22/14
to wire...@ml.ninux.org
2014-03-22 17:26 GMT+01:00 federico la morgia <super...@hotmail.com>:
> Guarda attualmente la cosa non visuale che ci si avvicina di più è usando i
> dns di ninux che traducono in automatico quegli indirizzi ip "sconosciuti"
> in nomi di tratta.
> Che poi sia userfriendly l'uso di un determinato schema di nomi quello è un
> altro discorso.

Allora stamo freschi... ;-) Forse mi sfugge qualcosa, ma per il
momento mi sembra che tutto quello che servirebbe sarebbe mantenere
dei record che specifichino per ogni indirizzo IP il nodo o supernodo
di appartenenza, ne potrei tirare fuori una lista SEMPLIFICATA di
salti, dove isolo i nomignoli dei nodi o supernodi, saltando a pie'
pari i salti da una interfaccia wifi all'altra di uno stesso
supernodo. Già da questo tracciamento semplificato individuare i salti
sulla mappa sarebbe MOOOOLTO più facile... Mettici pure che se so che
un indirizzo che pure non sia associato ad un nome nel DNS comunque
appartiene ad un certo nodo, automaticamente in caso di problemi -
packet loss, per esempio - saprei subito chi contattare o chi chiamare
in causa...

Andrea Pescetelli

unread,
Mar 22, 2014, 1:40:21 PM3/22/14
to ninux. org [ninux_wireless]

Ciao
Spiriteye

Perche' non inizi a mettere su carta qualcosa per iniziare?

Andrea Grillini

unread,
Mar 22, 2014, 2:16:08 PM3/22/14
to wire...@ml.ninux.org
2014-03-22 18:40 GMT+01:00 Andrea Pescetelli <andrea.p...@gmail.com>:
> Ciao
> Spiriteye
>
> Perche' non inizi a mettere su carta qualcosa per iniziare?

Bella Zio Fish! :-) Si comincia col chiedere se proprio non ci sia già
nulla, e quello l'ho fatto. Su carta si può mettere la stuttura di un
db che sostituirebbe la tabella statica sul sito, poi il db bisogna
metterlo su e ci vuole la dedizione e l'ordine nel tenerlo aggiornato
che, come sai, su una rete che procede su uno standard di qualità
"best effort", è facile perdersi per strada... :-(

federico la morgia

unread,
Mar 22, 2014, 2:17:15 PM3/22/14
to wire...@ml.ninux.org


> Date: Sat, 22 Mar 2014 17:52:04 +0100

> From: andrea....@gmail.com
> To: wire...@ml.ninux.org
> Subject: Re: [Ninux-Wireless] Futuro di map.ninux.org

> Allora stamo freschi... ;-) Forse mi sfugge qualcosa, ma per il
> momento mi sembra che tutto quello che servirebbe sarebbe mantenere
> dei record che specifichino per ogni indirizzo IP il nodo o supernodo
> di appartenenza, ne potrei tirare fuori una lista SEMPLIFICATA di
> salti, dove isolo i nomignoli dei nodi o supernodi, saltando a pie'
> pari i salti da una interfaccia wifi all'altra di uno stesso
> supernodo.

e questo già già succede se usi i dns di ninux e cioè 10.11.12.13 oppure il nuovo 10.10.10.10 (ma non so se è attualmente attivo)


> Già da questo tracciamento semplificato individuare i salti
> sulla mappa sarebbe MOOOOLTO più facile...

Ed infatti è facile ma visto che si è scelto un determinato schema di nomi, forse ragionando sullo schema si potrebbe migliorare la cosa anche se a conti fatti forse è già al massimo possibile, purtroppo rappresentare in una riga una tratta wifi non è sempre facile.


> Mettici pure che se so che
> un indirizzo che pure non sia associato ad un nome nel DNS comunque
> appartiene ad un certo nodo, automaticamente in caso di problemi -
> packet loss, per esempio - saprei subito chi contattare o chi chiamare
> in causa...
>

Credo che per questa cosa serva un tracert tipo quello che abbiamo sull'antenna peccato che ciò carichi il chip dell'antenna, quindi meglio svilcolare per il più semplice etx preso tramite snmp che si può prendere tramite l'indirizzo dell'antenna.

Andrea Pescetelli

unread,
Mar 22, 2014, 2:37:25 PM3/22/14
to ninux. org [ninux_wireless]

Inizia ad indicare la via :)
Proponi e metti su carta qualcosa,affiancati a chi sta lavorando gia sul nodeshot per incrementare e scrivere questa feature.
Chi ben comincia e' a meta' dell opera e chi mai comincia e' ncojoxe :)

Aggiungetela alle mie citazioni.

Bella Spiriteye!

Andrea Grillini

unread,
Mar 23, 2014, 9:18:39 AM3/23/14
to wire...@ml.ninux.org
2014-03-22 19:37 GMT+01:00 Andrea Pescetelli <andrea.p...@gmail.com>:
> Inizia ad indicare la via :)
> Proponi e metti su carta qualcosa,affiancati a chi sta lavorando gia sul
> nodeshot per incrementare e scrivere questa feature.

Cado parecchio dalle nuvole: non so a chi rivolgermi. A prescindere da
questo, il punto di partenza è sempre la solita "Gestione Indirizzi".
I dati stanno là, bisogna partire da quelli. Esiste una colonna
"Mapserver", ma non sempre la relativa casella è riempita. Perché
probabilmente si pensano come "indirizzi del nodo" solo gli indirizzi
delle interfacce wi-fi. Servirebbe piuttosto una colonna "nodo di
pertinenza", da riempire anche nel caso in cui si tratta di indirizzi
IP di unità interne alla rete locale del nodo. Sicuramente non posso
fare tutto da solo, ci vuole una mente sicura di sé che modifichi
quella tabella, eventualmente aggiungendo le informazioni che mancano.
In alternativa mi faccio un DB locale che uso e gestisco senza contare
su nessuno, almeno finché non ci si mette d'accordo per gestire i dati
pubblici...
Reply all
Reply to author
Forward
0 new messages