Страницы

суббота, 12 мая 2018 г.

Fedora Server 28. OpenVPN FAILURE. Отказ запуска через systemd

При настройке туннелей на VPS сервере Fedora Server 28, я столкнулся с неявными особенностями конфигурации.

1. Конфигурационный файл /etc/openvpn/server/server.conf


Ошибка вида:
systemd[1]: Failed to start OpenVPN service for server ...

Подготовленный конфигурационный файл надо сохранять в папку /etc/openvpn/server, под именем server.conf.
Это обеспечивает управление запуском и остановкой сервера OpenVPN посредством команды systemctl.

# systemctl enable openvpn-server@server.service
# systemctl start openvpn-server@server.service
# systemctl status openvpn-server@server.service

Все остальные трудности - это в конкретной конфигурации.

Примечание: В Ubuntu 18.04 LTS server - другое место конфигурационного файла - /etc/openvpn/server.conf

2. Для открытия доступа к VPN надо настроить Firewall


Просмотр некоторых сведений о Firewall.

# firewall-cmd --list-services | grep openvpn
# firewall-cmd --get-default-zone

Добавить службу openvpn в зону по умолчанию. На сервере, зоной по умолчанию является "FedoraServer"

# firewall-cmd --add-service=openvpn


Добавить возможность принимать openvpn-подключения по протоколу tcp, на стандартном порту 1194.

# firewall-cmd --permanent --service=openvpn --add-port 1194/tcp




Добавить возможность NAT
 
# firewall-cmd --permanent --add-masquerade
 
# firewall-cmd --reload

※※※

четверг, 10 мая 2018 г.

Fedora Workstation 28 systemd control. Под капотом операционки


Fedora Workstation уже давно использует систему инициализации Systemd. Это удобно, позволяет иметь единую входную точку управления - systemctl. Единый формат конфигурационных файлов (units).


Утилиты: systemctl, networkctl, journalctl

Конфигурация: /etc/systemd
Конфигурация сети: /etc/systemd/network


$ systemctl status

red
    State: running
     Jobs: 0 queued
   Failed: 0 units
    Since: Thu 2018-05-10 20:43:56 MSK; 2h 59min left

Зелёное пятнышко слева свидетельствует что все запущенные модули (systemd units) работают и не выходят с кодом ошибки.

red
    State: running
     Jobs: 0 queued
   Failed: 3 units
    Since: Thu 2018-05-10 20:43:56 MSK; 2h 59min left

Красное пятнышко слева свидетельствует, что у некоторых запущенных модулей произошли ошибки и требуется их исправить, чтобы опять всё зазеленело.
Failed - сообщает о количестве сломанного.


У меня, возникло красное пятнышко и я полез смотреть, что не так. Оказалось, что проблема с сервисом журналирования , проблема с аппаратным генератором случайных чисел (в AMD-процессоре отсутствует) и ещё с одним.

Чтобы посмотреть состояние конкретного сломанного модуля используется команда systemctl status конкретный.service

$ systemctl status abrt-xorg.service

  abrt-xorg.service - ABRT Xorg log watcher
   Loaded: loaded (/usr/lib/systemd/system/abrt-xorg.service; enabled; vendor preset: enabled)
   Active: active (running) since Thu 2018-05-10 17:43:58 MSK; 25min ago
 Main PID: 903 (abrt-dump-journ)
    Tasks: 1 (limit: 4915)
   Memory: 5.5M
   CGroup: /system.slice/abrt-xorg.service
           └─903 /usr/bin/abrt-dump-journal-xorg -fxtD

мая 10 17:43:58 red systemd[1]: Started ABRT Xorg log watcher.


Сейчас он уже исправлен, светит зелёным глазом, а светил красным и в его последних строчках лога был код выхода (EXIT CODE).
Из которых я и узнал, что проблема кроется в журналах.

Проверку системных журналов, выполнил:



$ journalctl --verify

Было показано много красных строчек из которых я понял, что надо почистить накопившиеся журналы.

С журналами, накопившимися за приличное время, я поступил так - посмотрел занимаемый объём (--disk-usage) очистил и ограничил их размер по времени 30 днями.

$ journalctl --disk-usage
Archived and active journals take up 40.0M in the file system.

$ sudo journalctl --vacuum-time=30days

Vacuuming done, freed 0B of archived journals from /var/log/journal/393e16c51f6....

После этого, перезапустил первый сервис, который падал из-за ошибок в журналах.

$ sudo systemctl restart abrt-xorg.service
$ systemctl status abrt-xorg.service

  abrt-xorg.service - ABRT Xorg log watcher
   Loaded: loaded (/usr/lib/systemd/system/abrt-xorg.service; enabled; vendor preset: enabled)
   Active: active (running) since Thu 2018-05-10 17:43:58 MSK; 25min ago
 Main PID: 903 (abrt-dump-journ)
    Tasks: 1 (limit: 4915)
   Memory: 5.5M
   CGroup: /system.slice/abrt-xorg.service
           └─903 /usr/bin/abrt-dump-journal-xorg -fxtD

Приступил затем к следующим сервисам - я их отключил, т.к. из-за аппаратуры, они не пригодны.

$ sudo systemctl disable конкретный.service


※※※