<h2>If editing critical flat-files across multiple servers in one place is too scary..</h2>

<p>One approach I have often recommended is to let system users reside in /etc/passwd files, and to add an additional Name Service Switch (NSS) source for humans that need to log in. For big projects (lots of users authenticating against the PAM user data), that means LDAP, and for small ones (few can be hundreds of such users), nss_db + pam_userdb.</p>

<p>With multiple NSS and PAM sources for users, you can avoid disabling a server when the human user accounts distribution fails for whatever reason. Services (like your privileged Ansible account) should always depend ONLY on the standard /etc/passwd files. LDAP (or even MySQL) is probably overkill for some cases (like yours). </p>

<p>Consider the old BDB backed gems, designed originally (for big FTP file distribution servers) to provide faster logins than /etc files, but otherwise work nearly the same. They store the same passwd and groups flat files' content, but loaded into a (now non GPL) BerkeleyDB NOSQL key/value database file which is faster to read. For this purpose, it's just an extra place to store user/group authentication/authorization data.</p>

<h2>NSS</h2>

<p><a href="https://en.wikipedia.org/wiki/Name_Service_Switch" rel="nofollow noreferrer">https://en.wikipedia.org/wiki/Name_Service_Switch</a></p>

<p><a href="https://www.systutorials.com/docs/linux/man/5-nsswitch.conf/" rel="nofollow noreferrer">https://www.systutorials.com/docs/linux/man/5-nsswitch.conf/</a></p>

<p><a href="https://sourceforge.net/p/nssdb/home/Home/" rel="nofollow noreferrer">https://sourceforge.net/p/nssdb/home/Home/</a></p>

<h2>PAM</h2>

<p><a href="https://en.wikipedia.org/wiki/Linux_PA" rel="nofollow noreferrer">https://en.wikipedia.org/wiki/Linux_PA</a></p>

<p><a href="https://www.systutorials.com/docs/linux/man/8-pam_userdb/" rel="nofollow noreferrer">https://www.systutorials.com/docs/linux/man/8-pam_userdb/</a></p>

<p><a href="https://www.cyberciti.biz/tips/centos-redhat-vsftpd-ftp-with-virtual-users.html" rel="nofollow noreferrer">https://www.cyberciti.biz/tips/centos-redhat-vsftpd-ftp-with-virtual-users.html</a></p>

<h2>steps</h2>

<ol>
<li>collect your passwd, shadow, and group files on a secure server with
the nss_db Makefile</li>
<li>build the nss passwd and group db files using the provided nss_db
Makefile</li>
<li><p>extract the users and password hashes from shadow file and build PAM db file</p>

<pre><code>awk -F: '{print $1;print$2}' shadow &gt; users.txt # used like the vsftpd vusers.txt example

db_load -T -t hash -f users.txt pam-users.db
</code></pre></li>
<li><p>distribute the files to somewhere appropriate on your target servers
(maybe /var/db/authdb/*.db)</p></li>
<li><p>set up the target servers' pam.conf and nsswitch.conf files to use
these db files</p></li>
<li><p>Steps 1-4 are the repeatable build/deploy process.</p></li>
</ol>

<h2>why?</h2>

<ul>
<li>Once you have working pam/nss configs, your risk of breaking services
by updating/corrupting user auth/auth is very low.</li>
<li>User authentication will work on each server with no external network dependencies like LDAP or MySQL etc.</li>
<li>You can treat the DB files as immutable artifacts on the farm to reduce/prevent user auth snowflakes even if you can't have immutable servers.</li>
</ul>

CC BY-SA 3.0
2017-10-24T07:53:05.100Z
For 3, the stdin redirection is superfluous, awk can read a file directly: `awk -F: '{print $1;print$2}' shadow > users.txt` is enough
Tensibai
CC BY-SA 3.0
2017-10-24T14:58:19.940Z
I chose this syntax @Tensibai it is only superfluous to the shell, commands. It communicates intent a little more
Jeremy
CC BY-SA 3.0
2017-10-24T15:16:31.940Z
feel free to edit it back in, I was mainly editing for the code block at first. (I'm against unnecessary context changes and stream abuse where not needed)
Tensibai
CC BY-SA 3.0
2017-10-25T18:19:28.760Z
Not worth the quibble on my end. Thanks for caring though!
Jeremy
CC BY-SA 3.0
2017-10-24T01:23:52.537Z
2017-10-24T07:54:08.167Z
2017-10-24T07:54:08.167Z
Jeremy
<p>I am going to be attached to a small project that basically organizes the users in a cluster of AWS Linux servers. The servers users assigned have different UIDS and maybe different GUIDs. I am hoping to use Ansible to fix this up and organize users better. I can get Ansible to run on a test environment but one thing has got me nervous is that <code>/etc/passwd</code> gets completely screwed up! So my questions are as follows:</p>

<ol>
<li>Would a better approach be to overwrite <code>/etc/passwd</code> using Ansible. So basically I have a template of <code>/etc/passwd</code> and use a combination of Jinja2 and Ansible vault to rewrite the values in <code>/etc/passwd</code> (I am currently doing this with <code>sudoers</code> and it works well)? If this is the case, would I need to do anything with <code>/etc/shadow</code> or am I safe there?</li>
<li>Is Ansible smart enough where I won't need to use <code>/etc/passwd</code>? For example, I have user <code>bob</code> assigned to UID 5001 when he should be consistently assigned 5002. If I was to readd the user using the users module and specifically assign 5002 to his UID, would that work better?</li>
</ol>

<p>Please let me know if you need any more information.</p>

CC BY-SA 3.0
2017-10-23T16:55:01.567Z
I'd try the [user module](http://docs.ansible.com/ansible/latest/user_module.html) first.  You might end up with local users that aren't in the central list that shouldn't get overwritten.  Replacing `/etc/passwd` would cause those users to get lost.
chicks
CC BY-SA 3.0
2017-10-23T18:01:59.463Z
Well one concern i have is trying to organize the UIDs for existing users and making sure they UIDs get correctly overwritten and stay consistent throughout the cluster of servers I have..
ryekayo
CC BY-SA 3.0
2017-10-24T07:57:17.160Z
What is unclear in [ansible user management](http://docs.ansible.com/ansible/latest/user_module.html#examples) documentation about forcing the uid ?
Tensibai
CC BY-SA 3.0
2017-10-24T13:49:16.427Z
@Tensibai I never said i was unclear about Ansible's documentation. In fact, Ansible is well documented. What I was asking is if reassigning a UID for already created users would have any side effects and if i would be better off rewriting /etc/passwd. But I think at this point, I am fine with just using Ansible's user module to overwrite the UIDs
ryekayo
CC BY-SA 3.0
2017-10-24T13:58:36.700Z
Changing a user uid will not change files ownership, so yes there's an impact, whatever the solution you go for.
Tensibai
<ansible><amazon-ec2>
Approaching user adds and edits with Ansible
ryekayo
# Approaching user adds and edits with Ansible

(Asked by: username_0 on 2017-10-23)

I am going to be attached to a small project that basically organizes the users in a cluster of AWS Linux servers. The servers users assigned have different UIDS and maybe different GUIDs. I am hoping to use Ansible to fix this up and organize users better. I can get Ansible to run on a test environment but one thing has got me nervous is that `/etc/passwd` gets completely screwed up! So my questions are as follows:

1. Would a better approach be to overwrite `/etc/passwd` using Ansible. So basically I have a template of `/etc/passwd` and use a combination of Jinja2 and Ansible vault to rewrite the values in `/etc/passwd` (I am currently doing this with `sudoers` and it works well)? If this is the case, would I need to do anything with `/etc/shadow` or am I safe there?
2. Is Ansible smart enough where I won't need to use `/etc/passwd`? For example, I have user `bob` assigned to UID 5001 when he should be consistently assigned 5002. If I was to readd the user using the users module and specifically assign 5002 to his UID, would that work better?

Please let me know if you need any more information.

**Tags:** ansible, amazon-ec2

> **Comments:**
> **username_1**: I'd try the [user module](http://docs.ansible.com/ansible/latest/user_module.html) first.  You might end up with local users that aren't in the central list that shouldn't get overwritten.  Replacing `/etc/passwd` would cause those users to get lost.  
> **username_0**: Well one concern i have is trying to organize the UIDs for existing users and making sure they UIDs get correctly overwritten and stay consistent throughout the cluster of servers I have..  
> **username_2**: What is unclear in [ansible user management](http://docs.ansible.com/ansible/latest/user_module.html#examples) documentation about forcing the uid ?  
> **username_0**: @username_2 I never said i was unclear about Ansible's documentation. In fact, Ansible is well documented. What I was asking is if reassigning a UID for already created users would have any side effects and if i would be better off rewriting /etc/passwd. But I think at this point, I am fine with just using Ansible's user module to overwrite the UIDs  
> **username_2**: Changing a user uid will not change files ownership, so yes there's an impact, whatever the solution you go for.  

---

## 1 answers

### Answer by username_3 on 2017-10-24. Score: 4

If editing critical flat-files across multiple servers in one place is too scary..
One approach I have often recommended is to let system users reside in /etc/passwd files, and to add an additional Name Service Switch (NSS) source for humans that need to log in. For big projects (lots of users authenticating against the PAM user data), that means LDAP, and for small ones (few can be hundreds of such users), nss_db + pam_userdb.
With multiple NSS and PAM sources for users, you can avoid disabling a server when the human user accounts distribution fails for whatever reason. Services (like your privileged Ansible account) should always depend ONLY on the standard /etc/passwd files. LDAP (or even MySQL) is probably overkill for some cases (like yours). 
Consider the old BDB backed gems, designed originally (for big FTP file distribution servers) to provide faster logins than /etc files, but otherwise work nearly the same. They store the same passwd and groups flat files' content, but loaded into a (now non GPL) BerkeleyDB NOSQL key/value database file which is faster to read. For this purpose, it's just an extra place to store user/group authentication/authorization data.
NSS
https://en.wikipedia.org/wiki/Name_Service_Switch
https://www.systutorials.com/docs/linux/man/5-nsswitch.conf/
https://sourceforge.net/p/nssdb/home/Home/
PAM
https://en.wikipedia.org/wiki/Linux_PA
https://www.systutorials.com/docs/linux/man/8-pam_userdb/
https://www.cyberciti.biz/tips/centos-redhat-vsftpd-ftp-with-virtual-users.html
steps

collect your passwd, shadow, and group files on a secure server with
the nss_db Makefile
build the nss passwd and group db files using the provided nss_db
Makefile
extract the users and password hashes from shadow file and build PAM db file
awk -F: '{print $1;print$2}' shadow > users.txt # used like the vsftpd vusers.txt example

db_load -T -t hash -f users.txt pam-users.db

distribute the files to somewhere appropriate on your target servers
(maybe /var/db/authdb/*.db)
set up the target servers' pam.conf and nsswitch.conf files to use
these db files
Steps 1-4 are the repeatable build/deploy process.

why?

Once you have working pam/nss configs, your risk of breaking services
by updating/corrupting user auth/auth is very low.
User authentication will work on each server with no external network dependencies like LDAP or MySQL etc.
You can treat the DB files as immutable artifacts on the farm to reduce/prevent user auth snowflakes even if you can't have immutable servers.

> **Comments:**
> **username_2**: For 3, the stdin redirection is superfluous, awk can read a file directly: `awk -F: '{print $1;print$2}' shadow > users.txt` is enough  
> **username_3**: I chose this syntax @username_2 it is only superfluous to the shell, commands. It communicates intent a little more  
> **username_2**: feel free to edit it back in, I was mainly editing for the code block at first. (I'm against unnecessary context changes and stream abuse where not needed)  
> **username_3**: Not worth the quibble on my end. Thanks for caring though!  

---

