Содержание

1 Изучение UNIX® (Linux) 6

1.1 Человеко-машинные системы 6

1.2 Процедурные системы 9

1.3 Проективные системы 12

1.4 Открытые технологии 15

1.4.1 История развития GNU/Linux 16

1.4.2 Архитектура и философия UNIX®. 22

2 Компоненты UNIX® 23

2.1 Ядро 23

2.2 Управление памятью 24

2.3 Управление процессами 25

2.4 Демоны 26

2.5 Понятие файла в Linux 26

2.6 Организация хранения файлов 27

2.6.1 Что такое файловая система? 28

2.7 Файловые системы Linux 30

2.8 Утилиты 31

2.9 Типы программ 31

3 Процедура загрузки ОС Linux 32

3.1 Основные конфигурационные файлы 35

3.2 Загрузка в однопользовательском режиме 39

3.3 Настройка общесистемных сервисов 40

3.3.1 Редактирование файла /etc/fstab 40

3.4 Файлы и разделы подкачки 41

3.5 Запуск демонов 43

3.6 Процессы 44

3.7 Управление процессами 46

3.7.1 Команда ps 46

3.7.2 Команда top 48

3.7.3 Приоритеты 50

3.7.4 Сигналы и команда kill 51

3.7.5 Перевод процесса в фоновый режим 53

3.8 GNU GRUB загрузчик 55

3.8.1 Что такое GRUB? 55

3.8.2 Компиляция и инсталляция программного пакета GRUB 56

3.8.3 Инсталляция загрузчика GRUB 57

3.8.4 Конфигурация GRUB 59

4 Справочная система Linux 63

4.1 Руководство (MAN) 63

4.1.1 Утилита man 64

4.2 Утилиты whatis и apropos 64

4.3 Работа с man 65

4.3.1 Система info 65

4.3.2 LDP 68

4.3.3 HOWTO файлы 68

4.3.4 Ресурсы в Интеренете. 68

5 Оболочка, Shell, командный интерпетатор. 69

5.1 Начало работы с Shell 70

5.2 Программы 71

5.2.1 Выполнение команд 71

5.3 Команды Shell 72

5.3.1 Опции 74

5.3.2 Аргументы 77

5.3.3 Исключения 79

5.4 Виртуальные консоли 80

5.5 Псевдонимы и переменные 81

5.6 Навигация и редактирование 86

5.7 История команд 89

5.8 Простые регулярные выражения 91

5.9 Запуск команды на выполнение 97

5.10 Стандартный ввод/вывод 98

5.11 Фильтры 103

6 Shell как язык программирования 104

6.1 Сценарий 104

6.2 Запуск сценария 107

6.3 Встроенные переменные 108

6.4 Условия проверки 109

6.4.1 Сложные условия поиска: 111

6.4.2 Условный оператор "if" 112

6.4.3 Конструкции 112

6.4.4 Оператор вызова ("case") 114

6.4.5 Пустой оператор 122

6.5 Функции в shell 122

6.6 Популярные команды 123

6.6.1 Поиск файлов. 123

6.6.2 Поиск внутри файла 125

7 Управление пользователями 125

7.1 Структура файла /etc/passwd 126

7.2 Структура файла /etc/group 126

7.3 Псевдопользователи 127

7.4 Команды работы с учетными записями пользователей 127

8 Установка программного обеспечения 129

8.1 Утилита rpm 130

8.2 Утилита Apt 135

8.2.1 Использование APT 136

8.2.2 Установка или обновление пакетов. 137

8.2.3 Удаление установленного пакета. 138

8.2.4 Обновление всех установленных пакетов 138

8.2.5 Поиск в репозитарии 138

9 Сборка ПО из исходных кодов 139

9.1.1 Необходимые сведения о программировании на языке Си 139

9.1.2 Инсталляция из исходных текстов 141

10 Файловая система 141

10.1 Основы работы файловых стистем 142

10.1.1 Файлы 142

10.1.2 Каталоги 144

10.1.3 Типы файлов 147

10.1.4 Файлы физических устройств 147

10.1.5 Именованные каналы (pipes) 149

10.1.6 Сокеты (sockets) 150

10.1.7 Символические ссылки 150

10.1.8 Права доступа к файлам и каталогам 152

10.1.9 Расширенные атрибуты доступа 158

10.2 Управление файловой системой 159

10.2.1 Разбиение диска на разделы, fdisk 159

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

10.2.3 Команды для работы с файлами 167

10.3 Команда find и символы шаблонов для имен файлов 171

10.4 Команда split — разбиваем файл на несколько частей 174

10.5 Сравнение файлов и команда patch 174

10.6 Команды архивирования файлов 176

10.6.1 Программа tar 176

10.6.2 Программа gzip 179

10.6.3 Программа bzip2 181

10.6.4 Примеры применения tar 182

11 Сетевая файловая система (NFS) 182

11.1 Запуск NFS 184

11.2 Монтирование тома NFS 184

11.3 NFS Daemons 187

11.4 Файл exports 187

12 Популярные приложения 190

12.1 Эффективная работа с vim 190

12.2 Эффективно передвигаемся по файлу 190

12.3 Вставка 193

12.4 Midnight Commander 194

12.4.1 Использование MC 195

12.4.2 Встроенный ftp-клиент 196

12.4.3 Переименование групп файлов 196

13 Сетевые средства Linux 198

13.1 Общие сведения о сетях 198

13.1.1 Стек TCP/IP 199

13.1.2 Адресация Internet 205

13.1.3 Система имен доменов (DNS - Domain Name System) 206

13.1.4 Модель Клиент-Сервер 209

13.1.5 Адреса TCP/IP 211

13.1.6 Преобразование адресов 213

13.2 Конфигурация сетевых интерфесов 214

13.2.1 Адрес сети 214

13.2.2 Широковещательный адрес 214

13.2.3 Адрес шлюза 214

13.2.4 Адрес сервера имен 215

13.2.5 Маска сети 215

13.3 Файлы конфигурации TCP/IP 215

13.3.1 файл /etc/hosts 217

13.3.2 файл /etc/networks 218

13.3.3 файл /etc/init.d/network 218

13.3.4 Параметры DNS 219

13.3.5 файл host.conf 220

13.3.6 Файл /etc/resolv.conf 220

13.4 Команда ifconfig 221

13.5 Маршрутизация 223

13.6 IP-псевдонимы (IP-Alias) 225

14 Контроль состояния сети 226

14.1 Ping 226

14.2 netstat 226

14.3 Команда lsof 228

14.4 Проверка ARP-таблиц 228

15 Управление работой межсетевого экрана (брандмауэра) netfilter 230

15.1 Настройка межсетевого экрана Iptables 230

15.2 Порядок прохождения таблиц и цепочек 231

15.2.1 Общие положения 231

15.3 Как строить правила - основы 235

15.3.1 Команды 236

15.3.2 Критерии 238

15.3.3 Общие критерии 238

15.4 Неявные критерии 240

15.4.1 TCP критерии 240

15.4.2 UDP критерии 243

15.4.3 Критерий MAC 244

16 Shorewall: iptables с человеческим лицом 244

16.1 Базовая настройка 246

16.2 Фильтрация трафика 250

16.3 Дополнительные возможности 252

16.3.1 Вместо заключения 254

16.4 Приложение. Устанавливаем Shorewall 254

17 Управление ядром 254

17.1 Версия ядра 254

17.2 Причины для пересборки ядра 255

17.3 Подготовка 255

17.4 Компиляция (Make) 256

17.5 Установка заплат 257

17.6 Сборка единичного модуля 258

17.7 Sytem.map 259

18 Мониторинг системы 259

18.1 Система ведения логов 259

18.2 Демон Syslogd 259

18.2.1 Параметры запуска 260

18.2.2 Сигналы 260

18.2.3 Файл конфигурации 261

18.2.4 Советы по настройке SYSLOG 266

18.3 logger - утилита записи в журнал 266

18.4 logrotate или "что делать со старыми журналами?" 267

18.5 logwatch или "как извлечь полезную информация из кучи мусора?" 269

19 CRON - планирование заданий 272

19.1 Настройка задач Cron 274

19.2 Запуск и остановка службы 276

19.3 Системное время 276

20 Резервное копирование в Linux 276

20.1 Использование серверов резервного копирования 277

20.2 Аппаратные средства, предназначенные для создания резервных копий 277

20.3 Способы резервного копирования 278

20.3.1 Резервное копирование, инициируемое клиентом 279

20.3.2 Резервное копирование, инициируемое сервером 280

20.4 Использование tar 281

20.4.1 Возможности tar 281

20.4.2 Список команд tar: 281

20.4.3 Использование smbtar 291

20.4.4 Создание разделяемых объектов резервного копирования 296

20.5 Обзор и установка системы резервного копирования BackupPC 299

20.5.1 Введение 299

20.5.2 Требования к установке 301

20.5.3 Настройка BackupPC 304

20.5.4 Интерфейс 307

21 Основы безопасности Linux 307

21.1 Меры предосторожности 309

21.2 Принципы защиты 310

21.3 Идентификаторы пользователя и группы пользователей 311

21.4 PAM 312

21.4.1 Безопасность файлов 313

21.5 Важные системные файлы 316

21.6 Проблемы защиты /etc/passwd и /etc/shadow 320

21.6.1 Скрытые пароли 321

21.6.2 Устаревание паролей 322

1Изучение unix® (Linux)

UNIX® невозможно изучить урывками, читая книжку в метро, а тем более - не подходя к компьютеру. Это непростая задача требующая определенных усилий и добровольного самопринуждения действовать правильно и методично.

Рассмотрим самый, на наш взгляд, естественный алгоритм решения любой задачи:

1. уяснить задачу;

2. выбрать самый подходящий инструмент решения (самый подходящий, а не самый знакомый!);

3. освоить этот инструмент (начиная с изучения документации).

4. придумать по возможности красивое решение;

5. зафиксировать это решение (чтобы можно было в случае чего повторить);

6. применить его.

Казалось бы, спорить не с чем, но как часто мы поступаем строго наоборот! Желая "сэкономить время", мы нередко начинаем с того, что так и эдак применяем попавшиеся под руку инструменты (6) и даже начинаем набрасывать кое-какие сценарии или проекты решения (5). Потом мы задумываемся над тем, как же решить нашу задачу "по уму" (4), и понимаем, что инструмент нам, в сущности, незнаком, что надо изучать руководство (3). Из руководства выясняется, что инструмент нам не подходит, и приходится искать другой (2). И только тогда мы понимаем, что для этого надо разобраться, какую именно задачу мы решаем (1).

Драма пользователя UNIX® в том, что система на такой непрофессиональный способ взаимодействия не рассчитана. Если начинать не с начала, времени на решение будет потрачено гораздо больше. К тому же это верное средство создать хаос в собственной голове.

1.1Человеко-машинные системы

Эта тема чрезвычайно важна для правильного понимания сути обсуждаемых далее тем. Оставшийся один на один с машиной человек называется пользователем. Пользователь - часть человеко-машинной системы, он ставит перед машиной задачи и добивается их решения. Специалист-разработчик не является частью этой системы: свою работу - создание системы и инструкций к ней - он уже сделал.

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

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

Пользователь как клиент

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

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

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

Кто оказывается главным в такой системе, от кого зависит качество получаемого продукта? Машина, а точнее создатели системы, заложившие в нее соответствия между рычагами управления и выполняемыми действиями. Если после нажатия очередной кнопки объект, вопреки сказанному в инструкции, испортился - это недоработка авторов, а не ошибка клиента: все, что он мог сделать, - не нажимать на кнопку. Клиент такой системы требует гарантий качества от разработчиков, потому что сам в силах гарантировать только неукоснительное следование инструкциям.

Пользователь как администратор

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

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

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

Такой подход требует, чтобы в системе были предусмотрены разнообразные универсальные и специализированные средства создания решений любых возможных задач. Для компьютера это высокоуровневые языки программирования и отдельные программы для элементарных взаимодействий с системой. Для автомобиля - набор удобных ключей и прочих инструментов для работы с любой деталью и всевозможные насосы-домкраты. Решив (чаще всего чисто умозрительно) поставленную задачу, администратор дает команду машине: "Делай по моему проекту". Машина работает, а пользователь занимается другими делами, не забывая, однако, приглядывать за системой: хорошо ли справляется с задачей его творение, не стоит ли где подправить? Составление проекта, по которому машина будет решать задачи самостоятельно, - ключевая особенность, иначе пользователю пришлось бы делать часть формализуемой работы за машину, поэтому организованные таким образом системы можно назвать проективными.

Про уровень знаний о системе, необходимый пользователю-администратору, - чем больше он знает, тем лучше она работает. К сожалению, обратное тоже верно: чем меньше - тем хуже. Более того, "больше" должно быть именно знаний, то есть понимания внутрисистемных механизмов, а не просто сведений о том, как в разных случаях пользоваться системой. К тому же администратор должен иметь ясное представление обо всех прикладных областях системы, даже если не является сам себе заказчиком.

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

В проективной системе как раз администратор дает гарантии качества получающегося продукта - в меру своей квалификации, конечно. Претензии к разработчикам возникают только тогда, когда очевидна неисправность инструмента (ее, как правило, все равно можно обойти при помощи другого инструмента). Так или иначе, в такой человеко-машинной системе больший авторитет имеет человек: сколь бы качественна ни была дрель, ею можно и починить рояль, и загубить его, все зависит от того, где и сколько сверлить.

Свобода от или свобода для?

Следует отметить парадокс, связанный с тем, насколько человек свободен во время работы с машиной. Не желая попасть в зависимость от машины, некто выбирает работу в качестве клиента процедурной системы. Под процедурную систему не нужно "подлаживаться": постигать ее структуру, учить "машинный язык", настраивать ее. Наоборот, сама система всячески демонстрирует, как она подстраивается под желания пользователя, даже предугадывает их. В результате почти все время работы в такой системе он проводит, скрупулезно выполняя ее команды вроде "для продолжения нажмите кнопку далее" или "выберите тип преобразования файла", то есть попадает в ситуацию, когда для эффективного решения своих задач ему приходится временно жертвовать собственной свободой.

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