haary schrieb
Nachteile:
- Obwohl mich die Erfahrung das Gegenteil lehrt geben mir die überall lesbaren Warnungen "Bleeding Edge" nicht als Produktiv-System zu verwenden zu denken.
- Die Pakete sind nicht signiert - was heutzutage ein Sicherheitsrisiko darstellt. Als Lösung fällt mir nur ein, das komplette System "from Scratch" selbst zu bauen.
Ich sag mal was zu den "Nachteilen":
BleedingEdge - es gibt einen Unterschied zwischen der
aktuellen stabilen Version von Upstream
(z.B. eines MTA) und einer preBeta eines MultimediaPlugins aus dem AUR oder Community.
Inwieweit man sich bei diesem Konzept auf einem Server eine "BleedingNose" holen kann, kommt
IMHO v.a. auf den Admin an.
Die meisten Probleme auf einem Desktop (sagen wir mal X.Org gerade, oder KDE4, oder das
Player xy plötzlich keinen Sound mehr bei YouTube macht,...) kommen auf einem (Produktiv)-Server
nicht vor.
Hingegen muß sich der Admin bei anstehenden Updates (ein blindes pacman -Syu und zwischendrin
einen Kaffee holen ist nicht) für die Hauptapplikationen über evtl. neuere Features oder Änderungen
informieren - bei Ustream halt. Und notfalls/bzw. besser eine Testumgebung haben. Das trifft aber
bei Release-basierenden Distros auch zu.
Ich sehe den Hauptpunkt beim Kernel - auf einem Server macht man die z.zt. recht häufigen
(Upstream)-Patchlevel-Updates nicht gerne mit. Da bietet sich ein eigener Kernel an, den
Standard-Arch-Kernel kann man ja trotzdem installiert haben und auch updaten - und bei Gelegenheit
auch immer mal testen. Aber auch hier muß der Admin entscheiden welche Updates er ggf. in den
eigenen Kernel einfließen läßt.
Bei einem Fileserver (mit Samba z.B.) kann es durch Upstream-Changes halt eher mal zur Situation
kommen: ein Update bedeutet evtl. Änderungen an den Clients. So etwas kann dich bei RollingRelease
halt evtl. unvermittelter treffen als z.B. bei Debian. Aber dem vorzubeugen bzw. damit umzugehen
ist Sache des Admins - nicht der Distribution.
Ähnliches gilt für DB-Server und Clients bzw. Client-Software.
Die Kombination Webserver/PHP kann von regelmäßigen (Upstream)-Updates eher profitieren IMHO.
Außerdem gibt es auch noch die Option - einfach nichts zu updaten (abgesehen von Dingen wie
das letzte Kernel-Exploit). Diese Entscheidung ist aber auch Sache des Admins. Ich habe z.B.
zwei Funktions-Server die ich irgendwann 2007 installiert habe - die kriegen kein Update (außer
den eben angesprochenen Kernel), da nicht öffentlich angebunden und die einfach nur "ihr Ding"
machen sollen.
Kurze Rede 😉 : Ob ich nun dpkg, aptitude, snaptics, pacman, yum oder rpm nutze - gefragt ist
primär der Admin. Er entscheidet ob, wann und welche Updates gemacht werden.
Und wenn du aus deiner Erfahrung mit Arch ja zurechtkommst ... sehe ich im Prinzip keine
Nachteile.
//Edit: zu den signierten Paketen.
Ist in der Tat ein Knackpunkt (und kann je nach Firmenpolicy/SLA ein No-Go darstellen). Allerdings
wird daran gearbeitet. Aktuell ist halt bei der Wahl des Mirrors der beste Weg: einen Mirror nehmen,
der schon vom erkennbaren Namen/Firma/Universität erkennen läßt, das es dort primär um
Spiegelung geht und nicht um Manipulation. Also hosteurope oder eine der Uni-Server: dort ist
die Möglichkeit der Manipulation zwar auch gegeben, aber die Wahrscheinlichkeit das es in diesem
Umfeld passiert bzw. techmisch passieren kann ist ziemlich gering. Wenn ich aber als Admin z.B.
(und das jetzt ohne konkrete Wertung, lediglich als Beispiel) einen Mirror wie piotr***.bla.blu
einstelle: Tja, dann: 6, setzen; gehen Sie nicht über Los,.....
AFAIK gibt es noch keinen Fall einer Paketmanipulation seit es Arch+Mirrors gibt.