Salt 的 solaris_system 执行模块在 Solaris 上统一封装 reboot / shutdown / init / halt / poweroff【免费下载链接】saltSoftware to automate the management and configuration of infrastructure and applications at scale.项目地址: https://gitcode.com/gh_mirrors/sa/salt导读salt.modules.solaris_system是 Salt 针对 SunOS/Solaris 系操作系统提供的系统电源管理执行模块它把shutdown(1M)命令封装成halt、poweroff、reboot、shutdown、init五个统一的执行模块函数让运维人员可以用同一套 Salt 命令在 Solaris 主机上完成停机、重启与运行级别切换。本文以 salt/modules/solaris_system.py 为骨架结合平台检测、底层命令构造与测试用例完整讲解每个函数的参数、语义、runlevel 状态定义与实战调用方式读完后你可以在 Salt 的 CLI、状态文件SLS或 runner 中安全地驱动 Solaris 主机的电源管理。模块定位Solaris 系主机的 system 虚拟模块该模块在 2016.3.0 版本中引入模块顶部 docstring 明确其定位是 Support for reboot, shutdown, etc支持重启、关机等操作并且假设系统使用 Solaris 风格的 shutdown 命令。模块通过__virtualname__机制把自己注册为虚拟名system# salt/modules/solaris_system.py __virtualname__ system def __virtual__(): Only supported on Solaris-like systems if not salt.utils.platform.is_sunos() or not salt.utils.path.which(shutdown): return ( False, The system execution module failed to load: only available on Solaris-like ystems with shutdown command., ) return __virtualname__这意味着在 Solaris 主机上salt * system.reboot这类命令会被路由到这个 Solaris 专用实现而在 Linux/BSD/Windows 上则加载各自平台的system实现例如通用的 salt/modules/system.py。加载条件有两条缺一不可平台必须是 SunOS底层通过 salt/utils/platform.py 中的is_sunos()判断其实现是sys.platform.startswith(sunos)该函数带有real_memoize装饰器结果会被缓存避免重复调用sys.platform的开销。系统中必须存在shutdown可执行文件使用salt.utils.path.which(shutdown)在 PATH 中查找。Solaris 的shutdown位于/usr/sbin/shutdown只有找到该命令才认为系统真正具备 Solaris 风格关机能力。若任一条件不满足模块加载失败并返回描述性错误信息注意源码中 systems 的拼写笔误ystems是原样保留的加载失败文案。核心设计所有操作都收敛到一条 shutdown 命令这个模块的设计非常简洁shutdown()是唯一的真实现halt、poweroff、reboot都是对它的薄封装。所有命令都通过__salt__cmd.run执行并且强制python_shellFalse——即以列表形式直接 exec不经过 shell 解释避免命令注入与引号转义问题。shutdown默认进入运行级别 5安全断电def shutdown(delay0, messageNone): cmd [shutdown, -i, 5, -g, delay, -y] if message: cmd.append(message) ret __salt__cmd.run return retdelayint默认0关机前等待的秒数。messagestring可选关机前向终端用户广播的消息。构造出的命令形如shutdown -i 5 -g 0 -y含义是切换到 init state 5宽限期 0 秒自动回答 yes。reboot进入运行级别 6重启def reboot(delay0, messageNone): cmd [shutdown, -i, 6, -g, delay, -y] if message: cmd.append(message) ret __salt__cmd.run return ret与shutdown唯一的区别是把-i参数从5换成6即让系统进入 init state 6 完成重启。参数语义完全相同。halt 与 poweroff直接委托给 shutdowndef halt(): return shutdown() def poweroff(): return shutdown()halt和poweroff没有任何参数调用时直接委托给无参的shutdown()。因此三者行为完全等价执行salt * system.halt与salt * system.poweroff与salt * system.shutdown在 Solaris 上都会触发shutdown -i 5 -g 0 -y。这种设计为上层调用方提供了与 Linux 模块一致的接口命名Linux 上 halt 与 poweroff 语义有差异同时保持 Solaris 底层实现统一。initSolaris sysV 运行级别切换详解init(state)是模块中唯一不依赖默认 init state 的函数它把用户传入的 state 直接透传给shutdown -idef init(state): cmd [shutdown, -i, state, -g, 0, -y] ret __salt__cmd.run return ret注意这里宽限期被硬编码为 0 秒、自动确认-y与shutdown/reboot可配置 delay 不同。由于state会被直接拼进命令行参数实际调用时应传入受控的取值0/1/5/6/s/S不要传入用户可控的任意字符串。模块 docstring 给出了完整的 Solaris 运行级别语义这是实操时必须掌握的核心知识init state含义0停止操作系统Stop the operating system1管理状态administrative state。挂载多用户操作所需的文件系统允许访问多用户文件系统的登录可用从固件模式进入 state 1 时只有控制台console处于活动状态其他多用户state 2服务不可用。注意从多用户状态切换到 state 1 时并非所有用户进程都会被停止s / S单用户状态single-user state。所有用户进程在转入该状态时被停止多用户登录所需的文件系统被卸载只能通过控制台访问系统需要访问多用户文件系统的登录不可用5关闭机器直到可以安全断电若可能则让机器自动断电调用 rc0 过程执行该任务6停止操作系统并按/etc/inittab中initdefault条目定义的状态重启调用 rc6 过程执行该任务这些语义与 Solaris 的shutdown(1M)/init(1M)手册页一致直接决定了你在编排任务时该选哪个 state日常维护进单用户用system.init s安全断电用system.init 5重启用system.init 6。底层命令语义-i / -g / -y 与广播消息五个函数构造的命令行可以归纳为一张表函数构造命令目标 init stateshutdown(delay, message)shutdown -i 5 -g delay -y [message]5安全断电reboot(delay, message)shutdown -i 6 -g delay -y [message]6重启init(state)shutdown -i state -g 0 -y用户指定halt()shutdown -i 5 -g 0 -y5poweroff()shutdown -i 5 -g 0 -y5对照 Solarisshutdown(1M)的语义-i init-state指定要切换到的 init 运行级别取值范围即上表的 0/1/5/6/s/S。-g grace-period宽限期秒在宽限期开始时会向所有登录终端发送警告。模块中delay参数直接映射到这里默认0表示立即执行。-y预回答 shutdown 在宽限期结束后可能提出的确认询问使整个过程无需人工干预这也是自动化执行的前提。尾部的message作为广播消息追加在命令行末尾会在宽限期内显示给所有登录用户。因为python_shellFalse整个命令以参数列表形式交给cmd.run直接执行delay与message中的特殊字符不会被 shell 二次解释这是模块保证参数安全传递的关键实现细节。与其他平台 system 模块的分工对比Salt 采用同一虚拟名、多平台实现的加载策略在 salt/modules/system.py 中同样存在reboot构造shutdown -r now与shutdown构造shutdown -h nowFreeBSD/NetBSD/OpenBSD 上为-p now等实现并由各自__virtual__中的平台判断决定加载哪一个。tests/pytests/unit/modules/test_system.py中的测试可以印证这一分工通用模块的test_reboot断言调用参数为[shutdown, -r, now]test_shutdown断言为[shutdown, -h, now]而 Solaris 实现则统一使用shutdown -i state的 Solaris 风格。因此在Solaris/SunOS主机上system.reboot实际执行shutdown -i 6 ...由 salt/modules/solaris_system.py 提供在Linux/BSD主机上system.reboot执行shutdown -r now由 salt/modules/system.py 提供。同样的命令名在不同平台上落到不同实现这正是 Salt 执行模块虚拟名机制的典型体现也让用户无需关心目标平台差异。实战调用CLI、salt-call 与状态编排1. 通过 salt CLI 批量下发假设你的 Solaris 目标主机已用salt-key -L确认接受密钥直接使用# 立即关机等同 halt / poweroff salt sol* system.shutdown salt sol* system.halt salt sol* system.poweroff # 60 秒后关机并广播消息 salt sol* system.shutdown 60 disk replacement # 立即重启 salt sol* system.reboot # 60 秒后重启并广播消息 salt sol* system.reboot 60 system upgraded # 切换到单用户状态维护模式 salt sol* system.init s # 切换到运行级别 3多用户 salt sol* system.init 3其中system.shutdown 60 disk replacement 与system.reboot 60 system upgraded 是模块 docstring 中给出的标准 CLI 示例分别对应delay60与message参数的实战用法。2. 在单台主机上验证salt-call只想在目标 Solaris 主机本地确认模块行为不真正关机时可以用testTrue预览命令或用 salt-call 直接触发salt sol01 system.reboot testTrue salt-call system.shutdown 30 maintenance window 3. 在 SLS 状态文件中编排虽然solaris_system是执行模块而非状态模块但可以通过状态文件中的module.run引用它实现先同步配置、再安排重启的编排# /srv/salt/solaris/reboot.sls reboot-maintenance: module.run: - name: system.reboot - delay: 60 - message: rolling upgrade: reboot in 60s 配合 Salt 的schedule或 reactor还可以把延迟重启安排到业务低峰窗口执行。4. 目标选择与批量控制由于__virtual__的加载限制system.*只在 SunOS 且存在shutdown命令的主机上可用。批量执行时可以用 grains 或子网掩码精确定位 Solaris 目标salt -G kernel:SunOS system.reboot salt -C sol* and Gos_family:Solaris system.init s测试与验证当前仓库中 tests/pytests/unit/modules/test_system.py 为通用salt.modules.system提供了单元测试通过patch.dict(system.__salt__, {cmd.run: MagicMock(...)})模拟cmd.run并断言构造的命令列表这同样验证了所有电源管理函数最终收敛为一条shutdown命令的设计模式。针对solaris_system的测试方式可以照此模式mockcmd.run后断言shutdown()收到[shutdown, -i, 5, -g, 0, -y]、reboot(60, msg)收到[shutdown, -i, 6, -g, 60, -y, msg]、init(s)收到[shutdown, -i, s, -g, 0, -y]。手动验证模块是否在目标主机加载成功可用salt sol01 sys.doc system.reboot salt sol01 sys.list_modules | grep system若模块未加载sys.list_modules中不会出现system此时应检查主机是否 SunOS、/usr/sbin/shutdown是否存在以及 minion 日志中的加载失败提示即__virtual__返回的错误信息。注意事项与使用限制仅限 Solaris 系模块由is_sunos()门控SmartOSillumos等也属于sunos平台前缀会尝试加载非 SunOS 主机请使用通用 salt/modules/system.py 提供的system.reboot/system.shutdown。延迟参数默认立即执行delay默认0意味着system.shutdown不带参数时会立即关机生产环境务必显式传延迟或先testTrue演练。init 的宽限期固定为 0system.init state无法配置延迟调用即切换编排时需自行把控时机。消息为可选广播message仅在传入时才追加到命令尾部不含 shell 元字符时无需转义python_shellFalse已规避 shell 解释。返回值为cmd.run的 stdout函数直接透传命令输出判断执行结果应结合 Salt 的cmd.run返回语义非零退出码会反映在模块返回中。不可在仓库内修改代码本模块源码 salt/modules/solaris_system.py 为开源仓库只读内容文中所有分析仅用于理解与调用改动需遵循 Salt 上游贡献流程。小结salt.modules.solaris_system用不到 150 行代码把 Solaris 的shutdown(1M)收敛为五个语义清晰的执行模块函数halt/poweroff/shutdown收敛到 init state 5reboot收敛到 init state 6init透传任意运行级别配合delay延迟、message广播与-y自动确认可以在无人值守场景下安全完成 Solaris 主机的关机、重启与维护模式切换。掌握它的加载条件、命令构造与运行级别语义你就能在任何 Salt 管理的 Solaris 主机上可靠地编排电源管理任务。【免费下载链接】saltSoftware to automate the management and configuration of infrastructure and applications at scale.项目地址: https://gitcode.com/gh_mirrors/sa/salt创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考