форумы  помощь  поиск  регистрация  майллист  ВХОД  слежка

Вариант для распечатки		Архивированная нить - только для чтения!  Пред. тема | След. тема
Форумы OpenNET: Виртуальная конференция (Public)
Изначальное сообщение		[Проследить за развитием треда]

"Удалённое исследование конфигурации 'железа'"
Сообщение от RapaNui on 12-Ноя-02, 19:20  (MSK)
Здравствуйте. Если кто уже решал такую проблемку - поделитесь опытом. Необходимо удалённо собрать информацию о конфигурации оборудования под UNIX-машиной. Попросту говоря - нужен список "железа", работающего на машине. Специально не уточняю конкретный вид операционной системы так как меня интересует общий подход к проблеме - протоколы, сервисы. Моё воображение подсказывает мне в качестве протокола лишь SNMP (может ещё что?). Но тогда непонятно как генерировать MIB'ы описания оборудования. Да и секьюрити оставляет желать лучшего... В общем, буду рад любой информации по этому поводу. Спасибо за ответы.
	Рекомендовать в FAQ | Cообщить модератору | Наверх

Индекс форумов | Темы | Пред. тема | След. тема

Сообщения по теме

1. "RE: Удалённое исследование конфигурации 'железа'"
Сообщение от Ilya on 13-Ноя-02, 09:31  (MSK)
>информацию о конфигурации оборудования под UNIX-машиной. Попросту говоря >нужен список "железа", работающего на машине. Специально не уточняю конкретный >вид операционной >системы так как меня интересует общий подход к проблеме - протоколы, >сервисы. На мой взгляд слишком уж зависит решение этой задачи от платформы. Может пойти по пути демона на какой-либо обной машине (вроде как сервер для сбора данных :) и клиентов, посылающих ему сообщения в оговоренном формате независимо от платформы? А клиентов делать под каждую ОС конкретно (для SCO - /var/adm/message поглядеть, на Sparc -prtconf/prtdiag запустить и т.п.) А в SNMP для этой цели я разочаровался - то что видел толком ничего не сообщало. Единственное что удалось нормально сделать - контроль за состоянием ибп и за температурой в серверных :( Удачи
	Рекомендовать в FAQ | Cообщить модератору | Наверх

	2. "RE: Удалённое исследование конфигурации 'железа'"
	Сообщение от Mercurius on 13-Ноя-02, 09:44  (MSK)
	>>информацию о конфигурации оборудования под UNIX-машиной. Попросту говоря >>нужен список "железа", работающего на машине. Специально не уточняю конкретный >>вид операционной >>системы так как меня интересует общий подход к проблеме - протоколы, >сервисы. > >На мой взгляд слишком уж зависит решение этой задачи от платформы. Может >пойти по пути демона на какой-либо обной машине (вроде как сервер >для сбора данных :) и клиентов, посылающих ему сообщения в оговоренном >формате независимо от платформы? А клиентов делать под каждую ОС конкретно >(для SCO - /var/adm/message поглядеть, на Sparc -prtconf/prtdiag запустить и т.п.) > >А в SNMP для этой цели я разочаровался - то что видел >толком ничего не сообщало. Единственное что удалось нормально сделать - контроль >за состоянием ибп и за температурой в серверных :( > >Удачи К вопросу об SNMP - через него можно на обычной UNIX-машине смотреть загруженность сети на интерфейсах? На Цисках-то народ смотрит, я вроде все поднял, правда с дефолтными настройками, а оно мне 0 выдает. А хотел бы чтобы показывало по каждому интерфейсу. Может кто знает?
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	3. "RE: Удалённое исследование конфигурации 'железа'"
	Сообщение от Ilya on 13-Ноя-02, 10:21  (MSK)
	>К вопросу об SNMP - через него можно на обычной UNIX-машине смотреть >загруженность сети на интерфейсах? На Цисках-то народ смотрит, я вроде все >поднял, правда с дефолтными настройками, а оно мне 0 выдает. А >хотел бы чтобы показывало по каждому интерфейсу. >Может кто знает? я использую ucdsnmp 1) запускаешь snmpd от ucdsnmp 2) snmpwalk твой_хост public interfaces и смотришь результат, если mib'ы настроены, тогда даже получишь текстовку к результату :) 3) загрузка интерфейса - можно оценить запуская snmpwalk через определенные промежутки времени и оценивая скорость прироста принятых/отправленных пакетов  :))
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	4. "RE: Удалённое исследование конфигурации 'железа'"
	Сообщение от RapaNui on 13-Ноя-02, 16:24  (MSK)
	Здравствуйте. >На мой взгляд слишком уж зависит решение этой задачи от платформы. Может >пойти по пути демона на какой-либо обной машине (вроде как сервер >для сбора данных :) и клиентов, посылающих ему сообщения в оговоренном >формате независимо от платформы? А клиентов делать под каждую ОС >конкретно >(для SCO - /var/adm/message поглядеть, на Sparc -prtconf/prtdiag >запустить и т.п.) Я думал об этом, но специфика не та. Вот что уже есть: 1) есть менеджер на сервере, собирающий инфу. на нём я могу реализовать всё, что угодно. 2) есть куча клиентов. на них очень нежелательна какая-либо клиентская часть. идеал - просто настройка какого-нибудь не очень экзотического сервиса. ну и секьюрити, конечно, тоже надо - а то так можно просто расшать всё для всех - и проблем никаких. >А в SNMP для этой цели я разочаровался - то что видел >толком ничего не сообщало. Единственное что удалось нормально сделать - >контроль за состоянием ибп и за температурой в серверных :( а я и не планирую юзать стандартные мибы snmpd - там ничего нет. если связываться с snmp, то придётся делать клиентскую часть :( , которая генерит нужные мибы и подсовывает их демону. но это есть плохо. так что вопрос открыт... > >Удачи спасибо.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	5. "RE: Удалённое исследование конфигурации 'железа'"
	Сообщение от Ilya on 14-Ноя-02, 02:05  (MSK)
	>2) есть куча клиентов. на них очень нежелательна какая-либо клиентская >часть. идеал - просто настройка какого-нибудь не очень экзотического >сервиса. ну и секьюрити, конечно, тоже надо - а то так можно >просто расшать всё для всех - и проблем никаких. а чем понизит безопасность клиент который коннектится (сам) к серверу на другой машине и ТОЛЬКО и делает, что отдает десяток-другой TCP-пакетов? >>а я и не планирую юзать стандартные мибы snmpd - там ничего >нет. если связываться с snmp, то придётся делать клиентскую часть :( >, которая >генерит нужные мибы и подсовывает их демону. но это есть плохо. сложно однако :(
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	6. "RE: Удалённое исследование конфигурации 'железа'"
	Сообщение от RapaNui on 14-Ноя-02, 02:28  (MSK)
	>>2) есть куча клиентов. на них очень нежелательна какая-либо клиентская >>часть. идеал - просто настройка какого-нибудь не очень экзотического >>сервиса. ну и секьюрити, конечно, тоже надо - а то так можно >>просто расшать всё для всех - и проблем никаких. >а чем понизит безопасность клиент который коннектится (сам) к серверу на другой >машине и ТОЛЬКО и делает, что отдает десяток-другой TCP-пакетов? я, наверное, неправильно выразился... требование к секьюрити - это одно. а требование к отсутствию клиентской части - это другое. просто такова специфика задачи - администраторы локальных машин НЕ ДОЛЖНЫ ставить какой-либо клментский софт. максимум того, что на них можно переложить - это настройка какого-либо не очень экзотического сервиса. всё остальное должно делаться на сервере. >>>а я и не планирую юзать стандартные мибы snmpd - там ничего >>нет. если связываться с snmp, то придётся делать клиентскую часть :( >>, которая >>генерит нужные мибы и подсовывает их демону. но это есть плохо. > >сложно однако :( ничуть. если бы пришлось делать именно клиента, отсылающего инфу на сервер - я так бы и сделал. это так сказать прямой путь. но сейчас нужен именно сервер, собирающий инфу с сервисов - а не с клиентов.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	7. "RE: Удалённое исследование конфигурации 'железа'"
	Сообщение от Ilya on 14-Ноя-02, 02:57  (MSK)
	>- администраторы локальных машин НЕ ДОЛЖНЫ ставить какой-либо клментский софт. максимум понятно >сейчас нужен именно сервер, собирающий инфу с сервисов - а не >с клиентов. если найдешь, напиши, а?
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	8. "RE: Удалённое исследование конфигурации 'железа'"
	Сообщение от RapaNui on 14-Ноя-02, 10:52  (MSK)
	>>сейчас нужен именно сервер, собирающий инфу с сервисов - а не >>с клиентов. >если найдешь, напиши, а? ok
		Рекомендовать в FAQ | Cообщить модератору | Наверх

Удалить

Индекс форумов | Темы | Пред. тема | След. тема

Пожалуйста, прежде чем написать сообщение, ознакомьтесь с данными рекомендациями.