Arch Linux

Arch im "professionellen" Umfeld?

GerBra

Wie sind eure Erfahrungen mit Arch als Server in einem "professionellen" Netzwerk?

Ich würde gerne Erfahrungen austauschen, was Für oder Gegen Arch als Distribution
z.B. in einem Firmen-Umfeld sprechen würde.
Also eher die Frage: Fließendes Update ("bleeding edge") gegen Release-Wechsel.

Bei einer Release-basierenden Distri (z.B. Debian) konnte ich mich drauf verlasssen,
daß die Funktionalität eines bestimmten Programms/Vorgangs sowohl an den Servern als
auch zu den Clients erhalten blieb. Eben bis zum Release-Wechsel (den man evtl. noch
herauszögern konnte).

Erst dann mußte ich mich um etwaige Konfig-Änderungen aufgrund neuerer Versionen etc.
kümmern - dann allerdings oft massiv.

Bei Arch z.B. könnten ja quasi "täglich" ein neues php, mysql, samba einschlagen.
Ich selbst habe keine Erfahrung mit dieser Art von Distris auf Servern.

Deshalb: wie steht ihr dazu? Setzt ihr Arch auf "richtigen" Servern ein?
(Hier nochmal eine Anmerkung zu "professionell" und "richtig": Ich meine
hier wirklich z.B. Server die man "außerhalb" aufzieht und z.B. nur per ssh
administriert. Das soll den eigenen Rechner in keinster Weise abwerten)

Wie handhabt ihr die Updates? Klar, ich muß für wichtige Pakete halt im
Arch-CVS oder im Upstream-changelog nachschauen, ob ich lokal in der Umgebung
etwas ändern muß, ob ich das Update überhaupt mache,...

Habt ihr schon mal in so einem Umfeld mit Arch (oder mit der Update-Art) "böse"
Überraschungen erlebt?

Ich setzt Arch jetzt auf zwei Desktop-Rechnern ein. Bisher habe ich diesbezüglich
nichts Negatives erlebt. Momentan bilde ich gerade in einer VM meinen privaten
Debian-Server ab um diesen unter Arch eine Zeitlang parallel laufen zu lassen und so eigene
Erfahrungen zu sammeln.

Von meiner Seite aus kann ich mir Arch schon als Grundlage für zukünftige Server
vorstellen. Vor allem die "Freiheit", die man nach der Base-Installation hat spricht
IMHO sehr dafür.
Und das man nicht gezwungen ist, etwaige Bugs in Programmen mit sich
rumzuschleppen bis zum nächsten "Release" (oder halt doch mit oder gegen das
jeweilige Paketsystem selbst kompiliert).

Würde mich über Meinungen freuen 😉

Alko++

Hallo

Ich denke es kommt auf die Anwendung an. fileserver, ftp, dhcp, cups oder sonstige "normale" Anwengungen denke ich kann man durchaus mit arch realisieren. Immer die aktuellsten features sind da schon nobel.

Ich wuerde arch jedoch nicht bei kritischen anwendungen wie Datenbanken oder aehnliches einsetzen. Da Distris wie Suse und Redhat exact die Releases auf die der Datenbanken anpassen.
Weiter probleme sind support und gewaehrleistung.

Daher wuerde ich arch im firmentechnischen Umfeld nur fuer unkritische Dienste einsetzen.

Wie bei mir auf meinem Firmenlaptop 🙂

moe

Ich benutze zwar Arch nicht auf Servern, aber Gentoo, was ja auch fliessende Updates hat.

Es hat Vor- und Nachteile, ein Vorteil ist z.B. dass ich nicht einmal im Jahr eine Menge Arbeit durch einen Releasewechsel habe, sondern dafür quasi gleich verteilten Aufwand über das ganze Jahr. Und man bekommt halt auch neue Funktionalitäten statt nur Bugfixes.
Nachteil ist natürlich dass prinzipiell bei jedem Update irgendwas nicht mehr gehen könnte, und dadurch erheblicher, ungeplanter Mehraufwand entsteht. Bei Servern die 24/7 laufen sollen wäre das nicht machbar, "meine" Server stehen Intranet von normalen mittelständischen Firmen, Updates mache ich Freitag abend oder Sonnabend, somit habe ich den Sonntag noch als Puffer für diesen ungeplanten Mehraufwand.
Ausserdem habe ich bei mir vmware-server mit mehreren nahezu identischen Servern zu laufen, dort baue ich die Updatepakete (bei Arch nicht nötig), und teste sie, so gut es im virtuellen Umfeld geht. Eine Vollbelastung eines Samba-PDCs der in der Firma 20 Clienten bedient, lässt sich schwer simulieren und testen, ebenso Sachen die ich in der VM einfach nicht habe, z.B. einen Faxserver auf 2 AVM B1. Somit sind immermal Sachen, die nicht auf Anhieb funktionieren, aber dafür hat bis jetzt immer der Sonntag gereicht, auch wenns mal sehr spät wurde..

Du hast leider nicht gesagt, was der oder die Server genau machen sollen, sprichst aber von mysql und php, was auf einen Webserver (24/7) schliessen lässt. Dort würde ich wie gesagt eine Distrie mit fliessenden Updates nur einsetzen, wenn ich die Möglichkeit und die Disziplin habe Updates vorher in einer nahezu identischen Umgebung zu testen.

Generell benutze ich Archlinux nur auf meinem Laptop (ansonsten Gentoo), da ich auf der Kiste nicht kompilieren möchte. Auf den Servern (sowohl meine eigenen als auch Server von Kunden) werd ich bei Gentoo bleiben, da das Kompilieren hier in meinem Testsystem erledigt wird, und ich Gentoo dafür komfortabler finde, z.B. dispatch-conf, was neue Versionen von Config-Dateien gegen die installierten vergleicht, und interaktiv updatet, elogv was die Hinweistexte die bei Installationen ausgegeben werden zum späteren Lesen speichert, usw. Durch die USE-Flags hab ich mehr Kontrolle über das System und kann z.B. kann ich da hylafax installieren ohne X mitinstallieren zu müssen. Auch fehlen mir einige Pakete in Arch die ich auf dem Server brauche.
Aber generell ist Arch meiner Meinung nach auch als Server einsetzbar, obs zufriedenstellend läuft, liegt denke ich zu 95% am Admin. Updates vorher auf einer anderen Maschine zu testen ist Pflicht und sollte im Übrigen auch bei release-basierten Distries gemacht werden.

GerBra

@Alko++++ und moe

Danke euch beiden schon mal.

Alko++:
Wirklich "kritische" Installationen, bei denen Management evtl. noch SLA's etc. haben
will, sei mal außeracht gelassen.

moe:
Ich meine schon Installationen, in denen z.B. ich als Admin die Verantwortung für
fast die ganze Infrastruktur habe (also i.d.R. "Mittelstand", die wollen einen
Server abseits der W*ndows-Lizenz-Restriktionen: File, SQL, Web + evtl.
vmware-server)

Ich habe z.B. letztens eine gemeinnütziges Internet-Cafe/Schulung-Umgebung mit
Terminal-Server+Thin-Clients gehabt, dafür habe ich (mit Knurren) Edubuntu
genommen(LTSP).
Das wäre etwas (weil es z.zt. auch sehr gefragt ist), was ich mir von meiner Sicht als
Admin auch unter Arch vorstellen kann - ich will halt nur nicht in einem halben
Jahr merken müssen, daß ich in der Zeit 20x "flicken" muß aufgrund von Updates.

Webserver wäre auch interessant - wenn jemand unter Arch einen solchen betreibt.
Also die Erfahrungen damit über einen längeren Zeitraum.

Ansonsten ist klar: man kann und sollte System in einer VM testen - aber man kann
die Realität halt nicht wirklich abbilden.

moe

Terminalserver/Client Umgebungen interessieren mich auch, leider konnte ich bis jetzt keinen Kunden dazu überreden. 🙁

GerBra

Ist halt nur in einer homogenen Umgebung mit Linux-Clients möglich.
Im angesprochenen Fall (gemeinnützig!) hatten die bisher halt 166MHz Rechner
mit 64-128MB, auf denen Suse 9.x lief. Durch Spenden kamen jetzt 10 PC's
mit 600MHz und 512 MB hinzu.

Wir haben jetzt einen dieser neuen Rechner auf 1GB "aufgerüstet" und dieser bedient
jetzt momentan 9 Arbeitsplätze auf denen KDE i.d.R. mit Firefox und OpenOffice
läuft. Und trotz des "mangelhaften" Terminal-Servers geht laut Aussagen der
Nutzer "die Post ab" - im Gegensatz zur alten Umgebung!
Und sie müssen sich zukünftig halt vornehmlich "nur" um die Server-Aufrüstung
kümmern und können alte Clients weiterbenutzen.

Aber da wine in meinen Augen große Fortschritte gemacht hat, ist das Konzept
IMHO auch auf kleine bis mittlere Firmen-Umgebungen anwendbar, die oftmals
"nur" wegen 1,2 Anwendungen an Windows "kleben" und dort über die XP->Vista
Schiene Rechenboliden unterm Schreibtisch stehen haben (müssen) um z.B.
kaufmännische Anwendungen zu bedienen.

Und da halt neben dem Ubuntu/Edubuntu als Basis eine "kleinere", "feinere" Distri
zu haben wäre schon toll...

moe

Naja nicht ganz, in heterogenen Umgebungen ist das auch möglich, und wird auch oft eingesetzt. Z.B. kann ein Linuxserver per (Free)NX auch Windowsclienten versorgen, oder Linuxclienten bedienen sich per rdesktop am Windowsserver. Letzteres hab ich eine Zeitlang auch privat mit einem alten 233MHz Laptop und nem unterdurchschnittlichen Desktop als Server eingesetzt, aber irgendwann durch FreeBSD und Freenx ersetzt, weil man mit Windows irgendwie nicht arbeiten kann 😉
LTSP hab ich ebenfalls getestet, aber zum einen hat man da irgendwie "gespürt", dass man remote arbeitet, bei FreeNX wars schon sehr viel weniger und be rdesktop merkt man es nur bei Video-ähnlichen sachen (Flash z.B.), die Verbindung war aber auch nur eine 54MBit Wlan-Verbindung. Zum anderen find ich die Möglichkeit die Sitzung offen zu halten während der Client selbst aus ist genial. Aber das ist auch wieder eine Frage des Bedürfnisses, und in einem INet-Cafe wird sicher kein Wert auf Resume der Sitzungen gelegt, und die Clienten sind sicher auch nicht per WLan angebunden..

Aber ich glaub ich komme gerade vom eigentlichen Thema ab :-*)

Pierre

Ich betreibe ja nun schon seit Längerem archlinux.de auf einem Arch-System. Vorher hatte ich eine ganze Zeit Debian.

Ob Arch im Servereinsatz sinnvoll ist, hängt ganz stark von den Anforderungen und dem Admin ab.

Da Arch ständig aktualisiert wird, ist der Aufwand gut verteilt und lässt sich überblicken. Damit spart man sich die Arbeit, wenn bei einem neuen Release alle Pakete aktualisiert werden. Hier hat man dann potentiell mit mehr als einem Paket Probleme. Im Gegenzug muß man bei Arch auch am Ball bleiben und kann Updates nicht zu lange hinauszögern.

Wenn Du also durch äußere Einflüsse (z.B. bei Hosting fremder Webseiten) auf bestimmte Versionen festgelegt bist und auch sonst weißt, was Du tust, sollte man mit Arch als Webserver gut klar kommen. Man muss so z.B. selbst den Webserver neu starten wenn PHP aktualisiert wurde, die php.ini anpassen und prüfen, ob die alten Webanwendungen damit noch laufen.

[gelöscht]

Seit einem guten Monat befasse ich mich mit Arch Linux und finde schon, dass es gute Einsatzzwecke im Unternehmen gibt. An sich würde mich vor allem der Einsatz als Terminal Server reizen, allerdings scheitet dies bisher an einem nicht funktionierenden freenx-Paket. Obendrein müsste ich noch die LDAP-Authentifikation an unserem SLES10 (TLS) hinbekommen.
Für Workstations würde ich es auch einsetzen, sofern LDAP OK ist.

Die ständigen Updates sehe ich eher positiv. Unser Suse Terminal Server hat leider gezeigt, dass viele Pakete oft unreif sind. Wirklich stabil und gut funktioniert KDE bei uns erst mit 3.5.7 (vor allem der PIM).

GerBra

Pierre, jcci: Danke für eure Statements.

Ich werde wohl (neben der Migration meines eigenen Servers) als nächstes einfach
mal Arch bei der nächst sich bietenden Gelegenheit aufsetzen.

Zu den von mir und euch angesprochenen Dingen als TerminalServer:
Ich werde mich die nächsten Wochen mal ernsthaft darum kümmern,
LTSP (mein Hauptanliegen), FreeNX, XDMCP so in Arch einzubinden, daß Arch
mit "wenigen Handgriffen" als TS einsetzbar ist.

Mit LDAP-Anbindung habe ich persönlich nichts ernsthaftes am Hut, es wäre
aber eine gute Gelegenheit im Zuge von o.a. da mal "reinzuschnuppern". Bei
etwaigen Problemen weiß ich ja, wohin ich mich wende 😉