Using Ansible to Manage install and update Apple OSX DHCP clients

DustinB3403

@stacksofplates said in Using Ansible to Manage install and update Apple OSX DHCP clients:

@DustinB3403 said in Using Ansible to Manage install and update Apple OSX DHCP clients:

may not be available at update time.

This is harder and a lot more advanced. There's multiple ways to handle this, but like I said it's a lot more advanced than just running playbooks or ad-hoc commands on a system.

Okay so lets stick with ad-hoc commands for now.

Pretending I was still at the office with this server installed and the homebrew role installed. How would I start finding my clients?

stacksofplates

@DustinB3403 said in Using Ansible to Manage install and update Apple OSX DHCP clients:

We do have a uniform user account that could be use and is a wheel user and can be elevated to root if needed.

If I wanted to not use that account (because passwords) I'd have to generate ssh keys from every apple workstation I have and pass those to the ansible server?

No you would generate the key on the Ansible server and push the pub key out to the workstations. You can use Ansible to do that.

- name: Ensure user key is present
  authorized_key:
    user: dustin
    state: present
    key: "{{ lookup('file', '/home/dustin/.ssh/id_rsa.pub') }}"

Then just send it out using your username/password for the first time, and then you can use the key after that.

stacksofplates

@DustinB3403 said in Using Ansible to Manage install and update Apple OSX DHCP clients:

@stacksofplates said in Using Ansible to Manage install and update Apple OSX DHCP clients:

@DustinB3403 said in Using Ansible to Manage install and update Apple OSX DHCP clients:

may not be available at update time.

This is harder and a lot more advanced. There's multiple ways to handle this, but like I said it's a lot more advanced than just running playbooks or ad-hoc commands on a system.

Okay so lets stick with ad-hoc commands for now.

Pretending I was still at the office with this server installed and the homebrew role installed. How would I start finding my clients?

Do they have DNS names or are you referencing solely off of IP addresses?

DustinB3403

@stacksofplates said in Using Ansible to Manage install and update Apple OSX DHCP clients:

@DustinB3403 said in Using Ansible to Manage install and update Apple OSX DHCP clients:

@stacksofplates said in Using Ansible to Manage install and update Apple OSX DHCP clients:

@DustinB3403 said in Using Ansible to Manage install and update Apple OSX DHCP clients:

may not be available at update time.

This is harder and a lot more advanced. There's multiple ways to handle this, but like I said it's a lot more advanced than just running playbooks or ad-hoc commands on a system.

Okay so lets stick with ad-hoc commands for now.

Pretending I was still at the office with this server installed and the homebrew role installed. How would I start finding my clients?

Do they have DNS names or are you referencing solely off of IP addresses?

They'll register in DNS, but nothing is assigned, so it would be better to reference off of the IP only until a key was present.

Which

@stacksofplates said in Using Ansible to Manage install and update Apple OSX DHCP clients:

name: Ensure user key is present
authorized_key:
user: dustin
state: present
key: "{{ lookup('file', '/home/dustin/.ssh/id_rsa.pub') }}"

Where / how do this go?

stacksofplates

@DustinB3403 said in Using Ansible to Manage install and update Apple OSX DHCP clients:

They'll register in DNS, but nothing is assigned, so it would be better to reference off of the IP only until a key was present.

I'm confused as to how a key will change any of that?

Where / how do this go?

That would go in a playbook. You could use this:

---
- name: Ensure key exists
  hosts: all
  user: dustin
  
  tasks:
    - name: Ensure user key is present
      authorized_key:
        user: dustin
        state: present
        key: "{{ lookup('file', '/home/dustin/.ssh/id_rsa.pub') }}"

Then just run:

ansible-playbook playbook.yml

Keep in mind the inventory has to be populated for this to hit those systems and you will most likely want to set Ansible to ignore the host keys because you will have to accept each one as it tries to connect if you don't.

DustinB3403

@stacksofplates So on your ansible server do you have a folder called playbooks and in that you have numerous different <something>.yml files each that do something?

IRJ

As @stacksofplates mentioned, connect with SSH how you do now, and I would create a special account just for ansible via playbook once you authenticat

IRJ

@DustinB3403 said in Using Ansible to Manage install and update Apple OSX DHCP clients:

@stacksofplates So on your ansible server do you have a folder called playbooks and in that you have numerous different <something>.yml files each that do something?

You can and it's recommended to do that when things start to get more complex, but for simple commands you can use a single yaml file.

stacksofplates

@DustinB3403 said in Using Ansible to Manage install and update Apple OSX DHCP clients:

@stacksofplates So on your ansible server do you have a folder called playbooks and in that you have numerous different <something>.yml files each that do something?

It's up to personal preference. I store things in ~/Documents/projects/ansible. Then in that I have a playbooks directory and a roles directory. Playbooks has the playbooks I need which is a single git repo and then each role has it's own git repo under roles.

Your default ansible.cfg file is in /etc/ansible.cfg. It points you to /etc/ansible/hosts and /etc/ansible/roles I never use that. I always set an ansible.cfg in my playbooks directory. It overrides that and stores everything in that playbooks directory.

DustinB3403

@IRJ said in Using Ansible to Manage install and update Apple OSX DHCP clients:

As @stacksofplates mentioned, connect with SSH how you do now, and I would create a special account just for ansible via playbook once you authenticat

@IRJ said in Using Ansible to Manage install and update Apple OSX DHCP clients:

As @stacksofplates mentioned, connect with SSH how you do now, and I would create a special account just for ansible via playbook once you authenticat

OKay that that would just be over ssh as our administrative user

IRJ

@stacksofplates said in Using Ansible to Manage install and update Apple OSX DHCP clients:

@DustinB3403 said in Using Ansible to Manage install and update Apple OSX DHCP clients:

So going out on the wild assumption that I wasn't on my couch right now, how would ansible find my clients?

No credentials have been set anywhere - how do I add my clients?

So how you use credentials depends on how you have them set up on your systems. If you have a user that can access all of them, then you can use that user. If you don't, you'll have to call separate plays for the different systems.

If you running an ansible ad-hoc command you can do:
ansible -i <path to inventory> group-name -m setup -u <username> 
SSH keys are preferable, but if you don't have them you can pass a -k to ask for the SSH password. -K is the sudo password flag and goes along with -b for become (meaning become another user).

To run a playbook, just have your user defined like I showed in the other thread and become as true if you need it.

@DustinB3403 this is what I am talking about. Use your SSH root user to run the user creation playbook.

DustinB3403

@IRJ said in Using Ansible to Manage install and update Apple OSX DHCP clients:

@stacksofplates said in Using Ansible to Manage install and update Apple OSX DHCP clients:
@DustinB3403 said in Using Ansible to Manage install and update Apple OSX DHCP clients:

So going out on the wild assumption that I wasn't on my couch right now, how would ansible find my clients?

No credentials have been set anywhere - how do I add my clients?

So how you use credentials depends on how you have them set up on your systems. If you have a user that can access all of them, then you can use that user. If you don't, you'll have to call separate plays for the different systems.

If you running an ansible ad-hoc command you can do:
ansible -i <path to inventory> group-name -m setup -u <username> 
SSH keys are preferable, but if you don't have them you can pass a -k to ask for the SSH password. -K is the sudo password flag and goes along with -b for become (meaning become another user).

To run a playbook, just have your user defined like I showed in the other thread and become as true if you need it.
@DustinB3403 this is what I am talking about. Use your SSH root user to run the user creation playbook.

So my inventory file is currently in (I assume) is /etc/ansible/hosts right?

Also I don't think that is how you create users on OSX cli (have to confirm)

stacksofplates

So here's my tree view for that directory

ansible
   ├── playbooks
      ├── ansible.cfg
      ├── apache.yml
      ├── group_vars
      ├── inventory
      ├── Makefile
      └── roles
        ├── apache
        ├── firewalld
        ├── grafana
        ├── nginx
        ├── node-exporter
        └── prometheus

DustinB3403

@stacksofplates said in Using Ansible to Manage install and update Apple OSX DHCP clients:

So here's my tree view for that directory

ansible
   ├── playbooks
      ├── group_vars
      ├── inventory
      └── roles
   └── roles
        ├── apache
        ├── firewalld
        ├── grafana
        ├── nginx
        ├── node-exporter
        └── prometheus

I assume this actually looks like

etc
└──ansible
	├── playbooks
	├── group_var
	├── inventory
	└── roles
└── roles
	├── apache
	├── firewalld
	├── grafana
	├── nginx
	├── node-exporter
	└── prometheus

stacksofplates

@DustinB3403 said in Using Ansible to Manage install and update Apple OSX DHCP clients:

@stacksofplates said in Using Ansible to Manage install and update Apple OSX DHCP clients:
So here's my tree view for that directory
ansible
   ├── playbooks
      ├── group_vars
      ├── inventory
      └── roles
   └── roles
        ├── apache
        ├── firewalld
        ├── grafana
        ├── nginx
        ├── node-exporter
        └── prometheus
I assume this actually looks like

etc
└──ansible
├── playbooks
├── group_var
├── inventory
└── roles
└── roles
├── apache
├── firewalld
├── grafana
├── nginx
├── node-exporter
└── prometheus

No it's under ~/Documents/projects/ansible like I mentioned above.

DustinB3403

To ask, can I add hosts by hostname to the host file rather than by IP address. Being these systems are portable, their IP can change at a moments notice and would cause all kinds of SSH complaints like WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!

IRJ

@DustinB3403 said in Using Ansible to Manage install and update Apple OSX DHCP clients:

To ask, can I add hosts by hostname to the host file rather than by IP address. Being these systems are portable, their IP can change at a moments notice and would cause all kinds of SSH complaints like WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!

yes. That was one of the first things I recommended

stacksofplates

@DustinB3403 said in Using Ansible to Manage install and update Apple OSX DHCP clients:

To ask, can I add hosts by hostname to the host file rather than by IP address. Being these systems are portable, their IP can change at a moments notice and would cause all kinds of SSH complaints like WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!

Yeah that's why I said you can either use FQDN or IP address and why I also mentioned disabling host key checking for Ansible. There are times not to disable it but shouldn't matter in this case.

Obsolesce

So you are going to have SSH open on everything while allowing root and/or password login?

TF?

DustinB3403

@Obsolesce said in Using Ansible to Manage install and update Apple OSX DHCP clients:

So you are going to have SSH open on everything while allowing root and/or password login?

TF?

SSH is open on Mac OSX by default already, nothing I'm doing is opening that.

~~I'm looking to setup SSH keys also~~I've already setup SSH keys, so I'm not sending passwords.

This is also still very early stage testing and things can be changed/improved well before deployment.