Headless CentOS Upgrade
Alexander Griesser
Hat jemand von euch schon mal remote von CentOS 4.6 auf CentOS 5.2
hochgezogen?
Ich fahr so ungern unnötige Kilometer nur um eine CD einzulegen...
Ich hab diesbezüglich schon ein paar Sachen gefunden, z.B. ein Kommentar
in diesem Artikel welcher Beschreibt, dass man einfach folgende Packages
aus dem neuen Repo ziehen soll und drüberklopfen:
http://www.cyberciti.biz/tips/upgrading-centos-51-to-52.html
Oder reichts wenn man einfach /etc/yum.repos.d/*.repo entsprechend
anpasst?
ciao,
Alex
Bernd Petrovitsch
[....]
> Hat jemand von euch schon mal remote von CentOS 4.6 auf CentOS 5.2
> hochgezogen?
Ja.
> Ich fahr so ungern unnötige Kilometer nur um eine CD einzulegen...
Ich habs remote gemacht, damit es "nebenbei" geht (wobei ich nicht
unterschreiben würde, daß es deswegen schneller gegangen ist - aber
jedenfalls bequemer, weil von zu Hause. Naja, nachher ist man immer
schlauer;-).
> Ich hab diesbezüglich schon ein paar Sachen gefunden, z.B. ein Kommentar
> in diesem Artikel welcher Beschreibt, dass man einfach folgende Packages
> aus dem neuen Repo ziehen soll und drüberklopfen:
>
> http://www.cyberciti.biz/tips/upgrading-centos-51-to-52.html
Allerdings ist 5.1 doch 5.2 *massiv* ähnlicher als 4.*. Und ein upgrade von
5.1 auf 5.2 ist Designziel (was es bei 4 nicht ist).
Also vergiß mal obigen Link.
> Oder reichts wenn man einfach /etc/yum.repos.d/*.repo entsprechend
> anpasst?
Good joke, ROTFL ....
Im wesentlichen:
- `rpm -e *-devel*`
- `rpm -e $KDE $GNOME $XFCE $X11
Oder so ähnlich.
- *.repo's anpassen
- Output von `yum upgrade` anschauen, welche Dependencies nicht aufgelöst
werden können und entsprechend weitere RPMs entsorgen. Ja, da waren auf
der MTA u.ä. dabei.
Update für einzelne "periphere" RPMs ("teile und herrsche";-) geht kaum,
weil
- die glibc neu ist und deshalb fast alle Pakete die glibc updaten wollen
- `rpm -i glibc' hab ich nicht gemacht (und schon wieder
vergessen/verdrängt, warum)
python ist auch neu. yum ist (leider) in python implementiert ist. Da sind
die Dependencies dermaßen anders (oder es fehlen nur Obsoletes o.ä.), daß
ich hab dann irgendwann auch `rpm -e yum* (nachdem ich einen Haufen
abhängige RPMs damit gesaugt hab).
BTW: CentOS-5/RHEL5 hat keine i586 Kernels mehr.
Bernd
--
Bernd Petrovitsch Email : be...@bofh.at
"For I was talking aloud to myself. A habit of the old: they choose
the wisest person present to speak to; the long explanations needed
by the young are wearying." --- Gandalf, the White
Alexander Griesser
>> Ich hab diesbezüglich schon ein paar Sachen gefunden, z.B. ein Kommentar
>> in diesem Artikel welcher Beschreibt, dass man einfach folgende Packages
>> aus dem neuen Repo ziehen soll und drüberklopfen:
>>
>> http://www.cyberciti.biz/tips/upgrading-centos-51-to-52.html
>
> Allerdings ist 5.1 doch 5.2 *massiv* ähnlicher als 4.*. Und ein upgrade von
> 5.1 auf 5.2 ist Designziel (was es bei 4 nicht ist).
> Also vergiß mal obigen Link.
Das ist mir schon klar, deswegen schrieb ich auch "ein Kommentar in
diesem Artikel", weil unten bei den Kommentaren jemand von 4.x auf 5.x
upgegradet hat, das aber bei mir nicht wie beschrieben funktioniert hat.
>> Oder reichts wenn man einfach /etc/yum.repos.d/*.repo entsprechend
>> anpasst?
>
> Good joke, ROTFL ....
Mit ein Grund, warum ich CentOS nicht mag.
> Im wesentlichen:
> - `rpm -e *-devel*`
> - `rpm -e $KDE $GNOME $XFCE $X11
> Oder so ähnlich.
> - *.repo's anpassen
> - Output von `yum upgrade` anschauen, welche Dependencies nicht aufgelöst
> werden können und entsprechend weitere RPMs entsorgen. Ja, da waren auf
> der MTA u.ä. dabei.
Naja, wenn des wirklich nicht anders geht, dann werd ich da wohl mit der
CD hinfahren. Ist zwar weniger 1337, aber zumindest hab ich da dann
nicht immer diese Bauchschmerzen beim Arbeiten.
Danke auf alle Fälle für die Antwort, ich hatte gehofft es gibt einen
etwas praktikableren Weg :)
Weiß jemand, ob es von 5 auf 6 dann wenigstens einen Upgradepath geben
wird? Ich mein, Debian bringt das ja auch hin...
ciao,
Alex
Bernd Petrovitsch
> Bernd Petrovitsch wrote:
[....]
>>> Oder reichts wenn man einfach /etc/yum.repos.d/*.repo entsprechend
>>> anpasst?
>>
>> Good joke, ROTFL ....
>
> Mit ein Grund, warum ich CentOS nicht mag.
Schau Dir mal die Release-Zyklen und und Supportlaufzeiten an.
Ja, Debilian kann das vielleicht besser.
Allerdings kommt CentOS^WRHEL aus dem kommerziellen Umfeld. Und da updatet
niemand einen Server von $MAJOR_RELEASE auf $MAJOR_RELEASE+1, weil
- never touch a running system
- sonst andere Applikationen (eigene und 3rd Party) ebenfalls - zumindest
rudimentär - ausgetestet werden wollen/müssen.
Von Supportverträgen und zertifizierten Installationen ganz zu schweigen.
Nur so Wahnsinnige wie ich (und Du?:-) machen das - bei mir waren das der
Wohnungsserver, ein Webserver irgendwo und ein
"Studenten-Programmier-Server".
Nix mit "3rd Party" oder "Support" ......
>> Im wesentlichen:
>> - `rpm -e *-devel*`
>> - `rpm -e $KDE $GNOME $XFCE $X11
>> Oder so ähnlich.
>> - *.repo's anpassen
>> - Output von `yum upgrade` anschauen, welche Dependencies nicht aufgelöst
>> werden können und entsprechend weitere RPMs entsorgen. Ja, da waren auf
>> der MTA u.ä. dabei.
>
> Naja, wenn des wirklich nicht anders geht, dann werd ich da wohl mit der
> CD hinfahren. Ist zwar weniger 1337, aber zumindest hab ich da dann
> nicht immer diese Bauchschmerzen beim Arbeiten.
> Danke auf alle Fälle für die Antwort, ich hatte gehofft es gibt einen
> etwas praktikableren Weg :)
Das Problem bei Upgrades aufs nächste Major Release ist ja nicht wirklich
der Kernel oder die glibc, sondern der ganze andere Haufen an Tools und
Applikationen. Die, die mir ad hoc so einfallen sind:
- neue(re)s PHP drauf: Schönen Gruß an existierende PHP-Apps, da muß man
nacharbeiten. Und mitunter hat man nicht einmal wirklichen Source davon
(sondern obfuskierte Varianten oder es wird eAccelerator o.ä. verwendet).
- neue(re)s PostgreSQL drauf: Da muß man auch *vor* dem Update die alten DBs
dumpen und nachher importieren.
CentOS4 hat PgSQL-7.[23] IIRC und CentOS5 hat 8.*.
- CentOS4->5: Python-RPMS sind anders. Ob das ein Python oder ein
RPM-Problem ist, hab ich nie nachgeschaut.
- CentOS4->5: db4 ist (auch) anders IIRC. Da hab ich auch rumspielen
müssen IIRC.
Liste erhebt keinen Anspruch auf Vollständigkeit.
Obiges *kann* einen treffen oder auch auch nicht. Aber es ist trotzdem
lästig.
> Weiß jemand, ob es von 5 auf 6 dann wenigstens einen Upgradepath geben
Gibt es: "Neu installieren und migrieren";-) SCNR ....
Aber nachdem es von 3 auf 4 schon keinen gegeben hat, wage ich das mal zu
bezweifeln.
Rein technisch würde man das Ganze ja strategisch anders lösen: $TOOL wird
per Paket in /opt/$TOOL-$VERSION/ installiert und verwendet. Welche glibc,
Kernel oder bash drunter rennt ist relativ egal.
Selbiges für Libs. Da muß man halt u.U. die Pakete selber bauen, damit sie
gegen die korrekte Lib (unter /opt) linken.
> wird? Ich mein, Debian bringt das ja auch hin...
Wer ist der "Debian"?
Der Debian-Weg, wo hunderte/tausende Paketmaintainer ohne Ende Arbeit und
Know-How investieren, um das hinzukriegen, macht für (IMHO bestenfalls) 1%
der Kunden im Fall von RH (oder SuSE) wenig kommerziellen Sinn. Relevant
ist "Update" bei rein internen Servern (wie Fileserver, DB-Server, ....) eh
nicht. Wenn man Performance-Probleme hat, ist es einfacher und billiger,
neue große Hardware zu kaufen und die Installation als Ganzes zu
übersiedeln als ein SW-Update mit neuem Austesten der Applikation.
Zumindest ist das die einzige rationale Erklärung, die mir dazu einfällt.
Alexander Griesser
> Schau Dir mal die Release-Zyklen und und Supportlaufzeiten an.
Nicht sonderlich sehenswert.
> Allerdings kommt CentOS^WRHEL aus dem kommerziellen Umfeld. Und da updatet
> niemand einen Server von $MAJOR_RELEASE auf $MAJOR_RELEASE+1, weil
> - never touch a running system
> - sonst andere Applikationen (eigene und 3rd Party) ebenfalls - zumindest
> rudimentär - ausgetestet werden wollen/müssen.
Mir gehts jetzt ja nicht darum, der Updateritis zu fröhnen, sondern weil
ich mit diesem einen CentOS 4.6 System massive Probleme habe.
Zum Einen ist da der Samba Server der Probleme macht die angeblich in
3.0.26 behoben sein sollten, die letzte Version auf CentOS 4.6 ist
3.0.25 und dann hab ich noch Probleme mit der 3rd party Scalix
Installation auf dieser Maschine. Die Aussage des Scalix Supports war
dann, ich solle mal auf CentOS 5.2 upgraden und dann nochmal probieren.
Sind also schon zwei gute Gründe, warum ich upgraden will und nicht mit
angestaubter Software arbeiten will. Den Fall, dass jemand ein
Produktivsystem auf eine neuere Major-Release upgraden will gibts
täglich und das aus den verschiedensten Gründen. Die Tatsache, dass
jemand upgraden will/muss ist also nicht das Thema sondern nur, dass
es nicht so einfach geht wie es sein könnte.
Im Prinzip gibts bei der CentOS Upgrade Installation irgendeinen Config-
Migrator der mir hoffentlich dann alle Konfigurationen meiner Services
für die 5.2er Version übernimmt (alles mit Paketen installiert, nichts
selbst kompiliert und keine Ugly Patches/Hacks, etc., alles straight-
forward). Wieso also nicht - so wie du eh schon geschrieben hast - einen
Major-Updater nach /opt statisch gelinkt kopieren und dort das Upgrade
machen, dann diesen Migrator drüberlaufen lassen und fertig?
Nein, CD schubsen und viel Downtime wirkt einfach wesentlich
professioneller. Mir solls recht sein, ich kann die Stunden dort vor Ort
dann eh verrechnen, nur nage ich halt weniger am Hungertuch als an einem
massiven Zeitproblem, also wenn ichs mir aussuchen könnte, dann würde
ich lieber eine oder zwei Stunden verrechnen und das ganze Remote machen
als zig Stunden verrechnen und dort dafür vor Ort angekettet zu sein.
> Von Supportverträgen und zertifizierten Installationen ganz zu schweigen.
Das ist mir schon klar, aber ich habe da mit niemandem einen
Supportvertrag und es ist auch keine zertifizierte Installation.
Supportverträge und zertifizierte Installationen hat man in dem
Zusammenhang auch ja meist nur mit dem Hersteller der spezifischen 3rd
party Software die da drauf läuft und dann interessiert mich der Server
sowieso recht wenig, denn ein System, auf dem ich nicht root bin,
interessiert mich nicht, dafür übernehm ich dann schon mal überhaupt
keine Verantwortung.
ciao,
Alex
Bernd Petrovitsch
> Bernd Petrovitsch wrote:
>> Alexander Griesser wrote:
>>> Bernd Petrovitsch wrote:
>> [....]
>>>>> Oder reichts wenn man einfach /etc/yum.repos.d/*.repo entsprechend
>>>>> anpasst?
>>>
>>
>> Schau Dir mal die Release-Zyklen und und Supportlaufzeiten an.
>> Ja, Debilian kann das vielleicht besser.
>> Allerdings kommt CentOS^WRHEL aus dem kommerziellen Umfeld. Und da
>> updatet niemand einen Server von $MAJOR_RELEASE auf $MAJOR_RELEASE+1,
>> weil - never touch a running system
>
Ja, ganz bestimmt zu 100% für alle obskure und nicht-so-obskure Pakete.
SCNR .....
>> - sonst andere Applikationen (eigene und 3rd Party) ebenfalls - zumindest
>> rudimentär - ausgetestet werden wollen/müssen.
>> Von Supportverträgen und zertifizierten Installationen ganz zu
>> schweigen.
>
> Heisst das, ein Supportvertrag verhindert Updates? Das ist dann aber ein
Nicht zwingend. Aber wenn Du z.b. Oracle+Oracle-Support haben willst/mußt,
dann wird die Auswahl der zertifizierten Distributionen schon relativ eng.
Weitere Details muß man dann bei den jeweiligen Suppoprtern
nachlesen/fragen.
Aber ich bezweifle ernsthaft, daß ein seriöser Supporter 99,999% Uptime
garantiert und Dir die Freiheit läßt, "einfach so" auf nächste Major
Release upzugraden.
> schlechter Supportvertrag.
Gibt es andere?
>> Nur so Wahnsinnige wie ich (und Du?:-) machen das - bei mir waren das der
>> Wohnungsserver, ein Webserver irgendwo und ein
>> "Studenten-Programmier-Server".
>> Nix mit "3rd Party" oder "Support" ......
>
> Den benötigt man auch nicht, wenn nicht ein kommerzieller Hersteller im
> stillen Kämmerlein etwas gebastelt hat. SuSEs Yast vermurkste mir früher
Es gibt nicht alles als GPLv*. Und manche Firmen kaufen selbst für
GPL-Software externen Support ein. Und manchmal gibt es Branchenlösungen,
die halt unbedingt (z.B.) Oracle wollen. Außer "Branche wechseln" kann man
dagegen wenig tun.
> regelmässig bei neuen Versionen meine Konfig. Seit ich Debian nehme fühlt
> sich mein Rechner viel stabiler an.
>
>> Das Problem bei Upgrades aufs nächste Major Release ist ja nicht wirklich
>> der Kernel oder die glibc, sondern der ganze andere Haufen an Tools und
>> Applikationen. Die, die mir ad hoc so einfallen sind:
>> - neue(re)s PHP drauf: Schönen Gruß an existierende PHP-Apps, da muß man
>> nacharbeiten. Und mitunter hat man nicht einmal wirklichen Source davon
>> (sondern obfuskierte Varianten oder es wird eAccelerator o.ä.
>> verwendet).
>> - neue(re)s PostgreSQL drauf: Da muß man auch *vor* dem Update die alten
>> DBs
>> dumpen und nachher importieren.
>> CentOS4 hat PgSQL-7.[23] IIRC und CentOS5 hat 8.*.
>> - CentOS4->5: Python-RPMS sind anders. Ob das ein Python oder ein
>> RPM-Problem ist, hab ich nie nachgeschaut.
>> - CentOS4->5: db4 ist (auch) anders IIRC. Da hab ich auch rumspielen
>> müssen IIRC.
>> Liste erhebt keinen Anspruch auf Vollständigkeit.
>
> Solche Probleme bereitet CentOS?
Nein, die oben genannten Applikationen bereiten die Probleme, wenn man
entsprechend "weit" updatet (unabhängig von der Distribution). *Ob* die
Distributionshersteller um die Probleme herumarbeiten, ist eine andere
Frage.
Keine Ahnung, ob Debian den PgSQL-Upgrade von 7.* auf 8.* ohne
Admin-Intervention hinbringt (und ohne die DBs zu verlieren).
Und wenn $DB_APPLIKATION ein syntaktisches Konstrukt bei den Queries
verwendet, daß die nöchste Version nicht kann (for whatever reason), dann
muß man das auch fixen. Ob das die Schuld der Distribution, der Datenbank
oder $DB_APPLIKATION ist, kann man im Einzelfall sich anschauen und
klären - aber das hilft im nachhinein wenig ....
>>> wird? Ich mein, Debian bringt das ja auch hin...
>>
>> Wer ist der "Debian"?
>> Der Debian-Weg, wo hunderte/tausende Paketmaintainer ohne Ende Arbeit und
>> Know-How investieren, um das hinzukriegen, macht für (IMHO bestenfalls)
>> 1% der Kunden im Fall von RH (oder SuSE) wenig kommerziellen Sinn.
>
> Klar. Die wollen schliesslich am Support verdienen und ausserdem bunte
> Packungen mit DVDs distributen.
Ja, und?
Ist halt RedHats und SuSEs Motivation mit Vor- und Nachteilen.
>> Relevant
>> ist "Update" bei rein internen Servern (wie Fileserver, DB-Server, ....)
>> eh nicht. Wenn man Performance-Probleme hat, ist es einfacher und
>> billiger, neue große Hardware zu kaufen und die Installation als Ganzes
>> zu übersiedeln als ein SW-Update mit neuem Austesten der Applikation.
>
> Eine Neuinstallation kostet Zeit und verursacht Ärger. Bei Debian war ein
Ja. Aber dafür kann man idR die Migration in kleinere Stücke zerlegen und
damit das Risiko senken, daß was nicht geht (und es gehen nicht alle 5
wichtigen Apps zugleich nicht).
Selbst wenn man vorher die Migration einmal (oder mehrmals) auf einen
Scratch-Rechner vorübt, sich Scripte und Doku mitschreibt, etc. bleibt
immer ein Restrisiko.
> Upgrade von 3.1 auf 4.0 problemlos trotz PHP und Co.
Es hängt auch von den eingesetzten PHP-Applikationen ab - nicht nur von PHP
als solchem.
Und ich fürchte, daß die Masse der Webshops da sehr viel mühsamer sind als
leidlich einfache OSS-PHP-Apps.
Dazu kommt, daß es einen (kommerziell) gewaltigen Unterschied macht, ob
meine interne Stundenverwaltung für 2 Wochen oder mein Webshop für 2
Stunden steht.
Bernd Petrovitsch
> Bernd Petrovitsch wrote:
>> Allerdings kommt CentOS^WRHEL aus dem kommerziellen Umfeld. Und da
>> updatet niemand einen Server von $MAJOR_RELEASE auf $MAJOR_RELEASE+1,
>> weil - never touch a running system
>> - sonst andere Applikationen (eigene und 3rd Party) ebenfalls - zumindest
>> rudimentär - ausgetestet werden wollen/müssen.
>
> Mir gehts jetzt ja nicht darum, der Updateritis zu fröhnen, sondern weil
> ich mit diesem einen CentOS 4.6 System massive Probleme habe.
>
> Zum Einen ist da der Samba Server der Probleme macht die angeblich in
> 3.0.26 behoben sein sollten, die letzte Version auf CentOS 4.6 ist
> 3.0.25 und dann hab ich noch Probleme mit der 3rd party Scalix
Hmm, da würde ich eher `rpmbuild --rebuild .src.rpm` machen.
> Installation auf dieser Maschine. Die Aussage des Scalix Supports war
> dann, ich solle mal auf CentOS 5.2 upgraden und dann nochmal probieren.
Na super. Scalix ist ja auch "nur" ein Sammelsurium von Apps. Die werden ja
Details über die Versionen der Apps, mit denene sie können rauslassen?
> Sind also schon zwei gute Gründe, warum ich upgraden will und nicht mit
> angestaubter Software arbeiten will. Den Fall, dass jemand ein
Das war mein Hintergrund. gcc < 4 und noch ein paar Sachen waren schon eher
mühsam.
> Produktivsystem auf eine neuere Major-Release upgraden will gibts
> täglich und das aus den verschiedensten Gründen. Die Tatsache, dass
Das glaub ich nicht, Tim;-) Zumindest nicht im "muß durchlaufen" Umfeld.
> jemand upgraden will/muss ist also nicht das Thema sondern nur, dass
> es nicht so einfach geht wie es sein könnte.
Es ist ja auch ein ekliges Problem, weil man -zig Apps hat, wo man wissen
muß, was nicht mehr geht und das automagisch und transparent reparieren.
> Im Prinzip gibts bei der CentOS Upgrade Installation irgendeinen Config-
> Migrator der mir hoffentlich dann alle Konfigurationen meiner Services
> für die 5.2er Version übernimmt (alles mit Paketen installiert, nichts
Gibt es den?
Ich hab nicht den Eindruck gehabt, daß es sowas gibt.
> selbst kompiliert und keine Ugly Patches/Hacks, etc., alles straight-
> forward). Wieso also nicht - so wie du eh schon geschrieben hast - einen
> Major-Updater nach /opt statisch gelinkt kopieren und dort das Upgrade
> machen, dann diesen Migrator drüberlaufen lassen und fertig?
Ich fürchte, daß rechnet sich kommerziell für RH/SuSE nicht und deshalb
macht es halt niemand.
Send patches;-)
>> Von Supportverträgen und zertifizierten Installationen ganz zu
>> schweigen.
>
> Das ist mir schon klar, aber ich habe da mit niemandem einen
> Supportvertrag und es ist auch keine zertifizierte Installation.
> Supportverträge und zertifizierte Installationen hat man in dem
> Zusammenhang auch ja meist nur mit dem Hersteller der spezifischen 3rd
> party Software die da drauf läuft und dann interessiert mich der Server
> sowieso recht wenig, denn ein System, auf dem ich nicht root bin,
> interessiert mich nicht, dafür übernehm ich dann schon mal überhaupt
> keine Verantwortung.
Yup. Und umgekehrt wird es ähnlich sein.
Alexander Griesser
>> Zum Einen ist da der Samba Server der Probleme macht die angeblich in
>> 3.0.26 behoben sein sollten, die letzte Version auf CentOS 4.6 ist
>> 3.0.25 und dann hab ich noch Probleme mit der 3rd party Scalix
>
> Hmm, da würde ich eher `rpmbuild --rebuild .src.rpm` machen.
Ist natürlich eine Möglichkeit, ja, aber wie gesagt, da CentOS 4.6
ohnehin schon sehr angestaubt ist, wird früher oder später ohnehin
ein Upgrade fällig.
Scalix weigert sich zwar, Debian zu supporten, allerdings gibts da
ziemlich einiges an Ressourcen wie man Scalix unter Debian installiert
und auf den "Updaten Sie CentOS auf die aktuellste Version" Support
kann ich sowieso verzichten - zumal ich dort ohnehin nur die freie
Community Edition laufen habe. Muss mir also überlegen die CentOS
Problematik vielleicht grundlegend an der Wurzel zu behandeln.
>> Installation auf dieser Maschine. Die Aussage des Scalix Supports war
>> dann, ich solle mal auf CentOS 5.2 upgraden und dann nochmal probieren.
>
> Na super. Scalix ist ja auch "nur" ein Sammelsurium von Apps. Die werden ja
> Details über die Versionen der Apps, mit denene sie können rauslassen?
Wenn die das könnten, dann würden sie sich auch nicht auf spezielle
Distributionen versteifen. Einen sendmail in Version x.y.z kann ich
unter Debian genauso installieren.
>> Produktivsystem auf eine neuere Major-Release upgraden will gibts
>> täglich und das aus den verschiedensten Gründen. Die Tatsache, dass
>
> Das glaub ich nicht, Tim;-) Zumindest nicht im "muß durchlaufen" Umfeld.
"Muß durchlaufen" ist hier auch nicht mein Hauptkriterium, ganz im
Gegenteil, das könnte bei dieser speziellen Maschine am Abend oder
am Wochenende geschehen, nur von zu Hause aus isses bequemere aus zuvor
bereits erwähnten Gründen.
> Es ist ja auch ein ekliges Problem, weil man -zig Apps hat, wo man wissen
> muß, was nicht mehr geht und das automagisch und transparent reparieren.
Ja, klar, je mehr da läuft umso mehr muss man dabei aufpassen.
>> Im Prinzip gibts bei der CentOS Upgrade Installation irgendeinen Config-
>> Migrator der mir hoffentlich dann alle Konfigurationen meiner Services
>> für die 5.2er Version übernimmt (alles mit Paketen installiert, nichts
>
> Gibt es den?
Keine Ahnung. Ich geh mal stark davon aus, dass wenn ich eine
Upgradeinstallation mache, mein System danach noch genauso funktioniert
und nicht einfach alle Konfigurationsdateien überschrieben werden.
Aber das werde ich dann wohl eventuell live miterleben dürfen.
> Ich fürchte, daß rechnet sich kommerziell für RH/SuSE nicht und deshalb
> macht es halt niemand.
Vermutlich nicht, nein.
> Send patches;-)
Send money first.
ciao,
Alex
Bernd Petrovitsch
> Bernd Petrovitsch wrote:
>>> Zum Einen ist da der Samba Server der Probleme macht die angeblich in
>>> 3.0.26 behoben sein sollten, die letzte Version auf CentOS 4.6 ist
>>> 3.0.25 und dann hab ich noch Probleme mit der 3rd party Scalix
>>
>> Hmm, da würde ich eher `rpmbuild --rebuild .src.rpm` machen.
>
> Ist natürlich eine Möglichkeit, ja, aber wie gesagt, da CentOS 4.6
> ohnehin schon sehr angestaubt ist, wird früher oder später ohnehin
> ein Upgrade fällig.
Also offiziell wird RHEL4 noch einige Jahre supportet.
> Scalix weigert sich zwar, Debian zu supporten, allerdings gibts da
Naja, 2 Distributionen (mit je einer 1 Version) zu supporten ist - Auge mal
Pi - der doppelte Aufwand von einer. Zumal es bei "Workgroup-Servern" mit
automagischen Regressiontestsuites ziemlich mager ausschauen wird.
Ein anderer Ansatz wäre: Man supportet für alle Apps bestimmte Versionen.
Und für die produziert man eigene RPMS/.deb (die unter /opt/ installieret
werden).
Aber dann hat vermutlich wieder irgendwer ein Problem damit.
> ziemlich einiges an Ressourcen wie man Scalix unter Debian installiert
> und auf den "Updaten Sie CentOS auf die aktuellste Version" Support
Haben die überhaupt RHEL4 supportet?
[...]
>>> Installation auf dieser Maschine. Die Aussage des Scalix Supports war
>>> dann, ich solle mal auf CentOS 5.2 upgraden und dann nochmal probieren.
>>
>> Na super. Scalix ist ja auch "nur" ein Sammelsurium von Apps. Die werden
>> ja Details über die Versionen der Apps, mit denene sie können rauslassen?
>
> Wenn die das könnten, dann würden sie sich auch nicht auf spezielle
> Distributionen versteifen. Einen sendmail in Version x.y.z kann ich
Ist mbMn eine Frage der Qualität des Supports. Für at.linux Regulars mit
viel Erfahrung und entsprechendem Preis macht es vermutlich keine großen
Unterschied, aber was ist, wenn man die nicht bekommt (oder sich nicht
leisten will)?
> unter Debian genauso installieren.
[...]
>>> Im Prinzip gibts bei der CentOS Upgrade Installation irgendeinen Config-
>>> Migrator der mir hoffentlich dann alle Konfigurationen meiner Services
>>> für die 5.2er Version übernimmt (alles mit Paketen installiert, nichts
>>
>> Gibt es den?
>
> Keine Ahnung. Ich geh mal stark davon aus, dass wenn ich eine
> Upgradeinstallation mache, mein System danach noch genauso funktioniert
> und nicht einfach alle Konfigurationsdateien überschrieben werden.
Überschrieben wird gar nichts. Entweder wird das neue als $N.rpmnew
installiert oder das alte als $N.rpmsave hinterlassen (oder es ist eh
nichts verändert - dann wird es überschrieben).
> Aber das werde ich dann wohl eventuell live miterleben dürfen.
`find / -name '*.rpm???*'`
macht man dann.
GsD macht RH nicht diese kranken interaktiven Abfragen, daß man stundenlang
beim Upgrade (oder Installation) sitzen und zuschauen muß, nur um
vielleicht alle paar Minuten mal ein paar Tasten zu drücken.
>> Ich fürchte, daß rechnet sich kommerziell für RH/SuSE nicht und deshalb
>> macht es halt niemand.
>
> Vermutlich nicht, nein.
>
>> Send patches;-)
>
> Send money first.
-EFEATURE_NOT_NEEDED_HEREOVER
Du sollst ja auch nicht Patches für RHEL, sondern CentOS produzieren;-)
Alexander Griesser
>> Ist natürlich eine Möglichkeit, ja, aber wie gesagt, da CentOS 4.6
>> ohnehin schon sehr angestaubt ist, wird früher oder später ohnehin
>> ein Upgrade fällig.
>
> Also offiziell wird RHEL4 noch einige Jahre supportet.
Es kommt auch alle Ritt ein neuer 2.2er Kernel raus, den muss ich aber
trotzdem für meine Sachen nicht verwenden.
> Ein anderer Ansatz wäre: Man supportet für alle Apps bestimmte Versionen.
> Und für die produziert man eigene RPMS/.deb (die unter /opt/ installieret
> werden).
Oder man machts gleich in Java und liefert die JRE mit, juhu, das wärs,
ich werd das mal vorschlagen.
> Aber dann hat vermutlich wieder irgendwer ein Problem damit.
Man kanns sowieso nie allen recht machen.
Im Prinzip wollt ich ja eigentlich nur meine Möglichkeiten ausloten,
damit ich mir dann überlegen kann, welche der Optionen mir eher
zuspricht.
Im Moment bin ich stark am hadern mit mir ob ich jetzt dann doch Option
A oder Option A nehmen soll. Witzigerweise unterscheiden sich diese
beiden Optionen fast nicht voneinander, ja, die sind beinahe identisch,
ausser dass die zweite Option A durch das erneute Lesen noch
unsympathischer wirkt.
> Haben die überhaupt RHEL4 supportet?
Laut Website:
Supported Operating Systems
Red Hat Enterprise Linux 4
Red Hat Enterprise Linux 5
CentOS 4/CentOS 5
SuSE Linux Enterprise 9
SuSE Linux Enterprise 10
Fedora 9*/OpenSuSE 10.2*
> Ist mbMn eine Frage der Qualität des Supports. Für at.linux Regulars mit
> viel Erfahrung und entsprechendem Preis macht es vermutlich keine großen
> Unterschied, aber was ist, wenn man die nicht bekommt (oder sich nicht
> leisten will)?
Was mich wieder daran erinnert, meinen Stundensatz mal analog zu den
Benzinpreisen gen Himmel zu schrauben... Ich bin vermutlich eh der
einzige hier mit einem Stundensatz unter 0.1k€.
> Überschrieben wird gar nichts. Entweder wird das neue als $N.rpmnew
> installiert oder das alte als $N.rpmsave hinterlassen (oder es ist eh
> nichts verändert - dann wird es überschrieben).
Ja, ist ja bei Debian ähnlich, bis auf die interaktiven Abfragen (die
man übrigens auch deaktivieren kann).
> Du sollst ja auch nicht Patches für RHEL, sondern CentOS produzieren;-)
:) Es gibt Dinge, die mach ich gratis und dann gibts wieder welche, die
lass ich mir einfach gerne bezahlen, sozusagen Schmerzensgeld.
ciao,
Alex
Bernd Petrovitsch
> Bernd Petrovitsch wrote:
>> Ein anderer Ansatz wäre: Man supportet für alle Apps bestimmte Versionen.
>> Und für die produziert man eigene RPMS/.deb (die unter /opt/ installieret
>> werden).
>
> Oder man machts gleich in Java und liefert die JRE mit, juhu, das wärs,
> ich werd das mal vorschlagen.
Die graut auch vor gar nix, oder;-)
[....]
>> Haben die überhaupt RHEL4 supportet?
>
> Laut Website:
>
> Supported Operating Systems
>
> Red Hat Enterprise Linux 4
> Red Hat Enterprise Linux 5
> CentOS 4/CentOS 5
Also dann halte ich "probieren Sie mal Centos-5.2" am Helldesk auch für eine
fachliche Bankrotterklärung.
[...]
>> Du sollst ja auch nicht Patches für RHEL, sondern CentOS produzieren;-)
>
> :) Es gibt Dinge, die mach ich gratis und dann gibts wieder welche, die
> lass ich mir einfach gerne bezahlen, sozusagen Schmerzensgeld.
ACK.
Bernd Petrovitsch
> Bernd Petrovitsch wrote:
>> Chris Leick wrote:
>>> Bernd Petrovitsch wrote:
>>> Heisst das, ein Supportvertrag verhindert Updates? Das ist dann aber ein
>>
>> Nicht zwingend. Aber wenn Du z.b. Oracle+Oracle-Support haben
>> willst/mußt, dann wird die Auswahl der zertifizierten Distributionen
>> schon relativ eng.
>
Ich fürchte, der einzige "Dienstleister", der derartiges entscheidet, ist
Oracle.
Man kann auch Oracle auf nicht-zertifiziertem fahren. Ist halt v.a. die
Frage, ob "man" das Risiko nehmen kann/will.
[....]
> Igitt. Manchmal beheben neue Major-Releases Probleme und Limitierungen der
> Vorversion. Wenn man dann von einem solchen Supportvertrag geknebelt wird
"Update ist der Austausch von bekannten Fehlern durch unbekannte."
SCNR ....
> wäre das für mich ein Grund, mich mal nach einem anderen Dienstleister
> umzuschauen.
Hängt halt auch vom Supportvertrag ab. Wenn $KUNDE auch rumbasteln kann,
dann wird es halt nur per Stunde geben und keine Verfügbarkeitsgarantie der
Services.
Oder meinst Du, irgendwer garantiert 99,999% Uptime und gibt das
root-Passwort her?
[....]
>>>> Nur so Wahnsinnige wie ich (und Du?:-) machen das - bei mir waren das
>>>> der Wohnungsserver, ein Webserver irgendwo und ein
>>>> "Studenten-Programmier-Server".
>>>> Nix mit "3rd Party" oder "Support" ......
>>>
>>> Den benötigt man auch nicht, wenn nicht ein kommerzieller Hersteller im
>>> stillen Kämmerlein etwas gebastelt hat. SuSEs Yast vermurkste mir früher
>>
>> Es gibt nicht alles als GPLv*. Und manche Firmen kaufen selbst für
>> GPL-Software externen Support ein. Und manchmal gibt es Branchenlösungen,
>> die halt unbedingt (z.B.) Oracle wollen. Außer "Branche wechseln" kann
>> man dagegen wenig tun.
>
> Es gibt also in Deiner Branche quasi ein Monopol?
Ich bin Branchen-agnostisch.
Aber es gibt Branchen, da gibt es nicht viel Auswahl.
[....]
> PgSQL habe ich nicht, aber ich kann mir vorstellen, dass man die Queries
Ich geh mal davon aus, daß es bei MySQL auch ähnliches geben wird.
> auch bei einer Neuinstallation des OS ändern muss.
Ja, eh. Aber wenn ich eine Neuinstallation auf einer anderen Hardware mache
und die Services migriere (und dem Rest der Welt erst zugänglich mach, wenn
sie wirklich gehen), dann hab ich weniger Druck und v.a. Risiko
als "`apt-get dist-upgrade` und um 6:00 in der Früh *muß* alles wieder
laufen".
[....]
>>> Klar. Die wollen schliesslich am Support verdienen und ausserdem bunte
>>> Packungen mit DVDs distributen.
>>
>> Ja, und?
>> Ist halt RedHats und SuSEs Motivation mit Vor- und Nachteilen.
>
> Welchen Vorteil hat das für den Kunden?
Er muß sich für etliche Jahre um so gut wie nichts kümmern und kann den
Telefonjoker benützen, wenn es ein Problem gibt.
Dafür gibt er auch Geld aus.
Und er braucht dafür auch kein sonderlich gut geschultes Admin-Personal
(oder Supporter)[0], weil `yum update` innerhalb eine Major Releases ja
Sinn und Zweck der Übung ist (und RH/SuSE bezahlen Schmerzensgeld an Leute,
die so übercoole Sachen machen wie "Securityfix backporten und testen" für
5 alte supportete Versionen).
[....]
>>> Upgrade von 3.1 auf 4.0 problemlos trotz PHP und Co.
>>
>> Es hängt auch von den eingesetzten PHP-Applikationen ab - nicht nur von
>> PHP als solchem.
>> Und ich fürchte, daß die Masse der Webshops da sehr viel mühsamer sind
>> als leidlich einfache OSS-PHP-Apps.
>> Dazu kommt, daß es einen (kommerziell) gewaltigen Unterschied macht, ob
>> meine interne Stundenverwaltung für 2 Wochen oder mein Webshop für 2
>> Stunden steht.
>
> Wenn Du das System neu installierst nimmst Du aber doch sicher auch die
> neuere PHP-Version, oder?
Kommt drauf an, was die Apps wollen/brauchen.
Ich glaub, ich hab vergessen zu erwähnen, daß "Neuinstallation" natürlich
auf einer anderen, neuen Hardware sein wird und die Migration der
Applikationen nicht unbedingt "hauruck-mäßig".
`apt-get dist-upgrade` bzw. `yum upgrade` sind ja nur Krücken, wenn man
keine neue Hardware hat (oder sich leisten will oder kann oder ....).
Bernd
[0]: Naja, zumindest theoretisch;-)
Alexander Griesser
>> Oder man machts gleich in Java und liefert die JRE mit, juhu, das wärs,
>> ich werd das mal vorschlagen.
>
> Die graut auch vor gar nix, oder;-)
Ich hab einen guten Magen, ja.
> Also dann halte ich "probieren Sie mal Centos-5.2" am Helldesk auch für eine
> fachliche Bankrotterklärung.
Es war ja nicht der Helpdesk. Eigentlich weiß ich nichtmal, obs wirklich
wer von Scalix war oder einfach irgendwer der im Forum gepostet hat
(wobei ich da ja eher auf letzeres tippe).
Als Anwender der Community Edition hat man da nämlich nur bedingten
Support und (soweit ich das mal wo rausgelesen habe) kostet eine Anfrage
für die Community Edition erst mal was, dann wird geschaut und wenn
das Problem wirklich an Scalix liegt (Bug, keine Fehlkonfiguration),
dann wird das Geld zurückerstattet. Die Summen sind gar nicht so mikrig,
weshalb ich mich also zuerst ans Forum gewendet habe, wenngleich der
Support dort eher mäßig ist oder ich bis jetzt einfach nur die
falschen Fragen gestellt habe.
ciao,
Alex
Bernd Petrovitsch
> Bernd Petrovitsch wrote:
>> Chris Leick wrote:
>>> Bernd Petrovitsch wrote:
[...]
>>>> willst/mußt, dann wird die Auswahl der zertifizierten Distributionen
>>>> schon relativ eng.
>>>
>>> Das hängt dann aber vom entsprechenden Dienstleister ab.
>>
>> Ich fürchte, der einzige "Dienstleister", der derartiges entscheidet, ist
>> Oracle.
>
> verlierst Du jeglichen Support? Auch wenn es z.B. um Trigger o.ä innerhalb
Du wirst erst gar keinen Supportvertrag abschließen können[0] - insofern
wirst Du nichts verlieren.
Und was der Support umfaßt, wird im Supportvertrag drinstehen.
Und ja, es ist nichts unbekanntes oder neues, daß "man" $SOFTWAER auch auf
nicht-zertifizertem Systemen im Einsatz fährt - for whatever reason - und
Fehler auf einem 100% zertifiziertem System repliziert, um den Supporter
damit "quälen" zu können.
Die erste Frage ist, ob das ein Pauschal- oder Stundenvertrag ist.
Natürlich wird der Oracle-Support Deine Probleme auf
Gentoo-Updatet-Automatically-Nightly-by-cron lösen, wenn Du ihn per
Stundenaufwand bezahlst.
Wenn Du einen Fixpreis pro Monat und/oder Uptime-Garantien-mit-Pönale haben
willst ungeachtet des Aufwands auf der anderen Seite, wird es das mbMn so
nicht spielen.
In der Praxis trifft man sich irgendwo dazwischen, wo das Risiko für beide
Seiten handhabbar ist.
NB: Ich bin jetzt bei seriösem kommerziellem Support und nicht jenem der
Klasse "Chello-Helldesk mit 30 Minuten in der Warteschleife im
Telephon".
> der DB geht? Klingt nicht sehr kundenfreundlich. Ich verwende Sybase. Dort
Wenn sie schlau sind, werden sie ein "wirf-einen-Bug-ein" Tool haben, daß
jeder benutzen darf.
Supportverträge haben idR wenig bis nichts mit Bugs der Software[1] zu tun.
Üblicherweise hat man Supportverträge, daß man jemanden fragen kann, der
viel mehr über $TOOL und dessen Umgebung und Interaktion mit derselben
weiß, als man selber. Und mitunter schauen diese Leute auch am akuten
Patienten nach, um eine seriöse Diagnose stellen zu können.
> ist das bisher nie ein Problem gewesen. Genaugenommen weiss ich nicht
> einmal, was bei denen zertifiziert ist.
Oracle wird Dir immer auch die DB und alles andere verkaufen und auch im
Rahmen der gesetzlichen Gewährleistung - je nachdem wo man es wie kauft -
(na no na net) unterwegs sein. Ob es zusätzliche Garantie(n) gibt (gratis
oder bezahlt), muß man nachschauen.
Einen Supportvertrag schließt man üblicherweise ab, weil man mit obigem
nicht ausreichend zufrieden ist und u.U. mehrere Telefonjoker braucht.
>> Man kann auch Oracle auf nicht-zertifiziertem fahren. Ist halt v.a. die
>> Frage, ob "man" das Risiko nehmen kann/will.
>
> Du meinst, dann fährst Du ganz ohne Support?
Yup.
[...]
>>> wäre das für mich ein Grund, mich mal nach einem anderen Dienstleister
>>> umzuschauen.
>>
>> Hängt halt auch vom Supportvertrag ab. Wenn $KUNDE auch rumbasteln kann,
>> dann wird es halt nur per Stunde geben und keine Verfügbarkeitsgarantie
>> der Services.
>> Oder meinst Du, irgendwer garantiert 99,999% Uptime und gibt das
>> root-Passwort her?
>
> Du hast kein root-Passwort? Dann gehört die Kiste wohl dem Dienstleister.
Definiere "gehören":
Die Hardware: Nicht zwingend.
> Das ist doch einfach. Wenn was nicht geht musst Du nur dort
> anrufen. "Basteln" tue ich nur an eigenen Rechnern. Allein schon wegen der
Eben. Und "basteln" kann man an der Installation auch.
> Garantie. Entweder die sind root mit allen Konsequenzen oder ich. Wenn's
> mal kracht, wird sonst die Schuld auf den jeweils anderen geschoben.
So ist es.
[ Debian-Werbung, die am Thema vorbei geht, gelöscht ]
>> Dafür gibt er auch Geld aus.
>> Und er braucht dafür auch kein sonderlich gut geschultes Admin-Personal
>> (oder Supporter)[0], weil `yum update` innerhalb eine Major Releases ja
>> Sinn und Zweck der Übung ist (und RH/SuSE bezahlen Schmerzensgeld an
>> Leute, die so übercoole Sachen machen wie "Securityfix backporten und
>> testen" für 5 alte supportete Versionen).
>
> Wie Du sagst:"...innerhalb des Major Releases...". Die Releaseabstände bei
> SuSE und Redhat sind kurz und wenn man es auf Servern sieht findet man oft
7 Jahre Life-Cycle sind kurz?
siehe z.B. http://www.redhat.com/security/updates/errata/
Oder meinstest Du Fedora?
> veraltete Releases, weil der Aufwand zum Upgrade zu hoch ist
Ein Releases ist mbMn dann veraltet, wenn es nicht mehr supportet wird.
Insofern ist ein "altes" Release (z.B. > 3 Jahre) nicht
notwendigerweise "veraltet".
Und es gibt Branchen, die Systeme für > 10 Jahre supportet haben wollen.
[....]
>>>> Und ich fürchte, daß die Masse der Webshops da sehr viel mühsamer sind
>>>> als leidlich einfache OSS-PHP-Apps.
>>>> Dazu kommt, daß es einen (kommerziell) gewaltigen Unterschied macht, ob
>>>> meine interne Stundenverwaltung für 2 Wochen oder mein Webshop für 2
>>>> Stunden steht.
>>>
>>> Wenn Du das System neu installierst nimmst Du aber doch sicher auch die
>>> neuere PHP-Version, oder?
>>
>> Kommt drauf an, was die Apps wollen/brauchen.
>
> IMO ist auch PHP Abwärtskompatibel.
Also wenn ein Scriptsprache den Ruf hat, daß sie nicht besonders
backwardskompatibel ist, ist es PHP. Oder war das nur bis vor ein paar
Jahren so?
Und zumindest am php.ini hab ich unlängst schrauben müssen, weil sich intern
was geändert hat und auf einmal eine lästige Warnugn gekommen ist
(php-4.3.9 -> php-5.1.6).
>> Ich glaub, ich hab vergessen zu erwähnen, daß "Neuinstallation" natürlich
>> auf einer anderen, neuen Hardware sein wird und die Migration der
>> Applikationen nicht unbedingt "hauruck-mäßig".
>> `apt-get dist-upgrade` bzw. `yum upgrade` sind ja nur Krücken, wenn man
>> keine neue Hardware hat (oder sich leisten will oder kann oder ....).
>
> Bei jedem Release neue Hardware hinzustellen kann teuer werden. Ubuntu
Wenn die Umstellung (mind.) 1 Mannmonat (oder eher 2) verschlingt und
Restrisken mit sich bringt, geht neue Hardware idR im Rauschen unter.
Ja, jetzt kommt gleich wieder Debian-Marketing, daß da immer alles ganz
einfach und fehlerfrei und risikolos vollautomatisch an einem Vormittag
funktioniert.
<aetz>Ich nehm an, die Debian-Supporter arbeiten deshalb auch alle fast
gratis mit 99,99% Uptime-Versprechen, weil eh immer alles funktioniert und
es eh kein Risiko gibt.</aetz>
Und ich war bei "Major Releases" wie bei Centos-4 vs Centos-5 (und
nicht "Fedora-9 vs Fedora-10"). Da ist natürlich der Unterschied viel
größer, weil viel mehr Zeit dazwischen liegt wie popelige 6 Monate.
> bringt beispielsweise alle 6 Monate neue Versionen heraus. ;-)
Deshalb installiert man sowas (oder Fedora oder ....) dort vielleicht besser
nicht, wo man selber jahrelang nichts wirklich angreifen will, sich nicht
selber um Updates, Bugfix-Backports, Konfig-File-Änderungen und
Auswirkungen auf sonstige Apps großartig kümmern will - selbst wenn man
dafür wen anderen bezahlt (weil es billiger oder besser ist, als was man
selber machen kann bzw. will).
Und jetzt erkennst Du vielleicht den Unterschied, ob man auf der Suche
nach "stable für 6 Jahre und `$PKT_MANAGER update` tut einfach" oder "immer
leidlich aktuelle Software durch permanentes Upgraden und Anpassen der
Konfigfiles und Apps" ist.
Bernd
[0]: Du wirst ihn mbMn abschließen können, weil er Oracle Geld bringt, aber
kaum Leistungen draus beziehen können.
[1]: Und für welche Software? Für Bugs in der eigenen geht das ja noch;-)
Aber in "fremder" Software wie "Kernel", $SCRIPT_INTERPRETER,
$DBSERVER?
Bernd Petrovitsch
> Bernd Petrovitsch wrote:
>> Chris Leick wrote:
>>> Bernd Petrovitsch wrote:
>>>> Ich fürchte, der einzige "Dienstleister", der derartiges entscheidet,
>>>> ist Oracle.
>>>
>>> Wenn Du es auf einem OS installierst, das die nicht zertifiziert haben
>>> verlierst Du jeglichen Support? Auch wenn es z.B. um Trigger o.ä
>>> innerhalb
>>
>> Du wirst erst gar keinen Supportvertrag abschließen können[0] - insofern
>> wirst Du nichts verlieren.
>> Und was der Support umfaßt, wird im Supportvertrag drinstehen.
>
Nachdem sich ein Supportvertrag durch seinen Inhalt definiert, wird man den
immer genau überlegen. Und die eigenen Anforderungen sind auch nicht immer
gleich.
Insofern kann man sich nur Einzelfälle anschauen.
Laß es mich anders formulieren: Du würdest für ein größeres Softwareprodukt
bezahlten Support anbieten, das die Kunden auf beliebiger Hardware mit
beliebigem "Linux" drunter installieren dürfen.
Zu welchen Bedingungen?
[....]
>> Wenn Du einen Fixpreis pro Monat und/oder Uptime-Garantien-mit-Pönale
>> haben willst ungeachtet des Aufwands auf der anderen Seite, wird es das
>> mbMn so nicht spielen.
>
> In solchen Fällen lasse ich mir eine Kiste vom Anbieter hinstellen mit
> fest definierten Leistungen und einem Vor-Ort-Support.
Und entsprechendem Preis und anderen Einschränkungen wie
$ZERTIFIZIERTE_DISTRIBUTION.
Aonsonsten ganz meine Rede.
>>> der DB geht? Klingt nicht sehr kundenfreundlich. Ich verwende Sybase.
>>> Dort
>>
>> Wenn sie schlau sind, werden sie ein "wirf-einen-Bug-ein" Tool haben, daß
>> jeder benutzen darf.
>
> Das gehört heute zum guten Ton.
Es wäre ja auch dumm, wenn ich - als Softwarehersteller - Gratisbugreports
nicht auch akzeptieren würde.
[...]
>> Oracle wird Dir immer auch die DB und alles andere verkaufen und auch im
>> Rahmen der gesetzlichen Gewährleistung - je nachdem wo man es wie kauft -
>> (na no na net) unterwegs sein. Ob es zusätzliche Garantie(n) gibt (gratis
>> oder bezahlt), muß man nachschauen.
>> Einen Supportvertrag schließt man üblicherweise ab, weil man mit obigem
>> nicht ausreichend zufrieden ist und u.U. mehrere Telefonjoker braucht.
>
> *schulterzuck*
> Für das darunterliegende OS habe ich sowas noch nie gebraucht. Vermutlich
Es ging um Support primär von und für Oracle. Das OS drunter bzw. daneben
ist ja nur Mittel zum Zweck (um nicht "notwendiges Übel" zu schreiben;-).
> würde ich mich auch schämen, wenn ich bei einem Datenbankhersteller
> anrufen müsste um zu erfragen, wie man ein Linux ans Laufen kriegt.
"Linux" zum Laufen kriegen ist ja keine Hexerei (mehr).
Aber $HIGH_PERFORMANCE_APP am $KONKRETER_DISTRI so zum Laufen zu kriegen,
daß man die Hardware zu 99% ausreizt, ist was anderes. Mit
Standardinstallationen wird man das nicht schaffen.
[...]
> Die supporten auch zusammengefriemelte Rechner?
Kaum. Ich würd' es nicht tun. Je nach Anwendung will $KUNDE auch gerne
vorher wissen, wie groß die Leistung ist. Und ohne Randbedingungen (und die
Hardware drunter ist nicht die einzige) wird man da nichts konkretes sagen
wollen.
[....]
>> [ Debian-Werbung, die am Thema vorbei geht, gelöscht ]
>
> Sorry. So sollte das nicht rüberkommen. Ich wollte nur aufzeigen, dass das
> auch anders geht. Ein Bekannter von mir hat seine Server auf Slackware und
Ja, Fedora macht das auch anders. Das kann man auch fast mit "*.repo
austauschen und `yum upgrade`" upgraden.
> installiert auch immer neue Releases. Er sagt er habe damit auch keine
> Probleme. Allerdings besteht Slackware soweit ich weiss nur aus einer
Ich hab mit CentOS auch keine Probleme. Zumindest keine größeren wie mit
Debian. Und wenn PgSQL das Binär-Layout der DB-Files ändert, kann man das
kaum $DISTRIBUTION anlasten.
> Ansammlung von gepackten Einzelpaketen. Gibt es dafür eigentlich
> Installer, die Abhängigkeiten auflösen?
RPM oder .deb verwenden?
Aus einem nackten .tar.gz ohne entsperchende Metadaten kann man das kaum
rauslesen (wie denn auch?).
>>>> Dafür gibt er auch Geld aus.
>>>> Und er braucht dafür auch kein sonderlich gut geschultes Admin-Personal
>>>> (oder Supporter)[0], weil `yum update` innerhalb eine Major Releases ja
>>>> Sinn und Zweck der Übung ist (und RH/SuSE bezahlen Schmerzensgeld an
>>>> Leute, die so übercoole Sachen machen wie "Securityfix backporten und
>>>> testen" für 5 alte supportete Versionen).
>>>
>>> Wie Du sagst:"...innerhalb des Major Releases...". Die Releaseabstände
>>> bei SuSE und Redhat sind kurz und wenn man es auf Servern sieht findet
>>> man oft
>>
>> 7 Jahre Life-Cycle sind kurz?
>> siehe z.B. http://www.redhat.com/security/updates/errata/
>
> Du meinst, wie lange das alte Zeug noch mit Sicherheitsupdates versorgt
Was denn sonst, wenn ich an der Installation als solcher nichts ändern will?
> wird? Ich dachte eher daran, dass man seine Distribution aktuell hält.
Sie ist ja immer "aktuell".
Wenn man sonst nichts ändert, muß man auch $DBSERVER nicht unbedingt ändern.
OK, wenn am Anfang Kinderkrankheiten repariert werden, wird man das
vielleicht machen, weil sich sonst wenig ändert. Aber irgendwann will man
das nicht mehr angreifen.
> Wenn Du dann wirklich mal neuere Hardware brauchst, kommt die aktuelle
> Version meist damit zurecht. Bei einem noch-supporteten Uraltlinux mit
> 2.2er Kernel vermutlich nicht.
Wenn man einer 2.2er Kernel fährt (oder unbedingt ISA-Karten oder -
inzwischen - unbedingt PCI-Karten braucht), dann wird man auch die Hardware
danach aussuchen.
Wenn nicht: SSKM.
HP, Dell, Thomas Krenn, IBM u.a. machen auch das Geschäft damit, daß man
identische PC-Modelle über > 1 Jahr kaufen kann.
Mag am Desktop für 3 Rechner mit Root-Paßwort-Besitzern egal erscheinen.
Aber wenn man 4-stellige Installationen hat (weil man $GROßE_FIRMA o.ä.
ist), dann schaut es anders aus, wenn man nur 3 verschiedene HW-Modelle
oder 300 verschiedene hat.
Ähnlich für Anwendungen, die die Hardware ausreizen und wo man
entsprechendes Tuning machen muß.
>>> veraltete Releases, weil der Aufwand zum Upgrade zu hoch ist
>>
>> Ein Releases ist mbMn dann veraltet, wenn es nicht mehr supportet wird.
>
> Das stimmt nur, solange das Umfeld auch auf dem alten Stand bleibt. Wenn
> die Clients eine neuere Funktion von Samba, dem MTA oder einer DB, wie
> MySQL benötigen, dann hilft die supportete alte Version auch nicht weiter.
Dann kann man immer noch die 3 Pakete für die alte Version rebuilden und gut
ist.
Aber der Upgrade-Problematik (Inteferenzen mit anderer Software, .....) muß
man sich für die 3 Pakete sowieso stellen.
Und Samba und $MTA ist ja harmlos, weil die wenig Abhängigkeiten haben. Bei
$GROUPWARE_PRODUKT, das vorne Applikationscode und ein Konfiginterface hat
und hinten eine DB, einen LDAP-Server, einen MTA, Userverwaltung,
Diskspace-Mgmt., ... voraussetzt/hat/betreibt, schaut es schon ganz anders
aus.
Und gute Leute mit >7 Jahren Unix- und Linux-Erfahrung werden die meisten
Kunden nicht bezahlen wollen (und die, die das wollen, haben dermaßen große
Anforderungen an Benutzer desselben, daß das sowieso ganz eigene Projekte
sind).
> Ganz zu schweigen von neuer Hardware.
Zur Not tauscht man "nur" Kernel+engste Umgebung aus. Sollte im Prinzip
tun .....
[...]
>>> bringt beispielsweise alle 6 Monate neue Versionen heraus. ;-)
>>
>> Deshalb installiert man sowas (oder Fedora oder ....) dort vielleicht
>> besser nicht, wo man selber jahrelang nichts wirklich angreifen will,
>> sich nicht selber um Updates, Bugfix-Backports, Konfig-File-Änderungen
>> und Auswirkungen auf sonstige Apps großartig kümmern will - selbst wenn
>> man dafür wen anderen bezahlt (weil es billiger oder besser ist, als was
>> man selber machen kann bzw. will).
>
> Sehe ich genauso. Man muss die Stunden, die man selbst damit verbringt und
> die Kosten für einen externen Support gegeneinander aufrechnen. Und da
Auf der Kundenseite ja.
Und die Anbieterseite macht das ja auch. Wenn es auf Kundenseite keine
Einschränkungen gibt, wird es nunmal mehr kosten. Oder es gibt
Einschränkungen, dann gibt es das billiger (weil man weniger Zeit braucht,
weil man "Newbies" einsetzen und anlernen kann, ...). Und wenn jemandem der
Support nicht so viel Wert ist, wie er kostet, ...
> Hardware heute vergleichsweise günstig ist, kann man sich auch einfach
> identische Hardware zum Testen, Ausprobieren und natürlich zum Ersetzen
> beim Crash danebenstellen.
Eben.
Und wenn wirklich der "worst case" eintritt, daß man auf
$NEUES_MAJOR_RELEASE übersiedeln will/soll/muß, dann kann man das auch
streß- und risikofreier machen.
>> Und jetzt erkennst Du vielleicht den Unterschied, ob man auf der Suche
>> nach "stable für 6 Jahre und `$PKT_MANAGER update` tut einfach" oder
>> "immer leidlich aktuelle Software durch permanentes Upgraden und Anpassen
>> der Konfigfiles und Apps" ist.
>
> Klar. Ich ziehe zweiteres allerdings vor.
Ja, aber manchmal ist das, was man persönlich vorzieht, einfach eine ganz
dumme Idee. V.a. wenn man laufende Systeme haben muß/will. Oder wenn $KUNDE
es nicht bezahlen wird.
It depends ....
> BTW: Vor sechs Jahren war noch Kernel 2.2 aktuell und der Pentium III /
Ja, in Debian/Stale aka "Sarge" IIRC.
> AMD Athlon 2000+ war Standard, oder?
Nein, da war 2.4 schon länger heraußen
(http://www.linuxtoday.com/news_story.php3?ltsn=2001-01-05-001-04-NW-LF-KN).
Und ich hab in der damaligen Firma einen AMD-900 gehabt IIRC (aber war vor 6
Jahren schon ein 1 Jahr alt und auch nicht das teuerste vom teuersten).
Bernd
Wolfgang Fuschlberger
> Bernd Petrovitsch wrote:
[snip]
> >> BTW: Vor sechs Jahren war noch Kernel 2.2 aktuell und der Pentium III /
> >
> > Ja, in Debian/Stale aka "Sarge" IIRC.
> >
> >> AMD Athlon 2000+ war Standard, oder?
> >
> > Nein, da war 2.4 schon länger heraußen
> >
> (http://www.linuxtoday.com/news_story.php3?ltsn=2001-01-05-001-04-NW-LF-KN).
> > Und ich hab in der damaligen Firma einen AMD-900 gehabt IIRC (aber war vor
> > 6 Jahren schon ein 1 Jahr alt und auch nicht das teuerste vom teuersten).
>
> *staun*
> Heute kann man diese Rechnergeneration noch für einen IP-Cop nutzen.
Ah geh! Kommt immer drauf an, was man alles braucht. Ich sitze daheim an
einem PIII 900 mit 256 MB RAM aus dem Jahr 2001. Eterm, Firefox, openoffice
und lyx laufen sehr gut darauf. Wenn ich Rechenleistung zB zum Fotos
stitchen brauche boote ich meinen DualCore irgendwas und log mich dort ein,
aber für den xserver reicht die alte Kiste auch locker.
wolfgang
--
.-- --- .-.. ..-. --. .- -. --. ... ... .. --. -. .- - ..- .-. .
Bernd Petrovitsch
> Bernd Petrovitsch wrote:
>> Chris Leick wrote:
>>> Bernd Petrovitsch wrote:
[...]
>> Laß es mich anders formulieren: Du würdest für ein größeres
>> Softwareprodukt bezahlten Support anbieten, das die Kunden auf beliebiger
>> Hardware mit beliebigem "Linux" drunter installieren dürfen.
>> Zu welchen Bedingungen?
>
Also statisch linken. SCNR ....
Normale Software war natürlich gemeint: mit den üblichen 10-15 Libs.
[...]
>>> Ansammlung von gepackten Einzelpaketen. Gibt es dafür eigentlich
>>> Installer, die Abhängigkeiten auflösen?
>>
>> RPM oder .deb verwenden?
>
> Bei Slackware? Wusste gar nicht, dass Slackware das kann.
Keine Ahnung. Naja, ein .rpm ist ja auch nur ein cpio Archiv.
Deshalb sind mbMn rpm und .deb entstanden, weil .tar.gz zuwenig kann.
>> Aus einem nackten .tar.gz ohne entsperchende Metadaten kann man das kaum
>> rauslesen (wie denn auch?).
>
> Soweit ich mich erinnere hat Slackware auch keine Abhängigkeitsprüfung.
Ah ja. Mutig. Oder linken die alles statisch?
>>>>> Wie Du sagst:"...innerhalb des Major Releases...". Die Releaseabstände
>>>>> bei SuSE und Redhat sind kurz und wenn man es auf Servern sieht findet
>>>>> man oft
>>>>
>>>> 7 Jahre Life-Cycle sind kurz?
>>>> siehe z.B. http://www.redhat.com/security/updates/errata/
>>>
>>> Du meinst, wie lange das alte Zeug noch mit Sicherheitsupdates versorgt
>>
>> Was denn sonst, wenn ich an der Installation als solcher nichts ändern
>> will?
>
> Die Anforderungen ändern sich meist im Lauf der Zeit.
Tun sie das?
>>> wird? Ich dachte eher daran, dass man seine Distribution aktuell hält.
>>
>> Sie ist ja immer "aktuell".
>> Wenn man sonst nichts ändert, muß man auch $DBSERVER nicht unbedingt
>> ändern. OK, wenn am Anfang Kinderkrankheiten repariert werden, wird man
>> das vielleicht machen, weil sich sonst wenig ändert. Aber irgendwann will
>> man das nicht mehr angreifen.
>
> Das sagen z.B. Banken sehr oft und arbeiten deshalb heutzutage manchmal
> noch mit Cobol-Anwendungen. Begründet wird es dann damit, dass es stabil,
> über Jahre getestet und für viel Geld genau an die Bank angepasst wurde.
> Man treibt dann einen furchtbaren Aufwand, wenn man wirklich mal etwas
> ändern muss, weil z.B. eine Schnittstelle fehlt.
Nur daß es für alte große Software idR niemanden gibt, der sie im Großen
überblickt und versteht. Von numerischen Problemen mal ganz abgesehen.
Und wenn eine Bank mal 6h (IIRC) kein funktionierendes Computersystem hat,
sperrt sie zu.
s.a. "Restrisiko"
[....]
>> Mag am Desktop für 3 Rechner mit Root-Paßwort-Besitzern egal erscheinen.
>> Aber wenn man 4-stellige Installationen hat (weil man $GROßE_FIRMA o.ä.
>> ist), dann schaut es anders aus, wenn man nur 3 verschiedene HW-Modelle
>> oder 300 verschiedene hat.
>> Ähnlich für Anwendungen, die die Hardware ausreizen und wo man
>> entsprechendes Tuning machen muß.
>
> Bei 4-stelligen Installationen lohnt es sich allerdings, wenn man das
> nicht alles fremdtunen lässt, sondern es selbst erlernt oder einen
> Fachmann einstellt.
Du willst aber für 4E3 Rechner nicht (Hausnumer) 10 (teure) Fachleute
einstellen, sondern 3 teure Fachleute und 5 kostengünstige Anfänger von
einer HTL, die ein bißchen was dazulernen, den 1st Level Support abfackeln
und HW-Austausch/Verwaltung machen.
Deshalb hat man nur 3 Modelle und zahlt halt 15% mehr pro Stk.
[....]
>> Dann kann man immer noch die 3 Pakete für die alte Version rebuilden und
>> gut ist.
>
> Argh. Solche gemixten Versionen können manchmal recht ulkige Fehler
> hervorbringen. Hast Du mal probiert ein MySQL5 auf einem SuSE5 zu
Man muß vorher schon checken, ob das überhaupt gehen sollte. Aber sonst?
> installieren?
SuSE hab ich bis jetzt vermeiden können (und MySQL fast ganz).
[....]
> Das ist bei Linuxen IMO auch nicht erforderlich. Wenn die Server keine
> exotischen Dinge tun laufen die über Jahre problemlos. Meine
> Postfix-Konfiguration schleppe ich schon seit Jahren von Server zu Server
> und von Version zu Version. Sie funktioniert immer noch. Das ist der
> grosse Vorteil der Unixe und Linuxe.
Nein, von Postfix, weil sich da im Konfigfile offenbar nicht viel ändert.
Beim sendmail.mc mach ich's i.Ü. auch so (nur das die
Default-sendmail-Konfig bei Debian extrem schwach ist. udn Das /etc/init.d/
Script ebenfalls BTW. <aetz>Naja, Debian halt ...</aetz>).
[...]
>> Zur Not tauscht man "nur" Kernel+engste Umgebung aus. Sollte im Prinzip
>> tun ...
>
> Mmmh. Zuerst tust Du drei Pakete rebuilden, dann den Kernel anpassen - so
> langsam verstehe ich, warum Du neu installierst statt abzugraden. Wo war
Du hast nicht verstanden.
> doch gleich der Vorteil des Sechs-Jahre-Supports?
Du vermischt schon wieder ca. 3 verschiedenen Sachen und reißt sie aus dem
Zusammenhang. Lies und verstehe die letzten Postings nochmal (und quote die
Antworten vollständig). Danke.
[...]
>>> Sehe ich genauso. Man muss die Stunden, die man selbst damit verbringt
>>> und die Kosten für einen externen Support gegeneinander aufrechnen. Und
>>> da
>>
>> Auf der Kundenseite ja.
>> Und die Anbieterseite macht das ja auch. Wenn es auf Kundenseite keine
>> Einschränkungen gibt, wird es nunmal mehr kosten. Oder es gibt
>> Einschränkungen, dann gibt es das billiger (weil man weniger Zeit
>> braucht, weil man "Newbies" einsetzen und anlernen kann, ...). Und wenn
>> jemandem der Support nicht so viel Wert ist, wie er kostet, ...
>
> ...oder die Software in entsprechenden Versionen anbieten. Firmen, wie
Das macht man/Oracle dann und nur nur, wenn es sich (vermutlich) kommerziell
rechnet. D.h. entweder zahlst Du (und andere) genug oder es wird das nicht
(mehr) geben.
> Oracle, die seit Jahren am Markt sind haben mit Sicherheit auch noch den
> Datenträger für das Uraltlinux mit dem Uraltkern.
Welches "Uraltlinux" meinst Du konkret? Debian/Stale?
Du kommst mir schon schon wie 2tklassige HW-Hersteller vor,
die "Linux-Support" überall draufschreiben und dann gibt es irgendwo einen
Binärtreiber für einen 3 Jahre alten Kernel von SuSE.
[...]
>> Und ich hab in der damaligen Firma einen AMD-900 gehabt IIRC (aber war
>> vor 6 Jahren schon ein 1 Jahr alt und auch nicht das teuerste vom
>> teuersten).
>
> *staun*
> Heute kann man diese Rechnergeneration noch für einen IP-Cop nutzen.
Hängt von den Anforderungen ab: (Normale) DNS, DHCP, Time, TFTP-Server
brauchen kaum Ressourcen. Detto Firewalls ohne Echtzeit-Malware-Scanner.
Für einen normalen Fileserver wird es auch reichen, wenn man neuere
schneller Disks reinpackt. Und Mailserver ohne Spam/Virus-Filter (z.B. eine
klassischen Outgoing-Only-Mailserver) kann man auch drauf betreiben.
Außerdem macht man auf derartiger Hardware Abnahmen von eingekauften
Projekten. Dann merkt $LIEFERANT wenigstens, wo er schlecht gearbeitet hat
(weil auf Quad-Core mit 4GHz und 4GB RAM kann jeder schnelle Software
bauen). SCNR ...
Schon eher könnte man überlegen, den Stromverbrauch zu messen und
nachrechnen, ob sich nicht schon aus Stromgründen neue (kleine) Hardware
rechnet.
Adalbert Michelic
> Außerdem macht man auf derartiger Hardware Abnahmen von eingekauften
> Projekten. Dann merkt $LIEFERANT wenigstens, wo er schlecht gearbeitet hat
> (weil auf Quad-Core mit 4GHz und 4GB RAM kann jeder schnelle Software
> bauen). SCNR ...
Sorry, weils bei mir grad aktuell ist: Das ist ein sehr frommer
Wunsch, mit genügend Hirnschmalz schafft man es auch, Software zu
schreiben, die trotz Quad-Core, 4 GHz und 4 GB eine Performance an
den Tag legt, bei der man nach nur wenigen Tagen entweder schwer
koffeinsüchtig oder nikotinabhängig wird.
Ich darf/kann das leider den Verbrecher nicht um die Ohren hauen,
gottseidank hab ich damit keine ernsthafte Arbeit zu erledigen.
Adalbert, kopfschüttelnd
Bernd Petrovitsch
> * On 2008-08-19, Bernd Petrovitsch wrote:
>> Außerdem macht man auf derartiger Hardware Abnahmen von eingekauften
>> Projekten. Dann merkt $LIEFERANT wenigstens, wo er schlecht gearbeitet
>> hat (weil auf Quad-Core mit 4GHz und 4GB RAM kann jeder schnelle Software
>> bauen). SCNR ...
>
> Sorry, weils bei mir grad aktuell ist: Das ist ein sehr frommer
> Wunsch, mit genügend Hirnschmalz schafft man es auch, Software zu
> schreiben, die trotz Quad-Core, 4 GHz und 4 GB eine Performance an
> den Tag legt, bei der man nach nur wenigen Tagen entweder schwer
> koffeinsüchtig oder nikotinabhängig wird.
Das schließt ja obiges nicht wirklich aus.
OK, "kann jeder" ist zu optimistisch ge-word-et und hätte besser "sollte
jeder besser .. können" gewesen sein sollen.
Fürs akute Problem: Es gibt inherent schlecht parallelisierbare Probleme -
da hilft ein 32-Core dann auch wenig. Und wenn die Applikation/System
I/O-bound (und nicht CPU-bound) ist, helfen schnelle CPUs nichts und viel
RAM vermutlich eher wenig.
> Ich darf/kann das leider den Verbrecher nicht um die Ohren hauen,
> gottseidank hab ich damit keine ernsthafte Arbeit zu erledigen.
Bernd
Adalbert Michelic
> Adalbert Michelic wrote:
>> * On 2008-08-19, Bernd Petrovitsch wrote:
>>> Außerdem macht man auf derartiger Hardware Abnahmen von eingekauften
>>> Projekten. Dann merkt $LIEFERANT wenigstens, wo er schlecht gearbeitet
>>> hat (weil auf Quad-Core mit 4GHz und 4GB RAM kann jeder schnelle Software
>>> bauen). SCNR ...
>>
>> Sorry, weils bei mir grad aktuell ist: Das ist ein sehr frommer
>> Wunsch, mit genügend Hirnschmalz schafft man es auch, Software zu
>> schreiben, die trotz Quad-Core, 4 GHz und 4 GB eine Performance an
>> den Tag legt, bei der man nach nur wenigen Tagen entweder schwer
>> koffeinsüchtig oder nikotinabhängig wird.
>
> Das schließt ja obiges nicht wirklich aus.
> OK, "kann jeder" ist zu optimistisch ge-word-et und hätte besser "sollte
> jeder besser .. können" gewesen sein sollen.
So irgendwie, ja. Man würde es sich wünschen.
> Fürs akute Problem: Es gibt inherent schlecht parallelisierbare Probleme -
> da hilft ein 32-Core dann auch wenig. Und wenn die Applikation/System
> I/O-bound (und nicht CPU-bound) ist, helfen schnelle CPUs nichts und viel
> RAM vermutlich eher wenig.
Ach was, das würd halbwegs effizient programmiert nichtmal
Parallelisierung brauchen. Ist ein stinknormaler Dienstplan, da
klickt man sich halt für 30-50 Leute zusammen, an welchem Tag im
Monat sie welchen Dienst machen, sieht die erreichten Stunden und
hat zusätzlich noch ein paar Funktionen um das Personal zu
verwalten.
Wenn man sich bemüht, das ganze Interface streng objektorientiert
macht, und die Daten als serialisierte Objekte in die Datenbank
einkippt, steht man halt blöd da, sobald man was von der DB braucht
- wenn man nicht grad eine Indextabelle für gewisse Felder anlegt,
kann man halt nur suchen, indem man alle Objekte rausholt, und
einzeln anschaut.
Gemeinsam mit ein paar zu gut gemeinten Ideen, wie automatische
Aktualisierung von Daten (aber nicht im Hintergrund, das Programm
darf in der Zeit ruhig blockieren), ergibt das alles andere als
Performance.
Adalbert
Gerald Pfeifer
>>>> Der Debian-Weg, wo hunderte/tausende Paketmaintainer ohne Ende
>>>> Arbeit und Know-How investieren, um das hinzukriegen, macht für
>>>> (IMHO bestenfalls) 1% der Kunden im Fall von RH (oder SuSE) wenig
>>>> kommerziellen Sinn.
>>> Klar. Die wollen schliesslich am Support verdienen und ausserdem bunte
>>> Packungen mit DVDs distributen.
>> Ja, und?
>> Ist halt RedHats und SuSEs Motivation mit Vor- und Nachteilen.
Dass in Linux (kernel und sonst) stark investiert wird und viel
Entwicklung stattfindet die diese beiden finanzieren. (Sprich
einmal einen upstream stark involvierten Kernelentwickler auf
Ubuntu an, zum Beispiel.)
Und dass diese beiden eine Linux-System wirklich voll supporten
können, aufgrund der Größe der Entwicklungsmannschaft und der
Beziehungen zu Hardwareherstellern und Softwareherstellern.
So auf die Schnelle.
Gerald
--
Gerald (Jerry) Pfeifer ger...@pfeifer.com http://www.pfeifer.com/gerald/
Gerald Pfeifer
> Wie Du sagst:"...innerhalb des Major Releases...". Die Releaseabstände bei
> SuSE und Redhat sind kurz und wenn man es auf Servern sieht findet man oft
Major Releases bei RHEL und SLE kommen in etwa alle drei Jahre, das
scheint mir nicht so kurz zu sein. Minor Releases bzw. Service Packs
kommen alle 6-12 Monate, das ist tatsächlich relativ häufig.
> Bei jedem Release neue Hardware hinzustellen kann teuer werden. Ubuntu
> bringt beispielsweise alle 6 Monate neue Versionen heraus. ;-)
LTS allerdings nicht.
Wir müssen aufpassen dass da jetzt nicht Fedora/openSUSE/Ubuntu in
einen Topf mit RHEL/SLE/Ubuntu LTS geworfen wird.
Gerald Pfeifer
> Sehe ich auch so. Ich wollte keineswegs sagen, dass andere Distris keine
> brauchbaren Lösungen hätten. (Na ja - von SuSE mal abgesehen.)
Was war die letzte openSUSE/SLE die du probiert hast? Was war das
Problem? Wo/wie hast du es berichtet?
>> HP, Dell, Thomas Krenn, IBM u.a. machen auch das Geschäft damit, daß
>> man identische PC-Modelle über > 1 Jahr kaufen kann.
> Klar. Die lassen sich das vergolden.
s/vergolden/Kosten entgelten/
Im Prinzip ist die Wahl diese, oder eben in die Softwareseite mehr Geld
zu investieren wie Bernd festgestellt hat. Ohne Kosten auf der einen
oder anderen Seite wird's nicht gehen.
Bernd Petrovitsch
[....]
> Wir müssen aufpassen dass da jetzt nicht Fedora/openSUSE/Ubuntu in
> einen Topf mit RHEL/SLE/Ubuntu LTS geworfen wird.
Natürlich nicht (oder hat jemand geglubt, daß z.B. RHEL und Fedora das
gleiche wäre?).
Die bedienen in Wirklichkeit 2 ganz verschiedenen Zielgruppen (oder anders
formuliert: Die gehen von verschiedenen organisatorischen Randbedingungen
aus).
Bernd
Bernd Petrovitsch
[...]
> einmal einen upstream stark involvierten Kernelentwickler auf
> Ubuntu an, zum Beispiel.)
Mehr Statistik ist auch in http://www.youtube.com/watch?v=L2SED6sewRw zu
finden.