У меня есть openldap сервер, который я настроил на cent os 7. Я сделал так, чтобы он работал со всеми моими другими ВМ, которые монтируют nfs mount с nfs сервера для их /home.
Я только что выяснил, что если я создаю нового пользователя ldap и пытаюсь войти в какую-нибудь виртуальную машину, она позволяет мне войти, но сообщает, что не может создать /home/user и не может выполнить chngdir к нему.
Но я также узнал, что если я сначала ssh user@mynfsserver, он входит в систему, создает соответствующий /home/user, а затем после этого я могу ssh на любую другую ВМ с моим ldapuser, и он работает просто отлично, больше не жалуется на то, что не может создать папку в home для указанного пользователя.
Я использую autofs на каждой ВМ с файлом home.map, похоже, что он имеет правильные разрешения:
* -fstype=nfs,rw,nosuid,soft 10.10.1.139:/home/&
так что это похоже на какую-то проблему с разрешениями, когда пользователи получают ошибки при входе в ВМ с их недавно созданными учетными данными ldap. Но если тот же пользователь входит на 10.10.1.139 (nfs сервер, с которого сопоставлен home), то это, кажется, позволяет им входить в VMs без ошибок unable to create /home/user.
Должен ли мой openldap-сервер как-то быть осведомлен о сервере nfs?
Не считая заминки с необходимостью сначала войти на сервер nfs, я могу зайти на другую ВМ, коснуться файла в папке home и бинго, он находится на любой другой ВМ, на которую я войду. Так что это работает на 95%, просто раздражает необходимость сначала войти на nfs-сервер с пользователем ldap, чтобы создание /home/user работало на других ВМ.
Автоматическое создание новых домашних каталогов выполняется пользователем root, но по умолчанию root отображается на анонимного пользователя при монтировании nfs, и поэтому домашний каталог не может быть создан на всех клиентах nfs. Добавьте no_root_squash
в свою строку в / etc / exports
на вашем сервере nfs, чтобы отключить это, и запустите sudo exportfs -ra
, чтобы изменения вступили в силу. Итак, судя по вашему комментарию, это должно выглядеть так:
/home 10.10.1.0/24(rw,no_root_squash)
Это позволит получить root-доступ к смонтированной файловой системе nfs на всех клиентах.
Однако это имеет некоторые последствия. Из справочной страницы exportfs:
Сопоставление идентификаторов пользователей
nfsd основывает управление доступом к файлам на сервере на основе идентификаторов uid и gid, предоставленных в каждом запросе NFS RPC. Обычное поведение, которого ожидает пользователь, состоит в том, что он может получить доступ к своим файлам на сервере так же, как и в обычной файловой системе. Для этого необходимо, чтобы на клиенте и сервере использовались одни и те же идентификаторы uid и gid. Это не всегда верно и не всегда желательно.
Очень часто нежелательно, чтобы пользователь root на клиентской машине также рассматривался как root при доступе к файлам на сервере NFS. С этой целью uid 0 обычно сопоставляется с другим идентификатором: так называемым анонимным или никому uid. Этот режим работы (называемый «корневое сжатие») является по умолчанию и может быть отключен с помощью no_root_squash.
По умолчанию exportfs выбирает uid и gid 65534 для ограниченного доступа. Эти значения также могут быть отменены параметрами anonuid и anongid. Наконец, вы можете сопоставить все запросы пользователей с анонимным uid, указав опцию all_squash.