Newsgroup: it.comp.os.linux.sys
Titolo: Dansguardian senza Proxy

Ciao a tutti!
Vorrei installare Dansguardian in modo da bloccare alcuni siti
(decisamente NON lavorativi) e controllare i download con un antivirus.
Ho fatti dei tests con una VM e sembra veramente carino. Pero' devo anche
installare un ProxyServer (tinyproxy o squid non importa, basta che sia
uno).
Non sono riuscito a trovare il modo di dire a Dansguardian di collegarsi
direttamente ad Internet senza Proxy.
Non e' possibile o sono cieco io?
Grazie
Luca Bertoncello
(
luca...@lucabert.de
)
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 Non e' possibile o sono cieco io?
Ciao, per quanto mi riguarda posso solo confermarti che anch'io non ho trovato 
il modo di usarlo da solo, senza proxy in uscita.
Addirittura io volendo avere l'autenticazione su AD ho dovuto fare un sandwich 
di dansguardian tra 2 squid; il primo squid che mi gestisca l'autenticazione AD 
(l'autenticazione di Dansguardian non veniva passata a Squid e non riuscivo a 
gestire alcune acl), dansguardian per le bl dei siti e altri controlli e uno 
squid stupido per fare caching puro e semplice in uscita -proprio perchè 
dansguardian non riesce ad uscire diretto-.
Se dovessi trovare il modo sarei felice di poter togliere l'ultimo squid che fa 
semplicemente caching.
Ciao
Rizio
-- 
Si dice che essere liberi significa non avere nulla da perdere... ma la verità è 
che non avere nulla da perdere significa essere pronti a rischiare tutto ciò che 
si possiede.


Tutti i content filter hanno necessità di una cache di qualche genere, i 
confronti sugli header e sul corpo impiegano diverso tempo, non si 
possono fare on the fly.
Dansguardian, che non brilla in velocità peraltro,  non fornisce cache 
propria, si appoggia su squid.
http://dansguardian.org/?page=dgflow
Naturalmente dovrebbe funzionare anche con altri Caching Proxy

possono fare on the fly.
Be', no, dai. Considera che un documento ti arriva, bene che vada, a 2.5
megabyte al secondo. In un secondo, anche uno scriptaccio in Perl 2.5 Mb
te li rivolta come un calzino.
Specie poi visto che molti controlli sono URL-based, ed i dati da vedere
sono veramente poca roba.
Se mai è vero che molti content-filter fanno solo il content-filter, non
hanno funzionalità di proxy (che non sono immediate da implementare, non
se si vuole fare un lavoro fatto bene)... ma non c'entra la velocita' di
esecuzione del filtro.
Leonardo
-- 
Enough, enough!  But, stranger, ere we part,
Glancing farewell to each nefarious bier,
This warning would I beg you take to heart:
There is an end to e'en the worst career!


...se consideri un singolo utente che apre una singola pagina per volta. 
Se pensi a 100 utenti che usino tutti un solo filter proxy....
Ecco perchè DG, a quanto pare dalla documentazione, è stato scritto 
attorno al vecchio squid.



Oh naturlamente potremmo farci il nostro filter proxy on the fly 
scalando su thread (o processi figli per avere un gusto più retrò). 
Probabilmente elimineremmo la cache consumando il processore e la 
memoria. Ma non credo sia consigliabile un sistema di questo genere

 te li rivolta come un calzino.
Beh considera che l'umano dietro lo schermo una latenza di 200ms per 
richiesta la percepisce.
Considera che:
- i content filter spesso fanno delle query DNS che qualche ms lo 
richiedono, spesso più di qualcuno.
- i content filter prima di mandarti il contenuto, lo devono analizzare e 
questo implica che i dati di qualsiasi flusso (pagina HTML da 200K o 
immagine interlacciata) ti arriva tutta in un botto e non a pezzi come 
dovrebbe essere. La velocità media alla fine è simile ma la sensazione è 
diversa per l'utente
- se usi un proxy HTTP1.0 di merda come tinyproxy, puoi fare una 
richiesta per connessione e ti perdi le multi-richieste per connessione 
di HTTP/1.1
- se usi HTTP/1.1 comunque il content filter è impegnato ad analizzare 
diversi documenti alla volta, anche quando un utente singolo lo usa
- se aumenti la concorrenza degli utenti, lo scenario sopra peggiora...
Se sommi tutti i se ed i ma, alla fine un content filter rallenta 
parecchio la navigazione.

attorno al vecchio squid.
No, il motivo è stato proprio di praticità. All'inizio ti concentri sulle
funzioni core, e demandi il networking e lo smazzarsela con i client a un
programma che ha già dimostrato di sapersela cavare.
DansGuardian lavora come connessione browser-to-browser, e cioe' fa finta
di essere un browser, ma si può connettere a un unico server "sicuro" che
è squid. Quindi tutta una serie di problemi di connection management ecc.
(ma anche error handling, e via) in gran parte se le risparmia.
Poi magari ti ottimizzi uno strato di networking tuo, anche basandolo sul
programma di cui sopra o magari no, e lo chiami Network Guardian.
Del resto, avrai presente com'e' installato di regola DansGuardian, ossia
A VALLE di Squid. A livello di prestazioni, il vantaggio è zero: su mille
richieste, DansGuardian se le deve spupazzare tutte e mille.
 
http://dansguardian.org/?page=dgflow
Leonardo SE&O


 ne passa.
CFR havp.
-- 
Flavio Visentin
Ubuntu in Zulu significa "Non so usare Debian". (cit. CtRiX)

parecchio la navigazione.
E avrebbe quindi senso mettere un proxy a MONTE del content filter, in
modo da accelerare l'accesso ai dati già filtrati, e ridurre il numero
di interventi del filtro medesimo, le query DNS e tutta l'altra robina
di cui - giustamente - parlavi.
Il motivo per cui, secondo me, DansGuardian non si preoccupa di queste
cose (anche se, sicuramente, è contento che vengano accelerate!) è che
viene tipicamente installato... a VALLE.
 
http://dansguardian.org/?page=dgflow
Non solo: nelle FAQ (#9) viene detto che qualora sia installato invece
a monte di squid, serve un proxy ancora più a monte ("panino" di proxy
con DansGuardian nel ruolo del prosciutto).
Dato che il proxy a monte è quello dell'ISP, che ci sia o no al client
non cambia niente. Le pagine arrivano alla stessa velocità di prima in
ogni caso, sempre proxate, e DansGuardian può solo rallentarle.
Il motivo per cui "deve" esserci un proxy, anche un proxy schifido sul
genere di tinyproxy o nullproxy, è quindi evidentemente un altro. E il
motivo più probabile è che essendo nato con una architettura simile al
suo antico 'rivale' squidGuard, ne eredita alcune limitazioni, e nella
fattispecie questa... «Technically DansGuardian is more of a filtering
pass-through than a true proxy».
Ovviamente, se scrivi un pass-through, hai parecchi vantaggi (non devi
preoccuparti di tutti i casini che possono venire fuori nel proxying),
ma uno svantaggio lo devi pagare: ti serve un proxy a monte che faccia
il lavoro che tu non fai.



Quel link non mi è nuovo....ah sì l'ho postato io quale gardino più in 
sù della discussione.
Concordo sul fatto che DG possa in futuro la sua cache e che per ora (o 
per sempre) si basi su squid per convenienza.
Concordo che usando squid l'autore ha evitato di doversi replicare le 
funzioni di un proxy.
Concordo sul fatto che, in macanza delle funzioni proxy, si debba porre 
tra browser e proxy (a valle). CHe poi il browser sia un'altra cppia 
(browser, proxy) va bene uguale, mi faccio un panino.
Concordo che i due prodotti potrebbero essere integrati in un terzo 
(perdendo scalabilità)
Concordo un pò meno sul fatto che si possa fare a meno della cache.
Non discuto sul fatto che la banda sarà condivisa, ma converrai che ogni 
utente produce una propria  sequenza di istruzioni atte a scandire delle 
stringhe ed interrogare una lista di url. E magari query dns. E magari 
in fururo query su db. E magari sono ripetute.
Per carità, puoi fare tutto in memoria, chi ha fatto DG ha scelto 
altrimenti. Perchè? Stiamo certamente facendo un processo alle 
intenzioni, ma a me viene in mente:
- evitare di occupare troppa memoria a fronte di multitask
- magari, forse (se DG scrive in quella cache) per usarla proprio come 
cache ed evitare le funzioni ripetitive
- essere scalabile
- ovvimanete per evitare lo scazzo di "fare il browser"
 >networking e lo smazzarsela con i client a un
 > programma che ha già dimostrato di sapersela cavare.
Anche DG si fa la sua parte di NW, ha a che fare con i suoi client, 
interpreta anche l'html. Forse gli manca solo la parte storage di un proxy.
 > ...passano tutti dalla medesima ADSL/HDSL. Per cui si dividono i 2.5 Mb/s
A parte che potrei usare un DG a fronte di una connessione internet da 
20 Mb/s, ma perchè non posso usarlo nella mia intranet da 1Gb/s (o più)? 
Ho un collo di bottiglia inferiore e molti, ma molti più dati da gestire 
in contemporanea. Posso farlo con  la mia memoria? Sì e sarebbe più 
veloce per pochi client, ma dopo ogni sessione mi rallenta il server, 
potrebbe anche non andarmi bene.
su mille
 > richieste, DansGuardian se le deve spupazzare tutte e mille.
 >
E certamente, il problema sta in quanto è veloce a spupazzare la singola 
richiesta (perchè dopo deve moltiplicarla per mille).
Anche DG ha comunque un decdimento di performance notevole, perchè ogni 
suo processo deve passare per lo stack tcp/ip 2 volte. Satura la banda 
un bel pò, aggiunge errori a livello trasporto. Ma, secondo me, la 
strategia usata è mediamente valida su macchine non dedicate.

CFR havp.
Exactly.
Leonardo (havp happy user)


un bel pò, aggiunge errori a livello trasporto.
Non così tanto. Il doppio transito passa su uno stack a 200 gigabit se
non di più [YMMV], a meno di avere architetture distribuite che non e'
il caso d'uso tipico. E d'altra parte, su una architettura distribuita
non è che ci siano molte altre scelte possibili, AFAIK.
Poi (già che si parla di Squid) è pacifico che a questi livelli stiamo
cercando il belino ai polpi :-D
Leonardo



Se ci sono, sono sicuramente molto verticali.

 saturi, grazie allo "storage" di squid, il sistema rimane performante.
Uh?
Come puo' squid evitare di saturare la memoria che usa DG?
-- 
           |Save our planet!
    Ciao   |Save wildlife!
   roberto |For your E-MAIL use ONLY recycled Bytes  !!
           |roberto poggi   
rpo...@softhome.net

Mandi! Luca Bertoncello
  In chel dì si favelave...
LB> Non e' possibile o sono cieco io?
Io, che mi ero stufato di usare i proxy a catena, ora utilizzo
SquidGuard e c-icap; il secondo è poco più che un giocattolo, ma per
quelo che devo fare va più che bene.
-- 
  Il diavolo fa i file system ma non i tool di ripristino.
							(Claudio Piciarelli)


cons storage
- arriva una richiesta utente
- dg la passa a squid
- squid fa il lavoro da proxy, usando lo storage
- dg verifica se è da scartare
- dg risponde all'utente
senza storage
- arriva una richiesta utente
- dg interroga la rete
- dg impila la transazione in memoria
- dg attende la risposta e fa altre richieste ed impila impila impila
- dg legge la risposta
- dg verifica se è da scartare
- dg risponde all'utente

 - squid fa il lavoro da proxy, usando lo storage
Ma anche no.
