Nie jesteś zalogowany.
Jeśli nie posiadasz konta, zarejestruj je już teraz! Pozwoli Ci ono w pełni korzystać z naszego serwisu. Spamerom dziękujemy!
Prosimy o pomoc dla małej Julki — przekaż 1% podatku na Fundacji Dzieciom zdazyć z Pomocą.
Więcej informacji na dug.net.pl/pomagamy/.
Na VPS z KVM mam Debiana 8. Chciałem uaktualnić libssl do wersji wymaganej przez skrypty, więc ściągnąłem źródła z testing i zrobiłem paczki. Nie chciałem instalować bezpośrednio ze Stretcha, bo oni jadą na gcc 5.X. Naiwnie myślałem, że po dpkg -i libssl uaktualni się do najnowszej wersji. No ale niby dlaczego miało się uaktualnić, skoro mają inną nazwę pakietu. W efekcie uaktualniło się libssl-dev i openssl, no i mam 2 wersje libssl (1.0.2 i 1.0.0).
Aplikacje zainstalowane wcześniej korzystają z libssl1.0.0, np:
$ ldd /usr/bin/mysql ... libssl.so.1.0.0 => /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0 (0x00007fe34702a000) libcrypto.so.1.0.0 => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0 (0x00007fe346c2f000)
Teraz domyślnie jest ustawiona wersja 1.0.2
$ openssl version OpenSSL 1.0.2e 3 Dec 2015
Teraz chciałem zainstalować nowszą wersję nginx, która właśnie wymaga libssl1.0.2.
Jestem raczej cienki w temacie ssl, więc mam pytanie, czy dwie wersje libssl w systemie są do zaakceptowania? Generalnie nie należy się przejmować występowaniem kilku wersji bibliotek, ale libssl jest biblioteką szczególną – stąd moje pytanie. Ważne dla mnie, bo chciałem też zainstalować certyfikat od Let's Encrypt.
Offline
logan@toshiba:~$ dpkg -l | grep libssl ii libssl1.0.0:amd64 1.0.1k-3+deb8u2 amd64 Secure Sockets Layer toolkit - shared libraries ii libssl1.0.0:i386 1.0.1k-3+deb8u2 i386 Secure Sockets Layer toolkit - shared libraries
Tu mam 1.0.1, nie 1.0.0.
logan@toshiba:~$ dpkg -L libssl1.0.0:amd64 /. /usr /usr/lib /usr/lib/x86_64-linux-gnu /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0 /usr/lib/x86_64-linux-gnu/openssl-1.0.0 /usr/lib/x86_64-linux-gnu/openssl-1.0.0/engines /usr/lib/x86_64-linux-gnu/openssl-1.0.0/engines/libatalla.so /usr/lib/x86_64-linux-gnu/openssl-1.0.0/engines/libgmp.so /usr/lib/x86_64-linux-gnu/openssl-1.0.0/engines/libchil.so /usr/lib/x86_64-linux-gnu/openssl-1.0.0/engines/libubsec.so /usr/lib/x86_64-linux-gnu/openssl-1.0.0/engines/libsureware.so /usr/lib/x86_64-linux-gnu/openssl-1.0.0/engines/libpadlock.so /usr/lib/x86_64-linux-gnu/openssl-1.0.0/engines/libgost.so /usr/lib/x86_64-linux-gnu/openssl-1.0.0/engines/libaep.so /usr/lib/x86_64-linux-gnu/openssl-1.0.0/engines/libcswift.so /usr/lib/x86_64-linux-gnu/openssl-1.0.0/engines/lib4758cca.so /usr/lib/x86_64-linux-gnu/openssl-1.0.0/engines/libcapi.so /usr/lib/x86_64-linux-gnu/openssl-1.0.0/engines/libnuron.so /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0 /usr/share /usr/share/doc /usr/share/doc/libssl1.0.0 /usr/share/doc/libssl1.0.0/changelog.gz /usr/share/doc/libssl1.0.0/changelog.Debian.gz /usr/share/doc/libssl1.0.0/copyright
Idąc za tym, dwie wersje są do zaakceptowania. Z ciekawości zerknąłem sobie do zależności i libssl nie jest wymagany (i jednocześnie nie wymaga) gcc. Moim zdaniem, mógłbyś dodać repo z testinga i wrzucić tamtejszą wersją bez kompilacji. Dwie wersje moim zdaniem nie powinny ze sobą w żaden sposób kolidować, ale niech mnie ktoś poprawi.
Offline
Dziękuję za rzeczową odpowiedź. Chcąc mieć aktualny zestaw webowy doszedłem jednak do wniosku, że łatwiej, i chyba bezpieczniej, będzie przejść na Testing, zamiast ręcznie przerabiać Stable. Tak więc Stretch już hula na serwerze i tylko czas pokaże, czy miałem rację.
Offline
Od paru lat używam testinga na serwerach, do tej pory żadnych problemów nie miałem.
Offline
mati75 napisał(-a):
Od paru lat używam testinga na serwerach, do tej pory żadnych problemów nie miałem.
A ja sida w domu, problemów nie ma ale czasami trzeba cofnąć konkretną paczkę do wersji z testinga. Po kilku dniach można spokojnie zaktualizować, bo deweloperzy poprawią co trzeba (pod warunkiem, że ktoś zgłosi problem).
Offline
stretch i sid na pewno błędnie działają na openvz, ale ta pseudo wirtualizacja pomału odchodzi. Można poczytać na grupie debian-devel o tym.
Offline
mati75 napisał(-a):
stretch i sid na pewno błędnie działają na openvz, ale ta pseudo wirtualizacja pomału odchodzi. Można poczytać na grupie debian-devel o tym.
OpenVZ to nie jest żadna wirtualizacja, tylko chroot na sterydach.
Wirtualizacja na Linuxie to XEN albo KVM, a w klasie chrootów na sterydach liderem jest teraz LXC.
OpenVZ z resztą skończył się na jaju 2.6.32 - a to już ostatecznie go dyskwalifikuje, bo nikt normalny przez 10 lat nie będzie utrzymywał wsparcia dla 2.6.32, kiedy w vaniliowym jaju ma dużo lepsze i bardziej uniwersalne narzędzia.
Pozdro
Ostatnio edytowany przez Jacekalex (2015-12-23 19:35:28)
Offline
@Jackalex
A, to dobrze, że sobie dałem spokój z OpenVZ. Chodziło szybko, ale nie idzie nic nowego na tym postawić. Tylko się dziwię, że jeszcze tyle tego skansenu chodzi. Teraz mam KVM na ssd od Prometeusa. Zastanawiałem się przez chwilę jaki system plików zastosować. W końcu wybór zawężył się do ext4 i xfs. Zastosowałem ext4, choć może xfs jest odrobinę szybszy na ssd. Podobno też logical volumes coś dają, ale ja tego nie rozumiem, jak dodatkowa warstwa może coś usprawniać? Może chodzi o to, że logical volumes mają być na hoście? Jeszcze jedno zapytam – słyszeliście, żeby ktoś wyłączał journal na serwerze? Podobno przyspieszenie na KVM jest znaczne. Ale to tylko tak z ciekawości pytam, bo nie mam zamiaru nic takiego szybko wdrażać.
Offline
Skansenu tyle chodzi dzięki RHEL/CentOS 6 :P Tam jajo jest dostatecznie archiwalne do robienia takich szaleństw
Offline
2487
Ostatnio edytowany przez uzytkownikubunt (2016-12-01 01:29:40)
Offline