May 1st, 2008

ppp Ppp PPp PPP

Какая-то беда с ppp. Началась недавно.
#uname -a
OpenBSD router.home.local 4.2 GENERIC#375 i386

Недавно его пропатчил, но не уверен, что связано с этим, хотя началось приблизительно в это время. Да и если связано, то у ОпенБСД философия "только вперед", никаких откатов. :)

Проблема такая. Отваливается интернет, при том, что интерфейс tun0 поднят, ip получен, шлюз прописан. Более того, вообще странным образом этот роутер ведет себя. Не пингуется или пингуется с большими задержками, по ssh так же - либо не входит совсем, либо с большими задержками. При том, он отвечает на первичные запросы (судя по strace и telnet), стопорится где-то ближе к запросу пароля. Притом, если установить ssh-сессию заранее, то все работает зашибись (как я и смог ввести ifconfig итд).
Мне удалось сэмулировать проблему путем перезагрузки adsl модема, после чего клиент дошел до кондиции. Видимо, у меня отваливается adsl периодически. Но это не предмет разговора. Вопрос в другом. ppp я поднимаю таким образом:
# cat /etc/hostname.tun0
!/usr/sbin/ppp -unit 0 -quiet -ddial pppoe; sleep 5
Конфиг:
Collapse )
То есть, -ddial при падении должна "перезванивать", lqr-ы отсылаются каждые пять секунд. По логам - глухо. Обрыв лога (в который каждые пять секунд валится такое:
Apr 30 23:49:08 router ppp[12544]: tun0: LCP: deflink: RecvEchoRequest(99) state = Opened
Apr 30 23:49:08 router ppp[12544]: tun0: LCP: deflink: SendEchoReply(99) state = Opened
Apr 30 23:49:18 router ppp[12544]: tun0: LCP: deflink: RecvEchoRequest(100) state = Opened
Apr 30 23:49:18 router ppp[12544]: tun0: LCP: deflink: SendEchoReply(100) state = Opened)
- как раз в момент обрыва связи.
То есть, ppp вроде контролирует связь, но только до ее обрыва. Дальше канал кратковременно падает, после чего удаленный раздатчик знать меня не знает и пинги не принимает(аплинк-шлюз).

Далее анализировать и тестить не имею времени - диплом. Помогите кто чем может?

P.S. подписал в конфиг enable lqr echo и set echoperiod 5, теперь в логи фигачится в два раза больше. :)
  • dil

Средство централизованного управления эккаунтами

Есть несколько десятков юниксовых машин (линукс, солярис, AIX), поделенных на логические группы (веб-серверы, базы данных, серверы приложений, разработческие машины...), причём даже в одной группе могут присутствовать разные ОС. Задача осложняется тем, что машины физически раскиданы по нескольким датацентрам, связь между которыми иногда теряется.
И несколько десятков пользователей.

Ищется средство для централизованного управления пользовательскими эккаунтами (и паролями) в этом зоопарке.
Скажем, администраторы имеют право заходить куда угодно, девелоперы - на девелоперские машины, администраторы БД - на БД, и т.п.
Плюс чтобы при появлении нового сотрудника не надо было ходить по всем машинам и его добавлять, а при увольнении - везде удалять.
AD+winbind по некоторым причинам не подходит.

Пока надумался только NIS. Но я с ним никогда дела не имел. Посему вопрос: можно ли в нём без шаманских плясок реализовать вышеозначенное? С делением пользователей и машин на группы, репликацией баз на локальные серверы в каждом датацентре, и пр.
hope

(no subject)

Приветствую, многоуважаемые руты.
Есть конфигурация такого плана: сервер с FreeBSD 7.0-RELEASE (GENERIC ядро), PCI-E контроллер Adaptec AIC-7901 (одноканальный), внешний рейд на 5 Тб (7 lun'ов).
Возникла проблема. При включении сервера, если шнурок от рейда воткнут в контроллер - имеем уход ОСи в медитацию на стадии "Waiting 5 seconds for SCSI device to settle"; как только выдергиваем шнурок - загрузка продолжается как ни в чем не бывало. В логах при этом такая вот картина. Дождаться окончания "5 seconds" можно - примерно через час, на da31, процесс заканчивается.
Если подключать рейд нагорячую - имеем пустоту в messages; делаем camcontrol rescan all - часовое молчание, в логах картина аналогичная приведенной выше, и как итог
# ls /dev/|grep da|grep -v da0|wc -l
31
на da0 живет штатный винт с ОСью.

P.S. Напрягает момент, что системой контроллер определятся как AIC-7902 (двухканальный), хотя он абсолютно точно 7901.
Что это может быть и как это починить?