Newsgroup: it.comp.reti.ip-admin
Titolo: Server Proxy [lungo]

Dovendo fornire un servizio web affidabile, dati i fault di energia
elettrica che abbiamo in sede dovrei metterlo fuori, e quindi da un
ISP. Però se lo metto fuori ho meno controllo sulla sua protezione
(firewall, virus,...) e più difficoltà nell'eseguirne la manutenzione
(ad es,. aggiungere account di posta elettronica).
 
Una possibilità che vorrei considerare è quella di tenere il sito web
da noi, ma con un proxy situato (cioè housed) dall'ISP.
 
In questo modo il mondo, facendo 
www.chessoio.it
, arriva sul proxy. Se
questo ha in cache la pagina richiesta te la dà, sennò la cerca sul
web server nostro, la recupera e te la dà.
 
Vantaggi:
le pagine che dobbiamo ospitare sono per ora html e simili. Intendo,
niente ASP, query SQL, eccetera. Quindi si possono cachare facilmente
le richieste più frequenti saranno dunque soddisfatte dalla cache del
proxy, per cui le richieste che entrano da noi sono poche, e non ci
vanno a strozzare la banda passante (che in upload è poca)
per giunta, con un server in housing ho tutti i GB che voglio, quindi
posso far entrare gli interi siti nella cache del proxy. Per cui di
query non me ne dovrebbe arrivare in pratica manco una.
le richieste sono dunque soddisfatte in tempo mediamente minore, anche
quando la nostra connessione e/o il nostro web server sono affaticati,
o addirittura quando il link è down o la nostra sede è senza corrente
dall'ISP non metto un server http ma solo un proxy, quindi le
possibilità di hacking da parte di malintenzionati dovrebbero - a mio
parere - essere più limitate
beccatami l'affidabilità grazie al proxy, mi becco anche il pieno
controllo sui contenuti, dato che posso aggiornare comodamente
qualsiasi pagina (sta da me), e poi forzare il rinfresco della cache
del proxy.
Problemi:
1) Poichè il server proxy in genere è usato in altri contesti questa
modalità di utilizzo poco ortodossa ha qualche pecca concettuale?
2)quale software conviene mettere sul PC housed dall'ISP? Microsoft
proxy server ( o ISA) ? O qualche robetta linux (SQUID) ? Mi serve di
sapere qual'è il software più semplice e affidabile, diciamo quello
che usano tutti gli altri per fare questa cosa, come si gestiscono poi
il conto e le statistiche sugli accessi?
3) un altro problema sarebbe poi costituito dall'introduzione (futura
ma probabile) di eventuali pagine dinamiche (ASP), il che
complicherebbe l'architettura (nel caso di duplicazione dei contenuti
attivi) o limiterebbe (per non dire annullerebbe) l'utilità del proxy
dall'ISP (nel caso di contenuti attivi non duplicati, bensì ospitati
solo da noi). Come ci converrebbe far evolvere l'architettura nel caso
dell'introduzione di contenuti attivi (io a naso credo sarebbe meglio
duplicarli); Infatti fino a duplicare una base di dati SQL read-only
non c'è grosso problema, ma se i contenuti attivi si complicano (ad
es. basi si dati SQL read/write) potremmo affogare nel nostro sangue.
Inoltre il cosa dobbiamo duplicare (tipo: file, DB SQL, ...) influisce
sul come lo duplichiamo (leggi: quali port dobbiamo tenere aperti,
quali servizi attivi, quali directory condivise...), e considerazioni
di security impediscono di tenere tutto spalancato.
Vi ringrazio fin da adesso per la collaborazione.

 noi).
[...]
Mi son perso ;-)
Al di là di tutto, qui molto dipende dalla struttura definitiva di quello
che metterere in piedi. Il metodo più comodo/usato/efficiente è definire
delle ACL tramite regex che matchino tutto ciò che ha natura dinamica e
poi usarle per escludere le richieste relative dal caching.
In questo caso puoi avere l'esportazione completa del tuo sito (contenuti
dinamici compresi) evitando la duplicazione di porzioni dello stesso,
senza peraltro rinunciare ai vantaggi in termini di traffico dati
dall'interposizione del reverse proxy.
Spero di aver azzeccato quello che intendevi ;-)
Mandi...
-- 
Emanuele Balla aka Skull
-----------------------------------------------------------------------
Besides, I think [Slackware] sounds better than 'Microsoft', don't you?
(By Patrick Volkerding)

 web server nostro, la recupera e te la dà.
UCAS...
non ti conviene mettere in housing il server web?
tanto mi sa che t fanno pagare la stessa cifra...
e siccome è una situazione molto comune (l'avere il web server in housing),
probabilmente riesci a trovare molte più info e aiuto.
intendiamoci, si usa anche il sistema che hai indicato tu, ma solitamente mi
pare sia impiegato per siti ad alto traffico. è il tuo caso?
(per alto, non intendo 5000 hit l'ora, ma qualcosina di più... ;-P)
con la soluzione del server in housing, t risolvi anche tutti i problemi di
aggiornamento pagine dinamiche e simili, dato che il server è sempre e cmq
disponibile direttamente on, indipendentemente da quante volte t salta la
corrente in ufficio...
al max, puoi installarti un server gemello (come cfg) in lan, per servire
gli utenti locali e schedulare una sincronizzazione periodica dei dati.
imho, è la soluzione più semolice, pratica e affidabile, oltre che la più
collaudata per lo scenario che hai presentato.
ripeto, imho :-)

 >
tralasciavo un dettaglio: se hai bisogno di un server web sempre
disponibile, probabilmente hai un pò di utenti che lo visitano.
6 sicuro sia sano mettere sulla stessa macchina web+posta?
detto questo, il tuo problema di posta, si risolve semplicemente con una cfg
dei record mx adeguata:
MX 20 
smtpserver.tuoprovider.it
MX 10 
smtpserverlanconipubblico.tuodominio.it
MX10 sta nel tuo ufficio, quindi te lo gestisci tu come vuoi, aggiungendo in
locale utenti, caselle, software, antivirus e tutto quello che t salta.
se cade il link col provider, MX10 non è più raggiungibile, quindi tutti
contattano automaticamente MX20, che tiene la posta in giacenza per te,
tentando di inoltrarla a MX10.
quando il link si riattiva, tutti ricominciano automaticamente a raggiungere
MX10 e a mandargli correttamente la posta e MX20 inoltra quella che ha
ricevuto durante il downtime a MX10 senza necessità di alcun intervento
esterno.
semplice, no?
:-)

 Spero di aver azzeccato quello che intendevi ;-)
Rimango dell'idea che un Apache in housing sia in questo caso una
soluzione piu` gestibile, ma ha ovviamente le sue limitazioni.
Footnotes: 
[1]  questo va letto: "non pensateci nemmeno"
-- 
	kinkie (kinkie chiocciola tiscalinet punto it)
	E ora, qualche parola dai nostri sponsor:
The important thing is not to stop questioning.