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

[mgo 20]

cat docs/test_dump.sql | mysql -u root -p stg

колись канало))

 

думаю того, що шось зламалось. Перезапуск старгейзера не помагає?

ну дик  я зробив

killall stargazer

drop database stg

stargazer

killall stargazer

 

cat docs/test_dump.sql | mysql -u root -p -f stg

stargazer

 

http://wiki.ubilling.net.ua/doku.php?id=setupfreebsd отут вичитав

 

 

 Я на жаль не можу придумати ситуації, нафіга мені в практичному житті може стати потрібною кнопка очистки всієї бази в продакшні.

 

ну це не продакшин а віртуалка яку впадло переставляти кожен раз коли натупив щось з БД

Изменено 2014-09-03 15:01:15 пользователем mgo

[nightfly 1 252]

ну дик я зробив killall stargazer drop database stg stargazer killall stargazer cat docs/test_dump.sql | mysql -u root -p -f stg stargazer

Ну приблизно так. Тільки там залишається тоді дефолтний логіно-пароль старгейзера. Після зміни його штатним конфігуратором - ламаються права на старгейзер. Після того треба знову потушити старгейзер і зробити

UPDATE `admins` SET 
`ChgConf` = '1',
`ChgPassword` = '1',
`ChgStat` = '1',
`ChgCash` = '1',
`UsrAddDel` = '1',
`ChgTariff` = '1',
`ChgAdmin` = '1' WHERE `login` = 'admin';

(admin_rights_hotfix.sql) з убінсталлера.

 

 

ну це не продакшин а віртуалка яку впадло переставляти кожен раз коли натупив щось з БД

Екхм.

cp -R ubilling_test.vdi ubilling_test.vdi.bak

cp -R ubilling_test.vdi.bak ubilling_test.vdi

 

Інакше я б давно йоб...ся тестувати на собі то все гівно.

Изменено 2014-09-03 15:07:23 пользователем nightfly

[mgo 20]

Екхм.

 

cp -R ubilling_test.vdi ubilling_test.vdi.bak

 

cp -R ubilling_test.vdi.bak ubilling_test.vdi

 

погодьтеся  два рядки в консолі легше написати чим копіювати 8 гіг  ubilling_test.vdi

 

 

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

Изменено 2014-09-03 15:13:52 пользователем mgo

[nightfly 1 252]

 

погодьтеся  два рядки в консолі легше написати чим копіювати 8 гіг  ubilling_test.vdi

oO

nightfly@badass ~ $ du -hs zBak/FreeBSD\ 9.3_64.vdi.vdi 
2,5G	zBak/FreeBSD 9.3_64.vdi.vdi

nightfly@badass ~ $ du -hs ./FreeBSD\ 9.3_64.vdi.vdi
3,2G    ./FreeBSD 9.3_64.vdi.vdi

Ну і SSD рулить, да

[mgo 20]

Блін! недоходять руки собі вінду переставити... 4рік уже, все жду, що куплю собі пару вінтів і рейд 0 замутю  а Ви тут з ssd...

[mgo 20]

 

Тільки там залишається тоді дефолтний логіно-пароль старгейзера. Після зміни його штатним конфігуратором - ламаються права на старгейзер. Після того треба знову потушити старгейзер і зробити

 

яким чином міняти  старгейзер пароль штатним конфігуратором?

 

Після того треба знову потушити старгейзер і зробити

UPDATE `admins` SET
`ChgConf` = '1',
`ChgPassword` = '1',
`ChgStat` = '1',
`ChgCash` = '1',
`UsrAddDel` = '1',
`ChgTariff` = '1',
`ChgAdmin` = '1' WHERE `login` = 'admin';

без змін нічого не редагується

 

 

-------------------------------------------через 5 хв---------------------------------------------------

 

форум має магічну власитивість, тільки написав як приходить в голову рішення)

розібрався

 

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

Изменено 2014-09-03 18:10:16 пользователем mgo

[mgo 20]

Хурясь!

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

тепер питання що бракує моїм макам в імпортовані базі?

 

копіпаст мака в ручний ввід на вебморді чудово працює, єдина зміна то ма з 00:1E:33:6D:EB:EC робиться      00:1e:33:6d:eb:ec

 

треба попробувати

Изменено 2014-09-03 18:26:10 пользователем mgo

[mgo 20]

ТАТАММММ!

з маками в нижнім регістрі імпорт проходить успішно!

думаю варто зазначити це в доці.

 

ато через це виніс мозок саппорту хостінгу і Вам тут сьогодні поки знайшов.

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

Изменено 2014-09-03 18:50:27 пользователем mgo

[l1ght 377]

А ви майстерно самі собі робите проблем, а потім так само майстерно їх вирішуєте

Ще й з супроводом думок на форумі.

Я особисто нічого не маю проти - може кому й знадобиться

В мене теж буває, шо треба поміркувати "вслух".

[mgo 20]

 

А ви майстерно самі собі робите проблем

де?  у мене  потреба імпортувати базу, яка не імпортувалася, хоча робив усе по феншую

 

Ще й з супроводом думок на форумі.

 

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

 

Я особисто нічого не маю проти - може кому й знадобиться

 

ага для себе пишу теж)

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

Изменено 2014-09-04 08:19:07 пользователем mgo

[mgo 20]

 

Свежеустановленный Ubilling (да, да - с полностью чистой базой)

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

 

Змушений розбити на куски базу з поділом по NAS.

потрібно на кожен NAS своя підмережа

Який вихід?

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

брр секасу однако

Изменено 2014-09-04 18:36:41 пользователем mgo

[mgo 20]

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

благо нарив на форумі як mod_store_mysql  оновити)

[mgo 20]

 

/OpenPayz: в фронтенде XML протокола ПриватБанка исправлены несовпадения имен элементов, добавлен режим отладки.

в приваті кажуть вертає порожній результат

 

фронтент витягнув з ubcurrent privatx

* Фронтенд для получения уведомлений о платежах от Приватбанка
* Протокол: https://docs.google.com/document/d/1JrH84x2p4FOjm89q3xArvnEfsFXRnbIoa6qJFNq2VYw/edit#
*
* Возможно получение запросов как в виде отдельной POST переменной, так и в виде HTTP_RAW_POST_DATA
* Идентификация абонента по лицевому счету в виде paymentID материализующемуся из вьюшки вида:
* CREATE VIEW op_customers (realid,virtualid) AS SELECT users.login, CRC32(users.login) FROM `users`;
*/


/////////// Секция настроек
// Имя POST переменной в которой должны приходить запросы, либо raw в случае получения
// запросов в виде HTTP_RAW_POST_DATA.
define('PBX_REQUEST_MODE', 'raw');
//Режим отладки - заставляет данные подгружаться из файла debug.xml
define('PBX_DEBUG_MODE',0);

//Текст уведомлений и екзепшнов
define('ISP_NAME','NET'); //Информация о поставщике услуг
define('ISP_CODE','МФО'); // Id в ПС з анкети кодитифікатор
define('ISP_SERVICE_NAME','Интернет'); // Наименование услуги
define('ISP_SERVICE_CODE','1'); //Код услуги з анкети 1

//Исключения
define('PBX_EX_NOT_FOUND', 'Абонент не найден');
define('PBX_EX_DUPLICATE', 'Дублирование платежа');

// подключаем API OpenPayz
include ("/тут дописав шлях/libs/api.openpayz.php");

error_reporting(E_ALL);

// Send main headers
header('Last-Modified: ' . gmdate('r'));
header('Content-Type: text/html; charset=utf-8');
header("Cache-Control: no-store, no-cache, must-revalidate"); // HTTP/1.1
header("Pragma: no-cache");

Изменено 2014-09-05 14:52:12 пользователем mgo

[mgo 20]

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

 

по цьому запиту має вернути невідомий ls, раз  вернуло, підставив свій платіжний ID вернуло прізвище юзеря.

1.1.3 Пример запроса ПП по лицевому счету
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<Transfer xmlns="http://debt.privatbank.ua/Transfer" interface="Debt" action="Presearch">
    <Data xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="Payer">
        <Unit name="ls" value="710005007302" />
    </Data>
</Transfer> 

як повторити ?

ато я пальцем в небо тиць і є, а більше не хоче(

 

поставив сертифікат на мозілу, poster. 

і тестую

 

хоче, лишні табуляції і пропуски забрав і поїхало

 

 

 

оцим в мене дядя з привату тицяв і воно не їде

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<Transfer xmlns="http://debt.privatbank.ua/Transfer" action="Search" interface="Debt">
<Data xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="Payer">
<Unit name="bill_identifier" value="3871659694"/>
</Data>
</Transfer>

Изменено 2014-09-05 19:18:33 пользователем mgo

[mgo 20]

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

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<Transfer xmlns="http://debt.privatbank.ua/Transfer" action="Search" interface="Debt">
<Data xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="Payer">
<Unit name="bill_identifier" value="3871659694"/>
</Data>
</Transfer>

bill_identifier в коді немає, є   billIdentifier 

чому воно там матеріалізувалося незнаю коли в протоколі bill_identifier 

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<Transfer xmlns="http://debt.privatbank.ua/Transfer" action="Search" interface="Debt">
<Data xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="Payer">
<Unit name="billIdentifier" value="3871659694"/>
</Data>
</Transfer>

на такий запит є відповідь.

 

/OpenPayz: в фронтенде XML протокола ПриватБанка исправлены несовпадения имен элементов, добавлен режим отладки.

 

режим відладки наблюдаю, "исправлены несовпадения имен элементов" ненаблюдаю

 

гібрид попався

[nightfly 1 252]

 

bill_identifier в коді немає, є   billIdentifier

 

чому воно там матеріалізувалося незнаю коли в протоколі bill_identifier

Лиш вчора виправляли це заміною bill_identifier на billIdentifier та ls на billIdentifier: https://github.com/nightflyza/Ubilling/blob/master/openpayz/frontend/privatx/index.php#L476

 

 

 

режим відладки наблюдаю, "исправлены несовпадения имен элементов" ненаблюдаю

Най вони ідуть наxуй з такими розкладами. Вчора пів дня угрохали на те аби розібратись шо від тих поців прилітає і чому їх документація так слабо відповідає реальності. Якщо в них імена елементів XML-ки міняються спонтанно від випадка до випадка - най так і напишуть в документації (ага, поряд з іншими синтаксичними помилками - там половина семплів невалідна)

 

Клієнтам на яких зараз цей фронтенд тестимо - прилітає саме

<Unit name="billIdentifier" value="3871659694"/>

І власне так воно всьо робить.

 

Всі інші поки що сидять на старому GET фронтенді.

 

 

поставив сертифікат на мозілу, poster. 

і тестую

Нахуа? Включаєм режим дебага і кладемо запити в debug.xml - зирим відповіді в браузері.

 

P.S. Presearch взагалі нафіг не потрібен. Як виявилось він тре тільки водоканалу і всякому такому гівну з нечітким пошуком абонента.

Изменено 2014-09-05 21:05:17 пользователем nightfly

[mgo 20]

 

Нахуа? Включаєм режим дебага і кладемо запити в debug.xml - зирим відповіді в браузері.

буду знати, ато я думав що класти в debug.xml

 

Най вони ідуть наxуй з такими розкладами. Вчора пів дня угрохали на те аби розібратись шо від тих поців прилітає і чому їх документація так слабо відповідає реальності. Якщо в них імена елементів XML-ки міняються спонтанно від випадка до випадка - най так і напишуть в документації

 

ну мені попався блондинка, з коронною фразою 

Пытаюсь осуществить поиск, но возвращает пустой ответ.

а ще 

результат не изменился

Клієнтам на яких зараз цей фронтенд тестимо - прилітає саме

<Unit name="billIdentifier" value="3871659694"/>

 

І власне так воно всьо робить.

 

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

 

ps. я два дні визвонював по сапортах привата поки вони мене з'єднали з людиною яка зрозуміла про що я питаю  , дала доку і анкету.

[nightfly 1 252]

 

 

ps. я два дні визвонював по сапортах привата поки вони мене з'єднали з людиною яка зрозуміла про що я питаю , дала доку і анкету.

Приватбанк... традиційно...

[mgo 20]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193420

 

ng_mikrotik_eoip фіксять 

[mgo 20]

чудеса мля творяться!

проблема наблюдається на NAS rscriptd, Mikrotik добре їде.

 

поки не писалася табличка 47 то неписалася, а тепер мені усі в табличку 47 занесло!

і з грошима теж, та щей таблички 3 і 4 підчистило

перегружаю сервер бо killall strargazer довго убивається, спочатку усі в табличці 47, потім наблюдаю що потихо переносить в 3 і 4...

наблюдаю....

обнова?

 

10 хв  ніби усі проплачені по 3, 4 табличках розкидало

непроплачених в табл 47 немає   - порожня

дивлюся далі, бо люди кажуть що 10хв нет є 10 нема

 

30хв ніби нормально

з якого перепуго могло таке статися?

Изменено 2014-09-07 18:21:23 пользователем mgo

[jcomm 6]

чудеса мля творяться!

проблема наблюдається на NAS rscriptd, Mikrotik добре їде.

 

поки не писалася табличка 47 то неписалася, а тепер мені усі в табличку 47 занесло!

і з грошима теж, та щей таблички 3 і 4 підчистило

перегружаю сервер бо killall strargazer довго убивається, спочатку усі в табличці 47, потім наблюдаю що потихо переносить в 3 і 4...

наблюдаю....

обнова?

 

10 хв  ніби усі проплачені по 3, 4 табличках розкидало

непроплачених в табл 47 немає   - порожня

дивлюся далі, бо люди кажуть що 10хв нет є 10 нема

 

30хв ніби нормально

з якого перепуго могло таке статися?

Возможно теряется связь NAS'а с STG. Насколько я помню - при потере связи все отключаются..

Изменено 2014-09-07 19:28:53 пользователем jcomm

[nightfly 1 252]

 

 

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

tail -F /var/stargazer/allconnect.log на NAS-і. ЯКшо туда-сюда дісконнектяться, то так - проблема таки в якості звязку до NAS-a. В такому випадку або доводимо лінк до належної якості, або крутимо таймаути srcriptd догори, і сушимо сухарі.

[mgo 20]

Перший раз таке наблюдаю за два місяці юзання, тай редвін туди тримає 50/50 стабільно.

пакетлосс сюди 1-3% під нагрузкою в час пік, зазвичай немає взагалі.

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

 

після того ребуту проблема не наблюдається більше.

Изменено 2014-09-08 05:56:02 пользователем mgo

[mgo 20]

бага в коді  privatx/index.php

 $rawhash=$xmlParse['Transfer']['Data']['Reference'];

<?xml version="1.0" encoding="UTF-8" standalone="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="511325466" cancel="false">
<PayerInfo billIdentifier="3871659694"/>
<TotalSum>0.01</TotalSum>
<CreateTime>2014-09-08T14:49:42.096+03:00</CreateTime>
<ServiceGroup>
<Service sum="0.01" serviceCode="101"/>
</ServiceGroup>
</Data>
</Transfer>

Response

body <20140908145111439>: <br />
<b>Notice</b>: Undefined index: Reference in <b>/.../openpayz/frontend/privatx/index.php</b> on line <b>500</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>

Изменено 2014-09-08 12:18:44 пользователем mgo

[nightfly 1 252]

Там всьо плохо. Продовжуєм тестувати і правити з приватом.  Актуальні зміни тут: https://github.com/nightflyza/Ubilling/blob/master/openpayz/frontend/privatx/index.php

 

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