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

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

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

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

Посмотрим /etc/X11/xorg.conf, как эта проблема решается.

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

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

Сегодня мы посмотрим, как устроен дистрибутив ALT Linux Terminal Server. Это бонусный дистрибутив (по программе надо было разработать три, а разработали четыре). Дело в том, что команда, которая его разрабатывала, занималась внедернием подобной хрени, и у них уже было нечто пригодное для благоприятного внедрения. Они воспользовались открывшимся ресурсом, чтобы допилить его до дистр. сстояния. Что он себя представляет? В документации по ALT Linux была статья лектора про терминальные клиенты. О чём там шла речь: для того, чтобы попробовать линукс, совершенн необязательно уст. ег на компьютер. Самый простой способ сделать эт не устанавливая --- исполоьзовать livecd. Суть livecd очень прста --- на нём находится готовая ОС, которая при загрузке разворачивается немного в оперативке, большая часть там ссылается на диск и начинается работа. бычно заводится виртуальный диск, куда можно немножк записывать, втрой вирт. диск со всеми файлами. Работа с livecd неудобна тем, что он довольно долг загружается и работает (скорость случайнго позиционирования у cd больше на три порядка). Существует специальные технологии размещения файлов на диске так, чтобы головки дёргались меньще, но это всё так. Другой вариант --- запись на флешку. Тут лучше с скоростью и нет позицинаирования. Кроме того, её можно разметить так, что часть будет под польз. данные. Но проблема в количестве циклов записи. Ещё один недостаток --- систему пишут один раз и после этого её не поменяешь. У liveflash можно с исп. unionfs обойти эту прблему, но пока это до ума никто не довёл.

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

Идея сост. в следующем. Есть достаточно новый компьютер, на который инукс поставить не очень получается. С другой стороны, может быть так: у нас есть ОС, но компьютеров 20 штук, и при каждой необходимости переставить систему сталкиваешься с проблемой их количества. Решением может быть работа в едином системном пространстве, каике-то мелкие различия где-т там хранить, и в таком случае администрирование будет упрощено: поставил пакет один раз и все 20 его подцепили. Про эт лектор рассказывал в Переславле. Вкратце, технология толстых клиентов состоит в следующем: у нас есть два вида ресурсов --- оперативная память и дисковые устройства. ЖЁсткий диск не исп. вообще, а используется технология загрузки по сети. Есть специальные методы загрузить какую-то небольш. программу через сеть с сервера, потом загрузить большую программу, которая уже всё делает (она, собственно и будет являться линуксом). В этом случае будет происх. вот что: загруженный таким образом линукс будет расчитывать, что все файлы лежат не на ливсиди или флеш, а в сети. Причём здесь возм. следующая ситуация: берёте livecd, переклаыдваете его на сервер, и отдаёте его. Ещё один извращённый вариант --- загружать весь образ целиком в память. Получается в результате кмпьютер, жёсткий диск которог не исп. процедура загрузки --- сетевая, весь корпус ПО подкл. с удалённого сервера, весь процесс загрузки тоже на сервере. Это требует некоторых телодвижений со стороны щагр. сервера, о которых мы поговорим. Получается машина, которая потр. блоьше ресурсов, чем та, у которой линукс установлен. Кроме того, использьвоать своп не получится. Но работать это в случае образа в памяти будет существенно быстрее.

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

Получаем такую табличку:

В/В

задачи

файлы

толстый клиент

станция

станция

сервер

тонкий клиент

станция

сервер

сервер

Это рабтает из того, что сервер может работать по сети. Какие нас ждут неприятнсти? Да никаких. В той же статье про клиенты лектор показывал, как сделать из n+1 livecd делать сеть из n клиентов и 1 сервера. В этом нас помогает тот факт, что графический логин, который мы видим на машине, эт не только логин, это достаточно сложная программа, которая может сделать следующее: вот рабочая станция запущена и вот запущен дисковый менеджер, вот вторая такая машина. Пользователь обращается к первой, но польз. может сказать, а ну-ка поищи, не предлагает ли кто в сети подключиться по сети к нему (по xdmcp). И если такой есть, то он сначала связывается с соотв. сервером, после чего вот рашаривший дисплей менеджер работает в качестве клиента и отображается на запрсившей станции. После логининга он перекидывает соединение другому клиенту (kde). Тут мжет быть ещё тдельный сервер приложений, который об этом говорит. Мы получили, что на работающей станции работает две программы: Xorg и XDM. Результатом становится то, что в табличке: все задачи забускаются не на станции, а на машине.

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