To pytanie jest otwarte, ale chciałbym przeprowadzić konstruktywną i pomocną dyskusję na ten temat.
Aby wyjaśnić pytanie: na serwerze z CentOS 7 (lub inną dystrybucją / wersją Linuksa) Czy najlepiej trzymać się wersji pakietu w repozytorium Base / EPEL, czy też jest w porządku, aby uzyskać najnowszą stabilną wersję utworzyć witrynę pakietu? W tym przypadku odnoszę się konkretnie do pakietów takich jak nginx, MariaDB i PHP 7. Na przykład, jakie byłyby zalety i wady instalacji nginx 1.8.0 w wersji EPEL 1.6.3? Czy występują różnice w wydajności lub zagrożenia bezpieczeństwa?
Wszelkie dyskusje i doświadczenia są mile widziane, spróbuj zacytować zasoby i fakty.
linux
centos
package-management
GiggleSquid
źródło
źródło
/usr/local
podobnej wersji lub podobnej.Odpowiedzi:
Zasadniczo bardzo staram się używać domyślnych pakietów systemowych.
Jednak czasami nie jest to możliwe. Aby dokonać wykształconego wyboru, musiałeś odpowiedzieć na następujące pytania:
źródło
Odpowiedzi Matthew Ife i shodanshoka dotyczą ogólnie zagadnień, ale chcę zająć się twoją szczególną troską, umieszczając je w odpowiednim kontekście, ponieważ dokładnie takimi systemami zarządzam.
Moja obecna wersja do wdrażania aplikacji internetowych PHP / MySQL to:
Najpierw zastanówmy się, dlaczego wybieramy konkretną dystrybucję lub zestaw pakietów. Albo cenimy stabilność w porównaniu z najnowszymi funkcjami, albo cenimy najnowsze funkcje w porównaniu ze stabilnością. Zasadniczo nie można mieć obu w tej samej dystrybucji, ponieważ oprogramowanie stabilizujące wymaga czasu na naprawę błędów, a dodanie nowych funkcji wprowadza błędy, a tym samym niestabilność.
Zasadniczo chcę, aby system operacyjny, na którym działa aplikacja, był jak najbardziej stabilny, ale z odpowiednio nowoczesnym zestawem funkcji. Dlatego wybiorę CentOS 7 zamiast CentOS 6, który jest dość stary w tym momencie i chociaż będzie działał , nie ma już tyle czasu w cyklu życia wsparcia, więc nie wykorzystam go do nowego projektu .
Potem jednak natknąłem się na problem polegający na tym, że wersja nginx zawarta w CentOS była zbyt stara i nie zawierała niektórych wymaganych funkcji i poprawek błędów. Poszedłem więc szukać alternatywnych pakietów i odkryłem, że nginx.org dystrybuuje własne. Przełączyłem się na nie prawie natychmiast i znalazłem je idealnie stabilne na dłuższą metę.
Potem jest PHP. Wiem z historii, że wersja PHP dostarczana z CentOS będzie jedyną wersją, jaką kiedykolwiek dostanie, i będzie otrzymywać tylko aktualizacje bezpieczeństwa; brak nowych funkcji lub poprawek błędów. Tak więc, gdy przestanie być obsługiwany w górę, ostatecznie nie będę mógł uruchamiać nowoczesnych aplikacji PHP, jeśli użyję tych pakietów. Dlatego należy je również wymienić.
Z długiego doświadczenia nauczyłem się, że najlepiej śledzić wydania poprawek za pomocą PHP, a nie tylko zawieszać się w jednym punkcie i pobierać tylko poprawki bezpieczeństwa, ponieważ uruchamiane przeze mnie aplikacje internetowe również będą aktualizowane i będą potrzebować tych poprawek. Więc po przeanalizowaniu wielu różnych zestawów pakietów PHP, zdecydowałem się na pacmaki remi. Remi jest pracownikiem Red Hata i jest również odpowiedzialny za pakiety PHP w RHEL / CentOS. Wiem, że jego paczki będą wysokiej jakości i tak było. Są to zamienniki dla pakietów systemowych i działają idealnie.
Wreszcie docieramy do MariaDB. Państwo może wybrać, aby zachować tu pakiety systemowe i cierpią żadnych niepokojących objawów. Zdecydowałem się przejść na pakiety MariaDB 10.0 (a wkrótce przejdę do 10.1), aby skorzystać z TokuDB i niektórych innych ulepszeń wydajności niedostępnych w wersji 5.5 dostarczanej z CentOS, i dla których nigdy nie będzie otrzymywać większych aktualizacji.
Ogólnie potrzebujesz stabilności w systemie podstawowym, ale aplikacje internetowe zmieniają się znacznie szybciej niż, powiedzmy, oprogramowanie biznesowe, a Twój serwer będzie musiał nadążyć. Dlatego wybrałem ukierunkowane punkty, w których aktualizacja pakietów przyniesie wyraźne korzyści przy niewielkim dodatkowym obciążeniu administracyjnym (czyli pracy).
źródło
Krótka odpowiedź brzmi: zawsze używaj danych dostarczonych przez repozytoria systemowe. Bądź bardzo ostrożny co ty repozytoriów należy instalować zbyt. Niektóre są po prostu złe.
Nie powinieneś nadpisywać pakietów systemowych nowszymi wersjami, Redhat jest zaprojektowany i starannie opracowany i możesz skończyć z dziwnymi błędami lub problemami.
Niektóre rzeczy do rozważenia i uważania, które mogą powodować problemy, to:
php
pakiet został umieszczony w systemie, ale nie zaktualizowałempear
pakietu, który wprowadził problemy.Nigdy nie buduj pakietów ze źródła i nie instaluj ich na wierzchu pakietów, które tam są. To łamie integralność pakietu systemowego, co może prowadzić do dziwnych problemów ABI, takich jak odbieranie
unresolved symbol
lubundefined reference
wiadomości. Bardzo ważne jest, aby system utrzymywał wiarygodny i dokładny indeks tego, jakie oprogramowanie zostało wdrożone w danym systemie, aby upewnić się, że wszystko działa ze sobą poprawnie, dlatego właśnie używamy RPM.Realnym (i pobłogosławionym przez Redhata) sposobem rozwiązania tego problemu jest użycie kolekcji oprogramowania.
www.softwarecollections.org
Instaluje oprogramowanie i jego „nowe” zależności we własnym katalogu głównym. Może to nieco utrudnić zastosowanie pakietu w środowisku, ale chroni system przed dziwnymi błędami lub problemami. Instaluje również pakiety we własnej przestrzeni nazw, umożliwiając równoległe instalowanie wielu wersji pakietu.
Witryna zawiera instrukcje instalacji i aktywacji tych pakietów, zawiera większość tego, czego brakuje ludziom w starszych wersjach CentOS i Redhat (w szczególności EL6). Niektóre rzeczy, z których z powodzeniem korzystałem na tej stronie.
Zauważ, że twoim domyślnym stanowiskiem w tej sprawie nie powinno być dostosowywanie się do tego, co popychają repozytoria Redhat. Zamiast tego dokonaj oceny, czy naprawdę potrzebujesz zaktualizowanej wersji pakietu, w szczególności jakie są twoje specyficzne wymagania, jakie problemy należy naprawić i jakie ryzyko to wprowadza.
Zasadą ogólną jest to, że jeśli ciągle potrzebujesz zaktualizowanego oprogramowania i / lub potrzebujesz wielu równoległych wersji tych samych pakietów, aby wszystko działało, zazwyczaj oznacza to, że robisz coś źle.
źródło
nginx
jest jednym z takich pakietów typu „wszystko w jednym”. Ale w szczególnościhttpd
(zależności libapr) imysql
(zależności libmysqlclient) nie są. Złe aktualizacje obu tych pakietów powodowały błędy w przeszłościpython
iphp
dla mnie w przeszłości. Problem w tym, że nie jest łatwo wiedzieć, w jaki sposób jedna paczka wchodzi w interakcje z inną, chyba że wiesz, czego szukać (tłumaczenie: zostało wcześniej przez nią wypalone).