问题描述
在将Ansible应用于管理AWS Linux服务器集群上的用户时，面临一些问题。主要问题是希望在不破坏/etc/passwd文件的情况下，更好地组织用户。用户考虑是否可以使用Ansible来解决这个问题，但同时担心/etc/passwd文件被完全覆盖会导致问题。用户的具体问题如下：
- 是否应该使用Ansible重写
/etc/passwd，并使用Jinja2和Ansible vault来重新编写/etc/passwd中的值？如果是这样的话，需要在/etc/shadow文件中做些什么？是否安全？ - Ansible是否足够智能，以至于我不需要使用
/etc/passwd？例如，如果我重新使用users模块，并为用户分配正确的UID（例如，我有一个用户”bob”，他的UID应该一致为5002），这样会更好吗？
解决方案
请注意以下操作注意版本差异及修改前做好备份。
使用Ansible的user模块重写/etc/passwd
一个更好的方法是使用Ansible的user模块，该模块可以管理系统用户，它可以让你对现有用户进行管理而不会破坏/etc/passwd文件。这样，你可以重新分配用户的UID，使其保持一致。
以下是使用Ansible的user模块的步骤：
-
确保你已经安装了Ansible并配置了适当的连接设置，以便可以与AWS Linux服务器通信。
-
创建一个Ansible Playbook文件，比如
manage_users.yml。 -
在Playbook中，使用
user模块来管理用户。在这里，我们可以使用user模块来确保用户”bob”的UID为5002。注意，这不会破坏/etc/passwd文件，而是通过更改用户的属性来实现这一点。
以下是示例的manage_users.yml文件内容：
---
- name: Manage users on AWS Linux servers
hosts: your_aws_servers
tasks:
- name: Ensure user "bob" has UID 5002
user:
name: bob
uid: 5002
- 运行Ansible Playbook以应用更改：
ansible-playbook manage_users.yml
这将确保用户”bob”的UID为5002，而不会破坏/etc/passwd文件。
使用Name Service Switch (NSS) 和 PAM 用户管理
另一种方法是使用NSS和PAM的多个来源来管理用户，这样可以将系统用户和人类用户分离开来。对于大型项目，可以考虑使用LDAP，对于小型项目，nss_db和pam_userdb可能更适合。
NSS允许你在/etc/passwd文件以外的位置存储用户信息，而PAM允许你配置用户身份验证和授权。通过使用NSS和PAM的组合，你可以避免因为人类用户分布失败而导致服务器禁用。然而，对于服务（如使用Ansible的特权帐户），应该始终仅依赖于标准的/etc/passwd文件。
以下是使用NSS和PAM的步骤：
-
收集
/etc/passwd、/etc/shadow和/etc/group文件的安全副本并将其放在一个安全服务器上。 -
使用提供的NSS的Makefile来构建NSS passwd和group数据库文件。
-
从
shadow文件中提取用户和密码哈希，并构建PAM数据库文件。
awk -F: '{print $1; print $2}' shadow > users.txt
db_load -T -t hash -f users.txt pam-users.db
-
将文件分发到目标服务器的适当位置（例如
/var/db/authdb/*.db）。 -
设置目标服务器的
pam.conf和nsswitch.conf文件以使用这些数据库文件作为数据源。
这些步骤是可重复的构建/部署过程，一旦设置好pam/nss配置，更新/破坏用户身份验证/授权的风险就会非常低。
参考链接
- Name Service Switch (NSS)
- nsswitch.conf documentation
- pam_userdb documentation
- CentOS/RedHat vsftpd FTP with virtual users
结论
以上，我们介绍了两种解决方案来优化AWS Linux服务器上的用户管理。你可以根据项目规模和需求选择使用Ansible的user模块或使用Name Service Switch (NSS) 和 PAM的方法来更好地组织用户，而不会破坏/etc/passwd文件。确保在执行任何操作之前备份数据，并根据特定情况进行调整。