Comments 28
откуда скрины? это CentOS? в нем кеды по умолчанию?
всегда хотел увидить эту ОС
у нас с коллегами только ssh-доступ, а сервера в Чикаго, мы никогда не увидим какой там интерфейс, а так интересно)
всегда хотел увидить эту ОС
у нас с коллегами только ssh-доступ, а сервера в Чикаго, мы никогда не увидим какой там интерфейс, а так интересно)
X over SSH и в путь
да, CentOS. По умолчанию ставиться Гном, но как я писал — Гном я просто не перевариваю) Не срослось мое с ним знакомство…
VNC + SSH port forwarding уже не торт?
Возможно я ошибаюсь, но как вы собираетесь реализовать терминальный сервер через VNC и SSH порт форвардинг? В лучшем случае вы получите защищенный удаленный сеанс. Я имею ввиду, что VNCServer не является менеджером сеансов и новый сеанс вам запустить не удастся. Для локальной сети в учебных классах использовать ssh я смысла не вижу. Из других возможных альтернатив — X11vnc и nx, если не изменяет память.
По сути можно было бы и самому собрать ядро для тонких клиентов с минимальным необходимым набором софта, но зачем изобретать велосипед?
По сути можно было бы и самому собрать ядро для тонких клиентов с минимальным необходимым набором софта, но зачем изобретать велосипед?
Спасибо за статью, меня давно мучила родственница которая работает учителем информатики, и у неё половина компьютерного класса мягко сказать старовата, а со след года вводят СПО в школы, и будет интересно опробовать статью.
Вопросы:
1) доступ к флешкам в сессии (каким образом реализован?)
2) звук
3) Печать на локальные принтеры.
1) доступ к флешкам в сессии (каким образом реализован?)
2) звук
3) Печать на локальные принтеры.
Вот по поводу локальных принтеров присоединяюсь к вопросу, без этого в офисе никак.
Звук работает точно.
1) Доступ к флешам клиентов я еще не проверял. Но видел на хабре статью о такой настройке. Нужно будет попробовать и проверить.
2) По поводу звука — я устанавливал на сервер пакет Ричарда Джоуна (rpm , tar)
3) По поводу печати на локальные принтеры — необходимости не было. Но можно будет протестировать, т.к. в документации к LTSP заявлено, что такая возможность есть.
Если данная тема действительно вас заинтересовала — то со временем напишу статью, в которой постараюсь ответить на все интересующие вас вопросы, а так же те, которые в ходе внедрения данного решения возникнут у меня.
2) По поводу звука — я устанавливал на сервер пакет Ричарда Джоуна (rpm , tar)
3) По поводу печати на локальные принтеры — необходимости не было. Но можно будет протестировать, т.к. в документации к LTSP заявлено, что такая возможность есть.
Если данная тема действительно вас заинтересовала — то со временем напишу статью, в которой постараюсь ответить на все интересующие вас вопросы, а так же те, которые в ходе внедрения данного решения возникнут у меня.
Кстати, в Debian LTSP есть в репозитории.
А в Ubuntu 10.04 Server?
Убунты под рукой нету, так что не знаю. Но, думаю, что должен быть, ведь Убунта с Дебианом — близкие родственники, как-никак.
$ 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
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
По-моему использование 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-сервер.
По-хорошему для 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-сервер.
UFO just landed and posted this here
Да, действительно, в нотации 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 на одну больше, чем закрывающих?
Однако, как я уже писал, согласно 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 на одну больше, чем закрывающих?
Отличная статья! Так держать!
Отличная статья! Так держать!
Статья понравилась, ждем продолжения с последующими тонкостями использования системы в продакшене ну и настройками на которые вам хотелось бы уделить внимание.
У самого руки никак не дойдут чтобы поэкспериментировать с терминальным сервером и тонкими клиентами, набраться опыту на будущее.
У самого руки никак не дойдут чтобы поэкспериментировать с терминальным сервером и тонкими клиентами, набраться опыту на будущее.
тезис про 64 бита интересный. Но только мне он кажется избыточным. Дело в том, что все новые процессоры (серверные и десктопные) поставляются с поддержкой 64 бит с 2004 или 2005 года. Более старое железо использовать для терминального сервера как-то неэффективно, я считаю.
Спасибо автору за статью. Сам недавно успешно настроил LTSP-сервер на своем домашнем мини-сервере. Подробности описаны в моём посте на хабре:
Ссылку забыл: habrahabr.ru/post/208114/
Sign up to leave a comment.
Поднятие терминального сервера на примере LTSP и CentOS 5.4