Использование бездисковых Linux-станций с загрузкой по сети. AOMEI PXE Boot: Загрузка компьютеров по сети из файла образа диска Установка linux с windows lan
Для меня долгое время оставалось загадкой, почему в Ubuntu только два варианта установочного диска – Desktop и Alternate. В Debian кроме обычных полных установочных дисков, устанавливающих сразу полный GNOME или KDE, существует также NetInstall диск, предназначенный для установки системы по сети.
Загрузочный CD в таком варианте предназначен для запуска инсталлятора, устанавливающего минимальный необходимый набор пакетов. Все остальное при необходимости выкачивается и устанавливается из сети. Такой вариант предполагает большую квалификацию пользователя, выполняющего установку, но зато обеспечивает гибкость в установке только необходимых компонентов системы. Это также позволяет экономить дисковое пространство.
Оказалось, что в Ubuntu тоже есть вариант установочного диска, предназначенный для установки по сети. Просто ссылка для его закачки не расположена на главной странице сайта. А спрятана по следующему адресу .
Меня интересовал вопрос, какого минимального размера можно получить установленную Ubuntu без совершения специальных трюков. Для теста было решено установить Ubuntu c минимального диска в VirtualBox.
Размер имиджа минимального диска составляет 11Mб. Это немного, и позволяет выкачать его на любой, даже самой маленькой скорости.
А вот при установке желательно иметь канал в интернет побыстрее. Потому что минимальный диск, кроме собственно инсталлятора, не содержит ничего. Поэтому в процессе установки будет качаться все. Действительно всё!
Первую попытку выполнить установку Ubuntu с минимального диска я предпринял, подключившись к интернету по ADSL на скорости 128 кбит/с. Установка (в основном закачка пакетов) растянулась на несколько часов.
Для повторного эксперимента удалось найти подключение на существенно большей скорости.
При загрузке с минимального диска нас встречает cначала текстовое приглашение:
а затем стандартное загрузочное графическое(!) меню Ubuntu:
Имеющийся пункт "Command-line install" не означает, что установка будет производиться из командной стоки. В любом случае запускается инсталятор в текстовом режиме.
Пункт «Advanced options» содержит дополнительное меню:
позволяющее выполнить Expert install. При его выборе появляется меню с действиями по установке, позволяющее выполнить их в почти произвольном порядке:
Я же выбираю пункт – «Install».
Текстовый инсталятор обычный. Такой же, как и в Alternate диске. С тем лишь отличием, что пакеты берутся не с диска, а закачиваются по сети.
Инсталятор традиционно спрашивает язык:
настраивает раскладку клавиатуры:
потом предлагает выбрать репозиторий:
который по умолчанию предлагается локальный для выбраной страны:
Сегодня автоматизируется все больше задач, для максимальной отдачи серверов все шире используют виртуализацию. Но устанавливать операционки по-прежнему приходится. Каждый делает это по-своему: у кого-то полные карманы различных образов на все случаи жизни, кто-то по старинке носит с собой «барсетку» с дисками, а то и две. Как правило, администраторы выполняют эту работу с невеликим удовольствием. Давай посмотрим, как сократить время на тривиальные задачи, как научить компьютеры устанавливать системы самостоятельно, вообще без участия админа, используя при этом только локальную сеть.
Итак, сегодня мы научимся: устанавливать Windows и Linux по сети, грузить небольшие ISO-образы, полезный софт (всяких там Касперских, Акронис, WinPE, мемтесты), разворачивать тонкие клиенты и рулить ими. Чтобы, например, бухгалтер, работающая с 1С по RDP, не прибила тебя за то, что у нее слетела винда, а отчет нужно было подготовить еще вчера... Или скупой начальник, который не хочет обновлять свой комп, восхитился твоим профессионализмом, когда увидит, как на стареньких компах летает Windows 8... В достижении наших коварных целей нам поможет сервер, предоставляющий загрузку по сети (PXE).
У любого системного администратора в заначке есть универсальный USB-диск для экстренной реанимации компьютера. Согласись, было бы куда лучше иметь ту же функциональность, используя одну лишь сетевую карту. Нельзя при этом не отметить возможность одновременной работы с несколькими узлами сразу. Итак, исходя из наших потребностей у нас есть два пути решения: использовать PXE или LTSP.
LTSP нам не очень подходит: он призван грузить по сети ОС, установленную на самом сервере, что позволяет использовать приложения сервера LTSP. Это не совсем то, что нам нужно. PXE - инструмент для загрузки компьютера по сети без использования локальных носителей данных, так же как и LTSP. PXE позволяет организовать мультизагрузочное меню загрузки, аналогичное универсальному «USB-реаниматору».
Что будем реализовывать?
Началось все с необходимости иметь под рукой инструмент для удаленной установки Ubuntu/Debian Server по сети, с возможностью загрузки Live CD маленькой системы, вроде SliTaz или Kolibri OS.
Как говорится, аппетит приходит во время еды: намеченное не успели реализовать, а к плану добавился еще ряд «хотелок». В итоге список получился весьма внушительным.
- Тонкие клиенты на базе Thinstation Linux.
- Раздел Linux.
- Установка Ubuntu 14.04 x86.
- Установка Ubuntu 14.04 x64.
- Установка Ubuntu 12.04 x86.
- Установка Ubuntu 12.04 x64.
- Раздел Windows.
- Установка Windows 2012.
- Установка Windows 7.
- Acronis.
- Windows PE с пакетом полезного ПО.
- Acronis True Image.
- Legacy BIOS.
- UEFI.
- Acronis Disk Director.
- Legacy BIOS.
- UEFI.
- Касперский Rescue v 10.
- ERD Commander от 5 до 8 через ISO-образ.
- Memtest.
Собираем все в кучу и взлетаем
В качестве дистрибутива для сервера выбор пал на Ubuntu Server 14.04.2 LTS. Можно остановиться на любой другой ОС, разница будет только в синтаксисе. Итак, приступим. Нам потребуется TFTP, DHCP (необязательно установленный на этом же сервере, в роли DHCP-сервера может выступить роутер), сервис для организации сетевой файловой системы NFS. Рассматривать будем только те настройки, которые нас интересуют в рамках темы. Первым делом установим все необходимое, предварительно сделав все обновления:
Продолжение доступно только участникам
Вариант 1. Присоединись к сообществу «сайт», чтобы читать все материалы на сайте
Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», увеличит личную накопительную скидку и позволит накапливать профессиональный рейтинг Xakep Score!
( 2018-04-10 )
PXE это среда загрузки компьютера с помощью сетевой карты без использования локальных носителей. Возможности применения достаточно широки: от просто начальной загрузки системы, до запуска полноценных рабочих систем без использования локального диска.
Некоторое время назад автору этих строк в руки попал старенький IBM ThinkCentre S51 8171 с неисправным CD-приводом. С загрузкой с флэшки, созданной с помощью UNetBootin, так же возникли проблемы и осталась последняя надежда: загрузка инсталлятора по PXE. Далее будет кратко описан полученный опыт.
IBM ThinkCentre S51 8171 имеет очень неплохую начинку для машины 2006-го года выпуска: Pentium 4 540, 2x512MB DDR, 30GB ATA HDD. Но в 2018-м она смотрится блекло, хотя и сейчас ей можно найти множество применений. Основная проблема: процессор не поддерживает EMT64 и потому операционная система должна быть обязательно 32-битной. К счастью Ubuntu 16.04 существует в редакции i386 и было решено ставить её.
В качестве сервера загрузки решено было использовать домашний сервер под управлением Ubuntu 16.04. Для раздачи адресов в локальной сети используется isc-dhcp-server. В остальном конфигурация сервера достаточно типична. Для создания PXE-окружения нам понадобится -сервер. Мы будем использовать пакет "tftpd-hpa". Установим его, а так же (на всякий случай) tftp-клиент:
Apt-get install tftpd-hpa tftp-hpa
По умолчанию tftpd-hpa использует директорию "/var/lib/tftpboot". Если по какой-то причине необходимо это изменить то нужно соответствующим образом отредактировать файл "/etc/default/tftpd-hpa" и перезапустить сервис "tftpd-hpa". Но нас вполне устроит конфигурация по умолчанию.
Список доступным инсталляторов Ubuntu 16.04 для загрузки через PXE и сетевой установки можно найти на этой странице . Нас интересует архив под названием "netboot.tar.gz" для архитектуры i386. Скачиваем и распаковываем его в директорию tftp-сервера:
Wget http://archive.ubuntu.com/ubuntu/dists/xenial-updates/main/installer-i386/current/images/netboot/netboot.tar.gz mkdir -p /var/lib/tftpboot/ubuntu/ tar zxfv netboot.tar.gz -C /var/lib/tftpboot/ubuntu/
На этом подготовка TFTP-сервера заканчивается и остаётся настроить DHCP-сервер. Вся конфигурация сводится к добавлению строки:
# Путь к файлу "pxelinux.0" относительно директории TFTP-сервера filename "ubuntu/pxelinux.0";
Эту строку можно добавить в описание подсети, группы хостов или даже конкретного хоста. Главное чтобы машина, ради которой это всё делается, получила нужную конфигурацию. После этого можно включить машину и выбрав загрузку по PXE приступить к установке системы. После загрузки инсталлятора установка будет происходить обычным образом, так, будто бы была произведена загрузка с "MinimalCD ".
На этом можно было бы закончить, но есть ещё интересный момент: автоматическая установка. Инсталлятор Ubuntu частично поддерживает формат конфигурации kickstart от RedHat Linux. Подробнее можно прочитать . Если есть необходимость в использовании сценария автоматической установки то сначала необходимо создать файл сценария и разместить его на веб-сервере в локальной сети, затем надо немного модифицировать файл "/var/lib/tftpboot/ubuntu/ubuntu-installer/i386/boot-screens/txt.cfg":
#append vga=788 initrd=ubuntu-installer/i386/initrd.gz --- quiet append ks=http://192.168.2.1/ks.cfg vga=788 initrd=ubuntu-installer/i386/initrd.gz --- quiet
Здесь параметр "ks=" указывает URL, по которому расположен сценарий настройки kickstart. Более детальное изучение этой темы оставим читателю.
На этом всё. Приятной работы!
Предисловие.
Это придумано давным давно. Во всяком случае в статье , написанной в конце прошлого века (1998 год), идею сетевой загрузки автор называет старой. И это не удивительно, загрузка операционной системы по сети - мечта любого администратора. Ведь операционная система загруженная с сервера всегда будет «белой и пушистой», а изменения и обновления достаточно будет внести в загрузочный образ на сервере, вместо того, чтобы бегать с флешкой по всему парку компьютеров.
Почему же такая хорошая идея не получила широкого распространения? Из-за сложности? Нет! Серверы для сетевой загрузки настраиваются довольно просто, как правило одним конфигурационным текстовым файлом, и, забегая вперёд, скажу, что в lanboot_server создание файлов конфигурации производится автоматически. На практике это сводится к «включил, и готово».
Что потребуется?.
Если локальная сеть не настроена - настройте её. После этого смело командуйте lanboot start и клиенты могут загружаться.
Для остановки соответственно lanboot stop. В ALTLinux и Ubuntu придётся поработать руками, доустановить необходимое и настроить.
Впрочем, не всё так страшно. Скрипт запуска lanboot (/usr/sbin/lanboot) должен работать и в других линуксах, например в Simply Linux (ALT) скрипт создал правильные файлы конфигурации и сервер запустился, только загружаемых файлов в «TFTP directory» (/var/lib/tftpboot) не оказалось, и это не удивительно, ведь откуда взяться файлам PuppyRus в ALTLinux.
Продолжим.
Из чего собрано.
Для загрузки Linux по сети нам потребуется tftp-сервер (используется tftp-hpa-5.0), bootp или dhcp (я выбрал dhcp-4.1.1, хотя сначала использовал bootp) и inetd или xinetd (я выбрал inetd, он проще).
Как настраивается.
1. Bootp
Самый простой.
Выдаёт IP привязанный к MAC-адресу клиента.
Поэтому может применяться только в сетях с постоянным парком машин.
Пример /etc/bootptab
Используемые параметры:
Td -- TFTP directory (отсюда будут загружаться файлы) - rp -- root path (путь к корню сервера) - bf -- bootfile (загружаемый файл) - sa -- boot server address (IP TFTP-сервера) - sm -- subnet mask (маска подсети) - gw -- gateways (шлюз) - to -- time offset (seconds) - ha -- hardware address (аппаратный, он же MAC адрес) # Можно писать либо в столбик, либо в одну строку. # Настройки, общие для всех клиентов: .default:td=/var/lib/tftpboot:rp=/var/lib/tftpboot:bf=pxelinux.0:sa=192.168.1.2:sm=255.255.255.0:gw=192.168.1.1:to=auto: #или так.default:\ td=/var/lib/tftpboot:\ rp=/var/lib/tftpboot:\ bf=pxelinux.0:\ sa=192.168.1.2:\ sm=255.255.255.0:\ gw=192.168.1.1:\ to=auto: # Настройки для клиентов в других подсетях: #.subnet1:sm=255.255.255.0:gw=192.168.0.1:tc=.default: # Индивидуальные настройкм каждого клиента (примеры): #notick:tc=.default:ha=00140B016592:ip=192.168.1.4: #sharick:tc=.default:ha=0123456789ab:ip=192.168.1.2 #bobick:tc=.default:ha=ba9876543210:ip=192.168.1.5 # и т.д.
2. Dhcpd
Полноценный dhcp-сервер.
Пример /etc/dhcpd.conf
# dhcpd.conf # # Use this to enble / disable dynamic dns updates globally. ddns-update-style none; subnet 192.168.1.0 netmask 255.255.255.0 { option routers 192.168.1.1; option subnet-mask 255.255.255.0; option broadcast-address 192.168.1.255; range dynamic-bootp 192.168.1.10 192.168.1.200; default-lease-time 21600; max-lease-time 43200; filename "pxelinux.0"; }
3. Tftp
Файловый сервер с упрощённым протоколом.
Пример /etc/exports
#Каталоги, разрешённые для tftp-загрузки и nfs-монтирования (no_root_squash - разрешён пользователь root) /var/lib/tftpboot 192.168.1.0/255.255.255.0(ro,no_root_squash,sync)
4. Inetd
У нас служит для запуска tftp-сервера и bootp-сервера. Но может запускать и другие службы. Файл конфигурации /etc/inetd.conf. Файл длинный, «на все случаи жизни». Поэтому привожк только нужные строки.
Пример /etc/inetd.conf.
# Эта строка запускает tftp-сервер tftp dgram udp wait root /usr/sbin/in.tftpd in.tftpd -s /var/tftpboot # Эта строка запускает bootp-сервер bootps dgram udp wait root /usr/sbin/bootpd bootpd -i
5. Xinetd
Функции те же, что и у inetd, но настройки сложнее. Установлен в Альтлинуксе.
Пример /etc/xinetd.conf
# # Simple configuration file for xinetd # # Some defaults, and include /etc/xinetd.d/ defaults { log_type = SYSLOG authpriv info; log_on_success = PID HOST DURATION; log_on_failure = HOST; instances = 100; per_source = 5; only_from = 127.0.0.1; } includedir /etc/xinetd.d Для каждой запускаемой программы отдельный файл конфигурации кладётся в /etc/xinetd.d Пример /etc/xinetd.d/tftp # default: off # description: The tftp server serves files using the trivial file transfer \ # protocol. The tftp protocol is often used to boot diskless \ # workstations, download configuration files to network-aware printers, \ # and to start the installation process for some operating systems. service tftp { disable = no; socket_type = dgram; protocol = udp; wait = yes; user = root; server = /usr/sbin/in.tftpd; server_args = -u tftp -s /var/lib/tftpboot; per_source = 11 cps = 100 2 flags = IPv4 only_from = 192.168.1.0; }
Автоматическая настройка.
Для автоматической настройки переменные берутся из вывода стандартных linux-команд ifconfig и route. Поэтому их можно получить в любом Linux.
Serv=$(ifconfig | grep inet | grep -v 127.0.0.1 | cut -f 2 -d ":" | cut -f 1 -d " ") mask=$(ifconfig | grep inet | grep -v 127.0.0.1 | cut -f 4 -d ":") gate=$(route | grep UG | cut -f 10 -d " ") subnet=$(route | grep " U " | cut -f1 -d " ")
Эти переменные вписаны в соответствующие места шаблонов конфигурационных файлов содержащихся в скрипте lanboot. При выполнении скрипта значения переменных подставляются в шаблон и сгенерированный таким образом файл конфигурации отправляется «по месту назначения». Это избавляет вас от рутинной работы и человеческих ошибок тоже. Единственное непременное условие: сеть должна быть настроена, иначе откуда брать значения переменных.
Скрипт lanboot так же копирует в TFTP directory файлы PuppyRus: vmlinuz, initrd.gz и pup*-200.sfs, необходимые для запуска. Файлы берутся из операционной системы, на которой запущен сервер, и, если эта система не PuppyRus, то их взять неоткуда. Поэтому на других Linux вышеперечисленные файлы необходимо поместить в /var/lib/tftpboot вручную (копированием).
В статье подробно рассмотрен процесс развертывания сети "тонких клиентов", работающих под упралвением
дистрибутива Thinstation Linux и использующих сервер приложений на базе Windows 2000
Использование бездисковых Linux-станций с загрузкой по сети
Впервые опубликованно в журнале "Системный администратор" N11/2004Постановка задачи
Работа сотрудника отдела автоматизации – это постоянная борьба с проблемами и решение задач, которые попеременно подкидывают пользователи, разработчики эксплуатируемого программного обеспечения и руководство организации. И если два первых направления работы – это просто «борьба за живучесть корабля», то последнее, как правило, поступательное движение вперед. Как раз в ходе решения одной из таких задач и появилась на свет данная статья.
Итак, перед отделом автоматизации была поставлена задача в короткие сроки ввести в строй два новых удаленных офиса, каждый численностью в пять – десять человек. Оба офиса и «голову» связали посредством технологий VPN в одну сеть. Минимальная ширина канала между тремя точками составила 256 Кбит, что вполне удовлетворило наши потребности. В каждом из офисов был развернут дополнительный контроллер домена Windows 2000, а для минимизации трафика домен разделили на несколько сайтов. Все вышеописанное является стандартным решением, и здесь я не ожидал никаких сюрпризов. Главным вопросом для нас было – как поведет себя основная среда работы сотрудников организации – комплексная система автоматизации, при работе с которой и в пределах одной площадки хватало проблем. Изначально ориентированная на Novell/BTRIVE 6.15 после миграции сети на Windows, она работала под Windows/Pervasive.SQL 7.
После недели тестов этого основного бизнес-приложения организации, оказалось что разработчик и вовсе не оставил нам выбора, так как использование встроенного терминального режима используемой автоматизированной системы по ряду причин нас не устроило. Опять же, из-за особенностей функционирования, в качестве терминального сервера была выбрана платформа Microsoft Windows Server. Тестирование же решений компании Citrix, мы не проводили, так как работа с «родными» терминальными службами Windows нас вполне удовлетворила, а использование надстроек только увеличивает стоимость всей системы.
Когда с серверной частью все определилось, встал вопрос по клиентской составляющей системы. В первую очередь хотелось бы снизить необходимость в администрировании пользовательских машин, так как держать выделенного администратора на удаленных площадках не планировалось. Кроме того, желательным представлялось уменьшить стоимость решения, которая возросла из-за необходимости покупки терминальных лицензий. Также необходимо было учесть намерение разместить в офисах устаревшие компьютеры класса Celeron-400 с ОЗУ от 32 до 64 Мбайт.
Идеальным со всех точек зрения оказалось использование в качестве рабочих мест бездисковых станций с загрузкой по сети. При этом единственным компьютером, требующим внимание администратора становиться дополнительный контроллер домена в каждом офисе, управляемый по VNC. Само - собой, что рамках данной статьи я оставляю за пределами внимания оборудование и ПО, обеспечивающее шифрование трафика, доступ в интернет и т.д.
В роли ОС, которая будет по сети загружаться на рабочие станции, я выбрал Linux – что обеспечивает лицензионную чистоту решения (по крайней мере, на сегодняшний момент). Доступ к рабочему столу Windows 2003 должен был осуществляться при помощи разработки проекта www.rdesktop.org, который стал стандартом для решения данной задачи. В качестве же необходимых для такой загрузки серверов DHCP и TFTP, логично было бы использовать уже имеющиеся в каждом сайте дополнительные контроллеры домена Windows 2000. Благо, существуют как бесплатные реализации DHCP/TFTP под эту операционную систему, как и встроенные сервера. При этом TFTP наличествует в рамках службы Remote Installation Services (RIS).
Сетевые карты клиентских машин, естественно должны поддерживать возможность загрузки по Etherboot/PXE. В отдельных случаях из-за несовместимости оборудования я допускал использование загрузчика, расположенного на дискете.
Выбор реализации Linux
При выборе варианта ОС Linux с возможностью загрузки по сети в первую очередь я обратил внимание на уже готовые дистрибутивы подобной направленности со встроенным пакетом rdesktop. Наиболее известный из них NetStation (netstation.sourceforge.net), который застыл в виде бета версии с конца 2002 года, и его наследники: PXES (pxes.sourceforge.net), Thinstation (thinstation.sourceforge.net), и DIET-PC (diet-pc.sourceforge.net). При этом DIET-PC предназначен в первую очередь, пользователям, хорошо знакомым с ОС Linux, что сразу исключает его из области рассмотрения. Поскольку процедура его настройки достаточно кропотлива, и в DIET-PC присутствует достаточно много настроек которые простому смертному, а не Linux-гуру, никогда не пригодяться. PXES – является наиболее «продвинутым» с большим числом дополнительных возможностей, включая собственную графическую среду, что также лишнее в моем случае. В моей конфигурации клиент, минуя промежуточные меню, должен был сразу загружать удаленный рабочий стол и выходить на окно ввода пароля Windows 2003 Server. Таким образом, я обратил внимание на оставшийся дистрибутив – Thinstation.
Кратко рассмотрим его возможности:
поддержка протоколов X, RDP, VNC, SSH, Telnet, ICA и Tarantella;
возможность использовать браузер Firefox;
работа на ПК класса x86-100МГц c ОЗУ 16Мбайт;
наличие pre-build образа, и возможность самостоятельной сборки через web-интерфейс;
поддержка локальных дисков, USB и LPT принтеров
Из всех вариантов загрузки наиболее простой – это PXE при помощи Etherboot-загрузчика. В рамках этой статьи, мы пойдем по самому простому пути – использовании заранее скомпилированного образа.
Установка и первоначальная настройка
Начнем с того, что скачаем со странички http://struktur.kemi.dtu.dk/thinstation/download/, доступной по ссылке в официального сайта последний из архивов, в моем случае – это был Thinstation-2.0.2-prebuilt-NetBoot.zip. Архив содержит в себе все что необходимо, включая TFTP/DHCP сервер Tftpd32 который удобен при первоначальной настройке и конфигурировании. Кстати, если вы будете его использовать, то я бы порекомендовал сразу же обновить его с домашней странички, где имеется более свежая версия. Кстати, Tftpd32 (http://tftpd32.jounin.net/) – сама по себе отличная программа. Причем настолько, что даже рекомендуется Cisco для некоторых потребностей клиентов компании.
Развернув архив, мы получаем пять директорий:
BootDisk – образ дискеты с Etherboot-загрузчиком, для ПК, с неподдерживаемыми сетевыми картами
BootPXE – загрузчик через PXE для эмуляции Etherboot
BuildFiles – примеры конфигурационных файлов
TFtp – сервер Tftpd32
TftpdRoot – корневая директория TFTP сервера
Итак, первым делом, запускаем самораспаковывающийся архив thinstation.nbi (autoextract).exe, содержащий один единственный файл thinstation.nbi. архив сделан для того чтобы у вас была возможность ознакомиться с «CITRIX(R) LICENSE AGREEMENT».
Теперь копируем TFtp и TftpdRoot на Windows сервер в нашем сегменте сети. В качестве такого сервера при использовании Tftpd32 может выступать любая Windows-машина со статическим IP-адресом. Допустим, мы скопировали обе директории на диск C:\. Запускаем на исполнение C:\TFtp\Tftpd32.exe. Внешний вид окна программы представлен на рисунке.
Необходимо задать параметры сервера. Нажимаем кнопку «Settings», и прописываем в качестве «Base directory» значение «C:\TftpdRoot». Далее идем на вкладку «DHCP server». Там необходимо указать начальный IP-адрес выделяемый DHCP-сервером («IP pool starting address»), размер пула адресов («Size of pool»), маску подсети («Mask»), имя файла с Etherboot-загрузчиком(«Boot file»), в нашем случае это - thinstation.nbi.zpxe. Нажимаем кнопку «Save», для сохранения настроек, и сворачиваем приложение.
Все готово для работы. Вы можете попробовать включить одну из машин с сетевой картой, поддерживающей загрузку по протоколу PXE, не забыв выставить порядок загрузки в BIOS станции. При включении, машина должна получить IP-адрес из выделенного диапазона и загрузить по протоколу TFTP файл thinstation.nbi.zpxe. Он содержит загрузчик, эмулирующий работу сетевой карты с поддержкой Etherboot. Затем, управление передается загрузчику, который в свою очередь еще раз запрашивает по DHCP адрес, и загружает файл с именем, совпадающим с названием файла самого загрузчика минус расширение zpxe, то есть thinstation.nbi. Данный файл и есть образ Thinstation. Когда образ загружен, Thinstation пытается загрузить из корневой директории TFTP сервера конфигурационный файл thinstation.conf- , затем thinstation.conf- . Если такие файлы найдены, то Thinstation объединяет их содержимое с общим конфигурационным файлом thinstation.conf.network, который, в отличие от двух выше перечисленных обязан присутствовать на TFTP-сервере. Постарайтесь избежать конфликтов между главным файлом настроек и специфическим к группе или конкретной станции. Кроме того, можно объединять одним конфигурационным файлом целые группы IP и MAC-адресов. Это делается при помощи файла thinstation.hosts, имеющего следующий формат:
# HOST MAC GROUPS COMMENTS ws-oper1 0002B3655065 hi_res # Оператор №1 ws-oper2 0002B3651075 hi_res # Оператор №2 ws-oper3 0002B365A021 hi_res ssh_en # Оператор №3
В данном примере предполагается, что имеются два файла thinstation.conf.group-hi_res и thinstation.conf.group-ssh_en. Настройки прописанные в первом файле применяются ко всем трем станциям, а настройки из второго – только к компьютеру ws-oper3.
То, как отображаются сессии терминальных клиентов в оснастке диспетчера терминальных служб, вы можете увидеть на рисунке.
Клиенты с именами вида ts_ - это как раз клиентские терминалы, работающие под управлением Thinstation. Клиенты с именами вида P работают под управлением дистрибутива PXES, рассмотрение которого выходит за рамки данной статьи. Далее я приведу простой, но вполне работоспособный вариант конфигурационного файла с комментариями. # Опции сессий # # Первая сессия должна обязательно начинаться с номера 0. # При отсутствии необходимости выбора сессии, например, когда вы используете # только rdesktop, можно снять комментарий со следующего параметра, и # исключить меню выбора сессий. #AUTOSTART=On SESSION_0_TITLE="Windows 2003 terminal server (16 bit color depth)" SESSION_0_TYPE=rdesktop SESSION_0_RDESKTOP_SERVER=192.168.0.1 SESSION_0_RDESKTOP_OPTIONS="-u Administrator -p password -a 16" SESSION_1_TITLE="VNC server" SESSION_1_TYPE=vncviewer SESSION_1_VNCVIEWER_SERVER=192.168.0.2 SESSION_2_TITLE="Telnet server" SESSION_2_TYPE=telnet SESSION_2_TELNET_SERVER=192.168.0.3 SESSION_3_TITLE="SSH server" SESSION_3_TYPE=ssh SESSION_3_SSH_SERVER=192.168.0.4 # Общие опции # # Раскладка клавиатуры. В случае работы с rdesktop она роли не играет KEYBOARD_MAP=en_us # Опции XServer # SCREEN_RESOLUTION="1024x768" SCREEN_COLOR_DEPTH="16" SCREEN_HORIZSYNC="30-64" SCREEN_VERTREFRESH="56-87" MOUSE_RESOLUTION=100 # Опции печати # PRINTER_0_NAME=usb PRINTER_0_DEVICE=/dev/usb/lp0 PRINTER_2_TYPE=U
В заключение статьи, хочу сказать, что после отладки работы с терминальными клиентами, лучше всего передать функции TFTP- и DHCP- серверов программному обеспечению, способному работать в режиме службы на Windows NT/2000/2003/XP, например как я уже говорил, «родным» службам Windows, либо воспользоваться соответствующими сервисами любой другой операционной системы.
Кроме того, на сайте проекта thinstation.sourceforge.net при помощи веб-интерфейса вы можете самостоятельно перекомпилировать образ Thinstation без загрузки исходных кодов, включив какие-либо отсутствующие в prebuild образе функции, например, браузер, или исключив ненужные модули.
Андрей Маркелов. Андрей Маркелов (www.markelov.net) - Использование бездисковых Linux-станций с загрузкой по сети