notice: Run of Puppet configuration client already in progress; skipping

Бороться с этой ошибкой легко (ниже пример для Debian):

rm /var/lib/puppet/state/puppetdlock

источник: http://java.cocolog-nifty.com/blog/2010/04/pupptnotice-run.html

Руководство по поиску узких мест в производительности web-серверов

Самое первое, что стоит смотреть - это не уперся ли Апач в лимит коннектов.

tail -f /var/log/httpd/error_log
[Sat Apr 03 14:35:05 2010] [notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)
[Sat Apr 03 14:35:05 2010] [notice] Digest: generating secret for digest authentication ...
[Sat Apr 03 14:35:05 2010] [notice] Digest: done
[Sat Apr 03 14:35:06 2010] [notice] Apache/2.2.3 (CentOS) configured -- resuming normal operations
[Sat Apr 03 14:42:02 2010] [error] server reached MaxClients setting, consider raising the MaxClients setting

Вы не поверите, но это решает 50% проблем с работой веб-серверов :)

Перенос всей конфигурации Puppet в Subversion

Когда число конфигов и манифестов в Puppet улетает далеко за несколько сотен, встает проблема версионирования этих самых конфигов и манифестов. Как нельзя лучше для этого подходит VCS SVN. В этой статье я расскажу, как поместить всю конфигурацию Puppet сервера в SVN и как выполнять последующую работу с ним.

Допустим, у нас есть пустой репозиторий: https://domain.ru/configuration (как его сделать - можете найти в моем блоге по ключевому слову "subversion"), в котором мы планируем хранить конфиги Puppet.

Итак, в самую первую очередь необходимо сделать бэкап папки Puppet, чтобы случайно его не прибить в процессе работы:

tar -czf /root/puppet.tar.gz /etc/puppet

Теперь нам необходимо загрузить все имеющиеся у нас конфиги Puppet в Subversion, это делается командой import:

svn import /etc/puppet https://domain.ru/configuration/puppet -m 'init'

После этой операции в репозитории будет создана папка puppet и все конфиги будут лежать внутри нее.

Но, обращаю внимание, после этой операции папка /etc/puppet не становится рабочей копией! Она просто импортируется в репозиторий и все:

cd /etc/puppet
svn up
Skipped '.'
# что означает, что мы не минутой не в рабочей копии.

Теперь отключаем Puppet-сервер и сдвигаем исходную папку конфигов:

/etc/init.d/puppetmaster stop
mv /etc/puppet /etc/puppet_non_svn

Создаем новую папку для конфигов Puppet:

mkdir /etc/puppet
cd /etc/puppet

Делаем чекаут репозитория в нее:

svn co https://domain.ru/configuration/puppet ./ --username=puppet

Запускаем PuppetMaster:

/etc/init.d/puppetmaster start

Как Вы уже могли заметить, сервер Puppet работает с svn от имени пользователя puppet, в то время как я сам работаю по своему логину, nrg. Это сделано не случайно, а, во-первых, по соображениям безопасности и, во-вторых, по соображениям порядка :)

Дальнейшая работа с конфигурациями может выглядеть двумя способами - вы вносите изменения на сервере Puppet и коммитите их командой:

svn ci -m 'fix config'

либо исправляете конфиг "дома" (используя личный логин в svn):

svn ci -m 'fix config'

и после этого делаете обновление репозитория на сервере:

cd /etc/puppet
svn up

Ну вот и все, удачного использования и легкой поддержки кучи серверов :)

OpenVZ: как применить новый шаблон ограничения ресурсов для существующего контейнера?

Вот так вот:

vzctl set 102 --applyconfig vps.basic --save

При этом, даже если Вы изначально создавали VE с этим шаблоном, но потом внесли в него изменения, после применения этой команды, они сразу отразятся на значениях лимитов контейнера.

Увеличение max_allowed_packet в MySQL Debian

Откройте файл:

vi /etc/mysql/my.cnf

И ниже блока [mysqld] добавьте на следующей строке (если там такая переменная уже будет, тогда скорректируйте ее значение вместо добавления):

max_allowed_packet = 100M

После этого перезапустите MySQL:

/etc/init.d/mysql restart

Как заставить httpd на CentOS принимать .htaccess в папке /var/www/html?

Открываем конфиг:

vi /etc/httpd/conf/httpd.conf

Ищем там блок Directory "/var/www/html" и внутри него заменяем:

AllowOverride None

на

AllowOverride All

Применяем изменения:

/etc/init.d/httpd restart

Очистка файлов сессий PHP в Debian, через какое время это делать?

На долго работающих системах образуются папки /tmp или mod-tmp (либо bin-tmp) в случае использования ISPManager размером в миллионы и десятки миллионов файлов с файлами PHP сессий sess_тут_длинный_код, которые служат для временного хранения сессий от пользователей. То, что это наносит ущерб производительности файловой системы - однозначно (попробуйте пролистать такую папку ls ом или хотя бы удалить), поэтому их надо удалять. Возникает вопрос - как часто их можно удалять, чтобы не повредить работе приложений их использующих?

В комментариях к конфигу в Debian 5 Lenny сказано следующее:

; After this number of seconds, stored data will be seen as 'garbage' and
; cleaned up by the garbage collection process.
session.gc_maxlifetime = 1440

; NOTE: If you are using the subdirectory option for storing session files
; (see session.save_path above), then garbage collection does *not*
; happen automatically. You will need to do your own garbage
; collection through a shell script, cron entry, or some other method.
; For example, the following script would is the equivalent of
; setting session.gc_maxlifetime to 1440 (1440 seconds = 24 minutes):
; cd /path/to/sessions; find -cmin +24 | xargs rm

Как можно понять из текста, за время жизни файлов сессий отвечает переменная session.gc_maxlifetime, которая стандартно выставлена в 1440 секунд или 24 минуты. Также для определения этого промежутка на основе значений, заданных в системных php.ini, в Debian есть служебный скрипт:

/usr/lib/php5/maxlifetime
24

Все хорошо и прекрасно. Да, отчасти. А что будет, если кто-то из авторов CMS написал такую систему авторизации пользователей, которая работает на таких вот сессиях и, например, именно по ним проверяет залогиненость пользователя? Правильно, его вышибет. Думаете никто так не сделает? Ошибаетесь: http://php.net/manual/en/ref.session.php

Итого, резюмирую - лично я эту папку чистить буду не чаще раза в 2 недели (ну по крайней мере GMail и Yandex.Mail меня примерно через это время выкидывают и заставляют повторно авторизироваться), это самый безопасный путь. Других нету, увы.

xen: как узнать, сколько памяти еще доступно для Xen DomU?

При добавлении памяти какому-либо домену в Xen необходимо знать, если свободная память вообще :)

В этом нам поможет вот такая команда:

xm info | grep memory
total_memory : 1982
free_memory : 768

Причем, она показывает реально свободную память за вычетом памяти Dom0 и памяти всех запущенных DomU.

Массовая смена режима работы PHP на FastCGI в ISPManager

This summary is not available. Please click here to view the post.

ISPManager и задачи pbackup в CRON

У ISPManager система бэкапа создает в кроне рута (crontab -e от root) задачки pbackup, которые и выполняют бэкап. Тут все довольно просто - есть задача pbackup в CRON - бэкап включен, нету - выключена. Хотя, казалось бы, проще было в бинарике pbackup сделать проверку "активна ли задача" и после этого бэкапить или нет. Вот такая вот неприятность, да :(

fsch_assert FSCHVALUE_CMP(p->value, TICK_VALUE) >= 0 failed

This summary is not available. Please click here to view the post.

Регенерация /boot/grub/menu.lst на Debian

Иногда необходимо сделать регенерация файла menu.lst, лучший способ сделать это, команда:

update-grub

Совместная установка Zend и IonCube

Вполне возможна!

Конфиг-файл при этом должен иметь примерно вот такой вид:

[Zend]
zend_extension = /opt/ioncube/ioncube_loader_lin_5.2.so
zend_extension = /opt/zend/ZendOptimizer.so

FreeBSD: Not all disks connected

После отказа ad4:

gmirror status
Name Status Components
mirror/gm0 DEGRADED ad6

Заменили его и попытался запустить сборку массива:

gmirror insert gm0 /dev/ad4
gmirror: Not all disks connected.

Чтобы избавиться от проблемы, надо порекомендовать массиву "забыть" о потерянном бойце:

gmirror forget gm0

И после этого добавление диска сработает на ура:

gmirror insert gm0 /dev/ad4

Все, теперь ждем ребилд:

gmirror status
Name Status Components
mirror/gm0 DEGRADED ad6
ad4 (0%)

Как сделать полный бэкап Puppet сервера на CentOS 5?

Вот встала задача мигарции физического сервера в виртульную среду, в связи с этим надо бэкапить Puppet Server на CentOS для переноса.

Pueppet хранит свои конфигурации в двух папках:

/etc/puppet
/var/lib/puppet

Так что необходимо сбэкапить две этих папки и после переноса развернуть на новом сервере.

tar -czf etc_puppet.tar.gz /etc/puppet
tar -czf var_puppet.tar.gz /var/lib/puppet/

После переноса на новой машине устанавливаем puppet-master и останавливаем его:

/etc/init.d/puppetmaster stop

Далее на всякий случай перемещаем стандартные конфиги:

mv /var/lib/puppet/ /var/lib/puppet_old
mv /etc/puppet/ /etc/puppet_old

Теперь переходим в папку со старыми архивами и распаковываем их:

tar -xf etc_puppet.tar.gz
tar -xf var_puppet.tar.gz

Переносим папки из архива на место конфигов:

mv etc/puppet/ /etc/puppet
mv var/lib/puppet/ /var/lib/puppet

Потом запускаем сервер:

/etc/init.d/puppetmaster start

После этого, делаем запрос с какого-либо клиента и убеждаемся, что все работает корректно.