Answers: <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>
  
Answers: CC BY-SA 3.0
Answers: 2017-10-24T07:53:05.100Z
Answers: For 3, the stdin redirection is superfluous, awk can read a file directly: `awk -F: '{print $1;print$2}' shadow > users.txt` is enough
Answers: Tensibai
Answers: CC BY-SA 3.0
Answers: 2017-10-24T14:58:19.940Z
Answers: I chose this syntax @Tensibai it is only superfluous to the shell, commands. It communicates intent a little more
Answers: Jeremy
Answers: CC BY-SA 3.0
Answers: 2017-10-24T15:16:31.940Z
Answers: 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)
Answers: Tensibai
Answers: CC BY-SA 3.0
Answers: 2017-10-25T18:19:28.760Z
Answers: Not worth the quibble on my end. Thanks for caring though!
Answers: Jeremy
Answers: CC BY-SA 3.0
Answers: 2017-10-24T01:23:52.537Z
Answers: 2017-10-24T07:54:08.167Z
Answers: 2017-10-24T07:54:08.167Z
Answers: Jeremy
Body: <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>
  
Comments: CC BY-SA 3.0
Comments: 2017-10-23T16:55:01.567Z
Comments: 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.
Comments: chicks
Comments: CC BY-SA 3.0
Comments: 2017-10-23T18:01:59.463Z
Comments: 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..
Comments: ryekayo
Comments: CC BY-SA 3.0
Comments: 2017-10-24T07:57:17.160Z
Comments: What is unclear in [ansible user management](http://docs.ansible.com/ansible/latest/user_module.html#examples) documentation about forcing the uid ?
Comments: Tensibai
Comments: CC BY-SA 3.0
Comments: 2017-10-24T13:49:16.427Z
Comments: @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
Comments: ryekayo
Comments: CC BY-SA 3.0
Comments: 2017-10-24T13:58:36.700Z
Comments: Changing a user uid will not change files ownership, so yes there's an impact, whatever the solution you go for.
Comments: Tensibai
Tags: <ansible><amazon-ec2>
Title: Approaching user adds and edits with Ansible
UserDisplayName: ryekayo
ThreadText: # 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
  
  1. collect your passwd, shadow, and group files on a secure server with
     the nss\_db Makefile
  2. build the nss passwd and group db files using the provided nss\_db
     Makefile
  3. 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
  
     ```
  4. distribute the files to somewhere appropriate on your target servers
     (maybe /var/db/authdb/\*.db)
  5. set up the target servers' pam.conf and nsswitch.conf files to use
     these db files
  6. 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!  
  
  ---
  
  