Documentação

1- Introdução
2- Versões disponíveis
2.1- Stable
2.2- Releases
2.3- Snapshots
2.4- Current
3- Upgrade a partir de snapshots
4- Upgrade a partir do código fonte
5- Upgrade da userland
6- Fontes
7- Anexos
Anexo 1 - Reconstrução do Kernel
Anexo 2 - Upgrade do código fonte e ports
a) CVS
b) CVSup
Anexo 3 - Resolução de problemas

1 - Introdução

Este documento descreve todos os procedimentos necessários para efectuarmos o upgrade do OpenBSD para -current. No entanto, convém ter em mente que este documento não substitui a - "MINI-FAQ: Upgrading OpenBSD". Assim, este documento pretende ser um complemento a esta.

A -current é um sistema dinâmico, a leitura da mini-faq é obrigatória, além da sua leitura é necessário percebê-la. Porquê? Como é natural o código fonte muda a todo o momento e algumas das alterações implicam certos procedimentos para que seja possível "construir" o sistema a partir do código fonte. Além da mini-faq, se vamos usar a -current convém ler pelo menos as listas @tech e @misc, alguns dos problemas que vão surgindo são primeiro discutidos nestas listas e só posteriormente, se for caso disso, é que são incorporados na mini-faq.

A versão de desenvolvimento do OpenBSD designa-se por -current, após o seu ciclo de desenvolvimento "transformar-se-á" em "Release". Uma "Release", versão estável apenas recebe correcções a nível de bugs e "security fixes", novas funcionalidades apenas serão incorporadas depois de amplamente testadas na -current.

2 - Versões disponíveis

Existem várias versões do OpenBSD: releases, -current, -stable e snapshots.

2.1 - stable

A -stable é suposto ser calma, fiável e suficientemente estável requerendo pouca atenção. Isto torna a -stable numa óptima escolha para ambientes de produção. A única forma de manter a -stable actualizada é reconstruindo-a desde o código fonte: http://www.openbsd.org/stable.html
Alternativamente, aplicar os patches que vão surgindo na errata: http://www.openbsd.org/errata.html tem o mesmo efeito.

2.2 - Releases

As releases do OpenBSD são numeradas sequencialmente. Desde a 2.0 estas são incrementadas em 0.1 a cada release. Assim que se tenha uma stable release em mãos é altura de começar a seguir a errata: http://www.openbsd.org/errata.html

2.3 - Snapshots

Quase diariamente a equipa do OpenBSD "constroi" uma "release" a partir da -current mais recente e coloca-a disponível nos seus servidores FTP. Estas releases têm o nome de snapshots, estes são "construídos" apenas por conveniência, pois, é muito mais fácil fazer o upgrade para -current a partir de um snapshot do que fazer o mesmo a partir da release corrente.

2.4 - Current

Esta é a designação dada à versão de desenvolvimento mais recente do OpenBSD. A -current está disponível a qualquer pessoa, no entanto, o seu uso é mais indicado a programadores, beta-testers e claro, "curiosos". Normalmente, é esperado que a -current funcione sem problemas, contudo, é possível que o sistema "quebre" em qualquer altura. Nessa mesma altura é suposto que o utilizador seja capaz de fazer o debugging do problema e resolvê-lo.

3 - Upgrade a partir de snapshots

Fazer o upgrade para a -current a partir dos snapshots disponibilizados frequentemente pela equipa do OpenBSD é bastante mais fácil do que a partir do código fonte. Inclusivamente, este é o método mais aconselhado pela equipa do OpenBSD para os interessados em usar a -current mas que não estão totalmente à vontade em lidar com problemas relacionados com compilação de software e derivados.

Digamos que a diferença é que ao usarmos snapshots fazemos o upgrade a partir de binários pré-compilados, como tal não temos que ter em atenção os problemas relacinados com a compilação do código fonte. Contudo, continua a ser necessário fazermos o upgrade dos directórios /etc, /var e /dev "à mão".

O upgrade a partir de um snapshot é relativamente "simples". Basicamente temos de ter uma imagem de boot (bsd.rd) arrancar a partir dela, depois é só escolher "(U)pgrade" e seguir os passos. Muito idêntico à instalação do sistema. Sendo que o set etcXX.tgz não será opção aquando da selecção dos sets, pois, este terá de ser actualizado à mão. Para arrancarmos com o upgrade basta colocarmos o "bsd.rd" na raiz do sistema "/", rebootarmos e no prompt
de boot escrever precisamente "bsd.rd", ou então usamos a mini-iso distribuída pelo OpenBSD, "cd36.iso", ambas podem ser encontradas nos mirrors oficiais do projecto na directoria dos snapshots.

Antes de arrancarmos com o upgrade devemos fazer um backup do /etc e /var:

# tar -czvf etc.tar.gz /etc; mv etc.tar.gz /tmp
# tar -czvf var.tar.gz /var; mv var.tar.gz /tmp

Depois de arrancarmos pela imagem de boot por um dos métodos já referidos e terminado com sucesso o nosso upgrade devemos "tratar" do /etc, podemos fazê-lo usando o mergemaster, que se encontra em /usr/ports/sysutils/mergemaster ou efectuando todo o processo "à mão". No upgrade a partir de snapshots vamos usar o mergemaster, mais à frente no upgrade a partir do código fonte trataremos todo o processo "à mão":

# boot -s
# /bin/sh
# mount -a
# TERM=vt200; export TERM

Descompactamos o etcXX.tgz em /home/newroot e corremos o mergemaster:

# /usr/local/sbin/mergemaster -r -t /home/newroot

O script, mergemaster, irá começar comparar os ficheiros que se encontram em /home/newroot com os contidos no /etc. Este processo também levará algum tempo e frequentemente ser-nos-á perguntados o que queremos fazer com determinado ficheiro se o "Mergemaster" não for capaz de decidir por si só.

Alguns ficheiros que costumo deixar intocáveis para fazer o merge deles "à mão" costumam ser, geralmente, o /etc/group, o /etc/master.passwd, o /etc/inetd.conf e eventualmente outros que se encontram listados aqui: http://www.openbsd.org/faq/upgrade-minifaq.html#1.9 e
aqui: http://www.openbsd.org/faq/upgrade36.html

Os snapshots podem ser encontrados no ftp oficial, ou num dos mirrors oficiais, do projecto, bem como várias imagens de boot. Para a arquitectura
i386 no mirror oficial português: http://ftp.fmed.uc.pt/OpenBSD/snapshots/i386/

4 - Upgrade a partir do código fonte

A primeira coisa a fazer é obter o código fonte a partir de um dos mirrors oficiais do projecto. Para isso podemos usar o CVS ou o CVSup. Vêr Anexo 2 para obter o código fonte a partir de qualquer um dos métodos.

A partir daqui vamos assumir que estamos logados como root para que se torne mais fácil descrever o processo. Obviamente pode e deve ser usado o sudo(8).

Depois de termos o código fonte em /usr/src, devemos assegurar-nos de que existe realmente a directoria /usr/obj que será onde ficarão guardados os binários e os ficheiros criados pelo processo de "construção". Se a directoria não existe, devemos criá-la! Se aplicá-mos algum patch ou fizemos um upgrade desde o código fonte anteriormente é provável que a directoria /usr/obj precise de ser limpa:

# cd /usr/src
# find . -type l -name obj | xargs rm
# make cleandir
# rm -rf /usr/obj/*
# make obj

Agora é altura de visitar a "Upgrade mini-faq" e executar as recomendações necessárias para a versão que se ajusta ao upgrade que estamos a fazer. Para o upgrade do 3.6 para -current: http://www.openbsd.org/faq/upgrade-minifaq.html#3.6

Posto isto, antes de podermos instalar o nosso novo software devemos dar indicação ao sistema para construir as directorias necessárias para os novos programas.

# cd /usr/src/etc
# make DESTDIR=/ distrib-dirs

Agora devemos reconstruir um novo kernel. Para isso devemos consultar o Anexo 1. Depois de reconstruído o kernel e termos reiniciado
o sistema, é altura de compilar todo o sistema.

# cd /usr/src
# make build

Obviamente, em função da máquina que estamos a utilizar este processo poderá demorar bastante tempo. Depois de concluído, o sistema estará similar a um sistema acabado de instalar por CD-ROM ou FTP. Contudo, devemos ainda proceder à actualização dos directórios /dev, /var e /etc.

Visto que o directório /dev não é actualizado automaticamente devemos correr o script MAKEDEV para criarmos todos os "device nodes" dos periféricos existentes no nosso sistema:

# cd /dev
# cp /usr/src/etc/etc.`machine`/MAKEDEV ./
# ./MAKEDEV all

Agora, para o restante devemos escolher uma directoria que permita albergar as directorias /, /dev, /var, e /etc. Vamos usar a mesma que é sugerida na "Upgrade mini-faq" por uma questão de consistência. No entanto a directoria pode ser qualquer uma à nossa escolha.

# mkdir /home/newroot
# export DESTDIR=/home/newroot
# cd /usr/src/etc  && make distribution-etc-root-var

Agora é tempo de executar as alterações necessárias aos directórios em causa. Devemos então, comparar os ficheiros contidos em /home/newroot com os instalados no nosso sistema. Devemos substitui-los quando caso disso ou fazer o seu update (merge de ambos os ficheiros). Para este processo relativamente cansativo devemos ter cuidado. Pois um mau update dos ficheiros pode tornar o sistema inutilizável, ou quase. Assim, para este processo é frequente vermos nas mailing-lists do projecto recomendarem o "Mergemaster", que não é mais do que um script que fará parte desse trabalho por nós. Sublinhe-se parte do trabalho. Teremos sempre de saber o que estamos a fazer pois o "Mergemaster" não toma todas as decisões sozinho.

Alternativamente ao "Mergemaster" podemos fazer as coisas "sozinhos". Eu costumo fazer algo do género:

# diff -r --brief /home/newroot/etc /etc | grep differ | cat > $HOME/differ

Assim ficarei com um ficheiro chamado "differ" que me dirá todos os ficheiros que são diferentes. Isto relativamente ao directório /etc.

Para saber os que apenas estão num ou noutro directório:

# diff -r --brief /home/newroot/etc /etc | grep Only | cat > $HOME/only

Assim ficarei com um ficheiro chamado "only" que me dirá que ficheiros existem apenas num dos directórios.

Depois resta-me consultar os ficheiros gerados. Possivelmente executarei mais uns "diffs" entre os ficheiros para saber exactamente o que mudou e onde. Este processo é relativamente chato e moroso, mas tenho a garantia que quando estiver pronto, está realmente pronto.

Se quisermos usar o "Mergemaster", reiniciamos a máquina, arrancámos em "single user mode" e o processo já foi, basicamente, descrito no ponto anterior, upgrade a partir de snapshots.

Depois de terminado, reiniciamos a máquina, se tudo tiver sido feito correctamente não existirá qualquer problema. Se algo correu mal convém verificar algumas coisas que estão descritas no Anexo 3.

5 - Upgrade da userland

Visto que devemos manter obrigatoriamente a nossa userland sincronizada com o kernel, normalmente, removem-se todos os packages que temos no sistema:

pkg_delete -q /var/db/pkg/*

Em seguida devemos voltar a instalar as versões mais actualizadas dos mesmos. De forma a automatizarmos este processo podemos usar uma ferramenta desenvolvida pelo Nuno Morgadinho sobre a qual se podem encontrar informações mais detalhes
aqui: http://www.openbsd-pt.org/tools/pkg_script/

Deve-se ter em atenção que nem sempre é preciso ser tão "radical", isto é, nem sempre é necessário remover todos os packages do sistema, apenas em alguns casos é realmente necessário que tal aconteça.

6 - Fontes

OpenBSD.org
OpenBSD Documentation and FAQ
Building the System from Source
MINI-FAQ: Upgrading OpenBSD
Upgrade Guide: 3.5 to 3.6
OpenBSD AnonCVS
OpenBSD CVSup
OpenBSD -current changes
Absolute OpenBSD, Michael W. Lucas. No Starch Press

7 - Anexos

Anexo 1 - Reconstrução do Kernel

Para reconstruirmos o kernel devemos ter o código fonte do mesmo em /usr/src. Em seguida, executar:

# cd /usr/src/sys/arch/i386/conf
# /usr/sbin/config GENERIC
# cd /usr/src/sys/arch/i386/compile/GENERIC
# make clean && make depend && make &&

Depois de terminado, devemos arrancar com o que acabamos de compilar:

# cd /usr/src/sys/arch/i386/compile/GENERIC

Guardamos uma cópia do antigo para o que der e vier:

# cp /bsd /bsd.old

E colocamos o novo no seu devido sítio:

# cp bsd /bsd
# reboot

Todo este processo de copiar o kernel "à mão" pode ser omitido bastando para isso substituir o último "make" por um "make install", sendo que o kernel antigo será automaticamente renomeado para "obsd". O processo atrás está apenas detalhado para que haja uma maior percepção do que realmente acontece.

Anexo 2 - Upgrade do código fonte e ports

Se vamos usar a -current devemos ter os ports sincronizados com a versão que estamos a correr. Não devemos usar a -stable e usar os ports referentes à -current e vice-versa por forma a evitar falhas. Ambos devem estar devidamente sincronizados. Para tal temos duas possibilidades, CVS ou CVSup.

a) CVS

O cvs é instalado por defeito e encontra-se em /usr/bin/cvs.
Para obter os ports:

# cd /usr/ports

Em seguida, forçamos o cvs a usar o ssh em vez do rsh, por defeito.

# export CVSROOT=anoncvs@anoncvs1.ca.openbsd.org:/cvs
# cvs -q up -PAd

Para obter o código fonte (da -current):

# cd /usr
# export CVSROOT=anoncvs@anoncvs1.usa.openbsd.org:/cvs
# cvs -q get -P src

Note-se que se devem escolher servidores os mais próximo possível de nós geograficamente, os exemplos acima são meramente exemplificativos. Para uma lista completa dos servidores disponíveis ver aqui: http://www.openbsd.org/anoncvs.html#CVSROOT

b) CVSup

Para usar o CVSup, devemos criar um ficheiro como o que se apresenta baixo, dar-lhe o nome de supfile e colocá-lo no /etc. Assim, teremos um /etc/supfile no qual podemos especificar o que pretendemos "puxar". Para o código fonte temos o exemplo que se segue, se quisermos também os ports basta descomentar a sua entrada, o mesmo se aplica às restantes coleções.

*default release=cvs
*default delete use-rel-suffix
*default umask=002
*default host=cvsup.pt.openbsd.org
*default base=/usr
*default prefix=/usr
*default tag=.
*default compress
#OpenBSD-all
OpenBSD-src
#OpenBSD-www
#OpenBSD-ports
#OpenBSD-x11
#OpenBSD-xf4

Para começarmos a puxar o que pretendemos:

# cvsup -g /etc/supfile

Mirrors e mais detalhes sobre o CVSup:
http://www.openbsd.org/cvsup.html

Anexo 3 - Resolução de problemas

Quando surgem problemas o melhor é ler atentamente a mensagem de erro e tentar perceber o que falhou. Por vezes as alterações necessárias à "Upgrade mini-faq" não são imediatas, assim, a leitura assídua das mailing-lists oficiais do projecto são obrigatórias. Também existe a possibilidade, ainda que pouco provável, de termos feito o download do código fonte no preciso momento em que um "commiter" esteja a fazer um largo upload de ficheiros.
Se tudo o resto falha podemos sempre fazer o upgrade a partir de snapshots. Os upgrades a partir do código fonte apenas são recomendados a utilizadores capazes de dar a volta a estas situações.

Copyright (C) 2004, Rui Reis. Permitidas a cópia e distribuição literal do artigo, na íntegra, em
qualquer meio, desde que este aviso de copyright seja preservado.