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

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

Além disso, como o SUSE Linux Enterprise 15 SP2 é apenas de 64 bits, os upgrades de qualquer sistema SUSE Linux Enterprise 11 de 32 bits para o SUSE Linux Enterprise 15 SP2 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: Ignorando os Service Packs

A instalação consecutiva de todos os Service Packs é o caminho de upgrade mais fácil. Para a linha de produtos SUSE Linux Enterprise 15 (GA e os Service Packs seguintes), é permitido ignorar um pacote de serviço ao fazer upgrading. Por exemplo, é permitido fazer upgrade do SLE 15 GA para o 15 SP2 ou do SLE 15 SP1 para o 15 SP3.

Nota: Fazendo upgrade de versões principais

Recomendamos fazer uma nova instalação durante o upgrade para uma nova Versão Principal, por exemplo, do SUSE Linux Enterprise 12 para o SUSE Linux Enterprise 15.

Figura 1.1: Visão geral dos caminhos de upgrade suportados #

 

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:

Importante: Clientes 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/.

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

O SUSE tem o seguinte ciclo de vida de produtos:

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.

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

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.

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

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 comando zypper in zypper-lifecycle-plugin.

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

root # systemctl enable lifecycle-report

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.

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

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:

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

root # SUSEConnect -r REGCODE

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

root # SUSEConnect --de-register

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

root # SUSEConnect -s

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:

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

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

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

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

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

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

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

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

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

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

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

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

root # zypper lr -e repositories.bak

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

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

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

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

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

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

• Os pacotes foram divididos para permitir uma seleção de pacote mais detalhada. Por exemplo, 37 pacotes texlive no SLE 11 foram divididos em mais de 3.000 pacotes no SLE 15.

• Quando um pacote é dividido em outros pacotes, todos os novos pacotes são instalados no caso de upgrade para manter a mesma funcionalidade da versão anterior. No entanto, o novo padrão para uma instalação recente do SLE X+1 pode ser de não instalar todos os pacotes.

• Os pacotes legados do SLE X podem ser mantidos por questões de compatibilidade.

• As dependências de pacotes e o escopo dos padrões podem ter mudado.

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

3.5.2 Migrar o banco de dados PostgreSQL #

 

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

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

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

Importante: Fazendo upgrade do SLE 11

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

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

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

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 SP2, isso significa instalar o postgresql10-server e todos os pacotes dos quais ele depende.

   • Instale o pacote postgresql10-contrib que contém o comando pg_upgrade.

   • Verifique se você tem espaço livre suficiente na área de dados do PostgreSQL, que é /var/lib/pgsql/data, por padrão. Se o espaço for pouco, tente reduzir o tamanho com o seguinte comando SQL em cada banco de dados (pode levar muito tempo!):

     VACUUM FULL

2. Pare o servidor PostgreSQL usando qualquer um destes comandos:

   root # /usr/sbin/rcpostgresql stop

   ou

   root # systemctl stop postgresql.service

   (dependendo da versão do SLE que você usa como a versão inicial para o upgrade).

3. Renomeie o diretório de dados antigo:

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

4. Inicialize a nova instância do banco de dados manualmente com initdb ou iniciando e parando o PostgreSQL, que fará isso automaticamente:

   root # /usr/sbin/rcpostgresql start
   root # /usr/sbin/rcpostgresql stop

   ou

   root # systemctl start postgresql.service
   root # systemctl stop postgresql.service

   (dependendo da versão do SLE que você usa como a versão inicial para o upgrade).

5. Se você modificou os arquivos de configuração na versão antiga, considere transferir essas modificações para os novos arquivos de configuração. Isso pode afetar os arquivos postgresql.auto.conf, postgresql.conf, pg_hba.conf e pg_ident.conf. As versões antigas desses arquivos estão localizadas em /var/lib/pgsql/data.old/, as versões novas estão disponíveis em /var/lib/pgsql/data.

   Não é recomendado apenas copiar os arquivos de configuração antigos, pois isso pode sobregravar as novas opções, os novos padrões e os comentários modificados.

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

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

7. Inicia a nova instância de banco de dados usando um destes comandos:

   root # /usr/sbin/rcpostgresql start

   ou

   root # systemctl start postgresql.service

   (dependendo da versão do SLE que você usa como a versão inicial para o upgrade).

8. Verifique se a migração foi bem-sucedida. O escopo do teste depende do seu caso de uso, e não há nenhuma ferramenta geral para automatizar esta etapa.

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

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

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.

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.

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

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

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

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

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

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 “Guia de Implantação”, Chapter 21 “Instalando várias versões do kernel”, Section 21.1 “Habilitando e configurando suporte multiversão”.

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

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"

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:

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.

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

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: 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: A opção errada pode levar à perda de dados

   Neste ponto, verifique se você selecionou 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 Avançar.

   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 registrado no SUSE Customer Center ou não.

   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-SP2-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: 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 do 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 4.4.1, “Verificações pós-upgrade”.

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

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.

Com o SUSE Manager, é possível executar um upgrade do sistema. Com a tecnologia integrada do AutoYaST, os upgrades de uma versão principal para a versão seguinte são possíveis.

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

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:

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

tux > sudo zypper ref -s

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

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:

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:

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, Upgrade de caminhos e métodos.

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

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

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.

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

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: 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, adicione o parâmetro --no-recommends à linha de comando.

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

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: 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, adicione o parâmetro --no-recommends à linha de comando.

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

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: 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. Caso você tenha um sistema registrado, use a migração do YaST ou do Zypper.

Importante: Fontes de instalação

Este caminho de migração exige que você forneça as fontes de instalação para o novo pacote de serviço em um local que possa ser acessado pela máquina que será migrada. Para fazer isso, é possível, por exemplo, configurar 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.

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 7 “System Recovery and Snapshot Management with Snapper” para obter os detalhes.

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.

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

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

Você pode fazer upgrade de uma instalação do openSUSE online para o SUSE Linux Enterprise Server. O procedimento é semelhante ao da Seção 5.5, “Fazendo upgrade com o Zypper”, mas algumas outras etapas são necessárias. 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 as versões do openSUSE Leap que suportam migração, leia a Seção 1.1, “Caminhos de upgrade suportados para o SLES 15 SP2”.

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

Os repositórios do openSUSE incluem mais pacotes do que os que estão disponíveis nos repositórios do SUSE Linux Enterprise Server. Se você tiver algum desses pacotes instalados, eles não receberão mais atualizações após a migração. Esses pacotes serão removidos ao seguir o procedimento abaixo.

Verifique se todos os pacotes necessários para operação do seu sistema estão disponíveis no repositório do SUSE Linux Enterprise Server. Você também pode verificar se os pacotes estão disponíveis no repositório do SUSE Package Hub. Para obter os detalhes, consulte o Book “Guia de Implantação”, Chapter 20 “Instalando módulos, extensões e produtos complementares de terceiros”, Section 20.3 “SUSE Package Hub”.

Para migração do openSUSE Leap, execute o procedimento a seguir:

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:

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:

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:

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.

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.

Há vários locais onde as informações sobre correções de bugs e recursos que passaram por backport estão armazenadas: