LINUX AND VMWARE STUFF

This Blog is to share our knowledge and expertise on Linux System Administration and VMware Administration

Sunday, January 7, 2018

How to modify the Default Physical extent size of Physical Volume?

Sunday, January 07, 2018 0

There are 2 situation for modifying or Setting the Default Physical extent size in LVM.

1. Create a volume group with new Physical extent size. This method will be used before creating logical volume on that Volume Group.

 #vgcreate -s PE_SIZE 

 Here,
-s  --physicalextentsize Size[m|UNIT] - Sets the physical extent size of PVs in the VG.  The value must be either a power of 2 of at least 1 sector (where the sector size is the largest sector size of the PVs currently used in the VG), or at least 128KiB.  Once this value has been set, it is difficult to change without recreating the VG,unless no extents need moving.

2. Modify the Existing value of Physical extent size.

 - remove all Logical Volumes of the Volume Group with lvremove
- do a vgreduce on that VG.
- "vgchage -an" on that VG
- vgremove that VG
- setup the VG with large PE size (vgcreate -s PE_SIZE)

 A more "Forceful" approach is:
- "vgchange -a n" on the VG
- "pvcreate -ff" on all its PVs
- setup the VG with large PE size (vgcreate -s PE_SIZE)
Tags # LVM Continue Reading
By v�o l�c No comments:
Labels:

Saturday, January 6, 2018

Display what extents are allocated on the physical volume to logical volume

Saturday, January 06, 2018 0
We can see what extents are allocated on the physical volume

 NAME
       pvdisplay - Display various attributes of physical volume(s)
   
pvdisplay shows the attributes of PVs, like size, physical extent size, space used for the VG descriptor area, etc. Here pvdisplay along with options --maps will show the what extents are allocated on the physical volume to the lv.

 [root@nsk postfix]# pvdisplay --maps /dev/sda2
  --- Physical volume ---
  PV Name                /dev/sda2
  VG Name                centos
  PV Size                  <19.00 GiB / not usable 3.00 MiB
  Allocatable              yes (but full)
  PE Size                   4.00 MiB
  Total PE                   4863
  Free PE                   0
  Allocated PE           4863
  PV UUID                 DQjmHN-fso4-Mu4t-3l1V-Yogj-ksTH-ROFiK7

   --- Physical Segments ---
  Physical extent 0 to 511:
    Logical volume      /dev/centos/swap
    Logical extents      0 to 511
  Physical extent 512 to 4862:
    Logical volume      /dev/centos/root
    Logical extents      0 to 4350

 Here,
         -m  --maps  Display the mapping of physical extents to LVs and logical extents.
Tags # LVM Continue Reading
By v�o l�c No comments:
Labels:

Tee command in Linux

Saturday, January 06, 2018 0
NAME
       tee - read from standard input and write to standard output and files
   
Copy standard input to each FILE, and also to standard output

 options:
-a, --append  - append to the given FILEs, do not overwrite
-i, --ignore-interrupts - ignore interrupt signals
Ex : 
    [root@nsk postfix]# cat main.cf | egrep -v "^#|^$" |tee -a main.cf_catoutput

 Here,
Tee command will read the output of cat command & write the standard output to a specified file.
Tags # Linux General Continue Reading
By v�o l�c No comments:
Labels:

Friday, January 5, 2018

Single command to take the backup and removes the commented and blank lines in a file

Friday, January 05, 2018 0
We can achieve by using 2 ways in Linux.

SED Command:

Normally, we will take back up and tidy the most of the configuration file. There is a tendency for many software packages to over comment their configurations. This can cause issues where you think that you have implemented a change; however, it was also set later on and you may not have noticed it.
Postfix, main.cf configuration file having 679 lines. We will back up the file so that we do not lose comments and documentations, but we will also have a new working file with less than 10 percent of the number of lines. The following command shows how this is done
[root@nsk etc]# cat /etc/postfix/main.cf | wc -l
679

 [root@nsk etc]# sudo sed -i.bak '/^#/d;/^$/d' /etc/postfix/main.cf
Here:
#/d   - Remove the commented line
^$   - Remove the blank line

 [root@nsk etc]# cat postfix/main.cf | wc -l
25
Above sed command reduces the file from 679 lines to 25 lines and is far easier to work with. We can now edit this file without any distractions. We will add two new lines and edit two existing lines to the /etc/postfix/main.cf file. This will need to be edited as root.

CAT Command:

We can use below command also to achieve the above output. 

 [root@nsk etc]# [root@nsk postfix]# cat main.cf.bak | egrep -v "^#|^$" |tee -a main.cf_catoutput
[root@nsk postfix]# cat main.cf_catoutput | wc -l
25

Sed command will take the backup of existing file & the output will be saved in existing name. Here Cat command output will be saved in different name.

Tags # Linux General Continue Reading
By v�o l�c No comments:
Labels:

Thursday, January 4, 2018

find: paths must precede expression: SOLVED

Thursday, January 04, 2018 0

While running find command, we are getting the message "find: paths must precede expression:"

[root@testserver emd]# find /oem1/agent12c/odcagent/agent_inst/sysman/emd/ -mtime +10 -mtime -30 -type f -name core.* -exec ls -al {} \;
find: paths must precede expression: core.java.11182
Usage: find [-H] [-L] [-P] [-Olevel] [-D help|tree|search|stat|rates|opt|exec] [path...] [expression]

 Solution: 
While running find command, name field should be covered with ' ' notation.
[root@testserver emd]# find /oem1/agent12c/odcagent/agent_inst/sysman/emd/ -mtime +6 -mtime -30 -type f -name 'core.*'  -exec ls -al {} \;
-rw------- 1 odcagent dba 869224448 Dec 25 13:19 /oem1/agent12c/odcagent/agent_inst/sysman/emd/core.java.56825
-rw------- 1 odcagent dba 869380096 Dec 23 19:39 /oem1/agent12c/odcagent/agent_inst/sysman/emd/core.java.1860
Tags # Linux General Continue Reading
By v�o l�c No comments:
Labels:

Wednesday, January 3, 2018

Working with Docker Containers

Wednesday, January 03, 2018 0

Working with Docker Containers

We need an image to start the container. Let's see how we can search images on the Docker registry. A registry holds the Docker images and it can be both public and private. By default, the search will happen on 
the default public registry, which is called Docker Hub and is located at https://hub.docker.com/

 Docker client and server version
root@Docker:~# docker version
Client:
 Version:        17.09.0-ce
 API version:  1.32
 Go version:   go1.8.3
 Git commit:   afdb6d4
 Built:             Tue Sep 26 22:42:18 2017
 OS/Arch:       linux/amd64

 Server:
 Version:        17.09.0-ce
 API version:  1.32 (minimum version 1.12)
 Go version:   go1.8.3
 Git commit:   afdb6d4
 Built:             Tue Sep 26 22:40:56 2017
 OS/Arch:       linux/amd64
 Experimental: false

 Listing/searching for an image
Format : docker search TERM
root@Docker:~# docker search centos

 For help with the Docker search, run the following command:
docker search --help

 Pulling an image
Format: docker pull NAME[:TAG]

 root@Docker:~# docker pull fedora
Using default tag: latest
latest: Pulling from library/fedora
a8ee583972c2: Downloading [=========>                                         ]  16.75MB/86.82MB
..
Image tags group images of the same type. For example, CentOS can have images with tags such as centos5, centos6, and so on. For example, to pull an image with the specific tag, run the following command:
$ docker pull centos:centos7

 By default, the image with latest tag gets pulled. To pull all images corresponding to all tags, use the following command:
$ docker pull --all-tags centos

 For help with the docker pull use --help
Tags # Docker Continue Reading
By v�o l�c No comments:
Labels:

Tuesday, January 2, 2018

Configuring SMTP in RHEL 7

Tuesday, January 02, 2018 0

Configuring Simple Mail Transfer Protocol in RHEL 7

Many programs use  SMTP to send messages about their status and so on. By default, postfix is configured to deliver all messages locally and not respond to incoming mails. If you have an environment of multiple servers, this can become quite tedious to log on to each server to check for new mail. This document will show you how to relay messages to a central mail relay or message store that also uses SMTP.

 Postfix is installed by default on RHEL 7.

 In this document, we'll combine several options:
• We'll allow the server to accept incoming mails
• We'll only allow the server to relay messages from recipients in the testdomain.local domain
• We'll forward all mails to the mailhost.testdomain.local mailserver

 To complete this document, perform the following steps:
Edit /etc/postfix/main.cf with your favorite editor.
Modify inet_interface to accept mails on any interface through the following command:
      inet_interface = all
Add the smtpd_recipient_restrictions directive to only allow incoming mails from the testdomain.local domain, as follows:
     smtpd_recipient_restrictions =
     check_sender_access hash:/etc/postfix/sender_access, 
      reject
As you can see, the last two lines are indented. The postfix considers this block as one line instead of three separate lines.
Add the relayhost directive to point to mailhost.testdomain.local, as follows:
      relayhost = mailhost.testdomain.local
Now, save the postfix file.
Create /etc/postfix/sender_access with the following contents:
       testdomain.local   OK
Next, hash the /etc/postfix/access file using the following command:
       #postmap /etc/postfix/access
Finally, restart postfix, as follows:
       # systemctl restart postfix

 To monitor your mail queue on the system, execute the following:
       # postqueue -p
Whenever your mail relay cannot forward mails, it stores them locally and tries to resend them at a later time. When you restore the mailflow, you can flush the queue and attempt delivery by executing the following:
       # postqueue -f
The kind of setup presented in this recipe is quite simple and assumes that you don't have malicious users on your network. There are software that allow you to mitigate spam and viruses. Popular solutions for this are spamassassin and amavis.
Tags # Linux General Continue Reading
By v�o l�c No comments:
Labels:

Monday, January 1, 2018

Studying the anatomy of a Ansible Playbook

Monday, January 01, 2018 0

Studying the anatomy of a Ansible Playbook

Playbooks can have a list of remote hosts, user variables, tasks, handlers, and so on. You can also override most of the configuration settings through a playbook. Let's start looking at the anatomy of a playbook.

 The purpose of the playbook we are going to consider now, is to ensure that the httpd package is installed and the service is enabled and started. This is the content of the setup_apache.yaml file:

 --- 
- hosts: all 
  remote_user: testuser
  tasks: 
  - name: Ensure the HTTPd package is installed 
    yum: 
      name: httpd 
      state: present 
      become: True 
  - name: Ensure the HTTPd service is enabled and running 
    service: 
      name: httpd 
      state: started 
      enabled: True 
    become: True 
The setup_apache.yaml file is an example of a playbook. The file is comprised of three main parts, as follows:

 hosts: This lists the host or host group against which we want to run the task. The hosts field is mandatory and every playbook should have it. It tells Ansible on which hosts to run the listed tasks. When provided with a host group, Ansible will take the host group from the playbook and try look for it in an inventory file . If there is no match, Ansible will skip all the tasks for that host group. The --list-hosts option along with the playbook (ansible-playbook <playbook> --list-hosts) will tell you exactly which hosts the playbook will run against.
remote_user: This is one of the configuration parameters of Ansible (consider, for example, testuser -remote_user) that tells Ansible to use a particular user (in this case, testuser) while logging into the system.
tasks: Finally, we come to tasks. All playbooks should contain tasks. Tasks are a list of actions you want to perform. A tasks field contains the name of the task, a module that should be executed, and arguments that are required for the module. Let's look at the single task that is listed in the playbook, as shown in the preceding snippet of code:
Note
All examples in the book would be executed on CentOS, but the same set of examples with a few changes would work on other distributions as well.

 In the preceding case, there are two tasks. The name parameter represents what the task is doing and is present mainly to improve readability, as we'll see during the playbook run. The name parameter is optional. The modules, yum and service, have their own set of parameters. Almost all modules have the name parameter (there are exceptions such as the debug module), which indicates what component the actions are performed on. Let's look at the other parameters:

 In the yum module's case, the state parameter has the latest value and it indicates that the httpd latest package should be installed. The command to execute more or less translates to yum install httpd.
In the service module's scenario, the state parameter with the started value indicates that the httpd service should be started, and it roughly translates to /etc/init.d/httpd start. In this module we also have the "enabled" parameter that defines whether the service should start at boot or not.

 True parameter represents the fact that the tasks should be executed with sudo access. If the sudo user's file does not allow the user to run the particular command, then the playbook will fail when it is run.

 Note
Why there is no package module that figures out the architecture internally and runs the yum, apt, or any other package options depending on the architecture of the system. Ansible populates the package manager value into a variable named ansible_pkg_manager.

 In general, we need to remember that the number of packages that have a common name across different operating systems is a small subset of the number of packages that are actually present. For example, the httpd package is called httpd in Red Hat systems and apache2 in Debian-based systems. We also need to remember that every package manager has its own set of options that make it powerful; as a result, it makes more sense to use explicit package manager names so that the full set of options are available to the end user writing the playbook.
Tags # Ansible Continue Reading
By v�o l�c No comments:
Labels: