При проксировании https даже без сертификатов (чисто прокси) при реальной работе ловили
SSL_do_handshake() failed (SSL: error:1408C095:SSL routines:SSL3_GET_FINISHED:digest check failed) while SSL handshaking to upstream,
и 502 Bad Gateway.
Как ни странно, гугл дал всего 4 страницы, из которой только 1 была с решением:
proxy_ssl_session_reuse off;
Помогло. Непонятно, что это было и почему...
Проверять можно было через
openssl s_client -connect www.test.com:81 -state -ssl3 -no_ssl2 -no_tls1
в несколько потоков.
суббота, 28 апреля 2012 г.
suhosin и логи
Избавляемся от suhosin спама в логи (писалось под фрю, на линях пока не отлаживалось, может потом дополню)
пятница, 27 апреля 2012 г.
Intel SSD 710: обзор и тест SSD на технологии HET MLC
На замену x25-e серии интел выводит 710 серию, которая на MLC чипах. Что изменилось, обзор:
http://www.thg.ru/storage/obzor_intel_ssd_710/print.html
А вкратце - взяли 320гиг диск, откусили 40% под ремапы и резерв, обозвали это HET MLC, что не более чем простой маркетинг, и несколько изменили прошивку. Так что долговечность выше обычных MLC (за счет резервирования), но в остальном - та же деградация со временем, ресурс всё-равно ниже, на активных операциях есть провалы при работе чистилки мусора.
В общем, интел снова падает "в низы", видимо чтобы не создавать конкуренцию партнёрам, как с серверами например, которые "дёшево и сердито". В low-end нормально, выше или ничего нет, или отстой какой-то.
Хотя обещались выпустить 720 серию в формате платы в PCI-e, посмотрим что выйдет.
http://www.thg.ru/storage/obzor_intel_ssd_710/print.html
А вкратце - взяли 320гиг диск, откусили 40% под ремапы и резерв, обозвали это HET MLC, что не более чем простой маркетинг, и несколько изменили прошивку. Так что долговечность выше обычных MLC (за счет резервирования), но в остальном - та же деградация со временем, ресурс всё-равно ниже, на активных операциях есть провалы при работе чистилки мусора.
В общем, интел снова падает "в низы", видимо чтобы не создавать конкуренцию партнёрам, как с серверами например, которые "дёшево и сердито". В low-end нормально, выше или ничего нет, или отстой какой-то.
Хотя обещались выпустить 720 серию в формате платы в PCI-e, посмотрим что выйдет.
Цинизм в IT: Как заставить CentOS 6 реагировать на нажатие кно...
Цинизм в IT: Как заставить CentOS 6 реагировать на нажатие кно...: Очень просто, нужно поставить и запустить демон acpid: yum install -y acpid /etc/init.d/acpid start
среда, 25 апреля 2012 г.
вторник, 24 апреля 2012 г.
Регистрация IP-адресов и автономных систем
Оказывается, не так и дорого... мне раньше говорили про 1к+ баксов в месяц за AS.
http://www.netup.ru/Autonomous_System_Registration.php
Если у кого есть более дешёвые варианты - скидывайте, добавлю.
http://www.netup.ru/Autonomous_System_Registration.php
Если у кого есть более дешёвые варианты - скидывайте, добавлю.
понедельник, 23 апреля 2012 г.
/libexec/ld-elf.so.1: /usr/local/lib/libaprutil-0.so.9: Undefined symbol "gdbm_errno"
Ошибка была бы забавной, если бы не попортила столько нервов...
FreeBSD 7.3
при попытке запустить svnserve получали
/libexec/ld-elf.so.1: /usr/local/lib/libaprutil-0.so.9: Undefined symbol "gdbm_errno"
Вроде не так и страшно... но что это, проблемы с ld-elf.so.1? Пробуем обновить мир.. и на стадии make buildworld получаем ошибки сборки. Уже хуже...
Переустановка gdbm не помогает, portupgrade _вдруг_ начинает вылетать с ошибками и ругаться на make
Решение оказалось.. неожиданным.
root:/usr/src# mv /usr/local/lib/libaprutil-0.so.9 /usr/local/lib/libaprutil-0.so9
root:/usr/src# /usr/local/etc/rc.d/svnserve start
Starting svnserve.
root:/usr/src#
Вот так вообще левая библиотека может ломать работу всей системы.
FreeBSD 7.3
при попытке запустить svnserve получали
/libexec/ld-elf.so.1: /usr/local/lib/libaprutil-0.so.9: Undefined symbol "gdbm_errno"
Вроде не так и страшно... но что это, проблемы с ld-elf.so.1? Пробуем обновить мир.. и на стадии make buildworld получаем ошибки сборки. Уже хуже...
Переустановка gdbm не помогает, portupgrade _вдруг_ начинает вылетать с ошибками и ругаться на make
Решение оказалось.. неожиданным.
root:/usr/src# mv /usr/local/lib/libaprutil-0.so.9 /usr/local/lib/libaprutil-0.so9
root:/usr/src# /usr/local/etc/rc.d/svnserve start
Starting svnserve.
root:/usr/src#
Вот так вообще левая библиотека может ломать работу всей системы.
Парсер .htaccess в формат nginx
Парсер .htaccess в формат nginx
В целом, вариант как у nginx - "1 конфиг на все сайты, при изменении настроек требуется перезапуск" хорош своей скоростью, но не удобством в обслуживании. Например, если мы предоставляем хостинг клиентам, мы или вынуждены отказаться от nginx, или использовать различные костыли, или настроить nginx в режиме максимально простого прокси, лишаясь почти всех его плюшек. 2 вариант -- различные костыли -- это использование всяких систем управления вроде того же isp manager, но и они не могут оптимальный вариант под каждый сайт делать и просто содержат чуть более умную логику вроде попытки отдачи типовых форматов файлов nginx-ом, а при неуспехе передать апачу, вдруг он обработает (error_page 404 = @fallback;).
Можно сделать совсем простой свой вариант -- каждому сайту свой конфиг, который через include подключается в основной, благо система достаточно вменяема (намёк на тупой bind, который не умеет банально *) и можно прописать include "conf.d/*.conf"; а там к каждому проекту например в корень сделать симлинк. reload делать или по крону или по кнопочке в веб-панельке. А можно повесить хук на *notify... Полуавтоматический вариант -- под типовые движки пишутся свои варианты подключаемого конфига, потом определяем что у нас на бэкенде и подставляем нужный.
Можно формировать эти подключаемые конфиги на основе .htaccess, которые давно используются и являются стандартом. Самая большая проблема в том, что автоматического конвертера в пару строк не сделать -- системы работают совершенно по разному.
Есть онлайн-сервисы: http://www.anilcetin.com/convert-apache-htaccess-to-nginx/, http://winginx.ru/htaccess
Так что по теме заметки -- автоматически очень сложно и всё-равно будет нужна ручная доточка, поэтому правильнее всё-таки взять шаблоны и поправить нужный под проект, пользуясь веб-сервисами как помощниками.
Пример автоперевода и как это должно выглядеть тут:
http://rulkov.ru/htaccess-perevodim-v-nginx-conf/
А с готовыми шаблонами получается сложнее, гугл ничего толкового не выдал. Возможно, на этой неделе заведу на том же гитхабе репу и закидаю туда несколько вариантов...
О преобразовании есть и на офсайте, с примером для mongrel:
http://nginx.org/en/docs/http/converting_rewrite_rules.html
http://vds-admin.ru/nginx/zamena-rewriterule-v-nginx-dlya-razlichnykh-cms
http://wiki.opennet.ru/Nginx
В целом, вариант как у nginx - "1 конфиг на все сайты, при изменении настроек требуется перезапуск" хорош своей скоростью, но не удобством в обслуживании. Например, если мы предоставляем хостинг клиентам, мы или вынуждены отказаться от nginx, или использовать различные костыли, или настроить nginx в режиме максимально простого прокси, лишаясь почти всех его плюшек. 2 вариант -- различные костыли -- это использование всяких систем управления вроде того же isp manager, но и они не могут оптимальный вариант под каждый сайт делать и просто содержат чуть более умную логику вроде попытки отдачи типовых форматов файлов nginx-ом, а при неуспехе передать апачу, вдруг он обработает (error_page 404 = @fallback;).
Можно сделать совсем простой свой вариант -- каждому сайту свой конфиг, который через include подключается в основной, благо система достаточно вменяема (намёк на тупой bind, который не умеет банально *) и можно прописать include "conf.d/*.conf"; а там к каждому проекту например в корень сделать симлинк. reload делать или по крону или по кнопочке в веб-панельке. А можно повесить хук на *notify... Полуавтоматический вариант -- под типовые движки пишутся свои варианты подключаемого конфига, потом определяем что у нас на бэкенде и подставляем нужный.
Можно формировать эти подключаемые конфиги на основе .htaccess, которые давно используются и являются стандартом. Самая большая проблема в том, что автоматического конвертера в пару строк не сделать -- системы работают совершенно по разному.
Есть онлайн-сервисы: http://www.anilcetin.com/convert-apache-htaccess-to-nginx/, http://winginx.ru/htaccess
Так что по теме заметки -- автоматически очень сложно и всё-равно будет нужна ручная доточка, поэтому правильнее всё-таки взять шаблоны и поправить нужный под проект, пользуясь веб-сервисами как помощниками.
Пример автоперевода и как это должно выглядеть тут:
http://rulkov.ru/htaccess-perevodim-v-nginx-conf/
А с готовыми шаблонами получается сложнее, гугл ничего толкового не выдал. Возможно, на этой неделе заведу на том же гитхабе репу и закидаю туда несколько вариантов...
О преобразовании есть и на офсайте, с примером для mongrel:
http://nginx.org/en/docs/http/converting_rewrite_rules.html
http://vds-admin.ru/nginx/zamena-rewriterule-v-nginx-dlya-razlichnykh-cms
http://wiki.opennet.ru/Nginx
nice: Badly formed number
FreeBSD, csh, не работает nice.
Вывод: использовать полный путь или использовать другие шеллы. Говорят, в tcsh такая же бага.
# nice -n -5 date nice: Badly formed number. # which nice nice: shell built-in command. # whereis nice nice: /usr/bin/nice /usr/share/man/man1/nice.1.gz /usr/src/usr.bin/nice # /usr/bin/nice usage: nice [-n increment] utility [argument ...] # /usr/bin/nice -n 5 date Mon Apr 23 00:41:03 MSK 2012
Вывод: использовать полный путь или использовать другие шеллы. Говорят, в tcsh такая же бага.
вторник, 10 апреля 2012 г.
freebsd+gmirror - иногда может зависать...
Предыстория. Сервер "отпал". ребутнули и подключили квм. Снова завис, начали смотреть:
Apr 10 12:11:36 r3 kernel: ad6: FAILURE - READ_DMA48 status=51 error=40 LBA=987795712
Apr 10 12:11:36 r3 kernel: GEOM_MIRROR: Request failed (error=5). ad6[READ(offset=505751404544, length=131072)]
При этом
То есть почему-то выпадал ad4, может при ребуте, фря любит терять диски из зеркала. Пытается перестроить массив, попадает на дефектный блок на "нормальном" диске... Не понимает, обижается и перестает отвечать. И это совсем печально, потому что диски системные, используются только для системы и бэкапов и днём они не загружены, основные данные на других дисках с zfs, где всё в порядке.
Apr 10 12:11:36 r3 kernel: ad6: FAILURE - READ_DMA48 status=51
Apr 10 12:11:36 r3 kernel: GEOM_MIRROR: Request failed (error=5). ad6[READ(offset=505751404544, length=131072)]
При этом
> gmirror status
Name Status Components
mirror/gm0 DEGRADED ad4 (SYNCHRONIZING, 83%)
ad6 (ACTIVE)
То есть почему-то выпадал ad4, может при ребуте, фря любит терять диски из зеркала. Пытается перестроить массив, попадает на дефектный блок на "нормальном" диске... Не понимает, обижается и перестает отвечать. И это совсем печально, потому что диски системные, используются только для системы и бэкапов и днём они не загружены, основные данные на других дисках с zfs, где всё в порядке.
понедельник, 9 апреля 2012 г.
nginx: балансировка и отказоустойчивость
Делается балансировка через модуль upstream, пример на сайте
В апстрим имя сервера указываем без префикса протокола (http), иначе ругнётся. Протокол указывается в proxy_pass.
weight=5 - указывает вес сервера, по умолчанию 1. Означает, что на этот сервер будет отправлено 5 запросов, после чего будет выбран следующий сервер.
max_fails=3 - сколько может быть неудачных попыток за время fail_timeout, после чего сервер будет помечен как сломанный и временно (на время fail_timeout) исключен из списка. Если не задано, по умолчанию 1 попытка. 0 отключает эту проверку.
fail_timeout=30s - см. max_fails. По умолчанию 10 сек.
down - пометить сервер как нерабочий. Применяется в связке с ip_hash, чтобы не сломать распределение айпи по серверам.
backup - Применяется в связке основные сервера + резервные (например, в облаке с оплатой ресурсов), задействуются, когда нет серверов без этой опции - основные по max_fails временно отпали. Не может применяться с ip_hash.
Нет вменяемого механизма для логгирования переключений и отказов. Как костыль - задействовать log_module и потом парсить лог спец формата:
Замечание про location / {
Дело в том, что нельзя просто сослаться на локейшн, но есть именованные "области" (error_page 404 = @fallback;) или можно попробовать через alias
location ~"..." {
alias /var/www/vhost$name; }
Но совсем красивого решения я пока не вижу, поэтому пока делается 2 секции на / и для всех ссылающихся частей и через include описывается единая система.
upstream backend {
server backend1.example.com weight=5;
server backend2.example.com:8080 max_fails=3 fail_timeout=30s;
server unix:/tmp/backend3;
}
server {
location / {
proxy_pass http://backend;
}
}
В апстрим имя сервера указываем без префикса протокола (http), иначе ругнётся. Протокол указывается в proxy_pass.
weight=5 - указывает вес сервера, по умолчанию 1. Означает, что на этот сервер будет отправлено 5 запросов, после чего будет выбран следующий сервер.
max_fails=3 - сколько может быть неудачных попыток за время fail_timeout, после чего сервер будет помечен как сломанный и временно (на время fail_timeout) исключен из списка. Если не задано, по умолчанию 1 попытка. 0 отключает эту проверку.
fail_timeout=30s - см. max_fails. По умолчанию 10 сек.
down - пометить сервер как нерабочий. Применяется в связке с ip_hash, чтобы не сломать распределение айпи по серверам.
backup - Применяется в связке основные сервера + резервные (например, в облаке с оплатой ресурсов), задействуются, когда нет серверов без этой опции - основные по max_fails временно отпали. Не может применяться с ip_hash.
Нет вменяемого механизма для логгирования переключений и отказов. Как костыль - задействовать log_module и потом парсить лог спец формата:
log_format timing '$remote_addr - $remote_user [$time_local] $request ' 'upstream_response_time $upstream_response_time ' 'msec $msec request_time $request_time'; log_format up_head '$remote_addr - $remote_user [$time_local] $request ' 'upstream_http_content_type $upstream_http_content_type';(c линка наверху)
Замечание про location / {
Дело в том, что нельзя просто сослаться на локейшн, но есть именованные "области" (error_page 404 = @fallback;) или можно попробовать через alias
location ~"..." {
alias /var/www/vhost$name; }
Но совсем красивого решения я пока не вижу, поэтому пока делается 2 секции на / и для всех ссылающихся частей и через include описывается единая система.
воскресенье, 8 апреля 2012 г.
percona toolkit
Percona Toolkit
Замена maatkit-у, также может быть заменой mysqltuner.
Есть предположение, что работает только с последними версиями мускуля, в частности на штатном 5.0 может не заработать, ниже - не работает почти наверняка. Но надо проверить.
Percona Toolkit is a collection of advanced command-line tools used by Percona support staff to perform a variety of MySQL and system tasks that are too difficult or complex to perform manually, including:
Verify master and replica data consistency
Efficiently archive rows
Find duplicate indexes
Summarize MySQL servers
Analyze queries from logs and tcpdump
Collect vital system information when problems occur
Tools are a vital part of any MySQL deployment, so it's important to use ones that are reliable and well-designed. Over 4,000 tests and several years of deployment, including some of the Internet's best-known sites, have proven the reliability of the tools in Percona Toolkit. And the combined experience and expertise of Percona ensures that each tool is well thought-out and designed.
Percona Toolkit is derived from Maatkit and Aspersa, two of the best-known utility toolkits for MySQL server administration.
Замена maatkit-у, также может быть заменой mysqltuner.
Есть предположение, что работает только с последними версиями мускуля, в частности на штатном 5.0 может не заработать, ниже - не работает почти наверняка. Но надо проверить.
Percona Toolkit is a collection of advanced command-line tools used by Percona support staff to perform a variety of MySQL and system tasks that are too difficult or complex to perform manually, including:
Verify master and replica data consistency
Efficiently archive rows
Find duplicate indexes
Summarize MySQL servers
Analyze queries from logs and tcpdump
Collect vital system information when problems occur
Tools are a vital part of any MySQL deployment, so it's important to use ones that are reliable and well-designed. Over 4,000 tests and several years of deployment, including some of the Internet's best-known sites, have proven the reliability of the tools in Percona Toolkit. And the combined experience and expertise of Percona ensures that each tool is well thought-out and designed.
Percona Toolkit is derived from Maatkit and Aspersa, two of the best-known utility toolkits for MySQL server administration.
Ставим percona
Как ни странно, на сайте описаны все полезные варианты.
Варианты - под дебиан и центось + есть готовые rpm пакеты.
centos
rpm -Uhv http://www.percona.com/downloads/percona-release/percona-release-0.0-1.`uname -m`.rpm
Дальше можно yum makecache и ставить.
debian
gpg --keyserver hkp://keys.gnupg.net --recv-keys 1C4CBDCDCD2EFD2A
gpg -a --export CD2EFD2A | sudo apt-key add -
sudo echo 'deb http://repo.percona.com/apt squeeze main' >>/etc/apt/sources.list
sudo echo 'deb-src http://repo.percona.com/apt squeeze main' >>/etc/apt/sources.list
apt-get update
Варианты - под дебиан и центось + есть готовые rpm пакеты.
centos
rpm -Uhv http://www.percona.com/downloads/percona-release/percona-release-0.0-1.`uname -m`.rpm
Дальше можно yum makecache и ставить.
debian
gpg --keyserver hkp://keys.gnupg.net --recv-keys 1C4CBDCDCD2EFD2A
gpg -a --export CD2EFD2A | sudo apt-key add -
sudo echo 'deb http://repo.percona.com/apt squeeze main' >>/etc/apt/sources.list
sudo echo 'deb-src http://repo.percona.com/apt squeeze main' >>/etc/apt/sources.list
apt-get update
Подписаться на:
Сообщения (Atom)