Jump to content
Local
mgo

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

Recommended Posts

 

Власне це він і означає - десь самі собі зробили deny from xxx to yyy via zzz 
 
я про це  перше подумав, але сервер перезавантажувався після  останньої модифікації фаєра і успішно працював.
мене найбільше хвилює, що воно там без мене щось діється і я нерозумію що.
 
піду аналізувати що де там зарубується.
Edited by mgo

Share this post


Link to post
Share on other sites

що воно там без мене щось діється

дуже сумніваюсь

Share this post


Link to post
Share on other sites

передсмертний крик заліза   :wacko:

Edited by mgo

Share this post


Link to post
Share on other sites

 

Определять онлайновость исходя из содержимого /content/dn ?

DN_ONLINE_DETECT=1

 

накопав, що потрібно завжди онлайн поставити "ні"

і користуватися авторизатором.

тицніть  де про авторизатор щось написано.

Share this post


Link to post
Share on other sites

Забудьте про це - 2013-й рік на дворі. IPoE зараз модно.

Share this post


Link to post
Share on other sites

припускав, що авторизатор з DHCP логів підтягує хто получив адрес, так і визначати онлайн користувача.

хоча  можна обійтися.

Share this post


Link to post
Share on other sites

"Авторизатор" це трохи не те.

Загалом забудьте про це - нормально визначити наскільки користувач "онлайн" в 2013 році практично не можливо. DN_ONLINE_DETECT взагалі призначено для того, щоб мати уявлення - виконався для користувача OnConnect чи ні.

Share this post


Link to post
Share on other sites

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

результат - злетівші права на конфіг намед, uhw глючит і  ще х-зна  що там глючит

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

 

погуглив чуток  і  нагугглив таку штуку

 

1. Брати упса треба фірми APC

2. /usr/ports/sysutils/apcupsd - поставити з портів фірмову прогу і відстроїти її.

 

пошастав магазинами і поняв, що на  Smart деньгу кидати жаба душит, зупинився на таких моделях

APC Back-UPS 650VA (BX650CI-RS) особливо радує діапазон 140-300В вхідна напруга

або 

APC Back-UPS ES 700VA (BE700G-RS) 

обидва на USB порт.

на мої 100-150 Ват вони малиб тримати +- 15-20 хв. 

 

від такого упса я чеаю наступного функціоналу:

виключення сервера згідно налаштувань apcupsd (припустим 30% залишок батареї)

увімкнення сервера при відновленні електопостачання (упс без сторонньї допомоги на вихід дає 220)

на сервері в біосі налаштовано автоматичний старт при відновленні живлення.
 

у кого є досвід роботи з упсами поправте якщо туплю відносно очікуваного функціоналу.

Edited by mgo

Share this post


Link to post
Share on other sites








Warning: mysql_query(): Unable to save result set in /usr/local/www/apache22/data/billing/api/libs/api.workaround.php on line 1748

Warning: mysql_num_fields() expects parameter 1 to be resource, boolean given in /usr/local/www/apache22/data/billing/api/libs/api.workaround.php on line 1749

Warning: mysql_query(): Unable to save result set in /usr/local/www/apache22/data/billing/api/libs/api.workaround.php on line 1748

Warning: mysql_num_fields() expects parameter 1 to be resource, boolean given in /usr/local/www/apache22/data/billing/api/libs/api.workaround.php on line 1749

 

при спробі зробити резервну копію,







Warning: mysql_query(): Unable to save result set in /usr/local/www/apache22/data/uhw/libs/api.mysql.php on line 262
 wrong data input: SELECT COUNT(`id`) from `uhw_brute` WHERE `mac`='1c:6f:65:4e:9d:хх'

 

UHW видає 

 

гугл каже, що пошкоджена база(

Repair table ... курю як юзати.

добре є  бекап бази двох денної давності.

Edited by mgo

Share this post


Link to post
Share on other sites

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

 

 



mysqlcheck -A -auto-repair -u root -p
mysql -u root -p -f stg < /home/mg/billing-db-backup-1363200990.sql
mysqlcheck -r -A -uroot -p
 

незнаю точно що допомогло, але  функціонал бази відновлений 

Edited by mgo

Share this post


Link to post
Share on other sites

Таблички покрашились, при непередбаченій зупинці MySQL.

 

Загалом в таких випадках варто робити наступне:

1. зупиняємо stargazer

2. шукаємо хто поламався з допомогою CHECK TABLE `імя_таблички`

3. рихтуємо її з допомогою REPAIR TABLE `імя_таблички`

4. запускаємо stargazer

Share this post


Link to post
Share on other sites

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

непамятаю точно як воно написало - суть їм повний капець.

відновлення з бекапу допомогло

1. зупиняємо stargazer
....
4. запускаємо stargazer



цей момент упустив.

глянув на реальний монітор (не через SSH) там 10-15 помилок підчас загрузки(
кілька файлів і папок взагалі пропало, у кількох права злетіли,
систему сильно покоцало, дивно, що взагалі працює, мабуть переставлю коли упс нормальний буду крутити.

при перестановці
1. узяти усі конфіги які правив
2. бекап бази.
на нову систему залити старі конфіги
базі зробити щось таке

mysql -u root -p -f stg < /home/mg/billing-db-backup-1363200990.sql



решту дрібниць по ходу допилити.

Нічого не упустив?

Edited by mgo

Share this post


Link to post
Share on other sites

Нічого не упустив?

Здається - ні, не упустили.

 

Критичними є конфіги:

/config/mysql.ini

/config/billing.ini

/config/alter.ini

/config/ymaps.ini

/userstats/config/mysql.ini

/userstats/config/userstats.ini

 

Все інше затирається навіть при оновленнях обновлятором, після чого вищевказані конфіги повертаються на місце.

 

Можна взагалі бути брутальним і після того як поставились з нуля інсталятором  і розгортання бази перелити поверху каталог billing з бекапа (це такий варіант для надто лінивих).

У будь якому випадку треба пам'ятати, що заливати дампи БД потрібно при незапущеному stargazer. Він читає такі таблички як users чи скажімо tariffs тільки на старті, після чого тільки перезаписує їх.

Share this post


Link to post
Share on other sites

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

Дімнич ТетÑна ЯроÑлавівна

Додано через 5 хв.--------------------------------------------------------------------
сам запоров - сам розрулив UTF8 кодировка

Edited by mgo

Share this post


Link to post
Share on other sites

cat ваш_дамп.sql | /usr/local/bin/mysql -u root  -p stg --password=newpassword --default_character_set utf8

Share this post


Link to post
Share on other sites

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

 

wrong data input: INSERT INTO `weblogs` (`id`,`date`,`admin`,`ip`,`event`) VALUES(NULL,'2013-03-03 03:01:00','user','192.168.1.202','BALANCEADD (xxxxxx) ON 1')




при спробі записати з білінга щось в базу, але ж я обожнюю збочення і phpMyAdmin то все роблю
буду пробувати писати знову рядок в консолі

cat ваш_дамп.sql | /usr/local/bin/mysql -u root -p stg --password=newpassword --default_character_set utf8


дуже влучно дякую!

..... 5 хв і пара рядків в консолі.

і як завжди один рядок від nightfly розрулює ситуацію!
ДЯКУЮ, усе працює. Edited by mgo

Share this post


Link to post
Share on other sites

CREATE TABLE IF NOT EXISTS `weblogs` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`date` datetime NOT NULL,
`admin` varchar(45) DEFAULT NULL,
`ip` varchar(64) DEFAULT NULL,
`event` varchar(255) DEFAULT NULL,
PRIMARY KEY (`id`),
KEY `date` (`date`),
KEY `date_2` (`date`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 AUTO_INCREMENT=1 ;

Share this post


Link to post
Share on other sites

За замовчуванням в бекап weblogs не потрапляє. Тому я і раджу на продакшні використовувати ось це.

Share this post


Link to post
Share on other sites

А так, мало не забув. Таблички які не будуть звертатись кліканням по модулю бекапів з вебінтерфейсу - встановлюються опцією NOBACKUPTABLESLIKE=

Share this post


Link to post
Share on other sites

буду юзати

 

я розрулив ситуацію інакше чуть

убив старгейзер

зніс базу

запустив старгейзер, знову убив



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

розгорнув базу

і відновив базу

 

cat ваш_дамп.sql | /usr/local/bin/mysql -u root -p stg --password=newpassword --default_character_set utf8
запустив старгейзер і радуюсь роботою білінгу!
Edited by mgo

Share this post


Link to post
Share on other sites

установка UBinstaller-ом 8,3 i386 online неставить білінг

/usr/local/www/   пусто

офлайн нормально

Share this post


Link to post
Share on other sites

установка UBinstaller-ом 8,3 i386 online неставить білінг

і.....?

Share this post


Link to post
Share on other sites

і варіанта три є

1 туплю я

2 тупит залізо

3 баг в інсталяторі.

Share this post


Link to post
Share on other sites

Ну давайте повгадуємо грунтуючись на "я зробив шось - воно не робить, я зробив шось інше - воно чось робить".

 

Логи інсталяції складаються в /tmp/ub*

Share this post


Link to post
Share on other sites

Ну давайте повгадуємо грунтуючись на "я зробив шось - воно не робить, я зробив шось інше - воно чось робить".

 

Логи інсталяції складаються в /tmp/ub*

Треба логи одразу зливати на Центральний Сервер , і тут же по ним малювати квитанцію до сплати :)

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

  • Similar Content

    • By Vitaliy1984
      добрый день как настроить порт для подключения к ubilling ХХ.ХХ.Х.ХХ:2606/billing  (сейчас на данный момент доступ к биллингу такого формата ХХ.ХХ.ХХ.ХХ/billing необходимо настроить доступ к билингу через порт   (ХХ.ХХ.ХХ.ХХ - IP адресс)
       
    • By Karfax
      Здравствуйте!
      Пишу api на php для добавления пользователя. Скрипту передаются логин, пароль, ip, mac, email, имя пользователя.
      Пробую добавлять пользователя путем прямого insert в mysql в таблицы users, email, nethost, realname, notes (может ещё что пропустил). В интерфейсе юбилинга пользователь появляется, в проверке пользователя на целостность показывает по всем полям OK, но вот у созданного пользователя не меняется тариф, тупо ничего не происходит. Также, если посмотреть через конфигуратор самого старгейзера, то пользователь там не появляется.
      Может быть где-то нужно какой-то кеш обновить или скрипт запустить чтобы юзер попал в старгейзер?
    • By NETOS
      Доброго времени!
      Подскажите пожалуйста, посоветуйте, что может быть не так, в 00:00 отваливается инет у абонов. Сервер доступа rscriptd, 4 месяца все было отлично, но последние пару неделю уже с десяток абонов зависли пока Ресет в учетке не нажмёшь, инета нет.
       
      allconnect.log с BRAS
      root@BRAS:/var/stargazer # cat allconnect.log | grep Litovka 2020.12.01 17:21:55 DISCONNECT: ID-700;LOGIN-Litovka;IP-10.0.4.3;CASH-85.7419 2020.12.01 17:21:56 CONNECT: ID-700;LOGIN-Litovka;IP-10.0.4.3;CASH-85.7419;SPEED-100000;UPSPEED-100000,MAC-f8:1a:67:ae:3e:c9 2020.12.07 11:33:01 DISCONNECT: ID-701;LOGIN-Litovka;IP-10.0.4.3;CASH-47.0323 2020.12.07 11:33:27 CONNECT: ID-701;LOGIN-Litovka;IP-10.0.4.3;CASH-47.0323;SPEED-100000;UPSPEED-100000,MAC-f8:1a:67:ae:3e:c9 2020.12.08 06:08:17 DISCONNECT: ID-701;LOGIN-Litovka;IP-10.0.4.3;CASH-40.5806 2020.12.08 06:13:43 CONNECT: ID-701;LOGIN-Litovka;IP-10.0.4.3;CASH-40.5806;SPEED-100000;UPSPEED-100000,MAC-f8:1a:67:ae:3e:c9 2020.12.15 00:00:31 DISCONNECT: ID-705;LOGIN-Litovka;IP-10.0.4.3;CASH-1.87096 2020.12.15 13:43:48 CONNECT: ID-705;LOGIN-Litovka;IP-10.0.4.3;CASH--4.58065;SPEED-100000;UPSPEED-100000,MAC-f8:1a:67:ae:3e:c9 2020.12.17 11:22:22 DISCONNECT: ID-707;LOGIN-Litovka;IP-10.0.4.3;CASH-267.516 2020.12.17 11:22:22 CONNECT: ID-707;LOGIN-Litovka;IP-10.0.4.3;CASH-267.516;SPEED-100000;UPSPEED-100000,MAC-f8:1a:67:ae:3e:c9
      stargazer.log с базы 
      2020-12-01 17:21:55 -- Admin 'admin', 127.0.0.1: User 'Litovka': 'alwaysOnline' parameter changed from '1' to '0'. 2020-12-01 17:21:55 -- Admin 'admin', 127.0.0.1: User 'Litovka': 'alwaysOnline' parameter changed from '0' to '1'. 2020-12-02 00:00:25 -- Admin '@stargazer', 0.0.0.0: User 'Litovka': 'cash' parameter changed from '85.741933' to '79.290320'. Subscriber fee charge 2020-12-03 00:00:24 -- Admin '@stargazer', 0.0.0.0: User 'Litovka': 'cash' parameter changed from '79.290320' to '72.838707'. Subscriber fee charge 2020-12-04 00:00:24 -- Admin '@stargazer', 0.0.0.0: User 'Litovka': 'cash' parameter changed from '72.838707' to '66.387094'. Subscriber fee charge 2020-12-05 00:00:24 -- Admin '@stargazer', 0.0.0.0: User 'Litovka': 'cash' parameter changed from '66.387094' to '59.935481'. Subscriber fee charge 2020-12-06 00:00:24 -- Admin '@stargazer', 0.0.0.0: User 'Litovka': 'cash' parameter changed from '59.935481' to '53.483868'. Subscriber fee charge 2020-12-07 00:00:25 -- Admin '@stargazer', 0.0.0.0: User 'Litovka': 'cash' parameter changed from '53.483868' to '47.032255'. Subscriber fee charge 2020-12-08 00:00:24 -- Admin '@stargazer', 0.0.0.0: User 'Litovka': 'cash' parameter changed from '47.032255' to '40.580642'. Subscriber fee charge 2020-12-09 00:00:24 -- Admin '@stargazer', 0.0.0.0: User 'Litovka': 'cash' parameter changed from '40.580642' to '34.129029'. Subscriber fee charge 2020-12-10 00:00:24 -- Admin '@stargazer', 0.0.0.0: User 'Litovka': 'cash' parameter changed from '34.129029' to '27.677416'. Subscriber fee charge 2020-12-11 00:00:24 -- Admin '@stargazer', 0.0.0.0: User 'Litovka': 'cash' parameter changed from '27.677416' to '21.225803'. Subscriber fee charge 2020-12-12 00:00:24 -- Admin '@stargazer', 0.0.0.0: User 'Litovka': 'cash' parameter changed from '21.225803' to '14.774190'. Subscriber fee charge 2020-12-13 00:00:25 -- Admin '@stargazer', 0.0.0.0: User 'Litovka': 'cash' parameter changed from '14.774190' to '8.322577'. Subscriber fee charge 2020-12-14 00:00:25 -- Admin '@stargazer', 0.0.0.0: User 'Litovka': 'cash' parameter changed from '8.322577' to '1.870964'. Subscriber fee charge 2020-12-15 00:00:25 -- Admin '@stargazer', 0.0.0.0: User 'Litovka': 'cash' parameter changed from '1.870964' to '-4.580649'. Subscriber fee charge 2020-12-15 13:43:39 -- Admin 'admin', 127.0.0.1: User 'Litovka': 'creditExpire' parameter changed from '0' to '1608588000'. 2020-12-15 13:43:47 -- Admin 'admin', 127.0.0.1: User 'Litovka': 'credit' parameter changed from '0.000000' to '200.000000'. 2020-12-16 00:00:24 -- Admin '@stargazer', 0.0.0.0: User 'Litovka': 'cash' parameter changed from '-4.580649' to '-11.032262'. Subscriber fee charge 2020-12-17 00:00:25 -- Admin '@stargazer', 0.0.0.0: User 'Litovka': 'cash' parameter changed from '-11.032262' to '-17.483875'. Subscriber fee charge 2020-12-17 09:28:41 -- Admin 'admin', 127.0.0.1: User 'Litovka': 'cash' parameter changed from '-17.483875' to '267.516125'. 2020-12-17 11:22:21 -- Admin 'admin', 127.0.0.1: User 'Litovka': 'alwaysOnline' parameter changed from '1' to '0'. 2020-12-17 11:22:21 -- Admin 'admin', 127.0.0.1: User 'Litovka': 'alwaysOnline' parameter changed from '0' to '1'.  

    • By ppv
      Скажіть будь ласка чи хтось стикався коли killall не зупиняє stargazer, або зупиняє через пів год? Якщо пробувати для прикладу killall bandwidthd вбиває зразу. 
      Процес stargazer може пропасти через пів год. Інколи зразу.
      Ubiling розгорнутий на віртуальній машині в proxmox. (відновлений з бекапу ver 1.1.0). cтандартними засобами ubilling.
      Підкажіть куди копати. 
    • By eminema_nema
      Всім доброго дня!
      Встановлено Ubilling (1.1.2 rev 7784) на FreeBSD 12.1. Налаштовано дві мережеві карти, одна для зв'язку з  NAS (фізичний Mikrotik), інша - реальна ІР.
      NAS налаштовано таким чином. Все чудово працює, користувачів при зміні стану Активний\Неактивний перекидає по відповідних списках адрес. 
      Після встановлення ssl (letsencrypt) - перестає працювати, користувач на мікротіку залишається в списку Not Allow, хоча в білінгу він активний і навпаки. Якщо сам натисну кнопку "Регенерація бази" то лише тоді відбудеться зміна в списках адрес.
      Логи cron показують, що регенерація бази multigen відбувається кожної хвилини. SSL встановлено для адмінки та кабінету користувача.
      В чому може бути проблема?


×