Preparando -se para aplicar atualizações no Red Hat Linux

Objetivo

Nosso objetivo é garantir que a atualização do sistema operacional seja executada sem problemas e sem erros.

Sistema operacional e versões de software

• Sistema operacional: Red Hat Enterprise Linux 6+

Requisitos

Acesso privilegiado aos sistemas

Dificuldade

FÁCIL

Convenções

• # - requer que os comandos Linux sejam executados com privilégios root diretamente como usuário root ou por uso de sudo comando
• $ - dados os comandos do Linux a serem executados como um usuário não privilegiado regular

Introdução

Manter o sistema atualizado é uma tarefa diária para um sysadmin, bem como um usuário de desktop. Ao aplicar o software mais recente (estável) disponível no sistema, podemos tirar proveito dos recursos mais recentes e estaremos mais protegidos contra problemas de segurança e, esperançosamente, sofrerem com bugs. Para atualizar o sistema, você precisará configurado yum Repositórios que atuam como fonte do software atualizado.

Se você se sentar ao lado da máquina que está executando o sistema operacional a ser atualizado, poderá agir facilmente se algo der errado durante a atualização, como verificar a saída no terminal ou inicializar para um sistema vivo se o atualizado não retornar reiniciar - mas nem sempre é esse o caso. Pense em um datacenter com centenas ou milhares de máquinas (virtuais), ou simplesmente um PC físico que você precisa atualizar remotamente.

Existem etapas simples que podemos executar para preparar o sistema para atualizar e possivelmente esclarecer qualquer problema que pôr em risco uma atualização bem -sucedida.

Processo de atualização

Ao executar uma atualização incondicional (que significa "atualizar tudo"), yum buscará todos os metadados dos repositórios disponíveis e calcularão todos os pacotes a serem atualizados contra o RPM Banco de dados que contém todos os metadados sobre pacotes instalados no sistema.

O processo de atualização também calcula todas as dependências dos pacotes atualizados, pode substituir pacotes antigos e remover imagens antigas do kernel de acordo com sua configuração. O número de imagens do kernel para manter é definido no /etc/yum.conf arquivo de configuração e é 3 por padrão:

installonly_limit = 3

Depois de todas as modificações necessárias calculadas, yum Fornece uma extensa lista de todos os pacotes a serem atualizados, removidos ou instalados para dependências, da mesma maneira que ao instalar ou atualizar pacotes específicos.

Em uma sessão de atualização interativa yum fornecerá um resumo dos pacotes a serem modificados, bem como o cálculo do tamanho dos dados precisam ser baixados para a atualização, como mostrado abaixo:

Depois de examinar os resultados, podemos decidir se iniciarmos a atualização ou cancelar. Como Yum atualizará tudo o que pode encontrar atualizações, podemos querer remover pacotes desnecessários com antecedência. Também podemos notar um pacote marcado para atualização que estamos bloqueados com a versão com a necessidade de ser excluída da atualização.

Após a aprovação, o Yum baixará todos os novos pacotes e instalará/atualiza um por um. Quando concluído, ele verificará a integridade dos pacotes instalados/atualizados, limpe os arquivos desnecessários. Ele também fornece feedback durante o processo, fornecendo uma linha de texto para cada etapa, bem como um código de saída que sugere se a atualização foi bem -sucedida ou se surgir algum problema. Ele também cancelará o processo de atualização se um problema aumentar que parecer crítico da perspectiva consistente do sistema - mas há momentos em que já está tarde demais, portanto, impedir que os problemas de atualização aconteçam é uma abordagem melhor.

Espaço em disco

cache yum

Do processo descrito acima, poderíamos adivinhar que precisamos de algum espaço em disco para o processo de atualização:

• Os metadados de todos os repositórios configurados precisam ser armazenados até o cálculo de todos os pacotes (e suas dependências) para serem atualizados acabamentos.
• RPM Pacotes que constituem a própria atualização precisam ser armazenados localmente até instalar corretamente.

Esses dados, chamados cache yum é necessário apenas durante a atualização, mas pode ocupar um espaço de disco substancial. O local padrão para este cache está no /var/cache/yum diretório. Escusado será dizer que, se não houver espaço suficiente para armazenar todos os dados necessários, o processo de atualização falhará. Alguns downloads inacabados serão descartados, mas nem todo espaço pode ser libertado, o que acaba tendo um sistema falhou na atualização e tem seu volume contendo /var/cache quase cheio.

Muitas instalações armazenam seus /var diretório em um volume dedicado à exploração de log, como o local padrão para arquivos de log é /var/log Na maioria das distribuições, e a maioria dos aplicativos de bem-estar parará de funcionar ou até travar se não conseguirem escrever seus arquivos de log. Então, preencher o volume que eles estão escrevendo é um coisa ruim.

Quanto mais pacotes precisam ser atualizados e quanto mais repositórios tivermos, mais espaço a atualização ocupará temporários. Para calcular esse espaço da atualização para a atualização, é difícil, mas pode ser testado com a solução de corrida a seco descrita mais tarde se tivermos uma máquina de teste com o conteúdo exato do software. Para um exemplo em tempo real, atualizando do Rhel 7.1 a 7.5 (a instalação da área de trabalho com o Gnome) pode ocupar 4 GB de espaço de cache, mas a instalação de algumas correções em um sistema que está apenas um ou dois meses desatualizado ocupará apenas alguns MB.

Para verificar quanto espaço temos, podemos usar o df comando:

# df -h/var/arquivos do sistema usado use% montado em/dev/mapper/vg_sys -Var 6.0g 1.7g 4.4G 28% /VAR 

No exemplo acima, temos 4.4 GB de espaço livre, o que será suficiente, já que o servidor foi atualizado apenas alguns meses atrás. Para liberar espaço, um passo trivial seria limpar o cache yum já armazenado (talvez na última atualização). Para verificar quanto espaço o cache ocupa no momento, podemos usar du:

# du -mcd 1/var/cache/yum 1103/var/cache/yum/x86_64 1103/var/cache/yum 1103 Total 

Os números acima estão em MB, então o cache yum Neste exemplo, ocupa cerca de 1 GB de espaço em disco e ocupa a maior parte do espaço no /var volume.

Limpar o cache

Podemos limpar todo o cache com o seguinte comando:

yum limpe tudo

Mas como yum Notifica -nos na saída do comando acima nas versões RHEL 7, pode haver dados órfãos de repositórios removidos ou desativados, que provavelmente acontecerão após pequenos ugrades de liberação; nesse caso, podemos limpar com segurança os dados manualmente:

rm -rf/var/cache/yum/*

Podemos obter mais espaço para a atualização, limpando outros dados armazenados no volume, como compactar/excluir arquivos antigos, mover arquivos grandes para outros volumes ou estender o tamanho do volume.

Movendo o cache

Trabalhar com as possibilidades de yum, Se estivermos muito pouco no espaço em disco, não podemos limpar mais nada e não podemos adicionar mais espaço ao volume, podemos mover a localização do cache yum para outro volume com mais espaço livre. Podemos configurar o local do cache no yum.conf arquivo de configuração mencionado acima. Considere a configuração padrão:

Cachedir =/var/cache/yum/$ Basearch/$ releasever

Mudando o caminho antes $ Basearch A próxima operação YUM funcionará com a mesma estrutura de diretório, mas em um caminho diferente - espero com mais espaço livre para a atualização. Também podemos mover o cache para outro volume movendo todo o diretório:

mv/var/cache/yum/extend_data_volume/

E criando um symblink no local original que aponta para o novo local:

ln -s/extend_data_volume/yum/var/cache/yum

É aconselhável saber que a atualização não falhará em um erro trivial, como o baixo espaço em disco. Em um grande sistema Sysadmins implantam ferramentas de monitoramento como Nagios que podem relatar espaço em disco baixo em todas as máquinas, tornando essa etapa muito menos demorada e propensa a erros.

Erros de rede

Se houver problemas com a conectividade entre os repositórios e a máquina que executa a atualização, a atualização poderá falhar. Isso só pode acontecer nos metadados, ou no novo estágio de download de RPMs, e não quebrará o sistema. Você pode iniciar o processo de atualização novamente quando o problema da rede for resolvido.

Por outro yum pode perguntar. Se o estágio de instalação/atualização do pacote já iniciado, continuará desacompanhado e poderá falhar ou concluir se o faria de outra forma. Após a reconexão, o processo pode ser seguido no /var/log/yum.registro.

Yum Run Dry

Além de problemas insuficientes de disco e de rede, a atualização em muitos casos pode falhar nas dependências de pacotes não resolvidas. Eles precisam ser resolvidos com ferramentas que podem calcular e lidar com dependências de pacotes, mas seria útil saber que haverá problemas antes da atualização real (e, portanto, não desperdiçar o tempo de inatividade sempre muito curto do sistema). Para obter essas informações valiosas, podemos executar o processo de atualização, pois ele executaria a atualização real, mas pare antes de qualquer pacote real download, instalar ou atualizar.

Em torno de Redhat 6.6 Foi introduzida uma nova opção que causará yum Para assumir "não" a todas as perguntas que surgem durante a atualização - incluindo a aprovação antes do estágio real de manipulação do pacote e, como conseqüência, nenhuma interação real é necessária, execute uma execução a seco:

YUM ATUALIZAÇÃO --SUSMUMENO

Esta pode ser a ferramenta ideal para fornecer uma execução a seco da próxima atualização, incluindo pacotes a serem atualizados e quaisquer erros o que possa ocorrer. Considere o seguinte simples Bash roteiro:

#!/bin/bash yum update --assumeno &> $ (nome do host).yum.funcionamento a seco.$ (data '+%y-%m-%d').saída de saída $? 

O script acima pode ser executado automaticamente e fornecerá um relatório de texto da corrida a seco, bem como um código de saída geral indicando quaisquer problemas. A saída não precisa ser salva no sistema de arquivos local. O alvo do redirecionamento de saída pode ser um sistema de arquivos de rede, ou o relatório pode ser publicado em algum servidor de relatórios centrais, pode ser coletado por outros scripts ou aplicativos. Os relatórios podem ser publicados e distribuídos entre outros departamentos de TI para aprovação, assim todos os envolvidos podem ver exatamente quais pacotes serão atualizados e para qual versão.

A corrida a seco pode ser programada para ser executada em um determinado período de tempo (talvez à noite para impactar menos o desempenho do sistema) com Cron, ou executado de uma fonte central com uma configuração de fantoche. O código de saída também pode ser armazenado e processado pelo monitoramento ou Facter, Para agregar os possíveis resultados da próxima atualização antes de prosseguir.

Conclusão

Mesmo com um ou alguns computadores, devemos coletar informações antes de iniciar uma atualização de todo o sistema operacional, apenas para estar do lado seguro. Um dia, haverá um problema, e é muito menos estressante se você puder resolvê -lo antes que tenha impacto no trabalho real de uma determinada máquina. Em uma escala maior, simplesmente não é possível sentar -se ao lado de cada servidor ou desktop e apoiá -lo com sua presença na esperança de que isso ajude a atualização para executar perfeitamente.

Ao conhecer os estágios do processo de atualização, as armadilhas e a solução para elas são essenciais para atualizações bem -sucedidas. Iniciando a próxima atualização de toda a sua infraestrutura com a confiança de que não haverá problemas é fazer isso com o estilo.

Tutoriais do Linux relacionados:

• Coisas para instalar no Ubuntu 20.04
• Coisas para fazer depois de instalar o Ubuntu 20.04 fossa focal linux
• Arquivos de configuração do Linux: os 30 primeiros mais importantes
• Linux pode obter vírus? Explorando a vulnerabilidade do Linux…
• Uma introdução à automação, ferramentas e técnicas do Linux
• Download do Linux
• Como atualizar o Firefox no Linux
• Coisas para fazer depois de instalar o Ubuntu 22.04 Jellyfish…
• Melhor distro Linux para desenvolvedores
• Mint 20: Melhor que o Ubuntu e o Microsoft Windows?