Added solutions to 04_systemd task 1.

Corrected task 1.17.
Deleted one repeated subtask from task 1.

04_systemd/solutions.md

@@ -1,18 +1,200 @@
 
 # Задание 1
 
+0. Если у вас есть машина с графической оболочкой, в консоли перейдите в уровень запуска multi-user.target без перезагрузкпи, а затем обратно graphical.target.
+```
+# systemctl isolate multi-user.target
+# systemctl isolate graphical.target
+```
+
+1. Если у вас есть машина с графической оболочкой, перейдите в уровень запуска multi-user.target с перезагрузкой, а затем переключитесь в графическую оболочку обратно.
+```
+# systemctl set-default multi-user.target
+# reboot
+# systemctl set-default graphical.target
+# reboot
+```
+
+2. Выведите модуль, который активируется по-умолчанию.
+```
+# systemctl get-default 
+```
+
+3. Выведите возможные состояния модулей командой systemctl --state=help.
+```
+# systemctl --state=help
+```
+
+4. Найдите в man странице какие типы модулей есть в systemd.
+```
+# man systemctl 
+    The following unit types are available:
+
+        1. Service units, which start and control daemons and the processes they consist of. For details, see systemd.service(5).
+        2. Socket units, which encapsulate local IPC or network sockets in the system, useful for socket-based activation. For details about socket units, see systemd.socket(5), for details on socket-based activation and other forms of activation, see daemon(7).
+
+        3. Target units are useful to group units, or provide well-known synchronization points during boot-up, see systemd.target(5).
+        4. Device units expose kernel devices in systemd and may be used to implement device-based activation. For details, see
+           systemd.device(5).
+        5. Mount units control mount points in the file system, for details see systemd.mount(5).
+        6. Automount units provide automount capabilities, for on-demand mounting of file systems as well as parallelized boot-up. See
+           systemd.automount(5).
+        7. Timer units are useful for triggering activation of other units based on timers. You may find details in systemd.timer(5).
+        8. Swap units are very similar to mount units and encapsulate memory swap partitions or files of the operating system. They are
+           described in systemd.swap(5).
+        9. Path units may be used to activate other services when file system objects change or are modified. See systemd.path(5).
+       10. Slice units may be used to group units which manage system processes (such as service and scope units) in a hierarchical tree for resource management purposes. See systemd.slice(5).
+       11. Scope units are similar to service units, but manage foreign processes instead of starting them as well. See systemd.scope(5).
+```
+
+5. Выведите список установленных модулей.
+```
+# systemctl list-unit-files
+```
+
+6. Деактивируйте сервис timesyncd.
+```
+# systemctl disable systemd-timesyncd
+```
+
+7. Перезагрузите сервис timesyncd.
+```
+# systemctl restart systemd-timesyncd
+```
+
+8. Выведите список модулей в памяти.
+```
+# systemctl disable systemd-timesyncd
+```
+
+9. Проверьте, что сервис timesyncd активирован.
+```
+# systemctl is-enabled systemd-timesyncd
+```
+
+10. Выведите список зависимых модулей для сервиса timesyncd.
+```
+# systemctl list-dependencies systemd-timesyncd
+```
+
+11. Выведите список сокетов в памяти.
+```
+# systemctl list-sockets
+```
+
+12. Выведите список таймеров в памяти.
+```
+# systemctl list-timers
+```
+
+13. Проверьте статус сервиса timesyncd.
+```
+# systemctl status systemd-timesyncd
+```
+
+14. Проверьте, что сервис timesyncd активен.
+```
+# systemctl is-active systemd-timesyncd
+```
+
+15. Выведите список свойств модуля.
+```
+# systemctl show systemd-timesyncd
+```
+
+16. Выведите уровень логирования для сервиса timesyncd.
+```
+# systemctl service-log-level systemd-timesyncd
+```
+
+17. Перезагрузите конфигурацию systemd менеджера: перезапустите генераторы (systemd.generator), все модули и перестройте дерево зависимостей.
+```
+# systemctl daemon-reload
+```
+
+18. Какие префиксы можно использовать при указании исполняемых файлов в файлах .service.
+```
+# man systemd.service
+Table 1. Special executable prefixes
+           ┌───────┬──────────────────────────────────────────────────┐
+           │Prefix │ Effect                                           │
+           ├───────┼──────────────────────────────────────────────────┤
+           │"@"    │ If the executable path is prefixed with "@", the │
+           │       │ second specified token will be passed as         │
+           │       │ "argv[0]" to the executed process (instead of    │
+           │       │ the actual filename), followed by the further    │
+           │       │ arguments specified.                             │
+           ├───────┼──────────────────────────────────────────────────┤
+           │"-"    │ If the executable path is prefixed with "-", an  │
+           │       │ exit code of the command normally considered a   │
+           │       │ failure (i.e. non-zero exit status or abnormal   │
+           │       │ exit due to signal) is recorded, but has no      │
+           │       │ further effect and is considered equivalent to   │
+           │       │ success.                                         │
+           ├───────┼──────────────────────────────────────────────────┤
+           │":"    │ If the executable path is prefixed with ":",     │
+           │       │ environment variable substitution (as described  │
+           │       │ by the "Command Lines" section below) is not     │
+           │       │ applied.                                         │
+           ├───────┼──────────────────────────────────────────────────┤
+           │"+"    │ If the executable path is prefixed with "+" then │
+           │       │ the process is executed with full privileges. In │
+           │       │ this mode privilege restrictions configured with │
+           │       │ User=, Group=, CapabilityBoundingSet= or the     │
+           │       │ various file system namespacing options (such as │
+           │       │ PrivateDevices=, PrivateTmp=) are not applied to │
+           │       │ the invoked command line (but still affect any   │
+           │       │ other ExecStart=, ExecStop=, ... lines).         │
+           ├───────┼──────────────────────────────────────────────────┤
+           │"!"    │ Similar to the "+" character discussed above     │
+           │       │ this permits invoking command lines with         │
+           │       │ elevated privileges. However, unlike "+" the "!" │
+           │       │ character exclusively alters the effect of       │
+           │       │ User=, Group= and SupplementaryGroups=, i.e.     │
+           │       │ only the stanzas that affect user and group      │
+           │       │ credentials. Note that this setting may be       │
+           │       │ combined with DynamicUser=, in which case a      │
+           │       │ dynamic user/group pair is allocated before the  │
+           │       │ command is invoked, but credential changing is   │
+           │       │ left to the executed process itself.             │
+           ├───────┼──────────────────────────────────────────────────┤
+           │"!!"   │ This prefix is very similar to "!", however it   │
+           │       │ only has an effect on systems lacking support    │
+           │       │ for ambient process capabilities, i.e. without   │
+           │       │ support for AmbientCapabilities=. It's intended  │
+           │       │ to be used for unit files that take benefit of   │
+           │       │ ambient capabilities to run processes with       │
+           │       │ minimal privileges wherever possible while       │
+           │       │ remaining compatible with systems that lack      │
+           │       │ ambient capabilities support. Note that when     │
+           │       │ "!!" is used, and a system lacking ambient       │
+           │       │ capability support is detected any configured    │
+           │       │ SystemCallFilter= and CapabilityBoundingSet=     │
+           │       │ stanzas are implicitly modified, in order to     │
+           │       │ permit spawned processes to drop credentials and │
+           │       │ capabilities themselves, even if this is         │
+           │       │ configured to not be allowed. Moreover, if this  │
+           │       │ prefix is used and a system lacking ambient      │
+           │       │ capability support is detected                   │
+           │       │ AmbientCapabilities= will be skipped and not be  │
+           │       │ applied. On systems supporting ambient           │
+           │       │ capabilities, "!!" has no effect and is          │
+           │       │ redundant.                                       │
+           └───────┴──────────────────────────────────────────────────┘
+```
+
 # Задание 2
 
 1. Настройте беспарольный доступ по ssh на localhost. Подтвердите добавление хоста в known_hosts.
 ```
-ssh-keygen
+# ssh-keygen
-cat /root/.ssh/id_rsa.pub >> /root/.ssh/authorized_keys
+# cat /root/.ssh/id_rsa.pub >> /root/.ssh/authorized_keys
-ssh localhost
+# ssh localhost
 ```
 
 2. Сконфигурируйте сервис для прокси сервиса
 ```
-systemctl edit socksproxy --full --force
+# systemctl edit socksproxy --full --force
 ```
 
 содержимое /etc/systemd/system/socksproxy.service
@@ -32,13 +214,13 @@ WantedBy=multi-user.target
 
 3. Активируйте сервис и запустите
 ```
-systemctl enable socksproxy
+# systemctl enable socksproxy
-systemctl start socksproxy
+# systemctl start socksproxy
 ```
 
 4. Проверьте, что socks сервер слушает порт 80
 ```
-netstat -tulpn 
+# netstat -tulpn 
 ```
 
 5. Определите свой внешний IP адрес на сайте https://2ip.ru/, 

04_systemd/tasks.md

@@ -4,7 +4,7 @@
 
 0. Если у вас есть машина с графической оболочкой, в консоли перейдите в уровень запуска multi-user.target без перезагрузкпи, а затем обратно graphical.target.
 1. Если у вас есть машина с графической оболочкой, перейдите в уровень запуска multi-user.target с перезагрузкой, а затем переключитесь в графическую оболочку обратно.
-2. Выведите модуль, который активируется по-умолчанию systemctl get-default.
+2. Выведите модуль, который активируется по-умолчанию.
 3. Выведите возможные состояния модулей командой systemctl --state=help.
 4. Найдите в man странице какие типы модулей есть в systemd.
 5. Выведите список установленных модулей.
@@ -19,9 +19,8 @@
 14. Проверьте, что сервис timesyncd активен.
 15. Выведите список свойств модуля.
 16. Выведите уровень логирования для сервиса timesyncd.
-17. Проверьте, что timesyncd не активирован.
+17. Перезагрузите конфигурацию systemd менеджера: перезапустите генераторы (systemd.generator), все модули и перестройте дерево зависимостей.
-18. Перезагрузите systemd командой systemctl daemon-reload.
+18. Какие префиксы можно использовать при указании исполняемых файлов в файлах .service.
-19. Какие префиксы можно использовать при указании исполняемых файлов в файлах .service.
 
 
 ### Задание 2. Конфигурация сервиса