Showing posts with label RedHat. Show all posts
Showing posts with label RedHat. Show all posts

Tuesday, 16 July 2024

How to Use Jenkinsfile to connect into Ansible Tower and execute a server reboot running a ansible playbook ?

Let’s create a Jenkinsfile that integrates with Ansible Tower and executes a playbook to reboot a server. We’ll also include parameters for environment, target hostname group, and boolean options.


First, make sure you have the following prerequisites:

  1. Jenkins: Set up Jenkins on your system.
  2. Ansible Tower: Ensure you have Ansible Tower installed and configured.
  3. SSH Key Pair: Set up an SSH key pair for authentication between Jenkins and Ansible Tower.

Now, let’s create the Jenkinsfile:

pipeline {
    agent any

    parameters {
        string(name: 'ENV', description: 'Environment (e.g., dev, staging, prod)')
        string(name: 'TARGET_HOSTNAME_GROUP', description: 'Ansible inventory group for target hosts')
        booleanParam(name: 'REBOOT_ENABLED', defaultValue: true, description: 'Enable server reboot')
    }

    stages {
        stage('Checkout') {
            steps {
                checkout scm
            }
        }

        stage('Run Ansible Playbook') {
            steps {
                script {
                    def ansiblePlaybookCmd = """
                        ansible-playbook -i ${TARGET_HOSTNAME_GROUP} playbook.yml
                        --extra-vars 'reboot_enabled=${REBOOT_ENABLED}'
                    """
                    sh ansiblePlaybookCmd
                }
            }
        }
    }
}

Explanation:

  • The Jenkinsfile defines a pipeline with two stages: “Checkout” and “Run Ansible Playbook.”
  • We use parameters to allow users to input the environment, target hostname group, and whether to enable server reboot.
  • In the “Run Ansible Playbook” stage, we execute the Ansible playbook using the provided parameters.
  • The ansible-playbook command includes the inventory group and an extra variable (reboot_enabled) to control the reboot behavior.


Make sure to adjust the playbook.yml path and customize the playbook according to your specific requirements. Additionally, ensure that Jenkins has the necessary permissions to execute Ansible playbooks on the target hosts.

Remember to replace placeholders (such as ${TARGET_HOSTNAME_GROUP}) with actual values in your environment. If you encounter any issues, feel free to ask for further assistance! 🚀


- For more information on integrating Ansible with Jenkins, you can explore the official Ansible Tower plugin for Jenkins1

- Additionally, check out the Red Hat blog post on integrating Ansible with Jenkins in a CI/CD process2..

####################################################################


Let’s enhance the Jenkinsfile by adding the three boolean parameters: rebootstop_application, and start_application. These parameters will allow you to control additional actions during your pipeline execution. Here’s the updated Jenkinsfile:


pipeline {
    agent any

    parameters {
        string(name: 'ENV', description: 'Environment (e.g., dev, staging, prod)')
        string(name: 'TARGET_HOSTNAME_GROUP', description: 'Ansible inventory group for target hosts')
        booleanParam(name: 'REBOOT_ENABLED', defaultValue: true, description: 'Enable server reboot')
        booleanParam(name: 'STOP_APP_ENABLED', defaultValue: false, description: 'Stop application before reboot')
        booleanParam(name: 'START_APP_ENABLED', defaultValue: false, description: 'Start application after reboot')
    }

    stages {
        stage('Checkout') {
            steps {
                checkout scm
            }
        }

        stage('Run Ansible Playbook') {
            steps {
                script {
                    def ansiblePlaybookCmd = """
                        ansible-playbook -i ${TARGET_HOSTNAME_GROUP} playbook.yml
                        --extra-vars 'reboot_enabled=${REBOOT_ENABLED}'
                        --extra-vars 'stop_app_enabled=${STOP_APP_ENABLED}'
                        --extra-vars 'start_app_enabled=${START_APP_ENABLED}'
                    """
                    sh ansiblePlaybookCmd
                }
            }
        }
    }
}

Explanation:

  • I’ve added three new boolean parameters: STOP_APP_ENABLED and START_APP_ENABLED.
  • If STOP_APP_ENABLED is set to true, the pipeline will stop the application before rebooting the server.
  • If START_APP_ENABLED is set to true, the pipeline will start the application after the server reboot.

Remember to adjust the playbook (playbook.yml) to handle these additional actions based on the provided parameters. Feel free to customize the playbook according to your specific requirements.

Monday, 1 July 2024

How to Reboot RedHat Server 9 using Jenkins and Ansible Playbooks

 In order for you to automate the process of Reboot RedHat Servers with Jenkins and Ansible Playbooks.

You have to create a Jenkins pipeline for an application that involves the following steps: rebooting a Red Hat Server 9 using Ansible Playbooks, building, testing, scanning with SonarQube and Fortify, and storing the artifact in JFrog Artifactory. 

Below are the detailed steps along with the required Jenkinsfile, Ansible playbook, and information on the necessary credentials.

Prerequisites

  1. Jenkins Setup:

    • Jenkins should be installed and configured.
    • Plugins: Ansible, SonarQube Scanner, Fortify, JFrog Artifactory.
  2. Credentials:

    • Ansible: SSH Key for Red Hat Server.
    • SonarQube: API Token.
    • Fortify: API Token.
    • JFrog Artifactory: Username and API Key.
  3. Tools:

    • Ansible installed and configured on Jenkins.
    • SonarQube and Fortify servers accessible from Jenkins.
    • JFrog Artifactory accessible from Jenkins.

Jenkins Pipeline Script (Jenkinsfile)

groovy
pipeline { agent any environment { ANSIBLE_PLAYBOOK = 'reboot-server.yml' ANSIBLE_INVENTORY = 'hosts' SONARQUBE_SERVER = 'sonarqube.example.com' SONARQUBE_TOKEN = credentials('sonarqube-token') FORTIFY_SERVER = 'fortify.example.com' FORTIFY_TOKEN = credentials('fortify-token') ARTIFACTORY_SERVER = 'artifactory.example.com' ARTIFACTORY_CREDENTIALS = credentials('artifactory-credentials') } stages { stage('Reboot Server') { steps { script { ansiblePlaybook( playbook: "${ANSIBLE_PLAYBOOK}", inventory: "${ANSIBLE_INVENTORY}", extras: "--become --extra-vars '
ansible_become_pass=${env.ANSIBLE_SSH_PASS}'" ) } } } stage('Build') { steps { // Replace with your build steps, e.g., Maven, Gradle echo 'Building the application...' } } stage('Test') { steps { // Replace with your testing steps echo 'Running tests...' } } stage('SonarQube Scan') { environment { SONARQUBE_URL = "${SONARQUBE_SERVER}" } steps { withSonarQubeEnv('SonarQube') { sh 'sonar-scanner -Dsonar.projectKey=my_project
-Dsonar.sources=. -Dsonar.host.url=${SONARQUBE_URL}
-Dsonar.login=${SONARQUBE_TOKEN}' } } } stage('Fortify Scan') { steps { script { // Assuming Fortify command-line tools are
installed and configured sh "sourceanalyzer -b my_project -scan -f
my_project.fpr -url ${FORTIFY_SERVER} -token ${FORTIFY_TOKEN}" } } } stage('Artifact Storage') { steps { script { // Replace with your artifact storage steps sh "curl -u ${ARTIFACTORY_CREDENTIALS} -T
./path/to/your/artifact.ext https://${ARTIFACTORY_SERVER}/
artifactory/path/to/repo/" } } } } post { always { cleanWs() } } }

Ansible Playbook (reboot-server.yml)

yaml
--- - name: Reboot Red Hat Server hosts: all become: yes tasks: - name: Reboot the server ansible.builtin.reboot: reboot_timeout: 300

Inventory File (hosts)

css
[all] redhat-server-1 ansible_host=your.server.ip ansible_user=your_ssh_user
ansible_ssh_private_key_file=/path/to/ssh_key

Adding Credentials in Jenkins

  1. Ansible SSH Key:

    • Go to Jenkins Dashboard > Credentials > System > Global credentials (unrestricted).
    • Add a new credential of type "SSH Username with private key".
    • Add your SSH key file for the Red Hat Server.
  2. SonarQube Token:

    • Go to Jenkins Dashboard > Credentials > System > Global credentials (unrestricted).
    • Add a new credential of type "Secret text".
    • Enter your SonarQube API token.
  3. Fortify Token:

    • Repeat the same steps as for the SonarQube Token, but use your Fortify API token.
  4. JFrog Artifactory Credentials:

    • Add a new credential of type "Username with password".
    • Enter your Artifactory username and API key.

Summary

This Jenkins pipeline script is designed to:

  1. Reboot a Red Hat Server 9 using Ansible.
  2. Build the application (customise the build steps according to your project).
  3. Run tests (customise the test steps according to your project).
  4. Perform a SonarQube scan for code quality analysis.
  5. Perform a Fortify scan for security analysis.
  6. Upload the artifact to JFrog Artifactory.

Make sure to replace placeholder steps with your actual build and test commands, and ensure that your Jenkins environment is configured correctly with the necessary tools and credentials.

Friday, 24 August 2018

Does RHEL 7 support online resize of disk partitions?

Environment

  • Red Hat Enterprise Linux 7

Issue

  • Both Xen and KVM support online resize of the virtual block devices that the virtual machines use.
  • Unfortunately, since the partitions in the boot virtual block device are already in use, those can't be modified online and the virtual machine won't pick up the changes on the boot virtual block device without a reboot.
  • We are looking for ability to dynamically increase a partitioned volume, is it possible to resize the disk partitions online in RHEL 7?
  • We are unable to dynamically increase a SAN attached volume without taking the volume offline. When will this feature to Support online resize of disk partitions be available?

Resolution

The ability to resize a Logical Volume and filesystem has long been provided by Logical Volume Manager (LVM) by simply using the entire block device (/dev/sdx for example) as a Physical Volume in the LVM Volume Group. There is no need for the old style of partition. This would allow the Logical Volume and filesystem to easily be expanded.
As to older style partitions, this feature has been added in RHEL 7 current release with a feature request (RFE has been filed to add support for online resize of disk partitions to RHEL 7 in private Red Hat Bugzilla 853105). With this feature, it's possible to resize the disk partitions online in RHEL 7.

Warning: Online partition table resizing is not a recommended process mostly because the underlying layer of an active logical volume or filesystem that relies on that information is being modified. While it is possible to perform online partition resize operation, it is not recommended simply from a data integrity standpoint and not because it's not possible.

  • In order to resize online a partition which is in use please observe the following steps:
# fdisk -l /dev/vda

Disk /dev/vda: 32.2 GB, 32212254720 bytes, 62914560 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: dos
Disk identifier: 0x000db7e6

   Device Boot      Start         End      Blocks   Id  System
/dev/vda1   *        2048     1026047      512000   83  Linux
/dev/vda2         1026048    28289023    13631488   8e  Linux LVM

# cat /proc/partitions 
major minor  #blocks  name

 252        0   31457280 vda
 252        1     512000 vda1
 252        2   13631488 vda2
  11        0    1048575 sr0
 253        0   10240000 dm-0
 253        1    2129920 dm-1

# pvs
  PV         VG          Fmt  Attr PSize  PFree
  /dev/vda2  rhel_vm-205 lvm2 a--  13.00g 1.20g
  • Modify the on-disk partition table as usual (e.g. by using fdisk command).
    • Delete the partition:
      Command (m for help): d
      Partition number (1,2, default 2): 2
      Partition 2 is deleted
      
    • Re-create the partition with the new size:
      Command (m for help): n
      Partition type:
         p   primary (1 primary, 0 extended, 3 free)
         e   extended
      Select (default p): p
      Partition number (2-4, default 2): 2
      First sector (1026048-62914559, default 1026048): 
      Using default value 1026048
      Last sector, +sectors or +size{K,M,G} (1026048-62914559, default 62914559): +18G
      Partition 2 of type Linux and of size 18 GiB is set
      
      Command (m for help): t
      Partition number (1,2, default 2): 2
      Hex code (type L to list all codes): 8e
      Changed type of partition 'Linux' to 'Linux LVM'
      
      Command (m for help): p
      
      Disk /dev/vda: 32.2 GB, 32212254720 bytes, 62914560 sectors
      Units = sectors of 1 * 512 = 512 bytes
      Sector size (logical/physical): 512 bytes / 512 bytes
      I/O size (minimum/optimal): 512 bytes / 512 bytes
      Disk label type: dos
      Disk identifier: 0x000db7e6
      
         Device Boot      Start         End      Blocks   Id  System
      /dev/vda1   *        2048     1026047      512000   83  Linux
      /dev/vda2         1026048    38774783    18874368   8e  Linux LVM
      
    • Commit changes to on-disk partition table:
      Command (m for help): w
      The partition table has been altered!
      
      Calling ioctl() to re-read partition table.
      
      WARNING: Re-reading the partition table failed with error 16: Device or resource busy.
      The kernel still uses the old table. The new table will be used at
      the next reboot or after you run partprobe(8) or kpartx(8)
      Syncing disks.
      
    • While on-disk partition table has been updated, observe that on-memory kernel partition table has not:
      # partprobe 
      Error: Partition(s) 2 on /dev/vda have been written, but we have been unable to inform the kernel of the change, probably because it/they are in use.  As a result, the old partition(s) will remain in use.  You should reboot now before making further changes.
      
      # cat /proc/partitions | grep vd
       252        0   31457280 vda
       252        1     512000 vda1
       252        2   13631488 vda2
      
  • Execute partx (provided by util-linux package) with --update option on the block device to update the in-memory kernel partition table from the on-disk partition table:
    # partx -u /dev/vda
    
  • Verify that in-memory kernel partition table has been updated with the new size:
    # cat /proc/partitions | grep vd
     252        0   31457280 vda
     252        1     512000 vda1
     252        2   18874368 vda2
    
  • Proceed with any further steps, in this example by extending the PV on the partition:
    # pvresize /dev/vda2
      Physical volume "/dev/vda2" changed
      1 physical volume(s) resized / 0 physical volume(s) not resized
    
    # pvs
      PV         VG          Fmt  Attr PSize  PFree
      /dev/vda2  rhel_vm-205 lvm2 a--  18.00g 6.20g
    

Root Cause

  • Changes to allow online resizing of in-use partitions are required in both kernel and userland.
    • RHEL7 kernels include the required changes to BLKPG ioctl from block: add partition resize function to blkpg ioctl to support BLKPG_RESIZE_PARTITION operation.
    • RHEL7 util-linux package includes partx and resizepart binaries, currently the only userland commands that support BLKPG_RESIZE_PARTITION operation of BLKPG ioctl.

Tuesday, 1 October 2013

How to Install Ruby & Rails on CentOS, Fedora or RedHat

#get root access
$su -
$ cd /tmp
 
#Remove old Ruby
$ yum remove ruby
# Install dependencies
$ yum groupinstall "Development Tools"
$ yum install zlib zlib-devel
$ yum install openssl-devel
$ wget http://pyyaml.org/download/libyaml/yaml-0.1.4.tar.gz
$ tar xzvf yaml-0.1.4.tar.gz
$ cd yaml-0.1.4
$ ./configure
$ make
$ make install
# Install ruby
$ wget http://ftp.ruby-lang.org/pub/ruby/1.9/ruby-1.9.3-p194.tar.gz
$ tar zxf ruby-1.9.3-p194.tar.gz
$ cd ruby-1.9.3-p194
$ ./configure
$ make
$ make install
# Update rubygems
$ gem update --system
$ gem install bundler
#Test ruby and rubygems are working
#Close shell and reopen for changes to take effect
$ruby -v
$gem --version
# Rails
$ yum install sqlite-devel
$ gem install rails
$ gem install sqlite3

How to check for open ports on Linux

Checking for open ports is among the first steps to secure your device. Listening services may be the entrance for attackers who may exploit...