[Alug] SLES gesucht 7,8,9

Don Feb 12 01:45:09 CET 2004

Hi Jörg.

ich habe auf der [suse-oracle] mailingliste ein wenig stress geschoben,

wäre nett wenn ein erfahrener SuSe Fachmann sich zu
installations und Konfigurationsfragen von Oracle unter Suse 8.2  äussern
könnte.

Das einzige was ich noch tun kann, ist die Oracle originaldokumentation zu
lesen.

Ansonsten bin ich auf diese Information

http://openacs.org/doc/oracle.html

http://www.wicke.meiserver.de/Oracle8i/orainst8isuse82.html
http://www.wicke.meiserver.de/Oracle8i/orainst8isuse82en.html

http://oyap.net/Documents/LINUX/suseuk/

Angewiesen.

Stimmt sie so weit ?

Wenn Suse selber keine korrekte Installationsanleitung macht,
dann ein Paar von den existierenden Links  kommentieren,

Wenn wir uns auf der [suse-oracle] mailingliste treffen werden wir englisch
tippen dürfen.

mfg

Morten

----- Original Message ----- 
From: "Joerg Reuter" <jr at ccac.rwth-aachen.de>
To: "Aachener Linux User Group" <alug at scp.de>
Sent: Wednesday, February 11, 2004 11:39 PM
Subject: Re: [Alug] SLES gesucht 7,8,9

> Hi,
>
> auch wenn ich mich gewöhnlich nicht zu SUSE-Bashing äußere...
>
> > 1. SLES ist ein etwas ältliches Standard-SuSE-Linux
>
> SLES8 basiert auf SuSE Linux 8.1, hat aber mit der Original-8.1
> nur noch wenig zu tun.
>
> > 2. Für dich wahrscheinlich wichtig: die Oracle-Installation erfordert
> > exakt das gleiche Flickwerk wie andere SuSE Linuxe.
>
> Wenn zur Installation Flickwerk notwendig ist liegt das an Oracle.
>
> > 3. SLES ist das Geld nicht wert.
>
> Es kommt darauf an, was man benötigt. Wer keinen Support von Oracle für
> das Oracle-System benötigt, braucht auch kein SLES, das stimmt. Wer in
> der Pflege eines Produktivsystems so fit ist, dass er alle Security- und
> Bugfixes selbst bauen kann, auch nicht.
>
> > Ad 1: Mit der Begründung, man könne ja nicht jeden Kernelfurtz neu
> > zertifizieren neue Kernelreleases mit fast 1 Jahr 'Verspätung'
> > ausgeliefert. Das mag häufig nicht SO tragisch sein, weil Patches auf
> > den alten SLES Kernel zurück migriert werden. *würg*
>
> Die meisten Änderungen innerhalb (später) stabiler Kernel-Versionen sind
> reine Bug- und Security-Fixes, die sich problemlos zurückportieren
> lassen. Problematisch sind API-Änderungen, die manchmal trotz "stabiler"
> Kernel-Serie vorkommen, oder auch völlig neue Treiber- Versionen --
> selbstverständlich kann man diese nicht ohne Neuzertifizierung durch die
> ISVs¹ und gegen die zertifizierte Hardware übernehmen.  Der
> Enterprise-Server verspricht ja genau das: das Produkt darf nichts, was
> vorher ging, kaputt machen (dass einem diese verfluchten PC-BIOSe mit
> ihren grottigen ACPI-Implementierungen dies in Einzelfällen kaputtmachen
> ist Schuld der IHVs².)
>
> Ein anderer Grund, warum Kernel-Updates komplex sind: beim SLES8 sind
> die Kernel-Sourcen für alle Architekturen (x86, ppc, S/390, zSeries,
> x86_64, ipf) identisch -- sonst wäre das bei den vielen unterstützen
> Plattformen garnicht wartbar und ist von ISVs auch ausdrücklich so
> gewollt. D.h., ein Kernel-Upgrade muss für alle Prozessor-Architekturen
> getestet werden, von den Hardware-Herstellern freigegeben werden (bzw.
> die Hardware von SUSE re-zertifiziert werden), von etlichen
> Applikations-Herstellern durch lang laufenden Testsuites (und auch die
> müssen vor der Freigabe ggf. das Okay von Hardware-Herstellern
> einholen). Naturgemäß möchten IHVs und ISVs dieses nicht alle paar
> Wochen machen müssen.
>
> Es ist übrigens auch nicht gerade einfach, die Erweiterungen auf eine
> neue Kernel-Version zu portieren und testen, die gerade auf
> ausdrücklichem Wunsch von ISVs eingebaut wurden. Im Kernel für
> SUSE-Produkte stecken zudem (wohl aus diesem Grund) Rückportierungen
> aus Kernel 2.5/2.6. Wirklich Spaß macht die Pflege solcher Extrawürste
> vermutlich nicht...
>
> > Dumm nur, daß wir dort beim Kunden einen 2.4.21er Kernel benötigten,
> > weil ein EMIC Clustermanager drauf sollte.
>
> Dumm nur, dass du dich nicht vorher erkundigt hast, ob das überhaupt so
> zusammen laufen kann. (Dafür gibt es bei den Herstellern und bei SUSE
> Zertifizierungs-Listen)
>
> Mit dem Service-Pack 3 gibt es übrigens einen 2.4.21-Kernel.
>
> > Ad 3: Man zahlt reichlich Geld für eine Zertifizierung, die nicht viel
> > wert ist.
>
> Erstens ist es nicht nur die Zertifizierung für Oracle, sondern auch für
> eine ganze Reihe weiterer Produkte, die die Entwicklung verteuern.
> Zweitens ist der Kaufpreis eigentlich der Preis für das erste Jahr
> Maintenance: d.h. dafür, dass die Pakete auf dem SLES gepflegt werden,
> Kunden über Updates informiert werden und Support für die
> Erst-Installation des Basis-Systems und die Installation von
> Maintenance-Updates (inkl. Unterstützung, falls ein Update doch einmal
> bestehende Funktionalität des Paketes beschädigt hat).
>
> Die Zertifizierung des Systems ist Voraussetzung für (jegliche Form von)
> Support von SUSE und vom ISV (Oracle in diesem Fall). Der Einsatz
> zertifizierter Hardware ebenso.
>
> > "Ja wir geben ein Zertifikat nur auf die AUSFÜHRBAREN
> > Programme, die Probleme, die die Installation macht liegen an der
> > ENTWICKLUNGSUMGEBUNG. Darauf haben wir keinen Einfluß."
>
> Moment, das war dann doch eine Aussage von Oracle, oder?
> Installationsprobleme von ISV-Produkten werden nicht durch den
> SUSE-Support behandelt. Und Schuld daran, wenn Oracle nicht in der Lage
> ist, direkt lauffähige Programme auszuliefern, hat, na, wer wohl?
>
> > Ügrigens gehört die Entwicklungsumgebung (gcc und friends) NICHT zur
> > Standard-Installation.
>
> Nur Oracle braucht (anscheinend) solche Klimmzüge. Andere ISVs
> bekommen es hin, Produkte zu bauen die sich problemlos installieren
> lassen.
>
> > Wohl aber ein full featured KDE *lol*
>
> Man kann es nicht allen Recht machen. Du brauchst kein KDE, andere
> motzen, wenn irgenwelches KDE-Geraffel nicht geht. Auf einem Server. Es
> wird von den meisten Kunden verlangt. Wirkliches Entsetzen packt einen
> aber wenn Beschwerden kommen, dass KDE auf IBM zSeries soviel Speicher
> und CPU braucht und so langsam sei...
>
> > Dann meinte ich, ein gcc sei für mich absolut unabdingbar, weil ich
> > gewohnt sei auf Produktivsystemen optimierte LAMP-Komponenten zu
> > installieren. Antwort dazu: "Sie wissen ja sicher, daß Sie jeden
> > Anspruch auf Support verlieren, wenn Sie Komponenten installieren, die
> > NICHT von SuSE kommen ..."
>
> So allgemein stimmt das nicht. Natürlich dürfen auf einem Server
> Server-Applikationen installiert werden, dafür ist das da. Wenn du
> Komponenten ersetzt, die mitgeliefert werden, gibt es für den Selbstbau
> und alles was daran hängt keinen Support. Wenn die selbstgebauten Pakete
> irgendwas anderes im System zerstören, auch nicht. Übrigens von
> niemandem, weder von SUSE noch von den ISVs.
>
> > Ja Herrschaftszeiten - welchen Support??
>
> Mitgeliefert: Installations-Support für die Erstinstallation, Support
> für die Installation und Schadensbehebung von bzw.  durch
> Maintenance-Updates. Der größte Teil des Maintenance- Vertrags besteht
> wie erwähnt aus der aktiven Pflege der Pakete (mit aufwändigen
> Regressions-Tests), der Dokumentation der daraus folgenden Updates und
> dem Bereitstellen via Web-Download oder YaST Online Update. Eine
> Reaktionszeit wird nicht garantiert. Wenn du Reaktions-Zeiten und über
> den Installations-Support hinausgehende Unterstützung (inklusive
> L3-Support, also Entwicklung und Bereitstellung von Bugfixes) benötigst,
> musst du dazu entsprechenden Support dazukaufen.
>
> Dies ist auch unter http://www.suse.de/de/business/services/support/ und
> den Produkt-Beschreibungen (tatsächlich muss man nach der Aussage, dass
> das Paket mehr enthält als nur Handbuch und Medien, etwas suchen...)
> erklart. Zudem sind die Bedingungen im Handbuch deutlich dargelegt.
>
> Du solltest dich vor der Anschaffung eines Produktes schon informieren,
> was Lieferumfang ist. Spätestens aber bevor du zum Kunden rausfährst.
>
> > Übrigens gibts jetzt nach Ablauf des Support-Vertrags keine RPM's mit
> > Patches mehr. Das würde knapp 750 Euro pro Jahr extra kosten ... wegen
> > dem umfangreichen Support - ihr versteht schon :-)=)
>
> Nein, wegen der Kosten für die Erstellung und Bereitstellung der
> Maintenance-Updates. Und dem ganzen Rattenschwanz an Tests und Politik,
> der da noch dran hängt.
>
> > Übrigens war der gcc natürlich doch auf den Distri-CDs vorhanden - nur
> > nicht installiert. Das wußte der Supporter aber nicht :-)=)
>
> Einige Oracle-Versionen (oder zumindest auf einigen
> Rechnerarchitekturen) benötigen zum Linken wenn ich das richtig im Kopf
> habe einen gcc-2.95, mitgeliefert wird gcc-3.X. Der gcc-2.95 ist als
> "gcc_old" erst auf service pack 3 (alles aus dem Kopf, kann ich hier
> gerade nicht verifizieren). Was nicht mitgeliefert wird sind einige
> *-devel Pakete für Libraries (glibc-devel ist aber dabei).
>
> > Man empfahl mir auf die "SLES Entwickler-Workstation" zu warten, damit
> > könne man dann auch Software für die SLES Plattform entwickeln
>
> Für einige Rechner-Architekturen gibt es eine Developer's Edition, für
> SLES können die benötigten Pakete von der SL 8.1 nachinstalliert werden.
> Das Entwickler-Kit für SLES8 war wohl mal angedacht, ist aber bislang noch
> nicht aufgetaucht.
>
> ¹ IHV = Independent Hardware Vendor
> ² ISV = Independent Software Vendor
>
> Gruß,
> -- 
> Joerg Reuter                                    http://yaina.de/jreuter
> And I make my way to where the warm scent of soil fills the evening air.
> Everything is waiting quietly out there....                 (Anne Clark)
>
> _______________________________________________
> ALUG mailing list
> ALUG at scp.de
> http://www.alug.de
>