LTSP Версия 4.0

Да, прошло много времени. Очень много. Но LTSP-4 наконец доступен. Нижеприведённый документ описывает некоторые новые свойства, способы установки, настройки, а также получения исходного кода.

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

Спасибо,
Jim McQuillan - jam@Ltsp.org

Новые свойства
Установка
Настройка
Локальные приложения
Исходный код
Среда сборки LTSP - LTSP Build Environment (LBE)

Проверьте страницу LTSP-4 Errata для просмотра последних новостей

• Изменения в отношении RUNLEVEL

  Опция RUNLEVEL в lts.conf больше не используется. Она была заменёна опцией SCREEN_xx описанной ниже в Экранных сценариях.

• ltspcfg

  Мы сильно изменили порядок установки LTSP. Точнее, мы отделили "установку" дерева LTSP от "настройки" сервисов на сервере.

  Это позволит облегчить установку LTSP на любой версии любого дистрибутива Linux. В действительности установка является по сути распаковкой дерева LTSP в правильное место. Хоть из tarball'а, RPM, DEB или чего бы то ни было.

  "Настройка" может быть осуществлена как вручную, так и с помощью нового инструмента, называемого ltspcfg.

  Эта новая утилита обладает встроенной логикой для выяснения способа запуска различных сервисов таких как DHCP, TFTP, NFS и XDMCP на сервере. Если она не может выяснить способ запуска сервиса, то сообщит об этом, так что Вы сможете сделать это вручную.

  Дни показа сообщения "К сожалению, этот дистрибутив не поддерживается LTSP" теперь в прошлом.

  getltscfg ещё не завершён, но очень к этому близок.

• Экранные сценарии

  В предыдущих версиях LTSP тип сессии на рабочей станции диктовался параметром 'RUNLEVEL' в файле lts.conf. Уровень 5 запускал графический интерфейс. Уровень 4 запускал telnet-сессию, а уровень 3 предназначался для диагностического режима (приглашение оболочки bash).

  Теперь тип сессии может быть выбран для каждого виртуального терминального устройства tty. Т.е. возможно 6 telnet-сессий на vt1-vt6. Или пара telnet-сессий и графическая сессия. Или же, с помощью будущих дополнительных пакетов, у Вас могут быть локальные Rdesktop-сессии (да, и это тоже) или SSH-сессии или локальные рабочие столы X Window. Всё это управляется новыми параметрами в файле lts.conf.

  Например:

         SCREEN_01  = telnet 192.168.254.254
         SCREEN_02  = startx 

  Одна из хороших особенностей экранных сценариев - лёгкость создания новых экранных сценариев без необходимости в исправлении кода ядра ltsp. Они просто помещаются в директорию /opt/ltsp/i386/etc/screen.d и после этого доступны для файла lts.conf.

  Вот список доступных на сегодня экранных сценариев:

  • startx

    Запускает X на экране (Эквивалентен RUNLEVEL = 5 на ltsp-3)

  • telnet

    Запускает символьную telnet-сессию на сервер. (Эквивалентен RUNLEVEL = 4 на ltsp-3)

  • shell

    Запускает оболочку на терминале. Предназначен только для ДИАГНОСТИЧЕСКОГО режима. (Эквивалентен RUNLEVEL = 3 на ltsp-3).

  • rdesktop

    Запускает X с rdesktop в качестве единственного приложения. Идея в том, что rdesktop запускается в полноэкранном режиме, соединяясь непосредственно к Windows-серверу без необходимости входа на Linux-сервер вначале.

  Может быть написано больше сценариев для выполнения на рабочей станции чего угодно. Взгляните на существующие сценарии в директории /opt/ltsp/i386/etc/screen.d для примера написания сценариев.

• getltscfg был переписан

  getltscfg - программа, которая интерпретирует файл lts.conf. Она была переписана с использованием bison и flex. Это ведёт к более быстрой интерпретации и даёт нам большую гибкость в синтаксисе. Теперь у нас есть ключевое слово 'LIKE', которое позволит секциям наследовать параметры других секций.

  Здесь пример, где Вы используете несколько компьютеров HP Vectra и несколько Dell Dimension:

  
         [Vectra]
             X_MOUSE_DEVICE   = /dev/ttyS0
             X_MOUSE_PROTOCOL = Microsoft
      
         [Dimension]
             X_MOUSE_DEVICE   = /dev/psaux
             X_MOUSE_PROTOCOL = IMPS/2
         
         [ws001] LIKE = Vectra 
      
         [ws002] LIKE = Vectra 
      
         [ws003] LIKE = Vectra 
      
         [ws004] LIKE = Dimension 
      
         [ws005]
             LIKE               = Dimension
             PRINTER_0_DEVICE   = /dev/ttyS1
             PRINTER_0_TYPE     = S
      
         [ws006] LIKE = Dimension 

  Заметьте, что ws005 наследует от Dimension, но также включает локальный принтер.

• ltspinfod

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

• Локальный приложения

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

• Исходный код

  Исходный код теперь доступен для всего LTSP.

• Среда сборки LTSP (LBE - The LTSP Build Environment)

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

Процедура установки LTSP была значительно упрощена. Если Вы когда-либо устанавливали Ximian Desktop 2, то почувствуете себя как дома в новым средством установки LTSP-4.

Во-первых, Вы должны быть root'ом. Затем простая команда wget загрузит средство установки ltsp и начнёт процесс установки.

   su -
   wget -q -O - http://www.ltsp.org/ltsp_installer | sh

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

В будущем мы планируем предложить RPM и DEB пакеты.

Для LTSP-4 всё ещё нет специфического ядра Linux. Ядра для LTSP-3 будут работать и с LTSP-4.

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

Вы можете загрузить как RPM, так и tarball с ltspcfg.

ltspcfg поможет Вам настроить сервисы, необходимые для рабочих станций LTSP.

Замечания об установке ltspcfg:

• Установка RPM:

  rpm -ivh ltspcfg-0.3-0.i386.rpm

• Установка tarball:

  tar xvzf ltspcfg-0.3.tgz
  ./install.sh

В некоторых случаях нерационально иметь мощный процессор и большое количество ОЗУ, сидя за рабочим столом и используя только ядро Linux и X Server. Поэтому при помощи LTSP у Вас есть возможность запуска некоторых приложений локально.

Мы запускаем приложение, используя SSH.

Чтобы сделать ssh достаточно безопасным, необходимо хранить секретный ключ рабочей станции на каком-либо виде локального устройства хранения данных, таком как гибкий диск, флэш-диск или жёсткий диск. Мы пока не зашли настолько далеко с этим. Секретный ключ хранится на сервере и доступен через NFS. МЫ ЗНАЕМ, что это проблема безопасности. Нашей первой целью с ssh было сделать возможным запуск приложений на рабочей станции. Мы работаем над тем, чтобы сделать это настолько безопасным, насколько возможно.

Пара публичных/секретных ключей используется всеми рабочими станциями, должна быть создана при помощи ssh-keygen и сохранена в /opt/ltsp/i386/etc/ssh. Также публичный ключ должен быть сохранён в файл /etc/ssh/ssh_known_hosts. На самом деле один и тот же ключ должен располагаться в этом файле несколько раз. Один раз для каждой рабочей станции, с именем рабочей станции перед каждой записью. После этого, если Вы не хотите, чтобы пользователи вводили пароли каждый раз при запуске локального приложения, необходимо поместить пользовательский публичный ключ в их собственные файлы authorized_keys.

Для генерации пары секретного/публичного ключей для рабочих станций выполните следующие команды:

    ssh-keygen  -q  -t rsa1  -f /opt/ltsp/i386/etc/ssh/ssh_host_key      -C ''  -N ''
    ssh-keygen  -q  -t rsa   -f /opt/ltsp/i386/etc/ssh/ssh_host_rsa_key  -C ''  -N ''
    ssh-keygen  -q  -t dsa   -f /opt/ltsp/i386/etc/ssh/ssh_host_dsa_key  -C ''  -N ''

Затем возьмите содержимое файла /opt/ltsp/i386/etc/ssh/ssh_host_rsa_key.pub и добавьте строку в /etc/ssh/ssh_known_hosts для каждой рабочей станции. Удостоверьтесь, что Вы добавили имя рабочей станции перед каждой записью.

Ниже приведён пример того как должен выглядеть файл /etc/ssh/ssh_known_hosts:

    ws001  ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAxFCM2eZU7P3HvEOMYhAFUiwE...
    ws002  ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAxFCM2eZU7P3HvEOMYhAFUiwE...
    ws003  ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAxFCM2eZU7P3HvEOMYhAFUiwE...
    ws004  ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAxFCM2eZU7P3HvEOMYhAFUiwE...
    ws005  ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAxFCM2eZU7P3HvEOMYhAFUiwE...

После настройки ssh и NIS на сервере необходимо добавить следующие установки в файл lts.conf:

    LOCAL_APPS       = Y
    NIS_DOMAIN       = ltsp

Как только эти установки будут добавлены, а рабочие станции перезагружены, пользователь сможет запускать программы на работче станции. Конечно, приложение и все его библиотеки должны быть доступны рабочей станции через NFS.

Простой пример запуска программы на тонком клиенте:

    ssh  ws001  uptime

Мне удалось запустить Mozilla Firebird 0.7 в качестве локального приложения. Я не создавал официальный пакет. Скорее сие была проверка просто чтобы увидеть могу ли я это сделать. И это работает! Требуется скопировать весь набор библиотек в директорию /opt/ltsp/i386/usr/lib, а директорию Mozilla Firebird в директорию /opt/ltsp/i386/usr/local/MozillaFirebird-0.7. После этого запуск Firebird на тонком клиенте был сделан так:

    ssh ws001 env DISPLAY=:0.0 /usr/local/MozillaFirebird-0.7/MozillaFirebird

Одной из основных причин создания LTSP-4 со средой сборки было то, что мы можем собирать локальные приложения. Мы определённо планируем предложить официальный пакет, включающий Mozilla полностью со всеми необходимыми библиотеками.

LTSP-4 строится полностью из исходного кода. Это не означает, что Вы ОБЯЗАНЫ компилировать его. У нас также доступны и бинарные пакеты. Это означает, что Вы МОЖЕТЕ компилировать и адаптировать так, как Вы хотите.

Для начала работы с исходным кодом взгляните на нижеприведённую информацию о доступе к исходному коду через CVS.

Возможно единственная наиболее существенная особенность LTSP-4.0 - это факт того, что он полностью собран из исходного кода. В предыдущей версиии LTSP мы брали бинарники из других дистрибутивов Linux (в основном Redhat 7.0).

Во время процесса организации исходного кода для всех частей LTSP мы обнаружили, что практически невозможно учесть все версии инструментов разработки на всех платформах где люди могут захотеть собрать LTSP. Например, для компиляции Glibc-2.2 необходим gcc-3.2 или новее, а многие существующие дистрибутивы Linux всё ещё не содержат его. Именно поэтому мы сделали нечто, называемое Средой сборки LTSP - LTSP Build Environment (LBE).

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

Была проделана огромная работа над LBE с поры LTSP-3. Весь процесс сборки был переделан, а метод получения исходных tarball'ов изменён.

Новым в LTSP-4 является установка кросс-компилятора. Мы нашли, что нам необходим кросс-компилятор для того, чтобы заставить инструментарий в LBE использовать корректные библиотеки и заголовочные файлы. Мы ломали головы пытаясь выяснить почему LBE будет работать на одних дистрибутивах Linux, а не на других. Затем мы обнаружили, что разные дистрибутивы имеют разные версии заголовочных файлов и это приводит к тому, что некоторые вещи не работают. Поэтому теперь у нас есть кросс-компилятор. Несмотря на то, что мы работаем на x86 системе и генерируем код для x86 же. Одно лишь светлое пятно заключается в том, что это делает нас ближе к созданию среды, в которой мы сможем генерировать код для не-x86 клиентов. Но это дело будущего. Пока мы не готовы биться со всем этим. Посредством кросс-компилятора мы избавляемся от необходимости иметь ту или иную версию gcc и binutils на Вашей системе.

Для запуска процесса сборки используется небольшой корневой пакет. tarball'ы с исходниками каждой конкретной компоненты LBE и LTSP более не хранятся внутри основного пакета. Они получаются автоматически при помощи wget в начале процесса сборки.

Более того, общие компоненты LBE и LTSP находятся в одних и тех же tarball'ах вместо дублирования исходников. Примером может быть bash, эта оболочка используется как LBE, так и LTSP-4.0.

Для LBE и LTSP был написан очень мощный инструмент сборки. Этот инструмент читает список пакетов для сборки и затем для каждого пакета читает файл package.def на предмет инструкций как в действительности выполнять сборку.

Сборка LTSP-4.0 из исходников:

1. Загрузка из CVS

   Выберите директорию и войдите в неё. Я использую '/usr/local/projects', но Вы можете выбрать любую, какую предпочтёте.

   Получите пакет LBE через cvs с помощью следующей команды:

   cvs -d :pserver:anonymous@cvs.ltsp.org:/usr/local/cvsroot checkout lbe
   

   Это создаст поддиректорию lbe, содержащую следующее:

       lbe
          build_all
          crosscomp-src
          initrd-src
          kernel-src
          lbe-src
          ltsp-src
          README
          TODO
       

2. Сборка

   ./build_all

   Этот процесс соберёт кросс-компиляторы, LBE, LTSP, initrd и ядро LTSP.

   Будьте готовы ждать некоторое время. На 2.5ghz P4 процесс занимает около 3-х часов.