Management ru RU

Управление

В этом разделе рассматриваются вопросы, связанные с оптимальным управлением процессом ASF. Хотя это не является обязательным для использования, он включает в себя несколько советов, трюков и передовой практики, которые мы хотели бы поделиться, специально для системных администраторов, люди упаковывают ASF для использования в сторонних репозиториях, а также опытных пользователей и других.

`systemd` служба для Linux

В вариантах generic и linux ASF поставляется с файлом [email protected], который является конфигурационным файлом службы systemd. Если вы хотите запустить ASF в качестве службы, например для того, чтобы запустить его автоматически после запуска машины, тогда служба systemd, скорее всего, лучший способ сделать это, поэтому мы настоятельно рекомендуем вместо того, чтобы управлять им самостоятельно через nohup, screen или другое.

Во-первых, создайте учетную запись для пользователя, под которым вы хотите запустить ASF, при условии, что она еще не существует. Мы будем использовать пользователя asf для этого примера, если вы решили использовать другое имя, то вам нужно заменить asf пользователя во всех наших примерах ниже своим выбранным. Наш сервис не позволяет вам запускать ASF в root, так как это считается очень плохой практикой.

su # Или sudo -i, чтобы попасть в корневую оболочку
useradd -m asf # Создать учетную запись, в которой вы хотите запустить ASF

Далее, распакуйте ASF в папку /home/asf/ArchiSteamFarm. Структура папок важна для нашего сервисного узла, папка ArchiSteamFarm должна быть в вашей $HOME, или /home/<user>. Если вы сделали все правильно, будет существовать файл /home/asf/ArchiSteamFarm/[email protected]. Если вы используете вариант linux и не распаковываете файл в Linux, но, к примеру, использовали передачу файлов из Windows, тогда вам также понадобится chmod +x /home/asf/ArchiSteamFarm/ArchiSteamFarm.

Все действия ниже будут выполнены в виде root, так что дойдите до его оболочки с su или sudo -i.

Во-первых, стоит убедиться в том, что наша папка по-прежнему принадлежит нашему пользователю asf, chown -hR asf:asf /home/asf/ArchiSteamFarm выполнен, как только это будет сделано. Разрешения могут быть неправильными, например, если вы загрузили и/или распаковали zip-файл в качестве root.

Во-вторых, если вы используете generic вариант ASF, вы должны убедиться, что команда dotnet распознана и находится в одном из стандартных мест: /usr/local/bin, /usr/bin или /bin. Это необходимо для нашей службы systemd, которая выполняет команду dotnet /path/to/ArchiSteamFarm.dll. Проверьте, работает ли dotnet --info у вас: если да, введите command -v dotnet, чтобы узнать, где она находится. Если вы использовали официальный установщик, то она должна находиться в /usr/bin/dotnet или одном из двух других мест, что является правом. If it's in custom location such as /usr/share/dotnet/dotnet, create a symlink for it using ln -s "$(command -v dotnet)" /usr/bin/dotnet. Теперь command -v dotnet должна сообщать о /usr/bin/dotnet, что также приведет к работе systemd. Если вы используете платформо-специфичный вариант, то вам не нужно ничего делать в этом отношении.

Next, execute ln -s /home/asf/ArchiSteamFarm/ArchiSteamFarm\@.service /etc/systemd/system/ArchiSteamFarm\@.service, this will create a symbolic link to our service declaration and register it in systemd. Символьная ссылка позволит ASF автоматически обновлять ваш systemd в рамках обновления ASF - в зависимости от вашей ситуации, вы можете использовать этот подход, или просто cp файл и управлять им самостоятельно.

После этого убедитесь, что systemd распознает наш сервис:

systemctl status ArchiSteamFarm@asf

○ [email protected] - ArchiSteamFarm Service (on asf)
     Loaded: loaded (/etc/systemd/system/[email protected]; disabled; vendor preset: enabled)
     Active: inactive (dead)
       Docs: https://github.com/JustArchiNET/ArchiSteamFarm/wiki

Уделите особое внимание заявленному пользователю после @ (это asf в нашем случае). systemd ожидает от вас объявление пользователя, так как это влияет на точное место двоичного файла /home/<user>/ArchiSteamFarm, а также фактическая user systemd создаст процесс как таковой.

Если systemd выдала нечто, похожее на написанное выше, то все в порядке, и мы почти закончили. Теперь всё, что осталось - это запустить нашу службу от имени выбранного пользователя: systemctl start ArchiSteamFarm@asf. Подождите пару мгновений, и вы можете проверить статус снова:

systemctl status ArchiSteamFarm@asf

● [email protected] - ArchiSteamFarm Service (on asf)
     Loaded: loaded (/etc/systemd/system/[email protected]; disabled; vendor preset: enabled)
     Active: active (running) since (...)
       Docs: https://github.com/JustArchiNET/ArchiSteamFarm/wiki
   Main PID: (...)
(...)

Если состояние systemd - active (running), это означает, что все прошло успешно, и вы можете проверить, что ASF процесс должен быть запущен, например, с journalctl -r, так как ASF по умолчанию также записывает в свой вывод консоли, который записан systemd. Если вы довольны установкой прямо сейчас, вы можете попроситьsystemd автоматически запускать службу во время загрузки, выполнив systemctl enable ArchiSteamFarm@asf. На этом всё!

Если вдруг вы хотите остановить процесс, просто выполните systemctl stop ArchiSteamFarm@asf. Аналогично, если вы хотите, чтобы ASF запускался автоматически при загрузке, systemctl disable ArchiSteamFarm@asf сделает это за вас, это очень просто.

Пожалуйста, обратите внимание, что из-за отсутствия стандартных входных данных для нашей службы systemd вы не сможете вводить данные через консоль обычным способом. Прохождение через systemd эквивалентно заданию headless: true устанавливается и поставляется со всеми вытекающими последствиями. К счастью для вас, ASF очень легко управлять через ASF-ui, который мы рекомендуем в случае, если вам необходимо предоставить дополнительные данные во время входа в систему или иным образом управлять вашим процессом ASF.

Переменные среды

Возможна поставка дополнительных переменных среды в наш systemd, которая будет интересна в том случае, если вы хотите использовать пользовательский --cryptkey аргумент командной строки, поэтому задайте переменную окружения ASF_CRYPTKEY.

Чтобы предоставить пользовательские переменные окружения, создайте папку /etc/asf (в случае, если она не существует), mkdir -p /etc/asf. Рекомендуем использовать chown -hR root:root /etc/asf && chmod 700 /etc/asf, чтобы убедиться, что только root пользователь имеет доступ к чтению этих файлов, потому что они могут содержать конфиденциальные поля, такие как ASF_CRYPTKEY. После этого напишите в файл /etc/asf/<user>, где <user> - это пользователь, под которым вы запускаете службу (asf в нашем примере выше, поэтому у нас /etc/asf/asf).

Файл должен содержать все переменные окружения, которые вы хотели бы предоставить программе. Те, у которых нет отдельной переменной окружения, могут быть объявлены в ASF_ARGS:

# Объявите только то что вам нужно
ASF_ARGS="--no-config-migrate --no-config-watch"
ASF_CRYPTKEY="my_super_important_secret_cryptkey"
ASF_NETWORK_GROUP="my_network_group"

# И любые другие, нужные вам

Переопределение части сервисного юнита

Благодаря гибкости systemd, можно переписать часть блока ASF, сохраняя исходный файл и позволяя ASF обновлять его, например, в качестве части автоматического обновления.

В этом примере мы хотели бы изменить поведение юнита systemd ASF не только после перезапуска при успешном завершении, а также и при фатальных сбоях. Для этого мы переопределим свойство Restart в разделе [Service] с on-success по умолчанию на always. Просто запустите systemctl edit ArchiSteamFarm@asf, естественно, заменив asf целевым пользователем вашего сервиса. Затем добавьте ваши изменения, как указано systemd в нужном разделе:

### Editing /etc/systemd/system/[email protected]/override.conf
### Anything between here and the comment below will become the new contents of the file

[Service]
Restart=always

### Lines below this comment will be discarded

### /etc/systemd/system/[email protected]
# [Install]
# WantedBy=multi-user.target
# 
# [Service]
# EnvironmentFile=-/etc/asf/%i
# ExecStart=dotnet /home/%i/ArchiSteamFarm/ArchiSteamFarm.dll --no-restart --service --system-required
# Restart=on-success
# RestartSec=1s
# SyslogIdentifier=asf-%i
# User=%i
# (...)

И вот теперь ваш юнит действует так же, как если бы она имела только Restart=always под [Service].

Of course, alternative is to cp the file and manage it yourself, but this allows you for flexible changes even if you decided to keep original ASF unit, for example with a symlink.

Никогда не запускайте ASF от имени администратора!

ASF включает в себя собственную проверку того, запускается ли процесс с правами администратора (root) или нет. Running as root is not required for any kind of operation done by the ASF process, assuming properly configured environment it's operating in, and therefore should be regarded as a bad practice. This means that on Windows, ASF should never be executed with "run as administrator" setting, and on Unix ASF should have a dedicated user account for itself, or re-use your own in case of a desktop system.

For further elaboration on why we discourage running ASF as root, refer to superuser and other resources. Если вы все еще не убедились, спросите себя, что будет с вашей машиной, если ASF процесс выполнит команду rm -rf /* сразу после запуска (комментарий переводчика: трындец вашей операционке!).

Я запустил ASF через `root` потому что он не может записывать файлы

Это означает, что вы неправильно настроили разрешения файлов, к которым ASF пытается получить доступ. Вы должны войти в систему под учёткой root (либо с помощью su, либо sudo -i), а затем исправить разрешения, введя команду chown -hR asf:asf /path/to/ASF, заменив asf:asf пользователем, под которым вы будете запускать ASF, и /path/to/ASF соответственно. Если вдруг вы используете пользовательские --path, говорящие пользователю ASF использовать другие директории, вы также должны выполнить ту же команду для этого пути.

После этого вы больше не должны сталкиваться с проблемами, связанными с тем, что ASF не может перезаписывать свои собственные файлы, так как вы только что изменили владельца всего, что интересует ASF, на пользователя, от имени которого фактически будет выполняться процесс ASF.

Я запускаю как `root`, потому что не знаю, как это сделать иначе

su # или sudo -i, чтобы попасть в корневую оболочку
useradd -m asf # Создать учетную запись, в которой вы хотите запустить ASF
chown -hR asf:asf /path/to/ASF # Убедитесь, что ваш новый пользователь имеет доступ к директории с ASF
su asf -c /path/to/ASF/ArchiSteamFarm # Или sudo -u asf /path/to/ASF/ArchiSteamFarm, чтобы запустить программу под вашим пользователем

Это будет сделано вручную, гораздо проще использовать наш systemdсервис, как описано выше.

Я знаю лучше, и я все еще хочу запустить как `root`, БЕ!

ASF doesn't forcefully stop you from doing so, only displays a warning with a short notice. Просто не удивляйтесь, если в один день из-за ошибки в программе он взорвет всю вашу ОС с полной потерей данных - вы были предупреждены. Развлекайтесь XD

Запуск нескольких экземпляров

ASF поддерживает запуск нескольких экземпляров программы на одной и той же машине. Экземпляры могут быть полностью автономными или получены из одного двоичного местоположения (в этом случае вы хотите запустить их с помощью другого--path аргумента командной строки).

При использовании нескольких одновременно работающих копий одного исполняемого файла имейте в виду, что в этом случае обычно стоит отключать авто-обновления во всех конфигурационных файлах, поскольку обновление не будет синхронизировано между копиями. Если вы хотите оставить авто-обновление включенным, мы рекомендуем отдельные копии файлов, но вы можете всё равно добиться работы обновлений, если сможете обеспечить чтобы все остальные экземпляры ASF были закрыты.

ASF будет по возможности использовать минимум обще-системных, меж-процессных взаимодействий с другими экземплярами ASF. Сюда входит проверка ASF каталога конфигурации на другие случаи, а также обмен ограничениями ядра процессов, сконфигурированных с *LimiterDelay в глобальной конфигурации, убедитесь, что запуск нескольких ASF экземпляров не приведет к возникновению проблемы ограничения скорости. Что касается технической реализации — все платформы используют наш специальный механизм блокировок ASF, основанный на блокировках файлов во временной директории, в качестве которой используется C:\Users\<ВашеИмяПользователя>\AppData\Local\Temp\ASF под Windows, и /tmp/ASF под Unix.

Использование одинаковых параметров *LimiterDelay для всех запущенных экземпляров не является обязательным, они могут использовать различные значение, поскольку каждый экземпляр ASF будет добавлять собственную, заданную в конфигурационном файле, задержку до освобождения файла после его захвата. Если параметр *LimiterDelay задан равным 0, этот экземпляр ASF будет полностью игнорировать ожидание блокировки заданных ресурсов, разделяемых с другими экземплярами (которые могут потенциально поддерживать общую блокировку между собой). При установке любых других значений, ASF будет правильно синхронизироваться с любыми другими экземплярами ASF и будет ждать своей очереди, а затем снимать блокировку после заданной задержки, позволяя другим экземплярам продолжить работу.

ASF учитывает настройки WebProxy для принятия решения об использовании блокировок, то есть два экземпляра ASF, использующих разную настройку WebProxy не будут иметь общей блокировки между собой. Это сделано чтоб позволить конфигурациям с использованием WebProxy работать без излишних задержек, как ожидается от разных сетевых интерфейсов. Этого должно быть достаточно для большинства вариантов использования, однако, если у вас есть специальная настройка, в которой вы, например, будете маршрутизировать запросы самостоятельно другим способом, можно указать группу сети самостоятельно через аргумент командной строки --network-group, который позволит вам объявить группу ASF, которая будет синхронизирована с этим экземпляром. Имейте в виду, что пользовательские сетевые группы переопределяют внутреннюю группировку, а значит ASF больше не будет учитывать значение WebProxy для определения правильной группы, так как в этом случае вы полностью отвечаете за группировку.

Если вы хотите использовать наш systemd сервис, описанный выше для нескольких экземпляров ASF, то это очень просто, просто используйте другого пользоватея для нашего ArchiSteamFarm@ сервиса и следуйте остальным шагам. Это будет эквивалентно запуску нескольких ASF экземпляров с отдельными двоичными файлами, так что они могут также автоматически обновляться и работать независимо друг от друга.