Ir para o conteúdo
documentation.suse.com / Guia de Upgrade
SUSE Linux Enterprise Server 15 SP4

Guia de Upgrade

Este guia orienta você durante os upgrades do SUSE Linux Enterprise Server. Se você usa o SUSE Linux Enterprise Server como sistema base para outros produtos ou extensões do SLE, consulte também a documentação desses produtos para obter informações de upgrade específicas do produto ou da extensão.

Data de Publicação: 11 de dezembro de 2023
Lista de Exemplos

Copyright © 2006-2023 SUSE LLC e colaboradores. Todos os direitos reservados.

Permissão concedida para copiar, distribuir e/ou modificar este documento sob os termos da Licença GNU de Documentação Livre, Versão 1.2 ou (por sua opção) versão 1.3; com a Seção Invariante sendo estas informações de copyright e a licença. Uma cópia da versão 1.2 da licença está incluída na seção intitulada GNU Free Documentation License (Licença GNU de Documentação Livre).

Para ver as marcas registradas da SUSE, visite https://www.suse.com/company/legal/. Todas as marcas comerciais de terceiros pertencem a seus respectivos proprietários. Os símbolos de marca registrada (®, ™ etc.) indicam as marcas registradas da SUSE e de suas afiliadas. Os asteriscos (*) indicam marcas registradas de terceiros.

Todas as informações deste manual foram compiladas com a maior atenção possível aos detalhes. Entretanto, isso não garante uma precisão absoluta. A SUSE LLC, suas afiliadas, os autores ou tradutores não serão responsáveis por possíveis erros nem pelas consequências resultantes de tais erros.

Prefácio

1 Documentação disponível

Documentação online

A documentação online deste produto está disponível em https://documentation.suse.com/#sles. Procure ou faça download da documentação em vários formatos.

Encontre a documentação online de outros produtos em https://documentation.suse.com/.

Nota
Nota: Atualizações mais recentes

Normalmente, as atualizações mais recentes estão disponíveis na versão em inglês da documentação.

Notas de versão

Para ver as notas de versão, visite https://www.suse.com/releasenotes/.

Em seu sistema

Para uso offline, encontre a documentação no sistema instalada em /usr/share/doc. Muitos comandos também estão descritos em detalhes nas respectivas páginas de manual. Para vê-los, execute man, seguido do nome de um comando específico. Se o comando man não estiver instalado no sistema, instale-o com sudo zypper install man.

2 Melhorando a documentação

Seus comentários e suas contribuições para esta documentação são bem-vindos. Os seguintes canais para fornecer feedback estão disponíveis:

Solicitações de serviço e suporte

Para conhecer os serviços e as opções de suporte disponíveis para o seu produto, consulte https://www.suse.com/support/.

Para abrir uma solicitação de serviço, você precisa de uma assinatura do SUSE registrada no SUSE Customer Center. Vá para https://scc.suse.com/support/requests, efetue login e clique em Criar Novo.

Relatórios de bugs

Relate os problemas com a documentação em https://bugzilla.suse.com/. Para simplificar esse processo, você pode usar o link Report an issue (Relatar um problema) na versão HTML deste documento. Posicione o cursor na frase afetada e, na seção Give feedback (Enviar comentários) do painel de navegação direito, clique em Report an issue. O produto e a categoria certos são pré-selecionados no Bugzilla e um link é adicionado à seção atual. Você pode começar a digitar o relatório do bug imediatamente. Uma conta do Bugzilla é necessária.

Contribuições

Para contribuir com esta documentação, use o link Edit source document (Editar documento de origem) na versão HTML deste documento. Posicione o cursor na frase afetada e, na seção Give feedback (Enviar comentários) do painel de navegação direito, clique em Edit source document (Editar documento de origem). Esse procedimento leva você até o código-fonte no GitHub, onde é possível abrir uma solicitação pull. Uma conta do GitHub é necessária.

Nota
Nota: Edit source document está disponível apenas para inglês

Os links Edit source document estão disponíveis apenas para a versão em inglês de cada documento. Para todos os outros idiomas, use o link Report an issue conforme descrito acima.

Para obter mais informações sobre o ambiente da documentação usado para este documento, consulte o README do repositório em https://github.com/SUSE/doc-sle/blob/main/README.adoc

E-mail

É possível também relatar erros e enviar comentários sobre a documentação para <>. Inclua o título do documento, a versão do produto e a data de publicação do documento. Mencione também o número e o título da seção relevante (ou inclua o URL) e insira uma breve descrição do problema.

3 Convenções da documentação

Os seguintes avisos e convenções tipográficas são usados nesta documentação:

  • /etc/passwd: nomes de diretório e arquivo

  • MARCADOR: substitua MARCADOR pelo valor real

  • PATH: a variável do ambiente PATH

  • ls, --help: comandos, opções e parâmetros

  • user: usuários ou grupos

  • package name: nome de um pacote

  • Alt, AltF1: uma tecla ou uma combinação de teclas a serem pressionadas; as teclas são mostradas em letras maiúsculas como aparecem no teclado

  • Arquivo, Arquivo ›  Gravar Como : itens de menu, botões

  • AMD/Intel Este parágrafo é relevante apenas para a arquitetura AMD64/Intel 64. As setas marcam o início e o fim do bloco de texto.

    IBM Z, POWER Este parágrafo é relevante apenas para as arquiteturas IBM Z e POWER. As setas marcam o início e o fim do bloco de texto.

  • Pinguins Dançarinos (Capítulo Pinguins, ↑Outro Manual): É uma referência a um capítulo de outro manual.

  • Comandos que devem ser executados com privilégios root. Geralmente, você também pode usar o comando sudo como prefixo nesses comandos para executá-los como usuário não privilegiado.

    # command
    > sudo command
  • Comandos que podem ser executados por usuários sem privilégios.

    > command
  • Avisos

    Atenção
    Atenção: Mensagem de aviso

    Informações vitais que você deve saber antes de continuar. Avisa sobre problemas de segurança, potencial perda de dados, danos no hardware ou perigos físicos.

    Importante
    Importante: Aviso importante

    Informações importantes que você deve saber antes de continuar.

    Nota
    Nota: Nota

    Informações adicionais, por exemplo, sobre diferenças nas versões do software.

    Dica
    Dica: Aviso de dica

    Informações úteis, como uma diretriz ou informação prática.

4 Suporte

Encontre a declaração de suporte para o SUSE Linux Enterprise Server e as informações gerais sobre as prévias de tecnologia a seguir. Para obter detalhes sobre o ciclo de vida do produto, consulte o Capítulo 2, Ciclo de vida e suporte.

Se você tiver direito a suporte, encontre os detalhes de como coletar informações para um ticket de suporte no Book “Administration Guide”, Chapter 47 “Gathering system information for support”.

4.1 Declaração de suporte para o SUSE Linux Enterprise Server

Para receber suporte, você precisa de uma inscrição apropriada na SUSE. Para ver as ofertas de suporte específicas que estão disponíveis para você, acesse https://www.suse.com/support/ e selecione seu produto.

Os níveis de suporte são definidos da seguinte forma:

L1

Determinação do problema, que significa suporte técnico designado para fornecer informações de compatibilidade, suporte ao uso, manutenção contínua, coleta de informações e solução básica de problemas usando a documentação disponível.

L2

Isolamento do problema, que significa suporte técnico designado para analisar os dados, reproduzir os problemas dos clientes, isolar as áreas problemáticas e resolver os problemas não resolvidos no Nível 1 ou preparar-se para o Nível 3.

L3

Resolução do problema, que significa suporte técnico designado para resolver os problemas com a participação da engenharia para solucionar defeitos nos produtos que foram identificados pelo Suporte de Nível 2.

Para clientes e parceiros contratados, o SUSE Linux Enterprise Server foi entregue com suporte L3 para todos os pacotes, com exceção do seguinte:

  • prévias de tecnologia

  • som, gráficos, fontes e arte

  • pacotes que requerem um contrato de cliente adicional

  • alguns pacotes enviados como parte do módulo Workstation Extension contam apenas com suporte L2

  • os pacotes com nomes que terminam em -devel (contendo arquivos de cabeçalho e recursos de desenvolvedor semelhantes) serão suportados apenas junto com seus pacotes principais.

A SUSE apenas oferecerá suporte ao uso dos pacotes originals. Isto é, pacotes que não foram modificados nem recompilados.

4.2 Prévias de tecnologia

As Prévias de tecnologia são pacotes, pilhas ou recursos fornecidos pela SUSE como amostras de inovações futuras. As prévias estão incluídas para sua conveniência e para que você possa testar as novas tecnologias em seu ambiente. Agradecemos seus comentários! Se você testar uma prévia de tecnologia, contate seu representante SUSE e conte sobre sua experiência e seus casos de uso. Suas informações são úteis para o desenvolvimento futuro.

No entanto, as prévias de tecnologia são fornecidas com as seguintes limitações:

  • As prévias de tecnologia ainda estão em desenvolvimento. Portanto, elas podem ter funcionalidades incompletas, instáveis ou, de alguma outra maneira, inadequadas para uso em produção.

  • As prévias de tecnologia não contam com suporte.

  • As prévias de tecnologia talvez estejam disponíveis apenas para arquiteturas de hardware específicas.

  • Os detalhes e as funcionalidades das prévias de tecnologia estão sujeitos a mudanças. Consequentemente, o upgrade para as versões subsequentes de uma prévia de tecnologia pode ser impossível e exigir uma instalação nova.

  • As prévias de tecnologia podem ser descartadas a qualquer momento. Por exemplo, se a SUSE descobrir que uma prévia não atende às necessidades do cliente ou do mercado ou não cumpre os padrões da empresa. A SUSE não se compromete em oferecer uma versão com suporte desse tipo de tecnologia no futuro.

Para obter uma visão geral das prévias de tecnologia fornecidas com seu produto, consulte as notas de lançamento em https://www.suse.com/releasenotes/.

1 Caminhos e métodos de upgrade

O SUSE® Linux Enterprise (SLE) permite fazer upgrade de um sistema existente para a nova versão, por exemplo, do SLE 12 SP4 para o pacote de serviço mais recente do SLE 15. 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.

1.1 Comparação entre upgrade e nova instalação

Os upgrades entre duas versões principais do SUSE Linux Enterprise Server são suportados pelo SUSE. O seu cenário específico é que dita se é melhor fazer upgrade ou executar uma nova instalação. Os upgrades envolvem menos trabalho, mas as novas instalações garantem que você aproveite todos os novos recursos de uma versão, como mudanças de layout de disco, recursos específicos do sistema de arquivos e outros aprimoramentos. Portanto, para aproveitar o seu sistema ao máximo, a SUSE recomenda novas instalações na maioria dos cenários.

Nos dois casos, upgrade e nova instalação, os clientes ainda precisam verificar se as configurações do sistema e os valores padrão atendem aos seus requisitos.

Para atualizações de um pacote de serviço de uma versão específica para outro do mesmo fluxo de código, a SUSE recomenda executá-la no local, em vez de uma nova instalação. No entanto, pode haver motivos e cenários para um cliente executar uma nova instalação também nesse caso. Apenas o cliente pode tomar a decisão sobre a opção mais adequada.

1.2 Caminhos de upgrade suportados para o SLES 15 SP4

Antes de fazer qualquer migração, leia o Capítulo 3, Preparando o upgrade.

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 15 SP4 on POWER (novo: little endian!) não é suportado.

Além disso, como o SUSE Linux Enterprise 15 é apenas de 64 bits, os upgrades de qualquer sistema SUSE Linux Enterprise 11 de 32 bits para o SUSE Linux Enterprise 15 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 pacotes de serviço

O caminho de upgrade mais fácil é instalar consecutivamente todos os pacotes de serviço. Para a linha de produtos SUSE Linux Enterprise 15 (GA e os pacotes de serviço posteriores), é permitido também pular até dois pacotes de serviço ao fazer upgrade. Por exemplo, o upgrade do SLE 15 GA para o 15 SP3 é permitido (desde que o SLE 15 GA seja suportado).

Visão geral dos caminhos de upgrade suportados
Figura 1.1: Visão geral dos caminhos de upgrade suportados
Atenção
Atenção: Fazendo upgrade de bancos de dados

Os caminhos de upgrade descritos aqui são válidos apenas para o SUSE Linux Enterprise como sistema operacional de uma máquina, e não para todos os aplicativos que ele executa. Se você tiver cargas de trabalho, como bancos de dados PostgreSQL ou MariaDB, talvez sejam necessários upgrades de OS intermediários para fazer upgrade dos bancos de dados.

Antes de fazer upgrade do sistema operacional, consulte as Notas de versão para obter informações sobre as versões de banco de dados. Se uma nova versão principal for fornecida, consulte o Capítulo 3, Preparando o upgrade para obter instruções de upgrade.

Caminhos de upgrade suportados por versão
Upgrade do SUSE Linux Enterprise Server 11

O upgrade direto do SLES 11  não é suportado. No mínimo, você precisa do SLES 11 SP4 e apenas pode fazer upgrade para o SLES 15 SP3 antes de avançar para o SLES 15 SP4.

Se você não pode executar uma nova instalação, primeiramente faça upgrade do pacote de serviço do SLES 11 instalado para o SLES 11 SP4. Esse upgrade está descrito no Guia de Implantação do SLES 11 SP4 . Em seguida, faça um upgrade offline para o SLES 15 SP3. Esse upgrade está descrito no Guia de Implantação do SLES 15 SP3. N sequência, siga as instruções neste guia para fazer upgrade para o SLES 15 SP4.

Fazendo upgrade do SUSE Linux Enterprise Server 12 GA/SP1/SP2/SP3/SP4

O upgrade diretamente do SLES 12 SP4 ou de pacotes de serviço mais antigos não é permitido. No mínimo, você precisa do SLES 12 SP5 antes de avançar para o SLES 15 SP4.

Se você não pode executar uma nova instalação, primeiramente faça upgrade do pacote de serviço do SLES 12 instalado para o SLES 12 SP5. Esse upgrade está descrito no Guia de Implantação do SLES 12 SP5

Fazendo upgrade do SUSE Linux Enterprise Server 12 SP3 LTSS

O upgrade do SLES 12 SP3 diretamente com o LTSS não é mais suportado. No mínimo, você precisa do SLES 12 SP4 com LTSS antes de avançar para o SLES 15 SP4.

Fazendo upgrade do SUSE Linux Enterprise Server 12 SP4 LTSS

O upgrade do SLES 12  SP4 com LTSS apenas é suportado por meio de um upgrade offline. Consulte o Capítulo 4, Fazendo upgrade offline para obter os detalhes.

Fazendo upgrade do SUSE Linux Enterprise Server 12 SP5

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

Fazendo upgrade do SUSE Linux Enterprise Server 15 GA/SP1/SP2

O upgrade do SLES 15 GA, SP1 ou SP2 diretamente não é mais suportado. No mínimo, você precisa do SLES 15 SP3 antes de avançar para o SLES 15 SP4.

Upgrade do SUSE Linux Enterprise Server 15 GA LTSS/SP1 LTSS/SP2 LTSS

O upgrade do SLES 15 GA, SP1 ou SP2 com LTSS é suportado tanto online quanto offline. Consulte a Seção 1.3, “Upgrade online e offline” para obter os detalhes.

Fazendo upgrade do SUSE Linux Enterprise Server 15 SP3

O upgrade do SLES 15 SP1 ou SP2 é suportado tanto online quanto offline. Consulte a Seção 1.3, “Upgrade online e offline” para obter os detalhes.

Fazendo upgrade de convidados de nuvem pública do SUSE Linux Enterprise

Para obter instruções sobre como fazer upgrade de convidados do SLE em nuvens públicas, consulte Usando o sistema de migração de distribuições SUSE.

Upgrade do openSUSE Leap 15.0/15.1/15.2

O upgrade direto do openSUSE Leap 15.0, 15.1 ou 15.2 não é mais suportado. No mínimo, você precisa do openSUSE Leap 15.3 antes de avançar para o SLES 15 SP4.

Upgrade do openSUSE Leap 15.3/15.4

O upgrade do openSUSE Leap 15.3 ou 15.4 é suportado. Consulte a Seção 5.9, “Fazendo upgrade do openSUSE Leap para o SUSE Linux Enterprise Server. Apenas a instalação do servidor do Leap é suportada para fazer um upgrade.

1.3 Upgrade online e offline

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

Online

Upgrades feitos do próprio sistema operacional em execução (estado do sistema ativo e em execução). Exemplos: atualização online com Zypper ou YaST, conectado pelo SUSE Customer Center ou pela Repository Mirroring Tool (RMT), Política Salt pelo SUSE Manager.

Para obter os detalhes, consulte o Capítulo 5, Fazendo upgrade online.

Ao migrar entre Service Packs da mesma versão principal, sugerimos a Seção 5.4, “Fazendo upgrade com a ferramenta de migração online (YaST)” ou a Seção 5.5, “Fazendo upgrade com o Zypper” a seguir.

Offline

O upgrade offline implica no sistema operacional do qual fazer upgrade não estar em execução (estado do sistema inativo). Em vez disso, o instalador para o sistema operacional de destino é inicializado (por exemplo, da mídia de instalação, por rede ou por meio do carregador de boot local) e executa o upgrade.

Para obter os detalhes, consulte o Capítulo 4, Fazendo upgrade offline.

Importante
Importante: Clientes do SUSE Manager

Se sua máquina for gerenciada pelo SUSE Manager, atualize-a conforme descrito na documentação do SUSE Manager. O procedimento de Migração de Cliente está descrito no Guia de Upgrade do SUSE Manager, disponível em https://documentation.suse.com/suma/.

2 Ciclo de vida e suporte

Este capítulo apresenta informações sobre terminologia, ciclos de vida de produtos SUSE, versões de Service Pack e políticas de upgrade recomendadas.

2.1 Terminologia

Esta seção usa vários termos. Para compreender as informações, leia as definições abaixo:

Backporting

Backporting é o ato de adaptar mudanças específicas de uma versão mais recente do software e aplicá-las a uma versão mais antiga. Ele é mais utilizado para corrigir falhas de segurança em componentes de software mais antigos. Normalmente, ele também faz parte de um modelo de manutenção que oferece melhorias ou (menos comum) novos recursos.

RPM Delta

RPM Delta consiste apenas na diferença binária entre duas versões definidas de um pacote e, portanto, tem o menor tamanho de download. Antes de ser instalado, o pacote RPM completo é reconstruído na máquina local.

Downstream

Uma metáfora de como o software é desenvolvido no mundo open source (compare com upstream). O termo downstream refere-se a pessoas ou organizações, como o SUSE, que integram o código-fonte a outros softwares para criar a distribuição que será usada pelos usuários finais. Dessa maneira, o software flui de forma descendente (downstream) de seus desenvolvedores até os usuários finais por meio dos integradores.

Extensões, Produtos complementares

As extensões e os produtos complementares de terceiros oferecem funcionalidades adicionais de valor ao produto para o SUSE Linux Enterprise Server. Elas são fornecidas pelo SUSE e por parceiros do SUSE e são registradas e instaladas em coexistência com o produto base SUSE Linux Enterprise Server.

LTSS

LTSS é a abreviação de Long Term Service Pack Support, que está disponível como uma extensão para o SUSE Linux Enterprise Server.

Versão principal, Versão de disponibilidade geral (GA, General Availability)

A versão principal do SUSE Linux Enterprise (ou qualquer produto de software) é uma nova versão que traz recursos e ferramentas inéditos, desativa componentes que já foram descontinuados e inclui mudanças sem compatibilidade retroativa. Por exemplo, as versões principais são SUSE Linux Enterprise 12 ou 15.

Migração

Atualização para um Service Pack (SP) usando as ferramentas de atualização online ou um meio de instalação para instalar os respectivos patches. Atualiza todos os pacotes do sistema instalado para o estado mais recente.

Destinos de migração

Um conjunto de produtos compatíveis para os quais é possível migrar um sistema, incluindo a versão dos produtos/extensões e o URL do repositório. Os destinos de migração podem mudar ao longo do tempo e dependem das extensões instaladas. É possível selecionar vários destinos de migração.

Módulos

Os módulos são partes do SUSE Linux Enterprise Server totalmente suportadas com um ciclo de vida diferente. Eles têm um escopo claramente definido e são disponibilizados apenas pelo canal online. O registro no SUSE Customer Center, na RMT (Repository Mirroring Tool) ou no SUSE Manager é um pré-requisito para poder assinar esses canais.

Pacote

Pacote é um arquivo comprimido no formato rpm que contém todos os arquivos de determinado programa, incluindo componentes opcionais como configuração, exemplos e documentação.

Patch

Um patch consiste em um ou mais pacotes e pode ser aplicado por meio de RPMs delta. Ele também pode introduzir dependências nos pacotes que ainda não estão instalados.

Service Packs (SP)

Combina vários patches em um formulário fácil de instalar ou implantar. Os service packs são numerados, geralmente contendo correções de segurança, atualizações, upgrades ou aprimoramentos de programas.

Upstream

Uma metáfora de como o software é desenvolvido no mundo open source (compare com downstream). O termo upstream refere-se ao projeto original, autor ou mantenedor de um software que é distribuído como código-fonte. Feedback, patches, melhorias de recursos ou outros aperfeiçoamentos fluem dos usuários finais ou colaboradores até os desenvolvedores de upstream. Eles decidem se a solicitação será integrada ou rejeitada.

Se os membros do projeto decidirem integrar a solicitação, ela aparecerá nas versões mais recentes do software. Uma solicitação aceita beneficia todas as partes envolvidas.

Se a solicitação não for aceita, vários motivos poderão estar em jogo. Talvez seu estado não seja compatível com as diretrizes do projeto, seja inválido, já esteja integrado ou não seja do interesse nem faça parte do plano estratégico do projeto. Uma solicitação não aceita dificulta o trabalho dos desenvolvedores de upstream, já que eles precisam sincronizar seus patches com o código de upstream. Essa prática em geral é evitada, mas às vezes ainda é necessária.

Atualização

Instalação de uma versão de menor importância mais recente de um pacote, que normamente inclui correções de segurança ou bug.

Upgrade

Instalação de uma versão mais recente principal de um pacote ou distribuição, que agrega novos recursos. Para saber a diferença entre as opções de upgrade, consulte a Seção 1.3, “Upgrade online e offline”.

2.2 Ciclo de vida do produto

O SUSE tem o seguinte ciclo de vida de produto:

  • O SUSE Linux Enterprise Server tem um ciclo de vida de 13 anos: 10 anos de suporte geral e três anos de suporte estendido.

  • O SUSE Linux Enterprise Desktop tem um ciclo de vida de 10 anos: sete anos de suporte geral e três anos de suporte estendido.

  • As versões principais são criadas a cada quatro anos. Os service packs são lançados a cada 12 a 14 meses.

O SUSE suporta service packs anteriores durante seis meses após o lançamento do novo service pack. A Figura 2.1, “Versões principais e service packs” mostra alguns aspectos mencionados.

Versões principais e service packs
Figura 2.1: Versões principais e service packs

Se você precisar de mais tempo para criar, validar e testar seus planos de upgrade, o Suporte a Service Pack de Longo Prazo pode estender o suporte que você recebe para mais 12 até 36 meses em incrementos de 12 meses. O resultado disso é um total de 2 a 5 anos de suporte em qualquer pacote de serviço. Para obter os detalhes, consulte a Figura 2.2, “Suporte a service pack de longo prazo”.

Suporte a service pack de longo prazo
Figura 2.2: Suporte a service pack de longo prazo

Para obter mais informações, consulte https://www.suse.com/products/long-term-service-pack-support/.

Consulte https://www.suse.com/lifecycle para obter mais informações sobre ciclos de vida, frequência de lançamento e período de cobertura de suporte.

2.3 Dependências e ciclos de vida dos módulos

Para obter uma lista de módulos, suas dependências e ciclos de vida, consulte Article “Modules and Extensions Quick Start”.

2.4 Gerando relatório periódico do ciclo de vida

O SUSE Linux Enterprise Server pode verificar regularmente se há mudanças no status de suporte de todos os produtos instalados e enviar o relatório por e-mail em caso afirmativo. Para gerar o relatório, instale o zypper-lifecycle-plugin com o zypper in zypper-lifecycle-plugin.

Habilite a geração de relatórios no sistema com o comando systemctl:

> sudo systemctl enable lifecycle-report.timer

O destinatário e o assunto do e-mail de relatório, bem como o período de geração de relatórios, podem ser configurados no arquivo /etc/sysconfig/lifecycle-report com qualquer editor de texto. As configurações MAIL_TO e MAIL_SUBJ definem o destinatário e o assunto do e-mail, enquanto DAYS define o intervalo de geração do relatório.

O relatório exibe as mudanças de status de suporte depois que elas ocorreram, e não antes. Se a mudança ocorrer logo após a geração do último relatório, poderá levar até 14 dias para você ser notificado sobre ela. Leve isso em consideração ao definir a opção DAYS. Mude as seguintes entradas de configuração de acordo com seus requisitos:

MAIL_TO='root@localhost'
MAIL_SUBJ='Lifecycle report'
DAYS=14

O relatório mais recente está disponível no arquivo /var/lib/lifecycle/report. O arquivo contém duas seções. A primeira seção informa sobre o fim do suporte para os produtos usados. A segunda seção lista os pacotes com suas datas de término de suporte e disponibilidade de atualização.

2.5 Níveis de suporte

A faixa dos níveis de suporte estendido começa no décimo ano e termina no décimo terceiro ano. Eles incluem diagnóstico contínuo no nível de engenharia L3 e correções de bugs críticas reativas. Com esses níveis de suporte, você receberá atualizações para explorações de raiz comumente exploráveis no kernel e outras explorações de raiz diretamente executáveis sem interação do usuário. Além disso, eles suportam cargas de trabalho existentes, pilhas de software e hardware com lista de exclusões de pacotes limitadas. Consulte a visão geral na Tabela 2.1, “Atualizações de segurança e correções de bugs”.

Tabela 2.1: Atualizações de segurança e correções de bugs
 

Suporte Geral para Service Pack (SP) Mais Recente

Suporte Geral para SP Anterior, com LTSS

Suporte Estendido com LTSS

Recurso

Ano 1 a 5

Ano 6 a 7

Ano 8 a 10

Ano 4 a 10

Ano 10 a 13

Serviços técnicos

Sim

Sim

Sim

Sim

Sim

Acesso a Patches e Correções

Sim

Sim

Sim

Sim

Sim

Acesso a Documentação e Base de Dados de Conhecimento

Sim

Sim

Sim

Sim

Sim

Suporte para Pilhas e Cargas de Trabalho Existentes

Sim

Sim

Sim

Sim

Sim

Suporte para Novas Implantações

Sim

Sim

Limitado (Com base nos pedidos de parceiros e clientes)

Limitado (Com base nos pedidos de parceiros e clientes)

Não

Solicitações de aprimoramentos

Sim

Limitado (Com base nos pedidos de parceiros e clientes)

Limitado (Com base nos pedidos de parceiros e clientes)

Não

Não

Habilitação e Otimização de Hardware

Sim

Limitado (Com base nos pedidos de parceiros e clientes)

Limitado (Com base nos pedidos de parceiros e clientes)

Não

Não

Atualizações de driver pelo SUSE SolidDriver Program (anteriormente PLDP)

Sim

Sim

Limitado (Com base nos pedidos de parceiros e clientes)

Limitado (Com base nos pedidos de parceiros e clientes)

Não

Backport de Correções do SP Recente

Sim

Sim

Limitado (Com base nos pedidos de parceiros e clientes)

N/D

N/D

Atualizações de Segurança1

Todos

Todos

Todos

Apenas crítico

Apenas crítico

Resolução de Defeitos

Sim

Sim

Limitado (Apenas defeitos com Nível de Gravidade 1 e 2)

Limitado (Apenas defeitos com Nível de Gravidade 1 e 2)

Limitado (Apenas defeitos com Nível de Gravidade 1 e 2)

1 Para obter mais informações sobre a Política de Atualização do SUSE Linux Enterprise, consulte o seguinte artigo da base de dados de conhecimento.

2.6 Registrando e cancelando o registro de máquinas com o SUSEConnect

No registro, o sistema recebe repositórios do SUSE Customer Center (consulte https://scc.suse.com/) ou um proxy de registro local, como a SMT. Os nomes dos repositórios são mapeados para URIs específicos no atendimento do cliente. Para listar todos os repositórios disponíveis em seu sistema, use o zypper da seguinte forma:

# zypper repos -u

Esse comando mostra uma lista dos repositórios disponíveis no sistema. Cada repositório é listado por seu álias, nome e se está habilitado e será atualizado. A opção -u também mostra o URI de origem.

Para registrar sua máquina, execute o SUSEConnect, por exemplo:

# SUSEConnect -r REGCODE

Para cancelar o registro da sua máquina, você pode usar também o SUSEConnect:

# SUSEConnect --de-register

Para verificar os produtos instalados localmente e seus status, use o seguinte comando:

# SUSEConnect -s

2.7 Habilitando o suporte a LTSS

O Long Term Service Pack Support (LTSS, Suporte a Service Pack de Longo Prazo) estende o ciclo de vida do SUSE Linux Enterprise Server. Ele está disponível como uma extensão. Para obter mais informações sobre LTSS, consulte https://www.suse.com/products/long-term-service-pack-support/

Para habilitar a extensão LTSS, execute as seguintes etapas:

  1. Verifique se o seu sistema está registrado com uma assinatura qualificada para LTSS. Se o sistema ainda não foi registrado, faça o seguinte:

    > sudo SUSEConnect -r REGISTRATION_CODE -e EMAIL_ADDRESS
  2. Verifique se a extensão LTSS está disponível para o seu sistema:

    > sudo SUSEConnect --list-extensions | grep LTSS
    SUSE Linux Enterprise Server LTSS 15 SP4 x86_64
    Activate with: SUSEConnect -p SLES-LTSS/15.4/x86_64 -r ADDITIONAL REGCODE
  3. Ative o módulo conforme as instruções:

    > sudo SUSEConnect -p SLES-LTSS/15.4/x86_64 -r REGISTRATION_CODE

2.8 Identificando a versão do SLE

Se você precisa identificar a versão de uma instalação do SLE, verifique o conteúdo do arquivo /etc/os-release.

Uma saída XML legível por máquina está disponível com o zypper:

> zypper --no-remote --no-refresh --xmlout --non-interactive products -i
<?xml version='1.0'?>
<stream>
<product-list>
<product name="SLES" version="15" release="0" epoch="0" arch="x86_64" vendor="SUSE" summary="SUSE Linux Enterprise Server 15" repo="@System" productline="sles" registerrelease="" shortname="SLES15" flavor="" isbase="true" installed="true"><endoflife time_t="0" text="0"/><registerflavor/><description>SUSE Linux Enterprise offers [...]</description></product>
</product-list>
</stream>

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
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 Book “Storage Administration Guide”, Chapter 1 “Overview of file systems in Linux”, 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
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:

    # zypper lr -e repositories.bak
  2. 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
  3. 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
    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.

  1. 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
  2. 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/
  3. 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
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:

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

  3. Renomeie o diretório de dados antigo:

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

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

  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:

    # 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/"
  7. 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).

  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:

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

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

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

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

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

  5. Inicie o servidor MariaDB:

    # systemctl start mariadb

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

    # systemctl enable mariadb
  6. 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:

  1. Abra um terminal e efetue login como root.

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

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

    # openssl req -new -key server.key -out server.csr
  4. Autoassine o certificado:

    # openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt
  5. Crie o arquivo PEM:

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

      > 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/*
  3. Efetue login no servidor SMT.

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

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

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

    > 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 Book “AutoYaST Guide”, .

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 Book “Repository Mirroring Tool Guide”, 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 Book “Administration Guide”, Chapter 27 “Installing multiple kernel versions”, 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"

4 Fazendo upgrade offline

Este capítulo descreve como fazer upgrade de uma instalação existente do SUSE Linux Enterprise com o YaST, que é inicializado de um meio de instalação. Por exemplo, o instalador do YaST pode ser iniciado de um DVD, pela rede, ou do disco rígido no qual o sistema reside.

4.1 Visão geral conceitual

Antes de fazer upgrade do sistema, leia primeiro a Capítulo 3, Preparando o upgrade.

Para fazer upgrade do sistema, execute a inicialização de uma fonte de instalação, do mesmo modo que em uma instalação nova. Porém, quando a tela de boot aparecer, você deverá selecionar Upgrade (em vez de Instalação). O upgrade pode ser iniciado de:

4.2 Iniciando o upgrade de um meio de instalação

O procedimento a seguir descreve a inicialização de um DVD, mas você também pode usar outro meio de instalação local, como uma imagem ISO em um dispositivo de armazenamento em massa USB. O método de seleção de meio e de boot depende da arquitetura do sistema e se a máquina tem BIOS tradicional ou UEFI.

Procedimento 4.1: Fazendo upgrade manual para o SUSE Linux Enterprise Server 15 SP4
  1. Selecione e prepare um meio de boot. Consulte o Book “Guia de Implantação.

  2. Insira o DVD do Instalador Unificado do SUSE Linux Enterprise Server 15 SP4 e inicialize a máquina. Uma tela de boas-vindas aparece seguida da tela de boot.

  3. Opcional: Para forçar o instalador a instalar apenas os pacotes do DVD, e não de fontes de rede, adicione a opção de boot media_upgrade=1.

  4. Inicialize o sistema selecionando Fazer Upgrade no menu de boot.

  5. Prossiga com o processo de upgrade conforme descrito na Seção 4.4, “Fazendo upgrade do SUSE Linux Enterprise”.

4.3 Iniciando o upgrade de uma fonte de rede

Para iniciar o upgrade de uma fonte de instalação de rede, você deve cumprir os seguintes requisitos:

Requisitos para upgrade de uma fonte de instalação de rede
Fonte de instalação de rede

Configuração de uma fonte de instalação de rede de acordo com o Book “Guia de Implantação”, Chapter 16 “Configurando uma fonte de instalação de rede”.

Conexão e serviços de rede

Ambos o servidor de instalação e a máquina de destino devem ter uma conexão de rede ativa. Os serviços de rede necessários são:

  • Domain Name Service (Serviço de Nomes de Domínio)

  • DHCP (Dynamic Host Configuration Protocol): necessário apenas para inicialização por PXE. O IP pode ser definido manualmente durante a configuração

  • OpenSLP (opcional)

Meio de boot

Um DVD do SUSE Linux Enterprise inicializável, uma imagem ISO ou uma configuração PXE funcionando. Para obter detalhes sobre como inicializar via PXE, consulte o Book “Guia de Implantação”, Chapter 17 “Preparando o ambiente de boot de rede”, Section 17.4 “Preparando o sistema de destino para boot PXE”. Consulte o Book “Guia de Implantação”, Chapter 11 “Instalação remota” para obter informações detalhadas sobre como iniciar o upgrade de um servidor remoto.

4.3.1 Fazendo upgrade manualmente por meio da fonte de instalação de rede: inicialização do DVD

Esse procedimento descreve a inicialização de um DVD, como exemplo, mas você também pode usar outro meio de instalação local, como uma imagem ISO em um dispositivo de armazenamento em massa USB. A maneira de selecionar o método de boot e inicializar o sistema do meio depende da arquitetura do sistema e se a máquina tem BIOS tradicional ou UEFI. Para obter detalhes, consulte os links a seguir.

  1. Insira o DVD do Instalador Unificado do SUSE Linux Enterprise Server 15 SP4 e inicialize a máquina. Uma tela de boas-vindas aparece seguida da tela de boot.

  2. Selecione o tipo de fonte de instalação de rede que deseja usar (FTP, HTTP, NFS, SMB ou SLP). Normalmente, você vê essa opção pressionando F4, mas caso sua máquina esteja equipada com UEFI, e não com um BIOS tradicional, talvez seja necessário ajustar os parâmetros de boot manualmente. Para obter os detalhes, consulte o Book “Guia de Implantação”, Chapter 7 “Parâmetros de boot” e o Book “Guia de Implantação”, Chapter 8 “Etapas de instalação”.

  3. Prossiga com o processo de upgrade conforme descrito na Seção 4.4, “Fazendo upgrade do SUSE Linux Enterprise”.

4.3.2 Fazendo upgrade manualmente por meio da fonte de instalação de rede: inicialização via PXE

Para fazer upgrade de uma fonte de instalação de rede usando o boot PXE, faça o seguinte:

  1. Ajuste a configuração do servidor DHCP para fornecer as informações de endereço necessárias à inicialização via PXE. Para obter os detalhes, consulte o Book “Guia de Implantação”, Chapter 17 “Preparando o ambiente de boot de rede”, Section 17.1.1 “Atribuição dinâmica de endereço”.

  2. Configure um servidor TFTP para manter a imagem de boot necessária à inicialização via PXE. Use o DVD do Instalador do SUSE Linux Enterprise Server 15 SP4 para esse procedimento ou siga as instruções na Book “Guia de Implantação”, Chapter 17 “Preparando o ambiente de boot de rede”, Section 17.2 “Configurando um servidor TFTP”.

  3. Prepare o Boot PXE e o Wake-on-LAN na máquina de destino.

  4. Inicialize o sistema de destino e use o VNC para conectar-se remotamente à rotina de instalação que está sendo executada nessa máquina. Para obter mais informações, consulte o Book “Guia de Implantação”, Chapter 11 “Instalação remota”, Section 11.3 “Monitorando a instalação por VNC”.

  5. Prossiga com o processo de upgrade conforme descrito na Seção 4.4, “Fazendo upgrade do SUSE Linux Enterprise”.

4.4 Fazendo upgrade do SUSE Linux Enterprise

Antes de fazer upgrade do sistema, leia o Capítulo 3, Preparando o upgrade. Para executar a migração automatizada, faça o seguinte:

Nota
Nota: SUSE Customer Center e conexão com a Internet

Se o sistema do qual você deseja fazer upgrade foi registrado no SUSE Customer Center, verifique se há conexão com a Internet durante o procedimento a seguir.

  1. Após a inicialização (de um meio de instalação ou da rede), selecione a entrada Upgrade na tela de boot.

    Atenção
    Atenção: A opção errada pode levar à perda de dados

    Neste ponto, selecione Upgrade. Se você selecionar Instalação por engano, a partição de dados será sobregravada por uma instalação nova.

    O YaST inicia o sistema de instalação.

  2. Na tela Bem-vindo, escolha Idioma e Teclado. Continue com Próximo.

    O YaST verifica se já existem sistemas do SUSE Linux Enterprise instalados em suas partições.

  3. Na tela Select for Upgrade (Selecionar para Upgrade), selecione a partição para fazer upgrade e clique em Avançar.

  4. O YaST monta a partição selecionada e exibe o contrato de licença referente ao produto do qual foi feito o upgrade. Para continuar, aceite a licença.

  5. Na tela Repositórios previamente utilizados, ajuste o status dos repositórios. Por padrão, todos os repositórios são removidos. Se você não adicionou nenhum repositório personalizado, não mude as configurações. Os pacotes para o upgrade serão instalados do DVD, e você poderá habilitar os repositórios online padrão na próxima etapa.

    Se você tem repositórios personalizados, há duas opções:

    • Mantenha o estado do repositório como Removido. O software que foi instalado desse repositório será removido durante o upgrade. Use esse método se não houver uma versão do repositório disponível correspondente à nova versão.

    • Atualize e habilite o repositório se ele corresponder à nova versão. Para mudar o URL dele, clique no repositório na lista e clique em Alterar. Para habilitar o repositório, marque Alternar Status até ele ser definido como Habilitar.

    Não mantenha os repositórios da versão anterior, já que o sistema pode se tornar instável ou parar de funcionar. Em seguida, clique em Próximo para prosseguir.

  6. A próxima etapa depende se o sistema do qual foi feito o upgrade foi ou não registrado no SUSE Customer Center.

    1. Se o sistema não foi registrado no SUSE Customer Center, o YaST exibe uma mensagem popup sugerindo o uso de um segundo meio de instalação, a imagem SLE-15-SP4-Full-ARCH-GM-media1.iso.

      Se você não tiver esse meio, não será possível fazer upgrade do sistema sem o registro.

    2. Se o sistema foi registrado no SUSE Customer Center, o YaST mostra os destinos de migração possíveis e um resumo.

      Selecione um destino de migração na lista e clique em Próximo para continuar.

  7. Na caixa de diálogo seguinte, você pode adicionar outro meio de instalação. Se você tem uma mídia de instalação adicional, ative a opção Eu desejo instalar outro Produto Complementar e especifique o tipo de mídia.

  8. Revise as Configurações de Instalação para o upgrade.

  9. Se todas as configurações estiverem conforme desejado, inicie o procedimento de instalação e remoção clicando em Atualizar.

    Dica
    Dica: Falha no upgrade em clientes SMT

    Se a máquina da qual será feito o upgrade for um cliente SMT, e houver falha no upgrade, consulte o Procedimento 3.1, “Cancelando o registro de um cliente SUSE Linux Enterprise de um servidor SMT” e reinicie o procedimento de upgrade posteriormente.

  10. Após o término bem-sucedido do processo de upgrade, execute as verificações pós-upgrade conforme descrito na Seção 6.1, “Verificações pós-upgrade”.

4.5 Fazendo upgrade com o AutoYaST

O processo de upgrade pode ser executado automaticamente. Para obter os detalhes, consulte o Book “AutoYaST Guide”, Chapter 4 “Configuration and installation options”, Section 4.10 “Upgrade”.

4.6 Fazendo upgrade com o SUSE Manager

O SUSE Manager é uma solução de servidor que oferece atualizações, patches e correções de segurança para clientes SUSE Linux Enterprise. Ele vem com um conjunto de ferramentas e uma interface do usuário baseada na Web para as tarefas de gerenciamento. Consulte https://www.suse.com/products/suse-manager/ para obter mais informações sobre o SUSE Manager.

Você pode fazer um upgrade do sistema usando o SUSE Manager. A tecnologia do AutoYaST permite upgrades de uma versão principal para a próxima.

Se sua máquina for gerenciada pelo SUSE Manager, atualize-a conforme descrito na documentação do SUSE Manager. O procedimento de Migração de Cliente está descrito no Guia de Upgrade do SUSE Manager, disponível em https://documentation.suse.com/suma/.

4.7 Atualizando o status do registro após o rollback

Ao executar o upgrade de um pacote de serviço, é necessário mudar a configuração no servidor de registro para fornecer acesso aos novos repositórios. Se o processo de upgrade for interrompido ou revertido (por meio da restauração de um backup ou instantâneo), as informações sobre o servidor de registro ficarão inconsistentes com o status do sistema. Isso pode impedir você de acessar os repositórios de atualização ou fazer com que repositórios errados sejam usados no cliente.

Quando um rollback é feito por meio do Snapper, o sistema notifica o servidor de registro para garantir que o acesso aos repositórios corretos seja configurado durante o processo de boot. Se o sistema foi restaurado com outro método ou houve falha na comunicação com o servidor de registro, acione manualmente o rollback no cliente. Um exemplo de acionamento manual de rollback pode ser quando o servidor não estava acessível por causa de problemas na rede. Para fazer um rollback, execute:

> sudo snapper rollback

É recomendável verificar sempre se os repositórios corretos estão configurados no sistema, principalmente após a atualização do serviço com:

> sudo zypper ref -s

Essa funcionalidade está disponível no pacote rollback-helper.

4.8 Registrando seu sistema

Se o sistema não foi registrado antes de executar o upgrade, você pode registrar o sistema a qualquer momento usando o módulo Registro de Produto do YaST.

O registro de sistemas tem as seguintes vantagens:

  • Qualificação para suporte

  • Disponibilidade de atualizações de segurança e correções de bug

  • Acessar o SUSE Customer Center

  1. Inicie o YaST e selecione Software › Registro de Produto para abrir a caixa de diálogo Registro.

  2. Informe o endereço de E-mail associado à conta do SUSE que você ou sua organização usa para gerenciar inscrições. Se você ainda não tem uma conta do SUSE, vá para a home page do SUSE Customer Center (https://scc.suse.com/) para criar uma.

  3. Digite o Código de Registro que você recebeu com a cópia do SUSE Linux Enterprise Server.

  4. Se houver um ou mais servidores de registro locais disponíveis na rede, você poderá escolher um deles na lista.

  5. Para iniciar o registro, clique em Avançar para prosseguir.

    Após o registro bem-sucedido, o YaST mostrará uma lista de extensões, complementos e módulos disponíveis para o seu sistema. Para selecioná-los e instalá-los, continue no Book “Guia de Implantação”, Chapter 9 “Registrando o SUSE Linux Enterprise e gerenciando módulos/extensões”, Section 9.4 “Gerenciando módulos e extensões em um sistema em execução”.

5 Fazendo upgrade online

O SUSE oferece uma ferramenta gráfica intuitiva e uma ferramenta de linha de comando simples para fazer upgrade de um sistema em execução para um novo pacote de serviço. As duas oferecem suporte para rollback de pacotes de serviço e muito mais. Este capítulo apresenta instruções passo a passo sobre como fazer o upgrade de um pacote de serviço usando essas ferramentas.

5.1 Visão geral conceitual

A SUSE lança novos pacotes de serviço para a família do SUSE Linux Enterprise regularmente. Para facilitar aos clientes a migração para um novo pacote de serviço e minimizar o tempo de espera, o SUSE suporta a migração online durante a execução do sistema.

A partir do SLE 12, o YaST Wagon foi substituído pela migração do YaST (GUI) e pela migração do Zypper (linha de comando). Esse procedimento tem as seguintes vantagens:

  • O sistema está sempre em um estado definido até a atualização do primeiro RPM.

  • Cancelamento possível até a atualização do primeiro RPM.

  • Recuperação simples em caso de erro.

  • É possível fazer um rollback por meio das ferramentas do sistema. Não há necessidade de backup ou de restauração.

  • Uso de todos os repositórios ativos.

  • Capacidade de ignorar um pacote de serviço

Atenção
Atenção: Migração online não suportada para versões principais

A migração online apenas é suportada para migração entre pacotes de serviço. A migração online não é suportada para fazer upgrade para novas versões principais. Para obter os detalhes, consulte o Capítulo 1, Caminhos e métodos de upgrade.

Use a migração offline para fazer upgrade para uma nova versão principal. Para obter os detalhes, consulte o Capítulo 4, Fazendo upgrade offline.

Importante
Importante: Fazendo upgrade de clientes do SUSE Manager

Se o sistema do qual será feito o upgrade for um cliente do SUSE Manager, não será possível fazer upgrade dele por meio da migração online do YaST ou do comando zypper migration. Em vez disso, siga o procedimento de Migração de Cliente. Ele está descrito no Guia de Upgrade do SUSE Manager.

5.2 Workflow de migração de pacote de serviço

É possível executar a migração do pacote de serviço pelo YaST, zypper ou AutoYaST.

Antes de começar a migração de um pacote de serviço, o sistema deve ser registrado no SUSE Customer Center ou em um servidor RMT local. É possível também usar o SUSE Manager.

Independentemente do método, a migração de service pack consiste nas seguintes etapas:

  1. Localize os destinos de migração possíveis em seus sistemas registrados.

  2. Selecione um destino de migração.

  3. Solicite e habilite novos repositórios.

  4. Execute a migração.

A lista de destinos de migração depende dos produtos que você instalou e registrou. Se você tem uma extensão instalada para a qual ainda não há um novo SP disponível, talvez nenhum destino de migração seja oferecido a você.

A lista de destinos de migração disponíveis para o seu host sempre será recuperada do SUSE Customer Center e depende dos produtos ou extensões instalados.

5.3 Cancelando a migração do pacote de serviço

É possível cancelar a migração de um pacote de serviço apenas em fases específicas durante o processo de migração:

  1. Até o upgrade do pacote ser iniciado, há apenas mudanças mínimas no sistema, como modificações feitas em serviços e repositórios. Restaure /etc/zypp/repos.d/* para reverter ao estado anterior.

  2. Depois que o upgrade do pacote é iniciado, você pode reverter ao estado anterior usando um instantâneo do Snapper (consulte o Book “Administration Guide”, Chapter 10 “System recovery and snapshot management with Snapper”).

  3. Depois que o destino de migração for selecionado, o SUSE Customer Center mudará os dados do repositório. Para reverter esse estado manualmente, use SUSEConnect ‑‑rollback.

5.4 Fazendo upgrade com a ferramenta de migração online (YaST)

Para executar a migração do pacote de serviço com o YaST, use a ferramenta Migração Online. Por padrão, o YaST não instala nenhum pacote de um repositório de terceiros. Se um pacote foi instalado de um repositório de terceiros, o YaST impede que os pacotes sejam substituídos pelo mesmo pacote que vem do SUSE.

Nota
Nota: Reduzir o tamanho da instalação

Ao executar a migração do Pacote de Serviço, o YaST instalará todos os pacotes recomendados. Principalmente no caso das instalações mínimas personalizadas, isso pode aumentar o tamanho da instalação do sistema de forma significativa.

Para mudar este comportamento padrão e permitir apenas os pacotes necessários, ajuste a opção solver.onlyRequires em /etc/zypp/zypp.conf.

solver.onlyRequires = true

Edite também o arquivo /etc/zypp/zypper.conf e mude a opção installRecommends.

installRecommends=false

Isso muda o comportamento de todas as operações de pacote, como a instalação de patches ou novos pacotes. Para mudar o comportamento do Zypper para uma única chamada, use o parâmetro --no-recommends.

Para iniciar a migração do pacote de serviço, faça o seguinte:

  1. Desative todas as extensões não utilizadas em seu servidor de registro para evitar conflitos futuros de dependência. Se você se esquecer de uma extensão, o YaST detectará posteriormente os repositórios de extensões não utilizadas e as desativará.

  2. Se você efetuou login em uma sessão do GNOME em execução na máquina que você pretende atualizar, alterne para um console de texto. Não é recomendável executar a atualização de uma sessão GNOME. Observe que isso não se aplica quando o login é efetuado de uma máquina remota (a menos que você esteja executando uma sessão VNC com GNOME).

  3. Execute a atualização online do YaST para obter as atualizações de pacote mais recentes para o seu sistema.

  4. Instale o pacote yast2-migration e suas dependências (no YaST em Software › Gerenciamento de Software).

  5. Reinicie o YaST; do contrário, o módulo recém-instalado não será mostrado no centro de controle.

  6. No YaST, escolha Migração Online (dependendo da versão do SUSE Linux Enterprise Server da qual você está fazendo upgrade, este módulo será classificado como Sistema ou Software). O YaST mostra os destinos de migração possíveis e um resumo. Se houver mais de um destino de migração disponível para o seu sistema, selecione um deles na lista.

  7. Selecione um destino de migração na lista e clique em Avançar para continuar.

  8. Se a ferramenta de migração oferecer repositórios de atualização, a recomendação será clicar em Sim para continuar.

  9. Se a ferramenta Migração Online encontrar repositórios obsoletos de DVD ou de um servidor local, será altamente recomendado desabilitá-los. Os repositórios obsoletos são de um SP anterior. Os repositórios antigos do SUSE Customer Center ou da RMT são removidos automaticamente.

  10. Confira o resumo e clique em Avançar para continuar a migração. Clique em Iniciar Atualização para confirmar.

  11. Reinicie o sistema após a migração bem-sucedida.

5.5 Fazendo upgrade com o Zypper

Para executar a migração do pacote de serviço com o Zypper, use a ferramenta de linha de comando zypper migration do pacote zypper-migration-plugin.

Nota
Nota: Reduzir o tamanho da instalação

Ao executar a migração do Pacote de Serviço, o YaST instalará todos os pacotes recomendados. Principalmente no caso das instalações mínimas personalizadas, isso pode aumentar o tamanho da instalação do sistema de forma significativa.

Para mudar este comportamento padrão e permitir apenas os pacotes necessários, ajuste a opção solver.onlyRequires em /etc/zypp/zypp.conf.

solver.onlyRequires = true

Edite também o arquivo /etc/zypp/zypper.conf e mude a opção installRecommends.

installRecommends=false

Isso muda o comportamento de todas as operações de pacote, como a instalação de patches ou novos pacotes. Para mudar o comportamento do Zypper para uma única chamada, use o parâmetro --no-recommends.

Para iniciar a migração do pacote de serviço, faça o seguinte:

  1. Se você efetuou login em uma sessão do GNOME em execução na máquina que você pretende atualizar, alterne para um console de texto. Não é recomendável executar a atualização de uma sessão GNOME. Observe que isso não se aplica quando o login é efetuado de uma máquina remota (a menos que você esteja executando uma sessão VNC com GNOME).

  2. Registre a máquina do SUSE Linux Enterprise, caso ainda não tenha feito isso:

    > sudo SUSEConnect --regcode YOUR_REGISTRATION_CODE
  3. Inicie a migração:

    > sudo zypper migration

    Algumas observações sobre o processo de migração:

    • Se houver mais de um destino de migração disponível para o seu sistema, o Zypper permitirá selecionar um SP na lista. Isso equivale a ignorar um ou mais SPs. Lembre-se de que a migração online para produtos base (SLES, SLED) permanece disponível apenas entre os SPs de uma versão principal.

    • Por padrão, o Zypper usa a opção --no-allow-vendor-change, que é passada para o zypper dup. Se um pacote foi instalado de um repositório de terceiros, essa opção impede que os pacotes sejam substituídos pelo mesmo pacote que vem do SUSE.

    • Se o Zypper encontrar repositórios obsoletos de DVD ou de um servidor local, será altamente recomendado desabilitá-los. Os repositórios antigos do SUSE Customer Center ou da RMT são removidos automaticamente.

  4. Revise todas as mudanças, principalmente os pacotes que serão removidos. Digite y para continuar (o número exato de pacotes para upgrade pode variar de acordo com o sistema):

    266 packages to upgrade, 54 to downgrade, 17 new, 8 to reinstall, 5 to remove, 1 to change arch.
    Overall download size: 285.1 MiB. Already cached: 0 B  After the operation, additional 139.8 MiB will be used.
    Continue? [y/n/? shows all options] (y):

    Use as teclas ShiftPage ↑ ou ShiftPage ↓ para mover a barra de rolagem no shell.

  5. Reinicie o sistema após a migração bem-sucedida.

5.6 Fazendo upgrade com o Zypper simples

Se seu sistema não foi registrado porque você não tem acesso à Internet ou um servidor de registro, a migração para um novo pacote de serviço não é possível com a Migração do YaST ou o zypper migration. Nesse caso, você ainda pode migrar para um novo pacote de serviço com o Zypper simples e algumas interações manuais.

Importante
Importante: Apenas para sistemas não registrados

Este caminho de migração para um novo pacote de serviço é suportado apenas para sistemas não registrados sem acesso à Internet ou um servidor de registro. Por exemplo, pode ser o caso de máquinas em uma rede com proteção especial. Se você tem um sistema registrado, use a migração do YaST ou do Zypper.

Importante
Importante: Fontes de instalação

Esse caminho de migração requer que o sistema de destino da migração tenha acesso às fontes de instalação. Por exemplo, é possível fazer isso configurando um servidor RMT ou SLP.

É necessário também que o sistema tenha acesso ao repositório de atualizações mais recente para a versão do produto instalado.

  1. Se você efetuou login em uma sessão gráfica em execução na máquina que você pretende migrar, efetue logout dessa sessão e alterne para um console de texto. Não é recomendável executar a atualização de uma sessão gráfica. Observe que isso não se aplica quando o login é efetuado de uma máquina remota (a menos que você esteja executando uma sessão VNC com X).

  2. Atualize as ferramentas de gerenciamento de pacote com os repositórios antigos do SUSE Linux Enterprise:

    > sudo zypper patch --updatestack-only
  3. Obtenha uma lista de pacotes que não têm um repositório atribuído a eles (pacotes órfãos). Esses pacotes não serão migrados, e não haverá garantia de que eles funcionarão após a migração (porque outros pacotes dos quais eles dependem podem ter mudado de um modo que acabaram ficando compatíveis). Para obter a lista, execute:

    > sudo zypper packages --orphaned

    Revise cuidadosamente a lista e remova todos os pacotes órfãos que não são mais necessários. Anote todos os pacotes órfãos restantes, você precisará deles mais tarde para comparação.

  4. Para obter uma lista de todos os repositórios em que o sistema está registrado atualmente, execute:

    > sudo zypper repos -u

    Atualize o URL de cada repositório para que o número da versão do produto seja 15-SP4. Por exemplo, se o URL de um repositório for

    http://rmt.example.com/repo/SUSE/Products/SLE-15-SP2-Product-SLES/x86_64/product/

    altere-o para

    http://rmt.example.com/repo/SUSE/Products/SLE-15-SP3-Product-SLES/x86_64/product/

    Isso deve ser feito com todos os repositórios habilitados. Convém fazer isso também com os repositórios que estão desabilitados no momento, para evitar ter fontes de instalação incorretas no sistema quando eles forem ativados posteriormente.

    Para mudar os URLs dos repositórios, você tem as seguintes opções:

    1. Por meio de YaST ›  Software ›  Repositórios de software. Selecione um repositório e clique em Editar para fazer a mudança necessária. Repita esse procedimento para todos os repositórios.

    2. Usando o zypper. Execute o seguinte comando para remover o repositório antigo

      > sudo zypper removerepo OLD_REPO_ID

      Em seguida, execute o comando abaixo para adicionar o novo repositório correspondente

       > sudo zypper addrepo -f URL NAME-15-SP4
    3. Por meio da edição dos arquivos de configuração do repositório em /etc/zypp/repos.d. Cada repositório é representado por um arquivo de configuração. É necessário mudar o valor do parâmetro baseurl em cada arquivo.

  5. Revise as mudanças executando o comando zypper repos -u e atualize os repositórios executando:

    > sudo zypper refresh -f -s

    Em caso de falha na atualização de um repositório, verifique se você não inseriu o URL incorreto. Se não for possível corrigir o problema, a recomendação será desabilitar o repositório com falha.

    Se todos os repositórios estiverem configurados corretamente, execute

    > sudo zypper refresh -f -s

    novamente para garantir que todos os repositórios estejam atualizados.

  6. Antes de iniciar a migração, é recomendável executar um teste:

    > sudo zypper dup -D --no-allow-vendor-change --no-recommends

    O parâmetro -D executará um dry run que simula a migração sem de fato mudar o sistema. Se houver problemas, corrija-os antes de continuar. Se a o teste for bem-sucedido, execute o comando abaixo para fazer a migração real:

    > sudo zypper dup --no-allow-vendor-change --no-recommends

    A opção -no-allow-vendor-change garante que os RPMs de terceiros não sobregravem os RPMs do sistema base. A opção --no-recommends garante que os pacotes desmarcados durante a instalação inicial não serão adicionados novamente.

  7. Quando a migração for concluída e o sistema for inicializado na nova versão do pacote de serviço, execute outra vez a verificação de pacotes órfãos:

    > sudo zypper packages --orphaned

    Compare a nova lista com aquela que você gerou antes de iniciar a migração. Se novos pacotes aparecerem na lista, talvez eles tenham sido movidos para um módulo diferente no novo pacote de serviço. Se você não tinha esse módulo na instalação anterior, o pacote não foi atualizado.

    Você pode verificar a qual módulo um pacote pertence em https://scc.suse.com/packages. Adicione os módulos ausentes por meio do comando zypper addrepo ou pelo módulo YaST Repositórios de software e atualize os pacotes órfãos executando:

    > sudo zypper install --no-recommends LIST OF PACKAGES
  8. Você migrou com êxito para um novo pacote de serviço!

5.7 Voltando um pacote de serviço

Se um pacote de serviço não funcionar para você, o SUSE Linux Enterprise permitirá reverter o sistema ao estado anterior à inicialização da migração do pacote de serviço. O pré-requisito é uma partição raiz Btrfs com instantâneos habilitados (este é o padrão desde o SLES 12). Consulte o Book “Administration Guide”, Chapter 10 “System recovery and snapshot management with Snapper” para obter os detalhes.

  1. Confira uma lista de todos os instantâneos do Snapper:

    > sudo snapper list

    Revise a saída para localizar o instantâneo que foi criado logo antes da inicialização da migração do pacote de serviço. A coluna Descrição contém uma declaração correspondente, e o instantâneo está marcado como important (importante) na coluna Userdata. Memorize o número do instantâneo da coluna e a data da coluna Data.

  2. Reinicialize o sistema. No menu de boot, selecione Iniciar carregador de boot de um instantâneo apenas leitura e escolha o instantâneo com a data e o número que você memorizou na etapa anterior. Um segundo menu de boot (aquele do instantâneo) é carregado. Selecione a entrada que começa com SLES 15 SP4 e inicialize o sistema.

  3. O sistema é inicializado no estado anterior com a partição do sistema montada como apenas leitura. Efetue login como root e verifique se você escolheu o instantâneo correto. Verifique também se tudo funciona conforme o esperado. Como o sistema de arquivos raiz está montado como apenas leitura, pode haver restrições de funcionalidade.

    Em caso de problemas ou se você inicializou o instantâneo errado, reinicialize e escolha outro instantâneo do qual inicializar. Até este ponto, não foram feitas mudanças permanentes. Se o instantâneo está correto e funciona conforme o esperado, faça a mudança permanente executando o seguinte comando:

    > sudo snapper rollback

    Reinicialize a máquina. Na tela de boot, escolha a entrada de boot padrão para reinicializar no sistema restaurado.

  4. Verifique se a configuração do repositório foi redefinida apropriadamente. Verifique também se todos os produtos foram registrados apropriadamente. Se não for nenhum desses casos, a atualização do sistema em um momento posterior talvez não funcione mais, ou o sistema pode ser atualizado usando os repositórios de pacotes errados.

    Verifique se o sistema pode acessar a Internet antes de iniciar este procedimento.

    1. Atualize serviços e repositórios executando

      > sudo zypper ref -fs
    2. Obtenha uma lista de repositórios ativos executando

      > sudo zypper lr

      Verifique cuidadosamente a saída deste comando. Não deve aparecer na lista serviços e repositórios que foram adicionados para a atualização. Por exemplo, se você estiver voltando do SLES 15 SP4 para o SLES15 GA, a lista deverá incluir os repositórios SLES15-GA, e não os repositórios SLES15-SP4.

      Se na lista constar os repositórios incorretos, apague-os e, se necessário, substitua-os pelas versões correspondentes à versão do produto ou do pacote de serviço. Para obter uma lista de repositórios para os caminhos de migração suportados, consulte a Seção 2.3, “Dependências e ciclos de vida dos módulos”. Observe que a intervenção manual talvez não seja necessária, já que os repositórios devem ser atualizados automaticamente, mas a melhor prática é verificar e fazer as correções pertinentes.

    3. Por fim, verifique o status do registro para todos os produtos instalados executando

      > sudo SUSEConnect --status

      Todos os produtos devem ser relatados como Registered (Registrados). Se não for esse o caso, conserte o registro executando

      > sudo SUSEConnect --rollback

Agora, você reverteu com êxito o sistema ao estado que foi capturado logo antes da inicialização da migração do pacote de serviço.

5.8 Fazendo upgrade com o SUSE Manager

O SUSE Manager é uma solução de servidor que oferece atualizações, patches e correções de segurança para clientes SUSE Linux Enterprise. Ele vem com um conjunto de ferramentas e uma interface do usuário baseada na Web para as tarefas de gerenciamento. Consulte https://www.suse.com/products/suse-manager/ para obter mais informações sobre o SUSE Manager.

A Migração do SP permite migrar de um Pacote de Serviço (SP, Service Pack) para outro dentro de uma versão principal (por exemplo, do SLES 15 GA para o SLES 15 SP4).

Se sua máquina for gerenciada pelo SUSE Manager, atualize-a conforme descrito na documentação do SUSE Manager. O procedimento de Migração de Cliente está descrito no Guia de Upgrade do SUSE Manager, disponível em https://documentation.suse.com/suma/.

5.9 Fazendo upgrade do openSUSE Leap para o SUSE Linux Enterprise Server

Você pode fazer upgrade de uma instalação do openSUSE Leap para o SUSE Linux Enterprise Server. O procedimento é semelhante ao da Seção 5.4, “Fazendo upgrade com a ferramenta de migração online (YaST)”, mas requer algumas etapas adicionais. Antes de executar esse procedimento em um sistema de produção, recomendamos que ele seja executado em um sistema de teste que replique a configuração da produção.

Para saber quais versões do openSUSE Leap são suportadas para migração, consulte a Seção 1.2, “Caminhos de upgrade suportados para o SLES 15 SP4.

Atenção
Atenção: Nem todos os pacotes openSUSE podem ser migrados

O openSUSE oferece mais pacotes do que o SUSE Linux Enterprise Server. A maioria dos pacotes adicionais está disponível por meio do SUSE Package Hub e será migrada. Quaisquer pacotes adicionais que não estejam disponíveis no SUSE Package Hub não receberão mais atualizações após a migração e, portanto, deverão ser removidos posteriormente.

Verifique se todos os pacotes necessários para operação do seu sistema estão disponíveis nos repositórios do SUSE Linux Enterprise Server e do SUSE Package Hub. Para obter mais informações sobre o SUSE Package Hub, consulte https://packagehub.suse.com/.

Procedimento 5.1: Fazendo upgrade do openSUSE Leap para o SUSE Linux Enterprise Server

Para migrar do openSUSE Leap para o SUSE Linux Enterprise Server, siga as etapas abaixo:

  1. Alterne para uma TTY, por exemplo, pressione CtrlAltF1. Em seguida, efetue login como root.

  2. Instale os pacotes yast2-registration e rollback-helper:

    # zypper in yast2-registration rollback-helper
  3. Habilite o serviço rollback-helper:

    # systemctl enable rollback
  4. Registre o sistema no SUSE Customer Center:

    # yast2 registration
  5. Execute a migração:

    # yast2 migration

    Em caso de conflito de pacotes, o YaST apresenta uma lista de resoluções para você fazer a sua escolha.

  6. Remova os pacotes órfãos:

    # zypper rm $(zypper --no-refresh packages --orphaned | gawk '{print $5}' | tail -n +5)
  7. Reinicialize o sistema:

    # reboot

Você migrou com êxito seu sistema para o SUSE Linux Enterprise Server.

Se você tiver algum problema após a migração, poderá revertê-la como um upgrade de pacote de serviço. Para obter instruções, consulte a Seção 5.7, “Voltando um pacote de serviço”.

6 Concluindo o upgrade

Após o upgrade, você precisará executar algumas tarefas adicionais. O capítulo a seguir orientará você durante as etapas.

6.1 Verificações pós-upgrade

  • Verifique se há quaisquer pacotes órfãos. Durante um procedimento de upgrade, os pacotes podem ser renomeados, removidos, fundidos ou divididos. Como resultado, alguns pacotes podem se tornar órfãos e perder o suporte. Os pacotes órfãos não são removidos automaticamente. O comando a seguir fornece uma lista deles:

    > zypper packages --orphaned --unneeded

    Use a lista para determinar quais pacotes ainda são necessários e quais podem ser removidos com segurança.

  • Verifique se há arquivos *.rpmnew e *.rpmsave, examine o conteúdo deles e faça a possível fusão das mudanças desejadas. Quando um upgrade inclui mudanças em um arquivo de configuração padrão, em vez de sobregravar esse arquivo, o pacote cria um desses tipos de arquivo. O *.rpmnew contém a nova configuração padrão e mantém seu arquivo original inalterado, já o *.rpmsave é uma cópia do seu arquivo original que foi substituído pelo novo arquivo padrão.

    Você não precisa pesquisar todo o sistema de arquivos para localizar os arquivos *.rpmnew e *.rpmsave, os mais importantes são armazenados no diretório /etc. Use o seguinte comando para listá-los:

    > find /etc/ -name "*.rpmnew" -o -name "*.rpmsave"

6.2 Habilitar o módulo Python 3

Por padrão, o SUSE Linux Enterprise Server 15 usa o Python 3.6. O Python 3.9 foi adicionado ao SLES 15 SP3 como uma alternativa mais recente. Essa versão não é mais suportada a partir do SLES 15 SP4. Em vez disso, versões recentes do Python com atualizações e correções de segurança importantes estão disponíveis no módulo Python 3.

Se você instalou o Python 3.9 no SUSE Linux Enterprise Server 15 SP3, habilite o módulo Python 3 por meio do comando:

> sudo SUSEConnect -p sle-module-python3/15.4/x86_64.

Se preferir, retorne à versão padrão do Python removendo 3.9 por meio do comando zypper remove -u python39.

6.3 Reformatar dispositivos XFS v4

OO SUSE Linux Enterprise Server suporta o formato em disco (v5) do sistema de arquivos XFS. As principais vantagens desse formato são os checksums automáticos de todos os metadados do XFS, suporte a tipos de arquivos e suporte a um número maior de listas de controles de acesso para um arquivo.

Observe que esse formato não é suportado pelos kernels do SUSE Linux Enterprise anteriores à versão 3.12, pelo xfsprogs anteriores à versão 3.2.0 e pelas versões do GRUB 2 lançadas antes do SUSE Linux Enterprise 12.

Importante
Importante: A V4 foi descontinuada

O XFS está descontinuando os sistemas de arquivos com o formato V4. Esse formato de sistema de arquivos foi criado pelo comando:

> sudo mkfs.xfs -m crc=0 DEVICE

O formato era usado no SLE 11 e em versões mais antigas e, atualmente, cria uma mensagem de aviso pelo dmesg:

Deprecated V4 format (crc=0) will not be supported after September 2030

Se você vir a mensagem acima na saída do comando dmesg, é recomendável atualizar o sistema de arquivos para o formato V5:

  1. Faça backup de seus dados em outro dispositivo.

  2. Crie o sistema de arquivos no dispositivo.

    > sudo mkfs.xfs -m crc=1 DEVICE
  3. Restaure os dados do backup no dispositivo atualizado.

7 Backports de código-fonte

O SUSE faz uso intensivo de backports, por exemplo, na migração de correções e recursos de software atuais para pacotes lançados do SUSE Linux Enterprise. As informações neste capítulo explicam por que pode ser equivocado comparar os números de versão para determinar os recursos e a segurança dos pacotes de software do SUSE Linux Enterprise. Este capítulo explica também como o SUSE mantém o software do sistema protegido e atualizado assegurando a compatibilidade de seu software de aplicativo em coexistência com os produtos SUSE Linux Enterprise. Você também aprenderá como verificar os problemas de segurança pública que são realmente resolvidos no software do sistema SUSE Linux Enterprise e o status atual do seu software.

7.1 Prós do backporting

O foco principal dos desenvolvedores de upstream está na evolução do software que eles criam. Em geral, eles combinam correção de bugs com a introdução de novos recursos que ainda não foram amplamente testados e que podem inserir novos bugs.

Para os desenvolvedores de distribuição, é importante saber a diferença entre:

  • correções de bugs com potencial limitado para interromper a funcionalidade; e

  • mudanças que possam interromper a funcionalidade existente.

Normalmente, os desenvolvedores de distribuição não seguem todas as mudanças de upstream quando um pacote torna-se parte de uma distribuição lançada. Normalmente, eles mantêm a versão de upstream que lançaram inicialmente e criam patches com base nas mudanças de upstream para corrigir os bugs. Esta prática é conhecida como backporting.

Em geral, os desenvolvedores de distribuição apenas lançam uma nova versão do software em dois casos:

  • quando as mudanças entre os pacotes e as versões de upstream tornam-se tão grandes que o backporting não é mais viável, ou

  • quando o software apresenta um comportamento inerentemente errôneo ao longo de sua vida, como um software antimalware.

O SUSE faz uso intensivo de backports para buscar o equilíbrio ideal entre as várias questões que envolvem o software empresarial. As mais importantes são:

  • Oferecer interfaces estáveis (APIs) nas quais os fornecedores de software podem confiar na hora de desenvolver produtos para usar com os produtos empresariais do SUSE.

  • Garantir que os pacotes usados no lançamento dos produtos empresariais do SUSE sejam da mais alta qualidade e tenham sido completamente testados, sozinhos e como parte do produto empresarial inteiro.

  • Manter as diversas certificações dos produtos empresariais do SUSE por outros fornecedores, como as certificações para produtos Oracle ou SAP.

  • Permitir que os desenvolvedores do SUSE se concentrem na criação da próxima versão do produto, sem dividir a atenção entre uma ampla gama de versões.

  • Manter uma visão clara do que compõe uma versão empresarial específica, para que nosso suporte possa oferecer informações precisas e imediatas sobre ela.

7.2 Contras do backporting

Existe uma regra da política geral de que nenhuma versão nova de upstream de um pacote é introduzida em nossos produtos empresariais. Essa regra não é, na verdade, absoluta. Para determinados tipos de pacotes, em um software antivírus específico, as questões de segurança têm um peso maior do que a abordagem conservadora, o que é preferível do ponto de vista do controle de qualidade. Para os pacotes dessa classe, ocasionalmente, são inseridas versões mais recentes em uma versão lançada da linha de produtos empresariais.

Também para outros tipos de pacotes, às vezes a opção é introduzir uma nova versão em vez de fazer backport. Isso é feito quando a realização do backport não é economicamente viável ou quando existe um motivo técnico bastante relevante para se introduzir uma versão mais recente.

7.3 Implicações dos backports na interpretação dos números de versão

Devido à prática de backporting, não é possível simplesmente comparar números de versão para determinar se um pacote do SUSE inclui a correção de determinado problema ou se um recurso específico foi adicionado a ele. Com o backporting, a parte de upstream do número de versão do pacote do SUSE apenas indica em qual versão de upstream o pacote do SUSE está baseado. Ele pode incluir correções de bugs e recursos que não estejam na versão de upstream correspondente, mas que passaram por backport no pacote do SUSE.

As ferramentas de exploração de segurança são uma área específica em que pode haver problemas com esse valor limitado de números de versão quando há backporting envolvido. Algumas ferramentas de exploração de vulnerabilidades de segurança (ou alguns testes dessas ferramentas) operam exclusivamente com as informações de versão. Portanto, essas ferramentas e testes tendem a gerar falsos positivos (quando uma parte do software é identificada incorretamente como vulnerável) quando há backports envolvidos. Durante a avaliação dos relatórios das ferramentas de varredura de segurança, sempre verifique se uma entrada baseia-se no número da versão ou no teste real de vulnerabilidade.

7.4 Verificando bugs corrigidos e recursos que passaram por backport

As informações sobre as correções de bugs e recursos de backport são armazenadas em vários locais:

  • O registro de mudanças do pacote:

    > rpm-q --changelog name-of-installed-package
    > rpm -qp --changelog packagefile.rpmpackagefile.rpm

    A saída documenta resumidamente o histórico de mudanças do pacote.

  • O registro de mudanças do pacote pode incluir entradas como bsc#1234 (Bugzilla Suse. Com) que fazem referência a bugs no sistema de monitoramento Bugzilla do SUSE ou links para outros sistemas de monitoramento de bugs. Por causa das políticas de confidencialidade, nem todas as informações podem ser acessadas por você.

  • Um pacote pode incluir um arquivo /usr/share/doc/PACKAGENAME/README.SUSE, com informações gerais de alto nível específicas ao pacote do SUSE.

  • O pacote de origem RPM contém os patches que foram aplicados durante a compilação dos RPMs binários regulares como arquivos separados, que poderão ser interpretados se você estiver familiarizado com a leitura de código-fonte. Consulte o Book “Administration Guide”, Chapter 9 “Managing software with command line tools”, Section 9.1.3.5 “Installing or downloading source packages” para ver as fontes de instalação do software do SUSE Linux Enterprise. Consulte o Book “Administration Guide”, Chapter 9 “Managing software with command line tools”, Section 9.2.5 “Installing and compiling source packages” para criar pacotes no SUSE Linux Enterprise. Consulte o manual de RPM máximo para obter detalhes sobre as criações de pacote de software para o SUSE Linux Enterprise.

  • Para obter correções de bug de segurança, consulte os anúncios de segurança do SUSE. Em geral, eles fazem referência aos bugs por meio de nomes padronizados, como CAN-2005-2495, que são mantidos pelo projeto Common Vulnerabilities and Exposures (CVE) (Vulnerabilidades e Exposições Comuns).