Linux

Просмотр конфигурации кластера # crm configure show 1 2 3 4 5 6 7 8 9 10 11 node node1 node node2 primitive Cluster_Server ocf::heartbeatIPaddr2 params ip="192.168.1.200" cidr_netmask="24" op monitor interval="30s" property $id="cib-bootstrap-options" dc..-version="1.1.10-14el6_52-368c726" cluster-infrastructure="classic openais (with plugin)" expected-quorum-votes="2" stonith-enabled="false" no-quorum-policy="ignore" Статус кластера # crm status 1 2 3 4 5 6 7 8 9 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 Удаление ресурса 1 2 crm resource stop Cluster_Server crm configure delete Cluster_Server Очистка ошибок Иногда, когда используется pacemaker/corosync кластер, вы можете видеть подобные уведомления в выводе crm_mon: 1 2 Failed actions: drbd_mysql:0_promote_0 (node=node2.cluster.org, call=11, rc=-2, status=Timed Out): unknown exec error Для очистки этих сообщений можно использовать команду crm_resource, которая принудительно проверит статус ресурса: ...

В openssh есть возможность ограничить доступ пользователя в подсистеме sftp. Т.е. задать ему ChrootDirectory, как в proftpd. Например в домашнюю папку (ибо нефиг лазить за её пределами). Рассмотрим, как это можно реализовать. Для начала, создадим группу sftpusers. Ограничения будут действовать только на пользователей из этой группы (мы ведь не хотим ограничивать пользователя root?): 1 addgroup --system sftpusers Далее заменим подсистему sftp в /etc/ssh/sshd_config: 1 2 -Subsystem sftp /usr/lib/openssh/sftp-server +Subsystem sftp internal-sftp Ну и наконец запишем ограничения в тот же файл: 1 2 3 4 Match Group sftpusers ChrootDirectory %h ForceCommand internal-sftp AllowTcpForwarding no Не забываем перечитать конфиг: 1 invoke-rc.d ssh reload Теперь разберемся с пользователями. При создании пользователя не надо указывать ему шелл, так как он все равно не сможет им воспользоваться (см. ForceCommand internal-sftp). Поэтому указываем в качестве шелла /bin/false. Домашняя папка (точнее папка, которую мы указали в ChrootDirectory) обязательно должна иметь владельцем пользователя root. Иначе будем получать ошибку: 1 fatal: bad ownership or modes for chroot directory "/home/%username%" А вот группу-владельца chroot-папки можно задать любую. Но главное условие - chroot-директория должна быть доступна на запись только для пользователя root и никого больше. В противном случае получим вышеприведенную ошибку. ...

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: 1 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): ...

Как узнать каким процессом qemu запущен инстанс 1 2 ps axu|grep <instance_id> lsof |grep <process_pid>|grep qemu-system В ответ можем получить что-то похожее 1 2 3 4 5 6 7 $ 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 символы в начале файлов переводов расширений. Проверяем 1 grep -rl $'\xEF\xBB\xBF' . Автоматически исправляем 1 find . -type f -exec sed '1s/^\xEF\xBB\xBF//' -i {} \; Был рад помочь!

Файрволл в cpanel представлен сервисом csf, иногда приходится его останавливать из-за слишком “удачной” настройки клиентами. После не забыть iptables -F

# cat /etc/rsyncd.conf 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 pid file = /var/run/rsyncd.pid syslog facility = local5 munge symlinks = no use chroot = no uid=root socket options="--sockopts=SO_SNDBUF=65536,SO_RCVBUF=131072" [user] path = /home/user write only = false read only = true hosts allow = hostYYY.domain.net 192.168.3.8 [nginx] path = /etc/nginx write only = false read only = true hosts allow = hostXXX.domain.net 192.168.3.1 При этом на другом хосте можем использовать конструкцию rsync -av rsync://host1.com/user/web/domain.net/public_html/ /home/web/domain.net/public_html/

Процедура смены пароля пользователя root в CentOS 7 очень сильно отличается от процедуры в CentOS 6. Эта статья как раз о том, как сменить пароль пользователя root в CentOS 7. 1 – В загрузочном меню grub выберите пункт для редактирования. 2 – Нажмите кнопку для редактирования (e). 3 – Отправляйтесь к указанной ниже строке и измените ro на rw init=/sysroot/bin/sh. 4 – Сейчас нажмите Control+x для загрузки в single user mode. 5 – Сейчас войдите в chroot, набрав команду. 1 chroot /sysroot 6 – Сбросьте пароль. 1 passwd root 7 – Обновите selinux информацию. 1 touch /.autorelabel 8 – Выйдите из chroot. 1 exit 9 – Перезагрузите систему. 1 reboot Вот и всё. Пользуйтесь.

Недавно закончилось место на одной из моих виртуалок. Дано: Виртуалка на Proxmox Функции - mysql сервер Корневой раздел обычный, без использования LVM. Как бы ничего сложного, в гипервизоре увеличиваем размер диска и дальше по многим мануалам в сети. Но не тут то было, нельзя было выключать сервер, а файловая система была корневой, соответственно и отмонтировать в процессе работы сервера её нельзя было. Как мне подсказывали коллеги, поможет всего одна строка: 1 2 3 4 resize2fs /dev/vda2 resize2fs 1.42.12 (29-Aug-2014) The filesystem is already 7863561 (4k) blocks long. Nothing to do! Увы, не так просто ) Но, казалось бы такая сложная задача, свелась всего к двум строкам. 1 2 growpart /dev/vda 2 resize2fs /dev/vda2 После этих действий всё подхватилось как и планировалось, перезагрузка сервера и его сервисов не потребовались. Все действия описанные в статье вы совершаете на свой страх и риск!

В этой статье хочу описать те моменты, с которыми приходится сталкиваться самому. Решение приходится искать по разным уголкам интернетов. TASK ERROR: CT is locked (disk) Произошло это после попытки сделать бэкап на NFS диск, который отвалился. В качестве решения можно выполнить в консоли: 1 2 pct unlock <vm id> - для KVM виртуалки qm unlock <vm id> - для LXC контейнера и попробовать заново выполнить действие.