Авторские права на русский перевод этого текста принадлежат 00 ASPLinux Все права зарезервированы.
Этот документ является частью проекта Linux HOWTO.
Авторские права на документы Linux HOWTO принадлежат их авторам, если явно не указано иное. Документы Linux HOWTO, а также их переводы, могут быть воспроизведены и распространены полностью или частично на любом носителе, физическом или электронном, при условии сохранения этой заметки об авторских правах на всех копиях. Коммерческое распространение разрешается и поощряется; но, так или иначе, автор текста и автор перевода желали бы знать о таких дистрибутивах.
Все переводы и производные работы, выполненные по документам Linux HOWTO, должны сопровождаться этой заметкой об авторских правах. Это делается в целях предотвращения случаев наложения дополнительных ограничений на распространение документов HOWTO. Исключения могут составить случаи получения специального разрешения у координатора Linux HOWTO, с которым можно связаться по адресу приведенному ниже.
Мы бы хотели распространить эту информацию по всем возможным каналам. Но при этом сохранить авторские права и быть уведомленными о всех планах распространения HOWTO. Если у вас возникли вопросы, пожалуйста, обратитесь к координатору проекта Linux HOWTO по электронной почте: linux-howto@metalab.unc.edu> или к координатору русского перевода Linux HOWTO компании ASPLinux по адресу linux-howto@asplinux.ru>
Команды ci(1) и co(1) используются для проверки старых и измененных файлов, при помощи сравнения их с архивом RCS. Команда ci(1) может быть использована для проверки всех архивов. В самой простой форме эти команды требуют только имя файла: ci название_рабочего_файла и co название_рабочего_файла
Команда ci -l название_рабочего_файла проверяет новый файл, с включенной опцией изменения архивов, а co -l название_рабочего_файла выполняется автоматически. Это означает, что команда ci -l проверяет и старые файлы. ci -u название_рабочего_файла выполняет проверку нового и предыдущей версии, при выключенной опции изменения файлов. Во всех случаях пользователю предоставляется журнал изменений.
ci(1)также создает архив RCS, если он не был создан до этого.
Если вы не указываете номер изменения, ci(1) увеличивает номер версии на единицу, по отношению к предыдущему, и записывает измененный файл туда. Если вы сами указываете номер версии, то он не должен быть меньше, чем существующий. ci(1) также может произвести ветвление версии, если вы укажете несуществующую ветвь версии. Прочтите руководство к ci(1) и co(1)
для выяснения деталей.
ci(1) и co(1) имеют несколько опций для интерактивного и пакетного режима использования.
Скачайте дистрибутив RCS версии 5.7. Он находится по адресу
ftp://sunsite.unc.edu/pub/Linux/devel/vc/rcs-5.7.src.tar.gz
или на зеркалах этого сайта. После того, как вы разархивировали все в каталог исходных текстов, вам надо настроить RCS под свою систему. Это можно сделать, при помощи скрипта configure, находящегося в каталоге исходных текстов. Для этого надо его запустить. Он создаст Makefile и соответствующий вашей системе conf.sh. Затем вы можете набрать make install, который создаст программу. В принципе, это лучше сделать, как пользователь root, чтобы разместить все в нужные каталоги.
Robert Kiesling
Перевод: Михаил Корепанов, ASPLinux
В этом документе объясняется, как установить и использовать RCS (GNU Revision Control System), под Linux. В нем также затронуты темы установки утилит diff(1) и diff3(1), которые необходимы для работы RCS. This document may be reproduced freely, in whole or in part, provided that any usage of this document conforms to the general copyright notice of the HOWTO series of the Linux Documentation Project. See the file COPYRIGHT for details. Посылайте все предложения, добавления и сообщения об ошибках kiesling@terracom.net, чтобы я мог их включить в последующие версии.
Программа rlog(1) обеспечивает пользователя информацией об архиве и журналом изменений. Командой rlog work_file_name вы выведете названия версий файла, дату его создания и авторские userids. А также вы можете указать некоторые опции файла относящиеся к просмотру.
Функция контроля версии (Version Control) у emacs(1) является ярким примером использования RCS. Это в особенности относится к Версии 19.34 GNU Emacs, который поставляется с большинством дистрибутивов Linux. Когда вы редактируете файл, при помощи emacs(1), он регистрируется RCS, команда vc-toggle-read-only (по умолчанию C-x C-q ) проверит версию файла, а затем это сделает RCS. Emacs откроет буфер, в котором вы можете написать сообщение в журнал RCS. Для того, чтобы закрыть этот журнал и продолжить процесс проверки, есть команда C-c C-c.
Если на файле стоит опция запрещения редактирования RCS, вы можете ее снять, редактируя его в emacs(1). Вы можете проверить файл при помощи, Version Control командой % в режиме меню буфера.
Для уточнения деталей прочтите руководство к GNU Emacs.
Программа rcs(1) создает архивы и изменяет их атрибуты. Все опции rcs(1)
описаны в руководстве rcs(1).
Самый простой способ создать архив - это сначала mkdir RCS в текущем каталоге, затем командой rcs -i название_рабочего_файла
создать архив. Она создает архив под именем ./RCS/название_рабочего_файла,v и запрашивает описание архива, но не помещает туда сам архив. вы можете включить и выключить изменение архивов командами rcs -L название_рабочего_файла
и rcs -U название_рабочего_файла
соответственно. Есть и другие опции для управления доступом к архивам, указания формата и нумерации версий, о которых рассказано в руководстве к rcs(1).
RCS требует для работы diff(1) и diff3(3) для создания diff-файлов, отражающих изменения в файлах. У вас должны быть установлены эти утилиты, но, в любом случае, при установке RCS, программа установки проверит их наличие.
Эти утилиты (скомпилированные) можно взять на:
ftp://sunsite.unc.edu/pub/Linux/utils/text/diffutils-2.6.bin.ELF.tar.gz
или на зеркалах этого сайта. Если вам потребуется скомпилировать исходник diff(1), то он находится на: ftp://prep.ai.mit.edu/pub/gnu/diffutils-2.7.tar.gz
или с зеркал этого сайта.
Если вы будете устанавливать скомпилированный diff(1), то понадобятся установленные библиотеки ELF. Для уточнения этого вопроса прочтите ELF-HOWTO.
co(1) поддерживает ключевые слова базы данных RCS, которая расширяется при проверке файла. Ключевое слово $Id$ в документе включает в себя имя файла, номер версии, дату проверки, автора, статус проверки и имя того, кто изменял права на внесение поправок в документ. Вместе с ключевым словом, $Log$
выдаст журнал изменений.
Эти ключевые слова могут использоваться, как идентификационный критерий при поиске в архиве RCS. Прочтите руководство к ident(1) для уточнения деталей.
ППЗУ удаленной загрузки существуют достаточно давно, но, до недавних пор, они продавались исключительно с бездисковыми станциями. С 1996 года этот How-to утверждает, что BootPROM значительно более интересны при использовании в машинах с локальным жестким диском, потому что они позволяют использовать плюсы и тех, и других:
ППЗУ удаленной загрузки позволяет иметь более "живучие" конфигурации, потому что с ним компьютер загружается всегда одинаково, не зависимо от вирусов или разрушения таблицы разделов. Он может использоваться даже (как у нас) для очистки диска до загрузки операционной системы.
Локальный диск может сделать конфигурацию более эффективной, потому что он может сократить сетевой трафик при помощи кэширования, и позволяет сделать подкачку более эффективной.
Мы рады видеть на сегодняшний день, что многие производители компьютеров пришли к тому же выводу и внесли BootPROM в стандартную конфигурацию новых компьютеров.
Заметьте, что вы можете использовать утилиты, описанные ниже, по-старому, в качестве простого загрузчика ядра/электронного диска, даже на бездисковых компьютерах. Однако, мы бы не рекомендовали, такое их использование.
Эти три названия относятся к трем вариантам одной и той же программы, различающихся в следующем:
BpBatch - это специальная программа, которую можно запустить из BootPROM до загрузки операционной системы. Она состоит из двух частей: bpbatch.P - динамического загрузчика, и bpbatch.ovl - собственно самой программы. BpBatch предоставляет возможность работать с дисками и файлами на них, при помощи собственной встроенной поддержки FAT16, FAT32 и Ext2fs, а также с сетевыми ресурсами, при помощи BootPROM TFTP API. BpBatch был собран в DOS, при помощи Borland C 5.0 и Turbo Assembler 3.2.
MrBatch - это DOS/Linux-версия BpBatch. Все команды, известные BpBatch, обрабатываются MrBatch и наоборот. Она бывает очень полезна, если вы хотите проверить работу своих пакетных скриптов из DOS/Linux. В DOS, MrBatch эмулирует удаленный доступ к файлам, при помощи ОС, если BootPROM не доступен. В Linux, BootPROM недоступен вообще, но MrBatch эмулирует его работу, при помощи встроенной в Linux поддержки IP, или, в крайнем случае, при помощи ОС. MrBatch был собран в Linux при помощи GCC 2.7.2.1, и в DOS, при помощи Borland C 5.0 и Turbo Assembler 3.2.
MrZip - это интерпретатор, обрабатывающий дополнительный набор команд языка MrBatch, служащий для создания образов дисков. В MrZip
ограниченный доступ к удаленным файлам заменен на полноценный доступ к файлам, при помощи ОС. В MrZip не встроена поддержка VESA. MrZip был собран в Linux, при помощи GCC 2.7.2.1, и в DOS, при помощи Borland C 5.0 и Turbo Assembler 3.2.
Все программы имеют одинаковый набор возможных опций. MrBatch и MrZip берут их из командной строки, а MrBatch берет их из опции 155 BOOTP. Список возможных опций:
[-x] [-l] [-b] [-v] [-w] [-i] [базовое_имя_скрипта] |
где:
-x запрещает использование расширенной памяти
-l запрещает использование набора символов ISO-latin-8859-1 в качестве стандартного
-b запрещает обнаружение BootPROM (вызывающее инициализацию флоппи-диска в DOS)
-v запрещает обнаружение VESA (вызывающее переключение в полноэкранный режим в Windows 95)
Black 0 (Черный) Blue 1 (Синий) Green 2 (Зеленый) Cyan 3 (Голубой) Red 4 (Красный) Magenta 5 (Фиолетовый) Brown 6 (Коричневый) LightGray 7 (Светло-серый) DarkGray 8 (Темно-серый) LightBlue 9 (Светло-синий) LightGreen 10 (Светло-зеленый) LightCyan 11 (Ярко-голубой) LightRed 12 (Ярко-красный) LightMagenta 13 (Светло-фиолетовый) Yellow 14 (Желтый) White 15 (Белый) |
"help.bpb" - это файл help.bpb в каталоге /tftpboot "gifs/MyImage.gif" - этой файл в каталоге /tftpboot/gifs |
"198.76.54.32:help.bpb" |
"198.70.0.1/198.76.54.31:help.bpb" |
"198.76.54.32@89:getpasswd/smith" |
"C:\\autoexec.bat" "C:/config.sys" "/mnt/net/usr" |
logdir "{:-1}" |
clean -1 |
Когда клиентский компьютер включается, он производит стандартную проверку системы до того, как управление передается TCP/IP Bootprom или PXE Boot ROM.
ППЗУ удаленной загрузки посылает запрос BOOTP/DHCP, чтобы узнать параметры IP-конфигурации.
Если сервер узнает компьютер, пославший запрос, он посылает обратно BOOTP/DHCP-ответ с различной информацией: IP адрес клиента, шлюз по умолчанию и образ загрузочного диска, который нужно использовать.
В случае PXE Boot ROM, может существовать кое-какой дополнительный обмен информацией между клиентом и сервером до полного определения параметров загрузки.
После этого BootPROM скачивает загрузочный образ с сервера, используя протокол TFTP. Этот образ представляет из себя небольшую программу bpbatch, наш интерпретатор пакетных файлов загрузки систем.
Затем запускается наш интерпретатор пакетных файлов. К этому моменту он единственный находится в памяти. Еще не загружена ни одна операционная система, кроме дозагрузочного исполнительного окружения, формируемого Boot ROM.
Интерпретатор обрабатывает ответ BOOTP/DHCP в поисках различных опций, и, иногда, имени пакетного файла, который надо исполнить.
В соответствии с инструкциями пакетного файла он, например:
Загрузить национальную раскладку клавиатуры
Произведет авторизацию пользователя на сервере (Unix, Radius или Windows NT)
Даст возможность пользователю выбрать операционную систему
В соответствии с выбранной операционной системой, он создаст разделы на жестком диске и произведет быстрое форматирование некоторых разделов
Проверит, имеется ли соответствующий компрессированный образ выбранной ОС в конце жесткого диска. Если нет, то загружает его, при помощи TFTP
Разархивирует выбранную ОС на основной раздел
Если ОС - это Linux, загрузит ядро и запустит его
Если ОС - это DOS или Windows, то просто позволит компьютеру загрузиться со свежего жесткого диска
Для DOS и Windows 3.1, мы используем бесплатный Microsoft LanManager для DOS (поищите в сети ближайшее зеркало этой программы; дистрибутив состоит из трех файлов, названных от disk1 по disk4) в качестве SMB-клиента. Microsoft LanManager поддерживает динамическую конфигурацию, при помощи DHCP. После входа в систему пользователь оказывается в DOS и затем обычным образом может запустить Windows 3.1, набрав традиционную команду win. Заметьте, что с этого момента DOS и Windows 3.1 выглядят так, как будто установлены на локальной машине.
На сервере вам понадобится настроить следующее:
BOOTP/DHCP-сервер
Возможно - Прокси- DHCP сервер
TFTP-сервер
Замечание для пользователей PXE-совместимых BootPROM: После нескольких часов изнурительных поисков мы обнаружили, что PXE-BootPROM версии ранее 0.99 не очень точно поддерживают IP-протокол и отказываются понимать все пакеты, имеющие установленный флаг Не фрагментировать (Don't Fragment)
(DF). Это означает, что вам надо на сервере запретить опцию Path MTU Discovery, или Boot ROM не увидит эти пакеты. В Solaris-е используйте команду ndd /dev/ip ip_path_mtu_discovery, чтобы узнать, включена ли эта опция, и команду ndd -set /dev/ip ip_path_mtu_discovery 0, чтобы эту опцию выключить. Однако, эти команды не работают для широковещательных пакетов (Спросите SUN, почему) Это означает, что работать будет только TFTP, но не DHCP :-(. Intel недавно исправил эту ошибку - если вы купили свой компьютер позже Июня 1998 года, то, скорее всего, у вас эта ошибка исправлена.
Настройка DHCP
Задачей DHCP-сервера является выделение клиенту IP-адреса и указание ему загрузить с TFTP-сервера файл bpbatch.P. DHCP в данном случае действует, как дополнение к протоколу BOOTP. Если вы используете TCP/IP BootPROM фирмы InCom, то вы можете обойтись без DHCP (используя старую версию BOOTP-сервера).
На Windows NT вы, вероятнее всего, будете использовать встроенный DHCP-сервер. Если у вас TCP/IP BootPROM фирмы InCom, то вам придется использовать одну хитрость, чтобы указать имя загрузочного файла (подробную информацию смотрите на веб-сайте фирмы InCom). Если же у вас PXE-совместимое ППЗУ, то вам понадобится Прокси-DHCP-сервер, но никаких дополнительных хитростей не потребуется, потому что имя загрузочного файла будет передаваться Прокси-DHCP-сервером.
В Linux лучшим будет стандартный DHCP-сервер производства Internet Software Consortium. Если у вас PXE- BootPROM, то, в дополнение к обычным опциям, вам придется указать следующее:
option dhcp-class-identifier "PXEClient"
option vendor-encapsulated-options ff;
Marc Vuilleumier Stuckelberg
David Clerc
Перевод: Станислав Рогин, ASPLinux
В этом документе содержится информация о том, как создать защищенный кластер PC, основанный на сервере и позволяющий каждому клиенту выбирать при загрузке компьютера необходимую операционную систему. Основой подобной конфигурации является программа, базирующаяся на BootPROM, позволяющая пользователю выбирать при загрузке один из образов загрузочного диска. Ее можно реализовать, при помощи InCom TCP/IP BootPROM (дополнительный компонент, подходящий почти ко всем сетевым картам) или любого PXE-совместимого BootROM (он часто бывает установлен в компьютеры со встроенными сетевыми картами). Последнюю версию этого документа (со ссылками на программы и сопутствующие материалы) можно найти по адресу http://cuiwww.unige.ch/info/pc/remote-boot/howto.html. В том же каталоге находятся версии этого документа в формате Linuxdoc-SGML, DVI и PostScript. Если вы хотите, чтобы вам присылалась информация о дальнейшем развитии проекта, пишите по адресу David.Clerc@cui.unige.ch.
Сначала мы настроим часть, общую для всех операционных систем - интерпретатор пакетных файлов BpBatch. После этого для каждой операционной системы мы сделаем следующее:
Настроим отдельную клиентскую машину
Сохраним его конфигурацию на сервере
Протестируем его работу в качестве клиента с удаленной загрузкой
Адаптируем эту настройку для любой подобной клиентской машины
После того, как мы все это проделаем, мы получим возможность настройки любой дополнительной клиентской машины путем простой установки в его сетевую карту ППЗУ удаленной загрузки (если его там еще нет) и добавлением одной строки в файл конфигурации DHCP.
В наших примерах мы предполагаем, что у вас есть жесткий диск, объемом не менее 1,4 Гб. Если у вас диск меньшего размера, то уменьшите размеры разделов, но не забудьте оставить свободными несколько сот мегабайт в конце диска, предназначенных для специального кэш-раздела. Более того, кэш всегда начинается с цилиндра, следующего за последним занятым стандартными разделами цилиндра, поэтому, если вы не будете использовать один и тот же размер стандартных разделов для всех ОС, то вам придется всегда загружать с сети необходимые файлы (кэш, в этом случае, очищается).
Никогда не отчаивайтесь. Если вы не можете заставить это все работать, сначала взгляните в главу Проблемы и их решение - возможно, решение находится там (возьмите самую свежую версию этого документа). Затем посетите форум BpBatch. Может быть у кого-то возникали подобные трудности, и ответ находится в форуме по адресу http://cuiwww.unige.ch/info/pc/remote-boot/forum/. Если вы не нашли там ответ на свой вопрос, попытайтесь последить за сетевым трафиком, на предмет проблем с передачей данных в сети (используйте tcpdump на Linux или snoop
на Solaris). Если и это не поможет, то можно послать письмо по адресу David.Clerc@cui.unige.ch или Marc.VuilleumierStuckelberg@cui.unige.ch. Если ваша проблема действительно относится исключительно к конфигурированию удаленной загрузки, и мы не перегружены, то попытаемся решить вашу проблему.
Чтобы установить Linux, вам понадобится загрузочный флоппи-диск, идущий в комплекте поставки дистрибутива RedHat Linux. В BpBatch входит команда, позволяющая загрузить систему с флоппи: FloppyBoot.
Установите на клиентскую машину RedHat Linux, включая поддержку сети, и все пакеты, которые могут понадобиться. Вы также можете пересобрать ядро специально для клиентской машины, но это не обязательно.
Неплохой идеей будет включить поддержку BOOTP в ядро, чтобы не настраивать IP-адрес клиента вручную.
Чтобы уменьшить нагрузку на сеть, используйте filecache для кэширования на жестком диске файлов, взятых с NFS. Грубо говоря, принцип файлового кэша состоит в следующем - когда эта система встречает, в подкаталоге cache, символьную ссылку на файл, она заменяет его на сам файл. Если это каталог, то для каждого элемента каталога создается символьная ссылка на источник на сервере. Filecache был написан компанией Unifix GmbH, и является частью Unifix Linux 2.0. Это некоммерческий продукт, и все необходимые файлы можно взять по адресу http://cuiwww.unige.ch/info/pc/remote-boot/soft/filecache.tar.gz. Для того, чтобы использовать filecache вам надо
внести изменения в ядро (патч patch-filecache), включить поддержку filecache в make config, и пересобрать ядро
скопировать исполняемый файл filecache в /sbin
создать точку подключения /mnt/nfs (используя mkdir)
скопировать файл filecache.conf в /etc. Этот файл содержит следующие строки: Max 100 MB 50 % # Cache /mnt/nfs/usr /usr Cache /mnt/nfs/opt /opt
скопируйте содержимое каталогов /usr и /opt на сервер, экспортируйте их в режиме "только чтение" с флагом anon=0 (для того, чтобы root имел к ним доступ), и подключите к /mnt/nfs (добавьте соответствующую строку в /etc/fstab)
переименуйте /usr в /usr.orig
создайте символьную ссылку /usr на /mnt/nfs/usr
переименуйте /opt в /opt.orig
создайте символьную ссылку /opt на /mnt/nfs/opt
проверьте, чтобы /usr и /opt не были пусты, и в них было правильное содержание
Скачайте программу BpBatch в любом формате: .zip или .tar.gz. Ее можно найти по адресу
http://cuiwww.unige.ch/info/pc/remote-boot/soft/bpb-exe.zip
http://cuiwww.unige.ch/info/pc/remote-boot/soft/bpb-exe.tar.gz
Также по запросу там можно получить и исходные тексты программ (Assembler и C).
В каталоге /tftpboot сервера поместите три специальных загрузочных образа, которые вместе составляют предзагрузочный пакетный интерпретатор:
bpbatch.P, динамический загрузчик (сохраните верхний регистр расширения!)
bpbatch.ovl, перемещаемый интерпретатор
bpbatch.hlp, файл помощи
Затем добавьте строку в файл конфигурации DHCP, установив загрузочный файл в "bpbatch.P". Задайте дополнительную опцию производителя 155 (десятичное 155), присвоив ей значение "-i" (в стандартном DHCP-сервере это задается командой option option-155 "-i";. Эту строку bpbatch воспринимает в качестве командной, в которой -i означает "интерактивный".
Включите клиентский компьютер. Через некоторое время вы увидите
Копирайт BootPROM
Строку DHCP, означающую, что машина ожидает ответ DHCP
Строку TFTP, означающую, что машина ожидает первый пакет от TFTP
Строку Loading BpBatch в процессе загрузки интерпретатора
После этого вы увидите нашу заставку, за которой последует красивое приглашение.
Примите наши поздравления! Вы успешно запустили интерпретатор пакетных файлов... Если вам интересно, что вы можете сделать с его помощью, то читайте следующую главу. Если же вы торопитесь, пропустите ее и перейдите к разделу "Установка вашей операционной системы". Если у вас возникли проблемы с интерпретатором, запустите команду help.
Заметьте, что можно использовать этот же интерпретатор в DOS и Linux, запустив программу MrBatch. Существуют, правда, незначительные различия этих версий - в Linux-версии нет поддержки графики, а DOS-версия может посылать BOOTP- и TFTP-запросы только в том случае, если BootPROM не скрыт операционной системой.
Неплохо было бы прочитать и главу Синтаксические правила BpBatch, а также главы, относящиеся к Ссылкам на файлы и Кэш-разделу. Это вам поможет понять приводимые здесь примеры.
После настройки всех операционных систем сделайте меню, позволяющее пользователю загрузить необходимую операционную систему. Вы, скорее всего, сами сможете понять, как настроить такое меню. Все необходимые для этого команды находятся в конце этого документа.
Мы в настоящий момент не используем Windows NT на удаленно загружаемых машинах, но проверили нашу систему для NT. И она работает.
В наших утилитах нет поддержки NTFS (у нас нет ни документации, ни времени ее реализовывать, но я буду рад помочь тому, кому это интересно) - вам придется установить NT на FAT16 (просто не преобразовывайте ваши разделы в NTFS в процессе установки).
Скопируйте скрипт win95.bpb в winnt.bpb. Замените строку setpartitions в winnt.bpb на следующее:
Nobreak.sys - это небольшая программа (размером около 350 байт), которую вы можете загрузить в начале config.sys. Ее цель - обезопасить процесс загрузки и авторизации пользователя от нажатия Ctrl-Break. В DOS есть подобный механизм (BREAK=OFF), но он не настолько надежен, и практически не работает в autoexec.bat. Наш драйвер обрабатывает скан-коды клавиш на уровне BIOS. Таким образом, ни одна программа просто не получит код клавиши Break, пока его обработка не будет разрешена.
Драйвер должен быть загружен в config.sys (или при помощи программы devlod
из Недокументированной DOS). После этого Break можно снова разрешить, послав Yes специальному псевдо-устройству NOBRK, или запретить, послав No
(на самом деле обрабатывается только первый символ - Y или N).
Драйвер использует вызовы BIOS, и, соответственно, работает только в DOS и Windows 3.1. В Windows 95 встроена своя внутренняя обработка клавиатуры.
Исходный текст на ассемблере можно взять здесь.
Во-первых, сделайте так, чтобы у вас под рукой было две машины:
Сервер - обычно машина с Unix или Windows NT
Клиентская машина - компьютер с включенным BootPROM, у которого на жестком диске нет ничего ценного.
Если вы хотите испытать эту конфигурацию, но у вас еще нет ППЗУ удаленной загрузки, то вы можете взять демонстрационную версию TCP/IP BootPROM с сайта компании InCom GmbH по адресу http://www.incom.de. При помощи этой программы, ваш компьютер будет работать так, как будто в него вставлен TCP/IP BootPROM.
Если же у вас уже есть Boot ROM, то надо его включить. Если у вас TCP/IP BootPROM фирмы Incom, то вам надо использовать специальную программу производителя вашей сетевой карты. Если же у вас PXE-совместимое ППЗУ, то надо это сделать в BIOS, сменив устройство загрузки по умолчанию.
На компьютерах студентов мы первым пунктом ставим загрузку с сети и запрещаем загрузку с винчестера или флоппи-диска. У ассистентов первым пунктом также идет сеть, затем жесткий диск и флоппи.
Честно говоря - практически все... Концепции сохранились практически без изменений, но программное обеспечение полностью переделано - оно не имеет ограничений предыдущих версий и значительно удобнее в работе. Краткий обзор новых возможностей:
Все функции (bpmenu, bpclean, bpunzip) объединены в одну программу.
Программа может запускаться не только из ПЗУ удаленной загрузки (Boot ROM), но и из DOS, Windows 95 и Linux.
Программа теперь имеет возможность восстанавливать образы разделов FAT16, FAT32 и EXT2FS. Если кто-то желает реализовать поддержку NTFS - дайте мне знать... Пока пользователи NT должны оставаться на FAT16.
Программа имеет возможность не только восстанавливать образы дисков, но и добавлять и исправлять конкретные файлы, чтобы удовлетворять любые нужды пользователя клиентской машины.
Образы дисков больше не привязаны к 87 MB. Теперь это - независимые от файловой системы архивы.
Также существует средство автоматической загрузки дисковых образов на достаточно большое количество клиентских машин одновременно (широковещание (broadcast)).
Вы теперь можете написать защищенный загрузочный скрипт, который будет определять поведение машины перед загрузкой.
Вы можете загрузить любое ядро Linux без исправлений. Также возможно указывать ядру параметры и использовать образ электронного диска.
Вы имеете возможность производить авторизацию пользователей в процессе загрузки, используя сервер Unix, NT или Radius и отказывать в любом доступе к машине.
Включена полная поддержка любых языков.
И много, очень много других хороших возможностей...
Существует ли программа, конвертирующая старые архивы в новый формат?
Нет, потому что внутренний формат архива полностью отличается от старого. Но вы можете легко сами произвести конвертацию, сделав следующее:
Загрузите старый образ (разархивируйте его на ваш диск)
Уберите вызов старой утилиты unzipreg и замените его на соответствующие вызовы команды patch (это очень просто - смотри подробные инструкции ниже )
Запустите новую программу mrzip, чтобы создать новый образ диска
Версия 3.0 была бета-версией. Дюжина сайтов по всему миру тестировала ее в течение месяца и отдала достаточно много времени поиску ошибок, и предложениям о доработках. Спасибо им всем за беспокойство, особенно Maciek Uhlig, Dick Velders и Jeff Teeters.
Несколько незначительных возможностей были добавлены в версии 3.01, такие, как поддержка бездисковой загрузки Linux (с запретом использования кэша).
Начиная с версии 3.10, внесена совместимость со стандартом сетевых машин "Wired for Management 1.1a" фирмы Intel. Эти утилиты теперь работают с любым PXE-совместимым ПЗУ удаленной загрузки (наиболее часто устанавливаемыми на встроенные сетевые карты boot ROM). Большое спасибо компании InCom GmbH за предоставленное PXE-ППЗУ, которые сделали возможным создание этой версии. Мы также удачно протестировали эти утилиты с PXE-BootROM, которое я случайно обнаружил в моем компьютере Dell, на встроенной сетевой карте (под названием LanDesk Service Agent).
В версиях 3.11 и 3.12 добавлены утилиты для серверов UNIX (PXE-Прокси DHCP-сервер для Solaris и Linux, и улучшенный TFTP-сервер для Linux), а также полностью и подробно описана настройка сервера и процесса загрузки PXE.
В версии 3.13 добавлена поддержка Расширенного Управления Питанием (Advanced Power Management) (команда PowerOff (Выключить)).
В версию 3.14 внесены незначительные улучшения и некоторые исправления. Мы решили проблему, возникавшую с терминалом RedHat 5.1, и другую ошибку в синтаксисе команды "if". Также добавлены некоторые функции, предложенные Laboratori de Cаlcul de la Facultat d'Informаtica de Barcelona (LCFIB) :
Новая переменная APM указывает, поддерживает ли ваша система Расширенное Управление Питанием (Advanced Power Management) (т.е. есть ли поддержка команды poweroff).
Команда "beep".
Новый параметр команды DrawWindow, добавляющий заголовок окна при его создании. Теперь вы можете использовать команду DrawWindow 200 200 400 200 "Заголовок".
В версию 3.15 добавлена полная поддержка VESA. Программа BpBatch теперь поддерживает несколько видеорежимов, чтобы ее можно было использовать на старых компьютерах, не поддерживающих графику 800x600. К команде InitGraph добавлена возможность задавать видеорежим, и из новой переменной VESA-Modes можно получить список поддерживаемых видеорежимов.
В этом разделе приводится решение наиболее часто возникающих проблем.
Q: Загрузка образа не работаетQ: Процедура разархивации образа раздела сразу выдает ошибкуQ: Компьютер повисает во время загрузки/разархивирования (1)Q: Компьютер повисает вместо загрузки/разархивирования (2)Q: Прокрутка экрана в VESA не работаетQ: В кэше находится испорченный файлQ: В пакетном файле не работает команда EXITQ: Команда Print ничего не выводитQ: MrZip выдает ошибку Malloc failedQ: MrZip прерывает работу при чтении каталоговQ: MrZip не может прочитать некоторые файлыQ: Образы дисков всегда читаются с сервераQ: Red Hat Linux 5.1 не загружаетсяQ: Электронный диск широковещательного TFTP повисает (Оставаясь в подключенном состоянии)Q: BpBatch повисает при доступе к файлу, а MrBatch работает нормальноQ: Разархивирование образа, разбитого на части, не работает (выдается ошибка Malloc failed)Q: MrBatch и MrZip жалуются на терминал в RedHat 5.xQ: "libncurses.so.3.0: невозможно открыть разделенный объектный файл" в LinuxQ: MrBatch и MrZip не работают в Linux (файл не найден)Q: У меня не работают никакие видеорежимы, кроме используемого по умолчанию VESA 800x600Q: BpBatch выводит сообщение "Malloc failed" при разархивировании образов, разбитых на несколько частейQ: Команда Fullunzip в Linux-версии MrBatch не работаетQ: Scandisk выдает сообщение об ошибках на дискеQ: RedHat не загружается с загрузочного диска, при помощи команды FloppyBootQ: Диск с файловой системой FAT32 не загружается
Q: Загрузка образа не работает
A: Вы, скорее всего, используете стандартный TFTP-севрер, который не поддерживает передачу более 65535 пакетов данных, размером по 512 байт (а в Solaris, вообще, только 32767 пакетов!). В результате этого образ раздела должен быть разбит на части, не более 30 Мб каждая (или не более 15 Мб в Solaris). Смотрите описание команды CopyArchive, которая имеет возможность разбивать на части уже существующий образ раздела. Однако мы настоятельно рекомендуем вам использовать улучшенный TFTP-сервер фирмы InCom - он значительно более эффективен (используя пакеты размером 1408 байт, вместо 512).
Q: Процедура разархивации образа раздела сразу выдает ошибку
A: Существуют три варианта: или образ раздела на диске содержит ошибку (используйте MrZip, чтобы определить, есть ли такие ошибки), или файл передан неправильно, из-за превышения времени ожидания в протоколе TFTP, или из-за несовместимости протокола.
Превышение времени ожидания TFTP происходит, если сеть перегружена (например, если вы пытаетесь загрузить большие образы разделов более, чем на 4 машины одновременно). В этом случае, BpBatch не пытается повторять процедуру загрузки бесконечно, потому что это все равно не поможет. Выключите несколько компьютеров и попытайтесь снова не более, чем на 4 компьютерах (или даже на трех). Если у вас есть необходимость часто загружать образы на большое количество компьютеров, то используйте наш специальный широковещательный TFTP-сервер (смотрите посвященный ему раздел).
Несовместимость протокола возникает при попытке использования стандартного TFTP-сервера (обычно входящего в комплект вашего UNIX-сервера), вместе с указанием BpBatch работать с улучшенной версией TFTP. Если вы используете стандартный TFTP-сервер, то должны убрать расширение .P у файла загрузочного образа (это будет разъяснено в ответе на следующий вопрос).
Q: Компьютер повисает во время загрузки/разархивирования (1)
A: Если вы используете TFTP-сервер фирмы Incom - попытайтесь указать ему опцию -s 1408 59 в командной строке. Если вы не используете улучшенную версию TFTP-сервера, уберите на сервере расширение .P в имени файла BpBatch и в bootptab.
Подробное разъяснение: эта проблема возникает в том случае, если вы, не установив улучшенную версию TFTP-сервера, использовали bpbatch.P в качестве тэга "имя файла загрузки" в DHCP/BOOTP. BpBatch будет пытаться связаться с улучшенной версией TFTP-сервера, если имя файла загрузки оканчивается на .P. Чтобы решить эту проблему, можно либо убрать расширение .P из имени файла загрузки (таким образом, BpBatch будет использовать стандартный TFTP), либо установить улучшенной версию TFTP-сервера. Единственный, поддерживаемый нами на сегодняшний день, улучшенный TFTP-сервер - это сервер фирмы Incom. Вы можете найти собранную версию на их веб-сайте, или в нашем каталоге дистрибутива нашей системы. Для того, чтобы TFTP-сервер фирмы Incom корректно работал с дополнительными функциями TFTP, ему надо в командной строке указать опцию -s 1408 59.
Q: Компьютер повисает вместо загрузки/разархивирования (2)
A:
Университет Женевы владеет сетью класса B, разделенной на несколько подсетей. Компьютерный факультет использует четыре подсети, из которых одна выделена для студентов.
В исходном варианте наши компьютеры использовали два сетевых протокола: IPX и IP. Для IPX мы использовали сервер Novell Netware 3 для совместного использования программ и файлов пользователей в DOS и Windows. Для IP у нас был сервер SUN с программами и разделами пользователей для Linux, использующих NFS.
В последней версии конфигурации мы больше не используем IPX. У нас стоит один сервер Unix (Это может быть и Linux, и SUN), позволяющий совместное использование программ и файлов пользователей, при помощи NFS, для Linux-клиентов и SMB (NetBIOS) поверх TCP/IP для Dos- и Windows-клиентов. Таким образом, мы можем предоставить один общий домашний каталог на всех операционных системах.
Мы написали специальную версию TFTP-сервера, включающую в себя самодельную версию широковещательного TFTP. Используя его, мы смогли достичь скорости передачи данных клиентам в 6 Мб/с на сильно загруженной 10-мегабитной сети (этот способ значительно более эффективен - он не посылает подтверждения на каждый пакет). Этот сервер работает в Linux или Solaris. Его можно взять по адресу http://cuiwww.unige.ch/info/pc/remote-boot/soft/btdtpd.tar.gz, вместе с исходными текстами и заранее собранными программами.
TCP/IP-BootPROM не поддерживает этот протокол, поэтому мы загружаем небольшой вариант ядра Linux, использующий электронный диск, при помощи ранее описанных утилит, в котором запускаем Linux-версию программы MrBatch, в которую встроена поддержка широковещательного TFTP. Простой пакетный файл загружает все необходимые файлы в кэш-раздел в течение пары минут одновременно на всех компьютерах. Вам не надо устанавливать Linux для использования этого пакета (за исключением того случая, если ваше очень экзотическое оборудование требует специального ядра).
Процедура состоит из нескольких шагов. Во-первых, загрузите вручную широковещательный сервер, задав ему количество клиентских машин в качестве параметра (запомните, что эта процедура должна производиться не ежедневно, а лишь в тех случаях, когда вы хотите синхронизировать образы дисков на всех машинах). Затем включите все клиентские машины, которые должны выполнить следующий скрипт:
# # Этот файл запускает мини-вариант linux с электронным # диском, который затем запустит mrbatch. # # Широковещательный TFTP-протокол работает только в Linux-версии # mrbatch, потому что в BootPROM нет поддержки широковещания. # # 1. Создаем небольшой раздел, оставляя большое пространство для кэша setpartitions "BIGDOS:50" # 2. Очищаем MBR clean 0 # 3. Запускаем ядро Linux с поддержкой initrd (Загрузочный Электронный Диск) и # используем в качестве этого диска bcastrd.gz (он будет подключен в # качестве корневой файловой системы и запущен через /linuxrc). См. initrd.txt, # в котором приведено подробное описание загрузочных дисков. Вам не надо задавать корневое # устройство) - ядро будет использовать электронный диск. linuxboot "linux.krn" "" "bcastrd.gz" # 4. Сначала linux запустит dhcpcd для настройки сети. # Затем он выполнит команду mrbatch -w bcastlx
|
# Этот файл выполняется mrbatch, после его загрузки с электронного диска # bcastrd.gz # Его главная задача - "широко скопировать" файлы в кэш # # 1. Выводим диагностические сообщения showlog # 2. Отключаем фразу "press a key" set pauselog="OFF" # 3. Устанавливаем реальные размеры разделов. # Внимание: Так как вы копируете файлы в кэш для дальнейшего использования, # задайте именно те размеры разделов, которые вы будете использовать. setpartitions "BIGDOS:1024" # 4. Очищаем кэш-раздел clean -1 # 5. И копируем файлы в кэш, используя широковещательный TFTP-протокол # (порт 99) # # Вы можете использовать этот скрипт "как есть", но последнюю строку обязательно # измените! В нашем примере мы загружаем файл mblinux.imz, который является образом # нашей инсталляции Linux. copy "$BOOTP-Server-IP@99:mblinux.imz" "{:-1}mblinux.imz" |
Мы также написали специальную версию TFTP-сервера, работающего, как шлюз системы безопасности для авторизации пользователей. Этот сервер работает в Linux или Solaris и может авторизовать пользователей в системе паролей Unix (с поддержкой NIS и shadow), на сервере Windows NT (или Samba) server или на сервере Radius. Его можно взять по адресу http://cuiwww.unige.ch/info/pc/remote-boot/soft/stdtpd.tar.gz, вместе с исходными текстами и заранее собранными программами. Заранее собранные программы не включают систему шифрования паролей NT - мы не можем распространять библиотеку libdes, но сборка программы - дело достаточно простое.
Чтобы использовать шлюз безопасности, вам надо настроить достаточно простой файл конфигурации доменов безопасности, в котором описывается соответствие серверов авторизации и доменов (домен Unix соответствует системе паролей Unix на той машине, на которой работает шлюз). Ниже приведен пример конфигурации
Эта конфигурация была успешно воспроизведена в нескольких других местах по всему миру. Некоторые, из участвовавших в проекте, написали советы и хитрости в дополнение к этому How-To. Если у вас тоже есть совет, и на этой странице нет ссылок на вас, то пишите по адресу Marc.VuilleumierStuckelberg@cui.unige.ch. Если у вас возникнут проблемы с воспроизведением этой конфигурации, взгляните на эти страницы!
http://www.br.fgov.be/RESEARCH/INFORMATICS/info/bootp.html, автор - Alain Empain из Национального Ботанического Сада Бельгии. Много полезных примеров скриптов, и красивая программа на PERL, позволяющая автоматически создавать меню и HTML-документацию из описания более высокого уровня.
http://www.katedral.se/system/elevsyst, автор - Johan Carlstedt из Кафедральной школы в Uppsala, Швеция. На настоящий момент, конфигурация, описанная на этой странице базируется на старой версии утилит удаленной загрузки, однако, практически все работает. А также там приводятся некоторые советы.
http://vitoria.upf.tche.br/~fred/, на португальском, автор - Frederico Goldschmidt из Университета Passo Fundo, Бразилия.
http://www.etse.urv.es/~larinyo,на испанском, автор - Lluis Arino, из Высшей Инженерно-Технической Школы (Escola Tecnica Superio d'Enginyeria), Испания.
Вы можете послать мне свой BpBatch-скрипт, чтобы я внес его в коллекцию скриптов.
Единственная поддержка сети, встроенная в TCP/IP BootPROM - это TFTP. Поэтому нам интересны специальные версии TFTP-серверов, позволяющих немного больше, чем обычные.
В этой главе приведено подробное описание утилит удаленной загрузки, разработанных нами на факультете компьютерных наук Университета Женевы.
Мы собрали модифицированную версию TFTP-сервера для Linux, работающего аналогично улучшенной версии TFTP-сервера фирмы Incom. На самом деле, мы просто увеличили размер пакета с 512 до 1408 байт и поменяли порт с 69 на 59. Его можно получить по адресу http://cuiwww.unige.ch/info/pc/remote-boot/soft/etdtpd.tar.gz.
Фирма InCom GmbH вместе со своим TCP/IP BootPROM распространяет улучшенную версию TFTP-сервера, который может посылать пакеты размером до 1408 байт, вместо стандартных 512. Это очень важное дополнение, которое мы рекомендуем использовать. Этот сервер есть на диске утилит TCP/IP Bootprom в вариантах для Solaris, Windows и Netware NLM.
Другой WWW документ на эту тему - это ``What to do when Tk says that your display is insecure'', http://ce-toolkit.crd.ge.com/tkxauth/. Его написал Kevin Kenny. Он предлагает аналогичное решение аутентификации X (xauth). Kevin дает решение, более подходящее для xdm.
X System Window System Vol. 8 X ``Window System Administrator's Guide'' от O'Reilly and Associates также привлек мое внимание в качестве хорошего источника информации. К сожалению, я не смог проверить его.
Еще один документ, похожий на этот называется ``Securing X Windows'' и находится по адресу http://ciac.llnl.gov/ciac/documents/ciac2316.html.
Можно также почитать конференции Usenet (такие как comp.windows.x, comp.os.linux.x, и comp.os.linux.networking).
Клиентская программ (например, ваше графическое приложение) знает, какой дисплей использовать из переменной окружения DISPLAY. Ее можно переопределить, либо использовать аргумент -display hostname:0 во время запуска вашей программы. Рассмотрим это на примере.
Наш компьютер известен в сети как light, в домене uni.verse. Если мы запустим обычный X-сервер, переменная DISPLAY будет равна light.uni.verse:0. Но мы хотим запустить программу для рисования xfig на удаленном компьютере dark.matt.er, а в качестве дисплея использовать машину light.
Полагаю, что вы уже вошли на удаленный компьютер dark.matt.er.
Если вы используете csh в качестве оболочки на нем:
dark% setenv DISPLAY light.uni.verse:0 dark% xfig & |
или же:
dark% xfig -display light.uni.verse:0 & |
Если вы используете sh в качестве оболочки:
dark$ DISPLAY=light.uni.verse:0 dark$ export DISPLAY dark$ xfig & |
или же:
dark$ DISPLAY=light.uni.verse:0 xfig & |
или, конечно же:
dark$ xfig -display light.uni.verse:0 & |
Кажется, некоторые версии telnet автоматически передают переменную DISPLAY
на удаленный компьютер. Если у вас как раз такая, считайте, что вам повезло, и не надо указывать ее вручную. В противном случае, большинство версий telnet передают переменную окружения TERM; можно установить переменную DISPLAY, основываясь на переменной TERM.
Основная идея состоит в том, чтобы при помощи скрипта сделать следующее: перед запуском telnet, добавляем значение переменной DISPLAY к переменной TERM. На другом конце в скрипте .*shrc устанавливаем значение DISPLAY из переменной TERM.
Сервер не принимает соединения просто так, откуда угодно. Да вам и не нужно, чтобы кто-нибудь выводил окна на экране. Или читал, что вы набираете (помните! клавиатура это часть дисплея).
Слишком мало людей, кажется, понимают, что подобный доступ к вашему дисплею снижает степень безопасности. Кто-нибудь, кто имеет доступ к вашему дисплею, может, что угодно посмотреть и написать на ваш экран , считывать нажатия клавиш и действий мыши.
Большинство серверов знают два пути аутентификации: механизм, основанный на списке машин (xhost), и механизм, основанный на magic cookie (xauth). Кроме того, есть ssh, оболочка с шифрованием, которая может обслуживать X-соединения.
Волшебное слово это DISPLAY (ДИСПЛЕЙ). В X-windows под дисплеем понимается (упрощенно) клавиатура, мышь и экран. Дисплей управляется программой-сервером, известной как X-сервер. Сервер обслуживает вывод программ, подключенных к нему.
Дисплей указывается именем, например:
DISPLAY=light.uni.verse:0
DISPLAY=localhost:4
DISPLAY=:0
Название дисплея содержит имя компьютера (напр. light.uni.verse или localhost), двоеточие и номер (напр. 0 или 4). Имя компьютера в названии дисплея - это имя машины, на которой запущен X-сервер. Неуказанное имя компьютера подразумевает localhost. Номер дисплея обычно ``0'', и может варьироваться, если к компьютеру подключено несколько дисплеев.
Если вы когда-либо сталкивались в названии дисплея с дополнительным .n в конце, это номер экрана. Хотя обычно есть только один экран с номером n=0
по умолчанию.
Существуют другие формы описания дисплея, но для наших целей достаточно вышесказанного.
Для любопытных:
hostname:D.S означает экран S на дисплее D машины hostname; X-сервер для этого дисплея находится на TCP порту 6000+D.
host/unix:D.S означает экран S на дисплее D машины host; X-сервер для этого дисплея находится на UNIX domain socket /tmp/.X11-unix/XD (т.е. доступном только с машины host).
:D.S эквивалент host/unix:D.S, где host это имя локальной машины.
Вы используете два компьютера. Первый, с графической оболочкой X, используется в качестве графического терминала. Второй - для некоторых важных работ с графикой. Вы хотите работать на втором компьютере, находясь за первым. X-windows предоставляет эту возможность.
Конечно для этого вам нужно соединить их в сеть. И желательно быструю; X-протокол сильно загружает сеть. Но при небольшом терпении и соответствующем протоколе сжатия, вы можете запускать приложения через модем. Для сжатия X-протокола, можно использовать dxpc http://ccwf.cc.utexas.edu/~zvonler/dxpc/ или LBX http://www.ultranet.com/~pauld/faqs/LBX-HOWTO.html также известного как LBX mini-HOWTO.
Чтобы достигнуть этого, необходимо две вещи:
Скомандовать X-серверу, чтобы он работал с удаленным компьютером.
Скомандовать удаленному компьютеру (клиенту), чтобы он посылал информацию на ваш дисплей.
Когда вы в первый раз пытаетесь запустить удаленное приложение, оно может не запустится. Вот несколько распространенных сообщений об ошибке, их возможные причины и решения.
xterm Xt error: Can't open display(Не могу открыть дисплей): |
Нет переменной DISPLAY в окружении, и вы не указали программе параметр -display. Приложение принимает по умолчанию пустую строку, а это синтаксически не правильно. Установите переменную DISPLAY (при помощи setenv или export в зависимости от оболочки).
_X11TransSocketINETConnect: Can't connect(Не могу соединиться) : errno = 101 xterm Xt error: Can't open display(Не могу открыть дисплей): love.dial.xs4all.nl:0 |
Errno = 101 это ``Сеть не доступна''. Приложение не может выполнить сетевое соединение с сервером. Проверьте, правильно ли установлена переменная DISPLAY, и доступен ли сервер с вашего клиента (сеть должна работать, в конце концов, вы только что вошли на удаленную машину через сеть).
_X11TransSocketINETConnect: Can't connect(Не могу соединиться): errno = 111 xterm Xt error: Can't open display(Не могу открыть дисплей): love.dial.xs4all.nl:0 |
Errno = 111 это ``В соединении отказано (Connection refused)''. Машина сервера, к которой вы хотите подсоединиться доступна, но указанный сервер на ней не запущен. Проверьте, правильное ли имя машины и номер дисплея вы используете.
Xlib: connection to ":0.0" refused by server (в соединении с ":0.0" отказано сервером) Xlib: Client is not authorized to connect to Server (Клиент не имеет авторизован для подключения к Серверу) xterm Xt error: Can't open display (Не могу открыть дисплей): love.dial.xs4all.nl:0.0 |
Клиент подключился к серверу, но сервер не позволяет клиенту пользоваться им (не авторизован). Убедитесь, что передана правильная авторизационная запись, и она не устарела (сервер использует новую запись каждый раз во время запуска).
Конечно, все что работает на удаленной машине, аналогично работает для другого пользователя на той же машине. Просто клиент и сервер это одна и та же машина. Тем не менее, в данном случае существует несколько кратчайших путей передать авторизационную запись.
Допустим, что вы используете su для переключения между пользователями. То есть все, что вы должны сделать, это написать скрипт, запускающий su с командами, необходимыми для запуска X-клиента: установить переменную DISPLAY и передать авторизационную запись.
Установить переменную DISPLAY сравнительно просто; надо определить DISPLAY="$DISPLAY" перед запуском команды su. Итак, вы можете просто сделать:
Vincent Zweije
zweije@xs4all.nl
Перевод: Павел Гашев, ASPLinux
В этот документе описываются способы запуска удаленных приложений под X. То есть представлена информация о том, как заставить программу выводить результат на дисплей другого компьютера, а не того, на котором она запущена. Или наоборот: как заставить программу работать на другом компьютере так, как будто вы сидите за ним. И как запустить приложение от другого пользователя на этом же компьютере. Основное внимание здесь уделяется безопасности.
Очевидно, все, что работает для обычных пользователей, будет работать и для root. Тем не менее, в случае с root вы можете сделать это даже проще, т.к. root может прочитать чей угодно ?/.Xauthority. Так что нет необходимости передавать записи авторизации. Все, что вам нужно сделать, это установить переменную DISPLAY и указать XAUTHORITY на ?serveruser/.Xauthority. Примерно так:
su - -c "exec env DISPLAY='$DISPLAY' \ XAUTHORITY='${XAUTHORITY-$HOME/.Xauthority}' \ command" |
Помещаем это в скрипт:
#!/bin/sh if [ $# -lt 1 ] then echo "usage: `basename $0` command" >&2 exit 2 fi su - -c "exec env DISPLAY='$DISPLAY' \ XAUTHORITY='${XAUTHORITY-$HOME/.Xauthority}' \ "'"$SHELL"'" -c '$*'" |
Называем его /usr/local/bin/xroot и пробуем запустить:
xroot 'control-panel &' |
Еще проще, не правда ли?
Авторизационные записи передаются по сети без шифрования. Если вы боитесь, что кто-нибудь будет подглядывать за вашим соединением, используете ssh, безопасную оболочку. Она обеспечит зашифрованное соединение сервера и клиента. И кроме того, она полезна и для других случаев. Это хорошее структурное улучшение вашей системы. Просто сходите на http://www.cs.hut.fi/ssh/
Кто знает еще какие-нибудь методы аутентификации или шифрования X-соединений? Может быть kerberos?
Xauth открывает доступ всем, кто знает "секрет". Этот секрет называется "авторизационная запись" или "magic cookie" (волшебная печенька). Эта схема авторизации формально названа MIT-MAGIC-COOKIE-1.
Эти записи для разных дисплеев хранятся вместе в файле ?/.Xauthority. Ваш ?/.Xauthority должен быть недоступен для других пользователей. Программа xauth управляет этими записями, т.е. xauth - псевдонимная система аутентификации.
В начале сеанса сервер считывает запись из файла, указанного в аргументе -auth. После этого сервер позволяет соединения только тем клиентам, которые имеют ту же запись. Если запись в ?/.Xauthority меняется, сервер не считает изменение.
Новые сервера могут генерировать такие записи на лету для клиентов, которые запрашивают их. Хотя записи содержатся внутри сервера, они не запишутся в ?/.Xauthority, если только клиент это не сделает сам. Согласно David Wiggins:
"Одна штучка была добавлена в X11R6.3, которой вы можете заинтересоваться. Через новую систему безопасности, сам X-сервер может сгенерировать и передать новые авторизационные записи на лету. Кроме того, запись может быть определена как ``ненадежная'', ограничивая функционирование приложений. Например, они не могут узнать содержимое окна или ввод с клавиатуры/мыши от других "надежных" клиентов. В xauth введена новая подкоманда ``generate'', чтобы сделать это средство, по крайней мере, возможным (если не легким) в использовании."
Xauth имеет большое преимущество в безопасности перед xhost. Вы можете ограничить доступ специфических пользователей на специфических компьютерах. В отличии от xhost, его невозможно обмануть, подделав адрес компьютера. И если хотите, вы можете по прежнему пользоваться xhost.
Создание авторизационной записи
Если вы хотите использовать xauth, запустите X-сервер с аргументом -auth authfile. Если вы пользуетесь скриптом startx, лучше это сделать в нем. Создайте авторизационную запись, как показано ниже в вашем скрипте startx.
Отрывок из /usr/X11R6/bin/startx:
Xhost открывает доступ, основанный на названиях машин. Сервер поддерживает список машин, которым позволено подключаться к нему. Он же может отключить проверку имен полностью. Осторожно: это значит, что не будет выполняться никаких проверок, так что может подключиться любая машина!
Вы можете изменять список машин при помощи программы xhost. Чтобы использовать этот механизм для предыдущего примера, сделайте:
Предположим, что вам нужно запустить графическую утилиту конфигурации, которая требует привилегий root. Тем не менее, ваш сеанс под X запущен от обычного пользователя. Это может показаться странным, но X-сервер не даст утилите доступа к вашему экрану. Как это может быть возможным, если обычно root может делать все что угодно? И как мне решить эту проблему?
Давайте обобщим ситуацию. Итак, вы хотите запустить X-клиент от другого пользователя clientuser, а X-сервер запущен пользователем serveruser. Если вы внимательно читали раздел, посвященный авторизационным записям, вам ясно, почему clientuser не имеет доступа к дисплею: ?clientuser/.Xauthority не содержит правильной авторизационной записи для доступа к вашему дисплею. Правильная авторизационная запись находится в ?clientuser/.Xauthority.
Менеджер окон (такой как twm, wmaker, или fvwm95) это такое же приложение, как другие. Должна сработать та же процедура.
Хорошо, почти. В одно и тоже время на дисплее может работать только один менеджер окон. Если у вас уже запущен локальный менеджер окон, вы не можете запустить еще и удаленный (он поругается и закончит работу). Необходимо сначала снять (используя kill или просто выйти) локальный менеджер.
К сожалению, большинство X-сессий заканчиваются командой
exec менеджер-окон-на-ваш-выбор |
а это значит, что когда (локальный) менеджер окон заканчивает работу, сеанс заканчивается, и X-сервер завершает работу.
По ходу вам придется решить еще парочку не очень сложных проблем. Просто поиграйтесь со скриптом X-сеанса (обычно это ?/.xsession или ?/.xinitrc), чтобы настроить его так, как вы хотите.
Только будьте осторожны. Менеджер окон часто предоставляет различные способы запуска программ, и, если они запускаются на локальной машине, запущен локальный менеджер окон. Если запущен удаленный менеджер окон, он запускает приложения, находящиеся на удаленной машине, а это может быть не то, что вы хотите. Конечно, они будут отображаться на вашем дисплее.
Dave Whitinger
dave@whitinger.net
Перевод: Станислав Рогин, ASPLinux
В этом документе описывается, как установить и заставить нормально работать RPM-пакеты под Slackware. Однако, нижеприведенная информация, возможно, применима и в любых других дистрибутивах Linux.
Последнюю версию RPM всегда можно найти по адресу:
ftp.rpm.org/pub/rpm/dist/latest |
На момент написания этого документа последней версией была
rpm-2.4.12-1.i386.tar.gz |
Обратите внимание на строку .i386. Она означает, что это готовый пакет для архитектуры Intel, готовый к распаковке и запуску. Убедитесь в том, что когда будете закачивать пакет, в его имени будет i386, иначе эти советы не будут работать.
Заметьте, что в некоторых версиях пакета RPM tar-файл был создан с неправильными разрешениями. После установки RPM, проверьте разрешения на некоторые каталоги (/bin, /usr, и т.п.). Если разрешения установлены в 700 (drwx------), то это результат этой ошибки.
Чтобы исправить эти проблемы, запустите нижеприведенный скрипт:
#!/bin/sh
chmod 755 /bin chmod 755 /usr chmod 755 /usr/bin chmod 755 /usr/doc chmod 755 /usr/lib chmod 755 /usr/man chmod 755 /usr/man/man8 chmod 755 /usr/share chmod 755 /usr/share/locale chmod 755 /usr/share/locale/de chmod 755 /usr/share/locale/de/LC_MESSAGES chmod 755 /usr/share/locale/pt-br chmod 755 /usr/share/locale/pt-br/LC_MESSAGES chmod 755 /usr/share/locale/sv chmod 755 /usr/share/locale/sv/LC_MESSAGES chmod 755 /usr/src |
Пишите мне, если у вас есть вопросы по этому поводу.
Наиболее простой способ установить RPM - использовать менеджер пакетов из самого Slackware.
Вы должны иметь права пользователя root для установки RPM.
installpkg /home/dave/rpm-2.4.12-1.i386.tar.gz |
Замените, конечно, /home/dave правильным путем к файлу.
(ВНИМАНИЕ!) Если этот вариант не сработает, просто распакуйте следующими командами:
cd / ; tar zxvpf /home/dave/rpm-2.4.12-1.i386.tar.gz |
Затем, создайте подкаталог "rpm" в каталоге /var/lib.
mkdir /var/lib/rpm
Затем, запустите 'rpm --initdb' для инициализации базы данных rpm.
Если все вышеописанное сработает нормально, то у вас система, совместимая с rpm! Проверьте ее, возьмите любой rpm-файл и установите его командой 'rpm -Uvh filename.rpm'