единственное, что требуется от сервиса, уметь периодически слать sd_notify
Придется накостылять скрипт или просить разработчиков сервиса добавить такую функциональность. Ведь по другому никак не узнать именно о зависании. Вообще systemd не запрещает писать скрипты и не думаю, что для фанов sysvinit это проблема. Тем более, если такая функциональность уже была в sysvinit скрипте, то останется добавить только одну строчку с вызовом systemd-notify
Собрав по кусочкам информацию от вас. Я пришёл выводу..
В данном случае systemd пытался задействовать механизм "The Discoverable Partitions Specification", для автоматического определения разделов.
И вот почему:
The OS can discover and mount the necessary file systems with a non-existing or incomplete /etc/fstab file and without the root= kernel command line option.
Итог: /etc/fstab нет или не полный, опция ядра root= не указана, разделы по спецификации вы явно не настраивали. Но systemd как всегда крайний.
То, что вы описали, никак не имеет отношения к systemd.
Это больше похоже на особенности работы UEFI, возможно даже особенности отдельных производителей железа. Например у меня одна мат.плата MSI при некоторых похожих условиях, самостоятельно удаляет запись загрузчика Linux и
устанавливает дефолтным загрузчиком Windows.
Есть механизм и директива WatchdogSec=, единственное, что требуется от сервиса уметь периодически слать sd_notify со значением WATCHDOG=1. При этом sd_notify можно использовать из поставки либо прямо слать дейтаграммы на AF_UNIX сокет из переменной окружения $NOTIFY_SOCKET. Для скриптов есть консольная утилита systemd-notify.
SOCKS5 по определению не может быть безопасным, он не для этого проектировался.
А парольная авторизация системных пользователей, через незащищённый SOCKS5 это даже не дыра в безопасности, это парадная дверь к серверу.
Если вы знаете способ аутентифицироваться в прокси в приложении Telegram по ключу, очень прошу поделиться.
Это и не нужно, SOCKS не безопасен. Все ваши подключения можно легко отследить и как минимум заблокировать, когда начнут душить незащищённые прокси, только дело времени. Всё, что нужно это использовать локальный SSH как безопасный туннель во внешний мир.
Чем не угодила авторизация по ключу вместо пароля?
Возможно вам также потребуется поделиться доступом к прокси с кем то из недоверенного круга.
К счастью это не проблема. Но это не тема вашей статьи. Которая уж точно не покрывает безопасные кейсы, особенно если судить о рекомендацией использовать код из подозрительного источника запущенный от root'а.
Слишком мало информации для анализа. :)
Да, я именно так и написал
Придется накостылять скрипт или просить разработчиков сервиса добавить такую функциональность. Ведь по другому никак не узнать именно о зависании. Вообще systemd не запрещает писать скрипты и не думаю, что для фанов sysvinit это проблема. Тем более, если такая функциональность уже была в sysvinit скрипте, то останется добавить только одну строчку с вызовом
systemd-notifyКурица или яйцо?
Ответ здесь https://habr.com/post/431202/#comment_19454844
Собрав по кусочкам информацию от вас. Я пришёл выводу..
В данном случае systemd пытался задействовать механизм "The Discoverable Partitions Specification", для автоматического определения разделов.
И вот почему:
Итог: /etc/fstab нет или не полный, опция ядра root= не указана, разделы по спецификации вы явно не настраивали. Но systemd как всегда крайний.
То, что вы описали, никак не имеет отношения к systemd.
Это больше похоже на особенности работы UEFI, возможно даже особенности отдельных производителей железа. Например у меня одна мат.плата MSI при некоторых похожих условиях, самостоятельно удаляет запись загрузчика Linux и
устанавливает дефолтным загрузчиком Windows.
Есть механизм и директива WatchdogSec=, единственное, что требуется от сервиса уметь периодически слать sd_notify со значением WATCHDOG=1. При этом sd_notify можно использовать из поставки либо прямо слать дейтаграммы на AF_UNIX сокет из переменной окружения $NOTIFY_SOCKET. Для скриптов есть консольная утилита systemd-notify.
Уточните, пожалуйста, какие баги раздражают.
И был ли открыт по ним issue до вас или вами?
Для этой задачи вообще никакие пакеты из NPM не нужны и велосипеды тоже.
Все что нужно уже есть из коробки, даже с примерами.
https://nodejs.org/api/readline.html#readline_example_read_file_stream_line_by_line
Но для построчного чтения не нужен велосипед. Ведь уже есть Readline
sudo: yum: command not foundсомневаюсь, что справится
SOCKS5 по определению не может быть безопасным, он не для этого проектировался.
А парольная авторизация системных пользователей, через незащищённый SOCKS5 это даже не дыра в безопасности, это парадная дверь к серверу.
Это и не нужно, SOCKS не безопасен. Все ваши подключения можно легко отследить и как минимум заблокировать, когда начнут душить незащищённые прокси, только дело времени. Всё, что нужно это использовать локальный SSH как безопасный туннель во внешний мир.
Чем не угодила авторизация по ключу вместо пароля?
К счастью это не проблема. Но это не тема вашей статьи. Которая уж точно не покрывает безопасные кейсы, особенно если судить о рекомендацией использовать код из подозрительного источника запущенный от root'а.
Зачем еще какие либо SOCKS серверы, если SSH уже с SOCKSом на борту.
Есть же systemd-swap в репах. С настройками под все возможные варианты.
Имя доступ к клавиатуре, заполучить какой либо файл не слишком сложная задача.
Вы забыли, что keepass тоже нужно разблокировать паролем с той же самой клавиатуры.