Salu2 Amigos
Quisiera hacer una consulta a manera de encuesta aqui en la lista y es sobre el uso de repositorios adicionales a los q usamos comunmente en la distribucion.
yo desde q comenze a usar CentOS (desde el Release de la version 4 tanto de RHEL y CentOS) comenze a complementarlo siempre con los repos de dag y dries, q mas adelante se juntaron practicamente en lo q es hoy rpmforge.
cuando necesitaba algo mas alla de ellos, generalmente iba a fedora/fedora extras, bajaba el src.rpm y a backportearlo. Hasta q salio Karan con su repo justo de backporting de fedora extras y salvo un problema de conflicto con el paquete spamassassin (q el mismo karan retiro luego q se le reporto) vi q se llevaba de mil perillas con dag/rpmforge.
En algun momento (aun en CentOS 4) probe ATrpms y el resultado fue lo q seguro varios experimentaron en su momento, q te reescriba paquetes core del sistema operativo. Lo interesante era q si solo usaba ATrpms como repositorio, podia salvarse la situacion, pero si agregaba a rpmforge/karan/kde-redhat o algun otro repo para EL4/CentOS4, la cosa explotaba ^_^.
A la salida de CentOS-5/RHEL5 segui con la combinacion rpmforge/karan para mis repos adicionales.
Luego salio la iniciativa de EPEL, y aqui es donde me quede medio parado todavia decidiendo darle una mirada.
Para lo q EPEL comenzaba a ofrecer, Karan llevaba tiempo haciendo lo mismo con un repositorio mas probado y q seguia el intento de establecer el estandar de repotags para poder identificar rpms de un repositorio alternativo, en EPEL recuerdo q luego de una controversial decision se decidio no usar repotags. Sin embargo EPEL es algo asi como el proyecto oficial para ofrecer un repositorio de extras par alas RHEL derived distros y es probable q mas adelante se tenga un soporte oficial del mismo.
ATrpms al menos para RHEL5/CentOS5 ya suavizo su politica y en su repo estable solo hay paquetes adicionales para la distribucion (aunq su repo testing/unstable si reescribe las cosas)
yo aun sigo usando rpmforge/karan y habilito generalmente centosplus (de donde excluyo los kernels) y centos-testing (openldap 2.3 me salvo la vida cuando usaba centos4 y ahora el port de directory server esta genial). Ultimamente vengo usando el repositorio de sernet-samba (versiones rpm oficiales de los devs de samba de sus ultimas versiones) pq sinceramente el samba q viene en rhel5/centos5 no termina de conversar bien con Active Directory en el 2003 y menos en el 2008. Desde q lo tengo, samba y winbind van seditas. en algunos casos por requerimientos de desarrollo hemos tenido q instalar postgresql desde los rpms proveidos por ellos.
solo una vez he usado epel y ha sido por requerir paquetes del repositorio de remi (un demente frances q da php 5.2, apache 2.2.8 y versiones bastante avanzadas de paquetes para lo q es web)
y uds amigos ? cual es su coctel preferido de repositorios adicionales ?
-- Yonsy Solis (aka BlackHand)
BlackHand wrote:
Salu2 Amigos
Quisiera hacer una consulta a manera de encuesta aqui en la lista y es sobre el uso de repositorios adicionales a los q usamos comunmente en la distribucion.
yo estoy dejando de usar rpmforge puesto que ellos están dejando desactualizados muchos paquetes (por ejemplo el nagios del que hoy se habló), por supuesto ya no uso dries/dag porque ellos se unieron en rpmforge.
No uso ATRPMS excepto cuando quiero bajar el libspf_2 de ellos. Por lo demás cuando les usé me armó un relajo enorme en una máquina. Ah, a veces para asterisk le uso pero bajando al detalle los rpm.
No uso karan, karan eran paquetes de fedora para centos... pero la gente de epel ha hecho ya su labor y al parecer karan ha quitado el pie a este repo.. hace rato no les uso.
Estoy usando solamente epel para los servidores... realmente está creciendo bastante epel y me siento contento con la forma de proceder.
Centos-plus, hum, lo uso para xfs, pero le hago un --enablerepo=centosplus cuando lo he necesitado, no lo dejo activado por defecto. Y para los usuarios de centos-4 que me piden que les instale php-5, ahi le uso el de centos-plus.
Cuando he tenido necesidad, usé priority plugin para marcar epel prioritario sobre rpmforge, y así poder hacer uso de algunos paquetes de rpmforge.
saludos epe
Ing. Ernesto Pérez Estévez escribió:
yo estoy dejando de usar rpmforge puesto que ellos están dejando desactualizados muchos paquetes (por ejemplo el nagios del que hoy se habló), por supuesto ya no uso dries/dag porque ellos se unieron en rpmforge.
En la medida de lo posible trato de evitar utilizar repositorios extra, y si lo hago normalmente es para instalar paquetes muy puntuales desde RPMforge, *siempre* dejo el repo deshabilitado para evitar cualquier posible problema.. y cuando los necesito para instalar/actualizar siempre lo habilito manualmente con --enablerepo.
Creo recordar que centos-plus solo lo he utilizando en CentOS 4 para instalar PHP 5 y MySQL 5, también en la medida de lo posible evitabamos trabajar con el.
Estoy usando solamente epel para los servidores... realmente está creciendo bastante epel y me siento contento con la forma de proceder.
Estoy siguiendo de cerca la evolución de EPEL.. pero lo cierto es que algunos paquetes están mucho mas desactualizados en EPEL que en rpmforge, por ejemplo Cfengine:
http://download.fedora.redhat.com/pub/epel/5/i386/repoview/cfengine.html http://dag.wieers.com/rpm/packages/cfengine/
El paquete de EPEL es casi un año mas viejo.. y de rpmforge tampoco es demasiado: Dic del 2007.. Dag ha dejado de actualizar?
Veo un problema en esta situación.. mucha gente está trabajando por separado. Lo ideal sería que todos los proyectos unificaran sus esfuerzos.. así tendíamos mas paquetes, actualizados con mayor frecuencia.. y al estar centralizado sería mucho mas sencillo para los usuarios/desarrolladores/colaboradores, todos iríamos al mismo sitio para colaborar o para descargar.. ahora según lo que quieras hacer vamos a un repo o a otro, ¿que opinaís de esto, soluciones?
Saludos!
-- Santi Saez http://woop.es
On Thu, 2008-11-06 at 01:48 +0100, Santi Saez wrote:
Veo un problema en esta situación.. mucha gente está trabajando por separado. Lo ideal sería que todos los proyectos unificaran sus esfuerzos.. así tendíamos mas paquetes, actualizados con mayor frecuencia.. y al estar centralizado sería mucho mas sencillo para los usuarios/desarrolladores/colaboradores, todos iríamos al mismo sitio para colaborar o para descargar.. ahora según lo que quieras hacer vamos a un repo o a otro, ¿que opinaís de esto, soluciones?
la gente de rpmforge, freshrpms, karan e incluso atrpms propusieron la estandarizacion de un tag adicional al rpm para identificar el repositorio de origen para asi poder manejar las dependencias entre repositorios ademas de proveer los fuentes de los rpms (cosa q ocasionaba problemas en fedora antes con fedora.us)
en su momento la gente de epel rechazo este item de los tag para repos pero si quedaron claros en q si era imperativo dar los srpms para poder saber al menos a lo q se enfrentan. kde-redhat y remi por ejemplo ahora solitican q se tenga activado epel para manejar sus dependencias (y ellos no estar metiendo paquetes de mas en sus repos) atrpms medio q apoya a epel pero sigue con sus propios paquetes, eso si, sin toquetear los paquetes base (a menos q actives atrpms testing)
karan ya habia comenzado con un esfuerzo similar al q esta haciendo epel ahora mucho antes q este y con una intencion de ser lo mas compatible posible a rpmforge (recuerdo q reporte un problema con el paquete clamav q proveia karan q chocaba con el clamav q proveia rpmforge, al final karan saco su paquete) el problema con epel es q este comenzo cuando habia fedora extras asi q era facil diferenciar q paquetes iban en epel (lo mismo con karan) cuando fedora unifico sus paquetes, la linea como q no quedo tan definida.
Que unan esfuerzos ahora lo veo poco probable, pero la situacion ya no es tan caotica como hace un buen tiempo atras, no es transparente el pase de un repo a otro pero se pueden evitar transparentemente los conflictos entre ellos.
yo personalmente pienso q lo q le falta a RHEL y CentOS seria un sistema tipo SuSE, donde construyen de manera automatica los paquetes a peticion de los usuarios. Se podria usar Fedora (incluso Rawhide) para hacer backport de paquetes a RHEL/CentOS de manera automatica (en mi experiencia reconstruir rpms de Fedora en CentOS casi siempre se puede hacer sin toquetear el srpm original, solo indicando el release al momento de reconstruir) un sistema q construya automaticamente desde los srpms de fedora y q si se detecta algun problema en la construccion, se pueda aplicar algun parche para su construccion.
-- Yonsy Solis (aka BlackHand)
Saludos.
Tengo un problema, en un servidor de mi empresa, tengo corriendo un MRTG, pero cuando en las dependencias desconectan los routers de la red, cada 5 minutos, tiempo que defini para verificar el trafico los routers, recibo un correo del Cron, indicandome que el existe un router caido, y deben imaginarse lo molesto que resulta.
Existe alguna configuracion para evitar que esto suceda, ya que el registro de las dependencias conectadas lo hago con otro software de reporte.
Saludos.
Est. Ing. Yoinier Hernandez Nieves Administrador de TinoLT.
------------------------------------------------------------------ Los Joven Club de Las Tunas Saludan el "21 Aniversario Honrando Nuestra Historia"
https://webmail.ltu.jovenclub.cu http://www.ltu.jovenclub.cu ------------------------------------------------------------------ Este mensaje ha sido enviado usando IMP, the Internet Messaging Program.
administrador@ltu.jovenclub.cu wrote:
Saludos.
Tengo un problema, en un servidor de mi empresa, tengo corriendo un MRTG, pero cuando en las dependencias desconectan los routers de la red, cada 5 minutos, tiempo que defini para verificar el trafico los routers, recibo un correo del Cron, indicandome que el existe un router caido, y deben imaginarse lo molesto que resulta.
supongo que hablas de que el cron te envía un mail cada vez que falla..
entonces reirige todo salida del cron hacia /dev/null
al final de la línea del mrtg en el cron ponle: &> /dev/null eso hará que todo mensaje de salida vaya al vacío saludos epe
Si sale un router del monitoreo con mrtg (o alguna interface del router) lo logico es reeditar el archivo mrtg.cfg
Ahora si tienes monitoreando un ruteador Cisco en el que se han definido subinterfaces, al apagar y encender el router, a pesar de que las subinterfaces siguen operando, mrtg sigue monitoreando cualquier otra cosa, menos la subinterface previamente definida. Al menos ese problema tengo yo. Me toca reeditar mrtg.cfg y capturar nuevamente la subinterface exacta, y rogar que ya no necesite apagar y encender el router. Si alguien ha tenido este problema y lo ha solucionado, mucho agradeceré que nos comente como lo hizo.
Slds
Ed
----- Original Message ----- From: ""Ing. Ernesto Pérez Estévez"" centos@nuestroserver.com To: centos-es@centos.org Sent: Thursday, November 06, 2008 10:48 AM Subject: Re: [CentOS-es] Sobre MRTG, Cron y Mail!!
administrador@ltu.jovenclub.cu wrote:
Saludos.
Tengo un problema, en un servidor de mi empresa, tengo corriendo un MRTG, pero cuando en las dependencias desconectan los routers de la red, cada 5 minutos, tiempo que defini para verificar el trafico los routers, recibo un correo del Cron, indicandome que el existe un router caido, y deben imaginarse lo molesto que resulta.
supongo que hablas de que el cron te envía un mail cada vez que falla..
entonces reirige todo salida del cron hacia /dev/null
al final de la línea del mrtg en el cron ponle: &> /dev/null eso hará que todo mensaje de salida vaya al vacío saludos epe _______________________________________________ CentOS-es mailing list CentOS-es@centos.org http://lists.centos.org/mailman/listinfo/centos-es
Edwin Aguilar wrote:
Si sale un router del monitoreo con mrtg (o alguna interface del router) lo logico es reeditar el archivo mrtg.cfg
Ahora si tienes monitoreando un ruteador Cisco en el que se han definido subinterfaces, al apagar y encender el router, a pesar de que las subinterfaces siguen operando, mrtg sigue monitoreando cualquier otra cosa, menos la subinterface previamente definida. Al menos ese problema tengo yo. Me toca reeditar mrtg.cfg y capturar nuevamente la subinterface exacta, y rogar que ya no necesite apagar y encender el router. Si alguien ha tenido este problema y lo ha solucionado, mucho agradeceré que nos comente como lo hizo.
Slds
Ed
----- Original Message ----- From: ""Ing. Ernesto Pérez Estévez"" centos@nuestroserver.com To: centos-es@centos.org Sent: Thursday, November 06, 2008 10:48 AM Subject: Re: [CentOS-es] Sobre MRTG, Cron y Mail!!
administrador@ltu.jovenclub.cu wrote:
Saludos.
Tengo un problema, en un servidor de mi empresa, tengo corriendo un MRTG, pero cuando en las dependencias desconectan los routers de la red, cada 5 minutos, tiempo que defini para verificar el trafico los routers, recibo un correo del Cron, indicandome que el existe un router caido, y deben imaginarse lo molesto que resulta.
edwin, yo pienso que lo que le sucede es que a veces se le caen routers por situaciones comunes en sus redes wan en su país y no es algo digamos conocido, se caen, vienen al poco rato o largo rato, en fin que no siguen un patrón.... pienso!
saludos! epe
Saludos.
Tengo un problema, en un servidor de mi empresa, tengo corriendo un MRTG, pero cuando en las dependencias desconectan los routers de la red, cada 5 minutos, tiempo que defini para verificar el trafico los routers, recibo un correo del Cron, indicandome que el existe un router caido, y deben imaginarse lo molesto que resulta.
Existe alguna configuracion para evitar que esto suceda, ya que el registro de las dependencias conectadas lo hago con otro software de reporte.
Saludos.
Est. Ing. Yoinier Hernandez Nieves Administrador de TinoLT.
------------------------------------------------------------------ Los Joven Club de Las Tunas Saludan el "21 Aniversario Honrando Nuestra Historia"
https://webmail.ltu.jovenclub.cu http://www.ltu.jovenclub.cu ------------------------------------------------------------------ Este mensaje ha sido enviado usando IMP, the Internet Messaging Program.
-
"Ing. Ernesto Pérez Estévez" -
administrador＠ltu.jovenclub.cu -
BlackHand -
Edwin Aguilar -
Santi Saez