|Фамилия |Логин |IP для tabularasaX /24|IP для studX /24|соответствующие белые адреса для studX на которые проброшены порты: 22, 25, 80, 110, 143, 443, 465, 587, 993, 995|доменные имена для studX|IP для examX /24|IP для gwX /24|IP для keepalived /24|IP для proxmox n1 /24|IP для proxmox n2 /24|IP для exam2_X /24|
Напишите команду, которая рекурсивно находит все HTML-файлы в папке и упаковывает их в `tar.gz` архив. Используйте `find` и `xargs`. Ваша команда должна работать, даже если в файлах есть пробелы (подсказка: используйте `null` разделитель).
## 20
(*) Напишите команду или сценарий для рекурсивного поиска самого последнего измененного файла в каталоге. В общем, можете ли вы перечислить все файлы по давности?
TODO install command
(*) Напишите команду или сценарий для рекурсивного поиска самого последнего измененного файла в каталоге. В общем, можете ли вы перечислить все файлы по давности?
Формально мы можем рассматривать процесс устранения неполадок как применение гипотетико-дедуктивного метода: учитывая набор наблюдений за системой и теоретическую основу для понимания поведения системы, мы итеративно выдвигаем гипотезы о потенциальных причинах сбоя и пытаемся проверить эти гипотезы.
В идеализированной модели, мы бы начали с отчета о проблеме, сообщающего нам, что с системой что-то не так. Затем мы можем просмотреть данные телеметрии и журналы системы, чтобы понять ее текущее состояние. Эта информация в сочетании с нашими знаниями о том, как устроена система, как она должна работать, и о режимах ее сбоев, позволяет нам выявить некоторые возможные причины.
Затем мы можем проверить наши гипотезы одним из двух способов. Мы можем сравнить наблюдаемое состояние системы с нашими теориями, чтобы найти подтверждающие или опровергающие доказательства. Или, в некоторых случаях, мы можем активно «лечить» систему, то есть изменять систему контролируемым образом, и наблюдать за результатами. Этот второй подход уточняет наше понимание состояния системы и возможных причин сообщаемых проблем. Используя любую из этих стратегий, мы неоднократно тестируем до тех пор, пока не будет определена основная причина, после чего мы можем предпринять корректирующие действия, чтобы предотвратить повторение, и написать postmortem. Конечно, для устранения непосредственной причины (причин) не всегда нужно ждать первопричины или postmortem заключения.
Пример postmortem https://sre.google/sre-book/example-postmortem/.
## Практика
Практический совет - в случае проблемы ищите руководства по устранению неполадок (имя технологии troubleshooting guide в google) для вашего программного обеспечения.
@ -43,31 +39,28 @@
#### Поиск синтаксических ошибок или предупреждений в конфигурации
С помощью простой команды вы можете проверить состояние файла конфигурации Nginx:
```
$ sudo systemctl config nginx
```
В выводе будет показано, правильный ли файл конфигурации, или, если это не так, он покажет файл и строку, в которой возникла проблема.
С помощью простой команды вы можете проверить состояние файла конфигурации Nginx: $ sudo systemctl config nginx В выводе будет показано, правильный ли файл конфигурации, или, если это не так, он покажет файл и строку, в которой возникла проблема.
```
$ sudo systemctl config nginx
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
```
Зайдите в файл `/etc/nginx/nginx.conf` и переместите директиву `worker_connections` внутрь блока `http`
Зайдите в файл /etc/nginx/nginx.conf и переместите директиву worker_connections внутрь блока http
```
$ sudo systemctl config nginx
"worker_connections" directive is not allowed here in /etc/nginx/nginx.conf:12
nginx: configuration file /etc/nginx/nginx.conf test failed
```
Если в вашей системе nginx не сконфигурирован как сервис `systemd`, вы можете использовать параметр `-t`, который также проверяет файл конфигурации на правильность синтаксиса, а затем пытается открыть файлы, указанные в конфигурации.
Если в вашей системе nginx не сконфигурирован как сервис systemd, вы можете использовать параметр -t, который также проверяет файл конфигурации на правильность синтаксиса, а затем пытается открыть файлы, указанные в конфигурации.
```
$ sudo nginx -t
```
Убедитесь, что Nginx работает. Проверить статус службы Nginx, вы можете использовать следующую команду:
Убедитесь, что Nginx работает
Проверить статус службы Nginx, вы можете использовать следующую команду:
```
$ sudo systemctl status nginx
```
@ -77,14 +70,14 @@ $ sudo systemctl status nginx
$ sudo /etc/init.d/nginx status
```
Или найти `nginx` среди процессов:
Или найти nginx среди процессов:
```
ps uax | grep nginx
```
Убедитесь, что порты открыты и служба их слушает
Убедитесь, что у вас открыты необходимые порты, и чтобы убедиться, что служба Nginx прослушивает их, вы можете использовать команду `lsof`, в идеале с портами по умолчанию `80` и `443`.
Убедитесь, что у вас открыты необходимые порты, и чтобы убедиться, что служба Nginx прослушивает их, вы можете использовать команду lsof, в идеале с портами по умолчанию 80 и 443.
Если Nginx действительно прослушивает соответствующие порты, следующим шагом будет проверка обработки запросов, что можно сделать с помощью инструмента `curl`с использованием IP-адреса, URL-адреса или локального хоста, если ваша установка прослушивает локальный хост:
Если Nginx действительно прослушивает соответствующие порты, следующим шагом будет проверка обработки запросов, что можно сделать с помощью инструмента curl с использованием IP-адреса, URL-адреса или локального хоста, если ваша установка прослушивает локальный хост:
После логина стрелки не работают и выводят странные символы. Исправьте проблему.
#### studX-troublesome-8
Залогиньтесь сначала в `stud` потом в `root`. Попробуйте обновить `apt` базу данных командой `apt update`. Посмотрите логи командой `journalctl -o short-iso`. В чём заключается проблема настройки машины? Исправьте её.
Залогиньтесь сначала в `stud` потом в `root`. Посмотрите логи командой `journalctl -o short-iso`. В чём заключается проблема настройки машины? Исправьте её.
Репликация это процесс в пространстве, backup это процесс во времени.
Репликация спасает от выхода из строя физического элемента хранения. Например, выход из строя диска/сервера/стойки/датацентра. RAID массивы на основе физических контроллеров и `mdadm` обеспечивают репликацию, которая спасает от выхода из строя диска на узле.
Backup спасает от выхода из строя элемента данных. Например, 09.12.2023 было выложено в ветку автоматических обновлений пакет обновления ядра, который приводил к повреждению данных при записи в Ext4 https://www.debian.org/News/2023/2023120902. При работе репликации в данном случае будут реплицированы повреждённые данные. Бэкапам также требуется репликация. Самая надежная, но наименее гибкая - репликация на разные несколько типов носителей: диски, флешки, оптические диски, ленты.
**Таблица 0. Минимально необходимая схема резервирования данных data(t,n)**
|| Устройство хранения n=1 | Устройство хранения n=2 |
|--|-|-|
|вчерашние данные t=0 | data(0,0) | data(0,1) |
|текущие данные t=1 | data(1,0) | data(1,1) |
### Таблица 1. Типы RAID массивов
|Тип| Описание| Количество дисков | Выдерживает потерю |
|---|---------|-----------| ------ |
| RAID0 | Дисковый массив из двух или более жёстких дисков без резервирования (striping — «чередование»). | от 2 | 0 дисков |
| RAID1 | Массив из двух дисков являющихся полными копиями друг друга (mirroring — «зеркалирование»). | от 2 | N-1 дисков |
| RAID2 | Данные распределяются по дискам, предназначенным для хранения информации, так же, как и в RAID 0, но требуются выделенные диски в массиве для хранения кодов Хэмминга для коррекции ошибок. | от 3 | 1 диска |
| RAID3 | В массиве RAID 3 из N дисков данные разбиваются на куски размером меньше сектора и распределяются по N-1 дискам. Ещё один диск используется для хранения блоков чётности. Коррекция ошибок проще, чем в RAID 2, коды коррекции занимают 1 диск, вместо log2(N) дисков. | от 4 | 1 диска |
| RAID4 | RAID 4 похож на RAID 3, но отличается от него тем, что данные разбиваются на блоки, а не на байты. Отчасти это решает проблему низкой скорости чтения данных небольшого объёма. | от 4 | 1 диска |
| RAID5 | Основным недостатком уровней RAID от 2-го до 4-го является невозможность производить параллельные операции записи, так как для хранения информации о чётности используется отдельный контрольный диск. RAID 5 не имеет этого недостатка. Дисковый массив с чередует блоки данных и блоки контроля чётности. | от 3 | 1 диска |
| RAID6 | Массив из четырёх или более дисков с проверкой чётности `P+Q` (двумя томами чётности) или `DP` (разработанный для защиты от потери данных при выходе из строя сразу двух жестких дисков в массиве). | от 4 | 2 дисков |
| RAID01 | Массив типа RAID 1, состоящий из двух вложенных массивов типа RAID 0. | от 4, чётное | от 1 до N/2 дисков |
| RAID10 | Массив типа RAID 0, составленный из двух и более RAID 1 (зеркалированных пар). | от 4, чётное | от 1 до N/2 дисков |
| RAID51 | Массив типа RAID 1, зеркалирующий два RAID 5. | от 6, чётное | 2 до N/2+1 дисков |
|Тип| Описание| Количество дисков | Выдерживает потерю |
|---|---------|-----------| ------ |
| RAID0 | Дисковый массив из двух или более жёстких дисков без резервирования (striping — «чередование»). | от 2 | 0 дисков |
| RAID1 | Массив из двух дисков являющихся полными копиями друг друга (mirroring — «зеркалирование»). | от 2 | N-1 дисков |
| RAID2 | Данные распределяются по дискам, предназначенным для хранения информации, так же, как и в RAID 0, но требуются выделенные диски в массиве для хранения кодов Хэмминга для коррекции ошибок. | от 3 | 1 диска |
| RAID3 | В массиве RAID 3 из N дисков данные разбиваются на куски размером меньше сектора и распределяются по N-1 дискам. Ещё один диск используется для хранения блоков чётности. Коррекция ошибок проще, чем в RAID 2, коды коррекции занимают 1 диск, вместо log2(N) дисков. | от 4 | 1 диска |
| RAID4 | RAID 4 похож на RAID 3, но отличается от него тем, что данные разбиваются на блоки, а не на байты. Отчасти это решает проблему низкой скорости чтения данных небольшого объёма. | от 4 | 1 диска |
| RAID5 | Основным недостатком уровней RAID от 2-го до 4-го является невозможность производить параллельные операции записи, так как для хранения информации о чётности используется отдельный контрольный диск. RAID 5 не имеет этого недостатка. Дисковый массив с чередует блоки данных и блоки контроля чётности. | от 3 | 1 диска |
| RAID6 | Массив из четырёх или более дисков с проверкой чётности `P+Q` (двумя томами чётности) или `DP` (разработанный для защиты от потери данных при выходе из строя сразу двух жестких дисков в массиве). | от 4 | 2 дисков |
| RAID01 | Массив типа RAID 1, состоящий из двух вложенных массивов типа RAID 0. | от 4, чётное | от 1 до N/2 дисков |
| RAID10 | Массив типа RAID 0, составленный из двух и более RAID 1 (зеркалированных пар). | от 4, чётное | от 1 до N/2 дисков |
| RAID51 | Массив типа RAID 1, зеркалирующий два RAID 5. | от 6, чётное | 2 до N/2+1 дисков |
Рассматрим структуру почтовой системы, в которой Postfix и Dovecot имеют доступ к списку пользователей и работают параллельно, разделяя доступ к почтовым ящикам пользователей.
Возможные структуры почтовой системы:
1. Postfix, Dovecot имеют доступ к списку пользователей и работают параллельно, разделяя доступ к почтовым ящикам пользователей.
2. Dovecot является «бэкендом» для доступа к почтовым ящикам пользователей. При этом подходе, расположение почтовых ящиков, список пользователей, известен только Dovecot.
В начале следует углубиться в теорию для понимания механизмов работы Postfix. Рассмотрим архитектуру Postfix, что такое классы адресов и какие бывают типы доменов. Затем рассмотрим классы адресов с точки зрения менеджмента почтовых ящиков. В конце разберёмся какие проблемы есть у почтовых серверов из-за спама, и как повысить надежность доставки писем вашим почтовым сервером.
Когда сообщение попадает в почтовую систему Postfix, первой остановкой внутри неё является очередь входящих сообщений `incoming`. На рисунке показаны основные процессы, связанные с новой почтой. Имена, за которыми следует цифра, представляют собой команды или программы сервера Postfix, а непронумерованные имена - очереди Postfix.
#### smtpd(8), qmqpd(8), pickup(8)
Почта из сети поступает в Postfix через сервисы `smtpd(8)` или `qmqpd(8)`. Эти сервисы удаляют инкапсуляцию протокола SMTP или QMQP, выполняют некоторые проверки на корректность для защиты Postfix и передают отправителя, получателей и содержимое сообщения сервис `cleanup(8)`. Сервис `smtpd(8)` может быть настроен на блокировку нежелательной почты, как описано в документе [SMTPD_ACCESS_README](https://github.com/vdukhovni/postfix/blob/master/postfix/README_FILES/SMTPD_ACCESS_README).
Локальные отправки принимаются с помощью команды Postfix `sendmail(1)` и помещаются в очередь `maildrop`с помощью привилегированной команды `postdrop(1)`. Эта схема работает даже тогда, когда почтовая система Postfix не работает. Локальный сервис `pickup(8)` собирает локальные отправленные сообщения, выполняет некоторые проверки работоспособности для защиты Postfix и передает отправителя, получателей и содержимое сообщения на сервису `cleanup(8)`.
#### cleanup(8)
Почта из внутренних источников передается непосредственно сервису `cleanup(8)`. Эти источники не показаны на рисунке и включают в себя: почту, пересылаемую агентом доставки `local(8)`, сообщения, возвращаемые отправителю сервером `bounce(8)`, и уведомления почтмейстера о проблемах с Postfix.
Сервер `cleanup(8)` реализует финальную стадию обработки перед постановкой почты в очередь. Он добавляет недостающие заголовки `From:` и другие сообщения, а также преобразует адреса, как описано в документе [ADDRESS_REWRITING_README](https://github.com/vdukhovni/postfix/blob/master/postfix/README_FILES/ADDRESS_REWRITING_README). При желании сервер `cleanup(8)` можно настроить для облегченной проверки содержимого с помощью регулярных выражений, как описано в документе BUILTIN_FILTER_README. Сервер `cleanup(8)` помещает результат в виде одного файла во входящую очередь `incoming` и уведомляет менеджер очередей `qmgr(8)`о прибытии новой почты.
#### trivial-rewrite(8)
Сервис `trivial-rewrite(8)` перезаписывает адреса в стандартную форму «user@complete.qualified.domain», как описано в документе [ADDRESS_REWRITING_README](https://github.com/vdukhovni/postfix/blob/master/postfix/README_FILES/ADDRESS_REWRITING_README). В настоящее время Postfix не реализует язык перезаписи, но многое можно сделать с помощью поиска по таблицам и, при необходимости, регулярных выражений.
Конфигурация сервисов участвующих в приёме почты в файле `master.cf`:
active ─────────► qmgr(8) ───────┼─ local(8) ───► File, command
▲ │
│ ├─ virtual(8) ─► File
▼ │
deferred └─ pipe(8) ────► Command
```
Как только сообщение достигнет входящей очереди, следующим шагом будет его доставка. На рисунке показаны основные компоненты доставки почты Postfix. Имена, за которыми следует номер, представляют собой команды Postfix или сервисы, а ненумерованные имена представляют очереди Postfix.
#### qmgr(8)
Менеджер очередей (серверный процесс `qmgr(8)` на рисунке) — это сердце доставки почты Postfix. Он связывается с агентами доставки `smtp(8)`, `lmtp(8)`, `local(8)`, `virtual(8)`, `pipe(8)`, `discard(8)` или `error(8)` и отправляет запрос на доставку одному или нескольким получателям. Агенты доставки `discard(8)` и `error(8)` являются особенными: они отбрасывают или возвращают всю почту и не показаны на рисунке выше.
Диспетчер очередей поддерживает небольшую активную очередь `active`с сообщениями, которые он открыл для доставки. Активная очередь действует как ограниченное окно для потенциально больших входящих `incoming` или отложенных `deferred` очередей. Ограниченная активная очередь не позволяет диспетчеру очередей исчерпать память при большой нагрузке.
Диспетчер очередей поддерживает отдельную отложенную очередь `deferred` для почты, которая не может быть доставлена, чтобы большой объем невыполненной почты не замедлял нормальный доступ к очереди. Стратегия администратора очередей в отношении отложенных попыток доставки почты описана в документах [QSHAPE_README](https://github.com/vdukhovni/postfix/blob/master/postfix/README_FILES/QSHAPE_README) и [TUNING_README](https://github.com/vdukhovni/postfix/blob/master/postfix/README_FILES/TUNING_README).
#### trivial-rewrite(8)
Сервер `trivial-rewrite(8)` разрешает каждый адрес получателя в соответствии сего локальным или удаленным классом адреса, как определено в документе [ADDRESS_CLASS_README](https://github.com/vdukhovni/postfix/blob/master/postfix/README_FILES/ADDRESS_CLASS_README). Дополнительную информацию о маршрутизации можно указать с помощью дополнительной таблицы `transport(5)`. Сервер `trivial-rewrite(8)` дополнительно запрашивает таблицу `relocated(5)`о получателях, чей адрес изменился; Для таких получателей письмо возвращается отправителю с объяснением.
#### smtp(8)
Клиент `smtp(8)` просматривает список почтовых обменников для хоста назначения, сортирует список по предпочтениям и пробует по очереди каждый сервер, пока не найдет сервер, который отвечает. Затем он инкапсулирует отправителя, получателя и содержимое сообщения в соответствии с требованиями протокола SMTP; это включает преобразование 8-битного MIME в 7-битное кодирование.
#### lmtp(8)
Клиент `lmtp(8)` использует протокол, аналогичный SMTP, который оптимизирован для доставки на серверы почтовых ящиков, такие как Cyrus. Преимущество этой настройки состоит в том, что одна машина Postfix может обслуживать несколько серверов почтовых ящиков через LMTP. Верно и обратное: один сервер почтовых ящиков может подключаться по LMTP к нескольким машинам Postfix.
#### local(8)
Агент доставки `local(8)` понимает почтовые ящики в стиле UNIX, qmail-совместимые файлы maildir, общесистемные базы данных `aliases(5)` в стиле Sendmail и файлы `.forward` для каждого пользователя в стиле Sendmail. Несколько локальных агентов доставки могут работать параллельно, но параллельная доставка одному и тому же пользователю обычно ограничена.
Агент доставки `local(8)` имеет несолько альтернативных формы локальной доставки. Вы можете настроить его:
- доставлять почту в файлы почтовых ящиков в домашних каталогах пользователей,
- делегировать доставку в почтовый ящик внешней команде, такой как `procmail`,
- делегировать доставку другому агенту доставки Postfix.
#### virtual(8)
Агент доставки `virtual(8)` — это простой агент доставки, который доставляет только в файлы почтового ящика в стиле UNIX или в файлы maildir в стиле qmail. Этот агент доставки может доставлять почту для нескольких доменов, что делает его особенно подходящим для размещения множества небольших доменов на одном компьютере. Подробнее описано в документе [VIRTUAL_README](https://github.com/vdukhovni/postfix/blob/master/postfix/README_FILES/VIRTUAL_README).
#### pipe(8)
Почтовая программа `pipe(8)` — это исходящий интерфейс к другим системам обработки почты (входящим интерфейсом является команда Postfix `sendmail(1)`. Интерфейс совместим с UNIX: он предоставляет информацию в командной строке и стандартном потоке ввода, а также ожидает код состояния завершения процесса, определенный в `<sysexits.h>`. Примеры доставки через почтовую программу `pipe(8)` находятся в документах [MAILDROP_README](https://github.com/vdukhovni/postfix/blob/master/postfix/README_FILES/MAILDROP_README) и [UUCP_README](https://github.com/vdukhovni/postfix/blob/master/postfix/README_FILES/UUCP_README).
Конфигурация сервисов участвующих в отправке почты в файле `master.cf`:
│ active ──────────► qmgr(8) ───────┼─ local(8) ───► File, command
postdrop(1) ▲ │
▲ │ ├─ virtual(8) ─► File
│ ▼ │
sendmail(1) deferred └─ pipe(8) ────► Command
▲
│
Local
```
Далее будет рассмотрен первый вариант. Но в начале следует углубиться в теорию для понимания механизмов работы Postfix. Рассмотрим что такое классы адресов и какие бывают типы доменов. Затем рассмотрим классы адресов с точки зрения менеджмента почтовых ящиков. В конце разберёмся какие проблемы есть у почтовых серверов из-за спама, и как повысить надежность доставки писем вашим почтовым сервером.
## Какое нам дело до классов адресов?
@ -197,7 +57,7 @@ AGENTS = service names ∈ /etc/postfix/master.cf
```
### 3. virtual alias domain class (виртуальные псевдонимы)
Назначение: хостинговые домены, в которых каждый адрес получателя псевдонимом привязан к учётной записи локальной UNIX-системы или к удаленному адресу. Пример виртуального псевдонима приведен в файле [VIRTUAL_README](https://github.com/vdukhovni/postfix/blob/master/postfix/README_FILES/VIRTUAL_README).
Назначение: хостинговые домены, в которых каждый адрес получателя псевдонимом привязан к учётной записи локальной UNIX-системы или к удаленному адресу. Пример виртуального псевдонима приведен в файле VIRTUAL_README.
Доменные имена перечисляются в virtual_alias_domains. Для совместимости с Postfix 1.1 по умолчанию используется значение $virtual_alias_maps.
@ -213,7 +73,7 @@ AGENTS = {}
```
### 4. relay domain class (адреса доменов-ретранляторов)
Назначение: переадресация почты на удаленные адреса, в которых ваша система указана в качестве основного или резервного MX-хоста. Для обсуждения основных деталей конфигурации см. документ [BASIC_CONFIGURATION_README](https://github.com/vdukhovni/postfix/blob/master/postfix/README_FILES/BASIC_CONFIGURATION_README). Обсуждение различий между каноническими доменами, размещенными доменами и другими доменами см. в файле [VIRTUAL_README](https://github.com/vdukhovni/postfix/blob/master/postfix/README_FILES/VIRTUAL_README).
Назначение: переадресация почты на удаленные адреса, в которых ваша система указана в качестве основного или резервного MX-хоста. Для обсуждения основных деталей конфигурации см. документ BASIC_CONFIGURATION_README. Обсуждение различий между каноническими доменами, размещенными доменами и другими доменами см. в файле VIRTUAL_README.
Доменные имена перечисляются с помощью параметра relay_domains.
@ -230,7 +90,7 @@ AGENTS = service names ∈ /etc/postfix/master.cf
### 5. default domain class (адреса по умолчанию)
Назначение: пересылка почты в Интернет от имени авторизованных клиентов. Для обсуждения основных деталей конфигурации см. файл [BASIC_CONFIGURATION_README](https://github.com/vdukhovni/postfix/blob/master/postfix/README_FILES/BASIC_CONFIGURATION_README). О различиях между каноническими доменами, размещенными доменами и другими доменами см. файл [VIRTUAL_README](https://github.com/vdukhovni/postfix/blob/master/postfix/README_FILES/VIRTUAL_README).
Назначение: пересылка почты в Интернет от имени авторизованных клиентов. Для обсуждения основных деталей конфигурации см. файл BASIC_CONFIGURATION_README. О различиях между каноническими доменами, размещенными доменами и другими доменами см. файл VIRTUAL_README.
У этого класса нет таблицы доменов назначения.
@ -246,13 +106,13 @@ AGENTS = service names ∈ /etc/postfix/master.cf
## Типы доменов
Большинство систем Postfix являются конечным пунктом назначения только для нескольких доменных имен. К ним относятся имена хостов и [IP-адреса] машин, на которых работает Postfix, а иногда и родительский домен имени хоста. Эти домены называются каноническими ( `canonical` ) доменами. Обычно они реализуются с помощью класса адресов локального домена Postfix, как определено в файле [ADDRESS_CLASS_README](https://github.com/vdukhovni/postfix/blob/master/postfix/README_FILES/ADDRESS_CLASS_README).
Большинство систем Postfix являются конечным пунктом назначения только для нескольких доменных имен. К ним относятся имена хостов и [IP-адреса] машин, на которых работает Postfix, а иногда и родительский домен имени хоста. Эти домены называются каноническими ( `canonical` ) доменами. Обычно они реализуются с помощью класса адресов локального домена Postfix, как определено в файле ADDRESS_CLASS_README.
Помимо канонических доменов, Postfix может быть настроен на то, чтобы быть конечным адресатом для любого количества дополнительных доменов. Такие домены называются размещенными ( `hosted` ), поскольку они не связаны непосредственно с именем самой машины. Размещенные домены обычно реализуются с помощью класса виртуального псевдонима домена и/или виртуального домена почтовых ящиков.
Но подождите! Это еще не все. Postfix может быть настроен как резервный MX-хост для других доменов. В этом случае Postfix не будет являться резервным хостом MX для этих доменов. Он просто ставит почту в очередь, когда основной MX-хост работает, и пересылает почту, когда основной MX-хост не работает. Эта функция реализуется с помощью класса адресов доменов-ретрансляторов, как определено в файле [ADDRESS_CLASS_README](https://github.com/vdukhovni/postfix/blob/master/postfix/README_FILES/ADDRESS_CLASS_README).
Но подождите! Это еще не все. Postfix может быть настроен как резервный MX-хост для других доменов. В этом случае Postfix не будет являться резервным хостом MX для этих доменов. Он просто ставит почту в очередь, когда основной MX-хост работает, и пересылает почту, когда основной MX-хост не работает. Эта функция реализуется с помощью класса адресов доменов-ретрансляторов, как определено в файле ADDRESS_CLASS_README.
Наконец, Postfix может быть настроен как транзитный хост для отправки почты через Интернет. Очевидно, что Postfix не является конечным адресатом такой почты. Эта функция доступна только для авторизованных клиентов и/или пользователей и реализуется классом доменных адресов по умолчанию, как определено в параметре [ADDRESS_CLASS_README](https://github.com/vdukhovni/postfix/blob/master/postfix/README_FILES/ADDRESS_CLASS_README).
Наконец, Postfix может быть настроен как транзитный хост для отправки почты через Интернет. Очевидно, что Postfix не является конечным адресатом такой почты. Эта функция доступна только для авторизованных клиентов и/или пользователей и реализуется классом доменных адресов по умолчанию, как определено в параметре ADDRESS_CLASS_README.
**Таблица. 1 Сводная таблица классов почтовых адресов**
Первые параметры, представляющие интерес, определяют идентификацию и роль машины в сети. Заполним таблицу:
@ -272,15 +131,14 @@ AGENTS = service names ∈ /etc/postfix/master.cf
|Вопрос|Ответ|Параметр|
|-|-|-|
| Куда указывает MX запись? | mail.stud12.myoffice.ru | MX запись DNS |
| Какое доменное имя у машины с Postfix? | mail.stud12.myoffice.ru | `myhostname` |
| Какой домен является родительским? | stud12.myoffice.ru | `mydomain` |
| Письма из которой сети будут приниматься без авторизации? | 127.0.0.0/8 | `mynetworks` |
| Какое доменное имя использовать в исходящей почте? | stud12.myoffice.ru | `myorigin` = `myhostname` или `mydomain` |
| Для каких доменов принимать почту и доставлять локально? | stud12.myoffice.ru | `mydestination = $myhostname localhost.$mydomain localhost` |
| С каких клиентов передавать почту? | | |
| В какие пункты назначения передавать почту? | | |
| Какой метод доставки использовать: прямой или непрямой? | прямой | relay or proxy not used? |
| Какое доменное имя у машины с Postfix | stud12.myoffice.ru | myhostname |
| Какой домен является родительским | myoffice.ru | mydomain |
| Какие адреса принадлежат доверенной сети от клиентов в которой будут пересылаться письма другим почтовым серверам | 127.0.0.0/8 | mynetworks |
| Какое доменное имя использовать в исходящей почте | stud12.myoffice.ru или myoffice.ru | myorigin = myhostname или mydomain |
| Для каких доменов принимать почту и доставлять локально | stud12.myoffice.ru или myoffice.ru | mydestination = $myhostname localhost.$mydomain localhost |
| С каких клиентов передавать почту | | |
| В какие пункты назначения передавать почту | | |
| Какой метод доставки: прямой или непрямой | прямой | relay or proxy not used? |
Параметр `mydomain` задает родительский домен `myhostname`. По умолчанию он получается из `myhostname` путем удаления первой части (за исключением случаев, когда в результате не будет получен домен верхнего уровня ). И наоборот, если вы укажете `mydomain` в файле `main.cf`, то Postfix будет использовать его значение для генерации полностью определенного значения по умолчанию для параметра `myhostname`.
@ -308,35 +166,35 @@ AGENTS = service names ∈ /etc/postfix/master.cf
Самый простой способ размещения дополнительного домена - это добавить имя домена к доменам, перечисленным в конфигурационном параметре Postfix `mydestination`, и добавить имена пользователей в файл паролей UNIX `/etc/passwd`. При таком подходе не делается различий между каноническими ( `canonical` ) и размещенными ( `hosted` ) доменами. Каждое имя пользователя может получать почту в каждом домене.
* Полное отсутствие разделения: почта для info@stud12.myoffice.ru доставляется на ту же системную учетную запись UNIX, что и почта для info@stud12.myoffice.space.
* Полное отсутствие разделения: почта для info@stud12.myoffice.ru доставляется на ту же системную учетную запись UNIX, что и почта для info@myoffice.space.
* При наличии пользователей в файле паролей UNIX администрирование большого числа пользователей становится неудобным.
### Виртуальные псевдонимы
При использовании подхода, описанного в данном разделе, каждый размещаемый домен может иметь свой собственный адрес электронной почты `info@stud12.myoffice.ru` и `info@stud12.myoffice.space`. Однако при этом по-прежнему используются системные учетные записи UNIX для доставки локальных почтовых ящиков.
При использовании подхода, описанного в данном разделе, каждый размещаемый домен может иметь свой собственный адрес электронной почты `info@stud12.myoffice.ru` и `info@myoffice.space`. Однако при этом по-прежнему используются системные учетные записи UNIX для доставки локальных почтовых ящиков.
При использовании виртуальных доменов-псевдонимов каждый размещаемый адрес привязывается к локальной учетной записи UNIX-системы или к удаленному адресу. Они не обязательно должны ссылаться на системные учетные записи UNIX на вашей машине. В приведенном ниже примере показано, как использовать этот механизм для домена stud12.myoffice.space.
При использовании виртуальных доменов-псевдонимов каждый размещаемый адрес привязывается к локальной учетной записи UNIX-системы или к удаленному адресу. Они не обязательно должны ссылаться на системные учетные записи UNIX на вашей машине. В приведенном ниже примере показано, как использовать этот механизм для домена myoffice.space.
9 # Uncomment entry below to implement a catch-all address
10 # @stud12.myoffice.space jim
10 # @myoffice.space jim
11 ...virtual aliases for more domains...
```
Виртуальные псевдонимы решает одну проблему: он позволяет каждому домену иметь свой собственный почтовый адрес. Например это даёт возможность работать с ящиками `info@stud12.myoffice.ru` и `info@stud12.myoffice.space` разным пользователям.
Виртуальные псевдонимы решает одну проблему: он позволяет каждому домену иметь свой собственный почтовый адрес. Например это даёт возможность работать с ящиками `info@stud12.myoffice.ru` и `info@myoffice.space` разным пользователям.
Но при этом остается один недостаток: каждый виртуальный адрес привязывается к системной учетной записи UNIX. При добавлении большего количества виртуальных адресов увеличивается и количество системных учетных записей UNIX. В следующем разделе эта проблема будет устранена.
Для повышения прав доступа до суперпользователя на управляемых машинах используется ключ `--become` или сокращенный вариант `-b`. Если вы не настроили sudo без запроса пароля на управляемых машинах, вы можете добавить ключ `--ask-become-pass` или сокращенный вариант `-K` для запроса пароля. По умолчанию `--become-user` равен `root`.
Для повышения прав доступа до суперпользователя на управляемых машинах используется ключ `--become` или сокращенный вариант `-b`. Если вы не настроили sudo без запроса пароля на управялемых машинах, вы можете добавить ключ `--ask-become-pass` или сокращенный вариант `-K` для запроса пароля. По умолчанию `--become-user` равен `root`.
```
$ ansible cluster -m apt -a "name=htop state=present" --become --ask-become-pass
Выполните задания по настройке Proxmox на виртуальных машинах и предоставьте доступ к веб-интерфейсу по адресу `https://proxmox.studX.myoffice.ru/`. Заведите тестового пользователя, который обладает правами на:
- запуск/выключение созданной для него виртуальной машины,
- может создавать диски,
- может изменять конфигурацию оборудования виртуальной машины,
- может сохранять бекапы и делать снепшоты системы.
Web интерфейс созданного в задании Proxmox доступен по адресу https://proxmox.studX.myoffice.ru/.
## 2. nginx_ha
Cайты доступены по адресу https://ha1.studX.myoffice.ru/ и https://ha2.studX.myoffice.ru/. При остановке активной машины сайт должен обслуживаться резервным сервером.
## 3. docker
Выполните контейнеризацию приложения `todo_app` и предоставьте доступ к веб-интерфейсу по адресу https://docker.studX.myoffice.ru/.
## 1. Подготовка экзаменационной машины к удалённой конфигурации
# 1.
Создайте виртуальную машину `studX-exam2` для настройки из `exam2-template`. Пароль от `root` и `stud` стандартные.
Создайте виртуальную машину для настройки из `debian-template`. Подключите к `vmbr15+X` и настройте ip адрес. К машине должна быть возможность подключиться по ssh с узла `studX`. Добавьте два жестких диска в конфигурацию оборудования размером 0.5 ГБ. Создайте снепшот.
Подключите её к `vmbr499`, настройте доступ в сеть интернет. Используйте ip адреса из колонки `exam2_X`.
# 2.
Настройте ssh подключение с узла `studX`. После настройки доступ по паролю к `studX-exam2` должен быть закрыт.
Настройте `sudo` доступ для пользователя `stud`.
Добавьте два жестких диска в конфигурацию оборудования размером 0.5 ГБ.
## 2. Конфигурирование экзаменационной машины по сети с помощью Ansible
Установите ansible на `studX`, если он ещё не установлен. Добавьте экзаменационную машину `studX-exam2` в инвентарь.
Напишите Ansible Playbook, который на созданной виртуальной машине `studX-exam2`:
Напишите Ansible Playbook, который на созданной виртуальной машине:
- устанавливает время таймаута меню загрузки равным 1 секунде,
- создаёт и монтирует на постоянной основе raid1 в `/var/lib/postgresql/`с помощью пакета `mdadm`,
- устанавливает в систему PostgreSQL данные которой будут храниться на raid1,
- устанавливает selinux и активирует его в режиме `permissive`,
- перезагружает машину.
- создаёт и монтирует на постоянной основе raid1 в `/var/lib/postgresql/`с помощью пакета `mdadm`,
- устанавливает в систему PostgreSQL данные которой будут храниться на raid1.
Playbook должен выполнять все пункты конфигурации машины для состояния зафиксированного снепшотом. Playbook должен выполняться от имени `stud`.
Playbook должен выполнять все пункты конфигурации машины для состояния зафиксированного снепшотом.
## 3. Проверка работоспособности установленного ПО
# 3.
Зайдите в сконфигурированную машину под пользователем `postgres`. Импортируйте данные в БД, запустив скрипт `weather.sql` из задания `05_sql_postgresql`.
@ -35,9 +23,9 @@ Playbook должен выполнять все пункты конфигура
### Оценка
За каждый пункт засчитывается балл:
За каждый пункт будет засчитывать балл.
1. Настроено время таймаута меню загрузки в 1 секунду.
2. Установлен и активирован selinux в режиме Permissive.
3. Создан и примонтирован mdadm raid1 в `/var/lib/postgresql/`.
4. Установлен PostgreSQL, данные хранятся в raid1, выполняется написанный вами sql запрос из секции задания 3.
5. Написан Ansible Playbook, который настраивает машину из состояния снепшота, как описано в секции задания 2.
5. Написан Ansible Playbook, который настраивает машину из состояния снепшота, как описано в секции ззадания 2.
Dmitry Ignatiev