Я написал проверку Nagios, которая должна проверять время, необходимое серверу для записи файла на одно из его монтирований. Проверка выполняется пользователем nagios.
Сервер NFS настроен так:
[root@ny4aftp2 ~]# tail /etc/exports
/proxy_logs *(rw,insecure,insecure_locks,no_subtree_check,async)
/sync_logs *(rw,insecure,insecure_locks,no_subtree_check,async)
[root@ny4aftp2 ~]# ls -ld /sync_logs/
drwxrwxr-x 3 peeradmin peeradmin 4096 Dec 10 10:14 /sync_logs/
[root@ny4aftp2 ~]#
Это команда, которую выполняет скрипт проверки:
dd if=/dev/zero of=/$MOUNTPOINT/`hostname`.dat bs=1024 count=102
Клиент настроен так:
[root@ny4aproxy11 ~]# grep sync /etc/fstab
IP:/sync_logs /sync_logs nfs intr,noatime 0 0
Когда проверка выполняется пользователем nagios, он получает ошибку «Permission denied», когда dd
команда пытается написать .dat
файл в общий ресурс nfs /sync_logs
хотя пользователь nagios
настроен одинаково на обеих машинах:
Сервер:
[root@ny4aftp2 ~]# id nagios
uid=498(nagios) gid=498(nagios) groups=498(nagios),500(peeradmin)
Клиент:
[root@ny4aproxy11 ~]# id nagios
uid=498(nagios) gid=498(nagios) groups=498(nagios),500(peeradmin)
А пользователь nagios является членом группы peeradmin, которая является владельцем /sync_logs
каталог.
/sync_logs
на сервере NFS:
[root@ny4aftp2 ~]# ls -ld /sync_logs/
drwxrwxr-x 3 peeradmin peeradmin 4096 Dec 10 10:20 /sync_logs/
/sync_logs
на клиенте NFS:
[root@ny4aproxy11 ~]# ls -ld /sync_logs/
drwxrwxr-x 3 peeradmin peeradmin 4096 Dec 10 10:20 /sync_logs/
Я бы не хотел chmod o+w /sync_logs
, Я предпочитаю исправить это так, как должно быть ... как nagios
пользователь будет получать разрешения из-за того, что он является членом peeradmin
группа, и это позволит nagios
пользователю писать в /sync_logs
каталог.
Как это сделать и что я делаю не так?
Редактировать # 1:
IP:/sync_logs on /sync_logs type nfs (rw,noatime,intr,vers=4,addr=SERVER_IP,clientaddr=CLIENT_IP)
заранее спасибо
На основе комментариев на данный момент:
Это означает, что проблема, скорее всего, связана с обработкой учетной записи NFSv4 и idmapd
. Что происходит в NFSv3, так это то, что ваш клиент сообщает серверу, какой UID и GID вы используете.
Что происходит в NFSv4, так это то, что они используют имена пользователей и использовать idmapd
для отображения вперед и назад. Это означает, что вам больше не нужно иметь одинаковые UID и GID в вашей области аутентификации.
Но вот в чем проблема - idmapd
необходимо иметь возможность выполнять отображение взад и вперед. Будет отправлено user@domain
(эквивалент), а не числовой UID / GID.
Так что проверь свой /etc/idmapd.conf
. Также убедитесь, что ваши доменные имена на клиенте и хосте совпадают. Вы ищете domainname
в idmapd.conf
- если он не установлен, по умолчанию будет использоваться любой domainname
в отчете сервера / клиента.
Переход на NFSv3 может служить обходным путем (и проверкой), но, вероятно, это не лучшая идея - NFSv4 имеет несколько хороших улучшений по сравнению с v3, и отключение их из-за проблемы с аутентификацией не идеально.