Ansible 2.4.2.0 on CentOS 7--ping module isn't working

scottalanmiller

@stacksofplates said in Ansible 2.4.2.0 on CentOS 7--ping module isn't working:

@scottalanmiller said in Ansible 2.4.2.0 on CentOS 7--ping module isn't working:

@stacksofplates said in Ansible 2.4.2.0 on CentOS 7--ping module isn't working:

Also 2.4.2 is kind of old. Some things are being deprecated soon, so you will want to either install from EPEL or use pip to pull in a newer version.

Another "CentOS problem" that "doesn't exist"

Well it's weird. Idk if CentOS hasn't caught up with RHEL yet. Ansible is at 2.7 in RHEL. I have no idea why it's lagging so far behind in CentOS.

oh, weird.

stacksofplates

@scottalanmiller said in Ansible 2.4.2.0 on CentOS 7--ping module isn't working:

@stacksofplates said in Ansible 2.4.2.0 on CentOS 7--ping module isn't working:

@scottalanmiller said in Ansible 2.4.2.0 on CentOS 7--ping module isn't working:

@stacksofplates said in Ansible 2.4.2.0 on CentOS 7--ping module isn't working:

Also 2.4.2 is kind of old. Some things are being deprecated soon, so you will want to either install from EPEL or use pip to pull in a newer version.

Another "CentOS problem" that "doesn't exist"

Well it's weird. Idk if CentOS hasn't caught up with RHEL yet. Ansible is at 2.7 in RHEL. I have no idea why it's lagging so far behind in CentOS.

oh, weird.

But even Fedora lags behind a little. It's getting better but I've seen it as far as 2 releases behind before.

wirestyle22

@matteo-nunziati said in Ansible 2.4.2.0 on CentOS 7--ping module isn't working:

@wirestyle22 said in Ansible 2.4.2.0 on CentOS 7--ping module isn't working:

@black3dynamite That looks so weird to me

shouldn't the host be ansible_host=hostname ? Did they change that?

Please post your inventory well formatted as code. It should contain a list of targets and should be passed to ansible with the -i flag. Also check the docs: https://docs.ansible.com/ansible/latest/user_guide/intro_inventory.html

This is a basic ping check with a basic inventory file. Originally it was this but I have removed the ssh password portion.

ansible-target1 ansible_host=192.168.1.208 ansible_ssh_pass=password
ansible-target2 ansible_host=192.168.1.209 ansible_ssh_pass=password

wirestyle22

@stacksofplates said in Ansible 2.4.2.0 on CentOS 7--ping module isn't working:

Dont' pass ansible_host= in the command line. That's defined in your inventory file. You also don't need to add that in your inventory file at all since you've defined it in your /etc/hosts file. I never add the password in the inventory. If I don't have a key on the other end I just pass -k in the command. So you would do this:
ansible -i inventory ansible-target1 -m ping -k
Also make sure every host is on a separate line in your inventory. I noticed you only did > instead of >>. You could have only put one host in, but figured I'd mention it just in case.

God you're handsome.

Time to screw around with YAML.

Obsolesce

Or in Salt:

salt pcname test.ping

stacksofplates

@Obsolesce said in Ansible 2.4.2.0 on CentOS 7--ping module isn't working:

Or in Salt:

salt pcname test.ping

It's much simpler if you have your ansible.cfg and keys set up. Then it's just ansible server -m ping.

This is like trying to use Salt without having certs set up (or SSH keys in the case of salt-ssh)

Obsolesce

@stacksofplates said in Ansible 2.4.2.0 on CentOS 7--ping module isn't working:

@Obsolesce said in Ansible 2.4.2.0 on CentOS 7--ping module isn't working:

Or in Salt:

salt pcname test.ping

It's much simpler if you have your ansible.cfg and keys set up. Then it's just ansible server -m ping.

This is like trying to use Salt without having certs set up (or SSH keys in the case of salt-ssh)

If you want to use ssh as a transport, but not needed or why you'd choose Salt. If that's the case then I'd rather want to use Ansible.

stacksofplates

@Obsolesce said in Ansible 2.4.2.0 on CentOS 7--ping module isn't working:

@stacksofplates said in Ansible 2.4.2.0 on CentOS 7--ping module isn't working:

@Obsolesce said in Ansible 2.4.2.0 on CentOS 7--ping module isn't working:

Or in Salt:

salt pcname test.ping

It's much simpler if you have your ansible.cfg and keys set up. Then it's just ansible server -m ping.

This is like trying to use Salt without having certs set up (or SSH keys in the case of salt-ssh)

If you want to use ssh as a transport, but not needed or why you'd choose Salt. If that's the case then I'd rather want to use Ansible.

I want saying you should. Just once things are set up properly they are both (Ansible and Salt) very similar in ease of use.

matteo nunziati

@stacksofplates said in Ansible 2.4.2.0 on CentOS 7--ping module isn't working:

@scottalanmiller said in Ansible 2.4.2.0 on CentOS 7--ping module isn't working:

@stacksofplates said in Ansible 2.4.2.0 on CentOS 7--ping module isn't working:

@scottalanmiller said in Ansible 2.4.2.0 on CentOS 7--ping module isn't working:

@stacksofplates said in Ansible 2.4.2.0 on CentOS 7--ping module isn't working:

Also 2.4.2 is kind of old. Some things are being deprecated soon, so you will want to either install from EPEL or use pip to pull in a newer version.

Another "CentOS problem" that "doesn't exist"

Well it's weird. Idk if CentOS hasn't caught up with RHEL yet. Ansible is at 2.7 in RHEL. I have no idea why it's lagging so far behind in CentOS.

oh, weird.

But even Fedora lags behind a little. It's getting better but I've seen it as far as 2 releases behind before.

I always download it from upstream

wirestyle22

@stacksofplates How are you organizing? I have playbooks and inventory together in the same directory right now. Seems bad. Also, are you using an IDE?

wirestyle22

Another way to do this ping test:

pingtest.yml

-
  name: Test connectivity to target servers
  hosts: all
  tasks:
   - name: Ping test
     ping:

black3dynamite

@wirestyle22 said in Ansible 2.4.2.0 on CentOS 7--ping module isn't working:

@stacksofplates How are you organizing? I have playbooks and inventory together in the same directory right now. Seems bad. Also, are you using an IDE?

Here are some best practices for directory layouts.

https://docs.ansible.com/ansible/latest/user_guide/playbooks_best_practices.html#directory-layout

https://docs.ansible.com/ansible/latest/user_guide/playbooks_best_practices.html#alternative-directory-layout

stacksofplates

@wirestyle22 said in Ansible 2.4.2.0 on CentOS 7--ping module isn't working:

@stacksofplates How are you organizing? I have playbooks and inventory together in the same directory right now. Seems bad. Also, are you using an IDE?

I'll give you a layout this afternoon. I keep my inventory with my playbooks but roles have their own repositories.

stacksofplates

@wirestyle22 said in Ansible 2.4.2.0 on CentOS 7--ping module isn't working:

@stacksofplates How are you organizing? I have playbooks and inventory together in the same directory right now. Seems bad. Also, are you using an IDE?

So I have my playbooks set up like this (for stuff at home). I've seen people put playbooks in a directory which is fine as well. It's just annoying because your ansible.cfg has to be in relation to your playbooks so you had to mess around with softlinks to get it to work that way.

Roles (ones I've written) are in their own directory:

Here's my default ansible.cfg which I store with the playbooks:

[defaults]
inventory           = inventory
roles_path          = roles
retry_files_enabled = False
pipelining          = True
library             = library
forks               = 50
callback_whitelist = profile_roles

And then in the inventory directory I have a prod and dev file that contain all of the groups and hosts.

Also, are you using an IDE?

I switch between VS Code and Vim. However I always turn on Vim mode in anything. I also have things like jj mapped to Esc and AA mapped to drop me to the end of a line in insert mode to make things easier.

stacksofplates

So to clarify, playbooks is it's own private repository. Then the roles are public repos. In the roles directory in the playbooks repo I have a single file called requirements.yml. This tells Ansible what roles to install for me before it runs.

It contains entries like this:

- src: https://gitlab.com/hooksie1/ansible-firewalld.git
  name: firewalld
  scm: git
  version: master

I've been using Jenkins to run my Ansible stuff so I have a build step that runs ansible-galaxy install -r roles/requirements.yml before it runs the playbook. That installs all of the roles for you. As a side note, if you're using Tower it will download the roles automatically if it sees that file exists.

Here's the build steps in Jenkins:

I also have started including a Makefile to do the same thing. That way you can just run make clean and make roles to remove and re-download them.

black3dynamite

@stacksofplates
That’s awesome.

wirestyle22

@stacksofplates I know this is a huge question, but what specifically are you doing in ansible right now that make it worthwhile? I can think of a lot of things to do with it but idk everything. Would be nice to hear it from someone who has used it over a long time.

Also, what modules are you using in VS Code?

stacksofplates

@wirestyle22 said in Ansible 2.4.2.0 on CentOS 7--ping module isn't working:

@stacksofplates I know this is a huge question, but what specifically are you doing in ansible right now that make it worthwhile? I can think of a lot of things to do with it but idk everything. Would be nice to hear it from someone who has used it over a long time.

Also, what modules are you using in VS Code?

So I'll answer for my last job since I'm still getting things set up at this one. We literally did everything with it. I mean there were still some things we had to do separately, but 99% of what we did was done with Ansible. You can build in health checks so that Ansible will either rebuild on a failure or like in this example let you know if a build actually fails even though it looks like it passed:

---
- name: Set up grafana
  hosts: monitoring
  gather_facts: true
  user: centos
  become: true

  roles:
    - grafana

  post_tasks:
    - name: wait for Grafana
      wait_for:
        host: "{{ ansible_default_ipv4.address }}"
        port: 3000
        state: present
        delay: 2
        timeout: 300

    - name: check if Grafana is up
      uri:
        url: "http://{{ ansible_default_ipv4.address }}:3000/login"
        return_content: yes
      register: webpage
      delegate_to: localhost
      retries: 30
      delay: 1
      become: false

    - name: Fail if page isn't up
      fail:
      when: "'Grafana' not in webpage.content"

This installs Grafana and then checks to see if the web page is actually available after the install is completed and the service is started.

One of the cool things you can do with tools like Tower or Jenkins is set up specific jobs for L1 and L2 people (and yourself as well). So say you need a service restarted on a system. You can set up a job where the help desk can restart a service on a system/systems without manually logging in to them. Here's an example:

You can do this from the command line, but this is a little more friendly and easier to manage RBAC.

As for VS Code I have a few go to extensions. Ansible (the one from Microsoft, it's really good), AsciiDoc, Go (Microsoft one), Jinja, Markdown, Terraform, Vagrant. Those are the ones I install all of the time.

stacksofplates

And with Jenkins you can do more advanced things like storing your jobs in Groovy. That way your build jobs are also stored in code. Like this one for example (you need the Ansible plugin installed in Jenkins for this to work):

pipeline {
    agent any
    
    parameters {
        string(description: 'Limit', name: 'Limit')
    }
    
    stages {
        stage('Clone Repo') {
            steps {
                git credentialsId: '766f3db4-319d-4f5b-bbd8-9fe7ba7ce5b4', 
                url: 'https://your-git-repo.com/reponame
            }
        }
        stage('Set up roles') {
            steps {
                sh 'find roles/* ! -name requirements.yml -prune -exec rm -rf {} \\;'
                sh 'ansible-galaxy install -r roles/requirements.yml'
            }
        }
        stage('Run playbook') {
            steps {
                ansiblePlaybook(
                    playbook: 'hardening.yml',
                    inventory: 'inventory',
                    credentialsId: 'c0924012-4666-47ff-98d7-40215742e9f4',
                    become: true,
                    becomeUser: 'root',
                    disableHostKeyChecking: true,
                    limit: params.Limit)
            }
        }
    }
}

Now that this is stored in Git, you can set up hooks to tell Jenkins that any time you update your playbook (hardening.yml in this case) that it should automatically kick off a run to whatever hosts are defined for your job. You never have to click or run anything manually, it will just do it in your CI/CD pipeline.

wirestyle22

@stacksofplates That's pretty incredible. Any advice on things I should attempt to set up right now for learning purposes?