main
protsenkovi 9 months ago
parent 747b35d50d
commit 8a918c058c

@ -0,0 +1,34 @@
Задания
https://git.ai.ssau.ru/myoffice/linux_tasks/
|Фамилия |Логин |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|
|---------------|------|----------------------|----------------|-----------------------------------------------------------------------------------------------------------------|------------------------|----------------|--------------|---------------------|---------------------|---------------------|------------------|
| |stud1 |10.160.179.31 |10.160.179.11 |193.32.63.171 |stud1.myoffice.ru |10.160.179.121 |10.160.179.61 |10.160.179.141 |10.160.179.161 |10.160.179.162 |10.160.179.201 |
| |stud2 |10.160.179.32 |10.160.179.12 |193.32.63.172 |stud2.myoffice.ru |10.160.179.122 |10.160.179.62 |10.160.179.142 |10.160.179.163 |10.160.179.164 |10.160.179.202 |
| |stud3 |10.160.179.33 |10.160.179.13 |193.32.63.173 |stud3.myoffice.ru |10.160.179.123 |10.160.179.63 |10.160.179.143 |10.160.179.165 |10.160.179.166 |10.160.179.203 |
| |stud4 |10.160.179.34 |10.160.179.14 |193.32.63.174 |stud4.myoffice.ru |10.160.179.124 |10.160.179.64 |10.160.179.144 |10.160.179.167 |10.160.179.168 |10.160.179.204 |
| |stud5 |10.160.179.35 |10.160.179.15 |193.32.63.175 |stud5.myoffice.ru |10.160.179.125 |10.160.179.65 |10.160.179.145 |10.160.179.169 |10.160.179.170 |10.160.179.205 |
| |stud6 |10.160.179.36 |10.160.179.16 |193.32.63.176 |stud6.myoffice.ru |10.160.179.126 |10.160.179.66 |10.160.179.146 |10.160.179.171 |10.160.179.172 |10.160.179.206 |
| |stud7 |10.160.179.37 |10.160.179.17 |193.32.63.177 |stud7.myoffice.ru |10.160.179.127 |10.160.179.67 |10.160.179.147 |10.160.179.173 |10.160.179.174 |10.160.179.207 |
| |stud8 |10.160.179.38 |10.160.179.18 |193.32.63.178 |stud8.myoffice.ru |10.160.179.128 |10.160.179.68 |10.160.179.148 |10.160.179.175 |10.160.179.176 |10.160.179.208 |
| |stud9 |10.160.179.39 |10.160.179.19 |193.32.63.179 |stud9.myoffice.ru |10.160.179.129 |10.160.179.69 |10.160.179.149 |10.160.179.177 |10.160.179.178 |10.160.179.209 |
| |stud10|10.160.179.40 |10.160.179.20 |193.32.63.180 |stud10.myoffice.ru |10.160.179.130 |10.160.179.70 |10.160.179.150 |10.160.179.179 |10.160.179.180 |10.160.179.210 |
| |stud11|10.160.179.41 |10.160.179.21 |193.32.63.181 |stud11.myoffice.ru |10.160.179.131 |10.160.179.71 |10.160.179.151 |10.160.179.181 |10.160.179.182 |10.160.179.211 |
| |stud12|10.160.179.42 |10.160.179.22 |193.32.63.182 |stud12.myoffice.ru |10.160.179.132 |10.160.179.72 |10.160.179.152 |10.160.179.183 |10.160.179.184 |10.160.179.212 |
| |stud13|10.160.179.43 |10.160.179.23 |193.32.63.183 |stud13.myoffice.ru |10.160.179.133 |10.160.179.73 |10.160.179.153 |10.160.179.185 |10.160.179.186 |10.160.179.213 |
| |stud14|10.160.179.44 |10.160.179.24 |193.32.63.184 |stud14.myoffice.ru |10.160.179.134 |10.160.179.74 |10.160.179.154 |10.160.179.187 |10.160.179.188 |10.160.179.214 |
|Тестовая машина|stud15|10.160.179.45 |10.160.179.25 |193.32.63.185 |stud15.myoffice.ru |10.160.179.135 |10.160.179.75 |10.160.179.155 |10.160.179.189 |10.160.179.190 |10.160.179.215 |
Proxmox координаты для подключения к виртуальным машинам
URL: https://193.32.63.170:8006
Realm: Proxmox ...
Логин: studX
Пароль: ****************
Виртуальные машины stud1 - stud12 по ssh
Host: 193.32.63.170
Port: 22
Логин: stud
Пароль: ****************
Команда ssh 193.32.63.17X -p 22 -l stud

File diff suppressed because it is too large Load Diff

@ -134,3 +134,6 @@ done
## 20
(*) Напишите команду или сценарий для рекурсивного поиска самого последнего измененного файла в каталоге. В общем, можете ли вы перечислить все файлы по давности?
TODO install command

@ -552,3 +552,4 @@ DHCP состоит из двух компонентов: протокола д
- Michael Lucas. Networking for System Administrator
- https://www.youtube.com/playlist?list=PLowKtXNTBypH19whXTVoG3oKSuOcw_XeW
- https://www.brendangregg.com/linuxperf.html
- https://habr.com/ru/articles/307252/

@ -95,3 +95,5 @@ verify(данные, подпись: массив<байт>, открытый к
Релевантные ссылки:
- https://missing.csail.mit.edu/2020/security/
- https://letsencrypt.org/how-it-works/
TODO https://www.golinuxcloud.com/generate-ssh-key-linux/

@ -3,10 +3,10 @@
Для проверки расписания вы можете использовать сайт https://crontab.guru/, https://cronheatmap.com и аналоги.
### 0.
Проверьте наличие команд cron и at в системе. Установите их в случае отсутствия.
Проверьте наличие команд `cron` и `at` в системе. Установите их в случае отсутствия.
### 1.
Выведите документацию crontab и cron.
Выведите документацию `crontab` и `cron`.
### 2.
Создайте cron расписание для выполнения скрипта или к:
@ -38,16 +38,16 @@
Создайте задание в котором отчёты cron будут отправляться вам на внешний почтовый ящик.
### 4.
Установите пользовательский сrontab.
Установите пользовательский `сrontab`.
### 5.
Настройте выполнение исполняемого файла script.sh из `/usr/sbin/` каждую среду, модифицировав `PATH` в cron задании.
Настройте выполнение исполняемого файла `script.sh` из `/usr/sbin/` каждую среду, модифицировав `PATH` в cron задании.
### 6.
Пользуясь полномочиями суперпользователя, запретите пользователю mike выполнять команду at.
Пользуясь полномочиями суперпользователя, запретите пользователю `mike` выполнять команду `at`.
### 7.
Запланируйте командой at:
Запланируйте командой `at`:
1. выполнение скрипта сегодня в 9 часов,
2. перезагрузку через 2 часа,
3. выполнение команды через 100 лет.
@ -67,6 +67,10 @@
- /etc/at.deny
Релевантные команды:
- cron
- at
- crontab
- `cron`
- `at`
- `crontab`
TODO добавить упражнения для systemd .timer
добавить timedate/ntp? (установка времени вручную и по ntp, cron, at, systemd timer)

@ -9,9 +9,13 @@
## Теория
Формально мы можем рассматривать процесс устранения неполадок как применение гипотетико-дедуктивного метода: учитывая набор наблюдений за системой и теоретическую основу для понимания поведения системы, мы итеративно выдвигаем гипотезы о потенциальных причинах сбоя и пытаемся проверить эти гипотезы.
В идеализированной модели, мы бы начали с отчета о проблеме, сообщающего нам, что с системой что-то не так. Затем мы можем просмотреть данные телеметрии и журналы системы, чтобы понять ее текущее состояние. Эта информация в сочетании с нашими знаниями о том, как устроена система, как она должна работать, и о режимах ее сбоев, позволяет нам выявить некоторые возможные причины.
Затем мы можем проверить наши гипотезы одним из двух способов. Мы можем сравнить наблюдаемое состояние системы с нашими теориями, чтобы найти подтверждающие или опровергающие доказательства. Или, в некоторых случаях, мы можем активно «лечить» систему, то есть изменять систему контролируемым образом, и наблюдать за результатами. Этот второй подход уточняет наше понимание состояния системы и возможных причин сообщаемых проблем. Используя любую из этих стратегий, мы неоднократно тестируем до тех пор, пока не будет определена основная причина, после чего мы можем предпринять корректирующие действия, чтобы предотвратить повторение, и написать postmortem. Конечно, для устранения непосредственной причины (причин) не всегда нужно ждать первопричины или postmortem заключения.
Пример postmortem https://sre.google/sre-book/example-postmortem/.
## Практика
Практический совет - в случае проблемы ищите руководства по устранению неполадок (имя технологии troubleshooting guide в google) для вашего программного обеспечения.
@ -39,28 +43,31 @@
#### Поиск синтаксических ошибок или предупреждений в конфигурации
С помощью простой команды вы можете проверить состояние файла конфигурации 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
```
@ -70,14 +77,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`.
```
$ sudo lsof -i :80 -s TCP:LISTEN
nginx 1305 nginx 6u IPv4 1613873 0t0 TCP *:http (LISTEN)
@ -88,7 +95,7 @@ nginx 1306 nginx 7u IPv6 1613874 0t0 TCP *:http (LISTEN)
Проверить, обрабатывает ли Nginx запросы
Если Nginx действительно прослушивает соответствующие порты, следующим шагом будет проверка обработки запросов, что можно сделать с помощью инструмента curl с использованием IP-адреса, URL-адреса или локального хоста, если ваша установка прослушивает локальный хост:
Если Nginx действительно прослушивает соответствующие порты, следующим шагом будет проверка обработки запросов, что можно сделать с помощью инструмента `curl` с использованием IP-адреса, URL-адреса или локального хоста, если ваша установка прослушивает локальный хост:
```
$ curl -i http://127.0.0.1/nginx_status
HTTP/1.1 200 OK
@ -106,7 +113,10 @@ Reading: 0 Writing: 1 Waiting: 0
#### Проверьте журналы
Проверьте последние журналы службы Nginx. $ sudo tail -f /var/log/nginx/access.log /var/log/nginx/error.log
Проверьте последние журналы службы Nginx.
```
$ sudo tail -f /var/log/nginx/access.log /var/log/nginx/error.log
```
#### Проверить разрешения
@ -136,7 +146,7 @@ $ sudo systemctl restart nginx
#### Включите режим отладки
В конфигурационном файле (обычно /etc/nginx/nginx.conf) измените уровень логирования директивой error_log:
В конфигурационном файле (обычно `/etc/nginx/nginx.conf`) измените уровень логирования директивой `error_log`:
```
server {
# stuff
@ -157,7 +167,7 @@ rewrite_log on;
#### Проверьте разрешение имён DNS
Правила в /etc/hosts имеют приоритет над разрешениями DNS. Вы можете проверить записи DNS с помощью:
Правила в `/etc/hosts` имеют приоритет над разрешениями DNS. Вы можете проверить записи DNS с помощью:
```
$ host -t Веб-сайт.com
```

@ -15,4 +15,4 @@ ssh-copy-id stud@192.168.0.106
После логина стрелки не работают и выводят странные символы. Исправьте проблему.
#### studX-troublesome-8
Залогиньтесь сначала в `stud` потом в `root`. Посмотрите логи командой `journalctl -o short-iso`. В чём заключается проблема настройки машины? Исправьте её.
Залогиньтесь сначала в `stud` потом в `root`. Попробуйте обновить `apt` базу данных командой `apt update`. Посмотрите логи командой `journalctl -o short-iso`. В чём заключается проблема настройки машины? Исправьте её.

@ -80,6 +80,7 @@ apt remove ifupdown
Создайте `N` виртуальных машин `studX-net1` и `N` виртуальных машин `studX-net2` для `vmbrX`. Удалите пакет `ifupdown`.
## 4. Подготовка виртуальной машины к занятиям `12`.
# TODO АВТОМАТИЗИРОВАТЬ
Данные виртуальные
@ -135,8 +136,8 @@ networkctl reload
# task 5
# ping gateway
ping 192.168.0.1 -c 1 2> /dev/null 1> /dev/null
gateway_mac=$(arp -n | grep 192.168.0.1 | awk '{ print $3 }')
ip link set address "$(gateway_mac)" dev ens18
gateway_mac=$(arp -n | egrep '^192.168.0.1\s' | awk '{ print $3 }')
ip link set address "${gateway_mac}" dev ens18
```
Активируйте следующий сервис:

@ -124,3 +124,6 @@ PXE — это протокол, используемый для загрузк
1. Evi Nemeth, Garth Snyder, Trent R. Hein, Ben Whaley, Dan Macking. Unix Handbook. 2 Chapter. (117 page ebook).
2. Raphael Hertzog, Roland Mas. The Debian Administrators's Handbook. 9 Chapter (233 page ebook).
3. Michael W. Lucas. Absolute FreeBSD. 4 chapter (103 page ebook)
TODO stress distinction of primary bootloader and secondary bootloader (comments for tasks, or separate tasks)

@ -0,0 +1,32 @@
# Репликация и бэкапы
Репликация это процесс в пространстве, 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 дисков |
https://ru.wikipedia.org/wiki/RAID

@ -14,21 +14,7 @@
### Таблица 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 дисков |
https://ru.wikipedia.org/wiki/RAID
## 1. Программный RAID `mdadm`

@ -308,35 +308,35 @@ AGENTS = service names ∈ /etc/postfix/master.cf
Самый простой способ размещения дополнительного домена - это добавить имя домена к доменам, перечисленным в конфигурационном параметре Postfix `mydestination`, и добавить имена пользователей в файл паролей UNIX `/etc/passwd`. При таком подходе не делается различий между каноническими ( `canonical` ) и размещенными ( `hosted` ) доменами. Каждое имя пользователя может получать почту в каждом домене.
```
myhostname = stud12.myoffice.ru
mydomain = myoffice.ru
mydestination = myoffice.space $myhostname localhost.$mydomain
mydomain = stud12.myoffice.ru
mydestination = stud12.myoffice.space $myhostname localhost.$mydomain
```
Ограничениями данного подхода являются:
* Полное отсутствие разделения: почта для info@stud12.myoffice.ru доставляется на ту же системную учетную запись UNIX, что и почта для info@myoffice.space.
* Полное отсутствие разделения: почта для info@stud12.myoffice.ru доставляется на ту же системную учетную запись UNIX, что и почта для info@stud12.myoffice.space.
* При наличии пользователей в файле паролей UNIX администрирование большого числа пользователей становится неудобным.
### Виртуальные псевдонимы
При использовании подхода, описанного в данном разделе, каждый размещаемый домен может иметь свой собственный адрес электронной почты `info@stud12.myoffice.ru` и `info@myoffice.space`. Однако при этом по-прежнему используются системные учетные записи UNIX для доставки локальных почтовых ящиков.
При использовании подхода, описанного в данном разделе, каждый размещаемый домен может иметь свой собственный адрес электронной почты `info@stud12.myoffice.ru` и `info@stud12.myoffice.space`. Однако при этом по-прежнему используются системные учетные записи UNIX для доставки локальных почтовых ящиков.
При использовании виртуальных доменов-псевдонимов каждый размещаемый адрес привязывается к локальной учетной записи UNIX-системы или к удаленному адресу. Они не обязательно должны ссылаться на системные учетные записи UNIX на вашей машине. В приведенном ниже примере показано, как использовать этот механизм для домена myoffice.space.
При использовании виртуальных доменов-псевдонимов каждый размещаемый адрес привязывается к локальной учетной записи UNIX-системы или к удаленному адресу. Они не обязательно должны ссылаться на системные учетные записи UNIX на вашей машине. В приведенном ниже примере показано, как использовать этот механизм для домена stud12.myoffice.space.
```
1 /etc/postfix/main.cf:
2 virtual_alias_domains = myoffice.space ...other hosted domains...
2 virtual_alias_domains = stud12.myoffice.space ...other hosted domains...
3 virtual_alias_maps = hash:/etc/postfix/virtual
```
```
5 /etc/postfix/virtual:
6 postmaster@myoffice.space postmaster
7 info@myoffice.space joe
8 sales@myoffice.space jane
6 postmaster@stud12.myoffice.space postmaster
7 info@stud12.myoffice.space joe
8 sales@stud12.myoffice.space jane
9 # Uncomment entry below to implement a catch-all address
10 # @myoffice.space jim
10 # @stud12.myoffice.space jim
11 ...virtual aliases for more domains...
```
Виртуальные псевдонимы решает одну проблему: он позволяет каждому домену иметь свой собственный почтовый адрес. Например это даёт возможность работать с ящиками `info@stud12.myoffice.ru` и `info@myoffice.space` разным пользователям.
Виртуальные псевдонимы решает одну проблему: он позволяет каждому домену иметь свой собственный почтовый адрес. Например это даёт возможность работать с ящиками `info@stud12.myoffice.ru` и `info@stud12.myoffice.space` разным пользователям.
Но при этом остается один недостаток: каждый виртуальный адрес привязывается к системной учетной записи UNIX. При добавлении большего количества виртуальных адресов увеличивается и количество системных учетных записей UNIX. В следующем разделе эта проблема будет устранена.

@ -179,7 +179,7 @@ $ ansible cluster -m apt -a "name=htop state=present"
#### 1.2.6 Эскалация прав доступа
Для повышения прав доступа до суперпользователя на управляемых машинах используется ключ `--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
```

Loading…
Cancel
Save