Подключение к серверу потоковой загрузки zhitsoboy.ru

Подключение к серверу потоковой загрузки

Библиотека

Тема выпускной работы: Система моделирования технологической схемы производства и организации работы с документами

Научный руководитель: доцент кафедры компьютерной инженерии, кандидат технических наук Теплинский Сергей Васильевич

Перевод статьи

Методы доставки контента

Content Delivery Techniques / IIS Smooth Streaming Technical Overview

Alex Zambelli, Media Technology Evangelist

Microsoft Corporation — March 2009

Сегодня доставка медиа контента в Интернете осуществляется тремя методами: традиционное потоковое вещание, прогрессивная загрузка и адаптивное потокове вещание

Традиционное потоковое вещание

RTSP (Потоковый протокол передачи в реальном времени — англ: Real-Time Streaming Protocol) — хороший пример традиционного потокового протокола. RTSP определен как полноценный протокол, что означает, что с момента первого подключения клиента к потоковому серверу и до момента его отключения сервер отслеживает состояние клиента. Клиент сообщает свое состояние серверу при помощи посылки команд PLAY, PAUSE или TEARDOWN (первые две очевидны, последняя используется для отключения от сервера и закрытия сессии потоковой передачи).

После того, как связь между сервером и клиентом установлена, сервер начинает отсылку медиа в виде непрерывного потока небольших пакетов (формат таких пакетов известен под названием RTP). Размер типичного RTP пакета составляет 1452 байта, что подразумевает кодирование видеопотока в 1 мегабит в секунду (Mbps) и длительность одного кадра примерно 11 миллисекунд. В RTSP пакеты могут быть переданы либо через UDP, либо через TCP протоколы — последний предпочтителен, если файрволл или прокси блокируют UDP пакеты, однако его использование может приводить к увеличению задержки (пакеты TCP пересылаются до успешного получения).

Рисунок 1. RTSP — пример традиционного потокового протокола.

С другой стороны, HTTP, известный как протокол «без состояний». Когда клиент запрашивает некоторые данные, сервер отвечает посылкой данных, но он не будет помнить состояние клиента. Каждый запрос HTTP обрабатывается как полностью отдельная одноразовая сессия.

Сервисы Windows Media поддерживают потоковую передачу при помощи RTSP и HTTP. Но если HTTP является протоколом без состояний, то как может использоваться для потоковой передачи? Сервисы Windows Media использую модифицированную версию HTTP, известную как MS-WMSP (в сервисах Windows Media она называется Windows Media HTTP Streaming Protocol, или в общем случае, просто Windows Media HTTP). MS-WMSP использует стандарт HTTP для передачи данных и сообщений, при этом вводя состояния сессии, эффективно подключая их к протоколу потоковой передачи, например, RTSP. Сервисы Windows Media также поддерживают потоковую передачу через RTSP с 2003 года (в Windows Media Services 9 Series) через UDP и TCP. Его реализация публично задокументирована как MS-RTSP.

Из сервисов Windows Media Silverlight поддерживает доставку, основанную только на HTTP.

Наиболее важными аспектами традиционных потоковых протоколов, таких как RTSP и Windows Media HTTP (MS-WMSP), являются:

  • Сервер посылает клиенту пакеты данных исключительно в режиме реального времени — это и есть битрейт, которым закодирован поток. Например, видео, закодированное при 500 килобитах в секунду (kbps), передается клиенту на скорости примерно 500 кб/с.
  • Сервер просто посылает так много пакетов, сколько необходимо для заполнения клиентского буфера. Клиентский буфер обычно включает от 1 до 10 секунд (стандартный буфер проигрывателя Windows Media и Silverlight — 5 секунд). Это означает, что если вы приостановите потоковое видео и подождете 10 секунд, все равно только около 5 секунд видео будет загружено клиенту за это время.

Другими примерами традиционных потоковых протоколов являются проприетарный протокол передачи сообщений (RTMP, англ: Real Time Messaging Protocol) компании Adobe Systems и протокол RTSP over Real Data Transport (RDT) компании RealNetworks. Функция динамического переключения потоков (Dynamic Streaming stream-switching), реализованный в платформе Adobe® Flash® основан на протоколе RTMP и поэтому рассматривается как метод традиционного, а не адаптивного вещания.

Прогрессивная загрузка

Другая форма доставки медиа контента в Интернете — прогрессивная загрузка, которая является ни чем иным, как обычной загрузкой файла с HTTP сервера. Прогрессивную загрузку поддерживают большинство медиа проигрывателей и платформ, включая Adobe Flash, Silverlight, и проигрыватель Windows Media. Термин «прогрессивная» происходит от факта, что большинство проигрывателей клиентов разрешают воспроизведение медиа файла в то время, когда загрузка файла еще идет — до тех пор, пока файл полностью не загрузится на диск (обычно в кэш Web браузера). Клиенты с поддержкой спецификации HTTP 1.1 могут менять позицию чтения файла до завершения его загрузки путем выполнения серии запросов к Web серверу (при условии, что он также поддерживает HTTP 1.1).

Популярные Web сайты для обмена видео, включая YouTube, Vimeo, MySpace, и MSN Soapbox почти полностью используют прогресивную загрузку.

В противовес потоковым серверам, редко посылающим на клиентскую сторону более 10 секунд медиа данных за раз, HTTP Web серверы поддерживают поток данных до их полной загрузки. Если вы приостановите прогрессивно загруженное видео в начале и затем подождете, велика вероятность того, что все видео загрузилось в кэш браузера и вы сможете посмотреть полностью все видео без прерываний. Однако, у такого подхода есть обратная сторона медали — если посмотрев 30 секунд из 10 минутного видео, вы решите прекратить просмотр, то получится, что вы и ваш контент провайдер впустую потратили пропускную способность сети, равную 9,5 минутам видео. Во избежание этой провлемы, IIS 7.0 предлагает хорошее расширение, именуемое регулирование битрейта (англ: Bit Rate Throttling), позволяющее контент провайдерам регулировать скорость загрузки точно так же, как это делают потоковые сервера для снижения затрат при передаче.

Адаптивное потоковое вещание, основанное на HTTP

Адаптивное потоковое вещание — это гибридный метод доставки контента, который функционирует как потоковый сервер, но при этом основан на прогрессивной HTTP загрузке. Это весьма передовая методика, использующая HTTP, а не новый протокол. IIS Smooth Streaming и Move Networks Adaptive Stream являются примерами адаптивного вещания. Даже если две технологии используют различные кодеки, форматы и схемы шифрования, они обе полагаются на HTTP как на транспортный протокол и выполняют загрузку медиа в виде большой последовательности очень маленьких прогрессивных загрузок, а не одну большую прогрессивную загрузку.

В реализации обычного адаптивного вещания видео/аудио исходник делится на множество небольших сегментов (частей) и кодируется согласно выбранному формату. Части обычно имеют продолжительность 2-4 секунды. На уровне видео кодека это означает, что каждая часть определена в пределах GOP (англ: Group of Pictures, группа картинок — перев.) (каждая часть начинается с ключевого кадра) и не зависит от предыдущих или последующих частей/GOP. Это позволяет каждой части быть закодированной независимо от других частей.

Читать еще:  Два маршрутизатора в одной сети

Закодированные части размещаются на HTTP Web сервере. Клиент запрашивает части с Web сервера линейно и скачивает их, используя обычную прогрессивную загрузку по HTTP. Как только все части переданы клиенту, он воспроизводит эти части линейно в обратном порядке. Поскольку видео кодируется без пробелов и дублирования, части воспроизводятся как непрерывное видео.

«Адаптивная» часть этого подхода раскрывается, когда видео/аудио исходник кодируется разными битрейтами, генерируя множество частей различного размера для каждого промежутка 2-4 секунды видео. Теперь клиент может выбирать между частями различного размера. Так как Web сервера обычно доставляют данные с максимальной скоростью, клиент может оцениь пропускную способность пользовательского канала и решить, загружать ему большие или маленькие части. Размер проигрываемого/загруженного буфера является полностью настраиваемым.

Рисунок 2. Адаптивное потоковое вещание — гибридный метод доставки медиа.

Адаптивное вещание, как и другие виды HTTP доставки, имеет следующие преимущества перед обычным вещанием для поставщика контента:

  • Экономичное развертывание из-за того, что адаптивное вещание использует обычные HTTP кэши/прокси и не требует специализированных серверов.
  • Данный подход имеет лучшую масштабируемость, снимая воспрос «последней мили», так как он может гибко подстраиваться под меняющиеся условия сетей.
  • Он позволяет потребителю выбирать понравившееся качество контента, а не вынуждает провайдеров догадываться о битрейте, который понравится потребителю

Оно также имеет такие преимущества для пользователя:

  • Быстрый запуск и мгновенная перемотка, так как для этих действий требуется низкий битрейт перед переходом на более высокий битрейт.
  • Никакой буфферизации, отключений и остановки вопроизведения (если пользователь удовлетворяет требованиям минимального битрейта).
  • Непрерывная смена битрейта, зависящая только от состяния сети и возможностей CPU.
  • Гладкое воспроизведение.

Microsoft создала прототип реализации адаптивного потокового вещания, основанного на HTTP, для Web сайта телеканала NBC, посвященного Летним Олимпийским играм в Пекине (2008 год). Для того, чтобы соответствовать графику разработки проекта, реализация была очень простой. NBC использовала кодеры Digital Rapids и Anystream для создания множества файлов Windows Media Video (WMV) различного битрейта для каждого исходника. Кодеры не применяли никаких хитростей, а следовали строго по алгоритму (близкостоящие GOP, GOP равной длины, заголовки точек вхождения VC-1 и так далее.), который обеспечивал точное смещение кадров видео с различным битрейтом. Эти файлы WMV пропускались через инструмент пост-обработки, который физически делил каждый файл WMV на тысячи 2 секундных частей (файлов). Остальная часть решения заключалась в выгрузке частей на Web сервера CDN и запуске проигрывателя Silverlight, кторый был способен загружать части и вопроизводить их в правильной последовательности.

С такой реализацией NBC и Microsoft могли предложить лучшее, чем WMS, потоковое решение, используя лишь простую загрузку по HTTP. Возросшая зрительская аудитория привела к увеличению числа размещений рекламы и, следовательно, увеличению прибыли.

Однако, операторы CDN потратили сотни часов, управляя миллионами маленьких частей в своих системах. Представьте: если каждые 2 секунды видео делились на различные файлы и это повторялось для 5 доступных битрейтов, то для этого требовалось бы 150 файлов на каждую минуту видео, или 13500 файлов на 90-минутный футбольный матч!

Так что несмотря на то, что сайт Олимпиады телеканала NBC был огромным успехом для Silverlight и адаптивного потокового вещания, основанного на HTTP, довольно скоро стало очевидно, что для дальнейшего развития этой идеи и совершенствования методик управления файлами, необходимы значительные изменения.

ESP32-CAM ov2640, потоковое видео в среде Arduino IDE.

Эта статья представляет собой краткое руководство по началу работы для платы ESP32-CAM. Я расскажу как настроить веб-сервер потокового видео менее, чем за 5 минут с помощью Arduino IDE.

Примечание: в этой статье я использую пример из библиотеки arduino-esp32, но не рассматриваю как его изменить.

ESP32-камера — это очень маленький модуль камеры с чипом ESP32-S, который стоит около $ 10. Помимо камеры OV2640 и нескольких GPIO для подключения периферийных устройств, он имеет слот для карт microSD, который может быть полезен для хранения изображений, сделанных с помощью камеры, или хранения файлов.

Основные характеристики ESP32-CAM:

Беспроводной модуль — ESP32-S WiFi 802.11 b/g/n + модуль Bluetooth;

Внешнее хранилище — слот для карт micro- SD ёмкостью до 4 ГБ;

Поддержка камер OV2640 (продаётся с платой) или OV7670;

Формат изображения — JPEG (только OV2640), BMP, оттенки серого;

Контакты – 16 с интерфейсами UART, SPI, I2C, PWM

Напряжение питания — 5 В;

Потребляемая мощность:

  • при выключенной вспышке — 180 мА;
  • при включенной вспышке — 310 мА;
  • глубокий сон — 6 мА;
  • модем-сон — 20 мА;
  • лёгкий сон — 6,7 мА.

Размеры — 40,5 х 27 х 4,5 мм

Температурный диапазон:

  • рабочий: 20 – 85 ℃;
  • хранение: -40 — 90 ℃ при 90% относительной влажности.

Карты памяти на 4 Гб не было под рукой, поэтому проверить не получилось. Ставил на 16 Гб. Не сохраняет.

На следующем рисунке показаны выводы ESP32-CAM.

Есть три вывода GND и два вывода для питания: 3.3 V, либо 5V.

GPIO 1 и GPIO 3 — это последовательные контакты. Вам нужны эти контакты, чтобы загрузить код на вашу плату. Кроме того, GPIO 0 играет важную роль, поскольку он определяет, находится ли ESP32 в режиме программирования или нет. Когда GPIO 0 подключен к GND, ESP32 находится в режиме программирования.

Для программирования ESP32-камеры понадобятся следующие компоненты:

Приступим к установке, настройке необходимого ПО и прошивке ESP32. Разделим вс ё на несколько этапов:

1. Установка дополнения ESP32
В этом примере я использую Arduino IDE для программирования платы ESP32-CAM. Установите Arduino IDE, и настройте работу с ESP32. Если этого у вас не сделано, воспользуетесь следующей инструкцией:

2. Пример Кода CameraWebServer
В среде Arduino IDE выберите пример для работы с камерой для этого перейдите:

Файл > Примеры > ESP32 > Camera>CameraWebServer

Откроется пример скетча работы с камерой ESP32:

Если вы не можете найти данный пример, то можете его скачать с нашего сайта. Внизу статьи есть ссылка для скачивания материала. Внимание! Для того, чтобы скачать файлы с сайта вам нужно зарегистрироваться.

После загрузки распакуйте папку и откройте файл скетча для esp32 cam ov2640: CameraWebServer.ino.

Перед загрузкой прошивки в модуль ESP32 CAM необходимо указать ваши данные для подключения к Wi-Fi сети.

Затем убедитесь, что вы выбрали правильный модуль камеры. В данном случае используйте модель AI-THINKER Model. Для этого закомментируйте все другие модели и раскомментируйте указанную ниже:

Читать еще:  Хаб для локальной сети

Теперь код готов к загрузке на вашу ESP32.

3. Прошивка ESP32-CAM

Для прошивки я использую самый недорогой TTL программатор. И всё прошивается и работает отлично.

Подключаю всё вот по такой схеме:

Важно! GPIO 0 должен быть подключен к GND, чтобы вы смогли загрузить код.

Чтобы загрузить код, выполните следующие действия:

  • Перейдите в меню Инструменты>Плата и выберите модуль ESP32 Wrover
  • Перейдите в меню Инструменты >порт и выберите COM-порт, к которому подключен ESP32
  • В меню Инструменты >Partition Scheme , выберите “Huge APP (3MB No OTA)
  • Нажмите кнопку ESP32-CAM on-board RESET
  • Затем нажмите кнопку Загрузка, чтобы загрузить код

Важно! Если вы не можете загрузить код, то еще раз проверьте, что GPIO 0 подключен к GND и, что вы выбрали правильные настройки в меню Инструменты. Вы также должны нажать кнопку сброса на борту, чтобы перезагрузить ESP32 в режиме программирования.

4. Получение IP-адреса и подключение к камере.

После загрузки кода отключите GPIO 0 от GND. Подключите питание на 5 В. На 3,3 В у меня камера не заработала.

Откройте последовательный монитор со скоростью передачи данных 115200. Нажмите кнопку ESP32-CAM on-board Reset.

IP-адрес ESP32 должен быть выведен в последовательном мониторе.

Теперь вы можете получить доступ к серверу потоковой передачи камеры в локальной сети. Откройте браузер и введите IP-адрес ESP32-CAM . Нажмите кнопку Start Streaming, чтобы начать потоковую передачу видео.

У вас так же есть возможность делать фотографии, нажав на кнопку Get Still. К сожалению, этот пример не сохраняет фотографии, но вы можете изменить его, чтобы использовать встроенную карту microSD для хранения полученных фотографий.

Есть еще несколько настроек камеры, с которыми вы можете поиграть, чтобы настроить параметры изображения.

Если вы откроете монитор порта во время работы камеры, то вы получите подробную информацию о количестве кадров в секунду, о скорости обработки и пр.

Чем выше качество потокового вещания, тем меньше кадров. Комфортно работает при разрешении 600х800.

Можно реализовать распознавание лиц. Но, пока, в данном направлении я не экспериментировал. Как будут результаты, обязательно напишу статью, или сделаю проект.

Подписывайтесь на наш канал на Youtube и вступайте в группы в Вконтакте и Facebook.

Всем Пока-Пока. И до встречи в следующей статье.

Понравилась статья? Поделитесь ею с друзьями:

powered by leo blog …

По сути тот How-To, который я сделал можно считать баяном, так как это делали раньше и инструкций было завалом, но в инете я не нашел таких инструкций, по которым можно сразу сделать всё в три-четыре шага… И тут мне написали с очередным вопросом – могу ли я помочь в создании «очередного» интернет радио.

Инструкция описывает процесс создание интернет-радио на ОС Windows 2000, XP, Vista, Seven (7).

Для начала, если вы хотите вещать именно в интернет – то у вас должен быть реальный IP адрес (то есть должен быть виден из интернета. )

Шаг 1. Ставим SHOUTcast Server.

Соглашаемся и жмём далее … Обязательно выбираем GUI версию, а остальное по желанию … Указываем путь установки (по умолчанию он будет таков, как на картинке) … Установка завершена !

Это окно у вас не задержится и более 5-10 секунд, после чего оно закроется, откроется readme.txt и в меню «Пуск» появится папка «Programs» где и будет сам «SHOUTcast DNAS (GUI)», но прежде чем запускать его – настроим конфигурацию для его работы.

Файл конфигурации находится в папке «C:Program FilesSHOUTcast» а называется он «sc_serv.ini». Открываем его блокнотом и используя полное описание всех параметров, настраиваем по своему вкусу.

Полное описание параметров:

Несколько комментариев – основные параметры это MaxUser, Password, PortBase и PublicServer. Остальное можно оставить по умолчанию.

Шаг 2. Ставим Winamp.

Winamp – это плеер, с которого будет транслироваться вся музыка в интернет. Последнюю русскую версию всегда можно найти на сайте производителя, ну например по этому адресу http://www.winamp.com/media-player/ru. Особого внимания я акцентировать на его установке не буду – там и так всё предельно ясно и просто. Перейдём к третьему шагу!

Шаг 3. Устанавливаем SHOUTcast DSP Plug-In.

Это и есть тот плагин, который ретранслирует поток на сервер. Существует немало его аналогов, которые работают как самостоятельные плеера и dj-студии, но особого внимания я на них акцентировать не стану. Скачать последнюю версию как обычно можно на сайте производителя — www.shoutcast.com. Прямая ссылка, для тех, кто в танке — http://yp.shoutcast.com/downloads/shoutcast-dsp-1-9-0-windows.exe.

Начнём процесс установки:

Согласимся с соглашением … Здесь можно оставить всё по дефолту или снять галочку с тулбара … Укажем, где обитает сам winamp … Увидев данный вопрос можно отпраздновать установку плагина, и заодно отказаться от прочтения readme файла и приступить к настройке.

Настраиваем:

Запускаем WinAmp плеер и выбираем «Сервис=>Параметры», там выбираем

1) «DSP (Эффекты)»

2) «Nullsoft SHOUTcast Source DSP v1.9.1 [dsp_sc.dll]»

3) Откроется окно плагина «SHOUTcast Source»

Далее закрываем «Параметры проигрывателя…» и приступим к настройке.

На этом рисунке мы видим окно статуса вещания. Данный плагин способен на вещание в 5 потоков, тоесть грубо говоря он может подключиться к пяти серверам, ретранслирующим поток. Но мы будем настраивать 1, остальное – на свой вкус. Вкладка «Output» — там есть поле «Output», где можно выбрать интересующий нас канал, «Status» — где можно увидеть байты переданной информации, галочку «Connect at Startup» — подключаться автоматически ну и сама кнопка «Connect» — которая говорит сама за себя. Далее мы видим нажатую кнопку «Connection» где мы можем настроить «Address» — адрес сервера к которому мы подключаемся (в нашем случае оставим как и есть, так как сервер стоит на нашей же машине), «Port» — порт, к которому нужно подключиться, пароль доступа к серверу (это то что вы прописали в параметрах сервера в строчке «Password») и выбираем нужный кодировщик звука «Encoder». Ниже есть галочка «Automatic Reconnection on Connection Failure», которая в случае обрыва подключения будет снова подключать к серверу и поле «Reconnection timeout» — там указываем секунды таймаута. «Yellowpages» — Там мы указываем основную информацию о нашем радио. С картинки я думаю всё понятно, поэтому расписывать все пункты не стану.

Вкладка «Encoder» — тут мы настраиваем кодировщик звука. В «Encoder Type» мы выбираем из трёх кодировщиков наиболее подходящий, а именно Mp3. «Encoder Settings» — тут мы выбираем то качество вещания, на которое способен наш интернет канал. Самое оптимальное, это «128/44100/Stereo». Вкладка «Input» — Тут мы выбираем, откуда будет идти музыка на сервер, из Winamp-а или со звуковой карты.

Читать еще:  Kmsauto принудительная установка gvlk

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

Универсальный сервер сетевой загрузки и установки. Начало.

Данная статья посвящена описанию настройки сервера сетевой загрузки и установки с его помощью разнообразных ОС.

Каждому системному администратору, даже не большой локальной сети, приходиться устанавливать или обновлять разнообразные операционные системы. Довольно часто конфигурация оборудования настолько разнообразна, что ни о какой установке ОС с заранее подготовленного образа установленной и настроенной системы, речи быть не может. Для компаний занимающихся разработками клиент-серверного программного обеспечения работа с СУБД Sybase SQL Anywhere [14], Oracle Database [13] и т.д. список ОС для тестирования серверной части продукта может быть очень большим. Работы по созданию кроссплатформенных приложений тоже требуют наличия разнообразных платформ. В этот список могут входить как все версии серверных и десктопных ОС от Microsoft, так и целый зоопарк популярных операционных систем семейства Unix. Так же время от времени возникает необходимость решения таких «насущных» задач как восстановление систем, загрузчиков, удаление вирусов и т.д. и т.п. Для этого администратору удобно иметь под рукой как минимум два live-дистрибутива (Windows и Unix). Из всего выше сказанного следует, что администратору необходимы носители на которых располагаются все эти ОС, а это достаточно большое количество дисков. Тем более, что в разнообразные системы желательно интегрировать последние сервис-паки и обновления, которые выходят достаточно часто. Это приводит к тому, что носители периодически необходимо перезаписывать, что неэффективно с точки зрения затрат времени.
Следует также отметить, что, из соображений безопасности и по причине экономии при комплектовании рабочих станций не всегда устанавливается DVD привод, а многие системы инсталлируются с DVD дисков. В такой ситуации облегчить жизнь системному администратору поможет сервер сетевой загрузки и установки операционных систем. В интернете существует огромное количество статей и сайтов посвященных этой теме. Но во многих случаях описание процесса установки уже не соответствует новым реалиям, так как написаны достаточно давно. После недавнего внедрения системы сетевой установки на новом сервере, возникло желание поделиться этим опытом.

Сетевая установка

Существует два стандартных варианта решения этой задачи. Для установки операционных систем семейства Windows существуют всем известные WDS (Windows Deployment Services) и SMS (Microsoft System Management Server). У Unix-подобных систем с давних пор была возможность установки разнообразными методами, в том числе и по сети. Нет сомнения, что для развертывания и установки Windows систем WDS удобен и выполняет свои обязанности, но для инсталляции операционных систем семейства Unix он не очень подходит.

Как известно, основным компонентом сервера сетевой установки является TFTP сервер. Его расположение (IP — адрес) указывается при помощи параметров DHCP. Если DHCP-сервер в вашей сети один, то перенаправлять сетевой загрузчик то на один TFTP сервер, то на другой для загрузки не получится. Поэтому нельзя объявить сразу два источника установки – такой сервер должен быть один. Существует решение для установки Linux систем с помощью Windows WDS — проект WDSLINUX [1]. Его основной минус заключается в том, что не все дистрибутивы поддерживают подключение по smb и http протоколу к серверу установки (для примера http://www.openfiler.com) . Обычно такие дистрибутивы требуют подключения по nfs. Мне хотелось получить универсальную схему для установки разных версий Microsoft Windows и Linux, а так же сетевую загрузку разнообразных «спасательных» систем.

Для начала немного теории. Принцип сетевой установки очень прост. При включении компьютера управление передается ПЗУ сетевой карты. Обычно используется среда PXE (Pre-Execution Environment). После распаковки в оперативную память, она активирует сетевую карту и начинает посылать широковещательный запрос в сеть для нахождения сервера DHCP. При ответе DHCP, PXE запрашивает у него IP адрес, который необходимо присвоить сетевой карте, маску сети, IP адрес сервера TFTP, имя файла для загрузки и т.д. Далее, если ответы на вопросы получены при помощи встроенного TFTP-клиента, PXE обращается к указанному серверу с запросом на получение указанного в параметрах файла. Если файл найден и получен то управление передается на него. Всеми последующими действиями будет руководить именно он.

Широкое распространение получил проект Питера Анвина (Peter Anvin) под названием — Syslinux [2]. Он имеет простые конфигурационные файлы и включен в поставку многих Linux дистрибутивов. На официальном сайте дается такое определение этому пакету: «SYSLINUX является загрузчиком для операционных системы Linux, который работает на MS-DOS/Windows FAT файловых системах. Он предназначен для простой загрузки и установки Linux. А также для создания спасательных и других специальных загрузочных конфигураций». В этот пакет входит PXELINUX, который является производной от SYSLINUX и используется для загрузки Linux с сетевого сервера. PXELINUX соответствует Intel PXE (Pre-Execution Environment) спецификации. Основой PXELINUX является файл «pxelinux.0» — это и есть загрузчик. Этот файл располагается в корне TFTP сервера. Его конфигурационные файлы размещаются в папке «/tftpboot/pxelinux.cfg/». После запуска на клиентской машине «pxelinux.0» скачивает с сервера и отображает файл «message». Это простой текстовый файл, в котором описаны доступные варианты загрузки. Затем он скачивает свой конфигурационный файл («/tftpboot/pxelinux.cfg/default») и переходит в режим ожидания ввода имени предоставленных конфигураций. Имя раздела пишется после метки label. В ответ на ввод имени варианта установки «pxelinux.0» начинает выполнять действия описанные в нем. Для создания простого текстового меню файл «/tftpboot/pxelinux.cfg/default» может выглядеть так:

default pe
label xpinstall # Установка Windows XP
kernel startrom.0
label win7 # Установка Windows 7
kernel sources/pxeboot.0

label pe # Запуск Live-CD WindowsPE
pxe keep
kernel pe.0
append initrd=winpe.wim ramdisk_size=262144
label suse112 # Установка openSuSe11.2
kernel suse/suse112x32/linux
append initrd=suse/suse112x32/initrd ramdisk_size=65536 install=nfs://192.168.1.7/ srv/tftpboot/suse/suse112x32/CD1/

Так же возможно создание графического меню выбора операционных систем (рис.1-3).

Рисунок 2 Меню «спасательных» систем и утилит

Рисунок 3 Меню установки ОС

Ссылка на основную публикацию
Adblock
detector