как узнать версию nfs
Как в need for speed payback узнать версию игры
Доброго времени суток всем. В этой инструкции, я подробно и пошагово расскажу вам как узнать версию need for speed payback, инструкция очень простая и не займет много времени.
И так чтобы узнать версию игры в need for speed payback, вам нужно будет на своем компьютере выполнить следующие действия: Открываем локальный жесткий диск и папку в которую, вы устанавливаете игры, затем находим и переходим в папку с игрой «Need for Speed Payback».
После того как вы перешли в папку Need for Speed Payback, на вашем компьютере или ноутбуке откроется папка, в которой, вы увидите все файлы от игры, нам понадобится исполняемый файл игры, который отвечает за запуск игры, для этого нам нужно выбрать файл «NeedForSpeedPayback», затем не отводя курсора мыши нажать один раз правую кнопку мыши, в открывшемся меню выбрать пункт «Свойства».
После всех выполненных действий на вашем компьютере откроется окошко свойство игры, где нам нужно будет навести курсор мыши на вкладку «Подробно» и один раз нажать леву кнопку мыши, после чего у вас отобразится вся информация и описание, а в пункте «Версия файла», вы увидите версию установленной игры need for speed payback.
Обратите внимание: если вы не можете найти игру на своем компьютере или забыли место установки, а у вас присутствует ярлык игры на рабочем столе, то вы можете быстро и легко попасть в папку с игрой в два клика, для этого на рабочем столе windows наводим курсор мыши на ярлык игры и нажимаем правую кнопку мыши, после чего у вас откроется меню, в котором, нам нужно перейти по ссылке «Свойства».
В открывшемся окошке «Свойства», выбираем вкладку «Ярлык» и нажимаем на кнопку «Расположение файла», после чего на вашем экране монитора откроется папка с установленной игрой, где вы сможете выбрать отвечающий файл за загрузку игры, в открывшемся меню выбрать «свойство», в открывшемся окошке выбрать пункт «Подробно» и посмотреть версию игры.
Как побывать в корейском университете с помощью Network File System
Предисловие
Давным-давно в начале 2000-х многие развлекались тем, что регулярно «сканировали» сети своего провайдера, а иногда и более далекие цели на предмет обнаружения Windows машин и ресурсов на них (SMB), доступных на чтение (запись). Процесс поиска был примитивен: задавался диапазон IP-адресов или маска сети и посредством различных инструментов — LANguard Network Scanner, xIntruder и подобных — сканировались адреса и находились сервера. Зачастую на обнаруженных машинах оказывались доступными на чтение, реже на запись, различные сетевые ресурсы (диски, принтеры, директории). Через анонимную сессию посредством IPC$ и пользователя «Guest» удавалось перечислять ресурсы на машине, иногда находились члены «Administrators» без паролей, а иногда, после более «активного» воздействия в отношении обнаруженных машин, удавалось найти сервера с ОС Windows NT 4.0 или Windows 2000 Server. Если удача соблаговолила обнаружить машины с распространенной тогда Windows 98, то становилось проще — в те времена в указанной ОС содержалось множество разных уязвимостей, в том числе в реализации работы с SMB, брутфорс для получения доступа к ресурсу осуществлялся за считанные минуты даже на dial-up соединениях. Для желающих окунуться в старину здесь подробно написано про «доступ» к Windows 9x — Hacking Exposed: Network Security Secrets & Solutions. Chapter 4: Hacking Windows 95/98 and Me. Но далее в статье речь не об этом.
Никогда бы не подумал, что в 2019 году возможно подобное «развлечение». Подобие же заключается в легкости поиска чужих доступных ресурсов для всех любопытствующих. Далее речь пойдет не о популярном в последние 2 года тренде — поиске открытых для доступа баз данных MongoDB или Elasticsearch — а о несколько более приземленном сервисе.
Далее весь порядок действий, их этическую норму предлагаю не оценивать, отмечаю, что настоящий пост не призыв к действиям, которые возможно отнести к некоторым статьям Уголовного кодекса РФ или подобным нормам из законодательств других государств.
Network File System (NFS)
Network File System (NFS) — протокол сетевого доступа к файловым системам, позволяет подключать (монтировать) удалённые файловые системы через сеть, обеспечивает пользователям доступ к файлам, позволяет работать с этими файлами точно так же, как и с локальными.
Большинство представленных на рынке Network-attached storage (NAS), конечно же, поддерживают NFS, и предоставляют доступ к локальным ресурсам равно как и на любом сервере с операционной системой, в которой возможно развернуть службу NFS.
Настройки доступа к ресурсам сервера с какой-нибудь ОС Ubuntu и IP-адресом 192.168.1.1 содержатся в файле /etc/exports и представляют собой записи вида:
В данном случае доступ по NFS к серверу и его ресурсу /data/place1 возможен для клиентов с IP-адресами из сетей 192.168.1.0/255.255.255.0, 192.168.101.0/255.255.255.0.
В случае, если вместо IP-адресов указано * или (everyone) — то, зачастую, любой клиент может смонтировать удаленный ресурс себе в систему.
Таким образом формируется следующий сценарий: детектировать сервера с работающей службой NFS, определить доступные ресурсы на серверах, консолидировать результат в единую форму вывода, и дальше действовать по ситуации.
Что может быть на ресурсах — очевидно, что угодно:
Получение IP-адресов
В отношении обнаружения серверов со службой NFS в глобальном Интернете возможны 2 способа: самостоятельно, используя различные инструменты, и готовые сторонние результаты сканирования, базы данных и сервисы. Фактически всё сводится к получению списка IP-адресов. В локальной сети, полагаю, вариант очевиден — действовать самостоятельно.
Свидетельством функционирования сервиса NFS могут выступать открытые TCP-порты 111, 2049.
Для самостоятельного получения списка IP-адресов серверов достаточно просканировать диапазон адресов или целиком подсети на наличие указанных открытых портов. Для этого подойдет любой инструмент: nmap, masscan и так далее.
Или установить клиент Shodan(CLI), инициализировать свой API KEY к сервису и из командной строки вызвать поиск, например:
Итак, как получить списки IP-адресов устройств с действующей службой NFS – понятно.
Получение информации о доступных ресурсах службы NFS на конкретных серверах.
Для решения этой задачи массово есть множество путей: написать bash-скрипты, организовать хитрый pipeline из цепочки команд с вызовом showmount и другие варианты — кому что нравится.
Я же в своих изысканиях решил эту задачу на Python, причем двумя разными способами. Первый — с подключением посредством ssh к своему личному серверу на Ubuntu с NFS-клиентом и последующим вызовом на нем команды showmount с искомым пулом IP-адресов. Второй вариант решения — на чистом Python.
Предполагаю, что может возникнуть вопрос: почему так сложно, почему на Python?
Потому что, как и в предыдущей своей статье на Хабр, я буду использовать инструмент Lampyre, к которому 26 февраля опубликовали API, позволяющий писать на Python свои модули к платформе.
Кратко про Lampyre — программная платформа для OSINT и анализа данных с «толстым» клиентом под Windows, аналог известного и популярного инструмента для тех же целей — Maltego. Как и в Maltego, в Lampyre «из коробки» предоставляется набор запросов к различным сервисам. Запросы концептуально являются аналогами трансформаций из более известного продукта. Если чего-то не хватает, теперь возможно написать свои запросы. Запросы, поставляемые с Lampyre, исполняются на инфраструктуре платформы, написанные самостоятельно — на машине. То есть у пользователя должен быть установлен Python и все необходимые библиотеки, используемые в коде.
Я решил протестировать возможности API. Ключевой момент — в Lampyre уже есть несколько «requests» к Shodan, тем более что иметь свой API KEY от сервиса пользователю не надо. Таким образом, одним запросом можно получить списки IP-адресов с поднятым NFS сервисом, а вторым запросом, написанный мной модуль будет проверять доступные ресурсы и визуализировать результат с характеристиками ресурсов на том же графе.
Причем тут Корея
В ходе поиска из Shodan и тестирования модуля стало интересно посмотреть обстановку с качеством и количеством результатов сканирования сервисом Shodan стран Азии, как обстоят дела с незащищенными ресурсами. Выбор пал на Республику Корея, думаю нет нужды говорить о том, что Южная Корея очень технологически развитая страна, и я предположил, что в ее сетях можно найти что-нибудь интересное.
Поиск по Shodan, в Query: nfs, в Country: код Республики Kорея, kr
Результат не заставил себя долго ждать (на изображении ниже только часть общей схемы).
Все они, как это видно и на графе, и по названиям — числятся за AS1781 — Korea Advanced Institute of Science and Technology
Корейский институт передовых технологий — ведущий учебный и исследовательский университет Южной Кореи, расположенный в Тэджоне, находится на второй строчке национального рейтинга в Южной Корее. Университет стабильно входит в 5% топовых учебных заведений Южной Кореи.
Указанные IP-адреса используем как входные аргументы к написанному модулю «Explore: NFS(SSH)» и в результате:
Я быстро составил такую схему отображения результатов таблицы в граф (о схемах и принципах построения графов дальше по тексту статьи).
Результат объединения со схемой Shodan
При анализе вершин и связей графа становится очевидно на каких адресах расположен ресурс /home, доступный всем (*).
Для лучшего визуального восприятия изменим свойства объектов графа и другие настройки схемы:
Конечно же, я по очереди смонтировал часть ресурсов на один из своих серверов и стал изучать. Везде оказывалось почти одно и тоже — директории пользователей: asm, hoo, hyshin, jay, jiwon, jkhee110, jokangjin, kmh603, ksm782, lee, linus, lost+found, marvel_guest, pie, qwe, scloud, seokmin, sgim, thrlek, yoosj, ysha, zinnia7.
Я сгенерировал свой ключ, скопировал его в authorized_keys одного из пользователей и подключился к серверу по ssh на порт 2222, номер порта получил из данных от Shodan.
Пользователи, настройки сети:
Файл /etc/exports и диски:
Файл /etc/fstab и OS:
Полагаю, что это сеть какой-то кафедры для аспирантов или студентов, а на серверах производят какие-то свои вычисления, потому как там много различных исходников на Python, что-то связанное с GPU и дистрибутив Anaconda, тому прочее. Я не стал всё изучать и стал думать, что с этим всем делать, понятно, я мог «ходить» по большей части нод(может быть придумать что-нить более экзотическое), но интереса особенного у меня это не вызывало. И надумал я следующее: раз институт научный и передовой, должны быть направления по информационной безопасности. Действительно, даже целая лаборатория: Software Security Lab и ее руководитель Sang Kil Cha
Ему я и решил написать письмо, так мол и так, дозволять всем в Интернет подключать ресурсы NFS с правами чтения и записи очень опасно, видимо вам надо что-то исправить, прикрепил скриншоты и отправил.
Вскоре мне ответили, вольный перевод: спасибо, перешлём кому положено.
Thanks for letting me know! I will forward this email to someone in charge of our network and security. Best, Sang Kil
Перед публикацией настоящей статьи я решил проверить, посмотреть что изменилось:
Действительно, доступ к ресурсам разрешили только от машин во внутренней сети, но как быть с сервером 143.248.247.251. Согласно записям в таблице к ресурсам хоста в настройках NFS так и осталось *. Я набросал еще один вариант «мэпинга» таблицы в граф:
В чем изменения «мэпинга»: объекты NFS теперь «склеиваются» при 2 одинаковых атрибутах — IP и NFS path. Объект Status создается лишь тогда, когда в атрибуте Value, в который попадает содержимое колонки raw record, содержится значение «*»
И граф по таблице предстает в новом виде:
Теперь, кстати, стала отчетлива видна адресация внутренней сети, причём на сервере 143.248.247.251 также возможно редактирование содержания пользовательских директорий, файлов; в принципе — возможности остались те же самые, что и ранее.
И вот я пишу второе письмо мистеру Sang Kil Cha, с подобным первому содержанием, отмечая, что часть событий будут изложены в статье на популярном ресурсе habr.com:
Dear Sang Kil Cha, good day to you.
I decided to take a look if anything changed after my e-mail to you and indeed, the access settings have been changed. But apparently the security engineers left out the 143.248.247.251 ip address and its settings stayed the same. Please secure this ip as well so that no strangers could access it.
I’m writing an article on the subject of Information Security and I’ll be posting it at https://habr.com. This is a very popular website in Russia. The article will include a few passages on the matter of low quality of NFS access settings with a few examples of the case with your servers. I will send you the link to my article when it’s posted.
Как использовать API Lampyre и написать свой модуль
От модуля будет требоваться принимать на вход список из IP-адресов или список из подсетей в виде 192.168.0/24 — на данном этапе, необходимо будет самостоятельно в коде осуществлять валидацию корректности входных данных на причастность строк к IP-адресам, в случае подсети — преобразовать в список IP.
Далее, по замыслу концепта, осуществляется примитивная попытка разобрать значение ключа status_ip на предмет: IP-адрес, запись хоста, значения «*» или «everyone»
Согласно документации к API и пояснениях от support Lampyre.io — каждый модуль должен возвращать данные в таблицу, одну или несколько, но таблица должна быть описана в рамках API (Task headers, table header). Фактически — это основной результат работы модуля.
Таким образом, конечный результат с учетом ключей словаря будет таблицей:
В таблицу будут записываться значения (несколько модифицированные) от разбора результата исполнения команды showmount на сервере. Названия полей класса говорят сами за себя, в колонке raw record будет храниться информация о возможностях доступа к ресурсу. Такой разбор данных о ресурсах NFS можно в некотором смысле считать и OSINT-ом, информация о возможном доступе с различных IP-адресов дает какое-то представление о собственниках ресурса или адресации внутри сети ресурса. Например, IP-адрес сервера со службой NFS расположен в Украине, а IP-адрес, разрешенный на доступ — в Германии:
А если расширить изучение данного примера, то тут же находится подтверждение связи серверов не только через NFS, но и через один сертификат на адресах: 77.120.103.9, 138.201.202.135 и домен *.aniart.com.ua:
Как передавать данные в модуль и писать в таблицу:
создается собственный класс SearchDataNFS от класса Task:
В методе get_id возвращаем уникальный рандомный UUID:
В методе get_headers указываем какие таблицы будем использовать:
Метод get_enter_params будет определять вид окна ввода входных данных. Из кода очевидно, что на вход подается список строк, который позже самостоятельно будет преобразован в IP-адреса:
В методе execute происходит основное исполнение задачи:
К входным параметрам осуществляется обращение через enter_params.ips. В методе reparse_ip_hosts — происходит самостоятельно реализованная валидация строк в IP-адреса.
В функции thread_async_nfs_one_client происходит подключение к серверу с ssh (IP-адрес, логин и пароль заданы hardcode) и исполняется showmount, так как ранее указывал, результат разбирается, потом в функции reparse_result_rows он еще раз модифицируется. Важно отметить, info — список, состоящий из словарей, в каждом словаре ключи названы как поля класса NFSHeader. То есть словарь выглядит так:
Важно соблюдать типы данных в словаре, они должны быть такими же, как в описании таблицы.
Далее в цикле происходит итерация по элементам списка и их запись через метод API (result_writer.write_line) в конкретную таблицу NFSHeader.
Для более подробного описания необходимо ознакомиться с документацией.
В принципе, модуль уже готов для добавления в Lampyre.
Использование своего модуля в Lampyre
В связи с тем, что используется ssh и исполнение команды showmount, конечно же, необходимо иметь доступ к своему серверу по ssh. У меня для тестов такую роль выполняла виртуальная машина в Virtualbox c Ubuntu и установленным на ней NFS-клиентом.
Загрузка модуля в Lampyre осуществляется следующими шагами:
Обновленное окно List of requests:
Конечно необходимо учитывать и пропускную способность от своего и чужого серверов, и timeout, заданные жестко в коде модуля.
Результат получен в виде таблицы, но можно продолжить и совместить результат таблицы с графом результатов от исполнения Shodan search. Это будет несколько сложно для восприятия сначала.
Визуализация таблицы с результатом
Приступим. Есть таблица с набором колонок со значениями от исполнения модуля пользователя. Но если обратить внимание на кнопку Sсhema окна Requests – она неактивна. Потому как не задано отображение таблицы в граф и его необходимо задать.
Схема 1 (не самая лучшая)
При открытой таблице от результата модуля внизу в правом углу есть элемент интерфейса «Add creation template», нажав на который появляется окно «Creation template». В нём-то и можно задавать отображение строк таблицы в объекты графа, подробно описывать процесс в рамках статьи не буду, по ссылке на канале платформы в Youtube показано как такое осуществить, в рамках статьи я ограничусь изображениями того что должно получиться:
Важно отметить, объекты IP, Domain — имеются в Lampyre, а объекты NFS и Network – я создал. У каждого объекта есть атрибуты, в которые пользователь «мэпит» колонки таблицы. Причем, у объекта может быть несколько атрибутов, часть из которых — по которым вершины должны «склеиться» на графе — ключевые, другие — для вывода названия вершин-объектов графа, это могут одни и те же атрибуты или совсем другие. Например, для объекта NFS – созданы 2 атрибута, NFS path и Status, ключевой атрибут — NFS path. Объекту можно назначить свою иконку — кликнув на изображение объекта справа. По завершении «мэпинга» колонок в атрибуты объектов можно строить схему — упомянутая выше кнопка Schema станет активной.
Шаблон отсутствует:
Шаблон для графа по таблице составлен:
В целом такой подход к «мэпингу» значений из колонок и строк таблицы в объекты графа существует и в другом приложении — i2 (IBM i2 Analyst’s Notebook):
После визуализации графа от такого «мэпинга» становится понятно, что это не лучший вариант: видно отношение IP-адреса сервера к IP-адресам и хостам, с которых возможны доступы, и имеющиеся ресурсы NFS на сервере, но ведь к разным ресурсам возможны доступы с разных IP. Поэтому создаём другую схему (для любой таблицы можно создать множество схем).
Схема 2
Уже лучше. Всё становится на свои места — на каком сервере есть ресурсы, и с каких IP-адресов к ним возможен доступ:
Такой вариант создания шаблона схемы графа по таблице удобен лишь тогда, когда не так часто приходится работать с собственным модулем, или в случае импорта текстовых файлов (csv) в приложение. Дело в том, что созданный подобным образом «мэпинг» сохраняется лишь в рамках текущего расследования. После создания нового «расследования» модуль будет сохранен и будет исполнятся с результирующей таблицей, но схема не сохранится и её придется строить заново.
Для объединения результатов от поиска по Shodan и NFS необходимо открыть схему Shodan search, активировать кнопку add to active tab и нанести на ту же вкладку результат нашего модуля — схемы объединятся:
Код модулей для Lampyre доступен, там же вторая версия модуля без использования подключения по ssh.
Вместо заключения — коллеги, регулярно проверяйте корректность настроек своих NFS и не только.
Блог о системном администрировании. Статьи о Linux, Windows, СХД NetApp и виртуализации.
Доброго времени, читатели и гости моего блога. Очень большой перерыв между постами был, но я снова в бою ). В сегодняшней статье рассмотрю работу протокола NFS, а так же настройку сервера NFS и клиента NFS на Linux.
Введение в NFS
Если указанных строк в файле /proc/filesystems не окажется, то необходимо установить описанные ниже пакеты. Это скорее всего позволит установить зависимые модули ядра для поддержки нужных файловых систем. Если после установки пакетов, поддержка NFS не будет отображена в указанном файле, то необходимо будет перекомпилировать ядро, с включением данной функции.
История Network File System
Протокол NFS разработан компанией Sun Microsystems и имеет в своей истории 4 версии. NFSv1 была разработана в 1989 и являлась экспериментальной, работала на протоколе UDP. Версия 1 описана в RFC 1094. NFSv2 была выпущена в том же 1989 г., описывалась тем же RFC1094 и так же базировалась на протоколе UDP, при этом позволяла читать не более 2Гб из файла. NFSv3 доработана в 1995 г. и описана в RFC 1813. Основными нововведениями третьей версии стало поддержка файлов большого размера, добавлена поддержка протокола TCP и TCP-пакетов большого размера, что существенно ускорило работоспосбоность технологии. NFSv4 доработана в 2000 г. и описана в RFC 3010, в 2003 г. пересмотрена и описана в RFC 3530. Четвертая версия включила в себя улучшение производительности, поддержку различных средств аутентификации (в частности, Kerberos и LIPKEY с использованием протокола RPCSEC GSS) и списков контроля доступа (как POSIX, так и Windows-типов). NFS версии v4.1 была одобрена IESG в 2010 г., и получила номер RFC 5661. Важным нововведением версии 4.1, является спецификация pNFS — Parallel NFS, механизма параллельного доступа NFS-клиента к данным множества распределенных NFS-серверов. Наличие такого механизма в стандарте сетевой файловой системы поможет строить распределённые «облачные» («cloud») хранилища и информационные системы.
NFS сервер
Установленные пакеты в Debian запускается в следующем порядке:
То есть, сначала запускается nfs-common, затем сам сервер nfs-kernel-server. В RedHat ситуация аналогичная, за тем лишь исключением, что первый скрипт называется nfslock, а сервер называется просто nfs. Про nfs-common нам сайт debian дословно говорит следующее: общие файлы для клиента и сервера NFS, этот пакет нужно устанавливать на машину, которая будет работать в качестве клиента или сервера NFS. В пакет включены программы: lockd, statd, showmount, nfsstat, gssd и idmapd. Просмотрев содержимое скрипта запуска /etc/init.d/nfs-common можно отследить следующую последовательность работы: скрипт проверяет наличие исполняемого бинарного файла /sbin/rpc.statd, проверяет наличие в файлах /etc/default/nfs-common, /etc/fstab и /etc/exports параметров, требующих запуск демонов idmapd и gssd, запускает демона /sbin/rpc.statd, далее перед запуском /usr/sbin/rpc.idmapd и /usr/sbin/rpc.gssd проверяет наличие этих исполняемых бинарных файлов, далее для демона /usr/sbin/rpc.idmapd проверяет наличие модулей ядра sunrpc, nfs и nfsd, а так же поддержку файловой системы rpc_pipefs в ядре (то есть наличие ее в файле /proc/filesystems), если все удачно, то запускает /usr/sbin/rpc.idmapd. Дополнительно, для демона /usr/sbin/rpc.gssd проверяет модуль ядра rpcsec_gss_krb5 и запускает демон.
В NFSv4 при использовании Kerberos дополнительно запускаются демоны:
portmap и протокол RPC (Sun RPC)
Кроме указанных выше пакетов, для корректной работы NFSv2 и v3 требуется дополнительный пакет portmap (в более новых дистрибутивах заменен на переименован в rpcbind). Данный пакет обычно устанавливается автоматически с NFS как зависимый и реализует работу сервера RPС, то есть отвечает за динамическое назначение портов для некоторых служб, зарегистрированных в RPC сервере. Дословно, согласно документации — это сервер, который преобразует номера программ RPC (Remote Procedure Call) в номера портов TCP/UDP. portmap оперирует несколькими сущностями: RPC-вызовами или запросами, TCP/UDP портами, версией протокола (tcp или udp), номерами программ и версиями программ. Демон portmap запускается скриптом /etc/init.d/portmap до старта NFS-сервисов.
Работу RPC-сервера можно представить следующими шагами:
Для получения информации от RPC-сервера используется утилита rpcinfo. При указании параметров -p host программа выводит список всех зарегистрированных RPC программ на хосте host. Без указания хоста программа выведет сервисы на localhost. Пример:
Как видно, rpcinfo отображает (в столбиках слева направо) номер зарегистрированной программы, версию, протокол, порт и название. С помощью rpcinfo можно удалить регистрацию программы или получить информацию об отдельном сервисе RPC (больше опций в man rpcinfo ). Как видно, зарегистрированы демоны portmapper версии 2 на udp и tcp портах, rpc.statd версии 1 на udp и tcp портах, NFS lock manager версий 1,3,4, демон nfs сервера версии 2,3,4, а так же демон монтирования версий 1,2,3.
NFS сервер (точнее демон rpc.nfsd) получает запросы от клиента в виде UDP датаграмм на порт 2049. Несмотря на то, что NFS работает с преобразователем портов, что позволяет серверу использовать динамически назначаемые порты, UDP порт 2049 жестко закреплен за NFS в большинстве реализаций.
Работа протокола Network File System
Монтирование удаленной NFS
Процесс монтирования удаленной файловой системы NFS можно представить следующей схемой:
Описание протокола NFS при монтировании удаленного каталога:
Обмен данными между клиентом и сервером NFS
Типичный доступ к удаленной файловой системе можно описать следующей схемой:
Описание процесса обращения к файлу, расположенному на сервере NFS:
Настройка сервера NFS
Настройка сервера в целом заключается в задании локальных каталогов, разрешенных для монтирования удаленными системами в файле /etc/exports. Это действие называется экспорт иерархии каталогов. Основными источниками информации об экспортированных каталогах служат следующие файлы:
Настройка файла /etc/exports
В простейшем случае, файл /etc/exports является единственным файлом, требующим редактирования для настройки NFS-сервера. Данный файл управляет следующими аспектами:
Каждая строка файла exports имеет следующий формат:
Вот типичный пример конфигурации файла exports:
В данном примере компьютерам files и 10.0.0.1 разрешен доступ к точке экспорта /archiv1, при этом, хосту files на чтение/запись, а для хоста 10.0.0.1 и подсети 10.0.230.1/24 доступ только на чтение.
Описания хостов в /etc/exports допускается в следующем формате:
Общие опции экспорта иерархий каталогов
showmount: вывод информации о состоянии NFS
Утилита showmount запрашивает демон rpc.mountd на удалённом хосте о смонтированных файловых системах. По умолчанию выдаётся отсортированный список клиентов. Ключи:
При запуске showmount без аргументов, на консоль будет выведена информация о системах, которым разрешено монтировать локальные каталоги. Например, хост ARCHIV нам предоставляет список экспортированных каталогов с IP адресами хостов, которым разрешено монтировать указанные каталоги:
Если указать в аргументе имя хоста/IP, то будет выведена информация о данном хосте:
exportfs: управление экспортированными каталогами
Клиент NFS
Прежде чем обратиться к файлу на удалённой файловой системе клиент (ОС клиента) должен смонтировать её и получить от сервера указатель на неё. Монтирование NFS может производиться с помощью команды mount или с помощью одного из расплодившихся автоматических монтировщиков (amd, autofs, automount, supermount, superpupermount). Процесс монтирования хорошо продемонстрирована выше на иллюстрации.
На клиентах NFS никаких демонов запускать не нужно, функции клиента выполняет модуль ядра kernel/fs/nfs/nfs.ko, который используется при монтировании удаленной файловой системы. Экспортированные каталоги с сервера могут монтироваться на клиенте следующими способами:
Третий способ с autofs в данной статье я рассматривать не буду, ввиду его объемной информации. Возможно в следующих статьях будет отдельное описание.
Монтирование файловой системы Network Files System командой mount
Пример использования команды mount представлен в посте Команды управления блочными устройствами. Тут я рассмотрю пример команды mount для монтирования файловой системы NFS:
Первая команда монтирует экспортированный каталог /archiv-small на сервере archiv в локальную точку монтирования /archivs/archiv-small с опциями по умолчанию (то есть для чтения и записи). Хотя команда mount в последних дистрибутивах умеет понимать какой тип файловой системы используется и без указания типа, все же указывать параметр -t nfs желательно. Вторая команда монтирует экспортированный каталог /archiv-big на сервере archiv в локальный каталог /archivs/archiv-big с опцией только для чтения (ro). Команда mount без параметров наглядно отображает нам результат монтирования. Кроме опции только чтения (ro), возможно задать другие основные опции при монтировании NFS:
Опции, влияющие на кэширование атрибутов при монтировании NFS
Опции обработки ошибок NFS
Следующие опции управляют действиями NFS при отсутствии ответа от сервера или в случае возникновения ошибок ввода/вывода:
Автоматическое монтирование NFS при загрузке (описание файловых систем в /etc/fstab)
Описание файла /etc/fstab я затрагивал в соответствующей статье. В текущем примере я рассмотрю несколько примеров монтирования файловых систем NFS с описанием опций:
Первый пример монтирует файловую систему /archiv-small с хоста archiv в точку монтирования /archivs/archiv-small, тип файловой системы указан nfs (всегда необходимо указывать для данного типа), файловая система монтирована с опцией для чтения, записи (rw). Хост archiv подключен по быстрому локальному каналу, поэтому для повышения производительности параметр timeo уменьшен и существенно увеличены значения rsize и wsize. Поля для программ dump и fsck заданы в ноль, чтобы данные программы не использовали файловую систему, примонтированную по NFS. Второй пример монтирует файловую систему /archiv-big с хоста nfs-server. Т.к. к хосту nfs-server мы подключены по медленному соединению, параметр timeo увеличен до 5 сек (50 десятых долей сек), а так же жестко задан параметр hard, чтобы NFS продолжала перемонтировать файловую систему после большого таймаута, так же задан параметр fg, чтобы при загрузке системы и недоступности хоста nfs-server не произошло зависания.
Прежде чем сохранять изменения в /etc/fstab, обязательно попробуйте смонтировать вручную и убедитесь, что всё работает.
Повышение производительности NFS
На производительность NFS могут влиять несколько параметров, особенно при работе через медленные соединения. При работе с медленными и высоконагруженными соединениями, желательно использовать параметр hard, чтобы таймауты не привели к прекращению работы программ. Но необходимо осознавать, что если смонтировать файловую систему через NFS с параметром hard через fstab, а удаленный хост окажется недоступен, то при загрузке системы произойдет зависание.
Так же, не стоит упускать из внимания и настройки тайм-аутов. NFS ожидает ответа на пересылку данных в течении промежутка времени, указанного в опции timeo, если ответ за это время не получен, то выполняется повторная пересылка. Но на загруженных и медленных соединениях это время может быть меньше времени реакции сервера и способности каналов связи, в результате чего могут быть излишние повторные пересылки, замедляющие работу.По умолчанию, timeo равно 0,7 сек (700 миллисекунд). после неответа в течении 700 мс сервер совершит повторную пересылку и удвоит время ожидания до 1,4 сек., увеличение timeo будет продолжаться до максимального значения в 60 сек. Далее в зависимости от параметра hard/soft произойдет какое-либо действие (см.выше).
Подобрать оптимальный timeo для определенного значения передаваемого пакета (значений rsize/wsize), можно с помощью команды ping:
Как видно, при отправке пакета размером 32768 (32Kb) время его путешествия от клиента до сервера и обратно плавает в районе 1 миллисекунды. Если данное время будет зашкаливать за 200 мс, то стоит задуматься о повышении значения timeo, чтобы оно превышало значение обмена в три-четыре раза. Соответственно, данный тест желательно делать во время сильной загрузки сети
Запуск NFS и настройка Firewall
Заметка скопипсчена с блога http://bog.pp.ru/work/NFS.html, за что ему огромное спасибо.
Запуск сервера NFS, монтирования, блокировки, квотирования и статуса с «правильными» портами (для сетевого экрана)
Пример конфигурации NFS сервера и клиента
Конфигурация сервера
Если вы хотите сделать ваш разделённый NFS каталог открытым и с правом записи, вы можете использовать опцию all_squash в комбинации с опциями anonuid и anongid. Например, чтобы установить права для пользователя ‘nobody’ в группе ‘nobody’, вы можете сделать следующее:
Это также означает, что если вы хотите разрешить доступ к указанной директории, nobody.nobody должен быть владельцем разделённой директории:
Конфигурация клиента
На клиенте необходимо примонтировать удаленный каталогудобным способом, например командой mount:
Резюме
Фух. Статья завершена. Сегодня мы изучили что такое Network File System и с чем ее едят, в следующей статье попытаюсь сделать HOWTO с аутентификацией Kerberos. Надеюсь материал получился доходчивым и нужным. Буду рад Вашим дополнениям и комментариям!
Дополнительно можно почитать