Изменения в «PspoClasses/080709/01TerminalTheory»

Теория использования терминальных серверов

Разное интересное перед лекцией

(Про fontconfig и перемещаемые профили)

Относительно мыши. Есть тайное знание. Есть драйвер evdev в исках, который, вообще говоря... Вот вы покупаете мышь. У этой мыши 8 кнопок, два колеса и мохнатые уши. Драйвер evdev устроен принципиально не так, как драйвер mouse, kbd, т.к. он умеет и клавиатуру хватать. Он по поведению устройства пытается определить, что это за устройство, более того, он ходит по идентификаторам разным, ведь для usb-устройства можно получить его какой-то id. И если это мышь, то некоторые вещи у них более или менее стандартные, например перемещение, его протокол можно распознать. Дальше, вы нажали на какую-то кнопку, это будет кнопка номер 1, нажали на другую, другое событие пришло, значит это будет кнопка номер 2, и так все 8 кнопок, точнее те, которые после стандартных трёх. Единственный недостаток evdev --- ему над сказать, куда смотреть, какой девайс. Раньше проблему с устройствами решали по-другому, на уровне системы. Раньше весь input сваливали /dev/mice, дальше говорили -- у меня драйвер mouse, все остальное автоматически, работайте, иксы. Там не распознавалась ни одна кнопка. А здесь это делается независимо от системы, т.к. он садится на какой-то девайс потом с ним работает. А в случае с evdev'ом и многозадачным линуксом проблема в том, что неизвестно, какой номер usb-девайса будет у мыши, когда вы ее воткнёте, точнее, когда он ее определит. Но спасибо добрым линуксостроителям за скажем ls /dev/input/by-id.

Посмотрим /etc/X11/xorg.conf, как эта проблема решается, пока что вручную, но более или менее однозначно. При этом текстовый идентификатор возвращает само устройство, поэтому при подключении к любому порту все будет работать.

  Section "InputDevice"
        Identifier      ...
  Driver             "evdev"
  Option             "Device"
        "/dev/input/by-id/usb-A4Tech_Ps.2+USB_Mouse-event-mouse"
EndSection 

Собственно лекция

Сегодня мы посмотрим, как устроен дистрибутив ALT Linux Terminal Server, ALTSP. Это бонусный дистрибутив (по госзаказу надо было разработать три, а эти идиоты из АльтЛинукс разработали четыре). Над четвертым работала принципиально другая команда, из Киева, фактически действительно ресурсы пришлось делить на большее количество Дело в том, что команда, которая его разрабатывала, занималась внедрением подобной хрени, и у них уже было нечто пригодное для внедрения авторами в благоприятной среде. Они воспользовались открывшимся ресурсом, чтобы допилить его до дистрибутива, надо сказать работы было много. Что он себя представляет?

В документации по ALT Linux есть статья лектора ("Linux-класс за час, или X-терминалы, тонкие и ленивые"), довольно старая, еще для ALT Linux Compact 3.0. О чём там шла речь: для того, чтобы попробовать линукс, совершенно необязательно устанавливать его на компьютер. Самый простой способ сделать это --- загрузить livecd. Суть livecd очень проста --- на нём, на лазерном диске, находится готовая к эксплуатации ОС, которая при загрузке разворачивается немного в оперативке, большая часть того, что находится в оперативке, ссылается на содержимое этого лазерного диска, и начинается работа. Обычно заводится очень небольшой виртуальный диск в оперативной памяти, куда можно что-то записывать, а другой большего размера второй виртуальный диск состоит из файлов, находящихся на лазерном диске. Работа с livecd неудобна тем, что он довольно долго загружается и довольно долго работает (скорость чтения данных с CD на два порядка ниже скорости чтения данных с жесткого диска, а скорость случайного позиционирования у cd больше аж на три порядка). Это большой недостаток, если вы пытаетесь пользоваться своим компьютером после загрузки с livecd как обычным компьютером, то есть с множеством разных программ, которые запускаются и работают.

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

По сравнению со статьей, которая была написана 2 года назад чуть более правильный вариант -- это тот же самый livecd, только записанный на флешку. По сравнению с livecd существенно возрастает скорость чтения и исчезают затраты на позиционирование, т.к. это устройство прямого доступа, Кроме того, флешку можно так разметить, что часть её будет как livecd, а часть будет доступна на запись, для пользовательских данных. Недостаток liveflash в том, что флешка штука не вечная, и особенно не вечная на запись. Она выдерживает столько-то циклов перезаписи. Но лектор не видел хороших технологий для liveflash, в альте есть просто скрипт, который образ livecd записывает на флешку, после чего оно просто работает. У обеих этих технологий на сегодняшний день есть достаточный недостаток: содержимое системной области недоступно на запись, система заморожена. Теоретически с помощью unionfs можно сделать штуку, которая будет делать вид, что вся область доступна на запись, но там начнутся другие проблемы, так что сбалансированного дистрибутива на базе liveflash нет.

Ещё одна проблема в том, что если вы хотите работать на ваших машинах, и что-то на них серьёзное делать, то эти машины могут быть достаточно разноплановые по производительности, и может быть, не все программы на них можно запустить, и т. д. Можно представить себе старый компьютер, на котором этот самый livecd будет работать так плохо и так медленно, что вы даже просто не станете этим заниматься. Это как раз та самая ситуация, когда, с одной стороны, машину хочется задействовать в работе, а с другой стороны ставить на нее linux бессмысленно, или даже невозможно, но не потому что он не работает на ней, а потому что там, всего очень мало (ресурсов). Но эти компьютеры попадают в класс машин, на которых хочется пользоваться линуксом, не устанавливая его туда.

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

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

Идея состоит в следующем. Допустим, у нас есть достаточно новый компьютер, на который линукс можно и поставить, но нам не хочется нам этого делать, например, потому что там стоит купленная вместе с компьютером операционная система, от повреждения которой человек лишается гарантии, или после нас придут пользователи, которые не захотят эту операционную систему, мало ли что. А с другой стороны, можно подумать так: у нас есть операционная система, но таких компьютеров у нас 20 штук. И каждый раз, когда нам приходит в голову установить что-то или как-то изменить настройку программного обеспечения на всех этих 20 компьютерах, оно нам в голову приходит, потом мы представляем, что нам 20 раз делать одно и то же, и как-то вот оно и выходит из головы.

Было бы неплохо заставить все эти машины каким-то образом работать с одним и тем же системным пространством, условно говоря, диском. Диск им дать один на всех, какие-то мелкие различия, которые существуют, где-то там хранить. В этом случае администрирование будет намного упрощено, мы просто будем содержимое этого диска как-то модифицировать, в результате работа всех этих компьютером будет как-то изменяться. Мы доставили пакет на этот диск, любой из 20 компьютеров загрузился с использованием этого диска как системного, и там этот пакет есть.

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

В случае, когда мы не хотим устанавливать линукс на компьютере, но хотим его использовать:

Вначале рассмотрим для новых компьютеров. Мы могли бы использовать livecd или liveflash, но есть дополнительные ограничения:

• мы не хотим мириться с тем, что livecd медленно работает и трудно организовать записываемую часть
• мы хотим изменять системную часть централизованно для 20 компьютеров

Тогда можно поступить так. Жесткий диск, как в случае с livecd или liveflash, не используется вообще, а используется технология загрузки по сети.

Есть специальные методы загрузить какую-то небольшую программу через сеть с сервера, которая загрузит большую программу, которая уже всё делает (она, собственно может являться ядром линукс, или, в нашем случае, небольшим дистрибутивом initrd).

После чего в случае толстого клиента будет происходить вот что: загруженный по сети специально подготовленный линукс будет рассчитывать, что та часть, которая раньше лежала по livecd, которая лежит на специальном файловом сервере в сети. То есть, отличие live-технологий от толстого клиента минимальное. Состоит оно в том, из какого места подключается носитель с основным корпусом программного обеспечения, в случае livecd, этот то же самый сидюк, с которого происходила загрузка компьютера (bios, все дела), в случае толстого терминального клиента это специальный файловый сервер, прописанный в настройках этого терминального клиента, на котором, собственно, лежит этот корпус.

Причём здесь возможна следующая ситуация: берёте livecd, его содержимое перекладываете на сервер, а потом монтируете также как монтировали при загрузке с него локально, с той лишь разницей, что во втором случае он будет смонтирован через NFS. Ещё один извращённый вариант, если у вас очень много памяти, вы можете положить образ на http. Клиент его скачает, положит в память, смонтирует, и будет работать. Много качать при каждой загрузке. Но если гигабитная сеть... Отличие этого варианта состоит в том, что используется соответственно больше памяти, потому что он монтируется не через сеть (например посредством NFS), а прямо в памяти размещается целиком.

(Здесь из зала была высказана идея о загрузке, размещении чего-то в памяти, после чего выяснилось, что и линукс и BSD так работают уже давно. Сама идея, к сожалению, неразборчива. Авторы, впишите пару строк --PavelSutyrin)

Получается в результате у нас компьютер, жёсткий диск которого вообще не используется, процедура загрузки выбирается сетевая, весь корпус программного обеспечения в виде сетевого носителя подключается с специально подготовленного сервера, как и вся процедура загрузки, которая не вполне простая, также на этом сервере находится, даже это могут быть два разных сервера, хотя когда один, то удобнее. (dhcp и т.п -- на одном сервере, а nfs -- на другом). Получается машина, которая потребляет больше ресурсов, чем если бы линукс был установлен на ее жесткий диск, как минимум больше ресурсов располагается в оперативной памяти непосредственно, более того, если мы даем себе зарок вообще не использовать жесткий диск, в такой машине не будет того, что называется область подкачки, swap. (swap по сети -- это смерть на взлёте, хотя такое тоже делается, в частности в altsp есть, там по другой причине, он там редко используется)

Если мы скачали образ с сервера и разместили его целиком в оперативной памяти, то это, несмотря на то, что жрёт много памяти, дает преимущества:

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

Это у нас получился толстый терминальный клиент. Обратите внимание, что это просто продолжение технологий livecd, просто вынесенное на сеть.

Теперь мы переходим на этаж ниже в таблице, и находим там старые компьютеры, установка линукс на которые возможна была бы, если бы ни одно прискорбное но, мы туда поставим линукс, мы там сможем, наверное, поставить, но ставится он будет долго и работать слабо. Что запустишь на компьютере с 64 MB RAM?..

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

(Я где-то читал одним глазом, что в случае, когда клиент и сервер оба на одной машине, они не обязательно будут все гонять по TCP-сокетам, а найдут друг друга и воспользуются, например, shared memory. --PavelSutyrin)

Получаем такую табличку со столбцами: где идет работа с устройствами ввода-вывода, где работают программы (задачи), где хранятся файлы.

При этом, чтобы не запутаться: на станции запускается X-сервер, а на сервере -- X-клиент, это понятно.

Какие нас ждут неприятности? По сути никаких. В той же статье про тонкие клиенты лектор показывал, как одной командой из n+1 livecd делать сеть из n клиентов и 1 сервера. Нужно чтобы сервер разрешал подсоединяться к ему по сети и использовать его программы, клиент --- разрешал подсоединяться к его X-серверу и работать с устройствами ввода-вывода. Это сделать легко.

В этом нам помогает тот факт, что графический логин, который мы видим на машине, где портреты пользователей, логины и пароли, это не только логин, это достаточно сложная программа, которая в том числе, может сделать следующее:

                         (1: xdm0 по сети протоколом xdmcp находит xdm1,
                             который себя там анонсирует)
 ..................................       ..............................
                                   :      :
 X-сервер xorg0 <------> xdm0 -----------------------------> xdm1
  | |    |                |        :      :                  / |
  | |    |                | (0: xdm0 умеет запустить kde0)  /  | (3: xdm1 запускает kde1)
  | |    |                v        :      :                /   |
  | |    \               kde0      :      :               /   kde1
  | |     ------------------------------------------------
  | |                              :      :
  | |       (2: xdm1 подключается по сети к xorg0 как x-client)
  | |                              :      :
  | (экран)                        :      :
  (мышка)                          :      :
                                   :      :
                                   :      :
                                   :      :
  машина0                          :-сеть-:         машина1
....................................      ...................................
       |
  (пользователь)

На машине0 запущен X-сервер xorg0, работающий с мышкой и экраном, за которым сидит пользователь. К xorg0 как X-клиент подключен display manager xdm0, который умеет после авторизации пользователя запустить, например, kde0, и перекинуть ему свое соединение с xorg0. Но пользователь может попросить xdm0 сходить в сеть и найти там другой, проанонсированный display manager xdm1, чтобы xdm0 перекинул своё соединение с xorg0 ему. X-протокол позволяет сделать это по сети. Затем xdm1 может точно также запустить kde1, уже на машине1, и пользователь будет работать с kde1.

Тут может быть ещё отдельный сервер приложений, который об этом говорит. Мы получили, что на работающей станции работает две программы: Xorg и XDM. Результатом становится то, что в табличке: все задачи запускаются не на рабочей станции (машина0), а на сервере (машина1).

starvm altsp...

История. Есть такой довольно исторически довольно давний проект --- LTSP (Linux Terminal Server Project. Без буквы A в начале). У него была довольно активная команда разработчиков, не то в Иркутске, не то в Н-ске, т.е. в Новосибирске. Суть проекта состояла в том чтобы поставить такую технологию (см. диаграмму), на дистрибутивные рельсы, чтобы не нужно было руками все эти сервис настраивать, а чтобы можно было более или менее автоматизировать этот процесс.

Начинался этот LTSP ещё на ядре 2.2, то есть это было давно. И в те поры ничего, кроме как вносить собственные изменения в ядро, чтобы кое-что там автоматически определялось, и т.д., а с другой стороны выкладывать в качестве специализированного образа...

В те поры задача могла быть поставлена на дистрибутивные рельсы единственным способом: с одной стороны, нужно было собирать два разных ядра, одно для сервера, другое для клиента, особенно для клиента оно должно было быть сильно изменено, чтобы происходило автоматическое определение железа и потом эту информацию об этом железе передать на сервер. Необходимо было поскольку там надо было много чего делать автоматом. Второе --- организовать достаточно развесистую инфраструктуру по приёму этой информации, адаптации соответствующих настоечных файлах, и т.д. Третье --- все это нужно было складывать в один специальный дистрибутив, которые не устанавливался на машину, а подкладывался на специально подготовленный сервер.

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

Сведения о ресурсах

CategoryLectures CategoryPspo CategoryMpgu CategoryUneex