Management pt BR

Gerenciamento

Esta seção abrange assuntos relacionados ao gerenciamento do processo do ASF de forma ideal. Embora não seja estritamente obrigatório para o uso, ele inclui várias dicas, truques e boas práticas que gostaríamos de compartilhar, especialmente para administradores de sistema, pessoas empacotando o ASF para uso em repositórios de terceiros, bem como usuários avançados e afins.

---

Serviço systemd para Linux

Nas variantes generic e linux, o ASF vem com o arquivo [email protected] que é um arquivo de configuração do serviço para o systemd. Se você quiser executar o ASF como um serviço, por exemplo, para executá-lo automaticamente após a inicialização do seu computador, então um serviço systemd adequado é provavelmente a melhor maneira de fazer isso, por isso, recomendamos fortemente ele ao invés de fazer o gerenciamento sozinho através do nohup, screen ou similar.

Primeiramente, crie uma conta para o usuário que você deseja executar o ASF, (supondo que ela ainda não existe). Nós vamos usar o usuário asf neste exemplo, se você decidir usar um diferente, você precisará substituir o asf em todos os nossos exemplos abaixo com o seu nome de usuário selecionado. Our service does not allow you to run ASF as root, since it's considered a bad practice.

su # Or sudo -i, to get into root shell
useradd -m asf # Create account you intend to run ASF under

Em seguida, descompacte o ASF na pasta /home/asf/ArchiSteamFarm. A estrutura de pastas é importante para a nossa unidade de serviço, ela deve ser a pasta ArchiSteamFarm no seu $HOME, então /home/<user>. Se você tiver feito tudo corretamente, existirá um arquivo /home/asf/ArchiSteamFarm/[email protected]. Se você estiver usando a variante linux e não descompactar o arquivo no Linux, mas, por exemplo, usar a transferência de arquivos do Windows, então você também precisará chmod +x /home/asf/ArchiSteamFarm/ArchiSteamFarm.

Nós faremos todas as ações abaixo como root, então vá ao shell com o comando su ou sudo -i.

Em primeiro lugar, é uma boa ideia garantir que nossa pasta ainda pertence ao nosso usuário asf, chown -hR asf:asf /home/asf/ArchiSteamFarm executado uma será suficiente. As permissões podem estar erradas, por exemplo, se você baixar e/ou descompactar o arquivo zip como root.

Secondly, if you're using generic variant of ASF, you need to ensure dotnet command is recognized and within one of the standard locations: /usr/local/bin, /usr/bin or /bin. This is required for our systemd service which executes dotnet /path/to/ArchiSteamFarm.dll command. Check if dotnet --info works for you, if yes, type command -v dotnet to find out where it's located. If you've used official installer, it should be in /usr/bin/dotnet or one of the two other locations, which is alright. 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. Now command -v dotnet should report /usr/bin/dotnet, which will also make our systemd unit work. If you're using OS-specific variant, you don't need to do anything in this regard.

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. Symbolic link will allow ASF to update your systemd unit automatically as part of ASF update - depending on your situation, you may want to use that approach, or simply cp the file and manage it yourself however you'd like.

Afterwards, ensure that systemd recognizes our service:

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

Pay special attention to the user we declare after @, it's asf in our case. Our systemd service unit expects from you to declare the user, as it influences the exact place of the binary /home/<user>/ArchiSteamFarm, as well as the actual user systemd will spawn the process as.

If systemd returned output similar to above, everything is in order, and we're almost done. Now all that is left is actually starting our service as our chosen user: systemctl start ArchiSteamFarm@asf. Wait a second or two, and you can check the status again:

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: (...)
(...)

If systemd states active (running), it means everything went well, and you can verify that ASF process should be up and running, for example with journalctl -r, as ASF by default also writes to its console output, which is recorded by systemd. If you're satisfied with the setup you have right now, you can tell systemd to automatically start your service during boot, by executing systemctl enable ArchiSteamFarm@asf command. That's all.

If by any chance you'd like to stop the process, simply execute systemctl stop ArchiSteamFarm@asf. Likewise, if you want to disable ASF from being started automatically on boot, systemctl disable ArchiSteamFarm@asf will do that for you, it's very simple.

Please note that, as there is no standard input enabled for our systemd service, you won't be able to input your details through the console in usual way. Running through systemd is equivalent to specifying Headless: true setting and comes with all its implications. Fortunately for you, it's very easy to manage your ASF through ASF-ui, which we recommend in case you need to supply additional details during login or otherwise manage your ASF process further.

Variáveis de ambiente

It's possible to supply additional environment variables to our systemd service, which you'll be interested in doing in case you want to for example use a custom --cryptkey command-line argument, therefore specifying ASF_CRYPTKEY environment variable.

In order to provide custom environment variables, create /etc/asf folder (in case it doesn't exist), mkdir -p /etc/asf. We recommend to chown -hR root:root /etc/asf && chmod 700 /etc/asf to ensure that only root user has access to read those files, because they might contain sensitive properties such as ASF_CRYPTKEY. Afterwards, write to a /etc/asf/<user> file, where <user> is the user you're running the service under (asf in our example above, so /etc/asf/asf).

The file should contain all environment variables that you'd like to provide to the process. Those that do not have a dedicated environment variable, can be declared in ASF_ARGS:

# Declare apenas aqueles que você realmente precisa
ASF_ARGS="--no-config-migrate --no-config-watch"
ASF_CRYPTKEY="my_super_important_secret_cryptkey"
ASF_NETWORK_GROUP="my_network_group"

# E quaisquer outras que você esteja interessado

Sobrescrevendo parte da unidade de serviço

Graças à flexibilidade do systemd, é possível substituir parte da unidade do ASF preservando o arquivo unitário original e permitindo que o ASF o atualize como parte das atualizações automáticas.

Neste exemplo, gostaríamos de modificar o comportamento unitário padrão do ASF systemd de reiniciando apenas no sucesso para reiniciando também em falhas fatais. Para fazer isso, Nós sobrescreveremos a propriedade Restart em [Service] do padrão on-success para always. Simplesmente execute systemctl edit ArchiSteamFarm@asf, substituindo asf pelo usuário de destino do seu serviço. Em seguida, adicione as alterações conforme indicado pelo systemd na seção adequada:

### Editando /etc/systemd/system/[email protected]/override.conf
### Tudo que estiver entre está linha e o comentário abaixo se tornará o novo conteúdo do arquivo

[Service]
Restart=always

### Linhas abaixo deste comentário serão descartadas

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

E é isso. Agora sua unidade age da mesma forma que houvesse apenas Restart=always em [Service].

Claro, a alternativa é usar o comando cp no arquivo e gerenciá-lo você mesmo, mas isso te permite mudanças flexíveis mesmo se você decidiu manter a unidade original do ASF, por exemplo, com um link simbólico.

---

Nunca execute o ASF como administrador!

O ASF inclui a sua própria validação, independente do processo estar sendo executado como administrador (root). Executar como root não é necessário para qualquer tipo de operação feita pelo processo ASF. Partindo do pressuposto de que o ambiente esteja funcionando corretamente e, portanto deve ser considerado uma mau prática. Isso significa que no Windows, o ASF nunca deve ser executado com a configuração "executar como administrador", e no Unix, o ASF deve ter uma conta de usuário dedicada para si mesmo, ou reutilizar a sua própria no caso de um sistema de escritório.

Para obter mais explicações sobre por que desencorajamos a execução do ASF como root, consulte superuser e outras fontes. Se você ainda não estiver convencido, pergunte-se o que aconteceria com seu computador se o processo do ASF executasse o comando rm -rf /* logo após ser iniciado.

Eu rodo como root porque o ASF não pode escrever em seus arquivos

Isso significa que você configurou incorretamente as permissões dos arquivos que o ASF está tentando acessar. Você deve fazer login como uma conta root (ou com su ou sudo -i) e corrigir as permissões enviando o comando chown -hR asf:asf /path/to/ASF, substituindo asf:asf pelo usuário em que você executará o ASF e /path/to/ASF de acordo. Se por alguma razão você estiver usando um --path personalizado dizendo ao usuário do ASF para usar um diretório diferente, você deve executar o mesmo comando novamente para esse caminho também.

Depois de fazer isso, você não deverá mais ter nenhum tipo de problema relacionado ao ASF não ser capaz de escrever nos seus próprios arquivos, já que você acabou de alterar o proprietário de tudo o que o ASF está interessado ao usuário com o qual o processo realmente será executado.

Eu executo como root porque eu não sei fazer de outra forma

su # Or sudo -i, to get into root shell
useradd -m asf # Create account you intend to run ASF under
chown -hR asf:asf /path/to/ASF # Ensure your new user has access to the ASF directory
su asf -c /path/to/ASF/ArchiSteamFarm # Or sudo -u asf /path/to/ASF/ArchiSteamFarm, to actually start the program under your user

Isso seria feito manualmente, seria muito mais fácil usar nosso **

serviço systemd explicado acima.

Eu já sei, mas ainda quero executar como root

O ASF não te impede diretamente de fazer isso, apenas exibe um aviso com um pequeno alerta. Só não fique chocado se um dia devido a um erro no programa, ele explodir todo o seu sistema operacional com perda completa de dados — você foi avisado.

---

Múltiplas instâncias

O ASF permite a execução de múltiplas instâncias do processo no mesmo computador. The instances can be completely standalone or derived from the same binary location (in which case, you want to run them with different --path command-line argument).

Quando estiver executando várias instâncias do mesmo executável certifique-se que você desativou as atualizações automáticas em todas as configurações, pois não existe nenhuma sincronização entre eles no que tange as atualizações automáticas. Se você quiser continuar com as atualizações automáticas habilitadas nós recomendamos rodar instâncias individuais, mas você ainda pode fazer as atualizações funcionarem, contanto que você possa garantir que todas as outras instâncias do ASF sejam fechadas.

O ASF fará o seu melhor para manter uma quantidade mínima de comunicação entre Sistema Operacional e multi-processos com outras instâncias do ASF. Isso inclui verificar sua pasta de configuração ao invés da pasta de outras instâncias, além de compartilhar limitadores de núcleo de processo configurados com a propriedade de configuração global *LimiterDelay garantindo que rodar várias instâncias do ASF não cause a possibilidade de ter problemas com limite de tráfego. No que diz respeito a aspectos técnicos, todas as plataformas usam nosso mecanismo dedicado de bloqueios baseado em arquivos personalizados do ASF criados em uma pasta temporária em C:\Users\<SeuUsuário>\AppData\Local\Temp\ASF no Windows e /tmp/ASF no Unix.

Não é necessário que instâncias do ASF compartilhem as mesmas propriedades *LimiterDelay, elas podem usar valores diferentes já que cada ASF adicionará seu próprio atraso configurado para o tempo de liberação após adquirir o bloqueio. Se a configuração *LimiterDelay estiver definida como 0, a instância do ASF vai pular a espera pelo bloqueio de determinado recurso que for compartilhado com outras instâncias (isso poderia manter um bloqueio compartilhado uns com os outros). Quando definido como outro valor, o ASF irá sincronizar corretamente com outras instâncias e esperar pela sua vez e liberar o bloqueio após o atraso configurado, permitindo que outras instâncias continuem.

O ASF leva em conta a configuração WebProxy quando decide sobre o escopo compartilhado, o que significa que duas instâncias do ASF usando configurações WebProxy diferentes não compartilharão seus limitadores entre si. Isso foi implementado para permitir que as configurações de WebProxy operem sem atrasos excessivos, como esperado de diferentes interfaces de rede. Isso deve ser o suficiente para a maioria dos casos, no entanto, se você tiver uma configuração personalizada específica na qual você roteie os pedidos de forma diferente, por exemplo, você pode especificar manualmente o grupo de rede atráves do argumento de linha de comando --network-group, o que vai permitir que você declare o grupo do ASF que será sincronizado com essa instância. Tenha em mente que grupos de rede personalizados são exclusividades, o que significa que o ASF não vai mais usar o WebProxy para determinar o grupo certo, já que você é responsável pelo agrupamento nesse caso.

Se você gostaria de usar o nosso ** serviço systemd explicado acima para múltiplas instâncias do ASF, é muito simples, basta usar outro usuário para nossa declaração de serviço ArchiSteamFarm@ e seguir com os passos restantes. Isso será o equivalente a rodar várias instâncias do ASF com binários distintos, então eles também poderão atualizar e operar automática e independentemente um do outro.