Aplica-se a SUSE Linux Enterprise Server 15 SP2

3 Preparando o upgrade #

Antes de iniciar o procedimento de upgrade, verifique se o sistema está preparado apropriadamente. Entre outras coisas, a preparação envolve o backup dos dados e a verificação das notas de versão.

3.1 Verificar se o sistema atual está atualizado #

O upgrade do sistema apenas é suportado do nível de patch mais recente. Verifique se as atualizações mais recentes de sistema estão instaladas por meio da execução do zypper patch ou ao iniciar o módulo Atualização Online do YaST.

3.2 Ler os detalhes da versão #

Nos detalhes da versão, você encontra mais informações sobre o que mudou desde a versão anterior do SUSE Linux Enterprise Server. Consulte os detalhes da versão para verificar se:

seu hardware precisa de considerações especiais;
qualquer pacote de software usado foi significativamente modificado;
são necessárias precauções especiais para a instalação.

Os detalhes da versão também apresentam informações que não puderam ser incluídas a tempo no manual. Eles também incluem notas sobre problemas conhecidos.

Se você está ignorando um ou mais Service Packs, consulte também os detalhes da versão dos Service Packs ignorados. Geralmente, os detalhes da versão contêm apenas as mudanças entre duas versões subsequentes. Você poderá perder mudanças importantes se ler apenas os detalhes da versão atual.

Localize os detalhes da versão atuais online em https://www.suse.com/releasenotes/.

Se preferir, localize os detalhes da versão no DVD de instalação no diretório docu.

3.3 Fazer um backup #

Antes de atualizar, copie os arquivos de configuração existentes em uma mídia separada (como dispositivo de fita, disco rígido removível, etc.) para fazer backup dos dados. Isso se aplica basicamente aos arquivos armazenados em /etc e a alguns diretórios e arquivos em /var e /opt. Você também pode gravar os dados do usuário em /home (os diretórios HOME) em uma mídia de backup. Faça o backup desses dados como root. Apenas o root tem permissões de leitura para todos os arquivos locais.

Se você selecionou Atualizar um Sistema Existente como o modo de instalação no YaST, poderá optar por fazer o backup (do sistema) em algum outro momento. É possível incluir todos os arquivos modificados e os arquivos do diretório /etc/sysconfig. Entretanto, esse não é um backup completo, já que todos os outros diretórios importantes mencionados anteriormente não estão incluídos. Encontre o backup no diretório /var/adm/backup.

3.4 Listando os pacotes e repositórios instalados #

Muitas vezes, convém gravar uma lista dos pacotes instalados, por exemplo, ao fazer uma nova instalação de uma nova versão principal do SLE ou ao reverter para a versão antiga.

Saiba que nem todos os pacotes instalados ou repositórios usados estão disponíveis nas versões mais novas do SUSE Linux Enterprise. Alguns podem ter sido renomeados, e outros substituídos. É possível também que alguns pacotes ainda estejam disponíveis para fins legados, enquanto outro pacote é usado por padrão. Portanto, talvez seja necessária alguma edição manual nos arquivos. Isso pode ser feito com qualquer editor de texto.

Crie um arquivo denominado repositories.bak.repo com uma lista de todos os repositórios usados:

root # zypper lr -e repositories.bak

Crie também um arquivo denominado installed-software.bak com uma lista de todos os pacotes instalados:

root # rpm -qa --queryformat '%{NAME}\n' > installed-software.bak

Faça backup dos dois arquivos. Os repositórios e os pacotes instalados podem ser restaurados com os comandos a seguir:

root # zypper ar repositories.bak.repo
root # zypper install $(cat installed-software.bak)

Nota: O número de pacotes aumenta com a atualização para uma nova versão principal

Um sistema do qual foi feito o upgrade para uma nova versão principal (SLE X+1) pode conter mais pacotes do que o sistema inicial (SLE X). Ele também terá mais pacotes do que uma nova instalação do SLE X+1 com a seleção do mesmo padrão. Os motivos para isso são:

Os pacotes foram divididos para permitir uma seleção de pacote mais detalhada. Por exemplo, 37 pacotes texlive no SLE 11 foram divididos em mais de 3.000 pacotes no SLE 15.
Quando um pacote é dividido em outros pacotes, todos os novos pacotes são instalados no caso de upgrade para manter a mesma funcionalidade da versão anterior. No entanto, o novo padrão para uma instalação recente do SLE X+1 pode ser de não instalar todos os pacotes.
Os pacotes legados do SLE X podem ser mantidos por questões de compatibilidade.
As dependências de pacotes e o escopo dos padrões podem ter mudado.

3.5 Fazendo upgrade do SUSE Linux Enterprise Server 11 SP4 #

Se você usa o MySQL, PostgreSQL ou Java MD5 com base em certificados no SUSE Linux Enterprise Server 11 SP4, prepare seu sistema conforme descrito nas seções a seguir.

3.5.1 Migrar o banco de dados MySQL #

A partir do SUSE Linux Enterprise 12, o SUSE trocou o MySQL pelo MariaDB. Antes de você começar qualquer upgrade, é altamente recomendável fazer backup do banco de dados.

Para executar a migração do banco de dados, faça o seguinte:

Efetue login na máquina do SUSE Linux Enterprise 11.
Criar um arquivo de dump:
```
root # mysqldump -u root -p --all-databases > mysql_backup.sql
```
Por padrão, o mysqldump não descarrega o banco de dados INFORMATION_SCHEMA ou performance_schema. Para obter mais detalhes, consulte https://dev.mysql.com/doc/refman/5.5/en/mysqldump.html.
Armazene o arquivo de dump, o arquivo de configuração /etc/my.cnf e o diretório /etc/mysql/ para investigação futura (NÃO para instalação!) em um local seguro.
Faça o upgrade. Após o upgrade, seu arquivo de configuração antigo /etc/my.cnf ainda estará intacto. Você encontra a nova configuração no arquivo /etc/my.cnf.rpmnew.
Configure o banco de dados MariaDB de acordo com as suas necessidades. Não use o arquivo de configuração e o diretório antigos, mas use-os como base e adapte-os.
Inicie o servidor MariaDB:
```
root # systemctl start mysql
```
Para iniciar o servidor MariaDB em cada boot, habilite o serviço:
```
root # systemctl enable mysql
```
Verifique se o MariaDB está sendo executado apropriadamente conectando-se com o banco de dados:
```
root # mysql -u root -p
```

3.5.2 Migrar o banco de dados PostgreSQL #

Uma versão mais recente do banco de dados PostgreSQL acompanha o SUSE Linux Enterprise Server 15 SP2. Por causa do trabalho de migração do banco de dados necessário, não existe um processo de upgrade automático. Dessa forma, a mudança de uma versão para outra precisa ser feita manualmente.

O processo de migração é realizado pelo comando pg_upgrade, que é um método alternativo do clássico dump e recarregamento. Em comparação com o método “dump e recarregamento”, o pg_upgrade reduz o tempo da migração.

Os arquivos de programas para cada versão do PostgreSQL são armazenados em diretórios diferentes dependentes da versão. Por exemplo, no /usr/lib/postgresql96/ para a versão 9.6 e no /usr/lib/postgresql10/ para a versão 10. Observe que a política de controle de versão do PostgreSQL foi modificada entre as versões principais 9.6 e 10. Para obter os detalhes, consulte https://www.postgresql.org/support/versioning/.

Importante: Fazendo upgrade do SLE 11

Ao fazer upgrade do SLE 11, o postgresql94 será desinstalado e não poderá ser usado para migração do banco de dados para uma versão superior do PostgreSQL. Portanto, migre o banco de dados PostgreSQL antes de fazer upgrade do sistema neste caso.

O procedimento a seguir descreve a migração do banco de dados da versão 9.6 para 10. Ao usar uma versão diferente como inicial ou destino, substitua os números das versões adequadamente.

Para executar a migração do banco de dados, faça o seguinte:

Verifique se as seguintes pré-condições foram atendidas:
- Caso ainda não tenha sido feito, faça upgrade de qualquer pacote da versão antiga do PostgreSQL para a versão mais recente por meio de uma atualização de manutenção.
- Crie um backup do seu banco de dados existente.
- Instale os pacotes da nova versão principal do PostgreSQL. Para o SLE 15 SP2, isso significa instalar o postgresql10-server e todos os pacotes dos quais ele depende.
- Instale o pacote postgresql10-contrib que contém o comando pg_upgrade.
- Verifique se você tem espaço livre suficiente na área de dados do PostgreSQL, que é /var/lib/pgsql/data, por padrão. Se o espaço for pouco, tente reduzir o tamanho com o seguinte comando SQL em cada banco de dados (pode levar muito tempo!):
```
VACUUM FULL
```
Pare o servidor PostgreSQL usando qualquer um destes comandos:
```
root # /usr/sbin/rcpostgresql stop
```
ou
```
root # systemctl stop postgresql.service
```
(dependendo da versão do SLE que você usa como a versão inicial para o upgrade).

Renomeie o diretório de dados antigo:

root # mv /var/lib/pgsql/data /var/lib/pgsql/data.old

Inicialize a nova instância do banco de dados manualmente com initdb ou iniciando e parando o PostgreSQL, que fará isso automaticamente:
```
root # /usr/sbin/rcpostgresql start
root # /usr/sbin/rcpostgresql stop
```
ou
```
root # systemctl start postgresql.service
root # systemctl stop postgresql.service
```
(dependendo da versão do SLE que você usa como a versão inicial para o upgrade).
Se você modificou os arquivos de configuração na versão antiga, considere transferir essas modificações para os novos arquivos de configuração. Isso pode afetar os arquivos postgresql.auto.conf, postgresql.conf, pg_hba.conf e pg_ident.conf. As versões antigas desses arquivos estão localizadas em /var/lib/pgsql/data.old/, as versões novas estão disponíveis em /var/lib/pgsql/data.
Não é recomendado apenas copiar os arquivos de configuração antigos, pois isso pode sobregravar as novas opções, os novos padrões e os comentários modificados.

Inicie o processo de migração como usuário postgres:

root # su - postgres
postgres > pg_upgrade \
  --old-datadir "/var/lib/pgsql/data.old" \
  --new-datadir "/var/lib/pgsql/data" \
  --old-bindir "/usr/lib/postgresql96/bin/" \
  --new-bindir "/usr/lib/postgresql10/bin/"

Inicia a nova instância de banco de dados usando um destes comandos:
```
root # /usr/sbin/rcpostgresql start
```
ou
```
root # systemctl start postgresql.service
```
(dependendo da versão do SLE que você usa como a versão inicial para o upgrade).
Verifique se a migração foi bem-sucedida. O escopo do teste depende do seu caso de uso, e não há nenhuma ferramenta geral para automatizar esta etapa.

Remova qualquer pacote antigo do PostgreSQL e o diretório de dados antigo:

root # zypper search -s postgresql96 | xargs zypper rm -u
root # rm -rf /var/lib/pgsql/data.old

3.5.3 Criar certificações de servidor não MD5 para aplicativos Java #

Durante a atualização do SP1 para o SP2, os certificados com base em MD5 foram desabilitados como parte de uma correção de segurança. Se você criou certificados como MD5, recrie-os seguindo estas etapas:

Abra um terminal e efetue login como root.
Crie uma chave privada:
```
root # openssl genrsa -out server.key 1024
```
Para uma chave mais forte, substitua 1024 por um número mais alto. Por exemplo, 4096.
Crie uma CSR (Certificate Signing Request - Solicitação de Autenticação de Certificado):
```
root # openssl req -new -key server.key -out server.csr
```

Autoassine o certificado:

root # openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt

Crie o arquivo PEM:

root # cat server.key server.crt > server.pem

Armazene os arquivos server.crt, server.csr, server.key e server.pem nos respectivos diretórios onde estão as chaves. Para o Tomcat, por exemplo, o diretório é /etc/tomcat/ssl/.

3.6 Encerrar convidados de máquinas virtuais #

Se a sua máquina atuar como Servidor de Host de VM do KVM ou Xen, encerre apropriadamente todos os Convidados de VM em execução antes da atualização. Do contrário, pode não ser possível acessar os convidados após a atualização.

3.7 Ajustando a configuração do cliente SMT #

Se a máquina que você deseja fazer upgrade estiver registrada como um cliente em um servidor SMT, tome os seguintes cuidados:

Verifique se a versão do script clientSetup4SMT.sh no seu host está atualizada. O clientSetup4SMT.sh de versões mais antigas da SMT não pode gerenciar clientes da SMT 12. Se você aplicar patches de software regularmente ao servidor SMT, sempre encontrará a versão mais recente do clientSetup4SMT.sh em <NOMEDEHOST_SMT>/repo/tools/clientSetup4SMT.sh.

Em caso de falha no upgrade da máquina para uma versão superior do SUSE Linux Enterprise Server, cancele o registro da máquina do servidor SMT, conforme descrito no Procedimento 3.1. Em seguida, reinicie o processo de upgrade.

Procedimento 3.1: Cancelando o registro de um cliente SUSE Linux Enterprise do servidor SMT #

Efetue login na máquina do cliente.

A etapa seguinte depende do sistema operacional atual do cliente:

Para o SUSE Linux Enterprise 11, execute os seguintes comandos:

tux > sudo suse_register -E
tux > sudo rm -f /etc/SUSEConnect
tux > sudo rm -rf /etc/zypp/credentials.d/*
tux > sudo rm -rf /etc/zypp/repos.d/*
tux > sudo rm -f /etc/zypp/services.d/*
tux > sudo rm -f /var/cache/SuseRegister/*
tux > sudo rm -f /etc/suseRegister*
tux > sudo rm -f /var/cache/SuseRegister/lastzmdconfig.cache
tux > sudo rm -f /etc/zmd/deviceid
tux > sudo rm -f /etc/zmd/secret

Para o SUSE Linux Enterprise 12, execute os seguintes comandos:

tux > sudo SUSEConnect --de-register
tux > sudo SUSEConnect --cleanup
tux > sudo rm -f /etc/SUSEConnect
tux > sudo rm -rf /etc/zypp/credentials.d/*
tux > sudo rm -rf /etc/zypp/repos.d/*
tux > sudo rm -f /etc/zypp/services.d/*

Efetue login no servidor SMT.
Verifique se o registro do cliente foi cancelado com êxito listando todos os registros do cliente:
```
tux > sudo smt-list-registrations
```
Se o nome de host do cliente ainda constar na lista retornada por esse comando, obtenha o ID Exclusivo do cliente na primeira coluna. (O cliente pode ser listado com vários IDs.)

Apague o registro desse cliente:

tux > sudo smt-delete-registration -g UNIQUE_ID

Se o cliente estiver listado com vários IDs, repita a etapa acima para cada um dos IDs exclusivos.
Agora, verifique se o registro do cliente foi cancelado com êxito executando novamente:
```
tux > sudo smt-list-registrations
```

3.8 Espaço em disco #

O software tende a crescer a cada versão. Portanto, verifique o espaço da partição disponível antes de atualizar. Se você suspeitar que esteja ficando sem espaço em disco, faça backup dos dados antes de aumentar o espaço disponível redimensionando as partições, por exemplo. Não há uma regra geral sobre a quantidade de espaço que cada partição deve ter. As exigências de espaço dependem do seu perfil de particionamento específico e do software selecionado.

Nota: Verificação automática de espaço suficiente no YaST

Durante o procedimento de atualização, o YaST verificará a quantidade disponível de espaço livre em disco e mostrará um aviso para o usuário se houver a possibilidade de a instalação exceder essa quantidade. Nesse caso, a atualização pode tornar o sistema inutilizável! Somente se você souber exatamente o que está fazendo (testando com antecedência), poderá ignorar o aviso e continuar a atualização.

3.8.1 Verificando o espaço em disco em sistemas de arquivos não Btrfs #

Use o comando df para listar o espaço em disco disponível. Por exemplo, em Exemplo 3.1, “Listar com df -h”, a partição raiz é /dev/sda3 (montada como /).

Exemplo 3.1: Listar com df -h #

Filesystem     Size  Used Avail Use% Mounted on
/dev/sda3       74G   22G   53G  29% /
tmpfs          506M     0  506M   0% /dev/shm
/dev/sda5      116G  5.8G  111G   5% /home
/dev/sda1       44G    4G   40G   9% /data

3.8.2 Verificando o espaço em disco em sistemas de arquivos de raiz Btrfs #

Em um sistema de arquivos Btrfs, a saída do df pode gerar confusão, porque além do espaço alocado pelos dados brutos, esse sistema de arquivos também aloca e usa espaço para os metadados.

Consequentemente, um sistema de arquivos Btrfs pode informar que está sem espaço mesmo que pareça ter bastante espaço ainda disponível. Nesse caso, todo o espaço alocado para os metadados está em uso. Para obter detalhes sobre como verificar espaço usado e disponível em um sistema de arquivos Btrfs, consulte o Section 1.2.2.3, “Checking for Free Space”. Para obter mais informações, consulte man 8 btrfs-filesystem e https://btrfs.wiki.kernel.org/index.php/FAQ.

Se você usa o Btrfs como sistema de arquivos raiz em sua máquina, verifique se há espaço suficiente. Verifique o espaço disponível em todas as partições montadas. Na pior das hipóteses, um upgrade precisará do mesmo espaço em disco que o sistema de arquivos raiz atual (sem /.snapshot) para um novo instantâneo.

As recomendações a seguir foram comprovadas:

Para todos os sistemas de arquivos, incluindo o Btrfs, você precisa de espaço livre suficiente em disco para fazer download e instalar RPMs grandes. O espaço dos RPMs antigos serão liberados apenas depois da instalação dos novos RPMs.
Para Btrfs com instantâneos, você precisa, no mínimo, do mesmo espaço livre que o espaço usado por sua instalação. Recomendamos ter o dobro de espaço livre da instalação atual.
Se você não tiver espaço livre suficiente, poderá tentar apagar instantâneos antigos com o comando snapper:
```
root # snapper list
root # snapper delete NUMBER
```
Porém, isso talvez não ajude em todos os casos. Antes da migração, a maioria dos instantâneos ocupa apenas um pouco de espaço.

3.9 Fazendo upgrade do servidor SMT (Subscription Management Tool) #

Um servidor que executa a SMT requer um procedimento de upgrade especial. Consulte o Chapter 2, Migrate from SMT to RMT no Guia da Repository Management Tool.

3.10 Desabilitando temporariamente o suporte à multiversão do kernel #

O SUSE Linux Enterprise Server permite instalar várias versões do kernel habilitando as respectivas configurações em /etc/zypp/zypp.conf. O suporte a esse recurso precisa ser temporariamente desabilitado para fazer upgrade de um pacote de serviço. Quando a atualização for concluída com êxito, o suporte à multiversão poderá ser reabilitado. Para desabilitar o suporte à multiversão, comente as respectivas linhas em /etc/zypp/zypp.conf. O resultado deve ser semelhante a:

#multiversion = provides:multiversion(kernel)
#multiversion.kernels = latest,running

Para reativar esse recurso após a atualização bem-sucedida, remova os sinais de comentário. Para obter mais informações sobre o suporte à multiversão, consulte o Seção 21.1, “Habilitando e configurando suporte multiversão”.

3.11 Fazendo upgrade no IBM Z #

O upgrade de uma instalação do SUSE Linux Enterprise no IBM Z requer o parâmetro de kernel Upgrade=1. Por exemplo, usando o parmfile. Consulte o Seção 5.4, “Parmfile: automatizando a configuração do sistema”.

3.12 IBM POWER: iniciando um servidor X #

No SLES 12 para IBM POWER, o gerenciador de exibição é configurado para não iniciar um Servidor X local por padrão. Essa configuração foi revertida no SLES 12 SP1: o gerenciador de exibição agora inicia um Servidor X.

Para evitar problemas durante o upgrade, a configuração do SUSE Linux Enterprise Server não é mudada automaticamente. Para que o gerenciador de exibição inicie um Servidor X após o upgrade, mude a configuração de DISPLAYMANAGER_STARTS_XSERVER em /etc/sysconfig/displaymanager da seguinte forma:

DISPLAYMANAGER_STARTS_XSERVER="yes"