우리는 때때로 새로운 서버가 BIOS에서 잘못된 시간을 가지고 있다는 문제를 겪고 있기 때문에 한 달이 지나면 시간이 걸릴 수 있습니다.
VMware에서 VM을 일시 중단했다가 일시 중단하지 않으면 시간도 줄어 듭니다. NTP는 최대 오프셋 후에 동기화되지 않기 때문에 /etc/ntp.conf에서 tinker panic 0을 사용하는 것을 고려하고 있습니다.
NTP가 동기화 시간을 멈추게하는 기본 최대 오프셋이 1000 초인 이유는 무엇입니까? 우리는 Puppet을 사용하여 NTP를 설정하고 있습니다. ntp.conf에서 tinker panic 0을 설정하는 것을 고려하고 있으므로 NTP는 동기화됩니다. 이 작업의 단점은 무엇입니까?
답변:
시간이 다른 서버와 동기화되지 않는 원인은 다음과 같습니다.
5.1.1.4. 기준 시간이 변경되면 어떻게됩니까?
이상적으로 참조 시간은 전 세계 어디에서나 동일합니다. 일단 동기화되면 운영 체제의 클럭과 기준 클럭간에 예기치 않은 변경이 없어야합니다. 따라서 NTP에는 상황을 처리하는 특별한 방법이 없습니다.
대신, ntpd의 반응은 로컬 클럭과 기준 시간 간의 오프셋에 따라 달라집니다. 작은 오프셋의 경우 ntpd는 평소와 같이 로컬 클럭을 조정합니다. 작고 큰 오프셋의 경우 ntpd는 잠시 동안 참조 시간을 거부합니다. 후자의 경우 운영 체제의 시계는 새로운 기준 시간이 거부되는 동안 마지막 수정 사항을 계속 적용합니다. 일정 시간이 지나면 작은 오프셋 (상당히 1 초 미만)이 회전하고 (느리게 조정 됨) 오프셋이 클수록 클럭이 단계적으로 변경됩니다 (새로 설정). 거대한 오프셋이 거부되고 ntpd가 종료되어 매우 이상한 일이 발생했다고 생각합니다.
에 의해 제어되는 현재 NTP 구성에서는 맨 페이지에 설명 된대로 파일을 사용 하고 데몬 설정 ( ) puppet에서 서버와의 동기화를 강제합니다 .ntp.conftinker panic/etc/sysconfig/ntpdntpd(8)
-g 오프셋이 공황 임계 값 (기본적으로 1000 초)을 초과하면 일반적으로 ntpd는 시스템 로그에 메시지와 함께 종료됩니다. 이 옵션을 사용하면 시간을 제한없이 임의의 값으로 설정할 수 있습니다. 그러나 이것은 한 번만 발생할 수 있습니다. 그 후 임계 값이 초과되면 ntpd는 시스템 로그에 대한 메시지와 함께 종료됩니다. 이 옵션은 -q 및 -x 옵션과 함께 사용할 수 있습니다.
연결중인 NTP 서버를 신뢰할 수 있기 때문에이 작업을 수행합니다.
클라이언트에 적용되는 모듈의 관련 부분은 다음과 같습니다.
class ntp (
$foo
$bar
...
){
$my_files = {
'ntp.conf' => {
path => '/etc/ntp.conf',
content => template("ntp/ntp.conf.$template.erb"),
selrole => 'object_r',
seltype => 'net_conf_t',
require => Package['ntp'], },
'ntp-sysconfig' => {
path => '/etc/sysconfig/ntpd',
source => 'puppet:///modules/ntp/ntp-sysconfig',
require => Package['ntp'], },
...
}
$my_files_defaults = {
ensure => file,
owner => 'root',
group => 'root',
mode => '0644',
selrange => 's0',
selrole => 'object_r',
seltype => 'etc_t',
seluser => 'system_u',
}
create_resources(file, $my_files, $my_files_defaults)
exec { 'ntp initial clock set':
command => '/usr/sbin/ntpd -g -q -u ntp:ntp',
refreshonly => true,
timeout => '-1',
subscribe => File['/etc/ntp.conf'],
}
}
그리고 참조 된 파일의 내용은 다음과 같습니다.
$ cat devops/puppet/modules/ntp/files/ntp-sysconfig
# Drop root to id 'ntp:ntp' by default.
OPTIONS="-u ntp:ntp -p /var/run/ntpd.pid -g -a"
과:
$ cat devops/puppet/modules/ntp/templates/ntp.conf.RedHat.erb
# HEADER: This file was autogenerated by puppet.
# HEADER: While it can still be managed manually, it
# HEADER: is definitely not recommended.
tinker panic 0
<% server.each do |ntpserver| -%>
server <%= ntpserver %> autokey
<% end -%>
server 127.127.1.0 # local clock
fudge 127.127.1.0 stratum 10
driftfile /var/lib/ntp/drift
crypto pw hunter2
crypto randfile /dev/urandom
keysdir /etc/ntp
여기에 hiera부분이 없지만 아이디어를 얻습니다.
최악의 경우는 LAN 연결 GPS 수신기에 대한 공격 일 수 있습니다. 이는 가능한 것으로 입증되었으며 NTP가 그러한 경우에 즉시 "누가"남는 것보다 더 나은 이유입니다. 이러한 종류의 문제 또는 갑작스런 소프트웨어 버그는 NTP의 디자인 타임에 예상되었으며 두 가지 모두 발생할 수 있습니다.
알고리즘의 하나의 보호 메커니즘은 그들이 falseticker 라고 부르는 것을 탐지하는 것이지만, 대부분 업스트림 클럭이 갑자기 뒤로 시간을 보내는 경우 일부 문제 만 탐지 할 수 있습니다.
"시작 시간에 시계가 잘못되었습니다"인 경우 :
tinker panic 0