Ich finde RHEL bzw. CentOS als Basis wirklich interessant, allerdings kann ich mit Gnome gar nichts anfangen und KDE 4.10 ist mir zu alt. Gibt es bei RHEL/CentOS ein Äquivalent zu den OBS bei SuSE?
der obs ist zwar von suse zusammengebuat, baut aber auch für andere distris pakete. sogar für ubuntu. könnte mir gut vorstellen das die auch kde centos haben.
Vielen Dank an das CentOS Team für diese hervorragende Distro. Und wenn auch EPEL und insbesondere RPMForge noch zusätzliche Pakete für CentOS 7 bereitstellen, hat man ein System welches sogar mit dem vergrützten Ubuntu in Sachen Multi-Media Unterstützung locker mithalten kann (ich spreche bewusst nicht von Debian, weil es ebenfalls eine solide Distro ist )
Wenn man diese Zusatzrepos hinzufügt, verliert man gleichzeitig den Hauptvorteil des Einsatzes eines RHEL-Klons: Nämlich die lückenlose Unterstützung mit Sicherheitsupdates über 10 Jahre hinweg. Langfristig dürften hierbei die Sicherheitsprobleme bei EPEL-Paketen die gleichen sein wie bei Ubuntus Universe- und Multiverse-Repos. Schon nach wenigen Jahren ist keine Versorgung mit aktuellen Extra-Paketen mehr möglich, da die Software in der RHEL-Basis zu alt geworden ist. Die Fixes der aktuellen Extrapaket-Versionen in die alten Versionen backzuporten ist etwas, woran diese freiwilligen Extra-Repoanbieter für gewöhnlich scheitern, da der Zeitaufwand dann viel zu groß wird. Es hat schon seinen Grund, warum Red Hat nicht wenige Pakete aus RHEL selbst heraushält: RHEL würde ansonsten unwartbar werden.
Das mit den "Sicherheitsproblemen der EPEL-Pakete" halte ich für stark übertrieben, denn EPEL sowie andere Extra-Repositories für RHEL stellen ja überwiegend keine System-Tools oder Dienste zur Verfügung, sondern fast ausschließlich Client-Anwendungen aus (überwiegend) dem Multimediabereich. Ausserdem liegt der Vorteil einer sog. Enterprise-Distribution im Vergleich zu einer Heimanwender-Distribution liegt auch nicht prinzipiell in einer größeren Sicherheit der verwendeten Pakete, sondern in einem stabilen Application Programming Interface (API) - also gleichbleibende Kernel und System-Bibliotheken Schnittstelle über den gesamten langjährigen Supportzeitraum einer solchen Distro. Dies stellt u.a. für professionelle (Software-)Entwickler das alles entscheidende Kriterium dar.
The plan is for EPEL packages to get updates as long as the corresponding RHEL release is supported. That is 10 years after the initial release according to the current errata support policy for 5 and 6 releases.
--- How can we be sure that someone will maintain the packages until end of life of the distribution the packages were built for?
The only way to be sure is to do it yourself, which is coincidentally the reason EPEL was started in the first place.
Software packages in EPEL are maintained on a voluntary basis. If you to want ensure that the packages you want remain available, get involved directly in the EPEL effort. More experienced maintainers help review your packages and you learn about packaging. If you can, get your packaging role included as part of your job description; EPEL has written a generic description that you can use as the basis for adding to a job description.
We do our best to make this a healthy project with many contributors who take care of the packages in the repository, and the repository as a whole, for all releases until RHEL closes support for the distribution version the packages were built for. That is ten years after release (currently) -- a long time frame, and we know a lot can happen in ten years. Your participation is vital for the success of this project. "
Genau das passiert bei RHEL 5, 6 und 7 nicht, da Red Hat immer sofort fixt. Notfalls wirft Red Hat unsichere, unfixbare Software sofort aus der Distro (Adobe Reader, Helix Player).
Diese annähernd hundertprozentige Sicherheit geht beim Einbinden von Third-Party-Repos zwangsläufig verloren. Der "Sich-in-punkto-Sicherheit-um-nichts-kümmern-müssen-Vorteil" ist dahin.
Bei Ubuntu LTS kann ich dieses Sicherheitsniveau z.B. dadurch erreichen, dass ich meine Softwareauswahl auf Ubuntu Main beschränke.
Ich finde RHEL bzw. CentOS als Basis wirklich interessant, allerdings kann ich mit Gnome gar nichts anfangen und KDE 4.10 ist mir zu alt. Gibt es bei RHEL/CentOS ein Äquivalent zu den OBS bei SuSE?
der obs ist zwar von suse zusammengebuat, baut aber auch für andere distris pakete. sogar für ubuntu. könnte mir gut vorstellen das die auch kde centos haben.
Zumindest sollte es möglich sein das auf Basis von Fedora Paketen dort selber zu machen. RHEL7 wird im OBS schon unterstützt.
Möglich ist das bestimmt. Nur bauen sich die RHEL-Pakete nicht von alleine. Die openSUSE-Community erstellt diese nicht standardmäßig.
Ein Beispiel hierzu, wie das aussehen kann:
http://download.opensuse.org/repositories/Education/
oder
http://download.opensuse.org/repositories/Application:/Geo/
Vielen Dank an das CentOS Team für diese hervorragende Distro. Und wenn auch EPEL und insbesondere RPMForge noch zusätzliche Pakete für CentOS 7 bereitstellen, hat man ein System welches sogar mit dem vergrützten Ubuntu in Sachen Multi-Media Unterstützung locker mithalten kann (ich spreche bewusst nicht von Debian, weil es ebenfalls eine solide Distro ist
)
Wenn man diese Zusatzrepos hinzufügt, verliert man gleichzeitig den Hauptvorteil des Einsatzes eines RHEL-Klons: Nämlich die lückenlose Unterstützung mit Sicherheitsupdates über 10 Jahre hinweg. Langfristig dürften hierbei die Sicherheitsprobleme bei EPEL-Paketen die gleichen sein wie bei Ubuntus Universe- und Multiverse-Repos. Schon nach wenigen Jahren ist keine Versorgung mit aktuellen Extra-Paketen mehr möglich, da die Software in der RHEL-Basis zu alt geworden ist. Die Fixes der aktuellen Extrapaket-Versionen in die alten Versionen backzuporten ist etwas, woran diese freiwilligen Extra-Repoanbieter für gewöhnlich scheitern, da der Zeitaufwand dann viel zu groß wird. Es hat schon seinen Grund, warum Red Hat nicht wenige Pakete aus RHEL selbst heraushält: RHEL würde ansonsten unwartbar werden.
Das mit den "Sicherheitsproblemen der EPEL-Pakete" halte ich für stark übertrieben, denn EPEL sowie andere Extra-Repositories für RHEL stellen ja überwiegend keine System-Tools oder Dienste zur Verfügung, sondern fast ausschließlich Client-Anwendungen aus (überwiegend) dem Multimediabereich. Ausserdem liegt der Vorteil einer sog. Enterprise-Distribution im Vergleich zu einer Heimanwender-Distribution liegt auch nicht prinzipiell in einer größeren Sicherheit der verwendeten Pakete, sondern in einem stabilen Application Programming Interface (API) - also gleichbleibende Kernel und System-Bibliotheken Schnittstelle über den gesamten langjährigen Supportzeitraum einer solchen Distro. Dies stellt u.a. für professionelle (Software-)Entwickler das alles entscheidende Kriterium dar.
Das ist nicht als Vorwurf an das EPEL-Projekt gemeint.
Es geht hier um Grundsätzliches.
Siehe hierzu:
https://fedoraproject.org/wiki/EPEL/FAQ#How_long_are_EPEL_packages_updated.3F
"
--- How long are EPEL packages updated?
The plan is for EPEL packages to get updates as long as the corresponding RHEL release is supported. That is 10 years after the initial release according to the current errata support policy for 5 and 6 releases.
--- How can we be sure that someone will maintain the packages until end of life of the distribution the packages were built for?
The only way to be sure is to do it yourself, which is coincidentally the reason EPEL was started in the first place.
Software packages in EPEL are maintained on a voluntary basis. If you to want ensure that the packages you want remain available, get involved directly in the EPEL effort. More experienced maintainers help review your packages and you learn about packaging. If you can, get your packaging role included as part of your job description; EPEL has written a generic description that you can use as the basis for adding to a job description.
We do our best to make this a healthy project with many contributors who take care of the packages in the repository, and the repository as a whole, for all releases until RHEL closes support for the distribution version the packages were built for. That is ten years after release (currently) -- a long time frame, and we know a lot can happen in ten years. Your participation is vital for the success of this project. "
Genau das passiert bei RHEL 5, 6 und 7 nicht, da Red Hat immer sofort fixt. Notfalls wirft Red Hat unsichere, unfixbare Software sofort aus der Distro (Adobe Reader, Helix Player).
Diese annähernd hundertprozentige Sicherheit geht beim Einbinden von Third-Party-Repos zwangsläufig verloren. Der "Sich-in-punkto-Sicherheit-um-nichts-kümmern-müssen-Vorteil" ist dahin.
Bei Ubuntu LTS kann ich dieses Sicherheitsniveau z.B. dadurch erreichen, dass ich meine Softwareauswahl auf Ubuntu Main beschränke.
Welch ein Unsinn
EPEL ist Teil der Fedora-Infrastruktur
Das ist was völlig anderes als Ubuntu/Cannoncial
Erst informieren und dann Behauptungen aufstellen
https://koji.fedoraproject.org/koji/builds?tagID=78&inherited=0&order=-completion_time
https://koji.fedoraproject.org/koji/packageinfo?packageID=2556
mod_security-2.6.8-6.el5 2014-04-18 16:12:34
EPEL ist die ganze Testphase der letzten Monate schon verfügbar