Переименование шары в Windows с сохранением прав доступа.

Думаю многие сталкивались с ситуацией, когда надо поменять имя шары в винде… но винда не разрешает переменовывать шары.

В итоге, для сохранения прав доступа, в таком случае, приходится делать новую шару на  целевой папке (уже с нужным именем) и «повторять» все назначения пермишенов на шару. Когда на шару назначено всего несколько пермишенов – это пустяковое дело. А вот если там 20+ назначений? или множество шар должно быть переименованно?

Нам на помощь приходит permcopy.exe (идет в пакете Windows Server 2003 Resource Kit Tools ). Немного поругавшись пакет стал на мою Win7 SP1 x64. Вот хелп утилиты:


d:\Windows Resource Kits\Tools>permcopy.exe /?
Copies the permissions (ACLS) from one share to another.

PERMCOPY \\SourceServer ShareName \\DestinationServer ShareName

Замечу, что необходимы указывать UNC сервера и через пробел имя шары (а не UNC шары). Собственно на этом все, работает быстро и четко :)

ЗЫ

полезно будет ознакомиться с KB майкрософта: How to Copy Files and Maintain NTFS and Share Permissions

Импорт в ESXi всех виртуальных машин с датастора.

Импорт в онсастку ESX(i) вирутальных машин из датастора можно сделать из контекстного меню .vmx файла виртуальной машины (выбрав Browse Datastore,  и найдя нужный файл. Но если таких машин больше несколькоих десятков, а то и сотни – на выполнение этих рутинных операций в ручную можно потратить много часов времени.

Мне пришлось переустановить один сервер с ESX 3.5 на ESXi 3.5 сохранив все виртуальные машины на отдельных датасторах (это были локальные диски, но ситуация не отличилась бы и в слуачае NAS/SAN хранилища).  Замечу, для того что бы подключить к новой инсталяции ESXi 3.5 старые диски с сохранением существующих VMFS разделов нужно на новом хосте в конфигурации выбрав «Advanced Settings», в разделе «LVM» изменить опцию «LVM.EnableResignaturing» c нуля на единицу и сделать Rescan всех котроллеров систем хранения с опцией поиска новых VMFS разделов.

Собстевнно массовый импорт машин для ESX хоста описан тут: Mass Import VMs to New ESX Host by .VMX files, там приведено два способа.

Первый способ – сделать скрипт.

for i in `find /vmfs/volumes/ -name "*.vmx" `
do
echo "Registering VM $i"
vmware-cmd -s register $i
done

Скрипт нужно сохранить, например, как massImport.sh, дать ему права на выполнение (chmod +x /path-to-script/massImport.sh) и выполнить. У этого решения свой недостаток – если в пути/имени виртуалки содержатся пробелы, то ничего не получится. Эта проблема решается во втором варианте.

Второй – одной строкой из консоли ESX:

find /vmfs/volumes -name “*.vmx” | while read LINE; do echo “registering VM $LINE”; vmware-cmd -s register $LINE

Но это решения дл ESX, а в моем случае был ESXi. Для ESXi комманды vmware-cmd нету, а на ESX я эти варианты не проверял… Немного погуглив я нашел список команд для работы через SSH/CLI с ESXi. Разрешив из локальной консоли доступ к  ESXi по  ssh, я нашел и протестировал работу аналога нужной команды.

vim-cmd solo/registervm /vmfs/vol/datastore/dir/vm.vmx
Registers vm in hypervisor inventory

т.к. у меня была куча виртуалкок в имени (и пути к VMX файлу) которых содержались пробелы, я решил «поправить» второй способ для работы в ESXi. Эта команда импортирует все виртуальные машины с выбранного датастора «Temp-IT-Drive(1TB)» в «корень» оснастки хоста. Вот что вышло:

find /vmfs/volumes/Temp-IT-Drive\(1TB\)/ -name "*.vmx"| while read LINE; do echo "registering VM $LINE"; vim-cmd solo/registervm "$LINE";done

Пришлось добавить к исходному варианту «;done» в конце и заключить $LINE в ковычки выполнении команды импорта, иначе виртуалки «с пробелами»  все же не обрабатывались.

Вот собственно и все, если есть что добавить – велком в коменты.

Смена настроек DNS на ESXi хостах средствами PowerCLI

Если есть необходимость смены настроек ДНС на сервереах виртуализации ESX(i), то можно пойти двумя путями.

1. В ручную изменить настройки на вкладке «Configuration», разделе «DNS and Routing» каждого хоста виртуализации. Все быстро и просто, пока работы охватывают пару-тройку хостов. А если нужно перенастриоть 10+ серверов нужно «идти в обход».

2. Когда хостов много, а времени на работу в вручную мало/жалко – пора использовать VMware PowerCLI. Я не обладая опытом работы за пару минут нашел способо изменить конфигурацию DNS на нужной мне группе хостов. Итак после загрузки последнего дистрибутива PowerCLI с сайта VMware можно сразу приступать к работе.

После запуска PowerCLI нужно подключиться к хосту, в простейшем случае (если ваш аккаунт имеет права в вашем vCenter) это делается одной командой:

Connect-VIServer -server vCenter-name

После подключения, нужно выполнить следующую команду. В данном примере будет смена адресов DNS сервреов всех хостов в датацентре «MyDataCenter»

Get-VMHost -Location (Get-Datacenter -Name MyDataCenter) | get-vmhostnetwork | set-vmhostnetwork -dnsaddress "192.168.0.1","192.168.0.2"

Ну и стоит отметить, что смена конфигурации DNS на хостах не приводит (по крайней мене в моем слуаче было так) к переключению хоста на новые настройки.  Новые настройки вступят в силу после перезагрузки хоста или после рестарта Management сервисов (services.sh restart из консоли хоста)

Windows 2008 теряет настройку шлюза по умолчнаию после ребута.

Уже несколько раз сталкивался с проблемой.

После деплоя из шаблона Windows2008 x64 есть проблемы с сетевыми настройками. После перезагрузки ОС теряется настройка шлюза по умолчанию. Если его вписать снова – то все работает до следующего ребута, а потом проблема повторяется… если мне не изменяет память, такое было и на Vista.

Я исправляю проблему так:

1. Редактором реестра заходим в HKLM/System/CurrentControlSet/Services/Tcpip/Parameters/Interfaces/%CLSID% .
2. Проверяем значения ключей DefaultGateway и DefaultGatewayMetric. Нужно удалить пустые строки и неверные записи. Можно ввести IP шлюза по умолчанию, если значение отсутсtвует.

После этого настроенная сеть не слетает после перезагрузки…

Есть еще и второй способ, но я пока не проверил его, как нибудь в след раз попробую. Суть в сбросе всех настроек и ввводе их по новому. Для сброса параметров IPv4 нужно с правами администратора выполнить в командной строке: netsh int ipv4 reset

Можно даже так, если нужно сбросить все настройки:

Reset WINSOCK entries to installation defaults: netsh winsock reset catalog

Reset IPv4 TCP/IP stack to installation defaults. netsh int ipv4 reset reset.log

Reset IPv6 TCP/IP stack to installation defaults. netsh int ipv6 reset reset.log

________________

Windows 2008 x64 virtual machines lose their Gateway IP address after rebooting

TCP/IP stack repair options for use with Windows Vista.

Upgrade virtual hardware с 4 на 7 версию. Как обновить виртуальное железо.

После переезда на VMware vSphere и обновления всех ESX/ESXi  хостов до 4 версии, начал наводить порядок с бэкапами, шаблонами и прочим добром.

Сразу думал что оставлю все старые виртуалки на 4 уровне virtual hardware (новые сразу уже 7 уровня делаю), т.к. много работы по обновлению. Ведь сразу все не сделаешь, да еще и может что-нибудь поломаться. А позднее, вышел на необходимость обновления виртуального железа до 7 уровня, что бы можно было юзать vStorage API, а конкретнее CBT (Changed Block Tracking).

Уже обновив более 20 виртуалок, можно сделать вывод: Windows виртуалки обновляются почти без проблем, Linux – тоже все ОК, а вот Solaris и прочие редкости – сразу ломаюццо (нужен индивидуальный подход с длительним инвестигейтом).

Сразу оговорюсь, что без предварительного бэкапа виртуалки, лучше не поводить обновление виртуального железа. В крайнем случае – сделать снапшот перед началом работ.

Использовать VMware vCenter Update Manager я не рискнул,  т.к. еще не налажены бэкапы виртуалок, может через пару недель попробую.

Итак, планируем обновление VMware Tools и Vitrual Hardware для каждой виртуалки. Потребуется 4 перезагрузки для каждой виртуалки, в течении всего процесса обновления.

Процес стоит проводить в такой последовательности:

1. Обновить VMware Tools вируталки до актуальной версии. В идеале билд тулзов=билд хоста, но минимальное требование – тулзы от esx\esxi 4. После завершения установки/обновления vmware tools гостевая ос должна перезагрузится (1 ребут). Для этого этапа можно использовать update manager, можно обновить тулзы в автоматическом или интерактивном режиме. В результате мы должны видеть статус ОК на вкладке Summary:
   

   VMtools Status OK before HW upgrade

2. Обновить Virtual Hardware, небходимо убедится в корректной установке VMware Tools на виртуалке. Обязательно наличие бэкапа виртуалки.
   Для этого процесса так же можно использовать vCenter Update Manager, или же вручную обновлять уровень виртуального железа (выключив предварительно виртуалку). Этот этап  – 2 ребут.
3. Перезагрузка Гостевой ОС, после установки всех драйверов на новое виртуальное железо железо (3-й ребут).
   для Windows:  Залогинившись в ОС, сразу после ее загузки (для винды), можно наблюдать поцесс установки драйверов. После завершения устанвоки драйверов должен появится запрос на перезагрузку, если он не появился – нужно ребутнутся вручную.
   При обновлении вируального железа происходит замена виртуальных сетевых адапетеров, настройки сети переносяся со старого адаптера на новый. Но иногда случается глюк, поэтому желательно предварительно сохранить сетевые настройки вируталки (ipconfig -all >c:\ipcongig.txt), или иметь возможность восстановить из другого источника.
4. Удаление отсутсвующего сетевого адаптера .
   (для Windows) При обновлении вируального железа происходит замена виртуальных сетевых адапетеров, но старые адаптеры все еще «числятся» в системе. Проверить это можно зайдя в TCP\IP настройки нового сетвеого адаптера. Если он настроен на статический IP адрес, то при нажатии на OK будет выеденно предупреждение, что другой сетевой адаптер уже имеет такой IP. Это не вызовет конфликтов в работе, но лучше удалить из системы запись о старом сетвом адаптере.
   сделать это можно так: http://support.microsoft.com/?kbid=269155 или тоже самое но в другом месте
   Кратко – нужно ввести в коммандной строке:
   set devmgr_show_nonpresent_devices=1
   start DEVMGMT.MSC
   И, включив в менеджере устройств отображение скрытых девайсов, удалить «бледный» сетевой адаптер. После этого предупреждение не будет выскакивать.
   (для linux) Тут можно отметить, что иногда сбивается нумерация сетевых адаптеров. Есть солюшены как этого избежать, но я еще не вникал.
   В своих случаях, я просто правил конфиги сети, заменяя номер eth0 на нужный.
5. Настройка WINS. Нужно заметить, что настройки WINS, если они у вас были, не переносятся со старого интерфейса на новый при обновлении железа. Если нужо – вносим WINS как и было, заодно и проверим, что по нажатию ОК  не появляется сообщения о адаптере с таким же IP.
6. Финальный ребут (четвертый). Это не обязательно, но если есть возможность – лучше ребутнутся еще раз и проверить что все ок. После этого можно считать работы с виртуалкой завершенными.

Ну и в заключение – нужно иметь ввиду, что после обновления вирутальног железа меняется имя сетевого подключения и MAC адрес. В большинстве случаев это не играет роли, но в некоторых окржениях может иметь значение.

___________________

Источники информации:

P2V – Error with NIC after migration with static IPv

Sphere Virtual Machine Upgrades-public

Email нотификация RSyslog с фильтрацией сообщений для разных получателей.

Данный пост продолжает тему использования  Email нотификаций (через SMTP) о событиях полученных демоном RSyslog. Однозначно и с уверенностю могу сказать, что сидеть в веб-интерфейсе (phpLogCon) и постоянно просматривать текущие события – дело нудное и бесполезное. Если вы хотите получить реальную пользу от внедрения RSyslog, то нужно делать почовую нотификацию на заинтересованных лиц (админов конретных сервисов/серверов).

В прошлом посте я писал об основах конфигурирования модуля для отправки почты. Сейчас, уже поработав  некоторое время с данной системой, могу выложить мой текущий конфиг. В этом конфиге я отсылаю разные сообщения на разные ящики и могу отсеивать не нужные нотификации. Фильтрация сообщений основана на Facility.Serverity классификации, плюс фильтрация на основе вхождения в текст сообщения определенного текста. Первая часть конфига – общая, служит для отправки уведомлений на сообщения с уровнем важности (serverity) начиная от err (ошибка), в не зависимости от источника (facility) события. Вторая часть – нотификация сетевого админа о событиях на коммутационном оборудовании, которое шлет сообщения с facility=local7. Дополнительно, на нотификации от коммутаторов уровень важности включает еще и предупреждения. Одинаково в обоих случаях реализована фильтрация сообщений, используя конструкцию:

if not ($msg contains 'Кусок текста по которому фильтуем').........