1. Лекция 4
8 октября 2018 г.
Заметили ошибку или есть предложение? Напишите на почту: romansdidnotcrucify@gmail.com
ACHTUNG! WORK IN PROGRESS!
Данная страница ещё не закончена и находится в процессе дополнения и переработки. Почитать уже можно, но не забудьте потом заглянуть, когда будет полная версия.
Содержание
у нас сегодня по плану небольшое отступление: мы начали бодро рассматривать разные классы задач и их различные решения
но, мне кажется, настала пора сделать отступление в пользу различных других инструментов и подробнее про них поговорить
все те инструменты, которые я постоянно использую, когда привожу какие-то другие примеры
много времени на это нет, но без того, чтобы немного упорядочить наши знания в этой области, вряд ли у нас что-то получится
прежде, чем мы залезем в комнадную строку, давайте поговорим ещё раз о том, зачем
если пытаться встречать линукс по одёжке, увидите много всего разного и друг на друга непохожего
однако при подборе инструментов некоторые вещи, связанные с управлением ос, останутся либо неизменными, либо очень похожими
инварианты
Полных инвариантов довольно мало:
- всё, что связано с текстовым вводом/выводом, в частности, текстовым управлением системой
- стандартное дерево каталогов
- права доступа и то, как процессы осуществляют доступ к файлам
даже эти три вещи в одну лекцию не влезут
в немалой степени тот факт, что в линукс-системе хорошо известно, где что находится, определяется тем, что каждый каталог файловой системы предназначен для хранения файлов определённого типа
нарушение этих правил является, как минимум, дурным тоном, а иногда нарушить эти правила и вовсе не получится
если следовать правилам, порядок в файловой системе сохранится
файловая система:
- физический способ хранения данных на носителе - ext4, btrfs, vfat, fat32 - способ размещения информации на диске
- дерево каталогов - и вот именно эта вещь в линуксе достаточно строго стандартизирована
есть даже более или менее живой проект - Filesystem Hierarchy Standard (FHS) - устанавливающий стандарт организации дерева каталогов (и где что должно лежать)
вся файловая система начинается с некоторого общего корня, содержимое которого стандартное
bin, sbin - исполняемые программы (нужные всем / системные)
boot - файлы для загрузки (в частности, ядро, стартовые виртуальные диски, memtest, настройки загрузчики)
dev - псевдофайлы - устройства
etc - настройки системы
home - домашние каталоги пользователей (единственный каталог, куда обычному пользователю можно что-то записывать, кроме tmp)
сегодня мы не будем подробно говорить про права доступа, но по умолчанию обычный пользователь имеет достаточно ограниченные права
root - пользователь, которому можно всё (это специальная группа привилегий, не системный администратор)
su - получение прав суперпользователя (запуск процесса)
sudo - можно указать, какие именно команды какие именно пользователи при каких именно условиях могут смотреть/изменять
в файловой системе, помимо файлов и каталогов, есть символьные ссылки - в них лежит путь к тому файлу, к которому действительно нужно обращаться
разница между sudo и su ещё в том, что вы действительно становитесь другим пользователем - суперпользователем
в убунте суперпользователь как бы есть, но его как бы нет
размер символьной ссылки (обычно?) совпадает с количеством символов в пути, который она в себе содержит
wc - word counter
lib, lib64, libx32 - библиотеки - то, без чего программы не работают, сборники подпрограмм (статические и динамические)
если вы возьмёте и удалите их - у вас не будет работать ни одна программа (останутся работать дай бог пара программ)
libx32 - система 64 разрядная, а адреса - 32-разрядные
что интересно в lib64: почему есть несколько библиотек с одинаковыми именами (объект и ссылка на него)
есть договорённость (её не все соблюдают) - если у вас изменилась субмажорная (минорная) версия библиотеки, в ней сохраняется ABI
при изменении мажорной версии сохранение ABI никто не гарантирует
это помогает сделать обновление более безболезненным - для запуска программы используется символьная ссылка, и минорные обновления проходят незаметно
раз уж пошла такая пьянка, давайте посмотрим, какие библиотеки требует ls для запуска
ldd - напечатать зависимости программы (это такая обманка, на самом деле)
ls требуется, в том числе, обработка регулярных выражений в стиле Perl (странно и неожиданно)
media, mnt, run - предназначены для примонтирования файловых систем
поскольку корень один общий, для того, чтобы одна файловая система (во втором смысле) могла работать с файловыми системами (в первом смысле), нужно это как-то совмещать
этим занимается команда mount
пример с sdb3 (старой убунтой, которую кто-то ставил в отдельный раздел)
umount - чтобы отмонтировать
# - значит, я работаю с правами суперпользователя
информация о состоянии файловой системы хранится в ядре (о том, что куда примонтировано, по крайней мере)
при старте ос кое-какие каталоги таки монтируются (правда, большинство из них - виртуальные файловые системы)
grep - поиск регулярного выражения
/etc/fstab - информация о монтируемых на страрте каталогов
lsblk - информация о разделах
blkid - информация о разделах и их UUID
продолжим разговор о монтировании
даже в /etc/fstab информации явно больше, чем ожидалось
proc - виртуальная фс: для того, чтобы у нас был файловый доступ к информации о самой системе (что очень удобно)
/proc/cpuinfo
/proc/meminfo - информация об актуальном состоянии памяти
на самом деле этих файлов нет; это всего лишь такие имена, по которым мы можем обратиться, чтобы получить системную информацию (обращение напрямую к ядру)
поэтому у многих их этих файлов нулевой размер (актуальный размер этих "файлов" нет смысла высчитывать)
в linux главный принцип: всё - текст
к таблице mountpoint можно получить доступ через файл [посмотреть имя файла]
/self - ссылка на информацию о процессе, который хочет прочесть эту информацию
/sys/ - целое дерево каталогов, описывающее аппаратную составляющую системы
/sys/devices - информация о шинах PCI
/dev - специальные файловые объекты, отвечающие за внешние устройства
у них вместо размера - два числа (старший и младший номера устройства - грубо говоря, номер драйвера и номер устройства, распознавшего этот драйвер (???))
эти объекты файловой системы - не до конца файлы:
- не хранят данные в обычном смысле
- не из всех из них можно и писать, и читать
/dev/zero - много-много нулей (устройство, позволяющее попросить у ядра побольше нулей)
hexdump - команда, показывающая шестнадцатеричный дамп файла
три предназначения:
- очистка памяти, занятого программой
- завести пустой файл с нулями
- ???
/dev/null - место, куда можно что угодно записывать (и всё попадёт в никуда)
если не знаете, куда направить вывод - направляйте его в /dev/null
> - перенаправление вывода команды в файл
| - конвейер - перенаправление вывода одной команды на ввод другой команды
/dev/urandom - случайные байты (много)
чем устройства ещё отличаются от файлов: с жёсткими дисками можно проводить ещё много всяких операций
поэтому у большинства внешних устройств есть ещё специальный вызов ioctl, позволяющий вызывать специфические для устройства операции
/dev/random - гарантирует надёжные случайные байты /dev/urandom - псевдослучайные числа (количество энтропии не уменьшится)
есть два способа генерировать случайные байты:
- подождать, пока система какое-то время поработает, и взять какую-то статистику (движения мышки) - но тут энтропия может закончиться
- встроенный генератор случайных чисел в современных процессорах (замер электромагнитного шума)
для серьёзной криптографии - только отдельное аппаратное устройство
urandom точно не подходит, random - ещё хоть как-то подойдёт
dev - тоже devtmpfs (тоже виртуальная фс) - файловая система в памяти, в которой, когда добавляется новое устройство в систему, добавляется файл
обычный файл начинается в выводе ls на ???
каталог начинается на d
в dev - файлы, начинающиеся на с (character device - посимвольное чтение) и b (block device - чтение только по блокам)
обычные файлы, скорее всего, читаются поблочно
терминал - побайтовое устройство
ещё есть файлы, начинающиеся на s - socket (аналогия с дырой из yellow submarine)
имеется в виду файловый сокет, не интернет-сокет
mkfifo - сделать односторонний канал (объект типа pipe) (fifo - first in - first out)
один в него пишет, другой - читает
конвейер - | на самом деле организован через такой же, только неименованный, односторонний канал
таких каналов можно сделать много, целую гармошку сделать
cd - сменить текущий каталог
pwd - узнать текущий каталог (print working directory)
зачем менять каталог - чтобы не указывать полный путь до файлов при работе с различными программами (не нужно указывать полный путь лишь для файлов, лежащих в текущем каталоге)
договорим об именах файлов:
файл QQ
символьная ссылка на QQ - QKRQ
в linux есть возможность придать одному тому же файлу несколько имен
через команду ln
уникальным идентификатором файла явлется не имя файла - их может быть сколько угодно - а идентификатор (так и называется)
с помощью ls -li можно увидеть, на какие идентификаторы ссылаются имена файлов
rm - удалить файл
в некоторых файловых символах данные хранят с помощью битых символьных ссылок (они быстрее читаются, не нужно тратить время на открытие и закрытие)
такие строчки есть и в /proc/fs
rm ни у кого не спрашивает, просто удаляет файл
alias - позволяет заменить одну команду на другую
unalias - снять псевдоним, алиас
по умолчанию rm - это псевдоним, не сама программа rm
удаление последнего из его имён приводит к реальному удалению файла (точная реализация зависит от конкретной файловой системы)
в супербезопасных системах эта информация буквально перезатирается
символьную ссылку можно сделать чему угодно, даже несуществующему файлу
дополнительное имя можно сделать только файлу, не каталогу
ls -a - увидеть ещё и . и .. . - текущий каталог .. - родительский каталог
ссылки на текущий каталог нельзя создавать, но у любого каталога (???) в каждый момент есть несколько имён:
- имя в родительском каталоге
- . в данном каталоге
- .. в дочернем каталоге
каталог - таблица, какое имя соответствует какому дескриптору
всё это работает только в рамках одной файловой системы в первом смысле (уникальная идентификация файлов по индексному дескриптору уникальна только в рамках одной файловой системы)
tmp - ещё один каталог, в который обычный пользователь может писать
inode - идентификатор, уникальный в рамках файловых системах (но его может не быть в фс вообще)
sort - сортировка лексикографически
sort -n - сортировка как чисел
uniq -c - проверить уникальность имён
чтобы uniq работала, вывод должен быть отсортирован
обратите внимание: можно внезапно столкнуться с задачей, в которой нужно работать с фс, и эта задача превращается в задачу обработки текстов
/opt, /srv - внесистемные данные
/var - для хранения файлов, длина которых всё время меняется
/usr - такие же подкаталоги (не все), как и в корне - страшное дремучее legacy, которому лет 40
история была такая: люди, которые делали unix
у них был большой жёсткий диск, на 8 MB
Потому им купили ещё один большой диск - на 20 MB
и они примонтировали его в /usr и стали класть в него всё то, что раньше приходилось удалять
/usr/share - документация, системно независимые файлы
/usr - может быть на другой файловой системе
по идее, содержимое usr может быть смонтировано исключительно readonly
/usr/local - каталог, в который кладутся файлы, уникальные для данного конкретного компьютера
если вы ставите что-то руками - скорее всего, в opt
если что-то ставится само, скорее всего, оно окажется в /usr/local