Samba 4 域控运维脚本包：备份、sysvol 与巡检实战

简介这份资源面向在 Debian Jessie 与 Stretch 上运维 Samba 4AD-DC的 Linux 系统管理员和运维工程师汇集了作者日常使用的实用脚本用于解决域控备份、SePrivileges 权限核查、sysvol ACL 检查与设置、域信息查看等常见运维问题适合具备一定 Samba 与 AD 基础的中级读者参考。压缩包共 25 个文件以 12 个 sh 脚本为主体辅以 9 个 txt 操作记录与 howto 说明、3 个 md 文档及 1 个 backup_samba4 备份脚本整体约 71KB体积轻量便于随取随用。目前已有 250 人学习。资源价值在于脚本可直接落地备份脚本基于原始 samba_backup 修改权限与 sysvol 检查脚本只读展示、不改动配置域信息工具同时兼容 AD 成员与 AD DC配套 howto 覆盖最小化 AD 搭建、成员文件服务器权限示例与检查流程便于读者对照理解脚本用途并快速排错。1. Samba 4 运维脚本包把域控日常从手敲命令里捞出来接手一台 Debian 上的 Samba 4 域控最磨人的不是装是装完之后那些重复活sysvol 到底同步没同步、备份有没有真的跑成功、某个用户改完密码多久生效、共享权限被谁动过。命令行一条条敲当然能查但每次都要翻历史记录拼参数时间一长就容易漏。这份脚本包就是冲这个场景来的——一组面向 Samba 4 的 Shell 脚本作者在 Debian Jessie 和 Debian Stretch 上做过验证覆盖备份、sysvol 处理、状态信息采集这类高频动作。它不适合想从零学 Samba 原理的人适合已经在维护域控、想把日常巡检和备份固化成脚本的从业者。下面按「脚本能干什么、怎么落地、哪里会翻车」拆开讲参数和边界都给到能直接抄的程度。2. 脚本包的能力边界先看清它替你干了哪几件事拿到一个 Shell 脚本包第一反应不该是直接bash xxx.sh而是先弄清它依赖什么、假设了什么环境。Samba 4 的运维脚本尤其如此因为 AD DC 模式下的目录结构、权限模型和普通文件服务器差别很大脚本写死一个路径换台机器就可能全盘失效。这一章先把脚本包的能力面和前置条件摊开再谈怎么跑。2.1 从文件名和调用方式反推脚本职责这类脚本包通常按动作命名比如备份类、sysvol 类、信息采集类。判断职责最直接的办法不是读全部代码而是先看每个脚本头部的变量定义和它调用的外部命令。常见做法是先跑一遍静态扫描# 列出脚本包内所有 shell 文件并提取每个文件头部 40 行做快速审阅 find ./samba4-scripts -type f -name *.sh -print0 | while IFS read -r -d f; do echo $f head -n 40 $f done这段的作用是把「这个脚本假设了哪些路径、调用了 samba-tool 还是 rsync、有没有硬编码域名」一次性暴露出来。重点看三类信息一是SAMBA_*或DC_*之类的变量默认值二是samba-tool子命令的用法三是备份目标路径是否写死。参数上head -n 40可以按需加大到 80脚本头部注释多的包看得更全。如果某个脚本第一行不是#!/bin/bash而是#!/bin/sh在 Debian 上要留意它是否用了 bash 特有语法Stretch 默认的 dash 会在[[ ]]这类写法上直接报错。审阅时还要确认脚本是否依赖samba-tool的版本行为。Samba 4 在不同小版本间samba-tool domain backup和samba-tool ntacl sysvolreset的参数有过调整Jessie 自带的 Samba 版本偏老Stretch 稍新脚本作者既然说两个版本都测过通常会在注释里标注兼容分支。看到if samba-tool ... 2/dev/null这种写法说明作者做了容错但也意味着失败可能被吞掉后面排查章节会专门讲这个坑。2.2 运行前置条件域控角色、权限与依赖命令脚本能跑通的前提是这台机器确实是 Samba AD DC而不是成员服务器或独立文件服务器。验证方式不是看smbd进程在不在而是查域功能级别和 sysvol 路径# 确认当前主机是 AD DC 角色并输出域信息与 sysvol 路径 samba-tool domain level show samba-tool domain info 127.0.0.1 testparm -s 2/dev/null | grep -E server role|sysvol|private dirsamba-tool domain level show输出 domain 和 forest 的功能级别能跑说明本机持有域数据库domain info连本机 127.0.0.1 拿域 SID 和 DC 列表连不上基本就是角色或服务有问题。testparm那段过滤出server role、sysvol、private dir三个关键项server role active directory domain controller是硬条件sysvol和private dir给出实际路径后面所有脚本的路径参数都要以这个输出为准不能照抄示例里的/var/lib/samba/sysvol。依赖命令方面备份脚本一般会用到rsync、tarsysvol 相关会用到samba-tool信息采集可能用到smbclient、wbinfo。Debian 上这些不一定默认全装先补齐再跑避免脚本跑到一半才报 command not found# 安装脚本包常见依赖Debian Jessie/Stretch 通用 apt-get update apt-get install -y rsync tar smbclient winbind samba-common-binwinbind在纯 DC 场景下不一定需要但wbinfo做用户和组查询时要用samba-common-bin提供testparm和部分samba-tool依赖。装完用command -v rsync samba-tool smbclient逐个确认路径存在比等脚本报错再回头补要省事。权限上备份 sysvol 和 private dir 需要 root脚本里如果没做id -u判断自己跑之前先sudo -i或确认当前是 root否则会出现「部分文件读不到但脚本仍返回 0」的假成功。2.3 把脚本参数化路径、域名、备份目录怎么改脚本包直接跑往往能用但换环境就得改。与其逐个文件vim不如把可变项抽成环境变量或统一配置文件。常见做法是在脚本包同级建一个env.sh被各脚本source进去# env.sh集中管理脚本包的可变参数按本机 testparm 输出填写 export SAMBA_DOMAINEXAMPLE # 短域名大写 export SAMBA_REALMEXAMPLE.LOCAL # 完整 realm export SYSVOL_PATH/var/lib/samba/sysvol # 以 testparm 输出为准 export PRIVATE_DIR/var/lib/samba/private # 以 testparm 输出为准 export BACKUP_ROOT/backup/samba # 备份落盘根目录需独立磁盘 export KEEP_DAYS14 # 备份保留天数变量含义逐条说清SAMBA_DOMAIN和SAMBA_REALM用于脚本里拼接 LDAP DN 或samba-tool的-H参数SYSVOL_PATH和PRIVATE_DIR必须和testparm实际输出一致写错会导致备份空目录却显示成功BACKUP_ROOT建议放在和系统盘不同的挂载点域控系统盘被备份撑满是经典翻车场景KEEP_DAYS控制清理策略后面清理脚本会读它。改完在脚本头部加一行source $(dirname $0)/env.sh这样脚本从任何目录调用都能找到配置。参数化之后同一套脚本在测试域控和生产域控之间迁移只需要换env.sh不用动脚本本体这也是判断一个脚本包值不值得长期用的重要标准。3. 备份与 sysvol 处理把高风险动作拆成可回滚的步骤Samba 4 域控最不能出事的两块数据一是域数据库private dir 下的 sam.ldb 等二是 sysvol 里的组策略和登录脚本。这两块的备份方式不一样恢复顺序也有讲究混在一起打包看着省事真出事时往往恢复不干净。这一章按「先备份、再校验、后清理」的顺序落地每一步都给可执行命令和判断依据。3.1 域数据库备份samba-tool domain backup 的正确用法Samba 4 自带samba-tool domain backup比直接 tar private dir 安全因为它会在备份时处理数据库一致性。常用两种模式online用于运行中的域控offline用于停机维护窗口。日常巡检用 online# 在线备份域数据库到指定目录文件名带时间戳便于轮转 TS$(date %Y%m%d-%H%M%S) BACKUP_DIR${BACKUP_ROOT}/domain-${TS} mkdir -p $BACKUP_DIR samba-tool domain backup online \ --server127.0.0.1 \ --targetdir$BACKUP_DIR \ --no-secrets 21 | tee ${BACKUP_DIR}/backup.log--server127.0.0.1指定从本机拉取避免网络抖动--targetdir是落盘目录脚本里通常按时间戳建子目录--no-secrets表示不备份密钥材料适合日常备份如果要做整机灾难恢复则去掉这个参数但备份文件敏感度会上升存放位置要收紧权限。tee把输出同时写日志后面校验和排查都靠它。执行完检查退出码和日志里有没有Backup successful只看目录非空是不够的——备份中途失败也可能留下半个目录。备份产物一般是一个 tar.gz校验分两层先看压缩包完整性再用samba-tool的恢复预检不实际恢复确认结构可读# 校验备份包完整性并列出包内顶层结构确认关键目录存在 BK$(ls -1t ${BACKUP_ROOT}/domain-*/samba-backup-*.tar.gz | head -n 1) gzip -t $BK echo gzip ok tar -tzf $BK | awk -F/ {print $1/$2} | sort -u | head -n 20gzip -t只验证压缩流没坏tar -tzf列出内容重点确认包内有private/、sysvol/这类顶层目录。如果列表里只有零星文件说明备份时源路径就不对回到env.sh核对PRIVATE_DIR。这一步花不了几秒但能挡掉大部分「以为备份了其实没备」的情况。3.2 sysvol 同步状态检查与 ACL 重置sysvol 在多台 DC 之间靠复制同步单台 DC 时问题不大一旦有两台以上GPO 不同步就是高频故障。检查思路是先看本机 sysvol 内容是否完整再看复制状态。Samba 4 的复制状态可以用samba-tool相关子命令和repadmin风格的工具查脚本包里通常封装成一条检查命令# 检查 sysvol 目录结构与 GPO 数量并输出复制相关状态 ls -1 ${SYSVOL_PATH}/${SAMBA_DOMAIN}/Policies | wc -l samba-tool ntacl sysvolcheck 21 | tail -n 20第一条数 Policies 下的 GPO 目录数量和预期值对比突然变少说明同步或挂载出了问题samba-tool ntacl sysvolcheck检查 sysvol 上的 NT ACL 是否和域内预期一致输出里出现ERROR或大量MISMATCH就要处理。注意这个命令在部分 Samba 版本上只读检查不会自动修修要用sysvolreset而sysvolreset会重写 ACL属于高风险动作执行前必须先做 3.1 的备份。ACL 重置的典型触发场景是 GPO 应用报权限错误或者从备份恢复 sysvol 之后。执行顺序固定为「备份 → 重置 → 再检查」# 高风险重置 sysvol ACL执行前确认已有可用备份 samba-tool ntacl sysvolreset samba-tool ntacl sysvolcheck 21 | grep -c ERROR || truesysvolreset不带额外参数它按域内对象重建 ACL耗时和 GPO 数量相关。执行后立刻再跑sysvolcheck用grep -c ERROR数错误行理想结果是 0。如果错误数不降反升多半是域内 GPO 对象本身损坏这时候别反复重置先查samba-tool gpo listall是否正常。血泪经验是sysvolreset不是万能药它只修 ACL 不修内容GPO 文件本身缺失得从备份或另一台 DC 补。3.3 备份轮转与清理别让备份把系统盘撑爆备份脚本跑通之后第二个星期往往不是备份失败而是磁盘满。轮转策略要在脚本里写死不能靠人记得删。基于env.sh里的KEEP_DAYS清理逻辑按目录修改时间删# 删除超过 KEEP_DAYS 的域备份目录先 dry-run 再实删 find ${BACKUP_ROOT} -maxdepth 1 -type d -name domain-* \ -mtime ${KEEP_DAYS} -print # 确认列表无误后去掉 -print 换成 -exec rm -rf {} 先-print看要删哪些确认没有误伤再实删这是清理脚本的固定习惯。-mtime 14表示修改时间超过 14 天按目录算而不是按文件因为每次备份是一个独立目录。参数上KEEP_DAYS别设太小域控备份体积和 GPO 数量、用户数相关保留两周是常见下限有合规要求就往上加。清理脚本建议单独放 cron和备份脚本错开时间避免备份还在写就被删。cron 配置示例备份每天凌晨、清理每周一次# /etc/cron.d/samba-backup 0 2 * * * root /opt/samba4-scripts/backup-domain.sh /var/log/samba-backup.log 21 30 3 * * 0 root /opt/samba4-scripts/cleanup-backup.sh /var/log/samba-backup.log 21时间错开半小时以上日志统一追加到同一文件便于按天排查。root字段不能省备份需要 root 权限。配完用run-parts --test /etc/cron.d不适用直接等一个周期或手动bash -x跑一遍脚本确认无交互提示cron 环境没有 tty任何read都会卡住。4. 状态采集与巡检把「域控还好吗」变成一条命令域控出问题往往不是突然崩而是先有一些小信号复制延迟、DNS 记录缺失、时间偏移、磁盘水位。脚本包里的信息采集类脚本价值就在这里——把散落在多个命令里的检查项收成一份输出巡检时扫一眼就知道要不要深入。这一章讲怎么用这类脚本以及输出怎么读。4.1 一条命令拿到域、复制、DNS 与磁盘概况信息采集脚本通常聚合多个samba-tool子命令。如果脚本包里的采集脚本输出太杂可以自己包一层固定检查项# 域控巡检快照域信息、DC 列表、DNS 记录数、磁盘水位 { echo domain info samba-tool domain info 127.0.0.1 echo dc list samba-tool domain dcpromo 2/dev/null || samba-tool computer list | head echo dns zones samba-tool dns zonelist 127.0.0.1 -U administrator --password${ADMIN_PASS} 2/dev/null | head -n 20 echo disk df -h ${SYSVOL_PATH} ${BACKUP_ROOT} } | tee /var/log/samba-health-$(date %F).logdomain info给域 SID 和 DC 列表computer list在部分版本上比dcpromo更稳用来确认 DC 计算机对象在dns zonelist需要凭据ADMIN_PASS从受限权限文件读别写死在脚本里df -h同时看 sysvol 所在盘和备份盘两个盘任一超过 80% 都该处理。整段用tee落日志按日期命名巡检历史可回溯。参数上head -n 20防止 zone 多时刷屏需要全量就去掉。读输出时抓几个关键点domain info里 DC 列表是否包含所有预期 DC少一台说明复制链路可能断了dns zonelist是否包含域的主 zone缺了会导致客户端加域失败df的Use%列是判断依据不是看剩余绝对值。这些判断标准写进巡检记录模板比每次凭感觉看要可靠。4.2 复制延迟与时间偏移两个最容易被忽略的指标多 DC 环境下复制延迟和时间偏移是很多「玄学」故障的根因。Samba 4 的复制可以用samba-tool drs showrepl看时间偏移用w32tm风格或直接比对 DC 间时间# 查看 DRS 复制状态摘要并比对本机与上游时间源偏差 samba-tool drs showrepl 21 | grep -E Last success|Last failure|consecutive failures | head -n 20 chronyc tracking 2/dev/null || timedatectl statusdrs showrepl输出里重点看Last success是否在预期复制周期内默认几分钟到十几分钟consecutive failures大于 0 就要查网络和凭据。时间部分chronyc tracking给偏移量没有 chrony 就用timedatectl看是否同步。Kerberos 对时间敏感偏移超过 5 分钟就会出现认证失败而现象往往是「密码明明对却登不上」很容易往密码策略上查偏。把这两项加进日常巡检能省掉大量排查时间。4.3 把巡检输出接进告警阈值怎么定巡检脚本只落日志还不够关键指标要能触发告警。最轻量的做法是在脚本末尾加判断异常时返回非零并输出原因交给上层 cron 邮件或监控 agent# 巡检阈值判断磁盘超 80% 或复制连续失败则返回非零 DISK_PCT$(df --outputpcent ${BACKUP_ROOT} | tail -n 1 | tr -dc 0-9) FAILS$(samba-tool drs showrepl 2/dev/null | grep -c consecutive failures: [1-9]) if [ $DISK_PCT -ge 80 ] || [ $FAILS -gt 0 ]; then echo ALERT disk${DISK_PCT}% repl_failures${FAILS} exit 1 fidf --outputpcent只取百分比列tr -dc 0-9去掉百分号grep -c数连续失败行数。阈值 80% 是经验值备份盘可以放到 85%系统盘建议 75%。exit 1让 cron 按非零退出码触发告警邮件比在脚本里自己发邮件更通用。注意grep -c在无匹配时返回 1配合|| true或直接判断数值别让脚本因为「没有失败」反而报错退出。5. 避坑与排查五个真实会遇到的翻车点脚本跑不起来的原因八成不是脚本本身写错而是环境假设不成立。下面五条按「现象 → 原因 → 解决」写都是这类 Samba 4 脚本包在 Debian 上落地时反复出现的。5.1 脚本返回 0 但备份目录是空的现象cron 日志显示备份脚本正常结束退出码 0但BACKUP_ROOT下只有空目录或半个 tar 包。原因脚本里samba-tool domain backup的失败被2/dev/null吞掉或者PRIVATE_DIR路径写错导致源目录不存在tar对空目录也能成功打包。解决去掉关键命令的2/dev/null把 stderr 写进日志备份后强制校验gzip -t和tar -tzf的顶层目录校验不过就exit 1。我一般会在备份脚本末尾加一段「产物非空且可解压」的断言不通过直接告警。5.2 sysvolreset 之后 GPO 反而应用失败现象执行samba-tool ntacl sysvolreset后sysvolcheck错误变少但客户端组策略应用报错增多。原因sysvolreset按域内对象重建 ACL如果域内 GPO 对象本身和 sysvol 文件不一致比如从旧备份恢复过重置只是把 ACL 对齐到错误的对象状态。解决重置前先samba-tool gpo listall核对 GPO 列表和 sysvol 下 Policies 目录逐一比对缺失的先从备份或另一台 DC 补齐再重置。重置永远放在备份之后且重置后要实际在客户端gpupdate验证不能只看sysvolcheck。5.3 Debian Jessie 上脚本报 [[ not found现象脚本在 Stretch 上正常在 Jessie 上第一行就报[[ not found或Syntax error: ( unexpected。原因脚本 shebang 写的是#!/bin/sh而 Debian 的/bin/sh指向 dash不支持[[ ]]、数组等 bash 语法。解决确认脚本用了 bash 特性就把 shebang 改成#!/bin/bash或者用bash script.sh显式调用。批量检查可以grep -l \[\[ *.sh找出用了[[但 shebang 是 sh 的文件。这类问题在跨 Jessie/Stretch 迁移时特别常见因为两个版本的默认 shell 行为一致但脚本作者测试时可能用了 bash 调用。5.4 cron 里跑正常、手动跑失败现象手动bash backup.sh一切正常配到 cron 后日志里全是 command not found 或路径错误。原因cron 的 PATH 极简通常只有/usr/bin:/binsamba-tool在/usr/sbin或/usr/local/sbin下就找不到另外 cron 不加载用户环境变量env.sh里的source如果用了相对路径也会失败。解决脚本里用绝对路径调用命令或在脚本开头export PATH/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/binsource改成基于$0的绝对路径。配完用env -i /bin/bash script.sh模拟干净环境跑一遍能提前暴露大部分环境依赖问题。5.5 备份文件权限过宽导致敏感信息暴露现象备份目录ls -l显示 755备份包内包含域数据库和可能的密钥材料。原因脚本用默认 umask 创建目录mkdir -p不指定权限备份包继承目录权限。解决备份根目录设 700备份子目录创建时mkdir -m 700备份包生成后chmod 600。如果用了--no-secrets敏感度降低但仍含域数据权限不能松。存放位置也别放在 Web 可访问目录或共享目录下独立挂载点加严格权限是底线。6. 进阶把脚本包改造成可审计的运维流水线脚本包能跑只是起点真正省心的是让它「自己证明自己跑对了」。我在维护域控时养成的习惯是任何高风险脚本执行前后都留可对比的快照任何定时任务都带产物校验任何告警都能追到具体哪一步失败。落到这份 Samba 4 脚本包上可以做三件事。第一给每个脚本加统一的执行框架记录开始时间、结束时间、退出码和关键产物路径写进一个 JSON 行日志。这样巡检时不用翻散落的 stdout直接按时间过滤就能看出哪次备份变慢、哪次 sysvol 检查错误数上升。第二把 3.1 的备份校验和 4.3 的阈值判断抽成公共函数所有脚本source同一份lib.sh避免每个脚本各写一套判断逻辑导致标准不一。第三定期做恢复演练——不是真恢复生产而是在隔离环境用最近一次备份跑samba-tool domain backup restore到临时目录确认包能解开、关键库文件在。备份没验证过恢复等于没有备份这句话在域控场景下尤其成立。一个可复用的执行框架骨架长这样# lib.sh统一记录脚本执行结果供各脚本 source run_logged() { local name$1; shift local start end rc start$(date %s) $; rc$? end$(date %s) printf {script:%s,start:%s,end:%s,rc:%s,dur:%s}\n \ $name $start $end $rc $((end-start)) /var/log/samba-scripts.jsonl return $rc }run_logged接收脚本名和命令执行后把耗时和退出码追加成 JSON 行rc非零时上层 cron 仍能拿到失败状态。参数上dur用秒够用且不引入额外依赖日志按行追加配合jq可以快速统计「过去七天备份平均耗时」这类指标。把这套框架套到备份、巡检、清理三个脚本上运维就从「记得跑」变成「跑没跑、跑得对不对都有据可查」。从那以后我每次改完域控脚本都会先用env -i模拟干净环境跑一遍再在隔离环境做一次恢复演练两步都过才敢放进 cron。希望帮到你。本文还有配套的精品资源点击获取