Перейти до

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


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

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

+ ще вагон позитиву у вигляді ОНУшка кінцеве обладнання абонента.

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

ага поки хто попривичці ресет не жмакне юзеру

мамі дорого дежурний обійдеться щоб  арп чистив постійно

дешевше  ціска  ;)

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

ага поки хто попривичці ресет не жмакне юзеру

мамі дорого дежурний обійдеться щоб  арп чистив постійно

дешевше  ціска  ;)

а ну переложить терминацию тоже хороший вариант))))

у меня по крайней мере с кучей реальников такого замечено не было, вся терминация на 3550 дешманской

так шо проси у мамы 100 баксов на 3550-12G и вперед))))

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

 

 

так шо проси у мамы 100 баксов на 3550-12G и вперед))))

чот я невїду як має цей  3550-12G своїми здвоїними оптичними портами вписатися в мережу

у мене тільки звичайні шахти під sfp на свічі і на ОЛТ головах

 

чи там до нього якісь спец медіки чи що ще в нагрузку тре :huh:

гуглю 

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

tcpdump став слухати , що куда літає

після вчорашного ковбашення з білими айпішками

 

цікава штука спостерігається

генериться трафік від білінга до віддаленого НАС на 2-5 сек  мегабіт етак 50-80 буває :blink:

 

і так до різних адрес з того НАСу

чо так?, хто таке бачив?

клієнти тут в основному wi-fi в основному убікутік декуди sxt лайт

є нормальні відповіді туда, але більшість отакого  (там дві підмережі)

в логах DHCP нічо підозрілого нема для цих адрес і в момент скачка.

в цей момент  tcpdump

21:52:26.225362 IP 172.16.0.1.67 > 172.16.23.35.68: BOOTP/DHCP, Reply, length 300
21:52:26.225369 IP 172.16.0.1.67 > 172.16.23.35.68: BOOTP/DHCP, Reply, length 300
21:52:26.225375 IP 172.16.0.1.67 > 172.16.23.35.68: BOOTP/DHCP, Reply, length 300
21:52:26.225383 IP 172.16.0.1.67 > 172.16.23.35.68: BOOTP/DHCP, Reply, length 300
21:52:26.225389 IP 172.16.0.1.67 > 172.16.23.35.68: BOOTP/DHCP, Reply, length 300
21:52:26.225402 IP 172.16.0.1.67 > 172.16.23.35.68: BOOTP/DHCP, Reply, length 300
21:52:26.225410 IP 172.16.0.1.67 > 172.16.23.35.68: BOOTP/DHCP, Reply, length 300
21:52:26.225423 IP 172.16.0.1.67 > 172.16.23.35.68: BOOTP/DHCP, Reply, length 300
21:52:26.225428 IP 172.16.0.1.67 > 172.16.23.35.68: BOOTP/DHCP, Reply, length 300
21:52:26.225437 IP 172.16.0.1.67 > 172.16.23.35.68: BOOTP/DHCP, Reply, length 300
21:52:26.225442 IP 172.16.0.1.67 > 172.16.23.35.68: BOOTP/DHCP, Reply, length 300
21:52:26.225450 IP 172.16.0.1.67 > 172.16.23.35.68: BOOTP/DHCP, Reply, length 300
21:52:26.225455 IP 172.16.0.1.67 > 172.16.23.35.68: BOOTP/DHCP, Reply, length 300
21:52:26.225465 IP 172.16.0.1.67 > 172.16.23.35.68: BOOTP/DHCP, Reply, length 300
21:52:26.225470 IP 172.16.0.1.67 > 172.16.23.35.68: BOOTP/DHCP, Reply, length 300
21:52:26.225478 IP 172.16.0.1.67 > 172.16.23.35.68: BOOTP/DHCP, Reply, length 300
21:52:26.225483 IP 172.16.0.1.67 > 172.16.23.35.68: BOOTP/DHCP, Reply, length 300

3yZUiPk.png

Відредаговано mgo
Ссылка на сообщение
Поделиться на других сайтах
Опубліковано: (відредаговано)
tcpdump -i bridge0 -w dump.log port 67 and port 68

15:10:55.955221 IP 172.16.24.53.bootpc > 172.16.0.1.bootps: BOOTP/DHCP, Request from 30:b5:c2:42:55:8d (oui Unknown), length 548
15:10:55.955365 IP 172.16.0.1.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length 300
15:10:55.965251 IP 172.16.24.18.bootpc > 172.16.0.1.bootps: BOOTP/DHCP, Request from 14:cc:20:6b:cd:43 (oui Unknown), length 548
15:10:55.965413 IP 172.16.0.1.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length 300
15:10:56.114055 IP 172.16.24.175.bootpc > 172.16.0.1.bootps: BOOTP/DHCP, Request from 10:60:4b:47:fc:9c (oui Unknown), length 548
15:10:56.114213 IP 172.16.0.1.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length 300
15:10:56.128855 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:30:67:d5:99:60 (oui Unknown), length 304
15:10:56.129054 IP 172.16.0.1.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length 300
15:10:58.335935 IP 172.16.24.206.bootpc > 172.16.0.1.bootps: BOOTP/DHCP, Request from b8:a3:86:1e:cd:d2 (oui Unknown), length 532
15:10:58.336157 IP 172.16.24.1.bootps > 172.16.24.206.bootpc: BOOTP/DHCP, Reply, length 300
15:10:58.472088 IP 172.16.23.33.bootpc > 172.16.0.1.bootps: BOOTP/DHCP, Request from 14:58:d0:c8:48:37 (oui Unknown), length 548
15:10:58.472265 IP 172.16.0.1.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length 300
15:10:59.452059 IP 172.16.24.181.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:30:67:d5:99:60 (oui Unknown), length 300
15:10:59.452215 IP 172.16.24.1.bootps > 172.16.24.181.bootpc: BOOTP/DHCP, Reply, length 300
15:10:59.571015 IP 195.95.147.117.bootpc > 172.16.0.1.bootps: BOOTP/DHCP, Request from 70:9e:29:cd:7b:72 (oui Unknown), length 548
15:10:59.571176 IP 172.16.0.1.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length 300
15:11:00.716523 IP 172.16.23.36.bootpc > 172.16.0.1.bootps: BOOTP/DHCP, Request from 00:1a:4d:55:f4:1d (oui Unknown), length 548

15:11:00.716668 IP 172.16.0.1.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length 300
15:11:01.392114 IP 172.16.23.20.bootpc > 172.16.0.1.bootps: BOOTP/DHCP, Request from 44:87:fc:8d:f7:d2 (oui Unknown), length 548
15:11:01.392281 IP 172.16.0.1.bootps > 172.16.23.20.bootpc: BOOTP/DHCP, Reply, length 300
15:11:01.398232 IP 172.16.0.1.bootps > 172.16.23.20.bootpc: BOOTP/DHCP, Reply, length 300
15:11:01.398252 IP 172.16.0.1.bootps > 172.16.23.20.bootpc: BOOTP/DHCP, Reply, length 300
15:11:01.398660 IP 172.16.0.1.bootps > 172.16.23.20.bootpc: BOOTP/DHCP, Reply, length 300
15:11:01.398668 IP 172.16.0.1.bootps > 172.16.23.20.bootpc: BOOTP/DHCP, Reply, length 300
15:11:01.398735 IP 172.16.0.1.bootps > 172.16.23.20.bootpc: BOOTP/DHCP, Reply, length 300
15:11:01.398757 IP 172.16.0.1.bootps > 172.16.23.20.bootpc: BOOTP/DHCP, Reply, length 300
15:11:01.398765 IP 172.16.0.1.bootps > 172.16.23.20.bootpc: BOOTP/DHCP, Reply, length 300
15:11:01.398773 IP 172.16.0.1.bootps > 172.16.23.20.bootpc: BOOTP/DHCP, Reply, length 300
15:11:01.400590 IP 172.16.0.1.bootps > 172.16.23.20.bootpc: BOOTP/DHCP, Reply, length 300
15:11:01.400598 IP 172.16.0.1.bootps > 172.16.23.20.bootpc: BOOTP/DHCP, Reply, length 300
15:11:01.401178 IP 172.16.0.1.bootps > 172.16.23.20.bootpc: BOOTP/DHCP, Reply, length 300
15:11:01.401186 IP 172.16.0.1.bootps > 172.16.23.20.bootpc: BOOTP/DHCP, Reply, length 300
15:11:01.401198 IP 172.16.0.1.bootps > 172.16.23.20.bootpc: BOOTP/DHCP, Reply, length 300
15:11:01.401211 IP 172.16.0.1.bootps > 172.16.23.20.bootpc: BOOTP/DHCP, Reply, length 300
15:11:01.401256 IP 172.16.0.1.bootps > 172.16.23.20.bootpc: BOOTP/DHCP, Reply, length 300
.........................................
15:11:01.414017 IP 172.16.0.1.bootps > 172.16.23.20.bootpc: BOOTP/DHCP, Reply, length 300
15:11:01.414027 IP 172.16.0.1.bootps > 172.16.23.20.bootpc: BOOTP/DHCP, Reply, length 300
15:11:01.414037 IP 172.16.0.1.bootps > 172.16.23.20.bootpc: BOOTP/DHCP, Reply, length 300
15:11:01.423563 IP 172.16.24.83.bootpc > 172.16.0.1.bootps: BOOTP/DHCP, Request from bc:5f:f4:7f:b2:a7 (oui Unknown), length 5
15:11:01.423755 IP 172.16.0.1.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length 300

чо так?

відповідь іде для 172.16.23.20 ~ 100 000 раз

що і де ще подивитися?

лівих  DHCP серверів небачу.

все ніби працює, тільки оця бадяга і тільки на віддалений НАС так відповідає.

там жменя тих абонентів.

може десь в транспорті проблема.

дайте пару ідей що ще перевірити.

 

freeBSD10.2 недавно переїхав, до цього неспостерігалося.

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

а є можливість деякому списку сайтів надавати максимальну швидкість на порту , в обхід тарифу ? типу отдельная скорость 

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

а є можливість деякому списку сайтів надавати максимальну швидкість на порту , в обхід тарифу ? типу отдельная скорость 

спидтест?

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

 

 

спидтест?

не ,з спид тест все добре  

 

как я понимаю, копать сюда:

http://wiki.ubilling.net.ua/doku.php?id=uaixshape

 

та має впринципі працювати , якщо в prefixes.txt , запіхну свої сайти 

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

Доброї ночі! Підкажіть будьласка. Після видлення юзера або декількох, з'явилися якись "тіні" чи то дущі. Отже, ні в біллінгу  ні в пошуку юзерів по ІР їх нема.

При спробі змінити ІР адресу останього у списку ІР на ІР того хто покинув біллінг не вдається, то так для феншуя хотілося, щоб всі йшли у порядку, та не було пропуків у списку ІР. Ось шматок конфігу ethrnet.conf

host m172x16x0x105 {
hardware ethernet 00:27:22:e8:1f:a8;
fixed-address 172.16.0.105;
}

host m172x16x0x106 {
hardware ethernet 00:27:22:9a:ea:4f;
fixed-address 172.16.0.106;
}

host m172x16x0x107 {
hardware ethernet ;
fixed-address 172.16.0.107

Як видно, перщі два юзери "нормальні" з МАС-адресами, а останій без МАС-а тай займає ІР, його вже нема в біллінгу, тай на його місце неможна поставити нікого.

При редагуванні ethrnet.conf руцями та після перезапуску DHCP, він заново генерується з "душами" юзерів. Як би то одна душа, то мать її за ногу, є декілька таких.

Отож питання, як довго ті дущі будуть мене лякати, чи варті вони уваги, чи є яка молитва проти того?

Дякую, гарної ночі!  :)

 

ЗІ. Сервер перезавантжив, дхцп логі вичистив, і все таке інше, результату 0.

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

То відразу запитаю, що воно таке і чі є ліки? 

Jun 22 01:02:30 eserverx bandwidthd: DNS timeout for 172.16.0.103: This problem reduces graphing performance
Jun 22 01:04:30 eserverx bandwidthd: DNS timeout for 172.16.0.103: This problem reduces graphing performance
Jun 22 01:05:51 eserverx bandwidthd: DNS timeout for 172.16.0.103: This problem reduces graphing performance
Jun 22 01:15:54 eserverx last message repeated 5 times
Jun 22 01:25:58 eserverx last message repeated 4 times
Ссылка на сообщение
Поделиться на других сайтах
Отож питання, як довго ті дущі будуть мене лякати, чи варті вони уваги, чи є яка молитва проти того?

До кінця днів ваших.

 

Молитва:

DELETE FROM `nethosts` where `ip`='172.16.0.107'

Після чого просто потицяти в "мережі та послуги" і подивитись як перегенерувався ваш ethrnet.conf. Амінь.

 

То відразу запитаю, що воно таке і чі є ліки?

Всьо погібло, тепер тричі "отче наш".

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

гг  оновив свій старий добрий 4.0 до поточного релізу

ще стільки не копіпастив запитів зараз :blink:

аж пальці заболіли, так, що оновлюйтесь вчасно 

Ссылка на сообщение
Поделиться на других сайтах
Всьо погібло, тепер тричі "отче наш".

 

Тепер усе по феньшую!

Дякую! -_-  -_-

 

 

 

так, що оновлюйтесь вчасно 

 

 

Стараюсь оновити одразу після виходу релізу  :rolleyes:

 

І не спиться ото вночі  :D

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

Прокляли конкуренти  ОЛТ після грози

до ОЛТ оптика, від тоже

і тут містика, пропадає олт рівно на 40-ві хвилині  по кілька разів на день

опитування 5 хв  swping поставив після появи, але всерівно в 40 хвилині.

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

абони звідти нежаліються, все ніби добре.

 

може хто стикався з таким бісом і підкаже чарівних заклинань а?

3A631jy.png

Відредаговано mgo
Ссылка на сообщение
Поделиться на других сайтах
Опубліковано: (відредаговано)
14:35:04.982337 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 172.16.4.1 tell 172.16.5.57, length 50
14:35:04.982341 ARP, Ethernet (len 6), IPv4 (len 4), Reply 172.16.4.1 is-at 02:c3:1b:af:d6:09 (oui Unknown), length 32
14:35:05.981736 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 172.16.4.1 tell 172.16.5.57, length 50
14:35:05.981742 ARP, Ethernet (len 6), IPv4 (len 4), Reply 172.16.4.1 is-at 02:c3:1b:af:d6:09 (oui Unknown), length 32

хто таке наблюдав і саме головне як лікувати?

сиплеться кожну секунду

172.16.4.1 НАС, 172.16.5.57 клієнт, мережа 172.16.4.0/22

 

клієнт непінгається, тицяєм роутер, ноут ситуація одинакова, висить на PON

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

 

alter.ini

SWITCH_PING_CUSTOM_SCRIPT="/bin/arp_switch_test"

cat /bin/arp_switch_test

#!/usr/local/bin/php
<?php
if (isset($argv[1])) {
        if(filter_var($argv[1], FILTER_VALIDATE_IP)) {
        $ip=$argv[1];
        $command='/usr/local/bin/sudo /usr/local/sbin/arping -v -c2  -i igb0 '.$ip;
                $pingResult=shell_exec($command);
                if (strpos($pingResult, 'time')) {
                   print('1');
                 } else {
                   print('0');
                 }      

        } else {
                print('FAIL:WRONG_IP');
        }

} else {
print('FAIL:NO_IP');
}
?>
Відредаговано nightfly
Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

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

Вхід

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

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


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