błąd podczas ładowania bibliotek współdzielonych: libcrypto.so.1.1

13

Kiedy uruchamiam „openssl”, pojawia się błąd jak poniżej:

openssl: błąd podczas ładowania bibliotek współdzielonych: libcrypto.so.1.1: nie można otworzyć pliku obiektu współdzielonego: brak takiego pliku lub katalogu ”

Stało się to po próbie aktualizacji OpenSSL zgodnie z tym artykułem

Czy można to naprawić?

System operacyjny: CentOS 6.8 Serwer WWW: nginx / 1.10.2

Aktualizacja nr 1:

[root@host ~]# yum info openssl
Installed Packages
Name        : openssl
Arch        : x86_64
Version     : 1.0.1e
Release     : 48.el6_8.3
Size        : 4.0 M
Repo        : installed
From repo   : system-updates
Summary     : A general purpose cryptography library with TLS implementation
URL         : ***
License     : OpenSSL
Description : The OpenSSL toolkit provides support for secure communications
            : between machines. OpenSSL includes a certificate management tool and
            : shared libraries which provide various cryptographic algorithms and
            : protocols.

Available Packages
Name        : openssl
Arch        : i686
Version     : 1.0.1e
Release     : 48.el6_8.3
Size        : 1.5 M
Repo        : system-updates
Summary     : A general purpose cryptography library with TLS implementation
URL         : ***
License     : OpenSSL
Description : The OpenSSL toolkit provides support for secure communications
            : between machines. OpenSSL includes a certificate management tool and
            : shared libraries which provide various cryptographic algorithms and
            : protocols.
mayasl
źródło
2
Przepraszamy, natrafiłeś na kolejny zły samouczek internetowy. Może być konieczna ponowna instalacja systemu. Zanim przejdziemy dalej, sugeruję, aby zapytać o oryginalny problem, który próbujesz rozwiązać, robiąc to. Prawdopodobnie jest lepszy sposób na osiągnięcie pierwotnego celu.
Michael Hampton
Chciałem zainstalować aplikację Monitor serwera dostarczoną przez Monitis. Potrzebował zależności biblioteki współdzielonej, które nie zostały zainstalowane na moim serwerze. Wszystko to wydarzyło się, gdy trzeba było je zainstalować. :(
majasl
@MichaelHampton Powiedz mi coś oprócz ponownej instalacji systemu. Ponieważ na tym serwerze działa witryna na żywo!
majasl

Odpowiedzi:

20

Miałem ten sam problem po zainstalowaniu ostatniej wersji openssl 1.1.0c, że problem został rozwiązany kopiowanie plików bibliotecznych libcrypto.so.1.1, libcrypto.aa libssl.sood /usr/local/lib64do biblioteki zakładowego /usr/lib64.
Po skopiowaniu bibliotek musisz utworzyć dowiązanie symboliczne.

ln -s libcrypto.so.1.1 libcrypto.so
ln -s libssl.so.1.1 libssl.so

Po utworzeniu dowiązania symbolicznego wymagana była również pamięć podręczna ldconfig :

sudo ldconfig
Benedykt
źródło
8

W twojej oryginalnej wersji OpenSSL wiedział, jak znaleźć współdzielone biblioteki, ponieważ /usr/lib64jest zawarty w ścieżce wyszukiwania linkera. Kiedy pobrałeś i skompilowałeś „lokalną” kopię OpenSSL, współdzielone biblioteki lib były /usr/local/lib64domyślnie umieszczone . Prawdopodobnie musisz po prostu dodać ten katalog do ścieżki wyszukiwania linkera, tak jak ten (jako root):

echo "/usr/local/lib64" > /etc/ld.so.conf.d/openssl.conf

następnie wykonaj:

ldconfig

Wierzę, że to rozwiąże problem.

doug.fsu
źródło
W przynajmniej współczesnych dystrybucjach Ubuntu (piszę to 16.04 LTS) i prawdopodobnie w innych, sudo echo "/usr/local/lib64" > /etc/ld.so.conf.d/openssl.confspowoduje błąd „odmowa uprawnień”, ponieważ druga połowa polecenia (zapis pliku) nie jest wykonywana jako root. Jeśli tak się stanie, spróbuj sudo sh -c "echo '/usr/local/lib64' >> /etc/ld.so.conf.d/openssl.conf"zamiast tego.
Matthew Cole
3

Ten błąd wystąpił podczas używania Termuxa w systemie ChromeOS, co spowodowało awarię programów npmi nodewiersza poleceń.

Uruchomienie pkg upgraderozwiązało problem!

Carl Walsh
źródło
1

Możesz go ponownie zainstalować za pomocą

yum install -y openssl-devel

mzhaase
źródło
Próbowałem też, ale nie pomogłem!
majasl
@mayasl Być może trzeba również zainstalować ponownie inne pakiety. Spodziewałbym się, że wywołany pakiet openssl-develbędzie zależał od pakietu o nazwie openssl. Pamiętaj, że minęło dużo czasu, odkąd go dotknąłem yum, więc nie mogę zweryfikować dla ciebie składni polecenia.
kasperd
Zaktualizowałem moje pytanie o wynik „yum info openssl”. Proszę spojrzeć, jeśli jest to przydatne. Przed rozpoczęciem tego wątku usunąłem i ponownie zainstalowałem openssl i openssl-devel. Nie działał! Polecenia użyłem: codeyum remove openssl yum remove openssl-devel yum oczyścić wszystkie
mayasl
Ponowna instalacja openssl(i nie openssl-devel) powinna być dobrym początkiem.
Michael Hampton
Już próbowałem @MichaelHampton Czy to jest jakiś problem z łączeniem ???
maja
1

To, co powiedział @benedict, działało dla mnie. Jednak może się okazać, że niektóre dowiązania symboliczne wskazują starsze wersje. Uruchomienie ls -l libcrypto*z / usr / libs pokaże linki. Jak w poniższym przykładzie:

lrwxrwxrwx 1 root root      16 May 21 15:28 libcrypto.so -> libcrypto.so.1.0

Następnie chciałbyś najpierw usunąć istniejące łącze, wpisując, sudo rm libcrypto.soa następnie kopiując libcrypto.so.1.1, jak wspomniano w @benedict. Wreszcie możesz utworzyć nowy link. sudo ln -s libcrypto.so.1.1 libcrypto.so

Mam nadzieję że to pomoże.

Ihsan Izwer
źródło
1

libcrypto.soNależy do openssl-libsspakowania. Jeśli ręcznie wymusisz usunięcie (z --nodeps) tego pakietu lub uszkodzenie go przez uaktualnienie, utracisz dostęp do yum, wget, curl, ssh itp. Jeśli system ma dostęp do Internetu, pobierz polecenie openssl-libsza pomocą /usr/bin/GET. Jeśli próbujesz przywrócić wersję, składnia wygląda następująco openssl-libs-1.0.2k-8.el7.x86_64:

/usr/bin/GET http://downloadURL/openssl-libs-1.0.2k-8.el7.x86_64.rpm > openssl-libs-1.0.2k-8.el7.x86_64.rpm

Spowoduje to utworzenie openssl-libs-1.0.2k-8.el7.x86_64.rpmpakietu, którego możesz użyć do ponownej instalacji lub wypakowania brakującego .sopliku.

Karthik
źródło
0

Przeszedłem dokładnie ten sam problem ... Rozwiązałem go, uruchamiając następujące polecenia.

ln -s /usr/local/lib/libcrypto.so.1.1 /usr/lib/libcrypto.so.1.1

Spowoduje to utworzenie softlink i możesz zacząć.

Faheem
źródło
0

To najlepsze rozwiązanie, jakie znalazłem ... inne rozwiązania dostępne w Internecie nie przetrwają ponownego uruchomienia systemu;)

System operacyjny: Ubuntu 16.04

sudo vim /etc/ld.so.conf.d/libc.conf

Skomentuj ustawienia katalogu lib i dodaj dobrą ścieżkę

# libc default configuration

#/usr/local/lib

/usr/lib

Po zakończeniu edycji uruchom to polecenie:

sudo ldconfig

Wtedy będziesz mieć dobre ustawienie, gdy uruchomisz:

ldd / usr / bin / openssl

Przed tą poprawką:

 /usr/bin/openssl: /usr/local/lib/libssl.so.1.0.0: no version information available (required by /usr/bin/openssl)
/usr/bin/openssl: /usr/local/lib/libssl.so.1.0.0: no version information available (required by /usr/bin/openssl)
 /usr/bin/openssl: /usr/local/lib/libssl.so.1.0.0: no version information available (required by /usr/bin/openssl)
/usr/bin/openssl: /usr/local/lib/libcrypto.so.1.0.0: no version information available (required by /usr/bin/openssl)
/usr/bin/openssl: /usr/local/lib/libcrypto.so.1.0.0: no version information available (required by /usr/bin/openssl)
/usr/bin/openssl: /usr/local/lib/libcrypto.so.1.0.0: no version information available (required by /usr/bin/openssl)
/usr/bin/openssl: /usr/local/lib/libcrypto.so.1.0.0: no version information available (required by /usr/bin/openssl)
linux-vdso.so.1 =>  (0x00007ffe6d1e3000)
libssl.so.1.0.0 => /usr/local/lib/libssl.so.1.0.0 (0x00007f8999827000)
libcrypto.so.1.0.0 => /usr/local/lib/libcrypto.so.1.0.0 (0x00007f89993ed000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f8999023000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f8998e1f000)
/lib64/ld-linux-x86-64.so.2 (0x00007f8999a97000)

Po poprawce podałem:

linux-vdso.so.1 =>  (0x00007ffec39bc000)
libssl.so.1.0.0 => /lib/x86_64-linux-gnu/libssl.so.1.0.0 (0x00007f7faad22000)
libcrypto.so.1.0.0 => /lib/x86_64-linux-gnu/libcrypto.so.1.0.0 (0x00007f7faa8dd000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f7faa513000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f7faa30f000)
/lib64/ld-linux-x86-64.so.2 (0x00007f7faaf8b000)
ZEROF
źródło
Dla osób ze ścieżką CentOS uważam, że dobrym plikiem jest /etc/ld.so.conf;), dla jasności.
ZEROF
0

Na CentOS 7 libssl.so.1.1znajduje się w /usr/local/ssl/lib.

Musiałem więc tylko dodać tę ścieżkę do domyślnych lokalizacji, w których dynamiczny moduł ładujący szuka bibliotek. Utworzyłem osobny plik dla mojego pliku binarnego openssl o nazwie openssl-1.1.1c.confw /etc/ld.so.conf.dfolderze:

echo "/usr/local/ssl/lib" > /etc/ld.so.conf.d/openssl-1.1.1c.conf

Teraz działa.

Boris Burkov
źródło
-1

Po zbudowaniu i zainstalowaniu open ssl openssl-1.1.0f naprawiłem ten sam błąd dla lib libssl.so.1.1 tworząc miękkie łącze:

ln -s /usr/local/lib/libssl.so.1.1 /usr/lib/libssl.so.1.1

Rafael
źródło