The mysql.session exists but is not correctly configured

One of our MySQL server(5.5.x) crashed but fortunately we have setup the backup of it. I have built the new server with MySQL(5.7.34) and restored the backup on it but when I tried to run any query like creating new user(s) etc got an error something like:

ERROR 1728 (HY000): Cannot load from mysql.db. The table is probably corrupted

This happens due to the schema changes required for different MySQL server versions. The simple fix to this problem recommended by MySQL is to run the mysql_upgrade command from the command line.
mysql_upgrade checks all tables across all databases for incompatibilities with the current version of MySQL. mysql_upgrade also upgrades the system tables so that we can take advantage of new privileges or capabilities that might have been added. It supersedes the older mysql_fix_privilege_tables script, which should no longer be used.

[IMPORTANT NOTE] Before running mysql_upgrade command on production server, it’s always a good practice to take a full backup of all the databases first, just in case something goes wrong.

I tried to run mysql_upgrade command from terminal:

mysql_upgrade -uroot -p

After entering the command, got this error message:

Note: I am not mentioning mysql username and password in the command because I am using .my.cnf configuration

mysql_upgrade will perform a weaker verification. If the result is not equal to 1, then mysql_upgrade cannot be executed.

RabbitMQ Clustering on AWS using Ansible

In this short post, I’ll show you the steps to configure the RabbitMQ clustering on AWS using Ansible. We decided to use the RabbtiMQ instead of AWS SQS because we want better performance and also require some flexibility.

In this setup, we have created 3 EC2 servers(Ubuntu 14.04 LTS) and 1 classic ELB on AWS. Clients both providers and consumers connect to the RabbitMQ servers through ELB, so system will be functional even one or more server will be down in other words system will be operational as long as one of the server is running.

RabbitMQ Requirement(Copied from official RabbitMQ Site):

RabbitMQ nodes address each other using domain names, either short or fully-qualified (FQDNs). Therefore hostnames of all cluster members must be resolvable from all cluster nodes, as well as machines on which command line tools such as rabbitmqctl might be used.

Hostname resolution can use any of the standard OS-provided methods:
DNS records
Local host files (e.g. /etc/hosts)

Settings on AWS:

Jenkins Installation and GitHub OAuth Integration using Ansible

In this tutorial, we’ll use Ansible to automate the installation of Jenkins CI on a fresh Ubuntu 14.04 LTS and integrate it with the GitHub OAuth. Ansible will also assign the matrix based permission on the Jenkins like which github user or group(s) have what rights on the Jenkins. Beside that, it will also install the Apache which serves as frontend for all the Jenkins requests.

In short, in this tutorial we’ll do the following tasks using Ansible:

• Install the JAVA 7
• Install the mentioned version of Jenkins(in this case it will be 1.658)
• Install the desired plugins
• Install the Apache and configure it as frontend for Jenkins
• Install the SSL certificate for Apache Virtual Host that act as frontend for Jenkins
• Integrate the Jenkins with GitHub using OAuth for Authenication
• Configure the matrix based security using the github username or group

Ansible role to create linux users with Github accounts ssh key

In this short tutorial we’ll learn how to create or delete the linux user accounts with public ssh keys associated with their Github accounts using Ansible, so please create a Github account if you don’t already have one, and follow the instructions for associated SSH keys with your account, if you didn’t perform it already.

First, download this Repository from the GitHub:

git clone https://github.com/arbabnazar/ansible-roles.git

Note: If git is not installed then you can simply download the zip file.

Move inside the cloned directory:

cd ansible-roles

Autoscaling with AWS instances using Ansible-Pull

Ansible has an excellent feature called ansible-pull, which many people don’t know or don’t use. This feature works best for self healing infrastructure, best example is AWS Autoscaling in which new ec2 instance is created from vanilla ami, then pull the code from somewhere (version control system) and configure itself before announcing that it is ready to serve (mean add to the serving ELB).

The steps for ansible-pull are:

1. Pull the git repo containing your playbooks.
2. That repo is cloned to the mentioned directory.
3. ansible-pull starts executing the local.yml found in your cloned repo directory.

Let’s assume that you want to pull the code from the private git repo and for this you need the ssh private key but you have taken the updated vanilla ubuntu ami from the Marketplace, then how you will clone this private repo? For this we’ll use the Bootstrap Pattern:

– Put the private part of ssh key for the git repository on S3.
– Getting ssh key from s3 bucket using IAM role credentials

For this, create a S3 bucket(in my case it is named “tendo-github-key-s3“):

Create AWS Cloudfront Distribution using Terraform

In this post, we’ll create the AWS Cloudfront Distribution using Terraform and for this, we need the latest version of Terraform.

Terraform v0.6.15

• Complete Cloudfront Terraform Plan as gist
• Complete Variables as gist

Before using the terraform, we need to export AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY as environment variables:

export AWS_ACCESS_KEY_ID="xxxxxxxxxxxxxxxx"
export AWS_SECRET_ACCESS_KEY="yyyyyyyyyyyyyyyyyyyy"

How to compile a development version of Terraform

In this tutorial I’ll describe all the steps to build the development version of Terraform. At the end of this process, it will generate a set of binaries for each supported platforms(Linux, Mac OS X, Windows etc..).

First we need to clone the terraform’s github offical repo:

git clone https://github.com/hashicorp/terraform.git

Move inside the cloned repo:

cd terraform

Highly-Available WordPress Setup inside AWS VPC using Terraform & Ansible

In this post,we’ll create the Infrastructure for Highly-Available WordPress website over AWS using Terraform and then install the WordPress using Ansible. If you don’t know about the Terraform, please check this link.

We’ll use the Terraform to create the fully operational AWS VPC infrastructure(subnets,routeing tables,igw etc), it will also create everything that need to be for creating EC2 and RDS instances (security key, security group, subnet group). It will also create the Elastic Load Balancer and add the EC2 instance(s) automatically to it as well as creating the Route53 entry for this wordpress site and add the ELB alias to it.

Ansible will be used to deploy the wordpress on the EC2 instances that have been created via Terraform, that will be fault tolerant and highly available.

Requirements:

• Terraform

• Ansible

• AWS admin access

Tools Used:

AWS Infrastructure Creation with Ansible Part-4

By this point, you should have gone through the Part-1, Part-2 and Part-3 of this series. In this tutorial, we’ll create the RDS instance inside the VPC that we have created in Part-1  and Security Group created in Part-2 using Ansible.

If you have completed the previous parts of this series, then you have already clone the git repo that contains all the roles, if not then clone the git repo:

git clone https://github.com/arbabnazar/ansible-aws-roles.git
cd ansible-aws-roles

Modified the aws.yml playbook to add the desired roles:

	---
	- hosts: localhost
	connection: local
	gather_facts: no
	roles:
	- vpc
	- ec2sg
	- ec2key
	- ec2instance
	- elb
	- rds

view raw aws-4.yml hosted with ❤ by GitHub

Note: May be, you have already noticed that we have also added the vpc, ec2sg, ec2key, ec2instance and elb roles in the playbook, it will not re-create all this except the EC2 instance(this role is not idempotent), if you have created them in the previous parts, because Ansible is idempotent.

AWS Infrastructure Creation with Ansible Part-3

By this point, you should have already read the Part-1 and Part-2 of this series. In this tutorial, we’ll create the EC2 instances inside the VPC that we have created in Part-1, Security Group & EC2 Key Pair created in Part-2 and also add them inside the ELB, all with Ansible.

If you have completed the previous parts of this series, then you have already clone the git repo that contains all the roles, if not then clone the git repo:

git clone https://github.com/arbabnazar/ansible-aws-roles.git
 cd ansible-aws-roles