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

Upgrade Guide: z 3.8 do 3.9

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

Jeżeli twoja maszyna posiada karty sieciowe korzystające ze sterownika le(4), prawdopodobnie został on zamieniony przez sterownik pcn(4). ZANIM rozpoczniesz aktualizację, skopiuj twoje plik(i) /etc/hostname.le* do odpowiednich plików /etc/hostname.pcn*, w przeciwnym wypadku możesz nie mieć działającej sieci w trakcie aktualizacji i po jej zakończeniu.

Ze względu na dodanie debugera, znacząco wzrosły rozmiary plików bibliotek. Przykładowo, dla platformy i386, rozmiar zajmowany przez katalog /usr/lib/ wzrósł z 47.7MB w 3.8 do 209MB w 3.9. Upewnij się, że masz wystarczającą ilość dostępnego miejsca zanim rozpoczniesz aktualizację.

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 3.9.

Zmienił się format pfsync(4), zatem nie może obsługiwać stanów pomiędzy maszynami z 3.8 a maszynami z 3.9. Niepasujące systemy utracą wszystkie połączenia w momencie gdy przełączysz maszynę podstawową, ponieważ stany nie będą przesyłane pomiędzy systemami. Możesz to zminimalizować wykonując najpierw aktualizację maszyn zapasowych, dzięki temu będziesz miał tylko jedną utratę aktywnych stanów.

Użytkownicy carp(4), korzystający z więcej niż jednego adresu na pojedyńczym interfejsie carp(4), mogą doświadczyć innego wydarzenia podczas aktualizacji: interfejsy są obecnie sortowane według adresów, zatem posiadanie aliasów w takim samym porządku, nie jest aż tak krytyczne jak w przeszłości. Oznacza to jednak, że mogą wystąpić problemy pomiędzy starymi i nowymi systemami. Jeżeli to konieczne, aby obejść ten problem, na starszych systemach możesz sortować aliasy ręcznie.

Zmienił się ftp-proxy(8), (jak to opisano poniżej), zatem zmian może wymagać twój plik pf.conf(5).

ancontrol(8), został zastąpiony przez dodanie jego funkcjonalności do ifconfig(8). To może mieć wpływ na konfigurację twoich interfejsów sieci bezprzewodowych.

Upgrade

Upgrade z medium instalacyjnego

Najłatwiejszą i najbezpieczniejszą drogą do aktualizacji z plików binarnych jest boot z medium instalacyjnego oraz podążanie za krokami aktualizacji, które są bardzo podobne do procesu instalacji. Później wykonaj ostatnie kroki, jak opisano poniżej.

Upgrade bez medium 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że w łatwy sposób przeprowadzić normalnego procesu aktualizacji. Może 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 3.8, prawdopodobnie będziesz musiał to zrobić również w wersji 3.9. 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 3.9. 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=/twoja_ścieżka 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, jest kilka sterowników, które przestaną działać jeśli nie będzie dostępnego pliku mikrokodu podczas startu nowego jądra. Dotyczy to wprawdzie tylko użytkowników kilku urządzeń, jednak nie zaszkodzi jak wszyscy wszyscy wykonają ten krok. Aby rozpakować pliki mikrokodu z base39.tgz, jako root użyj polecenia:
cd / tar xzpf ${RELEASEPATH}/base39.tgz "*etc/firmware/*"
Reboot na nowym jądrze 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.
Instalacja nowych aplikacji przestrzeni użytkownika NIE instaluj teraz etc39.tgz oraz xetc39.tgz, ponieważ proces ten nadpisze twoje aktualne pliki konfiguracyjne!
export RELEASEPATH=/twoja_ścieżka cd / tar xzpf ${RELEASEPATH}/base39.tgz tar xzpf ${RELEASEPATH}/comp39.tgz tar xzpf ${RELEASEPATH}/game39.tgz tar xzpf ${RELEASEPATH}/man39.tgz tar xzpf ${RELEASEPATH}/misc39.tgz tar xzpf ${RELEASEPATH}/xbase39.tgz tar xzpf ${RELEASEPATH}/xfont39.tgz tar xzpf ${RELEASEPATH}/xserv39.tgz tar xzpf ${RELEASEPATH}/xshare39.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 etc39.tgz oraz xetc39.tgz NIE są tutaj rozpakowywane.
Aktualizacja /dev. Nowy plik MAKEDEV zostanie skopiowany do /dev/ podczas instalacji base39.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 media instalacyjne i wykonanie "formalnego" procesu aktualizacji, czy też aktualizację binarną "w-miejsce", musisz wykonać kilka kroków.

Nowi użytkownicy i grupy

nie ma nowych użytkowników lub grup

1.2 - Zmiany w systemie

ftp-proxy ftp-proxy(8) został zastąpiony przez narzędzie wcześniej nazywane pftpx. Nowy ftp-proxy działa samodzielnie a nie, jak poprzednio, z inetd.conf(5) Będziesz musiał zaktualizować /etc/inetd.conf, by nie wywoływał więcej ftp-proxy(8), a także zaktualizować /etc/rc.conf i /etc/rc by uruchomić nowego. Przeedytuj rc.conf lub rc.conf.local by wywoływać nowy program:
echo 'ftpproxy_flags=""' >> /etc/rc.conf.local

Nowe proxy korzysta z zakotwiczeń by zezwolić na połączenia danych, co oznacza, że musisz przystosować twój istniejący /etc/pf.conf W sekcji NAT potrzebujesz:
nat-anchor "ftp-proxy/*" rdr-anchor "ftp-proxy/*"
Jest to obowiązkowe, nawet jeżeli nie korzystasz z NAT. Musisz pozostawić poniższą regułę, istniejącą prawdopodobnie dla poprzedniego ftp-proxy:
rdr pass on $int_if proto tcp from $lan to any port 21 -> \ 127.0.0.1 port 8021
W sekcji reguł, potrzebujesz:
anchor "ftp-proxy/*"
Reguły zezwalające proxy na nawiązywanie połączeń kontrolnych FTP (port docelowy 21/tcp), także muszą pozostać. Reguły zezwalające na połączenia danych FTP nie są więcej potrzebne. Reguły te mogą zawierać "user proxy" lub "to port > 49151". Zatroszczono się o zachowanie parametrów w linii poleceń, lecz niektóre są mogą się różnić. Zobacz stronę manuala ftp-proxy(8)
Uwaga dotycząca konkretnego przypadku: jeżeli posiadasz klientów którzy opierają się na połączeniach w trybie aktywnym, korzystającym z portu 20/tcp jako portu źródłowego, będziesz potrzebował flagi '-r' (w poprzedniej wersji wykonywałeś to przy pomocy flagi "-u root").
Uruchom ftp-proxy z "-d -D7" jeżeli okaże się, że masz problemy i chcesz określić co się dzieje.

1.3 - Zmiany w plikach w `/etc`

Potrzebujesz rozpakować pliki etc39.tgz do tymczasowej lokalizacji:

cd /tmp tar xzpf ${RELEASEPATH}/etc39.tgz

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

daily ipsec.conf magic monthly netstart rc security services weekly mtree/*

Zauważ, że JEST możliwe by lokalnie zmodyfikować te pliki, jeżeli to było zrobione, będzie konieczne ręczne scalenie. Tutaj są linie kopiuj/wklej do kopiowania tych plików, zakładając że rozpakowałeś etc39.tgz w miejscu sugerowanym powyżej:

cd /tmp/etc cp daily ipsec.conf magic monthly netstart rc security services weekly /etc cp mtree/* /etc/mtree/

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:

changelist inetd.conf lynx.cfg rc.conf ssh/ssh_config ssh/sshd_config sysctl.conf

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 < upgrade39.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" 3.8, 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).

hostapd.conf pf.conf spamd.conf

Usuń pliki libresolc, ponieważ nie są więcej używane:

rm /usr/lib/libresolv*

Ostatecznie skorzystaj z mtree(8) by utworzyć jakiekolwiek nowe katalogi:

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 3.8, istnieje prawdopodobieństwo, że będziesz musiał zmodyfikować kernel w 3.9. 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, możesz chcieć zaktualizować je po zakończeniu aktualizacji systemu bazowego. W OpenBSD 3.9, narzędzia obsługi pakietów pozwalają na aktualizację "w miejsce", poprzez użycie pkg_add -u. Zostało to sprawdzone dla większości pakietów, w szczególności dla pakietów dostępnych w 3.8. Przykładowo, aby zaktualizować twoje pakiety, upewnij się ze PKG_PATH wskazuje na katalog z pakietami dla 3.9 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.