Заметка по работе с pacemaker/corosync кластером.

Просмотр конфигурации кластера

# crm configure show
node node1
node node2
primitive Cluster_Server ocf::heartbeatIPaddr2 
        params ip="" cidr_netmask="24" 
        op monitor interval="30s"
property $id="cib-bootstrap-options" 
        cluster-infrastructure="classic openais (with plugin)" 

Статус кластера

# crm status
Last updated: Thu Mar  6 11:20:52 2014
Last change: Thu Mar  6 09:57:49 2014 via cibadmin on node1
Stack: classic openais (with plugin)
Current DC: node2 - partition with quorum
Version: 1.1.10-14.el6_5.2-368c726
2 Nodes configured, 2 expected votes
1 Resources configured
Online: [ node1 node2 ]
 Cluster_Server (ocf::heartbeat:IPaddr2):       Started node2

Удаление ресурса

# crm resource stop Cluster_Server
# crm configure delete Cluster_Server

Очистка ошибок

Иногда, когда используется pacemaker/corosync кластер, вы можете видеть подобные уведомления в выводе crm_mon:
Failed actions:
drbd_mysql:0_promote_0 (node=node2.cluster.org, call=11, rc=-2, status=Timed Out): unknown exec error

Для очистки этих сообщений можно использовать команду crm_resource, которая принудительно проверит статус ресурса:

# crm_resource -P
Waiting for 1 replies from the CRMd. OK


The Scenario

We continue to utilize Chef in our organization's infrastructure, and it's time to create a cookbook that installs Nginx. Creating new web servers, for either production or internal testing, is fairly common. We'd like to be able to control the run-list for all web server nodes in a single place though, and we've decided that we will use a new role to do this. After we've written our Nginx cookbook, we'll deploy it to the first web server node using a role.

Logging in

On the lab overview page, we'll see three EC2 instances: a Chef server ( we'll call it chef), a workstation (we'll call it worker) and a node (we'll call it node). The shell prompts in this lab guide will reflect which one we're running commands in at the moment.

Get Nginx Running and Enabled on web-node1

We need to write a cookbook that installs the Nginx package and starts the service. This cookbook needs to be published and the recipe run on web-node1.

Create the Cookbook

After logging into worker, we can get into the provided Chef repository right away, with cd chef-repo. Once we're in there, we can start building our cookbook:

cloud_user@worker]$ chef generate cookbook cookbooks/nginx

Create the Recipe

Edit the file ./cookbooks/nginx/recipes/default.rb with whichever text editor you like. When we're done, the file should read like this (after our additions, and once we've removed the comments that were sitting in there already):

package "nginx"

service "nginx" do
  action [:enable, :start]

Loading Our Cookbook

If we run this:

cloud_user@worker]$ knife upload cookbooks/nginx

and then this:

cloud_user@worker]$ knife node list

we'll see our web-node1 listed.

Create the webserver Role, and Ensure It Includes Nginx

We have to create a new role called webserver for installing Nginx and running the service. On this machine though, we don't have a default editor set, so we'll get an error if try we creating the role first. We're going to set Vim here, and then create the role:

cloud_user@worker]$ export EDITOR=vim
cloud_user@worker]$ knife role create webserver

Now we'll land in Vim, editing some JSON. Make the run_list section look like this:

"run_list": [

Use the webserver Role in the web-node1 Run-list

Let's set the webserver role to this node:

cloud_user@worker]$ knife node run_list add web-node1 'role[webserver]'

Now we can run our changes and push our cookbook up to the chef machine:

cloud_user@worker]$ knife ssh 'name:web-node1' 'sudo chef-client'

We'll be prompted for our password a couple of times (which will be the same as the cloud_user password we used for getting into the machine in the first place) and then we can watch the command output all of the things going on. As a sanity check, we should run the command again though. If nothing actually happens, then it means all went well. We should have gotten Nginx installed and started the first time around.


Now, we can run this:

cloud_user@worker]$ knife node show web-node1 -a run_list

And we'll see that our node is using a role, instead of a recipe directly. Since this is exactly how we wanted things to be running, we're done. Congratulations!

Как узнать каким процессом qemu запущен инстанс
# ps axu|grep <instance_id>
# lsof |grep <process_pid>|grep qemu-system​

В ответ можем получить что-то похожее
$ sudo lsof |grep 13491|grep qemu-system
qemu-syst 13491       libvirt-qemu  txt       REG               0,27      8466464       25908 /usr/bin/qemu-system-x86_64 (deleted)
qemu-syst 13491 13502 libvirt-qemu  txt       REG               0,27      8466464       25908 /usr/bin/qemu-system-x86_64 (deleted)
qemu-syst 13491 13522 libvirt-qemu  txt       REG               0,27      8466464       25908 /usr/bin/qemu-system-x86_64 (deleted)
qemu-syst 13491 13523 libvirt-qemu  txt       REG               0,27      8466464       25908 /usr/bin/qemu-system-x86_64 (deleted)
qemu-syst 13491 13531 libvirt-qemu  txt       REG               0,27      8466464       25908 /usr/bin/qemu-system-x86_64 (deleted)
qemu-syst 13491 20867 libvirt-qemu  txt       REG               0,27      8466464       25908 /usr/bin/qemu-system-x86_64 (deleted)​
Время от времени заказчики вносят свои коррективы в файлы сайтов, а потом приходится разбираться в чём же причина неизвестно откуда взявшихся глюков.

Довольно часто это BOM символы в начале файлов переводов расширений.

grep -rl $'\xEF\xBB\xBF' .​

Автоматически исправляем
find . -type f -exec sed '1s/^\xEF\xBB\xBF//' -i {} \;​

Был рад помочь :smile:

Это в конфиге виртуального хоста apache
php_admin_value sendmail_path “/usr/sbin/sendmail -t -i -f noreply@domain.com

а это в конфиге exim
trusted_users = apache

" = " (точное совпадение) и " ^~ "(не пробовать другие регекспы после совпадения) более строгие локейшены, чем простые " * " (регистро зависимый регексп) и " ~* "(регистро независимый регексп).