[Dethman]

Про сислог, флешки и место на насах:

А что мешает выкидывать все логи с наса на внешний сервер ?

У нас насы живут на флешках, да, /etc /tmp /var в тмпфс и каждому по 32 мб отведено ... но туда ничего не пишеться :)

[NiTr0]

Можно конечно... Но опять-таки при падении внешнего сервера помрут все пптп демоны на всех насах, а в журналах - ничего ценного нет. Да и памяти на насах - огромное кол-во ввиду того, что ддр2 менее 1 гига сейчас найти проблемно, а 2-канальный режим тазику совершенно не помешает ;)

Сейчас заглянул на один из насов - менее 500 МБ занято, и это - учитывая логи (256МБ tmpfs).

[Justas]

32-х битная Федора 12, kernel-PAE-2.6.32.11-99.fc12.i686.

 

Jun 17 21:56:44 helium3 pptpd[5262]: CTRL: Client 192.168.22.171 control connection started
Jun 17 21:56:44 helium3 pptpd[5262]: CTRL: Starting call (launching pppd, opening GRE)
Jun 17 21:56:44 helium3 pppd[5263]: Plugin /usr/lib/pptpd/pptpd-logwtmp.so loaded.
Jun 17 21:56:44 helium3 pptp[5263]: Plugin pptp.so loaded.
Jun 17 21:56:44 helium3 pptp[5263]: PPTP plugin version 0.8.4 compiled for pppd-2.4.3, linux-2.6.32.11-99.fc12.i686.PAE
Jun 17 21:56:44 helium3 pptp[5263]: pppd 2.4.3 started by root, uid 0
Jun 17 21:56:44 helium3 pptp[5263]: Couldn't create new ppp unit: Cannot allocate memory
Jun 17 21:56:44 helium3 pptp[5263]: Exit.
Jun 17 21:56:44 helium3 kernel: PPP: couldn't register device ppp751 (-12)
Jun 17 21:56:44 helium3 pptpd[5262]: CTRL: Client pppd TERM sending
Jun 17 21:56:44 helium3 pptpd[5262]: CTRL: Client pppd finish wait
Jun 17 21:56:44 helium3 pptpd[5262]: CTRL: Client 192.168.22.171 control connection finished

 

pptp не может выделить память, а ядро не может зарегистрировать интерфейс.

 

Сталкивался ли кто?

 

Сменил ядро на 2.6.33 - проблема не ушла. Уже все глаза просмотрел - не знаю, че ему надо. Памяти хватает - 2ГБ оперативной и 2ГБ своп, занято 40%. Поднимает не более 751 интерфейса. Гугл молчит. Сервер INPRO, всё оттестировано по 5 раз. Процессоры загружены на 30% максимум. Ядро не паникует, ругается только pptp. Использую accel-pptp, возможно проблема в нем, потому как на второй подобной машине (однако там ядро 2.6.20) с родным pptp проблемы не возникает.

 

Еще в логах в момент отказа в регистрации интерфейса:

 

Aug 19 21:05:06 helium3 kernel: PERCPU: allocation failed, size=2048 align=8, failed to allocate new chunk
Aug 19 21:05:06 helium3 kernel: Pid: 8918, comm: pppd Not tainted 2.6.32.14-127.fc12.i686.PAE #1
Aug 19 21:05:06 helium3 kernel: Call Trace:
Aug 19 21:05:06 helium3 kernel: [<c07a4650>] ? printk+0x14/0x1c
Aug 19 21:05:06 helium3 kernel: [<c04da20b>] pcpu_alloc+0x68c/0x714
Aug 19 21:05:06 helium3 kernel: [<c04d781a>] ? __kmalloc_track_caller+0x123/0x12f
Aug 19 21:05:06 helium3 kernel: [<c0447c50>] ? local_bh_enable_ip+0xd/0xf
Aug 19 21:05:06 helium3 kernel: [<c04da2b6>] __alloc_percpu+0xf/0x11
Aug 19 21:05:06 helium3 kernel: [<c076521d>] snmp_mib_init+0x22/0x5a
Aug 19 21:05:06 helium3 kernel: [<f8985ab1>] ipv6_add_dev+0x151/0x2e3 [ipv6]
Aug 19 21:05:06 helium3 kernel: [<f89869c3>] addrconf_notify+0x56/0x6b5 [ipv6]
Aug 19 21:05:06 helium3 kernel: [<c07635ab>] ? devinet_sysctl_register+0x3f/0x47
Aug 19 21:05:06 helium3 kernel: [<c076777a>] ? ip_mc_init_dev+0x72/0x89
Aug 19 21:05:06 helium3 kernel: [<c076400c>] ? inetdev_init+0xd6/0x10e
Aug 19 21:05:06 helium3 kernel: [<c072b4ba>] ? dropmon_net_event+0x32/0x128
Aug 19 21:05:06 helium3 kernel: [<c072b521>] ? dropmon_net_event+0x99/0x128
Aug 19 21:05:06 helium3 kernel: [<c07a825a>] notifier_call_chain+0x2b/0x4d
Aug 19 21:05:06 helium3 kernel: [<c045f1dd>] raw_notifier_call_chain+0x11/0x13
Aug 19 21:05:06 helium3 kernel: [<c071dce6>] call_netdevice_notifiers+0x16/0x18
Aug 19 21:05:06 helium3 kernel: [<c071f878>] register_netdevice+0x203/0x24e
Aug 19 21:05:06 helium3 kernel: [<c071f8fa>] register_netdev+0x37/0x46
Aug 19 21:05:06 helium3 kernel: [<c05c64d4>] ? sprintf+0x17/0x19
Aug 19 21:05:06 helium3 kernel: [<f8a1e787>] ppp_ioctl+0x27a/0xb23 [ppp_generic]          
Aug 19 21:05:06 helium3 kernel: [<c04e3b5d>] ? chrdev_open+0x0/0x110
Aug 19 21:05:06 helium3 kernel: [<c04ec29b>] ? do_filp_open+0x3e1/0x6e7
Aug 19 21:05:06 helium3 kernel: [<c058fb84>] ? file_has_perm+0x89/0xa3
Aug 19 21:05:06 helium3 kernel: [<f8a1e50d>] ? ppp_ioctl+0x0/0xb23 [ppp_generic]
Aug 19 21:05:06 helium3 kernel: [<c04ee52a>] vfs_ioctl+0x1d/0x76
Aug 19 21:05:06 helium3 kernel: [<c04eeac4>] do_vfs_ioctl+0x493/0x4d1
Aug 19 21:05:06 helium3 kernel: [<c058fe28>] ? selinux_file_ioctl+0x43/0x46
Aug 19 21:05:06 helium3 kernel: [<c04eeb48>] sys_ioctl+0x46/0x66
Aug 19 21:05:06 helium3 kernel: [<c04eddd6>] ? sys_fcntl64+0x7a/0x87
Aug 19 21:05:06 helium3 kernel: [<c040907b>] sysenter_do_call+0x12/0x28
Aug 19 21:05:06 helium3 kernel: PPP: couldn't register device ppp752 (-12)

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

[xeb]

Aug 19 21:05:06 helium3 kernel: PPP: couldn't register device ppp752 (-12)

это очень странно, первый раз такое вижу, ему явно не хвататет памяти, accel-pptp тут не причём, может редхатовцы ядро сломали...

 

[theMIROn]

xeb, патч поправляющий сборку на 2.4.

плюсом у меня спортирован gre.c на 2.4 + завязка на CONFIG_GRE + патч на ip_gre, дооформлю передам

fixed_2.4_build.patch.gz

[xeb]

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

[theMIROn]

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

Поздравляю :)

[Abram]

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

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

Ух нифига себе :). Люто, бешенно ХОТЕТЬ.

[Justas]

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

 

Как сделать donate?

[xeb]

можно на вм: Z319843403592 R402055482861 E132886217526

[hiller]

Возникла потребность отображения логов pptp-сессии из биллинговой системе.

Сейчас это можно сделать использую PID pppd, исходя из него узнать PID родителя (pptpd), отгрепать логи по этим двум пидам. Хорошо, но не очень удобно.

 

Возник вопрос: а можно ли сделать общий идентификатор сессии, который будет присутствовать в логах pptpd и pppd?

Нет ли у уважаемого Xeb'a такого в планах?

 

Логика видится такой:

При форке pptpd генерируется UUID, все сообщения, которые пишутся этим процессом pptpd в лог, начинаются с этого UUID.

При запуске pppd, в командной строке передается UUID, который был сгенерен pptpd. Pppd лог пишет начиная с этого UUID.

Также нужно, чтобы UUID передавался в скрипты auth-up, auth-down, ip-up, ip-down.

 

Имея в своем распоряжении логи, которые начинаются с уникального идентификатора сессии, можно настроить syslog-ng, чтобы он вырезал UUID текста лога и ложил его в SQL отдельным полем. Или написать скрипт, который будет грепать текстовые логи.

[xeb]

Неплохо бы туда еще поддержку CoA/DR пакетов включить

Возникла потребность отображения логов pptp-сессии из биллинговой системе.

сделаю в 0.9

 

[hiller]

сделаю в 0.9

Супер! Заранее огромное спасибо!

Приблизительной даты выхода 0.9 нет?

[xeb]

Приблизительной даты выхода 0.9 нет?

давайте ориентироваться на 1-е октября

 

[anton-s]

xeb, здравствуйте!

 

Мы тут обнаружили интересную особенность работы accel-pptpd (возможно где-то пробегало, но я не нашел)

У нас для абонентов адреса выдаются как самим accel-ом (динамика) так и биллингом (статика).

Так вот, при достижении количества интерфейсов ppp величины равной величине пула адресов прописанного в /etc/pptpd.conf , accel-pptpd перестает принимать коннекты, хотя из динамического пула адресов использовано чуть больше половины.

 

Если вдруг эта информация будет полезна -- будем рады.

 

Пользуясь случаем, хочу сказать спасибо за замечательный софт! :)

[xeb]

Здравствуйте anton-s!

На самом деле ситуация следующая: насколько я понял опция delegate не указана и pptpd думает что сам раздаёт адреса, так оно и есть, но pppd получив от радиуса другой ип заменяет тот что получил от pptpd, но pptpd об этом ничего не знает, поэтому тут надо либо полностью переходить на радиус, либо расширять диапазон адресов pptpd, либо мириться с этим нюансом.

В любом случае хорошо что напомнили, надо будет учесть в 0.9 ...

Изменено 3 сентября, 2010 пользователем xeb

[xeb]

Привествую всех пользователей accel-pptp и сочувствующих!

Итак, проект (версия 0.9) прошел критически важную (на мой взгляд) точку - прикручен радиус:

commit 4dcca9422c5c001789b17c3266f3db8e0590568d
Author: Kozlov Dmitry <dima@server>
Date:   Wed Sep 8 16:23:51 2010 +0400

    radius: implemented CHAP (md5) authorization

commit 4c6469a9fd820db713251a645ac2499782f796ed
Author: Kozlov Dmitry <dima@server>
Date:   Wed Sep 8 15:51:29 2010 +0400

    radius: implemented packet exchange
    radius: implemented PAP authorization
    radius: implemented IP assigning

Я думаю ещё числа до 20-го будет идти набор функционала, после чего кодовая база будет заморожена и начнётся лабораторное тестирование.

Так что пока идём по плану, делов конечно ещё много, но думаю к 1-му октября, как сообщалось ранее, должен быть готов первый релиз.

[hiller]

Xeb, спасибо за позитивную новость!

 

Очень ждем 1-го числа, после чего подключимся к тестированию!

[SokolovS]

2xeb: не совсем понял, что значит "прикручен radius"? Вроде к pppd радиус и так прикручен... :-/

[xeb]

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

 

[xeb]

commit 825fdec562ea4a968484c4d0dd3a6dbcc01a2a75
Author: Kozlov Dmitry <dima@server>
Date:   Thu Sep 9 16:10:40 2010 +0400

    radius: implemented DM/CoA extensions

[shicoy]

Клево, вот бы на пару лет раньше )

[DemYaN]

понимаю, что не стоит торопить события :) но когда по планам предвидится обработка CoA-Request?

[xeb]

Да я еще честно говоря не выработал идеалогию, скорее всего помимо файла radattr.pppXXX будет еще создавать что-то типа radattr_coa.pppXXX и вызываться внешний скрипт, который собственно и будет анализировать разницу и перестраивать шейперы или ещё какую работу выполнять.

Если есть какие-то конкретные предложения, то пишите.

Вообще хочу поинтересоваться вашим мнением, стоит ли делать встроенный (в виде модуля) настройщик шейпера tbf + ingress, либо еще какой не сложный вариант, помимо внешних скриптов конечно, или оно нафик никому не нужно ?

[NiTr0]

А нужно ли анализировать разницу, если в любом случае единственное, что выполнит внешний скрипт - изменение скорости классов + изменение фильтров iptables при их наличии?

Насчет встроенного шейпера - весьма спорное преимущество (хоть кто-то его будет пользовать, когда можно то же сделать более гибко скриптами?) - особенно на данной стадии. ИМХО - рюшечки, которые можно прикрутить и позже :) Разве что - втянуть код tc и сделать свои скрипты а-ля параметры tc - с возвратом режекта и восстановлением состояния (либо - с банальным дисконнектом пира) если шейпер создать/изменить не удалось...

Единственное пожелание к CoA/DR - поддержка идентификации нужного туннеля по максимуму критериев (ип, номер порта, session-id, логин и т.д.) - одному из них или их комбинации.

 

DemYaN

Если нужно сейчас - можете пропатчить классический пппд + повешать отдельный CoA демон, линк я давал, вполне стабильно работает. Все равно аксель 0.9 в продакшн сразу после релиза ставить ИМХО не стоит - очень большие изменения, и могут быть соответственно большие невыявленные глюки.