[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] | [FAQ Index]

Przewodnik po aktualizacji: z 4.2 do 4.3

Uwaga: upgrade jest dostępny 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 zanim przystąpisz aktualizacji.

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.1 i 4.2 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 plus43.html oraz w logach zmian CVS.

libexpat został przeniesiony do base43.tgz
Dla 4.2, libexpat został przeniesiony z portów do xbase42.tgz co okazało się wysoce kłopotliwe dla osób nie posiadających żadnych innych powodów do instalacji X-ów. Dla 4.3, libexpat przeniesiono do base43.tgz, zatem dla wielu aplikacji, nie ma powodu instalowania xbase43.tgz.
Oznacza to mały problem jeżeli zainstalowałeś xbase42.tgz aby mieć libexpat w systemie 4.2. Powinieneś zatem usunąć lub zaktualizować xbase42.tgz. W przypadku gdy instalacja xbase42.tgz wynikała tylko z konieczności posiadania libexpat, usunięcie xbase42.tgz wydaje się najlepszym rozwiązaniem Informacje o tym jak usunąć xbase42.tgz znajdziesz tutaj.
Zwróć także uwagę że kompilacja portów jest wspierana tylko przy pełnej instalacji, włącznie ze wszystkimi zestawami plików dla X-ów.
zmiany w httpd.conf
Pakiety dla modułów httpd(8) instalują obecnie pliki konfiguracyjne w /var/www/conf/modules.samples i zalecane jest tworzenie dowiązań w do nich w katalogu /var/www/conf/modules. Poniższe linie powinny być dodane do /var/www/conf/httpd.conf po LoadModule (koniec sekcji 1):
```
#
# Include extra module configuration files
#
Include /var/www/conf/modules/*.conf
```
Zmiany te zawiera także plik upgrade43.patch, jednak łatka ta może nie zostać poprawnie nałożona dla bardzo spersonalizowanych plików httpd.conf. Powinieneś się upewnić, że te linie znajdują się w twoim systemie - w przeciwnym wypadku pakiety instalowane w przyszłości mogą nie działać poprawnie.
hoststated(8) zmienił nazwę na relayd(8):
Nazwa hoststated(8) została zmieniona na relayd(8). Zmiana ta wymaga modyfikacji użytkownika i grupy _hoststated na _relayd, zmian w konfiguracji /etc/pf.conf oraz małych zmian polegających na przerobieniu hoststated.conf(5) na relayd.conf(5). Instrukcje podane poniżej pomogą zainstalować nowy plik relayd.conf. Będziesz mógł skonfigurować go według własnych potrzeb.
zmiany w carp(4):
Aby uczynić konfigurację łatwiejszą zmieniony został carp(4). Jeżeli korzystasz z carp-a z równoważeniem obciążenia dla ARP lub IP, twoja konfiguracja powinna się zmienić odpowiednio:
- Wiele interfejsów carp(4) współdzielących adres IP zostało zastąpione opcją carpnodes.
- net.inet.carp.arpbalance w sysctl(8) został zamieniony z trybem rozkładania arp.
- Flagi link0, link1, oraz link2 używane w równoważeniu IP zostały zastąpione trybami równoważenia ip,ip-stealth oraz ip-unicast.
zmiana domyślnej lokalizacji źródeł dla xenocara:
Domyślnym położeniem drzewa źródeł xenocary (X) jest teraz /usr/xenocara. Fakt ten ma szczególne znaczenie dla osób tworzących X-y ze źródeł. Po prostu przenieś twoje drzewo xenocara:
```
# mv /usr/src/xenocara /usr
```
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 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.3.

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.3 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: Podczas upgrade 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.2, prawdopodobnie będziesz musiał to zrobić również w wersji 4.3. 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.3. 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 base43.tgz, jako root użyj polecenia:
```
cd /
tar -C / -xzphf ${RELEASEPATH}/base43.tgz ./etc/firmware
```
Reboot na nowym jądrze: Może kusić chęć opuszczenia tego kroku, ale powinien on być wykonany teraz, jak zwykle, 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 etc43.tgz oraz xetc43.tgz, ponieważ proces ten nadpisze twoje aktualne pliki konfiguracyjne!
```
export RELEASEPATH=/usr/rel
cd ${RELEASEPATH}
tar -C / -xzphf base43.tgz
tar -C / -xzphf comp43.tgz
tar -C / -xzphf game43.tgz
tar -C / -xzphf man43.tgz
tar -C / -xzphf misc43.tgz
tar -C / -xzphf xbase43.tgz
tar -C / -xzphf xfont43.tgz
tar -C / -xzphf xserv43.tgz
tar -C / -xzphf xshare43.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 etc43.tgz oraz xetc43.tgz NIE są tutaj rozpakowywane.
Aktualizacja /dev. Nowy plik MAKEDEV zostanie skopiowany do /dev/ podczas instalacji base43.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 kroków.

1. Nowi użytkownicy i grupy

Wymagane jest utworzenie nowych użytkowników dla ospf6d oraz snmpd. Możesz dodać odpowiednie konta korzystając z polecenia useradd(8).

useradd -u90 -g=uid -c"OSPF6 Daemon" -d/var/empty -s/sbin/nologin _ospf6d
useradd -u91 -g=uid -c"SNMP Daemon" -d/var/empty -s/sbin/nologin _snmpd

Musisz także użyć vipw(8) do zmiany pliku z hasłami oraz ulubionego edytowa do zmiany pliku /etc/group, zmieniając _hoststated na _relayd, oraz zmieniając w vipw(8) opis z "HostState Daemon" na "Relay Daemon". Nie zmieniaj innych linii.

2. Aktualizacja `/etc`

Rozpakuj plik etc43.tgz do tymczasowej lokalizacji:

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

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

etc/mail/README
etc/moduli
etc/mtree/4.4BSD.dist
etc/mtree/BSD.local.dist
etc/mtree/special
etc/netstart
etc/ospf6d.conf
etc/rc
etc/rc.conf
etc/relayd.conf
etc/security
etc/snmpd.conf
var/named/etc/root.hint

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

cd /tmp/etc
cp moduli netstart ospf6d.conf rc rc.conf relayd.conf security snmpd.conf /etc
cp mtree/* /etc/mtree/
cp mail/README /etc/mail
cp ../var/named/etc/root.hint /var/named/etc

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/chio.conf
etc/ftpusers
etc/mail/aliases
etc/ssh/sshd_config
etc/sudoers
etc/sysctl.conf
var/named/etc/named-dual.conf
var/named/etc/named-simple.conf
var/named/etc/named.conf
var/www/conf/httpd.conf
var/www/conf/mime.types
var/www/htdocs/manual/mod/core.html
var/www/htdocs/manual/server-wide.html

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 < upgrade43.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.2, 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ć.

/etc/ttys został uzgodniony pomiędzy platformami, wymagają one jednak dodatkowych działań na tym pliku. Zalecane jest skopiowanie nowego pliku i ręczne wprowadzenie do niego zmian.

mv /etc/ttys /etc/ttys.orig
cp /tmp/etc/ttys /etc

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/pf.conf

Kilka plików musi zostać usuniętych z systemu ponieważ nie są używane w 4.3:

rm /etc/hoststated.conf /var/named/standard/root.hint

Ostatecznie skorzystaj z newaliases(8) aby zaktualizować bazę aliasów oraz mtree(8) aby utworzyć jakiekolwiek nowe katalogi oraz zmienić właściciela i prawa dostępu do /etc/chio.conf:

newaliases
mtree -qdef /etc/mtree/4.4BSD.dist -p / -u
chown root:operator /etc/chio.conf
chmod 644 /etc/chio.conf

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, juz zakończyłeś ten krok procesu. Jednakże, jeśli korzystałeś z medium instalacyjnego, i posiadałeś zmodyfikowany kernel w 4.2, istnieje prawdopodobieństwo, że będziesz musiał zmodyfikować kernel w 4.3. 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 uaktualnieniu 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.2 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.

5. Usunięcie xbase42.tgz

Jeśli instalowałeś xbase42.tgz aby mieć zainstalowane biblioteki libexpat wymagane dla niektórych pakietów, nie potrzebujesz tego w 4.3. Możesz go usunąć lub zainstalować xbase43.tgz.

Jeżeli chcesz usunąć, wykonaj poniższe polecenia:

# mv /usr/X11R6/lib/libexpat.so.* /usr/lib
# rm -r /usr/X11R6 /etc/X11 /etc/fonts

Jeżeli chcesz zainstalować xbase43.tgz, musisz wykonać porządki ze starymi plikami dla libexpat:

# mv /usr/X11R6/lib/libexpat.so.* /usr/lib
# rm /usr/X11R6/lib/libexpat*
# rm /usr/X11R6/include/expat*