Поднятие терминального сервера на примере LTSP и CentOS 5.4

    Интро


    Сейчас стала очень популярна идея использования тонких клиентов, а в частности – для организации учебных классов в ВУЗах и не только. Вот и для моего любимого ВУЗа пришлось потрудиться.
    Не так давно мне была поставлена задача выбора и настройки терминального сервера на CentOS 5.4. Почему именно CentOS – ума не приложу, но скорее всего это было предпочтение наших системных администраторов, которые в последствии будут поддерживать терминальный сервер. Ну а мне выбирать права предоставлено не было.

    Задача для меня была новой, показалась довольно интересной, и с первого взгляда не тривиальной. Изучив много информации, которую мне поведал Google мой выбор пал на LTSP (Linux Terminal Server Project). Данное программное обеспечение использует протокол XDMCP для аутентификации между Х-сервером и Х-клиентом, а так же проект xrdp, который позволяет терминальным клиентам (тонким клиентам) подключаться как к *NIX системам, так и к Windows.

    Существует множество дистрибутивов, в которых уже используется данное ПО и которые были специально созданы для терминальных серверов, такие как K12LTSP и Skolelinux. А так же данное решение поставляется и с альтернативным диском Ubuntu.
    В моем же случае все немного усложнялось тем, что готовых решений под CentOS не существует, в репозиториях данные пакеты так же не располагаются. При настройке и установке наступал на некоторые грабли, решение которых отнимало не мало времени. Поискав возможные решения по установке LTSP на любимом Хабре я ничего не нашел, по этому и родилась идея написать статью.

    Надеюсь что данная информация кому-либо пригодиться и постараюсь как можно подробнее описать процесс установки и настройки.

    Как это все работает?


    Думаю тут много рассказывать не нужно. Тонкие клиенты обычно являются сами по себе бездисковые станции. При включении они пытаются загрузиться с помощью сетевой карты используя PXE. Т.к. PXE ограничивает размер загрузчика 32 килобайтами – используется двухстадийная загрузка, когда первый загрузчик получает и запускает вторичный, который уже получает и запускает образ операционной системы. После чего загружается ядро ОС, созданное LTSP, которое монтирует через NFS файловую систему, хранящуюся на терминальном сервере и запускает терминальный клиент, который подключается к терминальному серверу.
    Итогом всего вышеописанного должен получиться сервер, на котором подняты DHCP, TFTP, NFS, а так же сам терминальный сервер.

    И так приступим


    Первое, что мне необходимо было сделать – установить CentOS 5.4 x86_64. Хочу оговорить сразу, что с CentOS’ом опыт работы у меня невелик. По чему-то так сложилось, что всю линейку RedHat и основанные на ней дистрибутивы я недолюбливаю. В качестве графической оболочки я отдал предпочтение KDE (ну недолюбливаю я Gnome и все тут), хотя потом я об этом немного пожалел, т.к. возник ряд проблем именно с KDE и CentOS’ом.

    Первым делом идем на сайт и качаем образ диска c пакетами LTSP (http://ltsp.mirrors.tds.net/pub/ltsp/isos/). Я выбрал версию 4.1.1, т.к. навороты более новых версий (такие как сессии через ssh и прочее мне были не нужны). Далее монтируем этот образ и устанавливаем пакет ltsp-utils.0.11-o.noarch.rpm

    #rpm –i ltsp-utils.0.11-o.noarch.rpm


    После чего мы получаем утилиты командной строки ltspadmin и ltspcfg. Первая утилита используется для настройки установки и самой установки LTSP, вторая – для конфигурации уже установленного терминального сервера. Запускаем утилиту ltspadmin.

    image

    Первым делом нам необходимо сконфигурировать установщик, соответственно мы выбираем пункт меню Configure the installer options. Первым вопросом нам предлагается определить откуда мы будем получать пакеты. Можно использовать сайт самого проекта, но разумнее указать путь к смонтированному нами образу. В моем случае это file:///media/CDROM/. Обратите внимание, что в пути используется именно 3 слеша, на что указывается и в документации по установке.

    image

    Следующий вопрос – путь куда будет установлен LTSP. По умолчанию он указывает на /opt/ltsp. Его изменять я не вижу смысла. Если же вы указали в качестве пути к местоположению пакетом http адрес (который задан по умолчанию) тогда вам необходимо указать адрес http (или же ftp, если пакеты лежат на ftp) прокси-сервера. В конце подтверждаем правильность настроек и нас возвращает к предыдущему пункту меню. Теперь мы можем приступать к установке терминального сервера.

    После установки мы будем иметь:
    • пакеты LTSP в папке /opt/ltsp
    • файлы, необходимые для загрузки PXE клиентов в папке /tftpboot/lts/


    Установка DHCP и TFTP серверов.


    Для загрузки по сети наших тонких клиентов нам необходимы DHCP и ТFTP сервера. TFTP сервера в дистрибутиве CentOS я не нашел, а DHCP решил поставить вручную – так надежнее. Соответственно устанавливаем их:

    # yum install dhcp.x86_64 tftp-server.x86-64


    Далее необходимо открыть 69 порт для UDP протокола в фаерволе нашего терминального сервера. Для этого используем консольную утилиту system-config-securitylevel-tui. Жмем кнопку «Уточнить» и настраиваем правила нашего firewall’a

    image

    В моем случае у меня на сервере 2 интерфейса: один смотрит в сеть классов – второй является managment-интерфейсом. Выбираем интерфейс, через который наши тонкие клиенты будут стучаться к tftp-серверу и добавляем его к доверенным, а так же открываем для него 69 порт.

    Конфигурация LTSP


    Для конфигурации мы можем воспользоваться пунктом меню Configure LTSP утилиты ltspadmin или же напрямую вызвать ltspcfg. В появившемся меню выбираем ручную настройку:

    image

    Проходимся по всем 11 пунктам. Пункт 8 можно в принципе пропустить. После завершения — у нас будут настроено практически все необходимое.
    Стоит уделить внимание пунктам 3 и 7. В пункте 3 будет создан файл примера конфигурации DHCP сервера (/etc/dhcpd.conf.sample), который необходимо отредактировать. После изменений – у меня он приобрел следующий вид:

    #
    # Sample configuration file for ISC dhcpd
    #
    # Make changes to this file and copy it to /etc/dhcpd.conf.sample
    #

    ddns-update-style none;
    default-lease-time 21600;
    max-lease-time 21600;

    #option domain-name "ltsp"; # <--Fix this domain name

    option option-128 code 128 = string;
    option option-129 code 129 = text;

    subnet 192.168.130.0 netmask 255.255.255.0 {
    use-host-decl-names on;
    option log-servers 192.168.130.254;
    range dynamic-bootp 192.168.130.1 192.168.130.253; ## пул адресов.
    option root-path "192.168.130.254:/opt/ltsp/i386"; ##опция ядру где находиться файловая система.
    option broadcast-address 192.168.130.255;
    option routers 192.168.130.254;
    option subnet-mask 255.255.255.0;
    if substring (option vendor-class-identifier, 0, 9) = "PXEClient" ##указываем что передавать в кач-ве загрузчика для PXE клиентов
    {
    filename "lts/2.6.9-ltsp-3/pxelinux.0"; ##в CentOS tftp обычно запущен с опцией -s, поэтому полный путь от корня указывать не нужно. полный путь должен выглядеть как /tftpboot/lts/.....
    }
    next-server 192.168.130.254; ## <- Обязательно указать. В противном случае загрузочный образ не получит конфиг!
    }


    Хочу обратить внимание на то, что в путь к PXE загрузчику указывается не полный, т.к. в RedHat и CentOS он запускается с ключем –s, соответственно папку tftp-сервера в пути мы опускаем. Так же возникла проблема с тем, что по-идее опцию next-server необходимо указывать только тогда, когда DHCP и TFTP сервера находятся на разных серверах. Но без этой опции загрузка глохла, пока я не продублировал самого себя в качестве next-server’a.

    На этом этапе я обрадовался, что настройка завершена и попытался загрузиться с тонкого клиента. Но не тут то было! В итоге запускались Иксы, но подключения к терминальному серверу не происходило. Как оказалось стандартным менеджером сеансов в CentOS являеться gdm (Gnome), а так как Gnome у меня вообще отсутствовал – kdm даже и не пробовал запускаться. Для того, что бы ОСь использовала kdm необходимо внести некоторые изменения в файл конфигурации, а именно - /etc/sysconfig/desktop (если файл отсутствует – его необходимо создать):

    DISPLAYMANAGER="KDE"


    Следующим огорчением было то, что при запуске иксов на терминальном клиенте – они падали, т.к. сервер тупо отвергал любые попытки открыть удаленные сеансы. Изменить это не проблема, проблемой для меня стало то, что я не мог найти стандартных файлов конфигурации KDE. В CentOS они «спрятаны» совершенно в другом месте. В итоге его местоположение можно определить следующим образом:

    # locate Xaccess


    Далее в указанном файле ищем строчку

    #* #any host can get a login window


    И раскомментируем ее. Перезапускаем Иксы, бутаем наш тонкий клиент – и вуаля! Все работает!

    Выводы


    В итоге мы получили компьютерный класс, основанный на использовании тонких клиентов. Об их преимуществах рассказывать не стоит. По заявлениям общая рекомендация всегда была такой: 256 МБ оперативной памяти на сам сервер плюс 60 МБ на каждого подключенного клиента (иногда советуют выделять по 100 МБ на терминал). Так как все программы выполняются на сервере, не помешает иметь запас вычислительной мощности: особенно хорошо подойдет двухядерная или двухпроцессорная система. При работе со множеством клиентов неплохо бы использовать 64-битный процессор, не только из-за дополнительной производительности, но и потому, что он может работать с большим количеством памяти, что часто является наиболее важным фактором, ограничивающим производительность. Как это все будет работать в действительности – еще не известно. Если эта тема будет кому-либо интересна, то о результатах напишу в следующем посте

    Ссылки по теме



    http://subhodip.fedorapeople.org/ltsp_in_fedora8.pdf
    http://edin.no-ip.com/content/ltsp-ubuntu-intrepid-mini-howto
    http://www.ltsp.org.ru/files/OnlineDocs/ltsp-3.0-ru/chapter6.html
    http://www.owlriver.com/tips/gdm-setup/remotexkdm.html
    http://sourceforge.net/apps/mediawiki/ltsp/index.php?title=Ltsp_Documentation
    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 28

      –3
      откуда скрины? это CentOS? в нем кеды по умолчанию?
      всегда хотел увидить эту ОС
      у нас с коллегами только ssh-доступ, а сервера в Чикаго, мы никогда не увидим какой там интерфейс, а так интересно)
        0
        X over SSH и в путь
          0
          да, CentOS. По умолчанию ставиться Гном, но как я писал — Гном я просто не перевариваю) Не срослось мое с ним знакомство…
            –2
            VNC + SSH port forwarding уже не торт?
              0
              Возможно я ошибаюсь, но как вы собираетесь реализовать терминальный сервер через VNC и SSH порт форвардинг? В лучшем случае вы получите защищенный удаленный сеанс. Я имею ввиду, что VNCServer не является менеджером сеансов и новый сеанс вам запустить не удастся. Для локальной сети в учебных классах использовать ssh я смысла не вижу. Из других возможных альтернатив — X11vnc и nx, если не изменяет память.

              По сути можно было бы и самому собрать ядро для тонких клиентов с минимальным необходимым набором софта, но зачем изобретать велосипед?
                –2
                Это ответ на
                всегда хотел увидить эту ОС
                у нас с коллегами только ssh-доступ, а сервера в Чикаго, мы никогда не увидим какой там интерфейс, а так интересно)
            0
            Спасибо за статью, меня давно мучила родственница которая работает учителем информатики, и у неё половина компьютерного класса мягко сказать старовата, а со след года вводят СПО в школы, и будет интересно опробовать статью.
              +3
              Вопросы:

              1) доступ к флешкам в сессии (каким образом реализован?)
              2) звук
              3) Печать на локальные принтеры.
                0
                Вот по поводу локальных принтеров присоединяюсь к вопросу, без этого в офисе никак.
                  0
                  Звук работает точно.
                    0
                    каким образом, не расскажите?
                    0
                    1) Доступ к флешам клиентов я еще не проверял. Но видел на хабре статью о такой настройке. Нужно будет попробовать и проверить.
                    2) По поводу звука — я устанавливал на сервер пакет Ричарда Джоуна (rpm , tar)
                    3) По поводу печати на локальные принтеры — необходимости не было. Но можно будет протестировать, т.к. в документации к LTSP заявлено, что такая возможность есть.

                    Если данная тема действительно вас заинтересовала — то со временем напишу статью, в которой постараюсь ответить на все интересующие вас вопросы, а так же те, которые в ходе внедрения данного решения возникнут у меня.
                      0
                      Если честно, уже не очень (остатки интереса со старой работы).

                      Но, обобщённая статья, которая бы рассказывала про технологии (а не про то, куда в каком порядке кликать) была бы интересна.
                    +1
                    Кстати, в Debian LTSP есть в репозитории.
                      0
                      А в Ubuntu 10.04 Server?
                        0
                        Убунты под рукой нету, так что не знаю. Но, думаю, что должен быть, ведь Убунта с Дебианом — близкие родственники, как-никак.
                          0
                          $ aptitude search ltsp
                          p ltsp-client — LTSP client environment
                          p ltsp-client-core — LTSP client environment (core)
                          p ltsp-cluster-accountmanager — Account creation and management daemon for
                          p ltsp-cluster-control — Web based thin-client configuration manage
                          p ltsp-cluster-lbagent — LTSP loadbalancer agent offers variables a
                          p ltsp-cluster-lbserver — LTSP loadbalancer server returns the optim
                          p ltsp-cluster-nxloadbalancer — Minimal NX loadbalancer for ltsp-cluster
                          p ltsp-cluster-pxeconfig — LTSP-Cluster symlink generator
                          p ltsp-controlaula — Classroom management tool with ltsp client
                          p ltsp-docs — LTSP Documentation
                          p ltsp-manager — Ubuntu LTSP server management GUI
                          p ltsp-server — Basic LTSP server environment
                          p ltsp-server-standalone — Complete LTSP server environment
                          p ltspfs — Fuse based remote filesystem for LTSP thin
                          p ltspfsd — Fuse based remote filesystem daemon for LT
                          p ltspfsd-core — Fuse based remote filesystem daemon for LT
                          p python-ltsp — provides ltsp related functions
                      0
                      По-моему использование next-server — это какой-то костыль. Если в DHCP указать все нужные для PXE-boot опции, то этот костыль не понадобится.
                      По-хорошему для PXE-загрузки с образа на TFTP-сервере нужно указать следующие опции на DHCP:

                      Опция 066 — имя TFTP-сервера (например: tftp.domain.example)
                      Опция 067 — имя загрузочного образа относительно корня TFTP (например: pxelinux.0, если этот образ лежит в корне TFTP)
                      Опция 150 — IP-адрес TFTP-сервера

                      Примечания:
                      а) В опции 066 можно указать, как короткое имя сервера, так и FQDN-имя. Если указывается короткое имя, то по-хорошему нужно тогда на DHCP определить опцию 015 (в ней указывается DNS-суффикс, например: domain.example).
                      б) Если на DHCP задано только имя TFTP-сервера (в опции 66), но не задан его IP-адрес (опция 150), тогда ещё для разрешения имени в IP по-хорошему должен быть задан DNS-сервер (один или несколько) в DHCP-опции 006.
                      в) В опции 66 вместо имени можно сразу указать IP-адрес TFTP-сервера (тогда опции 150, 15 и 6 — для PXE-загрузки необязательны). Это не по RFC, но работает.

                      Важный момент:
                      Если на DHCP-сервере задана опция 60 = PXEClient, тогда опции 66 и 67 PXE-клиентами игнорируются, и PXE-клиент будет брать TFTP-сервер и имя
                      образа из опции 43, где они записываются как-то хитро в бинарном виде.
                      Если опця 60 на DHCP-сервере определена, а опция 43 не задана (или если отсутствуют опции 60, 66, 67), тогда PXE-клиент по умолчанию считает TFTP-сервером для загрузки сам DHCP-сервер.
                        0
                        next-server это ведь и есть опция 66, разве нет?
                          0
                          Да, действительно, в нотации ISC dhcpd опция 66 — это next-server, опция 67 — это filename, опция 60 — это vendor-class-identifier.
                          Однако, как я уже писал, согласно RFC2132 (п. 9.13), при получении от клиента опции 60 (vendor-class-identifier) DHCP-сервер должен ему возвращать только значение опции 43 (Vendor Specific Information), в которой закодирован и TFTP-сервер, и имя файла-образа, а опции 66 (next-server) и 67 (filename) при этом должны игнорироваться.

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

                          Я бы предложил вообще не заморачиваться с проверкой подстроки «PXEClient» в опции 60 (vendor-class-identifier) и соответственно не указывать опцию 43 (Vendor Specific Information), а просто для всего DHCP-скоупа задать набор следующих DHCP-опций.
                          Типовые сетевые настройки (помимо IP-адреса):
                          1 — Subnet Mask
                          3 — Router
                          6 — DNS-server(s)
                          15 — Domain Name (DNS-suffix)
                          28 — Broadcast Address
                          Настройки для PXE-загрузки с TFTP:
                          66 — TFTP server name (next-server)
                          67 — Bootfile name (filename)
                          150 — TFTP server IP-address

                          P.S. Кстати, вас не смущает тот факт, что открывающих фигурных скобок в вашем dhcpd.conf на одну больше, чем закрывающих?
                            0
                            Да, спасибо, поправил.
                              0
                              Интересно, к сожалению, так дотошно RFC не изучал, возможно с этим у меня и были связаны проблемы, но некоторые версии PXE прошивок категорически отказывались грузить файлы с TFTP расположенного на другом сервере, кроме самого DHCP, указаны были как раз эти настройки:
                              1 — Subnet Mask
                              3 — Router
                              6 — DNS-server(s)
                              15 — Domain Name (DNS-suffix)
                              28 — Broadcast Address
                              Настройки для PXE-загрузки с TFTP:
                              66 — TFTP server name (next-server)
                              67 — Bootfile name (filename)

                              Единственное не настроена была опция 150, о ней я тогда вообще не слышал, а в параметре 66 был забит ip-адрес TFTP-сервера.

                              И ладно бы все клиенты не работали, тогда можно было ещё задуматься, а ведь только некоторые, жаль что давно уже нет под рукой этой сети, так бы проверил.
                          –1
                          Отличная статья! Так держать!
                            –1
                            Отличная статья! Так держать!
                              0
                              Статья понравилась, ждем продолжения с последующими тонкостями использования системы в продакшене ну и настройками на которые вам хотелось бы уделить внимание.

                              У самого руки никак не дойдут чтобы поэкспериментировать с терминальным сервером и тонкими клиентами, набраться опыту на будущее.
                                0
                                тезис про 64 бита интересный. Но только мне он кажется избыточным. Дело в том, что все новые процессоры (серверные и десктопные) поставляются с поддержкой 64 бит с 2004 или 2005 года. Более старое железо использовать для терминального сервера как-то неэффективно, я считаю.
                                  0
                                  Спасибо автору за статью. Сам недавно успешно настроил LTSP-сервер на своем домашнем мини-сервере. Подробности описаны в моём посте на хабре:
                                    0
                                    Ссылку забыл: habrahabr.ru/post/208114/

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

                                    Самое читаемое