add users, groups, authorized_keys, and dot files #9
Labels
No labels
bug
duplicate
enhancement
good first issue
help wanted
invalid
question
todo
todo 🗒️
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
stationgroup/ansible-experiments#9
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Overview
ubuntu,vagrant, orec2-user..bashrcor.cshrc. (Depending on OS and/or tag.) **.shell_aliasesfile so I can cleanly update/replace it per user?exportenvironment variables from a custom.shell_aliaseslike this:export SSH_AUTH_SOCK=$HOME/.gnupg/S.gpg-agent.ssh?~/.ssh/configif it doesn't exist.Details
I always need to add the same users to my servers but I don't want to add an
ubuntuuser to a FreeBSD server. Nor do I want to add the default FreeBSD AMI user; "ec2-user", to an Ubuntu server. I want those default accounts to stay, but I still want to be able to update them like the other user accounts.I need a stand-alone adduser playbook that I run against existing servers and new servers. Hopefully it will work in a sort of declarative fashion.
I want to be able to add and remove users and/or their variables from a list and run the playbook to match the list across all the hosts.
For example:
export SSH_AUTH_SOCK=$HOME/.gnupg/S.gpg-agent.sshto their.bashrc, IF it's not already there.SHELL=/bin/bashif they are on Ubuntu/debian or/bin/cshif the playbook detects they are on FreeBSD and/or the ec2 tag isfreebsd. ( ** Tags vs OS detection is your choice)List of users:
rememberdirectdegreesandgriefjamkingThis is what I tried to work with but gave up trying to debug my errors:
https://github.com/ANXS/generic-users
I started to make this little shell script to produce the
~/.ssh/configI wanted each user to run. But I decided since I'll be doing things this way for a long long time I might as well make it part of my custom add user playbook. This playbook should add the~/.ssh/configto existing servers if it doesn't exist, or update the existing one to match the playbook.I don't know the best way to achieve what I want. Maybe the task will have a bunch of variable files for each user and I update the config files for each user and re-run the playbook to update across all the servers.
I hope this makes sense.
Hi, I'm helping @srgvg with this and have aquestion.
Could someone elaborate a bit on the ssh config? When I look at the shell script it looks like it's being used for a local config. How would this look like when configured on all targeted servers? Thanks
Hello again Vincent,
I would have a bunch of pre done configs that I would like the playbook
to distribute. If there is an existing config with a non-matching checksum
in the users account on the remote system I would like it move to a file
name with the date appended and a .bak extension.
The shell script ended up being a dead end. But someone might find it
useful so I published it anyway. The script produces a simple shortcut for
a user to ssh with agent forwarding enabled every time. Agent forwarding is
great for keeping ssh keys off remote servers in a ssh bastion server
scenario. I ssh to the bastion with forwarding, and then forward the key to
the next server from there. That basic config file is what I want to
distribute. So agent forwarding works for each user. That shell script
isn’t really important.
On Sat, Aug 11, 2018 at 05:40 Vincent Van der Kussen <
notifications@github.com> wrote:
Hi,
So basically you want to add lines to both
~/.ssh/configand~/.bashrcor~/.cshrc?Ya. Basically.
I want to maintain the configs in my ansible playbook repo. So I can add and remove config options and rerun the playbook to update every users dot files. Same with the authorized_keys file.
Hi Bryan,
We prepared a first PR/MR for you, let us know what you think of it.
I noticed you migrated your repo to gitlab, just to be sure I prepared two
PR/MR for this, let us know on which repo's you want to move on.
Cheers,
Serge & Vincent
On 13 August 2018 at 16:14, Bryan Black notifications@github.com wrote:
Thank you!
I’ll review it tomorrow at work. I know it says I moved to GitLab, but I’ll do the review in GitHub until I’m more familiar with the GitLab workflow.
This PR is fantastic. Despite the subjectivity of this project you did everything exactly how I wanted. I really appreciate how well you guys read my mind. Every time I thought I had a question, I thought "I should see if they explain this is the documentation before I ask them..." sure enough, the doc had the answer or referenced the solution.
I'm really grateful.
There is one user option that I didn't realize I will need a toggle for. I need to be able to turn a users custom sudoer file on and off individually. There are different methods to adding a user to
sudo. The one we currently use on Ubuntu is adding a users sudoer file to/etc/sudoers.d/.Example on Ubuntu:
vagrant@ubuntu3:~$ sudo cat /etc/sudoers.d/vagrantIt looks like this method can work on FreeBSD as well: https://forums.freebsd.org/threads/sudoers-file-location-scripting-entries.60436/
Can you add an option for me to add/remove
sudofor a user and place the sudoer file in the appropriate directory with the correct permission, based on whether it's Ubuntu or FreeBSD? Then I can add or revoke a users sudo across servers whether the user is on Ubuntu or FreeBSD.I did seem to hit a bug with the initial
[GATHER FACTS]stage.Maybe it's a dependency I'm missing on FreeBSD (
10.0.0.219akalab3). I only did apkg install sudo pythonto satisfy the dependencies.(Click to expand -vvv console output)
It's a generic FreeBSD 11 AMI from the AWS Marketplace in EC2. Maybe there is a dependency or something simple I'm missing. But it prevents me from progressing at all on FreeBSD.
The console log above is cropped to the point where FreeBSD fails. The rest of the playbook continues and works on Ubuntu.
Hi,
I believe this is because the playbooks assume the remote user can become root via sudo. I just tested with a new BSD instance on AWS and got the same error. Using
become_method: susolved this for me.I tested initially with FreeBSD 11 which (not 100% sure because I might configured sude manually) allows the
ec2-userpasswordless sudo permissions.Oh ok. I encountered this earlier when I used part of
base-setup.ymlplaybook from the ansible-experiments/package_updates project. I noticed becomebecome_method=sudoin one of theansible.cfgand change the method specifically for the FreeBSD tasks. So this instance hassudoinstalled because ofbase-setup.yml, but theec2-userhasn't been configured forsudo, or password-less sudo yet. That makes more sense.It's one of the small differences in FreeBSD between different VPS (EC2, Vultr, Digital Ocean) or even Vagrant.
7U635073SA163173U