• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

Gelöst Installation von db 2 unter Suse 15.6 - Symbolische Links

Guten Tag,

nun versuche ich DB 2 auf OpenSuse 15.6 zu installieren.



Einige Probleme habe ich bereits beseitigt, aber ein Problem kann ich nicht lösen. Es geht um „Symbolische Links“. Leider weiß ich nichts darüber.



Wenn ich „./db2prereqcheck -i“ laufen lasse, bekomme ich u.a. folgende Fehlermeldung:



DBT3624E Das Dienstprogramm db2prereqcheck hat festgestellt, dass ksh nicht mit lksh oder mksh verknüpft ist. Dies ist für das Db2 High Availability-Feature erforderlich.

Was muss ich tun? Es muss etwas mit den diversen Shells zu tun haben.



Hat wer einen Tip?
 
Was ist "DB 2"? Dieses? Ist das Teil der Distribution?
Es gäbe sonst andere SQL-Systeme: MySQL, SQLite und MariaDB wären da die gängigen Namen.
 
@abgdf: Die Ursprünge dieser Datenbank gehen auf das Jahr 1970 zurück (Juni). Siehe hier:



IBM Db2 - Wikipedia



@marce: Ich werde aus dieser IBM-Hilfe nicht schlau. Sie bezieht sich auf OpenSuse 15.4.



Ich habe versucht, diverse Versionen der ksh zu installieren. Dies ist der momentane Stand:



ksh-93vu-lp156.287.1.x86_64
mksh-56c-1.10.x86_64

(Eingabe:)
rpm -qa | grep ksh

Aber das Problem besteht weiter. Ich weiß nicht, was ich probieren soll.
 

susejunky

Moderator
Teammitglied
@susejunky: Vielen Dank für Deinen Hinweis auf die Dokumentation. Da habe ich jetzt Folgendes gefunden:



Additional installation considerations (Linux)



An jener Stelle steht allerdings nichts über Versionen:


ksh or mksh or lkshAT&T Korn Shell or MirBSD Korn Shell or Legacy Korn Shell


Wie würde ich denn im Zweifelsfall die Korn Shell als Standard einstellen? Sollte ich es eventuell mit einer „Legacy Korn Shell“ versuchen? Das ist das einzige, was ich noch nicht probiert habe.
 
15.4 vs. 15.6 dürfte an der Stelle kein großes Thema sein (hoffentlich) - Hauptpunkt ist evtl. eher, dass die DB2 nur für SLES off. supported ist - und damit evtl. die kompletten nicht-SLES-OpenSuses "raus" sind, weil ggf. noch andere Abhängigkeiten an Bibliotheken nicht passen...
 
@marce: Danke für den Hinweis. Ich werde jetzt erstmal generell etwas über Shells nachlesen, weil mir das bisher alles noch relativ unklar ist.
 

susejunky

Moderator
Teammitglied
Sollte ich es eventuell mit einer „Legacy Korn Shell“ versuchen?
Laut dieser Dokumentation wird db2prereqcheck mittels einer XML-Datei gesteuert:

... The db2prereqcheck command uses a resource XML file that contains the prerequisites. The default path of the XML file for Linux® and UNIX is located in DB2 installation/cfg/DB2prereqs.xml.

Vielleicht ist aus dieser Datei ersichtlich, welche Voraussetzungen bezüglich der ksh durchgeführt werden.
 
@susejunky: Vielen Dank für den Hinweis. Eine entsprechende xml-Datei habe ich gefunden. Ich weiß allerdings nicht, ob es tatsächlich die richtige ist. Da heißt es u.a.:

<ksh value="LinuxDistro = SUSE SLESVersion = 15" >

<kshPackage>ksh</kshPackage>

<kshVersion>93u</kshVersion>

<kshRelease>0.8.1</kshRelease>

<mkshPackage>mksh</mkshPackage>

<mkshVersion>50f</mkshVersion>

</ksh>


Allerdings bin ich noch etwas blind, und kann es nicht deuten. Dies scheint eine uralt-Version zu sein. Diese Version hat nicht den Standard, der in dem ersten Link, der hier gepostet wurde, angegeben wird. (@marce)
Ich finde diese Version allerdings auch in meinen Notizen.
 
Hast Du schon mal geguckt ob Du die Version ksh-93vu-lp154.274.1.x86_64 unter PackageHub für deine 15.6 findest? Das ist die Version die in der von marce verlinkten Doku angegeben ist.

Ansonsten guck mal welche shell für root in der /etc/passwd angegeben ist und ändere das mal auf /bin/ksh (oder unter welchem Pfad sich das auch immer befindet). Reboot nicht vergessen! Ich vermute das es, im Gegensatz zu der Express-Version, keine dedizierten User (db2inst1 etc) für DB2 gibt?
 
Zuletzt bearbeitet:
@abgdf : Dir ist aber schon klar, dass die Wahl eines DB-Systems durchaus nicht davon abhängt, was "die gängigen Namen sind"? Nett, dass Du überall Deinen Senf abgibts, aber wenn Du mal rein gar nichts zu sagen hast - dann lass' es doch auch einfach.
Du weißt ja gar nicht, was das Thema ist.

Warum will er unbedingt DB2? Ich habe Alternativen genannt, die einfacher zu installieren und möglicherweise besser dokumentiert sind, und möglicherweise dasselbe erreichen, was er möchte.
Erstmal muß man herausfinden, was der Klient/Mandant/Kunde/Hilfesuchende überhaupt will. Sonst läuft man in eine völlig falsche Richtung.
Aber Du kannst gern noch ein bißchen ahnungslos in der Wüste umherirren, wenn Dir das Spaß macht.
 
@Geier0815 Merci, das habe ich jetzt auch probiert. Ich habe ksh als root shell eingetragen in /etc/passwd. Ich bekomme immer die gleiche Fehlermeldung.

@aggdf und @marce: Ihr habt beide recht. Ich dachte, ich probiere mal eine "alte" DB aus, aber das macht offensichtlich kein Vergnügen, weil sie kaum noch verwendet werden, oder in kleinen Kreisen.

Vielleicht sollte ich das ganze im Sande verlaufen lassen...
Eine schnelle Lösung sehe ich momentan nicht.
 
Alle drei Programme sind vorhanden. Möglicherweise werden sie von DB2 nicht nur mit dem Programmnamen, sondern mit einem "falschen" Pfad angesprochen. Bei dem Problem wird Dir nur der Hersteller oder jemand, der Erfahrung mit DB2 hat, helfen können.
 

susejunky

Moderator
Teammitglied
Vorab: Ich kenne mich mit DB2 nicht aus!

DBT3624E Das Dienstprogramm db2prereqcheck hat festgestellt, dass ksh nicht mit lksh oder mksh verknüpft ist. Dies ist für das Db2 High Availability-Feature erforderlich.

Bedeutet die obige Meldung, dass sich DB2 nicht installieren lässt oder wäre eine Installation ohne das "DB2 High Availability-Feature " möglich?

Ich könnte mir vorstellen, dass Du für Deinen Anwendungsfall ("... Ich dachte, ich probiere mal eine "alte" DB aus, ...") diese Funktionalität nicht unbedingt benötigst.
 
Nun habe ich die Installation mit den Parametern „-f sysreq“ gestartet und ich habe ein positives Ergebnis:


Die Ausführung wurde erfolgreich abgeschlossen.


Vielen Dank, Euch, ihr habt mir sehr geholfen. Ich habe auch einiges über Shells gelernt.



Vielleicht sollte ich noch erwähnen, dass ich sämtliche „/bin/bash“-Bezüge in der Datei „/etc/passwd“ durch „/usr/bin/ksh“ ersetzt habe.



Ich denke, dieses spezifische Problem ist jetzt zufriedenstellend gelöst.
 
Oben