Suse 8.2 : deinstallieren von OpenSSL - Abhaengigkeiten ???
Hallo Liste, ich möchte OpenSSL aufgrund seiner neulich entdeckten Sicherheitsloecher deinstallieren und mein eigenes Paket instalieren. Das Problem hierbei sind die Abhaengigkeiten von den anderen Paketen. Wie kann man das am besten haendeln ? Pakete wie openssh oder andere laufen dann nicht mehr weil sie auf die openssllib xxx referenzieren. 1 .Kann ich diesen Paketen der einfachheit halber beibringen das neue selbst kompilierte openssl zu benutzten ? ( ssh ist nicht schlimm , weil ich auch das neu kompiliere aber anderen Paketen und grundsaetzlich waere es eben interessant zu wissen... 2. wenn ich also den installierten Paketen die neuen libs unterschieben kann, kann man yast irgendwie beibringen, dass es die anhaengkeiten als gegeben anerkennt? Danke fuer eure Hilfe Filip
On Wednesday 01 October 2003 09:52, Filip Lyncker wrote:
Hallo Liste,
ich möchte OpenSSL aufgrund seiner neulich entdeckten Sicherheitsloecher deinstallieren und mein eigenes Paket instalieren. Das Problem hierbei sind die Abhaengigkeiten von den anderen Paketen. Wie kann man das am besten haendeln ? Pakete wie openssh oder andere laufen dann nicht mehr weil sie auf die openssllib xxx referenzieren.
Nö, die laufen schon (so denn die lib da ist). Was allerdings stimmt ist, das die Abhängigkeiten in der rpm-Datenbank nicht aufgelöst sind.
1 .Kann ich diesen Paketen der einfachheit halber beibringen das neue selbst kompilierte openssl zu benutzten ? ( ssh ist nicht schlimm , weil ich auch das neu kompiliere aber anderen Paketen und grundsaetzlich waere es eben interessant zu wissen...
Das machen die automatisch, wenn die lib installiert ist (und gefunden wird via dynamic link loader)
2. wenn ich also den installierten Paketen die neuen libs unterschieben kann, kann man yast irgendwie beibringen, dass es die anhaengkeiten als gegeben anerkennt?
Pack Deine Version in ein rpm oder erstell ein dummy rpm. Anders bekommst Du die rpm-Datenbank nicht konsistent. Andreas
Nö, die laufen schon (so denn die lib da ist). Was allerdings stimmt ist, das die Abhängigkeiten in der rpm-Datenbank nicht aufgelöst sind.
hmmn ok aber zB im Falle von openSSL ist eine lib x.6 installiert die neue ist jetzt x.7 sie hat also einen anderen namen ! ich habs ausprobiert und die wurde nicht gefunden von openssh.. was muss ich machen damit die lib gefunden wird ? Das machen die automatisch, wenn die lib installiert ist (und gefunden wird via dynamic link loader) kann der dynamic link loader auch die verschiedenen versionen der lib kompensieren ?
Pack Deine Version in ein rpm oder erstell ein dummy rpm. Anders bekommst Du die rpm-Datenbank nicht konsistent.
ok .. klingt gut ....:) gruesse filip
On Wednesday 01 October 2003 10:20, Filip Lyncker wrote:
Nö, die laufen schon (so denn die lib da ist). Was allerdings stimmt ist, das die Abhängigkeiten in der rpm-Datenbank nicht aufgelöst sind.
hmmn ok aber zB im Falle von openSSL ist eine lib x.6 installiert die neue ist jetzt x.7 sie hat also einen anderen namen ! ich habs ausprobiert und die wurde nicht gefunden von openssh.. was muss ich machen damit die lib gefunden wird ?
Dann hast Du geloost! Ganz mutige lösen das mit ein symbolischen Link, aber dafür würde ich nie garantieren. Hier hilft dann nur die Software, die die lib*x.6 benötigt zum Zusammenspiel mit lib*x.7 zu bringen. Dazu must Du i.d.R. hierfür neu übersetzen bzw. neuere rpm's einspielen.
Das machen die automatisch, wenn die lib installiert ist (und gefunden wird via dynamic link loader)
kann der dynamic link loader auch die verschiedenen versionen der lib kompensieren ?
Was heist kompensieren hier? Der dynamic link loader versucht, die angeforderte Lib zu laden. Nicht mehr und nicht weniger.
Pack Deine Version in ein rpm oder erstell ein dummy rpm. Anders bekommst Du die rpm-Datenbank nicht konsistent.
ok .. klingt gut ....:)
Wäre es nicht einfacher, die von SuSE bereitgestellten security fixes einzuspielen? Andreas
participants (2)
-
Andreas Kyek -
Filip Lyncker