Servidor de Correos

[Eduardo]

El jue, 21-09-2006 a las 22:25 -0400, Horst H. von Brand escribió:
> Juan Martínez <jeugenio en umcervantes.cl> wrote:
> > Horst H. von Brand escribió:
> > > Juan Martínez <jeugenio en umcervantes.cl> wrote:
> > >> El Mie, 20 de Septiembre de 2006, 9:34 pm, Marcos Vargas escribió:
> > >
> > >>> Queria pedirles que me recomienden o en que me tengo que fijar al
> > >>> momento de comprar un servidor (procesador,memoria, disco,etc) y
> > >>> que servicio (qmail, sendmail, squirrimail), seria el mas adecuado y
> > >>> mejor segun uds. para alrededor de 500 cuentas de correo
> > >>> institucionales.
> > >
> > >> Haber...depende todo depende. Algunas pistas...
> > >>
> > >> - Cuanto tienes de tope por cuenta? (cuotas)
> > >> 	De ahi sale la capacidad del disco para el /home
> > >> 	Para el resto del sistema 10GB es mas que suficiente.
> > > Ojo, hay que considerar el espacio para correo (si, aca tenemos
> > > perejiles
> > > con 1GiB de correo sin borrar...)
> 
> > Por eso sugeria cuotas. Aca en la UMC, para los alumnos, tenemos 250MB
> > como cuota blanda y 255MB para dura.
> 
> Y decia "usuarios institucionales"... Aca, si me dejaran, a los perejiles
> con mas de 100KiB de mbox les amputaria los deditos, a la altura del codo,
> sin anestesia, y una cucharita de te. En publico, para que el resto
> escarmiente. Pero son "institucionales"...
jajaja HvB parece que tienes un trauma con ese método de tortura :P (te lo he leído en más de una ocacion).

Con respecto a lo del 100kiB, no creo que tu mbox sea de 100kiB, y como
decia un gran fisico «Dar el ejemplo no es la principal manera de
influir sobre los demás; es la única manera.»
> [...]
> 
> > >> Tambien, no es malo preguntarse si es necesario respaldar ese servidor.
> 
> > > Como que "preguntarse", /hay/ que hacerlo. COnsiderar grabador de DVD
> > > doble capa, y un disco adicional en el cual armar las imagenes (y
> > > guardar respaldos tambien).
> 
> > Es que esto depende de las politicas de cada empresa.
> 
> Nope. /Tiene/ que haber suficiente respaldo para poder reponer el servicio
> si el cacharro fallece de un sincope multiple. El sistema de correo
> electronico es /extremadamente/ critico. Si falla tu servidor web, o DNS,
> o... te enteras a la semana; si falla el correo electronico en un par de ms
> tienes la oficina llena de usuarios iracundos. Acaso no has visto las
> discusiones aca de que "greylisting retrasa el correo!!!"?
> 
> > Dado que no hay legislacion actual sobre la privacidad de la
> > correspondencia electronica, puede ser todo un problema hacer
> > respaldos. No olvidemos que la jueza Chevesic se valio de un vacio
> > legal para incautar los respaldos de los emails del MOP.
> 
> Bueno, si los respaldos duran lo que los originales por leer...
> 
> [...]
> 
> > >> jejeje....la que conozcas mas....Trata de no usar Fedora u otra que tenga
> > >> software demasiado actualizado...
> 
> > > No. Usa alguna de vida mas bien larga (Fedora anda de pelos, pero hay
> > > que actualizar al menos una vez al an~o). RPMistica, CentOS (clon de
> > > RHEL, si no quieres pagar por el soporte); debianita, algun Ubuntu de
> > > los designados "para servidor" (tienen una sigla especial)
> 
> > _server_ para ser precisos ;-)
> 
> No, algo de "larga vida".
> 
> > >, no Debian oficial porque el "estable" es prehistorico,
> 
> > Ni tanto ... Pero haciendo mezclas en apt, se puede tener un buen
> > compilado a la carta...
> 
> Eso es completamente insano. Estas tomando paquetes de algo que esta
> probado para funcionar en conjunto (estable) y le mezclas paquetes en
> prueba (ramas no estables). El resultado en principio es /menos/ estable
> que la version de prueba pura (que al menos son paquetes que se prueban
> juntos).
> 
> > > y el "actual" es 100% experimental
> > 
> > 100% no. Hay paquetes que si pueden tener mucho de experimental.
> 
> O sea, tiene partes experimentales. Cuales son, hoy? Cuales seran man~ana? 
> Lo sabes en detalle siempre? Tienes como /siempre/ evitar las piezas
> experimentales en forma confiable?
> [O sea, es experimental para efectos practicos.]
> 
> > Pero Etch (es decir, Debian 4.0) sale estable en diciembre de este
> > año.
> 
> Ver para creer. Hay una pelea inmensa entre los debianitas actualmente
> porque el cabecilla se involucro en un esquema para financiar a
> desarrolladores selectos para acelerar el proceso, y (ojala) cumplir la
> fecha prometida.
> 
> >      Los paquetes mas _populares_ tienen bastante poca actualizacion
> > (normalmente hago upgrade del sistema casi diariamente)
> 
> Y? Que el paquete sea popular no significa que no tenga ranas. O el que sea
> actualizado frecuentemente no significa que no resulte critico para tu
> funcionalidad deseada.
> 
> > Personalmente, aqui no hay habido ni un solo drama con Etch.
> 
> Bien por ti! Pero la pregunta no es si has tenido problemas, es si pones tu
> carrera en juego por no tener problemas fatales en un plazo razonable, bajo
> una carga de trabajo /bien/ diferente que la que significa un tarro de uso
> personal... y en tal caso, prefiero no ser el unico que esta poniendo su
> pellejo en /esa/ linea.
> 
> > Pero, para cerrar este punto... Si el amigo que consulta conoce mas
> > los derivados o el propio RH, entonces CentOS es su opcion. Si conoce
> > la linea de debian...el mismo debian etch, pero le sugiero muy
> > concientemente Ubuntu dapper server....
> 
> Exacto. RHEL (o SLES, o Ubuntu "server") tienen un grupo de ingenieros
> responsable de su funcionamiento como servidor detras.