Linux和Windows下的NTP配置方法

原创 于 2021-04-21 18:05:56 发布 · 1.2k 阅读 · 3 ·
本内容遵循CC 4.0 BY-SA版权协议
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
标签
#时间同步 #Linux下的NTP配置 #Windows下的NTP配置 #NTP配置 #时间服务器
本文详细介绍了如何在Linux（Ubuntu和CentOS）及Windows系统中配置NTP服务，包括安装NTP软件、设置权限、指定上级服务器、调整配置文件以及重启和检查服务的状态。NTP的主要目标是实现不同计算机系统间的时间同步，确保精度在几毫秒内。对于Linux，重点讲解了`/etc/ntp.conf`的配置，而在Windows中，由于内置的Win32Time精度有限，建议使用第三方NTP软件以提高准确性。

文章目录


在这里插入图片描述

简介

网络时间协议（NTP）是一种网络协议，用于通过数据包交换的可变延迟数据网络在计算机系统之间进行时钟同步。NTP从1985年开始运行，是目前使用的最古老，最稳定的Internet协议之一。

NTP旨在将在公共Internet上运行的所有参与计算机同步到协调世界时（UTC）的几毫秒内。使用NTS-x000系列产品，可以在本地网络内部将精度提高到十几微秒。本文将详细介绍在linux和windows下如何配置NTP。

安装

ubuntu 安装：

sudo apt-get install ntp ntpstat ntpdate

CentOS 安装：

sudo apt-get install ntp ntpstat ntpdate

编写配置文件

配置文件:/etc/ntp.conf

restrict 管理权限：

在 ntp.conf 内可以利用『 restrict 』来控管权限，这个参数的设定方式为：

restrict [你的 IP] mask [netmask_IP] [parameter]

例如：

restrict 192.168.0.0 mask 255.255.255.0 nomodify

其中 parameter 的参数主要有底下这些：

  • ignore：拒绝所有类型的 NTP 连接；

  • nomodify：客户端不能使用 ntpc 与 ntpq 来修改服务器的时间参数，但客户端仍可通过过这部主机来进行网络校时的；

  • noquery：客户端不能够使用 ntpq, ntpc 等指令来查询时间服务器，等于不提供 NTP 的网路校时啰；

  • notrap：不提供 trap 这个远端事件登录(remote event logging)的功能；

  • notrust：拒绝没有认证的客户端。 那如果你没有在 parameter 的地方加上任何参数的话，这表示『该 IP
    或网段不受任何限制』的意思喔！一般来说，我们可以先关闭 NTP 的使用权限，然后再一个一个的启用允许登入的网段。

设定上级服务器：

利用 server 设定上层 NTP 服务器

上层 NTP 服务器的设定方式为：server [IP or hostname] [prefer] 。例如：

server ntp.ntsc.ac.cn prefer

在 server 后端可以接 IP 或主机名称，prefer 表示优先使用。

driftfile用来记录时间差异

driftfile配置：

设定的方式如下：

driftfile /var/lib/ntp/ntp.drift

因为预设的NTP Server 本身的时间计算是依据BIOS 的晶片震荡周期频率来计算的，但是这个数值与上层 Time Server 不一定一致。所以NTP 这个daemon (ntpd) 会自动的去计算我们自己主机的频率与上层 Time server 的频率，并且将两个频率的误差记录下来，记录下来的档案就是在driftfile 后面接的完整档名当中了！关于档名你必须要知道：driftfile 后面接的文件路径需要使用完整路径档名。

完整示例：

# /etc/ntp.conf, configuration for ntpd;
#driftfile 文件
driftfile /var/lib/ntp/ntp.drift
# 日志文件
statsdir /var/log/ntpstats/
#默认配置
statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable
#配置上级服务器
server ntp.ntsc.ac.cn prefer
# 下面两行默认是拒绝所有来源的任何访问
restrict -4 default kod notrap nomodify nopeer noquery limited
restrict -6 default kod notrap nomodify nopeer noquery limited
#允许192.168.0.0/24网段主机进行同步
restrict 192.168.0.0 mask 255.255.255.0 nomodify
#开放本机的任何访问
restrict 127.0.0.1
restrict ::1
#外部时间服务器不可用时，以本地时间作为时间服务
server 127.127.1.0
fudge 127.127.1.0 stratum 5

重启ntp服务

首先手动同步时间。

ntpdate ntp.ntsc.ac.cn

重启ntp服务。

systemctl restart ntp

同步查询状态

ntpq -p

remote：即是NTP主机的IP或主机名称啰～注意最左边的符号

状态统计码：

" " – 无状态，表示:没有远程通信的主机

“LOCAL” 即本机

“x” – 已不再使用

“-” – 已不再使用

“#” – 良好的远程节点或服务器但是未被使用 （不在按同步距离排序的前六个节点中，作为备用节点使用）

“+” – 良好的且优先使用的远程节点或服务器（包含在组合算法中）

“*” – 当前作为优先主同步对象的远程节点或服务器

“o” – PPS 节点 (当优先节点是有效时)。实际的系统同步是源于秒脉冲信号（pulse-per-second，PPS），可能通过PPS 时钟驱动或者通过内核接口。

  • refid：参考的上一层NTP主机的位址
  • st：就是stratum阶层
  • when：几秒钟前曾经做过时间同步化更新的动作
  • poll：下一次更新在几秒钟之后
  • reach：已经向上层NTP伺服器要求更新的次数
  • delay：网路传输过程当中延迟的时间，单位为10^(-3)秒
  • offset：时间补偿的结果，单位为10^(-3)秒
  • jitter：Linux系统时间与BIOS硬体时间的差异时间，单位为10^(-3)秒。

同步服务器查询

   ntpstat

图片

windows NTP 配置

Win32Time

W32Time是内置的微软SNTP(不是NTP)，因此它和完全的NTP相比是有限制rfc5905-09。所以相对于完全NTP。SNTP同步的准确性和多源性受到限制。所以为了达到更高精度需要使用完全的NTP软件。

NTP软件下载地址：https://elpromatime.com/downloads/

安装NTP软件

下载NTP软件包后安装后自动启动NTP服务，同时自动关闭W32Time。客户可以自行修改C:\WINDOWS\system32\drivers\etc\ntp.conf配置文件，后重新启动服务即可。

在这里插入图片描述

更改配置文件

ntp.conf的编写方法参考前文。在此处通常只需要更改本地NTP服务器地址即可。

查看同步状态

在命令行窗口使用ntpq命令查询，查询方式如下：

在这里插入图片描述

联系我们

我们是广州虹科，我们提供世界领先的时间同步解决方案。

官网：https://hongwangle.com/elproma/
在这里插入图片描述

博客
艾体宝洞察 | 推理模型很强，但依然需要好的上下文 / #1
06-18 209
推理模型改变了什么，又没有改变什么？以及为何上下文质量才是决定 Agent 可靠性的真正变量。
博客
艾体宝洞察 | Semantic Layer vs. Context Layer / #0
06-18 219
以上五个缺口共同指向一个结论：AI Agent 需要一层专属的运行时基础设施。Context Layer（上下文层）的核心职责是：​在 Agent 的每一个推理步骤中，管理它能看到什么信息​。用更工程化的语言描述，就是在运行时动态填充并管理 LLM 的 Context Window。这是一个近年来被称为。
博客
艾体宝洞察 | 什么才是真正的上下文？为什么我们需要它
06-18 222
很多人会问：用关系数据库、宽表或者更强大的向量库，能不能完成这个任务？局部可以，整体不能。因为上下文的本质，不是一张二维表上的属性字段，而是​高度互联的关系网络​。支付服务├─ 依赖 → Redis 集群│ ├─ 部署于 → 服务器 Node-42│ └─ 关联 → 最近变更记录 #12901├─ 触发 → 告警事件 Alert-3344└─ 负责 → 运维团队 SRE-Payments└─ 成员 → 张×、李×这个结构天然就是​**图（Graph）**​。
博客
艾体宝产品|Arango AutoGraph 如何重构企业的知识图谱
06-09 325
Arango AutoGraph：企业知识图谱的自动构建与智能应用 Arango AutoGraph 是一款面向企业级 AI 应用的知识图谱自动构建工具，旨在解决多源数据分散、知识管理低效和 AI 应用上下文割裂的问题。通过统一图、向量和文档能力，它实现了以下突破： 知识域自动识别 自动聚类文档，划分知识域（如产品研发、客服支持），构建语料图谱，优化检索策略（GraphRAG/VectorRAG），提升准确率至85%以上，减少提示词冗余和Token消耗。
博客
艾体宝洞察|从“图优先”到“上下文优先”：企业AI架构正在变化
06-09 163
摘要： 企业AI系统从概念验证迈向生产环境时，传统以图数据库为中心的架构面临根本性挑战——业务上下文被分散在图数据库、向量数据库等多个系统中，导致高延迟、语义漂移和决策不一致等问题。图数据库虽能建模关系，但无法统一管理业务上下文的关键维度（语义、时间、信任等）。纯图架构或拼凑式技术栈难以支撑智能体（Agent）所需的实时推理与行动，而编排层仅能缓解问题。解决方案是构建上下文优先的数据层，统一结构化与非结构化数据、关系与语义，避免运行时重建上下文。领先企业正转向集成化的上下文数据平台（如Arango），简化架
博客
艾体宝洞察|从 ERP 到知识图谱：供应链数据架构的下一次升级
06-09 348
现代供应链的本质是一个复杂的、多层嵌套的网络系统。传统关系型数据库和 Excel 分析工具在处理扁平数据时效率尚可，但在面对网络拓扑分析、多层关系遍历、动态风险传导等核心供应链挑战时力不从心。Arango 上下文数据平台凭借其原生多模型图数据库能力和 AI 原生的上下文数据层设计，为供应链管理提供了一条从“数据可见”到“风险可预测”、再到“决策可追溯”的技术演进路径，帮助企业在不确定的全球供应环境中建立起数据驱动的韧性。
博客
艾体宝洞察|看见供应链盲区：Arango如何让供应链网络变得透明
06-04 196
在这个充满不确定性的时代，供应链的透明度不再是加分项，而是生存的必需品。Arango 上下文数据平台提供的，正是一盏穿透“供应链盲区”的灯——让企业看见风险，预见变化，在动荡中保持韧性。因为真正危险的，从来不是已经发生的风险，而是那些你尚未看见的风险。
博客
艾体宝产品|从知识孤岛到智能知识中心：Arango 如何重塑企业知识图谱
06-04 255
摘要： 企业知识资产分散形成"知识孤岛"，传统解决方案难以满足关联查询需求。ArangoDB通过原生多模型架构统一文档存储、图结构和向量索引，构建三维知识空间。其AutoGraph功能自动化知识图谱构建，降低技术门槛；GraphRAG将知识图谱与大模型结合，提升检索精度。该方案实现内容-语义-关系的统一建模，支持高效决策和知识传承，验证显示可提升信息检索效率50%以上，缩短决策时间30-50%，有效解决企业知识管理痛点。
博客
艾体宝洞察|当大模型学会“理解关系”：知识图谱如何让企业AI不再只会关键词匹配
06-04 170
摘要： 企业搜索长期受限于文档数据的孤立性，难以回答跨实体、跨文档的关联性问题。知识图谱通过图结构（节点为实体，边为关系）显式存储数据关联，支持高效遍历查询，解决传统检索的“失语”问题。理想的架构需原生融合文档、图和向量能力，避免多系统拼接导致的上下文丢失。自动化工具（如LLM辅助的实体提取）可加速图谱构建，结合人机协同确保准确性。GraphRAG进一步将检索结果从文本片段升级为关联子图，大幅提升大模型推理的可靠性。知识图谱需持续运营，通过可视化、增量更新和规模化部署，成为企业AI的核心数据骨架。Arang
博客
艾体宝方案|“110天“倒计时：CRA合规之路（四）
05-27 475
根据欧盟委员会公开说明，CRA 已于 2024 年 12 月 10 日生效，主要义务将自 2027 年 12 月 11 日起适用，其中报告义务自 2026 年 9 月 11 日提前适用。CRA 对制造商的要求覆盖产品的规划、设计、开发、生产、交付和维护阶段，并要求相关义务贯穿价值链。这意味着，CRA 合规并不是一次性安全整改，也不是单独建立一个漏洞报告流程，而是要求企业建立能够支撑产品全生命周期的合规证明体系。
博客
艾体宝洞察|“顶会”看安全（八）：针对预训练大语言模型的仅标签成员推断攻击
05-27 419
本文发现基于鲁棒性差距的仅标签 MIA 在 LLM 的预训练阶段大多无效，可能原因包括更好的泛化能力和扰动过于粗糙。本文提出了 PETAL，一种针对 LLM 预训练阶段的简单而有效的仅标签 MIA 方法，利用词元级语义相似度来近似成员推断的输出概率。
博客
一文读懂SBOM：欧盟CRA法案下的产品安全“身份证“
05-12 441
随着欧盟《网络弹性法案》（CRA）的正式生效，SBOM（软件物料清单） 已从一项“最佳实践”转变为 IoT 等数字产品进入欧洲市场的​强制性合规要求​。本文通过一个真实的漏洞事件，深入浅出地解释了 SBOM 作为软件“成分说明书”的核心价值，系统梳理了 CRA 法案的时间表与关键条款，并为企业提供了从认知到落地的​五步行动指南​。
博客
固件安全事故平均损失37万：Swisscom案例揭示IoT合规紧迫性
05-12 408
根据瑞士电信（Swisscom）的实测数据，一次典型的固件安全事故为企业带来的平均直接经济损失高达​37.4 万瑞士法郎​（约合人民币 280 万元）。这不仅是应急响应的开销，更是对品牌声誉与市场信任的长期透支。随着欧盟《网络弹性法案》（CRA）合规大限逼近，固件安全已从技术问题演变为决定企业能否留在欧洲市场的​生存问题​。
博客
CRA是什么？一篇文章讲清楚
05-12 398
欧盟《网络弹性法案》（CRA）已于 2024 年 12 月 10 日正式生效，是首个对硬件和软件产品提出全生命周期网络安全要求的法规。其核心原则是“​默认安全​”——任何“带数字元素的产品”在进入欧盟市场前，必须被证明是安全的。不合规的后果极其严重，最高面临 1500 万欧元或全球年营业额 2.5% 的罚款，产品将被强制退出市场。本文将用最通俗的语言，为您解读 CRA 究竟是什么，并明确告诉您，它究竟对哪些产品和哪些企业产生直接影响。
博客
艾体宝干货|Active-Active/Active-Passive 数据库架构解析：高可用设计中的权衡与选型
05-09 435
Active-Active 与 Active-Passive 是应对数据库高可用需求的两种根本不同的技术路线。本文将系统梳理两种架构的工作机制、核心取舍，并重点解析 Redis 在 Active-Active 场景下的工程实现。
博客
艾体宝干货|【Redis实用技巧#21】让 Redis 支持 SQL 查询？标准 SQL 的技术实现与场景分析
05-09 317
在数据工程领域，SQL 至今仍是表达查询意图最为通用且精确的领域语言。无论是数据分析师、后端工程师，还是当下各类 LLM Agent，SQL 都是与数据存储系统交互的首选接口。与此同时，Redis 作为高性能内存数据库，在缓存、实时计算、向量检索等场景中已经确立了不可替代的地位。长期以来，这两个技术栈之间存在一道语义鸿沟：团队熟悉 SQL，但 Redis 的原生查询语法（FT.SEARCH / FT.AGGREGATE）对于复杂条件组合、聚合统计、向量相似度检索等场景，学习成本与翻译成本均不低。
博客
艾体宝洞察|Log4j漏洞席卷全球超40%企业：软件供应链中隐藏着多少风险？
05-07 295
Log4j 危機並非異常事件，而是一項嚴峻的警示。它揭示了軟體供應鏈已成為現代企業最為薄弱的環節之一，而基於傳統邊界防禦的理論已然失效。下一次大規模供應鏈漏洞事件的發生，並非是否可能的問題，而是時間問題。當下一次廣泛傳播的零日漏洞被披露時，組織是選擇執行一套精準、自動化的修復預案，還是陷入被動的應急狀態，手動搜尋一個位置不明的威脅？此一抉擇，將直接決定企業在未來安全挑戰中的命運。那麼，應對這一新常態的戰略性解決方案是什麼？
博客
艾体宝干货|提示注入攻击：4种类型及如何防御
05-07 395
随着生成式 AI 系统越来越多地集成到企业应用中，它们也带来了一种新型的安全威胁，即提示注入攻击。这些攻击通过将恶意或不受信任的输入注入到提示流中，操纵大型语言模型（LLM）对指令的解释方式，从而覆盖开发者最初定义的行为。这可能导致绕过控制、泄露数据或触发未经授权的操作。尽管 AI 带来了惊人的生产力提升，但使用时也需谨慎。当企业竞相率先将新的 AI 用例推向市场时，各种提示注入案例对开发者、安全团队以及将 LLM 应用于现实工作流程的组织来说，正成为一个日益增长的担忧。
博客
艾体宝洞察|面向 Agentic AI 场景：基于原生多模型架构构建“统一上下文层”
05-06 442
随着大语言模型（LLM）能力的演进，AI 应用的开发正在从单轮问答式的 RAG（检索增强生成），向具备长程规划与工具调用能力的智能体（AI Agent）架构迁移。然而，从工程实践的角度来看，大模型本身只是“计算引擎”，它缺乏对企业特定业务逻辑的理解。为了让 Agent 在执行复杂任务时（如跨表单信息核对、基础设施故障排查、个性化投顾）不产生幻觉，我们需要在模型和企业数据之间，构建一个高吞吐、低延迟的​上下文数据层。
博客
艾体宝方案|告别运维数据孤岛：如何为 AIOps 构建统一的上下文 AI 数据底座？
05-06 432
现代 IT 运维团队正面临一个典型的尴尬处境。一方面，我们坐拥海量的运维数据：日志系统里躺着的非结构化文本、APM 工具产生的海量指标和链路追踪数据、CMDB 里存储的资产配置、事件管理系统中不断滚动的事故单。但另一方面，这些数据散落在不同的孤岛中，格式各异，彼此割裂。当系统真正出问题时，On-call 工程师往往需要手动在十多个工具间来回切换，试图在脑海中拼凑出故障的全貌。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值