При проксировании 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
суббота, 7 апреля 2012 г.
Немного про mysqli
Вот отличия MySQLi от MySQL.
1. Поддержка двойного синтаксиса: функциональный и объектно-ориентированный.
2. Поддержка подготовленных операторов.
3. Поддержка транзакций.
4. Поддержка множественных запросов.
5. Расширенная поддержка отладки.
6. Встроенная серверная поддержка.
MySQLi – новая версия расширения MySQL
Объектно-ориентированный интерфейс
Поддержка предварительно объявляемых операторов
Поддержка множественных операторов
Поддержка транзакций
Расширенная поддержка отладки
http://ru.wikipedia.org/wiki/MySQLi
http://habrahabr.ru/search/?q=[mysqli]&target_type=posts
1. Поддержка двойного синтаксиса: функциональный и объектно-ориентированный.
2. Поддержка подготовленных операторов.
3. Поддержка транзакций.
4. Поддержка множественных запросов.
5. Расширенная поддержка отладки.
6. Встроенная серверная поддержка.
MySQLi – новая версия расширения MySQL
Объектно-ориентированный интерфейс
Поддержка предварительно объявляемых операторов
Поддержка множественных операторов
Поддержка транзакций
Расширенная поддержка отладки
http://ru.wikipedia.org/wiki/MySQLi
http://habrahabr.ru/search/?q=[mysqli]&target_type=posts
четверг, 5 апреля 2012 г.
VRRP
Поддержка протокола Virtual Router Redundancy Protocol (VRRP)
Коммутаторы DXS-3326GSR поддерживают протокол Virtual Router Redundancy Protocol (VRRP), позволяющий нескольким коммутаторам 3-го уровня локальной сети использовать один IP адрес. При этом один из коммутаторов будет выбран ведущим, а остальные будут играть роль резервных, на случай выхода из строя ведущего. Поддержка VRRP обеспечивает удобство при настройке IP параметров рабочей станции, не требуя изменения IP адреса шлюза по умолчанию, при выходе из строя устройства, выполняющего маршрутизацию.
Коммутаторы DXS-3326GSR поддерживают протокол Virtual Router Redundancy Protocol (VRRP), позволяющий нескольким коммутаторам 3-го уровня локальной сети использовать один IP адрес. При этом один из коммутаторов будет выбран ведущим, а остальные будут играть роль резервных, на случай выхода из строя ведущего. Поддержка VRRP обеспечивает удобство при настройке IP параметров рабочей станции, не требуя изменения IP адреса шлюза по умолчанию, при выходе из строя устройства, выполняющего маршрутизацию.
openjdk6 и freebsd
Небольшая заметка:
Не совсем понятно, нужно ли оно и зачем. Хотя procfs иногда подключаем.
И небольшое ЗЫ. При первой установке сервер повис (по всей видимости, был кернел паник) - пинговался, но все соединения сбрасывал. Поскольку это не совсем настоящий сервер, диагностировать удаленно не получилось, ехать куда-то в 4 часа ночи тоже желания никакого. Заказали ручную перезагрузку кнопкой.
Вторая попытка - поставилось нормально. хз что это было.
===> Checking if java/openjdk6 already installed
======================================================================
This OpenJDK implementation requires fdescfs(5) mounted on /dev/fd and
procfs(5) mounted on /proc.
If you have not done it yet, please do the following:
mount -t fdescfs fdesc /dev/fd
mount -t procfs proc /proc
To make it permanent, you need the following lines in /etc/fstab:
fdesc /dev/fd fdescfs rw 0 0
proc /proc procfs rw 0 0
Не совсем понятно, нужно ли оно и зачем. Хотя procfs иногда подключаем.
И небольшое ЗЫ. При первой установке сервер повис (по всей видимости, был кернел паник) - пинговался, но все соединения сбрасывал. Поскольку это не совсем настоящий сервер, диагностировать удаленно не получилось, ехать куда-то в 4 часа ночи тоже желания никакого. Заказали ручную перезагрузку кнопкой.
Вторая попытка - поставилось нормально. хз что это было.
Подписаться на:
Сообщения (Atom)