madf

Это который прописан в SubnetFile? А что в логах Stargazer?

Что за remote_nas.conf?

Вот и я все чаще замечаю что по сельской местности у нас супертехнологии, PON и 100 Мбит, а в городе говномедь через форточку. Не вижу причин не работать. Как же тут можно одним NAS обойтись если села 3? Не, ну можно там VLAN'ами раскидать, но их как минимум надо где-то терминировать.

Судя по количеству букв "ш" - поляк?

мля та це ж я стопанув старгейзера хоча він ще з якогось дива у процесах висів. Не стопнув а намагався стартувати з лівим конфігом. Можливо паралельно з уже запущеним.

Мабуть до купи згорів і loopback Гляньте шо у stargazer.log після такої команди.

Печаль-печаль. Но по предоставленной инфе могу только посочувствовать.

/me зітхає у розпачі.

Ага, а рядок "kissbohda" у поле password у базі мабуть потрапило автомагічним чином? Дивіться в логи, там все буде.

Не могу закрыть тему. Зачем закрывать, пусть будет.

Переместил в правильный раздел.

Как что? Маршируют!

zachott, можете и мне скинуть приватовскую карту в личку? Помогу чем смогу.

В личку ответил, продублирую тут — на случай если кто еще на такие грабли наступит. Ограничение на длину логина — 31 символ.

Вопрос не в бренде. Мне сложно представить себе человека ставящего винду на сервер для чего-то кроме адового AD или какого-нибуть 1С. А просто скопипастить - не проще будет?

Фраза "kotikiyeah" вас почему-то не смутила "Authentication of clients is performed only by a "community string", in effect a type of password, which is transmitted in cleartext." Hyper-V... Это ж виндовая виртуализация? Нафига запускать биллинг, и что еще более странно - NAS - в виртуалке к винде? Касательно неработающего веба - вы бы хоть объяснили что именно не работает.

Отличный вопрос Обычно где-то в районе /var/log. Но это ж мускуль, у него они где угодно могут быть

Для начала хотя бы глянуть логи СУБД. А дальше - там есть что-то типа mysql_check или mysql_repair - не помню точно. Вот с их помощью и чинить. Хотя сдается мне, он просто не может приконнектиться к базе.

С базой.

Есть новости?

2014-05-11 18:12:45, плюс-минус час.

Да, тоже есть такое желание

В общем, вот до чего додумался. 2014-05-11 18:12:45 -- purestg2: Accepted new client connection (socket=65) 2014-05-11 18:12:58 -- purestg2: User molot39 (socket=65) is connected. 2014-05-11 18:13:03 -- purestg2: Terminating previous session (oldsocket=65) for user "molot39" 2014-05-11 18:13:03 -- purestg2: User molot39 (socket=65) is connected. 2014-05-11 18:13:03 -- purestg2: ERROR: Can't send reply: Bad file descriptor 2014-05-11 18:13:03 -- purestg2: ERROR: can't handle client connection for socket 65 18:12:45 — от pppd прилетает запрос на новый коннект. Соединение устанавливается. 18:12:58 — через 13 секунд (почему так долго?) по этому соединению прилетает запрос на коннект юзера. Ранее этот юзер не был авторизован. 18:13:03 — через 5 секунд по этому-же соединению снова (почему?) прилетает запрос на коннект юзера. Юзер уже авторизован, по этому плагин прибивает предыдущее соединение. Но оно не предыдущее а то-же самое, по этому соединение тупо разрывается. Плагин радостно сообщает что юзер соединен, хотя сокет 65 уже закрыт. Он пытается по этому сокету отправить ответ об успешной авторизации и, естественно, не может. На данный момент сокет 65 в системе свободен, но зарегистрирован в usersockets для юзера molot39. Ситуация повторяется снова: 2014-05-11 18:13:24 -- purestg2: Accepted new client connection (socket=65) 2014-05-11 18:13:34 -- purestg2: Terminating previous session (oldsocket=65) for user "molot39" 2014-05-11 18:13:34 -- purestg2: User molot39 (socket=65) is connected. 2014-05-11 18:13:34 -- purestg2: ERROR: Can't send reply: Bad file descriptor 2014-05-11 18:13:34 -- purestg2: ERROR: can't handle client connection for socket 65 Т.к. сокет 65 свободен — он снова назначается системой юзеру. Но в usersockets он все еще есть, по этому с задержкой 10 сек (почему?) плагин пытается отключить „старое“ соединение. Отключает самого себя и снова ошибка отправки подтверждения. molot39 на некоторое время затихает и сокет за номером 65 попадает новому юзеру: 2014-05-11 18:13:41 -- purestg2: Accepted new client connection (socket=65) 2014-05-11 18:13:41 -- purestg2: User molot13 (socket=65) is connected На этот раз авторизация происходит без задержки. Теперь сокет 65 есть сразу у двух юзеров в usersockets: у molot39 и molot13. И вот тут начинается веселуха! 2014-05-11 18:14:14 -- purestg2: Accepted new client connection (socket=84) 2014-05-11 18:14:17 -- purestg2: Terminating previous session (oldsocket=65) for user "molot39" 2014-05-11 18:14:17 -- purestg2: User molot39 (socket=84) is connected. Просыпается molot39, получает новый сокет 84 (потому что 65-й занят molot13) и с задержкой в 3 сек грохает свое „старое“ соединение. А на самом деле отключает molot13. На стороне pppd фиксируется обрыв соединения 65 для molot13 и через 4 секунды инициализируется попытка подключиться снова: 2014-05-11 18:14:21 -- purestg2: Accepted new client connection (socket=65) 2014-05-11 18:14:21 -- purestg2: BUG: can't find previous user socket for user "molot13" 65-й снова свободен, по этому он назначается снова. И все бы хорошо, но когда molot39 закрывал свое „старое“ соединение (которое на тот момент принадлежало двум юзерам: molot39 и molot13) он, по видимому, убрал его из usersockets для molot13. В результате получаем что юзер molot13 все еще авторизован, но записи с сокетом для него нету. Отсюда и „BUG: can't find previous user socket for user "molot13"“. Почему возникает изначальная проблема — пока не ясно. Возможно баг на стороне плагина для pppd. Как возможный воркераунд можно сделать проверку, чтобы не закрывать свой собственный сокет. Патч с воркераундом в приложении.fix-selfclose-patch.diff.txt

Пока нету, смотрю.

да верно, висит онлайн, вин7 выдаёт ошибку 619 могу дать stargazer.log, куда скинуть? Пожать и в почту - faust@stg.dp.ua