Tag Archives | Red Hat Enterprise Linux

Ansible tutorial * Automate your systems

In a previous tutorial, we talked about expect command and we saw how to automate scripts in Linux using its scripting language. Today, we will take a step further in our automation techniques and talk about a tool that automates tasks more professionally and for different platforms, this tool is Ansible. We will also talk about some Ansible features such as playbook, inventory, vault, role, and container. Ansible is an open source IT tool provided by Red-Hat Enterprise Linux (RHEL) that helps in configuration management, orchestration service, task and application deployment automation.

Continue Reading →

What is Ansible?

Ansible is an open source IT tool provided by Red-Hat Enterprise Linux (RHEL) that helps in configuration management, orchestration service, task and application deployment automation.

This tool is aimed to help system administrators who are seeking to minimize recurring tasks, seamless deployment, and easy automation.

Similar tools to Ansible are Puppet, SaltStack, and Chef which are the main configuration management tools available on the market.

Each one of these tools has its own advantages and disadvantages, so choosing the right one can be a bit challenging, depending on which features are needed or which programming language is preferred.

From the advantages of Ansible compared to other tools, Ansible is sort of a new tool that is built on Python and uses YAML templates for scripting its jobs.

YAML stands for “YAML Ain’t Markup Language” that is a very easy human-readable language. This helps new users to understand it easily.

Another advantage is to use Ansible there is no need to install an agent in the hosts which enhances the communication speed as it is using both push and pull models to send commands to its Linux nodes and for Windows nodes, the WinRM protocol is used.

As we stated above since it’s a new tool from its disadvantages is that it has a poor GUI, un-customized and immature platform when compared to other tools.

Even though Ansible considered to be used more frequently than ever and there is an increase in downloading it.

Ansible setup on Ubuntu

As we previously mentioned that it’s no need to install an agent in the hosts which is unlike other tools. For Ansible it’s a master node installation only which lacks background process, database dependency, and always running service and that makes it extremely light.

It is recommended to use the default package manager for Ubuntu while installing Ansible which will help to install the latest stable version.

Before starting the installation process and for the Linux package installation, you have to make sure that Python 2 (version 2.6 or later) or Python 3 (version 3.5 or later) is installed.

Even though that most of Linux OS package managers when asked to download Ansible will download the best Python version and its dependencies automatically.

And for the source installation, the development suite may be needed like the build-essential package for Ubuntu.

We can install Ansible on Ubuntu using one of the following two methods:

The first method through the Ubuntu package manager

First, add Ansible PPA for Ubuntu using the following command:

sudo apt-add-repository ppa:ansible/ansible

Second, press Enter to confirm the key server setup. Third, update the package manager using the following command:

sudo apt update

Fourth, Ansible is ready to be installed using the next command:

sudo apt install ansible

The second method of installing Ansible is from its source:

This method is sometimes helpful for users who need some particular requirements like for example you need to install the beta or development version of Ansible even if this may grant you early access to new features and future modules but also you need to be careful it is an unstable version that is still under development and testing. Also, this method is helpful if you don’t need to install Ansible through the package manager. So, to get the Ansible source package you can use one of the following techniques. First through downloading the .tar file: Download the .tar file

wget -c https://releases.ansible.com/ansible/ansible-2.6.0rc3.tar.gz

Unarchive it

tar -xzvf ./ansible-2.6.0rc3.tar.gz

Second through the GitHub source: But we will need to install first the git command

sudo apt install -y git

Then get Ansible

git clone https://github.com/ansible/ansible.git --recursive

After downloading the Ansible source by using one of the previous techniques we will start building Ansible but as we previously mentioned that we will need to install Python. So, we can use the following commands to install Python to make sure that Ansible requirements are met: Go to Ansible Source directory

cd ./ansible*

Install Python using easy_install

sudo easy_install pip

Install Python requirements

sudo pip install -r ./requirements.txt

Setup the environment in order to use Ansible

source ./hacking/env-setup

If you are using GitHub Source you can update the Ansible project and its submodules as following:

git pull --rebase
git submodule update --init --recursive

For every time you execute the previous step you will need to be sure that the environment is already set up properly through the next two commands:

echo "export ANSIBLE_HOSTS=/etc/ansible/hosts" >> ~/.bashrc
echo "source ~/ansible/hacking/env-setup" >> ~/.bashrc

Finally, the Ansible inventory can be usually found in /etc/ansible/hosts and its configuration file is usually found in /etc/ansible/ansible.cfg

Ansible master node configuration

Usually the Ansible configuration file (ansible.cfg) is located in /etc/ansible/ansible.cfg or in the home directory which belongs to the user who installed Ansible.

As soon as you have installed Ansible you can start using it with its default configuration. Next, we will be discussing the most important and useful Ansible configurations that will improve your Ansible work experience.

Starting from Ansible 2.4 and later “ansible-config” is a command that is used by Ansible users to list the enable Ansible options with their values.

Ansible configuration file is divided into several sections but in this article, we will only focus on [defaults] general section. So, Let’s have a look on this section basic parameters.

Using your favorite text editor (Gedit, vi, nano…) you can open the ansible.cfg configuration file:

sudo nano /etc/ansible/ansible.cfg

inventory: points out to the location of the inventory that Ansible uses to know the available hosts
inventory = /etc/ansible/hosts

roles_path: points out to the location where the Ansible playbook have to search for extra roles
roles_path = /etc/ansible/roles

log_path: points out to the location where Ansible log file is stored. Permission to write in this file should be given to Ansible user.
log_path = /var/log/ansible.log

retry_files_enabled: indicates the retry feature which allows Ansible to create a .retry file anytime a playbook fails. It’s recommended leaving this option disabled unless you really want it because if it is enabled it will create multiple files which will take space.
retry_files_enabled = False

host_keychecking: this parameter is used in constantly changing environments where old hosts machines are deleted and new hosts take their place. This parameter is usually used in a cloud or a virtualized environment.
host_key_checking = False

forks: Indicates the number of parallel tasks that can be executed to the client host. By default, its value is 5 and this to save system resources and network bandwidth but in case you have enough resources and a good bandwidth you can increase the number.
forks = 5

remote_port: contains the port number used by SSH on the hosts
remote_port = 22

nocolor: It gives you the ability to use different colors for Ansible playbook and tasks that shows errors and success.
nocolor = 0

Node Configuration for Linux client

OpenSSH-server is the only important and required a tool to be installed on the client node and by default, all new versions of Linux use SSH as the main remote access tool. So, you need to check the following points carefully:

  • SSH service is always up and running.
  • SSH port which is 22 by default should be allowed in the system’s firewall.

Node Configuration for Windows client

In order to make Ansible able to remotely manage Windows host the following applications should be installed on Windows nodes:

  • PowerShell version 3.0 or higher
  • .NET version 4.0

For missing requirements, there is an Ansible already made PowerShell script that can carry out this installation automatically you can find it in the following link https://github.com/jborean93/ansible-windows/blob/master/scripts/Upgrade-PowerShell.ps1

But before running the previous script you need to change the execution policy to be unrestricted by executing the following script and you need to run it with administrator privilege:

$link = "https://raw.githubusercontent.com/jborean93/ansible-windows/master/scripts/Upgrade-PowerShell.$script = "$env:temp\Upgrade-PowerShell.ps1"
$username = "Admin"

password = "secure_password"
(New-Object -TypeName System.Net.WebClient).DownloadFile($link, $script)
Set-ExecutionPolicy -ExecutionPolicy Unrestricted -Force
script -Version 5.1 -Username $username -Password $password -Verbose
Set-ExecutionPolicy -ExecutionPolicy Restricted -Force
$reg_winlogon_path = "HKLM:\Software\Microsoft\Windows NT\CurrentVersion\Winlogon"
Set-ItemProperty -Path $reg_winlogon_path -Name AutoAdminLogon -Value 0
Remove-ItemProperty -Path $reg_winlogon_path -Name DefaultUserName -ErrorAction SilentlyContinue
Remove-ItemProperty -Path $reg_winlogon_path -Name DefaultPassword -ErrorAction SilentlyContinue

After that run, the Ansible already made PowerShell script then run the execution policy script again to return it back to restricted.

Another important script that needs to be run to configure WinRM to make it up and running to listen to Ansible commands, this script is also Ansible already made and you can find it in the following link: https://github.com/ansible/ansible/blob/devel/examples/scripts/ConfigureRemotingForAnsible.ps1

Similarly, this script needed to be run under administrator privileges and execution policy to be unrestricted you can use the following piece of code:

$link = "https://raw.githubusercontent.com/ansible/ansible/devel/examples/scripts/ConfigureRemotingForAnsible.$script = "$env:temp\ConfigureRemotingForAnsible.ps1"

(New-Object -TypeName System.Net.WebClient).DownloadFile($link, $script)
powershell.exe -ExecutionPolicy ByPass -File $script

If no errors are thrown then this Ansible now should be able to manage this node.

YAML Basics

As we have previously mentioned that YAML is a human-friendly language that can be used to manage data. Next, we will talk about YAML basics and will show you how to write a code using YAML.

Guidelines to create a YAML file:

  • YAML uses spaces instead of tabs.
  • YAML is case sensitive
  • YAML file should be saved with the .yaml extension
  • YAML file sometimes starts with “—” and ends with “…” but it is optional.

Since YAML can be used to write Ansible playbooks so next we will show you how YAML is easy to use. So in the following example where we need to copy user configuration. If you are using an Ansible command it will look like that:

- name: Copy user configuration copy: src=/home/admin/setup.conf dest=/usr/local/projects/ owner=setup group=dev mode=0677 backup=yes

But in case you are using YAML it will be like this:
- name: Copy user configuration
copy:
src: /home/admin/setup.conf
dest: /usr/local/projects/
owner: setup
group: dev
mode: 0677
backup: yes

Another example is a .ini inventory file can be as following:
node0.lab.edu
[lab1servers]
node1.lab.edu
node2.lab.edu
[lab2servers]
node3.lab.edu

But in case you are using YAML it will look like this:
all:
hosts:
node0.lab.edu
children:
lab1servers:
hosts:
node1.lab.edu
node2.lab.edu
lab2server:
hosts:
node3.lab.edu

So from the previous two examples, you will find that YAML is easy to use, human-friendly, neat and good looking language.

Ansible Inventory

It is a .ini file that consists of records of IP addresses, hostnames of the host clients. It may also contain some other variables about the hosts.

In general, these file contents are organized in groups and each group has a name, this name is written between two square brackets like for example [Group1].

The location of Ansible inventory file is by default can be found in /etc/ansible/hosts. But it is recommended to put all the Ansible configuration files in a folder in the home directory of the user and this to allow the user to add and modify their configuration according to their needs. So, next is an example for opening the Ansible configuration file and setting the inventory:

sudo nano /etc/ansible/ansible.cfg
inventory = /home/user1/ansible/hosts

Also, you can choose an Ansible inventory file while executing a command by adding -i option to the command:
ansible -m ping -i ~/ansible/hosts

There are two Ansible inventory types static and dynamic. Static inventory can be used in small organizations which has small to medium infrastructure. While Dynamic inventory can be used in large organizations where there is a huge number of hosts, complicated tasks to be done and enormous errors may start to appear. If you are trying to add hosts with a similar style to Ansible inventory you use a counter block like the next example:

Inventory file with similar style hosts:
[servers]
node0.lec
node1.lec
node2.lec
node3.lec
node4.lec

Inventory using a counter block:
[servers]
Node[0:4].lec

Ansible Playbook

Ansible playbook simply is a systematic group of scripts which is using Ansible commands in a more organized method that can install and configure systems. Ansible playbook can perform the following tasks and delegate them to other servers:

  • Reorder multi-tier system roll-outs.
  • Applying application and systems patches.
  • Collecting data from client hosts and depending on the collected data it starts sending instant actions to servers, devices, and load balancers.

Ansible playbook is written in YAML which is a very simple human-readable language compared to other tradition coding languages. YAML also can allow users sharing their code in an easy way.

Ansible Roles

While converting Ansible playbooks into roles will give you the ability to change a set of configuration management tasks into reusable modules with multiple configurations which will be easily shared when needed.

Structure of Ansible role is very simple it consists of many folders each one of them consists of a lot of YAML files that by default have one main.yml file but they can have more than one file.

Ansible Vault

It is an Ansible encryption tool which allows users to encrypt various variables. This Ansible vault produces encrypted files to save variables those files can be moved to another location when needed.

Ansible vault can encrypt any different forms of data that are found in Ansible roles and playbooks. Also, it can encrypt task files in case you need to hide a variable name.

Ansible Container

It is an open source tool which allows users to automate everything about their containers from building to deployment to management. Ansible container allows better code management and implementing containers on any cloud registries.

By default, Ansible container is not installed from the beginning as a part of Ansible installation so you will need to set it up on a container host and during the installation process, you will need to choose a container engine to work on.

0

Open Build Service 2.10 duyuruldu

Open Build Service (ya da eski adıyla OpenSUSE Build Service), 2.10 sürümüne güncellendi. Open Build Service geliştiricileri, SUSE Linux Enterprise Server de dahil olmak üzere birçok GNU/Linux dağıtımı (OpenSUSE, Red Hat Enterprise Linux, Mageia, Ubuntu, Fedora, Debian ve Arch Linux…) için paketleme sürecini basitleştiren ve böylece pek çok dağıtım için bir programın daha kolay paketlenmesine olanak sağlayan yazılımın yeni sürümünü duyurmaktan mutlu olduklarını ifade etti. GPL lisansı altında yayınlanan Open Build Service; geniş bir işletim sistemi yelpazesi ve donanım mimarileri için tüm dağıtımların, araçların ve eklentilerin güncellenmesine de olanak sağlıyor. Open Build Service 2.10 hakkında ayrıntılı bilgi edinmek için sürüm duyurusunu ya da sürüm notlarını inceleyebilirsiniz.

Continue Reading →

Open Build Service 2.10 edinmek için aşağıdaki linklerden yararlanabilirsiniz.

0

RPM 4.15.0 ALPHA duyuruldu

Kısaca RPM olarak adlandırılan Red Hat Package Manager, güçlü paketleme aracının 4.15.0 sürümünün alpha versiyonu duyuruldu. Bunun bir test sürümü olduğunun unutulmaması ve yalnızca test etmek amacıyla kullanılması gerektiği hatırlatılırken, test eden kullanıcıların tespit ettikleri hataları rapor etmeleri rica ediliyor. Genel hata düzeltmeleri ve geliştirmelerle gelen yeni sürüme, GNU/Linux’ta (deneysel) dayanaksız chroot işlemleri için destek eklendiği bildiriliyor. ARM algılamanın geliştirildiği sürüme, armv8 desteği de eklenmiş bulunuyor ve aarch64 ve arm64 arasında mimari uyumluluk eşlemesi eklenmiş. Ayrıca belge güncellemeleri yapıldığı ifade ediliyor. Başta Red Hat Enterprise Linux olmak üzere, Fedora, openSUSE, SUSE Linux Enterprise, Meego, Mageia ve diğer GNU/Linux dağıtımlarında kullanılan RPM ile yazılım kurma ya da kaldırma, sistemi güncelleme, çekirdeği derleme gibi işlemleri uçbirim üzerinden gerçekleştirmek mümkündür. RPM ile Red Hat, Fedora, Mageia gibi dağıtımlarda program indirme, kurma, güncelleme ve kaldırma işlemleri ile sistem genelinde yükseltme işlemleri yapılabilir. RPM paketleri genellikle platformlara göre hazırlanmış paketlerdir. Bir GNU/Linux dağıtımı için hazırlanmış bir RPM paketi, diğer bir GNU/Linux dağıtımına kurulamayacak ya da kurulsa bile hatalı kurulacaktır. Bu nedenle RPM paketlerinin isimlerinin yanında açıklayıcı ekler bulunur. Sözgelimi; i386: 386,486 ve daha yukarısı işlemciler için, i586: Pentium I ve daha yukarısı işlemciler için, i686: Pentium II ve daha yukarısı işlemciler için, ia64: 64 bit işlemci mimarisine uygun işlemciler için, noarch: Herhangi bir işlemci mimarisine bağlı kalınmadan kurulabilen paketler demektir. RPM 4.15.0 ALPHA hakkında daha geniş bilgi edinmek için sürüm notlarını inceleyebilirsiniz.

Continue Reading →

YUM ( Yellowdog Updater Modifier )
YUM, basitçe RPM paket yönetim sistemi olarak tanımlanabilir. Fedora ve benzeri sistemlerde, gerekli olan paketleri yüklemek, kaldırmak ve güncellemek amacıyla Yum kullanılabilir. Yum’u kullanmaya başlamadan önce birkaç yapılandırma işlemine tabi tutulması ve programın güncellenmesi gerekir. Mesela, paket yüklemek için yum install paket_adı komutu kullanılabilir.

Sisteme bir paket kurulmadan önce, paketin kurulu olup olmadığı kontrol edilebilir. Bunun için şöyle bir komut vermek gerekir:

rpm -qa |grep paket_adı

ya da

rpm -q paket_adı

Sözgelimi, kurmak istediğimiz paketin postfix olduğunu varsayalım. O vakit komutumuz şöyle olacaktır:

rpm -qa |grep postfix

ya da

rpm -q postfix

Postfix’in kurulu olmadığını öğrendik, şu halde kurulum için mesela şöyle bir komut vermemiz gerekiyor:

rpm -ivh postfix-2.2.2-2.i386.rpm

4.14.90 no’lu RPM 4.15.0 ALPHA edinmek için aşağıdaki linkten yararlanabilirsiniz.

0

Scientific Linux 7.6 duyuruldu

İkinci sürüm adayı 27 Kasım 2018‘de duyurulan Fermi National Accelerator Laboratory ve European Organization for Nuclear Research (CERN) tarafından ortaklaşa geliştirilerek Red Hat Enterprise Linux’tan yeniden derlenen Scientific Linux‘un, akademik ve bilimsel  ortamlarda kullanılmak üzere ekstra bilimsel uygulamalarla geliştirilen 7.6 sürümünün finali, Pat Riehecky tarafından duyuruldu. Bazı güncellemelerle gelen yeni sürümde, Cinnamon masaüstü kullanıcılarını etkileyen bilinen bir sorun bildiriliyor. Scientific Linux 7.x kullanıcıları şu an için ‘yum clean expire-cache’ komutunu çalıştırmalarının önemli olduğu vurgulanıyor. Kullanıcıların, küçük sürüm yükseltmelerinin bildirilmesi için desteğe sahip olan yeni sürüme terfi etmeleri öneriliyor. Scientific Linux 7.6 hakkında ayrıntılı bilgi edinmek üzere sürüm duyurusu ve sürüm notları incelenebilir.

Continue Reading →

Scientific Linux 7.6 edinmek için aşağıdaki linklerden yararlanabilirsiniz.

0

Scientific Linux 7.6 RC 2 duyuruldu

İlk sürüm adayı 15 Kasım 2018’de duyurulan Fermi National Accelerator Laboratory ve European Organization for Nuclear Research (CERN) tarafından ortaklaşa geliştirilerek Red Hat Enterprise Linux’tan yeniden derlenen Scientific Linux‘un, akademik ve bilimsel  ortamlarda kullanılmak üzere ekstra bilimsel uygulamalarla geliştirilen 7.6 sürümünün ikinci sürüm adayı, Pat Riehecky tarafından duyuruldu. Bunun bir test sürümü olduğunun unutulmaması ve yalnızca test etmek amacıyla kullanılması gerektiği hatırlatılırken, test eden kullanıcıların tespit ettikleri hataları rapor etmeleri rica ediliyor. Riehecky; final sürümün 3 Aralık 2018’de yayınlanmassının planlandığını hatırlattı. Çeşitli hata düzeltmeleriyle gelen sürüm, Xorg düzeltmesi de içeriyor. Scientific Linux 7.6 RC 2 hakkında ayrıntılı bilgi edinmek üzere sürüm duyurusu ve sürüm notları incelenebilir.

Continue Reading →

Scientific Linux 7.6 RC 2 edinmek için aşağıdaki linklerden yararlanabilirsiniz.

0

Scientific Linux 7.6-rc çıktı

Fermi National Accelerator Laboratory ve European Organization for Nuclear Research (CERN) tarafından ortaklaşa geliştirilerek Red Hat Enterprise Linux’tan yeniden derlenen Scientific Linux‘un, akademik ve bilimsel  ortamlarda kullanılmak üzere ekstra bilimsel uygulamalarla geliştirilen 7.6 sürümünün sürüm adayı çıktı. Henüz resmi duyurusu yapılmamış olan sürüme ait paketler, indirilmek üzere yansılarda yerini aldı. Scientific Linux 7.6 ayrıntılı bilgi edinmek üzere sürüm notları incelenebilir.

Continue Reading →

Scientific Linux 7.6-rc edinmek için aşağıdaki linklerden yararlanabilirsiniz.

0

RPM 4.14.2.1 duyuruldu

Kısaca RPM olarak adlandırılan Red Hat Package Manager, güçlü paketleme aracının 4.14.2.1 sürümü duyuruldu. Yeni sürüm hakkında daha geniş bilgi edinmek için sürüm notlarını inceleyebilirsiniz. Genel hata düzeltmeleri ve çeşitli geliştirmelerle gelen yeni sürümde, dokümantasyonlar da güncellenmiş bulunuyor. Başta Red Hat Enterprise Linux olmak üzere, Fedora, openSUSE, SUSE Linux Enterprise, Meego, Mageia ve diğer GNU/Linux dağıtımlarında kullanılan RPM ile yazılım kurma ya da kaldırma, sistemi güncelleme, çekirdeği derleme gibi işlemleri uçbirim üzerinden gerçekleştirmek mümkündür. RPM ile Red Hat, Fedora, Mageia gibi dağıtımlarda program indirme, kurma, güncelleme ve kaldırma işlemleri ile sistem genelinde yükseltme işlemleri yapılabilir. RPM paketleri genellikle platformlara göre hazırlanmış paketlerdir. Bir GNU/Linux dağıtımı için hazırlanmış bir RPM paketi, diğer bir GNU/Linux dağıtımına kurulamayacak ya da kurulsa bile hatalı kurulacaktır. Bu nedenle RPM paketlerinin isimlerinin yanında açıklayıcı ekler bulunur. Sözgelimi; i386: 386,486 ve daha yukarısı işlemciler için, i586: Pentium I ve daha yukarısı işlemciler için, i686: Pentium II ve daha yukarısı işlemciler için, ia64: 64 bit işlemci mimarisine uygun işlemciler için, noarch: Herhangi bir işlemci mimarisine bağlı kalınmadan kurulabilen paketler demektir.

Continue Reading →

YUM ( Yellowdog Updater Modifier )
YUM, basitçe RPM paket yönetim sistemi olarak tanımlanabilir. Fedora ve benzeri sistemlerde, gerekli olan paketleri yüklemek, kaldırmak ve güncellemek amacıyla Yum kullanılabilir. Yum’u kullanmaya başlamadan önce birkaç yapılandırma işlemine tabi tutulması ve programın güncellenmesi gerekir. Mesela, paket yüklemek için yum install paket_adı komutu kullanılabilir.

Sisteme bir paket kurulmadan önce, paketin kurulu olup olmadığı kontrol edilebilir. Bunun için şöyle bir komut vermek gerekir:

rpm -qa |grep paket_adı

ya da

rpm -q paket_adı

Sözgelimi, kurmak istediğimiz paketin postfix olduğunu varsayalım. O vakit komutumuz şöyle olacaktır:

rpm -qa |grep postfix

ya da

rpm -q postfix

Postfix’in kurulu olmadığını öğrendik, şu halde kurulum için mesela şöyle bir komut vermemiz gerekiyor:

rpm -ivh postfix-2.2.2-2.i386.rpm

RPM 4.14.2.1 edinmek için aşağıdaki linkten yararlanabilirsiniz.

0