Четыре варианта организации сетевых служб в VMware
«No networking». Виртуальная машина работает сама по себе, не имея возможности взаимодействовать с операционной системой базового компьютера или другими компьютерами. Этот вариант стоит рассматривать в том случае, когда виртуальная машина будет использоваться для тестирования программного обеспечения или для обеспечения безопасности хранимых на ней данных. Задать такую конфигурацию очень просто: достаточно при конфигурировании виртуальной машины не подключать сетевую плату. «Host-only networking». Виртуальный компьютер сможет взаимодействовать с операционной системой базового компьютера и любым виртуальным компьютером, запущенным на базовом компьютере, также имеющим сетевые возможности. Но виртуальный компьютер в такой конфигурации не сможет взаимодействовать с системами, находящимися вне базового компьютера (если только не используется прокси-сервер на базовом компьютере). Создается своего рода виртуальная частная сеть, состоящая из базового компьютера и всех запущенных на нем виртуальных. Обычно хосты такой сети используют стек протоколов TCP/IP, хотя использовать именно его не обязательно. Но какие бы протоколы не использовались, каждый компьютер в такой сети должен иметь свой адрес. Адреса могут назначаться «статически» или «динамически»; в последнем случае используются такие протоколы, как DHCP. Данный вариант конфигурации можно использовать, когда базовый компьютер не подключен ни к какой сети, или когда требуется изолировать виртуальный компьютер от внешних систем. Такая конфигурация аналогична соединению внутренней сети с Internet через межсетевой экран или прокси-сервер. «Bridged networking». Виртуальная машина будет подключаться к локальной сети, используя реальную Ethernet-плату основного компьютера, выполняющую функции «моста» между виртуальной машиной и физической сетью. Это позволяет виртуальному компьютеру выглядеть с точки зрения реальной сети как полноценный хост. Назначение сетевых адресов осуществляется в соответствии с правилами, принятыми в реальной локальной сети: можно либо подключаться по протоколу DHCP, либо получить у администратора статический IP-адрес. Виртуальная машина, подключенная таким образом, может использовать любые службы локальной сети, к которой она подключена: принтеры, файловые серверы, маршрутизаторы и т.д. Точно так же она может предоставить в сеть какие-то из своих ресурсов. Это наиболее часто используемая конфигурация сетевого подключения виртуального компьютера. Для того чтобы настроить данный вариант сетевой конфигурации, необходимо установить сетевую плату и выбрать для нее тип подключения «Bridged»; в операционной системе виртуального компьютера надо произвести настройку сетевых служб. «Custom networking». Виртуальный компьютер может использовать как реально существующее Ethernet-соединение основного компьютера, так и виртуальную сеть. Этот вариант предоставляет широкие возможности по построению сети из виртуальных компьютеров. Например, можно организовать виртуальную частную сеть из виртуальных компьютеров, размещающихся на нескольких физических хостах реальной сети. Однако настройка таких сетей требует хорошего понимания принципов построения локальных сетей и потому может быть рекомендована только опытным пользователям. Более того, процедура настройки этого варианта в фирменной документации практически не описана.
Журнал "Открытые системы", #11, 2001 год // Издательство "Открытые Системы" (http://www.osp.ru/)
Постоянный адрес статьи: http://www.osp.ru/os/2001/11/018.htm
Chkconfig
Манипуляция файлами в /etc/rc.d (какие сервисы запускать и останавливать при переходе с уровня на уровень). Криво сделан. Проще вручную сделать, но кругом натыкано проверок с помощью chkconfig. Он действует в терминах: включен/выключен. На самом деле для сервиса м.б. как процедура включения, так и выключения в любых комбинациях. В результате он выдает ответ "запущен сервер или нет" в зависимости от того, какой файл создан в директории последним - K или S!
Ключи:
--list (получить список сервисов) --add имя (добавить сервис в список отслеживаемых) --del имя --level уровень имя [ on | off | reset ] (поднять/опустить/сбросить сервис на указанном уровне)
Что дальше ?
После загрузки с дискеты вы можете любоваться строкой на экране. И всё это благодаря прерываниям BIOS. В следующей статье из этой серии я надеюсь написать о том как переключать процессор в защищённый режим. А до тех пор, пока!
Что делать?
Так что же делать?
Давайте сначала найдем хотя бы одну программу, которая работает с "XKB руссификацией" правильно. Что делать с "неправильными" программами решим потом.
Лучше всего взять программу xterm, если, конечно, она у вас из того же "комплекта", что и X-сервер. То есть собрана с "текущей Xlib" и с теми же "опциями", что и Xlib.
Сборка своего пакета не запутывает вещи, а наоборот, концентрирует и систематизирует ваши сведения касательно определённого ПО в одном месте -- пакете, содержащем это ПО. Самый, казалось бы, маленький архив с исходными текстами может породить столько проблем, сколько не сможет иной многомегабайтный монстр. Если сложность spec-файла для пакета явно превышает сложность функций, пакетом выполняемых, подумайте, не подыскать ли аналогичное ПО, у автора которого тараканов в голове меньше. Только после того, как вы соберёте RPM, вы сможете оценить количество потенциальных проблем, которые были ликвидированы самим наличием уже готового пакета. Постарайтесь при сборке пакета не забывать о Linux Filesystem Standard, определяющем, что где должно находиться, потому что авторы многих утилит и системных программ предполагали, что утилиты эти будут работать именно в таким образом организованной файловой системе.
Итак, вы имеете список стандартных пакетов, и, возможно, несколько самосборных RPM. Возьмите подходящий по параметрам запасной сервер и выполните установку новой системы. Сохраните список пакетов из инсталлятора (если он этого не умеет, вы вправе изменить свои предпочтения). Несколько слов о наборе пакетов: выбор "устанавливать всё" не так хорош, как кажется. Во-первых, вы получите пакеты, которые никогда не будут использоваться, но будут требовать обновления. Во-вторых, если какой-то из используемых вами стандартных или самосборных пакетов имеет неправильные зависимости, вы этого просто не заметите, а неправильные зависимости -- вещь неприятная и определённый процент сбоев в будущем. В-третьих, на специализированном сервере собственно система вместе с ПО может занимать 300 мегабайт, так зачем же выбрасывать лишние гигабайты (5-10 и более в зависимости от дистрибутива) на ветер? Дисковое пространство лишним не бывает, это проверенное временем правило.
Оглянитесь, не осталось ли что-то за бортом. Я, например, чаще всего забывал установить утилиты сетевой диагностики. Если да, то повторяйте установку с сохранением списка пакетов до достижения состояния "ни прибавить, ни отнять". Поздравляю, теперь вы действительно знаете, что именно работает у вас на конкретно взятом сервере. Дискета, как известно, вещь дешёвая и ненадёжная, поэтому лучше всего будет поместить её образ и на CD с конфигурационными файлами. Основная часть работы проделана, теперь необходимо только поддерживать ваши запечатлённые на обычном CD-R концентрированные сведения актуальными. Восстановление самого ценного -- данных -- в терминах работы с пакетами не формулируется и сильно зависит от самих данных, так что постарайтесь прорепетировать эту сцену самостоятельно, но с соблюдением тех же требований: только чистый сервер и стопка компакт-дисков в руках. Если всё, абсолютно всё, работает так же, как и на производственном сервере, попробуйте их подменить и подождите неделю. Переходите к следующему серверу.
Что делать если этого не хватает?
Проблема первая
Проблема вторая
Итак. Что же делать, если "нужно что-то большее"?
Как же добавить к файлу еще одну группу-категорию?
Решение первое
Решение второе
Так что же делать?
ACL
Рассмотренная система ограничения доступа к файлам и директориям, конечно, имеет свои недостатки.
Что делать с "неправильными" программами?
(Если мои советы вам не помогли (или есть какие-то "непонятки"), можете обращаться ко мне "мейлом".
Но я не хотел бы видеть вопросы типа - "я все сделал, как написано, но все равно не работает". Будет лучше, если вы подробно напишете о проделанных тестах и их результатах.)
Иван Паскаль pascal@tsu.ru
Вообще-то, первый ответ - узнайте - не решены ли эти проблемы в последней версии данной программы. Возможно "бороться" уже не надо. И только если проблемы остались, то ...
Прежде чем пытаться давать какие-то рецепты, я хотел бы поделить все "неправильные" программы на несколько категорий.
Программы "в исходниках".
Мультиязыковые программы.
Программы "в бинарниках".
Что еще можно делать с qlogin
Итак, теперь вы знаете как получить автоматически зарегистрированные оболочки на разных виртуальных консолях. Но простейшим изменением процедуры вы можете автоматически запускать другие программы на конкретных виртуальных консолях или последовательных терминалах. Просто укажите
qlogin /dev/tty5 root --command=/bin/top --noutmp
Допустим, ваш компьютер является узлом торговой системы магазина. Терминалами будут последовательные терминалы в кассовых аппаратах. Кассиры не желают регистрироваться в Linux и не желают видеть shell. Если программой POS является /usr/local/bin/pos, вы можете сделать следующее:
qlogin /dev/ttyS1 cashier --uid=500 --gid=500 --command=/usr/local/bin/pos --arg0=POS --homedir=/
В этом случае, программе pos, возможно, потребуется некоторая инициализация последовательного порта, например, установка его скорости. В традиционной моделе Unix-регистрации getty это делает перед тем, как отправит туда приглашение к регистрации.
Что еще нам нужно
as86 Это ассемблер. С его помощью исходная программа на ассемблере преобразовывается в объектный файл. ld86 Это компоновщик. Он конвертирует сгенерированный as86 объектный код в "актуальный" (т.е. пригодный к загрузке на выполнение -- прим. редактора ) машинный код. Это будет машинный язык, понятный процессору 8086. gcc Компилятор C. Нужен для компиляции программы, которая "доставит" наш код в загрузочный сектор. Свободная дискета Флоппи-диск, который будет использоваться для хранения нашей операционной системы (Перевод дословный. Судя по всему, автор об этом расскажет в следующих статьях. В этой же идет речь только о маленькой программке, показывающей на экране символ "A". Прим.перев.). К тому же будет выполнять функции загрузочного устройства. Старый добрый Linux Уверен, вы знаете, о чем я.
as86 и ld86 присутствуют в большинстве стандартных дистрибутивов. Если же их у вас нет, то вы можете взять их на сайте http://www.cix.co.uk/~mayday/ . Они оба включены в один пакет -- bin86. Кое-что из документации вы можете найти здесь www.linuxdoc.org/HOWTO/Assembly-HOWTO/as86.html.
Что еще почитать?
Естественно, man'уалы, имеющие отношение к теме.
man 5 passwd - описывает структуру учетной карточки (user account)
man adding_user - общие слова о добавлении юзера. Кстати, там есть рекомендации - каким должно быть Login name
Утилиты для регистрации нового юзера. А, также, для удаления, изменения полей в учетной карточке и т.п.
man pwd_mkdb
man vipw
man adduser
man pw
Утилиты для внесения изменений.
man passwd - изменение пароля
man chpass - другие изменения в учетной карточке
man pw - тоже делает изменения в учетной карточке
Утилиты для удаления юзера.
man rmuser
man pw
К вопросу о временной блокировке входа юзеру.
man login.access
man login.conf
А, также, в каждом из них есть раздел See Also (смотри также...). Их тоже можно почитать, хотя, в основном, они все ссылаются друг на друга.
Иван Паскаль pascal@tsu.ru
Что изменять
Вам не нужно быть разработчиком ядра, чтобы пользоваться /proc, а базовое понимание этой структуры отлично вам поможет. Вы можете найти, что вам не нужно знать обо всем в /proc, до тех пор пока пользователь не попросит вас увеличить производительность и вы должны будете изучить куда вносить изменения. Файловая система /proc помогает администратору в этом через свою структуру и атрибуты файлов.
Каждый файл в /proc имеет особый набор атрибутов и может принадлежать конкретному пользователю по его ID. Сделано это очень аккуратно, так что правильная работа обеспечена и администратору и пользователям. Следующий список обобщает какие атрибуты могут быть у файлов:
Read-only: Файл не может быть изменен ни каким пользователем; используется для представления системной информации
Root-write: Если файл может быть изменен, то изменения может вносить только пользователь root
Root-read: Некоторые файлы могут быть не читаемы для обычных пользователей системы, только для root
Other: Вы можете найти другие комбинации, чем перечисленные выше, по различным причинам
В основном в /proc вы найдете файлы read-only за исключением /proc/sys, которая содержит большинство параметров ядра и предназначена для изменения во время работы системы. Как результат в этой статье рассматривается в основном эта директория.
Последнее, что вам нужно знать о изменении файлов в /proc - это то, что нужно записывать в эти файлы. Вы заметите, что некоторые из файлов могут быть легко прочитаны человеком, а некоторые являются файлами данных и могут быть прочитаны только при специальных утилит таких как top, lspci,и free. Вы также заметите, что эти легко читаемые файлы имеют два различных формата: некоторые являются бинарными ключами, а другие содержат больше информации. Файлы с бинарными ключами содержат только 0 (выключено) или 1 (включено) для некоторых функций ядра.
Что может поменять сам юзер в своей учетной карточке?
Естественно, любой юзер может поменять свой пароль (и даже желательно, чтобы он это делал время от времени).
Делается это командой passwd, той же, которой пользуется администратор. Разница в том, что администратор может поменять пароль любому юзеру, вызвав эту команду с именем юзера в качестве аргумента. А обычный юзер может поменять только свой пароль.
Кроме того, юзер, как и администратор, может воспользоваться программой chpass. Естественно, он может редактировать только свою учетную карточку. При этом, он сможет поменять в ней только поля Shell и General information
(свое реальное имя, адрес, телефон).
Иван Паскаль pascal@tsu.ru
Что можно сделать?
Ну, во-первых, давайте вообще забудем пока про символ ISO_Next_Group, к которому "прицеплено" такое неудобное "действие". (Вообще-то, семантику ISO_Next_Group можно и переделать, но пока отложим этот вопрос).
Для простоты рассмотрения будем считать, что переключение у вас делается одной клавишей (обычно - это CapsLock),а не комбинацией клавиш (типа - Shift+Shift или Alt+Shift).
Напомню, что непосредственно в описании клавиши можно указать "действия", причем, разные для разных групп.
Кстати. Напомню, что, во-первых, большинство изменений мы будем делать в файле типа xkb_symbols. А, во-вторых, поскольку эти изменения не просто дополняют существующие определения клавиш, а изменяют их радикально, то лучше всего добавлять их в "общую конфигурацию" не "приплюсовыванием", а отдельной инструкцией replace, например -
xkb_symbols { include "en_US(pc104)" replace "new.symbols" };
(Вообще-то, можно "способ добавления" replace указывать в файле перед каждой инструкцией. Но это, почему-то, не всегда срабатывает.)
Что можно требовать от руководства
Иногда руководство не уделяет достаточно внимания материально-технической базе сисадмина. Надо брать это в свои руки. Обоснуйте начальству необходимость покупки различных CD-ROM'ов, дискет и причих носителей. Сисадмину также необходимы инструменты, спиртовые салфетки, другие расходные материалы.
Не следует забывать и о литературе. В арсенале надо иметь как периодическую литературу ("К+П" - обязательно :)), так и большие справочники. Если возникнут проблемы с аргументацией, приведите в пример бухгалтерию, которая наверняка себе что-то выписывает. Объясните, что информационные технологии меняются так же быстро, как и законы Украины, и вам надо быть в курсе.
Что мы будем делать теперь ?
На этот раз наш исходный код состоит из двух программ на ассемблере и одной на C. Первый файл (на ассемблере) -- это код загрузочного сектора. В нём хранятся инструкции, копирующие второй сектор флоппи-диска в сегмент памяти 0x500 (абсолютный адрес 0x5000)[2]. Операция выполняется при помощи прерывания BIOS 0x13. После этого код загрузчика передаёт управление по адресу 0x500:0 (сегмент -- 0x500, смещение -- 0). Код второго файла на ассемблере выводит на экран сообщение, используя прерывание BIOS 0x10. Программа на C предназначена для записи исполняемого кода программ на ассемблере в 1-й и во 2-й сектора дискеты.
Что надо удалить?
Во-первых, домашнюю директорию юзера. Кстати, если администратор не предпринимал никаких действий, чтобы дать юзеру возможность писать в другие директории, то все файлы, которые мог "наплодить" юзер должны лежать в его Home dir. Если же вы дали юзеру права создавать файлы в других диркториях (в публичном ftp архиве или в директории www сервера, например), то, возможно, надо "почистить" и там.
Во-вторых, "почтовый ящик" юзера в директории /var/mail. Сделайте это обязательно, даже если юзер просил "пока не удалять почту" (или хотя бы уберите этот файл из /var/mail). Дело в том, что название этого файла совпадает с Name юзера, а права на чтение/запись определяются его user ID, и, естественно, должны соответствовать друг-другу.
Не вдаваясь в подробности, могу сказать, что если вы вскоре зарегистрируете нового пользователя с тем же user ID (он же освобождается), но с другим именем, или наоборот - с таким же именем, как у старого юзера, но с другим user ID, то у этого нового юзера возникнут серьезные проблемы с получением почты.
В-третьих. Могут быть еще где-то раскиданы файлы, владельцем которых был этот юзер. Например, в директории /tmp, /usr/tmp, /var/tmp.
Найти все эти файлы можно с помощью программы find. Например, так
find / -user vasia
(Обратите внимание, первый аргумент - директория, начиная с которой искать. В данном примере это корневая, то есть будут просмотрены все файлы в системе. С одной стороны это хорошо - ничего не пропустите, но, с другой стороны, если у вас стоит ньюс-сервер или огоромный ftp-архив, то ждать придется долго).
С помощью этой же команды можно и удалить все найденные файлы
find / -user vasia -delete
однако, поскольку она не спрашивает подтверждения, этот метод очень опасный. Лучше уж заставить ее выполнять команду rm ( с подтверждением) для каждого найденного файла
find / -user vasia -exec rm -i {} \;
И, наконец, привожу небольшой список (скорее всего, неполный) - где еще могут остаться упоминания об этом юзере.
в файлах /etc/group, /etc/login.access, /etc/ftpusers
в таблицах программы sendmail: /etc/aliases и т.п. (virtusertable, genericstable и др.) если у вас отдельным юзерам разрешается запускать задачи с помощью cron, то юзер может упоминаться в /etc/crontab или в /var/cron/allow, /var/cron/deny, а, также, может быть его индивидуальная crontab в /var/cron/tabs/
если юзерам разрешается пользоваться "пакетным" выполнением программ, то юзер может упоминаться в /var/at/at.allow, /var/at/at.deny
если у вас ведется "квотирование" дискового пространства, то должна быть quote для этого юзера если юзер пользуется IP связью через модем, то он может упоминаться в файлах, лежащих в /etc/sliphome или /etc/ppp
от имени юзера могут запускаться какие-нибудь демоны (особенно это касается псевдо-юзеров), тогда имя юзера может быть в /etc/inetd.conf или /etc/rc.local.
Итак, вы видите, что полное удаление юзера из системы в общем случае очень не простая задача.
Однако, в большинстве случаев все гораздо проще.
Что нужно знать о файловой системе Linux
Подразумевается - что нужно знать простому, хотя и полагающему себя профессиональным, пользователю. И потому особых подробностей здесь не ищите: их можно обнаружить в толстых книгах про Linux или в замечательной статье Виктора Хименко "Файлы, файлы, файлы" (Мир ПК, 2000, ##2, 3).
А пользователю нужно в первую очередь осознать отличия файловой систему Linux от привычных систем DOS и Windows.
Linux позволяет работать с великим множеством файловых систем, как локальных, так и сетевых. Однако у него есть и своя, родная, файловая система, носящая название ext2fs. Построена она предельно просто и логично: все в ней является файлами - данные, программы, каталоги, устройства (для примера - последовательные или параллельные порты). И потому файлы разделяются на типы:
обычные файлы; каталоги; файлы устройств; ссылки.
Обычные файлы - это, во-первых, исполнимые двоичные файлы (типа файлов *.exe или *.com, но не привязанные к какому-либо расширению);во-вторых, ASCII-файлы, содержащие простой текст (не обязательно романического содержания - сюда относится и подавляющее большинство системных конфигурационных файлов); в третьих, файлы данных, созданные како-либо программой (текстовым процессором, графическим редактором или электронной таблицей, например) в собственном формате. Впрочем, все это пользователю DOS/Windows понятно.
Каталоги - это тоже файлы, содержащие информацию о каталогах: рекурсия - широко распространенный и любимый прием в мире Unix-систем (достаточно вспомнить расшифровку аббревиатуры проекта GNU - GNU's Not Unix). Каталоги объединяются в иерархическое дерево, начинающееся, как и положено, с корня (/ - root, корневой каталог) и растущее ввысь и вширь; любые накопители, как монтируемые при загрузке (жесткие диски, скажем, и их логические разделы), так и подключаемые в процессе работы (CD ROM, Zip, дискеты) - не более чем ветви дерева каталогов.
Файлы устройств - понятие для Windows-мигранта непривычное. Это нужно просто запомнить: все физические устройства, присутствующие в системы (порты ввода/вывода, накопители разного рода, звуковые устройства и прочие), с точки зрения ext2fs являются файлами. Устройства эти могут быть блочными (например, накопители) или символьными (порты ввода/вывода), но это - уже подробности.
Наконец, ссылки (links) - это некий аналог "ярлыков" в Windows или "теней" в OS/2. Ссылка может быть прямой, или жесткой (hardlink, или, часто, link просто) и символической (symlink). Первые могут указывать на любой файл в файловой системы, тогда как вторые обязаны находиться в одном дисковом разделе.
Чтобы лучше понять, что такое ссылки, давайте попробуем разобраться, что же такое с точки зрения ext2fs файл (не могу не отметить, что для себя я окончательно понял это после прочтения упомянутой статьи Виктора Хименко).
Так вот, файл состоит как бы из двух частей. Первая - это нумерованная в шестнадцатеричном исчислении запись - inode (адекватного перевода мне обнаружить не удалось, иногда переводится как "узел"). В ней содержится информация о размере файла, его формате, правах доступа и т.д. Вторая часть - это имя файла, связанное с inode посредством прямой ссылки.
Каковы следствия этого для конечного пользователя? Первое - имя файла, включая и расширение, не играет в Linux такой сакральной роли, как в DOS/Windows. Если в последней сменить расширение в файле, скажем, *.psd на любое иное - считать его Photoshop уже не удастся. В Linux же в общем случае файлу данных любого типа может быть приписано любое расширение (или его может не быть вовсе): на понимание его породившей программой это никак не отразится. Более того, файл может иметь несколько расширений (то есть групп знаков, разделенных точками): типичный пример - архивный компрессированный файл *.tar.gz.
Правда, некоторые программы (скажем, графические редакторы или офисные пакеты) все же требуют, чтобы файл формата TIFF имел расширение *.tif, и т.д. Но это - извращение генеральной линии. И вызывается тем, что имя файла неявно передается программе, то есть запускающей ее команде, в качестве одного из аргументов.
Следствие второе - теоретически (да и практически) с одним и тем же inode может быть несколько сколько угодно ссылок, причем - не обязательно идентичных. То есть один и тот же физический файл как бы выступает под разными именами. Это играет важную роль при использовании библиотек, шрифтов и в ряде других случае.
Следствие третье - удаление файлов в Linux происходит совершенно иначе, чем в DOS/Windows. Где, как известно, удаленный обычными средствами файл продолжает физически существовать до тех пор, пока на его место не записана новая информация. На чем и основаны программы восстановления ошибочно удаленных данных, вроде прославившей Нортона unerase.
В Linux файл (то есть inode) удаляется автоматически, когда становится недоступным для системы. Это происходит тогда, когда удалена последняя ссылка на него (а имя файла, удаляемое средствами командной строки или файлового менеджера - и есть такая ссылка) и закрыта последняя обращающаяся к нему программа.
То есть: если мы удалим все файлы во всех каталогах всех уровней вложенности (а средства командной строки дают возможность сделать это играючи, и даже подтверждения не запросят) - мы будем по прежнему существовать в работающей системе. И все открытые файлы данных будут существовать, могут быть изменены, записаны, переименованы и т.д. Все это исчезнет только после перезагрузки системы. Но зато - безвозвратно: никаких unerase, undelete и прочих либеральностей в Linux не возможно в принципе.
Правда, такая графическая среда, как KDE, имеет аналог мусорной корзины Windows. Но это - просто отдельный каталог, куда помещаются файлы, полагаемые ненужными, чтобы глаза не мозолили. И откуда их можно даже не восстановить в смысле DOS, а просто скопировать обратно.
Возвращаясь к имени файла. Поскольку оно в Linux не столь свято, как в DOS/Windows, и ограничений на него много меньше. Так, абсолютно запрещенные к использованию символы - только / и \. Правда, некоторые другие специальные символы, такие, как !, @ и прочие из верхнего ряда клавиатуры, за исключением _, всякого рода скобки и кавычки, также не рекомендуются к использованию в именах файлов, особенно - в начальной позиции, но это, обычно, требование оболочки командной строки, а не системы. максимальная
Максимальная длина имени файла (включая и любое количество "расширений") - 255 знаков. А максимально возможная длина пути - 4096, что практически можно считать бесконечным. В отличие от Windows, где при стремлении программ инсталлироваться глубоко в недра директории Programs Files, ограничение на длину пути в 256 знаков становится реальностью.
А вот структура каталогов в Linux, напротив, жестко фиксирована, хотя в деталях и может разниться от дистрибутива к дистрибутиву. Конечно, обладая правами суперпользователя, ее можно изменить. Но - делать это ни в коем случае не следует - в результате система может просто утратить работоспособность.
Как правило, после инсталляции системы в корневом (/, root) каталоге присутствуют:
/bin - каталог для исполнимых ( иначе называемых бинарными, binary) файлов общего назначения; здесь помещаются оболочки командной строки, общие команды управления файлами и их архивации, традиционные текстовые редакторы типа vi, и т.д.; именно каталог /bin в первую очередь просматривается на предмет поиска введенной с клавиатуры команды; /boot, как явствует из названия, содержит файл образа ядра, с которого загружается система; /dev - каталог для файлов устройств; /etc - каталог для конфигурационных файлов общего пользования; /home включает в себя домашние каталоги пользователей, со всеми их программами, личными конфигурационными файлами (имеющими в сеансе этого пользователя предпочтение перед общими файлами конфигурации) и данными; /lib - каталог для общесистемных библиотек (аналогов DLL в Windows); /mnt -каталог для монтирования сменных накопителей (вроде дискет) или временно подключаемых файловых систем (например, FAT-раздела диска); /proc - виртуальная файловая система для чтения информации о процессах; /root - аналог $home для суперпользователя; /sbin содержит системные двоичные файлы, используемые для системного администрирования; /tmp, понятно, включает в себя всякого рода временные файлы; как правило, этот автоматически очищается при перезагрузке или через некоторое время; /usr - каталог для прикладных пользовательских программ со всеми их компонентами - исполнимыми, конфигурационными и разделяемыми файлами (/usr/bin, /usr/etc и /usr/share, соответственно), библиотеками (/usr/lib), документацией в различных форматах (/usr/doc, /usr/man) и т.д.; важный подкаталог /usr/local предназначен для программ, не входящих в дистрибутив стандартно - сюда по умолчанию инсталлируются компилируемые из исходных текстов приложения; /var - каталог для варьирующих файлов, всякого рода системных журналов, почтовых и принтерных спуллингов и т.д.
Кроме того, в дереве могут присутствовать и некоторые другие каталоги, например, /opt - для опциональных компонентов, или /misc - для всего, что не подпадает под приведенные определения.
В общем, назначение каталогов и логика их организации понятна, если затратить некоторое время на изучение их содержимого. Трудности, скорее всего, могут возникнуть с каталогом /mount, поскольку ни DOS, ни Windows не имеют даже отдаленных аналогов этого понятия.
Когда шел разговор об инсталляции системы и создании дисковых разделов, вскользь упоминалась необходимость задать для них точку монтирования. Скажем, для созданного нами раздела под пользовательские данные такая точка определялась как /home. Тем самым мы включили этот (или любой другой) дисковый раздел в структуру дерева каталогов Linux. Или, иными словами, смонтировали его в файловую систему Linux.
Разделы жесткого диска с файловой системой ext2fs обычно монтируются автоматически, при загрузке системы. Часто так же поступают и с FAT-разделами. А в Linux Mandrake (и некоторых других дистрибутивах) предусмотрено автоматическое монтирование и для сменных накопителей - дискет и CD ROM. Вот под них-то и отведен каталог /mnt.
А вообще, что и как монтируется - описано в конфигурационном файле /etc/fstab, в котором в каждой строке указывается (слева направо) имя устройства, точка его монтирования, тип файловой системы, условия монтирования (по умолчанию, автоматическое, пользователем и т.д.) и параметры резервного копирования. Файл этот может выглядеть примерно так: /dev/hda1 /mnt/DOS_hda1 vfat user,exec,conv=auto 0 0 /dev/hda2 / ext2 defaults 1 1 /dev/hda3 swap swap defaults 0 0 /dev/hda4 /home ext2 defaults 1 2 /mnt/floppy /mnt/floppy supermount fs=vfat,dev=/dev/fd0 0 0 none /proc proc defaults 0 0 none /dev/pts devpts mode=0620 0 0 /mnt/cdrom /mnt/cdrom supermount fs=iso9660,dev=/dev/cdrom1 0 0
Из чего можно видеть, что в приведенном примере все разделы ex2fs, раздел подкачки и FAT-раздел монтируются по умолчанию, а для сменных носителей предусмотрена опция supermount, то есть монтирования при обращении и размонтирования - при прекращении его.
Если такая опция не поддерживается, сменные носители требуется монтировать вручную. Для этого дается команда mount с именем устройства и точкой монтирования в качестве аргументов. На пример, с помощью mount /dev/hdc /mnt/cdrom
монтируется CD ROM, подключенный в качестве мастера ко второму каналу IDE; содержимое его после этого можно будет увидеть в каталоге /mnt/cdrom. А перед извлечением сменного носителя (во избежание тяжких последствий, о которых - в разделе техники безопасности), его следует размонтировать командой umount (обращаю внимание - без буквы n, вопреки логике) с точкой монтирования в качестве аргумента. Разумеется, при этом обращений к файлам на носителе быть не должно.
Однако для пользователя наиболее важен каталог /usr (кроме его домашнего, разумеется). Если просмотреть его внимательно, можно обнаружить в нем многочисленные повторения. Например, каталоги /usr/X11R6/bin и /usr/bin/X11 кажутся идентичными по содержанию, так же как /usr/X11R6/lib/X11 и /usr/lib/X11. Возникает естественное желание стереть излишки для освобождения дискового пространства.
Делать этого не нужно: система не дура, и ничего в ней не происходит зря. Поскольку содержимое /usr/X11R6/bin и /usr/X11R6/lib/X11 - не более, чем символические ссылки на файлы из соответствующих раздов каталогов /usr/bin и /usr/lib. Почему?
Linux, как говорилось во введении - Unix-подобная система, то есть полный функциональный аналог Unix. И, теоретически рассуждая, любая программа для любой версии Unix должна работать и в Linux. В чем часто (хотя и не всегда) можно убедиться на практике, если скомпилировать эту программу из исходных текстов. Так вот, Unix-системы имеют несколько различающиеся структуры каталогов. И, соответственно, пытаются искать необходимые им компоненты (вроде библиотек, шрифтов и прочего) по различным путям. Чтобы предусмотреть это, такие и дублируются в виде ссылок везде, где в этом может возникнуть необходимость.
Впрочем, даже если желание стереть эти ссылки будет непреодолимым, выполнить его в режиме обычного пользователя не удастся без дополнительных манипуляций. А некоторые каталоги (например, /root) не удается даже просмотреть. Потому что все файлы в Linux (а все, что есть в Linux, как говорилось, - это файлы) имеют еще одно непременное свойство (также зафиксированное в inode) - права доступа.
Именно понятие прав доступа вызывает наибольшие психологические сложности у Windows-мигранта. Обычный случай - только что созданный самолично или скопированный файл не удается открыть, удалить или переместить, - способен довести до тихого бешенства. Если не догадаться посмотреть в свойства файла или каталога и с удивлением узнать, что вы не имеете в отношении него соответствующих прав.
А права эти умеют быть двух родов - права принадлежности и права действия. Первые определяются для владельца файла (owner), группы пользователей (group) и всех прочих (other). В отношении же действия существуют права на чтение (read), изменение (или запись, write) и исполнение (execute).
Владелец файла - это пользователь, создавший его или скопировавший. По умолчанию он обычно (хотя и не всегда) получает на него все права. Которые подразумевают возможность просмотреть его, модернизировать и записать изменения, а также - исполнить; исполнение для одиночного файла - это возможность запуска бинарной программы или скрипта, для каталога - возможность перейти в этот каталог и просмотреть содержимое. Единственное, чего не может владелец - изменить права принадлежности, то есть сделать владельцем своих файлов дядю Петю: это - привилегия исключительно администратора.
Группа обычно определяется как пользователи, работающие над общим проектом; однако в условиях автономной домашней машины это, скорее всего, ваша же скромная персона, но под другим аккаунтом (если вы послушались моего совета и создали одну учетную запись для серьезной работы, и другую - для нездоровых экспериментов). Группа обычно по умолчанию получает право чтения и исполнения, но не изменения файла или каталога.
Наконец, кто такие прочие - это ясно. Они обычно имеют право (и могут) прочитать файл, но не изменить или выполнить его.
На протяжении всего предыдущего повествования неоднократно упоминался всемогущий суперпользователь, именуемый в народе root (не путать с каталогом /root, который есть просто его домашний каталог), root-оператор, администратор и тому подобными титулами, подчеркивающими его величие и могущество. Настало время рассказать подробнее, кто это такой.
Суперпользователь - это администратор системы, ответственный за ее настройку и поддержание работоспособности. То есть, скорее всего, это опять же ваша скромная персона. Однако в этой ипостаси ваши права коренным образом отличаются от ваших прав в ранге пользователя. В частности, как root вы имеете все права действия для всех файлов системы. В том числе - и право, например, запретить самому себе как пользователю читать собственные файлы (своя рука - владыка). Поскольку в этом качестве вы можете сменить не только права действия, но и права принадлежности: назначить владельцем ваших пользовательских файлов не только дядю Петю с соседнего двора, но и самого же себя как суперпользователя, запретив их чтение всем, кроме владельца...
Впрочем, вы всегда в состоянии поменять ситуацию на обратную. Для этого не нужно даже завершать свой пользовательский сеанс и начинать новый, от лица суперпользователя. Достаточно в консоли или окне терминала набрать в командной строке команду su (аббревиатура понятна? - это тот же superuser) и ввести пароль администратора: на некое время вы выступите в его качестве. Ну а после завершения всех потребных действий не забудьте вернуться в обычный пользовательский режим командой exit...
Так что если вам вдруг захотелось послушать музыку, запустив собственноручно сделанный файл mpeg, а в ответ вы получаете сообщение, что права такого не имеете (permission denied) - не нужно поминать родных создателей Linux. А следует внимательно просмотреть каталог /dev на предмет прав доступа к аудиоустройства, владельцем которых является суперпользователь: возможно, прочие просто не имеют прав исполнения для соответствующих файлов. Выполните целительное действо, описанное в предыдущем абзаце - и наслаждайтесь музыкой в свое удовольствие...
Надеюсь, что с правами доступа к вновь созданным файлам все более или менее ясно. Несколько сложнее - с правами на файлы скопированные. Обычно вы являетесь владельцем всех файлов , расположенных в вашем домашнем каталоге по адресу /home/имя_рек, сокращенно обозначаемому в оболочке bash как $home. И, соответственно, располагаете в отношении их всеми правами. Но бывают и исключения.
Например, вы могли скопировать некие файлы в каталог $home в то время, когда по каким-либо причинам исполняли роль суперпользователя. В этом случае последний автоматически будет назначен их владельцем, со всеми вытекающими последствиями.
Во-вторых, ваши права ущемляются при копировании файлов с CD ROM. В DOS/Windows, как вы помните, такие файлы автоматически получают атрибут READ ONLY. В Linux же на них по умолчанию устанавливается запрет на запись для всех, включая и владельца.
Еще забавнее, если с помощью файлового менеджера с CD ROM копируются целые каталоги и подкаталоги. В этом случае родительский каталог копируется на винчестер, но - без всякого содержимого. Поскольку для него автоматически устанавливается запрет на запись. Правда, это свойственно не всем файловым менеджерам, но - многим.
Наконец, при копировании с носителя файловой системы FAT (дискового раздела, сменного винчестера, дискеты или Zip) наследуются атрибуты исходных файлов: если последние были помечены как READ ONLY, целевые файлы будут автоматически закрыты для записи, в том числе - и для их нового владельца.
Так что права доступа - вещь в Linux архиважнейшая (о чем я еще буду говорить в разделе о технике безопасности). Хотя, повторяю, ничего особенно хитрого здесь нет - нужно просто быть внимательным.
Теперь, получив начальные представления о файловой системе Linux, можно обратиться к изучению средств манипулирования ею, то есть файловым менеджерам. Но сначала - каковы они,
Что полезного вы можете здесь прочитать?
Во-первых, о всех (или почти всех) возможностях syscons. Возможно, вы найдете здесь для себя что-то новое. Во-вторых, о русификации своего терминала. Конечно, полная "русификация" системы не ограничивается установкой русских шрифтов для дисплея и русской "раскладки клавиатуры", но, по крайней мере, начинается с нее.
Хочу предупредить, что если вам надо "по быстрому" решить проблему русификации, то совсем не обязательно читать все что я написал далее.
Просто прочитайте краткую инструкцию (например,
эту). Но если вы хотите русифицировать свой компьютер несколько "нестандартным" образом или понять "как это работает", то, надеюсь, мои инструкции окажутся вам полезными. В-третьих, о переназначении некоторых клавиш - "переключатель РУС/ЛАТ", Meta-клавиша, "комбинация из трех пальцев" (Control+Alt+Del) и т.п.
И кроме того, немного справочной информации, которую я собрал из разных man'ов и исходников программ, мелкие, но полезные программки (которыми я пользовался при этом) и некоторые полезные (надеюсь) советы.
Итак...
Основные возможности syscons
Дисплей
Клавиатура
Несколько примеров изменения назначения клавиш.
Программа vidcontrol
Программа kbdcontrol
Русификация syscons
Как достигается "взаимопонимание" программ с терминалом (termcap, terminfo и переменная TERM).
Одно важное замечание: Какое отношение это имеет к X-Window?
Приложение 1. Команды (esc-последовательности) syscons
Приложение 2. Управляющие ("контроловые") символы
Приложение 3. "Функциональные" клавиши
Приложение 4. Несколько мелких полезных программок.
Иван Паскаль pascal@tsu.ru
Что такое GRUB?
GRUB - это очень мощный менеджер загрузки, который может загружать множество операционных систем, таких как Windows, DOS, Linux, GNU Hurd, *BSD и т.д.
В настоящий момент LILO является самым популярным менеджером загрузки, используемым практически всеми, кто работает с несколькими операционными системами. Но если вы используете LILO, вы должны помнить, что необходимо перезапускать LILO каждый раз как вы изменяете вашу конфигурацию или устанавливаете новое ядро. Также, LILO обладает меньшей гибкостью, чем GRUB.
GRUB - синоним слова гибкость. Его последний релиз, 0.5.96.1, поддерживает ext2 ( файловую систему, используемую Линукс), FAT16 и FAT32 (используемые Win9x и ME), FFS (Fast File System (Быстрая файловая система) используемую *BSD UNIX), ReiserFS (новую журналируемую файловую систему, разработанную для Линукс и интегрированную в ядро Линукс 2.4.1), и minix (старую файловую систему, разработанную для ОС MINIX, также используемую ранними версиями Линукс). С GRUB, вы можете "заглянуть" внутрь этих файловых систем, даже не загружая операционной системы. Например, если вы хотите увидеть дату и время, сохранённые в текстовом файле, и у вас нет времени на загрузку всей операционной системы, вы можете использовать командную оболочку GRUB (строка с подсказкой "grub>") ,введите: grub> cat (номер раздела)/home/god/filename.txt. Вы увидете всё содержимое текстового файла, включая даты и время.
Лучшее свойство GRUB - то, что вы можете загрузить любое ядро на любом разделе, прямо в ходе начальной загрузки. Например, если вы забыли добавить только что скомпилированное ядро в список, вам скорее всего потребуется загрузиться, добавить его в список и затем перезагрузиться, чтобы использовать его. Но с GRUB, вы можете просто использовать командную оболочку и загрузить при помощи её желаемое изображение ядра.
Теперь я опишу три основных шага, которые необходимо выполнить, чтобы начать использовать GRUB: компиляция, установка и конфигурирование.
Что такое группа?
Группа - это группа (из юзеров). :-)
В Unix все юзеры объединяются в группы. Причем,
каждый юзер входит по крайней мере в одну группу, но может быть "членом" нескольких различных групп.
Как и индивидуальные юзеры, каждая группа имеет свое имя (group name) и числовой номер (groupID). Естественно, они однозначно соответствуют друг другу. Также, как и для индивидуальных юзеров, groupID используется внутри системы, а имя (group name) при вводе и выводе сообщений для пользователей (хотя, в большинстве команд, можно указывать вместо имени и groupID).
В основном, группы (юзеров) используются при определении прав доступа к различным файлам и директориям. Не вдаваясь в подробности, можно сказать, что для каждого файла (директории) в Unix'е существует его владелец (это один из юзеров) и группа "особо допущенных" к этому файлу (директории). При этом владелец файла может задать права доступа к нему (чтение, запись и т.п.) разные для себя, группы "допущенных" и для всех остальных (не входящих в эту группу).
Естественно, сам состав групп (список индивидуальных юзеров, входящих в группу) хранится в соответствующей базе данных (пусть, даже и очень примитивной), а к файлам "привязывается" только номер группы (groupID).
Иван Паскаль pascal@tsu.ru
Что такое менеджер загрузки?
Менеджер загрузки - это программа, которая располагается в начальных секторах диска, т.е. в MBR (Master Boot Record - Главная загрузочная запись) жесткого диска. После проверки системы в ходе загрузки, BIOS (Basic Input/Output System), передаёт управление MBR, если система настроена на загрузку отсюда. Затем выполняется программа расположенная в MBR. Эта программа называется менеджером загрузки. Её задача - передать управление операционной системе, которая продолжит процесс загрузки.
Существует множество менеджеров загрузки, включая GNU GRUB (Grand Unified Boot Loader), Bootmanager, LILO (LInux LOader), NTLDR (менеджер загрузки для систем на базе Windows NT), и т.д. Я решил обсудить GNU GRUB и его использование.
Что такое распределенные файловые системы?
Способность совместно использовать диски, каталоги, и файлы по сети – это одно из наиболее значительных достижений современных информационных технологий. Эта способность может существенно сократить требования к дисковому пространству компьютеров и облегчить совместную работу пользователей. Компьютеры с Microsoft Windows и MacOS Apple / MacOS X используют для этого механизм совместного использования дисков и директорий. В системах Linux / Unix для тех же самых задач традиционно используется NFS – сетевая файловая система.
NFS – это самый известный механизм совместного доступа к файлам для Linux и других Unix-систем, потому что он присутствует во многих Unix-подобных системах и очень прост в настройке. NFS поддерживается ядром Linux, и утилиты, связанные с NFS, присутствуют в каждом дистрибутиве. Но в мире Linux существуют и более современные механизмы для совместного использования файлов и каталогов. Каждый из них имеет определенные преимущества в настройке или в использовании.
Распределенная файловая система OpenAFS – это Open Source-аналог известной коммерческой распределенной файловой системы AFS. Поддержка для распределенных файловых систем InterMezzo и Coda уже присутствует в новых ядрах Linux из серии 2.4. Новые механизмы совместного использования файлов, основанные на Web (например, WebDAV), тоже могут использоваться в качестве файловых систем.
В этой статье дается краткий обзор преимуществ распределенных файловых систем, обсуждаются самые распространенные проблемы и их решения, и описываются самые интересные из распределенных файловых систем, доступных для Linux сегодня.
Что такое "русские буквы"?
Давайте не поленимся и рассмотрим проблему с самого начала.
Под русским алфавитом в Юниксах обычно понимают кодировку KOI8-R (хотя иногда используется iso-8859-5 или "вариации на тему" KOI8-R - KOI8-U).
В этой кодировке русские буквы занимают коды 0xc0-0xff (в кодах 0x40-0x7f расположены латинские буквы).
Но в этом же диапазоне могут размещаться
буквы национальных алфавитов стран Западной Европы (буквы с "шляпкой", "тильдой", "умлаутом" и т.п.) греческий алфавит арабский алфавит и т.п.
То есть, на одно и то же место в "кодовой таблице" претендуют куча разных алфавитов.
Попытки совместить весь этот "зоопарк" в X-Window, привели к тому, что под код символа в раскладке клавиатуры были выделены два байта. В старшем байте хранится некий номер определяющий charset (набор символов), а в младшем - собственно код символа. (В общем, идея та же что и у UNICODE, хотя это и не "уникод").
Кстати, "кириллическому" алфавиту (не обязательно "русскому") достались коды, у которых в старшем байте число 6 (признак "кириллицы"), а младший байт содержит код, который совпадает, как правило, с кодом буквы в koi8-r (хотя это и не так уж важно, как мы увидим в дальнейшем).
Называются эти символы - Cyrillic_a, Cyrillic_be, Cyrillic_tse и т.д. Обычно про них говорят - Cyrillic коды.
Итак. При нажатии клавиши, когда активна "русская" раскладка, в программу должны попадать двубайтные Cyrillic коды.
Но проблема в том, что большинство программ внутри хранит строки (и выдает их на экран) как цепочку байтов. То есть, двубайтные коды на входе в программу должны быть преобразованы в однобайтные. При этом, естественно, часть информации (принадлежность символа к конкретному национальному алфавиту) теряется.
Что такое "учетная карточка" (user account)?
Unix - система многопользовательская.
Значит, для нормальной работы нужно...
Во-первых, разграничить права различных юзеров - какие файлы они могут читать/писать/изменять, какие программы запускать и т.п. Во-вторых, дать возможность каждому юзеру создавать свою "среду обитания" (environment) - иметь свои настройки для любимых программ, свои папки-директории, настройки терминала и т.п.
  Для этого в системе должна быть какая-то база данных (пусть даже очень примитивная), в которой хранятся основные сведения о каждом юзере, допущеном к работе на данной машине.
(Естественно, все вышесказанное относится к любой многопользовательской системе, но в данном случае речь об Unix'е).
Итак. В Unix такая запись в соответствующей БД, содержащая сведения об юзере называется user account. Для того, чтобы допустить нового пользователя в систему, необходимо создать для него этот account.
Слово "account" обычно переводится как "банковский счет". Понятно, что в данном случае это не очень подходящий перевод. Поэтому, как мне кажется, наиболее подходяшим по смыслу будет - "личная учетная карточка пользователя". Примерно так я и буду называть его (или ее) в дальнейшем.
Иван Паскаль pascal@tsu.ru
ЧТО ТАКОЕ «ВИРТУАЛЬНАЯ МАШИНА»?
Идея виртуальной машины (Virtual Machine, VM) состоит в независимой работе множества копий операционной системы (в данном случае Linux) на одном компьютере. Компании, предлагающие подобные технологии, добиваются этого разными способами, но в целом VM можно запускать отдельно или вместе на одной машине. По словам Сьюзен де Кекелэр, руководителя проекта по маркетингу IBM zSeries, цель заключается в максимальном использовании вычислительного потенциала аппаратного обеспечения.
«Со временем операционные системы VM стали невероятно мощными, — объясняет де Кекелэр. — Мы обнаружили, что целый ряд клиентов имеет множество распределенных серверов, выполняющих разные задачи. Они, в свою очередь, начали понимать, что по мере увеличения числа системы управление значительно усложнится».
Объединение серверов на данной «базе» должно привести к сокращению затрат на управление серверами. В некоторых случаях в компаниях, использующих IBM zSeries с виртуальными машинами Linux, выполняются сотни и даже тысячи образов Linux на одной физической системе.
Де Кекелэр заявляет, что таким образом можно снизить расходы на энергопотребление и сэкономить занимаемое серверами место: «...особенно на Западном берегу США, где недвижимость невероятно дорога. Серверы могут заполнить собой немало помещений, аренда которых обойдется вам недешево».
Джон Кристинак, директор по маркетингу VMWare, предлагающей виртуализацию для недорогих рабочих станций и серверов на базе процессоров Intel, подчеркивает, что, наряду со сбережением средств, технология VM позволяет клиентам распределять функции между машинами, разделив решения о приобретении программного обеспечения и операционных систем, с одной стороны, и аппаратных средств, с другой.
«Такая технология не привязывает вас к платформе, давая возможность решать ряд задач на одной машине», — добавляет он.
По словам Кристинака, снижение затрат на поддержку аппаратных средств — еще одно преимущество технологии VM. «Сегодня проблема заключается в том, что внезапно вы можете обнаружить в компании, например, 40 серверов при том, что в штате состоит всего 800 человек. Восемь из них занимаются поддержкой, поэтому директору по ИТ невольно придется задуматься, не лучше ли иметь 10 более мощных, управляемых машин, чем 40, 50 или даже 100 серверов».
Он не отрицает, что технология помогает экономить средства на аппаратном обеспечении, но, по данным Gartner Group, Giga Information или Forrester Research, само оборудование и ПО составляет всего лишь 15% от общих расходов, а значит, нужны и другие обоснования для ее применения. По его мнению, такой причиной может служить желание пользователей иметь более гибкую, управляемую и простую среду. Виртуализация как раз позволяет это сделать. Если затраты на оборудование можно снизить на 10%, то сокращение расходов на поддержку и эксплуатацию, уменьшение занимаемой площади, а также расширение выбора оборудования сэкономят от 10—15 до 40% финансовых вложений.
Что такое виртуальная машина и зачем она нужна?
Виртуальная машина, или, иначе, VM,- это программа, которая эмулирует настоящий физический компьютер, притом таким изощренным образом, что на этот компьютер можно установить операционную систему и приложения, которые будут работать, не подозревая о том, что работают они не на «железе», а в программной среде. При этом виртуальная машина может создавать различные аппаратные конфигурации (в некоторых пределах) — например, можно определить, сколько памяти получит та или иная виртуальная машина. Сама программа эмуляции, равно как и работающая на ней операционная система, называется виртуальной машиной, в то время как основная операционная система и физическая машина называются хост-системой.
Задействованные виртуальной машиной ресурсы или «вырезаются» из основного пула ресурсов (как, например, происходит с оперативной памятью), или раздельно используются и хост, и виртуальной системами — как это происходит с процессором и съемными носителями.
Следует отметить, что описываемые виртуальные машины предназначены для работы в качестве хост-системы под Windows и в случае VMWare — под Linux, хотя многообразие устанавливаемых систем значительно шире. Как правило, VMWare показывает отличные результаты, но если не удается поставить какую-то систему или возникают сбои, то, как вариант, попробуйте VirtualPC — возможно, она справится с вашими проблемами.
Что такое журналируюшая файловая система
Ниже предлагается информация общего характера о журналировании. За специфической информацией и техническими подробностями обращайтесь к статье Juan I. Santos Florido из Linux Gazette 55. Дополнительную информацию можно получить с freshmeat.net/articles/view/212/.
Большинство современных файловых систем используют журналирование, заимствованное из мира баз данных, которое призвано улучшить восстановление после сбоев в работе системы. Дисковые транзакции последовательно записываются в специальную зону диска, называемого журналом или логом, перед тем как записаться в конечные пункты своего назначения в файловой системе.
Реализации варьируются на уровне того, каким данные записываются в журнал. Некоторые варианты записывают только матаданные файловой системы, в то время как другие записывают в журнал абсолютно все данные.
Теперь, если сбой происходит перед внесением записи в журнал, то первоначальная версии файла сохраняется на диске, а теряются только несохраненные изменения. Если система "падает" в момент обновления данных на диске (то есть после внесения записи в журнал), то запись в журнале показывает, что планировалось сделать. Поэтому после перезагрузки системы, прочитываются журнальные записи и прерванные операции записи на диск доводятся до своего логического конца.
В любом случае у вас останутся неповрежденные данные и можно будет обойтись без засорения/разрушения дисковых разделов.
Также важно отметить, что использование журналирующей файловый системы не делает использование программ проверки файловой системы полностью устаревшими. Ошибки в программном и аппаратном обеспечении, которые разрушают случайные блоки файловой системы, как правило не исправляются за счет использования транзакционного журнала.
Что значит - "установить locale"?
Конечно, об этом лучше прочитать в man'ах или уже упомянутой "Locale AS IS".
Но я постараюсь вкратце описать основные моменты этого действа.
Во-первых, надо заметить, что существует "системная" locale (или "libc'ишная"), которая влияет на работу процедур libc, а не "иксов".
В X-Window существует как бы "продолжение" этой locale - дополнительные файлы, в которых описываются параметры влияющие на работу процедур из Xlib.
Для того, чтобы программа "настроила" libc под нужную locale, она вызывает в начале процедуру libc - setlocale().
Вызов это процедуры имеет три формы (возможно, так о них не говорят, но мне легче будет ссылаться)
setlocale(..., "ru_RU.KOI8-R") - в вызове явно указывается - какую locale требуется установить; setlocale(..., "") - в этом случае процедура пытается взять название соответствующей "категории locale" (вот что это такое, я объяснять не буду), заданной первым аргументом, из "одноименной" переменной окружения; если такой пременной нет, то из переменной окружения LANG, если и такой нет, то locale будет "никакая", то есть - "C". setlocale(..., NULL) - а вот это, скорее, не "set", а "get", поскольку она ничего не устанавливает, а наоборот - возвращает название locale, которое было установленно с помощью одной из первых двух форм вызова setlocale().
Итак. Для того, чтобы "установить locale" ("libc'ишную"), программа вызывает setlocale() в первой или второй форме. Обычно используется вторая форма, поскольку это позволяет пользователю гибко менять текущую locale с помощью переменных окружения.
Если программа "иксовая", то есть использует Xlib, то при первых же вызовах процедур Xlib, зависящих от locale, происходит настройка "иксовой" locale.
Надо заметить, что это делается автоматически. То есть никаких дополнительных вызовов не требуется.
Соответствующие процедуры Xlib узнают название текущей "libc'ишной" locale с помощью "третей формы вызова" setlocale() (это важно!) и по этому названию пытаются найти соответствующий файл (XLC_LOCALE), содержащий "иксовые" компоненты locale.
Для этого они ищут подходящую поддиректорию в файле X11R6/lib/X11/locale/locale.dir. Если там название не находится, то сначала пытаются "подменить" его с помощью файла X11R6/lib/X11/locale/locale.alias, а потом, опять же, найти с помощью locale.dir. (Содержимое этих файлов достаточно понятно без дополнительных пояснений.)
Если и после этого "ничего подходящего" не находится, то используется "иксовая" locale "C" (хотя "libc'ишная" может быть другая).
Таким образом, для "настройки locale", как "системной", так и "иксовой", необходимо в начале программы вызвать "libc'ишную" процедуру setlocale().
И вот здесь есть одна тонкость...
Циклы
Интерпретатор bash поддерживает циклы for, while, until, select, а интерпретатор sh только for и while.
В этой статье я рассмотрю только первые два цикла – for и while.
Синтаксис цикла for:
for имя_переменной in список1
do
список2
done
Простой пример:
for i in 1 2 3 4 5; do echo $i; done
На экране вы увидите
1 2 3 4 5
Еще раз напомню, что любой список в bash должен заканчивать точкой с запятой.
Построчно вывести содержимое файла file.txt мы можем с помощью такого цикла
for str in ‘cat ./file.txt‘
do
echo "$str";
done
Цикл for закончит свою работу, когда будет обработан последний элемент списка, в данном случае, когда на экран будет выведена последняя строка файла file.txt
Синтаксис цикла while:
while список1
do
список2
done
Цикл while будет выполняться, пока условие, заданное в списке список1, будет истинным. Поэтому цикл while иногда называют циклом с истинным условием. Например,
a=1
while [$a –lt 10]
do
echo $a
a = $(( $a + 1 ))
done
На экране вы увидите:
1 2 3 4 5 6 7 8 9
Когда переменная a примет значение 10, цикл завершит свою работу, так как программа test вернет значение false (a уже не меньше, а равен 10).
Class
Это поле пока ничего не означает. По замыслу, юзер может принадлежать к некоему login-классу. При этом, когда он будет входить в систему, могут быть сделаны какие-нибудь установки (например заданы переменные среды), общие для всех юзеров этого класса. Естественно, должна быть еще некая база данных, в которой указанно - что делать для юзера из конкретного класса (или не делать). Но, сейчас (по крайней мере до версии 2.2.2) это поле никакими программами не используется.
Clock и nlock
Следующие два модификатора - clock (CapsLock) и nlock (NumLock). Их влияние на другие клавиши по сути одинаково. Отличаются они только "областью действия". Как вы можете заметить, в файлах "раскладки клавиатуры", кроме восьми колонок с кодами, есть еще одна колонка, озаглавленная "lock state". Она и определяет - подвержена ли соответствующая кнопка действию clock или nlock.
Если в этой колонке стоит буква "O", то клавиша никак не реагирует ни на нажатие clock, ни на nlock. Обычно, это клавиши с цифрами на основной клавиатуре, функциональные клавиши и сами клавиши модификаторов. Если в "lock state" стоит "C", значит выбор значения зависит от состояния модификатора clock. Обычно, это клавиши с буквами. Буква "N" помечает клавиши, зависимые от состояния nlock. Традиционно - это клавиши на дополнительной цифровой клавиатуре. Наконец, в последней колонке может стоять буква "B" (от слова both - оба). Это должно означать, что клавиша реагирует и на clock и на nlock. Однако, ни в одной "раскладке клавиатуры" из дистрибутива FreeBSD такие клавиши не предусмотрены.
Действие же этих модификаторов заключается в том, что при нажатии соответствующего lock, значение модификатора shift инвертируется. То есть, если shift не нажат (но действует соответствующий lock), то выбирается такое значение для клавиши, которое соответствует "активному состоянию" модификатора shift. И наоборот - при нажатом shift выбирается значение соответствующее "не нажатому" shift'у.
То есть, в таблице раскладки меняются местами колонки "с shift'ом" и "без shift'а". Обратите внимание, что в соответствии с формулой, определяющей номер колонки, меняются местами не только первые две, но и все четные с нечетными (то есть, "просто ctrl" и "ctrl+shift", "просто alt" и "alt+shift" и т.д.).
Обе клавиши - clock и nlock, являются "фиксирующимися". То есть, после нажатия и отпускания clock (например) клавиатура переходит в состояние clock. А при повторном нажатии/отпускании возвращается в исходное состояние (что тоже всем известно).
По умолчанию, значение nlock "навешено" на клавишу [Num Lock]. А вот с clock все немного сложнее. Вообще-то, оно изначально соответствует клавише [Caps Lock], но если у вас загружена раскладка для русской клавиатуры (что бывает чаще всего), то на эту клавишу "навешивается" еще и другой модификатор - alock (Alt Group Lock), который служит для переключения на русский алфавит (о нем поговорим немного позднее). Для того, чтобы получить именно clock вам придется нажимать клавишу [Caps Lock] вместе с одним из основных модификаторов (не важно - shift, ctrl или alt).
Clonir
Клонирование рабочих станций в Линукс
Автор: Alan Ward
Перевод: Юрий Прушинский
Думаю, что любой кому приходилось готовить парк компьютеров из 10 - 100 рабочих станций с абсолютно идентичной ОС и программами, задумывался над методом облегчения и ускорения данного процесса, освобождающим от отупляющей смены компакт-дисков. Процесс клонирования состоит из первичной установки и настройки компьютера, и дальнейшего тиражирования созданной конфигурации на остальные машины.
Целью данной статьи является рассмотрение нескольких из многих способов клонирования жесткого диска рабочей станции. В процессе клонирования мы используем встроенные средства Линукс для того чтобы добиться результата, более менее сопоставимого с Norton Ghost для Windows.
И хотя мы будем загружать на наших опытных машинах Линукс, в реальной жизни это может быть и любая другая ОС. Я, например, пользуюсь нижеописанным методом для клонирования станций под Windows ME, которые приходиться форматировать хотя бы раз в год - по очевидным причинам (самый совместимый формат с Microsoft - "format c:" - прим.перев.)
Подключение жестких дисков
Традиционно для клонирования необходимы две машины (здесь и далее А - машина-модель, В - её клон), а также третий компьютер (назовём его С) под управлением Линукс.
1. Вынимаем жесткие диски из машин А и B, подключаем их к машине С. Не забудем, однако, что родной диск с ОС Линукс на машине С должен работать как IDE primary master. То есть схема подключения должна выглядеть примерно так:
IDE bus 0, master => жесткий диск машины C => /dev/hda IDE bus 0, slave => жесткий диск машины A => /dev/hdb IDE bus 1, master => жесткий диск машины B => /dev/hdc
Затем просто копируем содержимое /dev/hdb в /dev/hdc. В случае если модели компьютеров одинаковы, то создаем копию диска один к одному.
dd if=/dev/hdb of=/dev/hdc
или даже вот так:
cp /dev/hdb /dev/hdc (Но первый вариант предпочтительней -- вы можете "поиграть" в dd такой опцией как bs [количество читаемых и записываемых байт за один раз], что позволит вам "выжать" максимум из своих жёстких дисков. Прим.ред. )
Есть и другие ещё более простые способы создать копию, но при этом вы должны учитывать следующие моменты:
Жесткие диски должны быть именно одной и той же модели, иначе вы рискуете получить проблемы если один из них новее или старее другого Могут возникнуть проблемы если на диске А или B есть битые сектора Можно зря потратить время копируя пустые области диска с А на B
Вышеупомянутый способ копирования наиболее подходит тем, кто использует разные загрузчики типа lilo или grub, поскольку загрузочная область диска копируется тоже.
Можно пойти и другим путём копирования с А на B, более сложным (который скорее не клонирование, а просто копирование - прим.перев.), он состоит из двух этапов:
Сначала создаём таблицу разделов на B, (утилитами fdisk, cfdisk...) Затем форматируем созданные разделы (утилиты mkfs.ext2/3, mkfs.vfat, mkswap) Производим непосредственно само копирование
В этом случае копирование предполагает предварительное монтирование:
mkdir /mount/A ; mkdir /mount/B mount /dev/hdb /mount/A mount /dev/hdc /mount/B cp -dpR /mount/A/* /mount/B umount /dev/hdb ; umount /dev/hdc
Второй способ довольно неудобный для создания большого числа машин, но всё же короче чем время полноценной установки (потому что приходится переносить только актуальные данные, а не копировать абсолютно весь диск. прим. ред.)
.... и, к тому же, гарантирует одинаковую для всех машин конфигурацию.
Внимание: Если вы используете загрузчик типа lilo/grub для загрузки рабочей станции под Линукс, то при копировании вторым способом надо создать конфигурационный файл загрузчика и при его помощи устанавливать загрузчик в загрузочный сектор (MBR, Master Boot Record. прим.ред.) на диск B.
Загрузчику необходимо указать следующее:
Использовать диск /dev/hdc для записи загрузочного сектора, то есть туда, где клонируемый диск находится сейчас. Использовать /dev/hda для загрузки, то есть откуда затем клонированный диск будет загружаться.
Будьте предельно осторожны! Внимательно изучите содержимое своих файлов /etc/lilo.conf или /boot/grub/menu.lst и соответствующие man-страницы перед тем как предпринимать что-либо!
Альтернативный способ, если машины сразу грузятся в Линукс, то вы можете:
скопировать файлы на диск B вставить диск B обратно в рабочую станцию B Загрузить машину B с восстановительной (rescue) дискеты которую вы создали для машины А при установке системы непосредственно выполнить команду lilo или grub
Такой способ наверное наиболее подходящий для новичков в Линукс-системах... :-)
Можно предложить ещё один способ, если диск С (не путать с С:\ !!! - прим.перев.) достаточно емкий, то можно скинуть содержимое А на С, а оттуда соответственно растиражировать на B1, B2, B3....Если у вас достаточно много IDE интерфейсов (или SCSI) то можно за один раз сделать копии на 5 дисках.
Но всем, конечно, понятно, что копирование с диска на диск удобно использовать только при отсутствии сети, отсутствие последней сейчас можно назвать редкостью. Хотя копирование с диска на диск даёт преимущество в скорости, поскольку копирование происходит на скорости IDE-интерфейсов.
Копирование по сети
Схема при клонировании по сети такова: станция В загружается с дискеты или компакт-диска с операционной системой, способной работать в сети без установки непосредственно на жесткий диск (очевидно что Линукс с этим вполне справляется, чего нельзя сказать про MS Windows ), а далее просто копируется образ жесткого диска со станции А, ну, или с файлового сервера С. В своих примерах я буду использовать станцию В в качестве конфигурируемого компьютера, а образ жесткого диска с А лежит на сервере С.
Существует довольно много микро-дистрибутивов Линукс, умещающихся на дискету. Мне больше всех нравится MicroLinux (muLinux), хотя, на самом деле, все они работают по аналогичному принципу.
Надеюсь, вы уже догадались, что нам предстоит загрузиться с дискеты и настроить сеть.
Далее вы можете выбрать один из следующих способов:
Разместить образ жесткого диска на сервере, и затем по-байтно скопировать его на локальный жесткий диск. Но при этом следует учитывать те же нюансы, что и при по-байтном копировании с диска на диск через шину IDE/SCSI. Дать доступ к файлам на сервере, разметить и отформатировать локальный диск, а затем скопировать на него по сети все необходимые файлы.
Пример первого способа с использованием NFS:
mkdir /mount/C mount server:/exported.directory /mount/C dd if=/mount/C/my.image of=/dev/hda umount server:/exported.directory
Пример второго способа ( подразумевается что локальный диск /dev/hda уже разбит и отформатирован ):
mkdir /mount/B ; mkdir /mount/C mount /dev/hda /mount/B mount server:/exported.directory /mount/C cp -dpR /mount/C/* /mount/B umount server:/exported.directory /mount/C umount /dev/hda
Для второго случая не забудьте установить загрузчик (если вы его используете) сразу после копирования файлов, или после перезагрузки станции В с восстановительной дискеты.
Что мне нравится в Линуксе, так это то, что копирование файлов или образа по сети выглядит также как и копирование с другого жесткого диска в вашем компьютере!
Конечно, файлы с сервера С не обязательно копировать именно по NFS. Можно использовать любой другой протокол, который поддерживает ваш микро-дистрибутив с дискеты. Очевидно, что проще всего использовать тот протокол, который уже установлен на вашем сервере. А выбрать есть из чего:
| NFS (Network File System) | Классический протокол обмена файлами для *nix систем, устойчив и прост в настройке. Рекомендую. |
| HTTP (as in Web server) | Прост в настройке серверной части, но довольно трудно найти подходящего клиента. Используется в основном автоматическими инсталляционными скриптами. |
| FTP | Не так прост в настройке сервера, но зато прост при использовании клиентов. Вероятно у вас он уже установлен. |
| TFTP (trivial FTP) | Прост как в настройке сервера, так и клиента. Большинство маршрутизаторов (Cisco) используют tftp для хранения конфигурационных файлов. |
| SMB (or Netbios) | Да, он тоже подходит! Ваш сервер может работать и под Linux+Samba, и под любой версией Windows. Клиент в Линуксе на станции В может примонтировать ресурс командой smbmount, а уж надо это или нет - решать вам. |
| rcp or scp | (scp предпочтительней использовать если вам нужна повышенная безопасность) |
| rsync | Ещё один из моих предпочитаемых протоколов. Обычно используется для синхронизации резервных копий или веб-серверов с другими серверами. Если ваш сервер С доступен извне вашей сети, то в целях безопасности заблокируйте этот протокол на брандмауэре. А ещё rsync поддерживает компрессию. |
Также можно отметить современный CD-дистрибутив Knoppix, с которого можно грузиться сразу в KDE, и использовать ваши любимые графические утилиты.
Загрузка по сети
Ну и последний способ - это загрузка станции В прямо по сети без использования загрузочной дискеты. Смысл состоит в том чтобы BIOS загрузил небольшой драйвер сетевой карты из EPROM. Далее управление переходит к этому драйверу, который ищет в сети DHCP сервер, с которого затем получает IP-адрес и образ ядра. При последующей загрузке ядро монтирует файловую систему NFS сервера в качестве своей корневой.
После этого станция В работает в полноценной Линукс-системе. Можно отформатировать локальный жесткий диск и скопировать на него файлы с сервера.
Понятно, что подобный способ гораздо более сложен в настройке чем загрузка с дискеты или CD. Тем не менее, данный метод довольно легко автоматизировать и он хорошо подходит для больших сетей.
Здесь есть ещё один вариант - полностью распределить локальные жесткие диски на станциях В1, В2, В3 таким образом.... чтобы они загружались каждый раз по сети, а пользовательские файлы хранились на главном NFS сервере.
Литература для изучения
Многие администраторы для научных кластеров используют программу dolly. Я слышал о ней много чего хорошего, но попробовать самому пока не довелось.
На тему загрузки по сети обратите внимание на ключевое слово etherboot или, если ваше оборудование поддерживает этот метод удалённой загрузки, PXE.
PS. Для тех кто пожелает перевести эту статью: я написал её в духе GPL, т.е. вы можете совершенно свободно копировать, рассылать и переводить её - только пожалуйста, уведомьте меня об этом по эл.почте, я хочу отслеживать переводы - это полезно для учебного плана :-)
Alan Ward
Алан преподаёт Computer Science в средней школе и университете в Андорре. Из увлечений и хобби можно выделить научную фотографию (в том числе и цифровую), путешествия, коллекционирование процессоров и прочих камней. :)
Copyright (c) 2003, Alan Ward. Copying license http://www.linuxgazette.com/copying.html
Published in Issue 89 of Linux Gazette, April 2003
Разбор полётов. Статья "Клонирование рабочих станций в Линукс". Вот, что пишет Михаил Шигорин (mike at osdn.org.ua):
> dd if=/dev/hdb of=/dev/hdc
Лучше указать "bs=1M" :-)
...skip...
> Можно пойти и другим путём копирования с А на B, более сложным (который > скорее не клонирование, а просто копирование - прим.перев.), он состоит из > двух этапов:
..и вот тут я удивился отсутствию ссылки на Hard-Disk-Upgrade (mini?) HOWTO :) Оно аккурат по теме.
Точно. И есть перевод на русский язык этого mini-howto: "Мини-HOWTO: Переход на новый жёсткий диск", авторы Yves Bellefeuille и Konrad Hinsen, перевод Станислава Рогина. По поводу опции bs могу добавить, что имеет смысл выбирать размер одновременно копируемых данных кратный размеру буфера жёсткого диска.
Александр Куприн
Команда переводчиков:
Александр Куприн, Андрей Киселев, Александр Михайлов, Александр Саввин, Владимир Меренков, Иван Песин, Игорь Яровинский, Павел Соколов, Роман Шумихин, Сергей Скороходов, Юрий Прушинский
Со всеми предложениями, идеями и комментариями обращайтесь к Александру Куприну (ru_classic at mail.ru). Убедительная просьба: указывайте сразу, не возражаете ли Вы против публикации Ваших отзывов в рассылке.
Сайт рассылки: http://gazette.linux.ru.net
Эту статью можно взять здесь: http://gazette.linux.ru.net/lg89/ward.html
Архивы выпусков находятся здесь: http://gazette.linux.ru.net/archive/
Compose
И, наконец, надо сказать о клавише Compose. С ее помощью можно получить любой код, набрав его цифрами на клавиатуре. Для этого нужно прижать ее (как shift или ctrl) и набрать на дополнительной цифровой клавиатуре нужное число. После отпускания Compose syscons выдаст соответствующий код.
Особенность этой клавиши в том, что это именно физическая клавиша (со скан-кодом 56 - левый [Alt]) и она не может быть "переприсвоена" через таблицу раскладки. Кстати, и цифры с "дополнительной цифровой клавиатуры" "снимаются" на уровне скан-кодов. То есть, если вы даже поменяете их значения в таблице раскладки, для Compose они останутся обычными цифрами, причем независимо от состояния каких-либо модификаторов.
Иван Паскаль pascal@tsu.ru
Consortium Deamonicum
Я где-то читал, что администрирование UNIX - это на 60% знание конфигурационных файлов в /etc, на 20% - логов в /tmp и /var, на 10% файловой системы /proc, и только уделяется 10% остальным корневым каталогам. Пожалуй, это действительно так. Ведь в каталоге /etc находятся практически все управляющие файлы вашей системы. Если здесь я буду указывать файл shadow, то следует понимать, что он имеет полное название /etc/shadow. А если rc.d/rc1 - то /etc/rc.d/rc1. Управление Windows сводится, согласно их "frendly" и "easy-to-use", к постановке галок и нажатиям кнопок, а сам интерфейс подобен наколотым в разных местах пометочным листам. Если вам вдруг, захочется заглянуть поглубже, то, скорее всего, это не удастся, а если вы вдруг запортите один из листочков, то придется "переустанавливать систему". Управление Linux и UNIX аналогично тетради, которая всегда лежит в одном и том же месте и заполнена страничками-файлами. Для того чтобы получить полный доступ к возможностям системы достаточно прочесть эту тетрадь. Для облечения чтения этой тетради, на ее полях написаны примечания и комментарии. Если вдруг испортите одну из страничек, то просто создайте новую.
Администрирование UNIX системы сводится к нескольким основным моментам - это обеспечение нормального функционирования системы, работы пользователей и работы сетевых служб, а также установка новых программ и патчей. Обеспечение работы пользователей на сегодняшний день почти полностью автоматизировано специальными программами, например adduser.
Не рекомендуется менять эти настройки вручную через простой текстовый редактор, поскольку он может поменять не то, что нужно (например, маску доступа), а как раз то, что необходимо, вы забудете изменить.
Система предоставляет удобный интерфейс, который позволяет создать пользователя (в этом работа администратора сравнима с божественной), убить (а в этом с работой киллера), закрыть доступ к системе в течение определенного времени (это уже работа тюремного надзирателя), а также сделать массу неприятных для них штук. А потому пароль рута - это самая желаемая цель любого хакера. Следует очень внимательно оберегать этот секрет, не доверяя никому. (Автор и его друзья, в бытность юзерами, 4 раза по разным причинам угадывали пароли админов.)
Для обеспечения достаточной безопасности существует система теневых паролей. Они находятся в файле shadow, доступ к которому имеет только root. Каждый раз, когда кто-либо вводит логин и пароль, активируется механизм PAM (Pluggable Authentication Modules). Он разработан в связи с тем, что многим программам требуется авторизация пользователя, как например login, ftp, telnet и др. После получения пароля, модуль PAM, который имеет приоритет root'а, выполняет его шифрование, а затем сравнивает с зашифрованным значением из файла shadow. Это шифрование одностороннее, т.е. зная шифр нельзя узнать пароль, по крайней мере, в ближайшие 10000000 лет. Однако существует механизм позволяющий подобрать пароль при известном шифре (например, программой crack) с помощью простого перебора, если доступен файл shadow. Для защиты от таких взломов, shadow имеет владельца root, и маску доступа 600.
Другим механизмом защиты от пользователей реализованным в adduser, является система дисковых квот. Каждый юзер любит набить свой каталог всяким хламом, игрушками и порнухой. Если диск переполняется, то могут случатся самые неожиданные вещи, вроде полного отказа системы. А потому следует устанавливать квоты таким образом, чтобы в полностью заполненном состоянии оставалось не менее 20% свободного места. Имеется 2 вида квот - мягкие и жесткие. Нарушение жестких квот невозможно, тогда как при нарушении мягкой квоты пользователю выдается предупреждение о том, что через определенный промежуток времени следует освободить незаконно занимаемое дисковое пространство. По истечении этого срока пользователь просто не может зайти в систему, а админ получает сообщение о превышение мягкой квоты пользователем lamer.
Админ должен защищаться и сам. Существует несколько простых методов безопасности, которые должен выполнять любой root. Во-первых, никогда не следует заходить в систему под логином root. Для того, чтобы нормально работать как root, существует простая программка su (SuperUser). Если в shell ввести su, а затем пароль root'а, то можно получить все необходимые возможности. Никогда не следует отходить от открытого компьютера, не забывайте про logout. Пользоваться su следует очень осторожно, только по необходимости, затем немедленно logout. Пароль админа должен быть уникальный (шедевры вроде kozlik4 оставьте при себе), и нигде более не употребляться и не записываться.
Не менее серьезную дыру в безопасности представляют собой альтернативные загрузочные устройства, как-то флоппик и привод CD-ROM. Для простой работы они обычно не нужны, а потому их очень полезно отключить. Не следует в этом деле доверяться паролю на биосе, поскольку большинство материнских плат, помимо паролей для administrator и user, имеет еще и пароль для manufacturer (который, понятно, не меняется). Пускай юзеры пользуются новейшим достижением компьютерной мысли, более известным как локальная сеть.
Я малость отвлекся на больную тему всех админов, но продолжу. В директории /etc находится большое количество разнообразных файлов, а не только shadow. Есть там и развлекательные вещи. К таким несерьезным (но очень интересным) настройкам относятся issue и motd. В issue приглашение, которое выводится перед login. В серьезных системах это обычно ее описание, или, проще говоря, самореклама местного админа, для остальных - сообщение вроде "Заходи тихо, проси мало, уходи быстро". Файл motd содержит сообщения, которые в произвольном порядке получает пользователь сразу после входа в систему. В Windows есть аналогичное Tip of day, или "Сообщение дня", как правило, глупое и скучное. А в файл motd можно сунуть все что угодно, а не только приторную радость операционной системы от вашего присутствия, например полторы сотни коротких анекдотов или законы Мерфи. Мне даже известен один слабо одомашненный компьютер, который виртуозно ругался матом. Если вы только начинаете знакомиться с системой, то сначала следует "поменять мебель", т.е. motd или issue.
В конце предыдущего раздела я обещал подробно рассказать о конфигурации загрузчика lilo. Он управляется конфигурационным файлом lilo.conf. Поскольку lilo умеет загружать не только Linux, но и другие операционные системы вроде Windows, DOS, OS/2 и т.д., то его конфигурация должна учитывать и их особенности. Файл lilo.conf имеет заголовок, который описывает общую работу загрузчика и секции по каждой операционной системе. #Файл lilo.conf
#Заголовок
#
#Положение загрузчика, в данном случае в начале диска
boot=/dev/hda1
#Положение корневой файловой системы (не путать с администратором)
root=/dev/hda2
#map-файл, создается автоматически
map=/boot/map
#Графический режим загрузки
vga=normal
#Задержка для выбора
delay=30
#Секции
#Linux
image=/boot/bzImage-2.4.4
label=linux-2.4.4
#Не забудьте указать следующую строку
read-only
#Команда, подаваемая ядру Linux
append="ether=10,300,eth0" #Windows, содержит указатель на загрузчик и таблицу разделов
other=/dev/hda3 table=/dev/hda
label=win #Old Linux kernel
image=/boot/oldkernel label=oldkernel
read-only
append="ether=10,300,eth0"
После того, как вы внесли какие-нибудь изменения в lilo.conf, следует их активизировать, запустив загрузчик командой lilo или /sbin/lilo. В команде,подаваемой ядру, обычно содержится информация об активных сетевых интерфейсах. Обратите особое внимание, на то что в этой строке запрещены пробелы. Если в ней присутствует пробел, то ядро воспримет это как следующую строку!
Ядро приводит к запуску основного процесса системы init - это предок всех процессов, остальные процессы являются его потомками. Каждый процесс имеет свой номер и приоритет, номер init - 1 (один). Но сам по себе init конечно не знает, какие процессы ему следует запустить. Для этого служит группа файлов (понятно, в каталоге /etc). Основной файл этой группы называется inittab, и он определяет уровни выполнения. Каждая строка в этом файле имеет вид id:runlevel:action:process
А все строки, начинающиеся с #, считаются комментариями. (Короткое замечание о комментариях. Они так обозначаются практически везде, это не C. Всегда читайте комментарии, в них часто написано гораздо больше полезного и интересного, чем в мануалах. Всегда когда меняете какой-либо параметр, сначала закомментируйте старое значение, а потом пишите новое.)
Теперь подробнее о inittab
id - Параметр строки, каждая строка должна иметь уникальный id. runlevel - Уровни исполнения, обозначаются числом от 0 до 6. action - Действие выполнения, различаются множественные и однократные. process - Имя запускаемого процесса.
Иногда требуется, чтобы уже работающая система перечитала inittab без перезгрузки. Выполните команду kill -HUP 1. init также управляет выключением и перезагрузкой системы. Значения runlevel отвечают следующему
0 - Выключение системы.
1 - Однопользовательский режим.
2-4 - Различные режимы нормальной работы.
5 - Загрузка с графической средой.
6 - Перезагрузка.
Когда init запускается, он ищет в inittab строку, которая определяет уровень загрузки по умолчанию id:5:initdefault:
В данном случае, это загрузка с графической оболочкой. Для работающей системы параметр initdefault меняется командой telinit. Менять остальные параметры сценариев загрузки требуется редко, и для этого надо знать язык программирования shell.
В средневековье была наука под названием "демонология". Предметом ее изучения была связь демонов с человеком, поскольку тогда считалось, что человек не может познать связь демонов между собой. Но работа с Linux вынуждает заниматься именно этим. Демоны существуют в каждом компьютере, на котором стоит операционная система семейства UNIX. (Windows демоны переименованы в сервисы, т.е. в слуг или рабов, однако называть всех демонов слугами неправильно, есть огромное количество диких демонов.) Демоны запускаются процессом init и живут до того, как их не прикончит Бог (root) или плановый Армагеддон (shutdown). Демоны управляют практически всем в системе, и внутренними ресурсами и сетевыми соединениями. Запускаясь, демон сообщает об этом, также он сообщает, удалось ли это ему. Кстати, это противоречит спецификациям Microsoft pc99 и pc2001, согласно которым, человек не должен знать, какие сервисы в данный момент находятся в системе. Вот и думай после этого, кто демон, а кто слуга. Я приведу сокращенный список домашних (т.е. несетевых) демонов, а потом опишу некоторые подробнее.
| crond | Большой Демон Времени. Выполняет периодические команды. |
| anacrond | Малый Демон Времени. |
| atd | Демон Часов, выполняет однократные команды, заданные на определенное время. |
| gpm | Демон Консольной Мыши. Вообще говоря, не нужен, поскольку мышь в X Windows работает без некого, а в "чистой" консоли мышь пользуются крайне редко. |
| kerneld | Демон Ядра. |
| moduled | Демон Модулей Ядра. |
| syslogd | Демон-Архивариус. Записывает все что происходит, необходим для работы. |
| lpd | Демон Печати, управляет принтерами. |
| pcmciad | Демон PCMCIA-устройств. |
| dbflush | Демон Синхронизации Файловой Системы. |
| autofsd | Демон Монтирования Файловых Систем. |
| /dev/hda | IDE Primary Master |
| /dev/hdb | IDE Primary Slave |
| /dev/hdc | IDE Secondary Master |
| /dev/hda1 | Первый раздел на hda |
| /dev/cdrom | обычно мягкий линк на обнаруженный CD-ROM |
| /dev/fd0 | первый дисковод |
| /dev/ttyS0 | COM1 |
| /dev/ttyS1 | COM2 |
| /dev/ps2mouse | обычно мышь PS/2 |
| /dev/nv | видеокарта nVIDIA |
| /dev/nvidia1 | видеокарта nVIDIA в понимании nVIDIA |
| /dev/modem | обычно мягкий линк на порт модема (не рекомендуется) |
и т.д. Список очень большой. Все устройства делятся на 2 типа - блочные и символьные. Чтение/запись на блочные устройства может проводиться блоками через буфер, в то время как символьные работают только напрямую. Пример блочного устройства - винчестер, дисковод. А символьные устройства это мышь, клавиатура и видеокарта. Ошибка, которую совершают большинство перешедших с Windows, это работа с блочным устройством напрямую. Заметьте, что это не ошибка для системы, такая работа тоже возможна, но результат может здорово отличаться от ожидаемого. Например, команда cp /home/newbieroot/myfile /dev/hdb1
с привилегиями root'а запросто уничтожит файловую систему на первом разделе диска hdb (или диска d: в DOS), поскольку скопирует файл myfile в устройство /dev/hdb1 ПОСИМВОЛЬНО, начиная с первого сектора!
Файловая система
 |
Содержание: |  |
Linux Navigator. Консоль
Linux Navigator. Инсталляция
Linux Navigator. Опции ядра
Linux Navigator. Администрирование
Linux Navigator. Файловая система 1. Монтирование.
Linux Navigator. Файловая система 2.
Linux Navigator. Настройки сети.
Control panel
Запускается командой control-panel в xterm. Является площадкой для запуска отдельных графических средств конфигурации (printtool, kerneld, netcfg, run level editor, time and date, modem configuration).
Copyright ї , CEC Artime and JA
Команда переводчиков:
Владимир Меренков, Александр Михайлов, Иван Песин, Сергей Скороходов, Александр Саввин, Роман Шумихин, Александр Куприн, Андрей Киселев
Со всеми предложениями, идеями и комментариями обращайтесь к Александру Куприну (lgrus@lrn.ru). Убедительная просьба: указывайте сразу, не возражаете ли Вы против публикации Ваших отзывов в рассылке.
Сайт рассылки: http://gazette.linux.ru.net
Эту статью можно взять здесь: http://gazette.linux.ru.net/lg86/baro.html
| http://subscribe.ru/ E-mail: ask@subscribe.ru |
Отписаться Убрать рекламу |
Copyright (С) , Krishnakumar RCopying
Команда переводчиков:
Владимир Меренков, Александр Михайлов, Иван Песин, Сергей Скороходов, Александр Саввин, Роман Шумихин, Александр Куприн
Со всеми предложениями, идеями и комментариями обращайтесь к Сергею Скороходову (suralis-s@mtu-net.ru). Убедительная просьба: указывайте сразу, не возражаете ли Вы против публикации Ваших отзывов в рассылке.
Сайт рассылки: http://gazette.linux.ru.net
Эту статью можно взять здесь: http://gazette.linux.ru.net/lg77/articles/rus-krishnakumar.html
В предыдущий выпуск вкралась ошибка. Исправляюсь. Вот diff для того, чтобы быть в стиле:)
--- toy-os.html.old Thu May 02 15:13:12 2002 +++ toy-os.html Thu May 02 15:12:15 2002 @@ -291,7 +291,7 @@ class="sdfootnotesym"></a><sup><u><a href="#sdfootnote1anc">1</a></u></sup> На <a href="http://www.linuxgazette.com">Linux Gazette</a> на эту тему была лишь небольшая статья Константина Болдышева "Introduction to UNIX - Assembly Programming". Issue #52 апрель 2000г.</div> + Assembly Programming". Issue #53, май 2000г.</div> </div> <div id="sdfootnote2"> <div class="sdfootnote"><a name="sdfootnote2sym" href="#sdfootnote2anc"
Давайте поднимем тост!
Если вы уже решились поэкспериментировать с Wine, то для начала вам нужно взять последние исходники эмулятора с официального сайта проекта http://www.winehq.com. Хотя вовсе не обязательно собирать его вручную из "сырцов". На сайте есть ссылки на уже собранные версии эмулятора в разных форматах (rpm, deb и т.д.).
Если вы решились собрать Wine из исходников, то необходимо выполнить следующее:
gunzip Wine-20020411.tar.gz
tar -xvf Wine-20020411.tar
cd wine-20020411
./configure
make depend
make
make install
[Но лучше этого не делать и воспользоваться соответствующим пакетом "сырцов". Почему именно пакетом? Во-первых, для тех, кто не в курсе, смотрите статью
Дениса Овсиенко об организации и ведении "пакетного хозяйства". Во-вторых, почему пакет "сырцов", а не "бинарников"? Всегда лучше "заточить" программу под конкретную машину. Кроме этого, если вы используете rpm-based дистрибутив, то я советую вам взять пакет Wine на сайте ALT Linux из репозитория пакетов Sisyphus. Пакет с исходниками вы найдёте здесь
(ищите файл wine-номер_cvs_версии-номер_сборки.src.rpm). Здесь же вы можете взять и пакет исходников для WineX (см. подкаталог Sisyphus/unsupported
и ищите файл WineX-номер_версии-номер_сборки.src.rpm). Прим.ред.]
Если же вы хотите самую-самую свежую версию Wine, то можно взять исходный код с CVS:
export CVSROOT=:pserver:cvs@cvs.winehq.com:/home/wine
cvnpres login
На запрос пароля, введите 'cvs':
cvs -z 3 checkout wine
После этого в вашей текущей папке появится подкаталог "wine", в который и скопируются все необходимые файлы. После завершения копирования, вы можете скомпилировать wine вышеуказанными командами.
Debug
Клавиша debug включает "ядерный" отладчик (встроенный в ядро). Естественно, для того, чтобы он включился у вас должно быть ядро с встроенным отладчиком (то ядро, которое ставится при инсталляции, отладчика в себе не имеет), иначе вы просто получите сообщение на самом первом "виртуальном терминале" - "No debugger in kernel".
По умолчанию эта команда "повешена" на две комбинации - [Ctrl]+[Alt]+[Esc]
и [Ctrl]+[Print Screen].
Действия, изменяющие состояние XKB
Напомню, что в состояние XKB входят - текущий набор модификаторов, текущий номер группы и "набор управляющих флагов" (XKB Controls).
Причем и набор модификаторов и номер группы распределены по трем переменным, значение которых может меняться независимо. Поэтому существует три действия для изменения модификаторов (каждое действие меняет свою переменную) и три действия для изменения номера группы.
Делай как я
Старый как мир (и очень действенный) принцип обучения, поэтому не будем нарушать традиций.[7] Я бы предложил вам самим набрать показанный ниже пример -- всё-таки развивает моторную память и прочее. Будет время, можете сделать это, но если честно, то я один раз нарвался на очень странное поведение as86 -- он отказывался компилировать программу на "ровном месте". Код не вызывал подозрений, всё было правильно. Я заремил этот участок, после чего as86 собрал всё нормально. Убрал комментарии -- опять сообщение об ошибке. В конце концов, я перенабрал заново весь этот участок, добавляя по одной команде и проверяя собирается ли объектный файл или нет. Как ни странно, но код выглядел также как и до этого. В чём проблема я так и не понял, возможно знаки табуляции не понравились или что-то ещё. К сожалению, предыдущий вариант в неподдающемся компиляции виде я не сохранил, чтобы их сравнить. (Была такая классная хохма в старину: поскольку подавляющая часть autoexec.bat'ов заканчивалось строкой nc, то для общего развития непосвященных n ставилась латинская, а c -- кириллическое. Прим.редак.).
Итак, вот этот код:
entry _start _start: ;-------------------------------------------------------------------------- ; настраиваем регистры, перносим код в другое адресное пространство ;-------------------------------------------------------------------------- cli ; Запретить прерывания xor ax,ax ; Инициализируем следующие mov ss,ax ; регистры: mov sp,#0x7C00 ; ax = 0 mov si,sp ; sp = 0x7C00h push ax ; si = 0x7C00h pop es ; es = 0 push ax ; ss = 0 pop ds ; ds = 0 sti ; Разрешить прерывания cld ; Установить repne по возрастанию mov di,#0x600 ; di = 0x600 mov cx,#0x100 ; cx = 0x100 repne ; Переслать 512 байт в 0:0x600 movsw ; эта пересылка кода нужна, т.к. по этому ; адресу будет грузится mbr
mov ax,#_done ; Это странное преобразование add ax,#0x600 ; нужно только для того, чтобы push ax ; продожить выполнение программы, ret ; но уже по адресу (0x600 + _done)
;-------------------------------------------------------------------------- ; новая точка входа уже по адресу (0x600 + _done) ; настройка изображеныя, вывод сообщения на экран, ожидание нажатия ; клавиши пробел ;-------------------------------------------------------------------------- _done: mov ax,#0x0003 ; установить текстовый режим 80x25 int 0x10 ; одновременно это приводит к очистке экрана
mov ah,#1 ; делаем невидимым курсор mov cx,#0x2000 int 0x10
mov si,#msg_hello + 0x600 ; выводим сообщение на экран call show_str
press_key: mov ah,#0 ; вызывать прерывание обработки int 0x16 ; ввода данных с клавиатуры cmp ah,#0x39 ; это скан-код пробела? je load_mbr ; если да, то переходим к загрузке jmp press_key ; иначе, ждём следующего нажатия ;-------------------------------------------------------------------------- ; загрузка кода mbr жёсткого диска (master::ide0) по адресу 0:0x7c00 ;-------------------------------------------------------------------------- load_mbr: mov ah,#0x02 ; 0x02 - функция чтения с диска mov al,#0x01 ; 0x01 - кол-во считываемых секторов mov bx,#0x7c00 ; es:bx - адрес буфера для операции чтения mov ch,#0x00 ; 0x00 - номер дорожки (цилиндра) mov cl,#0x01 ; 0x1 - номер стартового сектора mov dh,#0 ; номер головки чтения/записи mov dl,#0x80 ; 0x80 - номер диска (master::ide0) int 0x13 jmp far 0:0x7c00 ; Передаем управление загруженному коду
msg_hello: .byte 13,10 .ascii "Linux Gazette ... сделаем работу с Linux немного веселее!" .byte 13,10 .byte 0
show_str: lodsb ; вывод сообщения на экран cmp al,#0x00 ; в режиме телетайпа je end_show_str ; переход, если конец ; сообщения push si ; запоминаем указатель mov bx,#7 mov ah,#0x0e int 0x10 ; вывод на экран
pop si ; восстанавливаем указатель jmp show_str ; продолжаем вывод сообщения end_show_str: ret
На мой взгляд, комментариев достаточно для того, чтобы понять кто и что делает. Если хотите посмотреть всё в действии, возьмите здесь тарбол. В нём вы найдёте скрипт, компилирующий наш пример и записывающий его на дискету (не забудьте вставить её в дисковод и, если у вас нет прав на запись в /dev/fd0, позаботиться об этом тоже). После того как, код загрузится с дискеты вы увидите на экране следующую фразу:
Опс! Маленькая неувязочка. Как я уже говорил ранее, практически ни одна видеокарта не содержит в прошивке знакогенератора кириллические шрифты. Что делать? А сделать надо вот что: загрузить в знакогенератор таблицу, которая содержит нужные нам символы. У прерывания 0x10 есть такая функция. К сожалению в официальном мануале от Phoenix Technologies Ltd., описывающем доступные прерывания на этапе загрузки, об этом не сказано ни слова. Эту информацию можно найти, либо в Tech Help по MS DOS, либо в Norton Guides.
Так что же это за таблица (иногда её называют матрицей или битовой картой), описывающая символы в знакогенераторе? Возьмем на рассмотрение шрифт 8 на 16 (8 точек по ширине, 16 по высоте). Чтобы вывести на экран букву "А" (большая, русская), знакогенератор должен знать, в каком месте он обязан нарисовать точку, а в каком сделать пропуск. Посмотрите на рисунок (часть скриншота из редактора консольных шрифтов cfe). Как видите, формирование буквы "А" описывается при помощи битовых последовательностей. При этом, один байт (8 бит) описывает одну строчку, а всего их 16. Если бы мы имели дело со шрифтом 8 на 14 или 8 на 8, то описание одного символа для знакогенератора занимало бы 14 или 8 байт, соответственно. Обратите внимание на столбец чисел в шестнадцатеричной кодировке на скриншоте. Это и есть те битовые последовательности. Если вам ещё не совсем понятно как они образуются, то возьмём для примера третью строку сверху: код -- 0x3e и переведём его в двоичную форму 00111110. Получается, что 0x3 -- это 0011, а 0xe -- 1110. Построение кода ведётся справа налево, вот и получается 0x3e.
Надеюсь, не слишком запутанно? Хорошо, пойдём дальше. Мы можем изменить начертание любого символа или последовательности символов за один раз. В нашем случае заменим всю таблицу знакогенератора для символов 8x16 (все 256 символов). Для этого нам нужен файл шрифтов для консоли с разрешением 8 на 16 в кодировке koi8-r. Такой мы можем найти в каталоге /usr/lib/kbd/consolefonts. Файл, который нас интересует -- koi8-8x16.psf.gz. Он имеет немного другой формат, но достать оттуда битовую карту символов несложно: нужно скопировать из него 4096 байт (256*16), отбросив первые четыре, которые являются сигнатурой psf-файла. Для этого можно воспользоваться программой dd (не забудьте распаковать его -- gzip -d koi8-8x16.psf.gz):
#!/bin/bash dd if=koi8-8x16.psf of=koi8-8x16.fnt bs=1 skip=4 count=4096
В конец нашего примера, описанного выше, нужно добавить следующую подпрограмму:
;-------------------------------------------------------------------------- ; настройка знакогенератора ;-------------------------------------------------------------------------- setup_font: mov ah,#0x02 ; 0x02 - функция чтения с диска mov al,#0x08 ; 0x08 - кол-во считываемых секторов ; 8*512=4096 байт; учтите, что кол-во ; секторов в сумме не больше, чем ; один цилиндр mov bx,#0x1000 ; es:bx - адрес буфера для операции чтения mov ch,#0x00 ; 0x00 - номер дорожки (цилиндра) mov cl,#0x02 ; 0x1 - номер стартового сектора mov dh,#0x00 ; номер головки чтения/записи mov dl,#0x00 ; 0x00 - номер диска (fd0) int 0x13
mov bp,bx ; es: bp указывает на новую таблицу mov ah,#0x11 ; 0x11 - функция генерации символов mov al,#0x00 ; подфункция 0x00 - загрузить ; пользовательский шрифт для текстового ; режима mov cx,#0xff ; 0xff - число изменяемых символов mov dx,#0x00 ; 0x00 - изменить кодировку начиная ; с ascii-кода символа mov bh,#0x10 ; 0x10 - число байт в образце символа mov bl,#0x00 int 0x10
ret
Кроме этого, перед вызовом подпрограммы show_str, нужно добавить вызов подпрограммы setup_font:
call setup_font
Теперь, кроме записи в первый (boot) сектор дискеты, мы должны записать в 8-м следующих за ним секторов файл со шрифтом (koi8-8x16.fnt), который будет использовать подпрограмма setup_font. Здесь вы найдёте тарбол с окончательным вариантом нашей программы. Там же находятся файл со шрифтом и скрипт, который всё это собирает и записывает на дискету. А загрузившись с неё, вы сможете увидеть на экране фразу:
Надеюсь, мне это хоть немного удалось.
Демон klogd
Демон klogd предназначен для перехвата и протоколирования сообщений ядра Linux. Вы можете использовать параметры демона, указанные в таблице 3.
Таблица 3.
| Параметр | Описание |
| -c n | Устанавливает уровень сообщений, которые будут выводиться на экран |
| -d | Режим отладки |
| -f file | Записывать сообщения в указанный файл раньше демона syslogd |
| -i | Позволяет перезагрузить символьную информацию ядра о модулях. |
| -I | Перезагружает статическую символьную информацию и информацию о модулях ядра |
| -n | Не переходить в фоновый режим. Этот параметр используется, когда демон управляется программой init |
| -o | Демон читает и протоколирует все сообщения, которые он найден в буферах сообщений ядра. После одно цикла чтения/протоколирования демон завершает работу |
| -s | Заставляет демон klogd использовать системные вызовы для обращений к буферам сообщений ядра |
| -k file | Использует указаный файл в качестве файла, содержащего символьную информацию ядра |
| -v | Выводит версию и завершает работу |
Для просмотра сообщений ядра используется команда dmesg. Обычно она используется так: dmesg | less
Данная программа выводит сообщения ядра при запуске системы. С помощью параметра -с этой программы можно очистить ring-буфер ядра. Параметр -n задает уровень сообщений, которые будут выводиться на консоль.
По умолчанию демон klogd вызывается системным вызовом для того, чтобы препятствовать отображению всех сообщений на консоль. Это не распостраняется на критические сообщения ядра (kernel panic). Эти сообщения все равно будут отображены на консоли.
Демон реагирует на сигналы: SIGHUP, SIGKILL, SIGINT, SIGTERM, SIGTSTP, SIGUSR1, SIGUSR2, SIGCONT. Сигналы SIGTSTP и SIGCONT используются для начала и завершения протоколирования сообщений ядра. Сигналы SIGUSR1 и SIGUSR2 аналогичны опциям -i и -I соответственно. То есть первый перезагружает информацию о модулях, а второй статическую информацию и информацию о модулях. Использовать сигнал GIGUSR1 (как и все остальные) можно так: # kill -USR1 PID
Демон следит за системой
Автор: Станислав Лапшанский, slapsh@kos-obl.kmtn.ru
Опубликовано: 31.01.2002
Оригинал: http://www.softerra.ru/freeos/15618/
Статья является переводом текста Майкла Лукаса (Michael Lucas), опубликованного по адресу http://www.onlamp.com/pub/a/bsd/2001/05/17/Big_Scary_Daemons.html
Система системного журналирования (syslog) является одной из самых восхитительных вещей в UNIX. В отличие от некоторых операционных систем которые заставляют вас использовать лишь тот ограниченный диапазон журналов, которые они соизволят вам предоставить, UNIX позволяет вам регистрировать почти все что угодно с практически любым уровнем детализации. Так как стандартные системные средства журналирования предусмотрены для большинства средств системы UNIX, администратор может выбрать конфигурацию журналирования удовлетворяющую его требованиям. Моя сеть обычно имеет один журналирующий узел который поддерживает журналирование не только для FreeBSD-узлов, но и для маршрутизаторов Cisco, коммутаторов и любых других систем поддерживающих syslog.
Журналирующая система устроена достаточно просто. Программы шлют записи предназначенные для журналирования к системному демону syslogd. Syslogd сравнивает каждую пришедшую запись с правилами, которые находятся в файле /etc/syslog.conf. Когда обнаруживается соответствие, syslogd обрабатывает запись описанным в syslog.conf способом.
Файл /etc/syslog.conf состоит из двух столбцов. В первом указывается правило отбора записей для журнала. Во втором содержится описание действий, которые будут предприняты для обработки подошедшей записи. Большинство затруднений вызывает полное понимание того, как точно указать правило отбора журналируемых записей.
Источник журналируемых записей описывается указанием категории (facility) и уровня (level). Категория это или источник записей, или программа, которая шлет сообщения демону syslogd. Существуют следующие категории:
auth – Все что связано с авторизацией пользователей, вроде login и su. authpriv – Тоже самое что и auth, однако пишет журнал в файл, который могут читать лишь некоторые пользователи (очевидно, автор имел в виду тот факт, что сообщения собираемые в этой категории могут содержать открытые пароли пользователей, которые не должны попадать на глаза посторонним людям, и следовательно файлы журналов должны иметь соответствующие права доступа). console – Сообщения, обычно печатаемые на системной консоли, могут быть записаны в журнал при помощи этой категории. cron – Сообщения от системного планировщика. daemon – Ловушка для сообщений от всех остальных системных демонов, которые не имеют явно описанных категорий. ftp – При помощи этой категории вы сможете сконфигурировать ваш FTP сервер, что бы он записывал свои действия. Смотрите /etc/inetd.conf. kern – Сообщения от ядра. lpr – Сообщения от системы печати. mail – Сообщения от почтовой системы. mark – Эта категория используется для того, что бы помещать в журнал сообщение каждые 20 минут. Она может быть полезна в комбинации с некоторыми другими журналами (например вы сможете узнать с 20-ти минутной точностью, когда же завис ваш сервер – прим. переводчика). news – Сообщения от сервера новостей. ntp – Сообщения от сервера точного времени. security – Сообщения от различных служб безопасности, таких как ipfw или ipf. syslog – Система журналирования может журналировать сообщения от самой себя. Только не пишите в журнал сообщение о том, что вы пишете в журнал сообщение от системы журналирования, иначе у вас закружится голова :-) user – Предназначена для сбора разнообразных сообщений. Если вы не укажете категорию журналирования для программ пользователя, то они будут использовать эту категорию (более чем спорное утверждение – прим. переводчика). uucp – Собирает сообщения от UNIX-to-UNIX Copy Protocol. Это часть истории UNIX и вероятнее всего она вам никогда не понадобится (хотя до сих пор определенная часть почтовых сообщений доставляется через UUCP – прим. переводчика). local0 - local7 – Зарезервированные категории для использования администратором системы. Многие программы дают возможность указать категорию журналирования, если ваша программа это позволяет, выбирайте одну из них.
Большинство систем записывают далеко не все, что сообщают их программы – зачастую незначительные сообщения отбрасываются, а записываются только важные события. Однако то, что кажется одному человеку незначительным, другому может показаться существенным. Здесь мы встречаемся с уровнями подробности сообщений.
FreeBSD предоставляет восемь уровней важности сообщений. С их помощью, вы можете сообщить syslog, что записывать в журнал, а что отбросить. Вот эти уровни, в порядке уменьшения важности:
emerg – Система в панике. Сообщения немедленно выводятся на все активные терминалы. Система обычно накрывается медным тазом :-), или остается чрезвычайно, чрезвычайно нестабильной. Продолжение работы невозможно.
alert – Это плохо, но не настолько плохо как уровень emerg. Система может продолжить работу, но эту ошибку следует устранить немедленно.
crit – Это критические ошибки, такие как проблемы с аппаратным обеспечением или серьезные нарушения работы программного обеспечения. Если ваш жесткий диск содержит плохие блоки, они проявятся в виде критических ошибок. Если вы очень смелый, попробуйте продолжить работу.
err – Разнообразные ошибки. Это скверно, такие ошибки должны быть устранены, но они не разрушат вашу систему.
warning – Разнообразные предупреждения.
notice – Общая информация которая должна быть записана, если она вам нужна, но вероятно она не потребует вашей реакции.
info – Различная системная информация.
debug – Этот уровень обычно используется программистами и иногда системными администраторами, которые пытаются понять – почему же эта программа так поступает? Отладочные сообщения могут содержать всю информацию которую счел необходимым вывести ее разработчик для отладки кода; между прочим она может содержать данные нарушающие приватность ваших пользователей.
none – Это специальный уровень означающий – «ничего не записывать в данной категории». Он обычно применяется для исключения информации из групповых записей.
Описание правила отбора источника информации включает в себя категорию и уровень детализации, разделенные точкой. Когда вы указываете уровень, по умолчанию в журнал записываются сообщения уровень которых выше или равен указанному. В качестве примера рассмотрим эту запись из файла /etc/syslog.conf: mail.info /var/log/maillog
В журнал /var/log/ maillog будут записаны сообщения от почтовой системы, с уровнем выше или равным уровню info.
Если возникнет потребность, то вы можете воспользоваться символом «*» в описании журналируемого источника. Например для записи абсолютно всех сообщений от почтовой системы вы можете воспользоваться следующим синтаксисом: mail.* /var/log/maillog
Для записи в журнал абсолютно всех событий происходящих в системе раскомментируйте строчку all.log (в файле /etc/syslog.conf – прим. переводчика): *.* /var/log/all.log
Это сработает, однако такой файл будет содержать слишком много очень подробных сведений, для того что бы его можно реально использовать: для нахождения полезных сведений вам придется каждый раз сооружать нетривиальные последовательности команд grep.
Благодаря тому, что категория отладочных сообщений тоже подпадает это правило, все приватные сведения пользователей попадут в этот журнал. Вероятно вы не захотите записывать подобную информацию. Вы можете исключить аутентификационную информацию используя категорию authpriv с уровнем none. Точка с запятой даст вам возможность объединить правила в одной строке: *.*;authpriv.none /var/log/all.log
В /etc/syslog.conf вы можете использовать операторы сравнения. Допустимы следующие операторы: «<» (меньше чем), «=» (равно), «>» (больше чем). Применив эти операторы вы сможете например разделить журнал записей почтового трафика и журнал отладочной информации предоставляемой почтовой системой: mail.info /var/log/maillog mail.=debug /var/log/maillog.debug
Таким образом вам нет необходимости отсортировывать отладочную информацию для того что бы узнать что думает ваш почтовый сервер о том что он делает.
Подобным образом у вас может оказаться программа которая захочет использовать для ведения журнала, например, категорию local3. Вы можете записать информацию от нее следующим образом: local3.* /var/log/whatever
В качестве источника записей вы можете указать имя программы. Если программа позволяет использовать категории, применяйте их. Однако, если вам не хватает категорий (local0-7 вполне могут закончиться – прим. переводчика), или программа просто не поддерживает syslogd, то вы можете использовать ее имя.
Такая запись состоит как минимум из двух строк. В первой строке находится название программы, в начале которого находится восклицательный знак. Вторая содержит параметры журналирования. Например, посмотрите, как выглядит запись для сбора информации о действиях ppp: !ppp *.* /var/log/ppp.log
Она начинается с указания имени программы и затем указывает syslog’у, что необходимо записывать абсолютно всю исходящую от нее информацию в файл. Вряд ли вы можете быть уверены, что случайная программа сторонних производителей имеет подходящие категории журналирования, так что лучшим выходом будет запись в журнал всех сообщений этой программы.
Наконец мы подошли к описанию второго столбца файла /etc/syslog.conf. В большинстве случаев он содержит полное имя файла журнала, но существуют и другие способы обработки поступающих записей.
Вы можете отсылать журналируемую информацию на другую машину, предварив ее имя символом «@». Следующий пример демонстрирует как можно перенаправлять все получаемое вашим syslog’ом на выделенный syslog-сервер в моей сети: *.* @loghost.blackhelicopters.org
/etc/syslog.conf на loghost используется для окончательной обработки присылаемых записей.
В качестве способа обработки записей вы можете указать имена пользователей, разделенные запятыми. Если эти пользователи будут находится в системе в момент прихода сообщения удовлетворяющего указанному условию, то оно будет перенаправлено на их терминалы. Если вы хотите показывать некоторые сообщения на всех пользовательских терминалах, то следует воспользоваться символом «*».
Наконец, если вы хотите воспользоваться какой-нибудь другой программой для журналирования, вы можете использовать символ «¦» для перенаправления потока ввода-вывода на эту программу: mail.* |/usr/local/bin/mailstat.pl
Теперь, когда журналирование вашей системы происходит в соответствии с вашими запросами, вас должно беспокоить, что в конце концов файлы журналов заполнят весь ваш диск! Эту ситуацию мы рассмотрим в следующий раз, когда будем обсуждать newsyslog.
Вниманию вебмастеров: использование данной статьи возможно только в соответствии
с правилами использования материалов сайта «Софтерра» (http://www.softerra.ru/site/rules/)
Демон, страдающий бессоницей
Давайте начнем с наиболее известного демона crond. В дистрибутив Red Hat 7.3, с которым я экспериментировал при написании данной статьи, входит вариант демона crond, который называется Vixie Cron, по имени его разработчика Пола Викси (Paul Vixie). Но для краткости будем говорить просто "cron".
Системный демон crond предназначен для выполнения регулярно повторяющихся заданий. Обычно crond запускается как системный сервис в процессе начальной загрузки системы и остается активным пока система не выключена. Сразу после старта он просматривает каталоги /var/spool/cron и /etc/cron.d, а также файл /etc/crontab в поисках заданий, которые нужно выполнять. Затем crond просыпается каждую минуту, выполняет предписанные ему задания и снова засыпает до начала следующей минуты.
Чтобы задать cron-у задачу лучше всего воспользоваться командой crontab. Если выполнить ее с опцией -l:
[user]$ crontab -l
то будет выведен текущий список заданий. Если вы еще никаких заданий cron-у не давали, вы увидите в ответ сообщение "no crontab for user". Сформулировать cron-у задачу довольно просто, но, прежде чем пытаться задать ему работу, установите в качестве значения переменной окружения EDITOR указание на любимый (или привычный) текстовый редактор. В противном случае будет вызван редактор vi, с которым я, например, не привык работать. Поэтому я обычно выполняю команду
[user]$ export EDITOR=mcedit
после чего получаю возможность использовать для редактирования списка заданий привычный CoolEdit из пакета Midnight Commander.
После задания значения переменной EDITOR можно выполнить команду
[user]$ crontab -e
по которой будет вызван указанный вами редактор, причем при первом запуске такой команды откроется пустое окно, в котором вы должны сформулировать задание cron-у. Возникает вопрос: а что мешает нам просто запустить любимый редактор, открыть для редактирования нужный файл и внести в него необходимые команды? Этому существует две причины.
Во-первых, файлы, которые хранят задания для cron-а (crontab-файлы), принадлежат root-у и защищены от модификации простыми пользователями. Команда же crontab запускается от имени root-а (для нее установлен так называемый setuid-бит) и имеет доступ к этим файлам. Конечно, если речь идет о вашем персональном компьютере, где вы имеете все права, вам законы не писаны, но лучше все же придерживаться принятых правил игры.
Вторая причина состоит в том, что записи в crontab- файлах должны подчиняться определенным стандартам, быть формализованы, чтобы crond мог их правильно интерпретировать. Команда crontab после того, как вы сохранили вновь отредактированный файл, производит его синтаксический анализ, и, если вы сделали какую-то ошибку, предлагает вам вернуться к его редактированию. Конечно, crontab не может сформулировать за вас задание cron-у, так что правила написания заданий вам необходимо знать. Давайте их рассмотрим.
Каждая строка crontab-файла (кроме строк комментариев, которые обозначаются знаком # в первой позиции) либо устанавливает значение некоторой переменной, либо представляет отдельное задание (ниже приведен пример crontab-файла, можете просмотреть его, чтоб составить первое впечатление).
Строка задания состоит из шести полей, разделяемых пробелами (по крайней мере одним). Первые пять полей отведены для указания времени выполнения задания. В следующей табличке представлены значения, которые можно придавать этим полям
| Поле | Определяет | Числовые значения |
| 1 | Минуты | 0-59 |
| 2 | Часы | 0-23 |
| 3 | Дни месяца | 1-31 |
| 4 | Месяц | 1-12 или три первых буквы английского названия месяца (регистр не имеет значения) |
| 5 | Дни недели | 0-7 или три первых буквы английского названия дня недели (регистр не имеет значения, а числа 0 и 7 оба обозначают воскресенье) |
список возможных значений, разделенных запятыми (в списках можно использовать только числа, имена не допускаются), интервал значений (например, 1-3) или звездочку (*), обозначающую любое из допустимых значений для данного поля.
Существует также возможность указать, что данное задание должно выполняться только в каждый n-ый час (минуту, день или месяц), для чего в нужном поле записывают примерно такую комбинацию: "*/n" (кавычки, конечно, нужно опустить, а вместо n поставить конкретное число). Эти варианты записи времени выполнения заданий можно комбинировать, но об этом лучше прочитайте на man-странице crontab(5).
Обратите внимание на то, что для указания дня отведено 2 поля: третье и пятое. Если в обоих полях заданы значения, отличные от *, то задание будет выполняться в те дни, когда хотя бы одно из значений дня совпадает с текущим. Например, если в третьем поле стоит 1,15, а в пятом поле - 5 (или FRI), то задание будет выполняться по первым и пятнадцатым числам каждого месяца, а также каждую пятницу (конечно, если в поле месяцев будет стоять *).
Следующее поле (шестое) содержит подлежащую выполнению командную строку оболочки shell. Считается, что поле команда продолжается до конца строки и может содержать пробелы и символы табуляции. Причем заключать эту командную строку в кавычки не требуется. Как и в обычной командной строке shell, можно указать в этом поле несколько команд, разделенных точкой с запятой (хотя, наверное, лучше написать командный файл и указать в crontab-файле его имя).
Задание переменных окружения для cron рассмотрим на примере переменной MAILTO. Надо сказать, что по умолчанию после выполнения каждой строки crontab-файла cron отсылает рапорт о выполнении задания. Содержанием такого рапорта является вывод исполнявшихся команд. Если не задавать переменную MAILTO, то сообщение отправляется тому пользователю, который задал ему данную задачу. Если вы хотите, чтобы сообщения отправлялись не вам, а, скажем, пользователю с именем fred, то в crontab-файле надо записать строку вида
MAILTO="fred"
Боюсь только, что fred не обрадуется, если его почтовый ящик будет заполняться сообщениями от cron. Если они не нужны и вам, то установите переменную MAILTO в нуль:
MAILTO=""
после чего cron не будет загружать вас лишними письмами. Несколько переменных окружения cron устанавливает автоматически при его запуске.
После завершения редактирования вы, как обычно, сохраняете результаты и выходите из редакторской программы. Если вы сделали ошибки, то увидите такое сообщение:
[user] $ crontab -e crontab: installing new crontab "/tmp/crontab.10348":0: bad day-of-week errors in crontab file, can't install. Do you want to retry the same edit? y
Естественно, придется ответить "y". Если же ошибок не было (или вы их исправили), вы увидите только одну строку:
[user] $ crontab -e crontab: installing new crontab
что означает, что введенные строки заданий сформулированы корректно (но это вовсе не гарантирует, что в поле команд нет ошибок).
В отличие от других процессов-демонов, которые требуют перезапуска после редактирования их конфигурационных файлов, перезапускать процесс crond после того, как пользователь задал новое задание, не требуется. Дело в том, что просыпаясь ежеминутно, cron проверяет время модификации crontab-файлов и перечитывает те файлы заданий, которые изменялись в последнее время. Поэтому не более чем через минуту ваши задания будут "приняты к исполнению".
Пользоваться услугами crond могут все пользователи, зарегистрированные в системе. Правда, суперпользователь может закрыть эту возможность для некоторых пользователей, прописав их имена в специальный файл /etc/cron.deny, либо же разрешив использовать cron только ограниченному числу пользователей, имена которых перечислены в файле /etc/cron.allow. Подробнее об этом вы можете прочитать на man-странице crontab(1), а пока будем считать, что вам такое право предоставлено.
Демон Syslogd
Syslogd обеспечивает вид протоколирования, который используется большинством программ. Демон syslogd пишет сообщения в файл /var/log/syslog. Обычно записи в этом файле содержат такие поля: дата и время, хост, программа, сообщение. Пример этого файла предстален ниже: Jan 27 17:09:35 dhsilabs modprobe: modprobe: Can't locate module sound-service-1-0 Jan 27 17:09:35 dhsilabs modprobe: modprobe: Can't locate module sound-slot-1 Jan 27 17:09:35 dhsilabs modprobe: modprobe: Can't locate module sound-service-1-0 Янв 27 17:10:07 dhsilabs DrakX: trying to load ru_RU.KOI8-R.po from ./po.cz2 Янв 27 17:11:23 dhsilabs DrakX: default cancel_clicked Jan 27 17:12:28 dhsilabs kernel: VFS: Disk change detected on device ide1(22,64) Jan 27 17:12:31 dhsilabs kernel: ISO 9660 Extensions: Microsoft Joliet Level 1 Jan 27 17:12:31 dhsilabs kernel: ISOFS: changing to secondary root Jan 27 17:12:32 dhsilabs kernel: VFS: Disk change detected on device fd(2,0) Jan 27 17:12:32 dhsilabs kernel: end_request: I/O error, dev 02:00 (floppy), sector 0
Например, из предпоследней записи мы можем узнать, что 27-го января 2002 года в 17:12 произошла смена носителя в устройстве fd, о чем нам любезно сообщило ядро системы (запись «программа» – kernel).
Демон syslogd автоматически при старте системы. Для его запуска предназначен сценарий /etc/rc.d/init.d/syslog. Как обычно, запустить демон самостоятельно мы можем с помощью команды: /etc/rc.d/init.d/syslog start, а остановить - /etc/rc.d/init.d/syslog stop. Для обеспечения автоматической загрузки нужно создать символическую ссылку на этот файла, например: ls -s /etc/rc.d/rc5.d/@S30syslog /etc/rc.d/init.d/syslog В этом случае мы обеспечим запуск демона на пятом уровне запуска (автоматический запуск X Window). Если вы используете Linux Mandrake, включить и отключить автоматический запуск вы можете с помощью команды drakxservices (см. рис. 1)
Демоны Ядра
8.1 Настройка
8.2 Упражнения
8.3 Дополнительные сведения
Когда вы используете команду ps aux, вы видите нечто вроде приведенного ниже:
USER PID %CPU %MEM SIZE RSS TTY STAT START TIME COMMAND root 1 0.1 8.0 1284 536 ? S 07:37 0:04 init [2] root 2 0.0 0.0 0 0 ? SW 07:37 0:00 (kflushd) root 3 0.0 0.0 0 0 ? SW 07:37 0:00 (kupdate) root 4 0.0 0.0 0 0 ? SW 07:37 0:00 (kpiod) root 5 0.0 0.0 0 0 ? SW 07:37 0:00 (kswapd) root 52 0.0 10.7 1552 716 ? S 07:38 0:01 syslogd -m 0 root 54 0.0 7.1 1276 480 ? S 07:38 0:00 klogd root 56 0.3 17.3 2232 1156 1 S 07:38 0:13 -bash root 57 0.0 7.1 1272 480 2 S 07:38 0:01 /sbin/agetty 38400 tt root 64 0.1 7.2 1272 484 S1 S 08:16 0:01 /sbin/agetty -L ttyS1 root 70 0.0 10.6 1472 708 1 R Sep 11 0:01 ps aux
Это список процессов, выполняющихся в системе. Информация берется из файловой системы /proc, описанной в предыдущем разделе. Заметьте, что init всегда имеет номер один. Процессами номер 2, 3, 4 и 5 являются kflushd, kupdate, kpiod и kswapd. Есть в них нечто странное: в обеих колонках виртуального размера (SIZE) и реального размера (RSS) стоят нули. Как процесс может не использовать память?
Эти процессы являются демонами ядра. Большая часть функций ядра не проявляется в списке процессов, и вы можете оценить объем потребляемой ядром памяти только путем вычитания доступной памяти из общего размера памяти компьютера. Демоны ядра стартуют после init и, следовательно, получают номера подобно другим процессам. Но их код и данные остаются в памяти, принадлежащей ядру.
Имена этих процессов заключены в скобки, поскольку файловая система /proc не имеет информации о командах, которыми эти процессы были запущены.
Так для чего нужны демоны ядра? Предыдущие версии документа содержали просьбу о помощи, так как я очень мало знал о демонах ядра. Последующее изложение было собрано из нескольких разных откликов на эту просьбу, за которые я весьма признателен. Приветствуются и будущие советы, ссылки и исправления!
Ввод и вывод выполняются через расположенные в памяти буферы. Это позволяет программам выполняться быстрее. То, что программа записывает может быть сохранено в памяти, в буфере, и записано на диск позднее, более крупной и эффективной порцией. Эта работа выполняется демонами kflushd и kupdate: kupdate выполняется периодически (5 секунд?) проверяя существование "грязных" буферов. Если таковые присутствуют, он командует kflushd записать их на диск.
Процессы часто остаются без работы, а некоторым нет необходимости держать весь свой код и данные в памяти. Это значит, что мы могли бы использовать память лучшим образом, перемещая неиспользуемые части программ в своп-раздел(ы) на жестком диске. Работа по перемещению данных и кода из памяти на диск и обратно выполняется демонами kpiod и kswapd. Каждую секунду или около того kswapd просыпается чтобы проверить обстановку в памяти и, если что-либо требуется загрузить из свопа в память или не хватает свободной памяти он вызывает kpiod.
Если вы настроили использование автоматического управления питанием (APM), здесь будет присутствовать и демон kapmd.
/Dev : Устройства и специальные файлы
Все устройства и специальные файлы в /dev должны соответствовать документу Linux Allocated Devices, который поставляется в составе исходных кодов ядра. Он поддерживается Питером Анвином (H. Peter Anvin) <адрес пропущен>.
Символические ссылки в каталоге /dev должны устанавливаться в Linux-системах не иначе как в соответствии с документом Linux Allocated Devices.
Devproc
| Использование файловых систем /dev и /proc: |
| Matt Butcher, 4.04.02. |
В Linux существуют две директории - /dev и /proc, которые не имеют Windows-аналогов, и их назначение начинающим пользователям обычно непонятно. Но именно они являются мощными инструментами для понимания и более эффективного использования Linux.
Эта статья - обзор файловых систем Device (/dev) и Process (/proc). Здесь обьясняется, что это такое, как они работают, и как они используются на практике.
/dev: Файловая система устройств.
Устройства: В Linux устройство - это любая вещь (или программа, эмулирующая эту вещь), которая предоставляет методы для осуществления ввода/вывода. Например, клавиатура - это устройство ввода. В Linux большинство устройств представлены, как файлы в этой файловой системе (сетевые карты - исключение). Эти специальные файлы хранятся в /dev, и легко доступны для всех процессов, работающих с устройствами.
Обычно устройства разделяются на 2 категории - символьные устройства и блочные устройства. Символьные устройства производят операции ввода-вывода на базе символов. Самый очевидный пример - это клавиатура, где каждое нажатие кнопки посылает один символ.
Блочные устройства читают данные большими блоками. Обычно это - устройства хранения данных, такие, как жесткие диски IDE (/dev/hd), SCSI (/dev/sd) и CD-ROMы (/dev/cdrom). В операциях ввода-вывода учавствуют большие массивы данных, что обеспечивает более эффективную работу.
Наименования устройств: Устройства часто называются сокращенными названиями вещей, которые они представляют. Например, /dev/fb представляет Frame Buffer для графики, а /dev/hd - жесткие диски IDE. Иногда более удобны бывают символьные ссылки, например - /dev/mouse может ссылаться на USB, PS2, и т.д.
Иногда может быть несколько одинаковых устройств. Если на компьютере 2 CD-ROMа, то первый будет называться /dev/cdrom0, а второй - /dev/cdrom1.
В случае с жесткими дисками наименование становится сложнее. Имя устройства состоит из типа, позиции и номера раздела. Например, первый жесткий диск может быть назван /dev/hda, где "hd" обозначает "диск IDE", а "a" - что это первый HDD. /dev/hdb будет указыать на второй жесткий диск. Первый раздел на первом диске будет называться /dev/hda1, где число 1 - номер раздела. Заметьте, что у некоторых устройств нумерация может начинаться и с нуля (/dev/cdrom0). Список всех разделов может выглядеть примерно так:
/dev/hda
/dev/hda1
/dev/hda2
/dev/hda3
/dev/hda4
/dev/hdb
/dev/hdb1
/dev/hdb2
/dev/hdb3
Жесткие диски SCSI используют /dev/sd вместо /dev/hd, но их правила наименования ничем не отличаются.
Специальные устройства: Существует несколько специальных устройств, которые иногда могут быть полезны - /dev/null, /dev/zero, /dev/full и /dev/random.
Устройство /dev/null физически не существует, но данные, помещенные туда, просто исчезают и их уже невозможно вернуть обратно. Во многих случаях программы выводят много лишней информации. В shell-скриптах /dev/null часто используется, чтобы не беспокоить пользователя различными ненужными вещами. В примере, приведенном ниже, в ядро помещается модуль и весь вывод перенаправляется в /dev/null.
$ modprobe cipher-twofish > /dev/null
/dev/zero выполняет почти те же функции, что и /dev/null. Это устройство так же используется, чтобы убрать ненужные данные, но чтение из /dev/zero постоянно дает символы "\0". (Чтение из /dev/null дает символы "End Of File"). Поэтому /dev/zero часто используется для создания пустых файлов:
dd if=/dev/zero of=/my-file bs=1k count=100
Эта команда создает файл размером 100 Kb, состоящий только из нулевых символов.
/dev/full изображает полное устройство. Запись в /dev/full возвращает ошибку. Это устройство полезно при тестировании таких ситуаций, когда программа обращается к устройству, не имеющему свободного места.
$ cp test-file /dev/full
cp: writing `/dev/full": No space left on device
$ df -k /dev/full
file system 1k-blocks Used Available Use% Mounted on
/dev/full 0 0 0 -
Устройства /dev/random и /dev/urandom генерируют "случайную" информацию. Хотя вывод из обоих этих устройств может показаться совершенно случайным, но /dev/random на самом деле более случайно, чем /dev/urandom. /dev/random генерирует случайные символы на основе "шума окружающей среды", который имеет ограниченное количество, поэтому /dev/random работает медленно, и может иногда останавливаться и ждать поступления новых данных. /dev/urandom использует те же данные, что и /dev/random, но если случайные данные заканчиваются, начинается генерация псевдослучайных чисел. Это делает /dev/urandom более быстрым, но менее безопасным.
Старая файловая система /dev: В прошлом / dev была частью нормальной файловой системы и состояла из специальных файлов, созданных при установке системы и хранящихся на жестком диске.
Обычно /dev занимала очень много места, чтобы поддерживать множество жестких дисков, консолей, и т.д. Например, в старой файловой системе размещались сразу же 11 записей для жестких дисков - с /dev/hdb1 по /dev/hdb11. И чтобы выяснить, какой из этих файлов действительно соответствует устройству, нужна была команда:
$ file -s /dev/hdb?
/dev/hdb1: Linux/i386 ext2 file system
/dev/hdb2: Linux/i386 ext2 file system
/dev/hdb3: Linux/i386 ext2 file system
/dev/hdb4: empty
/dev/hdb5: empty
/dev/hdb6: empty
/dev/hdb7: empty
/dev/hdb8: empty
/dev/hdb9: empty
Если файл для устройства не присутствовал, его нужно было создавать специальной программой mknod или MAKEDEV. Хотя старая модель работала, но она была сложной и неудобной.
DevFS: В ядрах версии 2.4 появилась альтернатива под названием DevFS. Принцип - файловая система /dev создается ядром при каждой загрузке и хранится в оперативной памяти. Если добавляются новые устройства, ядро просто добавляет запись, соответствующую им, в /dev. Если устройство требует специальной конфигурации для корректной работы с DevFS, то существует конфигурационный файл (обычно /etc/devfsd.conf).
/proc: Файловая система для процессов.
Процессы: В любое время Linux имеет много процессов, запущенных одновременно. Некоторые процессы доступны пользователю, а некоторые находятся на заднем плане и обрабатывают задачи, которые не требуют взаимодействия с пользователем. Запуск "ps -ef" в консоли выведет список всех процессов. Это выглядит примерно так:
$ ps -ef UID PID PPID C STIME TTY TIME CMD root 1 0 0 11:08 ? 00:00:04 init root 2 1 0 11:08 ? 00:00:00 [keventd] root 3 0 0 11:08 ? 00:00:00 [ksoftirqd_CPU0] root 4 0 0 11:08 ? 00:00:00 [kswapd] root 5 0 0 11:08 ? 00:00:00 [bdflush] root 6 0 0 11:08 ? 00:00:00 [kupdated] root 8 1 0 11:08 ? 00:00:00 [kjournald] root 86 1 0 11:08 ? 00:00:00 /sbin/devfsd /dev root 165 1 0 11:09 ? 00:00:00 [kjournald] root 168 1 0 11:09 ? 00:00:00 [khubd] root 294 1 0 11:09 ? 00:00:00 [kapmd] root 515 1 0 11:09 ? 00:00:00 metalog [MASTER] root 521 515 0 11:09 ? 00:00:00 metalog [KERNEL] root 531 1 0 11:09 ? 00:00:00 /sbin/dhcpcd eth0 /etc/X11/fs/config -droppriv -user xfs root 572 1 0 11:09 ? 00:00:00 /usr/kde/2/bin/kdm root 593 572 2 11:09 ? 00:04:27 /usr/X11R6/bin/X -auth /var/lib/kdm/authfiles/A:0-25pIgI root 644 1 0 11:09 vc/1 00:00:00 /sbin/agetty 38400 tty1 linux root 1045 572 0 12:16 ? 00:00:00 -:0 mbutcher 1062 1045 0 12:16 ? 00:00:00 /bin/sh /etc/X11/Sessions/kde-2.2.2 mbutcher 1091 1062 0 12:16 ? 00:00:00 /bin/bash --login /usr/kde/2/bin/startkde mbutcher 1132 1 0 12:16 ? 00:00:00 kdeinit: Running... mbutcher 1157 1132 0 12:16 ? 00:00:01 kdeinit: kwin mbutcher 1159 1 0 12:16 ? 00:00:07 kdeinit: kdesktop mbutcher 1168 1 0 12:16 ? 00:00:00 kdeinit: kwrited mbutcher 1171 1168 0 12:16 pty/s0 00:00:00 /bin/cat mbutcher 1173 1 0 12:16 ? 00:00:00 alarmd mbutcher 1207 1132 0 12:23 ? 00:00:08 kdeinit: konsole -icon konsole -miniicon konsole mbutcher 1219 1207 0 12:23 pty/s2 00:00:00 /bin/bash mbutcher 1309 1260 0 13:48 pty/s3 00:00:01 vi dev-and-proc.html root 1314 1220 0 14:03 pty/s2 00:00:00 ps -ef
Многие из задач в списке, выведенном ps - это процессы, выполняемые на заднем плане. Процессы, заключенные в квадратные скобки - это процессы на уровне ядра. И только несколько задач, таких, как процессы KDE и записи в нижней части списка, взаимодействуют с пользователем.
Чтобы управлять системой, ядро должно следить за каждым запущенным процессом, включая себя. Так же информация о запущенных процессах должна быть доступна и для многих пользовательских приложений, таких, как "ps" и "top". В файловой системе /proc ядро хранит информацию о процессах.
Как DevFS, /proc хранится в памяти, а не на диске. Если посмотреть на файл /proc/mounts (который перечисляет все смонтированные файловые системы), то вы увидите строку:
proc /proc proc rw 0 0
/proc контролируется ядром и не имеет соответствующего устройства.
Информация о запущенных процессах: Чтобы следить за процессами, ядро назначает каждому из них номер PID (Process ID). Запуск команды "ps -ef", как мы уже делали ранее, напечатает список процессов, отсортированный по номеру PID (вторая колонка). В /proc хранится информация о каждом PID.
Многие директории в /proc - это числа, соответствующие номерам PID. Внутри директорий есть файлы, предоставляющие важные детали о процессе. Например, в выводе ps (выше) была строка:
mbutcher 1219 1207 0 12:23 pty/s2 00:00:00 /bin/bash
Этот процесс запускает bash, и имеет PID 1219. Директория /proc/1219 содержит информацию об этом процессе.
$ ls /proc/1219
cmdline cpu cwd environ exe fd maps mem root stat statm status
Файл "cmdline" содержит команду, данную для запуска этого процесса. Файл "environ" содержит переменные для процесса. "status" имеет статусную информацию, включая номер пользователя (UID) и номер группы (GID) пользователя, запустившего процесс, номер родительского процесса PPID (parent process ID), который запустил PID, и текущее состояние процесса, такое, как "Sleeping" или "Running".
$ cat status
Name: bash
State: S (sleeping)
Tgid: 1219
Pid: 1219
PPid: 1207
TracerPid: 0
Uid: 501 501 501 501
Gid: 501 501 501 501
FDSize: 256
Groups: 501 10 18
VmSize: 2400 kB
VmLck: 0 kB
VmRSS: 1272 kB
VmData: 124 kB
VmStk: 20 kB
VmExe: 544 kB
VmLib: 1604 kB
SigPnd: 0000000000000000
SigBlk: 0000000080010000
SigIgn: 8000000000384004
SigCgt: 000000004b813efb
CapInh: 0000000000000000
CapPrm: 0000000000000000
CapEff: 0000000000000000
Каждая директория процесса также содержит несколько символических ссылок. "cwd" - ссылка на текущую рабочую директорию для этого процесса, "exe" - ссылка на саму программу, и "root" ссылается на директорию, которую программа считает корневой (обычно "/"). Директория "fd" содержит список символических ссылок на описания файлов, используемых процессом.
Так же в директории есть и другие файлы, предоставляющие информацию обо всем, начиная от использования процессора и памяти до количества времени, в течении которого этот процесс работал. Они описаны в исходниках ядра под "Documentation/file systems/proc.txt" и в man-странице "man proc".
Информация ядра: Кроме информации о процессах, /proc содержит много информации, генерируемой ядром для описания состояния системы.
Ядро и его модули могут генерировать файлы в /proc для предоставления информации об их состоянии. Например, /proc/fb предоставляет информацию о доступных устройствах frame buffer (чаще всего используются для демонстрации логотипа при загрузке).
$ cat fb
0 VESA VGA
Число 0 - это индекс устройства, соответствующего /dev/fb0. Если бы имелся второй frame buffer, то имелась бы еще одна запись, соответствующая /dev/fb1. Вообще, данные в /proc часто ссылаются на устройства в /dev или дают о них больше информации.
Много информации об устройствах хранится в /proc. Файл /proc/pci содержит информацию о почти каждом PCI-устройстве, обнаруженном в системе. Запуск команды "lspci" выводит похожий список, потому что в качестве источника информации используется именно /proc/pci. /proc/bus содержит директории для различных шинных архитектур (PCI, PCCard, USB), которые в свою очередь содержат информацию об устройствах, подключенных к этим шинам. Сетевая информация и статистика хранится в /proc/net. Информация о жестких дисках хранится в /proc/ide и /proc/scsi, в зависимости от типа жесткого диска. /proc/devices перечисляет все устройства, разделенные на категории "block" и "characters".
$ cat /proc/devices
Character devices:
1 mem
2 pty/m%d
3 pty/s%d
4 tts/%d
5 cua/%d
7 vcs
10 misc
14 sound
29 fb
116 alsa
162 raw
180 usb
226 drm
254 pcmcia
Block devices:
1 ramdisk
2 fd
3 ide0
22 ide1
А вообще - в / proc имеется намного больше файлов, чем описано здесь. Для каждого ядра формат /proc может быть разным, в зависимости от конфигурации и версии ядра, установленных устройств, и состояния компьютера. Формат информации может быть разным, но большинство из этих файлов документированы в Documentation/file systems/proc.txt.
Взаимодействие с процессами через /proc: Некоторые файлы из /proc предназначены не только для чтения. Запись в них может изменять параметры ядра. Чтение файлов из каталога /proc обычно безопасно, но записывать информацию в эти файлы, не зная их формата, опасно. Но все равно, иногда запись в /proc - это единственный способ взаимодействия с ядром.
Например, в последние версии ядра можно встроить высокопроизводительный Web-сервер, работающий на уровне ядра системы (khttp). Запуск Web-сервера по умолчанию может быть небезопасен, и поэтому khttp можно запустить через сообщение, посылаемое в /proc.
echo 1 > /proc/sys/net/khttpd/start
Когда ядро видит изменение содержимого /proc/sys/net/khttpd/start с нуля (значение по умолчанию) на единицу, оно запускает khttpd сервер.Так же в /proc имеется еще несколько десятков конфигурируемых параметров - некоторые для настройки оборудования, другие - для управления ядром. Почти все из них выполняются на низком уровне, и их неправильное использование может быть небезопасно для системы.
Заключение: /proc и /dev предоставляют в виде файлов интерфейсы для взаимодействия с Linux. Они помогают в определении конфигурации и состояния различных устройств и процессов системы. Так же они обеспечивают простое взаимодействие с операционной системой. Понимание и применение этих двух файловых систем - ключ к эффективной работе в Linux.
Директивы конфигурации сервера ProFTP
| Директива | Описание |
| AccessGrantMsg message | Ответное сообщение, которое будет отправлено пользователю в случае его регистрации или получения анонимного доступа. Символы %u будут заменены на имя пользователя, которое он ввел при регистрации. |
| Allow from all | host | network [,host | network[, ...]] | Используется внутри блока Limit. Ограничивает доступ к серверу (а именно разрешает доступ). По умолчанию allow from all |
| AllowAll | Разрешает доступ к блокам Directory, Anonymous, Limit |
| AllowForeignAddress on | off | Разрешает клиенту указывать при соединении соединения адрес, который не соответствует ему. По умолчанию off. Может использоваться в блоках VirtualHost, Anonymous, <Global> |
| AllowGroup group_list | Разрешает доступ определенным группам. Используется в блоке Limit |
| AllowUser user_list | Разрешает доступ определенным группам. Используется в блоке Limit |
| AnonRequirePassword on | off | Требует пароль при анонимной регистрации. Пароль должен совпадать с паролем того пользователя, который запустил демон. По умолчанию опция выключена. |
| <Anonymous directory> | Создает анонимную учетную запись, directory - корневой каталог анонимного сервера. |
| AuthGroupFile path | Позволяет указать путь к альтернативному файлу group. По умолчанию используется файл /etc/group |
| AuthUserFile path | Указывает альтернативный файл passwd |
| Bind address | Разрешает привязку дополнительного IP-адреса к основному или виртуальному хосту. |
| DefaultRoot directory | Задает корневой каталог по умолчанию |
| Deny from all | host | network | Запрещает доступ к серверу. Блок Limit |
| DenyAll | Запрещает анонимным пользователям доступ к объектам, указанным в блоке Limit |
| DenyUser user_list | Запрещает доступ определенным пользователям |
| <Directory> path | Используется в VirtualHost, Anonymous для того, чтобы определить особенные параметры доступа к каталогу и его подкаталогам |
| DisplayFirstChdir filename | Текстовый файл filename будет выводиться, когда пользователь впервые за время сеанса войдет в данный каталог. Используется в VirtualHost, Directory, Anonymous |
| DisplayLogin filename | Этот файл будет отображен, когда пользователь зарегистрируется |
| <Global> | Используется для задания параметров, которые будут использоваться как основным, так и всеми виртуальными серверами |
| <Limit command> | Ограничение на выполнение данной FTP-команды, например LOGIN, WRITE |
| MaxClients number | none | message | Ограничение на количество клиентов. Message будет отображено, если пользователю будет отказано в доступе. Блоки Anonymous, Global |
| MaxLoginAttempts | Максимальное количество попыток зарегистрироваться. По умолчанию 3. Блоки VirtualHost, Global |
| Order allow, deny | deny, allow | Порядок выполнения директив Allow и Deny в блоке Limit |
| PersistentPassword on | off | При значении on будут использованы системные файлы /etc/passwd и /etc/group, несмотря на то, что командой chroot корневой каталог был изменен. |
| RequireValidShell on | off | Разрешает или запрещает регистрацию при использовании оболочек (shells), которые не указаны в файле /etc/shells |
| ServerAdmin email | Определяет email администратора сервера. |
| ServerType | Определяет режим работы сервера standalone (по умолчанию) или inetd. В первом случае сервер будет запускаться автоматически из стартовых сценариев системы, во втором - его будет запускать сервер inetd при попытке соединения. |
| TimeoutIdle seconds | Время в секундах, в течение которого пользователь имеет право не проявить активности. По умолчанию 60 (1 минута). |
| User username | Имя пользователя, присвоенное демону ProFTP |
| UserAlias Alias User | Создает псевдоним (alias) для пользователя (user) |
| <VirtualHost address> | Создает виртуальный сервер |
Диски
Именование дисков: /dev/xxyN, где
xx - либо hd (IDE), либо sd (SCSI) y - номер диска
IDE
a - первый IDE диск b - второй IDE диск и т.д.
SCSI
a -первый SCSI диск b - второй SCSI диск и т.д.
N - номер раздела (от 1 до 4 - номера primary или extended разделов, от 5 - номера логических разделов)
Диски, разделы
Создание и редактирование таблицы разделов производится командой
fdisk /dev/hda (подставить требуемое имя диска)
Раздел надо создавать в той ОС, которая будет с ним работать. Например, MS Windows не любит разделов не на границе цилиндра. Переключение режима работы с большими дисками (LBA/Large/Auto) меняет размер цилиндра. Так что после смены режима надо заново разбивать диск.
cfdisk, sfdisk, parted
