Смоленск 1.5 автозагрузка скрипта под конкретным пользователем
имеется такая задача:
есть 2 пользователя, условно admin и user
user входит в систему, в которой сразу запускается программа, и он ничего не может делать, кроме как пользоваться этой программой,
под admin программа не запускается, его задача эту программу настраивать, обновлять, добавлять при необходимости пользователей типа user и т.д.
и вот в чём вопрос: как сделать, чтобы скрипт запускающий программу работал под конкретных пользователей?
на просторах интернета нашёл, что нужно добавить для конкретного пользователя
sudo -i -u user /etc/runmyprog.sh
или для всех пользователей
/etc/runmyprog.sh
в /etc/rc.local, но ни тот, ни другой вариант не работает, при этом двойной клик по rc.local запускает программу в обоих случаях
Montfer
New member
с режимом Киоск не пробовали?
— попробовал на виртуалке:
— установил пакет fly-admin-kiosk
— создал пользователя user
— сделал вход под ним, чтобы создались домашние каталоги
— под админом в политике безопасности включил user’у режим киоска, указав, что он будет работать только с прогой firefox.
— юзверю стал доступен только firefox
DrageFabeldyr
New member
в моём случае пользователь не должен запускать программу сам, она должна запускаться автоматически, но пользователей может быть несколько и у всех она должна запускаться
можно каждому пользователю при создании добавлять её в пуск -> настройки -> автостарт, но может есть более «админский» способ?
Montfer
New member
в моём случае пользователь не должен запускать программу сам, она должна запускаться автоматически, но пользователей может быть несколько и у всех она должна запускаться
можно каждому пользователю при создании добавлять её в пуск -> настройки -> автостарт, но может есть более «админский» способ?
В киоске прога при входе в систему и будет сама запускаться, а при закрытии программы должен сработать автовыход из сессии. И больше ничего нельзя запустить, ни файл сохранить. даже рабочего стола и меню пуск не будет
oko
New member
to DrageFabeldyr
/etc/rc.local — bash-скрипт, запускаемый при старте системы согласно спецификации System V Init, но до старта X-Server и его окружения (т.е. до старта графики). Поэтому размещать в нем скрипты, стартующие какое-либо GUI-приложение — не выход (хотя и тут можно нагородить велосипед с задержками и автоподключением к текущей X-сессии, но оно того не стоит). Еще /etc/rc.local исполняется с правами суперпользователя root. Из него, конечно, можно что-либо запустить с правами пользователя через su — имя_пользователя или через предложенный у вас вариант с sudo. Но это тоже весьма узкоспециализированные варианты и не для такого монолита, как Astra Linux Special Edition в графическом режиме, ага.
Так что да, проще и быстрее всего добавлять штатными средствами нужный софт в автозапуск пользователю при его создании. Можно чуток автоматизировать — тут на форуме был предложен вариант с автозапуском через правку файлов FlyWM. Поищите.
Или, да, +1 к тов. Montfer — «киос» решает проблему, если, конечно, пользователю для штатной работы хватит одного единственного приложения.
Автозапуск в Linux
Одним из самых старых способов запуска нужных команд является специальный файл rc.local. Находится данный файл в директории /etc/ и по умолчанию содержит всего одну команду:
Достаточно написать что-то перед данной строкой, и эта команда будет исполнятся при запуске системы.
В современных системах, вроде Debian 9 или Ubuntu 18.04, данный файл отсутствует, но ради обеспечения обратной совместимости возможность автозапуска с его помощью оставлена.
Для его использования, нужно сперва данный файл создать, а затем дополнительно активировать через systemd:
systemctl enable rc-local systemctl start rc-local.service.bashrc и .profile
Если нужно автоматически запускать какую-то программу, скрипт или команду при входе пользователя в систему, то для этой цели прекрасно подойдут файлы .bashrc и .profile.
Данные файлы находятся в двух местах, и выполняются в следующем порядке:
- Общие для всех пользователей файлы находятся в директории /etc/
- Для каждого пользователя так же существуют отдельные экземпляры данных файлов, которые находятся в корне их домашних директорий- например, у пользователя sysadmin, они будут находится по пути /home/sysadmin.
Для корректного использования данных файлов, следует понимать их предназначение в системе:
- .bash_profile — данный файл используется для загрузки файлов .profile и .bashrc (в приведенном порядке).
- .bashrc — содержимое данного файла загружается при входе в режим терминала. Именно здесь задаются такие параметры, как внешний вид среды терминала, текстовый редактор по умолчанию и другое.
- .profile — содержимое данного файла загружается при загрузке графической оболочки. Здесь могут быть указаны различные переменные среды, и прочее не относящееся к bash содержимое.
Как использовать /etc/rc.local при загрузке — Linux подсказка
В rc.local сценарий в некоторых дистрибутивах Linux и системах Unix представляет собой сценарий запуска суперпользователя, обычно расположенный в каталоге /etc/etc/rc.d. Имя файла rc относится к Run Control.
Rc.local — это устаревший скрипт, сохраненный для совместимости с системами systemV.
Когда-то это был универсальный файл, присутствующий в большинстве дистрибутивов Linux из-за того, что администраторам Linux было легко определять сценарии запуска или дополнительные службы для запуска.
Файл rc.local не содержит информации о компонентах запуска системы, а только о компонентах, определенных суперпользователем / root. Однако в rc.local описаны не все программы запуска root, а только те, которые не мешают работе компонентов системы. Обычно rc.local выполняется после запуска обычных служб.
Более новые системы Linux, включая Systemd, заменили сценарий rc.local, но его можно восстановить, несмотря на является рекомендуемым решением. В этом руководстве показано, как восстановить и использовать сценарий rc.local, а также использовать rc-local от systemd в новых дистрибутивах Linux.
Включение /etc/rc.local в дистрибутивах Linux с помощью Systemd:
ВАЖНЫЙ: Важно помнить, что /etc/rc.local больше не поддерживается и заменяется. Текущий метод запуска скриптов при загрузке описан после инструкций по включению /etc/rc.local. Это руководство предназначено для пользователей с особыми потребностями.
Для начала создадим файл /etc/rc.local используя нужный редактор и sudo (или root):
Вставьте приведенный ниже код в файл и замените с командой, которую вы хотите запустить при запуске. Не используйте sudo. Если команда, включенная в этот сценарий, не может быть выполнена, служба, которая вызовет rc.local (rc-local.service), выйдет из строя.
#! / bin / sh -e
#
# rc.local
#
# Этот сценарий выполняется в конце каждого многопользовательского уровня запуска.
# Убедитесь, что сценарий «выйдет из 0» в случае успеха или в любом другом случае.
# значение при ошибке.
#
# Чтобы включить или отключить этот скрипт, просто измените выполнение
# бит.
#
# По умолчанию этот скрипт ничего не делает.
В моем примере я буду использовать сценарий rc.local для обновления базы данных vuls сканирования безопасности при каждом запуске системы. Вы можете написать любой сценарий, который хотите запустить в начале, кроме сетевых сценариев (например, iptables), которые могут мешать нормальному процессу запуска и иметь собственные сценарии запуска, или каталоги.
Сохраните файл (CTRL + X и Y) и дайте ему разрешение на выполнение, выполнив команду ниже:
судо chmod + х / так далее / rc.local
Создайте файл /etc/systemd/system/rc-local.service, запустить:
нано / так далее / systemd / система / rc-local.service
Вставьте следующие команды и выйдите из сохранения, нажав CTRL + X и Y.
ExecStart = / так далее / rc.local start
TimeoutSec = 0
Стандартный выход = tty
RemainAfterExit = да
SysVStartPriority = 99
[ Установить ]
Разыскивается = multi-user.target
судо systemctl включить rc-local
Теперь вы можете запустить службу rc-local.service, которая будет читать файл /etc/rc.local. Выполните команду, показанную ниже:
systemctl start rc-local.service
Вы можете проверить, правильно ли был загружен rc-local, выполнив следующее:
статус systemctl rc-local.service
Правильный способ (Systemd):
Описанный выше процесс устарел, устарел и может привести к сбою некоторых служб.
В этом разделе показан текущий процесс запуска сценариев или служб при загрузке для дистрибутивов Linux с использованием Systemd.
Systemd — это менеджер служб, который назначает группы управления службами (cgroup) и отслеживает процессы. Systemd — это процесс (PID) 1, отвечающий за запуск системы.
Чтобы добавить сервисы или скрипты при запуске, вам нужно создать блок systemd.
Модули Systemd включают сервисы (.служба), точки монтирования (.устанавливать), устройства (.устройство) или сокеты (.разъем). В отличие от старого процесса, описанного ранее с помощью rc.local, вместо редактирования того же файла, содержащего информации о пользовательских скриптах, вам необходимо создать служебную единицу Systemd для каждого скрипта, который вы хотите запустить на запускать.
Модули Systemd расположены по адресу /etc/systemd/system, и именно здесь нам нужно создать модуль systemd для сценария, который мы хотим запустить при загрузке.
На следующем изображении показано содержимое блока. TeamViewer.service.
- Описание = Эта директива описывает устройство; вы можете установить имя устройства.
- Требуется = Здесь вы можете указать зависимости для предотвращения сбоев при запуске.
- Хочет = Как и в предыдущем случае, он поддерживает работу службы, даже если не находит определенных зависимостей.
- После = Агрегат запустится после указанного в этой директиве.
Некоторые директивы, используемые в разделе [Service], могут быть переданы [Unit].
- Тип = В примере, показанном выше, разветвлениеуказывает, что служба будет уничтожена, сохраняя дочерние процессы, которым должен быть назначен PID.
- PIDFile = Для директивы Forking требуется директива PIDFile, которая должна содержать путь к pid файла дочернего процесса, чтобы Systemd могла его идентифицировать.
- ExecStart = Здесь вы указываете путь и команды, которые хотите выполнить. Это похоже на файл rc.local.
- Перезагрузка = Эта директива указывает Systemd, когда перезапускать устройство. Доступны следующие варианты: при отказе, при прерывании, всегда, при успешном выполнении, при наблюдении или при отклонении от нормы.
- StartLimitInterval = Эта директива указывает, что у устройства есть 60 секунд на 10 попыток перезапуска в случае сбоя.
- StartLimitBurst = Эта директива указывает ограничение попыток, в приведенном выше примере 10 попыток за 60 секунд.
Единственная директива [Install] в приведенном выше примере — WantedBy.
- В розыске = Здесь вы можете указать этот модуль как зависимость; она похожа на директиву Wants, но определение текущего модуля считается зависимостью другого модуля.
Примечание: Вы можете проверить все директивы Systemd на
https://www.freedesktop.org/software/systemd/man/systemd.directives.html
Добавление собственного Systemd Unit:
Чтобы запустить сценарий при запуске, создайте его в /etc/systemd/system с именем, за которым следует точка и служба, например, linuxhint. обслуживание. Вы можете использовать nano, как в следующем примере:
Вставьте следующее, заменив Название или описание скрипта> с описанием вашего скрипта и где /usr/sbin/linuxhint.sh напишите правильный путь.
[ Единица измерения ]
Описание = < Название или описание скрипта >
[ обслуживание ]
ExecStart = / мусорное ведро / трепать / usr / sbin / linuxhint.sh # в этой строке укажите путь к скрипту.
[ Установить ]
Разыскивается = multi-user.target
Затем включите новую службу, запустив:
Запустите службу и проверьте ее правильность, выполнив:
systemctl start linuxhint
systemctl статус linuxhint
Ваш сценарий готов к запуску при запуске.
Вывод:
Хотя Systemd кажется намного более сложным, чем старый rc.local, каждая служба или скрипт представляет собой уникальную единицу, которая гарантирует большую стабильность системы.
Как сказано в первом разделе, посвященном rc.local, если команда в сценарии не загружается правильно, это может повлиять на общий файл конфигурации.
Кроме того, Systemd предоставляет инструменты, которых нет в rc.local, для обработки большего количества ситуаций и спецификаций.
Другие преимущества Systemd включают простоту контроля и управления процессами (что не объяснялось в этом руководстве). Systemd также позволяет группировать службы и содержит более подробные сообщения об ошибках.
Надеюсь, вы нашли этот полезный урок. Следуйте подсказкам по Linux, чтобы получить больше советов и руководств по Linux.