среда, 30 июня 2010 г.

Формирование структуры файлового сервера крупной организации

Пару лет назад столкнулись с необходимостью стандартизировать структуру сетевых дисков на наших файловых серверах в Центральном офисе и филиалах. Для стандартизации необходимо было сделать следующее:
  1. стандартизировать директории
  2. стандартизировать права доступа к директориям
  3. закрыть доступ пользователей к изменению структуры и прав доступа к ней до определенного уровня вложенности.
 Долго размышляли над тем, как правильно сделать, и в итоге пришли в выводу что надо это делать следующим образам:
  • Структуру директорий - делать аналогично штатному расписанию до его наименьшей единицы (в нашем случае отдел). Группы и подгруппы у нас не считаются административными единицами, т.к. их руководители не несут в себе административных функций (например, не регулируют уровень заработной платы своих сотрудников).
  • Структуру права доступа к директориям - по сервисной модели, т.е. на одну директорию вложенности отдела создается 4 группы доступа по шаблону местоположение файлового сокращенное название верхнего подразделения_название подразделения_тип доступа_тип группы. 
    • Обычно Типы доступа бывают 2-х видов. Доступ FC - полный доступ с возможностью изменения прав доступа. Сделан только на всю структуру, чтобы ее изменял только ограниченный круг лиц.
      1. RO - только чтение
      2. RW - запись
    • Типы групп бываю так же 2-х видов. Группы типа G включаются в DL и в случае, если необходимо на время прекратить доступ пользователей к ресурсу, можно порвать эту связь.
      1. G - глобальный группы в домене. Предназначены для добавления в них пользователей.
      2. DL - доменные локальные группы. Предназначены для выдачи прав на ресурсы.
    • Группы типа G включаются в DL и в случае, если необходимо на время прекратить доступ пользователей к ресурсу. Можно порвать эту связь.
БОЛЕЕ ДЕТАЛЬНО ОБ ЭТОМ - В ВЫДЕРЖКАХ СТАНДАРТА "НАИМЕНОВАНИЕ ДИРЕКТОРИЙ И ГРУПП ДОСТУПА ФАЙЛОВОГО СЕРВЕРА"

2 Требования Стандарта

2.1 Структура каталогов

Структура каталогов ФС филиала должна соответствовать структуре, описанной в Приложении А. Самостоятельное переименование, изменение, добавление или удаление папок верхнего уровня, описанных в Приложении А, запрещено.
Стандарт не регламентирует и не ограничивает структуру папок уровня ниже описанных в Приложении А.

2.1.1 Структура каталога APP Приложения А

Структура каталога APP не определена и согласуется с Администраторами Windows РЦ.

2.1.2 Структура каталога DEP Приложения А

В случае наличия в филиале отдела, группы или прочей структурной единицы, которая имеет доступ в домен МСК, для неё создается своя папка с кратким названием структурной единицы и подпапками chiefs и public. Форма - Приложение Б.

2.1.3 Структура каталога USERS Приложения А

Самостоятельное создание подпапок в этом каталоге запрещено, все папки создаются средствами Windows.

2.2 Наименование групп доступа

 Для каждого подкаталога общего ресурса файлового сервера, указанного в Приложении А, создаются отдельные группы доступа.
Каждая группа доступа к ФС филиала именуется согласно маске:
pXX-fs_PATH_ACL_G, где
ХХ – номер филиала
PATH – путь папки (относительно папки общего доступа), к которой предоставляется доступ. Подпапки разделяются символом “_”
ACL – права доступа к данной папке. Может принимать значение:
ro – только чтение
rw – чтение/запись
Например,
p13_dep_osh_public_rw_G
Существуют так же специальные группы:
pXX-fs_shared_ro_G                        – доступ на чтение к корневой папке общего ресурса
pXX-fs_FullControlAll_G                – полный доступ ко всем папкам общего ресурса
pXX-fs_ReadAll_G                          – доступ на чтение ко всем папкам общего ресурса

2.3 Назначение прав доступа пользователям

Для назначения прав доступа пользователю на каталог, необходимо включить его в соответствующую группу прав доступа.
Права доступа пользователю назначаются только включением его в группу доступа и только на каталог нижнего уровня стандартной структуры каталогов.
Запрещается выдавать права на каталог или файл конкретному пользователю.
Все дочерние каталоги, находящиеся в каталоге нижнего уровня, наследуют права родительского каталога.
Все группы доступа каталога нижнего уровня включаются в соответствующую  _ro - группу родительского, по отношению к данному, каталога.

Условия применения

Настоящий Стандарт вступает в силу сразу после его утверждения.

Разрешение исключений

Допускаются следующие исключения из Стандарта в случае необходимости. Если нет возможности приведения существующей структуры каталогов ФС филиала к данному стандарту, то предусмотрено расширение стандартной структуры каталогов. Для это необходимо подать заявку на расширение стандартной структуры каталогов (Приложение Б).

Приложение А
Общие ресурсы файлового сервера филиала
Наименование подпапки
Наименование групп
доступа
Назначение
Shared
PXX-fs_Shared_ro_G
Корневой каталог общих ресурсов (все остальные каталоги указаны относительно этого каталога)
App
PXX-fs_App_ro_G
Приложения филиала (индивидуален для каждого филиала, здесь расположены приложения, не требующие локальной инсталляции)
Dep
PXX-fs_Dep_ro_G
папки отделов
Dep\Adm
PXX-fs_Dep_Adm_ro_G
Папки администрации (секретарь, менеджер по персоналу)
Dep\Adm\chiefs
PXX-fs_Dep_Adm_Chiefs_ro_G PXX-fs_Dep_Adm_Chiefs_rw_G
папка руководителей отдела
Dep\Adm\Public
PXX-fs_Dep_Adm_Public_ro_G PXX-fs_Dep_Adm_Public_rw_G
Общая папка администрации
Dep\KS
PXX-fs_Dep_KS_ro_G
Папки коммерческой службы
Dep\KS\chiefs
PXX-fs_Dep_KS_Chiefs_ro_G PXX-fs_Dep_KS_Chiefs_rw_G
папка руководителей отдела (ком. Директор, НГП, и т.д.)
Dep\KS\Public
PXX-fs_Dep_KS_Public_ro_G PXX-fs_Dep_KS_Public_rw_G
Общая папка коммерческой службы
Docs
PXX-fs_Docs_ro_G
Каталог с нормативными документами


Reports
PXX-fs_Reports_ro_G
Документы отчетности



Public
PXX-fs_Public_ro_G 
PXX-fs_Public_rw_G
Публичный общий ресурс для обмена не конфиденциальной информацией в течении дня.
Users

Личные папки пользователей (перемещаемые/терминальные профили, перенаправленные папки my documents, application data)








Приложение Б

Список нестандартных директорий филиала для внесения в стандартную структуру каталогов

№ филиала
Город
Путь
Наименование групп доступа
Размер Mb
 Ответственное подразделение
Описание функционального назначения папки
П-13
Сити
Dep\Apple
PXX-fs_Dep_Apple_ro_G
250
Аутсортинговая компания ООО «Яблоко»
Хранение служебной документации по КМА и принтерам
П-13
Сити
Dep\Apple\ Chiefs
PXX-fs_Dep_Apple_ Chiefs_ro_G
PXX-fs_Dep_Apple_ Chiefs_rw_G
50
Аутсортинговая компания ООО «Яблоко»
Хранение служебной документации по КМА и принтерам
П-13
Сити
Dep\Apple\ public
PXX-fs_Dep_Apple_ public_ro_G
PXX-fs_Dep_Apple_ public _rw_G
200
Аутсортинговая компания ООО «Яблоко»
Хранение служебной документации по КМА и принтерам















среда, 23 июня 2010 г.

VMware User Group Russia Нижний Новгород

Коллеги приглашаю вас посетить мероприятие "VMware User Group Russia Нижний Новгород" проводящиеся как вы уже поняли в славном городе Нижним Новгороде.

Обещаю что будем зажгать )))

Ссылка на мероприятие http://blog.vadmin.ru/2010/06/vmware-user-group-2010-1.html

Екатеринбург

Ещё в марте я с коллегой Антоном Жбанковым (http://blog.vadmin.ru/) ездил в Екатеринбург. Мы выступали для интегратора средних размеров. Спасибо им за радушный приём, с удовольствием съездим туда снова, если позовут.

Выкладываю презентацию, которую читал там я, остальные презентации и отчёт о поездке туда смотрите в блоге Антона.

ПРЕЗЕНТАЦИЯ

суббота, 19 июня 2010 г.

Подмена MAC адреса в виртуальной машине

Недавно столкнулся с одной проблемой, которая потребовала подмены MAC-адреса в виртуальной машине.

Итак, были проведены работы по виртуализации одного старого сервера с Windows и работающего на нём серверного приложения.
Всё вроде прошло успешно, но после работ по виртуализации выяснилось, что приложение, которое там работает, не поднимается и пишет ошибку на лицензию.
После некоторых изысканий была выявлена следующая проблема: после виртуализации сменился MAC-адрес сетевого адаптера, к которому была привязана лицензия работающего на сервере приложения.

Вспомнил, что для смены на любой другой MAC-адрес (не из диапазона, выделенного компании VMware), надо выключить VM и поменять его в файле виртуальной машины "имя машины.vmx" (я делал это с помощью Veeam FastSCP).  После смены MAC-адреса машина вообще не захотела включатся со следующей ошибкой - "что-то там "MAC адрес" is not an allowed VPX assigned Ethernet address. Invalid MAC address specified. Failed to configure ethernet0.” (((.


Разбор полётов показал:

Назначение MAC-адресов в VMware ESX бывает 3 видов:
1. generated = авто-назначаемый через GUI, назначается в режиме Automatic свойств сетевого адаптера виртуальной машины (MAC-адрес должен начинаться с 00:0c:29)
2. vpx = создаваемый из консоли VMware vCenter, назначается вручную в режиме Manual свойств сетевого адаптера виртуальной машины (MAC-адрес должен начинаться с 00:50:56)
3. static = жёстко заданный вами определённый MAC-адрес, который желательно (но не обязательно) выдавать из диапазона, который выдан VMware, Inc.

Редактировать нужно следующие строчки:
1. ethernet0.generatedAddress = “MAC-адрес(где ethernet0 - номер сетевого адаптера) нужно редактировать MAC-адрес и название параметра с ethernet0.generatedAddress на ethernet0.Address
2. ethernet0.addressType = “generated” параметр с generated на static.


Источники:
Книга Михаила Михеева "Администрирование VMWare vShere. Виртуализация для профессионалов" http://www.vm4.ru/
http://mrraph.net/WordPress/?p=13
http://communities.vmware.com/message/438652