-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Management zh TW
本章節涵蓋的相關主題是以最佳方式管理ASF程序。 雖然這並不是強制性的,但它包含了我們想分享的大量提示、技巧與良好實作,特別是對於系統管理員、打包ASF以便於在第三方儲存庫中使用的人、以及進階使用者等人而言。
在generic
及linux
變體版本中,ASF自帶[email protected]
檔案,這是systemd
的服務設定檔。 若您想以服務來執行ASF,例如能在您的設備啟動時自動執行,那麼正確的systemd
服務無疑是最好的方法,因此我們強烈建議經由服務,而不是使用nohup
、screen
或其他方法來管理。
首先,若您還尚未建立用來執行ASF的使用者,請先建立它。 我們在此以asf
使用者作為範例,若您想使用其他的,您就必須將下列範例中的asf
使用者取代成您想使用的使用者名稱。 我們的服務不允許您使用root
來執行ASF,因為這被認為是糟糕的方法。
su # 或是 sudo -i
useradd -m asf
下一步,將ASF解壓縮至/home/asf/ArchiSteamFarm
資料夾中。 資料夾的結構對我們的服務單元來說非常重要,它應在您的$HOME
裡面,也就是說ArchiSteamFarm
資料夾需要放在/home/<使用者名稱>
中。 若您的操作完全正確,則現在應存在/home/asf/ArchiSteamFarm/[email protected]
檔案。 若您使用linux
變體版本,且檔案不在Linux中解壓縮,而是例如從Windows傳輸過來,那麼您需額外執行chmod +x /home/asf/ArchiSteamFarm/ArchiSteamFarm
。
我們將使用root
的身分執行下列操作,所以需使用su
或sudo -i
以獲得Shell。
我們最好先確認資料夾仍屬於asf
使用者,執行一次chown -hR asf:asf /home/asf/ArchiSteamFarm
即可。 因為如果您使用root
來下載並/或解壓縮.zip檔,權限很可能會不正確。
其次,若您使用的是ASF的Generic變體版本,您需要確保dotnet
命令能被辨識,且位於標準位置之一:/usr/local/bin
、/usr/bin
或/bin
。 這是執行dotnet /路徑/至/ArchiSteamFarm.dll
命令的systemd服務所必需的。 檢查dotnet --info
是否運作,若是,輸入command -v dotnet
以找出它的所在位置。 若您使用官方安裝程式,它應位於/usr/bin/dotnet
或其餘兩個位置之一,這樣是沒問題的。 若它位於自訂位置,例如/usr/share/dotnet/dotnet
,使用ln -s "$(command -v dotnet)" /usr/bin/dotnet
來建立一個symlink。 現在command -v dotnet
應該會回報/usr/bin/dotnet
,而這也使我們的systemd單元運作。 若您使用適用於特定作業系統的變體版本,則不需在這方面做任何事情。
接下來,cd /etc/systemd/system
,然後執行ln -s /home/asf/ArchiSteamFarm/ArchiSteamFarm\@.service .
,這將建立一個指向我們服務聲明的符號連結,並於systemd
中註冊。 符號連結可以使ASF在更新時,自動更新您的systemd
單元⸺依據您的情形,您可能想要使用上述方式,或使用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/<使用者名稱>/ArchiSteamFarm
二進制檔案的實際位置,以及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)
,代表一切正常。您可以透過例如journalctl -r
來驗證ASF程序已啟動並在執行中,因為ASF預設輸出至控制台,會被systemd
所記錄。 若您滿意現在的設定,就能執行systemctl enable ArchiSteamFarm@asf
命令,告訴systemd
在啟動期間自動啟動您的服務。 這樣就完成了。
若您想停止程序,只需執行systemctl stop ArchiSteamFarm@asf
。 同樣地,若您想要停用ASF自啟動,就執行systemctl disable ArchiSteamFarm@asf
,非常簡單。
請注意,由於我們的systemd
服務沒有啟用標準輸入,故您無法使用一般經由控制台的方式輸入資訊。 透過systemd
執行,等同於指定Headless: true
設定。 若您需要在登入期間提供額外資訊,或更好地管理您的ASF程序,幸運的是,我們能夠建議您使用ASF-ui,可以輕鬆管理您的ASF。
可以為我們的systemd
服務提供額外的環境變數,例如您想要使用自訂的--cryptkey
命令列引數,就要指定ASF_CRYPTKEY
環境變數。
若要提供自訂環境變數,使用mkdir -p /etc/asf
來建立/etc/asf
資料夾(如果不存在)。 我們建議使用chmod 700 /etc/asf
,來確保只有root
使用者能夠存取這些檔案,因為它們可能含有機密屬性,例如ASF_CRYPTKEY
。 然後,編輯/etc/asf/<使用者名稱>
檔案,其中<使用者名稱>
代表您要執行服務的使用者(在上述範例中是asf
,因此是/etc/asf/asf
)。
這個檔案應該含有所有您要提供給程序的環境變數:
# 只宣告您實際所需的變數
ASF_CRYPTKEY="my_super_important_secret_cryptkey"
ASF_NETWORK_GROUP="my_network_group"
# 及其他任何您想要使用的變數
ASF含有邏輯,驗證自身是否以系統管理員(root
)身分執行。 若環境設定正確,ASF程序的任何操作都不需要執行於Root,因此使用Root執行都被視為糟糕的方法。 這代表在Windows上,ASF永遠都不應該使用「以系統管理員身分執行」設定來執行;而在Unix上,ASF應要擁有專用的使用者帳號,或在桌面環境中使用您自己的帳號。
這代表在Windows上,ASF永遠都不應該使用「以系統管理員身分執行」設定來執行;而在Unix上,ASF應要擁有專用的使用者帳號,或在桌面環境中使用您自己的帳號。 若您仍不信邪,請自行想像,如果ASF程序在啟動後立刻執行rm -rf /*
命令,您的設備會怎樣。
這代表您錯誤設定了ASF試圖存取的檔案的權限。 您應使用root
帳號(使用su
或sudo -i
),然後執行chown -hR asf:asf /path/to/ASF
命令更正權限。其中,您需將asf:asf
取代成實際執行ASF的使用者,/path/to/ASF
取代成ASF的實際路徑。 若您使用自訂--path
,讓ASF使用者使用不同的資料夾,您還需為此路徑執行一次上述命令。
完成本操作後,您應該不會再遇到任何與ASF無法寫入自己的檔案類似的問題,因為您剛剛已將ASF所需檔案的擁有者改成實際執行ASF的使用者。
su # 或是 sudo -i
useradd -m asf
chown -hR asf:asf /path/to/ASF
su asf -c /path/to/ASF/ArchiSteamFarm # 或是 sudo -u asf /path/to/ASF/ArchiSteamFarm
這些是手動啟動,但使用我們上述說明的systemd
服務會更加輕鬆。
從V5.2.0.10版本開始,ASF不再阻止您這樣做,而是只顯示一條警告短訊。 但如果有一天由於程式錯誤,使它炸毀了您的整個作業系統,並導致資料完全遺失,那就不要感到驚訝⸺您已被警告過了。
ASF相容於在同一台設備上執行多個程序實例。 實例可以完全獨立,或從同一個二進制檔案衍生(若您需以不同--path
執行,可以使用命令列引數)。
在使用同一個二進制檔案執行多個實例時,請注意,您應該在所有設定裡面停用自動更新,因為它們並沒有同步自動更新相關的資訊。 若您想繼續啟用自動更新,我們建議您使用獨立的實例。但只要您能確保其他所有ASF實例皆已關閉,自動更新仍能正常運作。
ASF會盡量減少與其他ASF實例產生作業系統層面的跨程序通訊。 這包含ASF檢查其他實例的組態設定資料夾,及共用*LimiterDelay
全域設定屬性,來確保執行多個ASF實例不會造成速率限制的問題。 在技術方面,所有平台皆使用我們專屬的ASF自訂機制,在臨時資料夾中建立基於檔案的鎖,在Windows上為C:\Users\<您的使用者名稱>\AppData\Local\Temp\ASF
,而在Unix上為/tmp/ASF
。
執行ASF實例不需要共用相同的*LimiterDelay
屬性,它們可為不同值,因為每個ASF會在獲得鎖後,將自身的設定延遲加入至釋放時間中。 若設定中的*LimiterDelay
設定成0
,ASF實例會完全跳過等待其他實例釋放共用資源的鎖(但仍可能會保有一個共用鎖)。 當設定成其他任意值時,ASF會與其他ASF實例同步並等候輪到自身,然後在達到延遲設定後釋放鎖,使其他實例能夠繼續運作。
ASF在決定共用範圍時會考慮WebProxy
設定,這代表使用不同WebProxy
設定的兩個ASF實例,不會互相共用它們的限制器。 這是為了使WebProxy
設定可以在沒有過多延遲的情形下運作,就像使用不同網路介面所期望的那樣。 對於大多數情形來說這就應該夠了,但是,若您有特殊的自訂設定,例如經由其他方式的路由請求,您可以使用--network-group
命令列引數指定網路群組,使您能夠宣告要與此實例同步的ASF群組。 請注意,自訂網路群組是專用的,也就是說ASF不再依據WebProxy
來判斷群組,因為此時已經是由您自己所管理。
若您想使用我們上述的systemd
服務使用多個實例,這也非常簡單,只需在服務聲明ArchiSteamFarm@
裡面使用另外一個使用者,然後再次進行其餘步驟即可。 這等同於使用不同的二進制檔案執行多個ASF實例,因此它們也能夠自動更新,並彼此獨立運作。