WTware клиент RDP

[quote="Belov-SL"]2Antonio:
Не вполне вас понял, но кажется, что у меня для этого будет слишком много клиентов.[/quote]
Переписал свой предыдущий пост, надеюсь, стало понятней.
Но конкретно для вас в нем пользы мало, т.к. вашу задачу из первого поста я понял неправильно, и для двойной загрузки мой вариант не подойдет.

[quote="Belov-SL"]В Vendor class identifier "wtware" должно указано именно как класс вентора и выглядеть как "0000 / 77 74 77 61 72 65 / wtware" (Код / Двоичные данные / ASCII)?[/quote]
Да, вроде так. 6 байт.

Спасибо за быстрые ответы!

2aka:
Используемый DHCP-сервер (Windows Server 2003 R2) не получилось с наскока заставить выдавать нужные параметры. Буду разбираться. В Vendor class identifier "wtware" должно указано именно как класс вентора и выглядеть как "0000 / 77 74 77 61 72 65 / wtware" (Код / Двоичные данные / ASCII)?

2Antonio:
Не вполне вас понял, но кажется, что у меня для этого будет слишком много клиентов. Предполагается 90-100 рабочих мест перевести в терминальный режим, а еще для 120-150 обеспечить дуалбут (в свою ОС и к терминальному серверу).

Я когда-то для себя выпросил эту фишку в WTware, но в итоге до сих пор на практике ее не применил.

Фишка следующая: можно указать встроенному в втварь DHCP-серверу отвечать только на запросы МАКов уже настроенных тонких клиентов. Это позволяет внедрять втваре-центр и его встроеные сервисы в тех сетях, где уже работает DHCP-сервер. WTware DHCP будет обслуживать только "своих" тонких клиентов, и ничего не отвечать на запросы от неизвестных ему машин/МАКов.

Чтобы тонкие клиенты получали адреса и опции только у WTware-DHCP-сервиса, есть два варианта.

(1) Прописать черный или белый списки МАКов на существующем DHCP-сервере так, чтобы он не обслуживал тонкие клиенты WTware.

(2) Под свою тогдашнюю задачу я вроде наковырял в конфиге уже поднятого в моей сети DHCP-сервера известной фирмы ISC какие-то опции, позволяющие давать ответ всем спросившим, но с задержкой. Для тонких клиентов с WTware этот ответ стал бы вторым, и уже не актуальным, потому что клиент уже начал загружаться с помощью DHCP-сервера втваре. Для всех остальных клиентов он стал бы первым. Небольшая пауза в загрузке или выдаче IP для меня была не критична. Но, повторюсь, до практической реализации (по не зависящим от меня причинам) не дошло.

Втварь не имеет никакой возможности узнать, что было до неё в цепочке. Втварь ни о каких цепочках не знает.

Втварь делает запрос к dhcp. dhcp отвечает втвари. Втварь берёт префикс из 067 параметра dhcp, и от этого префикса ищет конфиги и остальное. Версии до 4.9 держали отдельные конфиги у каждой версии, 4.9 и новее ищут общие для всех версий конфиги, поэтому номер версии от префикса отрезается. А бинарные пакеты от версии зависят, потому будут искаться в wtware/5.0.7/packages/

Если DHCP умный и структура каталогов очень ценна, то можно поиграть с Vendor class identifier. У втвари в Vendor class identifier написано wtware, по этому полю умный DHCP может различать запрос начального загрузчика и запрос втвари. На запрос втвари соответственно отдавать длинный путь к wtware.pxe. Но для цепочки это никак не поможет.

Не знаю, как сделать цепочку.

label wtware4pxe
    MENU LABEL WTware 4.5.24 PXECHAIN
    kernel boot/syslinux/pxechain.com
    APPEND ::wtware/4.5.24/pxelinux.0
label wtware4cfg
    MENU LABEL WTware 4.5.24 CONFIG
    CONFIG wtware/4.5.24/pxelinux.cfg/default
    APPEND wtware/4.5.24/
label wtware5pxe
    MENU LABEL WTware 5.0.7 PXECHAIN
    kernel boot/syslinux/pxechain.com
    APPEND ::wtware/5.0.7/wtwarepxe.0
label wtware5cfg
    MENU LABEL WTware 5.0.7 CONFIG
    CONFIG wtware/5.0.7/pxe.cfg
    APPEND wtware/5.0.7/

boot/
    pxelinux/
        modules/
    syslinux/
configs/ (не для WTware!)
pxelinux.cfg/
    default
wtware/
    4.5.24/
        configs/
        packages/
        pxelinux.cfg/
        wtshell/
        pxelinux.0
        wtshell.nbi
    5.0.7/
        Everyone/
        packages/
        Terminals/
        debug.pxe
        pxe.cfg
        pxem.cfg (модифицированый pxe.cfg для использования совместно с vesamenu.c32)
        wtware.nbi
        wtware.pxe
        wtwarepxe.0 (копия wtware.pxe)
memdisk
pxelinux.0

Доброго времени суток!

У нас активно используется загрузка по сети через PXE (SYSLINUX 4.07), поэтому надо встроить запуск WTware в уже существующую систему. Однако это не удалось сделать ни с помощью директивы CONFIG, ни с помощью pxechain.com:
[code]label wtware4pxe
MENU LABEL WTware 4.5.24 PXECHAIN
kernel boot/syslinux/pxechain.com
APPEND ::wtware/4.5.24/pxelinux.0
label wtware4cfg
MENU LABEL WTware 4.5.24 CONFIG
CONFIG wtware/4.5.24/pxelinux.cfg/default
APPEND wtware/4.5.24/
label wtware5pxe
MENU LABEL WTware 5.0.7 PXECHAIN
kernel boot/syslinux/pxechain.com
APPEND ::wtware/5.0.7/wtwarepxe.0
label wtware5cfg
MENU LABEL WTware 5.0.7 CONFIG
CONFIG wtware/5.0.7/pxe.cfg
APPEND wtware/5.0.7/
[/code]
В обоих случаях WTware почему-то начинает искать конфигурационные файлы в корне TFTP.

При запуске загрузчиков (wtware/4.5.24/pxelinux.0 и wtware/5.0.7/wtwarepxe.0) напрямую через указание в параметре 067 WTware 4.5.24 Lite стартует нормально и берет конфигурационные файлы из wtware/4.5.24/configs , а WTware 5.0.7 пытается искать конфигурационные файлы в папках wtware/terminals и wtware/everyone .

Существующая структура каталогов (без папок не относящихся и не влияющих на WTware):
[code]boot/
pxelinux/
modules/
syslinux/
configs/ (не для WTware!)
pxelinux.cfg/
default
wtware/
4.5.24/
configs/
packages/
pxelinux.cfg/
wtshell/
pxelinux.0
wtshell.nbi
5.0.7/
Everyone/
packages/
Terminals/
debug.pxe
pxe.cfg
pxem.cfg (модифицированый pxe.cfg для использования совместно с vesamenu.c32)
wtware.nbi
wtware.pxe
wtwarepxe.0 (копия wtware.pxe)
memdisk
pxelinux.0
[/code]
Есть ли способ указать размещение конфигурационных файлов или заставить загрузчик работать при запуске по цепочке так же, как и при прямом? Структуру каталогов перестраивать очень не хочется.