Ansible Archives - Page 2 of 2 - The Blog of Nitin J Mutkawoa, AKA @TheTunnelix

Tag: Ansible

CVE-2015-7547 – Update Glibc & restart BIND with Ansible

02/21/2016 Nitin J Mutkawoa Add Comment

You might be seeing a huge crowd of system administrators and Devops rushing to update their servers immediately due to the security flaws detected on Glibc. This security leak is identified as skeleton key under CVE-2015-7547: glibc getaddrinfo stack-based buffer overflow. What is most sour to taste is where the Glibc library is used in the BIND application!

In brief, the CVE-2015-7547 vulnerability is simply where an attacker can performed mutilple stack-based overflows of the function send_dg and send_vc in the Glibc library to execute malicious code even causing denial of service attack.

Redhat have put it in this way “A back of the envelope analysis shows that it should be possible to write correctly formed DNS responses with attacker controlled payloads that will penetrate a DNS cache hierarchy and therefore allow attackers to exploit machines behind such caches.” I have try a little Ansible cookbook to update your Glibc package. Check it out on my Git Account

- - - 
  - hosts: ansible2
     user: root
     tasks:
       - name: update Glib
          yum: name=glibc* state=latest
       - name: restart named
          service: name=named state=restarted

Other articles on Buffer Overflow of Memory:

Some funs with Ansible playbooks

02/20/2016 Nitin J Mutkawoa Add Comment

As we have seen last time, Ansible is really cool especially for automation. In the blog post Getting started with Ansible i have share the following points:

Basic deployment of Ansible on 2 virtual machines
Dependencies that are usually needed
Setting up the SSH key
Some basic commands like ping, copy, transfer etc..
Errors that may be encountered due to dependency and SELINUX

Lets see how to delete a specific file

ansible ansible2 -m file -a 'path=/tmp/hackers.log state=absent'

However, you easily grasp all those modules names to delete, add etc.. with the ansible-doc -l command. If you want a more detailed information, say for example the copy module which i have used in the last Ansible blog post, we can just use the ansible-doc copy command. Cool isn’t it?

I will now lay some more emphasis on Ansible Playbooks. Playbooks are Ansible’s configuration, deployment, and orchestration language. They can describe a policy you want your remote systems to enforce, or a set of steps in a general IT process. – Ansible. Compared to Puppet there are odules and in Chef, we have Cookbooks, same thing apply for Ansible where we have a Playbook. These playbooks are written in YAML, which is human friendly data serialization standards for all programming languages. Playbooks are divided into three sections, that is Target ,Variable and Tasks sections :

Target section (similar to nodes.pp in Puppet and run-list in Chef), The target section simply defines in which host playbooks will be executed.
Variable section – This will comprise of all variables which can be used in the Playbooks
Tasks section – This is a list of all the modules that is going to run and in which particular order.

Before getting further deep into Ansible Playbooks, its very important to know that indentation and spacing are very important. So, get into /etc/ansible and create a .yml file there. I created a file1.yml as follows:

- - -
   -  hosts: ansible2 
       user: root
       vars: 
        motd_welcome: 'Welcome to hackers Mauritius'
       tasks:
       - name: sample motd
       copy:
        dest: /etc/motd
        content: "{{ motd_welcome }}"

Explanation of the file1.yml

The hosts in the file1.yml means in which target the task is going to be applied.
The user is pretty straight forward denoting with which user same is going to be executed
Vars here is where the variable section
motd_welcome is a variable defined under the vars section having the value ‘Welcome to hackers Mauritius’
tasks is where the task section starts
copy is the task that you want to do
dest is the destination where you want to copy
content is “{{ motd_welcome }}” which is reference in the vars section.

Execute this file with the command ansible-playbook test1.yml

The MOTD is now created on the ansible2 machine 🙂

If there were a syntax error, you might have encountered errors as such where the motd_welcome variables is wrongly set up.

Let’s take another example by creating a playbook for installing htop by creating test2.yml

- - -
   - hosts: ansible2
      user: root
      tasks:
       - name: copy repo files
          copy: src=files/epel.repo dest=/etc/yum.repos.d/epel.repo
       - name: installing htop
          action: yum name=htop state=installed

So, we can clearly see that the actions will be carried out on the ansible2 server with user root for the task to copy the file epel.repo to the repo of ansible2 following which the installation of htop will be carried out. I have also created a directory in /etc/ansible/files and a file called epel.repo which have the necessary configurations.

Another interesting stuff is that with Ansible, you have the flexibility of setting up several actions and at the time you are executing the .yml file you can for example use the command ansible-playbook -v test2.yml — step which will prompt you each time for a yes/no answer.

Linux Application, Linux System Ansible, Automation

Getting started with Ansible Deployment

02/20/2016 Nitin J Mutkawoa Add Comment

Ansible is on open source IT orchestration engine that manages on-premise and in the cloud remote devices in a coordinated fashion. These are servers, networking hardware, and storage devices. Ansible can be used to talk to typical load balances, firewalls switches or any Linux machines. Continuous deployment in any environment is important as to whether the tools are predictable. Undefined behavior should be taken into consideration. Ansible is a human-readable playbook format. There is a minimum jargon in the system.

How Ansible is different compared to Puppet and Chef?

Compared to Puppet or Chef which need to have an agent installed on remote machines and the controller on the main server, but, with Ansible, you do not need to install anything on the remote machine as it relies on SSH connection and a simple push mechanism. On the other side, Puppet and Chef would use a Pull mechanism.

Let’s deploy Ansible

You would normally find lots of pretty documentation on the official website. If you want to adventure a bit around Ansible here are some tips to get started on a Centos 6 machine. I have created 2 machines called ansible1 and ansible2. Each can ping each other and Port 22 – SSH is listening. There are several dependencies needed to install Ansible. I would advise you to edit the /etc/hosts file and point the IP on the hostname if you do not have any DNS.

On ansible1, simply enable the epel repo and do a yum install ansible. However, you can also compile from source. Different Python version would be required. Those are usually the packages needed:

PyYAML 
 libyaml 
 python-babel
 python-crypto
 python-crypto2.6 
 python-httplib2 
 python-jinja2 
 python-keyczar noarch
 python-paramiko noarch
 python-pyasn1 noarch 
 python-simplejson i686
 sshpass

Once Ansible is installed on the machine ansible1, even if more machines are connected on the same network, you would not need to install it anything. To make ansible2 part of the ansible1 network, an inventory file need to be configured. This is located at /etc/ansible/hosts

Add the following block in the /etc/ansible/hosts file

[myservers]
ansible1
ansible2

Try testing a ping

After adding the block as mentioned above, you carry out a simple test to check for ping via the ansible command.

ansible ansible2 -m ping -u root -k

Here is the result.

You might want to set up root password. This can be set up with the command :

ansible ansible2 -m setup -u root -k

Setting up your SSH Key

However, you might want to set up Ansible with a ssh key.

On ansible1, simply create a key with the command ssh-keygen and/or if already got your key send it to the ansible2 using the following commands ssh-copy-id -i ansible2. Also repeat same steps on ansible2 by sending your key to ansible1. The file located at ~/.ssh/authorized_keys would contain the keys. As from here you simply run any command without being prompt each time to enter password.

More funs with commands

Let’s say we want to have an information about the /etc/passwd file from the ansible2 server. We simply need to fire this command

ansible ansible2 -m file -a 'path=/etc/passwd'

I can also create a directory with Ansible in any directory i want and even setup the user and group permission. For example to create a directory in the /tmp.

ansible ansible2 -m file -a 'path=/tmp/hackers_mauritius state=directory mode=777 owner=root'

Errors that can be encountered

However, its very important you test your command before setting it up on production environment. Errors can also be encountered if dependencies packages are not installed. For example let’s send a file from ansible1 to ansible2. The command is

ansible ansible2 -m copy -a 'src=/root/hackers.log dest=/tmp'

You might noticed that SELINUX can be disabled or simply set the parameter in the /etc/selinux/config. I have disabled selinux and rebooted the machine. Here is the output

Linux Application, Linux System Ansible, Automation, centos, Python