saltstack状态配置管理使用技巧两则

以下配置管理功能均是支持跨操作系统、系统版本的，这也是saltstack的一个迷人之处。

怎样方便得管理一个系统用户

支持按需创建新用户，也同样支持按需对用户的配置属性进行变更。

#生成密码的命令，输入密码并得到相应的MD5散列值:openssl passwd -1
change test123 user passwd:
  user.present:
    - name: test123
    - password: $1$Ihuhx62V$l0L/Ws6gLp8ZaRdGjruM.0
#为用户配置ssh密钥登录的授权，使用test123.id_rsa.pub文件维护ssh-rsa公钥信息
add the test123 pub key:
  ssh_auth.present:
    - user: test123
    - source: salt://user-managed/test123.id_rsa.pub

批量配置zabbix监控postfix服务积压的邮件

我们经常会在操作系统中部署各种应用、脚本、定时任务等，这些操作中有很多环节可能会触发向操作系统用户发送系统邮件的行为。尤其是一些报警消息、错误提示消息。

当系统中的postfix服务启动且正常运行时，这些系统邮件会自动分发到各个系统用户帐号中去（一般为/var/spool/mail路径下，按系统用户名创建的同名文件），这样当用户登录系统时就会收到有新邮件的提示消息了。适当监控，及时关注并处理、清理系统用户的邮件信息，是很好的一个系统运维最佳实践。

但是，postfix服务本身因为同样可以提供向系统外部发送邮件的丰富功能，从信息安全的角度（比如等保三级的测评要求）看，这一邮件服务是存在较大的信息安全风险的（比方说这相当于给侵入的黑客提供了一个便利的把数据泄露到外部的工具）。所以说，目前是建议默认关停postfix服务。

关停postfix服务后，就不会产生系统邮件了吗？不完全是。实际上，操作系统中的各种报警消息、提示消息，仍然发送给了postfix处理，但邮件发送失败并积压在了/var/spool/postfix/maildrop路径下了。

大家可以试着推测下这一变化可能会带来的风险有哪些。

• 风险点1：由于各种系统报警与报错消息的邮件不能成功发送到系统用户了，系统管理员失去了及时感知和处理系统故障或配置错误的机会，可能会引发进一步更大的技术故障。
• 风险点2：发送失败的系统邮件会全部积压在/var/spool/postfix/maildrop路径下，每个邮件会产生一个文件。试想到一年或两年后可能会有多少？对于业务比较繁忙的主机系统来说，就会面临在长时间运行的过程中，在这一文件系统路径下产生5万、10万，甚至是更多数量系统邮件文件的风险。最终耗尽文件系统存储容量或inode资源，引发应用服务的事故。

下面是针对centos6/7设计并验证过的配置允许zabbix监控postfix积压系统邮件的salt功能。
在/srv/salt路径下，创建一个salt state状态配置管理文件 zabbix-postfix.sls，内容如下所示：

zabbix user properties adjust:
  user.present:
    - name: zabbix
    - createhome: False
    - shell: /sbin/nologin
    - optional_groups:
      - postdrop

adjust maildrop directory privileges:
  file.directory:
    - name: /var/spool/postfix/maildrop
    - dir_mode: 770
    - onlyif: test -d /var/spool/postfix/maildrop

restart zabbix agent when zabbix user is changed:
  service.running:
    - name: zabbix_agent
    - enable: True
    - watch:
      - user: zabbix user properties adjust

模块功能的说明：

• 将zabbix用户补充配置一个新的用户组postdrop，以实现查看该用户组权限的系统文件。当操作系统中不存在postdrop用户组时，保持静默执行，不会报错。
• 调整maildrop目录的权限以允许zabbix用户具有读权限并监控目录中积压的邮件文件数量。当且仅当操作系统中存在指定文件路径时执行，不存在则不执行。
• 按需重启zabbix agent服务，当且仅当系统用户zabbix的属性配置发生了变化时。无变化则不重启。
• 以上三个功能模块，虽然是针对于centos6/7设计并测试验证的，但实际上可以放心得在各种操作系统上执行，符合判定条件的则会进行变更，否则会略过，不执行。
• 以上模块功能的实现，支持幂等，即有则改之，无则权当做个“体检”，什么都不会变更