Você pode ser mais bem servido com um modelo nesse caso. Algo como ...
# This is done to bring the variable into scope.
$search_dom = $::dns_new::params::searchdomny4
if $::oddip == 'true' {
$dns_order = [ '1.1.1.1', '2.2.2.2' ]
} elsif $::oddip == 'false' {
$dns_order = [ '2.2.2.2', '1.1.1.1' ]
}
file { '/etc/resolv.conf':
[usual stuff]
content => template('dns_new/resolv.conf.erb'),
}
Com um modelo ERB semelhante a este:
new_dns/templates/resolv.conf.erb :
search <%= @search_dom %>
<% @dns_order.each do |serv| %>
nameserver <%= serv %>
<% end -%>
Qual deve emitir um arquivo resolv.conf na ordem que você deseja.
Outra opção é simplesmente codificar a lista de servidores DNS no módulo e usar o código ruby no modelo ERB para determinar se você percorre o array (cada) ou o percorre (reverse.each). Isso seria parecido com:
$search_dom = $::dns_new::params::searchdomny4
$dns_list = $::dns_new::params::dnslist
$oddip = $::oddip
file { '/etc/resolv.conf':
[usual stuff]
content => template('dns_new/resolv.conf.erb')
}
Com o ERB mais complexo formatado como:
search <%= @search_dom %>
<% if @odd_ip == 'true' %>
<% @dns_list.each do |srv| -%>
nameserver <%= srv %>
<% end -%>
<% elsif @odd_ip == 'false' -%>
<% @dns_list.reverse.each do |srv| -%>
nameserver <%= srv %>
<% end -%>
<% end -%>
Caso você não tenha feito modelos antes, a chave da marcação é aproximadamente:
<% : Here is ruby code.
<%= : Here is an evaluated value. Replace this block with the
result, or enter a blank line.
-%> : End a block. Don't render a blank line if it doesn't evaluate to anything.
O modelo será avaliado linha por linha. A primeira linha é uma coisa simples que elimina a parte 'servidor' do comando conf. A segunda linha é onde as coisas ficam mais complexas: estamos chamando funções de ruby. Isso é o que nos permite descartar o máximo de nameserver linhas que existem no array.
Eu vejo o que você está tentando fazer no ERB, mas acho que você está complicando demais. Você está codificando a lógica de localização (nj vs ams vs lax) no próprio ERB. Isso pode ser feito, mas você pode ter mais sorte fazendo essa parte no código dos fantoches. É mais provável que seja legível para outra pessoa se essa parte da lógica estiver dentro do código do fantoche.
dns_new/manifests/config.pp :
case $::dcd {
'ny4': {
$search_domain = $::dns_new::params::searchdomny4
$dns_list = [ "${::dns_new::params::ny4dns1}", "${::dns_new::params::ny4dns2}" ]
}
'nj': {
$search_domain = $::dns_new::params::searchdomnj
$dns_list = [ "${::dns_new::params::njdns1}", "${::dns_new::params::njdns2}" ]
}
'ams2': {
$search_domain = $::dns_new::params::searchdomams2
$dns_list = [ "${::dns_new::params::ams2dns1}", "${::dns_new::params::ams2dns2}" ]
}
}
file { '/etc/resolv.conf':
[the usual stuff]
content = template('dns_new/resolv.conf.erb')
}
Agora você tem duas variáveis para lidar no ERB. search_domain e dns_list . Isso encurta bastante o ERB:
dns_new/templates/resolv.conf.erb :
search <%= @search_domain %>
<% dns_list.each do |serv| -%>
nameserver <%= serv %>
<% end -%>
Se você está se perguntando por que eu estou atribuindo variáveis na classe e usando aquelas no ERB ao invés de usar as variáveis na classe params, é por causa da maneira não-intuitiva que as variáveis fora do escopo trabalham Arquivos ERB. É muito mais fácil e bom estilo atribuir variáveis que serão usadas em um arquivo ERB na mesma classe que chama o modelo.