Перейти до

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


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

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

Хто таке бачив?

Що воно таке?

Нагрузка по Rx в  80-100 мегабіт і  під 100 тисяч пакетів при вимкнутих усіх решта інтерфейсах.

Появляється невідомо звідки, также пропадає.

Проявляється одночасно на усіх аплінках від провайдера 1 , у провайдра 2 таких проблем ненаблюдаю.

Провайдер  1 каже у него все гут.

 

 

3b8436790416.jpg

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

Яка модель? В мене проблеми були з RB711, коли мережа була ну тупеньких коммутаторах, він ловив до 10к пакетів і клав лінк.

Через якийсь час з'єднання поновлювалось і знову розривалось, лікувалось перезавантаженням.

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

 

Також мікроти дуже чутливі до broadcast штормів. В мене в мережі один роутер тплінковський згорів, так робив шторм в мережі до 15к пакетів, в мене вмирали усі мікроти, а убнт жив собі и проблем не знав. І ця проблема вилікувалась свічами :)

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

433GL, 750UP, 2011L...

перекинув на іншого прова все гут.

 

BSD в якості НАС  теж тормозить на прові 1

схоже у прова 1 чи то кольцо чи ще якась неприємність.

 

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

 

перезавантаження нічого не дає.

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

А можете викласти скріншот із профайлом?

tools -> profile

Дуже цікаво звікди йде навантаження.

Же можно навіситі правило в фаєрі на input з вхідного інтерфейсу.

І взагалі при таких речах треба аналізувати трафік, звідки йде, на який інтерфейс.

Зовні чи зсередини мережі.

 

UPD

Якійсь великий трафік йде до вас, у вас днс зовні закритий?

93к пакетів і 83 мегабіти трафіку.

Відредаговано L1ght
Ссылка на сообщение
Поделиться на других сайтах
Опубліковано: (відредаговано)
Же можно навіситі правило в фаєрі на input з вхідного інтерфейсу.

 

немає реакції, уже пробував.

 

І взагалі при таких речах треба аналізувати трафік, звідки йде, на який інтерфейс.

 

інтерфейс аплінку. 

 

зараз глюк пропав, усе працює нормально.

ще оце заскрінив коли глючило

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

По перше, хтось вас таки добрячи "пінгує" :D

По друге, зробіть фаєр закритим і дозволяйте те, що вам потрібно - Best Practice!

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

 

зараз глюк пропав, усе працює нормально.

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

Хурма в зайвих 100-150кппс по окремих районах ліквідована.

 

 

 

По друге, зробіть фаєр закритим і дозволяйте те, що вам потрібно - Best Practice!

Тож не панацея, коли фізика забита в полік. Ріж не ріж фаєром, зливай в блекхоул - нормальному трафіку всеодно місця нема.

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

 

По друге, зробіть фаєр закритим і дозволяйте те, що вам потрібно - Best Practice!

 

Тож не панацея, коли фізика забита в полік. Ріж не ріж фаєром, зливай в блекхоул - нормальному трафіку всеодно місця нема.

 

Так то не панацея, але йде icmp трафік, що вказує на те, що при закритому фаєрі ціею проблеми не було б.

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

 

Так то не панацея, але йде icmp трафік, що вказує на те, що при закритому фаєрі ціею проблеми не було б.

ага.. дематеріалізувався б він..... трансцендентно..

 

:facepalm:

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

 

 

Так то не панацея, але йде icmp трафік, що вказує на те, що при закритому фаєрі ціею проблеми не було б.

ага.. дематеріалізувався б він..... трансцендентно..

 

:facepalm:

 

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

Тому що коли ротуер\машина не відповідає на пінг - йде очікування відповіді, перед тим як послати наступний запит.

Більше очікування - менше навантаження.

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

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

 

Натяк намба уан - icmp далеко не синонім тогопнга, що ви бачите в cmd->ping з його відомим "прєвишен інтервал ажиданія". Натяк намба ту - від того, що там за фігня намальована в фаєрі, кількість грубо

pps*mtu в фізичному порті фізіологічно не зміниться, які б фантазії з цього приводу не приходили. Натяк намба три - deny теж pps залежна операція.

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

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

 

Натяк намба уан - icmp далеко не синонім тогопнга, що ви бачите в cmd->ping з його відомим "прєвишен інтервал ажиданія". Натяк намба ту - від того, що там за фігня намальована в фаєрі, кількість грубо

pps*mtu в фізичному порті фізіологічно не зміниться, які б фантазії з цього приводу не приходили. Натяк намба три - deny теж pps залежна операція.

Я знаю, що icmp - не завжди пінг. Я привів це як приклад.

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

 

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

 

Хурма в зайвих 100-150кппс по окремих районах ліквідована.

 

 

І зарубаний icmp протокол в корінь)

Нічого не пінговається але працює :)

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

 

І зарубаний icmp протокол в корінь)

Аплінк намба уан до понеділка похмелиться і прийде розрулювати то гівно. Іцмп нє нужен :)

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

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

Є:

на білінгу мережа користувачів 172.16.0.1/16

НАСи з білінгом зєднані EoIP тунелем (емулятор витої пари)

тунелі в бріджі на білінгу і на НАСі з юзерінтерфейсом.

На насі роблю 172.16.1.1/16

юзеру видаю 172.16.1.2/24

 

НАС з білінгом пінговаються, білінг з користувачем  по IP нехоче, по МАКу пінгує, після пінгу по МАК IP теж починає пінгуватися.

За кілька хвилин знову зникає пінг по IP, і  так поки знову не попінгуєш МАК.

В чому може бути затик?

 

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

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

 

За кілька хвилин знову зникає пінг по IP, і  так поки знову не попінгуєш МАК.

як варіант arp who has намагається піти в обхід тунелю по фізиці. Біллінг взагалі в курсі, де знаходиться 172.16.0.1/16? Ну раутами там, чи як...

Ссылка на сообщение
Поделиться на других сайтах
Біллінг взагалі в курсі, де знаходиться 172.16.0.1/16

 

ну це намальовано в rc.conf на самому білінгу

 

ifconfig на  білінгу, bridge0 - юзерь інтерфйс, ngethХ   тунелі

bridge0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
        ether 02:d9:17:2f:c5:00
        inet 172.16.0.1 netmask 0xffff0000 broadcast 172.16.255.255
        inet 172.32.0.1 netmask 0xfffff000 broadcast 172.32.15.255
        inet 10.10.10.1 netmask 0xffffff00 broadcast 10.10.10.255
        id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
        maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200
        root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
        member: ngeth10 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
                ifmaxaddr 0 port 22 priority 128 path cost 55
        member: ngeth9 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
                ifmaxaddr 0 port 21 priority 128 path cost 20000
        member: ngeth8 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
                ifmaxaddr 0 port 20 priority 128 path cost 20000
        member: ngeth7 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
                ifmaxaddr 0 port 19 priority 128 path cost 20000
        member: ngeth6 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
                ifmaxaddr 0 port 18 priority 128 path cost 20000
        member: ngeth5 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
                ifmaxaddr 0 port 17 priority 128 path cost 20000
        member: ngeth4 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
                ifmaxaddr 0 port 16 priority 128 path cost 20000
        member: ngeth3 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
                ifmaxaddr 0 port 15 priority 128 path cost 20000
        member: ngeth2 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
                ifmaxaddr 0 port 14 priority 128 path cost 20000
        member: ngeth1 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
                ifmaxaddr 0 port 13 priority 128 path cost 20000
        member: ngeth0 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
                ifmaxaddr 0 port 12 priority 128 path cost 20000
ngeth0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=28<VLAN_MTU,JUMBO_MTU>
        ether 00:11:00:22:00:01
        media: Ethernet autoselect (1000baseT <full-duplex>)
        status: active
ngeth1: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=28<VLAN_MTU,JUMBO_MTU>
        ether 20:11:00:22:00:02
        media: Ethernet autoselect (1000baseT <full-duplex>)
        status: active
ngeth2: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=28<VLAN_MTU,JUMBO_MTU>
        ether 20:11:00:22:00:03
        media: Ethernet autoselect (1000baseT <full-duplex>)
        status: active
ngeth3: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=28<VLAN_MTU,JUMBO_MTU>
        ether 20:11:00:22:00:04
        media: Ethernet autoselect (1000baseT <full-duplex>)
        status: active
ngeth4: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=28<VLAN_MTU,JUMBO_MTU>
        ether 20:11:00:22:00:05
        media: Ethernet autoselect (1000baseT <full-duplex>)
        status: active
ngeth5: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=28<VLAN_MTU,JUMBO_MTU>
        ether 20:11:00:22:00:06
        media: Ethernet autoselect (1000baseT <full-duplex>)
        status: active
ngeth6: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=28<VLAN_MTU,JUMBO_MTU>
        ether 20:11:00:22:00:07
        media: Ethernet autoselect (1000baseT <full-duplex>)
        status: active
ngeth7: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=28<VLAN_MTU,JUMBO_MTU>
        ether 20:11:00:22:00:08
        media: Ethernet autoselect (1000baseT <full-duplex>)
        status: active
ngeth8: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=28<VLAN_MTU,JUMBO_MTU>
        ether 20:11:00:22:00:10
        media: Ethernet autoselect (1000baseT <full-duplex>)
        status: active
ngeth9: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=28<VLAN_MTU,JUMBO_MTU>
        ether 20:11:00:22:10:10
        media: Ethernet autoselect (1000baseT <full-duplex>)
        status: active

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

Проблема з пінгом у тільки у клієнтів, НАСи пінгуються чудово

 

починаю пінгувати клієнта  з будьчого іншонго зразу і білінг його пінгує.

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

e5e3abdef84d.jpg

mtr до NAS

що за знаки питання в пунктах 1-5? натяк на яку проблему?

коли уже пішов пінг то є тільки один пункт без знаків питання.

 

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







#sgconf_xml -s 127.0.0.1 -p 5555 -a admin -w 123456 -r "<GetAdmins/>"
Connect failed!
 

------------------------------------------------------------

думки в "голос" про пінги

Усе працювало чудово до грози, поки не вигоріло кілька БС і дофіга клієнтів.

Підгорений клієнт може створювати бурю пакетів або ще якусь лобуду в мережі.

у мене білінг у  бріджі  з НАСама і клієнтами через EoIP, щоб клієнт  получав адресу від білінга.

Топто один підгорений  клієнт може повалити усю мережу.

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

...

 

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






#sgconf_xml -s 127.0.0.1 -p 5555 -a admin -w 123456 -r "<GetAdmins/>"
Connect failed!
 
------------------------------------------------------------

думки в "голос" про пінги

Усе працювало чудово до грози, поки не вигоріло кілька БС і дофіга клієнтів.

Підгорений клієнт може створювати бурю пакетів або ще якусь лобуду в мережі.

у мене білінг у  бріджі  з НАСама і клієнтами через EoIP, щоб клієнт  получав адресу від білінга.

Топто один підгорений  клієнт може повалити усю мережу.

 

Мабуть до купи згорів і loopback :)

Гляньте шо у stargazer.log після такої команди.

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

stargazer.log 

2014-07-30 16:13:12 -- ReadSettings error. Cannot read file stop/stargazer.conf
2014-07-30 16:13:19 -- DOTCONF++: file 'stop/stargazer.conf':  realpath('stop/stargazer.conf') failed: No such file or directory

2014-07-30 16:13:19 -- ReadSettings error. Cannot read file stop/stargazer.conf
2014-07-30 16:13:20 -- DOTCONF++: file 'stop/stargazer.conf':  realpath('stop/stargazer.conf') failed: No such file or directory

2014-07-30 16:13:20 -- ReadSettings error. Cannot read file stop/stargazer.conf
2014-07-30 16:13:32 -- +++++++++++++++++++++++++++++++++++++++++++++
2014-07-30 16:13:37 -- Module: 'CAP_NF v. 0.4'. Stop successfull.


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

 

ReadSettings error. Cannot read file stop/stargazer.conf

мля та це ж я стопанув старгейзера :facepalm:

хоча він ще з якогось дива у процесах висів.

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

 

ReadSettings error. Cannot read file stop/stargazer.conf

мля та це ж я стопанув старгейзера :facepalm:

хоча він ще з якогось дива у процесах висів.

 

Не стопнув а намагався стартувати з лівим конфігом.

Можливо паралельно з уже запущеним.

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

 

Не стопнув а намагався стартувати з лівим конфігом.

stargazer stop міг  намалювати

 

 

у мене в top два  stargazer  висять

так має бути?

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

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

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

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

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

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

Вхід

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

Войти сейчас
  • Зараз на сторінці   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, торг
       


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