saravananlinux

If your instances running under AWS autoscaling, then instances will always use the same AMI or Instance-Type which configured in launch configuration. If you installed new packages or did any changes in instance root volume, then you need to take new AMI from that instance[root volume] and need to update that AMI in Autoscaling group[using launch configuration]. But it will require many manual steps. So I created a Bash script and it will do that task automatically. Example 1:- If you want to just update the AMI in Autoscaling group, run the script like below. #./script.sh <Autoscaling Group Name>  <Launch Configuration Name>  <AWS Region> Example 2:- If you want to  update both instance type and AMI in Autoscaling group, run the script like below. #./script.sh <Autoscaling Group Name>  <Launch Configuration Name>  <AWS Region>  <Instance Type> ==================================== #!/bin/bash Autos...

https://www.atlassian.com/git/ tutorials/what-is-version- control

#!/bin/bash #loadavg=$(awk '{ print $1 "\t" $2 "\t" $3 }' /proc/loadavg ) #To find the exact memory used percentage[Used-(Cached+Buffer)] Memusage=$(printf '%.0f\n' `free | awk 'FNR == 3{print $3/($3+$4)*100}'`) now=$(date +"%Y-%m-%d %H:%M:%S") #To find the cpu load average cpu_load=$(printf '%.0f\n' `uptime | awk '{print $(NF-2)}' | cut -c1-4`) if [ "$cpu_load" -ge "25" ] || [ "$Memusage" -ge "50" ];then   echo -e "\n\n=================\t$now\t========================" >> /var/log/top_report   top -b -c -n1 >> /var/log/top_report fi

Just change the following line on function mongo_killproc() in mongod init script[line 94], # vim /etc/init.d/mongod local pid=`pidof ${procname}` instead of local pid=`pidofproc -p "${pid_file}" ${procname}`

Step 1:- Check the Hardware requirements. ====== http://doc.gitlab.com/ce/install/requirements.html Here I going to use Ubuntu 14.04 LTS version. Step 2:- Choose an installation method [ Installation from source or Omnibus package installer ]. ====== But they recommend installing the Omnibus package instead of installing GitLab from source. Omnibus GitLab takes just 2 minutes to install and is packaged in the popular deb and rpm formats. Compared to an installation from source, the Omnibus package is faster to install and upgrade, more reliable to upgrade and maintain, and it shortens the response time for our subscribers' issues. A package contains GitLab and all its dependcies (Ruby, PostgreSQL, Redis, Nginx, Unicorn, etc.), it can be installed without an internet connection. But I am going to try both methods now. Step 3:- Install GitLab from Omnibus package. ====== Enterprise Edition is license-based, so I going to install Community Edition which is free. 1. Install and config...

Question:- --------------- i need to migrate a Linux box with no downtime to ESXi and with VMware tool that is not possible or i don't know how because you can't install the VCenter Converter into a linux OS and to the live migration with synchronization. Does any 1 know a way to do this? Solution:- --------------- Of course, we can migrate the Linux physical machine to ESXi host using vsphere converter tool. Yes, we can't install converter tool in linux but we can install it in windows machine then we can migrate the physical machine to ESXi through windows VM. Recently I did this task. Please follow the below steps. 1. Install a windows machine in ESXi host where you want to migrate the physical machine. 2. Install the vsphere converter tool in that windows machine. 3. But please choose the source machine as linux physical machine instead of "localhost". If you select localhost then that win...

QEMU is a powerful emulator, which means that it can emulate a variety of processor types. Xen uses QEMU for HVM guests, more specifically for the HVM guest's device model. The Xen-specific QEMU is called qemu-dm (short for QEMU device model) QEMU uses emulation; KVM uses processor extensions (intel-VT) for virtualization. Both Xen and KVM merge their various functionality to upstream QEMU, that way upstream QEMU can be used directly to accomplish Xen device model emulation, etc. Xen is unique in that it has paravirtualized guests that don't require hardware virtualization. Both Xen and KVM have paravirtualized device drivers that can run on top of the HVM guests. The QEMU hypervisor is very similar to the KVM hypervisor. Both are controlled through libvirt, both support the same feature set, and all virtual machine images that are compatible with KVM are also compatible with QEMU. The main difference is that QEMU does not support native virtualization. Consequently, QEMU has ...