Linux usr bin link

Разница между bin, sbin, usr/bin, usr/sbin

Я заметил, что в busybox ссылки разложены по этим четырём директориям.
Есть ли какое-то простое правило, чтобы определить, в какой директории какая из ссылок должна лежать…
К примеру, kill лежит в /bin, а killall — в /usr/bin… Я не вижу никакой логики в таком разделении.

Вы, наверное, знаете, что Кен Томпсон и Дэннис Ритчи создали Unix на PDP-7 в 1969-ом. Так вот, примерно в 1971 они проапгрейдились до PDP-11 с парой дисков RK05 (по 1,5 мегабайта каждый).

Когда операционная система разрослась и перестала помещаться на первом диске (на котором была расположена корневая ФС), они перенесли часть на второй, где располагались домашние директории (поэтому точка монтирования называлась /usr — от слова user). Они продублировали там все необходимые директории ОС (/bin, /sbin, /lib, /tmp . ) и складывали файлы на новый диск, потому что на старом кончилось место. Потом у них появился третий диск, они примонтировали его в директории /home и перенесли туда домашние директории пользователей, чтобы ОС могла занять всё оставшееся место на двух дисках, а это были целых три мегабайта (огого!).

Разумеется, им пришлось ввести правило, что «когда операционная система загружается, она должна быть в состоянии примонтировать второй диск в директорию /usr, поэтому не надо класть программы типа mount на второй диск в /usr, а то получим проблему курицы и яйца». Вот так просто. И это относилось к Unix V6 35 лет назад.

Разделение /bin и /usr/bin (и всех подобных директорий) — это последствие тех событий, деталь реализации из 70-х, которая до сих пор, в течение десятилетий, копировалась бюрократами. Они никогда не задавали вопрос почему, они просто делали так. Это разделение перестало иметь смысл ещё до того, как Linux был создан, по нескольким причинам:

1. При загрузке используется initrd или initramfs, который берёт на себя проблемы типа «этот файл нам нужен раньше чем тот». Таким образом, у нас уже есть временная файловая система, которая используется для загрузки всего остального.
2. Разделяемые библиотеки (которые были добавлены в Unix ребятами из Berkley) не позволяют вам независимо менять содержимое /lib и /usr/lib. Эти две части должны соответствовать друг другу, иначе они не будут работать. Этого не происходило в 1974-ом, поскольку тогда у них была некоторая независимость из-за статической линковки.
3. Дешёвые жёсткие диски преодолели барьер в 100 мегабайт где-то в 1990-ом и примерно в то же время появились программы для изменения размера разделов (partition magic 3.0 вышла в 1997-ом).

Разумеется, поскольку разделение есть, некоторые люди придумали правила, которые его оправдывают. Типа, корневой раздел нужен для всяких общих штучек ОС, а в /usr надо класть свои локальные файлы. Или в / помещают то, что распространяет AT&T, а в /usr — то, что твой дистрибутив, IBM AIX, или Dec Ultrix, или SGI Irix добавили, а в /usr/local лежат файлы, специфичные для твоей системы. А потом кто-то решил, что /usr/local — это не подходящее место, чтобы туда устанавливать новый софт, так что давайте ещё добавим /opt! Не удивлюсь, если появится ещё и /opt/local…

Разумеется, за 30 лет из-за такого разделения появлялись и исчезали всякие интересные специфичные для отдельных дистрибутивов правила. Например, «/tmp очищается при перезагрузке, а /usr/tmp — нет». (И в Ubuntu /usr/tmp нет в принципе, а в Gentoo /usr/tmp — это символическая ссылка на /var/tmp, на который теперь распространяется то правило, и он не очищается при перезагрузке. Да, это всё было ещё до tmpfs. А ещё бывает, что корневая ФС доступна только на чтение, и тогда в /usr тоже не надо ничего писать, а надо писать в /var. Или в / в основном нельзя писать, не считая того, что в /etc, которую иногда пытались перенести в /var. )

Бюрократы вроде Linux Foundation (которые поглотили Free Standards Group во время расширения годы назад) с радостью документируют и усложняют эти правила, даже не пытаясь понять, почему они появились. Они не догадываются, что Кен и Дэннис просто перенесли часть ОС в их домашнюю директорию, из-за того, что диск RK05 на PDP-11 был слишком мал.

Я практически уверен, что в busybox просто помещает файлы так же, как это исторически сложилось. Нет никакой реальной причины делать так до сих пор. Лично я просто делаю /bin, /sbin и /lib ссылками на аналогичные директории в /usr. Ведь люди, которые работают со встраиваемым софтом, стараются разбираться и упрощать…

Источник

Основы Linux от основателя Gentoo. Часть 1 (3/4): Ссылки, а также удаление файлов и директорий

Третий отрывок из перевода первой части руководства. Предыдущие: первый, второй.

В этом отрывке рассмотрены жесткие и символические ссылки, а также разобрано удаление файлов и директорий с помощью команд rm и rmdir.

Создание ссылок и удаление файлов

Жесткие ссылки

Мы уже упоминали термин «ссылка», когда рассказывали о взаимоотношениях между директориями (их именами) и инодами (индексным номерами, лежащими в основе файловой системы, которых мы не замечаем). Вообще в Linux существует два типа ссылок. Тип, о котором мы уже говорили ранее, называется «жесткие ссылки». Каждый инод может иметь произвольное число жестких ссылок. Когда уничтожается последняя жесткая ссылка, и не одна программа не держит файл открытым, то Linux автоматически удаляет его. Новые жесткие ссылки можно создать воспользовавшись командой ln:

Как видите, жесткие ссылки работают на уровне инодов, для указания конкретного файла. В Linux системах, для жестких ссылок есть несколько ограничений. В частности, можно создавать жесткие ссылки только на файлы, не на директории. Да-да, именно так; хотя «.» и «..» являются созданными системой жесткими ссылками на директории, вам (даже от имени пользователя «root») не разрешается создавать любые свои собственные. Второе ограничение жестких ссылок состоит в том, что нельзя связать ими несколько файловых систем. Это значит, что у вас не получится создать жесткую ссылку с /usr/bin/bash на /bin/bash и если ваши директории / и /usr находятся в разных файловых системах (разделах — прим. пер.).

Символьные ссылки

В практике, символьные ссылки (или символические, иногда «симлинки» — от англ.) используются гораздо чаще, чем жесткие. Симлинки — это файлы особого типа, которые ссылаются на другие файлы по имени, а не прямо по номеру инода. Они не спасают файлы от удаления; если файл, на который указывает ссылка, исчезает, то симлинк перестает работать, ломается.

Символические ссылки можно создать передав для ln опцию -s.

В выводе ls -l символьные ссылки можно отличить тремя способами. Во-первых, обратите внимание на символ l в первой колонке. Во-вторых, размер символической ссылки равен количеству символов в ней (secondlink в нашем случае). В-третьих, последняя колонка в выводе показывает куда ведет ссылка с помощью интуитивного обозначения «->».

Симлинки детально

Символические ссылки в целом более гибкие, чем жесткие. Вы можете создавать символьные ссылки на любой объект файловой системы, включая директории. И благодаря тому, что их реализация основана на путях (не инодах), можно совершенно свободно создать символьную ссылку указывающую на объект другой файловой системы. Однако, сей факт также делает их сложными в понимании.

Предположим, что мы хотим создать ссылку в /tmp, которая указывает на /usr/local/bin. Нам следует набрать:

Либо, альтернативный вариант:

Как вы видите, обе символические ссылки указывают на одну директорию. Однако, если наша вторая символьная ссылка когда-нибудь будет перемещена в другую директорию, то она может «поломаться» из-за относительности пути:

$ mkdir mynewdir
$ mv bin2 mynewdir
$ cd mynewdir
$ cd bin2
bash: cd: bin2: No such file or directory

Потому, что директории /tmp/usr/local/bin не существует, мы больше не можем переместиться в bin2; другими словами, bin2 сейчас сломана.

По этой причине, избегать создания ссылок с относительной информацией о пути, иногда будет хорошей идеей. Тем не менее, существует множество случаев, где относительные символические ссылки крайне удобны. Рассмотрим пример в котором мы хотим создать альтернативное имя для программы в /usr/bin:

От имени суперпользователя мы хотим короткий синоним для keychain, такой, как kc. В этом примере у нас есть root-доступ, о чем свидетельствует измененное на «#» приветствие bash. Нам нужен root-доступ потому, что обычные пользователи не имеют прав создавать файлы в /usr/bin. От имени суперпользователя мы можем создать альтернативное имя для keychain следующим образом:

В этом примере мы создали символьную ссылку под названием kc, которая указывает на файл /usr/bin/keychain.

Пока это решение будет работать, но создаст проблему, если мы решим переместить оба файла, /usr/bin/keychain и /usr/bin/kc в /usr/local/bin:

Поскольку мы использовали абсолютный путь для символической ссылки kc, то она все еще ссылается на /usr/bin/keychain, которого не существует с тех пор как мы переместили /usr/bin/keychain в /usr/local/bin.

Это привело к тому, что симлинк kc сейчас не работает. Как относительные, так и абсолютные пути в символьных ссылках имеют свои достоинства, и, в зависимости от вашей задачи, нужно использовать соответствующий тип пути. Часто, и относительный, и абсолютный путь, будут работать одинаково хорошо. Пример ниже будет работать, даже после перемещения обоих файлов:

# mv keychain kc /usr/local/bin
# ls -l /usr/local/bin/keychain

Теперь, мы можем запустить программу keychain набрав /usr/local/bin/kc. /usr/local/bin/kc указывает на программу keychain в той же директории, где находится kc.

Итак, мы знаем как использовать cp, mv и ln, настало время узнать о том, как можно удалять объекты из файловой системы. Обычно это делается с помощью команды rm. Чтобы удалить файлы, просто укажите их в командной строке:

$ rm file1 file2
$ ls -l file1 file2
ls: file1: No such file or directory
ls: file2: No such file or directory

Имейте ввиду, что под Linux, однажды удаленный файл, обычно исчезает на века. Поэтому многие начинающие системные администраторы используют опцию -i, когда удаляют файлы. Опция -i сообщает rm удалять файлы в интерактивном режиме — это значит спрашивать перед удалением любого файла. Например:

$ rm -i file1 file2
rm: remove regular empty file `file1′? y
rm: remove regular empty file `file2′? y

В примере выше команда rm запрашивает подтверждение на удаление каждого из указанных файлов. В случае согласия, я должен был вводить «y» и нажать enter, дважды. Если бы я ввел «n», то файл бы остался цел. Или, если я сделал что-нибудь не так, я мог бы нажать Control-C и сбросить выполнение команды rm -i целиком — всяко до того, как это могло нанести какой-нибудь ущерб моей системе.

Если вы все еще учитесь пользоваться командой rm, то может быть полезным добавить при помощи вашего любимого текстового редактора следующую строку в ваш файл

/.bashrc, и затем выйти (logout) и войти (login) в систему вновь. После этого, всякий раз, когда вы наберете rm, оболочка bash преобразует ее автоматически в команду rm -i. Таким образом, rm будет всегда работать в интерактивном режиме:

rmdir

Для удаления директорий у вас имеется два варианта. Вы можете удалить все объекты внутри директории и затем воспользоваться rmdir для удаления самой директории:

$ mkdir mydir
$ touch mydir/file1
$ rm mydir/file1
$ rmdir mydir

Этот метод широко известен под названием «способ удаления директорий для лохов». Все реальные пацаны и админы-гуру съевшие пользователя собаку на этом деле, используют гораздо более удобную команду rm -rf, описанную далее.

Самый лучший способ удалить директорию состоит в использовании опций «рекурсивного принуждения» (recursive force) команды rm, чтобы приказать ей удалять указанную директорию, также как и объекты содержащиеся внутри:

Обычно, rm -rf является наиболее предпочтительным методом для удаления древа директорий. Будьте очень осторожны, когда пользуетесь rm -rf, так как ее мощь может быть использована по обе стороны: добра и зла. =)

Об авторах

Daniel Robbins

Дэниэль Роббинс — основатель сообщества Gentoo и создатель операционной системы Gentoo Linux. Дэниэль проживает в Нью-Мехико со свой женой Мэри и двумя энергичными дочерьми. Он также основатель и глава Funtoo, написал множество технических статей для IBM developerWorks, Intel Developer Services и C/C++ Users Journal.

Chris Houser

Крис Хаусер был сторонником UNIX c 1994 года, когда присоединился к команде администраторов университета Тэйлора (Индиана, США), где получил степень бакалавра в компьютерных науках и математике. После он работал во множестве областей, включая веб-приложения, редактирование видео, драйвера для UNIX и криптографическую защиту. В настоящий момент работает в Sentry Data Systems. Крис также сделал вклад во множество свободных проектов, таких как Gentoo Linux и Clojure, стал соавтором книги The Joy of Clojure.

Aron Griffis

Эйрон Гриффис живет на территории Бостона, где провел последнее десятилетие работая в Hewlett-Packard над такими проектами, как сетевые UNIX-драйвера для Tru64, сертификация безопасности Linux, Xen и KVM виртуализация, и самое последнее — платформа HP ePrint. В свободное от программирования время Эйрон предпочитает размыщлять над проблемами программирования катаясь на своем велосипеде, жонглируя битами, или болея за бостонскую профессиональную бейсбольную команду «Красные Носки».

Источник

Фундаментальные основы Linux. Часть II: Первые шаги в изучении интерфейса командной строки

Глава 9. Дерево директорий Linux

В рамках данной главы производится обзор наиболее часто используемых директорий из дерева директорий файловой системы Linux . Также данная глава может служить доказательством утверждения о том, что в Unix-системе все является файлом.

Стандарт иерархии файловой системы

Многие дистрибутивы Linux частично следуют Стандарту иерархии файловой системы ( Filesystem Hierarchy Standard ). Данный стандарт может оказаться полезным для будущего процесса стандартизации деревьев директорий файловых систем Unix/Linux. Стандарт FHS доступен в сети по адресу http://www.pathname.com/fhs/ , причем на данном ресурсе мы можем прочитать: «Стандарт иерархии файловой системы был создан с целью его использования разработчиками дистрибутивов Unix, разработчиками пакетов для распространения программного обеспечения и разработчиками операционных систем. Однако, данный стандарт является в большей степени справочным материалом, нежели руководством по работе с файловой системой Unix или с иерархиями директорий.»

Страница руководства man hier

Существуют некоторые различия в иерархиях файловых систем различных дистрибутивов Linux . Для того, чтобы ознакомиться с информацией об иерархии файловой системы вашей машины, используйте команду man hier . На данной странице руководства будут приведены пояснения относительно структуры дерева директорий системы, установленной на вашем компьютере.

Корневая директория /

Директории для хранения бинарных файлов

Бинарные файлы являются файлами, содержащими скомпилированный исходный код (или машинный код). Бинарные файлы могут исполняться на компьютере. Иногда бинарные файлы также называются исполняемыми файлами .

Директория /bin содержит бинарные файлы , которые могут использоваться всеми пользователями. В соответствии со спецификацией FHS, директория /bin должна содержать исполняемые файлы /bin/cat и /bin/date (помимо других исполняемых файлов).

Другие директории /bin

Вы можете обнаружить поддиректорию /bin во многих других директориях. Например, пользователь с именем serena может разместить свои собственные приложения в поддиректории /home/serena/bin .

Файлы некоторых приложений, обычно в случае установки путем непосредственной сборки из исходного кода, устанавливаются в директорию /opt . К примеру, при установке сервера samba для хранения бинарных файлов может быть использована поддиректория /opt/samba/bin .

Директория /sbin содержит бинарные файлы, предназначенные для настройки операционной системы. Многие из бинарных файлов для настройки системы требуют наличия привилегий пользователя root для выполнения определенных задач.

Обычно ядро Linux загружает модули из директории /lib/modules/$версия-ядра/ . Содержимое этой директории будет подробно описано в главе, посвященной ядру Linux.

Директории /lib32 и /lib64

Формат ELF (формат исполняемых и компонуемых файлов — Executable and Linkable Format ) используется практически во всех Unix-подобных операционных системах с момента выпуска System V .

Директория /opt предназначена для хранения вспомогательного программного обеспечения . В большинстве случаев данное программное обеспечение устанавливается не из репозитория дистрибутива. В многих системах директория /opt пуста.

При установке пакета программного обеспечения большого объема файлы из него могут копироваться в поддиректории /bin , /lib , /etc директории /opt/$имя-пакета/ . Например, в том случае, если пакет программного обеспечения носит имя wp , файлы из него будут устанавливаться в директорию /opt/wp , при этом бинарные файлы будут устанавливаться в поддиректорию /opt/wp/bin , а файлы страниц руководств — в поддиректорию /opt/wp/man .

Директории для хранения файлов конфигурации

Директория /boot содержит все файлы, необходимые для загрузки компьютера. Эти файлы не изменяются очень часто. В системах Linux в данной директории обычно можно обнаружить поддиректорию /boot/grub . Директория /boot/grub содержит файл /boot/grub/grub.cfg (на более старых системах также может использоваться файл /boot/grub/grub.conf ), в рамках которого описывается меню загрузки, отображаемое перед загрузкой ядра ОС.

Все специфичные для машины конфигурационные файлы должны быть расположены в директории /etc . Изначально имя директории /etc была образовано от слова etcetera (и так далее), но сегодня люди часто расшифровывают его как Editable Text Configuration (директория с редактируемыми текстовыми файлами конфигурации).

В директории /etc также можно обнаружить большое количество других важных файлов.

Во многих дистрибутивах Unix/Linux имеется директория /etc/init.d , которая содержит сценарии для запуска и остановки демонов . Эта поддиректория может исчезнуть в процессе перехода дистрибутивов Linux на системы инициализации, которые заменят старую систему инициализации init , используемую для запуска всех демонов .

Управление системой вывода графики осуществляется средствами программного обеспечения от организации X.org Foundation (а именно, сервера оконной системы X Window System или просто X ). Файл конфигурации для вашего сервера оконной системы носит имя /etc/X11/xorg.conf .

Содержимое директории каркаса /etc/skel копируется в домашнюю директорию при создании учетной записи пользователя. Она обычно содержит такие скрытые файлы, как сценарий .bashrc .

Файл /etc/sysconfig/harddisks содержит дополнительные параметры настройки жестких дисков. Формат файла описан в самом файле.

Вы можете ознакомиться с описанием программного обеспечения, обнаруженного утилитой kudzu , которое сохраняется в файле /etc/sysconfig/hwconf . Kudzu является приложением от компании Red Hat, предназначенным для автоматического обнаружения и настройки аппаратного обеспечения.

Файлы для настройки сетевых устройств из данной директории будут обсуждаться в главе, посвященной настройке сети.

Директории для хранения данных

Во многих системах директория /root является стандартной директорией для хранения персональных данных и данных профиля пользователя root . В том случае, если ее не существует по умолчанию, администраторы могут создать ее самостоятельно.

Вы можете использовать директорию /srv для хранения данных, которые обрабатываются вашей системой . Спецификация FHS позволяет хранить в этой директории данные cvs, rsync, ftp и www. Кроме того, спецификация FHS подтверждает возможность использования таких административных имен для поддиректорий, как /srv/project55/ftp и /srv/sales/www.

В системах Sun Solaris (или Oracle Solaris) для этой цели используется директория /export .

Директория /mnt должна быть пустой и использоваться исключительно для создания временных точек монтирования файловых систем (в соответствии со спецификацией FHS).

Администраторы систем Unix и Linux обычно создают в данной директории множество поддиректорий, таких, как /mnt/something/. Вы, скорее всего, столкнетесь с системами с более чем одной директорией, созданной и/или смонтированной в рамках директории /mnt для работы с различными локальными и удаленными файловыми системами.

Приложения и пользователи должны использовать директорию /tmp для хранения временных данных при необходимости. Данные, хранимые в директории /tmp , могут в реальности храниться как на диске, так и в оперативной памяти. В обоих случаях обслуживание хранилища временных данных осуществляется средствами операционной системы. Никогда не используйте директорию /tmp для хранения данных, которые являются важными или которые вы желаете архивировать.

Директории в оперативной памяти

Файлы устройств из директории /dev выглядят как обычные файлы, но на самом деле не являются обычными файлами, размещенными на жестком диске. Директория /dev заполняется файлами в процессе определения устройств средствами ядра операционной системы.

Стандартные физические устройства

Помимо представления физических устройств, некоторые файлы устройств выполняют специальные функции. Эти специальные файлы устройств могут оказаться очень полезными.

Файлы устройств /dev/tty и /dev/pts

К примеру, файл устройства /dev/tty1 представляет терминал или консоль, соединенную с системой. (Не стоит ломать голову над точными значениями терминов ‘терминал’ или ‘консоль’, так как в данном случае имеется в виду интерфейс командной строки системы.) При вводе команд в эмуляторе терминала, поставляемом в составе такого графического окружения рабочего стола, как Gnome или KDE, ваш терминал будет представлен файлом устройства /dev/pts/1 (вместо числа 1 может использоваться другое число).

Файл устройства /dev/null

В Linux вы можете обнаружить и другие файлы специальных устройств, такие, как файл устройства /dev/null , которое может рассматриваться как черная дыра; хотя соответствующее устройство и имеет неограниченную емкость, после записи из него не могут быть прочитаны никакие данные. Говоря техническим языком, любые записанные на представленное файлом /dev/null устройство данные будут просто отброшены. Представленное файлом /dev/null устройство может быть использовано для отбрасывания ненужного вывода различных команд. Помните о том, что представленное файлом /dev/null устройство не является удачным местом для хранения ваших резервных копий данных 😉.

Директория /proc и взаимодействие с ядром ОС

Большая часть файлов из директории /proc предназначена исключительно для чтения, причем для чтения некоторых из них требуются привилегии пользователя root; в некоторые файлы могут записываться данные, причем в директории /proc/sys таких файлов большинство. Давайте поговорим о некоторых файлах из директории /proc.

Директория /sys для работы с системой горячего подключения устройств ядра Linux 2.6

Директория /sys была создана в процессе разработки версии 2.6 ядра Linux. С момента выпуска версии 2.6 ядро Linux использует файловую систему sysfs для реализации механизма горячего подключения устройств, использующих шины usb и IEEE 1394 ( FireWire ). Обратитесь к страницам руководств udev(8) (данная подсистема пришла на смену подсистеме devfs ) и hotplug(8) для получения дополнительной информации (или посетите ресурс http://linux-hotplug.sourceforge.net/).

По существу, директория /sys содержит файлы с информацией об используемом аппаратном обеспечении.

Директория системных ресурсов Unix /usr

Несмотря на то, что имя директории /usr напоминает слово user (пользователь), не следует забывать о том, что на самом деле оно расшифровывается как Unix System Resources (директория системных ресурсов Unix). Иерархия поддиректорий директории /usr должна содержать разделяемые данные приложений, доступные только для чтения . Некоторые системные администраторы осуществляют монтирование файловой системы /usr в режиме только для чтения. В этом случае данная директория должна быть расположена на отдельном разделе жесткого диска или на разделяемом ресурсе NFS.

(В системе Solaris директория /bin является символьной ссылкой на директорию /usr/bin .)

Директория для изменяемых данных /var

Файлы заранее неизвестного размера, такие, как файлы журналов, файлы кэша и файлы очереди печати должны сохраняться в директории /var .

Директория /var/spool обычно содержит поддиректории для хранения файлов с сообщениями электронной почты и данными задач cron , причем она также может быть родительской директорией для других файлов очередей (например, файлов очередей печати).

Директория /var/lib содержит файлы с данными состояния приложений.

Дистрибутив Red Hat Enterprise Linux, к примеру, хранит файлы, относящиеся к менеджеру пакетов rpm , в поддиректории /var/lib/rpm/ .

Другие директории /var/.

Директория /var также содержит файлы с идентификаторами процессов в поддиректории /var/run (которая в недалеком будущем будет заменена на директорию /run ), временные файлы, которые не должны удаляться при перезагрузке, в поддиректории /var/tmp , а также файлы блокировок в поддиректории /var/lock . Далее в данной книге будут приведены дополнительные примеры использования директории /var для хранения данных.

Практическое задание: дерево директорий Linux

1. Существует ли файл /bin/cat ? Как насчет файлов /bin/dd и /bin/echo . Какого типа данные файлы?

2. Каков общий объем файлов ядра Linux (vmlinu*) в директории /boot?

/test. После этого выполните следующие команды:

Утилита dd осуществит копирование одного блока (count=1) размером в 100 байт (bs=100) из специального файла /dev/zero в файл

/test/zeroes.txt. Какие пояснения вы можете дать относительно возможностей специального файла /dev/zero ?

Утилита dd осуществит копирование одного блока (count=1) размером в 100 байт (bs=100) из специального файла /dev/random в файл

/test/random.txt. Какие пояснения вы можете дать относительно возможностей специального файла /dev/random ?

С помощью первой команды будет выведен список файлов блочных устройств, с помощью второй — список файлов символьных устройств. Что вы можете сказать по поводу различий между символьными и блочными устройствами.

6. Используйте команду cat для вывода содержимого файлов /etc/hosts и /etc/resolv.conf . Что вы думаете по поводу предназначения данных файлов?

7. Хранятся ли какие-нибудь файлы в директории /etc/skel/ ? Не забудьте проверить наличие скрытых файлов.

8. Выведите содержимое файла /proc/cpuinfo . Машину какой архитектуры вы используете для работы с Linux?

9. Выведите содержимое файла /proc/interrupts . Каков размер этого файла? Где хранится данный файл?

10. Можете ли вы перейти в директорию /root ? Есть ли в этой директории файлы (в том числе скрытые)?

11. Существуют ли бинарные файлы ifconfig, fdisk, parted, shutdown и grup-install в директории /sbin ? По какой причине эти бинарные файлы размещены в директории /sbin , а не в директории /bin ?

12. Является ли /var/bin файлом или директорией? Как насчет /var/spool ?

13. Откройте два эмулятора терминала (с помощью сочетания клавиш Ctrl+Shift+T в gnome-terminal) или терминала (с помощью сочетания клавиш Ctrl+Alt+F1, Ctrl+Alt+F2, . ) и выполните команду who am i в обоих. После этого попытайтесь передать слово из одного терминала в другой.

14. Прочитайте страницу руководства random и попытайтесь на основе полученной информации объяснить разницу между специальными файлами /dev/random и /dev/urandom .

Корректная процедура выполнения практического задания: дерево директорий Linux

1. Существует ли файл /bin/cat ? Как насчет файлов /bin/dd и /bin/echo . Какого типа данные файлы?

2. Каков общий объем файлов ядра Linux (vmlinu*) в директории /boot?

/test. После этого выполните следующие команды:

Утилита dd осуществит копирование одного блока (count=1) размером в 100 байт (bs=100) из специального файла /dev/zero в файл

/test/zeroes.txt. Какие пояснения вы можете дать относительно возможностей специального файла /dev/zero ?

Файл /dev/zero является специальным файлом устройства Linux. Он может рассматриваться как источник нулевых байт. Вы не можете записать какие-либо данные в файл /dev/zero , но вы можете читать нулевые байты из него.

Утилита dd осуществит копирование одного блока (count=1) размером в 100 байт (bs=100) из специального файла /dev/random в файл

/test/random.txt. Какие пояснения вы можете дать относительно возможностей специального файла /dev/random ?

Файл /dev/random выступает в качестве генератора случайных чисел вашей машины, работающей под управлением Linux.

С помощью первой команды будет выведен список файлов блочных устройств, с помощью второй — список файлов символьных устройств. Что вы можете сказать по поводу различий между символьными и блочными устройствами.

Данные всегда записываются на блочные устройства (или читаются с них) блоками. В случае жестких дисков размер блоков обычно равен 512 байтам. Символьные устройства работают как источники или приемники потоков символов (или байт). Мышь и клавиатура являются типичными символьными устройствами.

6. Используйте команду cat для вывода содержимого файлов /etc/hosts и /etc/resolv.conf . Что вы думаете по поводу предназначения данных файлов?

7. Хранятся ли какие-нибудь файлы в директории /etc/skel/ ? Не забудьте проверить наличие скрытых файлов.

Выполните команду «ls -al /etc/skel/». Да, в данной директории должны храниться скрытые файлы.

8. Выведите содержимое файла /proc/cpuinfo . Машину какой архитектуры вы используете для работы с Linux?

Данный файл должен содержать как минимум одну строку с названием модели центрального процессора производства компании Intel или какой-либо другой компании.

9. Выведите содержимое файла /proc/interrupts . Каков размер этого файла? Где хранится данный файл?

Размер файла равен нулю байт, но при этом файл содержит данные. Он не хранится где-либо на диске, так как в директорию /proc монтируется виртуальная файловая система, которая позволяет взаимодействовать с ядром ОС. (Ответ «файл хранится в оперативной памяти» также является верным. )

10. Можете ли вы перейти в директорию /root ? Есть ли в этой директории файлы (в том числе скрытые)?

Попытайтесь выполнить команду «cd /root». Директория /root не доступна для чтения обычными пользователями в большинстве современных дистрибутивов Linux.

11. Существуют ли бинарные файлы ifconfig, fdisk, parted, shutdown и grup-install в директории /sbin ? По какой причине эти бинарные файлы размещены в директории /sbin , а не в директории /bin ?

Да. Так как данные бинарные файлы должны использоваться исключительно системными администраторами.

12. Является ли /var/bin файлом или директорией? Как насчет /var/spool ?

По обоим путям расположены директории.

13. Откройте два эмулятора терминала (с помощью сочетания клавиш Ctrl+Shift+T в gnome-terminal) или терминала (с помощью сочетания клавиш Ctrl+Alt+F1, Ctrl+Alt+F2, . ) и выполните команду who am i в обоих. После этого попытайтесь передать слово из одного терминала в другой.

14. Прочитайте страницу руководства random и попытайтесь на основе полученной информации объяснить разницу между специальными файлами /dev/random и /dev/urandom .

Источник