Re: [Ninux-Wireless] PicoPeering e peering obligation
Molto semplicemente, Elena, che se su un'antenna che hai in AP ci sono 3-4
clients alla stessa distanza ed il tutto è già in funzione e funziona bene, se
uno ti arriva da 40-50 km sicuramente ti fa più danno che altro, anche se è
liberissimo di collegarsi.
Non solo, ma se va pure a creare due link molto instabili che accorciano le
distanze tra due punti all'opposto di una rete, sai che succede in una rete con
routing olsr ? succede che tutto il traffico che va da una parte all'altra
della rete passerà da quel nodo andando praticamente a rendere la rete
inservibile.
Secondo me il picopeering è corretto usarlo ma è corretto usarlo solo in
maniera corretta e cioè prima di fare un link le due persone si devono parlare
per mettersi d'accordo su come realizzarlo per realizzarlo al meglio e non
arrecare fastidio ad altre persone.
Io credo che questo sia il miglior modo di utilizzare un picopeering.
Federico.
Da: wireless-boun...@ml.ninux.org per conto di
Elena ``of Valhalla''
Inviato: venerdì 16 settembre 2016 00.24.41
A: wireless@ml.ninux.org
Oggetto: Re: [Ninux-Wireless] PicoPeering e peering obligation
On 2016-09-15 at 19:17:58 +0200, Stefano De Carlo wrote:
> * Non c'è nessun requisito di no-auth nel PPA, solo di "pubblicazione delle
> info necessarie ad instaurare il peering"
> * L'obbligazione al peering ("chiunque") non fa parte del PPA. È la
> principale differenza tra il PPA e la Free Networks Definition [1]
>
> Questa precisazione è secondo me importantissima perché c'è certamente una
> fetta di partecipanti a Ninux che ritiene che non dovrebbe essere, a priori,
> consentito rifiutare il peering anche solo in qualche caso. Ma è un errore
> considerare il PPA come sorgente di questo requisito o (di conseguenza)
> presumere che questo requisito sia già universalmente in essere in Ninux.
uhm, ma se le informazioni per il peering sono pubblicate, cosa
impedisce tecnicamente ad una persona che si trova nel posto giusto¹ di
collegarsi e peerare?
¹ e quindi non ha bisogno di modifiche di puntamento delle antenne
--
Elena ``of Valhalla''
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless
Re: [Ninux-Wireless] Massively distributed Openstack
Sarebbe interessantissimo se ci facessi vedere un'installazione completa di uno stack openstack su una macchina andandoci a parlare dei suoi vari componenti. Federico. Da: wireless-boun...@ml.ninux.org per conto di Saverio Proto Inviato: giovedì 15 settembre 2016 17.53 A: wireless Oggetto: Re: [Ninux-Wireless] Massively distributed Openstack devstack è come usare tutti i giorni Linux con il LiveCD per capirsi. openstack single node si fa solo a scuola per didattica, o per provare una patch. scrivo da cellulare. quando avrò una tastiera vera sottomano risponderò piu decentwmente. sorry ma vogliamo fare una serata a tema a Roma la prossima volta che scendo ? Saverio ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless
Re: [Ninux-Wireless] NodogSplash e Traffic Control
Il 15/09/2016 18:07, Saverio Proto ha scritto: > > ma usare: > https://www.relakks.com/ > > gia lo usavamo al Fusolab anni fa > > Saverio > puoi riassumere perché usare proprio questa (o comunque, perché fu scelta) rispetto ad altri provider VPN? ho letto ma non sono riuscito a trovare nessun motivo ovvio. Stefanauss signature.asc Description: OpenPGP digital signature ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless
Re: [Ninux-Wireless] PicoPeering e peering obligation
Il 16/09/2016 00:24, Elena ``of Valhalla'' ha scritto: > uhm, ma se le informazioni per il peering sono pubblicate, cosa > impedisce tecnicamente ad una persona che si trova nel posto giusto¹ di > collegarsi e peerare? > > ¹ e quindi non ha bisogno di modifiche di puntamento delle antenne Le "informazioni per il peering" non devono per forza sottintendere ad una procedura gestibile in completa autonomia. Ad esempio tra le informazioni pubblicate ci può essere l'istruzione di fornire il MAC address per l'inserimento nella whitelist dei client ammessi. O quant'altro. Il PPA non si addentra in specificità tecnologiche o procedurali. In generale, l'assenza di impedimenti tecnici alla connessione autonoma non implica che il peering non possa essere rifiutato post-connessione. Ovviamente il no-auth rimane sensato se, tra le altre cose, prevedo che il rifiuto di fare peering con un altro membro della free network sia sempre e solo una extrema ratio. Stefanauss. signature.asc Description: OpenPGP digital signature ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless
Re: [Ninux-Wireless] NodogSplash e Traffic Control
Il 14/09/2016 19:16, Michele Salerno ha scritto: > Il discorso di mettere un hotspot è solo ed esclusivamente informativo > per il passante sotto casa che non conosce ninux e darsi una lettura > se interessato. > Tanta gente comune non sa neanche che esiste. Io che ho un bagaglio di > 15 anni nel settore informatico, solo 2 anni fa ho scoperto Ninux per > caso su google ed è stato amore a prima lettura del Manifesto. > > Questa cosa diverrebbe anche proponibile ad amici che hanno attività > commerciali come bar, pub, ristoranti etc > Non gli vai a saturare la linea ADSL con tutti i clienti seduti ai > tavoli, non dai accesso alla rete interna dove magari c'è il POS, il > tablet delle ordinazioni etc... Dai informazioni ai clienti sulla rete > Ninux, sulla spashpage puoi metterci il loghino del pub etc... > > Lo scopo è solo quello della promozione di Ninux dando un semplice, > banale accesso ad internet ma prevenire e tutelare chi mette il > servizio a disposizione di sconosciuti, negando al 100% l'accesso alla > rete Ninux perchè deve essere tutelata anche quella da sconosciuti. > > Il discorso AP sulla backbone non ha nessun limite ed è aperta, non ha > dhcpse non lo conosco, vado in gestione indirizzi di ninux.org e > vedo chi è, chiedo in ML, chiedo in chat su telegram, chiedo al resto > del gruppo nella mia zona, etc... > > Spero di aver spiegato meglio lo scopo di implementare un hotspot e di > usare il Traffic Control. Secondo me è un discorso anche condivisibile, ma c'è una grossa contraddizione tra la tua intenzione e l'implementazione che descrivi. Ovvero: dici che la motivazione primaria è la promozione di Ninux, eppure nel processo blocchi completamente l'accesso alla rete libera che vuoi promuovere, con le risorse/servizi DIY e comunitarie che contiene, e invece l'unica cosa che consenti è l'accesso (pure non neutrale, nel tuo caso) ad una rete non-libera. Non fila, IMO. Che modo migliore di promuovere Ninux ci può essere se non usarla e vedere com'è, chi ci sta, che ci sta, come si usa? La splash informativa ci può stare, ma come complemento. Come unico sbocco ninuxaro, quando c'è quell'alternativa, no. Il peso dato al "proteggere la rete" mi sembra ampiamente eccessivo. Con un DROP a prescindere ti precludi la possibilità di cui sopra di usare la rete per promuoversi da sola [1], quando in realtà i singoli nodi Ninux sono in una posizione migliore della tua per scegliere (granularmente!) se privilegiare/come bilanciare la sicurezza o l'accesso. Conoscendo le informazioni tecniche del tuo hostpot ogni nodo può decidere se filtrare il traffico da essa proveniente oppure no. Anche la definizione di "sconosciuto" dal quale proteggere mi sembra arbitraria. Per il resto: L'accesso a Internet direttamente tramite il proprio nodo non ricade nel dominio del free transit del PPA (non rientra nella definizione di "free network" e nemmeno di "additional service"). Averlo, non averlo, se e come consentirlo o limitarlo, non impatta la natura di Ninux come rete libera. E pertanto ogni singolo nodo può decidere per sé. Detto questo io sul mio hotspot attivo la condivisione di Internet, non lo filtro, ma limito la banda. Il rationale della mia scelta, in ordine sparso, è questo: * Un hotspot Ninux-only ha una pessima usabilità. Se creo un hotspot per consentire l'accesso a Ninux, voglio che le persone abbiano voglia di utilizzarlo, ma costringerle a setup complicati con doppia interfaccia wireless (una verso una qualche default) non è d'aiuto. * Il principio di neutralità è un buon principio, e per quanto possibile mi ci attengo. In un hotspot però l'esaurimento della risorsa arriva prima e non è un problema trattabile, come almeno in potenza è sempre possibile in Ninux, mettendo banalmente a disposizione più risorse. Pertanto occorre un compromesso. Non filtrare ma tentare di suddividere equamente è quello che mi piace di più. * Alla fine della fiera, filtrare a priori non è efficace, perché a meno di non spenderci quantità di tempo e risorse irragionevoli finirai per non bloccare qualcosa che vuoi bloccare, ma soprattutto bloccare qualcosa che vorresti permettere. * Preferisco impiegare le stesse quantità di tempo (magari sempre irragionevoli) a monitorare e reagire ad eventuali abusi reali quando avvengono, piuttosto che cullarmi di aver eliminato abusi in potenza grazie a filtri che nemmeno revisionerò personalmente. Mi mantiene consapevole dei servizi che metto a disposizione ed è la stessa attitudine che penso dovrei comunque tenere per ogni risorsa che attivo in Ninux, perché "pubblicarne" una e lasciarla nell'incuria annulla l'effetto promozionale positivo che sto ricercando per la rete. * Limitare la banda e ripartirla equamente già da sola scoraggia la maggior parte delle tentazioni di abusare del servizio. * Sono d'accordo con quanto detto da Elena sul calderone del tutto ambiguo delle responsabilità. Alla fine è il nodo che offre l'hotsp
[Ninux-Wireless] Traffic Control, PicoPeering, peering obligation e percing
Ragazzi, ci possono essere new entry in MLle vogliamo traumatizzare? Le varie isole sono principalmente realizzate tra amici non cracker. Il discorso di Hotpost e Traffic Control era di separare in maniera netta un hotspot (che fa da spot pubblicitario) dalla rete Ninux reale. Il client che fa un check-in su fb utilizzando l'hotspot non è un cracker pericoloso... Con il discorso HotSpot volevo fare una pubblicità ad entrare in Ninux, non a far scappare le new-entry ne dire, attento che hai le antenne aperte e di notte di può entrare il cracker a rubarti i filmini... A sto punto mi viene da chiedere: in che percentuale Ninux è stata attaccata da cracker? Il mio post era per individuare una soluzione di cautela, non di dire "Se condividi Internet non devi dormire la notte"! Condividere internet è un rischio, è un dato di fatto. Ma quanti di voi concretamente ha avuto un attacco reale?? Se vogliamo dare un messaggio alle new-entry che Ninux è vulnerabilie al 100%ditelo e scrivetelo nel Manifesto! Io non credo nelle cose distruttive ma credo nella crescita e produttività di: sviluppo, creatività, comunità, divulgazione del proprio sapere, sperimentazione. Chi vede il mio nodo vede il mio PC, il mio DNS, il mio samba, il mio netbook, il mio cellullare, la mia stampantetutto della mia LANperchè io voglio condividere ogni risorsa per lo sviluppo in Ninux. O dovrei mettere il router Ninux dietro un PfSense in DMZ come se fosse una rete iper-vulnerabile? Se annunciare la 0.0.0.0/0.0.0.0 ve la sentire di dire apsettati i caramba a casaditelo! Se è questo il messaggio da dare... direi che non ho capito un cazzo di Ninux in 2 anni! In ML non ci sono solo nonni, ma anche nipotini appena entrati, non dimenticalo e non traumatizzateli senza fatti concreti! Michele ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless
Re: [Ninux-Wireless] PicoPeering e peering obligation
On 2016-09-15 at 19:17:58 +0200, Stefano De Carlo wrote:
> * Non c'è nessun requisito di no-auth nel PPA, solo di "pubblicazione delle
> info necessarie ad instaurare il peering"
> * L'obbligazione al peering ("chiunque") non fa parte del PPA. È la
> principale differenza tra il PPA e la Free Networks Definition [1]
>
> Questa precisazione è secondo me importantissima perché c'è certamente una
> fetta di partecipanti a Ninux che ritiene che non dovrebbe essere, a priori,
> consentito rifiutare il peering anche solo in qualche caso. Ma è un errore
> considerare il PPA come sorgente di questo requisito o (di conseguenza)
> presumere che questo requisito sia già universalmente in essere in Ninux.
uhm, ma se le informazioni per il peering sono pubblicate, cosa
impedisce tecnicamente ad una persona che si trova nel posto giusto¹ di
collegarsi e peerare?
¹ e quindi non ha bisogno di modifiche di puntamento delle antenne
--
Elena ``of Valhalla''
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless
Re: [Ninux-Wireless] NodogSplash e Traffic Control
On 12/09/16 23:17, Michele Salerno wrote: Con Claudio di Palermo stiamo cercando di capire come implementare un sistema per limitare la banda sull'interfaccia hotspot pubblica. Abbiamo installato QoS, ma se attivato sulla WAN ci tagliamo le XX anche per la LAN. di base usiamo Chaos, che soluzioni ci sono sencodo voi? Io lascerei stare sti routerini dove ci gira OpenWRT per farci routing a terra etc. (poca ram, poca flash etc.) Riciclate un vecchio PC installandoci es. 3 schede di rete (1 per la connettivita' internet, una per la LAN, l'altra per il traffico wireless). Dal punto di vista software installateci un Hypervisor tipo VMware vSphere o XenServer. Create 2 macchine virtuali e fateci girare su una OpenBSD per gestirci tutta la parte di rete e della sicurezza e sull'altra FreeBSD per gestire i Servizi che volete offrire sulla Rete Ninux. ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless
Re: [Ninux-Wireless] NodogSplash e Traffic Control
Il 14/09/2016 00:18, Claudio Pisa ha scritto: > Altre isole stanno usando splash page con successo? Anche a Cosenza i risultati sono stati simili, ma onestamente il campione derivante dalla copertura o il tempo di uptime del servizio sono stati troppo poco ampi per estrapolare. Anche l'usabilità era migliorabile. Stefanauss. signature.asc Description: OpenPGP digital signature ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless
Re: [Ninux-Wireless] NodogSplash e Traffic Control
Il 15 settembre 2016 16:26, Elena ``of Valhalla'' ha scritto: > On 2016-09-14 at 19:16:43 +0200, Michele Salerno wrote: >> > Un altro caso è bloccare il traffico verso la propria rete privata. >> > Oppure il traffico che proviene dalla propria rete privata. >> > >> Non condivido il pensiero, la mia LAN di Ninux è la LAN che uso in >> casa, non ho altre LAN separate. >> Se sul mio pc di casa metto in shared una cartella, tu sull'altro nodo >> la vedi, se mi fai una scansione con nmap vedi tutti i miei device. >> A me sta bene così in quanto come me altri nunuxer non credo abbiano >> spasmi di cracker. > > questo mi pare un po' pericoloso: anche io credo che gli altri membri > della comunità ninux non abbiano intenti malevoli, ma le antenne della > rete ninux sono comunque aperte a chiunque senza nessuna autenticazione > (vedi picopeering agreement) e quindi ci si potrebbe collegare chiunque, > anche non membro della comunità e con intenti malevoli. > > Del resto chiunque potrebbe, anche per errore, installare qualcosa che > disturba, mi viene in mente come esempio assolutamente casuale¹ un > secondo DHCP, magari che fornisce dati sbagliati. Già quello mi pare un > buon motivo per tenere separate le due reti. > Sarei curioso di capire come usate la rete Ninux se la tenete separata dalla Vs. LAN. Viene tenuta in una DMZ? Nel mio caso ho la BackBone su 172.27.0.x/16 La mia LAN 10.27.0.0/24 L'interfaccia di hotspot su 192.168.20.0/24 alla quale è negato l'accesso sua sulla LAN che sulla Backbone. Sul mio PC winzoz un minimo di antivirus c'è e cmq spesso controlli i processi etc... L'interfaccia del router è quasi sempre aperta sul mio pc, anche perchè tra 1000 prove...la devo tenere per forza aperta. Forse nella mia realtà dove siamo ancora in pochi...se non pochissiminon mi sono posto il problema di tenere a bada 200 nodi, forse mi sarei messo un paio di firewall in cascata! > ¹ tipo mi è successo stamattina sulla rete di casa :) > ?? >> > Filtrare il traffico è BRUTTO, per il semplice motovo che vi prendete la >> > responsabilità dei pacchetti che passano sul voltro nodo. >> > >> Sto concetto non mi è chiaro: >> Se metto una Ubiquiti Bullet M2 con una antenna omnidirezionale da 150 >> cm sul mio tetto senza password, io sono SEMPRE responsabile di ogni >> pacchetto che transita dal mio router verso Internet. [...] > > questo vale qualunque sia la fonte di quel traffico, sia che arrivi da > un hotspot sul tuo tetto che dalla rete ninux, ed è un rischio che ci si > prende nel momento in cui si decide di condividere la propria > connessione ad internet casalinga. > > Poi è probabile che il tribunale dichiari innocenti del reato commesso > (ma a seconda di come si son svegliati negli ultimi mesi i legislatori > potrebbe essere tornato illecito fornire accesso ad internet senza > identificare gli utenti), ma in ogni caso nel frattempo la polizia è > arrivata e l'indagine è partita dal titolare del contratto. > > Per questo i filtri non servono a molto: ci sono tantissimi reati che è > possibile commettere senza essere bloccati dalle solite blacklist. > > Che io sappia, l'unico vero modo per non correre questo rischio è che a > condividere la connessione non sia un privato, ma un'entità legale che > goda delle opportune protezioni di legge ad esempio perché considerabile > ISP. > >> > Oltretutto filtrare è oneroso in termini di risorse. >> > Esistono delle librerie (opencv). che trovano facce in un immagine, o targe >> > di auto, oppure GATTINI, [...] >> > Per filtrare i pacchetti in maniera efficente il vostro nodo deve girare su >> > di un vero computer con prestazioni adeguate. >> E' un discorso un po' eccessivo! > > beh, filtrare con una manciatina di blacklist non occupa molte risorse, > ma è anche estremamente inefficace e lascia passare numerosi contenuti > che si vorrebbero fermare. > > filtrare con sistemi più sofisticati come quelli citati qui sopra occupa > molte più risorse, è più efficace nel senso che blocca molte più cose, > ma di solito causa anche molti più falsi positivi, censurando anche > contenuti particolarmente sensibili ed importanti (vedi l'approccio > facebook). > >> > Filtrare è oneroso in termini legali. [...] >> Qualsiasi cosa che transita sulla linea ADSL l'unico responsabile >> SEMPRE è chi ha sottoscritto l'abbonamento ADSL. > > in teoria la responsabilità dei reati è personale (poi come tutto ciò > che è correlato coi diritti umani ultimamente si tende un po' a trovare > eccezioni). > > Chi ha sottoscritto l'abbonamento ADSL è di sicuro il primo punto da cui > partono eventuali indagini, e probabilmente è legalmente tenuto a fare > il possibile per aiutarle ed aiutare ad identificare il responsabile. > > Fino a dove questa responsabilità arrivi non è chiarissimo, e non è > assurdo pensare che a chi fornisce un accesso pesantemente filtrato e > censurato possa essere chiesto di fare di più in tale senso. > >> [...] Non fa una piega il tuo discorso... >> Le AP non hanno un D
Re: [Ninux-Wireless] NodogSplash e Traffic Control
Il 15 settembre 2016 18:07, Saverio Proto ha scritto: > ma usare: > https://www.relakks.com/ > > gia lo usavamo al Fusolab anni fa > > Saverio > Non lo conosco ed è in inglese..che amo tantissimo! Ammetto la mia ignoranza...non mi entra! Ho imparato il rumeno, ma l'ingleseho un firewall tra me è l'inglese! :D ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless
[Ninux-Wireless] PicoPeering e peering obligation
Il 15/09/2016 16:26, Elena ``of Valhalla'' ha scritto:
> ma le antenne della
> rete ninux sono comunque aperte a chiunque senza nessuna autenticazione
> (vedi picopeering agreement)
* Non c'è nessun requisito di no-auth nel PPA, solo di "pubblicazione delle
info necessarie ad instaurare il peering"
* L'obbligazione al peering ("chiunque") non fa parte del PPA. È la principale
differenza tra il PPA e la Free Networks Definition [1]
Questa precisazione è secondo me importantissima perché c'è certamente una
fetta di partecipanti a Ninux che ritiene che non dovrebbe essere, a priori,
consentito rifiutare il peering anche solo in qualche caso. Ma è un errore
considerare il PPA come sorgente di questo requisito o (di conseguenza)
presumere che questo requisito sia già universalmente in essere in Ninux.
Stefanauss.
[1] https://sudoroom.org/pipermail/tmpcommonsnet/2013-October/08.html
signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless
Re: [Ninux-Wireless] NodogSplash e Traffic Control
ma usare: https://www.relakks.com/ gia lo usavamo al Fusolab anni fa Saverio Il 15 set 2016 4:26 PM, "Elena ``of Valhalla''" ha scritto: > On 2016-09-14 at 19:16:43 +0200, Michele Salerno wrote: > > > Un altro caso è bloccare il traffico verso la propria rete privata. > > > Oppure il traffico che proviene dalla propria rete privata. > > > > > Non condivido il pensiero, la mia LAN di Ninux è la LAN che uso in > > casa, non ho altre LAN separate. > > Se sul mio pc di casa metto in shared una cartella, tu sull'altro nodo > > la vedi, se mi fai una scansione con nmap vedi tutti i miei device. > > A me sta bene così in quanto come me altri nunuxer non credo abbiano > > spasmi di cracker. > > questo mi pare un po' pericoloso: anche io credo che gli altri membri > della comunità ninux non abbiano intenti malevoli, ma le antenne della > rete ninux sono comunque aperte a chiunque senza nessuna autenticazione > (vedi picopeering agreement) e quindi ci si potrebbe collegare chiunque, > anche non membro della comunità e con intenti malevoli. > > Del resto chiunque potrebbe, anche per errore, installare qualcosa che > disturba, mi viene in mente come esempio assolutamente casuale¹ un > secondo DHCP, magari che fornisce dati sbagliati. Già quello mi pare un > buon motivo per tenere separate le due reti. > > ¹ tipo mi è successo stamattina sulla rete di casa :) > > > > Filtrare il traffico è BRUTTO, per il semplice motovo che vi prendete > la > > > responsabilità dei pacchetti che passano sul voltro nodo. > > > > > Sto concetto non mi è chiaro: > > Se metto una Ubiquiti Bullet M2 con una antenna omnidirezionale da 150 > > cm sul mio tetto senza password, io sono SEMPRE responsabile di ogni > > pacchetto che transita dal mio router verso Internet. [...] > > questo vale qualunque sia la fonte di quel traffico, sia che arrivi da > un hotspot sul tuo tetto che dalla rete ninux, ed è un rischio che ci si > prende nel momento in cui si decide di condividere la propria > connessione ad internet casalinga. > > Poi è probabile che il tribunale dichiari innocenti del reato commesso > (ma a seconda di come si son svegliati negli ultimi mesi i legislatori > potrebbe essere tornato illecito fornire accesso ad internet senza > identificare gli utenti), ma in ogni caso nel frattempo la polizia è > arrivata e l'indagine è partita dal titolare del contratto. > > Per questo i filtri non servono a molto: ci sono tantissimi reati che è > possibile commettere senza essere bloccati dalle solite blacklist. > > Che io sappia, l'unico vero modo per non correre questo rischio è che a > condividere la connessione non sia un privato, ma un'entità legale che > goda delle opportune protezioni di legge ad esempio perché considerabile > ISP. > > > > Oltretutto filtrare è oneroso in termini di risorse. > > > Esistono delle librerie (opencv). che trovano facce in un immagine, o > targe > > > di auto, oppure GATTINI, [...] > > > Per filtrare i pacchetti in maniera efficente il vostro nodo deve > girare su > > > di un vero computer con prestazioni adeguate. > > E' un discorso un po' eccessivo! > > beh, filtrare con una manciatina di blacklist non occupa molte risorse, > ma è anche estremamente inefficace e lascia passare numerosi contenuti > che si vorrebbero fermare. > > filtrare con sistemi più sofisticati come quelli citati qui sopra occupa > molte più risorse, è più efficace nel senso che blocca molte più cose, > ma di solito causa anche molti più falsi positivi, censurando anche > contenuti particolarmente sensibili ed importanti (vedi l'approccio > facebook). > > > > Filtrare è oneroso in termini legali. [...] > > Qualsiasi cosa che transita sulla linea ADSL l'unico responsabile > > SEMPRE è chi ha sottoscritto l'abbonamento ADSL. > > in teoria la responsabilità dei reati è personale (poi come tutto ciò > che è correlato coi diritti umani ultimamente si tende un po' a trovare > eccezioni). > > Chi ha sottoscritto l'abbonamento ADSL è di sicuro il primo punto da cui > partono eventuali indagini, e probabilmente è legalmente tenuto a fare > il possibile per aiutarle ed aiutare ad identificare il responsabile. > > Fino a dove questa responsabilità arrivi non è chiarissimo, e non è > assurdo pensare che a chi fornisce un accesso pesantemente filtrato e > censurato possa essere chiesto di fare di più in tale senso. > > > [...] > > Le AP non hanno un DHCP attivo sulla BackBone e chi si collega tra > > virgolette lo conosco in quanto un altro ninuxer. > > beh, ma l'assenza di un DHCP non è un vero ostacolo per collegarsi ad > una rete: un'occhiata in giro (magari anche al traffico) e le > impostazioni si trovano. > > soprattutto se si hanno già intenzioni illegali, e quindi pochi > scrupoli. > > > [...] > > Mr. XX (Bean lo conosco) seduto sulla panchina vede un sid aperto > > "hotpost ninux", si collegasi apre il browser con una splashpage > > che spiega in breve cosa è Ninux, dice che la navigazione è limitata > > solo ed esclusivamente per la Pos
Re: [Ninux-Wireless] Massively distributed Openstack
devstack è come usare tutti i giorni Linux con il LiveCD per capirsi. openstack single node si fa solo a scuola per didattica, o per provare una patch. scrivo da cellulare. quando avrò una tastiera vera sottomano risponderò piu decentwmente. sorry ma vogliamo fare una serata a tema a Roma la prossima volta che scendo ? Saverio Il 15 set 2016 4:27 PM, "Claudio Pisa" ha scritto: On 09/15/2016 02:25 PM, Saverio Proto wrote: > Ragazzi devstack é solo un tool per installare il control plane su un > singolo nodo per gli sviluppatori per provare le patch. Ma che tu sappia e' un problema di performance, sicurezza o c'e' dell'altro? E non c'e' un modo per trasformare un'istanza di devstack in un deployment di openstack single-node? Cercando "single node openstack" ho trovato questo: http://www.brianlinkletter.com/openstack-on-one-machine/ ma i sistemi citati, a parte devstack, non mi sembrano molto adatti al nostro scenario... Clauz ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless
Re: [Ninux-Wireless] Massively distributed Openstack
On 09/15/2016 02:25 PM, Saverio Proto wrote: > Ragazzi devstack é solo un tool per installare il control plane su un > singolo nodo per gli sviluppatori per provare le patch. Ma che tu sappia e' un problema di performance, sicurezza o c'e' dell'altro? E non c'e' un modo per trasformare un'istanza di devstack in un deployment di openstack single-node? Cercando "single node openstack" ho trovato questo: http://www.brianlinkletter.com/openstack-on-one-machine/ ma i sistemi citati, a parte devstack, non mi sembrano molto adatti al nostro scenario... Clauz ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless
Re: [Ninux-Wireless] NodogSplash e Traffic Control
On 2016-09-14 at 19:16:43 +0200, Michele Salerno wrote: > > Un altro caso è bloccare il traffico verso la propria rete privata. > > Oppure il traffico che proviene dalla propria rete privata. > > > Non condivido il pensiero, la mia LAN di Ninux è la LAN che uso in > casa, non ho altre LAN separate. > Se sul mio pc di casa metto in shared una cartella, tu sull'altro nodo > la vedi, se mi fai una scansione con nmap vedi tutti i miei device. > A me sta bene così in quanto come me altri nunuxer non credo abbiano > spasmi di cracker. questo mi pare un po' pericoloso: anche io credo che gli altri membri della comunità ninux non abbiano intenti malevoli, ma le antenne della rete ninux sono comunque aperte a chiunque senza nessuna autenticazione (vedi picopeering agreement) e quindi ci si potrebbe collegare chiunque, anche non membro della comunità e con intenti malevoli. Del resto chiunque potrebbe, anche per errore, installare qualcosa che disturba, mi viene in mente come esempio assolutamente casuale¹ un secondo DHCP, magari che fornisce dati sbagliati. Già quello mi pare un buon motivo per tenere separate le due reti. ¹ tipo mi è successo stamattina sulla rete di casa :) > > Filtrare il traffico è BRUTTO, per il semplice motovo che vi prendete la > > responsabilità dei pacchetti che passano sul voltro nodo. > > > Sto concetto non mi è chiaro: > Se metto una Ubiquiti Bullet M2 con una antenna omnidirezionale da 150 > cm sul mio tetto senza password, io sono SEMPRE responsabile di ogni > pacchetto che transita dal mio router verso Internet. [...] questo vale qualunque sia la fonte di quel traffico, sia che arrivi da un hotspot sul tuo tetto che dalla rete ninux, ed è un rischio che ci si prende nel momento in cui si decide di condividere la propria connessione ad internet casalinga. Poi è probabile che il tribunale dichiari innocenti del reato commesso (ma a seconda di come si son svegliati negli ultimi mesi i legislatori potrebbe essere tornato illecito fornire accesso ad internet senza identificare gli utenti), ma in ogni caso nel frattempo la polizia è arrivata e l'indagine è partita dal titolare del contratto. Per questo i filtri non servono a molto: ci sono tantissimi reati che è possibile commettere senza essere bloccati dalle solite blacklist. Che io sappia, l'unico vero modo per non correre questo rischio è che a condividere la connessione non sia un privato, ma un'entità legale che goda delle opportune protezioni di legge ad esempio perché considerabile ISP. > > Oltretutto filtrare è oneroso in termini di risorse. > > Esistono delle librerie (opencv). che trovano facce in un immagine, o targe > > di auto, oppure GATTINI, [...] > > Per filtrare i pacchetti in maniera efficente il vostro nodo deve girare su > > di un vero computer con prestazioni adeguate. > E' un discorso un po' eccessivo! beh, filtrare con una manciatina di blacklist non occupa molte risorse, ma è anche estremamente inefficace e lascia passare numerosi contenuti che si vorrebbero fermare. filtrare con sistemi più sofisticati come quelli citati qui sopra occupa molte più risorse, è più efficace nel senso che blocca molte più cose, ma di solito causa anche molti più falsi positivi, censurando anche contenuti particolarmente sensibili ed importanti (vedi l'approccio facebook). > > Filtrare è oneroso in termini legali. [...] > Qualsiasi cosa che transita sulla linea ADSL l'unico responsabile > SEMPRE è chi ha sottoscritto l'abbonamento ADSL. in teoria la responsabilità dei reati è personale (poi come tutto ciò che è correlato coi diritti umani ultimamente si tende un po' a trovare eccezioni). Chi ha sottoscritto l'abbonamento ADSL è di sicuro il primo punto da cui partono eventuali indagini, e probabilmente è legalmente tenuto a fare il possibile per aiutarle ed aiutare ad identificare il responsabile. Fino a dove questa responsabilità arrivi non è chiarissimo, e non è assurdo pensare che a chi fornisce un accesso pesantemente filtrato e censurato possa essere chiesto di fare di più in tale senso. > [...] > Le AP non hanno un DHCP attivo sulla BackBone e chi si collega tra > virgolette lo conosco in quanto un altro ninuxer. beh, ma l'assenza di un DHCP non è un vero ostacolo per collegarsi ad una rete: un'occhiata in giro (magari anche al traffico) e le impostazioni si trovano. soprattutto se si hanno già intenzioni illegali, e quindi pochi scrupoli. > [...] > Mr. XX (Bean lo conosco) seduto sulla panchina vede un sid aperto > "hotpost ninux", si collegasi apre il browser con una splashpage > che spiega in breve cosa è Ninux, dice che la navigazione è limitata > solo ed esclusivamente per la Posta e Web tradizionale (wikipedia, > facebook, google, etc...). Quando clicca su ACCETTA viene indirizzato > sul sito http://basilicata.ninux.org/ e con questo ha a disposizione le risorse per commettere tutta una serie di reati, dall'inviare mail truffaldine (a singole persone, non necessariamente l'invio iniziale di massa) a
Re: [Ninux-Wireless] Massively distributed Openstack
Ragazzi devstack é solo un tool per installare il control plane su un singolo nodo per gli sviluppatori per provare le patch. Saverio Il 15 set 2016 12:29 PM, "Accattone" ha scritto: > On 13/09/2016 18:52, Claudio Pisa wrote: > > On 09/12/2016 11:00 AM, Accattone wrote: > >> On 05/09/2016 15:11, Claudio Pisa wrote: > mi sembra di ricordare in passato lavoro su "community cloud" > (clommunity?), ma non ho seguito quindi non so se si sovrappone. > >>> > >>> Come scopi probabilmente si sovrappone. > >>> > >>> Una cosa che nel WG che segnali non vedo e' il considerare mini PC con > >>> scarse risorse o con architetture eterogenee, tipo raspberry pi, odroid > >>> e simili. Ho l'impressione che il loro target sia soprattutto il mondo > >>> "aziendale" e non quello "casalingo". > >>> > >>> E domanda: Non e' che OpenStack e' troppo pesante e "overkill" per i > >>> nostri scopi? > >> > >> E' una delle domande che mi sto facendo da un po' di tempo a questa > >> parte. Non ho trovato risposte convincenti. Penso che bisognerebbe > >> sperimentare per capire. > >> > >> A me piacerebbe lavorarci. Avrebbe senso creare un gruppo di lavoro > >> specifico? > > > > Ciao, Accattone. > > Ciao, Clauz. > > > Anche se OpenStack e' un software complesso, pensato per girare su piu' > > di un server all'interno di un datacenter, si potrebbe intanto provare a > > installare devstack su un NUC o raspberry pi, vedere come va e cercare > > di capire come continuare. > > Questo sarebbe senz'altro un possibile buon inizio. > > > > O avevi qualcos'altro in mente? > > Vorrei sperimentare una sorta di "Data Center distribuito" su rete > Ninux. Uno degli obiettivi principali sarebbe usare hardware recuperato > o economicamente molto accessibile. Un altro costruire un servizio IaaS > di comunità, possibilmente federato, piuttosto che centralizzato. > > > > Forse ci possiamo coordinare su ninux-research? > > http://ml.ninux.org/mailman/listinfo/research > > Ottimo. Mi sono iscritto, grazie. > > > Saluti recuperati, > Accattone > > > -- > > "Il capitalismo vive se la gente resta persuasa che le cose importanti > siano monopolio dei signori e degli specialisti". > > Cornelius Castoriadis > > ___ > Wireless mailing list > Wireless@ml.ninux.org > http://ml.ninux.org/mailman/listinfo/wireless > ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless
Re: [Ninux-Wireless] Massively distributed Openstack
On 13/09/2016 18:52, Claudio Pisa wrote: > On 09/12/2016 11:00 AM, Accattone wrote: >> On 05/09/2016 15:11, Claudio Pisa wrote: mi sembra di ricordare in passato lavoro su "community cloud" (clommunity?), ma non ho seguito quindi non so se si sovrappone. >>> >>> Come scopi probabilmente si sovrappone. >>> >>> Una cosa che nel WG che segnali non vedo e' il considerare mini PC con >>> scarse risorse o con architetture eterogenee, tipo raspberry pi, odroid >>> e simili. Ho l'impressione che il loro target sia soprattutto il mondo >>> "aziendale" e non quello "casalingo". >>> >>> E domanda: Non e' che OpenStack e' troppo pesante e "overkill" per i >>> nostri scopi? >> >> E' una delle domande che mi sto facendo da un po' di tempo a questa >> parte. Non ho trovato risposte convincenti. Penso che bisognerebbe >> sperimentare per capire. >> >> A me piacerebbe lavorarci. Avrebbe senso creare un gruppo di lavoro >> specifico? > > Ciao, Accattone. Ciao, Clauz. > Anche se OpenStack e' un software complesso, pensato per girare su piu' > di un server all'interno di un datacenter, si potrebbe intanto provare a > installare devstack su un NUC o raspberry pi, vedere come va e cercare > di capire come continuare. Questo sarebbe senz'altro un possibile buon inizio. > O avevi qualcos'altro in mente? Vorrei sperimentare una sorta di "Data Center distribuito" su rete Ninux. Uno degli obiettivi principali sarebbe usare hardware recuperato o economicamente molto accessibile. Un altro costruire un servizio IaaS di comunità, possibilmente federato, piuttosto che centralizzato. > Forse ci possiamo coordinare su ninux-research? > http://ml.ninux.org/mailman/listinfo/research Ottimo. Mi sono iscritto, grazie. Saluti recuperati, Accattone -- "Il capitalismo vive se la gente resta persuasa che le cose importanti siano monopolio dei signori e degli specialisti". Cornelius Castoriadis ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless
