Реклама
Комментарии 27
Класс, работает. Я даже немного понял, что тут происходит
Ничего только не понял про безопасность — зачем делать копию скрипта htop_secure и какой смысл в прописывании юзера? И должен ли это быть один и тот же юзер в обоих сервисах?
tty2 теперь не требует логина, т.е. там сразу висит htop. Это очень удобно, но при желании может быть использовано, чтобы основательно подгадить хозяину машины
<...> при желании может быть использовано, чтобы основательно подгадить хозяину машины

Да, в том-то и дело. Для этого мы создаём ещё один сервис и ещё один скрипт, теперь — htop_secure@.service и run_wait_su. Их мы конфигурируем так, чтобы htop запускался с правами конкретного пользователя (в сервисе в секции Service) и требовал пароль (использование в скрипте exec su -c "$@" вместо exec "$@").


Вообще этот момент был написан на скорую руку, и, действительно, он не сопровождался никакими пояснениями действий. Теперь слегка дополнил статью, так что спасибо =)

А после переключения с этой консоли как её погасить? Ну чтобы при повторном переключении на неё заново спросило пароль?
И должен ли это быть один и тот же юзер в обоих сервисах?

Нет, мы создаём ещё один независимый сервис и ещё один независимый скрипт. htop@ никак не связан с htop_secure@, а run_wait никак не связан с run_wait_su. Вторая связка запускает софтину с указанными правами и только после корректного ввода рутового пароля, а первая просто запускает её же, но от рута и без лишних действий.

Вообще сам принцип запуска процессов подобным образом очень интересен, особенно в плане логина. А вот конкретно htop держать всегда запущенным, думаю, смысла нет. Переключиться на свободный tty и вбить команду в 4 символа — дело нескольких секунд.
Есть сценарий, при котором какая-то рыжая морда процесс внезапно отожрал тонну памяти, начался лютый swap out всего что только есть, но OOM killer еще не прибил негодяя. В таком случае, вы тупо не сможете снять задачу из нового терминала/процесса, ибо вы его не дождетесь. Переключиться же на физический терминал с уже запущенным htop будет быстрее.

Есть конечно еще magic sysrq key, но он не всегда включен и часто oom killer выбирает не тот процесс (у меня по крайней мере).
Частенько сталкивался с такими «негодяями», особенно при нехватке памяти (запущена виртуалка, всё впритык, и вдруг что-то тяжёлое запустил(ось)). Даже при полном зависоне интерфейса на терминал переключается без проблем. Ну, с лагами конечно, но так, чтоб критично, ни разу не было.

Каждый, кто работает за машиной с линуксом на борту, хоть раз использовал её: будь то поиск процесса (и его последующее убийство)

Не стоит говорить за всех. Это даже не считая того, что использование для этого error-prone даже при подходе с выделением процесса (пробелом) и отправкой сигнала после. Если процесс умер, можно послать kill не тому. Подходы с ps+kill и pgrep/pkill куда более безопасны.

А в чем проблема для подобной цели просто использовать screen без лишних плясок с бубном?
Преимущество такого подхода заключается в чистом окружении и независимости от иксов/терминала.

Ну или от терминала-мультиплексора в случае с screen. Вообще каждый решает для себя насколько этот вариант лучше (или наоборот), цель статьи — раскрыть метод.

`$ "$EDITOR" htop@.service` ⇐ sudo бы не помешал, а то намучаетесь сохранять изменения.

Зачем уточнять о повышении прав для работы с директорией, с которой никак иначе поработать не получится? =)

Так можно далеко зайти: «зачем писать `$EDITOR`, если и так понятно, что `cowsay` здесь не подходит» и «зачем писать `htop@.service`, если и так ясно, что за файл мы собираемся редактировать.

Доллар впереди намекает на то, что текущий шелл — не рутовый. Хорошим тоном в howto считается указывать команды, которые можно скопипастить и выполнить, но вы, конечно, можете продолжать писать половину и считать, что умные разберутся.

На самом деле всё нормально. Традиционно принято писать # "$EDITOR" htop@.service, но я не стал из-за подсветки синтаксиса — выглядит как комментарий. sudo же писать не стану, потому что, действительно, 1) "умные разберуться", и 2) лишняя сущность мешает восприятию команды "как есть"; тут, кстати, везде sudo нужен.


В общем, это будет лишним. Как и, например, лишним будет объяснение механизма контейнеризации, а потом вызов machinectl shell.

Вы просто совершенно не понимаете, зачем такие howto пишутся. Если вы их пишете для себя — ну отлично, пишите. Если вдруг для сообщества — то имеет смысл давать сниппеты, которые читатель сможет вставить как есть, без необходимости разбираться в лабиринтах шизофрении Поттеринга. Если мне вдруг втемяшится разобраться — я руководство почитаю, а не отписку на полстраницы.

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

У меня есть предложение получше: `$ sudoedit htop@.service`
И переменная "$EDITOR" пригодится, и доллар на решётку меня не надо.
Странны подход. Всегда делал так — заводил отдельного пользователя, в качестве шелла прописывал ему нужную программу, в данном случае htop.
При логине на данного пользователя сразу видишь htop, нажимаешь q — вываливаешься. Можно этому пользователю прописать все нужные права, сделать еще чего-то кроме в рамках указанного ему шелла сложно.

Да, интересное решение. Но оно имеет место быть ровно до того момента, пока не придётся писать надстройку в виде скрипта для имитирования опций вроде RootDirectory= или EnvironmentFile=.


// да и что-то отличное от шеллов в /etc/shells выглядит как-то противоречиво по отношению к семантике этого файла.

Зачем /etc/shells? Оболочка для конкретного пользователя разве не в /etc/passwd хранится?

Другая настройка PAM. В арче по дефолту login требует pam_shells.so, и правильно делает.

Только полноправные пользователи могут оставлять комментарии. , пожалуйста.