Перейти до

Ubilling + NAS на FreeBSD бортжурнал починаючого адміна


Рекомендованные сообщения

 

 

Дякую за поради.

наздоров'я

 

 

*.pfx це той самий *.p12

ну дякую, буду знати, відкрив анкету ще раз, про *.p12 нічого, просто клієнтський.

я робив *.p12 от понесло))

Ссылка на сообщение
Поделиться на других сайтах
  • Відповіді 1,8k
  • Створено
  • Остання відповідь

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

Вітаю Татко!   

Не так вже й багато   Ход коньом:   # cat /bin/clear_dhcpdlog #!/bin/sh /bin/echo > /var/log/dhcpd.log /usr/local/etc/rc.d/isc-dhcpd restart # chmod a+x /bin/clear_dhcpdlog # crontab -e

http://wiki.ubilling.net.ua/doku.php?id=userstats       Расист? http://wiki.ubilling.net.ua/doku.php?id=userstats

Posted Images

Опубліковано: (відредаговано)

пробую скрипіти 

тицніть носом де туплю



cat compareip.sh
#!/bin/sh

FirewallExtIP=`ipfw show | grep "nat 1 ip from any to" | awk '{print $10}'`
extIP=`ifconfig tun0 inet | grep inet | awk '{print $2}'`
#echo "ext="${extIP}
#echo "Firewall="${FirewallExtIP}

if ${FirewallExtIP} == ${extIP}
then
{
echo "`date '+%d-%m-%Y-%H:%M:%S'`:ether tun0 ip= ${extIP} = Firewall Nat IP ${FirewallExtIP}" >> /var/log/compareip.log
}
else
{
echo "`date '+%d-%m-%Y-%H:%M:%S'`: ether tun0 ip= -${extIP}- NOT Firewall Nat IP -${FirewallExtIP}- Firewal restart" >> /var/log/compareip.log
/etc/rc.d/ipfw restart
}
fi

сенс скрипта

з крона запускаю його кожні 5 хв і перевіряю чи не падала сесія pppoe і не помінялась зовнішня адреса

якщо так перезапустити фаєр, там extIP адреса виловлюється і нат запускається як треба.

 

тут же у мене завжди false! незалежно від  того одинакові айпішки чи ні

пробіли ніби не мішаються з айпішками  в extIP і FirewalExtIP

 

вихлоп з адекватним адресом нат в фаєрі 

./compareip.sh
94.***.***.***: not found
net.inet.ip.fw.enable: 1 -> 0
net.inet6.ip6.fw.enable: 1 -> 0
ipfw: getsockopt(IP_FW_ADD): Invalid argument
Firewall rules loaded.


Відредаговано mgo
Ссылка на сообщение
Поделиться на других сайтах

 

 

94.***.***.***: not found

це якраз з строчки if ${FirewallExtIP} == ${extIP}

перший параметр воно чось викидає а другий not found

як фіксанути?

Ссылка на сообщение
Поделиться на других сайтах

 

В чем может быть проблема?

що в логах?

наприклад

/var/stargazer/allconnect.log

/var/log/stargazer.log

 

 

 

usr/local/www/apache24/data/billing/api/libs/api.networking.php on line 709

https://github.com/nightflyza/Ubilling/blob/master/api/libs/api.networking.php#L709

тут у нас генерація платіжного ідентифікатора з IP адреси

 

/var/stargazer/allconnect.log   ---- такого файла логов нет

в а /var/log/stargazer.log  ничего не пишет

Ссылка на сообщение
Поделиться на других сайтах

а вот апач пишет PHP Fatal error:  Allowed memory size of 268435456 bytes exhausted (tried to allocate 240 bytes) in /usr/local/www/apache24/data/billing/api/libs/api.networking.php on line 709

 

в php.ini memory_limit = 256M

Відредаговано optims
Ссылка на сообщение
Поделиться на других сайтах

 

пробую скрипіти 

тицніть носом де туплю



cat compareip.sh
#!/bin/sh

FirewallExtIP=`ipfw show | grep "nat 1 ip from any to" | awk '{print $10}'`
extIP=`ifconfig tun0 inet | grep inet | awk '{print $2}'`
#echo "ext="${extIP}
#echo "Firewall="${FirewallExtIP}

if ${FirewallExtIP} == ${extIP}
then
{
echo "`date '+%d-%m-%Y-%H:%M:%S'`:ether tun0 ip= ${extIP} = Firewall Nat IP ${FirewallExtIP}" >> /var/log/compareip.log
}
else
{
echo "`date '+%d-%m-%Y-%H:%M:%S'`: ether tun0 ip= -${extIP}- NOT Firewall Nat IP -${FirewallExtIP}- Firewal restart" >> /var/log/compareip.log
/etc/rc.d/ipfw restart
}
fi

сенс скрипта

з крона запускаю його кожні 5 хв і перевіряю чи не падала сесія pppoe і не помінялась зовнішня адреса

якщо так перезапустити фаєр, там extIP адреса виловлюється і нат запускається як треба.

 

тут же у мене завжди false! незалежно від  того одинакові айпішки чи ні

пробіли ніби не мішаються з айпішками  в extIP і FirewalExtIP

 

вихлоп з адекватним адресом нат в фаєрі 

./compareip.sh
94.***.***.***: not found
net.inet.ip.fw.enable: 1 -> 0
net.inet6.ip6.fw.enable: 1 -> 0
ipfw: getsockopt(IP_FW_ADD): Invalid argument
Firewall rules loaded.


IF невірно описаний.

http://www.dreamsyssoft.com/unix-shell-scripting/ifelse-tutorial.php

Ссылка на сообщение
Поделиться на других сайтах

 

 

IF невірно описаний. http://www.dreamsyss...se-tutorial.php

ну пробував я по всякому отой if описувати з test [] чи без нього і що ви думаєте?

так ніфіга неїхало а воно виявляється пропусків хоче між квадратними дужками.

треба і біле вчитися читати :D

Ссылка на сообщение
Поделиться на других сайтах

 

IF невірно описаний. http://www.dreamsyss...se-tutorial.php

ну пробував я по всякому отой if описувати з test [] чи без нього і що ви думаєте?

так ніфіга неїхало а воно виявляється пропусків хоче між квадратними дужками.

треба і біле вчитися читати :D

 

Я на тому собаку з'їв, через оті пробіли :)

Ссылка на сообщение
Поделиться на других сайтах

 

 

Я на тому собаку з'їв, через оті пробіли

Ну паскаль/делфі ще зі школи пам'ятаю, с++ ну дуже мало тільки проходили(

хоча то всьо синтаксис, практика показує,  що  все швидко освоюється при бажанні і правильних мозгах.

Ссылка на сообщение
Поделиться на других сайтах

а вот апач пишет PHP Fatal error:  Allowed memory size of 268435456 bytes exhausted (tried to allocate 240 bytes) in /usr/local/www/apache24/data/billing/api/libs/api.networking.php on line 709

 

в php.ini memory_limit = 256M

проблема возникает именно если выбирать nas с микротиком версии 6.хх, пробовал на 5.хх несколько разных бордов, все ок, с 6.хх тоже несколько разных бордов - вылазит подобная обишка

memory_limit менял как в большую так и в меньшую сторону, не помогает

Ссылка на сообщение
Поделиться на других сайтах

А що гугл каже з цього приводу?)

 

 

а вот апач пишет PHP Fatal error:  Allowed memory size of 268435456 bytes exhausted (tried to allocate 240 bytes) in /usr/local/www/apache24/data/billing/api/libs/api.networking.php on line 709

 

в php.ini memory_limit = 256M

проблема возникает именно если выбирать nas с микротиком версии 6.хх, пробовал на 5.хх несколько разных бордов, все ок, с 6.хх тоже несколько разных бордов - вылазит подобная обишка

memory_limit менял как в большую так и в меньшую сторону, не помогает

 

Ссылка на сообщение
Поделиться на других сайтах
Опубліковано: (відредаговано)
у модуль світчі добреб було впиляти  виконання скрипта  на віддаленому світчі  наприклад ребут

 

 

Свого часу була така ідея. Навіть реалізацію красіву майже придумав.

Поділіться думками, буду мати час попиляю, може краще вийде як з смс  ;)

 

У мене така ідея.

в описі девайсу робим REBOOT.

 

 

 

а ще по remoteapi  пачков все ребутити   во кльово булоб .

тут я погарячився з ремотеапі :D

 

Думаю просто з крона (кому не треба ніхтож не заставляє в крон ставити :) ) запуск скрипта тіпа dnswitch.php

в скрипті  з БД витягнути список хто на REBOOT і ребутити)

 

 

 

то по духу звучить таки близько до SYSLOAD_CUSTOM_SCRIPTS

 

ну це кнопка буде в модулі стан системи  і пачков все ребутне для цього у нас є крон, краще кнопка в світчах  напроти світча з описом REBOOT кнопка ребут конкретного.

 

ps надоїло лазяти і руками ребутити рокети

мікротік сам Scheduler має і скрипіти на нім нона.

Watchdog на  ubnt невихід - віфі лагане і маєм ребут хоть по 100 раз на день.

Відредаговано mgo
Ссылка на сообщение
Поделиться на других сайтах
Опубліковано: (відредаговано)

Прикрутив ПБ, розіслав ІД....

Зняв АП

і у дівчинки на телефоні почалися епілептичні припадки після  надцятого звінка "заплатили а нету нема!"

ПБ каже 



Добный день
ПБ-->> Вы не подтвердили эти платежи, а сразу слали, что это дубликат


<Transfer xmlns="http://debt.privatbank.ua/Transfer" action="Pay" interface="Debt">
    <Data xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="Payment" id="682028ХХХ" cancel="false">
        <CompanyInfo>
            <CheckReference>45</CheckReference>
        </CompanyInfo>
        <PayerInfo billIdentifier="18472ХХХХ"/>
        <TotalSum>150.00</TotalSum>
        <CreateTime>2014-11-03T12:13:16.726+02:00</CreateTime>
        <ServiceGroup>
            <Service sum="150.00" serviceCode="101"/>
        </ServiceGroup>
    </Data>
</Transfer>






<Transfer xmlns="http://debt.privatbank.ua/Transfer" interface="Debt" action="Pay">
<Data xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="ErrorInfo" code="7">
<Message>Дублирование платежа</Message>
</Data>
</Transfer>

йду копатися сам, але може підкажіть на що в першу чергу звернути увагу

бо уже нейролептики закінчуюся  і дівчинки шкода((

 

мало не почерез одну оплату отака штука.

Відредаговано mgo
Ссылка на сообщение
Поделиться на других сайтах

Дублікат опізнається тільки у вигляді pbx_CheckHash($rawhash) де унікальним ідентифікатором платежу по ідеї мав би виступати CheckReference. Власне для того, аби платіж був унікальним, потрібна відсутність в op_transactions такого самого, вже опрацьованого PBX_+CheckReference.

Ссылка на сообщение
Поделиться на других сайтах
Опубліковано: (відредаговано)
<CheckReference>45</CheckReference> 

 

 

<CreateTime>2014-11-03T12:13:16.726+02:00</CreateTime> 

платіж що непройшов слався в 12:13:16

а у базі PBX_45 2014-11-03 12:14:53 успішний платіж

як так могло статися?

біля двох різних кас стоять наш клієнт

в один час касир починає наберати ідентифікатор і CheckReference на обох касах одинаковий тому що ще небуло такого платежу

перший клієнт дає без здачі 200 грн, другий рахує дрібні

і хто перший той і тато для CheckReference?

200 пройшло на другий відповіть дублікат.

 

якого х#~ вони тоді не перевіряють свій CheckReference перед відправкою

 

>>Референс ответа на запрос check, присвоенный билинговой системой

топто CheckReference ми шлемо банку і не фільтруєм ніяк що уже було відправлено!

думаю кожен CheckReference відправлений в ПБ потрібно писати в базу незалежно платіж відбувся чи ні.

інекше нейролептики дівчинці тре закуповівати оптом  :D

Відредаговано mgo
Ссылка на сообщение
Поделиться на других сайтах

отже з приватом ми налаштували три методи

 

Search

Chek

Pay

 

відбувається усе наступним чином

 

спочатку засовує клієнт свій ід в банк

банк шле Search

знаходить клієнта далі бере гроші і шле Chek і зразу мав би йти  Pay але виходить так, що виконуються два Сhek і  потім аж Pay.

я все правильно поЙняв?

вихід?

буду ще допитуватися у ПБ як у них ото все відбувається і що  мона зробити.

Ссылка на сообщение
Поделиться на других сайтах

 

в один час касир починає наберати ідентифікатор і CheckReference на обох касах одинаковий тому що ще небуло такого платежу

Я про це яким місцем маю взнати? Ну, ящо воно до мене ще навіть в теорії не прийшло?

 

 

і хто перший той і тато для CheckReference?

Нє бл..дь, давайте оба будемо вносити з спокійною мордою.

 

 

якого х#~ вони тоді не перевіряють свій CheckReference перед відправкою

На справді у всіх нормальних платіжних систем (а що саме смішне навіть у старого протоколу приватбанку) є нормальні унікальні ідентифікатори конкретного платежу в рамках їх системи.

 

 

топто CheckReference ми шлемо банку і не фільтруєм ніяк що уже було відправлено!

Ну давайте я буду сидіти і памятати, чим на що і кому відповідалось сто років тому. А так, геть забув, ще я повинен вгадувати, хто там на касі гроші рахує. Правильно все?

 

 

думаю кожен CheckReference відправлений в ПБ потрібно писати в базу незалежно платіж відбувся чи ні.

Пишіть. Дозволяю.

Хоча тоді ще варто буде весь openpayz переписати, щоб він оте все невідпрацьоване лайно ігнорив.

 

У будь-якому випадку, я здогадуюсь як це все можна елегантно і красиво обійти, але на це немає часу, бажання і настрою.

Ссылка на сообщение
Поделиться на других сайтах

 

 

  в один час касир починає наберати ідентифікатор і CheckReference на обох касах одинаковий тому що ще небуло такого платежу Я про це яким місцем маю взнати? Ну, ящо воно до мене ще навіть в теорії не прийшло?   Цитата   і хто перший той і тато для CheckReference? Нє бл..дь, давайте оба будемо вносити з спокійною мордою.

 

Несприймайте серьозно,  то думки в голос після дози нейролептиків :D

 

 

 

На справді у всіх нормальних платіжних систем (а що саме смішне навіть у старого протоколу приватбанку) є нормальні унікальні ідентифікатори конкретного платежу в рамках їх системи.
 

як я зрозумів треба переходити на старий протокол поки цей сирий. 

 

 

У будь-якому випадку, я здогадуюсь як це все можна елегантно і красиво обійти, але на це немає часу, бажання і настрою.

у мене ще одна думка проскочила  - заставити приват слати чек і зразу за ним пей.

хоча це підпірка а не вирішення проблеми.

Ссылка на сообщение
Поделиться на других сайтах

 

 

у мене ще одна думка проскочила - заставити приват слати чек і зразу за ним пей.

Поштою слати? Вони роблять конкретний запит, ми відповідаємо конкретною відповіддю.

Дуже сумніваюсь, що вони вміють обробляти дві різні відповіді в рамках одного запиту. Крім того, що, будем прямо при чеку вносити бабки, так? :)

 

 

хоча це підпірка а не вирішення проблеми

Це якась неіснуюча в реальному світі фантазія, а не підпірка.

 

Короче є ідея, як нормально забезпечити атомарність операцій. Зара прокинусь остаточно, попью кави і нафігачу фікс.

Ссылка на сообщение
Поделиться на других сайтах

 

 

Поштою слати?  

нє поштою довго, думаю методом POST чи GET непам'ятаю точно. :D

 

 

Крім того, що, будем прямо при чеку вносити бабки, так?

отак я мав на увазі

 

 

 

Все. Я прокинувся. Накидайте мені милом отих запитів, що вони шлють вам в реальності.

є один запит і відповіь, більше  накидати зможу в понеділок коли ПБ буде працьвати, у мене здається лог запитів ніде не ведеться.

оцей один запит і відповідь можу вислати, хоча сенсу небачу, по одному все гут.

 

Потрібно мінімум два з одним CheckReference той, що пройшов і той що мимо.

 

припадки трохи заспокоїлися і порахували скільки є незаписаних в білінг оплат

20 з 180 мимо.

Ссылка на сообщение
Поделиться на других сайтах

 

 

нє поштою довго, думаю методом POST чи GET непам'ятаю точно. :D

Тільки Укрпошта!

 

 

 

отак я мав на увазі

Вносити зі старту бабки, як реакція на запит, що мав би перевіряти можливість здійснення платежу в принципі? :facepalm:

Ссылка на сообщение
Поделиться на других сайтах

 

 

припадки трохи заспокоїлися і порахували скільки є незаписаних в білінг оплат 20 з 180 мимо.

То в вас карма фігова.

SELECT COUNT(`id`) from `op_transactions` WHERE `hash` LIKE 'PB_%' AND `date` LIKE '2014-11-%'
array (
  0 => 
  array (
    'COUNT(`id`)' => '1130',
  ),
)
Ссылка на сообщение
Поделиться на других сайтах
Опубліковано: (відредаговано)
Вносити зі старту бабки, як реакція на запит, що мав би перевіряти можливість здійснення платежу в принципі?

нє нетак

 

Ядумаю є зараз так (а як є треба дивитися реальні запити з точним часом)

 

1.   пошук    //через Укрпошту  початок операції               t=00:00

2.   чек         //через Укрпошту                                             t=t+00:01

2.1 рахуєм в касі гроші, чукаємся і кліпаєм на касірку :) t = t+ (від 05:00 десь  до 30:00) в  приват24 платіж мона кинути в корзину і 

//морозитися  ще пів години поки проведеш

3.   шлем пей  //через Укрпошту                                         t=t+00:01

 

в результаті розрив часу між чек і пей достатньо великий щоб ще хтось вклинився на цей CheckReference

 

 

А треба так 

 

1.   пошук    //через Укрпошту                                               t=00:00

2.   чек         //через Укрпошту                                               t=t+00:01

2.1 рахуєм в касі гроші, чукаємся і кліпаєм на касірку :)   t=t+багато часу

2.2 чек         //через Укрпошту                                               t=t+00:01

3.   шлем пей  //через Укрпошту з CheckReference з п2.2  t=t+00:01

 

в результаті розрив часу між чек і пей десь 1 сек., і вклинитися сюди  комусь другому на цейже CheckReference шансів набагаот менше ->  тіпа підпірка))

 

або 

 

1.   пошук    //через Укрпошту 

2 рахуєм в касі гроші, чукаємся і кліпаєм на касірку :)

2.1 чек         //через Укрпошту 

3.   шлем пей  //через Укрпошту 

 

* шлем = ПБ шле нам 

 

 

 

 

То в вас карма фігова. SELECT COUNT(`id`) from `op_transactions` WHERE `hash` LIKE 'PB_%' AND `date` LIKE '2014-11-%' array ( 0 => array ( 'COUNT(`id`)' => '1130', ), )

 

ні то все вила!

зовсім трішки погрожував

тепер юзери в касу бігають табунами :D

Відредаговано mgo
Ссылка на сообщение
Поделиться на других сайтах

Создайте аккаунт или войдите в него для комментирования

Вы должны быть пользователем, чтобы оставить комментарий

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Вхід

Уже зарегистрированы? Войдите здесь.

Войти сейчас
  • Зараз на сторінці   0 користувачів

    Немає користувачів, що переглядають цю сторінку.

  • Схожий контент

    • Від ppv
      Потрібно було витерти одну мережу, всі абоненти з неї були перенесені в іншу. Але світить що 6 IP зайняті, хоча вона повністю вільна.
       
      ID    Мережа/CID           RВсього IP        Використано IP ▾           Вільно IPСервіс
      6      172.16.70.0/23        506                    6                                       500
       
      Підкажіть як правильно це підчистити щоб видалити мережу.
    • Від sanyadnepr
      Приветствую всех.
      Подскажите пожалуйста где копнуть и нет ли проблемы со стороны протокола взаимодействия сити24 или возможно не учтена необходимая проверка в модуле сити24 в Ubilling, пока писал понял что похоже в проверке payID, но это не точно.  
      Недавно обнаружилось с сити24 начали прилетать дубликаты платежей, в целом платежей мало, два одинаковых запроса Pay с одинаковым transactionID и payID в одну секунду одному платежному ID при этом биллинг "думает" примерно чуть больше минуты и отвечает одним ответом <result>0</result>, сити24 утверждает что ответ они не получили и по протоколу дальше повторяет запросы дублем, биллинг ответ и так по кругу, сити24 спрашивает каким образом с одинаковым payID от сити24 билл продолжает обрабатывать запросы и пополнять абоненту счет раз в 5 минут примерно, на одну и туже сумму, ведь этот payID уже был обработан предполагают сити24 согласно протоколу.
      Конечно есть вопрос к сити24 зачем они дублем присылают два запроса, но они отвечают что эта ситуация учтена в протоколе и проблема на стороне биллинга, потому что он пополняет счет по уже обработанному одинаковому payID.
      При этом transactionID в дублях одинаковый, но с каждым новым дублем разный.
      Если зафаерволить запросы от сити24, но оставить возможность отвечать то после блокировки билл отправляет 2-3 минуты 6 ответов <account>0001</account>  <result>0</result>.
      После снятия блокировки, дубли и платежи нескольких проблемных абонентов прилетают так же по кругу, при этом и с некоторыми новыми пополнениями происходит аналогичная ситуация.
      В openpayz в платежах transactionID и не видно payID.
    • Від nightfly
      Ubilling 1.4.3 rev 9058 The Bladewood Grove
       
      Зміни в структурі БД. alter.ini: нові опції OPHANIMFLOW_ENABLED та OPHANIMFLOW_URLS котрі вмикають та керують інтеграцією з OphanimFlow. alter:ini: нова опція PHOTOSTORAGE_POSTPROCESSING, що вмикає післяобробку зображень при завантаженні в Сховище зображень. alter:ini: нова опція PHOTOSTORAGE_WATERMARK, що вмикає розміщення вотермарки на всіх зображеннях, що завантажуються. alter:ini: нова опція PHOTOSTORAGE_RECOMPRESS, що вмикає зміну компрессії завантажених зображень. alter:ini: нова опція PHOTOSTORAGE_AUTORESIZE, що вмикає автоматичне та лагідне масштабування зображень конячих розмірів. alter:ini: нова опція PHOTOSTORAGE_DRAWIMGINFO, що вмикає вдруковування в зображення відлагоджувальної інформації. alter.ini: нова опція ONDEMAND_CHARTS, що вмикає відкладене завантаження графіків завантаження користувацької смуги. userstats.ini: нова опція OPHANIM_ENABLED, що вмикає інтеграцію OphanimFlow в кабінеті користувача. Модуль Заздрість: тепер авторизаційні дані пристроїв, не відображаються в списку пристроїв. Модуль “Заздрість”: при створенні та редагуванні пристроїв, для полів “пароль” та “enable пароль” тепер використовуються інпути паролів. Модуль “Заздрість”: заздрісним пристроям додано нове поле “Порт”. Тепер в скриптах можна використовувати, відповідний макрос {PORT}. Модуль “Статистика трафіку користувача”: проведено радикальний рефакторинг. Модуль “Статистика трафіку користувача”: додано опційну можливість, відображення трафіку отриманого з OphanimFlow. Модуль “Статистика трафіку користувача”: виправлено проблему невірного відображення залишку коштів на кінець місяця, при використанні Ішимури. Модуль “Статистика трафіку користувача”: додано можливість відображення графіків за останню годину з OphanimFlow. Модуль “Користувачі”: додано опційну можливість, відображення трафіку отриманого з OphanimFlow. Модуль “Сховище зображень”: тепер додатково перевіряє завантажувані зображення на тему їх валідності. Модуль “Фінансові операції”: виправлено відображення суми платежів користувача. Remote API: новий виклик ophanimtraff, який просто бере і синхронізує локальну БД з віддаленими джерелами OphanimFlow. Remote API: виклик userbynum тепер також опційно містить поле з “Платіжним ID” користувача. Глобально: у всіх полях вводу паролів, окрім форми входу, тепер відображається елемент керування “показати/приховати” пароль. Кабінет користувача: в модулі “Трафік” додано опційну можливість, відображення трафіку отриманого з OphanimFlow. Кабінет користувача: в модулі “Трафік” виправлено проблему невірного відображення залишку коштів на кінець місяця, при використанні Ішимури. Кабінет користувача: в модулі “Відеоспостереження” для NVR WolfRecorder замінено розділювач попередньо заповнених даних авторизації. OpenPayz: додано frontend portmonemulti, для отримання платежів від різних контрагентів. Інформацію по контрагентам бере з біллінгу, також використовую розширену інформацію контрагента. Платіжна система в контрагенті мусить бути створена, як PORTMONE 1984tech: додано функціонал генерації RPZ для isc-bind, спасибі @misterromanbush  
      Повний чейнджлог
      Оновлена демка
       

    • Від mac
      Здається, після оновлення PHP 7.4 до PHP 8.2 feesharvester припинив працювати:
       
      /usr/local/bin/curl "http://127.0.0.1/billing/?module=remoteapi&key={SERIAL}&action=feesharvester" <br /> <b>Fatal error</b>: Uncaught TypeError: Unsupported operand types: string - string in {UBPATH}/billing/api/libs/api.fundsflow.php:570 Stack trace: #0 {UBPATH}/billing/modules/remoteapi/feesharvester.php(22): FundsFlow-&gt;harvestFees('2024-01') ...  
      Невеличке розслідування врешті з'ясувало, що це через наявність пробілу у деяких логінах абонентів. Як так сталося? Тому що інколи був неуважно додан трейлінг пробіл до номеру будинка і цей пробіл потрапив до логіну абоненту. Логін абоненту неможливо змінити ніяким чином штатними засобами. Я не розглядаю створення нового абонента для усунення помілки.

      Був обран такий шлях вирішення проблеми. Заміну функції php explode() знайшов у мережі. Мабуть це станеться в нагоді:

       
      diff api.fundsflow.php.bak api.fundsflow.php.new 559c559 < $eachfee = explode(' ', $eachline); --- > $eachfee = preg_split("~(?<!\\\\)(?:\\\\{2})*'[^'\\\\]*(?:\\\\.[^'\\\\]*)*'(*SKIP)(*F)|\s+~s" , $eachline);  
    • Від Zend
      Продам сабж.
      2 контроллера CA07336-C001, в каждом по одном интерфейсном модуле CA07336-C009 (2 x 1Gbps iSCSI)
      HDD: 24 x 900GB SAS 10K
      Исправен.
      С ним могу продать шкафчик того же вендора.
       
      Стоимость - $4000, торг
       


×
×
  • Створити нове...