Como gerar boas séries para zonas DNS com o Puppet?

7

Minha tradição é definir todos os seriais de zona para o registro de data e hora na modificação. Agora que Puppet é minha nova religião, desejo definir registros de data e hora em série ao criar arquivos de zona a partir de recursos exportados. Um exemplo um pouco banalizado pode ser assim:

file { "/tmp/dafile": content = inline_template("<%= Time.now.to_i %>"), }

O problema com essa abordagem é que o conteúdo será diferente o tempo todo, o que (em última análise) provocará a reconstrução de arquivos de zona em cada pesquisa de configuração de fantoches.

Existe alguma maneira de inserir um timestamp sem que ele seja incluído nos dados comparados com o estado anterior?

    
por Bittrance 29.11.2011 / 05:03

6 respostas

3

Não use um modelo, se você tentar usar um número de série, o problema é continuar fazendo alterações a cada vez.

Eu tenho duas ideias:

  1. Crie um tipo adequado que possa gerenciar o DNS usando atualizações de DNS por meio da API padrão. Então deixe o BIND fazer o número de série incrementar a si mesmo.
  2. Use um padrão de fragmento de arquivo em cada elemento da zona DNS e use-o para que o arquivo da zona principal seja atualizado apenas quando elas forem alteradas. Você faz isso com um exec 'zone refresh' que concilia suas partes na zona final, incluindo o cabeçalho. A diferença entre a maioria das soluções de fragmentos de arquivos é que você gera sua zona serial a partir de um timestamp ou algo parecido, que só deve ser acionado quando as partes são alteradas, evitando as constantes alterações no número de série de um modelo. >

Alguns exemplos do padrão de fragmento de arquivo estão aqui:

link

link

    
por 29.11.2011 / 13:21
2

Que tal usar o registro de data e hora do arquivo:

file { "/tmp/dafile": content = inline_template("<%= File.mtime("/tmp/dafile").to_i %>"), }

A única coisa é que isso provavelmente será executado em cada cliente e poderá atualizar o registro de data e hora do arquivo para cada execução. Se isso não acontecer, deve atender às suas necessidades.

    
por 29.11.2011 / 08:58
1

Como sobre o seguinte,

$utime_serial = inline_template("<%= Time.now.to_i %>")

file { "/var/named/$domain.hosts":
          content => template("named/$domain.hosts.erb"),
          owner => root,
          group => named,
          mode => 0640,
}

onde o arquivo de modelo erb contém,

$TTL 1D
@             IN      SOA       galaxy.example.com.  sysadmin.example.com.  (
                               <%=utime_serial %>       ; Serial
                                8H             ; Refresh
                                2H             ; Retry
                                4W             ; Expire
                                1D )           ; Minimum
    
por 15.01.2013 / 08:35
0

você pode executar comandos externos a partir do fantoche (estou usando cfengine, não sei fantoche) O que é sobre este /bin/date '+%Y%m%d00'

    
por 29.11.2011 / 10:25
0

Eu usei o seguinte para fazer isso:

file {"${zone['zoneName']}.db":
        name            => "/var/lib/bind/.temp/${zone['zoneName']}.db",
        ensure          => file,
        content         => template('dns/bind/zone.db.erb'),
        owner           => 'root',
        group           => 'bind',
        mode            => 'ug=r,o=',
        require         => File['/var/lib/bind/.temp'],
        notify          => Exec["updateSerial-${zone['zoneName']}"]
}

exec {"updateSerial-${zone['zoneName']}":
        command         => "/bin/sed \"s/#SERIAL#/$(/bin/date '+%s')/\" '/var/lib/bind/.temp/${zone['zoneName']}.db' > '/var/lib/bind/${zone['zoneName']}.db'",
        refreshonly     => true,
        require         => File["${zone['zoneName']}.db"],
        notify          => Service['bind']
}

O modelo tem #SERIAL# como espaço reservado, depois que o arquivo temporário é criado, o Exec é notificado, que usa sed e date para substituir o espaço reservado pelo carimbo de data / hora unix atual. arquivar para o local correto.

    
por 03.02.2015 / 07:37
0

Eu tenho a tendência de usar o tempo de modificação do arquivo manifest ou hiera no qual você está declarando as entradas do host e convertê-lo em um timestamp adequado para o serial. (Você também pode usar o que for o mais novo de um conjunto de arquivos se estiver dividido em vários arquivos ou um registro de data e hora para a alteração mais recente se for por meio de outra rota, como um banco de dados)

Infelizmente, o número de série máximo é um inteiro não assinado de 32 bits, portanto, você só pode usar números até 2147483647. Isso não nos permite simplesmente usar segundos desde o unix epoch como o número de série, infelizmente . Em vez disso, o formato padrão é usar YYYYMMDDxx, mas isso exige que você tenha o número de série atual como estado, se você já o definiu na mesma data.

Como alternativa, e uma que não exige que você leia em um arquivo e incremente o número, eu uso o seguinte modelo in-line:

$serial_mtime_file = '/etc/puppetlabs/code/environments/production/site/profile/manifests/dns_dhcp_pxe.pp'
$serial_secs = inline_template("<%= File.mtime(@serial_mtime_file).strftime(\"%y%j\").to_s + (File.mtime(@serial_mtime_file).to_i % 86400).to_s %>")

notify { "Created magical serial number ${serial_secs}": }
validate_numeric($serial_secs)

Isso faz com que você tenha um formato YYDDDsssss (ano de 2 dígitos, dia de ano de 3 dígitos, segundo dígito de 5 dígitos), que funcionará até 2099 (se você iniciar em 2000 como eu fiz acima) e permite atualizar a cada segundo até então. Isso permite usar essa variável como um argumento para qualquer módulo existente que você deseja usar para criar as configurações de ligação, em vez de precisar de um modelo que possa ler de volta a serial existente (para incrementar).

Portanto, os modelos são aceitáveis se você for um pouco criativo sobre o local de onde obter o tempo para definir o número de série com:)

Eu usei o acima com o módulo camptocamp / bind puppetforge e isso funciona corretamente

    
por 18.03.2016 / 00:05