Re: OT Re: antivirus proxy SOLUCIONADO
El día 15 de noviembre de 2012 14:48, Trujillo Carmona, Antonio
<antonio.trujillo.sspa@juntadeandalucia.es> escribió:
>
> El vie, 09-11-2012 a las 16:48 +0100, Esteban Torres Rodríguez escribió:
> .../...
>> Nos puedes dar mas detalles de como está montado? Tengo que migrar el
>> servicio de 2 proxy en sedes diferentes a centralizarlo todo a 3 proxy
>> en la sede central y todo consejo me interesa.
>>
>> Cuantas máquinas forman el servicio? Utilizan la cache preguntandose
>> entre ellas o tienen una particion compartida con algun sistema de
>> ficheros como GFS (Claro está, si tienes la posibilidad que puedan
>> compartir mismo almacenamiento)? Que sistema de ficheros utiliza tu
>> cache? Como autentican los usuarios? Active Directory? Utilizas Single
>> Sign-On?
>>
> .../...
>
> El servicio en dado por una sola maquina montada en un proliant DL360,
> con una CPU dual core Intel Xeon a 2.33GHz y 4G de memoria.
> Tengo una maquina virtual (VMware ESX) para dar el servicio en caso de
> caída de la principal.
Esta es una de mis dudas. Tengo unas máquinas RX220 / RX200 para poder
montar el proxy, pero el rendimiento de I/O de los discos es malo. Al
final me he decantado por montarlo en virtual ya que ahí tendré mas
juego con el hardware. Pero, que opinas de montarlo todo en virtual?
Ya dependes de la capa virtualizada.
> No lo he montado en cluster por que fallo, y todavía no se por que,
> tengo montado un cluster con maquinas iguales y funciona perfecto, pero
> este no. Quizás el fallo sea por las versiones del "corosin" que al
> estar en "testin" cambia, lo tengo en asuntos pendientes el volver a
> montarlo.
Las máquinas que yo estoy montando las tengo detrás de un balanceador
con roundrobin.
> La maquina principal valida contra un A.D. montado sobre unos windows
> 2008R2 valida a los usuarios por kerberos o por los ticket de windows,
> además de por clave, pero solo activamos la validación de usuarios de
> forma puntual, pues tenemos problemas con algunas maquinas, y es que
> cuando lo activas el proxy tiene que identificar a todos los usuarios y
> las conexiones hechas por los sistemas (actualizaciones de software...)
> no tienen usuario valido, por lo que poner el sistema en orden da mucho
> trabajo.
Esto no lo entiendo muy bien. Dices que la validación de los usuarios
es contra AD, bien. Pero haces el Single Sign-On? Yo, los clientes los
tengo configurados con un .pac para poder poner las exclusiones y
redirigir el tráfico como yo quiera. Lo de la autenticación me
interesa mucho, ya que mi jefe está caprichado en que los usuarios no
tengan que poner usuario y contraseña para poder navegar y eso, según
las pruebas que hice en su día, ralentiza mucho y hay páginas que por
un bug del firefox no hacen bien la autenticación (al menos esto me
paso en su día).
> Además identificar por usuario mete retardos (que pueden ser minimizados
> ampliando el tiempo y tamaño de la cache, pero los mete).
Ampliando tiempo? a que tiempo te refieres?
> Lo que si usamos es la denegación de acceso a internet a maquinas que
> estén metidas en un grupo de dominio AD de maquinas sin internet.
> No utilizamos cache compartida pues los fallos del proxy principal son
> mínimos (prácticamente inexistentes si no los tocamos) y no creo que
> valga la pena el ahorro de tiempo perdido por el servidor secundario en
> descargar lo que tenia el primero en la cache contra la complejidad que
> añade tener un disco compartido.
Si, llevas razón. Yo habia pensado en tener una lun compartida entre
las máquinas virtuales. Pero esto, a parte de tener la complicación
añadida de ese disco, creo que puede penalizar en I/O de disco. No
se.... Al final creo que pondré 3 proxys con su cache individual para
cada uno y que todos sean hermanos de todos.
> El proxy secundario no tiene configurado control de usuarios, maquinas o
> acceso a paginas maliciosas alguno, tal y como esta montado no lo
> soportaría, pero para el poquísimo nivel de fallos se asume que en caso
> de estos no haya control hasta la reparación del principal.
> El sistema de ficheros, visto desde el SO es xfs (para la cache, para el
> sistema es ext3 y desde el squid3 es ufs:
> # mount
> /dev/cciss/c0d0p1 on / type ext3 (rw,errors=remount-ro)
> tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755)
> proc on /proc type proc (rw,noexec,nosuid,nodev)
> sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
> udev on /dev type tmpfs (rw,mode=0755)
> tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
> devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=620)
> /dev/cciss/c0d0p2 on /var/spool/squid3 type xfs (rw)
>
> # cat /etc/squid3/squid.conf |grep "cache_dir"
> # cache_dir aufs Directory-Name Mbytes L1 L2 [options]
> cache_dir aufs /var/spool/squid3 14336 16 256
>
> Tenemos unos 2500 PC en 4 sedes manejados por unos 6000 usuarios y por
> exigencias superiores todo el acceso a internet lo tenemos que encaminar
> a un proxy padre del que solo se su nombre y el puerto.
El servicio que yo quiero montar es para unos 1300 usuarios (de
momento). Yo lo quiero poner en varias máquinas ya que ahora lo tengo
todo en una sola y cuando quiero hacer algo en esa máquina me veo
pillado por que en ese momento no se puede reiniciar el servicio. Lo
que busco es un poco la alta disponibilidad y poder hacer un pequeño
mantenimiento en las máquinas sin que el servicio se vea afectado.
>
> Espero que te sea de utilidad y si crees que hay algo mal en la
> configuración que tengo doy por bien venida cualquier sugerencia.
Muchas gracias!!!!
>
>
>
>
> --
> Es hora de negarse a caminar de puntillas cerca de los que piden
> respeto, consideración, tratamiento especial, basados en que tienen fe
> religiosa, como si fuera noble creer afirmaciones sin base y
> superticiones antiguas. -A. C. Grayling, filósofo Por favor, NO utilice
> formatos de archivo propietarios para el intercambio de documentos, como
> DOC y XLS, sino HTML, RTF, TXT,CSV o cualquier otro que obligue a
> utilizar un programa de un fabricante concreto para tratar la
> información contenida en él. SALUD.
>
>
> --
> To UNSUBSCRIBE, email to debian-user-spanish-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
> Archive: [🔎] 1352987310.6685.36.camel@trujo.hvn.sas.junta-andalucia.es">http://lists.debian.org/[🔎] 1352987310.6685.36.camel@trujo.hvn.sas.junta-andalucia.es
>
Reply to: