|
|
|
|
|
|
|
|
|
|
|
# Задание 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://ifconfig.me/, предварительно настроив в firefox плагине foxyproxy прокси сервер socks5 с адресом 193.32.63.170 + X к последнему октету, где X ваш идентификатор из studX.
|
