[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.0 -> 4.1] | [4.1 -> 4.2] | [4.2 -> 4.3] | [FAQ Index]

Przewodnik po aktualizacji: z 4.3 do 4.4

Uwaga: upgrade jest możliwy tylko z release do release - zalecane jest aby nie opuszczać wydań pośrednich. Nie opuszczaj wersji release.

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

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
Aktualizacja
Ostatnie kroki

Zanim rozpoczniesz: sprawy do przemyślenia i te którymi należy się martwić

To nie jest kompletna lista zmian jakie pojawiły się pomiędzy wersjami 4.3 i 4.4 lecz raczej zestawienie ważnych spraw na które może natrafić znaczna liczba użytkowników podczas procesu aktualizacji. Szczegółową listę zmian znajdziesz na stronie plus44.html oraz w logach zmian CVS.

Nowe narzędzie sysmerge(8):
Do OpenBSD 4.4 dodany został program sysmerge(8), mający pomagać administratorom w aktualizacji plików konfiguracyjnych po aktualizacji systemu. Sysmerge(8) porównuje aktualne pliki z twojego systemu z plikami które zostałyby zainstalowane podczas instalacji nowego systemu i daje użytkownikowi możliwość pozostawienia starego pliku, instalację nowego lub wspomaga proces ręcznego łączenia starego i nowego pliku, korzystając z sdiff. W przypadku wcześniejszych systemów i ich aktualizacji zamieszczaliśmy listę plików które mogą być kopiowane "jak-są", listę plików które powinny być zmienione oraz łatkę która wprowadzała zmiany do tych plików. Dla aktualizacji z 4.3 do 4.4, zamiast korzystać z pliku z łatką, możesz opcjonalnie skorzystać z sysmerge.
Kto powinien korzystać z sysmerge(8):
Użytkownicy korzystający z mocno zmodyfikowanych systemów, użytkownicy którzy nie rozpoczynali od poprzedniego wydania (np. korzystający ze snapshot-ów), użytkownicy którzy aktualizowali system do snapshot-a a także ci którzy w przeszłości niezbyt dokładnie aktualizowali system zauważą ogromną przewagę sysmerge nad łatkami, ponieważ operuje on na tym co faktycznie znajduje się w twoim systemie zamiast zakładać jego zawartość. Dodaktowo daje użytkownikowi możliwość większej kontroli nad procesem aktualizacji.
Kto NIE może nie chceć korzystać z sysmerge(8):
Użytkownicy posiadający wiele komputerów do aktualizacji o dość prostej konfiguracji, prawdopodobnie stwierdzą że poprzedni system aktualizacji oparty na łatce jest znacznie szybszy.
Zwróć uwagę, że wprawdzie sysmerge obsługuje WSZYSTKIE zmiany w /etc, /dev, /root oraz /var, zalecamy wykonanie kilku kroków ręcznie, ponieważ pozwoli to zaoszczędzić czas i ogranicza możliwość wystąpienia błędu ludzkiego. W szczególności, wysoce zalecane jest by nie używać sysmerge do aktualizacji kont użytkowników oraz grup gdyż łatwo można doprowadzić do sytuacji w której złą opcją zamazana zostanie baza kont użytkowników i ustawione zostanie puste hasło administratora - co w praktyce oznacza brak możliwości zdalnego zalogowania do systemu i naprawę błędu.
Plik dhcpd.interfaces nie jest więcej używany:
Plik /etc/dhcpd.interfaces nie jest więcej używany do określenia interfejsów na których nasłuchuje dhcpd. Listę interfejsów można określić poprzez flagę dhcpd_flags w pliku /etc/rc.conf.local. Większość użytkowników prawdopodobnie pozwoli by dhcpd(8) sam określił na którym interfejsie powinien słuchać na podstawie konfiguracji z pliku dhcpd.conf.
Nowe sterowniki X-ów Do Xenocara-y dodany został sterownik xf86-video-openchrome dla układów VIA, który zastępuje stary sterownik "via". Jeżeli posiadasz chipset VIA z plikem konfiguracyjnym X-ów, zamień Driver "via" przez Driver "openchrome" w /etc/X11/xorg.conf. Zobacz również stronę manuala openchrome(4).
Sterownik ati(4) został zaktualizowany. Ta aktualizacja w xf86-video-ati wprowadza kilka ważnych zmian.
- MergedFB: Usunięte zostało wsparcie dla MergedFB na korzyść: xrandr(1).
- Zmiany w dziwnych opcjach dla Macbook-ów: Użytkownicy Mac-ów oraz Macbook-ów którzy korzystali z poniższego dziwadła: Option "iBookHacks" "on" powinni przeczytać stronę manuala radeon(4), w szczególności sekcję "MacModel".
  Od tego wydania ta opcja została usunięta
rc.conf:
W odróżnieniu od poprzednich wersji tego procesu, od 4.1 zakładamy, że 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.
Modyfikowany kernel:
Sprawdź czy nie 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.4.

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.4 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 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 aktualizacyjnego. 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ść przestrzeni dyskowej!
Wyłącz wszystkie "niebezpieczne" aplikacje ze startu podczas uruchomienia systemu: Podczas aktualizacji może wystąpić moment gdy prawdopodobnie nie będzie włączony PF, jednak 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: Pomimo że większość osób może pominąć ten krok, jeżeli modyfikowałeś swój kernel w wersji 4.3, prawdopodobnie będziesz musiał to zrobić również w wersji 4.4. 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.4. 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 base44.tgz, jako root użyj polecenia:
```
cd /
tar -C / -xzphf ${RELEASEPATH}/base44.tgz ./etc/firmware
```
Instalacja nowej wersji narzędzia /sbin/ifconfig: Czasami sterowniki sieciowe (szczególnie bardziej złożone jak np. pppoe(4)) w nowszym kernelu wymagaja aktualizacji ifconfig tak aby zostały poprawnie skonfigurowane po restarcie systemu w następnym kroku. Ponownie, jest to sprawa która nie dotyczy większości użytkowników, jednak jeżeli wykonujesz aktualizację zdalnie poprzez połączenie pppoe(4) ten krok może być krytyczny. Aby wypakować ifconfig z base44.tgz użyj polecenia (jako root):
```
tar -C / -xzphf ${RELEASEPATH}/base44.tgz ./sbin/ifconfig
```
Reboot na nowym jądrze: Może kusić chęć opuszczenia tego kroku, ale powinien on być wykonany teraz, nowy kernel uruchomi stare aplikacje przestrzeni użytkownika (takie jak, będący wkrótce ważny, reboot!), jednak często nowe aplikacje NIE będą działały ze starym kernelem.
Instalacja nowych aplikacji przestrzeni użytkownika NIE instaluj teraz etc44.tgz oraz xetc44.tgz, ponieważ proces ten nadpisze twoje aktualne pliki konfiguracyjne!
```
export RELEASEPATH=/usr/rel
cd ${RELEASEPATH}
tar -C / -xzphf base44.tgz
tar -C / -xzphf comp44.tgz
tar -C / -xzphf game44.tgz
tar -C / -xzphf man44.tgz
tar -C / -xzphf misc44.tgz
tar -C / -xzphf xbase44.tgz
tar -C / -xzphf xfont44.tgz
tar -C / -xzphf xserv44.tgz
tar -C / -xzphf xshare44.tgz
```
Uwaga: nie wszystkie elementy muszą być zainstalowane dla wszystkich aplikacji, jednakże, jeżeli zainstalowałeś dany zbiór oryginalnie, powinieneś z pewnością uaktualnić go teraz nowym zbiorem.
Pliki z /etc są zarządzane oddzielnie, zatem etc44.tgz oraz xetc44.tgz NIE są tutaj rozpakowywane.
Aktualizacja /dev. Nowy plik MAKEDEV zostanie skopiowany do /dev/ podczas instalacji base44.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. Zwracamy uwagę, że sendmail nie działa w tym punkcie aktualizacji dobrze i wymagany jest jego restart (jako część restartu maszyny), zanim poczta będzie mogła być obsługiwana zgodnie z oczekiwaniami.

Ostatnie kroki

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

1. Nowi użytkownicy i grupy

Wymagane jest utworzenie nego użytkownika dla rtadvd, oraz ypldap(8). Możesz to wykonać korzystając z useradd(8)

useradd -u92 -g=uid -c"IPv6 Router Advertisement Daemon" -d/var/empty -s/sbin/nologin _rtadvd
useradd -u93 -g=uid -c"YP to LDAP Daemon" -d/var/empty -s/sbin/nologin _ypldap

2. Aktualizacja `/etc`

Rozpakuj plik etc44.tgz do tymczasowej lokalizacji:

tar -C /tmp -xzphf ${RELEASEPATH}/etc44.tgz

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

etc/magic
etc/netstart
etc/rc
etc/rc.conf
etc/security
etc/services
etc/mail/localhost.cf
etc/mail/sendmail.cf
etc/mail/submit.cf
etc/mtree/4.4BSD.dist

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ś etc44.tgz w miejscu sugerowanym powyżej:

cd /tmp/etc
cp magic netstart rc rc.conf security services /etc
cp mtree/* /etc/mtree
cp mail/*.cf /etc/mail # Uwaga na ten plik!!

Użyj pliku z łatką LUB sysmerge, nie obu

Pliki poniżej najprawdopodobniej zawierają lokalne zmiany, muszą być jednak zaktualizowane do wersji 4.4. Jeśli pliki te nie były zmieniane, możesz je po prostu skopiować z nowszej wersji.

etc/changelist
etc/ftpusers
etc/hosts.lpd
etc/man.conf
etc/sudoers
etc/mail/aliases
etc/ssh/ssh_config
etc/ssh/sshd_config

Zmiany w tych plikach znajdują się w tej łatce. Możesz spróbować z niego skorzystać wykonując jako root nastepujące polecenie:

cd /
patch -C -p0 < upgrade44.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.3, 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/dhclient.conf
etc/pf.conf
var/www/conf/httpd.conf

Istnieje także plik który może być skasowany ponieważ nie jest więcej używany w 4.4:

rm /etc/dhcpd.interfaces

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

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

3b. Łączenie lokalnie zmienionych plików przy pomocy sysmerge(8)

Pamiętaj by używać albo opisanego poniżej procesu opartego na sysmerge(8) LUB mechanizmu z patchfile, nigdy z obu.

Nowy program sysmerge(8) porówna pliki które obecnie znajdują się w twoim systemie z plikami które były by zainstalowane podczas świerzej instalacji i asystuje podczas łączenia ich zawartości. Zwróć uwagę, że w przeciwieństwie do rozwiązania z łatką, nie przyjmowane jest żadne założenie odnośnie tego co rzeczywiście znajduje się w twoim systemie, zatem możesz korzystać z sysmerge(8) by przejść z jednego punktu w procesie rozwoju systemu, np. z wcześniejszej wersji -current do 4.4-release lub z jednego -current'a do innego.

Prosimy zapoznaj się ze stroną manuala sysmerge(8), zanim zaczniesz korzystać z sysmerge w twoim systemie. Zachęcamy także do zapoznania się ze stronami manuali dla diff(1), sdiff(1) oraz more(1).

Zakładając że pliki etc44.tgz oraz xetc44.tgz, istnieją na ustawionej ścieżce $RELEASEPATH, skorzystaj z:

# sudo sysmerge -as $RELEASEPATH/etc44.tgz -x $RELEASEPATH/xetc44.tgz

Sysmerge(8) wyświetli wówczas jednolity diff(1), korzystając z twojej ulubionej przeglądarki plików podanej poprzez zmienną środowiskową $PAGER (np. more(1)) oraz, dla plików z największą ilością zmian, czy chcesz:

  Use 'd' to delete the temporary ./var/www/htdocs/index.html
  Use 'i' to install the temporary ./var/www/htdocs/index.html
  Use 'm' to merge the temporary and installed versions
  Use 'v' to view the diff results again

  Default is to leave the temporary file to deal with by hand

W przypadku gdy zechcesz zachować istniejący plik, usuń plik tymczasowy. Jeśli chcesz zamienić istniejący plik nową wersją, zainstaluj tymczasowy plik. Jeśli zamierzadz scalić dwa pliki, wybierając opcję 'm' uruchomiony zostanie sdiff(1), gdzie będzie można wykonać tą operację ręcznie. Domyślnym zachowaniem jest powrót i pozostawienie pliku do późniejszej, recznej, zmiany.

Wprawdzie może to zadzialać ale nie zalecamy korzystania z sysmerge do dodawania nowych użytkowników do systemu, zamiast tego zalecając podaną wcześniej metodę z useradd(8). Uważamy, że takie rozwiązanie jest znacznie bardziej odporne na błędy. (hint: nie instaluj tymczasowego pliku master.passwd na istniejącym!).

Sysmerge(8) zachowuje wszystkie zamienione pliki w katalogu tymczasowym, podobnym do /var/tmp/sysmerge.24959/backups, zatem jeżeli przypadkowo sprawisz, że stanie się coś co nie jest dobrym pomysłem, zawsze masz szansę przywrócić sytuację przed zmianami. Zwracamy uwagę, że daily(8) usuwa stare pliki z tego katalogu.

3. Sprawdzanie kernela

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

Jeżeli podążałeś za instrukcjami procesu aktualizacji bez instalacji nowego kernela, już wykonałeś ten krok z całego procesu. Jednakże, jeśli korzystałeś z medium instalacyjnego i posiadałeś zmodyfikowany kernel w 4.3, istnieje prawdopodobieństwo że będziesz musiał zmodyfikować kernel także w 4.4. 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.

4. 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 zaktualizowaniu pakietu. Sprawdź informacje dotyczące aktualizacji koniecznych pakietów.

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