linux_tasks/module1/04_systemd/solutions.md

Задание 1

1. Если у вас есть машина с графической оболочкой, в консоли перейдите в уровень запуска multi-user.target без перезагрузки, а затем обратно graphical.target.

# systemctl isolate multi-user.target
# systemctl isolate graphical.target

2. Если у вас есть машина с графической оболочкой, перейдите в уровень запуска multi-user.target с перезагрузкой, а затем переключитесь в графическую оболочку обратно.

# systemctl set-default multi-user.target
# reboot
# systemctl set-default graphical.target
# reboot

3. Выведите модуль, который активируется по-умолчанию.

# systemctl get-default 

4. Выведите возможные состояния модулей командой systemctl --state=help.

# systemctl --state=help

5. Найдите в 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).

6. Выведите список установленных модулей.

# systemctl list-unit-files

7. Деактивируйте сервис systemd-timesyncd.

# systemctl disable systemd-timesyncd

8. Перезагрузите сервис systemd-timesyncd.

# systemctl restart systemd-timesyncd

9. Выведите список модулей в памяти.

# systemctl disable systemd-timesyncd

10. Проверьте, что сервис systemd-timesyncd активирован.

# systemctl is-enabled systemd-timesyncd

11. Выведите список зависимых модулей для сервиса systemd-timesyncd.

# systemctl list-dependencies systemd-timesyncd

12. Выведите список сокетов в памяти.

# systemctl list-sockets

13. Выведите список таймеров в памяти.

# systemctl list-timers

14. Проверьте статус сервиса systemd-timesyncd.

# systemctl status systemd-timesyncd

15. Проверьте, что сервис systemd-timesyncd активен.

# systemctl is-active systemd-timesyncd

16. Выведите список свойств модуля.

# systemctl show systemd-timesyncd

17. Выведите уровень логирования для сервиса systemd-timesyncd.

# systemctl service-log-level systemd-timesyncd

18. Перезагрузите конфигурацию systemd менеджера: перезапустите генераторы (systemd.generator), все модули и перестройте дерево зависимостей.

# systemctl daemon-reload

19. Какие префиксы можно использовать при указании исполняемых файлов в файлах .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
# cat /root/.ssh/id_rsa.pub >> /root/.ssh/authorized_keys
# ssh localhost

2. Сконфигурируйте сервис для прокси сервиса

# systemctl edit socksproxy --full --force

содержимое /etc/systemd/system/socksproxy.service

[Unit]
Description=SocksProxy
After=network.target

[Service]
ExecStart=/usr/bin/ssh -N -D 0.0.0.0:80 localhost
Restart=always
RestartSec=5s

[Install]
WantedBy=multi-user.target

3. Активируйте сервис и запустите

# systemctl enable socksproxy
# systemctl start socksproxy

4. Проверьте, что socks сервер слушает порт 80

# netstat -tulpn 

5. Определите свой внешний IP адрес на сайте http://2ip.ru/, предварительно настроив в firefox плагине foxyproxy прокси сервер socks5 с адресом 193.32.63.170 + X к последнему октету, где X ваш идентификатор из studX.