Aplica-se a SUSE Linux Enterprise Server 15 SP4

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. O capítulo a seguir orientará você durante essas etapas.

3.1 Verificar se o sistema está atualizado #

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

3.2 Ler as notas de versão #

Encontre uma lista de todas as mudanças, novos recursos e problemas conhecidos nas notas de versão. Você também pode encontrar as notas de versão na mídia de instalação no diretório docu.

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

Consulte os detalhes da versão para verificar se as seguintes afirmativas são verdadeiras:

Seu hardware precisa de considerações especiais
Qualquer pacote de software usado foi significativamente modificado
Sua instalação requer cuidados especiais

3.3 Fazer um backup #

Antes de fazer upgrade, faça backup dos dados copiando os arquivos de configuração existentes para um meio separado (como dispositivo de fita, disco rígido removível etc). 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 backup de todos os dados como root. Apenas o usuário root tem permissões suficientes 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 Verificar o espaço em disco disponível #

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.4.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.4.2 Verificando o espaço em disco em sistemas de arquivos 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 o 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.

Ao usar o Btrfs como sistema de arquivos raiz em sua máquina, verifique se há espaço livre 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 a instalação atual usa. 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:
```
# snapper list
      # 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.5 Listando os pacotes e repositórios instalados #

É possível 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.

Nota

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:
```
# zypper lr -e repositories.bak
```
Crie também um arquivo denominado installed-software.bak com uma lista de todos os pacotes instalados:
```
# 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:
```
# zypper ar repositories.bak.repo
# 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.6 Desabilitar a extensão LTSS #

Se você fizer upgrade de um sistema SUSE Linux Enterprise Server com o Long Term Service Pack Support (LTSS) para uma versão que ainda esteja sob suporte geral, haverá falha no upgrade com o erro No migration available (Nenhuma migração disponível). Isso acontece porque o comando zypper migration tenta migrar todos os repositórios, mas ainda não há um repositório LTSS para a nova versão.

Para corrigir esse problema, desabilite a extensão LTSS antes do upgrade.

Verifique se a extensão LTSS está habilitada:

> sudo SUSEConnect --list-extensions | grep LTSS
SUSE Linux Enterprise Server LTSS 12 SP4 x86_64 (Installed)
Deactivate with: SUSEConnect -d -p SLES-LTSS/12.4/x86_64

Desabilite a extensão LTSS com o comando da saída SUSEConnect acima:

> sudo SUSEConnect -d -p SLES-LTSS/12.4/x86_64
Deregistered SUSE Linux Enterprise Server LTSS 12 SP4 x86_64
To server: https://scc.suse.com/

Verifique se o repositório LTSS não está mais presente com zypper lr.

3.7 Migrar o banco de dados PostgreSQL #

O SUSE Linux Enterprise Server 15 SP4 é fornecido com as versões 13 e 14 do banco de dados PostgreSQL. A versão 14 é a padrão, mas a versão 13 ainda é fornecida por meio do módulo Legacy para upgrades de versões anteriores do SUSE Linux Enterprise Server.

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, no /usr/lib/postgresql10/ para a versão 10 e no /usr/lib/postgres13/ para a versão 13. 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 12 para 13. 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 SP4, isso significa instalar o postgresql13-server e todos os pacotes dos quais ele depende.
- Instale o pacote postgresql13-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:
```
# /usr/sbin/rcpostgresql stop
```
ou
```
# 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:

# 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:
```
# /usr/sbin/rcpostgresql start
# /usr/sbin/rcpostgresql stop
```
ou
```
# systemctl start postgresql.service
# 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 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:

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

Inicia a nova instância de banco de dados usando um destes comandos:
```
# /usr/sbin/rcpostgresql start
```
ou
```
# 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:

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

Para obter mais informações sobre o upgrade de bancos de dados ou o uso de métodos alternativos, como replicação lógica, consulte a documentação oficial do PostgreSQL em https://www.postgresql.org/docs/13/upgrading.html.

3.8 Migrar o banco de dados MySQL ou MariaDB #

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:

Crie um arquivo de dump:
```
# mysqldump -u root -p --all-databases --add-drop-database > 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://mariadb.com/kb/en/mariadb-dumpmysqldump/.
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 do SUSE Linux Enterprise Server. 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:
```
# systemctl start mariadb
```
Para iniciar o servidor MariaDB em cada boot, habilite o serviço:
```
# systemctl enable mariadb
```
Verifique se o MariaDB está sendo executado apropriadamente conectando-se com o banco de dados:
```
# mariadb -u root -p
```

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

Como medida de segurança, os certificados baseados em MD5 não são mais suportados no Java. Se você criou certificados como MD5, recrie-os seguindo estas etapas:

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

Autoassine o certificado:

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

Crie o arquivo PEM:

# 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.10 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.11 Ajustar 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 de um 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:

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

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

> sudo SUSEConnect --de-register
> sudo SUSEConnect --cleanup
> sudo rm -f /etc/SUSEConnect
> sudo rm -rf /etc/zypp/credentials.d/*
> sudo rm -rf /etc/zypp/repos.d/*
> 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 de clientes:
```
> 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:

> 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:
```
> sudo smt-list-registrations
```

3.12 Mudanças nos perfis do AutoYaST do SLE 12 para 15 #

Para saber como migrar perfis do AutoYaST, consulte o Appendix D, Differences between AutoYaST profiles in SLE 12 and 15.

3.13 Fazendo upgrade de um servidor SMT (Subscription Management Tool) #

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

3.14 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 Section 27.1, “Enabling and configuring multiversion support”.

3.15 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 a Seção 5.6, “Parmfile: automatizando a configuração do sistema”.

3.16 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"