On Wed, Jan 12, 2005 at 10:29:55AM -0300, Ricardo Mun~oz A. wrote: > El mi?, 12-01-2005 a las 01:44, Satoru Lucas Shindoi escribi?: > > [...] > > > Creo IMHO que los "novatos" (perdon por llamarlos "pavos" pero.... > > no capte su atencion? :-D) deberian, por respeto al resto (sea novato > > o experto), tener muy en cuenta los puntos 1 y 2 (sin descuidar el > > resto) Y los expertos (yo tambien? :-P) deberian tener un poco mas de > > paciencia. Son nuestros "hijos" que estan tratando de crecer. Hay que > > encaminarlos, ense?arles, siendo tolerantes (hasta cierto margen), > > darle algunos chirlos de vez en cuando :-D > > creo que ahi esta el punto... de que se extra?an, si luego de tanto > esforzarse en difundir Linux el tema se empieza a masificar y las > nuevas generaciones no tienen la cultura "hacker" en sus venas?? > > lo unico que queda, tal como lo planteo Satoru, es encaminarlos, y > tener mucha paciencia...
De acuerdo, pero como en todos lados o en cualquier comunidad de cualquier indole, hay reglas. No hay que tener cultura "hacker" para cumplir las reglas estipuladas. Es solo una cuestion de sentido comun y educacion para con los demas participantes y especialmente para quien gentilmente (sin obligacion alguna) brinda los recursos. Saludos. -- Rodrigo Henriquez M. http://www.corporacionlinux.cl Corporacion Linux S.A. Fonos: 02 2442988 - 02 2444250 From [EMAIL PROTECTED] Wed Jan 12 10:49:04 2005 From: [EMAIL PROTECTED] (Rodrigo Henriquez M - Corporacion Linux S.A.) Date: Wed Jan 12 11:02:46 2005 Subject: QDISC y loopback In-Reply-To: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> On Wed, Jan 12, 2005 at 10:12:11AM -0300, Miguel Oyarzo wrote: [...] > por que no ser?a recomendable? Por que limitarias una tarea que el kernel sabe manejar perfectamente. > Creo q Victor pens? rapidamente una aplicacion. > Este ejemplo se ma acaba de ocurrir por la pregunta que el hace (esta muy > interesante su duda). > > Si spamd tiene muy sobrecargada la CPU podrias limitar el trafico de > paquetes de consutla a si misma (de"lo" a "lo" a la puerta 783). > En sistemas de alto trafico de correo spamd suele atorar la CPU. > Lo mismo con imap y otras cosas. Si tu sistema esta colapsando, es por sobrecarga o por una mala dimension de tus requerimientos base. Como mencione anteriormente, el kernel sabe manejar esto siempre y cuando tenga los recursos suficientes para hacerlo. Agregarle un componente extra para limitar el acceso a un dispositivo (ya sea fisico o virtual) es solo darle mas trabajo al kernel. > tengo justo un servidor proximo a un colapso de CPU... probar? el efecto > de limitar la salida de paquetes desde "lo" y publicar? aqui el resultado. Tal vez salgan un par de resultados interesantes de ello. Seria bueno verlos. Saludos. -- Rodrigo Henriquez M. http://www.corporacionlinux.cl Corporacion Linux S.A. Fonos: 02 2442988 - 02 2444250 From [EMAIL PROTECTED] Wed Jan 12 11:09:06 2005 From: [EMAIL PROTECTED] (Alvaro Herrera) Date: Wed Jan 12 11:09:10 2005 Subject: QDISC y loopback In-Reply-To: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> On Wed, Jan 12, 2005 at 09:24:50AM -0300, Rodrigo Henriquez M - Corporacion Linux S.A. wrote: Hola, > No entiendo cual es la idea. Recuerda que las cosas muchas veces tienen usos que ni siquiera los inventores originales llegaron a imaginar. > Probar _que pasa_ si generas una clase para controlar la interfaz de > loopback? > > Lo que pasa por loopback no es un trafico _real_. Asi que no tiene > sentido medirlo a menos que necesites hacer lo que puse mas arriba. Hay varias aplicaciones que se comunican usando loopback (eso _es_ trafico real). Es cierto que probablemente muchas de ellas podrian usar sockets Unix en vez de IP, pero ese no es el punto. (Lo bueno es que el uso de loopback esta probablemente casi tan optimizado como el de sockets Unix ... no tienes que pasar por ninguna tarjeta de red de verdad, y por lo tanto no pagas un sobrecosto en trafico PCI ni nada parecido). De hecho el mismo Postgres lo puedes hacer pasar por loopback ... probablemente controlar otras cosas podria ser mas razonable, cuyo uso de la red sea un indicador importante de actividad (como movimiento de correo: control de spam o antivirus, por ej.) -- Alvaro Herrera (<[EMAIL PROTECTED]>) "In a specialized industrial society, it would be a disaster to have kids running around loose." (Paul Graham) From [EMAIL PROTECTED] Wed Jan 12 11:19:22 2005 From: [EMAIL PROTECTED] (Horst von Brand) Date: Wed Jan 12 11:19:27 2005 Subject: QDISC y loopback In-Reply-To: Your message of "Wed, 12 Jan 2005 10:12:11 -0300." <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> Miguel Oyarzo <[EMAIL PROTECTED]> dijo: [...] > Si spamd tiene muy sobrecargada la CPU podrias limitar el trafico de > paquetes de consutla a si misma (de"lo" a "lo" a la puerta 783). En > sistemas de alto trafico de correo spamd suele atorar la CPU. Las consultas no atoran la CPU, es el procesamiento de los mensajes. Y en mi experiencia spamassassin se aturde (loop infinito?) con ciertos mensajes, particularmente al usar reglas aprendidas por usuario. La solucion chancha ha sido deshabilitar eso (igual no es nada divertido tener que subir archivos de varios MiB via NFS de cada una las cuentas destino para cada mensaje que llega...). Para nuestra solucion (adicional) actual, vease el mensaje sobre greylisting. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513 From [EMAIL PROTECTED] Wed Jan 12 11:11:50 2005 From: [EMAIL PROTECTED] (Rodrigo Henriquez M - Corporacion Linux S.A.) Date: Wed Jan 12 11:25:28 2005 Subject: QDISC y loopback In-Reply-To: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> On Wed, Jan 12, 2005 at 11:09:06AM -0300, Alvaro Herrera wrote: > On Wed, Jan 12, 2005 at 09:24:50AM -0300, Rodrigo Henriquez M - Corporacion > Linux S.A. wrote: > > Hola, Hola. > > No entiendo cual es la idea. > > Recuerda que las cosas muchas veces tienen usos que ni siquiera los > inventores originales llegaron a imaginar. De acuerdo. > > Probar _que pasa_ si generas una clase para controlar la interfaz de > > loopback? > > > > Lo que pasa por loopback no es un trafico _real_. Asi que no tiene > > sentido medirlo a menos que necesites hacer lo que puse mas arriba. > > Hay varias aplicaciones que se comunican usando loopback (eso _es_ > trafico real). Pero no a traves de un dispositivo fisico. > Es cierto que probablemente muchas de ellas podrian usar > sockets Unix en vez de IP, pero ese no es el punto. (Lo bueno es que el > uso de loopback esta probablemente casi tan optimizado como el de > sockets Unix ... no tienes que pasar por ninguna tarjeta de red de > verdad, y por lo tanto no pagas un sobrecosto en trafico PCI ni nada > parecido). Exacto. > De hecho el mismo Postgres lo puedes hacer pasar por loopback ... > probablemente controlar otras cosas podria ser mas razonable, cuyo uso > de la red sea un indicador importante de actividad (como movimiento de > correo: control de spam o antivirus, por ej.) Totalmente de acuerdo en todo. A lo que voy es que _no_ es necesario filtrar ese trafico ya que es una labor que el kernel debe manejar. Agregarle un filtro, es solo darle mas trabajo al kernel. En el caso de las interfaces reales, es otra cosa, ya que lo que pretendes filtrar es el como y cuando manejar los paquetes de salida. Saludos. -- Rodrigo Henriquez M. http://www.corporacionlinux.cl Corporacion Linux S.A. Fonos: 02 2442988 - 02 2444250 From [EMAIL PROTECTED] Wed Jan 12 11:41:53 2005 From: [EMAIL PROTECTED] (Miguel Oyarzo) Date: Wed Jan 12 11:42:09 2005 Subject: QDISC y loopback In-Reply-To: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> At 10:49 a.m. 12/01/2005, Rodrigo Henriquez M - Corporacion Linux S.A. wrote: >On Wed, Jan 12, 2005 at 10:12:11AM -0300, Miguel Oyarzo wrote: >[...] > > > por que no seria recomendable? > >Por que limitarias una tarea que el kernel sabe manejar perfectamente. > >Si tu sistema esta colapsando, es por sobrecarga o por una mala >dimension de tus requerimientos base. > >Como mencione anteriormente, el kernel sabe manejar esto siempre y >cuando tenga los recursos suficientes para hacerlo. > >Agregarle un componente extra para limitar el acceso a un dispositivo >(ya sea fisico o virtual) es solo darle mas trabajo al kernel. No es suficiente argumento. Piensalo así: Un ejemplo de ello: La mayoría de los kernels de Linux manejan el trafico de las interfaces su cola por omision: pfifo_fast. Pero esta cola no es "justa" y en sistemas de mucho trafico es muy inutil. Por eso se programaron colas con clases (para QoS) con posibilida de cambiar a SFQ y colas similares. Yo me cambie hace tiempo desde pfifo_fast a SFQ pues al kernel necesitaba darle una cola mas justa y que le permira gestionar mejor el trafico. El resultado final es es mejor que bueno. Agregarle cosas al kernel no siempre es darle más trabajo.. a veces pasa al reves. >Tal vez salgan un par de resultados interesantes de ello. Seria bueno >verlos. uff.. ojalá... apenas tenga el tiempo publico el resultado... prometido! Salu2 Miguel Oyarzo INALAMBRICA Punta Arenas
