Nas notas de versão, você encontra mais informações sobre o que mudou desde a versão anterior do SUSE Linux Enterprise. Verifique se o seu hardware ou configuração particular precisa de considerações especiais, quais dos seus pacotes de software específicos preferidos sofreram mudanças significativas e quais precauções você deve tomar além das recomendações gerais desta seção. As Notas de Versão também apresentam informações de último minuto e problemas conhecidos, que não seria possível incluir a tempo no manual.

É possível ler online a versão atual do documento das notas de versão com as informações mais recentes sobre o SUSE Linux Enterprise Server em http://www.suse.com/doc/sles12/#start.

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, assim como a alguns dos 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.

Antes de iniciar a atualização, anote a partição raiz. O comando df / relaciona o nome do dispositivo da partição raiz. Por exemplo, em Exemplo 7.1, “Listar com df -h”, a partição raiz a ser anotada é a /dev/sda3 (montada como /).

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

O software tende a “crescer” a cada versão. Portanto, verifique o espaço de partição disponível com df antes de atualizar. Se você achar que está ficando sem espaço em disco, proteja os dados antes de atualizar e reparticionar o sistema. 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.

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.

Para fazer uma atualização online, os seguintes requisitos devem ser atendidos. Leia também a Seção 7.3, “Preparações gerais para atualização”.

Importante: Sempre executar a migração online completa

A migração online deve sempre ser realizada do início ao fim. Se ela for interrompida durante sua execução, o sistema será corrompido sem meios de recuperação.

A atualização do sistema pela migração online é feita no sistema que está em execução. Só é preciso reinicializar uma vez após o término da atualização.

7.4.4.1 Requisitos #

Para fazer uma atualização online, os seguintes requisitos devem ser atendidos. Leia também a Seção 7.3, “Preparações gerais para atualização”.

Registro de Produto

Para se conectar aos repositórios de atualização, seu produto deve estar registrado. Se não estiver, execute o módulo Configuração do SUSE Customer Center no YaST ou a ferramenta de linha de comando suse_register para iniciar o registro.

Executar Atualização Online

Verifique se a versão instalada tem os patches mais recentes também instalados. Execute a Atualização Online antes da Migração Online. Ao usar uma interface gráfica, inicie a Atualização Online ou o applet de atualização do YaST. Na linha de comando, execute os seguintes comandos (o último precisa ser executado duas vezes):

zypper ref -s
zypper update -t patch
zypper update -t patch

Se necessário, reinicialize o sistema.

Consulte o Chapter 1, YaST Online Update, Administration Guide ou a Section “Updating Software with Zypper”, Chapter 6, Managing Software with Command Line Tools, Administration Guide. para obter mais informações. sobre as ferramentas de atualização online.

Software de Terceiros

Se a configuração envolver software de terceiros ou complementar, teste esse procedimento em outra máquina para garantir que as dependências não sejam danificadas pela atualização.

Importante: Sempre executar a migração online completa

A migração online deve sempre ser realizada do início ao fim. Se ela for interrompida durante sua execução, o sistema será corrompido sem meios de recuperação.

7.4.4.2 Migração online com o YaST Wagon #

Nota

A migração online com o YaST Wagon só está disponível antes do SUSE Linux Enterprise Server 12.

1. Com todos os requisitos atendidos (consulte a Seção 7.4.4.1, “Requisitos”), o applet de atualização na bandeja exibirá uma mensagem informando que há um upgrade de distribuição disponível. Clique nela para iniciar o YaST Wagon. Se preferir, execute /usr/sbin/wagon como root na linha de comando.

2. Confirme a caixa de diálogo Bem-vindo clicando em Avançar.

3. Se o Wagon determinar que os requisitos não foram cumpridos (há atualizações de manutenção necessárias disponíveis, mas que ainda não foram instaladas), ele fará uma autoatualização, o que pode exigir a reinicialização. Siga as instruções na tela.

4. Escolha o método de atualização na caixa de diálogo seguinte. Escolha Atendimento ao Cliente para usar a configuração padrão (recomendada).

   Clique em URL Personalizado para escolher manualmente os repositórios de software usados na migração online. Uma lista de repositórios será exibida com opções para habilitar, desabilitar, adicionar ou apagar manualmente os repositórios. Adicione a(s) fonte(s) de atualização do SP2. Pode ser a mídia de instalação do SP2 ou os repositórios SP2-Core e SP2-Updates. Clique em OK para retornar à caixa de diálogo Método de Atualização.

   Para revisar as mudanças feitas na configuração do repositório em virtude do processo de atualização, selecione Verificar Mudanças Automáticas no Repositório.

   Continue com Avançar.

5. O sistema será registrado novamente. Durante esse processo, os repositórios SP2-Core e SP2-Updates são adicionados ao sistema (consulte a Seção 7.7.2, “Modelo de repositório” para obter mais informações). Confirme a adição dos repositórios.

6. Se você selecionou Verificar Mudanças Automáticas no Repositório na caixa de diálogo Método de Atualização, a lista de repositórios será exibida com opções para habilitar, desabilitar, adicionar ou apagar manualmente os repositórios. Quando estiver pronto, clique em OK para continuar.

7. Escolha o tipo de migração:

   Migração completa

   Atualiza todos os pacotes para o último nível do SP2.

   Migração Mínima

   Atualiza um conjunto mínimo de pacotes para último nível do SP2.

   Clique em Avançado para selecionar manualmente os repositórios usados para o upgrade.

   Confirme sua seleção.

8. A tela Configurações do Upgrade da Distribuição é aberta com um resumo da configuração de atualização. As seguintes seções estão disponíveis:

   Produtos acessórios

   É possível adicionar produtos complementares do SUSE Linux Enterprise Server ou produtos de terceiros aqui.

   Opções de Atualização

   Lista as ações que serão realizadas durante a atualização. Você escolhe se vai fazer download de todos os pacotes antes de instalá-los (padrão, recomendado) ou se vai fazer download e instalar os pacotes um de cada vez.

   Pacotes

   Visão geral das estatísticas da atualização.

   Backup

   Defina as opções de backup.

   Clique em Avançar e em Iniciar Atualização para continuar.

   

   Importante: Interrompendo a migração online

   É seguro interromper a migração online nesta tela antes de clicar em Iniciar Atualização e em todas as telas anteriores. Clique em Interromper para sair do procedimento de atualização e restaurar o sistema ao estado em que estava antes de iniciar o YaST Wagon. Siga as instruções na tela e refaça o registro antes de sair do Wagon para remover os repositórios do SP2 do sistema.

9. Durante o procedimento de atualização, as seguintes etapas são executadas:

   1. Os pacotes serão atualizados.

   2. O sistema será reinicializado (clique em OK).

   3. O sistema recém-atualizado será registrado novamente.

10. O sistema foi atualizado com êxito para o Service Pack 2.

Como alternativa à Migração Online (consulte a Seção 7.4.4, “Migração Online” para obter os detalhes), é possível também atualizar o sistema inicializando de uma fonte de instalação: seja um DVD ou uma rede. A atualização é iniciada como uma instalação normal.

Você obtém as imagens ISO do Service Pack 2 no site http://download.suse.com/. Grave-as em um DVD ou prepare a fonte de instalação de rede conforme descrito na Seção 14.2, “Configurando o servidor que mantém as fontes de instalação”.

Em vez de fazer download das atualizações para cada sistema cliente do servidor de atualização do SUSE, é possível usar a SMT (Subscription Management Tool) do SUSE Linux Enterprise para espelhar as atualizações para um servidor local.

Essa ferramenta atua como proxy do SUSE Customer Center para os registros do cliente e como repositório de atualização de software. A documentação da SMT no site http://www.suse.com/doc/smt11/ apresenta uma visão geral dos recursos e as instruções de como implementá-la.

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.

A documentação do SUSE Manager no site http://www.suse.com/doc/suse_manager/ apresenta uma visão geral dos recursos e instruções de como configurar servidor e clientes.

É possível fazer upgrade do sistema inicializando de uma fonte de instalação, seja um DVD local ou uma rede, assim como se faz no caso de uma instalação nova. Em seguida, basta selecionar "Fazer Upgrade" em vez de "Instalar" na Tela de Boot para fazer upgrade do sistema.

Para executar a migração automatizada, faça o seguinte:

Execute multi-update. Esse comando executa o zypper em um ambiente chroot e atualiza o outro sistema, não importa qual é o ativo. Seu menu de boot será oferecido como o padrão na hora do boot.

Se o sistema atualizado tiver o carregador de boot danificado após a atualização, mude o flag “Ativo” e defina-o como a partição raiz do outro sistema para inicializá-lo.

Se o sistema atualizado não for inicializado de forma alguma, você precisará de acesso ao menu do carregador de boot para selecionar o outro sistema.

Para obter mais informações sobre o GRUB 2, consulte o Chapter 12, The Boot Loader GRUB 2, Administration Guide.

A partição raiz deve ser montada pelo nome ou ID da partição, ou de alguma outra forma. Não é suportado montar por UUID ou por rótulo da partição.

Para obter mais informações, consulte o /usr/share/doc/packages/multi-update-tools/README que acompanha o pacote multi-update-tools.

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. Esses níveis de suporte atualizam de maneira pró-ativa as explorações comuns de raiz local no Kernel ou outras explorações de raiz diretamente executáveis, sem a intervenção do usuário. Além disso, oferecem suporte a cargas de trabalho existentes, pilhas de software e hardware com lista de exclusão de pacotes limitada. Consulte a visão geral na Tabela 7.1, “Atualizações de segurança e correções de bugs”.

O layout do repositório corresponde aos ciclos de vida dos produtos. A Tabela 7.2, “Layout do repositório do SUSE Linux Enterprise 11 SP2 e SP3 e do SUSE Linux Enterprise 12” inclui uma lista de todos os repositórios do SUSE Linux Enterprise 11 SP2 para o SUSE Linux Enterprise 12.

zypper repos -u

zypper removerepo SLES11-SP1-Pool SLES11-SP1-Updates \
    SLE11-SP1-Debuginfo-Pool SLE11-SP1-Debuginfo-Updates \
    SLES11-SP2-Core SLES11-SP2-Updates \
    SLE11-SP2-Debuginfo-Core SLES11-SP2-Extension-Store\
    SLE11-SP2-Debuginfo-Updates

zypper addrepo -n SLES11-SP2-Extension-Store \
    https://nu.novell.com/repo/\$RCE/SLES11-SP2-Extension-Store/nu_novell_com:SLES11-SP2-Extension-Store

O foco principal dos desenvolvedores de upstream está na evolução do software que eles criam. Em muitos casos, 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:

Na maioria dos casos, os desenvolvedores de distribuição não seguem todas as mudanças de upstream, uma vez que o pacote tenha se tornado 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 usa bastante os 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 uma classe limitada de pacotes, em alguns softwares antivírus, 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. Dessa forma, essas ferramentas/testes estão propensas a gerar “falsos positivos” (alegando ter encontrado alguma parte vulnerável do software que, na verdade, não é vulnerável) quando há backports envolvidos. Durante a avaliação dos relatórios das ferramentas de exploração de segurança, convém sempre investigar se uma entrada se baseia no número da versão ou no teste real de uma vulnerabilidade que realmente exista.

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

Os scripts são pesquisados no diretório /var/lib/YaST2/wagon/hooks/. O nome do script esperado deve estar no formato etapa_seq_prefixo_nome, em que:

/var/lib/YaST2/wagon/hooks/before_package_migration_00_postgresql_backup

O script deve retornar o valor de saída 0. Em caso de falha (qualquer valor de saída diferente de zero), será exibida uma mensagem de erro no Wagon, e será possível reiniciar o script, ignorar a falha (e continuar com os outros scripts) ou cancelar completamente os ganchos na etapa ou fase atual.

Os scripts de gancho podem ser executados mais vezes (na troca de diálogos no Wagon, o Wagon pode se reiniciar ou executar algumas etapas várias vezes no workflow de migração); portanto, os scripts precisam lidar com esse fato (eles podem verificar logo no início se precisam realizar alguma ação ou se a ação já foi realizada, podem criar um arquivo de marcação temporário simples ou resolver de alguma forma as várias execuções apropriadamente).

Alguns ganchos são opcionais (porque dependem de resultados anteriores ou de valores selecionados pelo usuário). Observe que alguns ganchos são chamados várias vezes (por exemplo, o registro é chamado antes e após a migração). Veja a lista de ganchos suportados (nomes das etapas) em ordem de execução:

Esses são ganchos especiais de interrupção, chamados quando o usuário interrompe a migração. Esses ganchos podem ser chamados em qualquer etapa do workflow de migração; portanto, a ordem de execução não é garantida. Os scripts terão que verificar o estado atual se confiarem nos resultados de outros ganchos.

Esses ganchos são chamados sempre que o Wagon se reinicia.

A lista de ganchos é bem extensa, mas muitos deles só fazem sentido em casos especiais. Em casos de uso normal, dê preferência a estes ganchos:

As versões mais antigas do Wagon suportavam apenas dois scripts de gancho: /usr/lib/YaST2/bin/wagon_hook_init e /usr/lib/YaST2/bin/wagon_hook_finish. O problema era que somente um script podia ser executado como gancho e não era possível inserir os ganchos diretamente nos pacotes RPM.

Esses scripts de gancho antigos ainda são suportados nas versões mais recentes do Wagon para compatibilidade retroativa, mas os novos ganchos before_init e before_exit devem ser usados no lugar dos ganchos obsoletos.