Xkbevd и xkbbell
Судя по названию, xkbevd - "XKB event daemon". Как сказано в man xkbevd, "эта команда очень 'сырая'... мы предлагаем ее скорее как 'черновой прототип' для разработчиков, а не как инструмент для 'конечных юзеров'".
В основном она принимает bell event'ы и может служить "музыкальной приставкой" (подробнее смотрите в
"Внутренности XKB: Расширенные возможности 'пищалки'").
Правда сам xkbevd звуки не воспроизводит. В его конфигурационном файле можно указать имя программы для воспроизведения звуков и соответствия между "именем звука" и аудио-файлом, который надо передать в качестве аргумента этой программе.
А вот программа xkbbell служит "тестером" для "расширенных возможностей 'пищалки'". Она просто посылает запрос модулю XKB для воспроизведения звука. Причем, с ее помощью можно заказать как обычный "писк" (с помощью ключа -force), так и "музыкальный фрагмент", указав в качестве аргумента "имя звука".
С помощью дополнительных ключей можно симитировать запрос от конкретного приложения (окна).
Как я уже сказал, xkbbell служит скорее "тестером", чем полезной утилитой. Хотя ее можно использовать и в своих "скриптах", как команду для проигрывания звуков (естественно, должна быть запущена хоть какая-нибудь XKB-совместимая "музыкальная приставка").
Подробности о xkbevd можно почитать в соответствующем man'е. А для xkbbell никакого описания нет. Правда, можно посмотреть хотя бы список ключей, запустив ее с ключем -help.
Xkbprint
Эта утилита генерирует картинку (в формате postscript'а) изображающую клавиатуру. При этом она использует как описание геометрии (xkb_geometry), так и "назначение" клавиш. То есть, кроме отрисовывания самой геометрии клавиатуры, она еще и подписывает - какой символ генерируется каждой клавишей.
Особой пользы от нее я не вижу. Разве что - проверить правильность описания геометрии (собственно, кроме этой утилитки ее никто и не использует), да еще увидеть на картинке расположение сразу всех символов.
Подробности - в man xkbprint.
Xkbvleds и mxkbledpanel
Утилита xkbvleds предназначаена для отображения состояния виртуальных индикаторов XKB (в том числе и тех, которые имеют "реальные" аналоги в виде светодиодов на клавитатуре).
К сожалению, она выполнена в том же аскетичном стиле (никаких подписей), что и xkbwatch. И точно так же не имеет никакого описания.
Поэтому я не буду ничего о ней рассказывать (хотя она даже имеет какие-то ключи), а посоветую забыть о ней и, если хочется чего-то подобного, воспользоваться другой аналогичной утилиткой - mxkbledpanel.
Эта утилита имеет более "человеческое лицо". Все индикаторы на ней подписаны (естественно - те, которые реально используются; напомню, что в XKB может быть до 32 виртуальных индикаторов, но это не значит, что все они задействованы в конкретной конфигурации).
Кроме того, эта программа позволяет осуществлять и "обратную связь", если это предусмотренно в конфигурации (подробнее - смотрите в "Немного о внутренностях XKB":"Индикаторы"
и "Описание поведения индикатора":drivesKeyboard). То есть, "щелкая мышью" по индикатору можно включать/выключать его и таким образом менять соответствующее состояние XKB. (Кстати, благодаря этому, mxkbledpanel может служит простейшим индикатором-переключателем "РУС/ЛАТ").
Недостатки этой программы в том, что она во-первых требует для сборки Motif (хотя должно хватить и lesstif'а), а во-вторых - не входит в дистрибутивы XFree. Найти ее можно, например, на -
ftp://ftp.x.org/pub/unsupported/Motif/mxkbledpanel/
Xkbwatch
Эта утилитка показывает текущее состояние "виртуальных" и "реальных" модификаторов. К сожалению, она имеет очень "скромную внешность" (никаких подписей - только какие-то безымянные "лампочки") и, к тому же, остутствует какое-либо описание к ней. (Похоже, авторы писали ее "только для себя", но зачем-то засунули в дистрибутив. :-)
На самом деле, если знать - что именно она показывает, xkbwatch может оказаться весьма полезной при отладке своих файлов конфигурации.
Итак, восполняя пробелы в описании, привожу табличку, поясняющую значение индикаторов xkbwatch
| O | O | O | O | O | O | O | O | |
| O | O | O | O | O | O | O | O | |
| O | O | O | O | O | O | O | O | |
| O | O | O | O | O | O | O | O | |
| O | O | O | O | O | O | O | O | |
| Mod5 | Mod4 | Mod3 | Mod2 | Mod1 | Control | Lock | Shift |
Xmodmap
Как ни странно, но эта программа тоже может использоваться для работы с XKB. Просто, она работает с клавиатурным модулем с помощью "старого" протокола (core protocol). Но поскольку XKB "из соображений совместимости" этот протокол понимает, то вполне может воспринять таблицы, загружаемые с помощью xmodmap.
Естественно, используя xmodmap, вы лишаетесь всех дополнительных возможностей XKB. Но для простейших исправлений раскладки клавиатуры ее вполне можно использовать.
Единственное, что я бы не советовал - использовать широкораспростаненные файлы для руссификации клавиатуры в формате xmodmap (.Xmodmap). Почему этого делать не стоит, написано в "Почему руссификация через XKB не работает".
Подробности об этой программа читайте в соответствующем man'е. (Но если вы не знаете - что такое xmodmap, то ... лучше и не знать :-).
Эта каталоговая структура зарезервирована для
Для некоторого упрощения и сохранения совместимости XFree86 с системой X Window для других типов операционных систем должны быть созданы следующие символические ссылки, если только каталог /usr/X11R6 существует:
/usr/bin/X11 -> /usr/X11R6/bin
/usr/lib/X11 -> /usr/X11R6/lib/X11
/usr/include/X11 -> /usr/X11R6/include/X11
В общем случае программное обеспечение не должно использовать перечисленные символические ссылки при инсталляции или в целях управления. Они предназначены только для пользователей. Трудности связаны с версиями выпусков системы X Window -- в переходный период невозможно узнать, какая версия X11 используется.
Специфичные для каждого хоста данные в каталоге /usr/X11R6/lib/X11 должны использоваться только в демонстрационных целях. Приложения, которым необходима информация о текущей конфигурации хоста, должны искать ее в каталоге /etc/X11, куда могут быть сделаны ссылки из каталога /usr/X11R6/lib. (Примерами таких конфигурационных файлов могут служить Xconfig, XF86Config или system.twmrc.)
Могут создаваться следующие символические ссылки на каталоги.
/usr/spool -> /var/spool
/usr/tmp -> /var/tmp
/usr/spool/locks -> /var/lock
Эта возможность обусловлена необходимостью сохранить совместимость со старыми системами до тех пор, пока все реализации не начнут использовать каталоги, размещенные непосредственно в /var. Если система уже не требует наличия указанных ссылок, они могут быть удалены.
Xsnap
xsnap
написанный Clauss Strauch из Carnegie Melon University и другими разработчиками.
После многолетнего использования 'Snap!', перейдя на Линукс, я искал ему замену и тут и там. Нет, xsnap не обладает OCR возможностями, которые были частью 'Snap!', но он все равно весьма полезен.
Xsnap - это небольшое приложение, которое снимает скриншоты. Большое дело. Существует множество программ, которые делают тоже самое. Разница состоит в том, что xsnap позволяет вам захватывать произвольные области экрана (включая целые окна или экраны) и он работает быстро.
Когда вы запустите xsnap ваш курсор мыши изменится, превратившись в угол; просто поместите курсор где нужно и 'растяните' прямоугольник охватывающий область экрана, которую вы хотите захватить. Вот и все. Нажмите 'p' или 'w' в результирующем окне, чтобы сохранить пронумерованный скриншот в вашей домашней директории.
Это звучит не слишком впечатляюще, но когда вы хотите отослать по электронной почте кусочек изображения, или сделать небольшую 'липкую' заметку для себя, в то время как вы заняты чтением веб сайта, это то что вам нужно. На самом деле снятие скриншотов запущенных приложений, это самое малое, для чего вы можете использовать xsnap. Быстрое создание простых 'липких' заметок документов, сообщений электронной почты и man страниц, для использования в течении нескольких минут, вот где xsnap предстает во всей красе.
На самом деле, можете поверить мне на слово, xsnap потрясающе полезен, особенно когда привязан к горячей клавише вроде 'print screen' (для чего она вам еще нужна?). На самом деле, xsnap просто не используется по настоящему, если не назначен на глобальную горячую клавишу.
К сожалению он сохраняет свои файлы в виде 'xpm'. Они очень большие
Как всегда, мы можем написать обходной скрипт для исправления таких упущений. Просто сделаем скрипт, который будет преобразовывать файл на лету. Вот пример скрипта, который назначен у меня на горячую клавишу: #!/bin/bash # xsnap-jpg. Запускает xsnap, конвертирует в jpg и загружает electric eyes.
xsnap -stdout | xpmtoppm | cjpeg -quality 75 >~/snap.jpg;ee ~/snap.jpg
Чтобы избавить вас от лишнего набора, вот текстовая версия. Затем введите 'chmod 755 имя_файла' для загруженного файла, чтобы сделать его исполнимым. Это будет функционировать как и xsnap исключая то, что файлы будут в формате jpeg и вы сможете сделать с ними все что может ee - к тому же вы не будете захламлять вашу домашнюю директорию нумерованными файлами. '-quality 75' это опция по умолчанию для cjpeg. Измените '75' на меньшее или большее число, чтобы регулировать размер/качество, как вам нужно.
Я хочу упомянуть, что есть один небольшой дополнительных шаг для компиляции xsnap. Вы обнаружите, что он поставляется без работающего makefile или скрипта configure. Чтобы создать makefile введите 'xmkmf' (x make makefile). Затем действуйте как обычно.
Пока вы скачиваете xsnap, на той же самой странице можно обнаружить Lupe - очень приятный увеличитель, с некоторыми дополнениями, касающимися цветов и размещения (плюс он имеет 'клевый' дисплей в стиле 'heads-up' ).
Xterm
Проблема при работе в linux из xterm под Solaris: не выходит из режимов реверса и подчеркивания (less)
infocmp xterm (в Solaris) записать в файл в linux (например, xterm-sol.ti) отредактировать имя терминала (например, xterm-sol) tic -v xterm-sol.ti (в linux, с правами root) при каждом заходе из Solaris в linux делать: export TERM=xterm-sol (или встроить в .bash_profile разбор откуда мы пришли по DISPLAY или - в RH 6.2 - по REMOTEHOST)
Xxkb
Себя сильно хвалить не буду :-).
Замечу только, что основное достоинство как и у FvwmKb - индивидуальное состояние для каждого окна. Но в отличии от FvwmKb - работает с любым wm.
Недостаток - довольно "аскетичный" вид. Выбор раскладки осуществляется просто перебором "иконок", а не с помощью "меню".
Иван Паскаль pascal@tsu.ru
Зачем ?
Я хотел загружать все операционные системы без необходимости прохождения нескольких меню.Я знаю, что могу установить NT поверх win9x, которые установлены поверх DOS. Но чтобы загрузить DOS мне придется пройти меню NT, а затем меню win9x. Мне же хотелось иметь возможность загружать все эти операционные системы за один раз.
Эта задача достаточно не простая. Проблема с операционными системами от Microsoft в том, что все они хотят загружаться из первичного (primary) раздела. Здесь поможет GRUB. Он может скрывать первичные разделы. Вы можете использовать до 3 разделов для установки операционных систем Microsoft. GRUB скроет других 2 раздела, так что операционные системы их не увидят. Это означает, что для доступа к данным из DOS, Win9x и Windows 2000 вам потребуется еще один раздел. 4-й раздел используется для расширенного (extended) раздела.
Мне, также, хотелось иметь систему меню, что позволяет GRUB.
Еще одна приятная особеность GRUB в том, что он поддерживает reiserfs, поэтому мне не нужно держать свой /boot файл в отдельном разделе ext2.
Зачем так сложно?
Возникает вопрос - почему нельзя поставить шрифты сразу для кодов koi8-r и обойтись без какой-либо screenmap?
На самом деле - можно. Можно поставить шрифты для koi8-r, тем более, что в наборе шрифтов они есть и для всех трех матриц (а для 8x16, даже в нескольких вариантах - koi8-r, koi8-rb, koi8-rc).
Тогда соответствующие строчки в rc.conf будут выглядеть
scrnmap="NO" font8x16=koi8-r-8x16 font8x14=koi8-r-8x14 font8x8=koi8-r-8x8
Однако, не торопитесь это делать. Дело в том, что шрифты cp866 лучше подходят для видеокарты "писишки".
Каждый символ на экране рисуется в матрице шириной в 9 точек, при этом "перерисовать" (загружая шрифты) можно только 8 из них. Девятая колонка служит для того, чтобы символы, если они даже полностью занимают все восемь "программируемых" колонок, все-таки не сливались между собой. С другой стороны есть такие символы псевдографики, которые предназначены для рисования рамочек и просто горизонтальных линий. Для них, наоборот, желательно, чтобы они сливались, иначе горизонтальные линии будут выглядеть пунктирными.
Видео-контроллер, учитывает это и отрисовывает девятую колонку по-разному. Для обычных символов эта колонка остается пустой (независимо от содержимого остальных восьми колонок), а для псевдографических - девятая колонка точек просто повторяет восьмую.
Проблема в том, что видео-контроллер имеет свое мнение о том, какие символы являются псевдографическими (и, следовательно, должны сливаться в сплошную линию), а какие - нет. Псевдографическими он считает символы с кодами в диапазоне C0 - DF.
Так вот, в шрифтах cp866 "псевдографика" действительно попадает в этот диапазон (и горизонтальные линии рисуются слитно), а в koi8-r - нет (и те же линии рисуются пунктиром).
Другая проблема при использовании шрифтов koi8-r может возникнуть, если вы захотите включить поддержку "мыши" в syscons.
Дело в том, что для отрисовки графического курсора syscons перепрограммирует шрифты для четырех символов (коды D0 - D3). В шрифтах cp866 эти коды попадают на псевдографические символы (причем, редко используемые), а в koi8-r - на буквы "п я р с". Естественно, если вы используете шрифты koi8-r, при "мышевождении" эти буквы на экране портятся.
Правда, эта проблема имеет и другое решение. В последних версиях syscons, коды, используемые под "мышиный" курсор, можно изменить, пересобрав ядро системы.
Поэтому, тот же "FreeBSD Handbook" советует для русификации первым делом пересобрать ядро, добавив в файл конфигурации
option "SC_MOUSE_CHAR=0x03"
Хороший совет, если не обращать внимание на то, что сама по себе пересборка ядра - задача более сложная (и требует значительно больше времени), чем правка пары строк в rc.conf. (Кстати, и 0x03 - не очень удачная замена).
Вот эти причины и делают более предпочтительными шрифты cp866, хотя эффект от них чисто косметический.
с задачами подобно bash, но
Zsh работает с задачами подобно bash, но при этом имеется возможность более гибко работать с заданиями запущенными в фоновом режиме. Кроме команды &, которая используется для запуска задачи в фоновом режиме, также определены команды &| или &!, которые запускают программу, которая не будет иметь записи в таблице задач и с которой нельзя работать обычным функциями работы с заданиями.
Для ссылки на задания можно использовать специальные переменные: %NUMBER --- для ссылки на задание номер NUMBER (как в bash); %STRING и %?STRING --- для ссылки на задания, чьи командные строки начинаются и содержат строку STRING, соответственно; %% (или %+) и %- для ссылки на текущее и предыдущее задание.
Загрузчик LILO
Загрузчик LILO (LInux LOader), созданный Вернером Альмесбергером, может загружать ядро Linux как с дискеты, так и с жесткого диска. Он позволяет также загружать другие операционные системы: PC/MS-DOS, DR DOS, OS/2, Windows 95, Windows 98, Windows NT, 386BSD, SCO Unix, UnixWare и т.п. На этапе загрузки может быть задан выбор до 16 разных операционных систем.
LILO - это комплект из нескольких программ: собственно загрузчика, программ, используемых для установки и настройки загрузчика, и служебных файлов.
Программа /sbin/lilo, служащая для изменения конфигурации самого загрузчика. Ее необходимо перезапускать каждый раз после внесения изменений в ядро или в конфигурационный файл LILO. Служебные файлы, необходимые LILO. Обычно располагаются в каталоге /boot. Самые важные из них - собственно загрузчик, файл /boot/map, в котором указывается местоположение ядра, и файл конфигурации LILO /etc/lilo.conf. Собственно загрузчик, т.е. та часть LILO, которая первой загружается по прерыванию BIOS и заводит на компьютер ядро Linux или загрузочный сектор другой ОС. Загрузчик тоже состоит из двух частей: первая записывается в загрузочный сектор и служит для загрузки второй части, которая значительно больше по размеру. Обе части обычно хранятся на диске в файле /boot/boot.b.
Надо иметь в виду, что формат загрузочного сектора, создаваемого LILO, отличается от формата MBR в MBR; поэтому, если записать загрузочный сектор LILO в MBR, то ранее использовавшиеся операционные системы от Microsoft перестанут загружаться. Загрузочный сектор LILO организован так, чтобы его можно было использовать как загрузочный сектор раздела; в частности, в нем есть место для таблицы разделов. Загрузочный сектор LILO при установке системы можно разместить в следующих местах:
загрузочный сектор дискеты в формате Linux (/dev/fd0, ...); MBR первого жесткого диска (/dev/hda, /dev/sda,...); загрузочный сектор первичного раздела файловой системы Linux на первом жестком диске (/dev/hda1, /dev/hda2, ...); загрузочный сектор логического раздела в расширенном разделе первого жесткого диска (/dev/hda5, ...). Большинство программ типа fdisk не предполагают, что можно загружаться из расширенного раздела и отказываются объявлять его активным, поэтому в состав LILO включена специальная программа activate, позволяющая обойти это ограничение. Программа fdisk с опцией -b или с переменной BOOT поддерживает возможность активизации расширенного раздела.
Укажем также места, где размещать загрузочный сектор LILO нельзя:
загрузочный сектор дискеты или первичного раздела, отформатированных в других файловых системах; раздел подкачки Linux; второй жесткий диск.
 |
| Рис. 1. Структура главной загрузочной записи раздела |
Загрузка ОС с физического диска
Вопрос «Нельзя ли загружать ОС виртуального компьютера с физического диска?» особенно актуален в том случае, когда до установки VMware на компьютере в разные разделы уже была установлена как ОС Linux (в которой запускается виртуальный компьютер), так и одна из версий Windows [2]. Ответ на этот вопрос положителен. Более того, VMware может использовать загрузчики, установленные на компьютере ранее. Загрузчик будет работать внутри VMware и даст возможность пользователю выбрать ОС, запускаемую на виртуальном компьютере. Можно и заново установить ОС (скажем, Windows 98) на физический диск, а потом запускать ее в виртуальной машине.
Использование установленной на физическом диске операционной системы сопряжено с некоторыми особенностями; их надо учитывать при настройке ОС. Во-первых, версия VMware 2.0 поддерживает загрузку с реальных дисков только для IDE-устройств (при этом файл, моделирующий виртуальный диск, можно расположить как на диске IDE, так и на SCSI). Во-вторых, необходимо создать отдельный профиль оборудования для Windows.
Операционные системы Windows 95/98/NT используют понятие «профиля оборудования». Каждый профиль определяет некоторый набор известных системе устройств. Если заданы два или более профиля, пользователю в процессе загрузки предлагается выбрать один из них. Благодаря механизму Plug and Play, в процессе загрузки эти ОС (кроме NT) проверяют, отвечают ли реальные устройства указанному профилю оборудования. Несоответствие приводит к тому, что механизм определения устройств и установки драйверов запускается заново. В большинстве случаев этот процесс завершается успешно, однако существенно замедляет загрузку. NT не поддерживает Plug and Play и использует профиль оборудования для инициализации устройств. Если реальный набор не соответствует тому, что указано в профиле, выдается сообщение об ошибке, а устройство не подключается. А поскольку конфигурация виртуального компьютера отличается от конфигурации компьютера физического, то для запуска ОС от Microsoft внутри виртуальной машины надо создать отдельный профиль оборудования, чтобы упростить процесс загрузки. Поэтому процесс создания и конфигурирования виртуальной машины, которая использует операционную систему, установленную в один из разделов физического диска, имеет некоторые отличия от процесса создания виртуальной машины, работающей с виртуальными дисками.
Вначале надо установить на физический диск IDE реального компьютера операционную систему, которую требуется запускать на виртуальном компьютере. До запуска VMware загрузить на реальном компьютере эту ОС и создать два профиля оборудования. Для этого открыть «Панель управления», войти в пункт «Система» и переключиться на вкладку «Профиль оборудования». Там уже имеется как минимум один профиль, который называется «Текущий». Щелкнуть по кнопке «Копировать» и ввести название нового профиля, например, «Виртуальная машина».
Только для NT/2000. Отключить некоторые устройства во вновь созданном профиле, открыв пункт «Устройства» в «Панели управления», выбрав отключаемое устройство и нажав клавишу «Остановить» (необходимо отключить аудио-плату, MIDI, джойстик, Ethernet и другие сетевые платы, а также USB-устройства; отключать их надо только во вновь созданном профиле, не промахнитесь). Если в виртуальном компьютере предполагается запускать Windows 95 или Windows 98, то отключать устройства не требуется; это будет сделано автоматически на стадии загрузки ОС. Перезагрузить компьютер и запустить Linux. Убедиться, что раздел физического диска, который отведен для использования операционной системой виртуального компьютера, не смонтирован в Linux. Удалить (закомментировать) соответствующую строку в файле /etc/fstab, а в текущем сеансе размонтировать этот раздел непосредственно из командной строки. Задать права доступа к разделам жесткого диска. Самый простой способ сделать это заключается в том, чтобы включить пользователей VMware в группу disk, дав тем самым доступ ко всем физическим устройствам /dev/hd[abcd], которые содержат операционные системы или загрузчик, а в вопросах разграничения доступа положиться на конфигурационные файлы VMware. Тем самым обеспечивается доступ загрузчика к файлам, необходимым для запуска операционных систем (например, LILO требуется доступ на чтение к каталогу /boot в разделе Linux для запуска операционных систем, отличных от Linux, которые могут быть расположены на других разделах или дисках). Сконфигурировать виртуальную машину под вновь установленную ОС, используя Мастер конфигурации или Редактор конфигурации. Выполняя процедуру конфигурации для реальных дисков, при выборе типа виртуального диска следует выбрать пункт «Existing Partition». Для раздела диска, в котором находится соответствующая операционная система, установить права на чтение и запись. Для основной загрузочной записи и для других разделов рекомендуется предусмотреть право на чтение (вновь напомним, в частности, что загрузчик LILO должен иметь возможность прочитать файл из каталога /boot в разделе Linux). Запустить VMware и проверить созданную конфигурацию. Это можно проделать при помощи команды vmware <config-file>, где <config-file> — полное маршрутное имя конфигурационного файла, созданного Мастером конфигурации (имена таких файлов имеют расширение .cfg).
Открыть пункт меню «Settings > Configuration Editor» и убедиться в том, что в конфигурации дисков IDE указан хотя бы один физический диск («Raw Disk») и для него введено имя файла описания диска. Эти имена обычно имеют вид наподобие <configuration-name>.hda.dsk, <configuration-name>.hdb.dsk, и т.д. Полезно проверить и другие параметры конфигурации, особенно те, для которых указано значение по умолчанию, например, объем памяти виртуальной машины.
Включить питание виртуальной машины (кнопка «Power On»). VMware запускает Phoenix BIOS, после чего считывается главная загрузочная запись загрузочного диска. Если система была сконфигурирована с использованием нескольких дисков IDE, VMware BIOS попытается произвести загрузку ОС с этих дисков в следующей последовательности: Primary Master, Primary Slave, Secondary Master, Secondary Slave. При наличии нескольких дисков SCSI загрузка производится в порядке номеров SCSI-устройств. Если в системе сконфигурированы диски обоих типов, VMware BIOS сначала пытается загрузить ОС со SCSI-устройств, затем — с IDE. Порядок обращения к дискам в процессе загрузки можно изменить через пункт меню «Boot» в BIOS виртуальной машины (чтобы попасть в меню BIOS, после включения питания VMware надо нажать клавишу F2). Если предусмотрена многовариантная загрузка, выбрать нужную ОС из предлагаемого при загрузке меню.
 |
| Рис. 1. Выбор профиля оборудования для виртуального компьютера |
В процессе загрузки ОС должно появиться меню выбора конфигурации (если, конечно, для виртуального компьютера был создан отдельный профиль оборудования). Ввести номер, соответствующий конфигурации виртуального компьютера (см. рис. 1). Только для Windows 2000. После того, как в качестве ОС на виртуальном компьютере запустится Windows 2000, появится диалоговое окно «Найдено новое оборудование», в котором предлагается установить новый драйвер для видео-контроллера. Этого делать не нужно. Windows 2000 автоматически обнаружит и установит драйвер для сетевой платы AMD PCnet PCI Ethernet. Затем на виртуальном компьютере надо установить пакет VMware Tools. После того, как будет установлен SVGA-драйвер от VMware, перезагрузить Windows 2000 на виртуальной машине; затем можно поменять разрешение экрана виртуальной машины.
Только для Windows 95/98. В окне «Обнаружено новое оборудование» Windows предложит провести поиск драйверов. Для большинства устройств драйверы уже установлены, однако, в некоторых случаях может понадобиться установочный компакт-диск, и Windows попросит несколько раз перезагрузиться. Windows может не распознать компакт-диск, тогда рекомендуется указать в качестве пути к драйверу каталог C:\windows\system\ или отказаться от установки драйвера. Подключить такие устройства можно позже. Когда Windows установит виртуальные устройства и драйверы для них, надо удалить из системы неработающие устройства, соответствующие реальному оборудованию. Для этого, используя вкладку «Панель управления > Система > Устройства», выбрать неработающее устройство и щелкнуть по клавише «Удалить» (предварительно надо выбрать профиль оборудования, соответствующий виртуальному компьютеру, чтобы не удалить устройства, работающие при запуске ОС с физического диска).
Только для Windows NT. После завершения загрузки ОС просмотреть протокол загрузки, чтобы выявить устройства, которые не подключились; их можно отключить в профиле «Виртуальный компьютер», используя «Панель управления > Устройства».
Убедиться, что все виртуальные устройства работают корректно, особенно сетевые платы. Помните, что состав оборудования виртуального компьютера существенно отличается от набора устройств, реально имеющихся на физическом компьютере.
Только для Windows 95/98. Если какое-то виртуальное устройство отсутствует, следует воспользоваться меню «Панель управления > Добавить новое оборудование».
Установить VMware Tools. Данный пакет будет запускаться в обеих конфигурациях оборудования, но окажет какое-то влияние на работу только в конфигурации «Виртуальный компьютер».
При следующей загрузке Windows в реальном компьютере с использованием профиля оборудования, соответствующего реальной конфигурации аппаратуры, в списке устройств могут появиться некоторые виртуальные устройства; их можно удалить или отключить уже описанным способом. Если при задании конфигурации виртуального компьютера для реального диска установлен режим «с отложенной записью» («undoable») [1], то при перезагрузке ОС нужно либо согласиться с тем, чтобы все операции с диском, проделанные внутри виртуальной машины, сохранялись на диске, либо отказаться от сохранения изменений.
Загрузка с помощью loadlinexe
Не только загрузочные файлы и образы ядра могут располагаться в разделе DOS, но и вообще вся загрузка Linux может быть организована из DOS. Для этого используется программа LOADLIN.EXE, разработанная Хансом Лерменом. В частности, она используется в дистрибутиве Red Hat для организации процедур установки с компакт-диска.
LOADLIN предоставляет самый безопасный способ загрузки с жесткого диска, если на нем есть загрузочный (активный) раздел DOS или Windows. Этот вариант организации загрузки Linux можно особенно рекомендовать начинающим пользователям. Большинство новичков слишком нетерпеливы, для того чтобы прочитать очень хорошее, но длинное описание загрузчика LILO. Программа LOADLIN не требует какой-либо установки, надо только разместить ее саму и образы ядра на одном из дисков, доступных в DOS. С помощью LOADLIN можно загрузить систему с компакт-диска или сетевого диска, не используя загрузочной дискеты. Это делает LOADLIN великолепным инструментом на случай, когда необходимо загрузить Linux после сбоя в работе загрузчика LILO.
Рассмотрим последовательность действий по установке системы с помощью LOADLIN.
Выделить раздел для Linux. Установить Linux в выделенный раздел (LILO следует установить в первый сектор раздела Linux, чтобы не перезаписать MBR и не потерять возможность загружаться в Windows). Загрузить Linux (если не получается по-другому, то используйте загрузочную дискету). Смонтировать раздел DOS (будем считать, что в Linux раздел DOS именуется как /dev/hda1, а раздел Linux - как /dev/hda3): [root]# mount -t vfat /dev/hda1 /mnt/C
Создать каталог /mnt/C/loadlin и разархивировать в него содержимое файла LODLIN16.TGZ из дистрибутива Linux. Поместить туда же файл с образом ядра из каталога /boot. Найти нужный файл образа ядра можно в файле /etc/lilo.conf: нужное имя справа от знака равенства содержится в строке . У меня, например, полное имя этого файла - vmlinuz-2.2.16-3bc, но я при копировании в каталог /mnt/C/loadlin переименовал его в vmlinuz; это имя и буду использовать в примере.
Перезагрузить компьютер в DOS. Если есть возможность загрузить непосредственно DOS, это надо сделать сразу, а если нет, то следует загрузить Windows, при появлении сообщения нажав клавишу F8 и выбрав вариант . Если вы не успели нажать F8, можно дождаться завершения загрузки Windows 95, после чего в меню выбрать пункт и в нем - .
После выхода в режим DOS перейти в каталог C:\LOADLIN и выполнить команды:
C:\LOADLIN> LOADLIN vmlinuz /dev/hda3 ro vga=ask
или, при желании загрузить ядро с установкой диска в оперативной памяти:
C:\LOADLIN> LOADLIN vmlinuz /dev/ram rw initrd=diskimage
Чтобы избавиться от необходимости каждый раз при загрузке вводить команду loadlin со всеми параметрами, можно создать bat-файл или прописать вызов loadlin в файл config.sys. Надо только учесть, что для некоторых графических адаптеров Linux может выдавать после загрузки экран, если перед его загрузкой отображался логотип Windows. Поэтому в файле C:\MSDOS.SYS надо указать:
BootGUI=0 Logo=0
Это позволит избежать загрузки графической оболочки, и выбор пункта меню Windows 95 будет вызывать переход к обычной командной строке DOS.
Загрузка шрифтов
Для загрузки шрифтов используется ключ -f (от слова font). Поскольку, видеокарта может использовать три разных типа шрифтов (необходимых для разных "режимов отображения"), то ключ -f требует два аргумента
vidcontrol -f "тип шрифта" "имя файла со шрифтом"
Тип шрифта может быть 8x8, 8x14 и 8x16.
Файл со шрифтом может быть просто двоичным файлом, или содержать в себе те же данные но в формате uuencode. Если вы не укажете полный путь для имени файла, а просто короткое имя (напрмер - myfont), то vidcontrol будет искать
файл myfont в текущей директории файл myfont.fnt в текущей директории файл myfont в директории /usr/share/syscons/fonts
файл myfont.fnt в директории /usr/share/syscons/fonts
естественно, загрузит первый, который найдет.
Загрузка со SCSI при наличии IDE-дисков
/sbin/lilo делает оба диска незагружаемыми. Бездумный способ: запускать lilo с выключенным IDE (и в BIOS тоже). Разумный способ ищется.
Если диск уже запорчен:
выключить IDE-диски загрузиться с дискеты UPDATE дойти до места где он монтирует SCSI диски перейти в консоль для ручного вмешательства mount /dev/sda6 /mnt cd /mnt bin/bash chroot . mount /dev/sda1 /boot теперь можно запускать lilo
Где взять дополнительную информацию
Загрузка "таблицы перекодировки" (screenmap)
Для загрузки screenmap используется ключ -l (от слова load ?).
vidcontrol -l "имя файла с таблицей"
Как и для шрифтов, файл screenmap может быть просто двоичной таблицей (из 256 байт) или содержать в себе те же данные но в формате uuencode. Если вы не укажете полный путь для имени файла, а просто короткое имя (напрмер - mymap), то vidcontrol будет искать
файл mymap в текущей директории файл mymap.scm в текущей директории файл mymap в директории /usr/share/syscons/scrnmaps
файл mymap.scm в директории /usr/share/syscons/scrnmaps
естественно, загрузит первый, который найдет.
Если вам не нужна никакая перекодировка, используйте ключ -L
vidcontrol -L
по этой команде, vidcontrol сам сделает таблицу, которая ничего не меняет.
Загрузка таблицы раскладки клавиатуры
Для загрузки раскладки клавиатуры служит ключ -l (наверное,load)
kbdcontrol -l "имя файла раскладки"
Если вы не укажете полный путь для имени файла, а просто короткое имя (напрмер - mykbd), то kbdcontrol будет искать
файл mykbd в текущей директории файл mykbd.kbd в текущей директории файл mykbd.kbd в директории /usr/share/syscons/keymaps
естественно, загрузит первый, который найдет.
Кстати, kbdcontrol может выполнить и обратную операцию - напечатать вам ту раскладку, которая в данный момент загружена в syscons. Для этого есть ключ -d (dump).
Загрузочный сектор
Хватайте ваш любимый редактор и наберите следующее:
entry start start: mov ax,#0xb800 mov es,ax seg es mov [0],#0x41 seg es mov [1],#0x1f loop1: jmp loop1
Это понятный as86 диалект ассемблера. Первая инструкция описывает точку входа в программу. Мы объявляем, что управление первоначально должно быть передано на метку start. Вторая строка описывает расположение этой метки (не забудьте поставить ":" после "start"). Первая инструкция, которая должна быть выполнена в этой программе, расположена сразу после нее.
0xb800 -- это адрес сегмента видеопамяти в текстовом режиме. Символ # указывает на непосредственное значение. После выполнения команды
mov ax,#0xb800
регистр ax будет содержать значение 0xb800, это адрес расположения видеопамяти. Теперь мы копируем это значение в сегментный регистр es. Помните, что 8086 имеет сегментную архитектуру. У него четыре сегментных регистра, указывающих на: сегмент кода ( CS ), сегмент данных (DS), сегмент стека ( SS ) и дополнительный сегмент (ES ). Фактически, мы сделали видеопамять нашим дополнительным сегментом, так что все записанное в него, будет записано в видеопамять.
Для отображения любого символа на экране, вам нужно записать в видеопамять два байта. Первый -- это значение ascii-кода символа, который вы хотите вывести на экран. Второй -- атрибут символа. Атрибут содержит следующую информацию: цвет символа, цвет фона, мерцание. Инструкция seg es фактически является префиксом, указывающим относительно какого сегмента должна выполняться следующая операция. Итак, мы заносим в первый байт видеопамяти (адрес 0xb800:0) значение 0x41, которое соответствует ascii-коду символу "A" (большая английская A). Затем мы должны прописать значение атрибута символа в следующем байте видеопамяти. Сюда мы записываем значение 0x1f, соответствующее белому символу на синем фоне. (Чтобы понять, где что спрятано в байте атрибута, лучше преобразовать 0x1f в двоичное представление: 00011111. Здесь первые четыре бита [справа налево] -- цвет символа, следующие три -- цвет фона и последний 7-й бит [отсчет ведется с нуля] -- это признак мерцания. Из вышесказанного можно сделать следующий вывод: в текстовом режиме символ может иметь 16 цветов, фон -- 8. Прим.перев.) Теперь, если мы выполним эту программу, то получим белую "A" на синем фоне. В конце стоит программная "петля" (команда jmp указывающая на саму себя). Нам нужно, либо остановить выполнение кода после того, как отобразим символ, либо "намертво" замкнуть цикл. Сохраните файл как boot.s .
Идея с манипуляцией видеопамятью может быть не совсем понятна, поэтому позвольте мне объяснить на будущее. Предположим мы используем экран размером 80 на 25 (80 символов в строке и 25 строк). Для каждой строки нам нужно по 160 байт: 80 байт, содержащие коды символов и столько же, содержащие их атрибуты. Если нам нужно вывести 3-й символ в 1-й строке, то мы должны пропустить байты 0 и 1, как относящиеся к первому символу; байты 2-й и 3-й, как относящиеся ко второму символу и только после этого записать в 4-м байте ascii-код выводимого символа и в 5-м -- его атрибут.
Используя прерывание 0x13, код загрузочного сектора читает и копирует второй сектор флоппи-диска в память по адресу 0x5000 (сегментный адрес 0x500). Пример этого показан ниже. Сохраните его в файле bsect.s.
LOC1=0x500
entry start start: mov ax,#LOC1 mov es,ax mov bx,#0
mov dl,#0 mov dh,#0 mov ch,#0 mov cl,#2 mov al,#1
mov ah,#2
int 0x13
jmpi 0,#LOC1
Первая строка -- это макро-определение. Следующие две инструкции уже знакомы вам по предыдущей статье. Записать данные непосредственно в регистры сегментов нельзя, поэтому следующие две строки используются для загрузки в регистр es значения 0x500. Регистр bx содержит значение смещения в сегменте, по которому будут загружены данные.
Далее мы записываем...
номер устройства в регистр dl (принцип кодирования описан в пункте 1.3) номер головки чтения/записи в регистр dh номер цилиндра в регистр ch номер сектора в регистр cl количество загружаемых секторов в регистр al
Итак, мы загружаем второй сектор нулевой дорожки устройства номер 0 (что соответствует приводу флоппи-дисков на 1.44Мб) по адресу 0x500:0.
Значение 2 в регистре ah указывает на номер функции прерывания. Мы выбираем функцию номер 2, которая используется для чтения данных с диска (жёсткого или гибкого).
Теперь мы вызываем прерывание 0x13 и последней командой передаём управление коду, загруженному по адресу 0x500:0.
proc не просто, но поняв
Конфигурирования ядра на лету с использованием файловой системы / proc не просто, но поняв один раз его структуру и то, как манипулировать различными параметрами и файлами, вы получите мощную утилиту для управления вашими сервисами в любое время.
Многопользовательская операционная система GNU/ Linux становится все более популярной в однопользовательском контексте. В таких ситуация можно/хочется легко обойтись и без протоколов регистрации пользователя в системе. Данная статья иллюстрирует тот факт, что UNIX-корни не мешают использованию ОС и в таких "специальных" случаях. Несложные изменения конфигурационных файлов и немного программирования -- и процесс входа в систему может быть легко автоматизирован в большинстве дистрибутивов GNU/Linux, в полной мере сохраняя гибкость и настраиваемость системы.
Адриан Дж. Чанг [Adrian J Chung]
Время, свободное от преподавания информационных технологий студентам Вест-Индийского Университета в Тринидаде [University of the West Indies, Trinidad], Адриан посвещает написанию системных скриптов для управления сетью Linux-машин. Или проводит эксперименты по взаимодействию различных интерпретируемых языков [scripting environments] с "самопальными" [home-brew] библиотеками визуализации и построения изображений [computer graphics renderers and data visualization].
Итак, теперь вы в общих чертах знаете, как задать вашему компьютеру "работу на дом" (подробнее смотрите в man-страницах [3]). Дерзайте! Только имейте в виду, что те команды, которые вы прописываете в crontab-файлах, должны быть написаны без ошибок. Дело в том, что если команда задана с ошибкой, результатом ее выполнения, в лучшем случае, будет появление в вашем почтовом ящике сообщения об ошибке. Проснувшись утром вы не обнаружите тех положительных результатов, на которые рассчитывали, задавая с вечера работу вашему электронному другу. Не говоря уж о гораздо более неприятной ситуации, когда увидев результаты выполнения "домашнего задания", вы испытаете желание ударить по компьютеру кувалдой. Помните, что источником всех ошибок является не компьютер, а его владелец. Компьютер пока что не более чем "тупая" машина, которая слепо и точно выполняет все, что вы ему задали. Поэтому, прежде чем прописать задание на ночь, несколько раз проверьте, как оно будет выполняться под вашим присмотром.
Как видно из нашего рассказа, LVM -- это полностью масштабируемое и очень простое в использовании решение. После настройки групп томов размеры логических томов легко меняются по необходимости.
Опыт - штука наживная. И, как говорят, умный учится на чужих ошибках, а дурак - на своих. Поэтому записывайтесь в первую группу, перенимайте чужой опыт - и жить будет легче. Особенно в наши времена, когда так трудно найти приличную работу.
Евгений БОБРУЙКО, es2001@ukr.net
В заключении мы видим, что стандартная инсталляция FreeBSD оптимизирована для безопасности и целостности, совершенно не оптимизирована для использования в качестве высокопроизводительного сетевого сервера. В подавляющем большинстве случаев при обслуживании большого количества одновременных соединений, надежной поддержке большого количества процессов и высоким требованиям к производительности файловой системы, необходимо предпринять шаги для увеличения скорости системы по сравнению с конфигурацией "по умолчанию". Плюсы, которые могут быть извлечены из этого поистине огромны ? это повышение производительности как минимум в два раза!
Вниманию вебмастеров: использование данной статьи возможно только в соответствии
с правилами использования материалов сайта «Софтерра» (http://www.softerra.ru/site/rules/)
Заключительные действия
Протестируйте, что из GRUB всё работает:
Вы должны загрузить все 4 операционные системы с дискеты GRUB.
Если всё в порядке, то можно продолжать и установить GRUB на свой жесткий диск. Из linux наберите:
grub-install /dev/hda
Теперь вы можете загрузить все 4 операционные системы из меню GRUB. Наслаждайтесь!
"Заключительный аккорд" - "отцепляемся" от скан-кодов
Как я уже говорил - не очень хорошо, когда "действия" назначаются прямо в описании клавиши (в файлах xkb_symbols).
Во всяком случае, при этом трудно распространить наше решение на случай, когда роль основного или дополнительного переключателей (или обоих) выполняет не одиночная клавиша, а комбинация клавиш.
Обычно "хорошим тоном" является - привязать "действия" к каким-нибудь сиволам (через "интерпретации"), а в описании клавиш использовать только символы.
Давайте проделаем это для любого из примеров, например, последнего.
Единственная проблема - надо подобрать подходящии символы. Дело в том, что брать коды обычных символов (даже "экзотических" - типа "умлаутов") не очень хорошо. Потому, что при нажатии клавиши XKB будет не только выполнять соответствующие "действия", но и выдавать в прикладную программу эти символы. А программа, соответственно, будет пытаться их напечатать.
К счастью, в наборе символов есть группа кодов, которые должны использоваться только для внутренних нужд XKB и игнорироваться прикладными программами. Вы можете найти их в файле {XROOT}/include/X11/keysymdef.h
их названия начинаются на XK_ISO_. Например,
XK_ISO_First_Group XK_ISO_First_Group_Lock XK_ISO_Last_Group XK_ISO_Prev_Group_Lock
и т.п.
Конечно, там нет символов из названия которых следует, что по этому символу "записать в locked group число 3". Но мы можем изменить семантику любого из символов (тем более, что и не для каждого из этих символов задана семантика в "конфигах" XKB).
Давайте сначала выясним - сколько нам надо символов. Для этого посчитаем - сколько у нас различных действий в описании обоих переключателей.
LockGroup(group=1) LockGroup(group=2) LockGroup(group=3) SetGroup(group=2)
Итого - 4 штуки.
Давайте подберем им символы. Конечно, можно взять любые из тех о которых говорилось выше. Но, чтобы лучше в них ориентироваться, подберем такие, чтобы их название хоть немного походили на соответствующие действия.
Обратите внимание, чтов названиях присутствуют - First_Group, Last_Group, Next_Group и Prev_Group.
Давайте считать, что для нашего случая
First_Group - group=1
Next_Group - group=2
Last_Group - group=3
Тогда логично выбрать
для LockGroup(group=1) - ISO_First_Group_Lock
для LockGroup(group=2) - ISO_Next_Group_Lock
для LockGroup(group=3) - ISO_Last_Group_Lock
для SetGroup(group=2) - ISO_Group_Lock
Составим соответствующие "интерпретации". Напомню, что это нужно делать в файле типа xkb_compat и, соответственно, "приплюсовать" это файл к строчке в "полной" конфигурации, которая описывает именно xkb_compat
(а не xkb_symbols).
Итак, наша "добавка" к xkb_compat (не забудьте ее "приплюсовать" куда надо) -
xkb_compat { interpret ISO_First_Group_Lock { action=LockGroup(group=1); }; interpret ISO_Next_Group_Lock { action=LockGroup(group=2); }; interpret ISO_Last_Group_Lock { action=LockGroup(group=3); }; interpret ISO_Group_Lock { action=SetGroup(group=2); locking = True;};
group 2 = AltGr; group 3 = AltGr; };
(Последнии две инструкции, "по идее" не нужны, поскольку уже должны быть в "общей конфигурации". Но почему-то они иногда "теряются".)
А описание символов (в xkb_symbols) теперь будут выглядеть как
key <CAPS> { [ ISO_Next_Group_Lock ], [ ISO_First_Group_Lock ], [ ISO_Last_Group_Lock ] };
key <MENU> { [ ISO_Group_Lock ] };
Можно пробовать.
На этом наши эксперименты на тему переключателей не заканчиваются.
Дальше мы рассмотрим еще более сложный случай (и другие механизмы) -
Заметки о Linux-консоли Что же такое консоль
Алексей Федорчук
alv@linux-online.ru
Как уже было сказано, в случае настольной машины консоль - это сочетание экрана монитора и клавиатуры (мышь пока оставим в покое). То есть некая физическая реалия, правда? Правда, чистая правда, но - не вся правда.
Потому что одно из первых открытий, которое совершал ранее начинаюший линуксоид, - так называемые виртуальные консоли. Помнится, меня на первой фазе знакомства с Linux'ом они просто привели в восторг (каковой не ослабевает и по сей день). Нынче - не то: пользователь ну очень дружественного к нему дистрибутива, где по умолчанию устанавливается графический вход в систему, имеет шанс просто не узнать о них...
Виртуальные консоли - это (почти) самостоятельные системы (правда, работающие за счет одних и тех же ресурсов), в каждой из которых может быть открыт отдельный сеанс работы пользователя (или пользователей - а даже в самой-рассамой персональной Linux-системе их как минимум двое, включая root'а) и запущен совершенно независимый круг задач (включая оконную истсему X), со своими собственными настройками, наиболее для этого круга подходящими.
По умолчанию в большинстве дистрибутивов Linux активизировано шесть витруальных консолей (во FreeBSD, например, - восемь). Переключение между ними традиционно осуществляется комбинацией клавиш Alt+(F1-F6), клавиша PrtScr перемещает в следующую, после текущей, виртуальную консоль. Кроме того, т.н. Win-клавиши, без которых не обходится ни одна современная "доска", по умолчанию также служат для навигации по виртуальным консолям, позволяя перейти, скажем, к последней использвовшейся, и т.д. - точно не помню, потому что всегда переопределяю их назначение.
Раз уж зашла речь о переопределении - сделаю два маленьких замечания. Во-первых, комбинация Alt+F# для перехода между консолями не являет собой нечто предопределенное божественным промыслом. Ибо зависит исключительно от текущей раскладки клавиатуры, о чем подробнее будет говориться в одной из следующих заметок. Другое дело, что во всех известных мне штатных раскладках для Linux (и FreeBSD) именно эта комбинация задействована под навигацию по консолям (тогда как в раскладках OpenBSD, например, используется комбинация Alt+Control+F#). Но при желании такое положение дел можно изменить (и об этом также речь пойдет впереди) - другой вопрос, нужно ли это делать.
Во-вторых, на некоторых мультимедийных клавиатурах и клавиатурах ноутбучного типа, с которыми мне приходилось сталкиваться, дополнительные win-клавиши категорически отказывались выполнять свои навигационные функции. И вообще, следует помнить, что во всех Unix-системах, вследствие их кросс-платформенности, гарантированно однозначно ведут себя только основные алфавитно-цифровые клавиши, прочие же (стрелки управления курсором, клавиши на цифровом блоке, даже Delete и Backspace) в общем случае отнюдь не обязаны выполнять привычные пользователям связки PC-Windows обязанности.
К слову сказать - именно в этом одна из причин неувядающей популярности текстового редактора vi (и его клонов) среди системных администраторов: в какой бы системе своего подшефного зоопарка он ни оказался, его не оставит чувство уверенности в том, что привычные клавиши командного режима (под которые задействована только основная часть "доски") будут всегда вести себя совершенно однозначно.
Однако я отвлекся, вернемся к нашим консолям. Я уже говорил, что каждая виртуальная консоль может рассматриваться как самостоятельная, индивидуально настроенная, система. С оговоркой - "почти". Потому что в том, что касается пользовательских настроек программного уровня, это верно безусловно: авторизовавшись на второй консоли от лица другого пользователя, мы получаем рабочую среду, свойства которой описаны в его пользовательских конфигурационных файлах. Однако что касается собственно свойств консоли - тут существуют многочисленные ограничения.
Одни из свойств консоли (такие, как цвет шрифта и фона) действительно могут быть настроены независимо для каждой виртуальной консоли. Однако самые важные для пользователя характеристики - шрифт и раскладка клавиатуры, - загружаются для всех консолей сразу. Также на все консоли распространяется и карта соответствия (так называемая mapscreen) кодировки ввода (то есть раскладки клавиатуры) и кодировке вывода (то есть экранного шрифта), о чем подробнее будет говориться в заметке о русификации. Хотя (и это важно) карта соответствия не активизуется одновременно с активизацией произвольной виртуальной консоли. Тем не менее, настроить одну консоль на вывод русских текстов в кодировке KOI8-R, другую - в Windows-кодировке, а третью - так вообще в Unicode, без дополнительных ухищрений (о которых я скажу в свое время) не удастся.
Равноценны ли виртуальные консоли? Чтобы ответить на этот вопрос, придется обратиться к истории. Во времена былинные, до рождества PC, существовали так называемые большие машины, которые жили своей самостоятельной жизнью в специально отведенных заповедниках, куда пользователям путь был заказан. И общались с ними пользователи посредством так назваемых терминалов - локальных мониторов и клавиатур, не имевших собственных вычислительных ресурсов - все они были сосредоточны в главной машине, предоставлявший их терминалам через последовательные линии связи (но нынешнему, COM-порты). Власть пользователей была ограничена, каждый управлял только своими данными, и не имел (теоретически) никакой возможности повлиять на систему в целом.
Однако имелся среди пользователей один умник, который всех напаривал (пардон, всем управлял). Он назывался root-оператором (или просто root'ом), обладал всевластием в масштабе данной системы и реализовывал это всевластие с собственного, всевластного, терминала. Вот этот-то терминал всевластия и назывался консолью в предначальном смысле этого слова.
Казалось бы, консоль - точно такой же терминал, что и любой пользовательский. Однако root, обладая тайным знанием - своим собственным паролем, от которого его всевластие и зависело, мог засадить в систему все хитрости свои, все меры защиты, и все такое. В частности - запрещение авторизоваться root'ом с любого другого терминала, кроме консоли. А для напаривания (опять пардон, управления) пользователями он делал так, чтобы на консоль выводились все системные сообщения (в том числе сообщения об ошибках и информация об авторизации пользователей), почему консоль root'а и получила название системной.
Однако PC уравняла пользователей в правах не хуже дивайса полковника Кольта. И хотя даже на персоналке в любой Unix-системе по прежнему имеется всевластный root, в роли его обычно выступает сам пользователь настольной машины, И в его праве предоставить самому себе возможность авторизоваться root'ом или обычным пользователем с любой из виртуальных консолей (случай ущемления прав в домашних многопользовательских системах не рассматриваем, это - дело семейное). Можно организовать даже автоматический беспарольный вход в систему на любой из активизируемых при загрузке консолей.
Другое дело, что и тут можно зарезервировать для целей управления какую-либо одну консоль (запретив с остальных авторизацию root'ом). А также отвести отдельную консоль для вывода системных сообщений и сообщений об ошибках. Однако от рождения все виртуальные консоли равноправны. Несколько "равнее" других только текущая (в данный момент) консоль - именно на нее по умолчанию выводятся системные сообщения (если вообще вывод их не подавлен, как часто делается на настольных машинах). Разумеется, она же служит и для отображения ввода, если не используются специальные приемы перенаправления (но это - тема разговора о командных оболочках).
Еще одно отличие текущей консоли от всех прочих проявляется при запуске с нее какой-либо программы графического режима, например, Иксов (а при этом в первую очередь запускается вполне конкретная программа - X-сервер) или приложений, основанных на библиотеке SVGAlib (последних, правда, немного, кроме знаменитого Doom'а это, пожалуй, только графический вьювер zgv). В этом случае текущая консоль просто блокируется вплоть до выхода из Иксов (или из SVGAlib-программы). А для запушенной с нее программы активизируется новая виртуальная консоль (об активизации новых консолей - в следующем разделе), перехватывающая на себя и ввод, и вывод, то есть становящаяся текущей. Блокируется при этом и традиционная клавишная комбинация перехода - Alt+F#. Чтобы вернуться в какую-либо из виртуальных консолей, свободную от Иксов, требуется уже три пальца - Alt+Control+F# (не ради ли единообразия в OpenBSD она же используется для навигации по виртуальным консолям вообще?).
Забегая вперед, отметим, что использующая графику программа, запущенная из консоли с поддержкой графического режима через frame buffer (кучеряво получилось, впредь для этого попробую использовать термин фрейм-консоль), занимает только консоль текущую. Правда, программ таких (пока?) очень мало...
Уравнение в правах консоли и терминалов привело к тому, что ныне термины (виртуальная) консоль и (виртуальный) терминал часто выступают в качестве синонимов. И это, товарищи, почти правильно - хотя только для настольных персоналок. И то, следует помнить, что если терминал на PC - всегда виртуален, то консоль имеет и физическое вполощение - монитор и клавиатуру, физически прикрученные к данному системному блоку. Можно сказать, что файл устройства консоли (/dev/console) выступает в качестве реинкарнации активного в данный момент виртуального терминала.
Кроме того, слово терминал служит для обозначения программ эмуляции текстовой консоли с ее командной оболочкой (а в следующем разделе будет показано, что консоль в большинстве случаев тесно сопряжена с шеллом) в графическом режиме оконной системы X. Однако такие программы правильнее так и называть - эмуляторами терминала (или терминальными окнами). И вообще, к Linux-консоли они отношения не имеют, да и к Linux'у вообще - лишь косвенное, так как являют собой обычное Иксовое приложение. Речи о них в этих заметках не будет.
В заключение - несколько номенклатурных замечаний. Как известно, все, что существует в Unix-системе статически - суть файлы, в том числе физические или виртуальные устройства. И консоли тут - не исключение, каждой из них соответствует свой файл в каталоге /dev. Выше упоминалось, что физической консоли соответствует файл /dev/console, имеющий идентификатор группы устройств, так называемый старший (major) номер устройства, равный 5, и идентификатор конкретного устройства, младший (minor) номер, равный 1.
Виртуальные консоли в Linux'е ранее ставились в соответствие файлам вида /dev/tty??, где ?? соответствовал порядковому номеру устройства и мог изменяться в пределах от 0 до 63 (почему - будет подробно рассказано в следующей заметке), хотя в реальности их могло быть меньше. Старший номер всех их был равен 4, младший - был идентичен номеру устройства.
В большинстве современных Linux-дистрибутивов используется так называемая файловая система устройств (devfs), вносящая существенные коррективы в номенклатуру последних. Согласно ей, файлы устройств виртуальных консолей сгруппированы в каталоге /dev/vc/ (в некоторых системах имя каталога, в который монтируется devfs, может быть иным). И именуются они просто своими номерами - /dev/vc/1, dev/vc/2 и так далее, каковые и выступаю заодно в качестве младших номеров устройств (старший номер остается прежним - 4).
Во всех известных мне дистрибутивах, задействующих devfs, используется также демон devfsd, обеспечивающий обратную совместимость с файлами устройств в старой номенклатуре (собственно, дело не только в поддержке старой номенклатуры, но это выходит за рамки сегодняшней темы). И потому в каталоге /dev можно обнаружить и файлы устройств виртуальных консолей типа /dev/tty??. Однако это - лишь символические ссылки на файлы реальных устройств, в чем легко убедиться командой
$ ls -l /dev/tty*
которая выведет список вида
lr-xr-xr-x 1 root root 4 Июн 8 2003 /dev/tty0 -> vc/0 lr-xr-xr-x 1 root root 4 Июн 8 2003 /dev/tty1 -> vc/1 lr-xr-xr-x 1 root root 5 Июн 8 2003 /dev/tty10 -> vc/10 lr-xr-xr-x 1 root root 5 Июн 8 2003 /dev/tty11 -> vc/11
и так далее.
Однако теоретически при использовании devfs наличие файлов устройств старого образца отнюдь не обязательно и зависит от настроек демона devfsd в файле /etc/devfsd.conf. А, например, в моей самостройной системе я вообще отказался от обратной совместимости, и никаких tty?? в ней нету. От чего, к слову, никаких неудобств я не испытываю. И во всех остальных заметках молчаливо подразумечается использование файловой системы устройств.
Вот и все общие слова, которые я хотел сказать о консолях. В следующей заметке разговор пойдет о том, сколько же их, консолей, бывает в Linux-системе.
Заметки о Linux-консоли Прорубить окно в систему
Алексей Федорчук
alv@linux-online.ru
Как уже говорилось, экранную часть виртуальной консоли можно сравнить с окном, через которою мы наблюдаем за процессами в системе. Подобно окну экран консоли не только дает возможность видеть происходящее, но и ограничивает кругозор. Потому что реально оперировать можно только той информацией, которая в текущий момент выведена на экран.
Чтобы убедиться в справедливости сравнения экрана с окном (не в смысле оконной системы Икс, и тем более не в понимании MS Windows), представим себе выделение мышью блока текста, например, в редакторе. Подробностям мышиной темы я собираюсь посвятить отдельную заметку. Пока же заметим, что при этом происходит автоматическое копирование выделенного экранного блока в буфер обмена. Подчеркиваю - именно экранного блока, а не текстового фрагмента: если строка выходит за пределы экрана, невидимая в данный момент ее часть в буфер обмена не попадет. Также не будет скопирована и часть абзаца, уходящая вниз. То есть экранному буферу консоли глубоко безразлична разметка текста.
В то же время, если блоки для копирования и вставки выделять средствами текстового редактора (в joe, например, этой цели служат команды Control+K-B для начала и Control+K-K - для конца выделения блока. В этом случае мы, действуя клавишами управления курсором (или такими командами Joe, как Control+F, Control+B, Control+P, Control+N), как бы протаскиваем наш текст через прорезь экрана. Подобно тому, как детский диафильм стародавних времен для своего воспроизведения протаскивалася через соответствующий агрегат (кто не помнит - назвался он диапроектором). Правда, в случае с экранным буфером такое протаскивание возможно как по вертикали, так и по горизонтали.
И так, "призрачно все в этом мире бушующем, есть только миг", запечатленный в экранном буфере текущей виртуальной консоли. И потому возникает естественное желание продлить мгновение. Или, вспомнив, что миг этит мы видим в окне экрана, - прорубить окно пошире. И способы для этого имеются.
Поскольку сам по себе размер экрана - объективная реальность, данная нам в дюймах его диагонали (да и то, в случае CRT-мониторов, с обманом), напрашивается решение - поместить на экран как можно больше информации. То есть - увеличить разрешение.
Термин "разрешение" применительно к текстовому режиму используется в несколько ином смысле, чем в графических системах типа Иксов или MS Windows. Ведь в качестве единицы измерения ширины и высоты экрана здесь выступает не пиксель, а их набор (матрица), составляющий единичный символ. И потому правильнее говорить не о разрешении экрана текстовой консоли, а о плотности символов на ней.
Это повелось со стародавних времен чисто текстовых мониторов и видеоадаптеров, когда на экране могли воспроизводиться только цельные символы, выдаваемые знакогенератором видеоподсистемы из неких фиксированных их наборов, как бы "вшитых" в нее. Однако уже давно видеокарты приобрели способность подгружать (и выводить на экран) и разные другие наборы символов, считываемые из соответствующих шрифтовых файлов. Вот этим-то свойством мы и воспользуемся для расширения нашего поля зрения.
Стандартная плотность символов текстовой консоли в Linux, устанавливаемая по умолчанию, составляет 80 колонок на 25 строк (80x25). И обеспечивается она использованием шрифта с матрицей 8 на 16 пикселей (в имени такого шрифтового файла, вне зависимости от кодировки, присуствуют эти цифры - 8x16). То есть, казалось бы, для увеличения "разрешения" текстовой консоли достаточно было бы подгрузить шрифт с иной матрицей символов. Однако это не совсем так.
Начать с того, все консольные шрифты, говоря типографскими терминами, не пропорциональные, а моноширинные (то есть ширина буквы "л" в пикселях точно такая же, как и ширина буквы "щ". Далее, ширина символьной матрицы - фиксированная для любых шрифтов, и составляет 8 пикселей. Это обусловлено аппаратными особенностями видеосистемы тех компьютеров, которые в старое время называли IBM PC-совместимыми (а нынче кличут просто PC или писюками - это те самые машины, за которыми мы с вами и сидим). В них под ширину символа отведено 9 пикселей, причем последний, 9-й, зарезервирован на тот случай, чтобы между символами на экране всегда оставались пробелы, даже между буквами типа "н" и "м" (то есть теми, у которых полностью заняты первая и посленяя колонки матрицы). И, следовательно, заменяя шрифт с матрицей 8x16 на более мелкий (а стандартно в любом дистрибутиве можно найти еше и шрифты с матрицами 8x14 и 8x8 для любых кодировок, для некоторых же наборов символов доступны высоты матрицы 12, 10, 9, 7 и 6 пикселей), мы увеличиваем лишь количество строк, отображаемых на экране, при сохранении количества символов в строке.
Забегая вперед, отмечу, что в Linux-консоли возможно использование шрифтов с количеством строк матрицы, отличным от 8. Но - только в режиме графической консоли, который будет предметом одной из финальных заметок цикла.
Тем не менее, в некоторых случаях этого может оказаться достаточно. И на сей предмет к пакете kbd есть специальная команда - setfont (в console-tools ей соответствует consolechars; длина последней - одна из причин моей нелюбви к этому пакету)). Она требует единственного обязательного аргумента - имени подгружаемого шрифтового файла. То есть в форме
$ setfont cp866-8x8
мы загрузим шрифт в кодировке CP866 и с матрицей символов 8x8, в результате чего плотность строк у нас возрастет более чем вдвое (до примерно 55-56) по сравнению с "умолчальной". Вид экрана, правда, при этом будет вполне отвратительным. И потому "расширение окна" таким образом - лишь временное решение проблемы.
Второй вариант увеличения плотности символов на экране консоли - команда resizecons из все того же пакета kbd (есть она, кажется, и в пакете console-tools). Смысл ее понятен из название - это именно масштабирование консольного дисплея, то бишь изменение количества отображаемых строк и колонок. Она может быть использована в трех формах:
$ resizecons COLSxLINES
или
$ resizecons COLS LINES
а также
$ resizecons -l LINES
где под COLS и LINES понимается количество знаков в строке и количество строк, соответственно.
Использование команды resizecons сопряжено с рядом ограничений. Во-первых, ни количество строк, ни количество колонок не могут быть произвольными числами. Они должны соответствовать фиксированным сочетаниям, поддерживаемым, с одной стороны, ядром Linux, с другой - наличной видеокартой. Теоретически (то есть ядром) поддерживаются значения плотности строк - 25, 28, 30, 34, 36, 40, 44, 50, 60, и плотности знаков в строке - 80, 100, 132 (детали можно посмотреть в файле документации к ядру - /usr/src/linux/Documentation/svga.txt. Однако практически достижимы лишь некоторые сочетания этих значений. Далее в этой заметке я расскажу, как определить значения плотности символов, пригодные именно для данной системы.
Второе ограничение связано с используемыми шрифтов. Дело в том, что команда resizecons, если так можно выразиться, синтетическая, и выполняет несколько последовательных действий. Из которых финальным является смена текущего экранного шрифта тем, который имеет соответствующую плотности строк высоту матрицы (обычно 12 пикселей для 28-30 строк и 8 или 9 - для большего их числа). А имя этого шрифта, как нетрудно догадаться - default, и ни малейшей кириллицы он не содержит. То есть при необходимости работы с русскими текстами вслед за изменением "разрешения" экрана необходимо и переопределить шрифт на соответствующий кириллический.
И наконец (хотя, вероятно, с этого следовало бы начать), в некоторых системах команда resizecons просто отказывается работать, выдавая сообщение о невозможности найти файл указанного видеорежима.
Честно говоря, я разбирался с resizecons довольно давно, и детали уже забыл (так что буду признателен за любые дополнения по этому вопросу). И если пишу здесь о ней - так только ради полноты картины. Потому что есть наиболее эффектвиный способ установки желательной плотности знаков в консоли - передача соответствующих параметров ядру при старте системы.
Для выполнения этого действа неолбходимо, во-первых, иметь должным образом собранное ядро. То есть в пункте его конфигурации Console drivers (при использовании make menuconfig), кроме опции VGA text console (она обязательна в любом случае, кроме встраивания в ядро поддержки Frame Buffer, о чем пойдет речь в заключительных заметках цикла), необходимо включить и опцию Video mode selection support.
Далее, необходимо на стадии загрузки передать ядру параметр vga=значение. Это можно сделать вручную в ответ на приглашение boot при использовании Lilo или включив режим редактирования загрузочной записи, если в качестве загрузчика выступает GRUB. А можно и назначить какой-либо видеорежим загружаемым по умолчанию. В GRUB для этого следует дописать в строку его конфигурационного файла /boot/grub/menu.lst, определяющуюю образ ядра и устройство корневой файловой системы
kernel /bzImage root=/dev/hda?
параметр vga=значение. Например, если придать этой строке вид
kernel /bzImage root=/dev/hda? vga=5
по умолчанию будет загружаться видеорежим с плотностью знаков 80x34. В Lilo той же цели послужит строка
vga=5
добавленная в любое место Linux-секции файла /lilo.conf после строки, определяющей загрузочное устройство (детали - в документации по Lilo, я его основательно подзабыл).
В третьих, и это главное, следует выяснить, какие видеорежимы практически доступны в конкретной системе (напомню, что теоретически доступные режимы перечислены в файле /usr/src/linux/Documentation/svga.txt), и какие из них выглядят подходящими с точки зрения информативности и читабельности. Для этого нужно провести небольшое исследование с помощью передачи ядру параметра vga=ask (любым из упомянутых выше способов). В этом случае перед загрузкой ядра Linux будет выведено предложение просмотреть (нажав клавишу Enter) список доступных видеорежимов в виде вроде следующего:
0 0F00 80x25 1 0F01 80x50 ...
и так далее. Чтобы убедиться, что список этот полон, можно дать команду scan, которая проведет повторный мониторинг возможностей видеокарты (при этом может создасться впечатление, что система пошла на перезагрузку; впрочем, и мертвое зависание в этой ситуации случается) и выведет тот же (или расширенный) список повторно. Чтобы загрузиться в любом из доступных режимов, нужно ввести его номер, шестнадцатеричный (из первой колонки) или восьмеричный (из второй). А перепробовав все режимы, которые кажутся разумными, увековечить его вышеописанным способом в конфигурационном файле Lilo или GRUB.
Параметр vga может принимать и другие значения, например, normal (режим 80x25, что эквивалентно отсутствию параметра vga) или extended (в этом случае загружается какой-нибудь из режимов с большей плотностью строк, какой именно - предсказывать не берусь, скорее всего - 80x50). А при использовании Frame Buffer к списку добавится еще много режимов для графической консоли, но об этом речь впереди.
Загрузка ядра в выбранном видеорежиме через параметр vga никак не влияет на определение экранного шрифта по умолчанию, так как последний будет загружен далее по ходу старта машины при обработке одного из сценариев инициализации (например, /etc/rc.local). Изменение шрифта с "умолчального" на переопределенный можно зримо наблюдать на последней стадии загрузки, почти прямо перед появлением приглашения к авторизации (или - приглашения командной строки, если был выбран описанный ранее способ автоидентификации пользователя). И потому установка видеорежима через параметр ядра не накладывает на выбранный шрифт никаких ограничений. Так, даже использование плотности символов 132x60 ничуть не препятствует назначению умолчальным шрифта с матрицей 8x16. Впрочем, о шрифтах - в следующей заметке.
Но прежде - несколько слов о еще одном способе доступа через виртуальную консоль, осуществляемом через экранную память консоли (console screen memory), которая во FreeBSD удачно называется буфером истории (history buffer - не путать с историей команд, доступ к которой осуществляется средствами шелла). Это - расширение стандартного экранного буфера, позволяющее (по нажатию комбинации Shift+PgUp/PgDown) "пролистать" назад (и вперед - вплоть до текущего) несколько экранов и при помощи мыши вытащить на текущий экран (или другую виртуальную консоль) экранный блок из любого.
Правда, в Linux доступ к буферу экранной истории более ограничен, чем во FreeBSD. Поскольку первое же переключение на другую виртуальную консоль подменяет его содержимое, и при обратном переключении доступ к истории именно этой консоли становится невозможным (во FreeBSD каждая из виртуальных консолей имеет собственный буфер истории, и получиьть к нему доступ можно в любой момент, нажав клавишу ScrollLock, после чего клавиши типа PgUp/PgDown и управления курсором уже не перемещают курсор по текущему экрану, а служат для перемещения по экранам и строкам из буфера истории).
И еще о буфере экрана. Как и всякое историческое явление, текущее его содеражние можно сохранить для потомков. В виде, принятом в Unix - то есть в виде файла. Делается это командой setterm из пакета util-linux (запомним ее, она применяется и для других целей, о которых будет говориться в следующей заметке). Из-за своего многоцелевого назначения команда эта имеет множество опций, с которыми можно ознакомиться через man (1) setterm. Однако в сегодняшнем контексте нас интересуют следующие: dump, append и file.
Команда
$ setterm -dump
создает "слепок" буфера текущей виртуальной консоли в виде простого текстового файла с именем по умолчанию - screen.dump. В качестве ее аргумента можно использовать номер консоли, для которой требуется сделать дамп. А добавление опции --file имя_файла перенаправит этот дамп в файл с указанным именем. Опция же -append присоединит новый дамп к уже существующему файлу - "умолчальному" screen.dump или поименованному опцией -file.
Примечание для крутых программеров. К сожалению, в Linux'е нет инструмента для изготовления истинных скриншотов текстовых консолей (по крайней мере, мне такое не известно). Конечно, при использовании фреймбуфера сделать снимок графической консоли возможно (и об этом мы со временем поговорим), однако графическая консоль - это не чито текстовая.
И тут поневоле приходит на память FreeBSD, где существует утилита scr2png, именно для этой цели и предназначенная. Она принимает на ввод текстовый экранный дамп (создаваемый во Free командой vidcontrol) и преобразует его в графический файл формата PNG, используя информацию об экранном шрифте, данную в виде соответствующей опции. То есть в результате мы получаем графический снимок именно текстовой консоли, идентичный наблюдаемому, причем - очень высокого качества. Не взялся ли кто-нибудь за написание аналогичной программы для Linux'а?
А пока Linux-программеры размышляют на эту тему, мы перейдем к следующему вопросу - украшению консоли, что будет темой следующей заметки.
Заметки о Linux-консоли Сколько бывает консолей
Алексей Федорчук
alv@linux-online.ru
Виртуальная консоль, с одной стороны, - окно в систему (а в одной из следующих заметок я попытаюсь показать, что это не просто метафора), с другой же - рычаг воздействия на нее, подобный архимедову. И потому возникает вопрос, а сколько же таких окон и таких рычагов система может предоставить своему пользователю?
В предыдущей заметке вскользь было упомянуто, что практически во всех современных полнофункциональных дистрибутивах Linux'а при загрузке по умолчанию активизируется шесть виртуальных консолей. Однако число это не обусловлено ничем, кроме традиции, и легко может быть изменено в любую сторону.
В отличие от FreeBSD, где максимально возможное число консолей определяется при конфигурировании ядра (и составляет для умолчального ядра GENERIC целых шестнадцать), консоли в Linux'е создаются (ло определенного предела) на лету, по мере возникновения в них необходимости. Типичный пример - запуск Иксов (или приложений, использующих SVGAlib). Каждый сеанс Иксов (а командой типа startx -- :# или xinit -- :# их можно запустить сколько угодно, вернее, на сколько хватит ресурсов) будет открыт в своей собственной виртуальной консоли, следующей по порядку после уже используемых.
Правда, общее количество консолей для работы вне Иксов от этого не увеличится. Напротив, все терминалы, с которых Иксы были запущены, станут недоступными вплоть до завершения соответствующего Иксового сеанса. То же самое относится и к консолям, с которых были загружены SVGAlib-приложения.
Однако изменить число пригодных к нормальному употребелению консолей можно, и очень легко. Ибо для активизации новой консоли в Linux'е достаточно того, чтобы на ней был запущен какой-либо (в общем случае - любой) процесс.
За запуск процессов непосредственно после старта системы отвечает процесс init (/sbin/init), являющийся родительским (прямо или косвенно, через запуск пользовательских процессов) по отношению ко всем остальным процессам (во загнул-то!). А какие конкретно процессы он запускает - определяется его конфигурационным файлом, /etc/inittab.
Файл этот очень важен для системы вообще, однако детальное его рассмотрение мы отложим до лучших времен (и других заметок). Пока же для нас интересна толко одна его секция, отвечающая именно за активизацию виртуальных консолей при старте. Секция эта в моей системе в данный момент имеет вид:
c1:2:respawn:/sbin/agetty 38400 vc/1 linux c2:2:respawn:/sbin/agetty 38400 vc/2 linux c3:2:respawn:/sbin/agetty 38400 vc/3 linux c4:2:respawn:/sbin/agetty 38400 vc/4 linux c5:2:respawn:/sbin/agetty 38400 vc/5 linux c6:2:respawn:/sbin/agetty 38400 vc/6 linux
То есть мы видим простую colon-separated таблицу о четырех полях и шести записях. Последнее, как нетрудно догадаться, соответствует "умолчальному" количеству виртуальных консолей. А значение полей - следующие: идентификатор записи, уровень (или уровни) выполнения (runlevels), для которого эта запись имеет силу, акция, выполняемая при этом, и собственно исполняемая команда (в данном случае - команда активизации консоли). Сразу оговорюсь, что в других системах значения всех полей, кроме третьего, могут быть несколько иными (или совсем другими).
Идентификатор записи может в принципе быть любым, единственное требование к нему, как к ID любой базы данных (а перед нами - не что иное, как база данных, хотя и предельно элементарная), - уникальность. В большинстве систем здесь можно видеть просто порядковый номер записи, совпадающий с номером виртуальной консоли. Последнее, впрочем, отнюдь не обязательно.
Что такое уровень выполнения - вопрос в данном случае неуместный. Для наших сегодняшних целей достаточно знать, что это то состояние системы, в которое она приходит при нормальной загрузке по умолчанию. В моей системе такое умолчальное состояние достигается при уровне 2, в других здесь может стоять значение любого из доступных уровенй. Так как runlevel 0 соответствует останову системы, runlevel 1 зарезервирован за однопользовательским режимом, когда по определению активизируется только одна виртуальная консоль, а на runlevel 6 происходит перезагрузка системы, то доступными оказываются один из runlevels в диапазоне 2-5 или даже все они - в виде 2345.
Процедуру respawn в третьем поле можно, скорее всего, увидеть в /etc/inittab из любой Linux-системы. Она обеспечивает повторный вызов другого экземпляра того же процесса, который запускается командой из четвертого поля.
Команда же в четвертом поле - это обычно вариации на тему getty, что означает "получение терминала" (get tty). Она вызывает активизацию виртуальной консоли, указанной в качестве аргумента (в нашем примере vc/?) и запуск на ней программы login, обеспечивающей авторизацию пользователя в системе, после чего замешается программой, определенной в качестве его командной оболочки по умолчанию (login shell). Причем все эти программы (getty, login, пользовательский login shell) выполняются внутри одного и того же процесса. Хотя в ходе его протекания процесс этот меняет своего владельца - с root'а на того юзера, который авторизовался на этой консоли.
Завершение пользовательского сеанса работы приводит к смерти этого процесса, однако не вызывает деактивизации данной виртуальной консоли, так как процедура respawn обеспечивает "регенерацию" процесса getty с повторным вызовом программы login и (в случае авторизации) login shell. То есть всем определенным в /etc/inittab виртуальным консолям суждена вечная (до останова или переазгрузки системы) жизнь.
Еще несколько замечаний о содержимом четвертого поля. В приведенном примере использована команда /sbin/agetty (из пакета util-linux). Полный путь к ней указан не случайно - очевидно, что файл /etc/inittab задействуется системой раньше, чем считывается значение переменной $PATH из общесистемного (или, тем более, пользовательского) профильного файла типа /etc/profile. Однако сама по себе команда получения терминала в других системах может быть иной - например, /sbin/mingetty или что-нибудь подобное.
Первый аргумент команды обозначает скорость соединения по последовательной линии. Очевидно, что для виртуальной консоли никакого физического смысла он не имеет и спокойно мог бы быть опущен, что обычно и делается при использовании программы /sbin/mingetty (что и не удивительно, так как mingetty и приспособлена только для работы с вирутальными терминалами). Однако в /sbin/agetty попытка удалить этот аргумент приводит к ошибке (и, соответственно, невозможности загрузки). Так что лучше придерживаться той формы вызова getty, которая принята в вашем дистрибутиве.
Следующий аргумент - файл устройства активизируемой виртуальной консоли. При использовании devfs обязательно давать его именно в новой номенклатуре, вне зависимости от настроек демона devfsd (которые также вступают в силу после считывания /etc/inittab). Если devfs не используется, значение этого аргумента будет - tty1, tty2 и так далее.
Обращаю внимание, что в приведенном примере полный путь к файлу устройства не используется - команда agetty автоматически добавляет к нему префикс /dev/. Однако при использовании других команд получения терминала полный путь может потребоваться.
Наконец, последний аргумент определяет тип "получаемого" командой getty терминала (в примере - стандартная linux-консоль). Он также не обязателен, однако дан мной для пущей определенности (да и вреда от него никакого). Кроме того, насколько я понимаю, указание типа обязательно, если в linux-консоли должен эмулироваться какой-либо иной терминал (вроде vt100 или vt220).
Теперь, зная, как описываются "изначальные" виртуальные консоли, легко догадаться, как изменить их количество. Для уменьшения оного (что несколько сэкономит ресурсы слабой машины) достаточно удалить (или закомментировать) соответствующее число строк. А для увеличения - создать должное количество новых по образу и подобию существующих, изменяя только идентификатор и имя файла устройств:
c7:2:respawn:/sbin/agetty 38400 vc/7 linux c8:2:respawn:/sbin/agetty 38400 vc/8 linux
и так далее, вплоть до
c63:2:respawn:/sbin/agetty 38400 vc/63 linux
Ибо 63 - это максимально возможное количество виртуальных консолей. Обусловлено оно тем, что именно столько младших номеров ранее (до внедрения devfs) резервировалось за устройствами этого класса. Файловая система устройств сняла, как-будто бы, проблему их старших и младших номеров. Однако мне не удалось найти информации о том, можно ли при этом увеличить количество виртуальных консолей сверх приведенного скромного:-) числа. Исходя из соображений обратной совместимости - вряд ли.
Заодно замечу, что сказанного достаточно только при использовании devfs. Если она не задействована, то нет гарантии, что файлы устройств tty7 и выше реально имеются в каталоге /dev. И тогда их нужно будет создать - с помощью сценария /dev/MAKEDEV или непосредственно командой mknod. В первом случе достаточно перейти в каталог /dev и запустить
$ .MAKEDEV -v tty7
ответом на что будет сообщение типа
create tty7 c 4 7 root:tty 666
знаменующее успех предприятия. Если же последует сообщение об ошибке (например, потому, что создание такого устройства не предусмотрено конкретным вариантом сценария MAKEDEV), придется обратиться к команде mknod, требующей указания типа устройства, старшего и младшего номеров, а также прав доступа - за деталями отправляю к man (1) mknod.
А мы тем временем вернемся к истинно толстовскому вопросу: сколько же виртуальных консолей человеку надо? Ответ на него зависит в первую очередь от преобладающей рабочей среды того человека - Иксы ли это или все-таки консоль.
В первом случае увеличивать число виртуальных консолей не потребуется. Скорее, наоборот, его можно и урезать. Скажем, до трех - для запуска Иксов, для системных манипуляций, ну и одну на всякий пожарный случай. Конечно, экономия ресурсов - грошовая, а все же приятно.
А вот если стиль работы - преимущественно консольный, возможны варианты. Можно развести виртуальных консолей практически под каждую возможную задачу, и тогда 8-10 штук - вполне реально будут востребованы. До недавнего времени я придерживался именно такого подхода. И число консолей у меня иногда доходило до 11. Что требовало выработки четкой системы - какие задачи на каких консолях запускаются. А главное - неукоснительно этой системы придерживаться.
Для примера, моя система такова (это не пример для подражания, а просто возможный образец). Вне зависимости от числа консолей, последняя из них предназначается исключительно для запуска Иксов, а предпоследняя - для авторизации (при необходимости) в качестве root'а. Первые четыре консоли, напротив, служат для повседневной работы: на первой я пишу, на второй - смотрю ранее написанные тексты по теме (из которых надергиваю фрагменты с помощью мыши), на третьей запущен браузер (links), четвертая зарезервирована для выполнения необходимызх команд и (или) просмотра man-страниц.
Когда эта система окончательно устаканилась (а главное, следование ей дошло до рефлекторного уровня), я обнаружил, что перманентно мне довольно шести умолчальных консолей - четырех рабочих, одной для потенциального root'а и одной для Иксов. А необходимость в дополнительных терминалах возникает лишь время от времени, для кое-каких разовых акций (в основном копирования/перемещения файлов или просмотра каталогов). Или, напротив, для протяженного, но не требующего вмешательства, процесса, типа проигрывания mpeg-файлов (программой mpg123). И вот тут-то настало время вспомнить о возможности Linux'а (в отличие от FreeBSD) создавать виртуальные консоли на лету, для запуска конкретного процесса.
Очевидный способ открыть новую виртуальную консоль - запустить ту же программу из семейства getty, которая используется для инициации консолей умолчальных, например
$ agetty 38400 vc/9 login
Однако по ряду причин способ этот - не самый удобный. Тем более, что в пакете kbd этой цели служит штатная команда openvt (вероятно, и в console-tools существует аналогичное средство). Она имеет изрядное количество опций (о которых - см. man opennet), однако необходим ей лишь единственный аргумент - имя команды, которая будет исполнена на вновь активизированной консоли (при необходимости для этой команды не возбраняются собственные опции и аргументы). Так, в форме
$ openvt /bin/zsh
она активизирует ближайшую незадействованную консоль (например, 7-ю) и запустит на ней экземляр командной оболочки Z-Shell, команда
$ openvt login
выведет на следующей (скажем, 8-й) консоли предложение авторизоваться. А команда
$ openvt -l user_name
запустит (в данном примере - на 9-й консоли) сеанс работы именованного пользователя (с его командной оболочкой и всеми профильными настройками).
Номер активизируемой консоли можно задать явно, с помощью опции -c. То есть команда
$ openvt -c 63 mpg123 /path/*.mp3
начнет проигрывать на самой дальней консоли все mpeg-файлы из указанного каталога.
При открытии новой виртуальной консоли следует иметь ввиду, что она не будет полностью идентична по своим свойствам консолям "умолчальным". В частности, на нее автоматически не будет выведена "магическая последовательность", обеспечивающая активизацию так называемой карты соответствия (mapscreen), преобразующей кодировку клавиатурного ввода в кодировку экранного вывода. И потому, в случае стандартной для Linux русификации системы (ввод - KOI8, вывод - CP866) просмотреть в ней кириллическоий текст не удастся. Хотя и раскладка клавиатуры нашей новой консоли, и экранный ее шрифт будут вполне кириллическими. Впрочем, активизировать на ней mapscreen можно и вручную, но этому будет посвящена специальная заметка.
Во всех приведенных примерах текущей остается консоль, с которой была дана команда openvt (она назвается также управляющей консолью - это понятие нам потребуется в проследующих заметках). Чтобы одновременно с запуском процесса переключиться на консоль новообразованную, требуется опция -s. Однако и в том, и в другом случае в консоли, с которой запускалась команда openvt, возвращается приглашение командной строки, и в ней можно продолжать нормально работать. Хотя возможность эту можно и блокировать - с помощью опции -w командная строка в текущей (для openvt) консоли становится недоступной до завершения исполнения команды в новообразованной консоли.
Деактивация новообразованной консоли происходит либо естественным образом, по завершении запущенного на ней процесса (пример с запуском mpeg-проигрывателя), либо по принудительному выходу из работающей здесь программы (в примере с zsh и login - с помощью команды exit, а во втором случае также logout). Если команда openvt была дана с опцией -w, то есть блокировкой управляющей консоли, то из нее можно и прервать запущенный процесс - обычной клавишной косбинацией Control+C. При этом в примере с login никакой регенерации приглашения авторизоваться не происходит за отсутствием акции respawn.
Деактивированная тем или иным образом консоль как бы продолжает существоввать. То есть в нее можно перейти и даже посмотреть на остатки вывода выполнявшихся команд (хотя делать в ней, разумеется, ничего нельзя без повторной активации той же командой openvt). Для полного искоренения такой полуживой консоли предназначена специальная команда - deallocvt. В качестве аргументов ее выступают номера консолей, подлежащих окончательному истреблению. Без аргументов же она уничтожит все деактивированные консоли, то есть те, на которых в данный момент не исполняется никакого процесса. Разумеется, консолей умолчальных она не затронет - ведь на них в любом случае запущен процесс getty и порожденная им команда login.
Открывая консоли на лету, легко увлечься и перевалить за те 12, которые легко доступны по комбинации клавиш Alt+F# (к слову, количество активизированных консолей в данный момент можно посмотреть с помощью команды fgconsole). Как же получить доступ к этому консольному изобилию?
Во-первых, как уже говорилось, с помощью клавиши PrtScr в большинстве случаев можно как бы "пролистать" активизированные консоли, начиная с первой. Что, конечно, скучно, если требуется быстрый переход в консоль за номером 13... Во-вторых, к консолям с 13-й по 24-ю обычно возможен по комбинации клавиш Alt+Shift+F#. Однако, как уже было сказано ранее, оба эти способа возможны не всегда, так как зависят и от раскладки клавиатуры, и от ее типа. И к тому же не обеспечивают перехода на консоли с 25-й по 63-ю, буде таковые все же понадобятся.
К счастью, на такой чрезвычайный случай есть специальная, и очень простая, команда, не зависящая ни от чего -
$ chvt #
которая мгновенно перенесет нас в ту консоль, номер которой указан в качестве ее аргумента...
Открывать консоли с помощью openvt доступно только для root'а - это определяется правами доступа к файлам устройств неактивизированных консолей, хозяином которых является суперпользователь (активированная же консоль меняет хозяина на того пользователя, который в ней авторизовался). Поэтому любой запущенный на такой новообразованной консоли процесс также будет выполняться от лица администратора (если, конечно, это не процесс login с последующим входом в систему обычного пользователя). Такое положение не всегда желательно с точки зрения безопасности. Избежать же его можно с помощью иного способа активизации консолей, о которых я расскажу в следующей заметке.
Заметки о Linux-консоли Украшение консоли
Алексей Федорчук
alv@linux-online.ru
По мне так текстовая консоль Linux прекрасна сама по себе, в первозданном виде по умолчанию: белые или светло-серые буквы на радикально черном фоне строги, но элегантны. Разумеется, при одном непременном условии - выборе подходящего шрифта.
Кажется, одна из причин того, что многие пользователи пренебрегают консольным режимом, именно в шрифтах и кроется. Действительно, тот, с позволения сказать, шрифт, который обычно устанавливается в консоли по умолчанию при ее кириллизации, - отнюдь не верх эстетического совершенства. Однако ограничиваться "умолчальным" шрифтом никто не заставляет.
Благо, экранных шрифтов для консоли в современных Linux-дистрибутивах обычно много. В этом можно убедиться, просмотрев каталог типа /usr/share/kbd/consolefonts или тот, где они содержатся в конкретном дистрибутиве (точное местоположение легко определить командой find со значением consolefonts для опции -name). Вывод команды ls для этого каталога займет уж точно пару экранов. И шрифтовые файлы, которые в нем можно увидеть, обычно (хотя и не обязательно) имеют вид *.psf.gz (то есть использующие сигнатуру psf и сжатые утилитой компрессии gzip, хотя последнее не всегда применяется).
Правда, как легко догадаться, далеко не все эти шрифты содержат символы кириллицы. Однако и таких обнаружится десятка три. Если нет - их легко позаимствовать (прямым копирование в должный каталог) из любого Linux-дистрибутива отчественного производства (типа Altlinux или ASPLinux). Или - из пакета console-tools-cyrillic, собранного и периодически обновляемого Виктором Вагнером.
Полная коллекция кириллических экранных шрифтов включает наборы для всех традиционных кодировок Великого и Могучего, получивших распространение на родных просторах - DOS, Windows, KOI8, ISO8859, которые опознаются по именам шрифтовых файлов. Шрифты в DOS-кодировке имеют имена типа alt*, Cyr*, cp866* или просто 866* (имена одних и тех же шрифтов в разных дистрибутивах могут варьировать; хотя в принципе шрифты с префиксами alt и Cyr несколько различаются по наборам символов). Шрифты KOI8 (как R, так и U) именуются прозрачно - koi8r и koi8u, соответственно. Шрифты для Win-кодировки имеют в своем имени слово win или цифры 1251. ISO'шные шрифты опознаются по символам iso5 или слову sun (поскольку именно на Sparc'ах главным образом и используются).
По причинам, которые будут рассмотрены в заметке о русификации, практическое значение для экранного вывода в наших условиях имеют почти исключительно шрифты для кодировки DOS. Вне зависимости от того, как их называют, в любом дистрибутиве Linux (за исключением уж совсем американских) можно обнаружить минимум три таких "гарнитуры" (если этот термин в данном случае уместен), именуемые как-нибудь вроде cp866*, cp866-b* и cp866-c*. Они несколько отличаются своим обликом и расположением некоторых редко используемых специальных символов. Впрочем, все три внешне выглядят вполне скверно (особенно при плотности символов, отличной от стандартной).
В отечественных дистрибутивах (и в пакете console-tools-cyrillic) можно найти еще несколько кириллических шрифтов для DOS-кодировки. Например, alt-antiq, стилизованный под старину, или t866, имеющий как бы рукописный облик. Однако и они не вполне подходят для постоянного использования (хотя могут придать вашей консоли вполне оригинальный вид).
И потому очень рекомендую обратить внимание на семейство шрифтов UniCyr*. Среди них можно обнаружить как курьерообразные разновидности, так и вполне честные шрифты Sans Serife (а на мой взгляд, именно шрифты без засечек наиболее подходят для экранного вывода в консоли). Таковых - два, UniCyr-lenta-8x16 и UniCyr-sans-8x16. Их дополнительное достоинство - слабая подверженность деформации при нестандартной плотности символов (напомню, что в консоли мы всегда имеем дело с растровыми шрифтами, и потому их искажение при масштабировании неизбежно). Впрочем, на вкус и цвет товарищей нет, и потому подходящий шрифт каждый может выбрать для себя методом ползучего эпмиризма.
С некоторого времени в дистрибутивах Linux, претендующих на интернациональность, можно видеть шрифты вида *.psfu.gz или *.psfu. Таким образом можно опознать шрифты в кодировке Unicode (хотя не все они имеют суффикс psfu), содержащие наборы символов для разных алфавитов и кодировок. Так, практически всегда можно обнаружить семейство гарнитур, именуемое LatArCyrHeb-* (с высотами матрицы 8, 14, 16 и 19 пикселей). Как легко понять из названия, любой из них пригоден для вывода на экран символов латиницы, кириллицы, арабского и еврейского алфавитов, нужно только указать, какого точно (как - скажу чуть ниже).
Для смены экранного шрифта в текущем сеансе работы служит команда setfont из пакета kbd (в пакете console-tools ей соовтетствует команда consolechars). Дается она с указанием имени шрифта в качестве аргумента, например:
$ setfont UniCyr-sans
что приводит к мгновенной смене экранного шрифта на всех виртуальных консолях. Если шрифты расположены в стандартном для данного дистрибутива каталоге (например, /usr/share/kbd/consolefonts), не требуется ни указания полного пути к имени шрифтового файла, ни его суффикса (вида *.psf.gz). Необходимость и в том, и в другом возникнет, если шрифты берутся из необычного места (например, домашнего каталога пользователя).
В команде consolechars загружаемый шрифт значением опции -f, каковое подчиняется тем же правилам, что и аргумент команды setfont.
На практике любая из этих команд может потребовать дополнительной опции -m, значением которой выступает имя так называемой карты соответствия (mapscreen, то есть таблицы перекодирования набора символов клавиатурного ввода в таковой экранного вывода). Подробнее об этом будет говориться в заметке о русификации, пока же - лишь несколько соображений рецептурного характера.
Первое - если после исполнения команды setfont имя_шрифта вместо русского текста на экране наблюдаются всякого рода безобразия, команду следует повторит в виде
$ setfont UniCyr-sans -m koi2alt
где значение опции -m указывает на имя mapscreen. В особо тяжелых случаях (при нерусифицированной системе, или системе, русифицированной некорректно, а также при открытии новой виртуальной консоли в соответствии с ранее описанными методами), возможно, придется этот самый mapscreen еще и активизировать вручную вводом т.н. "магической последовательности"
$ echo -ne '(K'
Если загружаемый шрифт относится к категории юникодовских, опуия -m потребуется в любом случае, и значением ее должно быть koi8-r_to_uni, например:
$ setfont LatArCyrHeb-16 -m koi8-r_to_uni
При этом необходимости в выводе "магической последовательности" не возникнет (более того, делать это не следует). Единственное, что может потребоваться для нормального восприятия ранее выведенного кириллического текста - так это обновление экрана (во многих программах для этого служит клавишная комбинация Control+R).
Наконец, если принято решение использовать для вывода шрифты в кодировке KOI8, отпадает требование не только вывода "магической последовательности", но и опции -m в команде setfont. Оно и понятно - ведь в этом случае и для ввода, и для вывода используется один и тот же набор символов.
Рано или поздно упражнения со шрифтами заканчиваются достижением идеального (или, по меньшей мере, оптимального) варианта. Который хотелось бы увековечить как загружаемый по умолчанию при старте системы. Сделать это не очень-то и трудно, сложнее дать однозначные рекомендации, как именно. Поскольку метод загрузки "умолчального" шрифта очень зависит от системы инициализации, принятой в конкретном дистрибутиве.
В клонах Red Hat, наколько я помню, это достигается изменением значения строки SYSFONT в конфигурационном файле /etc/sysconfig/i18n. В других дистрибутивах "умолчальный" шрифт может изменяться в других конфигах из каталога /etc и его подкаталогов - сверяйтесь с документацией. А в почти любых неясных случаях самое место для подгрузки шрифта - файл /etc/rc.local, куда можно поместить строку вида
setfont UniCyr-sans -m koi2alt
Не забыв сопроводить ее сценарием инициализации mapscreen на всех открываемых при старте витруальных консолях, о чем подробно будет сказано в заметке о русификации.
Теоретически рассуждая, шрифт, загружаемый по умолчанию, можно вкомпилировать в ядро системы (во FreeBSD такая возможность предусмотрена в штатной документации). Преимущество этого метода - доступ к кириллическим шрифтам при всякого рода аварийных загрузках (например, при подмене штатного процесса init командной оболочкой путем передачи ядру параметра init=/bin/shell_name). Это позволит для исполнения ремонтно-спасательных действий прибегнуть к подсказкам из русскоязычной документации. Однако сам я такую процедуру не проделывал. Могу только предполагать, что она потребует изменения исходников файлов типа /usr/src/linux/drivers/char/console*. За любые соображения по сему предмету буду благодарен.
На мой взгляд, подбора подходящего шрифта довольно для придания консоли презентабельного вида. Однако при желании можно заняться и ее расцвечиванием (хотя, повторяю, монохромный стиль консоли столь же естественен, как и черно-белая гамма козинцевского "Короля Лира").
Правда, расцвечивание консоли может иметь и практический смысл - для визуального распознавания виртуальных консолей. Пэтому уделим некоторое внимание этому вопросу.
Для изменения цветовой гаммы используется неоднократно поминавшаяся ранее команда setterm (из пакета ulil-linux), для чего в ней имеются опции -foreground [цвет] и -background [цвет], изменяющие цвет текста и фона, соответственно. Значения обеих задаваются в 8-цветной палитре - black, blue, green, cyan, red, magenta, yellow. Кроме того, с помощью опции -reverce можно поменять цвет текста и фона, сделать текст мигающим (посредством опции -blink), выделенным (с опцией -bold) или, наоборот, "приглушенным" (с опцией -half-bright). Все опции, определенные для команды setterm (подробности см. в man (1) setterm), имеют силу только для текущей виртуальной консоли (почему цвет и используется для их различения; хотя, на мой взгляд, это проще и эффективнее сделать средствами командной оболочки zsh).
При манипуляциях с цветом консоли следует иметь ввиду следующие обстоятельства. Во-первых, реальное воплощение цветовых значений на экране зависит от монитора и (или) видеокарты, и может быть весьма неожиданным. И, определив для опции -foreground значение yellow, можно спокойно получить темно-горчичный цвет на черном фоне, что отнюдь не способствует читабельности текста.
Во-вторых, развитые командные оболочки имеют собственные средства манипуляции цветами, которые (для /bin/bash, например) задействуются по умолчанию во многих дистрибутивах. А сочетание изменений цветов через setterm и командную оболочку может привести к совершенно непредсказуемым эффектам, вплоть до полной нечитаемости текста.
И в третьих, многие программы (например, всенародно любимый Midnight Commander) сами по себе изменяют свойства терминала, сбивая настройки setterm после выхода из них. Чтобы этого не происходило, команду setterm следует давать с дополнительной опцией -store, сохраняющей в качестве умолчаний уставновленный ею набор терминальных атрибутов.
Тем не менее, если результаты цветовых экспериментов показались удачными, измененные цвета фона и текста можно сделать постоянными. Для этого достаточно включить команду setterm с требуемыми значениями опций в один из стартовых файлов (например, в тот же /etc/sysconfig/i18n в Red Hat клонах или в /etc/rc.local - во многих дистрибутивах, использующих BSD-стиль инициализации).
И последнее, что я хотел бы сказать о цветах. Консольный драйвер FreeBSD (syscons) позволяет менять цвет не только текста и фона, но и бордюра экрана отдельно для каждой виртуальной консоли. Что такое бордюр, помнят, пожалуй, только пользователи старых четырнадцатидюймовиков без средств цифрового управления: это та самая черно-серая кайма между изображением пластмассой окаемки дисплея. В старых DOS-русификаторах, помнится, изменение ее цвета использовалось для индикации текущей раскладки клавиатуры (латиницы или кириллицы). Однако на любом современном мониторе бордюр обычно сводят под ноль. Тем не менее, и его можно использовать в мирных целях (например, придав бордюру root-консоли тревожный красный цвет).
В Linux'е штатного средства для этого не имеется. Однако на сайте винницкой фирмы Крон я обнаружил патч к ядру, как будто бы позволяющий менять цвет бордюра аналогично тому, как это делается во FreeBSD. К сожалению, патч этот предназначен для достаточно старой версии ядра, и в современных ядрах работосопособность его гарантировать нельзя.
В общем, про экранный вывод можно заканчивать. Пора переходить к не менее важной составляющей работы в консоли - настройке клавиатурного ввода.
Заметки о Linux-консоли Вопросы автоматизации
Алексей Федорчук
alv@linux-online.ru
Каждый, кто активно использует виртуальные консоли в обыденной жизни, сталкивается с необходимостью регистрации на каждой из них - от имени ли какого-либо пользователя, или в качестве администратора. Уже при шести умолчальных консолях процесс этот может показаться утомительным. А при существенно большем их количестве - так и просто обременительным. Нельзя ли как-нибудь актоматизировать его?
Напрашивающееся решение - беспарольный вход в систему, - отнюдь не идеально. Во-первых, это вопиющее нарушение техники безопасности. Конечно, на локальной машине ею можно бы принебречь - все равно, доступ к ней легко получить, загрузившись с любого сменного носителя. Но уже при модемном подключении к Сети и динамическом IP-адресе беспарольный вход очень не рекомендуется. Главное же, он не избавляет от необходимости ввода пользовательского имени, то есть техника безопасности не только нарушается, но и нарушается неоправданно.
И потому были придуманы различные способы автоматизации входа в систему, то есть - автоматической регистрации пользователя в момент активации виртуальной консоли. Они работают вне зависимости от того, открывается ли консоль в момент старта системы или на лету в ходе дальнейшей работы. При этом сами по себе учетные записи пользователей (в том числе и их пароли) остаются в неприкосновенности, и потому удаленный доступ к данной машине все равно требует ввода регистрационных данных.
Несколько таких методов автоматизации входа рассмотрены в статье Адриана Чанга. В ней упомянуты патч к программе mingetty и пакет autologin, а также предложена автоматизация методом "правки напильником". Он основан на использовании опции -l программ семейства getty, которая позволяет подменить выполняемую по умолчанию команду login какой-либо альтернативной. В качестве такой альтернативы предложена простенькая Си-программа, выполняющая все ту же команду login в форме
login -f user_name
с предварительной аутентификацией указанного пользователя.
Метод этот не показался мне удобным. Во-первых, при необходимости регистрации более чем одного пользователя потребуется создавать (и компилировать) по экземпляру такой программы на каждого из них. Во-вторых (и главных), он у меня просто не сработал - стадия аутентификации действительно пропускалась, но пароль на вход запрашивался все равно (кстати, в man (1) login я не нашел никаких указаний на то, что опция -f освобождает от ввода пароля).
Интуитивно понятно, что проблема автоидентификации пользователей может быть решена каким-либо скриптовым методом. И я было занялся сочинением такого скрипта, когда благодаря статье Владимира Попова наткнулся на Perl-сценарий qlogin, специально для того и предназначенный. И к тому же подробно описанный в статье его автора - Брайана Хендерсона.
Установка его очень проста - достаточно распаковать архив и скопировать исполняемый сценарий (qlogin) в подходящее место (а подходящим для такого рода программ по понятным причинам является каталог /sbin). Также неплохо поместить и его man-страницу (qlogin.1) куда следует (у меня в системе - в /usr/man/man1), поскольку в ней содержится исчерпывающая информация по применению этого скрипта.
Правда, дополнительно требуется еще и установить два Perl-расширения. Первое, в соответствие с документацией (~/qlogin/README) находим в подкаталоге ~/qlogin/setgroups, перейдя в который, выполняем
perl Makefile.PL make make install
для помещения в должное место (по умолчанию - в /usr/lib/perl5/5.X.X/i686-linux/). Второе расширение относится к методу контроля за авторизацией, использующему файлы /etc/utmp и /etc/wtmp. В моей системе таковые отсутствуют за ненадобностью, и к тому же само расширение следовало еще скачать с http://cpan.org. Однако без него вполне можно обойтисть, для чего достаточно из qlogin удалить строки, имеющие отношение к Utmp.
Скрипт qlogin в равной мере пригоден как для интерактивной активизации консолей "на лету" (выступая как замена команды openvt), так и для автоматической регистрации на них при старте системы (то есть подмены программ семейства getty). При использовании qlogin во втором качестве автор настоятельно рекомендует предварительно "потренироваться в тряпичный" - то есть запустить его с нужными опциями и аргументами из командной строки. Помня при этом, что управляющим терминалом для qlogin будет та виртуальная консоль, с которой он был запущен.
Аргументов для команды qlogin, вне заивисимости от способа ее применения, требуется два - имя файла целевой консоли и имя пользователя:
$ qlogin /dev/vc/# user_name
Обращаю внимание, что имя файла устройства, в отличие от команды agetty, должно сопровождаться полным путем (как в примере).
Из опций qlogin (напомню, что их вдоволь можно найти в man-странице) наиболее важна --command, значением которой будет имя команды, запускаемой на новой консоли вслед за ее открытием и автоидентификацией пользователя. При необходимости команда может сопровождаться собственными опциями и агрументами:
$ qlogin /dev/vc/# user_name --command="command [options] [arguments]"
При этом очевидно, что для экранирования пробелов в этом случае должны использоваться кавычки (одинарные или двойные - в зависимости от применяемого шелла). Полный путь к исполняемого файлу команды при интерактивном запуске qlogin не обязателен (если, конечно, путь этот описан в переменной окружения $PATH).
Очевидно, что интерактивный запуск qlogin возможен только от лица root'а, посокльку ни один обычный пользователь не имеет соответствующих прав доступа к файлам устройств неактивизированных виртуальных консолей.
Для автоматической регистрации пользователей при старте системы вызов команды qlogin следует поместить в файл /etc/inittab вместо команды getty. Например, если мы хотим на первой виртуальной консоли автоматически авторизовать некоего пользователя "имя рек", следует изменить первую строку секции описания виртуальных консолей таким образом:
c1:2:respawn:/sbin/qlogin /dev/vc/1 имя_рек
Повторяю, указание полного пути к файлу устройства при этом обязательно, иначе init, не обнаружив оного, впадет посредством акции respawn в пятиминутный цикл перезапуска процесса qlogin.
Опции команды qlogin можно использовать и при вызове ее из файла /etc/inittab. Так, благодаря строке
c1:2:respawn:/sbin/qlogin /dev/vc/1 имя_рек --command="/bin/tcsh -l"
при старте системы на первой виртуальной консли будет не только зарегистрирован пользователь "имя рек", но для него в качестве login shell загрузится командная оболочка tcsh вместо той, что предписана ему по умолчанию (например, bash). А строка вроде
c6:2:respawn:/sbin/qlogin /dev/vc/6 имя_рек --command=/usr/bin/top
обеспечит на шестой консоли вывод программы top для контроля над запущенными процессами.
Следует только помнить, что вызов какой-либо программы как опции команды qlogin при этом происходит до считывания каких-либо пользовательских (и многих общесистемных) профильных файлов. Из чего следует, во-первых, необходимость указания полного пути к исполняемому файлу вызываемой программы (как в примере) - ведь переменная $PATH еще не определена. А во-вторых, сложные программы, зависящие от многих конфигурационных файлов, запустить как опцию команды qlogin не удастся. Так, моя попытка автоматом грузить на 6-й консоли Инксы "в лоб", с помощью опции вида --command="/usr/X11/bin/startx" успехом не увенчалась, вызвав только поток сообщений об отстутствии файлов типа xinit, xautority и т.д. Вероятно, задача эта решаема, но как - пока руки не дошли...
И еще следует помнить, что консоль, на которой через /etc/inittab и qlogin запущена какая-либо программа, уже не удастся использовать для иных целей: попытка выйти из программы top (в приведенном выше примере) приведет, благодаря акции respawn, к перезапуску qlogin и, через его опцию, нового экземпляра той же программы top.
Таким образом, мы обеспечили себя достаточным количеством виртуальных консолей и удобным способом доступа к ним. Теперь посмотрим, как создать в единичной консоли максимальный комфорт для практической работы. Задача эта распадается на две части - комфорт при выводе и комфорт при вводе. Поскольку глаз у нас всего двое, и больше уже не будет (а руки на худой конец можно заменить протезами), начнем с вывода.
Заметки о Linux-консоли Введение
Алексей Федорчук
alv@linux-online.ru
- Вот за это я и не люблю кошек...
- Может быть, ты просто не умеешь их готовить?
Из нашей любимой рекламы.
О том, что такое консоль, написано немало, в том числе и вашим покорным слугой: это сочетание стандартного устройства ввода и стандартного устройства вывода. В случае настольной персоналки (а только о ней и пойдет речь далее) в качестве оных выступают, соответственно, клавиатура и монитор данной конкретной машины (с некоторой долей условности в этот гарнитур можно включить и мышь). Работа в консоли часто отождествляется с использованием текстового режима и интерфейса командной строки. И то, и другое в общем случае не вполне правильно, как и противопоставление консольного режима графическому. Однако это отдельная история, которую я надеюсь затронуть под конец своего изложения.
Также много (и опять же не без участия автора этих строк) говорилось о несравненных достоинствах консольного режима - его удобстве и эффективности, не говоря уж о недороговизне (с точки зрения ресурсов) и полезности для здоровья (в плане сохранения зрения). Однако многие пользователи, особенно из числа начинающих, по прежнему относятся к текстовой консоли с изрядной долей пренебрежения. Возможно, просто потому, что не умеют ее готовить (пардон, настраивать). А не умеют они это по причине явно недостаточного количества источников инфорсвции.
Поэтому в настоящей серии заметок я решил обощить все, что мне известно о настройке Linux-консоли. На труд сей меня подвигла доблесть Ивана Паскаля, создавшего в свое время исчерпывающее (и не устаревшее по сей день) описание системной консоли FreeBSD. С которым, к слову сказать, не вредно ознакомиться и пользователю Linux'а. Дополнительным побуждением явилось то, что в форуме Linuxshop'а время от времени всплывают вопросы о том, как изменить плотность знаков в консоли, или изменить цвет экранного шрифта.
Конечно, управление консолью во FreeBSD существенно проще и логичнее, чем в Linux'е. Оно сводится, в сущности, к изучению возможностей двух программ - vidcontrol и kbdcontrol. Как нетрудно догадаться из названия, первая отвечает за все, связанное с выводом (то есть настройками экрана), вторая - за все, связанное с вводом (то есть настройками клавиатуры).
В Linux' е ситуация значительно более запутанная. Начать с того, что в различных дистрибутивах штатно используется один из двух сосуществующих пакетов управления консолью - kbd или console-tool. Второй до недавнего времени считался более продвинутым, тогда как kbd рассматривался в качестве устаревшего. Однако нынче они абсолютно равноценны. По ряду причин я определенно тяготею именно к kbd, а потому в первую очередь о нем и буду говорить.
Однако альтернативой между указанными наборами инструментов дело не ограничивается. Для установки некоторых свойств консоли требуется прибегать к утилитам, не входящим ни в один из них (и обнаруживающихся подчас в составе самых неожиданных пакетов).
Далее, служба консольной мыши в Linux'е существенно отличается от аналогичного сервиса FreeBSD (и вообще традиционного для Unix использования этого устройства).
Наконец, в Linux'е все большее признание получает так называемая графическая консоль, поддерживаемая через кадровый буфер видеокарты (так называемый frame buffer). Она предоставляет такое изобилие дополнительных возможностей (вплоть до просмотра видео), которое иначе достижимо только при использовании Иксов (или специализированной библиотеки SVGAlib, не получившей широкого распространения). Почему я и сказал чуть ранее, что в общем случае противопоставление консольного режима графическому неверно.
Обо всех этих темах и пойдет речь в этой серии заметок. Однако, вопреки первой моей фразе, скажу пару слов о том, что же такое консоль
Заметки о восстановлении данных под линуксом
Компьютерная промышленность выпускает все более быстрые и надежные средства хранения информации. А программисты (будем к ним снисходительны и немного приукрасим действительность) пишут все более помехоустойчивые и дуракоупорные операционные системы. Линукс, например.Но иногда все же и с ними случаются ЧП. Прогулявшаяся по клавиатуре кошка случайно стирает важный файл - результат многодневной работы. Неправильно набранная команда записывает мусор на место файловой системы. Глюкнувший драйвер приводит ее в красивое и загадочное, но совершенно бесполезное состояние. Запущенная после полугодового перерыва ради последней DirectX-игрушки Windows приносит с собой вирус CIH, начисто уносящий таблицу разделов. Что делать?
Под DOS/WINDOWS за время их существования наросло множество утилит, облегчающих восстановление данных - от известного каждому продвинутому владельцу компьютера Norton Disk Doctor-а до аварийных монстров типа Tiramisu Desktop. Их употребление широко распространено и общеизвестно.
Попытки поиска чего-нибудь подобного под линукс в большинстве случаев начинаются и заканчиваются рекомендацией регулярно производить резервное копирование. Рекомендация эта, безусловно, верна, дает гарантированное решение проблемы и, может быть, кому-то даже полезна. Однако суровая реальность такова, что лишь очень немногие могут позволить себе приобретение набора аппаратуры, необходимого для полноценного резервного копирования. Остальным же остается надеяться, что ничего страшного не случится.
Впрочем, все не так страшно. Некоторые (а при ближайшем рассмотрении, весьма даже приличные) средства для восстановления в линухе есть. Ниже я привожу свои комментарии и советы по поводу некоторых характерных случаев и важных моментов этого дела. Основаны они как на печальном личном опыте, так и на собрании разрозненных приемов из различных источников. Надеюсь, эти заметки кому-то окажутся полезными.
1) Делайте резервные копии.
Пункт первый и тривиальный, он, тем не менее заслуживает самого пристального внимания. Всегда легче и надежнее "восстановить" пропавшую информацию, просто переписав с резервного экземпляра, чем судорожно шарить по поверхности жесткого диска в поисках пропавших секторов. Мы договорились, что возможности производить резервное копирование полностью и систематически у вас нет. Но это еще не значит, что у вас нет вообще никаких возможностей для копирования.
К счастью, написано несколько средств, в значительной степени автоматизирующих этот процесс, таких, как, например, recover (http://www.linuxave.net/~recover/), unrm (http://hideout.art.ro/).
Впрочем, наиболее удобное из них встроено в Midnight Commander. Единственная сложность с ним заключается в несколько неочевидном способе его запуска. Для этого нужно из-под пользователя root (чтобы иметь прямой доступ к файловой системе) в командной строке программы набрать команду.
cd /#undel:<имяраздела>
имя нужно писать без части /dev/, то есть, например, для первого раздела первого ide-диска это будет
cd /#undel:hda1
После этого можно будет рассматривать получившийся список файлов, ища в них наиболее подходящие.
Да! - все эти манипуляции настоятельно рекомендуется (если не хотите еще сильнее усугубить ситуацию, повредив еще и файловую систему) выполнять в single-user mode на отмонтированном, или, в крайнем случае, примонтированном как read-only разделе.
3) Использование своп-раздела.
Редко когда на машине бывает достаточно свободного места, чтобы обеспечить свободу маневра при восстановительных работах. Однако, учитывая, что на время этих работ нормальной, загруженной работы машины все-равно не предвидится, можно использовать важный внутренний резерв - раздел для свопинга. В современных машинах этот раздел достигает сотен мегабайт, и для работы мелких системных утилит он совершенно не нужен. Можно его отформатировать и использовать для хранения информации, восстанавливаемой с других разделов, можно, в случае тяжелых повреждений корневого раздела, установить там маленькую линукс-систему и дальнейшую работу вести с нее (что гораздо удобнее, чем загружаться с rescue-дискеток.), можно делать то и другое одновременно.
4) Физически поврежденный диск.
Может случиться так, что, диск, на котором окажутся ваши данные, будет поврежден. Характерной опасностью в таком случае, оказывается то, что сам по себе любой доступ к этим данным, даже вроде бы только для чтения, будет для них разрушителен - дефектная головка царапает поверхность диска и наносит ей новые повреждения. Или же - хитрая электроника современных жестких дисков по собственной инициативе пытается вывести поврежденный участок из обращения и.....далеко не всегда это приводит к благоприятным результатам. Поэтому первое, что надо сделать в таком случае - скопировать все важное, что только еще цело в другое, безопасное место.
Если есть достаточное количество свободного места, разумным будет сначала скопировать полностью образ раздела в файл на другом разделе, а потом уже при попытках восстановления работать с этим файлов, обращаясь с ним как с файловой системой при помощи loopback-драйвера. Для такого копирования следует использовать системную утилиту dd, которая в отличии от обычных команд копирования, корректно перенесет (или, по крайне мере попытается это сделать) также и поврежденные блоки, а не прекратит свою работу на полпути.
5) Тяжелые повреждения файловой системы ext2.
Ну здесь все вроде бы ясно. Есть программа e2fsck для восстановления, ее надо запустить и она все сделает, есть debugfs для тонкой расчистки, им можно ковырять отдельные дефектные элементы файловой системы. Все-таки, несколько деталей.
Если начало файловой системы сильно разрушено, вместе с ней может оказаться разрушен и суперблок, в котором хранится вся важнейшая информация о файловой системе. e2fsck в таком случае вообще откажется воспринимать раздел как файловую систему.
К счастью, в юниксовых файловых системах суперблок, именно вследствие своей важности, многократно дублируется. Копии суперблока расположены на разделе через одинаковые промежутки, зависящие от размера блока, равные некоторой степени двойки. То есть можно запомнить, каких размеров должны быть промежутки при каждом размере блока, но гораздо приятнее непосредственно найти их по сигнатуре с помощью программы findsuper, входящей в стандартный пакет ext2fstools. Программа эта выдаст список похожих на суперблок блоков, и по ним уже достаточно просто определить, где идет суперблок, а где случайное совпадения, зная о равномерном распределении суперблоков.
Найдя суперблок, можно указать его программе e2fsck при помощи ключа -b. Обычно в таких случаях e2fsck полезно запустить два раза - сначала с ключом -n для того, чтобы проверить, что указание этого суперблока дает осмысленные результаты, а затем с ключом -y, чтобы произвести собственно изменения. Имеющаяся в программе возможность интерактивно управлять работой e2fsck в здесь обычно неполезна, поскольку осмысленный ответ на задаваемые вопросы может быть дан лишь при очень глубоких знаниях по поводу устройства ext2fs вообще и данной конкретной файловой системы в частности.
В каталоге lost+ found ищите файлы, которые e2fsck не смогла поставить на вполне правильное место. После восстановления таким образом работоспособности файловой системы в этом каталоге (впрочем, как и в любом другом месте) часто остаются файлы со странными именами и правами, которые не может удалить даже root. Файлы эти выкорчевываются посредством debugfs (не забудьте отмонтировать отлаживаемый раздел, или, по крайне мере, перевести его в read-only).
6) Разрушение таблицы разделов
Это - один из излюбленных методов хулиганства, применяемый вирусами. Метод лечения очевиден - нужно составить в точности такую же таблицу разделов, какая была. В простом случае - когда раздел на диске один, или когда вы точно помните, ка его разбивали, для этого достаточно простого fdisk-а, которым просто создается такая же таблица разделов, какая была. Большим подспорьем при определении границ разделов может послужить расположение суперблоков, определяемое упоминавшейся программой findsuper.
Есть, впрочем, и программы, которые облегчают восстановление, пытаясь сами определить границы между разделами. Назову такие как TestDisk (http://www.esiea.fr/public_html/Christophe.GRENIER/testdisk.html) и gpart, http://www.stud.uni-hannover.de/user/76201/gpart/.
Важный момент, на который следует обратить внимание - на разных машинах геометрия диска может выглядеть совершенно по разному. Разные типы BIOS, производят разную трансляцию между характеристиками реальными, и допустимыми BIOS. На нормальном диске сведения о геометрии можно получить как раз из таблицы разделов, но здесь она стерта и каждый выдумывает, во что горазд. Следствие - восстанавливать таблицу надо именно на той машине, на которой диск форматировался и работал. А если уж это невозможно, то, хотя бы, тщательно переписать в настойках BIOS параметры геометрии и вручную выставить их на машине, где будет происходить восстановление.
Также следует обратить внимание на такой замечательный ресурс, как Partition Rescue Mini-HOWTO (ttp://www.linux-france.org/article/jdanield/partition-rescue-mini-HOWTO.htm) где этот вопрос изложен со всей подробностью и детальностью. Федор Зуев fedor_zuev@mail.ru
Связь | О проекте LinuxRSP | Редколлегия | Реклама
© 1999-2001 LinuxRSP
Замуровали, демоны
rc - именно этот командный файл и отвечает, в основном, за переход между уровнями.
Разрешение на выполнение нужного набора скриптов можно задавать интерактивно. Для этого достаточно обратить внимание на заголовочек, указывающий на то, что нажатие I можно использовать для управления процессом старта. Реально после нажатия появляется файл /var/run/confirm, который и служит флагом интерактивного режима загрузки. Для перхода на уровень выполняются все файлы в соответствующем подкаталоге rc$runlevel.d. Имена этих файлов, как правило, начинаются с большой (это существенно) буквы S или K. Если первая буква иная, то файл просто не участвует в процессе межуровневого перехода. Файлы на S отвечают за старт службы, а файлы на K - за остановку какой-либо службы. Обратите внимание, что при переходе на уровень 3 прямо со старта, мы никак не используем файлы из rc2.d - только rc3.d. Этот вариант отличается от того, который принят, например, в Unix System V. Там при старте, последовательно выполняются стартовые файлы всех промежуточных каталогов, в частности, rc1.d, rc2.d и т.п.
После начальной буквы идут две цифры (маловато будет, достаточно типично сейчас использование трех). Эти цифры позволяют отсортировать командные файлы и указать точный порядок запуска. Ясно, что это достаточно важно. Например, сетевые сервисы должны стартовать после того, как заработают сетевые интерфейсы. После цифр идет имя службы - подсистемы.
Посмотрим порядок выполнения командных файлов более подробно. Сначала выполняется останов служб (первая буква K) и только затем старт (соответственно S). Ясно, что одна и та же служба, как правило, нужна на нескольких уровнях. Было бы обидно при каждом переходе (например, с уровня 2 на уровень 3) останавливать и рестартовать ее. От этого надо как-то защищаться. Для System V это получается автоматически, так как старт и останов службы входят в набор конкретного уровня. В Linux же требуются специальные проверки. Роль флагов выполняют файлы в каталоге /var/lock/subsys/${subsys} или /var/lock/ subsys/${subsys}.init, где subsys - имя подсистемы. Если файлов нет, то данная подсистема считается не запущенной (и, соответственно, запуск S-файла имеет смысл), а если есть - запущенной (и, соответственно, запуск K-файла имеет смысл). Поэтому останов службы по команде kill не будет замечен этим механизмом. Если посмотреть подробнее, то окажется, что все файлы в каталогах rcn.d являются символьными ссылками на соответствующие файлы из /etc/rc.d/init.d. Более того, и стартовые файлы, и файлы остановки подсистемы ссылаются на один файл. Отличие обеспечивается за счет передачи параметра start или stop. В некоторых вариантах Unix можно явно использовать тот факт, что стартстопный файл запускается два раза, но лучше этого не делать и честно разбираться с параметрами. Иногда для выдачи красивого листинга старта/останова системы на экран в Unix используется большее количество опций, например, что-либо в стиле start_msg/stop_msg. Если у вас есть привычки, то отладка скриптов при переносе может отнять массу времени.
Для управления набором доступных служб можно использовать программу конфигурирования linuxconf. Что означает разрешить или запретить использование какой-либо службы с точки зрения всяких там файлов? Запрещение старта какого-либо сервиса просто приводит к удалению соответствующей ссылки из каталогов rcn.d, а разрешение - к появлению. А как же обеспечивается корректная установка номера у соответствующей ссылки? Мы же должны обеспечить правильный порядок выполнения старта для подсистем. Неужели linuxconf обязан знать про роль всех служб и что-то интеллектуально вычислять?
Все устроено гораздо проще. Обратите внимание на часть заголовка файла /etc/rc.d/init.d/atd:
# Запуск демона
# chkconfig: 345 40 60
# processname: atd
Что-то неуловимо знакомое мы видим в строке с chkconfig. 345 - явно похоже на список уровней. 40 и 60 смахивают на номера для S и K файлов. Сумма номеров 100 достаточно типична (но, естественно, не обязательна). Таким образом, проще добиться того, чтобы порядок останова подсистем был почти в точности обратен стартовому. Попробуйте поменять 40 на 41 и отменить (разрешить) какую-либо службу. Стартовый файл поменяет свое имя. Description в данном файле четко отвечает за комментарий, который linuxconf выдает вам на экран для объяснения роли данной службы.
Заглянем в сам файл /etc/rc.d/init.d/atd. Мы сразу видим, что реально возможных опций больше, чем стандартные start и stop. Имеются еще restart, reload и status. Такая ситуация тоже достаточно типична. Старт, останов и проверка состояния демона выполняется рядом функций типа daemon, killproc, status. Если все происходит по плану, то создается (удаляется) файл /var/lock/subsys/atd.
Рассмотрим теперь подробнее вышеуказанные процедуры daemon, killproc, status. Они определяются (вместе с рядом других) в /etc/rc.d/init.d/functions (а тот пользуется определениями из /etc/sysconfig/init). Уже по названию ясно для чего они предназначены - старт, останов и проверка статуса демона.
Функция daemon обеспечивает старт подсистемы (службы, демона и т.п.). При этом можно учесть особенности поведения демона (требуемые ресурсы процессора и т.п.) и заказать их в виде nice-значения (+/-nicevalue) и конкретного пользователя (-user).
Перед стартом демона всегда делается проверка наличия его в системе. Поскольку демон может вызываться из скрипта, то для проверки текущего состояния можно заказать точное имя (-check name). Так как появление dump-а демона может приводить к проблемам с security, то все демоны запускаются в режиме без core-dump. Сам старт выполняется командой initlog $INITLOG_ARGS -c , которая и стартует демона и записывает информацию об этом в лог.
Останов демона выполняется процедурой killproc. Данная функция предполагает один аргумент в виде имени демона и, возможно, еще один для указания сигнала, который и будет послан демону для окончания. SIGKILL очень часто может быть не желателен, так как могут возникнуть разнообразные проблемы типа блокирования ресурсов. Поэтому, если сигнал назначен, то используется только он, если не назначен, то сначала SIGTERM и, если данный сигнал не позволит упокоить демон за разумное время, то посылается SIGKILL. Последним действием удаляется флаговый файл /var/run/подсистема.pid.
Наконец status позволяет проверить текущее состояние работы подсистемы. Если процесс работает, то просто сообщается данный факт. Если не работает, то делается проверка на наличие флаговых файлов (/var/run/подсистема.pid и /var/lock/subsys/подсистема), которые должны блокировать повторный запуск. Естественно наличие их диагностируется как ошибка.
Кроме этого, в файле functions есть объявления action - просто выполнить действие (без каких-либо проверок) и зафиксировать его в логе; confirm - генерируемый запрос на подтверждение продолжения работы; другие макросы. Action необходимы в тех случаях, когда работа службы обеспечивается непосредственно ядром системы, т.е. демон для работы не нужен. Соответственно к этой группе можно отнести конфигурирование сетевой подсистемы (например, ifconfig не должен работать непрерывно), монтирование nfs-систем и т.п.
Попробуем теперь добавить новый демон или новое действие в систему. Для этого скопируем /etc/rc.d/init.d/atd в новый файл. Что можно (at/atd), заменим на sleep. Что будет, если в строчке с демоном поставить daemon sleep 120? Потребуем у linuxconf подцепить службу. Да, не долго готов конфигуратор ждать запуска демона. 15 секунд ожидания - уже побег. Другими словами, демон обязан завершиться за разумное время... Но как в таком случае он будет выполнять свои демонические функции? На самом деле, нам требуется ограниченность по времени старта демона. Демон стартует, что-то там проверяет и, выполнив fork-exit, уходит в тину. Если бы у нас имелся файл mysleep с содержимым наподобие sleep 120 &, то старт:
daemon -check sleep /etc/
rc.d/init.d/mysleep
был бы вполне корректным (демон есть, но сидит в тине). В принципе старт демонов в различных вариантах Unix организуется разными способами.
Запись мультизагрузочных компакт дисков
Иногда приходится сталкиваться с ситуацией, когда загрузочные файлы на винчестере повреждены, и система не может загрузиться. И тут приходится сталкиваться с выбором v либо снять винчестер и воткнуть его в другой системный блок, либо грузиться с дискеты. Первый вариант слишком неудобен, второй вариант достаточно ненадежен из-за частой поломки дискеты. Также у обоих вариантов есть недостаток: обычно системные файлы присутствуют только от одной системы. Тут на помощь может прийти загрузочный компакт диск. Обычно создание загрузочного диска с одной загрузочной записью не вызывает затруднений, большинство программ для записи компакт дисков (CDRWIN, Easy CD creator, Nero и другие) имеют встроенную функцию. Другое дело мультизагрузочные диски. Можно сделать загрузочную запись на каждый вид операционной системы v windows 95, windows 98, linux, os/2 и возможно другие системы. Если систему можно загрузить с дисковода, то скорее всего это можно сделать и с CD-ROM-a.
CD-ROM позволяет эмулировать загрузку с дискет 1'2Мб, 1-44Мб, 2'88Мб и загрузку с образа винчестера. В первом случае загрузочная запись займет место дисковода А, а дисковод установленный в вашей системе, станет доступен на букве В. При загрузке с образа винчестера загрузочная запись займет букву С.
Для начала необходимо подготовить загрузочные дискеты. Возня с дискетами дело утомительное, поэтому лучше воспользоваться программой RamDisk98.
Программа позволяет эмулировать жесткие диски объемом до 2Гб и стандартные типы дискет. После установки программы и перезагрузки у вас появится новая буква виртуального устройства в системе. На рисунке показано, что создан виртуальный дисковод объемом 2-88Мб и ему присвоена буква Z. Образ формируется в файле c:\ramdsk98.img при перезагрузке Windows или, если вы поставили функцию AutoSave, через каждый выбранный временной интервал. Вы работаете с данным устройством точно также как и с реальным дисководом.
Здесь я объясню, как создать загрузочный образ дискеты с системой DOS. Данный пример чисто теоретический и не претендует на оригинальность. Предположим, у вас уже установлен Windows, вы заходите в DOS и вводите в командной строке:
sys c: z:
данная команда скопирует системные файлы с вашего диска С: на диск Z:. В принципе этого уже достаточно, но в чистом DOS-e работать не всегда удобно, поэтому скопируем туда же какой-нибудь файловый менеджер, например DN. Что еще? Файлы sys.com, fdisk.exe, himem.sys, может быть вам нужны будут архиваторы. Здесь все зависит от вашего вкуса и потребностей. Конечно, запихать можно поболе на диск объемом 2-88. И самое главное, что необходимо учесть. Некоторым программам необходим временный каталог для работы, его следует сделать либо в памяти (с помощью Ramdisk.sys), либо на винчестере. Без него программы попытаются записать на диск с которого загрузились, в данном случае CD-ROM, что у них конечно же не получится и вы увидите какое-нибудь предупреждение. В конце концов, вы напихали все, что вам нужно на диск. Образ диска у вас будет лежать, как показано на рисунке, в корне диска С. Сделайте столько загрузочных записей, сколько вам нужно.
В итоге мы имеем несколько образов v image1.bin, image2.bin и т.д. Предположим, что файлы у нас имеют номера в той последовательности, в которой вы хотите увидеть при загрузке. Зачем это надо? Дело в том, что не все машины позволяют иметь мультизагрузку. Все зависит от BIOS вашего компьютера. Мне встречались машины, которые могут загрузиться только с первой загрузочной записи. Поэтому вы должны решить какая система у вас будет первой. Допустим вы выбрали DOS7.1 и назвали эту запись image1.bin.
Теперь необходимо сделать ISO образ записываемой информации. Как это сделать? Предположим, вы уже подготовили каталог, где у вас размещены файлы (речь идет не о загрузочных файлах), которые вы хотите записать. Скопируйте в корень того каталога все загрузочные записи, и еще один дополнительный файл bootcat.bin. Этот файл вы можете получить из пакета cdboot. Кстати в этом пакете очень подробно рассказывается как сделать загрузочную запись для OS/2. Для создания ISO образа вам необходимо найти программу, которая это умеет делать - CDRWIN, Easy CD Creator. Я предпочитаю использовать CDRWIN, поскольку мой Easy CD неправильно создавал образ, но возможно это проблема моей beta версии. Если вы воспользуетесь CDRWIN-ом, то проверьте есть ли у вас файлы с русскими именами, эта программа переименует в нечитаемый вид.
Небольшое отступление. Вообще свои диски я записываю под Linux-ом. Благодаря этому появляются некоторые дополнительные функции, которые я вряд ли смогу сделать под windows. Это проверка записанного ISO образа - вы можете подключить получившийся образ к своей файловой системе и посмотреть, нормально ли он сформировался:
mount -t iso9660 -o ro,loop=/dev/loop0 image.iso /cdrom
таким образом я узнал про глючность Easy CD Creator, образ созданный с его помощью не подключался к системе. Вторая возможность это использовать другой формат записи на CDROM. Те, кто работал в Linux видел, что CD диск, записанный в windows, при монтирование к системе помечает все файлы как исполняемые, что не совсем удобно. При записи диска в linux можно сделать совместимость и c файловой системой windows и с файловой системой Linux - RockRidge . А чтоб не перегружаться постоянно из Windows в Linux у меня стоит эмулятор vmware, который позволяет запускать Windows не выходя из Linux-a, т.о. всю подготовку и запись я делаю в Linux-e.
Итак, мы сделали ISO образ и в этом образе есть все загрузочные записи. Теперь необходимо сделать все записи в образе загрузочными. Для этого вам необходима программа mkbootcd из пакета cdboot.
Для того чтобы ваши загрузочные записи действительно стали загрузочными необходимо в сеансе MS-DOS дать команду:
mkbootcd image.iso bootcat.bin vi88 image1.bin -i88 image2.bin -i88 image3.bin
Здесь показано формирование трех загрузочных записей, но никто не мешает вам сделать и более. Запуск команды только с ISO образом (mkbootcd image.iso) покажет вам, есть ли там загрузочные записи и сколько.
Все вы создали образ, сделали записи загрузочными, осталось только записать образ на диск. Это можно сделать вышеуказанными программами. Для начала я бы посоветовал сделать запись на перезаписываемую болванку и проверить нормально ли загружаются все записанные системы. Проверьте нормально ли работают программы, которые вы записали и т.д. и т.п. У меня есть дома купленный мультизагрузочный диск с антивирусной программой, вот только ни одной базы к ней не записали. Надеюсь вы такого не сделаете.
Запись загрузочного сектора на флоппи-диск
Теперь мы должны написать программу на C, которая скопирует наш код (код нашей ОС) в первый сектор дискеты. Вот она:
#include <sys/types.h> /* unistd.h needs this */ #include <unistd.h> /* contains read/write */ #include <fcntl.h>
int main() { char boot_buf[512]; int floppy_desc, file_desc;
file_desc = open("./boot", O_RDONLY); read(file_desc, boot_buf, 510); close(file_desc);
boot_buf[510] = 0x55; boot_buf[511] = 0xaa;
floppy_desc = open("/dev/fd0", O_RDWR); lseek(floppy_desc, 0, SEEK_CUR); write(floppy_desc, boot_buf, 512); close(floppy_desc); }
Сперва мы открываем файл boot в режиме только для чтения и копируем файловый дескриптор в переменную file_desc. Затем читаем первые 510 байт, либо, если файл размером меньше 510 байт, читаем весь файл. Наш код невелик, поэтому последний случай наш. Будьте паинькой -- не забудьте закрыть файл. 8-)
Последние четыре строки кода открывают устройство флоппи-диска (которым, как правило, является /dev/fd0). Затем переводим указатель в начало файла, используя lseek и записываем 512 байт из буфера на дискету.
Страницы справочного руководства функций read, write, open и lseek (смотрите man 2) дадут вам достаточно информации о том, что обозначают другие параметры функций и как их использовать. Есть две строки, которые выглядят немного таинственно. Вот они:
boot_buf[510] = 0x55; boot_buf[511] = 0xaa;
Это информация для BIOS. Если предполагается, что BIOS должна распознать устройство как загрузочное, то устройство должно содержать значения 0x55 и 0xaa, расположенные по смещениям 510 и 511. (Не берусь утверждать на все 100%, но раньше [по слухам], во времена MS DOS 2.0 и ниже, этой сигнатуры не было вообще. Она появилась позднее, как ответ на загрузочный вирус ( помните такие? -- прим. ред.), который при помощи этой сигнатуры проверял , заражал ли он этот компьютер или нет. Если нет, то вирус делал свое "черное дело" и "приписывал" эти два байта. Прим.перев.). Теперь почти все. Программа читает файл boot в буфер boot_buf. Делает нужные изменения в 510 и 511 байтах и записывает boot_buf на флоппи-диск. Сохраним файл как write.c .
ЗАПОЛНЕНИЕ БАЗЫ ДАННЫХ
Во-первых, имеющаяся информация об обслуживаемых доменах была экспортирована в файл формата CSV. Типичная строка такого файла:
www.some-domain.com,fred,AaBbCcDdEeFfg,/virtual/ www.some-domain.com
где поля содержат: имя домена; имя учетной записи, используемый для загрузки файлов по ftp; шифрованный пароль для данной записи; домашний каталог (где хранятся страницы Web).
Затем был написан сценарий на языке Perl, который считывал данные из файла CSV и создавал соответствующие записи в базе данных LDAP. Это сценарий domains2ldap (см. Листинг 2). Если вы будете его использовать, отредактируйте в соответствии со своими потребностями. Прежде всего, необходимо изменить информацию о пользователе, который имеет право вносить изменения в базу данных, и о том, где находится база данных. Для этого потребуется Net::LDAP. Он доступен по адресу: http://www.clan.org (сервер CPAN), под именем perl-ldap. Я использовал версию 0.22.
Запуск
Обычно zsh указывают в качестве интерактивной оболочки для входа в систему. Но кроме этого zsh можно запускать с разными ключами, определяющими его поведение. Например, ключ -r заставляет zsh работать в "ограниченном" режиме, ключ -c указывает откуда читать команды для выполнения, а ключ -i заставляет работать в интерактивном режиме.
При работе в "ограниченном" режиме запрещается выполнять некоторые действия: изменять каталог, запускать программы с помощью команды exec, перенаправлять вывод в файлы, изменять значение переменных среды, используемых при запуске программ, а также запускать программы, используя их абсолютные имена. При запуске zsh старается эмулировать sh или ksh, в зависимости от того, под каким именем его запустили. В режиме эмуляции не исполняются обычные скрипты инициализации/завершения работы zsh. Для инициализации используются файлы /etc/profile и $HOME/.profile
Запуск из оболочки
До начала редактирования /etc/inittab и внесения ошибок в задания init, было бы неплохо вам сначала проверить свои знания с помощью запуска qlogin из оболочки. Посмотрите работу qlogin своими глазами. Проблема с init в том, что, независимо от того, что это очень важный процесс, который вам не желательно нарушать, у него нет стандартного файла ошибок, т.е. не существует способа передать вам сообщение об ошибке, поэтому сложно понять, почему он работает не так, как вы ему говорите.
Обычно признаком того, что с init что-то не в порядке служит сообщение "id X spawning too fast. Disabled for 5 minutes." Это означает, что программа (например, qlogin), выполнять которую вы заставляете init, работает с ошибками и немедленно прерывается. А поскольку это запись "respawn", init просто создает новый процесс, выполняющий ту же программу. И эти процессы запускаются и "падают" поочередно. Init замечает это и "притормаживает" процедуру "respawn" на 5 минут, надеясь, что кто-нибудь исправит проблему. Но какова причина ошибки выполнения программы? Никто не знает, кроме самой программы, но она молчит.
Поэтому нужно просто вызвать qlogin из командной строки оболочки с теми же аргументами, с которыми вы собираетесь запускать ее из init. Теперь, если qlogin "рухнет", она выдаст сообщение об ошибке.
Разумеется, было бы лучше, если бы оболочка, из которой вы вызываете qlogin, была оболочкой суперпользователя. В противном случае я могу рассказать вам прямо сейчас, какие у вас будут сообщения об ошибках.
Запуск ("Ной родил Иакова, Иаков родил")
Начинается все со startx: добавляет xauth для доступа данного пользователя через unix и localhost к X-серверу и вызывает xinit. Т.к. никто их оттуда (.Xauthority и .ICEauthority) не удаляет, то через некоторое время запуск X начинает тормозить (пытается обратиться к серверу доступа через указанные в этих файлах порты, а там уже никого нет). Пришлось в собственный скрипт перед запуском startx добавить обнуление этих файлов).
xinit убеждается в наличии /etc/X11/xinit/Xclients и вызывает его.
Xclients пытается определить какой desktop установлен и запускает gnome-session/strtkde/Another Level/AfterStep/...
gnome-session (--help)...
Запуск windows-приложений под FreeBSD
Автор: Станислав Лапшанский, slapsh@slapsh.pp.ru
Опубликовано: 15.12.2002
© 2002, Издательский дом «КОМПЬЮТЕРРА» | http://www.computerra.ru/
Журнал «СОФТЕРРА» | http://www.softerra.ru/
Этот материал Вы всегда сможете найти по его постоянному адресу: http://www.softerra.ru/freeos/22624/
Эта статья является переводом текста Dru Lavigne.
Одним из многих достоинств FreeBSD, которое отчетливо становится видным, если на вашем компьютере установлена не одна операционная система, является то, что для доступа к данным находящимся в разделе другой операционной системы нет никакой надобности покидать FreeBSD. Другими словами вы можете просто смонтировать раздел в файловую систему FreeBSD и читать, писать или удалять файлы находящиеся в этом разделе. (Разумеется, поклонники Linux лишь хмыкнут – подобные возможности не уникальны и давно присутствуют в любимой ими операционной системе. Но что скажут поклонники Windows? – прим. переводчика.) Однако у вас может возникнуть вопрос: «А как обстоят дела с запуском исполняемых файлов?» Если ваша «другая» операционная система сделана корпорацией Майкрософт, и, кроме того, вы воспользуетесь эмулятором Windows (Wine), то на вашей FreeBSD вполне можно будет выполнять довольно большое количество Windows-приложений. (Кроме Windows-приложений, FreeBSD позволяет выполнять программы скомпилированные для операционной системы Linux. Поддержка Linux-приложений реализована гораздо полнее и лучше, чем поддержка Windows-программ. Достаточно сказать, например, что под FreeBSD прекрасно себя чувствует Linux-версия сервера баз данных Oracle версии 8 – прим. переводчика.)
В сегодняшней статье я хочу продемонстрировать процесс установки и использования эмулятора Wine. Если все пойдет нормально, то я рискну испытать судьбу, попробовав запустить какое-нибудь Windows-приложение на компьютере, на винчестере которого, кроме FreeBSD вообще ничего нет – ни одного раздела с софтом от Майкрософта.
Я поставлю Wine на двух машинах моей сети. На первой машине установлены Windows 98 и FreeBSD 4.3-RELEASE, выбор рабочей системы осуществляется в процессе загрузки. Вторая машина полностью управляется FreeBSD 4.3-RELEASE. Воспользовавшись аккаунтом суперпользователя я откомпилирую и установлю Wine на обеих машинах: su - Password: cd /usr/ports/emulators/wine make install clean
После того как Wine установлен, на обеих машинах необходимо проверить конфигурационные файлы ядра на наличие в них необходимых для работы Wine опций. Оставаясь под суперпользователем пишем: cd /usr/src/sys/i386/conf cp GENERIC WINE
Затем, используя мой любимый текстовый редактор, я открыл файл WINE для того, что бы убедиться в том, что в нем содержатся следующие строки: options USER_LDT options SYSVSHM options SYSVSEM options SYSVMSG
На моей FreeBSD 4.3-RELEASE, три опции SYS* уже были включены, так что мне пришлось добавить лишь параметр USER_LDT. Если вам тоже пришлось что-нибудь добавить, сохраните внесенные изменения и перекомпилируйте ядро: /usr/sbin/config WINE cd ../../compile/WINE make depend && make && make install && reboot
В последней строке на самом деле я вызываю сразу четыре отдельных команды, символы «&&» означают, что следующая команда из списка будет выполнена только при условии успешного выполнения предыдущей команды. Если вы решитесь включить в список команду «reboot», убедитесь, что другие пользователи в это время ничего не делают на этой системе, поскольку система будет перезагружена немедленно после окончания этапа установки скомпилированного ядра.
После установки Wine, прилагающуюся к нему документацию можно будет прочитать при помощи команды man 1 wine, а так же посмотреть ее в каталоге /usr/local/share/doc/wine. Кроме того, я нашел очень полезное HOW-TO (см. http://www.la-sorciere.de/Wine-HOWTO/book1.html), которое может очень пригодиться при первой установке Wine.
Для начала давайте попробуем запустить Wine на системе на которой помимо FreeBSD установлена Windows 98. Для запуска Wine на этой машине мне придется преодолеть следующие этапы:
Найти и где-нибудь смонтировать раздел Windows. Тщательно проверить и поправить конфигурационный файл Wine. Протестировать получившуюся систему запуском какого-нибудь Windows-приложения.
Поскольку установка операционной системы на этот компьютер была произведена довольно давно, я воспользуюсь утилитой sysinstall для того что бы восстановить в памяти карту распределения дискового пространства на винчестере. Под суперпользователем: /stand/sysinstall Configure Fdisk пробел ad0
И вот я вижу нечто подобное: Offset Size(ST) End Name PType Desc 0 63 62 - 6 unused 63 4176837 4176899 ad0s1 2 fat 4176900 4016250 8193149 ad0s2 3 freebsd
Для выхода из fdisk'а я нажал клавишу q, а затем покинул sysinstall несколько раз выбрав пункт «Cancel». Видно, что раздел Windows во FreeBSD имеет название ad0s1. Для того, что бы смонтировать этот раздел, сначала я создам для него точку монтирования под названием «dos»: mkdir /dos
На всякий случай я проверю права доступа к новому каталогу: ls -l / | grep dos drwxr-xr-x 2 root wheel 512 Aug 31 13:07 dos
Все нормально, все пользователи могут «читать» и «выполнять», и лишь один root может «писать» файлы.
Перед тем, как смонтировать раздел Windows на постоянной основе при помощи файла /etc/fstab, я должен убедиться, что он может правильно монтироваться вручную: mount -t msdos /dev/ad0s1 /dos
Заметьте, что в качестве типа файловой системы используется «msdos», название устройства «/dev/ad0s1», а точкой монтирования выступает каталог «/dos». Поскольку в результате выполнения команды я просто получил обратно приглашение к работе, система смонтирована корректно. Это можно проверить при помощи команды df: df -h Filesystem Size Used Avail Capacity Mounted on /dev/ad0s2a 97M 36M 53M 40% / /dev/ad0s2f 1.7G 567M 1.0G 35% /usr /dev/ad0s2e 19M 2.0M 16M 11% /var procfs 4.0K 4.0K 0B 100% /proc /dev/ad0s1 2.0G 783M 1.2G 38% /dos
Кроме того, я могу проверить содержимое смонтированного раздела при помощи команды ls. Я воспользуюсь ключом «-F» для того что бы названия каталогов отличались от названий файлов символом «/»: ls -F /dos
AUTOEXEC.BAT* COMMAND.COM* MSDOS.SYS* SCANDISK.LOG* BOOT.INI* CONFIG.SYS* My Documents/ SETUPLOG.TXT* BOOTLOG.PRV* DETLOG.TXT* NETLOG.TXT* WINDOWS/ bootsect.bsd* IO.SYS* Program Files/ RECYCLED/ ntdetect.com* ntldr*
Если вы никогда прежде не монтировали файловые системы, то вероятно вам понадобится несколько минут что бы поиграться с командами «cd» и «ls». Имейте в виду, что многие файлы имеют названия в верхнем регистре, так что когда вы будете к ним обращаться, пишите их с учетом регистра, поскольку FreeBSD чувствительна к регистру. Мало того, некоторые файлы содержат в названии символы пробела. Для доступа к таким файлам вы можете попробовать напечатать первоначальные несколько букв такого файла и нажав клавишу «Tab» воспользоваться функцией автодополнения имени файла, или поставить перед пробелом в имени файла символ обратного слеша «\»: cd Program\ Files
Если вы хотите монтировать раздел Windows непосредственно во время загрузки, аккуратно добавьте следующую строку в файл /etc/fstab: /dev/ad0s1 /dos msdos rw 0 0
Удостоверьтесь, что вы используете правильное название Windows-раздела, поскольку у вас оно может отличаться. Перед сохранением убедитесь, что вы не внесли в файл какой-нибудь ошибки. Я всегда стараюсь убедиться что мои изменения в файле fstab работоспособны следующим способом: shutdown now press enter when receive prompt back, then type exit
Как только вы вернетесь обратно, при помощи команды df -h, вы сможете убедиться что разделы смонтированы верно.
Теперь давайте отредактируем конфигурационный файл эмулятора Wine. В своем любимом текстовом редакторе откройте файл /usr/local/etc/wine.conf. Поскольку конфигурация Wine обычно не требует никаких изменений для работы, я сделаю в ней большие пропуски и покажу лишь участки куда вам придется внести некоторые изменения в соответствии с положением дел в вашей системе: more /usr/local/etc/wine.conf WINE REGISTRY Version 2 ;; All keys relative to \\Machine\\Software\\Wine\\Wine\\Config
<Вырезано>
[Drive A] "Path" = "/mnt/fd0" "Type" = "floppy" "Label" = "Floppy" "Serial" = "87654321" "Device" = "/dev/fd0"
[Drive C] "Path" = "/c" "Type" = "hd" "Label" = "MS-DOS" "Filesystem" = "win95"
<Вырезано>
Вот тут следует остановиться, поскольку в этом месте необходимо внести изменения. Замените значение переменной Path с «/c» на название вашей точки монтирования. Поскольку у меня точка монтирования называется «/dos», я изменил эту строку следующим образом: "Path" = "/dos"
Сохраните изменения. Я обнаружил, что для корректной работы Wine этот файл должен быть скопирован в домашний каталог пользователя. Под суперпользователем я произведу некоторые изменения в домашнем каталоге пользователя genisis: mkdir ~genisis/.wine chown genisis ~genisis/.wine cp /usr/local/etc/wine.conf ~genisis/.wine/config
Обратите внимание, что при копировании в каталог .wine я переименовал конфигурационный файл в «config». На данном этапе я покину аккаунт суперпользователя, поскольку конфигурация окончена. Под пользователем genisis, я запущу сессию XWindow: startx
Находясь в XWindow, в окне xterm'а, выберем для запуска какое-нибудь приложение: cd /dos/WINDOWS ls | more
Среди прочего я обнаружил файл PROGMAN.EXE. Интрига заключается в том, что это Диспетчер Программ Windows. Я решил посмотреть, смогу ли я запустить его в FreeBSD под эмуляцией Wine: wine -winver win98 -managed PROGMAN.EXE
После нескольких секунд ожидания, я был поприветствован Диспетчером Программ. Щелкнув по меню «Файл», я выбрал пункт «Выполнить» и нажал на кнопку «Обзор». В результате этого я увидел обширный список файлов находящихся на моем Windows-разделе.
Теперь началось веселье. При помощи метода проб и ошибок я стал выяснять какие приложения я смогу запустить. Я начал с Калькулятора, поэтому выбрав CALC.EXE я нажал кнопку «Открыть», а затем кнопку «ОК». И, вуаля, я пользуюсь Калькулятором Windows. Вы можете просидеть ночь тестируя приложения на «запускаемость» или вы можете воспользоваться функцией поиска на любом из этих двух сайтов:
Wine Development HQ (см. http://www.winehq.com/Apps) CodeWeavers Wine Application Database (см. http://appdb.codeweavers.com/)
В базе первого сайта на момент написания статьи содержится 2704 приложения которые протестированы на совместимость с Wine. Второй сайт имеет более удобный дизайн, но находится в стадии разработки.
Теперь давайте сделаем что-нибудь поинтереснее. Я вошел под суперпользователем и решил проверить, могу ли я установить и запустить какое-нибудь Windows-приложение под эмуляцией Wine. Для поиска программ, я пошел на http://www.download.com.
Я щелкнул по ссылке «самые популярные» игры и увидел Solsuite 2001. Реклама обещала 282 различных пасьянса. Я выкачал инсталлятор, который назвался solsuite.exe и сохранил его в каталоге /dos.
Вернувшись в xterm'е я напечатал: cd /dos wine -winver win98 -managed solsuite.exe
И тут же получил сообщение об ошибке, гласящее об отсутствии каталога .wine. Давайте создадим в домашнем каталоге суперпользователя этот подкаталог и скопируем туда конфигурационный файл Wine: mkdir ~/.wine cp /usr/local/etc/wine.conf ~/.wine/config
Теперь, когда я повторил запуск wine, запустился мастер инсталляции программы. Я проследовал через все этапы установки и проследил за процессом копирования файлов. В самом конце инсталлятор завис, однако он сообщал, что до конца процесса установки осталось 0 минут, 0 секунд, поэтому я решил попытать счастья и для завершения установки воспользовался комбинацией «^c». Затем я набрал: cd Program\ Files/SolSuite wine -winver win98 -managed Solsuite.exe
Наступило время обзванивать соседей и хвастаться. Я успешно установил и запустил Windows-программу из FreeBSD и, кроме того, у меня возобновился свой интерес к карточным играм.
В качестве последнего теста, я перезагрузил компьютер в Windows 98. Там я нажал на кнопку «Пуск», и в меню «Программы» увидел новый пункт «Solsuite-Solitaire Card Games», внутри правда было пусто. Не испугавшись, я запустил проводник и дважды щелкнул по папке «Program Files», а затем вошел в каталог «Solsuite», где и обнаружил выполняемые файлы. Это хороший знак, подумал я. Я открыл в проводнике папку Windows, затем «Программы», а затем «Solsuite-Solitaire Card Games», и перетащив туда правой кнопкой мыши файл solsuite.exe, выбрал в появившемся контекстном меню пункт «Создать ярлык».
Теперь нажав «Пуск», «Программы», «Solsuite-Solitaire Card Games» и выбрав «Ярлык на SolSuite», я опять могу выбирать интересующий меня пасьянс. Я впечатлен.
Настало время для самого серьезного испытания. Я перехожу к компьютеру, на котором установлена только FreeBSD. Его жесткий диск полностью отформатирован в файловой системе UFS и, разумеется не содержит ни одного компонента Windows. (На самом деле уважаемый автор зря так пугает потенциальных пользователей Wine – он изначально разрабатывался для выполнения Windows-приложений без какого-либо использования кода Windows – прим. переводчика).
Я вошел в систему под суперпользователем и создам там несколько каталогов и пустых файлов, наличие которых предполагается Windows-программами: su - Password: mkdir -p /usr/local/lib/win/windows cd /usr/local/lib/win/windows mkdir system touch win.ini cd system touch shell.dll shell32.dll winsock.dll wsock32.dll
Помните как нам пришлось отредактировать одну строчку в файле /usr/local/etc/wine.conf, что бы она указывала на точку монтирования раздела Windows? Сейчас нам придется сделать это снова, правда указывать она будет на «поддельную» структуру Windows-каталогов: [Drive C] "Path" = "/usr/local/lib/win"
Затем я создам необходимые каталоги и скопирую конфигурационный файл суперпользователю и пользователю genisis: mkdir ~/.wine cp /usr/local/etc/wine.conf ~/.wine/config mkdir ~genisis/.wine chown genisis ~genisis/.wine cp /usr/local/etc/wine.conf ~genisis/.wine/config
Оставаясь суперпользователем, я вернусь на http://www.download.com и загружу инсталлятор Solsuite 2001. Теперь я сохраню его в /usr/local/lib/win. Теперь запущу сессию XWindow, xterm и напечатаю: cd /usr/local/lib/win wine -winver win95 -managed solsuite.exe
Опять начнет выполняться инсталляционная программа. Я получил сообщение об ошибке, в котором говорилось о невозможности обнаружить файл «explorer.exe», но я успешно его проигнорировал. Когда все закончилось, я напечатал: cd Program\ Files/SolSuite wine -winver win95 -managed SolSuite.exe
И хотя это было немного медленнее (но это и более старый компьютер), и, кроме того, мне пришлось подстроить конфигурацию дисплея, но я все-таки смог поиграть в карточную игру написанную для Windows, на компьютере, который полностью выделен под FreeBSD. Человек с исследовательским складом натуры получит массу удовольствия от Wine.
Все вышесказанное говорит о том, что эмулятор Wine это программа из коллекции портов FreeBSD, с которой можно неплохо поразвлечься. Если в результате ваших экспериментов с Wine вам удастся запустить под ним программу, которая не включена в базу данных выполняемых под Wine программ, добавьте вашу запись в эту базу на любом из двух сайтов о которых я упомянул выше.
Телефон редакции: (095) 232-2261
E-mail редакции: inform@softerra.ru
По вопросам размещения рекламы обращаться к Алене Шагиной по телефону +7 (095) 232-2263 или электронной почте reclama@computerra.ru
Защита файлов в операционной системе UNIX
Сергей Кузнецов
С самого начала ОС UNIX замышлялась как интерактивная система.
Другими словами, UNIX предназначен для терминальной работы. Чтобы
начать работать, человек должен "войти" в систему, введя со
свободного терминала свое учетное имя (account name) и, возможно,
пароль (password). Человек, зарегистрированный в учетных файлах
системы и, следовательно, имеющий учетное имя, называется
зарегистрированным пользователем системы. Регистрацию новых
пользователей обычно выполняет администратор системы.
Пользователь не может изменить свое учетное имя, но может
установить и/или изменить свой пароль. Пароли хранятся в
отдельном файле в закодированном виде. Не забывайте свой пароль,
снова узнать его не поможет даже администратор!
Все пользователи ОС UNIX явно или неявно работают с файлами.
Файловая система ОС UNIX имеет древовидную структуру.
Промежуточными узлами дерева являются каталоги со ссылками на
другие каталоги или файлы, а листья дерева соответствуют файлам
или пустым каталогам. Каждому зарегистрированному пользователю
соответствует некоторый каталог файловой системы, который
называется "домашним" (home) каталогом пользователя. При входе в
систему пользователь получает неограниченный доступ к своему
домашнему каталогу и всем каталогам и файлам, содержащимся в нем.
Пользователь может создавать, удалять и модифицировать каталоги и
файлы, содержащиеся в домашнем каталоге. Потенциально возможен
доступ и ко всем другим файлам, однако он может быть ограничен,
если пользователь не имеет достаточных привилегий.
Поскольку ОС UNIX с самого своего зарождения задумывалась как
многопользовательская операционная система, в ней всегда была
актуальна проблема авторизации доступа различных пользователей к
файлам файловой системы. Под авторизацией доступа понимаются
действия системы, которые допускают или не допускают доступ
данного пользователя к данному файлу в зависимости от прав
доступа пользователя и ограничений доступа, установленных для
свой пароль. Имеется специальная программа /bin/passwd,
изменяющая пароли. Однако пользователь не может сделать это даже
с помощью этой программы, поскольку запись в файл /etc/passwd
запрещена. В системе UNIX эта проблема разрешается следующим
образом. При выполняемом файле может быть указано, что при его
запуске должны устанавливаться идентификаторы пользователя и/или
группы. Если пользователь запрашивает выполнение такой программы
(с помощью системного вызова exec), то для соответствующего
процесса устанавливаются идентификатор пользователя,
соответствующий идентификатору владельца выполняемого файла и/или
идентификатор группы этого владельца. В частности, при запуске
программы /bin/passwd процесс получит идентификатор
суперпользователя, и программа сможет произвести запись в файл
/etc/passwd.
И для идентификатора пользователя, и для идентификатора группы
реальный ID является истинным идентификатором, а действующий ID -
идентификатором текущего выполнения. Если текущий идентификатор
пользователя соответствует суперпользователю, то этот
идентификатор и идентификатор группы могут быть переустановлен в
любое значение системными вызовами setuid и setgid. Если же
текущий идентификатор пользователя отличается от идентификатора
суперпользователя, то выполнение системных вызовов setuid и
setgid приводит к замене текущего идентификатора истинным
идентификатором (пользователя или группы соответственно).
Как и полагается делать в многопользовательской операционной
системе, в UNIX поддерживается единообразный механизм контроля
доступа к файлам и справочникам файловой системы. Любой процесс
может получить доступ к некоторому файлу в том и только в том
случае, если права доступа, описанные при файле, соответствуют
возможностям данного процесса.
Защита файлов от несанкционированного доступа в ОС UNIX
основывается на трех фактах. Во-первых, с любым процессом,
создающим файл (или справочник), ассоциирован некоторый
уникальный в системе идентификатор пользователя, который в
дальнейшем можно трактовать как идентификатор владельца вновь
созданного файла. Во-вторых, с каждый процессом, пытающимся
получить некоторый доступ к файлу, связана пара идентификаторов -
действующие идентификаторы пользователя и его группы. В-третьих,
каждому файлу однозначно соответствует его описатель - i-узел.
На последнем факте стоит остановиться более подробно. Важно
понимать, что имена файлов и файлы как таковые - это не одно и то
же. В частности, при наличии нескольких жестких связей с одним
файлом несколько имен файла реально представляют один и тот же
файл и ассоциированы с одним и тем же i-узлом. Любому
используемому в файловой системе i-узлу всегда однозначно
соответствует один и только один файл. I-узел содержит достаточно
много разнообразной информации (большая ее часть доступна
пользователям через системные вызовы stat и fstat), и среди этой
информации находится часть, позволяющая файловой системе оценить
правомочность доступа данного процесса к данному файлу в
требуемом режиме.
Общие принципы защиты одинаковы для всех существующих вариантов
системы: Информация i-узла включает идентификаторы текущего
владельца файла (немедленно после создания файла идентификаторы
его текущего владельца устанавливаются соответствующими
действующим идентификатором процесса-создателя, но в дальнейшем
могут быть изменены системными вызовами chown и chgrp). Кроме
того, в i-узле файла хранится шкала, в которой отмечено, что
может делать с файлом пользователь - его владелец, что могут
делать с файлом пользователи, входящие в ту же группу
пользователей, что и владелец, и что могут делать с файлом
остальные пользователи.
Мелкие детали реализации в разных вариантах системы различаются,
однако в целом именно такова общая картина защиты файлов в ОС
UNIX.
Зависимости пакетов от библиотек и средств программирования
gnumeric -> guile -> umb-scheme
kernelcfg, netcfg -> tkinter -> tix, python
tix -> tk -> tcl
Tclx и itcl никем не используются.
"Жду ваших указаний"
Мы подробно рассмотрели что нужно сделать, чтобы компьютер периодически выполнял какие-то работы без нашего участия. А что, если нужно заставить его выполнить какую-то работу только один раз. Например, выключиться в полночь или еще что-нибудь в этом роде. Для таких случаев в Linux имеется еще один демон - atd, который, так же как и crond, постоянно находится "на посту". В этом вы можете убедиться, выполнив команду
[user] $ ps -ax | grep atd
Для того, чтобы задать работу этому демону, применяются команды at и batch.
Команда at в простейшем случае запускается с единственным параметром - временем выполнения задания:
[user] $ at TIME
После этого появляется следующее предупреждение: warning: commands will be executed using (in order) a) $SHELL b) login shell c) /bin/sh at>
и программа ожидает ввода вашего задания. В качестве задания может использоваться любая команда оболочки (в том числе скрипты). После завершения ввода команды надо нажать комбинацию клавиш [Ctrl-D]. В ответ вы увидите сообщение о том, что ваше задание принято под таким-то номером:
job 4 at 2002-09-26 12:15
Вы можете просмотреть очередь ждущих своего времени заданий с помощью команды atq (к сожалению, выводятся только номера ожидающих выполнения работ и время их выполнения, а содержание задания, то есть вызываемая команда, не выводится). Если вы не суперпользователь, вам будут показаны только ваши задания. Суперпользователь видит список заданий, введенных всеми пользователями системы. С помощью команды atrm вы можете удалить задание из этой очереди. Для этого надо указать его номер в качестве параметра команды atrm.
Посмотрим теперь как правильно задать время выполнения вашего задания, то есть правила формирования параметра TIME для команды at. В простейшем варианте указывается только час и минута запуска задания, разделенные двоеточием: "hh:mm". Можно указывать время "в американском стиле", добавив после минут окончание AM (до полудня) или PM (после полудня). Если сегодня указанное время уже прошло, задание будет выполняться завтра. Допускается прямо указать команде at, что задание должно быть выполнено сегодня (at 10:00PM today) или завтра (at 10:00PM tomorrow). Можно также указать дату выполнения задания в формате MMDDYY, или MM/DD/YY, или DD.MM.YY. Допускается использовать название месяца с числовым указанием дня и (необязательным) указанием года. При этом указание на время выполнения в течение заданного дня должно стоять перед указанием даты, например at 10:00PM Jul 31. Можно также указать программе at, что выполнение задания нужно повторить несколько раз. Для этого после указания времени добавляют количество повторений с указанием через какой интервал (час, день, неделя или месяц) надо повторить задание. Например, по команде at 10:00PM + 3 days задание будет выполняться в 10 вечера сегодня и еще в течение 3 дней в то же время. В общем, вариантов указания времени выполнения задания существует множество, их полная спецификация приведена в файле /usr/sharedoc/at-3.1.8/timespec (цифры 3.1.8 обозначают версию утилиты at и у вас могут быть другими).
Как и в случае с демоном crond, суперпользователь может лишить некоторых пользователей права запускать команду at, прописав их имена в специальный файл /etc/at.deny, либо же разрешить использовать at только тем пользователям, имена которых перечислены в файле /etc/at.allow. Причем оболочка сначала ищет файл /etc/at.allow и, если он есть, проверяет наличие вашего имени в нем. Второй файл уже не анализируется. Если же файла /etc/at.allow не существует, проверяется /etc/at.deny, и вам разрешается выполнить at, если ваше имя в этом файле не встречается. Если ни того, ни другого файла не существует, программу at может запускать только суперпользователь. В Red Hat Linux по умолчанию создается пустой файл /etc/at.deny, то есть давать задания демону atd могут все пользователи.
Кроме выполнения заданий в указанное время демон atd может выполнять какие-то работы в периоды низкой загруженности системы. Задания на этот случай формулируются с помощью утилиты batch и ждут своего часа в очереди. Когда загрузка системы снизится до уровня, указанного параметром -l (задается при запуске atd, по умолчанию равен 0.8), задания из очереди запускаются на выполнение.
Железо
2.1 Настройка
2.2 Упражнения
2.3 Дополнительные сведения
Когда вы включаете компьютер, он выполняет самотестирование дабы быть уверенным, что всё в порядке. Это называется "Самотестирование при включении" (``Power on self test''- POST). Затем начальный загрузчик, размещенный в ROM BIOS, ищет загрузочный сектор. Этот сектор является первым сектором диска и содержит небольшую программу для загрузки операционной системы. Загрузочные сектора помечаются "волшебным" числом 0xAA55 = 43603 в позиции 0x1FE = 510. Это последние два байта сектора. Это позволяет компьютеру решить является ли данный диск загрузочным.
Начальный загрузчик имеет список мест для поиска загрузочных секторов. Моя старая машина ищет на первом флоппи, затем на первом винчестере. Более современные машины могут просматривать CD-ROM. Если он находит загрузочный сектор, он загружает его содержимое в оперативную память и передает управление программе, которая продолжает процесс загрузки ОС. На типичной Linux-машине это будет программа первого шага загрузчика LILO. Существует много способов и конфигураций процесса загрузки. Подробности можно почерпнуть в LILO User's Guide. Ссылки приведены в разделе LILO.
На самом деле о железе PC и его поведении можно рассказать гораздо больше. Но здесь не место. На эту тему есть много хороших книг.
Zip, Jaz и другие сменные носители
Сменные диски могут отформатированы точно так же, как обычные жесткие диски. Для определения параметров диска достаточно подключить привод к системе и вставить туда диск во время загрузки. Просмотрите вывод команды dmesg и удостоверьтесь, что в нем присутствуют ваше устройство и размер диска. Если ядро выдает
Can't get the size
то диска в устройстве нет. В таком случае вам нужно перезапустить машину перед тем, как пытаться отформатировать диски.
Звук
Чтобы Wine "зазвучал", вы должны раскомментировать одну из строк в секции [WinMM]:
[WinMM] ... ;"Drivers" = "wineoss.drv" ; default for most common configurations "Drivers" = "winearts.drv" ; for KDE ;"Drivers" = "winealsa.drv" ; for ALSA users ;"Drivers" = "winejack.drv" ; for Jack sound server ;"Drivers" = "winenas.drv" ; for NAS sound system ;"Drivers" = "wineaudioio.drv" ; for Solaris machines ;"Drivers" = "" ; to disable sound ...
У меня запущен KDE, поэтому для переменной "Drivers" я указал значение "winearts.drv". Для большинства конфигураций подойдёт "wineoss.drv".
Чтобы убедиться в том, что в Wine появился звук, я установил Winamp версии 2.0 Заголовок главного окна оказался битым (но только главного -- окно плэйлиста и эквалайзера отображалось корректно), а само окно "мазалось" при перемещении других окон поверх него. Но звук был и что самое удивительное во всём этом -- в системном лотке KDE появился значок агента Winamp! И на рабочем столе столе тоже (см. скриншот)
