[xeb]

Не вопрос, мыло напомни

xeb@mail.ru

 

Хотя там тащить не чего =) 200 метров 15 минут =))

угу, только я щас на работе, а тут за каждый мегабайт дерут :)

 

[xeb]

http://www.spinics.net/lists/netdev/msg137102.html

http://www.spinics.net/lists/netdev/msg137101.html

http://www.spinics.net/lists/netdev/msg137104.html

[xeb]

commit 91701f793e127433833e4210cdeccebddac1f901

Author: Kozlov Dmitry <dima@server>

Date: Thu Aug 5 14:36:17 2010 +0400

 

using rcu instead read-write lock on 2.6 kernel

[xeb]

commit c30962027d1bd4e93ffd484f4177dee53a36aa1c

Author: Kozlov Dmitry <dima@server>

Date: Thu Aug 5 15:13:58 2010 +0400

 

oops: use rcu_dereference instead of =

чуть не забыл :)

Изменено 5 августа, 2010 пользователем xeb

[theMIROn]

using rcu instead read-write lock on 2.6 kernel

а кроме как на smp это даст хоть какой либо эффект?

[xeb]

а кроме как на smp это даст хоть какой либо эффект?

если и даст, то незначительный

 

[NiTr0]

Итак, pptpd опять внезапно умер на одном из серверов спустя более чем неделю работы. Умер из-за заполнения раздела под логи. Неплохо бы это как-то поправить - нехорошо, когда демон умирает из-за проблем с логированием...

Изменено 13 августа, 2010 пользователем NiTr0

[sfstudio]

Настройте logrotate. Нехорошо когда на разделах заканчивается место особенно так банально на разделе с логами.

[NiTr0]

logrotate работает. Проблема в том что логи на рамдиске (как и все остальное), а snmpd довольно активно гадит в логи :( Хотя и когда несколько глупых роутеров начинают долбиться с интервалом в 5 секунд, игнорируя отлуп по негативному балансу - тоже лог растет как на дрожжах...

[Ivantey]

-Ln в строке запуска snmpd поставь

[sfstudio]

logrotate работает. Проблема в том что логи на рамдиске (как и все остальное), а snmpd довольно активно гадит в логи :(

Дык его и покоцать.

 

Хотя и когда несколько глупых роутеров начинают долбиться с интервалом в 5 секунд, игнорируя отлуп по негативному балансу - тоже лог растет как на дрожжах...

Connlimit на 1723 порт разрешающий новые соединения не чаще 1/мин.

 

Ну и подумать о cramfs не гоже такие бещи без сжатия в памяти держать =)

[NiTr0]

Ivantey

Вариант, но лучше сначала попытаться пропатчить, чтобы не срал сообщениями о дублирующихся адресах на этом конце туннелей.

 

Дык его и покоцать.

И так ежесуточная ротация, и сжатие всего что старее 2 суток...

 

Connlimit на 1723 порт разрешающий новые соединения не чаще 1/мин.

Не поможет - там еще и PPPoE крутится.

 

Ну и подумать о cramfs не гоже такие бещи без сжатия в памяти держать =)

Она же рид-онли, не?

[sfstudio]

Ivantey

Вариант, но лучше сначала попытаться пропатчить, чтобы не срал сообщениями о дублирующихся адресах на этом конце туннелей.

Дык закоментить тады в сырцах сточку если проблема только в этом...

 

Не поможет - там еще и PPPoE крутится.

Для pppoe тоже не сложно родить аналогичный костыль.

 

Она же рид-онли, не?

Да попутал, но вроде была реализация ramfs+lzo

 

В любом случае падение при заполнении раздела лога как бы не проблема демона. Опять же кто мешает его лог вообще в дев нулл завернуть?

 

[NiTr0]

Дык закоментить тады в сырцах сточку если проблема только в этом...

Проблема не только в этом - с снмп демоном на досуге поборюсь еще. Просто в любом случае может быть ситуевина, когда "логово" чем-то загадится под завязку, или когда сислог по некоторым причинам не сможет принять данные на запись (к примеру, рестарт сислога - хоть при его обновлении). Демон при этом издыхать не должен - тем более, что ведение журнала для него - не основная функция :)

 

Для pppoe тоже не сложно родить аналогичный костыль.

iptables вроде как штатно PPPoE не разбирает - придется через match пилить...

 

Да попутал, но вроде была реализация ramfs+lzo

Мне вроде как не попадалось на глаза - хотя особо не искал.

 

В любом случае падение при заполнении раздела лога как бы не проблема демона. Опять же кто мешает его лог вообще в дев нулл завернуть?

Таки проблема. Потому как сислог может к примеру вообще журналировать на другую машину по сети - и при этом при проблемах с машиной, на которую это все будет журналироваться (скажем, плановый ребут) все железки с пптп демонами дружненько поумирают - т.к. не смогут записать в лог событие.

[sfstudio]

Таки проблема. Потому как сислог может к примеру вообще журналировать на другую машину по сети - и при этом при проблемах с машиной, на которую это все будет журналироваться (скажем, плановый ребут) все железки с пптп демонами дружненько поумирают - т.к. не смогут записать в лог событие.

А вот и нифига, при такой задачи это проблема вашего сислог демона а не демона pptp. Кстати у себя везде использую syslog-ng и при переполнении раздела дл ялогов не встречал падений pptpd.

 

Что касается pppoe делаем лимит по тырканью с одного мака и всё.

[NiTr0]

А вот и нифига, при такой задачи это проблема вашего сислог демона а не демона pptp. Кстати у себя везде использую syslog-ng и при переполнении раздела дл ялогов не встречал падений pptpd.

Он и у меня стоит. Что не мешает pptpd падать.

При этом - больше никакие демоны не падают, что наводит на мысли о проблеме именно с pptpd.

[sfstudio]

Ну фиг тады знает почему у вас это происходит. Вообще демоны и незнают что там место кончилось, ну кроме собсно сислога.

[NiTr0]

Первый раз у меня покрашился pptpd из-за превышения кол-ва кооннектов к unix-сокету сислога. Подозреваю, что сислог при окончании места точно так же отфутболивает желающих что-то записать в лог.

Другое дело, что демон не должен от этого дохнуть :)

[nuclearcat]

Nitro - а откуда вы pptpd брали?

 

[martin74]

странно... я как то просмотрел и место на флешках впн серверов кончилось. В результате все клиенты получили инет безлимитный, потому что /var/run/radattr.pppX создаться не могло и соответственно шейпер не строился ;) Но падения pptp не было. Теперь поставил в нагиос мониторинг разделов на основных серверах, и все....

[NiTr0]

Тот, что сейчас крутится - от sfstudio, был стянут где-то в мае с http://sourceforge.net/projects/wive-ng/files/others. И, насколько я понял, его патчи сейчас втянуты в основную ветку.

Изменено 15 августа, 2010 пользователем NiTr0

[sfstudio]

Там ещё не было патчей для pptpd т.е. там он чистый. Из пропатченного в том архиве модуль ядра.

[NiTr0]

Сравнил диффом с каррент 0.8.5 (от 8 августа) - менялся только модуль ядра. Соответственно, проблемы с демоном будут аналогичные.

Изменено 15 августа, 2010 пользователем NiTr0

[xeb]

pppd/pptpd ещё не патчил. Проблему временно можно решить путём увеличения кол-ва коннектов (max-connections в случае syslog-ng).

Вообще щас занимаеюсь переписыванием всего этого "добра", кроме модуля (см. бранч accel-pptpd). На первом этапе планирую запустить только pptp (эдак через месяц-два), ну и заодно клиентский плагин для pppd, хотя, если взгляните одним глазком, то увидите, что вновь разрабатываемый сервер не будет использовать pppd как таковой. На втором этапе - pptp/pppoe/l2tp, т.е. получится что-то типа бздэшного mpd.

Вот, это такой небольшой TODO :)

Что уже сделано (точнее говоря написано, но находится в стадии лабораторного тестирования):

1. модуль управления собственно pptp, в смысле управляющее соединение

2. поднятие ppp интерфейса

3. обмен ppp пакетами

4. согласование параметров по lcp

5. авторизация по pap

Перехожу к ccp и ipcp.

[NiTr0]

pppd/pptpd ещё не патчил. Проблему временно можно решить путём увеличения кол-ва коннектов (max-connections в случае syslog-ng).

Так собссно и сделал.

 

Вообще щас занимаеюсь переписыванием всего этого "добра", кроме модуля (см. бранч accel-pptpd).

Ждем :) Готов буду помочь в тестировании.

 

P.S. Неплохо бы туда еще поддержку CoA/DR пакетов включить - если поможет, я пилил демон для pppd для поддержки всего этого, на базе старенького радиус-сервера (который обеспечивал необходимый для перепиливания функционал, и в то же время имел малый объем кода), конечно выглядит сыровато, везде торчат хвосты старого демона, но все же оно работает, и причем стабильно - не один месяц в продакшне :)

Изменено 16 августа, 2010 пользователем NiTr0