Olá a todos,

Recentemente uma colega perguntou-me qual seria a melhor forma de garantir que o patch que fazia nas máquinas de Clientes que gere, fosse controlado não pela versão dos patches disponíveis nos repositórios, mas pela data de emissão dos mesmos.
O interesse dela seria garantir que todas as máquinas que eram atualizadas, o eram com os mesmos patches, fossem eles aplicados no mês 1, no mês 2 ou no mês três.

Isto é particularmente importante em plataformas que tenham patamares distintos de desenvolvimento, testes e produção, pois torna possível garantir que os patches de sistema operativo que são testados em desenvolvimento são os mesmos que são  aplicados em produção, mesmo que já tenham saído novos naquele canal em particular.

Sei que para alguns dos leitores isto poderá parecer estranho, mas acreditem que em termos de plataformas corporativas que tem de estar sempre disponíveis, nem sempre o ultimo é o melhor, testar é mandatário e estabilidade com segurança é fundamental.

Para esta função, o spacewalk disponibiliza uma ferramenta muito interessante nos seus utilitários com o nome spacewalk-clone-by-date, presente no pacote spacewalk-utils.

Este utilitário, como o nome indica, clona um channel para outro, baseando-se na data limite de produção dos patchs que integram dito channel.

A sintaxe do comando é relativamente simples, sendo composta pelo ficheiro de configuração e a data limite de patches a serem aceites.

/bin/spacewalk-clone-by-date --config=/home/automation/patch.cfg -d "2019-01-01"

É necessário definir o ficheiro de configuração para o clone, neste caso o patch.cfg:

# cat /home/automation/patch.cfg
{
       "username": "automation",
       "password": "1234567890",
       "assumeyes": true,
       "skip_depsolve": false,
       "security_only": false,
   "blacklist": {
       "ALL": [
         ""
          ]
                },
    "removelist": {
        "ALL": [
         ""
         ]
               },
    "channels": {
          "centos7.epel": "patches-epel-centos",
          "centos7.updates": "patches-epel-updates"
                }
}

No caso da configuração acima, estou a clonar dois repositórios, utilizando para tal a data de limite de construção dos patches – 1 de Janeiro de 2019, e para o fazer, autentico-me como o utilizador interno criado por mim no spacewalk com o nome de automation e password 1234567890. Não coloquei nenhum patch em blacklist.
Podem escolher qualquer nome para o software channel, desde que respeite os caracteres permitidos pelo spacewalk, e que vos seja fácil de associar no futuro.

No caso presente, escolhi os nomes patches-epel-centos e patches-epel-updates como destinatários dos clones. São nomes genéricos, pelo que poderei os deixar registados nos sistemas-cliente no futuro, efetuando atualizações das novas erratas, para o mesmo nome, mas com datas diferentes.

É importante que não se esqueçam do utilizador interno de spacewalk para a operação e que o utilizador tenha permissões suficientes para a efetuar.

Como nota final, lembro que o CentOS não carrega erratas automaticamente (ie. identificação por data que é o que nos permite fazer a separação).
Para se conseguir fazer uso dessa feature, pf visitem esta pagina, e corram o script que faz o carregamento das erratas baseadas nos alertas das mailing lists de CentOS.
Este problema não se manifesta nem no SuSE nem no RedHat Enterprise Linux, que agora na versão 2,9 do Spacewalk já é suportado até a versão 8.

Caso tenham duvidas, ou reparos, já sabem onde me encontrar. Até já!

Até já!
Nuno