Re: [freebsd] Re: panic: Solaris(panic): zfs: allocating allocated segment

2013-06-27 Пенетрантность George L. Yermulnik
Hello!

On Thu, 27 Jun 2013 at 20:15:55 (+0300), Sergey Rudenko wrote:

> >> После того, как под Solaris я вытянул данные, ребутнулся в FreeBSD и пул
> >> опять стал online без каких-либо намёков на панику или диски.
> >> Мистика или магическая сила Solaris его "вылечила".
> > Сезонное... У нас неделю назад тоже вылетел сервер в кернел паник.
> > Рибуты планомерно заканчивались паникой сразу после инициализации
> > кернелом рейд-контроллера. При этом сервер годами работал и никаких
> > изменений в его конфигурации не было. Выключили, подняли сервис на
> > бэкапе. На следующий день приволокли его на профилактику - включился,
> > как ни в чём не бывало... Замечу, zfs там нет, поэтому применить
> > магический livecd с соляркой не пришлось =)

> Я с подобным сталкивался много раз. Помогало обесточивание на 5-10 

Тоже надеялся на такой исход, но, к сожалению, сотрудник хостера
воспринял мою просьбу "выключить на пару минут и включить", как
"рибутнуть". В общем, так сказать, "сложности перевода" =) Теперь сервер
"отдыхает" вместо резервного =)

> минут. То-ли в кондёрах остаточное напряжение поддерживало в памяти 
> какие-то данные то-ли что-то в этом роде.

-- 
George L. Yermulnik
[YZ-RIPE]


Re: [freebsd] Re: panic: Solaris(panic): zfs: allocating allocated segment

2013-06-27 Пенетрантность Sergey Rudenko

27.06.2013 15:53, George L. Yermulnik пишет:

Hello!

On Thu, 27 Jun 2013 at 15:42:58 (+0300), skeletor wrote:


После того, как под Solaris я вытянул данные, ребутнулся в FreeBSD и пул
опять стал online без каких-либо намёков на панику или диски.
Мистика или магическая сила Solaris его "вылечила".

Сезонное... У нас неделю назад тоже вылетел сервер в кернел паник.
Рибуты планомерно заканчивались паникой сразу после инициализации
кернелом рейд-контроллера. При этом сервер годами работал и никаких
изменений в его конфигурации не было. Выключили, подняли сервис на
бэкапе. На следующий день приволокли его на профилактику - включился,
как ни в чём не бывало... Замечу, zfs там нет, поэтому применить
магический livecd с соляркой не пришлось =)

Я с подобным сталкивался много раз. Помогало обесточивание на 5-10 
минут. То-ли в кондёрах остаточное напряжение поддерживало в памяти 
какие-то данные то-ли что-то в этом роде.


--
WBR,
Сергей Руденко



Re: [freebsd] perl-after-upgrade

2013-06-27 Пенетрантность Taras Heychenko

On 27 июня 2013, at 16:37, Sayetsky Anton  wrote:

> 27 июня 2013 г., 16:30 пользователь Taras Heychenko
>  написал:
>> Ни у какой консоли памяти на такое количество строк не хватит.
> Ну не знаю, у меня SC_BUFFER_SIZE=1024, в Konsole = 1.
> Нигде не стоит более 1к пакетов, что гарантирует то, что результаты
> влезут в буфер даже на физической консоли.

Да, там все оказалось несколько проще. Из-за того, что практически все пакеты 
были уже пересобраны (ошибка была в предпоследнем, от которого зависел 
последний не пересобранный), я решил, что он выдал только те непересобранные 
пакеты, которые составляли дерево зависимостей для пакета, в котором была 
ошибка. А оказалось он показал таки все непересобранные. :)

--
Taras Heychenko





Re: [freebsd] perl-after-upgrade

2013-06-27 Пенетрантность Sayetsky Anton
27 июня 2013 г., 16:30 пользователь Taras Heychenko
 написал:
> Ни у какой консоли памяти на такое количество строк не хватит.
Ну не знаю, у меня SC_BUFFER_SIZE=1024, в Konsole = 1.
Нигде не стоит более 1к пакетов, что гарантирует то, что результаты
влезут в буфер даже на физической консоли.


Re: [freebsd] perl-after-upgrade

2013-06-27 Пенетрантность Volodymyr Kostyrko

27.06.2013 16:27, Anton Yuzhaninov написав(ла):

On 06/27/13 17:09, Taras Heychenko wrote:

И еще один интересный вопрос. Запустил я portupgrade -rf
perl-threaded. Трудился он, трудился, а после чего слетел по ошибке в
одном из портов. Я конечно ошибку поправлю. Но запускать заново
пересобирать все как-то не хотелось бы… Насколько я понимаю, с такими
опциями portupgrade будет таки все зависящее пересобирать. Есть идеи,
как можно избежать повторного перебора всего, уже собранного?


Рекомендую перейти на portmaster - если в середине пересборки N портов
случится ошибка, он перед выходом напишет список портов, которые не
успел пересобрать.


И если перезапустить с теми же параметрами скажет что в прошлый раз 
обралось не всё и предложит продолжить. Опция -R.


--
Sphinx of black quartz, judge my vow.


Re: [freebsd] perl-after-upgrade

2013-06-27 Пенетрантность Taras Heychenko

On 27 июня 2013, at 16:26, Sayetsky Anton  wrote:

> 27 июня 2013 г., 16:23 пользователь Taras Heychenko
>  написал:
>> Для этого должен быть выхлоп. Я (может и не прав, но речь не об этом) 
>> результаты его работы никуда не перенаправлял.
> А вот это зря... Надо ж было включить лог или хотя бы консоль не закрывать.

Ни у какой консоли памяти на такое количество строк не хватит.

> 
> В таком случае можно попробовать примерно следующее:
> portupgrade -frn perl-threaded (n - ничего не делать)
> Полученный список скормить find с ключом -mtime, результирующий список
> скормить portupgrade.

Ну т.е. то, что я и предполагал в изначальном письме. Спасибо за напоминание 
про mtime у find. :)

--
Taras Heychenko





Re: [freebsd] perl-after-upgrade

2013-06-27 Пенетрантность George L. Yermulnik
Hello!

On Thu, 27 Jun 2013 at 17:27:12 (+0400), Anton Yuzhaninov wrote:

> On 06/27/13 17:09, Taras Heychenko wrote:
> > И еще один интересный вопрос. Запустил я portupgrade -rf perl-threaded. 
> > Трудился он, трудился, а после чего слетел по ошибке в одном из портов. Я 
> > конечно ошибку поправлю. Но запускать заново пересобирать все как-то не 
> > хотелось бы??? Насколько я понимаю, с такими опциями portupgrade будет таки 
> > все зависящее пересобирать. Есть идеи, как можно избежать повторного 
> > перебора всего, уже собранного?

> Рекомендую перейти на portmaster - если в середине пересборки N портов 
> случится 
> ошибка, он перед выходом напишет список портов, которые не успел пересобрать.

portupgrade делает то же самое.

-- 
George L. Yermulnik
[YZ-RIPE]


Re: [freebsd] perl-after-upgrade

2013-06-27 Пенетрантность Alexey Markov

Hello, Taras!
On June, 27 2013 at 17:09 you wrote to freebsd@uafug.org.ua:

TH> И еще один интересный вопрос. Запустил я portupgrade -rf perl-threaded.
TH> Трудился он, трудился, а после чего слетел по ошибке в одном из портов.
TH> Я конечно ошибку поправлю. Но запускать заново пересобирать все как-то
TH> не хотелось бы… Насколько я понимаю, с такими опциями portupgrade будет
TH> таки все зависящее пересобирать. Есть идеи, как можно избежать
TH> повторного перебора всего, уже собранного? (Наверное можно отделить
TH> пересобранные пакеты по дате модификации соответствующего каталога в
TH> /var/db/pkg. Но дальше два списка приводить к одному виду, сравнивать
TH> diff'ом и пересобирать непересобранные? Можно, но может есть более
TH> простой путь?)

А вот в portmaster для этого есть ключик -R ;-P

--
WBR, Alexey Markov. 



Re: [freebsd] perl-after-upgrade

2013-06-27 Пенетрантность Sayetsky Anton
27 июня 2013 г., 16:27 пользователь Anton Yuzhaninov  написал:
> Рекомендую перейти на portmaster - если в середине пересборки N портов
> случится ошибка, он перед выходом напишет список портов, которые не успел
> пересобрать.
Не согласен с рекомендацией. См. "Listing the results" в конце выхлопа
portupgrade. Проблема в том, что ТС не сохранил выхлоп, как я понял.


Re: [freebsd] perl-after-upgrade

2013-06-27 Пенетрантность Sayetsky Anton
27 июня 2013 г., 16:23 пользователь Taras Heychenko
 написал:
> Для этого должен быть выхлоп. Я (может и не прав, но речь не об этом) 
> результаты его работы никуда не перенаправлял.
А вот это зря... Надо ж было включить лог или хотя бы консоль не закрывать.

В таком случае можно попробовать примерно следующее:
portupgrade -frn perl-threaded (n - ничего не делать)
Полученный список скормить find с ключом -mtime, результирующий список
скормить portupgrade.


Re: [freebsd] perl-after-upgrade

2013-06-27 Пенетрантность Anton Yuzhaninov

On 06/27/13 17:09, Taras Heychenko wrote:

И еще один интересный вопрос. Запустил я portupgrade -rf perl-threaded. 
Трудился он, трудился, а после чего слетел по ошибке в одном из портов. Я 
конечно ошибку поправлю. Но запускать заново пересобирать все как-то не 
хотелось бы… Насколько я понимаю, с такими опциями portupgrade будет таки все 
зависящее пересобирать. Есть идеи, как можно избежать повторного перебора 
всего, уже собранного?


Рекомендую перейти на portmaster - если в середине пересборки N портов случится 
ошибка, он перед выходом напишет список портов, которые не успел пересобрать.


Re: [freebsd] FIN_WAIT_1 ?? ????? DDoS

2013-06-27 Пенетрантность Oleg V. Nauman

Quoting Alexey Markov :



Hello, Oleg!
On June, 27 2013 at 16:13 you wrote to freebsd@uafug.org.ua:

??>> Есть некий веб-сервер под FreeBSD 8.3 на базе nginx и самописной
??>> CMS на Руби. В обычное время число соединений на нём выглядит

OVN>   Эту самую CMS обучить работать через local socket

Зачем? С CMS устанавливается всего по одному соединению на каждый
инстанс Юникорна, их в общем объёме даже под лупой не видно.

??>> Собственно, вопрос такой: будет ли ipfw считать соединения в состоянии
??>> FIN_WAIT_1 как "всё ещё установленные", и тем самым можно ли
??>> ограничить их число через limit src-addr ? И стоит ли в этом случае
??>> увеличить

OVN> С Немалой долей вероятности это приведет к росту числа соединений в
OVN> состояниях FIN_WAIT_2 и TIME_WAIT

М-м-м... Каким образом это произойдёт, если файрвол просто не даст боту
_создавать_ новые соединения?


 Или с той же вероятностью не давать нормально закрыть соединение.
Я бы не стал гарантированно утверждать, что время жизни динамического  
правила firewall с точностью учитывает все аспекты жизни данного  
конкретного соединения.




OVN> Достаточно большое количество соединений в TIME_WAIT как раз скорее
OVN> всего из-зв вмешательства firewall в процесс закрытия соединения.

Какое отношение файрвол имеет к TIME_WAIT? Насколько я помню, в этом
состоянии соединение просто ждёт "опоздавшие" пакеты в течение 2*MSL
миллисекунд, после чего переводит соединение в состояние CLOSED.


 Насколько я понимаю, TIME_WAIT будет отсчитываться заново после  
каждой неудачной попытки дождаться ACK на посланный FIN




--
WBR, Alexey Markov.




Re: [freebsd] perl-after-upgrade

2013-06-27 Пенетрантность Taras Heychenko

On 27 июня 2013, at 16:19, Andrey Blochintsev  wrote:

> Hi!
> 
> On Thu, Jun 27, 2013 at 16:09 +0300, Taras Heychenko wrote:
> 
>> On 27 июня 2013, at 15:21, Taras Heychenko  wrote:
>>> 
>>> Обновление модулей, дело конечно нужное и понятное. Но у меня exim и vim не 
>>> хотели работать из-за невозможности найти libperl.so. Что для меня менее 
>>> очевидно, чем поиск модулей.
>> 
>> И еще один интересный вопрос. Запустил я portupgrade -rf perl-threaded. 
>> Трудился он, трудился, а после чего слетел по ошибке в одном из портов. Я 
>> конечно ошибку поправлю. Но запускать заново пересобирать все как-то не 
>> хотелось бы? Насколько я понимаю, с такими опциями portupgrade будет таки 
>> все зависящее пересобирать. Есть идеи, как можно избежать повторного 
>> перебора всего, уже собранного? (Наверное можно отделить пересобранные 
>> пакеты по дате модификации соответствующего каталога в /var/db/pkg. Но 
>> дальше два списка приводить к одному виду, сравнивать diff'ом и пересобирать 
>> непересобранные? Можно, но может есть более простой путь?)
> 
> 
> Варианты на выбор:
> Добавить ключик -i, и отвечать "вручную" что пересобирать, а что нет. Много и 
> скучно...
> Не обламывать portupgrade ВСЮ малину, а потом по финальнму отчету посмотреть, 
> что не 
> обновилось/сломалось, и в следующий раз делать "portupgrade -rf 
> то-что-не-обновлялось-в-прошлый-раз".

Я бы ему и не обламывал. Он сам обломился на сборке одного из пакетов. :(

--
Taras Heychenko





Re: [freebsd] perl-after-upgrade

2013-06-27 Пенетрантность Taras Heychenko

On 27 июня 2013, at 16:11, Sayetsky Anton  wrote:

> 27 июня 2013 г., 16:09 пользователь Taras Heychenko
>  написал:
>> On 27 июня 2013, at 15:21, Taras Heychenko  wrote:
>>> 
>>> Обновление модулей, дело конечно нужное и понятное. Но у меня exim и vim не 
>>> хотели работать из-за невозможности найти libperl.so. Что для меня менее 
>>> очевидно, чем поиск модулей.
>> 
>> И еще один интересный вопрос. Запустил я portupgrade -rf perl-threaded. 
>> Трудился он, трудился, а после чего слетел по ошибке в одном из портов. Я 
>> конечно ошибку поправлю. Но запускать заново пересобирать все как-то не 
>> хотелось бы... Насколько я понимаю, с такими опциями portupgrade будет таки 
>> все зависящее пересобирать. Есть идеи, как можно избежать повторного 
>> перебора всего, уже собранного? (Наверное можно отделить пересобранные 
>> пакеты по дате модификации соответствующего каталога в /var/db/pkg. Но 
>> дальше два списка приводить к одному виду, сравнивать diff'ом и пересобирать 
>> непересобранные? Можно, но может есть более простой путь?)
> Это же элементарно. Берём выхлоп portupgrade (результаты выполнения),
> выкидываем всё с + (успешно собрано), скармливаем на второй проход
> оставшееся.

Для этого должен быть выхлоп. Я (может и не прав, но речь не об этом) 
результаты его работы никуда не перенаправлял.

--
Taras Heychenko





Re: [freebsd] Re: [freebsd] FIN_WAIT_1 �� ����� DDoS

2013-06-27 Пенетрантность Alexey Markov

Hello, Sergey!
On June, 27 2013 at 16:40 you wrote to Alexey Markov:

??>> reset_timedout_connection в конфиге nginx уже включен, а от
??>> limit_conn_zone толку не много: даже нормальные клиенты иногда
??>> устанавливают до 10 соединений при скачивании
??>> картинок/скриптов/стилей, а по 10 соединений на каждого бота дают в
??>> сумме до фига. Впрочем, это я тоже использую, но без особого эффекта.
??>>
SVD> не правда, не 10. Если мне склероз не изменяет, то максимум 8 у
SVD> последнего ie, и еще у кого-то, по умолчанию.

8 или 10 - это не принципиально. Хотя я часто натыкался на различные
"улучшатели Интернета", тупо увеличивающие максимальное число соединений
для IE с 4 до 10.

--
WBR, Alexey Markov. 



Re: [freebsd] perl-after-upgrade

2013-06-27 Пенетрантность Andrey Blochintsev
Hi!

On Thu, Jun 27, 2013 at 16:09 +0300, Taras Heychenko wrote:

> On 27 июня 2013, at 15:21, Taras Heychenko  wrote:
> > 
> > Обновление модулей, дело конечно нужное и понятное. Но у меня exim и vim не 
> > хотели работать из-за невозможности найти libperl.so. Что для меня менее 
> > очевидно, чем поиск модулей.
> 
> И еще один интересный вопрос. Запустил я portupgrade -rf perl-threaded. 
> Трудился он, трудился, а после чего слетел по ошибке в одном из портов. Я 
> конечно ошибку поправлю. Но запускать заново пересобирать все как-то не 
> хотелось бы? Насколько я понимаю, с такими опциями portupgrade будет таки все 
> зависящее пересобирать. Есть идеи, как можно избежать повторного перебора 
> всего, уже собранного? (Наверное можно отделить пересобранные пакеты по дате 
> модификации соответствующего каталога в /var/db/pkg. Но дальше два списка 
> приводить к одному виду, сравнивать diff'ом и пересобирать непересобранные? 
> Можно, но может есть более простой путь?)


Варианты на выбор:
Добавить ключик -i, и отвечать "вручную" что пересобирать, а что нет. Много и 
скучно...
Не обламывать portupgrade ВСЮ малину, а потом по финальнму отчету посмотреть, 
что не 
обновилось/сломалось, и в следующий раз делать "portupgrade -rf 
то-что-не-обновлялось-в-прошлый-раз".



Re: [freebsd] perl-after-upgrade

2013-06-27 Пенетрантность Sayetsky Anton
27 июня 2013 г., 16:09 пользователь Taras Heychenko
 написал:
> On 27 июня 2013, at 15:21, Taras Heychenko  wrote:
>>
>> Обновление модулей, дело конечно нужное и понятное. Но у меня exim и vim не 
>> хотели работать из-за невозможности найти libperl.so. Что для меня менее 
>> очевидно, чем поиск модулей.
>
> И еще один интересный вопрос. Запустил я portupgrade -rf perl-threaded. 
> Трудился он, трудился, а после чего слетел по ошибке в одном из портов. Я 
> конечно ошибку поправлю. Но запускать заново пересобирать все как-то не 
> хотелось бы... Насколько я понимаю, с такими опциями portupgrade будет таки 
> все зависящее пересобирать. Есть идеи, как можно избежать повторного перебора 
> всего, уже собранного? (Наверное можно отделить пересобранные пакеты по дате 
> модификации соответствующего каталога в /var/db/pkg. Но дальше два списка 
> приводить к одному виду, сравнивать diff'ом и пересобирать непересобранные? 
> Можно, но может есть более простой путь?)
Это же элементарно. Берём выхлоп portupgrade (результаты выполнения),
выкидываем всё с + (успешно собрано), скармливаем на второй проход
оставшееся.


Re: [freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] FIN_WAIT_1 во время DDoS

2013-06-27 Пенетрантность Sergey V. Dyatko
On Thu, 27 Jun 2013 16:02:41 +0300
Sayetsky Anton  wrote:

> 27 июня 2013 г., 15:58 пользователь Sergey V. Dyatko
>  написал:
> > не так давно как раз и ковырялся с кол-вом одновременных
> > коннектов у разных браузеров. опера (не могильная) их 6 или 8
> > открывала, per server, по дефолту.
> ОРЛЫ? Пруф по ссылке - http://rghost.ru/47054323.view
> 
хм. запустил на десктопе оперу и правда, якобы 16 по дефолту, но у меня
там почему-то 8 стоит. не могу вспомнить, чтобы я менял это значение. 

ff. about:config -> network.http.max-persistent-connections-per-server
6 у меня, firefox-esr

> > ОТ: сам я перешел на ff на ноутбуке, назад на оперу не
> > вернулся т.к. лень заморачиваться с вытаскиванием сохраненных в ff
> > паролях к сайтам. уходил от оперы т.к. она штатно не умела socks до
> > недавних версий
> Не храните в браузере пОроли. Для этого есть KeePassX ;)
а насколько удобно их копи-пастить если в монитор смотрит > 1 пар
глаз?;)



-- 
wbr, tiger


Re: [freebsd] perl-after-upgrade

2013-06-27 Пенетрантность Lena
> Запустил я portupgrade -rf
> perl-threaded. Трудился он, трудился, а после чего слетел по ошибке
> в одном из портов. Я конечно ошибку поправлю. Но запускать заново
> пересобирать все как-то не хотелось бы? Насколько я понимаю, с
> такими опциями portupgrade будет таки все зависящее пересобирать.
> Есть идеи, как можно избежать повторного перебора всего, уже собранного?

portupgrade -x perl\* -x '>perl-threaded' -rf perl\*



Re: [freebsd] perl-after-upgrade

2013-06-27 Пенетрантность Taras Heychenko
On 27 июня 2013, at 15:21, Taras Heychenko  wrote:
> 
> Обновление модулей, дело конечно нужное и понятное. Но у меня exim и vim не 
> хотели работать из-за невозможности найти libperl.so. Что для меня менее 
> очевидно, чем поиск модулей.

И еще один интересный вопрос. Запустил я portupgrade -rf perl-threaded. 
Трудился он, трудился, а после чего слетел по ошибке в одном из портов. Я 
конечно ошибку поправлю. Но запускать заново пересобирать все как-то не 
хотелось бы… Насколько я понимаю, с такими опциями portupgrade будет таки все 
зависящее пересобирать. Есть идеи, как можно избежать повторного перебора 
всего, уже собранного? (Наверное можно отделить пересобранные пакеты по дате 
модификации соответствующего каталога в /var/db/pkg. Но дальше два списка 
приводить к одному виду, сравнивать diff'ом и пересобирать непересобранные? 
Можно, но может есть более простой путь?)

> 
> --
> Taras Heychenko
> 
> 
> 

--
Taras Heychenko





Re: [freebsd] perl-after-upgrade

2013-06-27 Пенетрантность Lena
> > pkg_info | grep perl
> > записать версию x.x.x
> > portupgrade -f perl\* p5-\*
> > locate x.x.x | less
> 
> locate как-бы не сразу обновляет свою базу...

Конечно. Я же написала "Посмотреть, что осталось в найденных директориях",
а не посмотреть, что нашлось командой locate.
Мне не пришло в голову, что нужно подробнее разжевать, что смотреть нужно
не в выводе locate, а (с помощью mc или ls) содержимое директорий,
которые найдутся командой locate.

> > Посмотреть, что осталось в найденных директориях, и их portupgrade -f


Re: [freebsd] Re: [freebsd] Re: [freebsd] FIN_WAIT_1 �� ����� DDoS

2013-06-27 Пенетрантность Alexey Markov

Hello, Sayetsky!
On June, 27 2013 at 16:46 you wrote to Рассылка FreeBSD UA:

??>> Но, как я понимаю, соединения в состоянии FIN_WAIT_1 к nginx уже
??>> отношения не имеют - он закрыл соединение через close() и теперь
??>> система ждёт подтверждения закрытия от клиента. А боты, как известно,
??>> вежливостью не обременены. Вот я и думаю, как бы ограничить для ботов
??>> возможность создавать новые соединения, ещё на уровне транспорта?
SA> Ещё можно посмотреть на http accept filter.

Да, тоже уже используются. Но засада в том, что запросы от ботов идут
вполне валидные, так что http accept filter здесь не помогает. :-(

--
WBR, Alexey Markov. 



[freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] FIN_WAIT_1 во время DDoS

2013-06-27 Пенетрантность Sayetsky Anton
27 июня 2013 г., 15:58 пользователь Sergey V. Dyatko
 написал:
> не так давно как раз и ковырялся с кол-вом одновременных
> коннектов у разных браузеров. опера (не могильная) их 6 или 8
> открывала, per server, по дефолту.
ОРЛЫ? Пруф по ссылке - http://rghost.ru/47054323.view

> ОТ: сам я перешел на ff на ноутбуке, назад на оперу не
> вернулся т.к. лень заморачиваться с вытаскиванием сохраненных в ff
> паролях к сайтам. уходил от оперы т.к. она штатно не умела socks до
> недавних версий
Не храните в браузере пОроли. Для этого есть KeePassX ;)


Re: [freebsd] Re: [freebsd] Re: [freebsd] FIN_WAIT_1 во время DDoS

2013-06-27 Пенетрантность Sergey V. Dyatko
On Thu, 27 Jun 2013 15:47:59 +0300
Sayetsky Anton  wrote:

> 27 июня 2013 г., 15:40 пользователь Sergey V. Dyatko
> > не правда, не 10. Если мне склероз не изменяет, то максимум 8 у
> > последнего ie, и еще у кого-то, по умолчанию.
> Те, кто используют жОперу вместо браузера, создают уже много лет до 16
> коннектов на сервер.

не так давно как раз и ковырялся с кол-вом одновременных
коннектов у разных браузеров. опера (не могильная) их 6 или 8
открывала, per server, по дефолту.
впрочем, там уж много лет как это значение можно изменить штатно,
через опции, не то что в заменителях браузеров ;-)

ОТ: сам я перешел на ff на ноутбуке, назад на оперу не
вернулся т.к. лень заморачиваться с вытаскиванием сохраненных в ff
паролях к сайтам. уходил от оперы т.к. она штатно не умела socks до
недавних версий

-- 
wbr, tiger


Re: [freebsd] Re: panic: Solaris(panic): zfs: allocating allocated segment

2013-06-27 Пенетрантность George L. Yermulnik
Hello!

On Thu, 27 Jun 2013 at 15:42:58 (+0300), skeletor wrote:

> После того, как под Solaris я вытянул данные, ребутнулся в FreeBSD и пул 
> опять стал online без каких-либо намёков на панику или диски.
> Мистика или магическая сила Solaris его "вылечила".

Сезонное... У нас неделю назад тоже вылетел сервер в кернел паник.
Рибуты планомерно заканчивались паникой сразу после инициализации
кернелом рейд-контроллера. При этом сервер годами работал и никаких
изменений в его конфигурации не было. Выключили, подняли сервис на
бэкапе. На следующий день приволокли его на профилактику - включился,
как ни в чём не бывало... Замечу, zfs там нет, поэтому применить
магический livecd с соляркой не пришлось =)

-- 
George L. Yermulnik
[YZ-RIPE]


Re: [freebsd] FIN_WAIT_1 во время DDoS

2013-06-27 Пенетрантность Anton Yuzhaninov

On 06/27/13 15:53, Alexey Markov wrote:


И что теперь? Тупо задирать размеры буферов, очереди и maxfiles, пока боты
не выдохнутся? :-(


В общем случае да.
Система настроенная на максимальную производительность позволяет не замечать 
меленькие DoS-ы.


[freebsd] Re: [freebsd] Re: [freebsd] FIN_WAIT_1 во время DDoS

2013-06-27 Пенетрантность Sayetsky Anton
27 июня 2013 г., 15:40 пользователь Sergey V. Dyatko
> не правда, не 10. Если мне склероз не изменяет, то максимум 8 у
> последнего ie, и еще у кого-то, по умолчанию.
Те, кто используют жОперу вместо браузера, создают уже много лет до 16
коннектов на сервер.


[freebsd] Re: [freebsd] Re: [freebsd] FIN_WAIT_1 во время DDoS

2013-06-27 Пенетрантность Sayetsky Anton
27 июня 2013 г., 14:53 пользователь Alexey Markov  написал:
> Но, как я понимаю, соединения в состоянии FIN_WAIT_1 к nginx уже отношения
> не имеют - он закрыл соединение через close() и теперь система ждёт
> подтверждения закрытия от клиента. А боты, как известно, вежливостью не
> обременены. Вот я и думаю, как бы ограничить для ботов возможность создавать
> новые соединения, ещё на уровне транспорта?
Ещё можно посмотреть на http accept filter.


[freebsd] Re: panic: Solaris(panic): zfs: allocating allocated segment

2013-06-27 Пенетрантность skeletor



Всяческие попытки как-то добраться до пула через FreeBSD (Live CD, 8/9)
не увенчались успехом. Загрузился с Solaris 11.1 LiveCD
Сейчас сливаю данные на другой винт. Вот, что сказал Solaris (явно
намекая на тот сбойный винт):

# zpool status
   pool: dpool
  state: DEGRADED
status: One or more devices are unavailable in response to persistent
errors.
 Sufficient replicas exist for the pool to continue functioning
in a
 degraded state.
action: Determine if the device needs to be replaced, and clear the errors
 using 'zpool clear' or 'fmadm repaired', or replace the device
 with 'zpool replace'.
 Run 'zpool status -v' to see device specific details.
   scan: scrub repaired 64K in 0h3m with 0 errors on Sat Jun 22 17:10:17
2013
config:

 NAME STATE READ WRITE CKSUM
 dpoolDEGRADED 0 0 0
   raidz1-0   DEGRADED 0 0 0
 c7t1d0p0 ONLINE   0 0 0
 7844172536082216995  UNAVAIL  0 0 0
 c7t3d0p0 ONLINE   0 0 0

errors: No known data errors




После того, как под Solaris я вытянул данные, ребутнулся в FreeBSD и пул 
опять стал online без каких-либо намёков на панику или диски.

Мистика или магическая сила Solaris его "вылечила".


Re: [freebsd] Re: [freebsd] FIN_WAIT_1 во время DDoS

2013-06-27 Пенетрантность Sergey V. Dyatko
On Thu, 27 Jun 2013 15:53:58 +0400
"Alexey Markov"  wrote:

> Hello, Sayetsky!
> On June, 27 2013 at 14:49 you wrote to Рассылка FreeBSD UA:
> 
> SA> 27 июня 2013 г., 13:45 пользователь Alexey Markov 
> написал:
> ??>>
> ??>> Есть некий веб-сервер под FreeBSD 8.3 на базе nginx и самописной
> ??>> CMS на Руби. В обычное время число соединений на нём выглядит
> ??>> примерно так:
> ??>>
> ??>> Connections:   1404
> ??>>
> ??>> TIME_WAIT  1316
> ??>> ESTABLISHED  70
> ??>> FIN_WAIT_18
> ??>> LAST_ACK  5
> ??>> SYN_RCVD  3
> ??>> FIN_WAIT_21
> ??>> LISTEN1
> ??>>
> ??>> В последнее время на этот веб-сервер повадились набегать боты с
> целью ??>> устроить DDoS. С помощью nginx все ботовые запросы успешно
> отсекались, ??>> но вот с числом соединений творилось неприятное:
> ??>>
> ??>> Connections:  68628
> ??>>
> ??>> FIN_WAIT_144255
> ??>> TIME_WAIT 11944
> ??>> LAST_ACK   6141
> ??>> SYN_RCVD   3687
> ??>> ESTABLISHED1589
> ??>> FIN_WAIT_2  765
> ??>> CLOSING 241
> ??>> CLOSED5
> ??>> LISTEN1
> ??>>
> ??>> Насколько я помню, состояние FIN_WAIT_1 - это когда приложение
> (nginx) ??>> уже закрыло соединение через close(), система послала
> FIN клиенту, а в ??>> ответ - тишина... В итоге, через некоторое
> время общее число ??>> соединений упирается в системный лимит, и все
> остальные клиенты ??>> обламываются. :-(
> ??>>
> ??>> Собственно, вопрос такой: будет ли ipfw считать соединения в
> состоянии ??>> FIN_WAIT_1 как "всё ещё установленные", и тем самым
> можно ли ??>> ограничить их число через limit src-addr ? И стоит
> ли в этом случае ??>> увеличить сразу net.inet.ip.fw.dyn_max с
> дефолтных 8192? ??>>
> SA> Может, для начала покрутить limit_zone, reset_timedout_connection
> SA> etc?
> 
> reset_timedout_connection в конфиге nginx уже включен, а от
> limit_conn_zone толку не много: даже нормальные клиенты иногда
> устанавливают до 10 соединений при скачивании
> картинок/скриптов/стилей, а по 10 соединений на каждого бота дают в
> сумме до фига. Впрочем, это я тоже использую, но без особого эффекта.
> 
не правда, не 10. Если мне склероз не изменяет, то максимум 8 у
последнего ie, и еще у кого-то, по умолчанию.

> Но, как я понимаю, соединения в состоянии FIN_WAIT_1 к nginx уже
> отношения не имеют - он закрыл соединение через close() и теперь
> система ждёт подтверждения закрытия от клиента. А боты, как известно,
> вежливостью не обременены. Вот я и думаю, как бы ограничить для ботов
> возможность создавать новые соединения, ещё на уровне транспорта?
> 



-- 
wbr, tiger


Re: [freebsd] FIN_WAIT_1 �� ����� DDoS

2013-06-27 Пенетрантность Alexey Markov

Hello, Anton!
On June, 27 2013 at 15:13 you wrote to freebsd@uafug.org.ua:

??>> Насколько я помню, состояние FIN_WAIT_1 - это когда приложение (nginx)
??>> уже закрыло соединение через close(), система послала FIN клиенту, а в
??>> ответ - тишина... В итоге, через некоторое время общее число
??>> соединений упирается в системный лимит, и все остальные клиенты
??>> обламываются. :-(

AY> Либо nginx послал FYN на бэкенд (ruby) и не получил ответ.

Не, я посмотрел по netstat -an, там все соединения только с внешнего адреса.

А с движком, как я понял, устанавливается по одному соединению на каждый
инстанс Юникорна, и все запросы уже идут по нему, не создавая новых.

AY> net.inet.tcp.nolocaltimewait случаем не используется? У него есть
AY> "особенности" и проще будет его выключить.

Проверил, net.inet.tcp.nolocaltimewait: 0.

??>> Собственно, вопрос такой: будет ли ipfw считать соединения в состоянии
??>> FIN_WAIT_1 как "всё ещё установленные", и тем самым можно ли
??>> ограничить их число через limit src-addr ? И стоит ли в этом случае
??>> увеличить сразу net.inet.ip.fw.dyn_max с дефолтных 8192?

AY> ipfw в случае DoS ресурсов будет расходовать не меньше чем экономить, я
AY> рекомендую его отключить совсем.

Вот было у меня такое подозрение... :-/

И что теперь? Тупо задирать размеры буферов, очереди и maxfiles, пока боты
не выдохнутся? :-(

AY> 1. Нужно потюнить sysctl/tunables чтобы сервер мог обслуживать
AY> достаточное число коннекций. Немножко про это есть тут:
AY> http://webcrunch.ru/library/equipment/clusters/tuning-freebsd/
AY> хотя часть из того. что там написано уже устарело, так что это больше
AY> следует воспринимать не как готовый рецепт, а как подсказку, на что
AY> обратить внимание.

Да, с классическим выступлением Сысоева я давно уже ознакомился. Часть
даже успел реализовать. Буду кури^W читать дальше.

AY> На одном из моих серверов такие настройки:
AY> http://paste.org.ru/?mp3z7j (в nginx 
worker_processes*worker_connections*2

AY> должно быть меньше kern.ipc.maxsockets).

О, спасибо. Сейчас посмотрю, что у меня с этими переменными.

AY> 2. Далее можно ограничивать число коннекций / запросов на проксируемые
AY> location средствами nginx.

Это уже делается. Проблема в том, что после того как nginx уже дал отлуп
боту, соединение с тем продолжает висеть в состоянии FIN_WAIT_1, пока ОС
не получит подтверждение закрытия от клиента - а боты, по понятным причинам,
этим себя не утруждают. Причём для FIN_WAIT_1 есть sysctl-ы, которые можно
покрутить (и я их уже покрутил!):

net.inet.tcp.finwait2_timeout=5000
net.inet.tcp.fast_finwait2_recycle=1

а вот для FIN_WAIT_1 я ничего не нашёл. :-(

--
WBR, Alexey Markov. 



Re: [freebsd] perl-after-upgrade

2013-06-27 Пенетрантность Taras Heychenko
On 27 июня 2013, at 13:14, Anton Yuzhaninov  wrote:
> 
> perl-after-upgrade больше не нужен.
> 
> Для обновления 5.16.3 -> 5.16.x (x > 3) пересобирать модули не нужно будет.
> 
> Раньше модули устанавливались в папку x.y.z и для обновления 5.16.0 на 5.16.1 
> нужно было запускать perl-after-upgrade чтобы он переместил установленные 
> модули из директории 5.16.0 в 5.16.1
> 
> Сейчас модули ставятся в x.y и если при обновлении перла меняется только 
> последняя цифра никаких дополнительных действий не потребуется.
> 
> Для обновления с x.y на x.z (например с 5.16 на 5.18) все равно придется 
> пересобирать все модули, как минимум потому что меняется ABI для XS-модулей.


Обновление модулей, дело конечно нужное и понятное. Но у меня exim и vim не 
хотели работать из-за невозможности найти libperl.so. Что для меня менее 
очевидно, чем поиск модулей.

--
Taras Heychenko





Re: [freebsd] FIN_WAIT_1 ?? ????? DDoS

2013-06-27 Пенетрантность Alexey Markov


Hello, Oleg!
On June, 27 2013 at 16:13 you wrote to freebsd@uafug.org.ua:

??>> Есть некий веб-сервер под FreeBSD 8.3 на базе nginx и самописной
??>> CMS на Руби. В обычное время число соединений на нём выглядит

OVN>   Эту самую CMS обучить работать через local socket

Зачем? С CMS устанавливается всего по одному соединению на каждый
инстанс Юникорна, их в общем объёме даже под лупой не видно.

??>> Собственно, вопрос такой: будет ли ipfw считать соединения в состоянии
??>> FIN_WAIT_1 как "всё ещё установленные", и тем самым можно ли
??>> ограничить их число через limit src-addr ? И стоит ли в этом случае
??>> увеличить

OVN> С Немалой долей вероятности это приведет к росту числа соединений в
OVN> состояниях FIN_WAIT_2 и TIME_WAIT

М-м-м... Каким образом это произойдёт, если файрвол просто не даст боту
_создавать_ новые соединения?

OVN> Достаточно большое количество соединений в TIME_WAIT как раз скорее
OVN> всего из-зв вмешательства firewall в процесс закрытия соединения.

Какое отношение файрвол имеет к TIME_WAIT? Насколько я помню, в этом
состоянии соединение просто ждёт "опоздавшие" пакеты в течение 2*MSL
миллисекунд, после чего переводит соединение в состояние CLOSED.

--
WBR, Alexey Markov. 



Re: [freebsd] Re: [freebsd] FIN_WAIT_1 �� ����� DDoS

2013-06-27 Пенетрантность Alexey Markov

Hello, Sayetsky!
On June, 27 2013 at 14:49 you wrote to Рассылка FreeBSD UA:

SA> 27 июня 2013 г., 13:45 пользователь Alexey Markov 
написал:
??>>
??>> Есть некий веб-сервер под FreeBSD 8.3 на базе nginx и самописной
??>> CMS на Руби. В обычное время число соединений на нём выглядит
??>> примерно так:
??>>
??>> Connections:   1404
??>>
??>> TIME_WAIT  1316
??>> ESTABLISHED  70
??>> FIN_WAIT_18
??>> LAST_ACK  5
??>> SYN_RCVD  3
??>> FIN_WAIT_21
??>> LISTEN1
??>>
??>> В последнее время на этот веб-сервер повадились набегать боты с целью
??>> устроить DDoS. С помощью nginx все ботовые запросы успешно отсекались,
??>> но вот с числом соединений творилось неприятное:
??>>
??>> Connections:  68628
??>>
??>> FIN_WAIT_144255
??>> TIME_WAIT 11944
??>> LAST_ACK   6141
??>> SYN_RCVD   3687
??>> ESTABLISHED1589
??>> FIN_WAIT_2  765
??>> CLOSING 241
??>> CLOSED5
??>> LISTEN1
??>>
??>> Насколько я помню, состояние FIN_WAIT_1 - это когда приложение (nginx)
??>> уже закрыло соединение через close(), система послала FIN клиенту, а в
??>> ответ - тишина... В итоге, через некоторое время общее число
??>> соединений упирается в системный лимит, и все остальные клиенты
??>> обламываются. :-(
??>>
??>> Собственно, вопрос такой: будет ли ipfw считать соединения в состоянии
??>> FIN_WAIT_1 как "всё ещё установленные", и тем самым можно ли
??>> ограничить их число через limit src-addr ? И стоит ли в этом случае
??>> увеличить сразу net.inet.ip.fw.dyn_max с дефолтных 8192?
??>>
SA> Может, для начала покрутить limit_zone, reset_timedout_connection etc?

reset_timedout_connection в конфиге nginx уже включен, а от limit_conn_zone
толку не много: даже нормальные клиенты иногда устанавливают до 10
соединений при скачивании картинок/скриптов/стилей, а по 10 соединений на
каждого бота дают в сумме до фига. Впрочем, это я тоже использую, но без
особого эффекта.

Но, как я понимаю, соединения в состоянии FIN_WAIT_1 к nginx уже отношения
не имеют - он закрыл соединение через close() и теперь система ждёт
подтверждения закрытия от клиента. А боты, как известно, вежливостью не
обременены. Вот я и думаю, как бы ограничить для ботов возможность создавать
новые соединения, ещё на уровне транспорта?

--
WBR, Alexey Markov. 



Re: [freebsd] FIN_WAIT_1 ?? ????? DDoS

2013-06-27 Пенетрантность Oleg V. Nauman

Quoting Alexey Markov :


Всем, всего, и много!

Есть некий веб-сервер под FreeBSD 8.3 на базе nginx и самописной
CMS на Руби. В обычное время число соединений на нём выглядит


 Эту самую CMS обучить работать через local socket


примерно так:

Connections:   1404

TIME_WAIT  1316
ESTABLISHED  70
FIN_WAIT_18
LAST_ACK  5
SYN_RCVD  3
FIN_WAIT_21
LISTEN1

В последнее время на этот веб-сервер повадились набегать боты с целью
устроить DDoS. С помощью nginx все ботовые запросы успешно отсекались,
но вот с числом соединений творилось неприятное:

Connections:  68628

FIN_WAIT_144255
TIME_WAIT 11944
LAST_ACK   6141
SYN_RCVD   3687
ESTABLISHED1589
FIN_WAIT_2  765
CLOSING 241
CLOSED5
LISTEN1

Насколько я помню, состояние FIN_WAIT_1 - это когда приложение (nginx)
уже закрыло соединение через close(), система послала FIN клиенту, а в
ответ - тишина... В итоге, через некоторое время общее число соединений
упирается в системный лимит, и все остальные клиенты обламываются. :-(

Собственно, вопрос такой: будет ли ipfw считать соединения в состоянии
FIN_WAIT_1 как "всё ещё установленные", и тем самым можно ли ограничить
их число через limit src-addr ? И стоит ли в этом случае увеличить


 С Немалой долей вероятности это приведет к росту числа соединений в  
состояниях FIN_WAIT_2 и TIME_WAIT
 Достаточно большое количество соединений в TIME_WAIT как раз скорее  
всего из-зв вмешательства firewall в процесс закрытия соединения.



сразу net.inet.ip.fw.dyn_max с дефолтных 8192?

--
WBR, Alexey Markov.




Re: [freebsd] perl-after-upgrade

2013-06-27 Пенетрантность George L. Yermulnik
Hello!

On Thu, 27 Jun 2013 at 15:18:23 (+0400), Lystopad Aleksandr wrote:

> locate как-бы не сразу обновляет свою базу...
> так что идея не очень удачная.

У меня фактически на всех серверах
daily_local="/etc/periodic/weekly/310.locate" в /etc/periodic.conf
Так как-то удобнее =)

-- 
George L. Yermulnik
[YZ-RIPE]


Re: [freebsd] perl-after-upgrade

2013-06-27 Пенетрантность Anton Yuzhaninov

On 06/27/13 15:18, Lystopad Aleksandr wrote:

pkg_info | grep perl
записать версию x.x.x
portupgrade -f perl\* p5-\*
locate x.x.x | less


locate как-бы не сразу обновляет свою базу...
так что идея не очень удачная.


Посмотреть, что осталось в найденных директориях, и их portupgrade -f


Лучше
pkg which -g '*/site_perl/5.16.2/*'
или
fgrep -r '/site_perl/5.16.2/' /var/db/pkg/

где 5.16.2 версия, который была до обновления.


Re: [freebsd] perl-after-upgrade

2013-06-27 Пенетрантность Lystopad Aleksandr
 Hello, l...@lena.kiev.ua!

On Thu, Jun 27, 2013 at 12:49:21PM +0300
l...@lena.kiev.ua wrote about "Re: [freebsd] perl-after-upgrade":
> > Кто подскажет насчет обновления perl'а. Раньше была такая удобная штучка,
> > как perl-after-upgrade, запуск которой после обновления perl'а, сохранял 
> > работоспособность
> > других пакетов, зависящих от perl. Сейчас его убрали. Как результат после 
> > обновления перла
> > у меня лично поломались exim и vim (с остальным еще не разобрался). Как 
> > теперь малой кровью
> > обновлять перл без пересборки всех пакетов, от которых он зависит?
> 
> pkg_info | grep perl
> записать версию x.x.x
> portupgrade -f perl\* p5-\*
> locate x.x.x | less

locate как-бы не сразу обновляет свою базу...
так что идея не очень удачная.

> Посмотреть, что осталось в найденных директориях, и их portupgrade -f

-- 
 Lystopad Aleksandr 


Re: [freebsd] FIN_WAIT_1 во время DDoS

2013-06-27 Пенетрантность Anton Yuzhaninov

On 06/27/13 14:45, Alexey Markov wrote:


Насколько я помню, состояние FIN_WAIT_1 - это когда приложение (nginx)
уже закрыло соединение через close(), система послала FIN клиенту, а в
ответ - тишина... В итоге, через некоторое время общее число соединений
упирается в системный лимит, и все остальные клиенты обламываются. :-(



Либо nginx послал FYN на бэкенд (ruby) и не получил ответ.

net.inet.tcp.nolocaltimewait случаем не используется? У него есть "особенности" 
и проще будет его выключить.




Собственно, вопрос такой: будет ли ipfw считать соединения в состоянии
FIN_WAIT_1 как "всё ещё установленные", и тем самым можно ли ограничить
их число через limit src-addr ? И стоит ли в этом случае увеличить
сразу net.inet.ip.fw.dyn_max с дефолтных 8192?


ipfw в случае DoS ресурсов будет расходовать не меньше чем экономить, я 
рекомендую его отключить совсем.


1. Нужно потюнить sysctl/tunables чтобы сервер мог обслуживать достаточное число 
коннекций. Немножко про это есть тут:

http://webcrunch.ru/library/equipment/clusters/tuning-freebsd/
хотя часть из того. что там написано уже устарело, так что это больше следует 
воспринимать не как готовый рецепт, а как подсказку, на что обратить внимание.


На одном из моих серверов такие настройки:
http://paste.org.ru/?mp3z7j (в nginx worker_processes*worker_connections*2 
должно быть меньше kern.ipc.maxsockets).


2. Далее можно ограничивать число коннекций / запросов на проксируемые location 
средствами nginx.


А какой объем RAM на сервере? 68628 сокетов это не так уже и много...


[freebsd] Re: [freebsd] FIN_WAIT_1 во время DDoS

2013-06-27 Пенетрантность Sayetsky Anton
27 июня 2013 г., 13:45 пользователь Alexey Markov  написал:
> Всем, всего, и много!
>
> Есть некий веб-сервер под FreeBSD 8.3 на базе nginx и самописной
> CMS на Руби. В обычное время число соединений на нём выглядит
> примерно так:
>
> Connections:   1404
>
> TIME_WAIT  1316
> ESTABLISHED  70
> FIN_WAIT_18
> LAST_ACK  5
> SYN_RCVD  3
> FIN_WAIT_21
> LISTEN1
>
> В последнее время на этот веб-сервер повадились набегать боты с целью
> устроить DDoS. С помощью nginx все ботовые запросы успешно отсекались,
> но вот с числом соединений творилось неприятное:
>
> Connections:  68628
>
> FIN_WAIT_144255
> TIME_WAIT 11944
> LAST_ACK   6141
> SYN_RCVD   3687
> ESTABLISHED1589
> FIN_WAIT_2  765
> CLOSING 241
> CLOSED5
> LISTEN1
>
> Насколько я помню, состояние FIN_WAIT_1 - это когда приложение (nginx)
> уже закрыло соединение через close(), система послала FIN клиенту, а в
> ответ - тишина... В итоге, через некоторое время общее число соединений
> упирается в системный лимит, и все остальные клиенты обламываются. :-(
>
> Собственно, вопрос такой: будет ли ipfw считать соединения в состоянии
> FIN_WAIT_1 как "всё ещё установленные", и тем самым можно ли ограничить
> их число через limit src-addr ? И стоит ли в этом случае увеличить
> сразу net.inet.ip.fw.dyn_max с дефолтных 8192?
>
> --
> WBR, Alexey Markov.
Может, для начала покрутить limit_zone, reset_timedout_connection etc?


[freebsd] FIN_WAIT_1 �� ����� DDoS

2013-06-27 Пенетрантность Alexey Markov

Всем, всего, и много!

Есть некий веб-сервер под FreeBSD 8.3 на базе nginx и самописной
CMS на Руби. В обычное время число соединений на нём выглядит
примерно так:

Connections:   1404

TIME_WAIT  1316
ESTABLISHED  70
FIN_WAIT_18
LAST_ACK  5
SYN_RCVD  3
FIN_WAIT_21
LISTEN1

В последнее время на этот веб-сервер повадились набегать боты с целью
устроить DDoS. С помощью nginx все ботовые запросы успешно отсекались,
но вот с числом соединений творилось неприятное:

Connections:  68628

FIN_WAIT_144255
TIME_WAIT 11944
LAST_ACK   6141
SYN_RCVD   3687
ESTABLISHED1589
FIN_WAIT_2  765
CLOSING 241
CLOSED5
LISTEN1

Насколько я помню, состояние FIN_WAIT_1 - это когда приложение (nginx)
уже закрыло соединение через close(), система послала FIN клиенту, а в
ответ - тишина... В итоге, через некоторое время общее число соединений
упирается в системный лимит, и все остальные клиенты обламываются. :-(

Собственно, вопрос такой: будет ли ipfw считать соединения в состоянии
FIN_WAIT_1 как "всё ещё установленные", и тем самым можно ли ограничить
их число через limit src-addr ? И стоит ли в этом случае увеличить
сразу net.inet.ip.fw.dyn_max с дефолтных 8192?

--
WBR, Alexey Markov. 



Re: [freebsd] perl-after-upgrade

2013-06-27 Пенетрантность Anton Yuzhaninov

On 06/27/13 14:08, grayich wrote:

пересобирать с перлом сотни p5- и прочего
я ж правильно понял, что perl-after-upgrade возвращать не планируют


perl-after-upgrade больше не нужен.

Для обновления 5.16.3 -> 5.16.x (x > 3) пересобирать модули не нужно будет.

Раньше модули устанавливались в папку x.y.z и для обновления 5.16.0 на 5.16.1 
нужно было запускать perl-after-upgrade чтобы он переместил установленные модули 
из директории 5.16.0 в 5.16.1


Сейчас модули ставятся в x.y и если при обновлении перла меняется только 
последняя цифра никаких дополнительных действий не потребуется.


Для обновления с x.y на x.z (например с 5.16 на 5.18) все равно придется 
пересобирать все модули, как минимум потому что меняется ABI для XS-модулей.


Re: [freebsd] perl-after-upgrade

2013-06-27 Пенетрантность Sergey V. Dyatko
On Thu, 27 Jun 2013 13:08:44 +0300
grayich  wrote:

> 
> > как "так"?
> пересобирать с перлом сотни p5- и прочего
> я ж правильно понял, что perl-after-upgrade возвращать не планируют

необходимость в нем пропала после того, как убрали patchlevel 
при смене minor да, придется пересобрать все ПО. это очевидно.

-- 
wbr, tiger


Re: [freebsd] perl-after-upgrade

2013-06-27 Пенетрантность grayich

> как "так"?
пересобирать с перлом сотни p5- и прочего
я ж правильно понял, что perl-after-upgrade возвращать не планируют


Re: [freebsd] perl-after-upgrade

2013-06-27 Пенетрантность Sergey V. Dyatko
On Thu, 27 Jun 2013 12:48:24 +0300
grayich  wrote:

> 
> 
> 
> > less ${PORTSDIR}/UPDATING
> > /20130612
> 
> это теперь каждый раз так делать, чтоли?
> 
> 

как "так"?

-- 
wbr, tiger


Re: [freebsd] perl-after-upgrade

2013-06-27 Пенетрантность George L. Yermulnik
Hello!

On Thu, 27 Jun 2013 at 12:48:24 (+0300), grayich wrote:

> > less ${PORTSDIR}/UPDATING
> > /20130612

> это теперь каждый раз так делать, чтоли?

12:50:09 [yz@yz][w:1][j:0][~]> head -7 /usr/ports/UPDATING
This file documents some of the problems you may encounter when upgrading
your ports.  We try our best to minimize these disruptions, but sometimes
they are unavoidable.

You should get into the habit of checking this file for changes each time
you update your ports collection, before attempting any port upgrades.



-- 
George L. Yermulnik
[YZ-RIPE]


Re: [freebsd] perl-after-upgrade

2013-06-27 Пенетрантность grayich



> less ${PORTSDIR}/UPDATING
> /20130612

это теперь каждый раз так делать, чтоли?




Re: [freebsd] perl-after-upgrade

2013-06-27 Пенетрантность Lena
> Кто подскажет насчет обновления perl'а. Раньше была такая удобная штучка,
> как perl-after-upgrade, запуск которой после обновления perl'а, сохранял 
> работоспособность
> других пакетов, зависящих от perl. Сейчас его убрали. Как результат после 
> обновления перла
> у меня лично поломались exim и vim (с остальным еще не разобрался). Как 
> теперь малой кровью
> обновлять перл без пересборки всех пакетов, от которых он зависит?

pkg_info | grep perl
записать версию x.x.x
portupgrade -f perl\* p5-\*
locate x.x.x | less
Посмотреть, что осталось в найденных директориях, и их portupgrade -f


Re: [freebsd] perl-after-upgrade

2013-06-27 Пенетрантность Sayetsky Anton
27 июня 2013 г., 11:22 пользователь Sergey V. Dyatko
 написал:
> libreoffice, если не ошибаюсь, хочет перд тредовый
Ошибаетесь.
jason@jw:~$ egrep "^OPTIONS_DEFAULT" !$
egrep "^OPTIONS_DEFAULT" /usr/ports/lang/perl5.14/Makefile
OPTIONS_DEFAULT= PERL_64BITINT PTHREAD USE_PERL
Тогда бы LO не собирался с дефолтными опциями.


Re: [freebsd] perl-after-upgrade

2013-06-27 Пенетрантность Sayetsky Anton
27 июня 2013 г., 11:17 пользователь Alexander Chernyh
 написал:
> кстати, да тогда я б написал
> portupgrade -fr perl\*
Неправильно. Тогда пересоберутся все пакеты, имя которых начинается с
perl, но не только те, которые dependant on perl. Не критично, но
кол-во может быть разным.

> интересно в каких случаях нужен perl-threaded ???
В таких, когда надо писать многопоточные скрипты.


Re: [freebsd] perl-after-upgrade

2013-06-27 Пенетрантность Alexander Chernyh


On 06/27/2013 11:22 AM, Sergey V. Dyatko wrote:

On Thu, 27 Jun 2013 11:17:22 +0300
Alexander Chernyh  wrote:


On 06/27/2013 11:01 AM, Sayetsky Anton wrote:

27 июня 2013 г., 10:41 пользователь Taras Heychenko
 написал:

Я уже писал, что эту команду я запускал. Мне не жалко, запустил
еще раз. Вот все, что она сказала: root@academ:~>portupgrade -rf
perl [Updating the pkgdb  in /var/db/pkg ... -
312 packages found (-0 +2) .. done]

Ну и как я тоже уже писал, это не помешало остаться поломанными
exim'у и vim'у.

А теперь внимательно смотрим, что выдаёт pkg_info | egrep "^perl"
Может быть, он собран с THREADS и посему в системе нет пакета perl,
а есть perl-threaded?

кстати, да тогда я б написал
portupgrade -fr perl\*

интересно в каких случаях нужен perl-threaded ???



libreoffice, если не ошибаюсь, хочет перд тредовый


если опустить иксовое ПО то perl для консольных програм хватает вполне







Re: [freebsd] perl-after-upgrade

2013-06-27 Пенетрантность Sayetsky Anton
27 июня 2013 г., 11:15 пользователь Taras Heychenko
 написал:
> Да, спасибо. Так и есть -- не сообразил, как он смотрит на пакеты. Испытываю 
> некоторый дискомфорт от такой
> массовой пересборки пакетов, но похоже это единственный вменяемый по времени 
> вариант. Еще теперь нужно
> отслеживать, что он пересобрал, чтобы перезапускать то, что было запущено. :(
>
> Спасибо всем за помощь и подсказки.
По имени пакета и смотрит. Было же указано perl без wildcard. Ну, или
можно по port origin обновлять.
Кстати, разве в make.conf не вписаны MAKE_JOBS_NUMBER и FORCE_MAKE_JOBS?


Re: [freebsd] perl-after-upgrade

2013-06-27 Пенетрантность Sergey V. Dyatko
On Thu, 27 Jun 2013 11:17:22 +0300
Alexander Chernyh  wrote:

> 
> On 06/27/2013 11:01 AM, Sayetsky Anton wrote:
> > 27 июня 2013 г., 10:41 пользователь Taras Heychenko
> >  написал:
> >> Я уже писал, что эту команду я запускал. Мне не жалко, запустил
> >> еще раз. Вот все, что она сказала: root@academ:~>portupgrade -rf
> >> perl [Updating the pkgdb  in /var/db/pkg ... -
> >> 312 packages found (-0 +2) .. done]
> >>
> >> Ну и как я тоже уже писал, это не помешало остаться поломанными
> >> exim'у и vim'у.
> > А теперь внимательно смотрим, что выдаёт pkg_info | egrep "^perl"
> > Может быть, он собран с THREADS и посему в системе нет пакета perl,
> > а есть perl-threaded?
> 
> кстати, да тогда я б написал
> portupgrade -fr perl\*
> 
> интересно в каких случаях нужен perl-threaded ???
> 
> 
libreoffice, если не ошибаюсь, хочет перд тредовый



-- 
wbr, tiger


Re: [freebsd] perl-after-upgrade

2013-06-27 Пенетрантность Alexander Chernyh


On 06/27/2013 11:01 AM, Sayetsky Anton wrote:

27 июня 2013 г., 10:41 пользователь Taras Heychenko
 написал:

Я уже писал, что эту команду я запускал. Мне не жалко, запустил еще раз. Вот 
все, что она сказала:
root@academ:~>portupgrade -rf perl
[Updating the pkgdb  in /var/db/pkg ... - 312 packages found 
(-0 +2) .. done]

Ну и как я тоже уже писал, это не помешало остаться поломанными exim'у и vim'у.

А теперь внимательно смотрим, что выдаёт pkg_info | egrep "^perl"
Может быть, он собран с THREADS и посему в системе нет пакета perl, а
есть perl-threaded?


кстати, да тогда я б написал
portupgrade -fr perl\*

интересно в каких случаях нужен perl-threaded ???




Re: [freebsd] perl-after-upgrade

2013-06-27 Пенетрантность Taras Heychenko

On 27 июня 2013, at 11:01, Sayetsky Anton  wrote:

> 27 июня 2013 г., 10:41 пользователь Taras Heychenko
>  написал:
>> Я уже писал, что эту команду я запускал. Мне не жалко, запустил еще раз. Вот 
>> все, что она сказала:
>> root@academ:~>portupgrade -rf perl
>> [Updating the pkgdb  in /var/db/pkg ... - 312 packages 
>> found (-0 +2) .. done]
>> 
>> Ну и как я тоже уже писал, это не помешало остаться поломанными exim'у и 
>> vim'у.
> А теперь внимательно смотрим, что выдаёт pkg_info | egrep "^perl"
> Может быть, он собран с THREADS и посему в системе нет пакета perl, а
> есть perl-threaded?

Да, спасибо. Так и есть -- не сообразил, как он смотрит на пакеты. Испытываю 
некоторый дискомфорт от такой
массовой пересборки пакетов, но похоже это единственный вменяемый по времени 
вариант. Еще теперь нужно
отслеживать, что он пересобрал, чтобы перезапускать то, что было запущено. :( 

Спасибо всем за помощь и подсказки.

--
Taras Heychenko





Re: [freebsd] perl-after-upgrade

2013-06-27 Пенетрантность Sayetsky Anton
27 июня 2013 г., 10:41 пользователь Taras Heychenko
 написал:
> Я уже писал, что эту команду я запускал. Мне не жалко, запустил еще раз. Вот 
> все, что она сказала:
> root@academ:~>portupgrade -rf perl
> [Updating the pkgdb  in /var/db/pkg ... - 312 packages 
> found (-0 +2) .. done]
>
> Ну и как я тоже уже писал, это не помешало остаться поломанными exim'у и 
> vim'у.
А теперь внимательно смотрим, что выдаёт pkg_info | egrep "^perl"
Может быть, он собран с THREADS и посему в системе нет пакета perl, а
есть perl-threaded?


Re: [freebsd] perl-after-upgrade

2013-06-27 Пенетрантность Taras Heychenko

On 27 июня 2013, at 10:32, Alexander Chernyh  wrote:

> 
> On 06/27/2013 10:19 AM, Taras Heychenko wrote:
>>Hi!
>> Кто подскажет насчет обновления perl'а. Раньше была такая удобная штучка,
>> как perl-after-upgrade, запуск которой после обновления perl'а, сохранял 
>> работоспособность
>> других пакетов, зависящих от perl. Сейчас его убрали. Как результат после 
>> обновления перла
>> у меня лично поломались exim и vim (с остальным еще не разобрался). Как 
>> теперь малой кровью
>> обновлять перл без пересборки всех пакетов, от которых он зависит?
>> 
>> --
>> Taras Heychenko
>> 
> без пересборки по-моему никак
> portupgrade -fr perl

Я уже писал, что эту команду я запускал. Мне не жалко, запустил еще раз. Вот 
все, что она сказала:
root@academ:~>portupgrade -rf perl 
[Updating the pkgdb  in /var/db/pkg ... - 312 packages found 
(-0 +2) .. done]

Ну и как я тоже уже писал, это не помешало остаться поломанными exim'у и vim'у.

> 
> так очень хорошо
> 
>> 
> 

--
Taras Heychenko





Re: [freebsd] perl-after-upgrade

2013-06-27 Пенетрантность Taras Heychenko

On 27 июня 2013, at 10:30, Sayetsky Anton  wrote:

> 27 июня 2013 г., 10:19 пользователь Taras Heychenko
>  написал:
>>   Hi!
>> Кто подскажет насчет обновления perl'а. Раньше была такая удобная штучка,
>> как perl-after-upgrade, запуск которой после обновления perl'а, сохранял 
>> работоспособность
>> других пакетов, зависящих от perl. Сейчас его убрали. Как результат после 
>> обновления перла
>> у меня лично поломались exim и vim (с остальным еще не разобрался). Как 
>> теперь малой кровью
>> обновлять перл без пересборки всех пакетов, от которых он зависит?
> less ${PORTSDIR}/UPDATING
> /20130612
> 
> Можно бы было и самостоятельно посмотреть, не так ли? ;)

Я написал уже после того, как на это посмотрел. Команда portupgrade -rf perl 
(как там предложено) не сделала ничего.
Точнее она запустилась и закончилась ничего не сообщив на экран. После чего я 
обнаружил не работающий vim, а
еще через некоторое время не работающий exim.

> Ну и небольшой бонус: sysutils/bsdadminscripts, sysutils/libchk


Сейчас посмотрю на бонус -- может поможет. Потому как vim и exim ругались на 
невозможность обнаружить libperl.so. А 
пакетов, зависящих от perl у меня на машине столько,  что хватит пожалуй на 
сутки непрерывной пересборки.

--
Taras Heychenko





Re: [freebsd] perl-after-upgrade

2013-06-27 Пенетрантность Alexander Chernyh


On 06/27/2013 10:19 AM, Taras Heychenko wrote:

Hi!
Кто подскажет насчет обновления perl'а. Раньше была такая удобная штучка,
как perl-after-upgrade, запуск которой после обновления perl'а, сохранял 
работоспособность
других пакетов, зависящих от perl. Сейчас его убрали. Как результат после 
обновления перла
у меня лично поломались exim и vim (с остальным еще не разобрался). Как теперь 
малой кровью
обновлять перл без пересборки всех пакетов, от которых он зависит?

--
Taras Heychenko


без пересборки по-моему никак
portupgrade -fr perl

так очень хорошо







Re: [freebsd] TYPO3

2013-06-27 Пенетрантность Taras Heychenko

On 26 июня 2013, at 11:00, "George L. Yermulnik"  wrote:

> Hello!
> 
> On Wed, 19 Jun 2013 at 17:45:31 (+0400), Sergey Rudenko wrote:
> 
>> Это скорее всего сказывается то, что Makefile порта в старом формате, а 
>> система
>> у вас видимо хочет options-ng
>> У меня на этом порту даже make config не отрабатывает, сразу кидается ставить
>> зависимости
> 
> Это оно у Вас скорее всего не зависимости ставить кидается, а
> dialog4ports, без которого нынче `make config' не работает.

Чтобы уже закрыть тему. При замене mysqli на pgsql порт действительно не ставит 
mysql и вроде как удовлетворяется постгресом. Только проблема в том, что в
6 версии TYPO3 похоже постгрес нормально не поддерживается. Некоторое, не очень 
продолжительное, чтение интернетов на предмет жизни TYPO3 с postgresql привели 
меня к снесению установленного TYPO3 и переходу к другой CMS.

> 
> -- 
> George L. Yermulnik
> [YZ-RIPE]

--
Taras Heychenko





Re: [freebsd] perl-after-upgrade

2013-06-27 Пенетрантность Sayetsky Anton
27 июня 2013 г., 10:19 пользователь Taras Heychenko
 написал:
>Hi!
> Кто подскажет насчет обновления perl'а. Раньше была такая удобная штучка,
> как perl-after-upgrade, запуск которой после обновления perl'а, сохранял 
> работоспособность
> других пакетов, зависящих от perl. Сейчас его убрали. Как результат после 
> обновления перла
> у меня лично поломались exim и vim (с остальным еще не разобрался). Как 
> теперь малой кровью
> обновлять перл без пересборки всех пакетов, от которых он зависит?
less ${PORTSDIR}/UPDATING
/20130612

Можно бы было и самостоятельно посмотреть, не так ли? ;)
Ну и небольшой бонус: sysutils/bsdadminscripts, sysutils/libchk


[freebsd] perl-after-upgrade

2013-06-27 Пенетрантность Taras Heychenko
   Hi!
Кто подскажет насчет обновления perl'а. Раньше была такая удобная штучка,
как perl-after-upgrade, запуск которой после обновления perl'а, сохранял 
работоспособность
других пакетов, зависящих от perl. Сейчас его убрали. Как результат после 
обновления перла
у меня лично поломались exim и vim (с остальным еще не разобрался). Как теперь 
малой кровью
обновлять перл без пересборки всех пакетов, от которых он зависит?

--
Taras Heychenko