Сбой сетевой службы при загрузке в SLES 10.2, что может привести к проблемам клиента NFS
На коробке, недавно обновленной с SLES 9.3 до 10.2, я вижу следующую проблему:
Перед обновлением монтируется NFS (определяется через yast, т. Е. Он появляется в /etc/fstab) работал правильно. Однако после обновления он не работает. Трассировка сети показывает, что он устанавливает первоначальное соединение с сервером NFS через TCP (для RPC portmapper), но затем переключается на UDP для последующего вызова MOUNT; так как сервер NFS не позволяет UDP (по уважительной причине, из-за возможных проблем с повреждением данных, как в nfs(5)), соединение не пройдет.
Добавление опции TCP (либо в fstab, либо в командной строке и т. Д.) Не имеет никакого эффекта.
В ходе устранения этой проблемы я обнаружил, что /var/adm/messages сообщает следующее как происходящее во время загрузки:
Failed services in runlevel 3: network
(Должен заметить, что, несмотря на это сообщение об ошибке, по крайней мере, некоторые сетевые службы запускаются, так как ящик доступен через SSH.)
Мои вопросы, тогда:
- На что мне обратить внимание, чтобы определить причину сбоя при запуске службы?
- Может ли это быть причиной проблемы с NFS, описанной выше?
- Если ответ на (2) - нет, то есть предложения о том, что искать?
Редактирование, чтобы добавить некоторую информацию, касающуюся ответов ниже.
Оказывается, что при загрузке происходит сбой сетевой службы, поскольку один из интерфейсов (в этом блоке их два) использует DHCP, но в настоящее время он еще не доступен. Поэтому я отключил его, остановил / перезапустил сетевую службу и клиентские службы NFS, но все равно получил те же результаты.
На стороне клиента нет брандмауэра. Также iptables -L на стороне клиента показывает, что все принято; и нет записей в /etc/hosts.allow или /etc/hosts.deny.
На стороне NFS-сервера ничего не изменилось. Удаленный nfsserver действительно объявляет, что он позволяет использовать TCP и UDP для всех служб NFS (хотя есть правило iptables, блокирующее UDP).
Запись в /etc/fstab довольно проста - что вы получите от настройки в yast:
x.x.x.x:/volume /localdir nfs defaults 0 0
rpcinfo -p для окна клиента показывает только работающий portmapper v2, объявляющий как TCP, так и UDP. Для сервера он показывает все обычные сервисы:
program vers proto port
100000 2 tcp 111 portmapper
100000 2 udp 111 portmapper
100024 1 udp 4047 status
100024 1 tcp 4047 status
100011 1 udp 4049 rquotad
100021 1 udp 4045 nlockmgr
100021 3 udp 4045 nlockmgr
100021 4 udp 4045 nlockmgr
100021 1 tcp 4045 nlockmgr
100021 3 tcp 4045 nlockmgr
100021 4 tcp 4045 nlockmgr
100005 1 udp 4046 mountd
100005 1 tcp 4046 mountd
100005 2 udp 4046 mountd
100005 2 tcp 4046 mountd
100005 3 udp 4046 mountd
100005 3 tcp 4046 mountd
100003 2 udp 2049 nfs
100003 3 udp 2049 nfs
100003 2 tcp 2049 nfs
100003 3 tcp 2049 nfs
Вызов монтирования с записью в /etc/fstab выше:
mount /localdir
хотя я также пробовал это с различными вариантами, такими как tcp, v3, и т. д.
И запись /etc/fstab (отсюда и mount), и вызов rpcinfo -p используют IP-адрес, поэтому проблем с разрешением DNS не возникает.
6 ответов
Для справки, в случае, если кто-то еще сталкивается с этим вопросом и хочет получить ответ:
Я наконец открыл билет с Novell на это. Оказывается, это известная ошибка в SLES 10.2 (491140: mount игнорирует "proto=" для "nfs"), и для этого есть исправление (util-linux-2.12r-35.35.2.x86_64.rpm), После установки монтирование работает, как и ожидалось, и все запросы выполняются по TCP. (Служба поддержки Novell также сообщила мне, что это объединено в SLES 10.3.)
Пара вещей. Во-первых, вы заявляете в начале, что since the NFS server doesn't allow UDP, а затем в вашем редактировании упомянуть The remote nfsserver is indeed advertising that it allows both TCP and UDP for all of the NFS services, Это кажется немного странным. Почему сервер рекламирует что-то, чего не позволяет?
Во-вторых, вы пытаетесь использовать NFS версии 2 или 3? Версия 2 поддерживает только UDP, тогда как вам нужна версия 3 для TCP. Возможно, ручное указание версии 3 в опциях монтирования поможет? (vers=3) Если по умолчанию установлено значение 2, то даже указание TCP не принесет вам пользы.
У меня также были проблемы с новыми клиентами, пытающимися использовать версию 4, когда сервер не совсем ее поддерживал. Ваше обновление SLES могло привести к другой версии по умолчанию. Все больше причин указывать это явно.
Почему бы вам не опубликовать запись в /etc/fstab?
Как я понимаю ваш вопрос, вы можете сделать следующее:
- SSH к вашей клиентской системе NFS
- "соединить с
rpcinfoс клиента на сервер - вы отключили интерфейс dhcp, поэтому каждый трафик проходит через один интерфейс, а других маршрутов нет
но вы не можете смонтировать файловую систему с сервера nfs на клиенте nfs, и вы не получите никакого сообщения об ошибке.
какая разница между вашим rpcinfo а также mount звонки? Вы используете IP-адрес в одном и FQDN в другом? не могли бы вы опубликовать обе команды с выходным кодом и кодом возврата?
Проверьте, чтобы убедиться /etc/hosts.deny не содержит записи для mountdи проверить hosts.allowпо тем же причинам. Для чего это стоит, я обычно убираюсь hosts.deny и использовать iptables контролировать доступ.
использование rpcinfo -p nfsserver чтобы убедиться, что mountd действительно реклама TCP- есть вариант -n отключить прослушивание TCP, которое (IIRC на SuSE), вероятно, будет установлено в /etc/sysconfig/nfs или около того.
Попробуйте установить вещи явно и посмотрите, куда это вас приведет. Например, в /etc/fstab:
x.x.x.x:/vol /local nfs proto=tcp,port=2049,mountport=4046,nfsvers=3 0 0
Это должно по крайней мере обойти portmapper и явно попытаться подключиться к портам TCP, которые вы перечислили выше, и упростить трассировку tcpdump каждого канала во время отладки.
- Попробуйте запустить сервис вручную с
service network restartи посмотреть, какие сообщения вы получаете. Там должна быть какая-то информация. - Возможно...
- Проверьте, включен ли в вашей системе брандмауэр по умолчанию, это может вызвать проблемы. Особенно, если неудачный запуск сети неправильно загружает правила брандмауэра.