ARTICLE DETAIL

资讯详情

深耕郑州网站建设与运营推广的一线实战洞察。

Salt 的 system 执行模块:POSIX 系统的关机、重启、时钟与主机名管理全指南

Salt 的 system 执行模块:POSIX 系统的关机、重启、时钟与主机名管理全指南 运维配置管理后端【免费下载链接】saltSoftware to automate the management and configuration of infrastructure and applications at scale.项目地址https://gitcode.com/gh_mirrors/sa/salt点击查看免费下载导读system是 Salt 内置的执行模块Execution Module为 POSIX 类系统提供关机shutdown、重启reboot、停机halt、断电poweroff、运行级别切换init、系统日期/时间设置与读取、以及主机描述与主机名的管理能力。本文以 salt/modules/system.py 的实现为主线结合 官方模块文档 与 单元测试、功能测试 中的验证逻辑完整讲解每个函数的参数、返回值和 CLI 用法并深入剖析其底层命令调用、平台差异处理与硬件时钟同步原理帮助你安全、精准地在生产集群上批量执行电源管理与时间同步操作。模块概览定位、平台限制与加载机制模块定位salt.modules.system是 Salt 的“电源与系统时间控制”入口直接对应salt * system.function形式的远程命令。它把 POSIX 系统的常用管理动作halt、reboot、shutdown、poweroff、init、时间日期设置、主机名设置等封装成统一的 Salt 接口避免在各台机器上手工敲击底层命令。模块源码开头的模块说明明确指出salt/modules/system.py该模块提供对 POSIX 类系统上 reboot、shutdown 等操作的支持。平台可用性virtualsystem模块并不是在所有平台上都可用。__virtual__()函数salt/modules/system.py在加载阶段即做平台判定Windows不可用返回(False, This module is not available on Windows)macOSDarwin不可用返回(False, This module is not available on Mac OS)SunOS/Solaris不可用返回(False, This module is not available on SunOS)其他 POSIX 平台Linux、FreeBSD、NetBSD、OpenBSD 等返回虚拟名system正常加载。也就是说system只服务于 POSIX 类系统。Windows、macOS 与 Solaris 各有自己的专用模块Windows 使用 salt/modules/win_system.py其文档入口为 salt.modules.win_systemmacOS 使用 salt/modules/mac_system.py文档入口 salt.modules.mac_systemSolaris 使用salt/modules/solaris_system.py。这与官方模块索引 doc/ref/modules/all/index.rst 中列出的多平台 system 模块体系一致。一个重要的使用提醒molly-guard 等交互包装器模块文档开头特别提醒salt/modules/system.py如果系统配置了诸如molly-guard这类用于拦截交互式关机命令的包装脚本那么通过salt-call调用system.halt、system.poweroff、system.reboot、system.shutdown时会因为包装脚本在等待用户输入而无限期挂起而通过saltmaster 下发调用则行为正常。这在批量管理带有交互防护的生产机时是需要警惕的坑。电源管理四件套halt、poweroff、reboot、shutdown这四个函数是本模块最常用的能力全部基于__salt__[cmd.run]调用底层系统命令并且统一使用python_shellFalse以避免 shell 注入风险salt/modules/system.py。halt停机但不一定断电def halt(): cmd [halt] ret __salt__cmd.run return retCLIsalt * system.halt底层命令直接执行halt。注意halt在多数现代 Linux 上只是停机关机流程的一环具体是否断电取决于发行版与配置。poweroff直接断电def poweroff(): cmd [poweroff] ...CLIsalt * system.poweroff底层命令直接执行poweroff。reboot重启支持延迟时间def reboot(at_timeNone): cmd [shutdown, -r, (f{at_time} if at_time else now)] ...CLIsalt * system.reboot或salt * system.reboot 55 分钟后重启。参数at_time以分钟为单位的延迟时间不传则立即重启底层命令为shutdown -r now。底层命令shutdown -r [minutes|now]。这里的语义是传数字表示延迟 N 分钟传字符串now表示立即。单元测试对这两条命令路径做了精确断言tests/pytests/unit/modules/test_system.pycmd_mock.assert_called_with([shutdown, -r, now], python_shellFalse) cmd_mock.assert_called_with([shutdown, -r, 5], python_shellFalse)shutdown关机BSD 系自动断电def shutdown(at_timeNone): if (salt.utils.platform.is_freebsd() or salt.utils.platform.is_netbsd() or salt.utils.platform.is_openbsd()): # these platforms dont power off by default when halted flag -p else: flag -h cmd [shutdown, flag, (f{at_time} if at_time else now)] ...CLIsalt * system.shutdown或salt * system.shutdown 55 分钟后关机。参数at_time延迟分钟数不传则立即关机。平台差异关键点在 FreeBSD / NetBSD / OpenBSD 上halt 默认不会断电所以底层使用shutdown -ppower off其他平台使用shutdown -hhalt。单元测试覆盖了这四种平台分支tests/pytests/unit/modules/test_system.pyLinux/通用平台断言[shutdown, -h, now]FreeBSD、NetBSD、OpenBSD 分别断言[shutdown, -p, now]。initsysV 运行级别切换def init(runlevel): cmd [init, f{runlevel}] ...CLIsalt * system.init 3底层命令init runlevel仅适用于 sysV 兼容系统。注意参数是按字符串拼接的init 3传入的 runlevel 会原样传给init命令。时间管理读取系统时间与日期时间管理函数围绕_get_offset_time与_FixedOffset构建支持通过utc_offset参数在任意时区视角下读取时间salt/modules/system.py。时间偏移解析机制_offset_to_min(utc_offset)salt/modules/system.py用正则^([-])?(\d\d)(\d\d)$把0600、-0300、0800之类的偏移字符串解析为分钟数如0500→-300、-0300→180、0800→480。注意其返回值符号与直觉相反东八区0800返回-480因为该函数计算的是“从 UTC 到该时区的修正量”。_get_offset_time(utc_offset)以salt.utils.timeutil.utcnow()为基准加上偏移分钟数构造带_FixedOffset时区信息的 datetime未传偏移时使用datetime.now()本地时区。_FixedOffset类salt/modules/system.py是固定偏移 tzinfo 的轻量实现源自 Python 官方 datetime 文档的经典模式。读取函数族函数CLI 示例输出格式get_system_timesalt * system.get_system_timeHH:MM:SS AM/PM如02:37:54 PMget_system_date_timesalt * system.get_system_date_time -0500YYYY-MM-DD hh:mm:ssget_system_datesalt * system.get_system_date%a %m/%d/%Y如Tue 05/12/2015utc_offset参数为四位数偏移格式如0600带可选/-符号不传则使用本地时区。功能测试验证了本地时间与 UTC0000两种读取路径误差要求 3 秒以内tests/pytests/functional/modules/test_system.py。命令行引号提示在 salt 命令行上传递负偏移时由于 Salt 参数解析器会先处理参数需要使用双重引号例如−0000文档原文为0000示例负偏移同理如-0500。时间管理设置系统时间与日期set_system_time只改时分秒CLIsalt * system.set_system_time 11:20支持的输入格式解析器_try_parse_datetime依次尝试salt/modules/system.pyHH:MM:SS AM/PMHH:MM AM/PMHH:MM:SS24 小时制HH:MM24 小时制解析失败返回False。成功后将时分秒委托给set_system_date_time日期保持不变。由于命令行的日期/时间参数在到达模块前可能已被 Salt 命令行解析器处理所以时间参数必须以字符串形式传递命令行上通常需要双重引号如示例中的11:20。set_system_date只改年月日CLIsalt * system.set_system_date 03-28-13支持的输入格式YYYY-MM-DDMM-DD-YYYYMM-DD-YYMM/DD/YYYYMM/DD/YYYYYY/MM/DD格式非法时抛出SaltInvocationError(Invalid date format)salt/modules/system.py合法则调用set_system_date_time只更新年/月/日时间保持不变。set_system_date_time核心设置函数这是时间设置的真正实现salt/modules/system.pyset_system_time与set_system_date最终都委托给它CLIsalt * system.set_system_date_time 2015 5 12 11 37 53 -0500参数years、months、days、hours、minutes、seconds、utc_offset。每个参数都可选未传的字段沿用当前系统值从而实现“只改年份”“只改时间”等局部修改。取值范围months1-12days1-31hours0-23minutes/seconds0-59非法组合会抛出SaltInvocationError如datetime构造ValueError被捕获后重新抛出salt/modules/system.py。底层实现流程以_get_offset_time(utc_offset)取得当前时间作为基准缺失字段用当前值填充构造新的datetime调用_date_bin_set_datetime通过date命令设置软件时钟内核时钟若系统存在可设置的硬件时钟has_settable_hwclock()为真再调用_swclock_to_hwclock()执行hwclock --systohc把软件时钟同步到硬件时钟保证重启后时间不丢salt/modules/system.py。_date_bin_set_datetimedate 命令的两级降级策略_date_bin_set_datetimesalt/modules/system.py体现了对 POSIX 兼容性的细致处理若 datetime 带时区信息utcoffset() is not None先换算为 UTC 等价时刻加-u参数以 UTC 设置第一优先级使用非 POSIX 扩展格式date MMDDhhmm[[CC]YY[.ss]]可精确到秒执行cmd.run_all并检查返回码若失败返回码非 0降级为纯 POSIX 格式date MMDDhhmm[[CC]YY]只能精确到分钟重试两次都失败则抛出CommandExecutionError并透出第一次尝试的stderr便于排障。也就是说严格 POSIX 的 date 只能把时间设置到分钟级秒级设置是尽力而为的扩展特性。功能测试对此有专门的描述“我们只能把时间设置到秒的精度所以测试可能看起来在负时间运行”tests/pytests/functional/modules/test_system.py。has_settable_hwclock / _swclock_to_hwclock硬件时钟探测与同步has_settable_hwclock()salt/modules/system.py先用salt.utils.path.which_bin([hwclock])探测hwclock是否存在存在则执行hwclock --test --systohc--test为演练模式不真正写入返回码为 0 即认为硬件时钟可被软件设置。_swclock_to_hwclock()salt/modules/system.py真正执行hwclock --systohc把软件时钟写入硬件时钟失败仅记录 warning不中断流程。功能测试_test_hwclock_sync通过hwclock --compare对比硬件/软件时钟要求差值 ≤ 2 秒tests/pytests/functional/modules/test_system.py从侧面印证了set_system_date_time同步硬件时钟的正确性。主机名与主机描述管理get_computer_desc / set_computer_descPRETTY_HOSTNAME这两个函数管理/etc/machine-info中的PRETTY_HOSTNAME变量人类可读的机器描述如“Michaels laptop”。get_computer_descsalt/modules/system.py优先使用hostnamectl status --prettysystemd 系统无hostnamectl时回退为解析/etc/machine-info中的PRETTY_HOSTNAME行自动剥离引号并反转义\\、\、\n、\t文件或变量不存在时返回False。set_computer_descsalt/modules/system.py入参先做转义→\、换行 →\n、制表符 →\t优先使用hostnamectl set-hostname --pretty descsystemd回退路径/etc/machine-info不存在则先创建然后用正则定位既有PRETTY_HOSTNAME行并替换找不到则追加到文件末尾文件操作失败返回False成功返回True。功能测试验证了普通描述、包含引号/制表符/Unicode 的多行描述都能正确往返tests/pytests/functional/modules/test_system.py并且当测试环境中的hostnamectl因缺少 system bus 而退化时会被自动跳过check_hostnamectl探测逻辑tests/pytests/functional/modules/test_system.py。get_computer_name / set_computer_name主机名def set_computer_name(hostname): return __salt__network.mod_hostname def get_computer_name(): return __salt__[network.get_hostname]()CLIsalt * system.set_computer_name master.saltstack.com、salt * system.get_computer_name这两个函数委托给 network 模块network.mod_hostname与network.get_hostname实现在salt/modules/network.py中。因此system模块并未直接操作/etc/hostname而是复用了 network 模块的跨平台主机名管理逻辑。特殊功能NI Linux RT 的重启见证标记模块还包含一对仅适用于NI Linux RTos_family NILinuxRT由_is_nilrt_family()判定的特殊函数通过depends(_is_nilrt_family)装饰器salt/utils/decorators.py仅在 NI Linux RT 上暴露set_reboot_required_witnessed()salt/modules/system.py在临时文件系统tmpfs路径/var/volatile/tmp/salt/reboot_witnessed写入见证文件用于记录“已观察到需要重启的事件”由于写在 tmpfs 上重启后自动消失。目录创建失败会抛出SaltInvocationError。get_reboot_required_witnessed()salt/modules/system.py返回该文件是否存在用于判断当前启动会话中是否见证过重启请求。这是为 NI 实时 Linux 的嵌入式/工控场景设计的机制普通 Linux 上不可用。实战场景如何组合使用场景一批量延迟重启并等待回归借助salt.function状态模块与salt.wait_for_event可以实现“全量重启、等待 minion 全部回归”的编排该示例来自 salt/states/saltmod.py 的文档reboot_all_minions: salt.function: - name: system.reboot - tgt: * wait_for_reboots: salt.wait_for_event: - name: salt/minion/*/start - id_list: - jerry - stuart - dave - phil - kevin - mike - require: - salt: reboot_all_minions这展示了system.reboot作为状态编排中的一环先用它重启目标再用事件监听保证所有 minion 重新上线后才继续后续操作。场景二集群时间校正对需要强时间一致性的集群如依赖时间戳的分布式服务可在窗口期统一校正salt web* system.set_system_date_time 2025 5 12 11 37 53 0800 salt web* system.get_system_date_time 0800第一行按东八区 2025-05-12 11:37:53 设置系统时间内部换算为 UTC 执行date -u随后同步硬件时钟第二行验证结果。注意修改系统时间属于高风险操作应先在小范围 minion 上验证且确认systemd-timesyncd等 NTP 服务不会立即回拨时钟功能测试的 setup/teardown 正是先停用再恢复systemd-timesyncdtests/pytests/functional/modules/test_system.py。场景三批量标注机器用途salt * system.set_computer_desc Web frontend - production salt * system.get_computer_desc借助get_computer_desc/set_computer_desc在/etc/machine-info中维护可读的主机描述便于审计与资产盘点。结论与扩展阅读salt.modules.system用极薄的封装把 POSIX 电源管理、运行级别、系统时间与主机标识统一到了 Salt 的远程执行框架中底层命令与平台差异被函数级隔离shutdown的 BSD 断电分支、date命令的 POSIX 降级、hostnamectl//etc/machine-info的双路径处处体现对多发行版兼容性的设计。进一步阅读模块完整源码salt/modules/system.py官方 API 文档入口doc/ref/modules/all/salt.modules.system.rst单元测试命令级断言tests/pytests/unit/modules/test_system.py功能测试真实时间设置与硬件时钟同步tests/pytests/functional/modules/test_system.py平台专属替代模块salt.modules.win_system、salt.modules.mac_system状态编排示例salt.wait_for_eventsalt/states/saltmod.py赞分享运维配置管理后端【免费下载链接】saltSoftware to automate the management and configuration of infrastructure and applications at scale.项目地址https://gitcode.com/gh_mirrors/sa/salt点击查看免费下载相关推荐Salt hosts 执行模块全指南用 salt * hosts.* 管理 hosts 文件中的 IP 与主机名映射Salt hosts 执行模块全指南用 salt hosts. 管理 hosts 文件中的 IP 与主机名映射 本篇技术指南围绕 Salt 内置的 h运维配置管理后端Salt 的 Windows 系统管理模块 win_system重启关机、域加入、改名与待重启检测实战指南Salt 的 Windows 系统管理模块 win_system重启关机、域加入、改名与待重启检测实战指南 本指南系统讲解 Salt 中用于 Windows运维配置管理后端Salt vSphere 执行模块实战指南统一管理 vCenter 与 ESXi 主机Salt vSphere 执行模块实战指南统一管理 vCenter 与 ESXi 主机 导读 本文面向使用 Salt 管理 VMware 基础设施的运维与研发运维配置管理后端创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表