Korzystam z FreeBSD od około 5 lat - serwer / komputer stacjonarny - i mam tendencję do przyjmowania apt-get / yum upgrade wszystkich nawyków razem ze mną (administruję również skrzynkami Debian / RHEL / Cent - wiem, że wiem ... powinien być bardziej wymagający bez względu na platformę). Zwykle jest to:

portsnap fetch
portsnap update
portmanager -u

Do portów

Czasami następuje:

freebsd-update fetch
freebsd-update install

Dla systemu ... itd. Potem po prostu posprzątaj wszelkie bałagany później ... jeśli się pojawią.

Zdaję sobie sprawę, że jest to dość przesadny sposób na zrobienie czegoś poza BSD. Jaka jest twoja filozofia dla swoich skrzynek BSD? Czy uruchamiasz portaudit / portversion - sprawdź dane wyjściowe, a następnie zaktualizuj (dokonaj deinstalacji ... itd.) Po starannym rozważeniu?

Przyznaję, że jestem całkiem nowy w OpenBSD. Widzę, że od czasu do czasu przeglądam drzewo portów, uruchamiam skrypt „nieaktualny”, a następnie aktualizuję krytyczne porty --- ale zostawiam jądro / pliki binarne w spokoju i aktualizuję co sześć miesięcy. Czy łatasz / rekompilujesz / przebudowujesz jądro, pliki binarne --- dlaczego?

Jakie jest konserwatywne podejście do krytycznych usług (w miarę krytycznych - to nie jest bank ani szpital) na urządzeniach BSD? Czy używasz podobnego podejścia do swoich urządzeń Linux? Zasadniczo nie dotykam jądra na żadnym serwerze, chyba że alarm bezpieczeństwa wywołał przerażenie w mojej duszy.

Tak, jest mnóstwo dokumentów i książek - co wy właściwie robicie? Zakładając, że znamy podstawy - jaka jest mądrość? Przypadki użycia / środowiska i scenariusze są różne, podobnie jak stawki / interesariusze / użytkownicy. Książki i strony podręcznika dotyczą narzędzi i zastosowań, ale nie mają praktycznego zastosowania. Poleć książkę, jeśli znasz taką, która ją obejmuje!

Dziękuje za przeczytanie!

Bubnoff

Wnioski ~ Dziękujemy wszystkim, którzy poświęcili czas na odpowiedź na ten post. Moją ogólną strategią jest teraz podążanie za listami adresowymi dla obu BSD i bycie bardziej selektywnym / wymagającym od aktualizacji, niż ja w przeszłości.

FreeBSD ~ Portaudit to dobra odpowiedź. Sądzę, że dzięki listom mailingowym i starannym audytom będzie to dobrze służyć. Interesujące jest to, że nacisk na porty między wersami OpenBSD FreeBSD jest różny.

OpenBSD ~ podąży za listą mailingową i użyje narzędzi pakietu (pkg_info i pkg_add -u), jeśli zostanie to uznane za krytyczne. Uaktualnienia: Wygląda na to, że musisz uaktualnić przynajmniej raz w roku. Obsługują najnowszą wersję plus jedno z tyłu - w tej chwili jest to 4.8 i 4.7.

Dzięki jeszcze raz.

Należy sprawdzać zainstalowane porty co do wrażliwych pakietów co jakiś czas: portaudit -Fda

Nie jestem pewien, czy istnieje specyficzny „sposób BSD” na robienie tego typu rzeczy. Wszystko sprowadza się do wiedzy o tym, co jest aktualizowane i testowane - ogólne rzeczy dotyczące sysadmin. Na szczęście freebsd-update i portnap sprawiają, że „wiedza o tym” jest dość trywialna.

Ale skoro poprosiłeś o szczegóły, w przeszłości, kiedy zgromadziłem dużą liczbę maszyn FreeBSD, wszystkie były węzłami w klastrze. Samodzielne maszyny nie różniłyby się tak bardzo od tego, ale wydaje mi się, że można by to zrobić w nieco niejasny sposób dla swoich usług produkcyjnych. W końcu zawsze dobrym pomysłem jest posiadanie oddzielnych środowisk testowych i produkcyjnych.

W sytuacji klastrowej:

• Każda maszyna zamontowała porty / usr / src , / usr / obj i / usr / porty przez NFS.
• W zależności od budżetu możesz mieć maszynę pomostową / kompilacji lub wyznaczyć węzeł klastra jako węzeł pomostowy / kompilacji.
• Węzeł pomostowy miał inną kopię / usr / porty
• Węzeł pomostowy aktualizowałby src-all i porty-all za pośrednictwem cvsup każdej nocy
• W razie potrzeby aktualizuje, węzeł inscenizacja zostanie wycofany z obrotu i buildworld , installworld i portupgrade będzie działać.
• Węzeł pomostowy zostałby dokładnie przetestowany.
• Porty / usr / zostaną zamienione na hoście NFS
• Każdy węzeł klastra zostanie obrócony z run installworld i portupgrade , przetestował i obracany widok.

Oczywiście miało to miejsce zarówno w przypadku aktualizacji systemu, jak i portów, ale procedura była wystarczająco podobna, aktualizując tylko pakiety lub system.

Jeśli odbywa się to na dwóch komputerach, każda z nich może być na zmianę produkcyjna lub etapowa, lub po prostu zaktualizować produkcję z etapowego.

Możesz śledzić zmiany z dzienników cvs i sprawdzać, czy otrzymałeś określone aktualizacje w / usr / src / UPDATING i / usr / porty / UPDATING , które są automatycznie aktualizowane z cvsup .

Jeśli nie używasz cvsup (a obecnie jest mniej powodów), musisz po prostu znaleźć inny sposób, aby śledzić, jakie aktualizacje chcesz. Możesz wysłać do siebie listę zmian, które freebsd-update chce wprowadzić dla siebie, i miej oko na stronie błędu bezpieczeństwa.

Filozofia aktualizacji OpenBSD

To jest moje podejście do aktualizacji OpenBSD

Bądź na bieżąco o wydaniach / poprawkach zabezpieczeń dla:

• BASE (tzn. Rzeczy, które zespół deweloperów OpenBSD przechowuje w drzewie źródeł)
• Pakiety / porty (tj. Aplikacje zainstalowane na BASE)

Procedury aktualizacji:

• Ta sama wersja systemu operacyjnego
• Nowa wersja systemu operacyjnego

BAZA

za. Postępuj zgodnie z odpowiednimi listami adresowymi - obserwuję codzienne streszczenia squish.net, a także ogólny kierunek pokazany na listach dyskusyjnych Tech i Misc.

b. Śledź związane z Unix strony z ogłoszeniami o bezpieczeństwie / listy mailingowe.

do. Zachowaj lokalną kopię CVS przy użyciu cvsync

re. Zbuduj powyższe wersje STABILNE

Po opublikowaniu aktualizacji zabezpieczeń oceniamy rzeczywisty problem bezpieczeństwa z profilem komputerów z tą wersją systemu operacyjnego / podatności. Jeśli luka jest istotna, przechodzimy przez „tę samą procedurę aktualizacji wersji”.

Pakiety / Porty

Trudniej jest śledzić aktualizacje zabezpieczeń portów / pakietów, ale jeśli jest to wystarczająco ważne, aby być w naszej infrastrukturze, ważne jest, aby śledzić w podobny sposób jak BASE.

• Wejdź na listę mailingową dla konkretnej aplikacji (naszym obowiązkiem jest śledzenie zmian wcześniejszych, niezależnie od projektu OpenBSD).

• Wejdź na listy dystrybucyjne zabezpieczeń, takie jak CERT, które publikują informacje o lukach w zabezpieczeniach aplikacji itp.

Procedury aktualizacji

Oczywiście zbuduj i przetestuj procedurę instalacji na oddzielnym sprzęcie (lub maszynie wirtualnej) przed wykonaniem jej na maszynach produkcyjnych. Na szczęście dla nas mamy nadmiarowe hosty dla wielu rzeczy i dlatego możemy je wdrażać przy minimalnym przestoju usług. Ponieważ OpenBSD obsługuje szeroką gamę sprzętu, możemy wypuszczać sprzęt klasy serwerowej dla naszych głównych komputerów, a niższych komputerów stacjonarnych jako naszych redundantnych hostów (lub po prostu budujemy tymczasowe pole do wypełnienia dla głównego komputera podczas cyklu aktualizacji).

Nasze procedury aktualizacji są silnie uzależnione od używania systemu portów / pakietów dla oprogramowania innego niż BASE. Dwa hosty, na których instalujemy oprogramowanie ze źródła, utrudniają aktualizację między aktualizacjami wersji systemu operacyjnego.

Ta sama aktualizacja systemu operacyjnego

W przypadku BASE OS nadal odnosimy sukcesy po prostu instalując nowe pliki binarne na starych. Najlepiej jest wykonać kopię zapasową wszystkich plików konfiguracyjnych / danych systemu operacyjnego i aplikacji, sformatować i ponownie zainstalować poprawiony system operacyjny oraz ponownie zainstalować pakiety (zachowując oryginalne dane)

W naszych wdrożonych hostach OpenBSD (30+) i doświadczeniu tworzenie kopii zapasowej konfiguracji i danych nie jest trudne. W naszych zaporach wszystkie dane znajdują się w plikach konfiguracyjnych i logach.

W przypadku portów / pakietów - gdy zmiany są proste, modyfikujemy własny port i na tej podstawie budujemy pakiet. Posiadanie zaktualizowanego portu upraszcza powyższy proces.

Nowa aktualizacja systemu operacyjnego

Pomiędzy wersjami systemu operacyjnego instalujemy wszystko od szkicu.

Jestem pewien, że dostępna jest wystarczająca dokumentacja dla tego procesu, ale zasadniczo budujemy maszynę referencyjną o tej samej konfiguracji co system, który można „wymienić”. Przeprowadź te same testy wymagane przed wdrożeniem hosta.

Wykonujemy kopię zapasową konfiguracji z hosta referencyjnego i instalujemy OpenBSD na hoście produkcyjnym, przywracając na nim „zweryfikowaną” konfigurację (ponownie uruchamiając te same testy sprawdzania poprawności).

W przypadku OpenBSD przynajmniej:

• pakiety są produktem końcowym systemu portów; powinno być niewiele, jeśli trzeba, biegać z portami.
• -release i -stable jest (przeważnie) zamrożone w czasie, z kilkoma aktualizacjami od czasu do czasu.
• -prąd jest regularnie aktualizowany. Jeśli naprawdę potrzebujesz aktualnych pakietów, jest to odpowiedni sposób.
• zachowaj spójność: -release / -stable systemy przyklejają się z -release / -stable pakiety ...- obecne systemy działają -current pakiety

FAQ 15, wszystko o portach i pakietach

Jeśli nie ma problemu z bezpieczeństwem lub błędu blokującego funkcjonalność, zostaw to w spokoju. Sprawdź aktualizacje, może co 3-6 miesięcy, aby nie pozostać zbyt daleko w tyle, ale w przeciwnym razie zostaw rzeczy w spokoju.

Jeśli nie jest zepsuty, nie naprawiaj go.

Wolę używać portupgradedo aktualizacji portów i robię to tylko wtedy , gdy jest to absolutnie konieczne , np. Gdy w porcie zostanie wykryta podatność lub wymagana jest nowa funkcjonalność.

Jeśli chodzi o aktualizację systemu, zwykle przebudowuję ze źródeł z make buildworld. Nigdy nie miałem żadnych problemów z tym podejściem.