1. Лекция 4

8 октября 2018 г.

Заметили ошибку или есть предложение? Напишите на почту: romansdidnotcrucify@gmail.com

/!\ ACHTUNG! WORK IN PROGRESS! /!\

Данная страница ещё не закончена и находится в процессе дополнения и переработки. Почитать уже можно, но не забудьте потом заглянуть, когда будет полная версия.

Содержание

  1. Лекция 4

у нас сегодня по плану небольшое отступление: мы начали бодро рассматривать разные классы задач и их различные решения

но, мне кажется, настала пора сделать отступление в пользу различных других инструментов и подробнее про них поговорить

все те инструменты, которые я постоянно использую, когда привожу какие-то другие примеры

много времени на это нет, но без того, чтобы немного упорядочить наши знания в этой области, вряд ли у нас что-то получится

прежде, чем мы залезем в комнадную строку, давайте поговорим ещё раз о том, зачем

если пытаться встречать линукс по одёжке, увидите много всего разного и друг на друга непохожего

однако при подборе инструментов некоторые вещи, связанные с управлением ос, останутся либо неизменными, либо очень похожими

инварианты

Полных инвариантов довольно мало:

  1. всё, что связано с текстовым вводом/выводом, в частности, текстовым управлением системой
  2. стандартное дерево каталогов
  3. права доступа и то, как процессы осуществляют доступ к файлам

даже эти три вещи в одну лекцию не влезут

в немалой степени тот факт, что в линукс-системе хорошо известно, где что находится, определяется тем, что каждый каталог файловой системы предназначен для хранения файлов определённого типа

нарушение этих правил является, как минимум, дурным тоном, а иногда нарушить эти правила и вовсе не получится

если следовать правилам, порядок в файловой системе сохранится

файловая система:

  1. физический способ хранения данных на носителе - ext4, btrfs, vfat, fat32 - способ размещения информации на диске
  2. дерево каталогов - и вот именно эта вещь в линуксе достаточно строго стандартизирована

есть даже более или менее живой проект - 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 - специальные файловые объекты, отвечающие за внешние устройства

у них вместо размера - два числа (старший и младший номера устройства - грубо говоря, номер драйвера и номер устройства, распознавшего этот драйвер (???))

эти объекты файловой системы - не до конца файлы:

  1. не хранят данные в обычном смысле
  2. не из всех из них можно и писать, и читать

/dev/zero - много-много нулей (устройство, позволяющее попросить у ядра побольше нулей)

hexdump - команда, показывающая шестнадцатеричный дамп файла

три предназначения:

  1. очистка памяти, занятого программой
  2. завести пустой файл с нулями
  3. ???

/dev/null - место, куда можно что угодно записывать (и всё попадёт в никуда)

если не знаете, куда направить вывод - направляйте его в /dev/null

> - перенаправление вывода команды в файл

| - конвейер - перенаправление вывода одной команды на ввод другой команды

/dev/urandom - случайные байты (много)

чем устройства ещё отличаются от файлов: с жёсткими дисками можно проводить ещё много всяких операций

поэтому у большинства внешних устройств есть ещё специальный вызов ioctl, позволяющий вызывать специфические для устройства операции

/dev/random - гарантирует надёжные случайные байты /dev/urandom - псевдослучайные числа (количество энтропии не уменьшится)

есть два способа генерировать случайные байты:

  1. подождать, пока система какое-то время поработает, и взять какую-то статистику (движения мышки) - но тут энтропия может закончиться
  2. встроенный генератор случайных чисел в современных процессорах (замер электромагнитного шума)

для серьёзной криптографии - только отдельное аппаратное устройство

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 - увидеть ещё и . и .. . - текущий каталог .. - родительский каталог

ссылки на текущий каталог нельзя создавать, но у любого каталога (???) в каждый момент есть несколько имён:

  1. имя в родительском каталоге
  2. . в данном каталоге
  3. .. в дочернем каталоге

каталог - таблица, какое имя соответствует какому дескриптору

всё это работает только в рамках одной файловой системы в первом смысле (уникальная идентификация файлов по индексному дескриптору уникальна только в рамках одной файловой системы)

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


LecturesCMC/LinuxIntro2018/03_CommandlineFiles/Conspect (последним исправлял пользователь RomanKrivonogov 2018-10-08 19:50:19)