Ядро Linux
4.1 Настройка
4.2 Упражнения
4.3 Дополнительные сведения
Ядро выполняет множество полезной работы. Думаю, что правильно охарактеризовать его задачу можно так: оно заставляет железо выполнять задания программ точно, надежно и эффективно.
Процессор может единовременно выполнять только одну инструкцию, однако в системе Linux выполняются одновременно множество вещей. Ядро достигает этого быстрым переключением с задачи на задачу. Это приводит к лучшему использованию процессора, т.к. ядро отслеживает какие процессы готовы активно выполняться, а какие ожидают чего-либо вроде записи в файл или ввода с клавиатуры. Эта задача ядра называется scheduling.
Если программа ничего не делает -- её не надо держать в оперативной памяти. Если даже она что-то делает, могут найтись части, которые не делают ничего. Адресное пространство каждого процесса разделено на страницы. Ядро следит за тем, какие страницы каких процессов используются чаще. Редко используемые страницы могут быть перемещены в своп-раздел. Когда они понадобятся снова, другие неиспользуемые страницы перемещаются в своп, освобождая место в памяти. Это называется управлением виртуальной памятью.
Если вы уже компилировали своё собственное ядро, вы должны были заметить множество опций для различных устройств. Ядро содержит множество специального кода для взаимодействия с разнообразными видами железа и представляет все это для приложений достаточно простым и стандартным способом.
Ядро также управляет файловой системой, межпроцессным взаимодействием и всей этой сетевой кухней.
Будучи загруженным в память, первой задачей ядра является поиск и запуск программы init.
Эффект «хорошего соседа»
Для чего каждый раз перечитывать дисковые дескрипторы? Не будет ли достаточным создавать все необходимые структуры данных при создании логики и в дальнейшем ими пользоваться? Ведь пересоздание всех структур каждый раз с нуля сильно усложняет реализацию логики и работу с ней. Хорошо, допустим, на диске только одна операционная система и только в ней производится разбиение диска. Тогда такое поведение действительно нелогично. А если операционных систем несколько? А если имеются схемы загрузки на разные корневые файловые системы? А если диски переносились с одной машины на другую? Ни при каких обстоятельствах Linux не создаст проблем для своих соседей. И одно очень большое предупреждение. Опасайтесь использовать логику из операционных систем сомнительного качества.
Эффекты тонкой настройки
Автор: Станислав Лапшанский, slapsh@kos-obl.kmtn.ru
Опубликовано: 16.11.2001
Оригинал: http://www.softerra.ru/freeos/14083/
Статья является переводом текста Гилберта Гонга (Gilbert Gong), опубликованного по адресу http://www.daemonnews.org/200108/benchmark.html.
Эмуляция "мыши"
XKB может эмулировать события мыши с помощью клавиатуры. То есть, его можно настроить так, что при нажатии определенных клавиш X-сервер будет посылать приложению сообщения (events) не о нажатии/отжатии кнопок, а о перемещении мыши и нажатии кнопок на мышке.
Делается это с помощью соответсвующих действий
(actions) - перемещение мыши, нажатие кнопки мыши, выбор кнопки "по умолчанию".
Рассмотрим их немного подробнее.
В action "перемещение" можно задавать сразу обе координаты (или их приращения). Координаты могут быть как абсолютные (это означает, что при выполнении такого действия указатель мыши должен встать в заданную точку экрана), так и относительные - собственно перемещение на несколько точек в нужном направлении. Обычно для удобства делают несколько разных action
для одного направления, но с разными приращениями - на одну точку, на десять точек и т.д. Эти action можно привязать к одной кнопке, но в разных уровнях. Получится, что при обычном нажатии кнопки указатель смещается, на одну точку, а нажатие той же кнопки с Shift'ом перемещение будет на несколько точек при одном нажатии. В action "нажатии кнопки мыши" можно кроме самой кнопки указать и число повторов. То есть, одиночное нажатие клавиши может эмулировать "двойной клик" (или тройной, четверной и т.п.). Кроме того, существует разновидность этих действий, которая не просто "нажимает кнопку мыши" по нажатии клавиши, а оставляет ее нажатой после отпускания клавши (как все Lock клавши). То есть, вы можете с помощью такого действия "прижать кнопку мыши", переместить указатель и повторным нажатием клавиши "отпустить кнопку мыши". Естественно, это выглядит так, как будто вы двигали реальную мышь с нажатой кнопкой. И наконец, обратите внимание, что кнопок мыши может быть до пяти, а с учетом "многократных кликов" и Lock'ирующих нажатий может получится, что под "мышинные кнопки" придется занять довольно много клавиш. Для того, чтобы сократить это количество в XKB предусмотрено, что одну из кнопок можно объявить "кнопкой по умолчанию" (default button). Для такого назначения и его изменения предусмотрены специальные действия, в которых можно опять же указать, как конкретную кнопку (по номеру), так и относительное изменение номера "кнопки по умолчания". Комбинируя эти действия, можно одной клавишей перебирать циклически кнопки (делая их по очереди "умолчательными"), а в действиях "нажимающих" кнопки указать, что они относятся к той кнопке, которая сейчас выбрана как default button. (Проблема только в том, как не запутаться и не забыть - какая кнопка сейчас выбрана :-)
Кроме того, существует два режима (mode) перемещения мыши - простой и "с ускорением" (accelerated). При одиночном нажатии клавиши разница между ними незаметна. А вот если вы держите клавишу нажатой и работает автоповтор, тот в обычном режиме на каждый автоповтор указатель смещается на одно и то же количество точек (заданое в аргументах действия). А в accelerated mode
указатель начинает ускоряться, то есть с каждым новым автоповтором размер одиночного шага растет.
Весь процесс ускорения описывается несколькими дополнительными параметрами, которые хранятся во внутренних переменных XKB (являются частью "состояния" XKB). (Надо заметить, что режим ускорения имеет свои параметры автоповтора - задержку между реальным нажатием клавиши и первым повтором и интервал между повторорами.) Итак, эти параметры (числовые) описывают
delay - интервал (в миллисекундах) от нажатия клавиши (эмулирующей движение мыши) до первого автоповтора. interval - интервал (в миллисекундах) между повторами maxspeed - максимальная скорость (в точках на один повтор) timetomax - количество повторов, за которое достигается максимальная скорость движения. Как видите, здесь нет в явном виде величины ускорения. XKB сам вычисляет его из начальной величины смещения (задается в конкретном действии), maxspeed и timetomax. curve - "степень кривизны" ускорения. Дело в том, что скорость может расти не линейно. В общем виде приращение скорости пропорционально функции X^(1 + curve/1000). То есть, при curve=0 скорость растет линейно, а при других значениях (от -1000 до +1000) с некоторой "кривизной".
По умолчанию используется именно режим с ускорением.
Включение и выключение эмуляции мыши и выбор режима движения выбирается двумя управляющими флагами XKB (XKB Controls) - MouseKeys и MouseKeysAccel.
Надо заметить, что по умолчанию все нужные действия описаны и привязаны к кнопкам "дополнительной цифровой клавиатуры" (NUMPAD). Для включения и выключения режима эмуляции мыши используется комбинация Shift+NumLock.
Эмуляторы аппаратного обеспечения
Самые «тяжелые» и ресурсоемкие эмуляторы. С помощью этих систем можно создавать виртуальные компьютеры любой конфигурации.
Эмуляторы общего назначения:
Bochs: http://bochs.sourceforge.net/
Plex86: http://www.plex86.org/
VMware: http://www.vmware.com/
User-Mode Linux: http://user-mode-linux.sourceforge.net/
Эмуляторы операционных систем
Кроссплатформенные библиотеки всего лишь предоставляют механизм для запуска программ. Эмулятор операционной системы намного сложнее, потому что он должен эмулировать все процессы и функции операционной системы.
Эмуляторы Windows:
WINE: http://www.winehq.com/
Win4Lin: http://www.netraverse.com/
CrossOver Office: http://www.codeweavers.com/
Эту таблицу можно использовать
"Корона" [caron] -- это перевернутый значок ^ над буквой.
Острое ударение [Acute] -- это маленький штрих на подобие косой черты / над буквой (ú, обозначается uacute).
Диаерезис [diaeresis] (умляут) -- две точки .. над буквой.
Верхняя точка [dot] -- точка над буквой (как в zdot ż).
Рисунок объяснит лучше:
Если Вы хотите построть файл Xmodmap с кодовой таблицей ISO8859-1 для немецкой или датской раскладки, то придется выяснить правильные имена для необходимых символов, если Вы с ними не знакомы.
Символьные примитивы [entities] в правой колонке нужны в Xmodmap для определения восточно-европейской клавиатурной раскладки.
| Центрально-европейские символы | |
| Название символа | Обозначение SGML и Xmodmap |
Неразрывный пробел
NON-BREAKING SPACE
CURRENCY SIGN
BROKEN BAR
SECTION SIGN
DIAERESIS
COPYRIGHT SIGN
LEFT-POINTING DOUBLE ANGLE QUOTATION MARK
NOT SIGN
SOFT HYPHEN
REGISTERED SIGN
DEGREE SIGN
PLUS-MINUS SIGN
ACUTE ACCENT
MICRO SIGN
PILCROW SIGN
MIDDLE DOT
CEDILLA
RIGHT-POINTING DOUBLE ANGLE QUOTATION MARK
LATIN CAPITAL LETTER A WITH ACUTE
LATIN CAPITAL LETTER A WITH CIRCUMFLEX
LATIN CAPITAL LETTER A WITH DIAERESIS
LATIN CAPITAL LETTER C WITH CEDILLA
LATIN CAPITAL LETTER E WITH ACUTE
LATIN CAPITAL LETTER E WITH DIAERESIS
LATIN CAPITAL LETTER I WITH ACUTE
LATIN CAPITAL LETTER I WITH CIRCUMFLEX
LATIN CAPITAL LETTER O WITH ACUTE
LATIN CAPITAL LETTER O WITH CIRCUMFLEX
LATIN CAPITAL LETTER O WITH DIAERESIS
MULTIPLICATION SIGN
LATIN CAPITAL LETTER U WITH ACUTE
LATIN CAPITAL LETTER U WITH DIAERESIS
LATIN CAPITAL LETTER Y WITH ACUTE
LATIN SMALL LETTER SHARP S
LATIN SMALL LETTER A WITH ACUTE
LATIN SMALL LETTER A WITH CIRCUMFLEX
LATIN SMALL LETTER A WITH DIAERESIS
LATIN SMALL LETTER C WITH CEDILLA
LATIN SMALL LETTER E WITH ACUTE
LATIN SMALL LETTER E WITH DIAERESIS
LATIN SMALL LETTER I WITH ACUTE
LATIN SMALL LETTER I WITH CIRCUMFLEX
LATIN SMALL LETTER O WITH ACUTE
LATIN SMALL LETTER O WITH CIRCUMFLEX
LATIN SMALL LETTER O WITH DIAERESIS
DIVISION SIGN
LATIN SMALL LETTER U WITH ACUTE
LATIN SMALL LETTER U WITH DIAERESIS
LATIN SMALL LETTER Y WITH ACUTE
LATIN CAPITAL LETTER A WITH BREVE
LATIN SMALL LETTER A WITH BREVE
LATIN CAPITAL LETTER A WITH OGONEK
LATIN SMALL LETTER A WITH OGONEK
LATIN CAPITAL LETTER C WITH ACUTE
LATIN SMALL LETTER C WITH ACUTE
LATIN CAPITAL LETTER C WITH CARON
LATIN SMALL LETTER C WITH CARON
LATIN CAPITAL LETTER D WITH CARON
LATIN SMALL LETTER D WITH CARON
LATIN CAPITAL LETTER D WITH STROKE
LATIN SMALL LETTER D WITH STROKE
LATIN CAPITAL LETTER E WITH OGONEK
LATIN SMALL LETTER E WITH OGONEK
LATIN CAPITAL LETTER E WITH CARON
LATIN SMALL LETTER E WITH CARON
LATIN CAPITAL LETTER L WITH ACUTE
LATIN SMALL LETTER L WITH ACUTE
LATIN CAPITAL LETTER L WITH CARON
LATIN SMALL LETTER L WITH CARON
LATIN CAPITAL LETTER L WITH STROKE
LATIN SMALL LETTER L WITH STROKE
LATIN CAPITAL LETTER N WITH ACUTE
LATIN SMALL LETTER N WITH ACUTE
LATIN CAPITAL LETTER N WITH CARON
LATIN SMALL LETTER N WITH CARON
LATIN CAPITAL LETTER O WITH DOUBLE ACUTE
LATIN SMALL LETTER O WITH DOUBLE ACUTE
LATIN CAPITAL LETTER R WITH ACUTE
LATIN SMALL LETTER R WITH ACUTE
LATIN CAPITAL LETTER R WITH CARON
LATIN SMALL LETTER R WITH CARON
LATIN CAPITAL LETTER S WITH ACUTE
LATIN SMALL LETTER S WITH ACUTE
LATIN CAPITAL LETTER S WITH CEDILLA
LATIN SMALL LETTER S WITH CEDILLA
LATIN CAPITAL LETTER S WITH CARON
LATIN SMALL LETTER S WITH CARON
LATIN CAPITAL LETTER T WITH CEDILLA
LATIN SMALL LETTER T WITH CEDILLA
LATIN CAPITAL LETTER T WITH CARON
LATIN SMALL LETTER T WITH CARON
LATIN CAPITAL LETTER U WITH RING ABOVE
LATIN SMALL LETTER U WITH RING ABOVE
LATIN CAPITAL LETTER U WITH DOUBLE ACUTE
LATIN SMALL LETTER U WITH DOUBLE ACUTE
LATIN CAPITAL LETTER Z WITH ACUTE
LATIN SMALL LETTER Z WITH ACUTE
LATIN CAPITAL LETTER Z WITH DOT ABOVE
LATIN SMALL LETTER Z WITH DOT ABOVE
LATIN CAPITAL LETTER Z WITH CARON
LATIN SMALL LETTER Z WITH CARON
CARON
BREVE
DOT ABOVE
OGONEK
DOUBLE ACUTE ACCENT
Jurnalfs
 |
|
.gif) |
|
| Журналируемые файловые системы для GNU/Linux: мифы и реальность |
|
|
Первый и единственный миф - что журналируемые файловые системы спасут вас и ваши данные от любого сбоя. Нет, не спасут. Они просто предназначены для другого. [Олег Бройтман ] 24 сентября 2001 состоялось третье заседание семинара. Александр Боковой прочел лекцию "Журналируемые файловые системы. Мифы и реальность". Лекция была отличная. Александр и выглядит хорошо, и умеет говорить, он не суетился возле доски, и вообще поднял планку лекций семинара на такую высоту, что следующим лекторам придется попотеть, чтобы допрыгнуть. :) Александр рассмотрел 4 наиболее известные файловые системы - ReiserFS, JFS, XFS и ext3 - однако не вообще, а применительно к конкретной задаче - создание высокопроизводительного надежного файлового сервера. Александр не назвал лучшую, и я не назову - сначала дайте критерии "лучшести". Как будет видно ниже, по разным критериям лучшие бывают разные. Мифов же уважаемый лектор развеял немного. Первый и единственный миф - что журналируемые файловые системы спасут вас и ваши данные от любого сбоя. Нет, не спасут. Они просто предназначены для другого. Вот, скажем, сценарий. Вы открываете файл, и пишете в него большой объем данных. В середине записи происходит сбой, перезагрузка, и после восстановления файл оказывается пустой. Нулевой длины. Как же так, говорите вы, а где же то, что я туда писал? Ответ такой - журналируемые файловые системы ТАК не работают. Они предназначены не для восстановления всех ваших данных любой ценой, а для поддержания непротиворечивости метаданных файловой системы на момент сбоя. Поэтому такая система работает так: вы открываете файл - и он успешно открывается, файловая система отмечает открытие в своем журнале записью транзакции. Затем вы начинаете писать. Но файловая система не запоминает копии этих данных. И когда происходит восстановление после сбоя, происходит откат до последней успешной транзакции - открытия нового пустого файла. Следующие общие слова Александр сказал об алгоритмах журналируемых файловых систем. Большинство из них построено на основе сбалансированных деревьев, иначе известных как B+ деревья. Из четырех рассмотренных файловых систем 3 используют сбалансированные деревья. Второй способ оптимизации журналируемой файловой системы - вынесение журнала на другое независимое устройство (для асинхронного доступа). Это увеличивает эффективность системы на 30-50%! Не все из рассмотренных систем имеют вынос журнала. XFS имеет, для ReiserFS нужен особый патч. В основной части лекции Александр рассказал подробности о каждой из файловых систем. XFS была создана в начале 90-ых (1992-1993) фирмой Silicon Grapgics (сейчас SGI) для мультимедийных компьютеров с ОС Irix. Файловая система была ориентирована на очень большие файлы и файловые системы. Особенностью этой файловой системы является устройство журнала - в журнал пишется часть метаданных самой файловой системы таким образом, что весь процесс восстановления сводится к копированию этих данных из журнала в файловую систему. Размер журнала задается при создании системы, он должен быть не меньше 32 мегабайт; а больше и не надо - такое количество незакрытых транзакций тяжело получить. JFS, журналируемая файловая система фирмы IBM, была создана для ОС AIX. В дальнейшем была перенесена на OS/2, но проявила себя там очень вяло. Нынешняя ее версия для Linux и то лучше. Размер журнала - примерно 40% от объема файловой системы, но не больше 32 мегабайт. Особенностью этой файловой системы являются "агрегаты" - в этой файловой системе может быть несколько сегментов, включающих журнал и данные, и каждый из таких сегментов можно монтировать отдельно. Проект ReiserFS тоже начинался в 90-ых годах, первый прототип носил название TreeFS. Разработчики системы мечтают создать не только файловую систему, но вообще механизм иерархического именования объектов. Уже есть патчи, интегрирующие Squid с ReiserFS, аналогичный проект начался для qmail. В этом смысле работа Ханса Райзера с коллегами уникальна, потому что они ведут научные исследования, и воплощают результаты в свободный код! И, наконец, ext3. Это журналируемая надстройка над ext2. Достоинство ее в том, что она не меняет внутренние структуры ext2. Файловую систему ext3 можно создать из ext2 просто запустив программу создания журнала. Впоследствии эту файловую систему можно опять подмонтировать драйвером ext2. А потом опять драйвером ext3, и создать журнал. Во второй части лекции Александр показал кучу графиков сравнения производительности 4-ех описанных файловых систем. Сравнение проводилось с помощью стандартного теста NetBench, точнее, как стало понятно из лекции чуть позже, с помощью его свободного аналога DBench. NetBench - это распределенный клиент, который с сотни виндовых машин дает нагрузку на файловый сервер - создает, переименовывает, пишет и читает файлы, всего около 90 тысяч транзакций. DBench создан Эндрю Триджелом, автором Самбы, еще когда он работал в SGI, и у него была возможность использовать сотню виндовых машин. DBench не является, как я понял, распределенным клиентом, а эмулирует NetBench на одной машине, но отклонение от результатов NetBench составляет 1%. Вполне приемлемо. DBench был создан так - через сервер с Самбой прогнали NetBench, и Самба все операции записала в лог. Вот этим-то DBench'ем Александр нагрузил файловые сервера, создавая нагрузку, эквивалентную нагрузке NetBench от 1 до 25 клиентов. Результаты были представлены в виде графиков падения производительности на 1 клиента в зависимости от числа клиентов. Тестирование проводилось на сервер самой обычной конфигурации - Celeron 800Mhz, 256M памяти, 4 независимых IDE-контроллера; на одном Linux, на другом тестируемая файловая система, на третьем журнал (в тех FS, которые позволяют вынести журнал), один запасной. Я не буду пытаться воспроизвести эти графики здесь, возможно, Александр опубликует их отдельно. Приведу лишь общие выводы. Вывод номер один, самый главный: на таком железе (даже не Pentium4) файловые системы обладают такой высокой производительностью, что забивают 100-мегабитную сеть. То есть для того, чтобы выйти на предел, уже надо было бы иметь гигабитный ethernet. Теперь по отдельным файловым системам. Слабее всех проявила себя JFS. Ее производительность с самого начала невысокая, и падает она быстро. Зато ее падение производительности очень гладкое; тем, кому важна не только производительность, но и предсказуемость поведения, это важно. Лучше себя ведет XFS. Ее производительность на 1 клиенте выше, и падает медленнее. А при вынесении журнала на независимый контроллер ее производительность сильно улучшается, и она приближается к топовым показателям. Про XFS следует отметить, что она разрабатывалась как файловая система для больших файлов, а NetBench выполняет операции с небольшими, поэтому можно предполагать, что на реальных файловых серверах XFS будет вести себя еще лучше. К тому же у этой FS тоже очень гладкий график падения производительности. ReiserFS показал еще лучшую производительность, но зато у него негладкое падение. Где-то в районе 12-15 клиентов график начинает скакать вверх и вниз довольно резко (на вопрос из зала, воспроизводимо ли такое поведение, или это ошибка эксперимента, Александр ответил, что графики эти выверены, и все скачки воспроизводимы). После 15 клиентов график становится более гладким, возможно, за счет приближения к полной загрузке сети, а не файлового сервера. Графики ext3 до такой степени мало отличаются от ResierFS, что на сводном графике и не увидишь разницы. Особой проблемой является то, что во время интенсивной записи на диск файловые системы постоянно перебалансируют свои B+ деревья. Загрузка процессора при использовании XFS достигает 90%. ReiserFS дает 70%, потому что оптимизирует порядок операций. Другая оптимизация ReiserFS - она может упаковывать несколько маленьких файлов в один дисковый блок, а совсем маленькие - просто записать в inode :) Что касается стабильности, то наиболее устойчивой оказалась ReiserFS, которую Александр назвал рабочей лошадкой, на которую вполне можно положиться. Во время лекции и после нее возникло пара вопросов о совместимости журналируемых файловых систем с сетевыми. То есть можно ли поверх ReiserFS поставить NFS, или поверх XFS - Coda. Не все хорошо оказалось в этой области, но подвижки есть. Лучше всего должны быть совместимы Coda и ext3 - у них один автор Peter Braam. :)
[ опубликовано 24/10/2001 ] | ||
|
|
Как добавить юзера?
Ответ на этот вопрос не такой простой, как может показаться. Все зависит от того - какого юзера вы хотите зарегистрировать. (О том, какие типы юзеров могут встретиться смотри - "Для чего используется учетная карточка" ).
Заметьте, что, для того, чтобы пустить в свою систему реального юзера, надо не только добавить новую учетную карточку для него. Еще надо создать ему домашнюю директорию и, желательно, положить туда некоторые стартовые файлы (типа config.sys и autoexec.bat в DOS'е). При этом надо правильно установить права нового юзера на эти файлы.
Для того, чтобы не делать эту работу вручную, существует специальная утилита (см. ниже). Но, если вам нужно зарегистрировать псевдо-юзера или "почтового юзера", она не очень подходит. В этом случае лучше воспользоваться более примитивными средствами.
Итак. Программы для регистрации (и не только) нового пользователя.
pwd_mkdb
vipw
adduser
pw useradd
Еще что-нибудь
Как достигается "взаимопонимание" программ с терминалом (termcap, terminfo и переменная TERM)
Если в операционной системе Юникс для ввода/вывода можно использовать множество различных терминалов, отличающихся и размером экрана (количество строк и символов в строке), и командами управления экраном, и кодами, которые генерируют клавиши и т.п., то как же одна и та же программа может работать со всем этим "зоопарком"?
Вообще-то, этот вопрос выходит за рамки описания драйвера syscons. Но, поскольку некоторые настройки syscons превращают его в "немного другой" терминал (меняют количество строк на экране, коды, выдаваемые "функциональными" клавишами, и набор символов), то рассмотрим его хотя бы вкратце.
termcap
Переменная окружения TERM
"Баги" в termcap
terminfo
Как изменяются права доступа при копировании и перемещении файла
Этот вопрос на самом деле более сложный, чем может показаться.
Дело в том, что ответ на него зависит от многих условий
кто копирует (перемещает) файлы, root или обычный юзер какие программы и с какими ключами при этом используются копируется файл "на пустое место" или там уже существует файл с таким именем
Тем не менее, попробуем найти несколько общих правил, определяющих - какие права доступа могут получится в результат.
Во-первых, при копировании (например, командой cp) создается новый файл, а при перемещении (например, командой mv) меняется только место расположения файла (и, возможно, имя).
Поэтому, если "рядовой юзер" копирует файл, то действуют все те же правила, что и при создании файла. То есть, владельцем копии становится юзер, который ее создал, группа "наследуется" от директории, а сами права доступа определяются параметром umask.
Строго говоря, если копирование делает root, то эти правила действуют и для него (то есть, владельцем полученной копии будет root, группа будет взята от директории, а права выставятся в соответствии с umask). Однако, root может изменить поведение команды cp. У этой команды есть ключ (-p - сохранять permissions) который означает, что надо сохранить все атрибуты (владельца, группу и permissions) при копировании.
Обычный же юзер, даже используя ключ -p не сможет сохранить владельца и группу, но получит permissions такие же как у оригинального файла. К тому же биты suid и sgid при этом также "сбрасываются".
Существует еще одна ситуация, когда при копировании сохраняются все атрибуты доступа. Это происходит, когда в "месте назначения" файл с таким именем уже существует. Собственно, в этом случае файл не создается, а только замещается его содержимое. Поэтому, даже если эту операцию проделает обычный юзер (естественно, для этого надо, чтобы ему было разрешено писать в существующий файл), все атрибуты, в том числе владелец и группа сохранятся. Правда, биты suid и sgid все равно "сбросятся".
А вот при перемещении файла все атрибуты сохраняются (даже "опасные" биты suid и sgid). Однако, не забудьте, что для того, чтобы обычный юзер смог переместить чужой файл, он должен иметь право записи и в ту директорию, куда файл переносится и в ту, откуда он переносится (поскольку, там запись о файле должна быть удалена). Такие ситуации в нормальной системе, как правило, не встречаются.
Иван Паскаль pascal@tsu.ru
Как это можно сделать?
Вариант первый - "выделенные скан-коды".
Вариант второй - "перекрытия".
Прежде всего, хочу заметить, что я не могу предложить вам раскладку с четырьмя группами (откуда я знаю - что вы в них хотите "вложить").
Но если вам надо только поэкспериментировать, можно взять одну из кнопок (не обязательно "буквенную") и "навесить" на нее четыре группы.
Я сделал такую кнопку из клавиши "1".
key <AE01> { [ 1, exclam ], [ 2, exclam ], [ 3, exclam ], [ 4, exclam ] };
(значение клавиши отражает текущий номер группы :-).
Итак.
Как Linux работает с памятью
Случилось мне однажды поинтересоваться как же ядро работает с самым дорогим что у него есть, с памятью. Первые попытки разобраться с налету что и как ни к чему не привели. Не все так просто как хотелось бы. Отовсюду торчат концы, вроде все ясно, но как связать их воедино...
Возникла мысль обратиться к прошлому , чтобы по крайней мере разобраться как все это развивалось (версия 0.1). Это помогло понять и современное ядро. В дальнейшем речь пойдет о ядрах серии 2.2 об изменениях в 2.4 будет сообщено особо.
Не буду углубляться в тонкости функционирования защищенного режима процессора об этом написаны целые фолианты. Посмотрим только самую суть.
Итак, в овнове всего лежат страницы памяти. В ядре они описываются структурой mem_map_t.
typedef struct page {
/* these must be first (free area handling) */
struct page *next;
struct page *prev;
struct inode *inode;
unsigned long offset;
struct page *next_hash;
atomic_t count;
unsigned long flags; /* atomic flags, some possibly updated asynchronously */
struct wait_queue *wait;
struct page **pprev_hash;
struct buffer_head * buffers;
} mem_map_t;
Уже тут наблюдается наворороченность. Множество всяких ссылок. Все они используются . Одна страница может находиться в разных списках , например и всписке страниц в страничном кеше и в списке страниц относящихся к отображенному в память файлу (inode).В структуре описывающей последний можно найти и обратную ссылку,что очень удобно.
Все страницы адресуются глобальным указателем mem_map
mem_map_t * mem_map
Адресация страниц порисходит очень хитро. Если раньше в структуре page было отдельное поле указывающее на физический адрес (map_nr), то теперь он вычисляется
static inline unsigned long page_address(struct page * page)
{
return PAGE_OFFSET + PAGE_SIZE * (page - mem_map);
}
Свободные страницы хранятся в особой структуре free_area
static struct free_area_struct free_area[NR_MEM_TYPES][NR_MEM_LISTS];
, где первое поле отвечает за тип области : Ядра, Пользователя, DMA и.т.д. И обрабатываются по очень хитрому алгоритму.
Страницы делятся на свободные непрерывные обрасти размера 2 в степени x умноженной на размер страницы ( (2^x)*PAGE_SIZE ). Области одного размера лежат в одной области массива.
....
|------
|Свободные Страницы размера PAGE_SIZE*4 ---> список свободных областей
|------
|Свободные Страницы размера PAGE_SIZE*2 ---> список свободных областей
|------
|Свободные Страницы размера PAGE_SIZE ---> список свободных областей
|------
Выделяет страницу функция get_free_pages(order). Она выделяет страницы составляющие область размера PAGE_SIZE*(2^order). Ищется область соответствующего размера или больше. Если есть только область большего размера то она делится на несколько маленьких и берется нужный кусок. Если свободных страниц недостаточно, то некоторые будут сброшены в область подкачки и процесс выделенения начнется снова.
Возвращает страницу функция free_pages(struct page, order). Высвобождает страницы начинающиеся с page размера PAGE_SIZE*(2^order). Область возвращается в массив свободных обрастей в соответствующую позицию и после этого происходит попытка объединить несколько областей для создания одной большего размера.
Отсутствие страницы в памяти обрабатыватся ядром особо. Страница может или вообще отсутствовать или находиться в области подкачки.
Вот собственно и вся базовая работа с реальными страницами.Самое время вспомнить, что процесс работает все-каки с виртуальными адресами, а не с физическими. Преобразование происходит посредством вичислений, используя таблицы дескрипторов, и каталоги таблиц. Linux поддерживает 3 уровня таблиц: каталог таблиц первого уровня (PGD - Page Table Directory),каталог таблиц второго уровня (PMD - Medium Page Table Diractory), и наконец таблица дескрипторов (PTE - Page Table Entry). Реально конкректным процессором могут поддерживаться не все уровни, но запас позволяет поддерживать больше возможных архитектур (Intel имеет 2 уровня таблиц, а Alpha - целых 3 ). Преобразование виртуального адреса в физический происходит соответственно в 3 этапа. Берется указатель PGD, имеющийся в структуре описывающий каждый процесс, преобразуется в указатель записи PMD, а последний преобразуется в указатель в таблице дескрипторов PTE. И наконец к реальному адресу указывающему на начало страницы прибавляют смещение от ее начала.
page_dir = pgd_offset(vma->vm_mm, address);
if (pgd_none(*page_dir))
return;
if (pgd_bad(*page_dir)) {
printk("bad page table directory entry %p:[%lx]\n", page_dir, pgd_val(*page_dir));
pgd_clear(page_dir);
return;
}
page_middle = pmd_offset(page_dir, address);
if (pmd_none(*page_middle))
return;
if (pmd_bad(*page_middle)) {
printk("bad page table directory entry %p:[%lx]\n", page_dir, pgd_val(*page_dir));
pmd_clear(page_middle);
return;
}
page_table = pte_offset(page_middle, address);
Вообще-то все данные об используемой процессом памяти помещаются в структуре mm_struct
struct mm_struct {
struct vm_area_struct *mmap; /* Список отображенных областей */
struct vm_area_struct *mmap_avl; /* Те же области но уже в виде дерева для более быстрого поиска*/
struct vm_area_struct *mmap_cache; /* Последняя найденная область*/
pgd_t * pgd; /*Каталог таблиц*/
atomic_t count;
int map_count; /* Количество областей*/
struct semaphore mmap_sem;
unsigned long context;
unsigned long start_code, end_code, start_data, end_data;
unsigned long start_brk, brk, start_stack;
unsigned long arg_start, arg_end, env_start, env_end;
unsigned long rss, total_vm, locked_vm;
unsigned long def_flags;
unsigned long cpu_vm_mask;
unsigned long swap_cnt; /* number of pages to swap on next pass */
unsigned long swap_address;
/*
* This is an architecture-specific pointer: the portable
* part of Linux does not know about any segments.
*/
void * segments;
};
Сразу замечаем, что помимо вполне понятных указателей на начало данных (start_code, end_code ...) кода и стека есть указатели на данные отображенных файлов (mmap). Это надо сказать особенность Linux - тащить в себя все что только можно. Может быть это и хорошо, но с другой стороны так разбазариваться памятью (вспомним еще буфера ввода/вывода при файловой системе, которые тоже будут кушать все новую память пока она есть) Данный подход может негативно отразиться на стабильности системы, ведь для запуска какого-то жизненно необходимого процесса может потребоваться время на освобождение лишних кешей. Простенькая проверка на потерю свободной памяти: введите команду "cat /dev/mem >/image " и посмотрите сколько свободной памяти после этого осталось. Если вам это не нравится, то обратите взгляд на функцию invalidate_inode_pages(* struct_inode), освобождающую страничный кэш для данного файла.
При любом открытии файла, он сразу же отображается в память и добавляется в страничный кэш. Реальный же запрос на отображение файла только возвращает адрес на уже скешированные страницы.
На уровне процесса работа может вестить как со страницами напямую, так и через абстрактную структуру vm_area_struct
struct vm_area_struct {
struct mm_struct * vm_mm; /* VM area parameters */
unsigned long vm_start;
unsigned long vm_end;
/* linked list of VM areas per task, sorted by address */
struct vm_area_struct *vm_next;
pgprot_t vm_page_prot;
unsigned short vm_flags;
/* AVL tree of VM areas per task, sorted by address */
short vm_avl_height;
struct vm_area_struct * vm_avl_left;
struct vm_area_struct * vm_avl_right;
/* For areas with inode, the list inode->i_mmap, for shm areas,
* the list of attaches, otherwise unused.
*/
struct vm_area_struct *vm_next_share;
struct vm_area_struct **vm_pprev_share;
struct vm_operations_struct * vm_ops;
unsigned long vm_offset;
struct file * vm_file;
unsigned long vm_pte; /* shared mem */
};
struct vm_operations_struct {
void (*open)(struct vm_area_struct * area);
void (*close)(struct vm_area_struct * area);
void (*unmap)(struct vm_area_struct *area, unsigned long, size_t);
void (*protect)(struct vm_area_struct *area, unsigned long, size_t, unsigned int newprot);
int (*sync)(struct vm_area_struct *area, unsigned long, size_t, unsigned int flags);
void (*advise)(struct vm_area_struct *area, unsigned long, size_t, unsigned int advise);
unsigned long (*nopage)(struct vm_area_struct * area, unsigned long address, int write_access);
unsigned long (*wppage)(struct vm_area_struct * area, unsigned long address,
unsigned long page);
int (*swapout)(struct vm_area_struct *, struct page *);
pte_t (*swapin)(struct vm_area_struct *, unsigned long, unsigned long);
};
Идея данной структуры возникла из идеи виртуальной файловой системы, поэтому все операции над виртуальными областями абстрактны и могут быть специфичными для разных типов памяти, например при отображении файлов операции чтения одни а при отображении памяти (через файл /dev/mem ) совершенно другие. Первоначально vm_area_struct появилась для обеспечения нужд отображения, но постепенно распространяется и на другие области.
Что делать, когда требуется получить новую область памяти. Есть целых 3 способа.
1. Уже знакомый get_free_page()
2. kmalloc - Простенькая (по возможностям, но отнюдь не коду) процедура с большими ограничениями по выделению новых областей и по их размеру.
3. vmalloc - Мощная процедура, работающая с виртуальной памятью, может выделять большие объемы памяти.
С каждой из двух процедур в ядре связаны еще по списку свободных/занятых областей, что еще больше усложняет понимание работы с памятью. (vmlist для vmalloc, kmem_cash для kmalloc)
Что же в 2.4.
Добавлена поддержка новой архитектуры памяти NUMA. В противовес классической UMA память делится на зоны с разным временем доступа к каждой из них . Это очень полезно и для кластерных решений. В связи с этим появились новые обертки на функции и найти суть стало еще сложнее. Появилась также поддержка памяти до 64Гб.
Раньше для всех файловых систем был один generic_file_read и generic_file_mmap в связи с тотальным засасыванием всего подряд в память при чтении (различия делались уже только на уровне inode->readpage). Теперь появился и generic_file_write. В общем еще пара таких generic и прощай виртуальная файловая система.
Но посмотрим - увидим. Ведь Linux развивается очень быстро и не всегда предсказуемо.
Stanislav Ievlev.
inger@linux.ru.net
Как мы боролись (скорее "как мы напоролись" -- примред)
На Fish XFree работает от root'а, но не работает под правами обычных пользователей.
Причины: проблема либо с привилегиями, либо с пользовательскими конфигурационными файлами.
Решение: добавим нового пользователя[*1] и скопируем файлы настроек root'а в его домашний каталог:
root@fish# adduser judas
Enter new UNIX password:
Retype new UNIX password:
root@fish# cp --recursive /root/.[a-zA-Z]* /home/judas
root@fish# chown --recursive judas:judas /home/judas/.*
[Вы заметили разницу в регулярном выражении команд cp и chown?]
(Классическая ошибка использования регулярных выражений: следует помнить, что под шаблон .* подходит выражение "..", т.е. родительский каталог. Потому будьте осторожны с командой rm -rf /bla-bla/.* - можете остаться без корневого каталога - Прим.пер.) (И с дикой головной болью -- прим.ред.)
После длительной охоты на ошибки, проблема с иксами, наконец, решена; подошло время удалять пользователя. Что бы как-то ускорить процедуру, изучаем страницу руководства. Это приводит к обнаружению привлекательного ключа:
root@fish# deluser --remove-all-files judas
Ба-бах! Приехали! Данный ключ указывает команде deluser провести поиск по диску файлов, владельцем которых является judas и удалить их!
Содержимое каталога /home исчезло.
Две минуты спустя мы размонтировали соответствующее устройство (/dev/sda8).
Как обойтись без прав root'а Часть
Автор: Станислав Лапшанский, slapsh@slapsh.pp.ru
Опубликовано: 19.11.2002
© 2002, Издательский дом «КОМПЬЮТЕРРА» | http://www.computerra.ru/
Журнал «СОФТЕРРА» | http://www.softerra.ru/
Этот материал Вы всегда сможете найти по его постоянному адресу: http://www.softerra.ru/freeos/21799/
Эта статья является переводом текста Майкла Лукаса (Michael Lucas).
Правильная реализация системы безопасности на основе групп помогает резко уменьшить необходимость в применении пароля суперпользователя, однако, несмотря на это, время от времени пользователям все же необходимо выполнять команды с правами какого-нибудь другого пользователя (обычно это суперпользователь). Так как вы являетесь системным администратором, вам часто приходится стоять перед нелегким выбором, или постоянно выполнять просьбы ваших пользователей, или раздать всем желающим суперпользовательский пароль. Утилита sudo позволит разрубить вам этот гордиев узел, предоставляя третий, более рациональный путь. Впрочем, не следует забывать, что это довольно тонкая программа, требующая аккуратности при ее конфигурировании. sudo непосредственно интегрирована в OpenBSD, но с таким же успехом может быть установлена почти в любой версии UNIX в качестве стороннего приложения.
Утилита sudo является программой-посредником с установленным битом setuid, выполняющейся с привилегиями суперпользователя. Она позволяет установить гибкие правила доступа к программам, для запуска которых требуются административные полномочия. sudo получает от пользователя команду, затем сравнивает ее с внутренним списков разрешенных команд. Если пользователь имеет право на исполнение поданной команды, sudo немедленно ее выполняет. Поскольку суперпользователь может запускать программы от имени любого пользователя, sudo так же может выполнять команды от имени какого угодно наперед заданного пользователя.
При соответствующей настройке, системный администратор может позволить любому пользователю выполнять любые программы от имени любого другого пользователя. sudo очень мощная утилита, с ее помощью можно разрешить или запретить практически любой набор команд. Как результат такой гибкости, документация sudo, отпугивает новичков своей сложностью. Мы займемся конфигурированием sudo, на уровне, которого вполне должно хватить для большинства пользователей, однако вам следует помнить, что существует большое количество различных дополнительных параметров конфигурирования, которые описаны в руководстве sudo (8) и sudoers (5).
Преимущества от использования sudo не ограничиваются предоставлением четкой системы разграничения доступа. Одним из важнейших преимуществ является журналирование выполняемых пользователями команд. Каждая команда выполняемая sudo, записывается в журнал, что чрезвычайно упрощает выяснение того, кто, что и когда изменял. Кроме того, когда вы корректно настроите sudo, вы наконец сможете поменять суперпользовательский пароль и никогда больше никому его не давать. Более того, если вы все правильно настроите, то суперпользовательский пароль вообще никому не потребуется. Сокращение количества людей, знающих пароль суперпользователя ведет к увеличению защищенности вашей системы. И наконец, один и тот же конфигурационный файл программы sudo может применяться на всех ваших серверах, тем самым значительно сокращая временные затраты на администрирование системы.
Наиболее серьезным «недостатком» sudo является, чрезвычайно негативное отношение к ней пользователей и младших администраторов. Так как люди традиционно пользовались суперпользовательским паролем для выполнения своих действий, они подозревают, что при установке в систему sudo они потеряют некоторые прежде доступные им возможности. Для преодоления такого отношения к sudo, вы, в первую очередь должны будете удостовериться, что пользователи с ее помощью смогут выполнять свою работу в полном объеме. Если пользователи уверяют вас, что им требуется суперпользовательский пароль для выполнения других задач, то вы должны просто разобраться кто и за что отвечает. Вероятно такие пользователи брали на себя решение несвойственных им задач, вместо того, что бы озаботить ими вас.
Неправильная настройка sudo может привести к появлению «дыр» в безопасности системы. Бездумное конфигурирование может привести к тому, что сообразительный пользователь сможет «незаконно» получить права суперпользователя. Эта проблема разрешается при помощи внимательного конфигурирования и соблюдения административной политики.
Система sudo состоит из трех частей. Во-первых, это сама программа sudo (8) – программа-посредник с установленным setuid-битом, с которой непосредственно взаимодействуют пользователи. Во-вторых это конфигурационный файл sudo /etc/sudoers. Этот файл содержит таблицу прав доступа, в которой указывается кому и какие команды позволено запускать от имени какого пользователя. Его структура полностью описана в руководстве man 5 sudoers. И наконец команда visudo, которая позволяет администраторам редактировать файл sudoers без риска заблокировать себе вход в систему. Мы рассмотрим каждый компонент по очереди: visudo, sudoers и sudo.
Если файл sudoers имеет неправильный синтаксис, sudo просто не запустится. Если вы понадеетесь на sudo (имеется в виду случай, когда вы полностью отказались от использования суперпользовательского аккаунта «забыв» его пароль – прим. переводчика), предоставите через него доступ к файлу sudoers и при этом это файл испортите, то вы тем самым заблокируете доступ к любым действиям требующим прав суперпользователя и, к тому же, не сможете ничего исправить. Это плохо. Программа visudo (8) призвана обеспечить определенную защиту от подобных ситуаций.
Подобно утилите vipw (8), visudo (8) блокирует редактируемый файл для того чтобы в один момент времени его мог редактировать только одни человек. visudo открывает конфигурационный файл sudoers в редакторе (по умолчанию это редактор vi (1), однако такое поведение системы можно изменить, поменяв содержимое переменной $EDITOR). Когда вы покидаете редактор, visudo проверяет отредактированный файл на наличие синтаксических ошибок, о которых сообщает пользователю. Разумеется такая проверка не дает гарантии того, что конфигурационный файл будет таким как вы хотите, она просто подтверждает его синтаксическую корректность. Например утилита visudo (8) не моргнув глазом примет конфигурационный файл, в котором «никто при помощи sudo сможет сделать «ничего», если этот файл имеет правильный синтаксис.
Если программа visudo найдет в отредактированном файле ошибку, она выдаст на терминал номер строки в которой встретилась ошибка и спросит вас, что теперь делать: # visudo >>> sudoers file: syntax error, line 44 <<< What now?
В данном случае в 44 строке мы допустили ошибку. Есть три варианта действий: вернуться к редактированию, выйти не сохраняя сделанных изменений или заставить visudo сохранить файл sudoers, несмотря на найденные ошибки.
При нажатии клавиши «e», visudo вернет вас в режим редактирования, где вы сможете попытаться исправить обнаруженную ошибку.
Если нажать на «x», visudo завершится и возвратит конфигурационный файл в состояние, в котором он был до начала редактирования. Сделанные вами изменения будут потеряны, но возможно это именно то, что нужно в такой ситуации, поскольку лучше иметь старую, но работающую конфигурацию, чем новую, но неработоспособную.
Клавиша «Q» заставит visudo принять сделанные изменения, несмотря на найденную ошибку. Не забывайте, что если конфигурационный файл содержит ошибку, sudo не запустится. Делая это, вы, в сущности, на некоторое время «выключаете» sudo, до тех пор, пока вы не отредактируете конфигурацию под аккаунтом суперпользователя. В подавляющем большинстве случаев это не то что вам нужно.
Файл sudoers сообщает sudo, кто может выполнять какие команды и от какого пользователя. OpenBSD хранит файл sudoers в каталоге /etc, а FreeBSD в каталоге /usr/local/etc. Никогда не редактируйте этот файл напрямую, даже если вы уверены, что точно знаете, что именно вы хотите изменить. Всегда используйте visudo.
При первом конфигурировании sudo вам может быть вам непонятен синтаксис таблицы прав доступа. Возможно, что сразу сделать все правильно вам не удастся. Однако как только вы поймете каким образом sudo устанавливает эти правила, все станет легко и просто.
Разнообразные примеры файлов sudoers, которые вы можете легко найти в Интернете, часто бывают слишком сложны и запутаны для понимания, но в них можно увидеть все интересные штучки которые предоставляет пользователю sudo. Однако базовый синтаксис очень прост. Каждая запись правил доступа в файле sudoers имеет следующий формат: username host = command
Где username это имя пользователя, который может выполнять команду. Параметр host представляет собой имя машины, для которой применимо соответствующее правило. Таким образом есть возможность устанавливать правила для конкретной машины в сети.
В поле command содержится список команд для которых применимо данное правило. Вы должны указать полный путь для каждой команды, или sudo не будет их распознавать. (Вы ведь не хотите, что бы пользователи могли, просто поменяв переменную $PATH, выполнять совсем другие команды с теми же именами?)
Умолчания принятые в sudo исключают случайности. Для того что бы разрешить пользователю выполнять определенную команду, вы должны написать для этого соответствующее правило. Если хотя бы одно из трех полей не будет соответствовать необходимому значению, пользователь не сможет ничего сделать.
Вы можете использовать ключевое слово «ALL» в любом из трех полей для указания значения подходящего «для всего». Например, предположим, что я полностью доверяю пользователю chris и хочу позволить ему выполнять абсолютно любую команду от имени суперпользователя на любой машине: chris ALL = ALL
Однако давать младшему администратору полный контроль над одной из моих машин не очень разумно. Как главный администратор, я должен знать, какие команды понадобятся Крису для выполнения его работы. Предположим, что Крис администрирует DNS-сервер. К файлам, описывающим зоны сервера имен, доступ ограничивается при помощи групп, но они не смогут нам помочь, когда понадобится стартовать, перезапустить или остановить сервер. Вот как я дал ему права на запуск программы контролирующей демона DNS-сервера: chris ALL = /usr/sbin/ndc
Если я распространю этот файл на несколько машин, есть высокая вероятность, что далеко не на всех из них окажется сервер имен. Вот так я ограничиваю круг машин, на которых Крис сможет запускать управляющую программу, одним компьютером с именем «dns1»: chris dns1 = /usr/bin/ndc
С другой стороны, Крис является еще и администратором машины почтового сервера «mail». Он полностью отвечает за этот сервер, и, поэтому может выполнять на нем любые команды, как ему заблагорассудится. Я могу установить для него совершенно другие права доступа к почтовому серверу и, несмотря на это, использовать один и тот же файл sudoers на обеих машинах: chris dns1 = /usr/bin/ndc chris mail = ALL
Для того что бы указать несколько значений в одном поле, их можно разделять запятыми. Вот как можно разрешить Крису монтировать гибкий диск при помощи команды mount (8) и одновременно позволить управление сервером имен: chris dns1 = /usr/bin/ndc, /bin/mount
В файле sudoers, вы можете указать sudo, что ей необходимо выполнять определенные команды от пользователя отличного от root. Для этого вставьте имя нужного пользователя в скобках перед командой. Допустим, что наш сервер имен выполняется не от имени суперпользователя, а от имени пользователя «named» и все команды для управления им должны запускаться от имени этого пользователя. chris dns1 = (named) /usr/bin/ndc
Каждая запись в файле /etc/sudoers должна занимать одну строку. В связи с этим строки могут быть непомерно длинными. В таком случае вы можете перенести строку на другую воспользовавшись символом «\» в конце строки:
chris server1 = /sbin/fdisk,/sbin/fsck,/sbin/kldload, \
/sbin/newfs,/sbin/newfs_msdos,/sbin/mount
Теперь, когда вы ознакомились, как задаются правила доступа, давайте поглядим, как использовать sudo. Воспользуйтесь visudo, и разрешите своему аккаунту выполнять любую команду. (Если вы смогли установить sudo, значит вы уже обладаете правами суперпользователя и, поэтому то, что вы дали своему аккаунту неограниченные привилегии, не будет дырой в безопасности).
При запуске sudo, во-первых она спросит вас пароль. Введите пароль своего аккаунта (не пароль суперпользователя). Если вы неправильно введете пароль, sudo оскорбит ваши умственные способности или родословную, и предложит ввести пароль еще раз. После третьего раза, sudo отвяжется от вас. Если вы хотите попытаться еще, запустите sudo снова.
Как только вы введете правильный пароль, sudo засечет время. Если вы попытаетесь запустить sudo в течение следующих пяти минут, она не будет запрашивать пароль. После истечения пяти минут, пароль придется вводить как обычно. Это делает жизнь проще в случае, если вам необходимо выполнить сразу несколько команд при помощи sudo, однако помните, что если вы отлучитесь от компьютера пять минут пройдут достаточно быстро.
Если вы простой пользователь и на вашей машине установлена sudo, то весьма вероятно, что вам будет интересен список команд, которые системный администратор счел допустимыми для выполнения вами при помощи sudo. Для вывода этого списка вам пригодится ключ «-l»: # sudo -l Password: User mwlucas may run the following commands on this host: (root) ALL #
Если у вас более серьезные ограничения чем у меня, все они будут выведены на экран.
Для того что бы выполнить команду при помощи sudo, просто поставьте перед ней слово «sudo». Например, вот как можно выполнить команду su при помощи sudo: # sudo su Password: #
Использование sudo для доступа к аккаунту суперпользователя позволяет главному администратору надежно сохранять суперпользовательский пароль. Однако это не всегда полезно, поскольку младшие администраторы при наличии неограниченного sudo-доступа могут поменять пароль суперпользователя. В тоже время это хорошее начало для увеличения безопасности системы и применения sudo для выполнения всех команд.
При помощи sudo вы, так же можете запускать и более сложные команды передавая им все необходимые аргументы. Например, команда «tail -f» прекрасно подходит для просмотра последних сообщений в файле журнала, кроме того, новые записи будут появляться на экране по мере их появления в файле журнала. Просмотр некоторых файлов журналов доступен только для суперпользователя. Журнал программы sudo является отличной кандидатурой на такую роль. Наверняка вы хотите иметь возможность просмотра журналов без необходимости входить под аккаунтом суперпользователя. # sudo tail -f /var/log/authlog openbsd/usr/src/usr.bin/sudo;sudo tail -f /var/log/secure Jul 29 13:24:19 openbsd sudo: mwlucas : TTY=ttyp0 ; PWD=/home/mwlucas ; USER=root ; COMMAND=list Jul 29 13:30:03 openbsd sudo: mwlucas : TTY=ttyp0 ; PWD=/home/mwlucas ; USER=root ; COMMAND=/usr/bin/tail -f /var/log/authlog ...
Если вы обладаете достаточными правами, то вы сможете запускать программы не только от имени суперпользователя, но и от имени любого другого пользователя. Предположим, например, что у нас есть сервер баз данных, для работы с которым команды надо отдавать от имени пользователя под которым выполняется этот сервер. Вы можете указать необходимого пользователя в ключе «-u». Например оператор базы данных имеет привилегии для выполнения программы dump, используемой для резервного копирования: # sudo -u operator dump /dev/sd0s1
Все это замечательно, но как проконтролировать использование sudo?
Сообщения от sudo журналируются в источник LOCAL2. Каждое сообщение содержит время его записи, имя пользователя, каталог, где запускалась sudo и команду, которая была выполнена. Jul 29 11:21:02 openbsd sudo: chris : TTY=ttyp0 ; PWD=/home/chris ; USER=root ; COMMAND=/sbin/mount /dev/fd0 /mnt
При худшем варианте развития событий (если в системе что-то нарушится), вы сможете отследить, что происходило. Например, если одна из моих машин не может корректно перезагрузиться из-за того, что файл /etc/rc.conf испорчен или отсутствует, я могу проверить журнал sudo на предмет операций с этим файлом: Jul 29 11:34:56 openbsd sudo: chris : TTY=ttyp0 ; PWD=/home/chris ; USER=root ; COMMAND=/bin/rm /etc/rc.conf
Если кто-нибудь для запуска команд, воспользовался бы командой «su» или даже «sudo su» вместо «sudo», я не смог бы увидеть что привело к сбою системы. С журналами sudo я всегда могу выяснить кто виноват, как только доберусь до компьютера. Только из-за одного этого sudo стоит установить!
В следующий раз я расскажу о более сложных и интересных опциях конфигурации команды sudo, а так же о распространенных ошибках поджидающих новичков.
Телефон редакции: (095) 232-2261
E-mail редакции: inform@softerra.ru
По вопросам размещения рекламы обращаться к Алене Шагиной по телефону +7 (095) 232-2263 или электронной почте reclama@computerra.ru
Как определяется список "членов" группы?
Каждый юзер должен входить, по крайней мере, в одну группу. Эта группа (точнее ее groupID) прописывается в учетной карточке юзера (user account), в поле groupID (см. Какие данные хранятся в учетной карточке).
А, чтобы тот же юзер стал "членом" еще какой-нибудь группы, его можно записать (его login name) непосредственно в файл /etc/group, в поле "group members" (см. выше), соответствующей группы.
Таким образом, "членами" какой-либо группы являются
юзеры, которые перечисленные в файле /etc/group в "списке юзеров" этой группы и юзеры, в учетной карточке которых, стоит groupID этой группы.
Иван Паскаль pascal@tsu.ru
Как поменять
Владельца и группу.
Команда chown
Команда chgrp
Права доступа (permissions)
Флаги.
Как поменять данные в учетной карточке?
Во-первых, для изменения секретного пароля юзера (поле Password) надо использовать специальную команду
passwd "имя юзера"
поскольку, в учетной карточке пароль хранится в зашифрованном виде и правильно изменить его текстовым редактором невозможно.
Все остальные поля можно поменять с помощью утилиты vipw или chpass. Можно, также, использовать "универсальную" утилиту pw, хотя в данном случае, это, пожалуй, самый неудобный инструмент.
Программа vipw (можете посмотреть о ней также в разделе "Как добавить юзера") позволяет редактировать запись непосредственно в файле master.passwd. Естественно, вы должны представлять себе формат этой записи (об этом можно прочитать в man 5 passwd).
Несколько более удобной является утилита chpass (она же chsh и chfn). Она дает возможность редактировать конкретную учетную карточку юзера, имя которого вы укажете при запуске этой программы. Но, при этом, она выводит какждое поле какрточки в отдельной строке с подсказкой - что какое поле означает.
Login: vasia Password: ..... Uid [#]: 1000 Gid [#]: 1000 ... и т.д.
Особенно, программа chpass полезна, если вы захотите изменить Password change time (дату, когда система предложит юзеру поменять пароль) или Account expiration time (дату, после которой не пускать юзера в систему). Дело в том, что в самой учетной карточке эти даты хранятся в цифровом формате, понятном только самой системе, а chpass показывает и воспринимает их в "человеческом" виде (месяц, день, год).
Программу pw тоже можно использовать для изменения данных в учетной карточке (вообще-то ее удобнее применять для создания/удаления юзеров). Этой программе все данные нужно задавать в командной строке, с помощью соответствующих ключей. Например:
pw usermod vasia -s /bin/csh
запишет в учетную карточку юзера vasia Shell - /bin/csh.
Список всех возможных ключей можно "спросить" у самой программы
pw usermod help
(и, конечно, хорошо бы почитать man pw).
Чтобы не "действовать вслепую" можно посмотреть текущие данные у юзера командой
pw usershow vasia.
Конечно, в данном случае pw usermod менее удобна, чем "полноэкранные" утилиты. Ее использование может быть оправдано только в случае, когда надо сделать много однотипных изменений для нескольких юзеров. Ну, или если вы привыкли ей пользоваться (pw - утилита универсальная для регистрации/просмотра/изменения/удаления юзеров, и во многих случаях может оказаться более удобной, чем остальные).
Заметьте, что vipw вообще не проверяет корректность данных. А chpass и pw usermod проверяют только отдельные поля (и то, иногда отделываются предупреждениями). Ни одна из них не проверяет на уникальность Name и user ID. Поэтому, пользуйтесь ими с осторожностью.
И, наконец, опять замечание по поводу текстового редактора. Ни одна из описанных "полноэкранных" утилит не имеет своего редактора и вызывает тот редактор, который задан переменной окружения EDITOR
(если таковой не обнаружится, используется редактор vi). Не забудьте указать, в качестве значения этой переменной, ваш любимый текстовый редактор.
Иван Паскаль pascal@tsu.ru
Как поменять принадлежность юзера к группе (группам)?
Это зависит от того, о какой группе идет речь.
Если вы хотите поменять ему основную группу (первичную), то надо исправить соответствующее поле (group ID) в его "учетной карточке" (user account). Как это сделать подробно описано в Как поменять данные в учетной карточке.
Кстати, если вы проделаете такую операцию с реальным юзером, не забудьте, что его "домашняя директория" и файлы, находящиеся в ней "принадлежат" группе, в которой раньше находился юзер. Так что, очень желательно поменять соответствующий атрибут у всех файлов и директорий этого юзера.
Как это сделать описано в *****.
Если же вы хотите добавить юзера еще в какую-нибудь группу или, наоборот, исключить его из "членов группы" (не первичной для этого юзера), то исправления надо делать в файле /etc/group в поле "group members" соответствующей группы.
Как и в случае создания группы это можно сделать либо "вручную",просто отредактировав файл /etc/group вашим любимым редактором, либо воспользоваться специальными утилитами, теми же, что и для создания групп.
Как правило начинающие пользователи
Прежде чем приступить к экспериментам по установке Linux в качестве второй ОС, очень рекомендую принять некоторые меры предосторожности. Дело в том, что придется выполнить переразбиение диска, изменить загрузочные записи и подредактировать загрузочные и конфигурационные файлы. Все эти действия далеко не безобидны. Их результатом может стать то, что компьютер вообще перестанет загружаться. Поэтому, во-первых, необходимо изготовить загрузочную или дискету для старой системы. Во-вторых, стоит сохранить всю ценную информацию, наработанную в старой системе. И, в-третьих, подготовить комплект установочных файлов для старой системы. И еще один полезный совет: если что-то пошло не так, не пугайтесь.
После того, как необходимые меры предосторожности приняты, необходимо решить, каким образом будет осуществляться многовариантная загрузка, и подготовить диск к установке нескольких операционных систем.
Как работает LVM
Теперь, владея терминологией LVM, посмотрим, как это все работает. Каждый физический том делится на части, которые называются физическими экстентами (Physical Extents, PE). Размер физических экстентов может варьироваться, но един в пределах группы томов. В пределах физического тома каждый физический экстент имеет уникальный номер. Физический экстент -- минимальный блок пространства, который может быть адресован системой LVM на физическом хранилище.
Аналогично, каждый логический том состоит из минимальных адресуемых блоков, носящих название логических экстентов (Logical Extents, LE). В пределах группы томов размер логического экстента равен размеру физического. Очевидно, что размер логических экстентов одинаков для всех логических томов группы.
Каждый PE обязательно имеет уникальный номер в пределах физического тома, но не обязательно в пределах логического. Это связано с тем, что логический том может состоят из нескольких физических, потому уникальность идентификаторов PE невозможна. Следовательно, для идентификации LE используются как идентификаторы LE, так и соответствующие им PE. Как указывалось выше, существует взаимно-однозначное отображение LE на PE. При каждом доступе к хранилищу используется идентификатор LE для реальной работы с физическим устройством.
Теперь возникает вопрос, где хранятся все эти мета-данные о логических томах и группах томов. Как известно, в не-LVM системах, данные о разделах хранятся в таблице разделов. В LVM системе существует область дескрипторов группы томов (Volume Group Descriptor Area, VGDA), работающая аналогично таблице разделов. Она хранится в начале каждого физического тома.
VGDA содержит такие данные:
один дескриптор PV один дескриптор VG дескрипторы LV несколько дескрипторов PE.
При старте системы активируются логические тома и группы томов, а VGDA загружается в память. VGDA позволяет определить, где расположены LV. При попытке системы обратиться к устройству, используется таблица соответствия (при помощи VGDA) для определения физического адреса, используемого в операции ввода-вывода.
Как разделяют пингвинов Часть
Сергей А. ЯРЕМЧУК, 02/2003.
Как и любая другая операционная система, Linux обычно размещается на жестком диске компьютера, и пользователю, начиная с установки и заканчивая повседневным пользованием, приходится как-то взаимодействовать с разделами винчестера. Пришла пора разобраться, что все-таки творится там, на пингвиньих островах, с помощью чего можно их создавать, как они обозначаются, какие программы можно использовать для обслуживания файловых систем и, наконец, осмотреться во всем многообразии этих систем.
В статье я попробую ответить на все вопросы, которые когда-либо поступали на мой почтовый адрес по данной теме, а также на часто задаваемые в различных форумах. В некоторых случаях придется повторяться, исключительно для целостности восприятия общей картины и, естественно, для недавно присоединившихся. Также естественным желанием у меня было собрать всю информацию воедино. Статья будет логически разделена на четыре части. В первой рассмотрим все, что связано с разделами, от их наименования до количества. Во второй и третьей посмотрим, какие файловые системы можно использовать на созданных разделах. И в четвертой поговорим об утилитах, не рассмотренных в первых трех частях, и об оптимизации работы дисков.
Разделяй и властвуй
Начнем, пожалуй, с обозначения дисков, принятом в Linux. Традиционно в этой ОС ATA-диск (я думаю, SCSI уже как-то не актуален для десктопа) обозначается в соответствии с тем, к какому из интерфейсов он подключен: диск Primary IDE, подключенный как Master, всегда обозначается как /dev/hda, как Slave - hdb, соответственно, диск Secondary IDE, подключенный как Master - hdd, и как Slave - hdc. Причем называться он так будет независимо от того, есть ли диск в устройстве в наличии на данный момент или нет. Так обозначается весь диск целиком. Но как и повелось в любой операционной системе, диск делится для удобства работы на разделы. Жесткий диск может иметь не более четырех первичных (Primary) разделов, которые в Linux всегда обозначаются цифрами от 1 до 4, например hda2 для второго первичного раздела первого IDE-мастера. Но кому-то одних только первичных разделов может показаться мало, поэтому нередко создают в одном из первичных так называемый расширенный (Extended) раздел, на котором в свою очередь создается несколько логических разделов, обозначаемых цифрами начиная с 5. При этом в Linux разделы можно создавать, как это принято в DOS/Windows, то есть расширенный раздел может быть создан только в одном из первичных! Например, на диске может быть три первичных раздела hda1-hda3 и несколько логических, начиная от hda5, которые размещаются на четвертом первичном. Напомню, что в BSD-системах логические разделы (BSD Partitions) можно создать внутри каждого первичного.
До недавнего времени описанная здесь система обозначения дисков считалась стопроцентно правильной и сомнению не подвергалась. Но появившиеся в последнее время дистрибутивы новой волны, такие как Gentoo, Lunar Linux внесли свои коррективы в обозначение дисков. И виноваты в этом не сами их создатели, которые хотят запутать пользователя или как-то особенно выделиться. Нет, все обстоит иначе. Дело в том, что в ядрах Linux серии 2.4.* появилась новая файловая система устройств devfs, которая избавляет от множества неприятностей и неудобств. В двух словах, так как это соответствует теме статьи, назначение ее таково. Как известно, в Linux все, что ни попадя, в том числе и различные устройства, являются файлами - это упрощение намного облегчает взаимодействие пользователя с системой, так как для работы с диском могут применяться те же команды, что и для работы с обычным текстовым файлом (cat, dd), причем это взаимодействие абсолютно одинаково для всех типов и марок дисков. Но все было бы хорошо, если бы не один момент.
Для того, чтобы ядро могло нормально распознавать устройства, специальные файлы устройств нумеруются двумя целыми числами - старшим (major number) и младшим (minor number). Первое из них соответствует типу устройства (например, 3 - это первый IDE-диск), а второе - конкретному устройству (0A - его десятый раздел)(подробнее о наименовании устройств посмотрите в /usr/src/linux/Documentation/devices.txt). Так вот, major-номер не может быть присвоен от балды: если производитель хочет предложить свой драйвер для широкого использования, он должен входить в контакт с производителем ядер и получить для своего устройства "официальный" major-номер. И только после этого он может использоваться публично.
Проблемы здесь две. Одна состоит в том, что каталог /dev буквально завален различными файлами устройств для возможной совместимости системы со всеми девайсами; по большому счету, если не предвидится серьезного апгрейда, лишние, конечно, можно и убрать, но не лучше ли их вообще туда не класть? Вторая состоит в следующем. На первоначальном этапе эта схема распределения номеров еще была, скажем так, вполне оправдана малым количеством доступных девайсов (на заре Интернета при распределении IP-номеров и имен службы DNS названия узлов и соответствующий адрес тоже просто заносились в файл hosts на каждом компьютере). Но при современных темпах почкования новых устройств все это вызывает головную боль как производителя, так и лиц, отвечающих за поддержку ядра. Да и Linux уже подошел к тому рубежу, когда все major-номера скоро будут исчерпаны.
Выходом из всех этих проблем является использование devfs. При этом файлы устройств создаются "на лету" по мере подключения (хотя бывает, что для этого приходится систему все-таки перезагружать), при этом не захламляется каталог ненужными файлами, вдобавок, теперь, зайдя в /dev, можно узнать, какие устройства у вас присутствуют реально. После инициализации к устройствам обращаются по именам, поэтому необходимость в номерах отпала, со всеми вытекающими отсюда преимуществами. Хотя для обратной совместимости можно (но необязательно) указать major- и minor-номера. Так вот, в devfs по умолчанию используется совершенно другая номенклатура и предусмотрены иные каталоги для размещения файлов устройств. Так, в некоторых дистрибутивах файловая система устройств вообще монтируется в каталог /devices, а каталог /dev сохраняется для совместимости. Наши IDE-диски теперь можно найти в каталоге /dev/ide (SCSI - /dev/scsi), встроенному контролеру соответствует каталог /dev/ide/host0 (в платах с дополнительным контроллером доводилось видеть и каталог host1). Двум IDE-каналам этого контроллера соответствуют файлы /dev/ide/host0/bus0 и bus1, а подключенным дискам - каталоги /dev/ide/host0/bus0/target0 и target1. В каждом из этих каталогов имеется еще один lun0, в котором собственно и находятся файлы устройств, соответствующие как всему накопителю - disc, так и первичным (part1 - part4) и логическим (part5 - partN) его разделам. Исходя из этого, полное название дискового раздела будет выглядеть так: /dev/ide/host0/bus0/target0/lun0/part2.
Поверьте мне, что когда я не смог найти привычного hda, то просто обалдел. Такое обозначение можно назвать логичным, понятным, но уж никак не удобным. Поэтому в некоторых дистрибутивах (в частности, Lunar Linux, Gentoo) используется более удобный вариант, предполагающий создание жестких ссылок - например, в файле /etc/fstab для обозначения приведенного в предыдущем примере раздела встречается уже совсем другое обозначение: /dev/discs/disc0/part2. Но для совместимости никто не запрещает создать символическую ссылку со старым обозначением и работать как ни в чем не бывало - в некоторых дистрибутивах это предусмотрено автоматически.
Итак, с обозначением разобрались. Следующий вопрос, постоянно мучающий читателя: сколько и какие разделы нужно создавать. Итак, внимание - для нормальной работы необходимо создать как минимум два раздела: первый системный - Linux native, второй раздел подкачки - Linux Swap. Под системный раздел желательно выделить, если вы предполагаете работать с X-Window, как минимум 800 - 1000 Мб, но это, как вы понимаете, во многом зависит от самого дистрибутива: есть однодисковые, а есть 3-, 5- и даже 9-дисковые, так что разбирайтесь сами. Раздел подкачки желательно расположить, для увеличения скорости обмена данными, как можно ближе к началу диска, а идеальный вариант - на другом физическом диске. А лучше вообще разделить поровну между ними, сделав запись в /etc/fstab о равенстве их приоритетов:
/dev/hda5 swap swap defaults,pri=1 0 0 /dev/hdc5 swap swap defaults,pri=1 0 0
Но здесь, в зависимости от старости дистрибутива (ядра), могут быть свои ограничения на размер. В очень ранних дистрибутивах максимальный размер раздела подкачки не должен был превышать 16 Мб, а максимальное количество таких разделов достигало восьми. В более поздних предел составлял уже 128 Мб. Современные же ядра, начиная с 2.4.10, не могут монтировать swap, если размер дискового раздела меньше 128 Mб. Когда я это первый раз прочитал и посмотрел на свой 64-Мб swap, то не понял, в чем тут прикол. Вроде и так работает. Но ведь это официальная информация, а реально swap ограничен половиной адресного пространства оперативной памяти. Для i86-процессоров при размере страницы памяти 4 Kб (значение по умолчанию) размер адресного пространства равен 4 Гб, а максимальный размер swap, соответственно, - 2 Гб. Такой вариант разбиения на два раздела, по-моему, - наиболее удобный вариант для новичка, во всяком случае мороки и проблем на этапе освоения будет поменьше. Затем, если пингвин приживется на вашем компьютере (только не стирайте сразу - у самого месяца три ушло на то, чтобы разобраться что к чему), желательно на отдельные разделы вынести каталог /home, в котором хранятся все пользовательские данные и настройки, а также раздел /usr/local, в который по умолчанию устанавливаются все пользовательские программы, не входящие в дистрибутив штатно. В таком случае можно будет переустановить заново дистрибутив, не затрагивая при этом всех пользовательских настроек и не переустанавливая заново кучу программ, и пользоваться ими сразу после запуска (сравните с Windows). А что делать, если первоначально не были созданы все эти разделы, а теперь, по мере прочтения статьи, у вас созревает желание перенести их на отдельные разделы диска? Все очень просто до безобразия, создаем еще один раздел, затем монтируем в произвольную точку и просто копируем в него данные, а затем удаляем их из исходной папки, чтобы место не занимали. Например:
# mount -t ext3 /dev/hdb3 /mnt/temp # монтируем созданную файловую систему. # cp -R /usr/local/ /mnt/temp # рекурсивно копируем в нее все из каталога /usr/local (это можно проделать и с помощью mc или другим удобным способом); здесь необходимо проследить за выводимыми сообщениями # umount /dev/hdb3 # размонтируем # mount -t ext3 /dev/hdb3 /usr/local # монтируем поверх старого /usr/local (новые ядра позволяют это) для проверки, теперь прогоняем любимые программы # umount /dev/hdb3 # rm -f /usr/local/* # очищаем диск, так как информация все равно будет присутствовать # mount -t ext3 /dev/hdb3 /usr/local # монтируем новый раздел в качестве /usr/local и наслаждаемся полученным результатом.
И теперь, чтобы новый раздел при загрузке каждый раз монтировался на свое место, прописываем в файл /etc/fstab следующие строки:
/dev/hdb3 /usr/local ext3 defaults 0 0
Вот за что я и люблю Linux. Все просто, никаких тебе реестров, где регистрируется каждая программа и потому при смене раздела или добавлении нового диска как правило приходится заново ее переустанавливать. Кстати, если есть сеть с постоянно работающими компьютерами, то можно данный раздел вообще расположить только на ОДНОМ из них, тем самым экономя место, резервируя возможность контролировать и централизованно наполнять его содержание, а монтировать его уже на этапе загрузки с помощью NFS; тогда и бэкапить легче будет. При этом пользователи даже не будут догадываться, что какой-то раздел находится где-то совсем на другом компьютере. К слову, в соответствии со стандартами, продвигаемыми Linux Standard Base (http://www.linuxbase.org/), на смену каталогу /usr/local постепенно продвигается другой - /opt. И если первые два года моего знакомства с этой системой там было совсем пусто, то в последнее время он начал быстро и методично заполняться. Чтобы не создавать и здесь новый раздел, есть два выхода: явно задавать с помощью ?prefix=/usr/local путь при компиляции таких программ, или, что удобнее всего, вместо каталога /opt просто создать символическую ссылку на /usr/local:
# ln -s /usr/local /opt
После этого все программы при установке будут попадать на созданный раздел диска.
Также не помешает создать еще один раздел - /boot, это самая критическая часть для загрузки операционной системы. И как я уже говорил в статье о загрузчиках, ядро не всегда можно загрузить с современных журналируемых файловых систем. После публикации статьи мне пришло много писем о том, что, мол, грузимся, и ничего. Но это ведь придумал не я, моя задача - просто предупредить, что такой вариант вполне возможен, особенно на первых ядрах серии 2.4. Кроме того, есть второе ограничение для старых дистрибутивов (в основном для тех, у кого ядро древнее 2.4 - пользователей Mandrake 7, Red Hat 6 и т.д.), связанное с так называемой проблемой 1023-го цилиндра. Дело в том, что из-за ограничений, накладываемых BIOS’ом большинства Intel-совместимых компьютеров (заметьте, это ограничение именно BIOS’а, a не Linux’а), ядро может загружаться только с первых 1023 цилиндров жесткого диска, причем если у вас их два, то возможно даже, только с первого мастер-диска (для справки: в Partition Magic есть даже ярлычок, указывающий на 1023-й цилиндр). Вся необходимая информация для загрузки LILO/GRUB, в том числе и ядро, находится в каталоге /boot. Поэтому чтобы выйти из сложившейся ситуации, расположите этот каталог в первых 1023 цилиндрах (вариант загрузки с дискеты я откидываю сразу), а корневой / (и все остальные) раскидайте по диску (или дискам) так, как вам хочется. Монтировать данный раздел следует только при инсталляции нового ядра или новой схемы загрузки.
Запись в /etc/fstab может быть примерно следующей:
/dev/hda1 /boot ext2 noauto 1 2
Больше чем 20 Мб данный раздел все равно не потянет, так что можно и раскошелиться. На серверах обычно дополнительно выносят в отдельный раздел каталоги /var и /tmp, но на домашнем компьютере вряд ли есть в этом какая-то необходимость. Из всего вышеизложенного вы должны понять, что создание разделов - процесс сугубо творческий, и ограничивает вас в этом только ваша собственная фантазия (и размеры диска(ов)).
Итак, с обозначениями мы разобрались, теперь давайте посмотрим, с помощью чего все это можно сотворить.
При установке каждого дистрибутива Linux пользователь сталкивается с какой-нибудь более или менее удобной программой, с помощью которой можно разбить диск и отформатировать его под нужную файловую систему. Особенно просты в применении графические утилиты Disk Druid в Red Hat и Hard Drake в Mandrake (Рис. 1). Для тех, кто сталкивался хоть раз с Partition Magic и немного понимает суть процесса, особых проблем при их использовании возникнуть не должно. Но, господа (панове, товарищи), раздел под новую операционную сист ему должен быть предварительно подготовлен, т.е. очищен от информации, хотя это можно попробовать сделать и при установке, зайдя в другую консоль, и скопировать файлы в другой раздел. Не говорю уже о таком обычае как предварительное резервирование данных при всякой рискованной операции, к чему относится, конечно, и установка ЛЮБОЙ операционной системы. При установке же других дистрибутивов и в последующей деятельности придется общаться с совсем другими утилитами. Познакомимся с ними поближе.
До недавнего времени для работы с дисковыми разделами в уже установленном Linux я пользовался только одной программой, к которой привык с еще с долинуксовских времен - имя ей fdisk. Да, это та страшилка, которой пугают начинающего линуксоида на каждом сайте и книге. Она полностью удовлетворяла моим довольно скромным потребностям; к тому же и программы, аналогичной PM, в Linux все равно нет. Но естественно, есть и другие предназначенные для этого инструменты: cfdisk (кстати, применяется при установке Debian) и совсем новая GNU/parted, с которой я впервые столкнулся при установке Lunar Linux. В моем Red Hat их не было, и для того чтобы не лазить за ними в Интернет, я их просто скопировал из раздела с Lunar Linux в аналогичный каталог Red Hat; если программа требовала какую-то библиотеку, то поступал аналогично. В более тяжелых случаях (например, перенос KDE) я пользуюсь jail (http://www.gsyc.inf.uc3m.es/~assman/). Эта программка, правда, предназначена совсем для другой цели - создания chroot-среды на серверах и переноса в нее только нужных для работы программ, чтобы злоумышленник, взломав аккаунт, думал что он находится в настоящем корневом каталоге. Уж простите за маленькое отступление.
Итак, fdisk. Тех, кто пользовался хоть раз Windows-аналогом, найдут данную программу очень похожей. Позволю все-таки немного остановиться на ее работе, так как есть небольшие отличия. Запускается она с аргументом - названием диска, с которым будет производиться дальнейшая работа.
[root@grinder sergej]# /sbin/fdisk /dev/hdb Command (m for help): m
Взаимодействие с пользователем осуществляется путем нажатия клавиш соответствующей требуемой операции. Как видно из примера, m (manual) выводит полную справку, p (print) - состояние разделов, n (new) создает раздел, d (delete) удаляет его (кстати, удалить раздел Linux можно только с помощью описываемых программ и PM, ДОСовский fdisk в данном случае абсолютно бесполезен). Все введенные команды будут выполнены только после ввода w (write), а при помощи q (quit) можно выйти без записи изменений.
Command (m for help): p
Disk /dev/hda: 255 heads, 63 sectors, 3649 cylinders Units = cylinders of 16065 * 512 bytes
Device Boot Start End Blocks Id System /dev/hda1 247 3649 27334597+ f Win95 Ext'd (LBA) /dev/hda2 * 1 246 1975963+ b Win95 FAT32 /dev/hda5 247 756 4096543+ 83 Linux /dev/hda6 757 772 128488+ 82 Linux swap
Далее, клавиша а включает флаг указания загрузочного раздела, с помощью t устанавливается типфайловой системы раздела - список всех доступных можно просмотреть с помощью опции -l (list) (Рис. 2). Как видите, в списке присутствуют практически все широко известные файловые системы, но это не значит, что после выбора a5 FreeBSD на данном участке диска тут же будет создана файловая система FFS. Нет, в данном случае разделу присваивается только идентификатор раздела, с помощью которого можно разве что зарезервировать тип, а сама файловая система будет создана только после его форматирования. Вспомните, в ДОС после fdisk всегда нужно было запускать format. Здесь ситуация аналогична, только программы для создания файловой системы (форматирования) немного другие (и не одна). В нашем случае нас интересуют типы раздела Linux native (идентификатор 83), Linux swap (82), еще может пригодится тип 5 для создания расширенного раздела.
Итак, для создания раздела вводим n:
Command (m for help): n Command action l logical (5 or over) p primary partition (1-4)
На первом этапе нужно определиться, какой раздел нужен, если первичный - жмем на p, расширенный - l (хотя в старых версиях встречалась и е). После ввода, когда запросят номер раздела, порядка придерживаться не обязательно, можно вначале создать второй, а потом первый. Следующий вопрос - о размере. Его можно задать в цилиндрах (по умолчанию), в байтах, килобайтах и мегабайтах. Если просто ввести цифру 100, то раздел будет занимать ровно сто цилиндров, а для того чтобы задать сразу в мегабайтах, необходимо ввести +100M. При этом созданный раздел будет равен ближайшему кратному числу цилиндров. По умолчанию каждому созданному разделу присваивается идентификатор 83.
Более наглядна в работе утилита cfdisk (Рис. 3), с помощью которой легко проделать с дисковыми разделами все требуемые операции. Выбор раздела, с которым будут производиться дальнейшие действия, осуществляется с помощью клавиш вверх-вниз, а выбор требуемого действия - вправо-влево. Все изменения на диск будут записаны только при выборе пункта Write, после чего еще придется для подтверждения ввести yes, до этого можно совершенно не волноваться о сохранности данных. Удалить раздел можно с помощью Delete, пометить как загрузочный - Bootable, Print позволяет просмотреть таблицу разделов или сохранить ее в файле (Рис. 4), выбрать тип файловой системы можно с помощью Type, c помощью Units, чтобы не набирать каждый раз размер в мегабайтах, можно сразу установить режим ввода и отображения по умолчанию (Mb, sectors, cylinders), выйти, не внося изменения, - с помощью все той же Quit. Кстати, кто разбивал диски FreeBSD’шной программой /stand/sysinstall, не найдут здесь абсолютно ничего особенного. Можно вместо выбора пунктов меню использовать горячие клавиши, которые совпадают по назначению с таковыми в fdisk, что совсем не вызывает удивление, т.к. вышеописанная утилита является фронт-эндом к ней.
И наконец, GNU/parted, рожденная в недрах проекта GNU утилита, позволяющая не только создавать новые разделы, но дополнительно и файловые системы на них, к тому же она осуществляет проверку их целостности, а также удаление, перемещение, копирование и, что в новость для Linux, изменение размера разделов - правда, некоторые операции можно производить пока только с ext2fs, swap и FAT16/FAT32 .
Работать программа может в двух режимах: в интерактивном и командном.
Первый можно запустить, набрав просто parted в командной строке или добавив опцию -i в командном режиме. После запуска программы и выдачи стандартных для такого рода программ предупреждений и информации о диске, пользователь получает приглашение для ввода команд:
(parted)
Команда help позволяет получить краткую справку, а с аргументом [название команды] - справку по ее работе. Другие команды:
- print выводит таблицу разделов;
- check MINOR (где MINOR - раздел диска в терминологии parted, который можно узнать с помощью предыдущей команды) производит простую проверку файловой системы;
- cp [FROM-DEVICE] FROM-MINOR TO-MINOR - копирует файловую систему в другой раздел;
- mklabel ТИП-МЕТКИ - создать новую метку диска (таблицу раздела);
- mkfs MINOR ТИП-ФС - создать файловую систему на разделе MINOR; ТИП-ФС может принимать значения ext2, ext3, FAT, hfs, jfs, linux-swap, ntfs, reiserfs, hp-ufs, sun-ufs, xfs; хотя на данный момент поддерживаются только ext2fs, swap и FAT, будем надеяться, что это ненадолго;
- mkpart ТИП-РАЗД [ТИП-ФС] НАЧ КОН - создает раздел без файловой системы; ТИП_РАЗД может принимать значения primary, logical, extended. Полезная команда, если раздел удален случайно. НАЧ КОН - расстояние в мегабайтах от начала диска;
- mkpartfs ТИП-РАЗД ТИП-ФС НАЧ КОН - создать раздел с файловой системой;
- move MINOR START [END] - перемещение раздела в пределах диска;
-name MINOR NAME - присвоение имени разделу;
-quit - выйти из программы
- resize MINOR НАЧ КОН - изменить размер файловой системы на разделе, при этом гарантируется (если это вообще возможно при работе с дисками) сохранность данных (размер можно изменить только в соседних разделах);
- rm MINOR - удалить раздел MINOR;
- select DEVICE - смена рабочего диска;
- set MINOR FLAG STATE - изменение флага раздела, где FLAG - boot, root, swap, hidden, raid, lvm или lba, а STATE - on или off.
Взаимодействие с пользователем напоминает bash, тот же механизм автодополнения, редактирования строки ввода, та же история команд. Главное отличие от предыдущих программ - все изменения вступают в силу сразу после ввода команды. Вообще, утилита мне показалась продуманной, логичной и довольно удобной, правда, поначалу несколько непривычной. Но командный режим, скажу вам, это что-то. Введя сразу все необходимые опции, в bash на выходе получим уже готовый размеченный диск:
[root@grinder sergej]# parted /dev/hda mkpartfs primary linux-swap 0 128 && parted /dev/hda mkpartfs primary ext2 129 ###
Если необходимо разметить сразу несколько дисков, лучшего инструмента не сыскать. Жаль, правда, что пока возможности ограничены только ext2. Зная мир OpenSource, можно надеяться, что где-то уже пишется фронт-энд к данной утилите, и если это так, то, возможно, мы получим свой бесплатный Partition Magic!
Для работы с разделами можно использовать и программу sfdisk, которая имеет четыре основных режима работы: вывод размера раздела, вывод размера дисков, проверка разделов и еще один, помеченный как very dangerous, - изменение разделов.
Опция s выводит информацию о размерах дисков в блоках:
[root@grinder sergej]# /sbin/sfdisk -s /dev/hda: 29316672 /dev/hdb: 3167640 total: 32484312 blocks
Запуск с опцией -l позволяет просмотреть таблицу разделов; если при этом не указывать конкретно диск, то будет выведена информация обо всех дисках (Рис. 5). С помощью команды sfdisk -V можно проверить раздел на соответствие записи в таблице и реального состояния; если все прошло благополучно, то выведет ОК, иначе - краткий отчет о проблеме. Создавать разделы с помощью этой программы все-таки неудобно, поэтому трогать мы ее не будем, зато очень легко сохранить таблицу разделов:
[root@grinder sergej]# /sbin/sfdisk /dev/hda -O hda-partition-sectors.save и восстановить ее в случае проблем [root@grinder sergej]# /sbin/sfdisk /dev/hda -I hda-partition-sectors.save
Напомню, что эти же операции можно проделать и с помощью команд cat или dd.
Вот мы и рассмотрели все вопросы, которые затрагивают размещение и создание разделов для ОС Linux на жестком диске. В следующей части посмотрим, чем можно их наполнить. Linux forever.
Навигация по статье:
Часть 1: Разделы
Часть 2: Файловые системы
Часть 3: Утилиты и оптимизация
Источник - LinuxBegin.ru
http://linuxbegin.ru
Адрес этой статьи:
http://linuxshop.ru/linuxbegin/article262.html
Вот теперь, пожалуй, и все. Остальное в man’ах и в Интернете. По адресу http://linux.yaroslavl.ru/docs/conf/fs/l-fs_ru/l-fs_ru.htm, можно найти переводы цикла статей Daniel'a Robbins'a, оригинал которых расположен на сайте IBM (http://www-106.ibm.com/developerworks/library/l-fs.html - цикл не окончен, ожидается еще продолжение). И еще новость: заработал, наконец, в полную мощность сайт LinuxBegin, назначение которого - помочь пользователю в освоении этой непростой системы и имеющий к тому же мою самую любимую рассылку по Linux. Адрес такой: http://www.linuxbegin.ru/.
Навигация по статье:
Часть 1:Разделы
Часть 2: Файловые системы
Часть 3: Утилиты и оптимизация
Источник - LinuxBegin.ru
http://linuxbegin.ru/
Адрес этой статьи:
http://linuxshop.ru/linuxbegin/article264.html
Как создать или удалить группу?
Это достаточно просто сделать "вручную". Файл /etc/group, хранящий информацию о группах имеет простой формат и его можно менять любым текстовым редактором.
Просто добавьте строчку, создав ее "по образу и подобию" тех, которые там уже есть. Только подберите groupID такой, который не используется другими группами.
Для удаления группы, просто удалите соответствующую строчку.
Проблемы могут возникнуть только, если у вас слишком много разных групп и вам будет трудно ориентироваться в тексте. Тогда вам, возможно, помогут специальные программы.
Программы addgroup и rmgroup.
Программа pw.
Важное замечание о безопасности.
Как удалить юзера?
С одной стороны, очень просто - удалите его учетную карточку из базы. Это можно сделать программой vipw - найдите соответствующую строчку и удалите ее.
С другой стороны, в системе могут быть файлы, принадлежащие этому юзеру, а, также, имя юзера может встречаться в некоторых других файлах.
Что надо удалить?
Найти все эти файлы можно с помощью...
Где еще могут остаться упоминания об этом юзере?
Самый простой способ удалить юзера (программы rmuser и pw).
Как вносить изменения
Сначала, подумайте о том, как не вносить изменения в ядро. Есть две отличных причины, почему вам не стоит просто перейти в /proc, открыть файл в текстовом редакторе, сделать несколько изменений и сохранить файл. Вот они:
Целостность данных: Все эти файлы представляют работающую систему, а поскольку ядро может внести изменения в эти файлы в любое время, то если вы откроете файл и попытаетесь внести изменения в то время, когда туда вносит изменения система, то вы можете сохранить не то, что ожидает увидеть ядро.
Виртуальные файлы: Все эти файлы в действительности не существуют. Как же тогда синхронизировать сохраненные данные?
Ответом на это является не использование текстового редактора для внесения изменений. Поэтому для внесения изменения в что-либо в файловой системе /proc, вам следует использовать команду echo и перенаправлять вывод команды в выбранный файл в /proc.
Например: echo "Your-New-Kernel-Value" > /proc/your/file
Аналогично, если вы хотите увидеть информацию из /proc, вам следует использовать либо команду, которая предназначена для этого, либо команду cat.
Как временно убрать юзера (не удалить, но запретить вход)?
Бывают такие ситуации, когда надо запретить юзеру пользоваться вашей машиной временно. Конечно, самый простой способ - удалить его учетную карточку, но не трогать остальные файлы. Однако, этот способ имеет кучу недостатков:
- почта на несуществующего юзера будет возвращаться отправителю,
- user ID этого юзера может достаться другому (новому юзеру),
- при возвращении юзера в систему надо будет воспроизвести в точности ту же учетную карточку,
- и т.п.
Поэтому, этот способ - самый неудачный и его даже не стоит рассматривать. Лучше рассмотрим другие возможности:
Первый способ
Второй способ
Так как же все таки надо поступить?
Возможно, еще один способ
Как Xmodmap работает в разных системах
Для GNOME это не важно, но для корректного использования шрифтов в кодировке ISO8859-2 приложениями KDE 2.x необходимо изменить файл i18n (/etc/sysconfig/i18n) как указано ниже:
RedHat:
LANG="sk_SK"
где"sk_SK" -- правильное обозначение нужного Вам языка.
Mandrake:
SYSFONT=lat0-sun16
LC_MONETARY=en_US
LC_CTYPE=cs_CZ
LC_NUMERIC=en_US
LC_MESSAGES=en_US
LANGUAGE=cs_CZ:cs
LC_TIME=en_US
RPM_INSTALL_LANG=en
LC_COLLATE=en_US
SYSFONTACM=iso15
LANG=sk
Для FreeBSD 4.2 следующим образом отредактируйте /etc/profile:
LANG=cs_CZ.ISO_8859-2; export LANG #чтобы писать по Чешски
LC_MESSAGES=en_US.ISO_8859-1; export LC_MESSAGES # чтобы сообщения были по-английски.
В Mandrake или FreeBSD воспользуемся раскладкой "cs" из директории /usr/X11R6/lib/X11/xkb/symbols/. Всегда можно воспользоваться методикой, основанной на xmodmap, в качестве альтернативы можно изменить map-файл соответствующим образом, заменив определения клавиш на свои собственные. В KDE 2.x помимо этого требуется выбрать кодовую таблицу iso8859-2 (или другую подходящую) в меню Personalization > Country and Language. Только после этого шрифты ISO8859-2 будут верно отоброжаться в приложениях, написанных для KDE. В этом отношении GNOME будет подружелюбнее.
Следующее относится к случаю. когда файл i18n отстался неизмененным.
Как заставить cron выполнять наши приказания
Автор: Станислав Лапшанский, slapsh@kos-obl.kmtn.ru
Опубликовано: 15.03.2002
Оригинал: http://www.softerra.ru/freeos/16683/
Статья является переводом текста Dru Lavigne
Было бы здорово, если бы ваша FreeBSD постоянно автоматически выполняла свое техническое обслуживание и докладывала бы вам об этом по электронной почте. К счастью, благодаря демону cron и обслуживающим сценариям, ваша FreeBSD регулярно делает это. В сегодняшней статье мы обсудим как демон cron выполняет запланированные команды и обучимся как сконфигурировать cron для запуска ваших сценариев и программ.
Так же как большинство других демонов, cron запускается вместе с FreeBSD и потом тихонько работает в фоновом режиме. Что бы доказать себе, что нет необходимости запускать cron самостоятельно, поищите слово "cron" в списке запущенный процессов, например таким образом: ps -ax | grep cron
У вас должно получиться нечто похожее: 97 ?? Is 0:07.71 cron
В данном примере cron имеет 97-й номер процесса.
Cron "просыпается" каждую минуту и проверяет списки запланированных заданий -- crontab (сокращение от "chron or time table"), на предмет наличия там заданий подлежащих запуску. Crontab это обычный файл, содержащий список команд, а также время в которое эти команды должны запуститься. Когда вы установили FreeBSD, системный список запланированных заданий был создан автоматически. Вы не должны производить никаких изменений в этом файле. Далее мы опишем как используя утилиту crontab вы сможете создавать пользовательские списки запланированных заданий, которые cron будет выполнять помимо системного списка.
Системный список хранится в файле /etc/crontab. Воспользуйтесь командой more, для того что бы просмотреть этот файл, гарантированно не отредактировав его. Возможно вам следует войти в систему сразу на двух консолях, это позволит вам на одной консоли читать системный список заданий, а на другой выполнять различные команды. Напишите на первой консоли: more /etc/crontab
В результате вы увидите следующие строки: # /etc/crontab - root's crontab for FreeBSD # # $FreeBSD: src/etc/crontab,v 1.21 1999/12/15 17:58:29 obrien Exp $ # SHELL=/bin/sh PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin HOME=/var/log # #minute hour mday month wday who command # */5 * * * * root /usr/libexec/atrun
Как и в любом файле комментарий начинается с символа решетки "#". Наиболее полезны комментарии, описывающие содержимое полей этого файла. Заметьте -- пять полей описывают время, потом идет поле пользователя (поле "кто"), а затем команда. На первый взгляд формат этого файла может показаться вам странным, но каждая строка этого файла, не являющаяся комментарием, просто говорит cron'у когда следует запустить указанную команду.
В следующей таблице показаны границы допустимых значений аргументов столбцов описывающих время: Поле Допустимое значение Минуты (minute) 0-59 Час (hour) 0-23 День месяца (dayofmonth) 1-31 Месяц (month) 1-12 или первые три буквы английского названия месяца (регистр не учитывается) День недели (dayofweek) 0-7 (где 0 и 7 это воскресенье) или первые три буквы английского названия дня в неделе (регистр не учитывается)
Значения могут быть числом, трехбуквенным названием, а так же диапазоном например запись "1-5" в поле dayofweek будет означать "с понедельника по пятницу". Значения могут отделяться запятыми: "1,15,31" в поле dayofmonth будет запускать указанную команду 1-го, 15-го и 31-го числа каждого месяца.
Все пять полей времени допускают использование символа звездочка -- "*", который обозначает "использовать любое допустимое значение" для этого поля. Например для того что бы запускать команду каждый месяц, поставьте "звездочку" в поле month.
Также можно использовать значения вида "*/число". Например "*/2" в поле месяца будет означать "запускать каждый второй месяц". В системном списке заданий есть подобный пример: #minute hour mday month wday who command */5 * * * * root /usr/libexec/atrun
Эта строка читается так: выполнять команду /usr/libexec/atrun от пользователя root, если текущая минута делится нацело на пять (или просто каждые пять минут), каждый час каждый день любого месяца. Если вы не в курсе что делает команда atrun, напечатайте на консоли: whatis atrun
В ответ будет сказано: atrun(8) - run jobs queued for later execution
Т.е. команда atrun запускает задачи из очереди отложенного выполнения. Если ваше любопытство не удовлетворено таким объяснением, то загляните в man 8 atrun.
И заключительная таблица, перед тем как снова обратиться к /etc/crontab. Вы можете заменить все пять полей времени следующими подстановками: Строка Что это значит @reboot Запускать при начальной загрузке @yearly Заменяет "0 0 1 1 *" т.е. "ежегодно в 00:00 1 января" @annually Тоже что и yearly @monthly Заменяет "0 0 1 * *" т.е. "ежемесячно в 00:00 1 числа" @weekly Заменяет "0 0 * * 0" т.е. "еженедельно в 00:00 воскресенье @daily Заменяет "0 0 * * *" т.е. "ежедневно в 00:00" @midnight Тоже что и daily @hourly Заменяет "0 * * * *" т.е. "ежечасно в 00 минут"
Вернемся в первую консоль и продолжим чтение /etc/crontab: # rotate log files every hour, if necessary # (произвести ротацию журналов каждый час, если это необходимо) 0 * * * * root newsyslog
Т.е. производить ротацию файлов журналов каждый час, если это необходимо. Опять комментарий оказался полезен. Для того что бы узнать что делает команда newsyslog напишите: whatis newsyslog
Система ответит: newsyslog(8) - maintain system log files to manageable sizes
Т.е. newsyslog предназначен для придания системным журналам управляемых размеров.
Итак, читаем /etc/crontab дальше: # do daily/weekly/monthly maintenance # (проводить ежедневное/еженедельное/ежемесячное обслуживание) 59 1 * * * root periodic daily 2>&1 | sendmail root 30 3 * * 6 root periodic weekly 2>&1 | sendmail root 30 5 1 * * root periodic monthly 2>&1 | sendmail root
Обратите внимание, что обслуживающие сценарии никогда не запускаются одновременно. Ежедневное обслуживание запускается каждую ночь в 1:59, если вы спите рядом с вашей FreeBSD-системой, то вы можете услышать треск винчестера в это, казалось бы, странное время. Еженедельное обслуживание проводится каждую субботу, ночью в 3:30. Ежемесячное -- запускается в первый день каждого месяца в 5:30 утра. Вообще, это неплохая мысль -- запускать обслуживание, когда процессор не загружен работой (т.е. в середине ночи), и не обрабатывать сразу все сценарии одновременно, для предотвращения излишней загрузки процессора вашей системы.
Комбинация 2>&1 говорит интерпретатору команд, что все ошибки и сообщения должны быть сохранены вместе. При помощи канала они передаются программе sendmail, которая отсылает их пользователю root, таким образом весь вывод (вместе с ошибками) порождаемый обслуживающими сценариями будет отослан по электронной почте пользователю root. (На самом деле в текущих версиях FreeBSD процесс протекает несколько иначе -- сценарий periodic формирует почтовое сообщение сам. Следовательно необходимости в 2>&1 | sendmail root уже нет -- прим. переводчика).
Где cron находит обслуживающие сценарии? На второй консоли попробуйте напечатать: # ls /etc/periodic daily monthly weekly
# ls -F /etc/periodic/weekly 300.uucp* 330.catman* 310.locate* 340.noid* 120.clean-kvmdb* 320.whatis* 999.local*
Ключ -F добавляет к названиям всех запускаемых файлов символ звездочки "*". Таким образом мы видим, что /etc/periodic содержит подкаталоги в которых содержатся сценарии, которые, в свою очередь ежедневно (daily), еженедельно (weekly) и ежемесячно (monthly) выполняет cron (тут автор статьи умалчивает о том, что на самом деле сценарии из этих подкаталогов выполняет сценарий /usr/sbin/periodic, который и указан в файле /etc/crontab -- прим. переводчика). Если вы действительно любознательны, попробуйте написать: more /etc/periodic/weekly/310.locate
Если вы учитесь писать сценарии для интерпретатора команд, исследование встроенных в систему сценариев даст вам множество примеров правильного и общепринятого синтаксиса.
Поскольку результаты работы этих сценариев отправляются по почте пользователю root, он, используя почтовую программу, может контролировать возникающие в системе неполадки. Обычно вы не конфигурируете ваш любимый почтовый клиент для получения почты пользователя root, так как в большинстве ситуаций вам не требуется получать или отправлять почту от имени пользователя root (мягко говоря спорное утверждение -- прим. переводчика). Однако вы все же хотите получать уведомления о проблемах в системе, которые пришлет вам cron. Зарегистрируйтесь в системе как суперпользователь и воспользуйтесь вашим любимым почтовым клиентом для получения этой почты (большинство почтовых клиентов не требуют никакого конфигурирования для чтения почты любого пользователя -- необходимо только зарегистрироваться в системе от имени желаемого пользователя и запустить клиент -- прим. переводчика).
Если вы никогда не делали этого до этого, то вполне возможно, что вы получите сотни сообщений, в зависимости от того сколько времени включен ваш компьютер (в день обычно генерируется два сообщения, не считая еженедельных и ежемесячных отчетов -- прим. переводчика). Однако, если вы всегда выключаете компьютер до полуночи, то вероятно вы не получите вообще ни одного сообщения, так как все сценарии запускаются после полуночи.
Если у вас есть несколько сообщений, то помимо прочего вы должны получить как минимум одно названное "daily run output", если вы прочтете это сообщение, то вы увидите, сколько работы проделывает для вас cron каждую ночь в 1:59. Обратите внимание, что сообщения относящиеся к безопасности присылаются отдельным письмом которое называется "security check output". Это сообщение весьма полезно для прочтения так как оно содержит информацию о проверке файлов имеющих атрибут setuid, uid 0, пользователях без паролей, сообщениях ядра, отвергнутых попытках зарегистрироваться в системе и отклоненных соединениях.
После прочтения эти сообщения могут быть безопасно удалены. После выхода из почтового клиента не забудьте завершить сеанс суперпользователя.
До сего момента мы исследовали системный файл crontab, который не следует изменять. Теперь мы поглядим как создавать свой собственный файл crontab, для того что бы заставить cron выполнять наши команды. Во FreeBSD по умолчанию любой пользователь имеет право создать собственный файл crontab. Эти файлы хранятся в каталоге /var/cron/tabs. Если вы напечатаете (от пользователя root): ls /var/cron/tabs
то вы обнаружите, что по умолчанию там пусто. Создавая crontab, вы создаете файл в этом каталоге, с именем пользователя. Никогда не редактируйте этот файл используя текстовый редактор, вместо этого для редактирования и создания используйте утилиту crontab.
Вы можете быть удивлены, сколько разных команд и сценариев следует поручить cron'у для исполнения. Спросите себя какие команды вы выполняете регулярно или должны выполнять регулярно, но иногда об этом забываете. Например вы можете захотеть удалять core-файлы или dead.letter (т.е. обычно ненужные файлы -- прим. переводчика). Или возможно вам хочется регулярно очищать кеш вашего браузера.
Когда вы определитесь что вы хотите что бы cron сделал для вас, подумайте какими командами, или наборами команд, могут быть выполнены эти задачи. Каждая запись в crontab'е должна состоять из одной строки. Вполне нормально, если строка будет переноситься по границе экрана пока вы не нажмете клавишу "Enter". Однако если команда слишком длинна, то может быть проще создать для нее отдельный файл (сценарий) и указать в crontab'е уже этот файл. Покажем это на примерах.
Если я хочу найти и удалить файлы с определенными расширениями, то я могу ввести подобную команду (вы должны ввести ее на одной строке): find / \( -name "*.core" -or -name "dead.*" \) -print -exec rm -rf {} \;
Посмотрим, как можно интерпретировать эту малопонятную фразу. В общем виде эта команда что-то ищет. Поисковые выражения всегда выглядят как: find точка_начала_поиска искать_вот_это с_найденным_делать_это
Итак, когда я пишу find /, я говорю команде find искать от корня файловой системы.
Дальше я говорю find, что бы она искала файлы, чьи имена заканчиваются на ".core" или начинаются на "dead.". Так как в конечном итоге я хочу что бы оба типа фалов были удалены, то я окружил их скобками. Я добавил перед скобками по обратному слешу для того что бы интерпретатор команд не воспринял их на свой счет.
Когда find найдет такие файлы он применит к ним команду "rm -rf", указанную в параметре "-exec". Всякий раз когда вы используете предложение "-exec" в find, вы должны заканчивать его символами "\;", иначе ничего не будет работать. Фигурные скобки указывают exec место, куда следует подставить информацию найденную find.
Ну что, мне кажется это было не так уж плохо? Теперь создадим простой сценарий для очистки кеша браузера Netscape. Этот сценарий я взял из списка рассылки FreeBSD -- отсюда и еще отсюда.
Откройте ваш любимый текстовый редактор и напечатайте следующий текст: #!/bin/sh
# First, double- check that the user is not # currently using Netscape # Then remove the contents of all the subdirectories # in the Netscape cache # Во-первых двойная проверка, не использует ли # пользователь сейчас Netscape. Если нет, то удалить # содержимое кеша Netscape
if ! (`ps wxu $USER | grep -q [n]etscape`) then echo "Clearing Netscape cache..." rm -rf ~/.netscape/cache/*
fi
echo "Exiting...."
Попробуем разобраться что мы тут написали. Все сценарии начинаются вот с такой штуки: #!
за которой следует полный путь к программе которая будет выполнять сценарий. Мы создали сценарий для интерпретатора команд Bourne и указали что команда sh (Bourne shell) будет интерпретировать этот скрипт: #!/bin/sh
Далее мы включили семь строк комментариев (они начинаются с символа решетки "#") для того что бы не забыть для чего этот сценарий предназначается.
Далее идет полезное содержимое сценария. Оно содержит предложение "если", начинающееся ключевым словом "if" и заканчивается "fi". В первой строке предложения "если" указывается условие которое может принимать значение "истина" или "ложь": if ! (`ps wxu $USER | grep -q [n]etscape`)
Знак "!" это операция отрицания "не", которая позволяет блоку "if" выполняться когда выражение в скобках не истинно. По существу команда ps используется для поиска запущенного процесса Netscape у данного пользователя. В случае отсутствия такого процесса сценарий продолжается выводом строки заключенной в кавычки: echo "Clearing Netscape cache..."
Далее идет непосредственно очистка кеша Netscape, который находится в домашнем каталоге пользователя: rm -rf ~/.netscape/cache/*
В случае, если у пользователя существует запущенный процесс Netscape, то интерпретатор выходит из блока "if" не выполняя пункт "then".
Сохраните ваш сценарий. Я сохранил его под именем "clean". Вы же можете назвать ваш сценарий как вам будет угодно, однако не следует назвать его именем какой-нибудь существующей команды. Для перестраховки запустите на второй консоли следующую команду: whereis -b предполагаемое_имя_сценария
Если вы получите какой-то путь, то команда с таким названием существует и вам следует выбрать другое имя. Однако, если полученный результат выглядит примерно вот так: whereis -b clean clean:
то, вероятнее всего вы выбрали удачное имя для вашего сценария.
После того как вы сохраните ваш сценарий, вам следует установить у него атрибут выполняемого файла: chmod +x clean
Хорошим тоном будет создание в вашей домашнем каталоге подкаталога bin, в котором вы будете хранить ваши сценарии: cd ~ mkdir bin mv clean ~/bin
И наконец вы должны испытать ваш сценарий на работоспособность, прежде чем отдать его cron'у. В каталоге bin напишите: ./clean
Если вы находитесь в другом каталоге напишите: clean
Если вы используйте интерпретатор C-shell и получите сообщение "Command not found", то напечатайте: rehash
и повторите запуск сценария.
Теперь мы готовы к созданию файла crontab для того что бы cron выполнял наш сценарий, а так же команду find. Зарегистрируйтесь в системе под обычным пользователем. Я регистрируюсь под именем genisis. Теперь пишите: crontab -e
для использования утилиты crontab в режиме редактирования. Если вы очень шустрый, то вы успеете увидеть сообщение перед запуском редактора vi: crontab: no crontab for genisis - using an empty one (crontab: нет файла crontab для пользователя genisis -- используем пустой файл)
Поскольку мы находимся в vi, нажмите клавишу "ESC" и следом символ "i" для входа в режим вставки, затем введите этот текст: #every morning at 4:32 search and #destroy all core or dead files #каждое утро в 4:32 искать и удалять #все core и dead-файлы 32 4 * * * find / \( -name "*.core" -or -name "dead.*" \) -print -exec rm -rf {} \;
#run the script that clears the Netscape #cache every morning at 2:48 #запуск сценария который чистит кеш #Netscape каждую ночь в 2:48 48 2 * * * ~/bin/clean
(разумеется строки 5 и 6 это на самом деле одна строка).
Обратите внимание, что синтаксис несколько отличается от синтаксиса системного файла crontab, а именно отсутствует поле "кто". Так как этот файл crontab имеет такое же имя как и имя создавшего его пользователя, поле "кто" будет равно имени создавшего файл пользователя (т.е. все указанные в этом файле команды будут выполняться только от имени пользователя который создал этот файл -- прим. переводчика). Когда вы закончите, тщательно проверьте текст на наличие ошибок, а после этого нажмите клавишу "ESC", а затем "wq". Изменения будут сохранены и вы покинете редактор. Если вы введете неверные данные в какие-нибудь поля, утилита crontab сообщит вам об этом и попросит вас заново отредактировать файл. В этом случае скажите "yes" и заново проверьте файл на опечатки. В случае если все правильно, вы увидите следующую надпись: crontab: installing new crontab
Когда вы завтра будете проверять свой почтовый ящик, вы увидите два письма от cron'а с результатами деятельности записей в вашем файле crontab. Если ваши команды выполнились успешно, то вы получите нечто похожее: From genisis@.istar.ca. Thu Sep 14 04:38:31 2000 Date: Thu, 14 Sep 2000 04:38:50 -0400 (EDT) From: genisis (Cron Daemon) To: genisis Subject: cron find / \( -name "*.core" -or -name "dead.*" \) -print -exec rm -rf {} \;
find: /usr/games/hide: Permission denied /usr/home/genisis/dead.letter /usr/home/genisis/netscape.bin.core find: /var/spool/opielocks: Permission denied find: /var/cron/tabs: Permission denied find: /var/games/hackdir: Permission denied find: /stand/etc: Permission denied find: /etc/isdn: Permission denied find: /etc/uucp: Permission denied find: /root/mail: Permission denied
From genisis@.istar.ca. Thu Sep 14 02:51:36 2000 Date: Thu, 14 Sep 2000 02:52:01 -0400 (EDT) From: genisis (Cron Daemon) To: genisis Subject: cron ~genisis/bin/clean
Clearing Netscape cache... Exiting....
Теперь несколько финальных замечаний относительно crontab. Если вы хотите увидеть содержимое своего файла crontab, напечатайте: crontab -l
Если вы хотите изменить этот файл, опять пишите crontab -e.
Только суперпользователь root имеет право видеть, у каких пользователей установлены файлы crontab. Зарегистрируйтесь под пользователем root, и попробуйте написать следующее: ls /var/cron/tabs genisis
Вы должны будете увидеть новую запись с именем пользователя, который только что создал свой crontab-файл.
Мы лишь прикоснулись к функциональности файлов crontab. В следующих статьях мы исследуем новые команды и научимся писать более сложные сценарии и обязательно добавим записей в наши файлы crontab.
Вниманию вебмастеров: использование данной статьи возможно только в соответствии
с правилами использования материалов сайта «Софтерра» (http://www.softerra.ru/site/rules/)
Как же вызывать прерывания BIOS ?
В "обычных" языках программирования вызов подпрограммы реализуется через обращение к её имени. К примеру, если в программе на C у нас есть подпрограмма display, получающая в качестве параметров атрибуты (attr) и количество отображаемых символов на экране (noofchar), то обратиться к ней мы можем просто указав её имя и необходимые параметры. Однако, здесь мы будем использовать прерывания, вызов которых осуществляется посредством инструкции ассемблера int.
Например, для вывода символов на экран в C мы используем функцию похожую на:
display(noofchar, attr);
Эквивалентно этому, оперируя средствами ассемблера и BIOS, мы напишем:
int 0x10
Как жить дальше?
Сложный по сути вопрос, но касательно системного администрирования могу дать однозначный ответ "лучше". Теперь вы знаете, откуда и для чего в вашей системе появляются файлы. Знаете, потому что появляются они из пакетов и имеют соответствующие записи в базе данных RPM. Теперь вы можете безбоязненно запускать программу обновления вашей системы (разве у вас такой нет? ;-) ), потому что она -- действительно система, система, основанная на пакетах, обладающих зависимостями, и обновление системы сведено к обновлению пакетов.
Вы ещё помните пару предложений о маршрутизаторе, в который может спокойно ударить молния? Мораль этого примера не в том, что все маршрутизаторы должны быть специализированными железками, а в словах "...копию файла его текущей конфигурации", точнее, в слове "текущей". Опять же, незамыленным взглядом посмотрите на это слово. Текущая -- значит, непрерывно меняющаяся. Жизнь не стоит на месте, выходят новые версии дистрибутивов. Главное, что должно быть неизменным -- отражение долговременных и важных изменений конфигурации вашей системы в её резервных копиях. Надеюсь, если вы будете применять такую практику, то теперь при установке даже одного действительно нужного пакета, при редактировании даже одной строчки в одном конфигурационном файле вы будете думать о нарезке свежего экземпляра того CD, который лежит запертым в сейфе и в любой ситуации позволяет вам уходить домой вовремя.
Какая еще информация хранится для каждого скан-кода
Кроме таблицы символов (и, возможно, "действий") с каждым скан-кодом связаны еще несколько переменных
метод "выравнивания" номера группы, специфичный для данной клавиши; "поведение" клавиши; набор "исключений"; реальный модификатор (modmap) и виртуальный модификатор (vmodmap), связанные с этой клавишей.
Какие атрибуты файла определяют "право доступа"
Владелец файла и группа "допущенных".
Собственно "права доступа".
Какие данные хранятся в учетной карточке?
Прежде чем перечислить - какие поля есть в учетной карточке, хотелось бы обратить внимание вот на что.
Каждому юзеру присваивается уникальный номер (user ID), именно этот цифровой номер и используется внутри операционной системы при проверке прав доступа, сборе и хранении статистики и т.д. Однако, для человека оперировать все время номерами юзеров не удобно. Поэтому, каждому юзеру кроме номера присваивается еще уникальное имя (login name).
Если в какой-нибудь команде требуется в качестве аргумента указать юзера, обычно используется это "login name". И, наоборот, если какая-либо программа в своем выводе как-нибудь упоминает конкретных юзеров, она обычно называете их этим именем, а не просто печатает номер юзера.
То есть, между user ID и name должно быть всегда однозначное соответствие. Просто user ID используется во внутренних данных системы, а name при общеннии человек-компьютер.
Итак. В учетной карточке юзера хранится
Name
Password
user ID
group ID
General information
Home dir
Shell
кроме того есть еще поля, которые часто не используются (кстати, в карточке они располагаются между group ID и General Information)
Class
Password change time
Account expiration time
Назначение этих полей.
Какие операционные системы будут работать в VM?
Не существует однозначного ответа на этот вопрос— можно сказать только, для каких операционных систем виртуальная машина прошла тестирование. В принципе, если ОС работает на архитектуре Intel и не вытворяет с аппаратной частью несусветных вещей, то она с максимальной вероятностью установится и станет работать. Совершенно достоверно работают все версии DOS и Windows, а также основные дистрибутивы Linux. Проявив определенную настойчивость, мне удалось настроить FreeBSD (проблемы были только с видео, остальное прошло нормально). Определенно работает Plan9 (на VMWare). QNX работает в ограниченных графических режимах.
Обещанный NetWare мною не тестировался, так что ничего сказать не могу. Короче, практика — лучшее мерило истины. Попробуйте — это не сложно и диск форматировать не надо.
Какие задачи поручить демонам?
Какое практическое применение имеют эти демоны и нужно ли тратить драгоценные ресурсы на их постоянное присутствие в памяти? Мы уже вообще-то видели, что в стандартной установке дистрибутива Red Hat Linux демоны crond и anacron выполняют некоторые служебные функции. Характерным примером таких задач является задача обслуживания файлов системных протоколов. Как вы знаете, в Linux (как и вообще в UNIX) постоянно ведется несколько протоколов работы, в которых фиксируются те или иные действия как пользователей, так и ядра и других программ и демонов. . И рассматриваемые в статье демоны тоже вносят свои записи в системные протоколы. Отвечает за ведение протоколов системный демон syslogd. Создаваемые им протоколы быстро растут в объеме и, если их своевременно не чистить, могут заполнить все свободное пространство на диске. В стандартной конфигурации Red Hat Linux за ростом протоколов следит скрипт logrotate, расположенный в каталоге /etc/cron.daily. При превышении объема файла протокола некоторого заданного уровня старый файл переименовывается и открывается новый, а считающиеся уже ненужными файлы уничтожаются.
Самым очевидным примером практического использования демона crond является автоматическая выдача напоминаний о приближении каких-либо важных дат или событий. Проще всего организовать такую процедуру с помощью почтового агента (обычно он постоянно запущен на включенном компьютере). Например, почтовый агент kmail из KDE позволяет просматривать сообщения из нескольких "почтовых ящиков". Поэтому достаточно настроить его еще и на получение предназначенных вам писем из почтовой системы на локальном компьютере, указать cron-у когда надо прислать напоминание и вы будете во-время оповещены о приближении любого важного для вас события.
В книге [1] приведено еще несколько примеров использования демона crond для решения таких задач, как:
чистка временных файлов, образующихся в процессе функционирования системы,
организацию учета использования системных ресурсов,
передача служебной информации по сети в периоды низкой активности.
Я приведу еще один пример практического использования демона crond, причем пример, характерный как раз для персонального (домашнего) компьютера.
Рассмотрим обычную житейскую ситуацию: вы набираете на домашнем компьютере какой-то текст или корректируете исходные тексты программы и в это время отключается электроэнергия. Событие для нашей бытовой сети, к сожалению, обычное. Покупка источника бесперебойного питания вашим семейным бюджетом, конечно, не была предусмотрена, а сохранять результаты работы каждые 15 минут вы тоже, в азарте работы, не удосужились. Я попал в такую ситуацию как раз во время работы над данной статьей. И после восстановления питания последние изменения оказались потеряны, несмотря на то, что как раз перед отключением компьютера я их сохранил и даже вышел из программы редактирования. Это в ДОС сохранение результатов редактирования приводит к тому, что они тут же записываются на диск. А в Linux относительно медленные операции чтения/записи на диск кешируются в оперативной памяти. Это существенно повышает общую производительность системы, но, если система почему-либо рушится, такой подход приводит к тому, что вы потеряете результаты своей работы несмотря на то, что вовремя нажимали кнопочку "Сохранить на диске". Вот тут нам на помощь и может прийти cron!
Идея решения проста. Напомню, что в Linux имеется специальная команда sync, предназначенная для принудительного "сброса" содержимого временных буферов памяти на диск [4]. Давайте будем выполнять ее в автоматическом режиме каждые 15 (или 30) минут. Для этого достаточно прописать в crontab-файл строку следующего вида
0,30 * * * * date; sync; echo "запись данных на диск"
А чтобы сообщения о выполнении этой операции не переполняли ваш почтовый ящик, отправляйте их в никуда (см. выше). Конечно, и самому не надо забывать через каждые полчаса нажимать кнопочку "Сохранить на диске", иначе никакой cron не спасет вас от потери данных при неожиданном выключении питания.
Какое место занимает этот драйвер в работе FreeBSD?
Как любой Юникс, FreeBSD дает возможность пользователю общаться с компьютером через различные типы терминалов. Это может быть и "железный" терминал, подключенный, например, через COM-порт и другой компьютер, соединяющийся по сети (программой telnet). Но основным терминалом конечно же является дисплей и клавиатура той "писишки", на которой и запущена FreeBSD.
Естественно, работа программ (их ввод и вывод) не должны существенно отличаться как при работе с "железным" терминалом, так и при работе с "родными" дисплеем и клавиатурой. Поэтому, даже при вводе/выводе на терминал компьютера программа никогда не обращается к соответствующему "железу" (видео-контроллер и контроллер клавиатуры) напрямую.
Конечно, и в других операционных системах (даже таких простых, как MS DOS) обычная программа не "лезет в железо", а пользуется библиотечными функциями (getchar, print и т.п.) или функциями BIOS. Но, в данном случае, речь идет о том, что даже между самой системой FreeBSD (системными библиотеками) и "железными" устройствами, стоят соответствующие "драйверы терминалов", которые и обеспечивают "однообразие" при работе с очень разными терминалами.
Так вот, syscons - как раз такая программа, которая с одной стороны общается непосредственно с регистрами контроллеров (видео и клавиатуры) вашей "писишки", а с другой стороны изображает для операционной системы некоторое законченное устройство, наподобие внешнего терминала.
Надо заметить, что в FreeBSD есть еще один "альтернативный" драйвер консоли - pcvt. Для того, чтобы заменит на него syscons надо персобрать ядро системы с соответствующими опциями.
Но, поскольку, в "стандартной поставке" FreeBSD "встроен" именно syscons, он же и используется в большинстве случаев.
Поэтому я ограничусь только описанием syscons (тем более, что pcvt я практически не знаю :-)
Каталог /bin
Каталог /bin содержит команды, которые могут использоваться как системным администратором, так и рядовыми пользователями, причем только те команды, которые необходимы, когда никакая другая файловая система, кроме корневой, еще не смонтирована (например, в однопользовательском режиме). В этом каталоге могут также содержаться команды, которые используются не напрямую пользователем, а включаются в сценарии оболочки (скрипты). Исполняемые файлы, которые не так важны, чтобы быть расположенными в каталоге /bin, должны размещаться в каталоге /usr/bin. Те утилиты, которые необходимы только рядовым пользователям (файлы системы X Window, chsh, и так далее) обычно не так необходимы, чтобы размещаться в корневой файловой системе (в корневом разделе диска).
В /bin должны иметься следующие команды или символические ссылки на соответствующие команды:
cat, chgrp, chmod, chown, cp, date, dd, df, dmesg, echo, false, hostname, kill, ln, login, ls, mkdir, mknod, more, mount, mv, ps, pwd, rm, rmdir, sed, sh, stty, su, sync, true, umount, uname.
Следующие программы или символические ссылки на программы должны находиться в каталоге /bin, если только соответствующие пакеты установлены в системе:
csh, ed, tar, cpio, gzip, gunzip, zcat, netstat, ping.
В каталоге /bin не должно быть подкаталогов.
Каталог /boot
Этот каталог содержит все, что необходимо в процессе загрузки, исключая конфигурационные файлы и установщик карты загрузки (the map installer). Таким образом, в /boot хранятся данные, которые используются до того, как ядро начинает исполнять программы пользователя. Здесь же находятся резервные сохраненные копии главной загрузочной записи (master boot sectors) и другие данные, которые не подлежат прямому редактированию.
Ядро операционной системы должно быть расположено либо в корневом каталоге /, либо в /boot . Программы, необходимые загрузчику для организации загрузки файлов, должны быть расположены в /sbin. Конфигурационные файлы загрузчика должны размещаться в /etc.
Каталог /dev
Каталог /dev - это место расположения специальных файлов устройств. На случай, если потребуется создавать файлы устройств вручную, каталог /dev должен содержать команду MAKEDEV, которая может создать файл устройства в случае необходимости.
Каталог /etc
Каталог /etc содержит конфигурационные файлы и каталоги, специфичные для данной конкретной системы. В каталоге /etc не должно быть бинарных файлов. В соответствии со стандартом FHS этот каталог в обязательном порядке должен содержать подкаталог /opt, в котором должны размещаться подкаталоги с конфигурационными файлами отдельных пакетов и приложений. Для каждого установленного пакета <package> должен создаваться конфигурационный каталог /etc/opt/package. Надо отметить, что не все дистрибутивы следуют этому правилу: часто конфигурационные каталоги пакетов размещаются непосредственно в /etc.
Следующие каталоги и файлы либо символические ссылки на них должны быть расположены в /etc, если соответствующие пакеты установлены в системе:
Таблица 3. Подкаталоги и файлы в каталоге /etc
| /X11 | Конфигурационные файлы системы X Window | ||
| /sgml | Конфигурационные файлы для SGML и XML | ||
| csh.login | Общесистемный инициализационный файл для C shell logins | ||
| exports | Список контроля доступа для сетевой файловой системы NFS | ||
| fstab | Постоянная информация для монтирования файловых систем | ||
| ftpusers | Список контроля доступа для демона FTP | ||
| gateways | Файл, содержащий список шлюзов для демона routed | ||
| gettydefs | Установки терминала, используемые демоном getty | ||
| group | Файл, определяющий списки групп пользователей в системе | ||
| host.conf | Файл конфигурации для системы разрешения имен | ||
| hosts | Постоянная информация об именах хостов | ||
| hosts.allow | Список хостов, с которых разрешен доступ в систему | ||
| hosts.deny | Список хостов, с которых запрещен доступ в систему | ||
| hosts.equiv | Список доверенных (разрешенных) имен хостов для rlogin, rsh, rcp | ||
| hosts.lpd | Список доверенных (разрешенных) имен хостов для демона печати lpd | ||
| inetd.conf | Конфигурационный файл для демона inetd | ||
| inittab | Конфигурационный файл для демона init | ||
| issue | Сообщение, выдаваемое системой до регистрации пользователя | ||
| ld.so.conf | Список дополнительных каталогов для поиска разделяемых библиотек | ||
| motd | Сообщение, выдаваемое системой после регистрации пользователя | ||
| mtab | Динамически изменяющаяся информация о смонтированных файловых системах | ||
| mtools.conf | Конфигурационный файл для mtools | ||
| networks | Статическая информация о сетевых именах | ||
| passwd | Файл паролей пользователей | ||
| printcap | База данных с настройками принтеров для демона lpd | ||
| profile | Общесистемный файл инициализации для оболочки, запускаемой при входе пользователя в систему | ||
| protocols | Перечень IP-протоколов | ||
| resolv.conf | Конфигурационный файл для системы разрешения имен | ||
| rpc | Перечень протоколов удаленного вызова процедур | ||
| securetty | Файл со списком устройств, с которых может заходить пользователь root | ||
| services | Имена портов для сетевых сервисов | ||
| shells | Список путей доступа для имеющихся в системе оболочек | ||
| syslog.conf | Конфигурационный файл для демона syslogd |
Файл mtab не соответствует неизменяемой природе файлов, размещенных в /etc; он помещен в данный каталог в виде исключения по историческим причинам. Впрочем, в некоторых системах он является символической ссылкой на /proc/mounts, в этом случае делать исключение не требуется.
Каталог /etc/X11 - это место размещения всех конфигурационных данных для X11, специфичных для данного хоста. Эта директория необходима для того, чтобы обеспечить локальное управление системой X Window в том случае, когда файловая система /usr монтируется только на чтение.
Следующие файлы или символические ссылки на соответствующие файлы должны находиться в /etc/X11:
Xconfig - Конфигурационный файл для ранних версий XFree86
XF86Config - Конфигурационный файл для XFree86 версий 3 и 4
Xmodmap - Глобальный файл модификации клавиатуры в X11
Среди подкаталогов в /etc/X11 могут находиться отдельные подкаталоги с конфигурационной информацией для xdm и других программ (например, для оконных менеджеров), которые в такой информации нуждаются.
Каталог /home
В небольших системах каждый домашний каталог пользователя является одним из непосредственных подкаталогов каталога /home, таких как /home/smith, /home/torvalds, /home/operator и так далее. В больших системах (особенно когда каталоги /home являются разделяемыми между многими хостами посредством NFS) полезно объединить домашние каталоги в группы, введя подкаталоги групп такие как /home/staff, /home/guests, /home/students и так далее. Но как бы то ни было, структура домашних каталогов различается от хоста к хосту. Следовательно, никакая программа не должна полагаться на какие-то предположения о структуре домашних каталогов.
Каталог /lib
Каталог /lib содержит те разделяемые библиотеки, которые необходимы для загрузки системы и запуска команд, расположенных в каталогах /bin и /sbin.
По крайней мере, один из файлов, соответствующих каждому из следующих шаблонов, должен найтись в данном каталоге (это могут быть либо реальные файлы, либо символические ссылки):
libc.so.* - Динамически подсоединяемые библиотеки C;
ld* - Загрузчик/линковщик времени выполнения.
По историческим причинам, если препроцессор языка Си установлен, файл /lib/cpp должен быть ссылкой на него.
Не должны располагаться в /lib разделяемые библиотеки, которые необходимы только исполняемым файлам, расположенным в /usr (таким, как бинарные файлы системы X Window). В частности, библиотека libm.so.* может быть расположена в /usr/lib, если она не требуется никаким программам из /bin или /sbin.
Более одного варианта каталога /lib может существовать в системах, поддерживающих более одного формата исполняемых файлов (например, 32-х и 64-х разрядные форматы), при этом для каждого формата требуется свой отдельный вариант разделяемых библиотек (которые могут называться /lib32 и /lib64).
Каталог /mnt
Эта директория предназначена для того, чтобы системный администратор мог временно монтировать файловые системы по мере необходимости. Содержимое этого каталога индивидуально для каждой системы и не должно никаким образом влиять на работу запускаемых программ.
Этот каталог не должен использоваться программами инсталляции ПО; для создания и хранения временных файлов на этапе инсталляции должны использоваться временные каталоги, не используемые системой
Каталог /opt
Стандарт FHS резервирует каталог /opt для установки дополнительных пакетов программного обеспечения. Предполагается, что любой пакет, который устанавливается в каталог /opt, должен размещать свои статические файлы в отдельной каталоговой структуре /opt/<package>, где <package> - название соответствующего пакета программного обеспечения.
Как правило, все данные, необходимые для поддержки функционирования пакета, должны присутствовать в каталоге /opt/<package>, включая файлы, копируемые в каталоги /etc/opt/<package> и /var/opt/<package> а также специально создаваемые для пакета каталоги в /opt.
Каталоги /opt/bin, /opt/doc, /opt/include, /opt/info, /opt/lib и /opt/man зарезервированы для использования локальным системным администратором. Пакеты могут предоставлять "front-end" файлы, которые локальный системный администратор может разместить в этих зарезервированных каталогах (либо путем копирования, либо установив ссылку), но любой пакет должен нормально функционировать и в случае отсутствия этих зарезервированных директорий.
Программы, вызываемые на исполнение пользователем, должны располагаться в каталоге /opt/<package>/bin. Если пакет ПО содержит в своем составе страницы обычного в UNIX интерактивного руководства man, они должны устанавливаться в каталог /opt/<package>/man, который должен иметь такую же структуру, как и каталог /usr/share/man.
Файлы пакета, которые являются переменными (изменяемыми при выполнении стандартных операций), должны устанавливаться в /var/opt. Специфичные для хоста конфигурационные данные должны устанавливаться в /etc/opt.
Никакие файлы пакета не должны размещаться вне каталогов /opt, /var/opt и /etc/opt, кроме тех файлов, которые должны оказаться в других местах по той причине, что иначе пакет не сможет функционировать нормально. Например, файлы блокирования устройств должны располагаться в /var/lock, а файлы устройств должны располагаться в /dev.
Дистрибутивы могут устанавливать программное обеспечение в каталог /opt, но не должны модифицировать или удалять ПО, установленное местным системным администратором, без разрешения этого самого администратора.
Каталог /root
Каталог /root - это домашний каталог суперпользователя. Он может быть задан разработчиком или определен при инсталляции системы, но рекомендуемое место его расположения по умолчанию - корневая файловая система.
В стандарте FHS подчеркивается, что бюджет суперпользователя должен использоваться исключительно для системного администрирования и его не рекомендуется использовать для выполнения задач, которые могут быть выполнены непривилегированным пользователем. По этой причине не стоит размещать подкаталоги для почты и других приложений в домашнем каталоге пользователя root. Почта для таких администраторских ролей как root, postmaster и webmaster должна пересылаться соответствующему пользователю.
Каталог /sbin
Утилиты для выполнения задач системного администрирования (и другие команды, используемые только пользователем root) размещаются в /sbin, /usr/sbin и /usr/local/sbin. Каталог /sbin содержит исполняемые файлы, необходимые для загрузки системы и ее восстановления в различных ситуациях (restoring, recovering, and/or repairing the system), не попавшие в каталог /bin.
Единственная команда, которая обязательно должна присутствовать в /sbin, это команда shutdown - команда остановки системы.
Следующие команды или символические ссылки должны быть размещены в /sbin, если только соответствующие пакеты установлены в системе:
| fastboot | Команда перезагрузки системы без проверки дисков | ||
| fasthalt | Команда остановки системы без проверки дисков | ||
| fdisk | Программа переразбиения диска | ||
| fsck | Утилита для проверки и восстановления файловых систем | ||
| fsck.* | Утилиты для проверки и восстановления отдельных типов файловых систем | ||
| getty | Программа getty | ||
| halt | Команда остановки системы | ||
| ifconfig | Утилита конфигурирования сетевых интерфейсов | ||
| init | Первоначальный процесс | ||
| mkfs | Команда создания файловой системы | ||
| mkfs.* | Команда создания файловой системы конкретного типа | ||
| mkswap | Команда создания файла или раздела подкачки (swap-раздела) | ||
| reboot | Команда перезагрузки системы | ||
| route | Утилита определения таблицы статической IP-маршрутизации | ||
| swapon | Утилита подключения механизма свопинга | ||
| swapoff | Утилита отключения свопинга | ||
| update | Демон периодической очистки системных буферов |
Принять решение о том, какие программы разместить в каталогах "sbin", довольно просто: если обычный пользователь (не системный администратор) когда-либо запускает программу, она должна размещаться в одном из каталогов "bin". Обычные пользователи не должны указывать каталоги sbin в списке путей, просматриваемых по умолчанию (в своей переменной PATH).
Такие, к примеру, файлы, как chfn, которые пользователи запускают очень редко и только в особых случаях, должны, тем не менее, быть расположены в /usr/bin. Команда ping, хотя она абсолютно необходима суперпользователю для решения задач сетевой диагностики и восстановления сети, часто используется и рядовыми пользователями, и по этой причине должна размещаться в /bin.
Авторы стандарта рекомендуют предоставить всем пользователям право на чтение и выполнение для всех файлов, расположенных в /sbin, кроме, может быть тех программ, для которых установлены биты setuid и setgid. Разделение каталогов /bin и /sbin делается не из соображений безопасности и не для того, чтобы лишить пользователей возможности видеть системные утилиты. Целью такого деления является установление явного различия между исполняемыми файлами, которые используются всеми, и теми утилитами, которые в основном используются для решения административных задач. С точки зрения безопасности нет никаких преимуществ в том, чтобы сделать /sbin недоступным для пользователей.
Каталог /temp
Каталог /tmp предназначен для хранения временных файлов, создаваемых в процессе работы различных программ. При этом программы не должны предполагать, что какой-либо файл в каталоге /tmp сохранится при следующем запуске программы.
Хотя данные, сохраняемые в каталоге /tmp, могут удаляться по правилам, специфичным для каждого хоста, рекомендуется удалять все файлы и каталоги в /tmp при каждой загрузке системы. FHS вводит последнюю рекомендацию на основе исторических прецедентов и общей практики, но не считает ее обязательным требованием, поскольку вопросы системного администрирования не являются предметом этого стандарта.
Каталоговая структура /usr
Каталог /usr - это второй по важности раздел файловой системы. /usr содержит разделяемые данные, предназначенные только для чтения. Это означает, что /usr может быть доступен с различных FHS-совместимых хостов и права записи в него не должно быть. Любая информация, которая является специфичной для конкретного хоста или может изменяться со временем, должна записываться в другое место.
Следующие каталоги или символические ссылки на каталоги должны присутствовать в /usr.
| bin | Это основное место для размещения исполняемых файлов системы.
/usr/bin/X11 должен быть символической ссылкой на /usr/X11R6/bin если последний существует. Следующие файлы или символические ссылки на файлы должны быть размещены в /usr/bin, если только соответствующие пакеты установлены в системе: perl - Язык Perl (The Practical Extraction and Report Language) python - Интерпретирующий язык Python tclsh - Оболочка интерпретатора Tcl wish - Оболочка Tcl/Tk expect - Программа для организации интерактивного диалога Поскольку интерпретаторы скриптов оболочки (вызываемые командой вида #!<path> в первой строке скрипта) не могут полностью полагаться на эту строку, имеет смысл стандартизовать их расположение. Размещение интерпретаторов оболочек Борна и C-shell уже зафиксировано в каталоге /bin, но интерпретаторы языков Perl, Python и Tcl часто размещаются в самых разных местах. В каталоге /usr/bin можно оставить только символические ссылки на действительное местоположение интерпретаторов. | ||
| include | Это место, где должны быть размещены все системные подключаемые файлы общего пользования для языка программирования C, в частности файлы заголовков (header files), включаемые в программы на языке C.
Символическая ссылка /usr/include/X11 должна указывать на /usr/X11R6/include/X11, если только последний существует. | ||
| lib | Каталог /usr/lib содержит объектные файлы, библиотеки и внутренние исполняемые файлы, которые не могут вызываться непосредственно пользователями из командной строки или скриптов оболочки. (Различные архитектурно-зависимые статические файлы и подкаталоги, специфичные для отдельных приложений, должны размещаться в /usr/share. )
Приложения могут использовать отдельные подкаталоги в /usr/lib. Если приложение использует подкаталог, все архитектурно-зависимые данные, используемые только этим приложением, должны размещаться внутри этого подкаталога. (Например, подкаталог perl5 для модулей и библиотек Perl 5.) По историческим причинам /usr/lib/sendmail должен быть символической ссылкой на /usr/sbin/sendmail, если последний существует. (Некоторые исполняемые команды, такие как makewhatis и sendmail тоже по традиции размещаются в /usr/lib. makewhatis - это внутреннй исполняемый файл и должен размещаться в подкаталоге для бинарных файлов; пользователям предоставляется доступ только к catman. Исполняемые файлы последних версий sendmail теперь по умолчанию располагаются в /usr/sbin. Кроме того, системы, использующие sendmail-совместимые агенты передачи почты, должны делать /usr/sbin/sendmail символической ссылкой к соответствующему исполняемому файлу.) Если /lib/X11 существует, /usr/lib/X11 должен быть символической ссылкой на /lib/X11, либо на тот каталог, на который ссылается /lib/X11. (Специфичные для каждого хоста данные для системы X Window не должны размещаться в /usr/lib/X11. Специфичные для хоста конфигурационные файлы, такие как Xconfig или XF86Config должны храниться в /etc/X11. Это требование относится и к таким фонфигурационным данным, как system.twmrc, даже если это только символическая ссылка на более общий конфигурационный файл, вероятно в /usr/X11R6/lib/X11). | ||
| local | Каталоговая структура для локально устанавливаемого программного обеспечения (пустая непосредственно после инсталляции системы) | ||
| sbin | Этот каталог содержит системные команды, используемые исключительно системным администратором, не являющиеся жизненно-важными для системы. Программы для выполнения задач системного администрирования, которые необходимы для восстановления системы, монтирования /usr, или для других самых важных системных задач, должны размещаться в /sbin. (Локально устанавливаемые программы для системного администрирования должны размещаться в /usr/local/sbin.) | ||
| share | Архитектурно-независимые данные | ||
