Ir para o conteúdoIr para navegação de página: página anterior [tecla de acesso p]/próxima página [tecla de acesso n]
documentation.suse.com / Documentação do SUSE Linux Enterprise Server / Deployment Guide / Updating and Upgrading SUSE Linux Enterprise / Fazendo upgrade do SUSE Linux Enterprise
Aplica-se a SUSE Linux Enterprise Server 12 SP5

19 Fazendo upgrade do SUSE Linux Enterprise

O SUSE® Linux Enterprise (SLE) permite fazer upgrade de um sistema existente para a nova versão. Não há necessidade de uma nova instalação. Dados existentes, como diretórios pessoais e de dados e configuração do sistema, permanecem intactos. É possível atualizar de uma unidade de CD ou DVD local ou de uma fonte de instalação de rede central.

Este capítulo explica como fazer upgrade manualmente do sistema SUSE Linux Enterprise, seja de DVD, da rede, de um processo automatizado ou do SUSE Manager.

19.1 Caminhos de upgrade suportados para o SLE 12 SP5

Visão geral dos caminhos de upgrade suportados
Figura 19.1: Visão geral dos caminhos de upgrade suportados
Importante
Importante: Upgrades compatíveis com várias arquiteturas não são suportados

Upgrades compatíveis com várias arquiteturas, como um upgrade da versão de 32 bits do SUSE Linux Enterprise Server para a versão de 64 bits, ou de big endian para little endian, não são suportados!

Especificamente, o upgrade do SLE 11 on POWER (big endian) para o SLE 12 SP2 on POWER (novo: little endian!) não é suportado.

Além disso, como o SUSE Linux Enterprise 12 é apenas de 64 bits, os upgrades de qualquer sistema SUSE Linux Enterprise 11 de 32 bits para o SUSE Linux Enterprise 12 e posterior não são suportados.

Para fazer um upgrade compatível com várias arquiteturas, você precisa executar uma nova instalação.

Nota
Nota: Ignorando os Service Packs

O caminho de upgrade mais seguro é seguir o passo a passo e instalar todos os Service Packs consecutivamente. Em alguns casos, é permitido ignorar um ou dois Service Packs durante o upgrade. Para obter os detalhes, consulte Caminhos de upgrade suportados por versão e a Figura 19.1, “Visão geral dos caminhos de upgrade suportados”. No entanto, recomendamos não ignorar nenhum Service Pack.

Nota
Nota: Fazendo upgrade para as versões principais

Recomendamos executar uma nova instalação ao fazer upgrade para uma nova versão principal.

Caminhos de upgrade suportados por versão
Fazendo upgrade do SUSE Linux Enterprise 10 (qualquer Service Pack)

Não há um caminho de migração direto suportado para o SUSE Linux Enterprise 12. Recomendamos uma nova instalação neste caso.

Fazendo upgrade do SUSE Linux Enterprise 11 GA/SP1/SP2/SP3

Não há um caminho de migração direto suportado para o SUSE Linux Enterprise 12. No mínimo, você precisa do SLE 11 SP4 antes de prosseguir para o SLE 12 SP5.

Se você não pode executar uma nova instalação, primeiramente faça upgrade do SLE 11 Service Pack para o SLE 11 SP4. Estas etapas estão descritas no Guia de Implantação do SUSE Linux Enterprise 11: https://documentation.suse.com/sles-11/ .

Fazendo upgrade do SUSE Linux Enterprise 11 SP4

O upgrade do SLE 11 SP5 para o SLE 12 SP4 apenas é suportado por meio de um upgrade offline. Consulte o Capítulo 20, Fazendo upgrade offline para obter os detalhes.

Fazendo upgrade do SUSE Linux Enterprise 12 GA/SP1/SP2 para SP5

Não há suporte para upgrades diretos do SLE 12 GA, SP1 ou SP2 para SP5. Faça primeiro o upgrade para o SLE 12 SP3 ou SP4.

Fazendo upgrade do SUSE Linux Enterprise 12 SP3/SP4 para SP5

O upgrade do SUSE Linux Enterprise 12 SP3 ou SP4 para o SP5 é suportado.

Fazendo upgrade do SUSE Linux Enterprise 12 LTSS GA/SP1 para SP5

Não há suporte para upgrades diretos do SUSE Linux Enterprise 12 LTSS GA ou SP1 para SP5. Faça upgrade primeiro para o SLE 12 LTSS SP2.

Fazendo upgrade do SUSE Linux Enterprise 12 LTSS SP2/SP3/SP4 para SP5

O upgrade do SUSE Linux Enterprise 12 LTSS SP2, SP3 ou SP4 para SP5 é suportado.

19.2 Upgrade online e offline

O SUSE oferece suporte a dois métodos diferentes de upgrade e migração. Para obter mais informações sobre a terminologia, consulte a Seção 18.1, “Terminologia”. Os métodos são:

Online

Todos os upgrades executados de um sistema em execução são considerados online. Exemplos: Conectado por SUSE Customer Center, SMT (Subscription Management Tool), SUSE Manager usando Zypper ou YaST.

Ao migrar entre Service Packs da mesma versão principal, sugerimos a Seção 21.4, “Fazendo upgrade com a ferramenta Migração Online (YaST)” ou a Seção 21.5, “Fazendo upgrade com o Zypper” a seguir.

Offline

Normalmente, os métodos offline inicializam outro sistema operacional do qual é feito o upgrade da versão instalada do SLE. Os exemplos são: DVD, disco flash, imagem ISO, AutoYaST, RPM simples ou boot PXE.

Importante
Importante: Clientes SUSE Manager

Se a máquina é gerenciada pelo SUSE Manager, o procedimento de upgrade deve ser iniciado na interface de gerenciamento. Para obter os detalhes, consulte a Seção 20.6, “Atualizando pelo SUSE Manager”.

19.3 Preparando o sistema

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.

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

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

Encontre os detalhes da versão localmente no diretório /usr/share/doc/release-notes ou online em https://www.suse.com/releasenotes/.

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

19.3.3.1 Listando os pacotes e repositórios instalados

Muitas vezes, convém ter 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 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
root # zypper install $(cat installed-software.bak)
Nota
Nota: A quantidade 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 são divididos para permitir uma seleção de pacote mais detalhada. Por exemplo, 37 pacotes texlive no SLE 11 foram divididos em 422 pacotes no SLE 12.

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

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

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

    root # systemctl enable mysql
  7. Verifique se o MariaDB está sendo executado apropriadamente conectando-se com o banco de dados:

    root # mysql -u root -p

19.3.5 Migrar o banco de dados PostgreSQL

Uma versão mais recente do banco de dados PostgreSQL foi incluída como atualização de manutenção. 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
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 12 SP5, 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 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.

  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. Não existe uma ferramenta geral para automatizar essa 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

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

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

19.3.8 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 19.1. Em seguida, reinicie o processo de upgrade.

Procedimento 19.1: Cancelando o registro de um cliente SUSE Linux Enterprise do 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 do cliente:

    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

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

19.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 19.1, “Listar com df -h, a partição raiz é /dev/sda3 (montada como /).

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

19.3.9.2 Verificando o espaço em disco em sistemas de arquivos de raiz Btrfs

Se você usa o Btrfs como sistema de arquivos raiz em sua máquina, verifique se há espaço suficiente. 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. Para exibir o espaço em disco disponível, use o comando:

root # df -h /

Verifique também o espaço disponível em todas as outras partições montadas. 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.

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

19.4 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 4.3, “Arquivo parmfile: automatizando a configuração do sistema”.

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