Перейти до

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


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

 

 

 

Виглядає так, ніби у цієї MAC адреси в мережі є дублікати

пише пінгувач на вебморді

для залізок ubnt - норм практика, відповідати двіччі.

 

Двічі різними маками?

 

Пардон, провтикав. Таки одним.

Ссылка на сообщение
Поделиться на других сайтах
  • Відповіді 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

Увага хотюнчик!
у модуль світчі добреб було впиляти  виконання скрипта  на віддаленому світчі 

наприклад ребут

щоб всякі там ubnt і т.п мона  було ребутнути прямо з білінга і нелазяти по всяких ВПНах і ото перезапускати в ручну.

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

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

Увага хотюнчик!

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

наприклад ребут

щоб всякі там ubnt і т.п мона  було ребутнути прямо з білінга і нелазяти по всяких ВПНах і ото перезапускати в ручну.

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

Свого часу була така ідея. Навіть реалізацію красіву майже придумав. Тільки потім зрозумів, що ніколи практично просто так свічі не ребутив віддалено. В основному потреба виникає ребутати його руками, тільки власне коли до нього якраз добратись немож, тобто він наглухо повис. Що як би ліквідує цінність його ручного пинання в принципі.

 

Щодо массового ребуту за допомогою remoteapi (навіть боюсь уявити собі цю содомію, госпаді помилуй ще й відов в кроні?) то по духу звучить таки близько до SYSLOAD_CUSTOM_SCRIPTS

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

отож бо й  воно

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

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

і все живеньке та свіженьке зранку, тай мінімум незручностей користвкчам (5 година ранку десь 95% ХХХнушку уже подивились і солодко сплять :D)

 

Щодо массового ребуту за допомогою remoteapi (навіть боюсь уявити собі цю содомію, госпаді помилуй ще й відов в кроні?)

 

а як його без крона заставити запуститися в 5 ранку?

у мене нема здоровя самому вставати і руками запускати

 

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

 

ну ладно з тим кроном і апі

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

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

і знову приватХ!

у мене записався латіж а немав кажуть в приваті)





[#|2014-10-16T10:37:01.700+0300|INFO|sun-appserver9.1|DebtHttpClient-1378128|_ThreadID=18;_ThreadName=httpSSLWorkerThread-8137-1;|Request body <20141016103701480>: <?xml version="1.0" encoding="UTF-8" stan
dalone="yes"?>
<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="511725548" cancel="false">
        <PayerInfo billIdentifier="3962186"/>
        <TotalSum>0.01</TotalSum>
        <CreateTime>2014-10-16T09:56:46.416+03:00</CreateTime>
        <ServiceGroup>
            <Service sum="0.01" serviceCode="101"/>
        </ServiceGroup>
    </Data>
</Transfer>
|#]

[#|2014-10-16T10:37:01.975+0300|INFO|sun-appserver9.1|DebtHttpClient-1378128|_ThreadID=18;_ThreadName=httpSSLWorkerThread-8137-1;|Response body <20141016103701480>: <br />
<b>Notice</b>:  Undefined index: CompanyInfo in <b>/usr/local/www/apache24/data/openpayz/frontend/privatx/index.php</b> on line <b>503</b><br />
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
                    <Transfer xmlns="http://debt.privatbank.ua/Transfer" interface="Debt" action="Pay">
                     <Data xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="Gateway" reference="">
                    </Data>
                    </Transfer>|#]


был неудачный
id = 511725548 time = 779ms error = Message.InvalidResponse...................................................................FAIL

А почему у вас платеж записывается, не смотря на то, что ответ не соответсвует успешному проведению платежа ?

 

 

 

перший платіж у вас непройшов через Undefined index: CompanyInfo

 Это было из-за того, что первый платеж был без check

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

 

 

Notice: Undefined index: CompanyInfo in /usr/local/www/apache24/data/openpayz/frontend/privatx/index.php on line 503

в мене нема там CompanyInfo

 

 

 

перший платіж у вас непройшов через Undefined index: CompanyInfo

а де він проє...ся?

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

https://github.com/nightflyza/Ubilling/blob/master/openpayz/frontend/privatx/index.php

 тут 504 рядок

я мабудь десь підтягнув на рядок вище.

 

 

я >>>перший платіж у вас непройшов через Undefined index: CompanyInfo

ПБ>>>то было из-за того, что первый платеж был без check

 

тобто  з привату послали отой запит в лістингу без check і получили матюк

а у мене записався платіж.

наступний платіж пройшов нормально як у них так і у мене

 

єдине запитання від ПБ 

 

>>А почему у вас платеж записывается, не смотря на то, что ответ не соответсвует успешному проведению платежа ?

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

 

00:15:6d:9c:55:3b  172.16.8.35

00:15:6d:de:49:08 172.16.8.33

отак воно привязано в білінгу.

 

з якого переляку з 35 пінгує 33

а з 33 пінгувати мак 35  моя не розуміє

Схоже шо на 33 проксі-арп. Була така бадяга в мене в мережі :)

Пінганіть ще когось з тієї мережі - виповзе така ж хвігня?

 

Вариант раз: не включен wds на АП.

Вариант два: колизии маков на свиче.

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

ПБ>> <CompanyName> не шлите это элемент, пожалуйтса. Этот параметр будет браться с наших настроек.

я>> Розробник каже: В їх мануалі /Transfer/Data/ServiceGroup/DebtService/CompanyInfo/CompanyCode взагалі помічено як обовязковий елемент.

ПБ>>CompanyCode - да, обязательный, но не CompanyName
я >> забрав CompanyName

 

отут пропав 1 рядок  з ReplySearch

він їм мішає

 

доречі того разу теж був цей матюк на Pay але ми списали це на лишне для них  CompanyName в ReplySearch

і так їде у мене.

оце куму добре роблю)

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

 

.

там не має бути wds, там AP -> Client все.

 

Вариант два: колизии маков на свиче.

цілком ймовірно

Ссылка на сообщение
Поделиться на других сайтах
При виконанні скрипту
 
# /usr/local/bin/php /etc/stargazer/dnswitch.php
 
Маю такий вихлоп
 
#### Shape start 16-Oct-2014 14:45:44####
#### Shape end 16-Oct-2014 14:45:44####
 
Швидкіть при цьому не змінюється
В папці  /etc/stargazer/dn  є логіни юзерів
 
Дядько mgo показував, що має трапитись такє:

 

щось таке має виводити.

===============
user login:*d_ap1_qgce
normal mark:8130
user tariff:Unlim2
normal speed:2048
new speed:2048
===============
.....
.....
.....
####Shape end 10-Oct-2014 09:47:05####

 

Куди ще потрібно заглядати?  :unsure:  :facepalm:

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

ок запустили ви скрипт!

 

налаштувати швидкостя в білінгу лишилося

Це радує, але...

http://pichost.me/1915964/

і швідкості не змінюються, тобто беруться з модулю "Скорость тарифов" :huh:

Може шось не так з часовими рамками? м?

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








64 bytes from 172.16.4.196: icmp_seq=64 ttl=64 time=9.034 ms // тариф test 512/512
64 bytes from 172.16.4.196: icmp_seq=65 ttl=64 time=6.635 ms
64 bytes from 172.16.4.196: icmp_seq=66 ttl=64 time=4.458 ms
64 bytes from 172.16.4.196: icmp_seq=67 ttl=64 time=5.892 ms
64 bytes from 172.16.4.196: icmp_seq=68 ttl=64 time=4.162 ms
64 bytes from 172.16.4.196: icmp_seq=69 ttl=64 time=2.771 ms
ping: sendto: No buffer space available                      // тариф unlim2-100 2048/2048
ping: sendto: No buffer space available
ping: sendto: No buffer space available
ping: sendto: No buffer space available
ping: sendto: No buffer space available
ping: sendto: No buffer space available
ping: sendto: No buffer space available
ping: sendto: No buffer space available
ping: sendto: No buffer space available
64 bytes from 172.16.4.196: icmp_seq=79 ttl=64 time=4.426 ms  // отут ресет користувача
ping: sendto: No buffer space available
ping: sendto: No buffer space available
ping: sendto: No buffer space available
ping: sendto: No buffer space available
ping: sendto: No buffer space available
ping: sendto: No buffer space available
ping: sendto: No buffer space available
64 bytes from 172.16.4.196: icmp_seq=87 ttl=64 time=11.389 ms // тариф той самий з  зміненою швидкістю test 3512/3512
64 bytes from 172.16.4.196: icmp_seq=88 ttl=64 time=4.821 ms
64 bytes from 172.16.4.196: icmp_seq=89 ttl=64 time=4.568 ms
64 bytes from 172.16.4.196: icmp_seq=90 ttl=64 time=6.576 ms

оце 512/512 або 3512/3512 є пінг на НАС

на всіх інши нема або про мбуф лобуда, до білінга пінг є

 

що за глюк?

 

де моя гемороїдальна свічка ... :facepalm:

 netstat -m
443/2002/2445 mbufs in use (current/cache/total)  
437/857/1294/25600 mbuf clusters in use (current/cache/total/max)
437/843 mbuf+clusters out of packet secondary zone in use (current/cache)
0/104/104/12800 4k (page size) jumbo clusters in use (current/cache/total/max)
0/0/0/6400 9k jumbo clusters in use (current/cache/total/max)
0/0/0/3200 16k jumbo clusters in use (current/cache/total/max)
1031K/2630K/3661K bytes allocated to network (current/cache/total)

current/cache  постійно міняється у всіх ніби все їде)

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

Мережеві які карти? Той самий реалтек?

Також vmstat -z

vmstat -i

 

netstat -hdw 1

 

Та скажіть навантаження по ЦПУ.

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

так тут ота кака

 

але сьогодні намертво ззовні повис і ящик з інтелами

 я незміг глянути чому, перегрузили намісці.

 

намалював скрипти який буде пінгати гугл

як не пінгається то перегружаю фаєр

потім мпд

і як і то непомогло то систему.



 vmstat -z
ITEM                   SIZE  LIMIT     USED     FREE      REQ FAIL SLEEP

UMA Kegs:               208,      0,      93,       9,      93,   0,   0
UMA Zones:              640,      0,      93,       3,      93,   0,   0
UMA Slabs:              568,      0,    1526,       0,    2482,   0,   0
UMA RCntSlabs:          568,      0,     751,       5,     751,   0,   0
UMA Hash:               256,      0,       4,      11,       5,   0,   0
16 Bucket:              152,      0,      86,      14,      86,   0,   0
32 Bucket:              280,      0,      83,       1,      83,   0,   0
64 Bucket:              536,      0,      50,       6,      50,  57,   0
128 Bucket:            1048,      0,     327,       0,     327, 823,   0
VM OBJECT:              232,      0,    3234,     494,  133622,   0,   0
MAP:                    232,      0,       8,      24,       8,   0,   0
KMAP ENTRY:             120,  82026,      49,     230,   12037,   0,   0
MAP ENTRY:              120,      0,    1647,     740,  368954,   0,   0
fakepg:                 120,      0,       0,       0,       0,   0,   0
mt_zone:               4112,      0,     341,      32,     341,   0,   0
16:                      16,      0,    1932,     252,   98251,   0,   0
32:                      32,      0,    1985,    1045,30015601,   0,   0
64:                      64,      0,   12325,    1731,  198403,   0,   0
128:                    128,      0,   77436,   19511, 3764622,   0,   0
256:                    256,      0,    2051,    2554,59998450,   0,   0
512:                    512,      0,     839,    1422, 8443967,   0,   0
1024:                  1024,      0,      72,     140,   10991,   0,   0
2048:                  2048,      0,      94,      40,   13326,   0,   0
4096:                  4096,      0,     469,     116,    7747,   0,   0
Files:                   80,      0,     123,     192,  165830,   0,   0
rl_entry:                40,      0,      70,     182,      70,   0,   0
TURNSTILE:              136,      0,     163,      17,     163,   0,   0
umtx pi:                 96,      0,       0,       0,       0,   0,   0
MAC labels:              40,      0,       0,       0,       0,   0,   0
PROC:                  1192,      0,      58,      41,    6922,   0,   0
THREAD:                1160,      0,     144,      18,     145,   0,   0
SLEEPQUEUE:              80,      0,     163,      40,     163,   0,   0
VMSPACE:                392,      0,      37,      53,    6905,   0,   0
cpuset:                  72,      0,      61,     139,      62,   0,   0
audit_record:           960,      0,       0,       0,       0,   0,   0
mbuf_packet:            256,      0,     444,     836,64025015,   0,   0
mbuf:                   256,      0,       2,    1163,93385462,   0,   0
mbuf_cluster:          2048,  25600,    1280,      14,    1280,   0,   0
mbuf_jumbo_page:       4096,  12800,       0,     104,    1055,   0,   0
mbuf_jumbo_9k:         9216,   6400,       0,       0,       0,   0,   0
mbuf_jumbo_16k:       16384,   3200,       0,       0,       0,   0,   0
mbuf_ext_refcnt:          4,      0,       0,       0,       0,   0,   0
g_bio:                  248,      0,       0,    2880,   92186,   0,   0
ttyinq:                 160,      0,     180,     156,     495,   0,   0
ttyoutq:                256,      0,      95,      85,     260,   0,   0
ata_request:            328,      0,       0,       0,       0,   0,   0
ata_composite:          336,      0,       0,       0,       0,   0,   0
vtnet_tx_hdr:            24,      0,       0,       0,       0,   0,   0
FPU_save_area:          576,      0,       0,       0,       0,   0,   0
VNODE:                  504,      0,    2427,      37,    2516,   0,   0
VNODEPOLL:              112,      0,       0,       0,       0,   0,   0
S VFS Cache:            108,      0,    2345,      97,    3299,   0,   0
STS VFS Cache:          148,      0,       0,       0,       0,   0,   0
L VFS Cache:            328,      0,       0,       0,       0,   0,   0
LTS VFS Cache:          368,      0,       0,       0,       0,   0,   0
NAMEI:                 1024,      0,       0,      36,  357580,   0,   0
NCLNODE:                568,      0,       0,       0,       0,   0,   0
DIRHASH:               1024,      0,      79,      17,      81,   0,   0
Mountpoints:            824,      0,       2,      10,       2,   0,   0
pipe:                   728,      0,       6,      49,    4180,   0,   0
ksiginfo:               112,      0,      91,     965,     444,   0,   0
itimer:                 344,      0,       1,      21,       2,   0,   0
KNOTE:                  128,      0,       5,     111,   37299,   0,   0
socket:                 680,  25602,      48,      54,   49582,   0,   0
unpcb:                  240,  25600,      15,      33,     156,   0,   0
ipq:                     56,    819,       0,     189,    1375,   0,   0
udp_inpcb:              392,  25600,      15,      35,   47158,   0,   0
udpcb:                   16,  25704,      15,     489,   47158,   0,   0
tcp_inpcb:              392,  25600,       7,     343,     790,   0,   0
tcpcb:                  976,  25600,       7,      41,     790,   0,   0
tcptw:                   72,   5150,       0,     450,     699,   0,   0
syncache:               152,  15375,       0,      75,     177,   0,   0
hostcache:              136,  15372,       0,      56,       4,   0,   0
tcpreass:                40,   1680,       0,     252,     204,   0,   0
sackhole:                32,      0,       0,       0,       0,   0,   0
sctp_ep:               1384,  25600,       0,       0,       0,   0,   0
sctp_asoc:             2288,  40000,       0,       0,       0,   0,   0
sctp_laddr:              48,  80064,       0,     216,       9,   0,   0
sctp_raddr:             704,  80000,       0,       0,       0,   0,   0
sctp_chunk:             136, 400008,       0,       0,       0,   0,   0
sctp_readq:             104, 400032,       0,       0,       0,   0,   0
sctp_stream_msg_out:    104, 400032,       0,       0,       0,   0,   0
sctp_asconf:             40, 400008,       0,       0,       0,   0,   0
sctp_asconf_ack:         48, 400032,       0,       0,       0,   0,   0
ripcb:                  392,  25600,       1,      39,    1249,   0,   0
rtentry:                200,      0,      27,      49,      39,   0,   0
IPFW dynamic rule:      120,   4123,       0,       0,       0,   0,   0
selfd:                   56,      0,     130,     374,  732469,   0,   0
SWAPMETA:               288, 229424,       0,       0,       0,   0,   0
FFS inode:              168,      0,    2394,      70,    2478,   0,   0
FFS1 dinode:            128,      0,       0,       0,       0,   0,   0
FFS2 dinode:            256,      0,    2394,      36,    2478,   0,   0
bridge_rtnode:           64,      0,     240,     208,     512,   0,   0
NetGraph items:          72,   4118,       0,     116,  605559,   0,   0
NetGraph data items:     72,    522,       0,     116,66608377,   0,   0



vmstat -i
interrupt total rate
irq16: rl0 ehci0 42127439 4572
irq23: ehci1 13857 1
cpu0:timer 10369426 1125
irq264: hdac0 8 0
irq266: hdac1 83 0
irq267: re0 73141190 7938
irq268: ahci0 30723 3
cpu1:timer 10272126 1114
Total 135954852 14756



netstat -hdw 1
packets errs idrops bytes packets errs bytes colls drops
11k 0 0 7.8M 12k 0 12M 0 0
10k 0 0 6.9M 10k 0 10M 0 0
11k 0 0 7.4M 11k 0 11M 0 0
13k 0 0 9M 13k 0 13M 0 0
12k 0 0 8.3M 12k 0 12M 0 0
11k 0 0 7.8M 12k 0 12M 0 0
12k 0 0 8.7M 12k 0 13M 0 0
13k 0 0 9.2M 13k 0 14M 0 0
12k 0 0 8M 12k 0 12M 0 0
11k 0 0 7.5M 11k 0 11M 0 0
12k 0 0 8.2M 12k 0 12M 0 0
11k 0 0 7.0M 11k 0 10M 0 0
11k 0 0 7.6M 11k 0 11M 0 0
11k 0 0 8.5M 11k 0 13M 0 0
13k 0 0 9.7M 13k 0 14M 0 0
12k 0 0 9M 13k 0 13M 0 0
13k 0 0 9.0M 13k 0 13M 0 0
12k 0 0 8.1M 12k 0 12M 0 0
12k 0 0 9.0M 12k 0 13M 0 0
12k 0 0 7.9M 12k 0 11M 0 0
input (Total) output
packets errs idrops bytes packets errs bytes colls drops
11k 0 0 7.3M 11k 0 10M 0 0
11k 0 0 7.7M 11k 0 11M 0 0
12k 0 0 7.9M 12k 0 12M 0 0
13k 0 0 9.1M 13k 0 13M 0 0
15k 0 0 11M 14k 0 15M 0 0
14k 0 0 10M 14k 0 15M 0 0
12k 0 0 8.7M 12k 0 13M 0 0
12k 0 0 8.5M 12k 0 13M 0 0
12k 0 0 7.8M 12k 0 12M 0 0

 

 

Та скажіть навантаження по ЦПУ.

top

CPU: 0.9% user, 0.0% nice, 2.4% system, 7.3% interrupt, 89.3% idle

Mem: 90M Active, 38M Inact, 140M Wired, 403M Buf, 1524M Free

Swap: 4096M Total, 4096M Free

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

Мені дуже не подобаеться різниця в перериваннях по мережевих

irq16: rl0  42127439 4572
irq267: re0 73141190 7938

Змінити б карти на нормальні...

То проблема скорішь всього вирішиться.

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


 vmstat -i
interrupt                          total       rate
irq16: em1 ehci0                93410518       1533
irq19: em0 atapci0             133576465       2193
irq23: ehci1                       91453          1
cpu0:timer                      68556728       1125
irq264: hdac0                          8          0
cpu1:timer                      53556454        879
Total                          349191626       5733

а як вам різниця  з інтелами?

 

тай пінгу нема на себе (до насу) а через цей нас, через тунель пінг на білінг летить!

міняю швидкостя пінг і на нас починає летіти.

топто шейпер його пиняє,

ото треба й дослідити або  тицніть носом де пише шо шейп може відрубати пінг на реалтеку

причому тільки одному юзеру із майже 200.

 

хоча справді мережеві тре людські сюда  :)

Відредаговано 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, торг
       


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