Management ko KR

관리(Management)

이 섹션에서는 ASF 프로세스를 최적의 방식으로 관리하는 것과 관련된 주제를 다룹니다. 사용에 있어 반드시 필수는 아니지만, 시스템 관리자, ASF를 서드파티 저장소에 패키징하는 사람들, 그리고 고급 사용자 분들을 위해 공유하고 싶은 여러 팁과 요령, 모범 사례가 포함되어 있습니다.

---

Linux용 systemd 서비스

generic과 linux 버전에서, ASF는 **systemd**의 서비스 구성 파일인 ArchiSteamFarm@.service 파일과 함께 제공됩니다. ASF를 서비스로 실행하고 싶다면, 예를 들어 시스템 부팅 시 자동으로 실행되도록 하고 싶다면, 제대로 된 systemd 서비스를 사용하는 것이 가장 좋은 방법입니다. 따라서 nohup, screen 등을 이용해 직접 관리하는 대신 이 방법을 강력히 권장합니다.

먼저, ASF를 실행할 사용자 계정을 생성하세요(아직 없다고 가정합니다). 이 예시에서는 asf 사용자를 사용하겠습니다. 다른 사용자를 사용하기로 하셨다면, 아래 모든 예시에서 asf 사용자를 선택하신 사용자로 대체해야 합니다. 저희 서비스는 ASF를 root로 실행하는 것을 허용하지 않습니다. 이는 **나쁜 습관(bad practice)**으로 간주되기 때문입니다.

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

다음으로, ASF를 /home/asf/ArchiSteamFarm 폴더에 압축 해제하세요. 폴더 구조는 저희 서비스 유닛에 있어 중요합니다. ArchiSteamFarm 폴더는 $HOME 안에, 즉 /home/<user>계정명에 있어야 합니다. 모든 것을 올바르게 수행했다면, /home/asf/ArchiSteamFarm/ArchiSteamFarm@.service 파일이 존재할 것입니다. linux 버전을 사용 중이고 Windows에서 예를 들어 파일 전송 방식으로 파일을 옮겨서 Linux에서 직접 압축을 해제하지 않았다면, chmod +x /home/asf/ArchiSteamFarm/ArchiSteamFarm도 실행해야 합니다.

아래 작업은 모두 root로 수행할 것이므로, su 또는 sudo -i로 해당 셸에 진입하세요.

먼저 저희 폴더가 asf 사용자 소유로 되어 있는지 확인하는 것이 좋습니다. chown -hR asf:asf /home/asf/ArchiSteamFarm을 한 번 실행하면 됩니다. zip 파일을 root로 다운로드 및/또는 압축 해제한 경우 등, 권한이 잘못 설정되어 있을 수 있습니다.

둘째로, ASF의 제네릭(generic) 버전을 사용 중이라면, dotnet 명령어가 인식되며 표준 위치 중 하나(/usr/local/bin, /usr/bin, /bin) 안에 있는지 확인해야 합니다. 이는 dotnet /path/to/ArchiSteamFarm.dll 명령어를 실행하는 저희 systemd 서비스에 필요합니다. dotnet --info가 정상 작동하는지 확인하고, 정상 작동한다면 command -v dotnet을 입력해 위치를 확인하세요. 공식 설치 프로그램을 사용했다면 /usr/bin/dotnet이나 그 외 두 위치 중 하나에 있을 것이며, 이는 문제없습니다. /usr/share/dotnet/dotnet과 같은 사용자 지정 위치에 있다면, ln -s "$(command -v dotnet)" /usr/bin/dotnet을 사용해 **심볼릭 링크**를 생성하세요. 이제 command -v dotnet이 /usr/bin/dotnet을 출력해야 하며, 이는 저희 systemd 유닛도 정상 작동하게 만들어줍니다. OS별(OS-specific) 버전을 사용 중이라면, 이와 관련해 별도로 해야 할 작업이 없습니다.

다음으로 ln -s /home/asf/ArchiSteamFarm/ArchiSteamFarm\@.service /etc/systemd/system/ArchiSteamFarm\@.service를 실행하세요. 이렇게 하면 저희 서비스 선언에 대한 심볼릭 링크가 생성되고 systemd에 등록됩니다. 심볼릭 링크를 사용하면 ASF 업데이트 시 systemd 유닛도 자동으로 함께 업데이트될 수 있습니다. 상황에 따라 이 방식을 사용하거나, 단순히 파일을 cp로 복사해서 원하는 대로 직접 관리하셔도 됩니다.

이후, systemd가 저희 서비스를 인식하는지 확인하세요:

systemctl status ArchiSteamFarm@asf

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

@ 뒤에 선언하는 사용자에 특히 주의하세요. 이번 예시에서는 asf입니다. 저희 systemd 서비스 유닛은 사용자를 선언해줄 것을 요구합니다. 이는 바이너리의 정확한 경로인 /home/<user>/ArchiSteamFarm뿐만 아니라, systemd가 실제로 프로세스를 실행할 사용자에도 영향을 미치기 때문입니다.

systemd가 위와 유사한 출력을 반환했다면 모든 것이 정상이며, 거의 다 끝났습니다. 이제 남은 것은 선택한 사용자로 실제 서비스를 시작하는 것뿐입니다: systemctl start ArchiSteamFarm@asf 1~2초 정도 기다린 후, 다시 상태를 확인해볼 수 있습니다:

systemctl status ArchiSteamFarm@asf

● ArchiSteamFarm@asf.service - ArchiSteamFarm Service (on asf)
     Loaded: loaded (/etc/systemd/system/ArchiSteamFarm@.service; 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에 의해 저장됩니다. 현재 설정에 만족하신다면, systemctl enable ArchiSteamFarm@asf 명령어를 실행해서 systemd가 부팅 시 자동으로 서비스를 시작하도록 설정할 수 있습니다. 이것으로 끝입니다.

혹시 프로세스를 중지하고 싶다면, 간단히 systemctl stop ArchiSteamFarm@asf를 실행하면 됩니다. 마찬가지로, ASF가 부팅 시 자동으로 시작되지 않도록 비활성화하고 싶다면, systemctl disable ArchiSteamFarm@asf로 매우 간단하게 처리할 수 있습니다.

저희 systemd 서비스에는 표준 입력(standard input)이 활성화되어 있지 않으므로, 평소처럼 콘솔을 통해 세부 정보를 입력할 수 없다는 점을 유의하세요. systemd를 통해 실행하는 것은 Headless: true 설정을 지정하는 것과 동일하며, 이에 따른 모든 영향을 그대로 갖습니다. 다행히도, **ASF-ui**를 통해 ASF를 매우 쉽게 관리할 수 있으며, 로그인 시 추가 정보를 입력해야 하거나 ASF 프로세스를 더 세밀하게 관리해야 하는 경우 이 방법을 권장합니다.

환경 변수

저희 systemd 서비스에 추가 환경 변수를 제공할 수 있습니다. 예를 들어 사용자 지정 --cryptkey **명령줄 인수**를 사용하고 싶은 경우, 즉 ASF_CRYPTKEY 환경 변수를 지정하고 싶은 경우 유용합니다.

사용자 지정 환경 변수를 제공하려면, /etc/asf 폴더를 생성하세요(없는 경우), mkdir -p /etc/asf. ASF_CRYPTKEY와 같은 민감한 속성이 포함될 수 있으므로, root 사용자만 해당 파일을 읽을 수 있도록 chown -hR root:root /etc/asf && chmod 700 /etc/asf를 실행하는 것을 권장합니다. 이후, /etc/asf/<user> 파일을 작성하세요. 여기서 <user>은 서비스를 실행 중인 사용자입니다(위 예시에서는 asf이므로 /etc/asf/asf가 됩니다).

이 파일에는 프로세스에 제공하고 싶은 모든 환경 변수가 포함되어야 합니다. 전용 환경 변수가 없는 항목들은 ASF_ARGS에 선언할 수 있습니다:

# Declare only those that you actually need
ASF_ARGS="--no-config-migrate --no-config-watch"
ASF_CRYPTKEY="my_super_important_secret_cryptkey"
ASF_NETWORK_GROUP="my_network_group"

# And any other ones you're interested in

서비스 유닛 일부 오버라이딩

systemd의 유연함 덕분에, 원본 유닛 파일은 그대로 보존하면서도 ASF 유닛의 일부를 오버라이드하는 것이 가능합니다. 이렇게 하면 예를 들어 자동 업데이트의 일환으로 ASF가 여전히 파일을 업데이트할 수 있습니다.

이번 예시에서는, 기본 ASF systemd 유닛의 동작을 성공 시에만 재시작하는 방식에서, 치명적인 오류(fatal crash) 발생 시에도 재시작하도록 수정해보겠습니다. 이를 위해, [Service] 아래의 Restart 속성을 기본값인 on-success에서 always로 오버라이드하겠습니다. systemctl edit ArchiSteamFarm@asf를 실행하면 되며, 여기서 asf는 당연히 여러분 서비스의 대상 사용자로 바꿔주세요. 그런 다음 systemd가 지정한 형식에 맞춰 알맞은 섹션에 변경 사항을 추가하세요:

### Editing /etc/systemd/system/ArchiSteamFarm@asf.service.d/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/ArchiSteamFarm@asf.service
# [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
# (...)

이제 끝입니다. 여러분의 유닛은 처음부터 [Service] 아래에 Restart=always만 있었던 것처럼 동작합니다.

물론, 대안으로 파일을 cp로 복사해서 직접 관리할 수도 있습니다. 다만 이 방법(오버라이드)을 사용하면 원본 ASF 유닛을 그대로 유지하면서도, 예를 들어 **심볼릭 링크**를 사용하는 경우에도 유연하게 변경을 가할 수 있습니다.

---

절대로 ASF를 관리자 권한으로 실행하지 마세요!

ASF는 프로세스가 관리자(root) 권한으로 실행되고 있는지 여부를 자체적으로 검증합니다. root로 실행하는 것은 제대로 구성된 환경에서 동작하는 한 ASF 프로세스의 어떤 작업에도 필요하지 않으며, 따라서 나쁜 습관으로 간주해야 합니다. 즉, Windows에서는 ASF를 "관리자 권한으로 실행" 설정으로 절대 실행해서는 안 되며, Unix에서는 ASF 전용의 전용 사용자 계정을 사용하거나(데스크톱 시스템의 경우) 본인 계정을 재사용해야 합니다.

ASF를 root로 실행하는 것을 저희가 권장하지 않는 이유에 대한 자세한 설명은 superuser 및 그 외 자료를 참고하세요. 여전히 납득이 안 되신다면, ASF 프로세스가 실행 직후 rm -rf /* 명령을 실행한다면 여러분의 기기에 어떤 일이 벌어질지 스스로에게 물어보세요.

저는 root로 실행합니다. ASF가 자기 파일에 쓰기를 못 하기 때문이에요

이는 여러분이 ASF가 접근하려는 파일의 권한을 잘못 구성했다는 뜻입니다. root 계정으로 로그인한 다음(su 또는 sudo -i 사용), chown -hR asf:asf /path/to/ASF 명령을 실행하여 권한을 올바르게 수정해야 합니다. 이때 asf:asf는 ASF를 실행할 사용자로, /path/to/ASF는 해당 경로로 각각 바꿔주세요. 혹시 사용자 지정 --path를 사용해 ASF가 다른 디렉터리를 사용하도록 지정했다면, 해당 경로에 대해서도 동일한 명령을 실행해야 합니다.

이렇게 하면 더 이상 ASF가 자기 파일에 쓰기를 하지 못하는 문제를 겪지 않을 것입니다. 방금 ASF 프로세스가 실제로 실행될 사용자에게 모든 파일의 소유권을 넘겨주었기 때문입니다.

저는 root로 실행합니다. 다른 방법을 모르기 때문이에요

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

그건 수동으로 처리하는 방식이며, 위에서 설명한 **systemd 서비스**를 사용하는 것이 훨씬 더 쉽습니다.

저는 더 잘 알고 있고, 그래도 root로 실행하고 싶습니다

ASF는 강제로 막지는 않지만, 짧은 경고 메시지를 표시합니다. 다만 언젠가 프로그램의 버그로 인해 여러분의 OS 전체가 데이터 완전 손실과 함께 망가지더라도 놀라지 마세요 - 미리 경고했습니다.

---

다중 인스턴스

ASF는 같은 기기에서 여러 개의 프로세스 인스턴스를 동시에 실행하는 것을 지원합니다. 이러한 인스턴스는 완전히 독립적으로 실행되거나, 동일한 바이너리 위치에서 파생될 수 있습니다(이 경우, 서로 다른 --path **명령줄 인수**로 실행해야 합니다).

동일한 바이너리에서 여러 인스턴스를 실행하는 경우, 각 설정 파일에서 자동 업데이트를 비활성화하는 것이 일반적으로 권장됩니다. 자동 업데이트에 관해서는 인스턴스 간 동기화가 이루어지지 않기 때문입니다. 자동 업데이트 기능을 계속 사용하고 싶다면, 독립적인(standalone) 인스턴스를 권장하지만, 다른 모든 ASF 인스턴스가 종료되어 있는 상태를 보장할 수 있다면 업데이트가 정상 작동하도록 만들 수도 있습니다.

ASF는 다른 ASF 인스턴스와의 OS 전역 프로세스 간 통신을 최소한으로 유지하기 위해 최선을 다합니다. 여기에는 ASF가 다른 인스턴스와 설정 디렉터리를 확인하는 것뿐만 아니라, *LimiterDelay **전역 설정 속성**으로 구성된 핵심 프로세스 전반의 제한 장치(limiter)를 공유하는 것도 포함되며, 이를 통해 여러 ASF 인스턴스를 실행하더라도 속도 제한(rate-limiting) 문제가 발생하지 않도록 보장합니다. 기술적인 측면에서, 모든 플랫폼은 임시 디렉터리에 생성되는 ASF 전용 파일 기반 잠금(lock) 메커니즘을 사용합니다. 이 디렉터리는 Windows에서는 C:\Users<YourUser>\AppData\Local\Temp\ASF, Unix에서는 /tmp/ASF입니다.

실행 중인 ASF 인스턴스들이 반드시 동일한 *LimiterDelay 속성 값을 가져야 하는 것은 아닙니다. 각 ASF는 잠금을 획득한 뒤 해제 시점까지 자신에게 구성된 지연 시간을 추가하므로, 서로 다른 값을 사용해도 됩니다. 구성된 *LimiterDelay가 0으로 설정되어 있다면, 해당 ASF 인스턴스는 다른 인스턴스와 공유되는 리소스에 대한 잠금 대기를 완전히 건너뜁니다(다만 서로 간에 공유 잠금 자체는 여전히 유지될 수 있습니다). 그 외 값으로 설정된 경우, ASF는 다른 ASF 인스턴스와 제대로 동기화하여 자신의 차례를 기다린 뒤, 구성된 지연 시간이 지나면 잠금을 해제하여 다른 인스턴스가 계속 진행할 수 있도록 합니다.

ASF는 공유 범위를 결정할 때 WebProxy 설정도 고려합니다. 즉, 서로 다른 WebProxy 설정을 사용하는 두 ASF 인스턴스는 제한 장치(limiter)를 서로 공유하지 않습니다. 이는 서로 다른 네트워크 인터페이스에서 예상되는 대로, WebProxy 설정이 과도한 지연 없이 동작할 수 있도록 하기 위함입니다. 이는 대부분의 사용 사례에는 충분하지만, 예를 들어 요청을 직접 다른 방식으로 라우팅하는 등 특정한 사용자 지정 설정을 사용 중이라면, --network-group **명령줄 인수**를 통해 네트워크 그룹을 직접 지정할 수 있습니다. 이를 통해 해당 인스턴스와 동기화될 ASF 그룹을 직접 선언할 수 있습니다. 사용자 지정 네트워크 그룹은 배타적으로 사용된다는 점을 유의하세요. 즉, 이 경우 ASF는 더 이상 올바른 그룹을 판별하기 위해 WebProxy를 사용하지 않으며, 그룹 지정은 전적으로 사용자의 몫이 됩니다.

위에서 설명한 **systemd 서비스**를 여러 ASF 인스턴스에 활용하고 싶다면 매우 간단합니다. 그저 ArchiSteamFarm@ 서비스 선언에 다른 사용자를 지정하고, 나머지 단계를 그대로 따르면 됩니다. 이는 서로 다른 바이너리로 여러 ASF 인스턴스를 실행하는 것과 동일한 효과를 가지므로, 각각 독립적으로 자동 업데이트되고 동작할 수 있습니다.