[OpenBSD]

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

Przewodnik po aktualizacji: z 4.1 do 4.2


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: 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 plus42.html oraz w logach zmian CVS.


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.2 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:

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. Aktualizacja /etc

Rozpakuj plik etc42.tgz do tymczasowej lokalizacji:

tar -C /tmp -xzphf ${RELEASEPATH}/etc42.tgz
Pliki które prawdopodobnie mogą być skopiowane z etc42.tgz "w takiej postaci w jakiej są":
etc/magic
etc/man.conf
etc/netstart
etc/rc
etc/rc.conf
etc/rpc
etc/services
etc/mail/helpfile
etc/mail/localhost.cf
etc/mail/sendmail.cf
etc/mail/submit.cf
etc/mtree/4.4BSD.dist
etc/mtree/BSD.local.dist
etc/mtree/special
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ś etc42.tgz w miejscu sugerowanym powyżej:
cd /tmp/etc
cp magic man.conf netstart rc rc.conf rpc services /etc
cp mtree/* /etc/mtree/
cp mail/helpfile mail/localhost.cf mail/submit.cf /etc/mail
cp mail/sendmail.cf /etc/mail     # Uważaj na ten plik!!

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/ntpd.conf
etc/sensorsd.conf
etc/ssh/ssh_config
etc/ssl/x509v3.cnf
etc/sudoers
etc/sysctl.conf
etc/wsconsctl.conf
var/www/conf/httpd.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 < upgrade42.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.9, 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 bgpd.conf, przyjżyj się sugerowanej zmianie strategii i zdecyduj czy jest właściwa dla twoich potrzeb).

etc/bgpd.conf
etc/mail/spamd.conf
etc/ospfd.conf
etc/ssh/sshd_config
Ostatecznie skorzystaj z newaliases(8) aby zaktualizować bazę aliasów oraz mtree(8) aby utorzyć 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 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.1, istnieje prawdopodobieństwo, że będziesz musiał zmodyfikować kernel w 4.2. 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. Pliki konfiguracyjne X-ów

Ze względu na znaczące zmiany w systemie X dla tego wydania, najprostrzym sposobem na aktualizację X-ów do wersji z 4.2 może być wykonanie kopii zapasowej plików konfiguracyjnych X-ów, rozpakowanie xetc42.tgz, i ręcznie wprowadzenie wszystkich zmian które wykonałeś.

Plikami które najprawdopodobniej możesz chcieć zachować są /etc/X11/xorg.conf oraz /etc/X11/xinit/xinitrc. Ponieważ X-y często pracują BEZ pliku xorg.conf, możesz spróbować uruchomić je bez tego pliku, zanim wprowadzisz do nowej wersji swoje zmiany.

Rozpakuj xetc42.tgz podobnie jak inne zestawy plików:

export RELEASEPATH=/usr/rel
cd ${RELEASEPATH}
tar -C / -xzphf xetc42.tgz

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.

Zanim przejdziemy dalej, jest kilka zmian w wydaniu 4.2 o których powinieneś wiedzieć:

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.

Najprawdopodobniej zobaczysz podobny komunikat podczas wykonywania podanego powyżej polecenia:

Looking for updates: complete
Cannot find updates for expat-2.0.0
Proceed? [y/N] 
Oznacza on natrafienie na problem z libexpat i jego rozwiązanie wymaga zainstalowania xbase42.tgz jak to zostało opisane powyżej. Jeżeli nie masz zainstalowanego xbase42.tgz, zalcane jest przerwanie aktualizacji pakietów, zainstalowanie xbase42.tgz a następnie ponowne uruchomienie aktualizacji pakietów.

Ostatecznie po zaktualizowaniu wszystkich twoich pakietów, posprzątaj system usuwając stary pakiet expat z systemu:

# pkg_delete expat

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


[back] www@openbsd.org
$OpenBSD$