Que pregunta no?, la famosa guerra de los clones.
CentOS: .src.rpm recompilados de RHEL
SL: .src.rpm recompilados de RHEL, con algunas modificaciones en algunas config.
Cuando instalé por esos tiempos SL6.1, lo hice porque había un total y completos "NO SE", en CentOS Team.
Su Team Leader se había ido, y todo quedo medio colgando, ademas, se fue con el buildsystem (el servidor de armado de RPM), con lo cual dejó a todos como dicen en mi país, en pelotas.
Eso provoco un exceso en la demora de la salida de CentOS 6.1, y retardo de updates en CentOS 6.0, así que como debia si o si instalar un server y escoger una de las dos, me decanté por la que tenia soporte en el momento, lo mismo paso con mi laptop.
Luego de algún tiempo, CentOS recuperó, o le donaron, un server para armar los RPM, con lo cual, incluso superó en velocidad a SL, sacando la version 6.3 aun mas rapido.
En aquel momento, de 6.1, cuando ya CentOS se habia puesto al día, SL demoraba 1, maximo 2 días en aplicar updates, mientras que CentOS 2-3, seguian con el problema del servidor, y uno como admin y paranoico, claro, estaba mas seguro con SL.
Vamos a distinguir algo con respecto a updates:
updates: Por lo general son security updates
fast track: (CentOS y RHEL): Corresponden a bugfix, lo cual no implica seguridad
sl-fast bugs: Corresponde al fast track de SL
El tiempo pasó y las cosas se han dado vuelta, y porque digo esto?, bueno, primero, antes de dar el batacazo a SL, voy a establecer unas diferencias entre ambos:
CentOS: Está orientado al uso puro y exclusivo de servidor, puede usarse como desktop, si, pero es identico a RHEL. Esto implica que muchas cosas de desktop en CentOS a veces dan un poco mas de trabajo.
Por algo Red Hat tiene una version desktop, que no es RHEL. Posee una excelente wiki, y tienen un contacto MUY directo con Red Hat y la gente de Fedora.
SL: Esta orientado al uso servidor, HPC, (El CERN...), y tambien desktop, dado que incluyen en sus repos, rpm que instalan los repos de terceros y los configura, con lo cual, se nota que apunta a algo un poco mas amplio que CentOS. Asimismo, podemos notarlo por la escasa wiki y documentacion, cosa que CentOS si posee.
Por contrapartida, SL, posee un foro, y un canal de IRC, con gente MUY MUY amigable, dispuesta siempre, a dar el mejor consejo que tengan, sin nigun resquemor, aunque a veces no sepan o no sean expertos.
Porque digo esto?, porque tanto el canal de CentOS en IRC, como foro, es muy elitista, y claro, se asume que uno es un RHCE, ademas de un admin de 50 años de edad, que trabaja con RHEL desde los 18, algo asi.
Por lo tanto, hacer una pregunta o algo en su canal oficial, o social, es como medio... pedirle peras al olmo, comparado a SL.
Algo que me llamó la atencion, es que CentOS viene por defecto con la configuracion de PAM, en md5, mientras que SL, en sha512, asumiedo que ellos copian al 100% a RHEL, asumo que este, debe venir asi, algo raro, viniendo de Red Hat.
En fin, el que sabe como organizar las cosas le da lo mismo, pero al recien llegado, no. Ustedes, vayan sumando y evaluando.
Existen otros cambios, que SL realiza en algunas configuraciones, que pueden verlas aquí y aquí. Algunos cambios son interesantes, como SL_password_for_singleuser, mencionado en el segundo link.
Hasta el momento, cualquiera diría, bueno, ya me voy quedando con SL, pero esperen.... esto no termina acá.
Tanto el cambio de SL_password_for_singleuser, como pam.d, y otros tantos, una persona que conoce del tema o bien es certificado en red hat, le da lo mismo SL que CentOS, dado que conoce esos detalles sin que esten en un repo o como un paquete, pero, para el usuario final, no es lo mismo.
Ahora bien, el dia 1/11/2012, pude comparar algo, teniendo 2 servidores corriendo uno con CentOS 6.3 y otro con SL 6.3, recibí una update bugfix en CentOS, que fué:
glibc-2.12-1.80.el6_3.6.x86_64, según el changelog, el error corregido fue:
* Mon Oct 8 14:00:00 2012 Patsy Franklin <3spfranklilaw@redhat.com> - 2.12-1.80.el6_3.6
- Don't free memory allocated by mempool allocator. (#864046)
El cual, por su número, se menciona en red hat errata, aquí: http://rhn.redhat.com/errata/RHBA-2012-1422.html
Repositorio de CentOS: glibc-2.12-1.80.el6_3.6.x86_64.rpm 01-Nov-2012 12:23
Si se fijan, se publico el .src.rpm, el día 1/11/2012, el update, en CentOS aparecio el mismo dia!.
Malas noticias... en SL no aparecio, siendo dia 4, ni en fast bugs, ni en testing, ni en rolling.
Si bien es un bugfix, al menos yo pediria que este registrado en fast bugs, como dicen que es, fast bugs se usa para bugfixes, no para security, por lo tanto, que pasa con SL?.
Nada, siempre fue así, solo, que comparado a CentOS en su peor momento, era lo mejor que había.
En la actualidad, para mi, sigue siendo mejor si van a instalar un desktop, dado que se ahorran muchas configuraciones de seguridad y repos, que, ya vienen por defecto, con la contra de unos dias de demora en bugfixes, ya veremos, cuando demora en aparecer aquí en mi SL, actualizaré el post.
Aunque el bug no implica seguridad, si leen bien, implica un problema de manejo de memoria, que en un server, puede traer problemas, y si le buscamos la vuelta, si, es un problema de seguridad.
Por eso, mi consejo actual, en vista de esto, que no debe ser ni el primer ejemplo ni el ultimo, es que si van a instalar un servidor, usen CentOS, eso si, no anden preguntando en su canal de IRC o foros, porque donde detecten que son novatos, los van a ignorar.
Si lo que buscan es un desktop estable, rapido y facil, sin mucho problema agregado a lo que ya es lidiar con repos, recomiendo SL, por sus repos, por su by default security, por su comunidad... etc.
Tambien se debe evaluar, que SL, dice "no siempre armamos los RPM de Red Hat apenas salen, porque rompen otras cosas, preferimos probar bien todo antes", con lo cual, uno pensaria "wow, estos tipos se toman las cosas en serio". Es a gusto de como se entienda!.
Ademas, alguno tambien podria decir "SL esta hecho por el CERN mientras que CentOS por una comunidad, asi como pasó eso con 6.1 y 6.0, puede pasar otra vez, y yo que hago con mi servidor?", lo cual es cierto, y entendible, yo pienso lo mismo, total... bugfix con demora, no siempre son graves, depende, y si es buen admin, se toma el RPM de CentOS y se instala, es lo mismo, identico.
En fín, para los que preguntaron, cual, como y porqué, acá estan las diferencias mas grandes, de aca en adelante, el usuario o admin es quien debe elegir uno u otro, segun lo que vaya a usar, lo que este dispuesto de sacrificar en haras de que otra cosa, o vice versa.
Espero haber aclarado dudas.
PD: Dedicado a todos los que han preguntado, y a la gente de muylinux.com, con su articulo copiado, de la guerra de los clones, donde no supieron explicar nada sobre el tema, que por cierto, me suelen bloquear comentarios ;).
PD2: Si no saben/pueden decidir, yo, usaría, CentOS para server y virtualizacion, y SL para desktop o workstation.
CentOS: .src.rpm recompilados de RHEL
SL: .src.rpm recompilados de RHEL, con algunas modificaciones en algunas config.
Cuando instalé por esos tiempos SL6.1, lo hice porque había un total y completos "NO SE", en CentOS Team.
Su Team Leader se había ido, y todo quedo medio colgando, ademas, se fue con el buildsystem (el servidor de armado de RPM), con lo cual dejó a todos como dicen en mi país, en pelotas.
Eso provoco un exceso en la demora de la salida de CentOS 6.1, y retardo de updates en CentOS 6.0, así que como debia si o si instalar un server y escoger una de las dos, me decanté por la que tenia soporte en el momento, lo mismo paso con mi laptop.
Luego de algún tiempo, CentOS recuperó, o le donaron, un server para armar los RPM, con lo cual, incluso superó en velocidad a SL, sacando la version 6.3 aun mas rapido.
En aquel momento, de 6.1, cuando ya CentOS se habia puesto al día, SL demoraba 1, maximo 2 días en aplicar updates, mientras que CentOS 2-3, seguian con el problema del servidor, y uno como admin y paranoico, claro, estaba mas seguro con SL.
Vamos a distinguir algo con respecto a updates:
updates: Por lo general son security updates
fast track: (CentOS y RHEL): Corresponden a bugfix, lo cual no implica seguridad
sl-fast bugs: Corresponde al fast track de SL
El tiempo pasó y las cosas se han dado vuelta, y porque digo esto?, bueno, primero, antes de dar el batacazo a SL, voy a establecer unas diferencias entre ambos:
CentOS: Está orientado al uso puro y exclusivo de servidor, puede usarse como desktop, si, pero es identico a RHEL. Esto implica que muchas cosas de desktop en CentOS a veces dan un poco mas de trabajo.
Por algo Red Hat tiene una version desktop, que no es RHEL. Posee una excelente wiki, y tienen un contacto MUY directo con Red Hat y la gente de Fedora.
SL: Esta orientado al uso servidor, HPC, (El CERN...), y tambien desktop, dado que incluyen en sus repos, rpm que instalan los repos de terceros y los configura, con lo cual, se nota que apunta a algo un poco mas amplio que CentOS. Asimismo, podemos notarlo por la escasa wiki y documentacion, cosa que CentOS si posee.
Por contrapartida, SL, posee un foro, y un canal de IRC, con gente MUY MUY amigable, dispuesta siempre, a dar el mejor consejo que tengan, sin nigun resquemor, aunque a veces no sepan o no sean expertos.
Porque digo esto?, porque tanto el canal de CentOS en IRC, como foro, es muy elitista, y claro, se asume que uno es un RHCE, ademas de un admin de 50 años de edad, que trabaja con RHEL desde los 18, algo asi.
Por lo tanto, hacer una pregunta o algo en su canal oficial, o social, es como medio... pedirle peras al olmo, comparado a SL.
Algo que me llamó la atencion, es que CentOS viene por defecto con la configuracion de PAM, en md5, mientras que SL, en sha512, asumiedo que ellos copian al 100% a RHEL, asumo que este, debe venir asi, algo raro, viniendo de Red Hat.
En fin, el que sabe como organizar las cosas le da lo mismo, pero al recien llegado, no. Ustedes, vayan sumando y evaluando.
Existen otros cambios, que SL realiza en algunas configuraciones, que pueden verlas aquí y aquí. Algunos cambios son interesantes, como SL_password_for_singleuser, mencionado en el segundo link.
Hasta el momento, cualquiera diría, bueno, ya me voy quedando con SL, pero esperen.... esto no termina acá.
Tanto el cambio de SL_password_for_singleuser, como pam.d, y otros tantos, una persona que conoce del tema o bien es certificado en red hat, le da lo mismo SL que CentOS, dado que conoce esos detalles sin que esten en un repo o como un paquete, pero, para el usuario final, no es lo mismo.
Ahora bien, el dia 1/11/2012, pude comparar algo, teniendo 2 servidores corriendo uno con CentOS 6.3 y otro con SL 6.3, recibí una update bugfix en CentOS, que fué:
glibc-2.12-1.80.el6_3.6.x86_64, según el changelog, el error corregido fue:
* Mon Oct 8 14:00:00 2012 Patsy Franklin <3spfranklilaw@redhat.com> - 2.12-1.80.el6_3.6
- Don't free memory allocated by mempool allocator. (#864046)
El cual, por su número, se menciona en red hat errata, aquí: http://rhn.redhat.com/errata/RHBA-2012-1422.html
Repositorio de CentOS: glibc-2.12-1.80.el6_3.6.x86_64.rpm 01-Nov-2012 12:23
Si se fijan, se publico el .src.rpm, el día 1/11/2012, el update, en CentOS aparecio el mismo dia!.
Malas noticias... en SL no aparecio, siendo dia 4, ni en fast bugs, ni en testing, ni en rolling.
Si bien es un bugfix, al menos yo pediria que este registrado en fast bugs, como dicen que es, fast bugs se usa para bugfixes, no para security, por lo tanto, que pasa con SL?.
Nada, siempre fue así, solo, que comparado a CentOS en su peor momento, era lo mejor que había.
En la actualidad, para mi, sigue siendo mejor si van a instalar un desktop, dado que se ahorran muchas configuraciones de seguridad y repos, que, ya vienen por defecto, con la contra de unos dias de demora en bugfixes, ya veremos, cuando demora en aparecer aquí en mi SL, actualizaré el post.
Aunque el bug no implica seguridad, si leen bien, implica un problema de manejo de memoria, que en un server, puede traer problemas, y si le buscamos la vuelta, si, es un problema de seguridad.
Por eso, mi consejo actual, en vista de esto, que no debe ser ni el primer ejemplo ni el ultimo, es que si van a instalar un servidor, usen CentOS, eso si, no anden preguntando en su canal de IRC o foros, porque donde detecten que son novatos, los van a ignorar.
Si lo que buscan es un desktop estable, rapido y facil, sin mucho problema agregado a lo que ya es lidiar con repos, recomiendo SL, por sus repos, por su by default security, por su comunidad... etc.
Tambien se debe evaluar, que SL, dice "no siempre armamos los RPM de Red Hat apenas salen, porque rompen otras cosas, preferimos probar bien todo antes", con lo cual, uno pensaria "wow, estos tipos se toman las cosas en serio". Es a gusto de como se entienda!.
Ademas, alguno tambien podria decir "SL esta hecho por el CERN mientras que CentOS por una comunidad, asi como pasó eso con 6.1 y 6.0, puede pasar otra vez, y yo que hago con mi servidor?", lo cual es cierto, y entendible, yo pienso lo mismo, total... bugfix con demora, no siempre son graves, depende, y si es buen admin, se toma el RPM de CentOS y se instala, es lo mismo, identico.
En fín, para los que preguntaron, cual, como y porqué, acá estan las diferencias mas grandes, de aca en adelante, el usuario o admin es quien debe elegir uno u otro, segun lo que vaya a usar, lo que este dispuesto de sacrificar en haras de que otra cosa, o vice versa.
Espero haber aclarado dudas.
PD: Dedicado a todos los que han preguntado, y a la gente de muylinux.com, con su articulo copiado, de la guerra de los clones, donde no supieron explicar nada sobre el tema, que por cierto, me suelen bloquear comentarios ;).
PD2: Si no saben/pueden decidir, yo, usaría, CentOS para server y virtualizacion, y SL para desktop o workstation.
Gracias por el artículo, SynFlag. Actualizaciones de seguridad que se demoran un día o dos, no me parece grave, la verdad. La documentación de CentOS es un punto muy importante a favor, pero si SL está más enfocada al escritorio, seguiré adelante con SL.
ResponderEliminarDe nada!, si, si bien se puede usar y en realidad lo usan como servidor, dado que, es un clon de RHEL, esas pequeñas demoras en bugfixes, mas los repos que estan para instalar, indican que no estan 100% enfocados SOLO a servidor.
EliminarPor mas que no sea seguridad, un servidor, por ejemplo, que corre unas 12 VPS usando KVM, un bugfix, que no es seguridad necesariamente, puede afectarlo. Por eso mi aclaracion.
Oye SynFlag, ¿qué opinión te merece Stella (http://li.nux.ro/stella/)? En principio no me interesa las distros derivadas, pero esta parece buena, salvo que comentan que podría tener problemas de incompatibilidad con las repos de Forge.
ResponderEliminarMira, no la he probado, pero basicamente se que es un remix de CentOS 6.3, y no sabria decirte mas de ella, porque no la probé como para evaluarla. Si los repos de nux corresponden a stella, y las cosas que he usado de ahi, funcionan muy bien.
EliminarDe la que si tengo referencias, por conocidos y colegas, es de ROSA Linux, que en su version servidor usa RHEL de base, y en su version desktop, un mix entre RHEL y Mandriva, dando mucha estabilidad y cosas relativamente nuevas, con KDE como desktop principal. Ademas, esta hecho por rusos, y que decirte, en estos años, me di cuenta que los rusos, son excelentes coders e informáticos, asi que yo le daria una probada.
Otros clones, son PUIAS, el cual si probe y te digo que anda muy bien, pero si, Stella es un remix de CentOS 6.3 con agregados de paqueteria, lo que, seria lo mismo que instalar CentOS o SL y añadir sus repos, algo que yo hice hace rato :).
En realidad todos los repos de terceros para RHEL tienen conflictos entre si, porque muchos ofrecen lo mismo, incluso en misma version pero de distintos repos, ergo, crea conflicto, es por eso que se usa yum priority y protect base, sabiendo elegir que si y que no para cada cosa (multimedia, server, etc) se ordenan y todo anda bien.
En estos dias le daré una probada en una VM, a ver que tal va y haré un post sobre ello.
Gracias por el apunte. En la página ponía que no era un fork, pero claro, al leer ahora tu artículo de Skype y ver que tienes las repos de nux (que pensaba que eran más o menos solo para Stella, aunque si es un remix obvio que pueda utilizarse también en CentOS/ SL), ya no resulta tan atractiva. En todo caso a ver que te encuentras cuando la pruebes.
EliminarSaludos, muy bueno tu análisis, respondiste a mi pregunta de ¿qué clon de redhat utilizar en un desktop o un workstation?, ya me pondré a descargar Scientific Linux a ver que tal rueda, realmente estoy cansado de los .deb y quiero incursionar en este tipo de distros que tienen como cierta formalidad con sus políticas que le dan un toque más profesional que las demás. Por otra parte Fedora no es lo mio, creo que deberían oficialmente volverse una distro RollingRelease de tanto que actualizan el kernel y el poco de paquetes casi a diario, quiero una distro meramente para trabajar y no para procrastinar, espero haberla encontrado.
ResponderEliminarLuis Mauricio,
EliminarSi, asi es, SL esta mas orientado al desktop, no deja de ser un clon como lo es CentOS, incluso Stella es buena opcion, sin romper la compatibilidad binaria. (Stella es el que posee el repo nux-dextop muy util). Te recomiendo probar las dos y fijarte cual te gusta mas o va mejor.
Fedora, mira, la verdad, comparto lo que decís, porque es tal cual, actualizan al último kernel siempre, hay updates como en una rolling release, asi que podrían hacerla rolling y dejar de joder con tantas versiones que no son mas que una continuación de la anterior.
Ahora bien, yo he planteado esto a algunos developers de Fedora, y otros miembros, lo que me han dicho, es que si bien parece ser rolling release o podria hacerse como tal, hay un punto en que no quieren, no es que no puedan. Es el hecho de que al introducir cambios muy significativos en cada release, si la vuelven rolling release, siempre se terminaria rompiendo algo (lo cual si analizas algunas cosas, es cierto). Asi que por eso preupgrade, futuro fedup, o bien yum a pelo. Algunos prefieren reinstalar conservando el /home, es lo mismo practicamente, dado que todos los rpm son reemplazados, y los archivos de configuracion en /etc.
Yo dejé de usar Fedora por eso mismo, no es que las updates rompan algo, es que me consumen tiempo que realmente uso para trabajar, asi es que opté por dejarla en el desktop para ir viendo cosas nuevas y en la laptop que es de trabajo, un clon de RHEL.
Muchas gracias por el artículo, me ha parecido estupendo.
ResponderEliminar¿Podrías añadir como haces los cambios para utilizar los repositorios de Centos o SL en una máquina funcionando?
Saludos Ricardo
Los repositorios se modifican desde terminal, y se encuentran todos bajo /etc/yum.repos.d/, alli estan todos, con extension .repo, los editas con nano, vim de preferencia.
Eliminar