В прошлый раз говорили о том, что сама ос может предоставять решения коего каких из комплекса задач прикладного уровня.

Мы помним, что по фантазии лектора каждый из 5 уровней состоит из 2 подуровней. Для прикладного уровня это связывание потоков данных с интерпретаторами. Можно это не делать, а можно сделать метадемон inetd, которй бы сам активировал нужные демоны.

Когда нужна и активация по сокету, и работа демона с сокетом, это решается новомдными системами запуска типа systemd.

Сегодня обсудим веши прикладного уровня, без которых компьютер работать не будет.

Чего не хватает в нашем супе? Можем ли мы с помощью перечисленного пользоваться интернетом? Ответ нет нельзя, потому что мы ничего не говории о днс.

Если у нас компьютеров в сети 12 штук, мы можем взять и запомнить 12 адресов.

Если у нас компьютеров 100, запомнить все сложно, но можем сделать специальный файл /etc/hosts со строчками вида адрес - имя. И положить этот файл на 100 компьютеров.

Чем наличие второго слоя именования усложнило задачу? Ваша программа не обязана знать про файл с соответствиями.

В программном смысле все должны использовать libresolve чтобы пользоваться вместо адресов именами.

Какой бонус? На прикладном уровне адресация отвязана от уровня сетевого. Когда вы пишите uneex.ru или uneex.org -- они соответствуют одному и тому же ип-адресу.

Преобразование имен преврашается в технический инструмент, упрощающий написание прикладных программ.

В чем недостаток файла?

  1. Сам компьютер хочет решать какое у него имя. Брезжит проблема, которая заключается в следующем -- никто не может единолично написать всех адресов и имен в интернете, потому что решения об именовании принимается многими людьми -- администраторами. Решением проблемы является анонсирование. Анонсирование очень древний прием -- аппл ток, и прочие. Многие протоколы, особенно в локальной сети, имели возможность анонсирования.
    1. Её никто не может раздать по всем компьютерам, она слишком быстро меняется.
    В чем недостатки анонсирования?
    1. Нужен какой-то порядок анонсирование.
    2. Если компьютеров слишком много, вместо анонсирования вы получите флуд.
    Надо вводить систему, которая обеспечивала бы адекватное превращение имен в адреса. Она должна быть распределенная и привязка адресов к имени должна управлятся со стороны администраторов, а не большого дяди. С другой стороны как же без большого дяди.

На волне этого возникла DNS.

Какие проблемы мы должны решать?

  1. децентрализация, потому что никто не знает всех имен
  2. централизация -- должно быть место, куда вы идете, чтобы узнать ответ на вопросы.

Решением является распределенная иерархия.

Именно с этим связано понятие домена. Что это такое? Это из феодальных времен. Когда люди уже стали жить достаточно хорошо, и рабов стали использовать как людей, но необходимость вертикальной власти все еще сохранялась, изобрели такой строй -- есть лендлорд, он хозяин земли, у него есть крестьяне, которые пользуются землей (как мы пользуемся некоторыми лицензионными продуктами). Чтобы управлять конгломератом должен быть еще один человек, который хозяин. Хозяин хозяев король, хозяин королей бог. Там еще очень весело деньги перераспределялись.

Конгломераты назывались доменами. Отношения назывались отношениями вассала и сюзерена.

Чтобы разделить имена никаких технических инструментов не надо.

Когда государство берет на себя функции раздачи имен более мелким пользователям, оно делает так -- организует несколько больших доменов. А дальше некоторая большая организация говорит -- хочу получить поддомен msu.ru. государство говорит ок, но внутри себя будешь отвечать само.

Когда хочется понять, какой домен, идется сначала к корневому днс. Если оно не знает адрес, то оно спрашивает, где сервер имен для msu.ru.

Строгое административное разделение соблюдается, поэтому цепочки могут строиться практически до бесконечности.

Конечно, с любым адресом к корневым серверам не ходят. Полную такую процедуру должны мочь делать не все.Каждому дается ип-адрес локального днс-сервера.

Запросы делятся на рекурсивные и нерекурсивные, и большинство запросов становится нерекурсивными.

Есть у записи в базе данных такая штука, как время жизни. Сервер запоминает табличку ровно на это время.

Есть еще значение expire. Нейм-сервер может быть недоступен. Вам ответят из кэша, пока запись не проэкспайрится.

Скорее всего днс-сервер недоступен не потому что он взорвался, а потому что нарушена связность -- полчища крыс перегрызли все кабели между германией и швейцарией.

При регистрации на себя доменного имени от вам требуют не менее двух неймсерверов для ващего домена, причем они должны лежать в разных сетях класса Б. Это в некоторых случаях будет гарантировать, что они не станут недоступны одновременно.

Упомяну, что эти 2-3-4 неймсервера у зоны не могут быть равноправными. Вы добавляете руками хост сначала в одну. Получается одна главная, другие неглавные.

Как получать обновления? Сушествует куча протоколов для поддержания актуальности реплик. Такая ситуация у бинд. На самом верху там все хитрее.

Два-три авторитетных нейм-сервера, каждый из которых отвечает за весь домен, эти все сервера равноправны кроме главного, который занимается обновлением базы.

Итак у нас получается достаточно забавная распределенная база данных, которая хранит в себе распределенное преобразование доменных имен в адреса. Запись типа а рассказывает адрес. Запись типа ns преобразует доменное имя в адрес или доменное имя неймсерверов соответствующего домена. Запись типа mx рассказывает куда посылать почту. cname -- когда у вас несколько имен у одной машины -- алиасы на какое-то центральное имя.

SOA -- относится к блоку имен, и там указаны много разных числовых характеристик.

Отдельный интерес представляют SRV и TXT.

TXT позволяет хранить в днсе все. Зачем? Удобная же вешь распределенная база данных.

Зачем нужна SRV? Мы с вами почти сделали структуру для хождения по интернету. Есть еще некие ограничения -- обычно, например, рекурсивные запросы только для своих клиентов.

Задача анонса еще не решена.

Мы хотим анонсировать разное -- например принтер или файловую помойку.

Анонсирование сетевых служб это большая подзадача настройки сетевого окружения.

Можно делать это с помощью днса, введя туда специальный тип записей SRV. Правда придется научить днс-сервер менять таблицу по запросу. Возникает много проблем с безопасностью. Протокол называется DynDNS.

Запись типа срв позволяет анонсировать через днс некоторые службы.

У имени чем ближе к началу, тем конкретнее, у адреса наоборот.

По этой причину нейм-сервер который занимает бэкрезолвом хранит октеты ип-адреса в обратном порядке.

В чем недостаток анонса через днс? Юзабилити версус секьюрити.

Хотелось бы чтобы каждый мог анонсировать что хотел, но это бы согласвывалось с анонсированным товарищами.

Что еще бывает в автоматической настройке? Например присвоить ип-адрес, если его никто не выдает. Самонастройки и их анонс.

По результатам самонастройки можно выяснять чужие настройки. Локальный днс по результатам анонса.

Ну и собственно анонсирование служб как таковых.

Раньще особенно виндоус постоянно устраивали перевыборы космонавтов и всякое такое.

zeroconf и его реализация avahi значительно проще.

Авахи реализует зероконф как таковой, малтикаст днс, анонсировать и просматривать службы.

Что будет у вас на машине? Демон на порту 5353 и мултикаст.

У вас будет авахи демон, avahi browse. у него есть прекрасный ключик -t, terminate. Когда вы говорите browse было бы хорошо, чтобы он когда-нибудь перестал смотреть. Но учитывая, что никто не знает что соседи заанонсировали, надо уметь его останавливать.

Есть возможность самому анонсировать доступность служб с помощью avahii publish, либо если это какой-то системный анонс, то вы тогда делаете описаолов, которое при старте он его съедает и все описатели анонсирует. Конкретные примеры на странице лекции.

К этому надо пришпандорить два замечания. Что не хватает? Не хватает главного, что означают волшебные буквы, вывещивающияся в анонсе.

Смысл анонсируемых служб авахи совершенно недоступен, он анонсирует просто строку. Из того что установлен авахи не следует, что все зашевелится. Те компоненты, которые захотят вопспользоваться, должны понимать, как анонсировать и как понимать анонсированное.

Пока прикладной софт не научиься пользоваться анонсами, ничего само не заработает.

Второе замечание про все в целом.

libresolve управляется nsswitch.conf -- управление работой с пространствами имен. Именно в нем указывается, как будут обрабатываться преобразования.

NFS

Network File system

Какие можно вообразить проблемы при создании сетевой фс?

Когда возникла необходимость хранить данные в сети?

Тогда сети быти тухлые и хотелось минимизировать и ускорить ходяший по ним трафик.

Протоко работает по udp или по tcp,

Разрабатывался SUN, когда та ещё занималась RPC. Он построен на нем весь. Напоминаю, что это такой способ динамического анонсирования доступных портов.

Будем считать, что порт 2049.

Забота о быстродействии привела создателей nfs к идее создания фс без сохранения состояний. Идемпотентный протокол. Можете взять и послать на нфс сервер несколько датаграмм, открывающих файл, и никто ругаться на это не будет.

В этом смысле UDP особенно удобен для реализация Идемпотентных функций. Одна операция -- одна датаграмма.

Значительно снижается нагрузка на сеть, по сети гуляют только датаграммы с пользовательскими данными.

Помимо этого есть несколько недостатков. Несколько компьютеров открывают файл и начинают писать. Кто последний записал, того и тапки.

Зато такой фс можно пользоваться как обычной фс с помощью mount и unmount

Есть команда showmount -e

Файлик /etc/exports

Помимо нфс есть пресловутый цифс.

mount проводится от рута, а доступ на запись получает пользователь. На каком основании разрешать или не разрешать монтировать? На основе ип в файла экспортсс.

Если специально не прицелиться в ногу, то от рута в нфс записать не получится, зато от любого другого пользователя вполне.

Что касается самбы.

Помимо того, что это протокол для передачи всего. common internet file service, которая ничего из этого. Это не ip-based аутентификация, а user-base. Чтобы там что то делать, нужны логин и пароль.

nfs4 правда умеет работать по керберосу, но для этого керберос надо ещё сначала настроить.

В домашнем задании будет autofs. Это пример того как можно воспользоваться анонсом серверов через авахи и через днс.

LecturesCMC/LinuxNetwork2013/Conspects/08 (last edited 2013-11-19 08:02:31 by Allena)