Backups automáticos de equipamentos de rede e seu armazenamento no sistema de controle de versão

Esclarecimento: a solução está configurada para D-Link DFL, cisco 29xx e WatchGuard Firebox, mas é adequada para tudo o que pode fazer backup ao conectar via ssh e / ou carregá-los em um agendamento / evento para o servidor ftp / tftp.

Tudo começou com o fato de meu amigo programador perguntar: "Por que você não armazena configurações de rede no sistema de controle de versão?" E a verdade - pensei - por quê? A maioria dos arquivos de configuração pode ser baixada em formato de texto (bem, esses são binários, é claro, mas as informações legíveis são abertas e exibidas em um editor de texto).

Na rede, temos cerca de 30 DFLs D-Link diferentes, uma dúzia de Cisco 29xx e duas WatchGuard Firebox. Para cada dispositivo, os funcionários de nível de administrador da filial de TI, onde está, além da TI da matriz, têm acesso no nível de administrador. Isso envolve problemas como "eu não fiz backup por seis meses e quebrei tudo, você tem o nosso backup?" E "o equipamento queimou o último backup fez o administrador anterior, não sei onde, nos configurar como estava". E se o Cisco já redefine automaticamente o running-config para ftp toda vez que é salvo, esse não é o caso do D-Link. E o sistema de controle de versão ajudaria a rastrear problemas como "Não lembro o que e quando mudei, mas temos algo que é usado uma vez que um mês está quebrado". O regulamento de backup não salva você do fator humano e não faz backup para você; portanto, é melhor advertir do que desembaraçar.

Eu admito sinceramente, antes de me sentar para escrever um post, eu não sabia sobre ranço e oxidação. Mas os dois não sabem o que eu preciso por completo. O primeiro é voltado para cisco e não funciona muito bem com exóticos, o segundo não possui autorização do usuário (embora isso possa ser feito com simples manipulações com o servidor da web) e, o mais importante, ambos exigem um login e senha para o sistema redundante. Todos os DFLs de link D suportam login ssh. A Cisco mescla os próprios backups e geralmente não requer conexão com ele. Portanto, por que manter as senhas alteradas periodicamente, além disso, se você pode fazer login usando a chave.

Foi decidido fazer algo que me convém por conta própria.

Na verdade, os backups automáticos imploram por um longo tempo. Mas o sistema de controle de versão - era novo.

Portanto, a tarefa: coletar todas as configurações significativas do equipamento de rede em um local com suporte para arquivos de versão, atualizá-las regularmente automaticamente lá, para permitir que administradores em outro fuso horário as baixem de uma maneira simples, sem me ligar às 3 da manhã. Tudo isso, é claro, é gratuito.

Para todos os DFLs, o arquivo de configuração é chamado de mesmo, portanto, era necessário nomeá-los claramente ao copiar. Eu também não queria reconfigurar o sistema de preenchimento de configuração em execução existente para ftp com cisco.

Primeiro, configure um sistema de controle de versão


Eu peguei svn, tk. svn é o único popular que armazena binários diff, nem todos os arquivos do histórico. Não que isso fosse importante em pequenos volumes, mas agradável. Em geral, levo em consideração a pequena quantidade de arquivos de configuração que o sistema de controle de versão deve levar - sem diferença.

O servidor Visual SVN é instalado no site oficial usando o método pronto para uso. Coloquei-o em um servidor no Windows, para facilitar a administração dos colegas (criar usuários, distribuir direitos). Em seguida, um repositório é criado, as seções necessárias são criadas nele e o único usuário com direitos totais ao repositório é criado (por enquanto). No Windows, as ações são concluídas.

Os backups automáticos são feitos por mim a partir de uma única máquina Linux (no Debian).

Primeiro, configuramos o svn para termos um cliente:

sudo apt-get install svn 

Agora, uma cópia do projeto é criada manualmente (criada no diretório atual):

 svn checkout https://servername.mydomain.ru/svn/DFL_BACKUPS/ DFL_BACKUPS --username go 

Agora eu tenho três seções no repositório:

  • Current_backup, onde as configurações DFL da D-Link são armazenadas e substituídas.
  • Old_versions, em que configurações com uma data atribuída são armazenadas para facilitar o download pelos administradores da filial.
  • Cisco, onde as configurações de Cisco e WatchGuard Firebox são armazenadas (bem, aconteceu).

Vamos começar com os backups automáticos do DFL e configurar o próprio DFL


A conexão continua no ssh. Para não exibir senhas de forma aberta, é usado um par de chaves público-privado. Privado é armazenado no servidor em / usr / dfl_scripts / sshkeys / dfl_key.

Geramos um par de chaves público-privadas no servidor de backup automático:

 ssh-keygen –t rsa 

o aberto é derramado em todas as DFLs e a regra de acesso ssh é feita:





Bem, o gerenciamento remoto correspondente é permitido. A porta do padrão pode ser alterada para, por exemplo, 2222, embora o acesso seja possível apenas a partir de determinados endereços.



O arquivo com a configuração atual do D-Link DFL está na raiz e é chamado config.bak; você pode simplesmente copiá-lo para si mesmo usando scp.

Então, o script (cortei a lista de ramos para que não houvesse folha):

 #!/bin/bash rm /usr/dfl_scripts/dflbackup/* #    dfls=( "amur:10.28.10.254" #  "arhangelsk:10.29.10.254" "buratia:10.3.10.254" "volgograd:10.34.10.254" "voronezh:10.36.10.254" "irkutsk_210:10.38.20.253" "irkutsk_260:10.38.20.254" "yaroslavl:10.76.10.254" ) rm /usr/dfl_scripts/log.txt # - for dfl in "${dfls[@]}" ; do #   - filial="${dfl%%:*}" #delete the longest substr :* search from the end of string ip_addr="${dfl##*:}" #delete the longest substr *: search from the head of string echo $filial $ip_addr >> /usr/dfl_scripts/log.txt #     scp -P 2222 -i /usr/dfl_scripts/sshkeys/dfl_key admin@$ip_addr:config.bak /usr/dfl_scripts/dflbackup/$filial.bak 2>>/usr/dfl_scripts/log.txt #   ,      done FILES=$(ls /usr/dfl_scripts/dflbackup) #     now=$(date +"%d_%m_%Y") #     for f in $FILES ; do #      (    ) cp /usr/dfl_scripts/dflbackup/$f /usr/dfl_scripts/DFL_BACKUPS/current_backup/$f #       cp /usr/dfl_scripts/dflbackup/$f /usr/dfl_scripts/DFL_BACKUPS/old_versions/${f%.bak}_$now.bak #        done cd /usr/dfl_scripts/DFL_BACKUPS #   svn  svn add * --force -q >> /usr/dfl_scripts/log.txt #  .    . svn commit -m "added backups $now" >> /usr/dfl_scripts/log.txt #     /usr/bin/mail it@mydomain.ru < /usr/dfl_scripts/log.txt -s "   DFL" #    -   

O script é compactado no cron e é executado às 8:30 da manhã diariamente. É assim que o crontab se parece:
 30 08 * * * /usr/dfl_scripts/autobackup.sh 30 06 * * * /usr/dfl_scripts/ciscobackup.sh 00 06 * * 1 /usr/dfl_scripts/fireboxbackup.sh 

Agora sobre cisco


Nos próprios dispositivos, algo como isto está configurado:

 archive log config logging enable logging size 500 hidekeys path ftp://ftp.mydomain.ru/in/autolog/$H-$T write-memory ip ftp username user ip ftp password mypass ip scp server enable 

Como resultado, o comando write-memory redefine a configuração atual para ftp. Meu ftp está em um servidor diferente de um monte de backups automáticos. Existem duas maneiras: fazer uma cópia do repositório nesse servidor e adicionar configurações lá ou copiar configurações para um servidor vizinho. Basicamente, toda a diferença é se deve fazer cp ou scp.

No diretório em que as configurações com Cisco caem, coloquei o incron para monitorar a aparência dos arquivos. Pela aparência do arquivo, eu o renomeio como deveria e copio-o para o servidor coletor de backup automático em um diretório temporário. Ao recortar, os arquivos do diretório temporário são carregados no svn. No total, eu tenho no sistema de controle de versão uma configuração atualizada por um certo tempo, uma vez por dia. Na minha opinião, isso é suficiente, mas o sistema pode ser modificado sem problemas para qualquer lista de desejos.

A configuração do incrontab é assim:

 /var/ftp/cisco/in/autolog/ IN_CREATE /usr/ftp_scripts/incron_cisco.sh $# $% 

O script em si:

 #!/bin/bash if [[ $2 == "IN_MOVED_TO" || $2 == "IN_CREATE" ]]; then sleep 10 filial="${1%%-*}" #delete the longest substr -* search from the end of string.        scp -P 2222 -i /usr/ftp_scripts/ssh_key_private /var/ftp/cisco/in/autolog/$1 go@10.10.10.220:/usr/dfl_scripts/ciscobackup/$filial.conf fi 

O script agendado é iniciado no servidor de backup automático de acordo com o agendamento:

 #!/bin/bash logfile=/usr/dfl_scripts/log_cisco.txt rm $logfile now=$(date +"%d_%m_%Y") cd /usr/dfl_scripts/DFL_BACKUPS cp /usr/dfl_scripts/ciscobackup/* /usr/dfl_scripts/DFL_BACKUPS/cisco/ svn add * --force –q >> $logfile svn commit -m "added cisco backups $now" >> $logfile /usr/bin/mail it@mydomain.ru < $logfile -s "   cisco  watchguard" 

Como você pode ver, aqui também estamos falando sobre o WatchGuard Firebox. Eu estava francamente com preguiça de criar um diretório separado para eles. Portanto, os backups caem no ftp no mesmo local que o Cisco. Os backups do WatchGuard em um script separado meia hora antes e geralmente uma vez por semana. Observe que a sintaxe foi alterada da versão de firmware 12. Anteriormente, isso podia ser feito com uma imagem de backup no comando ftp e agora a exportação foi adicionada. Nele, não consegui configurar o login via ssh por chave, portanto, as senhas são usadas.

 #!/bin/bash watchguards=( "10.10.10.20:password1" "10.97.10.20:password2" ) now=$(date +"%Y_%m_%d") for wg in "${watchguards[@]}" ; do ip_addr="${wg%%:*}" pass="${wg##*:}" sshpass -p $pass ssh backupuser@$ip_addr -p 4118 << ENDME backup image WG_$now.fxi export image WG_$now.fxi 123456qQ to ftp://user:mypass@ftp.mydomain.ru/in/autolog/WG_$ip_addr-$now.fxi ENDME Done 

Os binários do WatchGuard são exportados apenas criptografados, portanto, com uma aparência de texto e uma diferença, não funcionará muito bem. Preste atenção à chave de criptografia: letras maiúsculas e minúsculas obrigatórias e números, no mínimo 8 caracteres. Em caso de não conformidade, o comando simplesmente não é executado, não é indicado especificamente onde está o erro.

Então, tudo foi feito. Agora, colocamos o cliente em nosso computador de trabalho no Windows. Você pode simplesmente visualizar arquivos e diferenças no navegador, mas baixe a versão de uma revisão específica apenas do cliente. Colocamos o TorToSiteSVN no site oficial .

No servidor, crie um usuário com os direitos necessários (leitura) para as ramificações.

Então você precisa inserir o cliente através do menu de contexto em qualquer arquivo e conectar-se ao repositório. Não é necessário criar uma cópia do repositório se você não planeja fazer alterações nos arquivos. Bem, tenha cuidado com isso, você precisará trabalhar com a cópia através do sistema de controle de versão, e não apenas com uma parte do sistema de arquivos.





Para fazer diferenças nos arquivos tex não padrão, você precisa garantir que o SVN considere esses arquivos não binários, mas texto. Assim:

 svn propset svn:mime-type text/plain current_backup/*.bak 

Execute este comando, por exemplo, no linux e faça commit.

Bem, aqui estão as mudanças, olhe através dos olhos. Vemos que as regras do firewall foram alteradas:





É mais conveniente assistir em um navegador.



Se algo aconteceu, o administrador pode baixar o backup desejado sem gestos desnecessários na data desejada.



Embora, geralmente, o mais recente seja suficiente.

De certa forma, a invenção da bicicleta surgiu. Mas ele trabalha no DFL da D-link há quase um ano, exatamente como eu preciso, e às vezes isso ajuda muito.

Espero que alguém venha a calhar.

Referências:

Sobre ranço
Manual da WatchGuard Firebox CLI
Pro oxidado

Source: https://habr.com/ru/post/pt480386/


All Articles