Что лучше winbind или ssd
Медленно, но верно старые добрые «винты» вытесняются с рынка. Жесткие диски теперь если для чего и нужны, так только для специфических задач вроде хранения крупных массивов данных. Вот только зачем это обычному пользователю с каналом хотя бы 25 Мбит/с? Не удивительно, что все больше людей выбирают твердотельные накопители, намного более быстрые и бесшумные по сравнению с HDD. Сегодня расскажем, на что стоит обратить внимание при выборе SSD.
При покупке винчестера надо было лишь определиться с емкостью, выбрать модель со скоростью вращения шпинделя повыше (в большинстве случаев 7200 оборотов в минуту) да буферной памятью побольше (обычно 64 МБ). У SSD есть превеликое множество нюансов, о которых многие пользователи даже не подозревают. Вот о них-то в том числе и расскажем. Знали вы, например, что скорость твердотельного накопителя очень часто связана с его объемом?
Содержание
Куда втыкать?
Как было с жестким диском? Берешь и подключаешь к нему кабель от блока питания, SATA-шнурком соединяешь с материнской платой, и готово! При выборе SSD вам обязательно надо определиться, как вы будете интегрировать его в компьютер, а также выяснить, какие способы интеграции поддерживает ваша машина.
Самый простой вариант — пойти по пути HDD. Можно выбрать твердотельный накопитель в формфакторе ноутбучного винчестера 2,5″. Внешне это будет маленькая плоская коробочка, которую точно так же, как и винчестер, можно подключить к ноутбуку или настольному компьютеру с помощью кабеля питания и SATA-шнурка.
Есть SSD в виде платы расширения, которая вставляется в слот PCI Express материнки точно так же, как, например, Wi-Fi-приемники, контроллеры USB и т. д. В силу особенностей, о которых мы поговорим дальше, такие накопители почти всегда будут быстрее тех решений, о которых шла речь абзацем выше.
Впрочем, накопители в виде плат расширения высоким спросом не пользуются. Вместо них настоящую конкуренцию 2,5-дюймовым моделям с SATA-подключением составляют устройства, предназначенные для формфактора M.2. Это относительно новый стандарт, который уже широко используется в современных комплектующих. Главное — проверить на сайте производителя вашей материнской платы или ноутбука, есть ли у вас нужный слот.
Накопитель в формфакторе M.2 выглядит как компактная плата размером чуть больше зажигалки. Здесь не нужны никакие кабели — плата вставляется прямо в миниатюрный разъем, расположенный на материнке, и прижимается винтом. Но есть нюанс: такие носители могут быть разной длины — 42, 60, 80 или 110 мм. Впрочем, особо переживать по этому поводу не стоит, потому что большинство потребительских SSD и, соответственно, «железо» под них адаптированы под длину 80 мм.
В случае с SSD формата M.2 обмениваться данными с системой накопитель может как через интерфейс SATA, так и через PCI Express. По первому пути, как мы уже говорили, пошло большинство моделей формфактора 2,5″, а по второму — твердотельные накопители в виде плат расширения. Практичнее выбирать те SSD формата M.2, которые «дружат» с PCI Express, потому что этот интерфейс обеспечивает скорость передачи данных в несколько раз выше, чем SATA.
Что ж, определились: выбираем SSD в формфакторе M.2 с поддержкой PCI Express. Часто вы можете видеть надпись вроде «PCI Express 3.0 х4». Страшно? На деле все просто: 3.0 — это версия PCI Express, а 4 — количество линий передачи данных, которые подведены к коннектору SSD. Если коротко, то чем их больше, тем потенциально выше скорость обмена информацией. Лучшее, что вы сегодня можете встретить, это поддержка PCI Express 3.1 x4 и PCI Express 3.0 x8. Но таких накопителей пока очень мало, делает их Intel, стоят они дорого. Оптимально с точки зрения цены и производительности — PCI Express 3.0 x4.
Бывают еще накопители формфактора 3,5″, 1,8″, mSATA, DOM, однако почти все они — штуки редкие и для большинства «домашних» пользователей неинтересные.
Коротко о главном: если позволяет «железо», лучше брать SSD в формфакторе M.2 и с подключением по шине PCI Express. Если система старовата, покупайте SATA-накопитель 2,5″ — выйдет медленнее, но и дешевле.
Помни о памяти!
Твердотельные накопители — штуки очень технологичные и развиваются постоянно. Особенно важно то, какой тип флеш-памяти используется в SSD. Фактически это и есть та первооснова, на которой будет храниться вся ваша информация.
С ходу типов памяти можно назвать штук шесть, хотя по сути их три (ну или четыре). Давайте разбираться. О флеш-памяти типа SLC можете сразу забыть. Она очень крутая, долговечная и невероятно быстрая, но дорогая. Ее характеристики даже избыточны для пользователей. Какая, в конце концов, разница, проживет ваш SSD тысячу лет или семьдесят?
Поэтому сегодня распространены накопители с памятью MLC и TLC. Если в случае с SLC одна ячейка флеш-памяти вмещает в себя 1 бит информации, то MLC содержит 2 бита, а TLC — уже 3 бита. Увы, вместе с повышением плотности падают остальные потребительские характеристики. Считается, что MLC выдерживает в 20 раз меньше циклов перезаписи информации, чем SLC, к тому же этот тип памяти примерно вдвое медленнее. У TLC, в свою очередь, с долговечностью и скоростью все еще хуже.
Вроде бы выбор очевиден: раз уж накопителей с памятью SLC днем с огнем не сыщешь, бери MLC и радуйся. Однако в дело вступают технологии, маркетинг и цена, которые все вместе дают шанс TLC. Во-первых, несмотря на имеющиеся скоростные различия, пользователь не заметит разницы в производительности похожих SSD с разными типами памяти. Во-вторых, на скорость работы накопителя помимо типа флеш-памяти влияют и другие параметры, о которых поговорим ниже. В-третьих, поколения MLC и TLC постоянно сменяются, техпроцесс совершенствуется, потребительских отличий между двумя технологиями становится все меньше и меньше.
Погодите-ка, а что за TLC 3D V-NAND и MLC 3D V-NAND? Очередные новые типы памяти? И да, и нет. Типы остаются теми же — TLC и MLC. Другое дело, что 3D V-NAND указывает на взаимное расположение ячеек памяти в несколько слоев вместо обычного плоского массива. Это значительно увеличивает емкость накопителя, а также, говорят, заметно повышает скорость его работы и долговечность.
И еще кое-что. В давно устоявшееся положение вещей, где фактически есть только TLC 3D V-NAND и MLC 3D V-NAND, нагло вмешалась Intel, совсем недавно выпустившая на рынок накопители с принципиально новым типом памяти 3D XPoint. Это самая настоящая инновация, о полном строении и функционировании которой сегодня нет общедоступной информации. Но даже без этого тесты показывают, что накопители Optane от Intel в разы шустрее флагманских решений, построенных на TLC 3D V-NAND или MLC 3D V-NAND. Из-за новизны разработки говорить о надежности и долговечности новой памяти рано, но Intel обещает чуть ли не вечную работу SSD на 3D XPoint. Будущее уже здесь! Но будущее очень дорогое — как вам идея заплатить за 375 ГБ почти три тысячи рублей?
Коротко о главном: если у вас денег куры не клюют, обратите внимание на Intel Optane с памятью 3D XPoint. Если же вы не готовы отдать больше тысячи рублей за 280 ГБ, поищите модели с памятью 3D MLC V-NAND. Нужно сэкономить и при этом нет необходимости ежедневно перегонять терабайты информации? Тогда спокойно берите 3D TLC V-NAND — ничего не потеряете.
Тише едешь — недалеко от HDD уедешь
«Ну уж со скоростью-то все понятно! Бери то, где написано побольше, и все дела», — наверняка думает большинство покупателей SSD. Ха, если бы все было так просто! Однако твердотельные накопители — это как целая жизнь, здесь все непросто.
Мы уже знаем, что на скорость памяти влияют интерфейс подключения, тип памяти и даже расположение ячеек относительно друг друга. Сейчас ко всему этому добавим еще пару переменных.
Контроллер — не менее важная часть SSD, чем тип памяти. Плохой контроллер может загубить весь потенциал 3D MLC V-NAND, подключенного через скоростную шину PCI Express. Хороший же раскроет TLC так, что 3D XPoint обзавидуется. Утрируем, но в теории как-то так.
Контроллер представляет собой чип с вычислительными ядрами и программой-прошивкой. Все вместе они отвечают за управление операциями записи и чтения информации в ячейках памяти, за обмен данными с SATA или PCI Express, обслуживание накопителя и т. д. Беда в том, что производителей контроллеров очень много, к тому же у каждого в портфолио есть несколько моделей.
Сегодня выбирать SSD по контроллеру вряд ли кто-то будет. Все-таки современные накопители получают, как правило, «допиленные» чипы, которые не сдерживают потенциал памяти. Традиционно хороши Samsung Polaris и Phoenix, Silicon Motion SM2262, актуальные представители Marvell и Phison. Но, повторимся, уделять особое внимание выбору контроллера стоит только в том случае, если вы знаете, что ищете и зачем (а такие пользователи читать эту статью вряд ли будут).
Также на скорость работы накопителя влияет… его объем! Не напрямую, а косвенно. А вы думали, что между моделью на 250 ГБ и 1 ТБ в рамках одной линейки нет разницы, кроме емкости и цены? О нет, разница бывает, да еще какая.
Во-первых, для быстродействия важен объем буферной DRAM-памяти — фактически это аналог оперативной памяти компьютера, который нужен для сверхбыстрой обработки данных. Объем DRAM-памяти почти всегда зависит об объема накопителя. Так, в новой линейке Samsung 970 EVO модели объемом 250 и 500 ГБ имеют буфер емкостью 512 МБ, а «терабайтник» может похвастаться уже гигабайтом оперативной памяти. Относительно недавно в моду стали входить безбуферные SSD — недорогие, но заметно теряющие в производительности.
Но и это еще не все. Многие современные SSD имеют SLC-кеш. Знакомая аббревиатура? Помните, когда мы говорили о типах памяти, то упоминали SLC? Нынешние накопители умеют имитировать работу этого типа памяти. В таком случае в одну ячейку записывается только 1 бит информации, а не 2 или 3. За счет этого повышается скорость работы.
Обычно под SLC-кеш зарезервирована часть емкости SSD, также под него может выделяться дополнительный объем памяти в зависимости от потребностей и оставшегося свободного пространства. В целом, чем меньше объем накопителя, тем меньше у него объем SLC-кеша. Например, у популярной модели Samsung 960 EVO на 250 ГБ объем SLC-кеша может достигать примерно 13 ГБ, а у модели на 500 ГБ — уже 22 ГБ. Счастливчики с терабайтом могут рассчитывать на 42 ГБ кеша.
Те скорости, которые вы видите в описании накопителя, частенько как раз указываются с учетом сверхбыстрого SLC-кеша. Но что случится, когда он заполнится? При заполнении буфер сбрасывает записанную в него информацию в стандартно функционирующую, но более медленную память TLC или MLC. В большинстве случаев это никак не сказывается на впечатлениях от работы. Но если вы надумали записать огромный файл, например 40-гигабайтный фильм BDRemux, то непременно почувствуете падение производительности, как только заполнится кеш. Так, накопитель емкостью 250 ГБ первые 12—13 ГБ запишет в SLC-кеш на скорости около 1500 МБ/с, после чего она упадет раз в пять. А вот терабайтный SSD за раз «переварит» ваши 40 ГБ.
Была необходимость ввести в домен Windows машину с Ubuntu. Для этих целей обычно используют Samba и Winbind. Но возможен альтернативный вариант с sssd, краткое руководство по нему ниже.
Для примера будем использовать:
1. Переключаемся под рута
2. Устанавливаем необходимые пакеты
3. Редактируем /etc/krb5.conf, в качестве отступов используется табуляция
4. Редактируем файл /etc/hosts, указываем FQDN для данного хоста:
5. Пробуем получить Kerberos ticket от имени администратора домена:
Если тикет получен успешно, то теперь можно сгенерировать Kerberos principals для данного хоста, регистр важен:
Сейчас наш хост должен отобразиться в списке компьютеров в каталоге. Если все так — удаляем полученный Kerberos ticket:
6. Создаем файл /etc/sssd/sssd.conf со следующим содержимым:
Описание параметров конфигфайла sssd можно посмотреть тут
Устанавливаем права доступа для файла sssd.conf:
Перезапускаем SSSD service
7. Редактируем настройки PAM
Плохое решение:
редактируем файл /etc/pam.d/common-session, после строки
Хорошее решение:
переопределить параметры через системные настройки PAM, вызываем
и отмечаем пункты sss auth и makehomdir. Это автоматически добавит
строчку выше в common-session и она не будет перезатерта при обновлении системы.
Теперь мы можем логиниться на машине доменными пользователями, которым разрешен вход.
P.S.: Можно дать права на использование sudo доменным группам. Используя visudo, редактируем файл /etc/sudoers, или лучше, как рекомендует maxzhurkin и iluvar, создаем новый файл в /etc/sudoers.d/ и редактируем его
добавляем требуемую группу — например, Domain Admins (если в названии группы есть пробелы — их необходимо экранировать):
P.S.S.: Спасибо gotch за информацию о realmd. Очень удобно — если не нужны специфические настройки, то ввод машины в домен занимает, по сути, три (как заметил osipov_dv четыре) команды:
1. Устанавливаем нужные пакеты:
2. Редактируем файл /etc/hosts, указываем FQDN для данного хоста:
3. Проверяем, что наш домен виден в сети:
4. Вводим машину в домен:
5. Редактируем настройки PAM
Дополнительный плюс данного варианта — сквозная авторизация на файловых ресурсах домена.
Традиционный вариант использующий Samba winbind, имеет ряд существенных преимуществ по сравнению с базовым устаревшим решением, включая следующее:
- Winbind предполагает, что он подключается к AD, и использует преимущества собственных протоколов Windows и расширений протокола LDAP.
- Он не только понимает концепцию доменов и лесов, но также работает с доверием между доменами и лесами.
- Он может обнаруживать серверы, используя DNS.
- Он может переключиться на другой сервер, если другой контроллер домена AD становится недоступным.
- Он может динамически завершать сопоставление идентификаторов на основе идентификаторов объектов AD (SID) или использовать атрибуты POSIX, хранящиеся в AD (если эти расширения были загружены).
- Он хорошо интегрируется с клиентом Samba FS и CIF.
- Безопасность соединения хорошая и основана на идентификационной информации клиентской системы и ключах Kerberos, выданных этой системе.
Хотя Samba winbind обладает перечисленным выше набором преимуществ и является шагом вперед по сравнению с устаревшим интеграционным решением, он также имеет некоторые ограничения:
- Политики все еще не управляются централизованно и должны распространяться вне группы.
- Samba winbind может подключаться только к AD, тогда как устаревшее решение может работать с любой реализацией сервера LDAP и Kerberos.
Современный вариант интеграции основан на компоненте под названием SSSD. SSSD расшифровывается как Systems Security Services Daemon (Демон служб системы безопасности). На самом деле это группа служб, которые являются частью основной ОС Linux и работают совместно для обеспечения аутентификации, поиска идентификаторов и контроля доступа для системы Linux. SSSD действует как соединитель между операционной системой и центральным сервером идентификации. SSSD может взаимодействовать с AD, FreeIPA (также известным как «Identity Management»), Samba DC или любыми другими стандартными реализациями серверов LDAP и/или Kerberos.
Последние версии Linux содержат компонент под названием «realmd». Этот компонент действует как конфигуратор для SSSD. Он позволяет обнаруживать присутствие центрального идентификационного сервера путем запроса DNS. Realmd может настроить SSSD для работы с AD, FreeIPA (IdM) или MIT Kerberos, делая установку и настройку такой же простой, как и решения сторонних производителей.
По сравнению с Samba winbind SSSD может делать практически все, что делает winbind. Единственным серьезным ограничением является поддержка (старого) протокола NTLM. SSSD не реализует этот протокол, поскольку по современным стандартам NTLM более не безопасен для использования. Лучшей практикой безопасности является исключение использования NTLM на предприятии, однако некоторые организации могут столкнуться с проблемой, учитывая исторические причины и/или сложность среды.
Также следует отметить, что до недавнего времени в SSSD отсутствовала интеграция с SambaFS и клиентом CIFS, но последняя версия SSSD покрывает этот пробел. В дополнение ко всем современным функциям Samba Winbind SSSD представляет ряд функций, которые делают Samba winbind менее значимым:
SSSD активно развивается и имеет четкую дорожную карту для обеспечения большей интеграции с другими современными компонентами, такими как Docker, Cockpit, GSS Proxy и другими.
По сравнению с коммерческими решениями, SSSD основан на прямой интеграции, которая может все еще иметь некоторые ограничения. (См. таблицу)
Функционал обычного файлового сервера неизменно остается одним из самых популярных и востребованных в работе среднестатистического офиса. Сегодня я расскажу как установить и настроить файловый сервер Samba с авторизацией в AD и управлением доступом с помощью доменных учетных записей. Сразу скажу, что тема это достаточно трудная и хрупкая, очень часто что-то идет не так, нужно неплохо ориентироваться в теме, чтобы решать возникающие проблемы.
Прежде чем начинать настройку файлового сервера samba, прочитайте полностью материал, чтобы решить, каким способом будете настраивать. По ходу написания статьи у меня получились 2 принципиально разных решения.
Введение
Ранее я рассказывал как сделать очень простую и быструю настройку самбы, когда доступ ограничивается либо внутренними пользователями самбы, либо с помощью ip. Если вас такой формат эксплуатации файлового сервера устраивает, то читать дальше не обязательно. Используйте приведенную статью, и у вас все получится очень быстро.
Для более сложной настройки самбы с авторизацией в Active Directory будем разбираться дальше. Существует как минимум 2 способа добавления linux сервера в домен Windows Server:
Если у вас еще нет готового сервера, то можете воспользоваться моими материалами на эту тему — установка и настройка centos 7. Так же рекомендую настроить iptables для корректной работы сервера с доменом windows. Далее я не буду касаться этого вопроса, мы просто отключим фаерволл, потому что его настройка не тема этой статьи.
Настраивать файловую шару samba будем на сервере под управлением CentOS 7 следующей версии:
Вводные слова я все сказал. Начнем настройку самбы с ввода сервера в домен.
Добавляем сервер к домену через realm
Я не буду придумывать ничего нового, а полностью воспользуюсь инструкцией из приведенной выше статьи по настройке авторизации доменных учеток на сервере, но при этом не буду настраивать саму авторизацию. В данном случае мне это не нужно.
Итак, отключаем firewall и SELinux, если не сделали это раньше. Если не хотите отключать, то настройте сами. Данная настройка выходит за рамки статьи.
Выполняем команду, чтобы не ждать перезагрузки для применения изменений.
| xs.local | название домена |
| 10.1.3.4 | ip адрес контроллера домена |
| xs-winsrv.xs.local | полное имя контроллера домена |
| xs-design | имя сервера centos, который вводим в домен |
| admin51 | учетная запись администратора домена |
Перед дальнейшей настройкой, убедитесь, что с вашего сервера centos вы без проблем пингуете и резолвите контроллер домена по полному имени. Если есть какие-то проблемы, исправьте это либо указанием нужного dns сервера, либо правкой файла hosts.
Настроим синхронизацию времени с контроллером домена. Это важно, у вас должно быть одинаковое время с контроллером домена. Проверьте его и убедитесь, что стоят одинаковые часовые пояса.
Устанавливаем утилиту для синхронизации времени chrony:
Добавляем в конфиг /etc/chrony.conf адрес контроллера домена. И делаем его единственным сервером для синхронизации, остальные удаляем.
Сохраняем конфиг, запускаем chrony и добавляем в автозагрузку.
Проверим, что с синхронизацией.
Устанавливаем софт, который понадобится для дальнейшей работы.
Делаем проверку перед вводом в домен.
Заводим в домен.
Если не получили никакой ошибки, значит все прошло нормально. Можно зайти на контроллер домена и проверить, появился ли наш linux сервер в домене.
Проверьте на самом сервере, что он нормально обращается к домену и получает информацию об учетных записях. Показываю на примере доменной учетной записи control.
Еще несколько проверок.
Настройка Samba с интеграцией в AD через sssd
Устанавливаем сам файловый сервер самба.
Рисуем ему примерно такой конфиг.
Запускаем службу smb.service и добавляем в автозагрузку.
Мне стало жаль тратить время на поиски готового решения с sssd, хотя мне очень хотелось получить рабочий вариант, так как с winbind достаточно часто возникают проблемы. Я надеялся от них избавиться переходом на sssd, но не получилось. Статью не стал переделывать, сохранив то, что уже настроил. Может быть у вас заработает.
Попутно узнал, что sssd не поддерживает NTLM авторизацию, только kerberos. Я не знаю, по какой причине, но у меня самба, судя по логам, упорно пыталась авторизовать пользователя по ntlm. В итоге, я прекратил попытки и вернулся к старому проверенному варианту с winbind. Далее расскажу, как настроить файловый сервер samba для работы в домене windows с помощью winbind.
Вводим CentOS 7 в домен с помощью winbind
Если у вас виртуальная машина, проще установить ее с нуля. Если не хочется по какой-то причине, можно просто удалить все установленные ранее пакеты через команду yum remove. Я поступил именно так.
Устанавливаем недостающие пакеты:
Не забудьте о настройке синхронизации времени, которую мы делали на предыдущих шагах. Надо это проделать, если вы сразу начали настройку с данного пункта. Так же убедитесь, что все в порядке с dns, и контроллеры домена пингуются по именам.
Формируем конфиг для kerberos.
Для удобства дублирую таблицу с информацией, чтобы не пришлось скролить страницу вверх.
| xs.local | название домена |
| 10.1.3.4 | ip адрес контроллера домена |
| xs-winsrv.xs.local | полное имя контроллера домена |
| xs-design | имя сервера centos, который вводим в домен |
| admin51 | учетная запись администратора домена |
Вывод после работы команды у меня такой:
Это не страшно, продолжаем настройку. Заводим сервер с CentOS в домен:
На выходе получил:
В принципе, ничего страшного. Нам придется самим создать A запись на DNS сервере. Я не понимаю, почему иногда она не создается автоматически. Во время написания статьи, я использовал один сервер, у него не было этой ошибки при вводе в домен. Когда проверял статью на втором сервере, получил эту ошибку. Проверяем на контроллере домена в списке компьютеров наш сервер и создаем руками А запись, соответствующую имени сервера и его IP адресу.
Теперь рисуем конфиг для самбы примерно такой.
У меня русский язык на контроллере домена, поэтому и имена групп на русском. Проблем с этим не возникает. Не забудьте создать директорию /mnt/shara.
Запускаем samba и winbind и добавляем в автозагрузку.
Выполняем ряд проверок, чтобы убедиться, что все в порядке, winbind работает и samba будет получать актуальную информацию о пользователях и группах домена.
Последние две команды должны вывести список всех пользователей и групп домена.
Проверим теперь авторизацию в домене.
В данном случае control — имя пользователя домена, pass — его пароль. Успешная проверка выглядит так, как у меня. В завершении проверок посмотрим, корректно ли система сопоставляет доменные учетные записи локальным.
Все в порядке. Теперь все готово для корректной работы файлового сервера на основе Samba с доменными учетными записями. В завершении настроек, сделаем администратора домена владельцем нашей шары.
Проверяем, что получилось.
Уберем доступ на чтение у всех остальных, оставим полные права для пользователя admin51 и на чтение у пользователей домена.
Идем на любую виндовую машину и пробуем зайти на шару по адресу \\ip-адрес-сервера. Попадаем на нашу шару.Если не получилось зайти, проверьте настройки iptables. На время отладки можно их отключить. Так же убедитесь, что у вас запущена служба smb.service.
Смотрим расширенные параметры безопасности:
Получилось то, что хотели. Управлять правами доступа можно через windows acl с любой машины windows, где учетная запись пользователя домена будет обладать необходимыми правами. Если по какой-то причине это не получится (а я с такими ситуациями сталкивался достаточно часто), на помощь придут консольные утилиты getfacl для проверки прав и setfacl для изменения прав. Документация по этим командам есть в сети и легко ищется. Я рекомендую всегда использовать эти команды, когда вы выполняете изменение прав по большому дереву каталогов. Через консоль выставление прав будет выполнено раз в 5-10 быстрее, чем через windows acl. На больших файловых архивах разница может быть в десятки минут или даже часы.
Настройка прав доступа на файлы в Samba
Сделаю небольшое пояснение по правам доступа в файловом сервере samba. Вопрос этот сложный и объемный. Ему можно посвятить и отдельную статью. Но для полноты картины по настройке самбы, расскажу самое основное.
Как я уже ранее сказал, изменять права доступа к каталогам на файловом сервере можно с помощью команды setfacl. Давайте сейчас посмотрим на права доступа, которые установлены:
Обращаю внимание, что иногда при копировании команд setfacl они не отрабатывают, выдавая не очень понятную ошибку:
Наберите команду с клавиатуры, либо просто удалите и наберите снова ключ -m, он почему-то при копировании часто дает эту ошибку.
Смотрим, что получилось:
То, что надо. Теперь пользователи группы gr_it имеют полные права на шару. Создадим одним таким пользователем папку test1 на нашей шаре и посмотрим, какие права она получит.
Права на папку имеет только ее создатель и больше никто. Для того, чтобы наследовались права с вышестоящего каталога, необходимо на этот вышестоящий каталог добавить дефолтные права доступа. Примерно вот так.
Смотрим, что получилось:
Создадим теперь тем же пользователем еще одну папку test2 и проверим ее права.
Применилось наследование с вышестоящих папок. Не забывайте про дефолтные права и учитывайте их при настройке прав доступа на файловом сервере.
Для удобной и корректной работы с правами доступа я обычно для крупных, корневых директорий выставляю права аккуратно через setfacl в консоли. Какие-то мелкие изменения по пользователям и группам в более низших иерархиях директорий делаю через windows acl с какой-нибудь виндовой машины.
Заключение
- Иногда через windows acl права перестают выставляться, возникают неинформативные ошибки, по которым невозможно понять, что не так.
- Я достаточно регулярно наблюдаю ситуацию, когда слетают соответствия доменных учеток линуксовым UID. В итоге права доступа превращаются в ничего не значащий набор цифр и перестают работать.
- При переносе данных с одного сервера на другой трудно сохранить права доступа. Можно поступить вот так для копирования прав доступа, либо как-то заморочиться, чтобы на всех серверах у вас были одинаковые UID доменных учетных записей. Я не разбирал этот вопрос подробно.
Если у вас есть возможность настроить файловый сервер на windows, либо обойтись линуксом без домена, то сделайте так. Существенно упростите настройку и дальнейшую эксплуатацию.
Файловый сервер. Влияние SSD на производительность.
Около года назад мы провели тестирование различных ОС и файловых систем, изучая их влияние на производительность файлового сервера. Сегодня, когда в обиход плотно входят твердотельные накопители (SSD) и выпущен релиз Samba c поддержкой протокола SMB2, наступило время провести новое тестирование, чтобы на практике выяснить, какие новшества действительно несут увеличение производительности, а какие представляют собой маркетинговые ходы.
Что и как мы тестировали.
Наше сегодняшнее исследование преследует две цели: изучить влияние SSD на производительность файлового сервера и ознакомиться с возможностями новой Samba с поддержкой протокола SMB2. Тестовая платформа осталась прежней, что дает возможность сравнить сегодняшние результаты с результатами прошлогоднего тестирования.
Для тестирования использовались: жесткий диск Western Digital Caviar Blue <WD5000AAKS> емкостью 500 Гб массовой "синей" серии.
И твердотельный накопитель (SSD) OCZ Agility 2 <OCZSSD2-2AGTE60G> емкостью 60 Гб, также относящийся к бюджетной серии.
Из программного обеспечения мы выбрали Windows Server 2008 R2 и Ubuntu Server 11.04, и файловые системы NTFS и ext4 соответственно. Почему Ubuntu Server 11.04, а не 10.04 LTS? Все просто, команда TRIM, без которой использование SSD лишено всякого смысла, поддерживается начиная с ядра 2.6.33 и в состав Ubuntu Server 11.04 входит Samba 3.5.8 которая поддерживает SMB2 (по умолчанию эта опция отключена).
Для тестирования использовался пакет Intel NASPT 1.0.7 работающий в среде Windows 7 32-бита. Для каждой конфигурации проводилось 5 прогонов теста, предварительно было проведено еще 5 прогонов для "прогрева" кэша. Ниже приведены средние результаты, округленные до целых значений.
Файловые операции.
Появление поддержки SMB2 в Samba дает свои плоды, результаты Ubuntu Server, в большинстве тестов приближаются к результатам Windows Server 2008 R2 и говорить о безоговорочном лидерстве последнего уже не приходится. Однако Ubuntu Server имеет определенные проблемы с записью, что хорошо видно в тесте File copy to NAS.
Что касается SSD, то в данной группе тестов преимущество весьма сомнительно, очевидно, что в данном случае решающую роль играет реализация сетевого протокола, нежели быстродействие файловой системы, хотя в реальных условиях SSD все таки покажет лучшие результаты, об это мы расскажем ниже.
Мультимедиа
Воспроизведение
Здесь Ubuntu Server и Windows Server идут практически вровень и выделить лидера не представляется возможным, разница находится в области погрешности измерений. И как раз здесь SSD проявляют себя во всей красе: в то время как HDD с ростом числа клиентов начинает резко снижать производительность, SSD не только поддерживает ее на прежнем уровне, но и имеет тенденцию к увеличению. Собственно данный пример хорошо показывает различие меду механическими и твердотельными накопителями, последние имеют гораздо более высокую скорость произвольного доступа, что хорошо продемонстрировал данный тест. В условиях многопользовательского доступа SSD однозначно предпочтительнее HDD.
Запись.
На запись результат довольно таки ровный, явного преимущества SSD здесь нет, т.е. опять на первый план выходят сетевые протоколы, а не быстродействие дисковой подсистемы. Что касается Ubuntu, то хорошо видны преимущества SMB2, система идет "дыша в затылок" Windows.
Выводы.
В то же время SSD показывает отличные характеристики при увеличении числа клиентов, в то время как HDD диски начинают довольно существенно снижать производительность. Из чего можно сделать вывод, что переход на SSD для файловых серверов оправдан при большом количестве клиентских подключений, если же вы ожидаете увеличение скорости доступа к общему ресурсу, то вынуждены вас разочаровать - этого не произойдет.
Также неоднозначно выглядит сравнение Windows Server и Ubuntu Server, последний показал более низкие, но вполне сравнимые результаты, а с учетом того, что Samba и Ubuntu Server ничего не стоят, данное решение является весьма привлекательным для малого и среднего бизнеса.
В общем, можно сказать следующее: хотите сэкономить - берите Ubuntu Server, нужна высокая нагрузочная способность - ставьте SSD. Windows Server R2 в роли файлового сервера рекомендуем использовать для высоконагруженных систем или когда требуется плотная интеграция с Active Directory.
Читайте также: