nightfly

Но это же ебанутый п@зд#ц категорически неконцептуальное решение - пихать неймсервера на каждого юзера, тем более в авторизацию прямо. Есть подсеть/пул, со своими параметрами типа дефалтраутов, днс-ов, домейнов итд - туда такие вещи и рисуются. В БСД это таки ppp.conf в этом контексте, в этих ваших линуксах - понятия не имею, так как с pppoe/pptp не работаю очень давно, но могу поспорить что там тоже никто не додумался пихать днс сервера к авторизации - так что должно строиться по-нормальному, типа как pppoe-server-options или как там его в rp-pppoe. Вон посмотрите на вполне себе клевый солюшн от Алексея выше например. Судя по всему он работает на чистом старгейзере - так что и с убиллингом проблем быть не должно. Энивей он выглядит, как-то более концептуальным чем наколенная генерация secrets по каждому чиху. Если вылезут какие-то артефакты - с удовольствием посмотримс что можно сделать для обеспечения компатибильности.

да ну вот - понятным же языком написано в чем проблема. Как я и пророчил - в интерпретере. это не папка, это путь к php собранному к слову с поддержкой CLI. Подсуньте туда чего вам говорит whereis php что-ли.

Руками если позапускать - тоже пустота? А то вот, как-бы работает [nightfly@jesus ~/dev/ubilling/]$ /etc/stargazer/GetNasIP testuser 10.10.15.20 [nightfly@jesus ~/dev/ubilling/]$ Хотя да, я был прав - после шабанга интерпретер, по умолчанию там точно BSD-шный воткнут. Измените его для начала. И удостоверьтесь в том, что скрипто имеет права на выполнение и в /etc/stargazer/config указаны адекватные параметры БД.

Я типа в курсе как это работает Ну сделайте в OnConnect что-то типа NASIP=`/etc/stargazer/GetNasIP ${LOGIN}` echo ${NASIP} >> /var/log/nas.log вот и увидите чего оно вам возвращает. Ну либо что еще проще просто позапускайте руками из консоли /etc/stargazer/GetNasIP [логин_существующего_абонента] Естественно для подсети к которой пренадлежит абонент должен быть добавлен NAS соответствующего типа, чтобы оно в обратную сторону по логину могло айпишку NAS-а выдернуть. Есть подозрения, что собака могла порыться банально в шабанге.

Покажите в каком контексте пытаетесь их использовать в OnConnect/OnDisconnect

Обожаю эти ваши линуксы, каждый день что-то новое

Возможно человек хочет, чтобы все на него смотрели при помощи tail -F. Если бы хотел внимания от gdb - обозвался бы Segmentation fault

Тарифам - наплевать на скорость. Скорости - наплевать поверх чего и куда ее ложат. Вполне себе можно минимальную обертку, хоть на базе того же GetCF изобразить при желании.

Оке, проверим. Догадываюсь откуда ноженьки растут. OPENPAYZ_REALID - достает по каждому пользователю по его логину, настоящий virtualid из op_customers вместо дефолтной трансформации ip2int() как это делалось раньше в OpenPayz. В общем опция актуальна, если вы используете openpayz для приема оплат и хотите вместо традиционного Payment ID слепленного по айпишке нечто иное. Например, чистый цифренный логин. Опция влияет на модуля "Профиль пользователя" и "Поиск пользователя", а также собственно на "Кабинет пользователя" - но она там отдельно. SEARCH_STRICT - просто выставляет по каким типам полей будет осущестляться поиск без масок. Думаю понятно зачем это нужно. Возможные Значения: realname,login,phone,mobile,email,note,contract,ip,mac. Разделитель запятая. Опция влияет только на модуль "Поиск пользователя".

http://www.colocall....ua/prefixes.txt - на 99.5% готовый /etc/stargazer/rules http://www.colocall....ua/prefixes.txt - можно использовать как основу для политики шейпа

было еще пару недопиленых заказух правильно - на новый год я высыпался И вам вкусной кути

Релиз Ubilling 0.3.6 - rev 2264 - Изменения в структуре БД, см дамп. - alter.ini: новая опция SEARCH_STRICT управляющая строгостью поиска - alter.ini: новая опция DEAD_HIDE отключающая показ мертвых людей (ну прямо как в «Шестом чувстве» с Брюсом Уиллисом) - alter.ini: новая опция DEAD_TAGID устанавливающая ID тега отмечающего похороненных пользователей - alter.ini: новая опция OPENPAYZ_REALID указывающая на то, что следует доставать платежные ID из op_customers - alter.ini: новая опция PASSPDATA_IN_PROFILE включающая отображение паспортных данных в профиле - userstats.ini: новая опция OPENPAYZ_REALID внезапно, делающая то же, что и в alter - billing.ini: новая опция RESET_AO хотфиксящая проблему при использовании rscriptd (включать строго по дикой нужде) - Новый модуль «Експресс регистрация»: позволяет регистрацию без удобного визарда, также требует прав на карточку. - Новый модуль «Редактирование паспортных данных»: угадайте что делает - Модуль «Експресc карточка»: косметика, теперь адрес регистрации по умолчанию отжат - Модуль «Експресc карточка»: добавлены минимальные проверки на валидность IP (формат,свободен,попадает в сеть) - Модуль «Експресc карточка»: после всех изменений теперь однозначно вызывается ресет пользователя - Модуль «Поиск»: строгость поиска по отдельным полям профиля теперь управляема - Модуль «Карта оборудования»: теперь также умеет отображать приблизительную зону покрытия - Модуль «Онлайн»: теперь умеет не видеть «мертвых людей» в HP_MODE - Модуль «Свитчи»: появилась «машина времени», позволяющая отслеживать состояние свитчей при cronping - Модуль «Редактирование договора»: для установки даты заключения договора более не требуется CRM_MODE - Модуль «Редактирование пользователя»: бессовестно рефакторнут - Модуль «OpenPayz»: бессовестно рефакторнут - Модуль «Профиль пользователя»: теперь умеет отображать настоящий payment ID - Модуль «Поиск пользователей»: теперь также умеет искать по настоящим payment ID - Модуль «Профиль пользователя»: теперь умеет отображать паспортные данные при указании соотв. опции. - Модуль «Состояние системы»: теперь умеет проверять наличие обновлений. - Модуль «Свитчи»: теперь есть отдельная привилегия для добавления, модификации и удаления свитчей. - Паспортные данные теперь также доступны для шаблонизации - Кабинет пользователя: в профиле может отображаться реальный Payment ID - OpenPayz: появился фронтенд работы с QIWI - OpenPayz: теперь принудительно логирует транзакции как платежи Ubilling Перед обновлением следует Вкатить вот такой дампик на БД: CREATE TABLE `switchdeadlog` ( `id` INT NOT NULL AUTO_INCREMENT PRIMARY KEY , `date` DATETIME NOT NULL , `timestamp` INT NOT NULL , `swdead` TEXT NOT NULL , INDEX ( `date` , `timestamp` ) ) ENGINE = MYISAM DEFAULT CHARSET=utf8 AUTO_INCREMENT=1; В alter.ini добавить следующие опции: SEARCH_STRICT="contract" DEAD_HIDE=0 DEAD_TAGID=15 OPENPAYZ_REALID=0 PASSPDATA_IN_PROFILE=0 userstats.ini: OPENPAYZ_REALID=0 billing.ini: RESET_AO=0

На первый взгляд все нормально. Когда добьетесь, чтобы заработало $globconf=parse_ini_file(CONFIG_PATH."billing.ini"); $sudo=$globconf['SUDO']; $command=$sudo.' id'; $result=shell_exec($command); deb(nl2br($result)); сможете быть уверенным, что взлетит и все остальное. Я бы порекомендовал при исполнении этого куска паралельно смотреть в httpd-error.log на предмет воплей о том, почему же ему исполнение sudo из shellexec() не нравиться. Возможно в этих ваших центосах, кроме selinux присутствуют еще какие-то упоротые патчи на apache либо php препятствующие эскалации прав скрипта (suhosin?). В общем есть такое чувство, что это чисто дистрибутиво зависимые заморочки. Так как у существующих людей с gentoo/debian/ubuntu что-что а банальный system() работает всегда. И кто-то еще спрашивает, почему официальная поддержка производиться только на FreeBSD

окей, будем считать что в данном контексте apache и sirko эквивалентны ниразу не понял, кто работает и кто нет можете елементарно попробовать под sirko все тот же /usr/bin/sudo /bin/ping -i 0.01 -c 1 127.0.0.1 (надеюсь такие путя у вас в billing.ini прописаны?) если работает - значит болезнь порылась где-то в system() - ему, кто-то претит выполнять внешние команды.

дык это ж хорошо Чего последний тест говорит? $command='id'; $result=shell_exec($command); deb(nl2br($result));

значит sudo либо не выполняется вообще, либо пытается запросить пароль. конечно мило, но вызывается оно для самого себя форком апача - из этого и следует исходить. Для начала возможно стоит позырить под кем же работают процессы php: $command='id'; $result=shell_exec($command); deb(nl2br($result)); Если в выхлопе вы таки увидите своего apache - значит проблема таки либо: 1. в том как это должно быть описано в sudoers (я реально не знаю, отличается ли оно в GNU-том окружении) 2. либо в банальном пути до самого sudo Больше вариантов почему оно может не работать - придумать сложно.

А так чего говорит? $globconf=parse_ini_file(CONFIG_PATH."billing.ini"); $sudo=$globconf['SUDO']; $command=$sudo.' id'; $result=shell_exec($command); deb(nl2br($result)); таки походу sudo не работает

Того под которым работает апач. Для BSD это www. В этих ваших линуксах - вообще неизвестно кто начиная httpd и apache и заканчивая http,nobody,www и еще невесть кем. Итого в sudoers следует добавить User_Alias BILLING = пользователь_апача BILLING ALL = NOPASSWD: ALL Хоть бы чем-то ругнулось Одно из двух - либо проблема действительно в sudo и оно например пароль просит, либо у вас в принципе не исполняется shell_exec()/system() попробуйте тогда так: $ip='127.0.0.1'; $globconf=parse_ini_file(CONFIG_PATH."billing.ini"); $ping=$globconf['PING']; $ping_command=$ping.' -c 1 '.$ip; $ping_result=shell_exec($ping_command); deb(nl2br($ping_result)); Если и после такого в дебаге пустота - у вас таки по идее ничерта системные вызовы не исполняются. Соответственно не должно работать вообще ничего. Без рабочего только sudo - не будут работать: 1. парсинг новых МАС из логов 2. перезапуск dhcpd 3. выпарсивание начислений средств stargazer 4. посылка HUP для stargazer при работе с NAS-ами 5. все пинговалки 6. еще черт знает что - оно в большинстве своем форкается под sudo

Опять SELinux? А вообще проверяется очень просто при помощи "PHP консоли": $ip='127.0.0.1'; $globconf=parse_ini_file(CONFIG_PATH."billing.ini"); $ping=$globconf['PING']; $sudo=$globconf['SUDO']; $ping_command=$sudo.' '.$ping.' -i 0.01 -c 1 '.$ip; $ping_result=shell_exec($ping_command); deb(nl2br($ping_result));

То была шутка. Ваш КО. Не за что. С праздниками.

Не хочу ничего менять.

Есть такая класная штука, называется документацией.

MASSSEND_ENABLED=1 MASSSEND_SAFE=0

..либо [!] с последующей экскомуникацией ноды. У нас тут борзая эха