Архив рубрики: Uncategorized

Зависание загрузки Onboard Administrator на 69% в IE 10 и 11

Оставлю сегодня пометку-коротыш с тривиальным советом: Всем кому приходится работать с HP Blade Sysyem Onboard Administrator в рамках обслуживания корзин C3000 или C7000 сталкиваются с некорректной работой под Internet Explorer 10 или 11 версий. Обычно загрузка состояния шасси затормаживается на 69% и довольно долго висит. На IE 9 и ниже все работает замечательно. Обновление прошивки OA не дает эффекта. Выглядит это так:

enclosure_loading_stuck_69

Затем возможен запуск оснастки статуса, но состояние элементов корзины все равно не загружается. Решается все это очень просто: нужно заставить IE работать в режиме совместимости. Для этого достаточно нажать кнопку режима совместимости

enclosure_loading_stuck_69_correction

и работа с Onboard Administrator в дальнейшем будет беспроблемной.

Network Management Card AP9619, AP9631 и событие System: Warmstart. 0x0002

С недавнего времени, периодически, мне на почту стали падать эвенты с одного из старых бесперебойников о перезапуске интерфейса управления. Посмотрев в лог, обнаружил там изредка повторяющуюся последовательность:
System: Restarting. Stack overrun - Task 31.Stack overrun. 0x0009
System: Warmstart. 0x0002
System: Network service started. System IP is 192.168.3.30 from manually configured settings. 0x0007
UPS: Restored the local network management interface-to-UPS communication. 0x0101

Скорее всего, стек переполняется из за слишком частого обращения к ntp серверу за синхронизацией времени (на том бесперебойнике синхронизировалось раз в час). Поиск по просторам интернета дал ответ, что в ликвидации данных ошибок поможет обновление firmware. Читать далее Network Management Card AP9619, AP9631 и событие System: Warmstart. 0x0002

Баг USB при переходе с KIS2010 на KIS2011

Вчера решил обновить на своем рабочем компе версию Kaspersky Internet Security с 2010 на 2011. Благо лицензия у меня купленная как надо и возможность бесплатного перехода лабораторией Касперского предусмотрена. Читать далее Баг USB при переходе с KIS2010 на KIS2011

SSH на vSphere

Решил включить ssh на своем многострадальном сервере с ESXi 4.0. Как оказалось, процедура включения ничем не отличается от запуска ssd демона на ESXi 3.5:

1. Запросил KVM доступ к консоли сервера (надо сказать дело было в 5 утра, и по этому на хостинге среагировали не сразу а где то через пол часа)
2. В консоли нажал ALT+F1 ивывалился из станадпртной менюшки ESXi в консольное окно
3. Ввел слово unsupported в слепую, ибо эа в этом режиме нет и результатов ввода не видно, и нажал Enter
4. В появившемся приглашении ввести пароль root, ввел его, нажал Enter
5. Попал в шелл на приглашение командной строки ~#
6. Вызвал в текстовый редактор vi конфиг демона inetd набрав vi /etc/inetd.conf
7. Нашел закомментированную строку запуска при загрузке демона ssh (в случае с ESXi это dropbear) и разкомментировал ее, убрав # в начале строки:
ssh stream tcp nowait root /sbin/dropbearmulti dropbear ++min=0,swap,group=shell -i -K60
8. Нажал трижды ESC потом набрал :qw (двоеточие q и w) чтобы сохранить изменения в файле. Если нужно выйти без сохранения то комбинация :q!
9. Перезагрузил сервер

В итоге все заработало и я смог подключиться, и даже сразу с доступом root. Чего в ранних версиях ESXi было сделать нельзя, нужно было разрешать руту ходить по ssh. Не знаю зачем они изменили эту настройку безопасности, ибо хождение под рутом в шелл штука опасная, у нас же есть su, но факт остался фактом.
Все работает, но я прибавил еще одну уязвимость на свой сервер :)