[3.4 -> 3.5] | [3.5 -> 3.6] | [3.6 -> 3.7] | [3.7 -> 3.8] | [3.8 -> 3.9] | [3.9 -> 4.0] | [4.1 -> 4.2] | [FAQ Index]

Przewodnik po aktualizacji: z 4.0 do 4.1

Uwaga: upgrade jest dostępny tylko z release do release, zalecane jest aby nie opuszczać wydań pośrednich. Nie opuszczaj wersji release.

Jest niezwykle zalecane abyś przeczytał cały dokument i dokładnie zrozumiał proces zanim będziesz usiłował go przeprowadzić. Jeśli zamierzasz działać na krytycznej lub fizycznie odległej maszynie, jest zalecane abyś przetestował ten proces na identycznej, lokalnej maszynie i zweryfikował szanse na powodzenie zanim przystąpisz do krytycznej lub odległej maszyny.

Upgrade to wygodny sposób na utrzymywanie twojego systemu OpenBSD aktualnym z ostatnią aktualną wersją. Jednakże, rezultat w zamierzeniu nie odpowiada dokładnie wynikowi instalacji wyczyść-i-załaduj. W szczególności stare pliki bibliotek, nie są usuwane w procesie aktualizacji, ponieważ mogą być wymagane przez starsze aplikacje które mogą, lecz nie muszą być zaktualizowane w danym momencie. Jeżeli NAPRAWDĘ chcesz pozbyć się tych wszystkich plików, prawdopodobnie lepiej będzie jeśli zainstalujesz wszystko od początku.

Spis treści:

Zanim rozpoczniesz
Upgrade
Ostatnie kroki

Zanim rozpoczniesz

Sprawdź czy wykonywałeś jakichkolwiek modyfikacji twojego kernela. Przykładowo, mogłeś zmodyfikować twoją kartę sieciową by korzystała z innych niż domyślne ustawień, korzystając z config(8). Zapisz te ustawienia, aby je odtworzyć dla nowego jądra w 4.1.

rc.conf: W odróżnieniu od poprzednich wersji zakładamy obecnie, ze plik /etc/rc.conf nie jest edytowany przez użytkownika. Jeżeli wykonywałeś zmiany w swoim pliku /etc/rc.conf przenieś je do /etc/rc.conf.local. Jeżeli NIE MASZ pliku /etc/rc.conf.local po prostu skopiuj swój plik /etc/rc.conf do /etc/rc.conf.local i usuń ostatnią linię z tego skryptu! W przeciwnym wypadku umieść zawartość obecnego pliku rc.conf na początku istniejącego pliku rc.conf.local a następnie usuń ostatnią linię skryptu zanim przejdziesz do dalszych etapów procesu.

Uwagi dla użytkowników systemów opartych na ARM (armish, zaurus): Zmiany w ABI wymagają wykonania nieznacznie różniącego się procesu uaktualnienia jeżeli wykorzystywany jest niestandardowy kernel. Nie wykonuj restartu po instalacji kernela i przed instalacją nowej przestrzeni użytkownika.

Proces uaktualnienia

Uaktualnienie za pomocą kernela instalacyjnego

Jeżeli posiadasz dostęp do konsoli serwera wówczas najłatwiejszą i najbezpieczniejszą metodą na uaktualnienie systemu jest uruchomienie systemu z medium instalacyjnego lub z bsd.rd i wykonanie procesu uaktualnienia który bardzo przypomina proces instalacji systemu. Następnie należy wykonać przedstawione poniżej ostatnie kroki.

Jedną z najłatwiejszych metod na uruchomienie systemu z instalacyjnego kernela jest umieszczenie pliku bsd.rd dla wersji 4.1 w głównym drzewie systemu plików i poinstruowanie boot loadera by wystartował z pliku bsd.rd. Dla amd64 oraz i386 wykonasz to wpisując po prostu "boot bsd.rd" gdy pojawi się znak zachęty boot>.

Uaktualnienie bez kernela instalacyjnego

Nie jest to zalecany proces. Korzystaj z medium instalacyjnego gdy to tylko jest to możliwe!

Czasem ktoś może potrzebować aktualizacji na maszynie na której nie można w łatwy sposób przeprowadzić normalnego procesu aktualizacji. Można wówczas wykonać aktualizację ostrożnie postępując w procesie podobnym do aktualizacji opartej na źródłach:

Umieść pliki instalacyjne w "dobrej" lokalizacji. Upewnij się że posiadasz wystarczającą ilość miejsca!
Wyłącz wszystkie "niebezpieczne" aplikacje ze startu podczas uruchomienia systemu: Może wystąpić moment gdy prawdopodobnie nie będzie włączony PF podczas upgrade systemu, ale twoje aplikacje mogą pracować poprawnie. Każda aplikacja zależna w sensie bezpieczeństwa od PF powinna zostać wyłączona zanim wyłączony zostanie PF i nie powinna być włączana aż do poprawnej weryfikacji działania PF po aktualizacji. Mogą działać również inne aplikacje które chcesz by działały podczas aktualizacji systemu, je również zatrzymaj i wyłącz.
Sprawdź swój kernel: Aczkolwiek większość osób może pominąć ten krok, jeżeli modyfikowałeś swój kernel w wersji 4.0, prawdopodobnie będziesz musiał to zrobić również w wersji 4.1. W szczególności gdy przeprowadzasz proces aktualizacji zdalnie, teraz jest dobry czas, aby się upewnić że nowy kernel będzie działał po restarcie maszyny. Jeśli jakiekolwiek zmiany muszą być wprowadzone do kernela, najbezpieczniejszą rzeczą jaką można zrobić, jest wykonanie tych zmian na lokalnym systemie 4.1. Może to być równie proste jak modyfikacja określonego urządzenia korzystając z config(8), lub może pociągać za sobą rekompilację, jeśli dana opcja nie jest włączona w kernelu GENERIC. Prosimy zobacz FAQ 5 - Tworzenie systemu ze źródeł, zanim zdecydujesz się na rekompilację kernela.
Instalacja nowego kernela(-li)
export RELEASEPATH=/usr/rel # gdzie mają znajdować się pliki cd ${RELEASEPATH} rm /obsd ; ln /bsd /obsd && cp bsd /nbsd && mv /nbsd /bsd cp bsd.rd bsd.mp /
Zauważ dodatkowe polecenia kopiujące pierwotne jądro: wykonywane są aby mieć pewność że zawsze istnieje właściwa kopia jądra na dysku tak, że możliwy będzie boot systemu w sytuacji gdy przytrafi się przerwa w zasilaniu w niewłaściwym momencie lub awaria systemu.
Instalacja nowych plików /etc/firmware: Z uwagi na fakt, że niektóre załadowane fragmenty "firmware" zostały przeniesione z jądra do katalogu /etc/firmware. Dotyczy to wprawdzie tylko użytkowników kilku urządzeń, jednak nie zaszkodzi jak wszyscy wszyscy wykonają ten krok. Aby rozpakować pliki mikrokodu z base41.tgz, jako root użyj polecenia:
cd / tar -C / -xzpf ${RELEASEPATH}/base41.tgz ./etc/firmware
Reboot na nowym jądrze: (użytkownicy ARM-ów powinni pominąć ten krok) Może kusić chęć opuszczenia tego kroku, ale powinien on być wykonany teraz, jak zwykle, nowe jądro uruchomi stare aplikacje przestrzeni użytkownija (takie jak będący wkrótce ważny reboot!), jednak często nowe aplikacje NIE będą działały ze starym jądrem.
Uwaga: Użytkowniky ARM-ów (armish/zaurus) POWINNI pominać ten krok w procesie uaktualnienia.
Instalacja nowych aplikacji przestrzeni użytkownika NIE instaluj teraz etc40.tgz oraz xetc40.tgz, ponieważ proces ten nadpisze twoje aktualne pliki konfiguracyjne!
export RELEASEPATH=/twoja_ścieżka cd / tar xzpf ${RELEASEPATH}/base41.tgz tar xzpf ${RELEASEPATH}/comp41.tgz tar xzpf ${RELEASEPATH}/game41.tgz tar xzpf ${RELEASEPATH}/man41.tgz tar xzpf ${RELEASEPATH}/misc41.tgz tar xzpf ${RELEASEPATH}/xbase41.tgz tar xzpf ${RELEASEPATH}/xfont41.tgz tar xzpf ${RELEASEPATH}/xserv41.tgz tar xzpf ${RELEASEPATH}/xshare41.tgz
Uwaga: nie wszystkie elementy muszą być zainstalowane dla wszystkich aplikacji, jednakże, jeżeli zainstalowałeś dany zbiór orginalnie, powinieneś z pewnością uaktualnić go teraz nowym zbiorem.
Ponadto pliki z /etc są zarządzane oddzielnie, zatem etc41.tgz oraz xetc41.tgz NIE są tutaj rozpakowywane.
Aktualizacja /dev. Nowy plik MAKEDEV zostanie skopiowany do /dev/ podczas instalacji base40.tgz, zatem powinieneś zwyczajnie wykonać poniższe:
cd /dev ./MAKEDEV all
Zaktualizuj /etc jak poniżej.
Reboot

Podczas tego procesu, sendmail(8) może zwrócić pewien błąd podobny do poniższego:


    Nov 1 12:47:05 puffy sm-mta[16733]: filesys_update failed: No such file or dire
    ctory, fs=., avail=-1, blocksize=380204

Wiadomość ta może być bezpiecznie zignorowana, możesz też chcieć zatrzymać sendmail(8)-a na czas aktualizacji.

Ostatnie kroki

1. Aktualizacja `/etc`

Jakkolwiek wykonujesz aktualizację, czy to przez kernel instalacyjny i wykonanie "formalnego" procesu aktualizacji, czy też aktualizację binarną "w-miejsce", musisz wykonać kilka kroków.

Nowi użytkownicy i grupy

Serwisy RIP oraz "HostState" zostały zaimportowane i wymagają utworzenia dodatkowych użytkowników oraz grup. Jako root, dodaj poniższego użytkownika i grupę korzystając z useradd(8):
useradd -u88 -g=uid -c"RIP Daemon" -d/var/empty -s/sbin/nologin _ripd useradd -u89 -g=uid -c"HostState Daemon" -d/var/empty -s/sbin/nologin _hoststated
W ten sposób zostanie jednocześnie dodany użytkownik i odpowiednia grupa. Twoje środowisko pracy może pozwolić ci na skopiowanie/wklejenie tego polecenia.

1.2 - Zmiany w systemie

To nie jest pełna lista zmian jakie nastąpiły pomiędzy wersją 4.0 a 4.1, lecz zestawienie kilku ważnych zmian mogących dotyczyć wielu użytkowników w procesie uaktualnienia systemu. Kompletną listę znajdziesz na stronie plus41.html lub w logach systemu CVS.

domyślne "flags S/SA keep state" w pf.conf(5)
Flagi flags S/SA keep state są obecnie domyślnymi dla "przepuszczających" reguł w pf.conf(5), oraz dodane zostały nowe opcje no state i flags any aby nadpisać zachowanie domyslne. Obecne zestawy reguł powinny się wciąż ładować, jednak ich zachowanie może się nieznacznie zmienić ponieważ obecne zachowanie domyślne jest bardziej restrykcyjne. Zestawy reguł z filtrowaniem bezstanowym (no state) lub wymagające tworzenia stanów dla pakietów pośrednich (flags any) powinny zostać zaktualizowane i jawnie rządać odpowiedniego zachowania.
Ze szczególną uwagą należy podchodzić do interfejsu enc0 ponieważ zmienne stany są potencjalnym problemem w filtrowaniu ruchu IPsec: stany powinny być ograniczone do interfejsu, aby uniknąć przepuszczenia nieszyfrowanego ruchu isakmpd(8) powinien być wyłączony. Zatem wszystkie reguły na interfejsie enc0 powinny mieć jawnie ustawione keep state (if-bound).
Partycje DOS MBR: FreeBSD i NetBSD nie są już wykorzystywane do przechowywania etykiet dysków, i nie są już pod ich kątem przeszukiwane.
W rezultacie dyski z podstawowymi partycjami FreeBSD lub NetBSD nie będą więcej zawierały partycji 'a' utworzonych w "sztucznym" disklabel. Disklabel na takich dyskach będzie przechowywany i ładowany z pierwszego sektora, i w ten sposób może znaleźć przypadkowy disklabel. Skorzystaj z fdisk(8) aby zmienić typ partycji na OpenBSD ('A6') i korzystać z istniejącego disklabel.
amd64, i386, macppc, i mvmeppcnie próbują startować z pierwszej partycji NetBSD w sytuacji gdy nie zostaje znaleziona partycja OpenBSD.
Aby zmienić typ partycji na OpenBSD ('A6') użyj fdisk(8).
Nowy sposób na włączenie procesu accounting-u podczas startu
Aby nakazać włącznie accounting-u podczas startu systemu musisz ustawić nową zmienną w rc.conf "accounting=YES". Istnienie pliku /var/acccount/acct nie powoduje już jego automatycznego startu.
spamd(8) domyślnie działa obecnie w trybie greylistingu
Biorąc pod uwagę, że wcześniej greylisting włączany był poprzez parametr -g obecnie istnienie tej flagi jest zakładane przy starcie. Parametr -b (używana poprzednio do podawania adresu na którym spamd(8) ma nasłuchiwać) może być użyty do uruchomienia spamd tylko w trybie czarnych-list. Nowy parametr -l jest używany do określenia na jakim adresie IP spamd powinien nasłuchiwać.
spamd.conf(5) jest obecnie położony w /etc/mail:
Plik konfiguracyjny spamd.conf(5), który dotychczas położony był w katalogu /etc, został przeniesiony do /etc/mail. Przenieś swój obecny plik konfiguracyjny do /etc/mail aby spamd(8) mogł załadować twoją konfigurację.
MIB sysctl(3) dla sensorów jest obecnie hierarchiczny
MIB sysctl(3) dla sensorów zawiera obecnie nazwę urządzenia sensora a także typ i indeks aktualnego sensora. Zatem, wykonując wcześniej "sysctl hw.sensors" otrzymywałeś coś podobnego do "hw.sensors.12=it0, Temp 1, 25.00 degC", obecnie uzyskasz "hw.sensors.it0.temp0=25.00 degC". Zaktualizuj swój plik konfiguracyjny sensorsd.conf(5) by odpowiadał nowym nazwom czujników.

1.3 - Zmiany w plikach w `/etc`

Musisz rozpakować pliki etc41.tgz do tymczasowej lokalizacji:

cd /tmp tar -C /tmp -xzpf ${RELEASEPATH}/etc41.tgz

Pliki które prawdopodobnie mogą być skopiowane z etc41.tgz "w takiej postaci w jakiej są":

etc/daily etc/disktab etc/hoststated.conf etc/magic etc/monthly etc/netstart etc/rc etc/rc.conf etc/ripd.conf etc/sasyncd.conf etc/security etc/weekly etc/mail/Makefile etc/mail/localhost.cf etc/mail/sendmail.cf etc/mail/submit.cf etc/mail/spamd.conf etc/mtree/* var/www/conf/bgplg.css var/www/conf/bgplg.foot var/www/conf/bgplg.head var/www/htdocs/bgplg/*

Zauważ, że JEST możliwe by lokalnie zmodyfikować te pliki, jeżeli to było zrobione, będzie konieczne ręczne scalenie. Zwróć szczególną uwagę na mail/* jeżeli używasz czegoś innego niż domyślna konfiguracja Sendmail(8)-a. Tutaj są linie kopiuj/wklej do kopiowania tych plików, zakładając że rozpakowałeś etc41.tgz w miejscu sugerowanym powyżej:

cd /tmp/etc cp daily disktab hoststated.conf magic monthly netstart rc rc.conf ripd.conf sasyncd.conf security weekly /etc cp mtree/* /etc/mtree/ cp mail/Makefile mail/localhost.cf mail/submit.cf /etc/mail cp mail/sendmail.cf /etc/mail # Uważaj na ten plik!! cp mail/spamd.conf /etc/mail # LUB ... mv /etc/spamd.conf /etc/mail cd /tmp/var/www cp conf/bgplg.css conf/bgplg.foot conf/bgplg.head /var/www/conf mkdir /var/www/htdocs/bgplg cp htdocs/bgplg/* /var/www/htdocs/bgplg/

Pliki które muszą być ręcznie włączone, uwzględniając lokalne zmiany w nich wykonane, jeżeli były modyfikowane z domyślnych, w przeciwnym wypadku, po prostu również je skopiuj:

etc/changelist etc/ftpusers etc/login.conf etc/newsyslog.conf etc/services etc/sysctl.conf etc/mail/aliases var/cron/tabs/root

Zmiany w tych plikach znajdują się w tym patch-u. Możesz spróbować z niego skorzystać wykonując jako root nastepujące polecenie:

cd / patch -C -p0 < upgrade41.patch

Spowoduje to przetestowanie łatki jak dobrze pasuje do TWOJEGO systemu, aby ją zastosować opuść opcję "-C". Zauważ że w sytuacji w której posiadasz zmodyfikowane pliki, lub pliki które nie są wystarczająco aktualne, a także w sytuacji w której zostały zaktualizowane z wersji "snapshot" 4.0, pliki te mogą nie zostać "czysto" zaakceptowane. W takiej sytuacji, będziesz musiał ręcznie uwzględnić zmiany. Prosimy wykonaj test tego procesu zanim się na niego zdecydujesz dla maszyny do której nie możesz się w łatwy sposób dostać.

W poniższych plikach zostały wprowadzone pewne zmiany na które należy zwrócić uwagę, lecz nie mogą być bezpośrednio skopiowane lub scalone (przykładowo jeżeli korzystasz z pf.conf, przyjżyj się sugerowanej zmianie strategii i zdecyduj czy jest właściwa dla twoich potrzeb).

etc/hostapd.conf etc/pf.conf etc/sensorsd.conf

Ostatecznie skorzystaj z newaliases(8) by zaktualizowac bazę aliasów oraz z mtree(8) by utworzyć jakiekolwiek nowe katalogi:

newaliases mtree -qdef /etc/mtree/4.4BSD.dist -p / -u

2. Sprawdzanie kernela

Uwaga: większość osób może pominąć ten krok!

Jeżeli podążałeś za instrukcjami aktualizacji bez medium instalacyjnego, już wykonałeś ten krok. Jednakże, jeśli korzystałeś z medium instalacyjnego, i posiadałeś zmodyfikowany kernel w 4.0, istnieje prawdopodobieństwo, że będziesz musiał zmodyfikować kernel w 4.1. Może to być równie proste jak modyfikacja określonego urządzenia korzystając z config(8), lub może pociągać za sobą rekompilację, jeśli dana opcja nie jest włączona w kernelu GENERIC. Prosimy zobacz FAQ 5 - Tworzenie systemu ze źródeł, zanim zdecydujesz się na rekompilację kernela.

3. Aktualizacja pakietów

Jeśli instalowałeś jakiekolwiek pakiety w twoim systemie, powinieneś zaktualizować je po zakończeniu aktualizacji systemu bazowego. Jednakże pamiętaj że niektóre pakiety mogą wymagać dalszej konfiguracji przed i/lub po uaktualnieniu pakietu. Sprawdź informacje dotyczące aktualizacji koniecznych pakietów.

Poniższe pakiety znane są z problemów jakie mogą wystąpić podczas ich aktualizacji dla znacznej grupy użytkowników. Fakt, że dany pakiet nie występuje na tej liście nie oznacza że jego uaktualnienie będzie proste. Musisz odrobić "pracę domową" dla aplikacji których UŻYWASZ.

Postgresql: musisz zrzucić bazę danych przed uaktualnieniem i pożniej ją przywrócić

Narzędzia obsługi pakietów pozwalają na aktualizację "w miejsce", poprzez użycie pkg_add -u. Przykładowo, aby zaktualizować twoje pakiety, upewnij się ze PKG_PATH wskazuje na katalog z pakietami dla 4.1 na twoim CD lub najbliższym mirrorze FTP (przyp. tłum. lub na katalog na lokalnym dysku), i użyj polecenia podobnego to poniższego

# pkg_add -ui -F update -F updatedepends

gdzie opcja -u wskazuje tryb aktualizacji, -i określa tryb interaktywny, więc pkg_add będzie zwracał się do ciebie gdy napotka niejasność. Przeczytaj stronę manuala dla pkg_add(1) oraz dokument FAQ dotyczący zarządzania pakietami.