пятница, 31 августа 2012 г.

freebsd: модульный ipfw - особенность настройки

По умолчанию ipfw в виде модуля работает в режиме запрета, поэтому после включения в rc.conf строкой firewall_enabled=YES можно получить недоступную систему. По живому изменить поведение нельзя:

# sysctl -w net.inet.ip.fw.default_to_accept=1
sysctl: oid 'net.inet.ip.fw.default_to_accept' is a read only tunable
sysctl: Tunable values are set in /boot/loader.conf

Особенность в том, что обычно параметры для sysctl правятся в /etc/sysctl.conf, но не в данном случае! Тут надо вписывать именно в /boot/loader.conf:
net.inet.ip.fw.default_to_accept=1

Вариант 2, не такой красивый и более опасный: в rc.conf
firewall_enable="YES"
#firewall_type="/etc/firewall.conf"
firewall_type="open"

(строка с type="/etc/firewall.conf" закомментирована)
Проблем будет больше, в частности с ipfw -f flush - всё отвалится.

четверг, 30 августа 2012 г.

Fetching 4 new ports or files... gunzip: unknown compression format

Иногда при portsnap fetch update вылезает ошибка
Fetching 4 new ports or files... gunzip: unknown compression format

которую очень сложно поправить. Иногда оно правится удалением базы и повторным выкачиванием (rm -r /var/db/portsnap/*), иногда это не помогает. Причина обычно - какой-то сбой на серверах обновлений, надо выяснить, откуда пытаемся обновиться и забаннить его, например через внесение этого имени в hosts или просто указанием, с какого конкретно сервера хотим обновиться.

среда, 22 августа 2012 г.

selectel: увеличиваем диск

Для паркинга уже была инструкция, теперь для selectel, уже вкратце.

Имеем: отдельный диск под /var/www, расположенный на диске /dev/xvdb, целиком отданным под lvm, с именем vg--www-www (группа vg-www, имя www), путь /dev/vg-www/www

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

Размер в панели уже увеличен.

Для начала, надо будет отмонтировать раздел. (umount)

Смотрим где наш том
pvdisplay

Растянем на весь новый диск.
pvresize /dev/xvdb

pvdisplay
Alloc PE / Size 8191 / 32.00 GiB
Free PE / Size 8192 / 32.00 GiB
Было 32, стало 64. Нормально.

Теперь надо увеличить наш том
# lvextend -l +100%FREE /dev/vg-www/www
Extending logical volume www to 64.00 GiB
Logical volume www successfully resized

И файловую систему.
# resize2fs /dev/vg-www/www
resize2fs 1.41.12 (17-May-2010)
Please run 'e2fsck -f /dev/vg-www/www' first.

# e2fsck -f /dev/vg-www/www
...

# resize2fs /dev/vg-www/www
resize2fs 1.41.12 (17-May-2010)
Resizing the filesystem on /dev/vg-www/www to 16776192 (4k) blocks.

С первого запуска не прошло - надо сначала проверить раздел.
Всё, можно монтировать и работать.

Можно попробовать ptmax, но не совсем понятно, в какое место ей тыкать.
Надо выжать из саппорта селектела их вариант без перезагрузки, пока у меня не получилось.

вторник, 21 августа 2012 г.

400 Bad Request Request Header Or Cookie Too Large

Самое просто решение - почистить куки. Если же сервер наш, можно подкрутить настройки серверов:

для nginx это
large_client_header_buffers 4 8k;

Можно выставить например 16к, но дальше будет ошибка
Your browser sent a request that this server could not understand.
Size of a request header field exceeds server limit.

Потому что надо увеличить эти же значения и для apache
LimitRequestFieldSize 8190

Можно выставить
LimitRequestFieldSize 16380

Но проблема может быть и по другой причине.
Включаем в nginx.conf строку

error_log  /var/log/nginx/error.log info;


И видим в логе

2012/11/28 13:15:42 [info] 77783#0: *1146484 client sent too long header line: "X-Forwarded-For: 1.2.123.24, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, 127.0.0.1, ..." while reading client request headers, client: 127.0.0.1, server: _, request: "GET / HTTP/1.0", host: "site.ru"

Это признаки циклического редиректа, например в proxy_pass указан тот же порт, на котором сидит сам nginx (и так бывает иногда, да)

суббота, 18 августа 2012 г.

Очередная авария в selectel

В 19.10 сегодня (17.08) произошел сбой:

"К сожалению, случилась авария со связностью в сети облака, мы работаем над её устранением. Пострадавшие машины будут перезагружены.
Потерь данных не прогнозируется. "

Видимо, хваленое дублированное СХД не помогло.

До сих пор (18.08, 00:20):
"Пострадавшие виртуальные машины запускаются. Просьба не перезагружать виртуальные машины, их перезагрузка будет крайне замедленной. "
и
"Пострадавшие виртуальные машины запускаются. В результате ошибочной коммутации часть хранилищ оказалась отключенной от хостов виртуализации. Просьба не перезагружать виртуальные машины, их перезагрузка будет крайне замедленной. Компенсация за даунтайм будет предоставлена в начале следующего месяца. Приносим извинения за созданные проблемы. "

понедельник, 6 августа 2012 г.

freebsd и percona mysql

На сегодняшний день перкона-сборка сломана. Есть набор патчей:
http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/164072
Но
1) патчи аж февральские, но до сих пор не втянуты
2) даже после ручного применения могут быть проблемы.

Так что пока или воевать с конфликтами сборки, или ставить пакетами, или использовать пока оф версию или марию (mariadb)

среда, 1 августа 2012 г.

exim, гугл и ipv6

# echo "test www1" | mail -v -s "testing www1" (skip)@gmail.com
LOG: MAIN
  <= root@server.spb.ru U=root P=local S=396

# delivering 1SwU4n-000NDx-Fz
Connecting to gmail-smtp-in.l.google.com [2a00:1450:8005::1a]:25 ... LOG: MAIN PANIC DIE
  unable to parse "2a00:1450:8005::1a" as an IP address: ai_family not supported
LOG: MAIN
  == (skip)@gmail.com R=dnslookup T=remote_smtp defer (-1): smtp transport process returned non-zero status 0x0100: exit code 1
LOG: MAIN
  Frozen

Причина в том, что по какой-то причине система пытается отправить по ipv6, и при невозможности - просто забивает, вместо пробы другого протокола. Может возникнуть в частности при собранном exim с ipv6 и отключенным ипв6 в самой системе.
Решение: ставить exim без поддержки ипв6 или добавить в конфиг опцию
disable_ipv6 = yes
и перезапустить сервис. Мне было проще пересобрать без ipv6 вообще, поскольку всё-равно пока протокол сырой и ещё лет 5 для внедрения допустим только после тщательных тестов. И минимум несколько лет после массового перехода в протоколе будут находить критические дыры.