nightfly

Ні, до маку воно привязує зовсім іншим місцем (див arp -a). А це - психодел якийсь, такі конфіги в принципі генеруватись не можуть. Даремно. Фря на яку ви щось вже намагались ставити руками - вже нечистива, нічорта там нормально не взлетить. Убінсталлером в варіантах 8.3 Offline та 8.3 Offline KMOD ставиться клієнтам практично щотижня - все нормально. cat /etc/firewall.conf ipfw nat 1 show ipfw table 2 list ipfw table 4 list ipfw table 9 list покажіть

Що куримо - написано в FAQ сподіваюсь на чисту не чіпану руцями 8.3? Підозрюю, що як мінімум - фігово заповнили мережу в розділі "Мережі та послуги". От вам і sanity check failed. В вашому випадку наскільки розумію повинно бути, щось на кшталт початкова: 172.16.0.0 кінцева: 172.16.0.255 мережа/cidr: 172.16.0.1/24 а це ще що за психодел?

То-то я думаю маразмом попахивает втыкание туда DNS-ов. nlo - попробуйте таки со звездочкой, если взлетит - добавлю опцией в 0.3.7. Сможете обновиться из ночных сборок если таки заработает.

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

да ну вот - понятным же языком написано в чем проблема. Как я и пророчил - в интерпретере. это не папка, это путь к 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 - просто выставляет по каким тип

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 включающая отображение паспортных данных в профиле

На первый взгляд все нормально. Когда добьетесь, чтобы заработало $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 препятствующие эскалации прав скрипта (s

окей, будем считать что в данном контексте 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=$pin

Опять 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));

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

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

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