nightfly

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

Виправлено в Ubilling CURRENT 1.4.0 rev 8939

Має. Про що прямим текстом сказано в документації. А це тут до чого взагалі?

кіса, ти шо абідєлась? Так "не знайшли" чи "розглядали"? Визначтесь вже. Натяжка не затерпла ще? До слова на сусідній сторінці.

Неймовірно сильно шукали, так? От прямо 10-ма сантиметрами нижче. 20-ма сантиметрами нижче

Насправді відповіді на всі ваші запитання, максимально прямо розписано в документації до Філій, у відповідному розділі. Технологічно - можливо. Перше, що приходить в голову, це вирізати цей шматок коду і накрити його відповідним правом, намалювавши то окремим модулем в чорну магію. Технологічно - можливо. Перше, що приходить в голову, це відокремити право на мапу ОНУ в якесь окреме, та й все. Теоретично? Напевне можливо. Якщо ви вивезете, переписування всього рендеру даних ПОНізатора та інтеграцію, біс зна якими підпорками в існуючу реалізацію

Добридень. Отак взяли і спалились, що навіть не намагались зазирнути в FAQ Фу таким бути.

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

Ну може тому, що живе він в двох основних місцях - власне в /bin/ubapi та в базі. Той, що вказується при міграції, власне і потрапляє замість свіжозгенерованого в ubapi а той, що в базі, несподіваного але розвертається разом з базою з дампу

На якийсь запит куди? P.S. ні дякую, хочеться послухати ваші фантазії.

З якої причини, від ону щось провинно "приходити"?

UPD он, навіть документовано всьо чудово, для того ж мікротіка, що вище згадувався. Бери, роби R&D, пиши скільки влізе. Навіщо якусь шизу завідомо неробочу вигадувати? 😕

Теоретично - можливо. А який бюджет?

Відкриваю таємницю: з net.inet.ip.fw.one_pass в нас пайпи dummynet працюють, тупо як allow. Нема пайпа - малюєм allow. екхм ${FwCMD} add 62100 allow all from table\(2\) to table\(17\) ${FwCMD} add 62100 allow all from table\(17\) to table\(2\) всьо, молодець, можете переходити до наступного кроку:

Вам так, щоб поєбатись зaєбавши себе та інших, чи як нормальні люди роблять? Якщо, щоб пoєбaтись: робите список доменів "платіжних систем" та всіх їх CDN-ів парсите це все скриптом, наприклад dig-ом та резолвите кожен домен не забуваєте, що існують ще всякі гугло-аналітики та інші метрики не забуваєте, що існують ще DNS сервери, і вони потрібні користувачам, щоб до них добрались як це приблизно робиться можна подивитись десь тут тим же скриптом додаєте ту всю купу айпішок, в якусь вільну табличку та додаєте десь в початку фаєру аллоу траф

Ну причина, може бути, наприклад в тому, що його немає. Не так багато варіантів: 1. якась всрата вьюшка op_customers 2. в юзера стоїть галка "Заборонити онлайн платежі цьому користувачу" тоді це виглядає так: чи так якщо ж поля "Платіжний ID" взагалі немає, то це вимкнені опції вигляду OPENPAYZ_SUPPORT в alter.ini чи OPENPAYZ_ENABLED в userstats.ini, що виглядає наступним чином: або так

Ubilling 1.3.9 rev 8920 All Eyes on Lucian alter.ini: нова опція VSERVICES_AS_PAYMENTS котра керує поведінкою віртуальних сервісів. alter.ini: нова опція VISOR_CACHED_USERDATA що дозволяє вмикати та вимикати використання кешованих даних користувачів. alter.ini: нова опція BTRX24_POLLS_URL, що вказує URL для експорту опитувань. alter.ini: нова опція BTRX24_POLLS_VAR, що встановлює ім'я POST змінної для експорту опитувань та їх результатів. alter.ini: нова опція DEFERRED_SALE_ENABLED, що вмикає механіку продажів з розтермінуванням. ADcomments: трішки причеса

Добридень. Угу, як виявилось є таке. Право на створення резервних копій(BACKUP), як виявилось не давало права на завантаження резервних копій, їх видалення та завантаження резервних копій файлів конфігурації. Для цього таки необхідно було право ROOT. В очевидь, за кільканадцять років, цього не було виявлено, оскільки нікому не приходило в голову, наділяти настільки безграничними (ну по факту вся абонбаза + всі критичні доступи, в конфігах) привілеями, не довірених адміністраторів, котрі не заслуговують на повний доступ, та використовують обмежені у будь-чому аккаунти

О... ще один "внє палітіки". Звідки ж вони лізуть такі бл#дь.. Специальный перевод для тупеньких и лингвистически ограниченных: "довольно сложно сидеть и вытирать вам сопли, когда тебя ежедневно пытаются убить". Можете считать это специальной oхyитeльной операцией по десвинособакизации.

UPD: Мережі трішки не так працюють. Існують такі штуки як маршрутизація, маски, адресація оце от всьо скучне. Почитайте на дозвіллі про них, і ваше життя та розуміння того, шо відбувається навколо, радикально зміниться - гарантую

1. яким чином OS мала б вирішити, що пакети для адреси IP 62.80.138.134 потрібно форвардити на інтерфейс vmx0? 2. якого біса і з якої причини, вона взагалі повинна би це робити, якщо на інтерфейсі vmx0 висить мережа 172.16.0.1/24 і жодних інших аліасів та мереж я там не бачу? 3. чому пакети для підмережі 62.80.138.131/29 куди входить і 62.80.138.134 повинні матеріалізуватись десь окрім vmx1 де і висить мережа 62.80.138.131/29? 4. чому у 62.80.138.134 маска /32? А хто мав би бути його дефолтгейтвеєм який потрапляє в цю маску? Він сам собі? Хтось інший? Якась інша сусідня IP?

Немає за що, звертайтесь.

Можливо. Для цього просто треба вміти копіпастити і знати як користуватись вашим терміналом Підказка: ctrl-insert/shift-insert оце от всьо

Так. Тому, що там база нова. Але після розгортання вашої старої бази, власне разом з нею підійметься ваш старий серійник, власне разом з базою. На етапі встановлення, він запитується для того, щоб його було прописано в ubapi (і може ще десь, вже не пам'ятаю) замість того, котрий генерується на етапі встановлення.