Por causa disso, resolvi fazer um post totalmente off topic sobre o horário de verão no Brasil.
Afinal, tem como saber previamente se o meu CUCM vai mudar de horário na data certa ou não?
Sim! E é muito fácil!
Dê um SSH no seu CUCM e rode o comando:
run sql select * from typetimezone
Esse comando vai listar todos os time zones do CUCM, incluindo as informações do summer time, direto da base de dados. Para buscarmos apenas o de São Paulo, podemos filtrar pelo campo enum:
run sql select * from typetimezone where enum=17
Esse será o output (cole num notepad, e desabilite o Word Wrap):
enum name description moniker bias stddate stdbias dstdate dstbias abbreviation legacyname
==== ================= ==================== ========================== ==== =================== ======= ==================== ======= ============ =======================================
17 America/Sao_Paulo (GMT-03:00) Brasilia TIMEZONE_AMERICA_SAO_PAULO 180 0/2/0/3,00:00:00:00 0 0/10/0/3,00:00:00:00 -60 BST E. South America Standard/Daylight Time
O importante aqui é vermos os campos stddate e dstdate, que informam, respectivamente, o dia/hora que acaba o horário de verão, e o dia/hora que inicia.
No caso acima, temos:
stddate = 0/2/0/3,00:00:00:00
dstdate = 0/10/0/3,00:00:00:00
Não tenho certeza sobre os dois primeiros 0s. Talvez indique o dia da semana, sendo 0 = domingo. Not sure... se alguém souber, comenta aí. Mas o importante (pelo menos no Brasil) são os valores em vermelho. O primeiro é o mês e o segundo é a semana. Ou seja, nesse caso acima, o horário de verão acabará no terceiro domingo de fevereiro e começará no terceiro domingo de outubro.
Assim você já pode de antemão saber se vai ter que alterar algo na mão ou não.
E para os voice gateways, eu sempre uso os seguintes comandos:
clock timezone BRST -3
clock summer-time BRDT recurring 3 Sun Oct 0:00 3 Sun Feb 0:00
Isso porque no Brasil o horário de verão sempre começa no terceiro domingo de Outubro e acaba no terceiro domingo de Fevereiro. Se não me engano, a fixação dessas datas é coisa recente, do governo Lula, acho. Enfim... mas o problema é que, pelo que eu li, se o terceiro domingo de Fevereiro cai no Carnaval, aí o horário de verão acaba no quarto domingo. Foda, né? Nesses casos você (ou o plantonista azarado) tem que ficar esperto, porque provavelmente vai ter que ajustar na mão.
Tá, mas e a prova?
Ok, mas isso não tem absolutamente NADA a ver com a prova, né? Não, não tem! hehehe...
Mas para a prova você precisa saber configurar o NTP nos gateways e servidores, e se preocupar com o horário de cada site. E aqui eu dou algumas dicas.
NTP todo mundo está careca de saber como se configura, né? Por exemplo, se o horário é PST -8, colocamos no roteador:
ntp server x.x.x.x
! NÃO coloque o NTP master, a não ser que o roteador tenha
! o clock local, sem puxar de uma fonte externa. Ao colocar
! o comando ntp server, o roteador já estará pronto para
! fornecer o horário para outro servidor. Não precisa do comando
! ntp master.
clock timezone PST -8
A dica que eu dou também é sempre configurar o summer-time. Eles descontam ponto se não configurar? Não sei... tem gente que especula que sim, e tem gente que diz que não. Mas é uma linha de comando, e não vale a pena corrermos o risco. Portanto:
clock summer-time PDT recurring
Se o horário do Site A é PST -8, quer dizer que o Date/Time Group desse site tem que estar certo (obvio), para os telefones aparecerem com o horário correto.
E o que mais? Isso, o horário dos usuários da Unity Connection, olha só! Muita gente esquece disso!!
E já que estamos considerando o horário dos subscribers na Unity, nada mais lógico do que configurar o NTP também nesse servidor, o que muita gente deixa de fazer (e não sei se perdem ponto ou não, mas é melhor pecar pelo excesso, né?)
Então é isso. Não me vá perder ponto de NTP por uma besteira, heim!
Além disso, lembre-se que a falta de sincronia de NTP do Publisher e Subscriber é a causa número 1 para problemas de replicação de base de dados.
Tá, mas e a prova?
Ok, mas isso não tem absolutamente NADA a ver com a prova, né? Não, não tem! hehehe...
Mas para a prova você precisa saber configurar o NTP nos gateways e servidores, e se preocupar com o horário de cada site. E aqui eu dou algumas dicas.
NTP todo mundo está careca de saber como se configura, né? Por exemplo, se o horário é PST -8, colocamos no roteador:
ntp server x.x.x.x
! NÃO coloque o NTP master, a não ser que o roteador tenha
! o clock local, sem puxar de uma fonte externa. Ao colocar
! o comando ntp server, o roteador já estará pronto para
! fornecer o horário para outro servidor. Não precisa do comando
! ntp master.
clock timezone PST -8
A dica que eu dou também é sempre configurar o summer-time. Eles descontam ponto se não configurar? Não sei... tem gente que especula que sim, e tem gente que diz que não. Mas é uma linha de comando, e não vale a pena corrermos o risco. Portanto:
clock summer-time PDT recurring
Se o horário do Site A é PST -8, quer dizer que o Date/Time Group desse site tem que estar certo (obvio), para os telefones aparecerem com o horário correto.
E o que mais? Isso, o horário dos usuários da Unity Connection, olha só! Muita gente esquece disso!!
E já que estamos considerando o horário dos subscribers na Unity, nada mais lógico do que configurar o NTP também nesse servidor, o que muita gente deixa de fazer (e não sei se perdem ponto ou não, mas é melhor pecar pelo excesso, né?)
Então é isso. Não me vá perder ponto de NTP por uma besteira, heim!
Além disso, lembre-se que a falta de sincronia de NTP do Publisher e Subscriber é a causa número 1 para problemas de replicação de base de dados.
Feliz início de horário de verão pra vocês!
Nenhum comentário:
Postar um comentário