Обновление Samba: практический опыт
Новое время диктует новые решения, вот и в нашей фирме количество пользовательских машин, работающих под управлением Windows 7, постепенно растёт, вытесняя с десктопов привычную всем XP. В связи с этим недавно встал вопрос их интеграции в существующую доменную инфраструктуру для разграничения прав, централизованного управления доступом – сделать их полноправными членами корпоративного домена.
Здесь стоит отметить один момент: у нас служба контроллера домена построена на базе Samba и базируется на ветке '3.0.х' этого продукта. Связка Samba+OpenLDAP на основном сервере была настроена в 2007-м году и с тех пор пор претерпевала лишь минорные изменения. Устанавливались обновления, которые закрывали найденные уязвимости в безопасности протокола. Иначе говоря, несмотря на последние версии Samba, базовый функционал продукта соответствовал состоянию дел примерно на 2007 год. Попытки решить проблему «в лоб» (ставить машины с «семеркой» в домен Samba 3.0, аналогично XP) не увенчались успехом, а чтение документации и поиск по форумам выявил проблему принципиальной несовместимости Samba версий '3.0.x' и последних операционных систем от Microsoft.
Необходимость обновления вызывала вполне понятные опасения насчёт совместимости с уже работающими клиентами. Очень не хотелось прерывать работу предприятия на несколько часов, пытаясь разобраться, что же пошло не так, или из-за изменившихся параметров доменной авторизации повторно ставить в домен почти сотню машин основного филиала. Положение упрощал тот факт, что база учётных записей пользователей находилась в LDAP и при неблагоприятном развитии событий, по крайней мере, можно было не беспокоиться насчёт пользовательских данных. Поэтому, для экспериментов была настроена тестовая машина с параметрами, аналогичными рабочему контроллеру домена, скачаны последние стабильные версии и всё сначала проверялось на ней. Для внедрения была выбрана ветка '3.5'.
В основном, мои опасения не оправдались и обновление на тестовом (а в последующем, и на действующем) контроллере домена с '3.0.36' до '3.5.3' сборки команды SerNet не вызвали особых проблем. Обновление пакетов производилось стандартным способом. Имеющиеся клиенты прозрачно подхватили новый домен и продолжили работу, как обычно. Машины с Windows 7 теперь нормально авторизуются и работают в домене.
Вот основные подводные камни, с которыми мне пришлось столкнуться при обновлении:
- На каком-то этапе развития Samba от ветки '3.0' до '3.4' сменился формат TDB-файлов и у меня создалось впечатление, что заявленная автоматическая конвертация срабатывает не всегда корректно. Я сохранил SID-ы («net getlocalsid», «net getdomainsid») и удалил все TDB-файлы из /etc/samba. После обновления я восстановил значения («net setlocalsid», «net setdomainsid») и задал права доступа к LDAP-базе через 'smbpasswd';
- В новых версиях по умолчанию включен доступ к LDAP по SSL. В моём случае, используется незашифрованное соединение к базе на localhost, поэтому пришлось отключить шифрование («ldap ssl = off» в '/etc/samba/smb.conf');
- На RHEL4 не удалось обновить пакет 'samba3-cifsmount' из-за отсутствующей в дистрибутиве (по умолчанию) библиотеки 'libkeyutils'. По этой же причине, при проверке сигнатур RPM-пакетов выдаются предупреждения, которые можно проигнорировать. В версии для RHEL5/CentOS5 всё нормально. Для меня монтирование SMB-каталогов с RHEL4-машины не является критичным, поэтому я не стал разбираться с этим вопросом;
- Для нормальной работы Windows 98 в '/etc/samba/smb.conf' нужно включить опцию «lanman auth = yes» (теперь она по умолчанию отключена). Это сработало только с основным контроллером домена, но lanman-аутентификация на другом Samba-сервере, который является членом домена и проверяет авторизацию на контроллере домена через winbind, не работает. У меня в сети всего одна машина с Windows 98, поэтому для меня это также не критично;
- Для управления доменом через стандартную Windows-утилиту «UsrMgr» требуется версия Samba старше '3.5.3'. В предыдущих версиях её поддержка была сломана.