mgo Posted February 27, 2013 at 04:31 PM Author Posted February 27, 2013 at 04:31 PM (edited) Власне це він і означає - десь самі собі зробили deny from xxx to yyy via zzz я про це перше подумав, але сервер перезавантажувався після останньої модифікації фаєра і успішно працював. мене найбільше хвилює, що воно там без мене щось діється і я нерозумію що. піду аналізувати що де там зарубується. Edited February 27, 2013 at 04:33 PM by mgo
nightfly Posted February 27, 2013 at 04:33 PM Posted February 27, 2013 at 04:33 PM що воно там без мене щось діється дуже сумніваюсь
mgo Posted February 27, 2013 at 05:28 PM Author Posted February 27, 2013 at 05:28 PM (edited) передсмертний крик заліза Edited February 27, 2013 at 05:41 PM by mgo
mgo Posted March 3, 2013 at 01:08 PM Author Posted March 3, 2013 at 01:08 PM Определять онлайновость исходя из содержимого /content/dn ?DN_ONLINE_DETECT=1 накопав, що потрібно завжди онлайн поставити "ні" і користуватися авторизатором. тицніть де про авторизатор щось написано.
nightfly Posted March 3, 2013 at 01:11 PM Posted March 3, 2013 at 01:11 PM Забудьте про це - 2013-й рік на дворі. IPoE зараз модно.
mgo Posted March 3, 2013 at 01:20 PM Author Posted March 3, 2013 at 01:20 PM припускав, що авторизатор з DHCP логів підтягує хто получив адрес, так і визначати онлайн користувача. хоча можна обійтися.
nightfly Posted March 3, 2013 at 01:30 PM Posted March 3, 2013 at 01:30 PM "Авторизатор" це трохи не те. Загалом забудьте про це - нормально визначити наскільки користувач "онлайн" в 2013 році практично не можливо. DN_ONLINE_DETECT взагалі призначено для того, щоб мати уявлення - виконався для користувача OnConnect чи ні.
mgo Posted March 15, 2013 at 10:27 PM Author Posted March 15, 2013 at 10:27 PM (edited) сьгодні елепотреки вирубали на пів дня електрику ... результат - злетівші права на конфіг намед, 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 March 15, 2013 at 11:04 PM by mgo
mgo Posted March 16, 2013 at 12:38 PM Author Posted March 16, 2013 at 12:38 PM (edited) 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 March 16, 2013 at 02:59 PM by mgo
mgo Posted March 16, 2013 at 05:10 PM Author Posted March 16, 2013 at 05:10 PM (edited) З допомогою молотка зубила и какойто матери пари рядків в консолі усе відновив 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 March 16, 2013 at 08:29 PM by mgo
nightfly Posted March 16, 2013 at 11:16 PM Posted March 16, 2013 at 11:16 PM Таблички покрашились, при непередбаченій зупинці MySQL. Загалом в таких випадках варто робити наступне: 1. зупиняємо stargazer 2. шукаємо хто поламався з допомогою CHECK TABLE `імя_таблички` 3. рихтуємо її з допомогою REPAIR TABLE `імя_таблички` 4. запускаємо stargazer
mgo Posted March 17, 2013 at 07:43 AM Author Posted March 17, 2013 at 07:43 AM (edited) там пару табличок невдалося відрехтувати( непамятаю точно як воно написало - суть їм повний капець. відновлення з бекапу допомогло 1. зупиняємо stargazer....4. запускаємо stargazer цей момент упустив.глянув на реальний монітор (не через SSH) там 10-15 помилок підчас загрузки(кілька файлів і папок взагалі пропало, у кількох права злетіли,систему сильно покоцало, дивно, що взагалі працює, мабуть переставлю коли упс нормальний буду крутити.при перестановці1. узяти усі конфіги які правив2. бекап бази.на нову систему залити старі конфігибазі зробити щось таке mysql -u root -p -f stg < /home/mg/billing-db-backup-1363200990.sql решту дрібниць по ходу допилити.Нічого не упустив? Edited March 17, 2013 at 07:45 AM by mgo
nightfly Posted March 17, 2013 at 02:24 PM Posted March 17, 2013 at 02:24 PM Нічого не упустив? Здається - ні, не упустили. Критичними є конфіги: /config/mysql.ini /config/billing.ini /config/alter.ini /config/ymaps.ini /userstats/config/mysql.ini /userstats/config/userstats.ini Все інше затирається навіть при оновленнях обновлятором, після чого вищевказані конфіги повертаються на місце. Можна взагалі бути брутальним і після того як поставились з нуля інсталятором і розгортання бази перелити поверху каталог billing з бекапа (це такий варіант для надто лінивих). У будь якому випадку треба пам'ятати, що заливати дампи БД потрібно при незапущеному stargazer. Він читає такі таблички як users чи скажімо tariffs тільки на старті, після чого тільки перезаписує їх.
mgo Posted March 20, 2013 at 12:12 AM Author Posted March 20, 2013 at 12:12 AM (edited) ой ... у мене аваріяпісля відновлення бази з кирилецею така фігня сталася.Дімнич ТетÑна ЯроÑлавівна Додано через 5 хв.--------------------------------------------------------------------сам запоров - сам розрулив UTF8 кодировка Edited March 20, 2013 at 12:35 AM by mgo
nightfly Posted March 20, 2013 at 12:48 AM Posted March 20, 2013 at 12:48 AM cat ваш_дамп.sql | /usr/local/bin/mysql -u root -p stg --password=newpassword --default_character_set utf8
mgo Posted March 20, 2013 at 12:57 AM Author Posted March 20, 2013 at 12:57 AM (edited) та з кодуванням я розібрався ужеа оце мені точно не позубах 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 March 20, 2013 at 02:00 AM by mgo
nightfly Posted March 20, 2013 at 02:00 AM Posted March 20, 2013 at 02:00 AM 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 ;
nightfly Posted March 20, 2013 at 02:01 AM Posted March 20, 2013 at 02:01 AM За замовчуванням в бекап weblogs не потрапляє. Тому я і раджу на продакшні використовувати ось це.
nightfly Posted March 20, 2013 at 02:04 AM Posted March 20, 2013 at 02:04 AM А так, мало не забув. Таблички які не будуть звертатись кліканням по модулю бекапів з вебінтерфейсу - встановлюються опцією NOBACKUPTABLESLIKE=
mgo Posted March 20, 2013 at 02:06 AM Author Posted March 20, 2013 at 02:06 AM (edited) буду юзати я розрулив ситуацію інакше чуть убив старгейзер зніс базу запустив старгейзер, знову убив 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 March 20, 2013 at 02:08 AM by mgo
mgo Posted April 29, 2013 at 12:26 PM Author Posted April 29, 2013 at 12:26 PM установка UBinstaller-ом 8,3 i386 online неставить білінг /usr/local/www/ пусто офлайн нормально
nightfly Posted April 29, 2013 at 01:26 PM Posted April 29, 2013 at 01:26 PM установка UBinstaller-ом 8,3 i386 online неставить білінг і.....?
mgo Posted April 29, 2013 at 02:52 PM Author Posted April 29, 2013 at 02:52 PM і варіанта три є 1 туплю я 2 тупит залізо 3 баг в інсталяторі.
nightfly Posted April 29, 2013 at 02:57 PM Posted April 29, 2013 at 02:57 PM Ну давайте повгадуємо грунтуючись на "я зробив шось - воно не робить, я зробив шось інше - воно чось робить". Логи інсталяції складаються в /tmp/ub*
madf Posted April 29, 2013 at 03:27 PM Posted April 29, 2013 at 03:27 PM Ну давайте повгадуємо грунтуючись на "я зробив шось - воно не робить, я зробив шось інше - воно чось робить". Логи інсталяції складаються в /tmp/ub* Треба логи одразу зливати на Центральний Сервер , і тут же по ним малювати квитанцію до сплати
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now