rpcbind(1M)
НАЗВАНИЕ
rpcbind — сопоставитель универсальных адресов и номеров программ RPC
СИНТАКСИС
ОПИСАНИЕ
rpcbind — это сервер, преобразующий номера программ RPC в универсальные адреса. Он должен работать, чтобы можно было делать вызовы удаленных процедур (RPC calls).
При запуске службы RPC, она сообщает rpcbind, по какому адресу она принимает информацию и какие номера программ RPC она готова обслуживать. Когда клиент желает выполнить вызов удаленной процедуры, он сначала связывается с rpcbind на сервере для определения адреса, куда необходимо посылать пакеты RPC.
rpcbind допускает частичный успех. Т.е., если ему удается запуститься как минимум на одном интерфейсе закольцовывания (loopback provider), он продолжит работу, даже если запуск на других интерфейсах закольцовывания и транспортах типа tcp, udp, spx и ipx закончится неудачей.
ИСПОЛЬЗОВАНИЕ
Обычно стандартные серверы RPC запускаются мониторами портов, поэтому rpcbind должен быть запущен перед вызовом мониторов портов. Если rpcbind не может запуститься на транспорте, указанном в файле /etc/netconfig, он выдает предупреждающее сообщение о проблемном транспорте, а затем пытается запуститься на оставшихся транспортах.
rpcbind может запускаться только пользователями с идентификатором, совпадающим с root.
Опции
rpcbind воспринимает следующие опции:
| -d | Выдает отладочную информацию для каждого из доступных транспортов, указанных в файле /etc/netconfig. |
| -q | Не выдает сообщения об ошибках, кроме сообщений, связанных с фатальными ошибками при запуске rpcbind. |
Предупреждения
Если происходит сбой rpcbind, все серверы RPC необходимо перезапустить.
Если не удалось запустить демон rpcbind, причина может быть в том, что имя машины отличается от указанного в файлах /etc/net/*/hosts. Так может происходить, если имя машины изменено с помощью команды uname(1).
Чтобы проверить, работает ли rpcbind, введите
nfsping -o rpcbind
Если выдается сообщение, утверждающее, что rpcbind не работает, сравните имя системы (uname -n) с записями в файлах /etc/net/*/hosts, и проверьте, совпадают ли они.
Если они не совпадают, значит, имя вашей машины было изменено с помощью команды uname, и придется вручную изменить имена хоста в записях файлов /etc/net/*/hosts.
Например, если имя хоста для машины было hulk (используйте uname -n), первая запись в каждом из файлов /etc/net/*/hosts должна выглядеть следующим образом:
Если первая запись в каждом из файлов /etc/net/*/hosts не совпадает с именем хоста машины, необходимо обновить первую запись в файлах /etc/net/*/hosts и перезапустить демон rpcbind. Чтобы перезапустить rpcbind, введите:
ССЫЛКИ
Copyright 1994 Novell, Inc.
Copyright 1999 В. Кравчук, OpenXS Initiative, перевод на русский язык
Источник
rpcbind, port 111 зачем он нужен? Если можно, на пальцах
Читал интернет, но так и не понял, зачем нужен этот сервис.
Обьясните на пальцах, как для чувака с улицы, пожалуйста.
Фирма Sun придумала всё это, потому что посчитала неправильным под каждый удалённый сервис (вызов удалённой процедуры) выделять отдельный фиксированный порт. Сейчас от этого остался только NFS, а раньше было больше.
Когда на сервере запускается демон nfsd он может начать слушать порт 2049, а получить какой-нибудь другой порт, если 2049 занят. Он сообщает об этом запущенному на том же сервере rpcbind’у, который всегда слушает порт 111. Клиент сначала обращается к rpcbind’у на сервере, узнаёт, запущен ли nfsd и на каком порту, и после этого уже обращается к nfsd.
А сейчас это где-то используется? Вроде nfs 4 уже без него работает.
так хорошая же идея, не? Я например люблю юзать Netflix Eureka, которая работает как DNS, но умеет отдавать не только IP но и порт
Идея хорошая, но как-то не прижилось. ИМХО, правильнее когда информацию о портах получают прямо с того сервера, где запущены службы (демоны), чем, с какого-то другого сервера, допустим с DNS, через SRV-записи.
А с другой стороны, отсутствие фиксированых портов — проблема в настройке firewall’ов.
Гуглится, что из-за бага, только начиная с версии 3.14 ядра линукса реально заработал nfs v4 без rpcbind. На серверах ядра не часто обновляют, да и nfs 3 ещё используются, есть ведь всякие медиаценты и прочие клиенты, умеющие только v3.
А может у кого вобще ещё NIS живой.
а это из-за отсутствия девопса идея не приживается. Порты тоже может открывать скрипт
правильная идея для одного случая: когда у тебя три фиксированных сервера, и ты их админишь.
а вот если у тебя автоматически выделяются виртуалки в собственном опенстеке или Амазоне, ты задолбаешься самостоятельно знать, где что находится (и информация эта будет протухать каждые полчаса). Нужна автоматика, которая сама будет знать, кого куда отправить, и какие порты где открыть.
эту автоматику нужно написать самостоятельно) Отркытие портов и прочее можно сделать тупо на Ansible, автоматический service discovery — вот как раз через Eureka
Eureka лучше, чем DNS по той причине, что DNS как правило админят админы, а это проблема для автоматики. В Эврике же, новые сервисы при своём запуске самостоятельно там регистрируются
Еще идея — обычно все сервисы в кластере лучше объединять в DMZ относительно друг друга, и тогда никакие порты прописывать и не надо, фаервол не нужен. А вот снаружи кластер уже нужно окружить забором и выставить наружу только 80 порт
Порты тоже может открывать скрипт
Скрипт может открывать порты только на сервере, а фильтрация трафика зачастую настраивается на маршрутизаторах, особенно во времена появления rpcbind, когда firewall для ОС Solaris был отдельным пакетом за отдельные деньги. Точнее, теоретически в скрипт можно понаписать ключей/паролей от маршрутизаторов, но это как бы клинический случай.
В DNS есть механизм обновлений, разве что DNS-сервера не позволяют настраивать какой клиент какие записи может обновлять и какие ip-адреса туда прописывать. Но может кто уже и написал подобный «гибкий» DNS-сервер.
Автоматизацию я не признаю, начиная с dhcp, а уж всякие виртуалки, облака и микросервисы вобще для меня не существуют, я динозавр :). В фирме мне с избытком хватает другой работы руками, чтобы админить не более трёх серверов.
и выставить наружу только 80 порт
И как через 80 порт пускать NFS?
rpcbind/NFS это, скорее не к интернету, где всё сейчас через web, а к корпоративной сети на 1-100к машин, когда админы серверов давно уже перестали представлять, кто где и что делает, и откуда и куда лезет вирусня и т.д. Но нужно обеспечивать доступ по разным протоколам и передачу больших объёмов данных.
Идея хорошая, но на безопасность они забили, поэтому и не прижилось — мало кому понравится, когда вся инфа о конфигурации сети передаётся кому попало, включая логины-пароли юзеров открытым текстом.
Точнее, теоретически в скрипт можно понаписать ключей/паролей от маршрутизаторов, но это как бы клинический случай.
используя Ansible, ты централизованно хранишь файловые ключи от всей сети, и после этого Ansible использует их для беспарольного подключения по SSH, гуляет и настраивает что ему нужно. Это совершенно нормальный мэйнстримовый способ
если ты всё-таки считаешь себя сисадмином серверной инфраструктуры, очень советую учиться пользоваться автоматизацией. В самом ближайшем будущем классические сисадмины, которые руками что-то делают в консольке юникса, будут истреблены как класс =) (я в свою очередь стараюсь учиться другим способом программирования, т.к. обычным корпоративным программистам скоро тоже будет звезда)
обычно есть два основных домена безопасности: внутрисеть и веб
по вебу обычные пользователи могут смотреть на веб-морду и звать HTTP API типа REST или SOAP. Вот там должен быть 80, 443, 465 и всё. Важно что этот домен относится как «к людям из интернета», так и к «людям внутри локальной сети предприятия».
работу вебморды обеспечивают сервисы внутри внутрисети. Вот там уже можно размещать всякие небезопасные штуки типа NFS, или тупо раздать всем файловые ключи и общаться по SSL или еще как-то так. Во внутрисети уже можно сделать DMZ. Важно что в этом домене не могут работать люди, только приложения.
логины-пароли юзеров открытым текстом
моё литсо. (( кто пустил школьников программировать такую важную штуку..
читни уже что такое rpcbind и зачем он нужен, чтобы больше так не позориться. хронического школьника 
stevejobs это тоже касается.
Вот там должен быть 80, 443, 465 и всё . и прочее блаблабла и dmz
Это и так хз сколько десятков лет как делают в нормальных конторах, а хипстеры только начинают открывать прописные истины.
кто пустил школьников программировать такую важную штуку
Дык это было в такие бородатые времена, когда ещё никто не парился. rsh был не многим лучше, root с паролем root был обычным делом.
логины-пароли юзеров открытым текстом
моё литсо. (( кто пустил школьников программировать такую важную штуку..
т.е. существование ftp до сих пор, вас не смущает?
Источник
rpcbind(8) — Linux man page
rpcbind — universal addresses to RPC program number mapper
Synopsis
Description
The rpcbind utility is a server that converts RPC program numbers into universal addresses. It must be running on the host to be able to make RPC calls on a server on that machine.
When an RPC service is started, it tells rpcbind the address at which it is listening, and the RPC program numbers it is prepared to serve. When a client wishes to make an RPC call to a given program number, it first contacts rpcbind on the server machine to determine the address where RPC requests should be sent.
The rpcbind utility should be started before any other RPC service. Normally, standard RPC servers are started by port monitors, so rpcbind must be started before port monitors are invoked.
When rpcbind is started, it checks that certain name-to-address translation-calls function correctly. If they fail, the network configuration databases may be corrupt. Since RPC services cannot function correctly in this situation, rpcbind reports the condition and terminates.
The rpcbind utility can only be started by the super-user.
Options
-h‘ Specify specific IP addresses to bind to for UDP requests. This option may be specified multiple times and is typically necessary when running on a multi-homed host. If no -h option is specified, rpcbind will bind to INADDR_ANY, which could lead to problems on a multi-homed host due to rpcbind returning a UDP packet from a different IP address than it was sent to. Note that when specifying IP addresses with -h, rpcbind will automatically add 127.0.0.1 and if IPv6 is enabled, ::1 to the list.
-i‘ »Insecure» mode. Allow calls to SET and UNSET from any host. Normally rpcbind accepts these requests only from the loopback interface for security reasons. This change is necessary for programs that were compiled with earlier versions of the rpc library and do not make those requests using the loopback interface.
-l‘ Turn on libwrap connection logging.
-s‘ Cause rpcbind to change to the user daemon as soon as possible. This causes rpcbind to use non-privileged ports for outgoing connections, preventing non-privileged clients from using rpcbind to connect to services from a privileged port.
-w‘ Cause rpcbind to do a «warm start» by read a state file when rpcbind starts up. The state file is created when rpcbind terminates.
Notes
All RPC servers must be restarted if rpcbind is restarted.
Источник
Что делает rpcbind?
Утилита rpcbind [3] отображает службы RPC в порты, на которых они прослушивают. RPC-процессы уведомляют rpcbind, когда они начинают, регистрируют порты, которые они прослушивают, и номера программ RPC, которые они ожидают. Затем клиентская система связывается с rpcbind на сервере с определенным номером программы RPC. Служба rpcbind перенаправляет клиент на соответствующий номер порта, чтобы он мог связываться с запрошенной услугой
Чтобы проверить это, я настроил сервер и клиент NFS и отслеживал трафик между ними. Из того, что я видел, клиент уже знал, что служба NFS на сервере прослушивает порт 2049.
Итак, когда вступает в игру rcpbind? Когда я делаю rpcinfo на сервере, я получаю следующее:
что означает 0.0.0.0.8.1 в этом случае? И как это перевести на порт 2049?
rpcbind является близким аналогом BIND или, действительно, любым DNS-сервером. Если я правильно помню, вы выбираете или присваиваете номер протокола при компиляции объявления интерфейса RPC в код сервера и клиента с rpcgen .
Когда клиент подписывается для определенного интерфейса на конкретном хосте, обычно с clnt_create() , код-заглушка запрашивает у rpcbind на этом узле вопрос, что-то вроде «на каком UDP или TCP-порту есть номер протокола X?»? rpcbind , в отличие от большинства других сервисов ONC, слушает TCP и UDP-порт 111, поэтому, учитывая имя хоста или IP-адрес, программа может просто запросить rpcbind на этом хосте или IP-адресе. rpcbind отвечает соответствующим номером порта, если сервер зарегистрировался на нем на этом хосте. Эта регистрация выполняется серверным процессом при svc_create() .
В вашем примере 100003 является номером протокола для NFS. Некоторые процессы зарегистрировались с помощью rpcbind , указав свой номер протокола (100003) и любой TCP или UDP-порт, который они приобрели. Это необходимо, чтобы rpcbind правильно выдал этот номер порта, 2049 в вашем случае, любому вызову для него «какой порт следует использовать для протокола номер 100003».
Теперь мы попадаем в более туманную территорию. «0.0.0.0.8.1» находится в столбце «адрес» вывода rpcinfo . Поскольку это «универсальный адрес» процесса NFS-сервера, я уверен, что префикс «0.0.0.0» – это IP-адрес (INADDR_ANY в этом случае), который сервер использовал в системном вызове bind() при получении номера порта. Я не уверен, что такое суффикс «8.1», но, глядя на вывод rpcinfo , он должен иметь какое-то отношение к серверу NFS, в основном являющемуся потоком ядра.
Источник
