documentation.suse.com / Documentação do SUSE Linux Enterprise Server / Guia de Upgrade / Preparando o upgrade
Aplica-se a SUSE Linux Enterprise Server 15 SP3

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

  • 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.

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

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

    root # zypper lr -e repositories.bak

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

  3. 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
    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 certificados com base em MySQL, PostgreSQL ou Java MD5 no SUSE Linux Enterprise Server 11 SP4, prepare seu sistema conforme descrito nas seções a seguir. Além disso, verifique as outras seções deste capítulo para obter mais informações sobre os preparativos necessários.

3.5.1 Migrar o banco de dados PostgreSQL

 

Se você usa um banco de dados PostgreSQL no SUSE Linux Enterprise Server 11, precisa fazer upgrade dele. Para obter mais informações, consulte a Seção 3.6, “Migrar o banco de dados PostgreSQL”.

3.5.2 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:

  1. Efetue login na máquina do SUSE Linux Enterprise 11.

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

  3. 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.

  4. 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.

  5. 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.

  6. Inicie o servidor MariaDB: 

    root # systemctl start mariadb

    Para iniciar o servidor MariaDB em cada boot, habilite o serviço: 

    root # systemctl enable mariadb

  7. Verifique se o MariaDB está sendo executado apropriadamente conectando-se com o banco de dados: 

    root # mariadb -u root -p

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:

  1. Abra um terminal e efetue login como root.

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

  3. Crie uma CSR (Certificate Signing Request - Solicitação de Autenticação de Certificado): 

    root # openssl req -new -key server.key -out server.csr

  4. Autoassine o certificado: 

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

  5. Crie o arquivo PEM: 

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

  6. 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 Migrar o banco de dados PostgreSQL

 

O SUSE Linux Enterprise Server 15 SP3 é fornecido com as versões 10, 12 e 13 do banco de dados PostgreSQL. Embora a versão 13 seja o padrão, as versões 10 e 12 ainda são fornecidas 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/postgres12/ para a versão 12. 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 o https://www.postgresql.org/support/versioning/.

Importante
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:

  1. 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 SP3, 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

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

  3. Renomeie o diretório de dados antigo: 

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

  4. 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).

  5. 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.

  6. 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/"

  7. 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).

  8. 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.

  9. 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

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/10/upgrading.html.

3.7 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.8 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 de um servidor SMT
 

  1. Efetue login na máquina do cliente.

  2. 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/*

  3. Efetue login no servidor SMT.

  4. Verifique se o registro do cliente foi cancelado com êxito listando todos os registros de clientes: 

    tux > sudo smt-list-registrations

  5. 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.)

  6. Apague o registro desse cliente: 

    tux > sudo smt-delete-registration -g UNIQUE_ID

  7. Se o cliente estiver listado com vários IDs, repita a etapa acima para cada um dos IDs exclusivos.

  8. Agora, verifique se o registro do cliente foi cancelado com êxito executando novamente: 

    tux > sudo smt-list-registrations

3.9 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
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.9.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.9.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 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.10 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.11 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 Management Tool.

3.12 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 23.1, “Habilitando e configurando suporte multiversão”.

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

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