Ошибка VMware vSphere Client


Столкнулся с интересной темой в Windows Server 2003, при попытке подключиться к ESX серверу с помощью VMware vSphere Client. При вводе логина клиент выдает ошибку “Error parsing the server “SERVER IP” “clients.xml” file. Login will continue, contact your system administrator” и после нажатия на ОК вываливается во вторую ошибку “The type initializer for “VirtualInfrastructure.Utils.HttpWebRequestProxy” threw an exception”. То есть подключение к серверу недоступно.

Сначала было решили что это проблема с доступом, но просмотрев логи, убедились что мой клиент даже не стучится к серверу, так что стал копать в другую сторону и обнаружит что эту ошибку выдает Windows 7, при использовании стандартного клиента. В этой связи я всял совместимого с Windows 7 клиента VMware-viclient-all-4.0.0-208111 и обновил с его помощью имеющегося.

Ошибка исчезла, так что по видимому была вызвана каким то из последних обновлений для Windows систем.

VN:F [1.9.21_1169]
Rating: 7.0/10 (3 votes cast)
VN:F [1.9.21_1169]
Rating: +1 (from 1 vote)

Теги: ,

Настройка IP в CentOS


Настраивал себе систему в VmWare Player, после чего перенесли её на ESX Server, ну и по пути возникла необходимость, из дома, сменить на системе IP адрес и повесить дополнительный алиас на интерфейс. Поскольку настраивал центосину до этого исключительно из окошек Х, пришлось немного поморщить голову, но после прочтения официального мануала, все оказалось проще некуда.

Смена IP производится следующим образом:
Открываем файлец /etc/sysconfig/network-scripts/ifcfg-eth0 и смотрим что мы в нем имеем:

DEVICE=eth0
BOOTPROTO=dhcp
HWADDR=00:0C:29:BC:B7:60
ONBOOT=yes

Собственно как понятно из файла- IP адрес он цепляет от DHCP сервера, хотя мне казалось что я его задавал лапками, поэтому отрубаем DHCP и меняем настройки на:

DEVICE=eth0
BOOTPROTO=static
HWADDR=00:0C:29:BC:B7:60
ONBOOT=yes
DHCP_HOSTNAME=crm_security.lan
IPADDR= новый_IP_адрес
NETMASK=255.255.255.0
GATEWAY= новый_шлюз
TYPE=Ethernet

После перезагрузки машины или рестарта сетевых служб, с помощью команды service network restart , система переподхватит новый IP адрес.

Теперь по поводу алиасов- там же где мы правили файло с сетевыми настройками, создаем файлик ifcfg-<if-name>:<alias-value> Единственно что надо учесть тот момент что алиас не может цеплять свой адрес по DHCP, поэтому следует задавать статический адрес, для чего создаем файл /etc/sysconfig/network-scripts/ifcfg-eth0:0 и в него прописываем следующие строки:

DEVICE=eth0:0
ONBOOT=yes
BOOTPROTO=static
IPADDR=алиас_IP
NETMASK=255.255.255.255

Если нужно добавить пул алиасов, скажем от 192.168.10.1 до 192.168.10.200, то сделать это можно либо создав 200 конфигурационных файлов для алиаса, либо описав весь пул адресов, для чего создадим файл /etc/sysconfig/network-scripts/ifcfg-eth0-range0 и внесем в него следующие строки:

IPADDR_START= 192.168.10.1 # первый IP в пуле
IPADDR_END= 192.168.10.200 # последний IP в пуле
NETMASK=255.255.255.255
CLONENUM_START=1 # число <alias-value> с которого будет начинаться пул
NO_ALIASROUTING=yes

VN:F [1.9.21_1169]
Rating: 8.2/10 (21 votes cast)
VN:F [1.9.21_1169]
Rating: +11 (from 11 votes)

Теги: , , ,

Коды разблокировки порнобаннеров от винлокеров


Столкнулся с очередным винлокером, который лочит винду и не дает ничего делать, требуя прислать бабла на определенный номер. Причем написан гораздо веселее чем все предыдущие которые мне довелось повстречать, ибо не выпадает в ошибку от  хаотичного нажатия клавиш в начале загрузки. Также заблокированы диспетчер задач и вход в безопасный режим. Как говорится- шибко заколдован. Самое веселое то, что человек ко мне обратившийся с этой проблемой сначала с неделю пытался починить сам, ибо баннер который вывешивает локер ссылается на пидовскую порнушку, так что когда я пришел и загрузил компьютер- мне стоило больших сил сдержаться.

Собственно починяется подобная вещь либо вводом кода, который я приведу ниже, либо нехитрыми пассами с Live CD. То есть мы грузим систему с сидюка, после чего заходим в файловую систему системного диска и чистим все директории временных файлов, temp и содержимое темпов Documents and Settings/%username% , после чего система загружается нормально и загрузив её, разлочиваем все функции с помощью avz -> восстановление системы и перегружаемся в безопасный режим. Там прогоняем систему антивирусами и антишпионами. Поскольку эта процедура долгая и муторная, то можно сделать все в разы быстрее, если ввести запрашиваемый код и после этого начать сразу с восстановления системы.

Список кодов разблокировки различных порнобаннеров и винлокеров:

Читать полностью »

VN:F [1.9.21_1169]
Rating: 9.2/10 (13 votes cast)
VN:F [1.9.21_1169]
Rating: 0 (from 4 votes)

Теги: , , , ,

Обнуляем Master Password для Thunderbird


Слетел у меня что то Portable ThunderBird который стоял на флешке, в связи с чем я его проапгрейдил до версии 3.0 и тут то выяснилось что я зачем то установил в нем какой то Master Password, который защищает всю информацию о хранимых паролях, так что почтовые пароли приходится постоянно вводить, при этом они не сохраняются в системе, а Master Password запрашивается с дикой настойчивостью. Перебор всех паролей, имевшихся в голове не дал никакого результата, поэтому осталоcь только сбросить его. Единственный момент заключается в том, что вместе с ним слетят все хранящиеся в почтовой клиенте ThunderBird  пароли.

Делается это просто- для версии выше ThunderBird 2.0, идем в Tools -> Error Console, в открывшемся окне в поле Code вводим строку openDialog(“chrome://pippki/content/resetpassword.xul”) и нажимаем кнопку Evaluate. Это запустит диалога сброса пароля, так что щелкаем ОК и начинаем набивание паролей сначала.

VN:F [1.9.21_1169]
Rating: 7.0/10 (6 votes cast)
VN:F [1.9.21_1169]
Rating: +2 (from 2 votes)

Теги: ,

Делегируем управление субдоменом


Возникла необходимость делегировать управление доменной зоной третьего уровня (то есть например newdomain.odminblog.ru) серверам доменных имен хостера. Первое что пришло в голову, это создать зону в named.conf где указать что данный сервер является вторичным и первичным обозначить доменный сервер хостинг провайдера.

Согласуясь с вышесказанным запись в named.conf приобретает следующий вид:

############################################
zone “newdomain.odminblog.ru” {
type slave;
file “slave/newdomain.odminblog.ru”;
masters {
DNS-провайдера;
};
############################################

Но данный вариант по мне не корректен, так что пришлось пойти в изысканиях дальше.  Поковырявшись в доках, мануалах и описаниях на сайте RU-CENTER пришел к тому, что управление зоной можно делегировать в файле описания зоны, подобно тому как это делает провайдер при делегировании PTR записи. Для этого необходимо описать DNS сервера отвечающие за данный субдомен, в разделе определения серверов доменных имен, причем их имена должны принадлежать к субдомену.

newdomain    IN    NS    ns1.newdomain.odminblog.ru
newdomain    IN    NS    ns2.newdomain.odminblog.ru

После чего, через канонический тип имени CNAME определяем доменные сервера провайдера

ns1.newdomain  CNAME  ns1.DNC-провайдера.
ns2.newdomain  CNAME  ns2.DNC-провайдера.

В таком варианте все должно нормально работать. При тестировании попробовал описать DNS сервера провайдера сразу в описании NS для субдомена, используя их хостнеймы, но после такого финта, по непонятной причине отвалились MX-записи для корневого домена, что было довольно неожиданно, ибо вся остальная зона отдавалась замечательно.

VN:F [1.9.21_1169]
Rating: 7.5/10 (2 votes cast)
VN:F [1.9.21_1169]
Rating: +1 (from 1 vote)

Теги: , , ,

Перепрошивка устройства Checkpoint EDGE


Возникла необходимость залить на десяток устройств Edge кастомную прошивку, которая прошла сертификацию ФСТЭК. Сделать это можно несколькими способами, как через SmartUpdate, так и через GUI. Если в ситуации со SmartUpdate все понятно, но однозначно не подходит, ибо поднимать SmartCentre ради того чтобы обновить пару-тройку Edge, совсем не катит, то придется использовать другие способы.

Начнем с GUI, для чего настроим машину либо на DHCP либо на сетку 192.168.10.0/24. Заходим через бродилку по адресу http://192.168.10.1/ где задаем администраторский пароль и попадаем в основное меню GUI. Далее выбираем Setup -> вкладка Firmware -> Firmware Update, выбираем файл который является нашей новой прошивкой и говорим Upload. После этого Edge задумается на пару минут, вывесив объявление о том, что обновление в процессе, после чего уйдет в перезагрузку. После того как он загрузится, снова заходим в GUI с установленным нами ранее паролем и сбрасываем устройство в состояние Factory Default (по крайней мере моей задачей было передать устройство заказчику, так что все установки должны были быть по умолчанию): Setup -> Tools -> Factory Settings -> на загрузившейся странице следует обратить внимание на то, чтобы галочка на чекбоксе “Revert to the factory default firmware version” была снята. Нажимаем ОК и ждем несколько минут пока устройство перегрузится. Здесь следует обратить внимание на тот не приятный факт, что гуй Edge подглючивает в Mozilla, поэтому, чтобы не озадачиваться зазря, следует пользоваться IE.

Второй вариант такой же как и установка новой лицензии на Edge- путем загрузки её посредством протокола tftp. Для этого переводим устройство в режим tftp сервера, т.е нажимаем кнопку Power и держа её, включаем устройство. Кнопку отпускаем после того как индикатор работы PWR/SEC загорается красным. Настраиваем сетевые свойства компьютера на сеть 192.168.10.0/24, после чего загружаем dos-promt (win -> run -> cmd) и в нем задаем команду: tftp -i 192.168.10.1 put <N.extension> , где N- номер версии, а extension тип файла:
* Для устройств Edge без поддержки ADSL, extension будет tftp (например 8042x.tftp)
* Для устройств Edge с поддержкой ADSL, extension будет  firm (например a8042a.firm)
Вот тут начинается самое интересное- по мануалу, устройство должно перегрузиться после этого само, но к сожалению у меня оно и дальше продолжало радостно помигивать лампочками, поэтому все приходилось делать своими руками. Так что перегружаем устройство и ждем пока оно проморгается и начнет снова стабильно гореть здоровым зеленым цветом на индикаторе PWR/SEC, правда ждать придется минут 5 как минимум. Но по невыясненным причинам у меня из десяти устройств это вариант прокатил только с 3мя, так что рекомендую все таки воспользоваться способом через GUI.

VN:F [1.9.21_1169]
Rating: 10.0/10 (1 vote cast)
VN:F [1.9.21_1169]
Rating: +1 (from 1 vote)

Теги: ,

Ускоряем разрешение доменных имен через resolve.conf


Системный файл /etc/resolv.conf является файлом конфигурации процедур сервера доменных имен. В этом файле хранится информация об используемых DNS серверах, и этот файл перечитывается при вызове процедуры разрешения имен. В файл можно поместить информацию о трех DNS серверах, причем алгорит действия будет таким, что запрос всегда уходит на стоящий первым в списке сервер. В случае если он не отвечает в течении некоторого времени (по умолчанию 5 секунд), то запрос отправляется на вторичный сервер DNS, если он не отвечает, то запрос переходит к третичному серверу DNS. То есть по умолчанию система всегда использует первый из списка сервер, и обращается ко второму и третьему только в случае, если первичный сервер не отвечает.

Но в версии BIND 8.2 были добавлено некоторое количество новых опций, с помощью которых мы можем несколько ускорить работу разрешения доменных имен для нашего сервера:

Опиция timeout позволяет задавать время таймаута для присутствия в очереди запросов. По умолчанию этот параметр равен 5 секундам (максимально 30), так что если мы хотим ускорить отработку запроса, то выставляем этот параметр например на 2 секунды:
options timeout:2

Опция rotate позволяет использовать из списка доменных серверов все адреса, а не только первый, который может быть перегружен многочисленными запросами. Причем вторичный и третичный сервера используются только в случае отказа в обслуживании первого сервера. Поэтому с помощью этой опции мы можем разгрузить первичный сервер и отправить часть запросов на остальные сервера, указанные в resolve.conf
options rotate

Единственно что следует помнить о том что мы используем эту опцию, ибо в случае отладки, например почтового демона, мы никогда не будем знать какой из доменных серверов дал нам ответ на наш запрос. Еще один момент заключается в том, что данная опция будет полезна не всем программам, ибо часть из них, например ping, одноразово инициализирует резолвер и после разрешения имени выходит. Тогда как почтовые демоны, отправляющие многочисленные запросы разрешения доменных имен, будут использовать этот функционал.

Опираясь на все вышесказанное, resolve.conf  будет иметь следующий вид:

nameserver 1.1.1.1
nameserver 2.2.2.2
nameserver 3.3.3.3
option rotate
option timeout:2

VN:F [1.9.21_1169]
Rating: 9.6/10 (5 votes cast)
VN:F [1.9.21_1169]
Rating: +2 (from 2 votes)

Теги: , , ,