nix: августа 2012

пятница, 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 для внедрения допустим только после тщательных тестов. И минимум несколько лет после массового перехода в протоколе будут находить критические дыры.

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

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

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

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

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

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

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