mirror of
https://gitea.com/gitea/docs.git
synced 2026-11-08 02:50:31 +00:00
Add version v28 (#564)
<!-- cloudflare-preview --> Preview: https://pr-564.docs-gitea-com.pages.dev Reviewed-on: https://gitea.com/gitea/docs/pulls/564 Reviewed-by: bircni <[email protected]> Co-authored-by: Lunny Xiao <[email protected]>
This commit is contained in:
Lunny Xiao authored and 
bircni committed
1 parent
deb2f068d4
commit
ba60edbbda
338 files changed
+114457
-47
No files matched your search
@@ -0,0 +1,9 @@
|
||||
{
|
||||
"label": "運維",
|
||||
"position": 30,
|
||||
"link": {
|
||||
"type": "generated-index",
|
||||
"slug": "/administration",
|
||||
"title": "運維"
|
||||
}
|
||||
}
|
||||
+34
@@ -0,0 +1,34 @@
|
||||
---
|
||||
date: "2023-05-23T09:00:00+08:00"
|
||||
slug: adding-legal-pages
|
||||
sidebar_position: 110
|
||||
|
||||
aliases:
|
||||
- /zh-tw/adding-legal-pages
|
||||
---
|
||||
|
||||
# 添加法律頁面
|
||||
|
||||
一些法域（例如歐盟）要求在網站上添加特定的法律頁面（例如隱私政策）。按照以下步驟將它們添加到你的 Gitea 實例中。
|
||||
|
||||
## 獲取頁面
|
||||
|
||||
Gitea 源程式碼附帶了範例頁面，位於 `contrib/service/sample-page` 目錄中。將它們複製到 `custom/public/assets/` 目錄下。例如，如果要添加隱私政策：
|
||||
|
||||
```
|
||||
wget -O /path/to/custom/public/assets/privacy.html https://raw.githubusercontent.com/go-gitea/gitea/main/contrib/service/sample-page/privacy.html.sample
|
||||
```
|
||||
|
||||
現在，你需要編輯該頁面以滿足你的需求。特別是，你必須更改電子電子郵件地址、網址以及與 "Your Gitea Instance" 相關的引用，以匹配你的情況。
|
||||
|
||||
請務必不要放置會暗示 Gitea 專案對你的伺服器負責的一般服務條款或隱私聲明。
|
||||
|
||||
## 使其可見
|
||||
|
||||
建立或追加到 `/path/to/custom/templates/custom/extra_links_footer.tmpl` 文件中：
|
||||
|
||||
```go
|
||||
<a class="item" href="{{AppSubUrl}}/assets/privacy.html">隱私政策</a>
|
||||
```
|
||||
|
||||
重啟 Gitea 以查看更改。
|
||||
+301
@@ -0,0 +1,301 @@
|
||||
---
|
||||
date: "2016-12-01T16:00:00+02:00"
|
||||
slug: "authentication"
|
||||
sidebar_position: 10
|
||||
aliases:
|
||||
- /zh-tw/authentication
|
||||
---
|
||||
|
||||
# 認證
|
||||
|
||||
## 輕量級目錄訪問協議（Lightweight Directory Access Protocol，LDAP）
|
||||
|
||||
透過 BindDN 的 LDAP 和簡單認證方式 LDAP 共享以下欄位:
|
||||
|
||||
- 認證名稱 **(必選)**
|
||||
|
||||
- 分配給新授權方法的名稱。
|
||||
|
||||
- 主機名 **(必選)**
|
||||
|
||||
- LDAP 服務的主機地址.
|
||||
- 例如:`mydomain.com`
|
||||
|
||||
- 端口號 **(必選)**
|
||||
|
||||
- LDAP 服務的端口號.
|
||||
- 例如: LDAP `389`/ LDAPs `636`
|
||||
|
||||
- 安全協議 (可選)
|
||||
|
||||
- 連接 LDAP 伺服器時是否使用 TLS 協議。
|
||||
|
||||
- 管理員過濾規則 (可選)
|
||||
|
||||
- 一個 LDAP 過濾器，用於指定哪些使用者應該被賦予管理員特權。如果使用者帳戶符合過濾器條件，則該使用者將被授予管理員權限。
|
||||
- 範例:`(objectClass=adminAccount)`
|
||||
- 適用於 Microsoft Active Directory（AD）的範例:`memberOf=CN=admin-group,OU=example,DC=example,DC=org`
|
||||
|
||||
- 使用者名稱屬性（可選）
|
||||
|
||||
- 使用者 LDAP 記錄中包含使用者名稱稱的屬性。在第一次成功登入後，將使用指定的屬性值作為新的 Gitea 帳號名稱。若留空，則使用登入表單上提供的使用者名稱。
|
||||
- 當提供的登入名與多個屬性匹配時，這一選項非常有用，但是隻有一個特定屬性應該用於 Gitea 帳號名稱，請參閱"使用者過濾器"。
|
||||
- 範例:uid
|
||||
- 適用於 Microsoft Active Directory（AD）的範例:`sAMAccountName`
|
||||
|
||||
- 名字屬性（可選）
|
||||
|
||||
- 使用者 LDAP 記錄中包含使用者名稱字的屬性。將用於填充他們的帳號資訊。
|
||||
- 範例:givenName
|
||||
|
||||
- 姓氏屬性（可選）
|
||||
|
||||
- 使用者 LDAP 記錄中包含使用者姓氏的屬性。將用於填充他們的帳號資訊。
|
||||
- 範例:`sn`
|
||||
|
||||
- 電子郵件屬性 **(必選)**
|
||||
- 使用者 LDAP 記錄中包含使用者電子電子郵件地址的屬性。將用於填充他們的帳號資訊。
|
||||
- 範例:`mail`
|
||||
|
||||
### LDAP(via BindDN)
|
||||
|
||||
需要額外設定以下欄位:
|
||||
|
||||
- 綁定 DN (可選)
|
||||
|
||||
- 搜索使用者時綁定到 LDAP 伺服器的 DN。這可以留空以執行匿名搜索。
|
||||
- 範例: `cn=Search,dc=mydomain,dc=com`
|
||||
|
||||
- 綁定密碼 (可選)
|
||||
|
||||
- 上述指定的 Bind DN（綁定區別名）的密碼，如果有的話。注意：該密碼在伺服器上使用 SECRET_KEY 進行加密儲存。仍然建議確保 Bind DN 具有儘可能少的權限。
|
||||
|
||||
- 使用者搜索基準 **(必選)**
|
||||
|
||||
- 這是用於搜索使用者帳戶的 LDAP 基礎路徑.
|
||||
- 範例: `ou=Users,dc=mydomain,dc=com`
|
||||
|
||||
- 使用者過濾規則 **(必選)**
|
||||
- LDAP 過濾器聲明如何查找試圖進行身份驗證的使用者記錄
|
||||
`%[1]s`匹配參數將替換為登入表單中給出的登入名
|
||||
- 範例: `(&(objectClass=posixAccount)(|(uid=%[1]s)(mail=%[1]s)))`
|
||||
- 範例 for Microsoft Active Directory (AD): `(&(objectCategory=Person)(memberOf=CN=user-group,OU=example,DC=example,DC=org)(sAMAccountName=%s)(!(UserAccountControl:1.2.840.113556.1.4.803:=2)))`
|
||||
- 如需多次替換，應使用 `%[1]s`，例如在將提供的登入名與多個屬性（如使用者標識符、電子郵件甚至電話號碼）進行匹配時。
|
||||
- 範例: `(&(objectClass=Person)(|(uid=%[1]s)(mail=%[1]s)(mobile=%[1]s)))`
|
||||
- 啟用使用者同步
|
||||
- 這個選項啟用了一個週期性任務，用於將 Gitea 使用者與 LDAP 伺服器進行同步。預設的同步週期是每 24 小時，
|
||||
但您可以在 app.ini 文件中進行更改。
|
||||
有關此部分的詳細說明，請參閱[sample
|
||||
app.ini](https://github.com/go-gitea/gitea/blob/main/custom/conf/app.example.ini)
|
||||
的*cron.sync_external_users* 部分的註釋。前面提到的*User Search Base*和*User Filter*
|
||||
設定將限制哪些使用者可以使用 Gitea 以及哪些使用者將被同步。
|
||||
在初始運行任務時，將根據給定的設定建立所有與 LDAP 匹配的使用者，因此在使用大型企業 LDAP 目錄時需要小心。
|
||||
|
||||
### LDAP(simple auth)
|
||||
|
||||
需要額外設定以下欄位:
|
||||
|
||||
- 使用者 DN **(必選)**
|
||||
|
||||
- 用作使用者 DN 的模板。匹配參數 `%s` 將替換為登入表單中的登入名。
|
||||
- 範例: `cn=%s,ou=Users,dc=mydomain,dc=com`
|
||||
- 範例: `uid=%s,ou=Users,dc=mydomain,dc=com`
|
||||
|
||||
- 使用者搜索基準 (可選)
|
||||
|
||||
- 使用者搜索基準聲明哪些使用者帳戶將被搜索.
|
||||
- 範例: `ou=Users,dc=mydomain,dc=com`
|
||||
|
||||
- 使用者過濾規則 **(必選)**
|
||||
- LDAP 過濾器聲明何時允許使用者登入
|
||||
`%[1]s`匹配參數將替換為登入表單中給出的登入名。
|
||||
- 範例: `(&(objectClass=posixAccount)(|(cn=%[1]s)(mail=%[1]s)))`
|
||||
- 範例: `(&(objectClass=posixAccount)(|(uid=%[1]s)(mail=%[1]s)))`
|
||||
|
||||
### 使用 LDAP 驗證分組成員
|
||||
|
||||
使用以下欄位:
|
||||
|
||||
- 群組搜索基礎 DN(可選)
|
||||
|
||||
- 組使用的 LDAP DN。
|
||||
- 範例: `ou=group,dc=mydomain,dc=com`
|
||||
|
||||
- 組名過濾器 (可選)
|
||||
|
||||
- LDAP 過濾器，聲明如何在上述 DN 中查找有效組。
|
||||
- 範例: `(|(cn=gitea_users)(cn=admins))`
|
||||
|
||||
- 組中的使用者屬性 (可選)
|
||||
|
||||
- 組中列出了哪個使用者的 LDAP 屬性。
|
||||
- 範例: `uid`
|
||||
|
||||
- 使用者組屬性 (可選)
|
||||
- 哪個組的 LDAP 屬性包含一個高於使用者屬性名稱的數組。
|
||||
- 範例: `memberUid`
|
||||
|
||||
## 可插拔式認證模組(Pluggable Authentication Module,PAM)
|
||||
|
||||
這個過程啟用了 PAM（Pluggable Authentication Modules）認證。使用者仍然可以透過使用者管理手動添加到系統中。
|
||||
PAM 提供了一種機制，通過對使用者進行 PAM 認證來自動將其添加到當前資料庫中。為了與普通的 Linux 密碼一起使用，
|
||||
運行 Gitea 的使用者還必須具有對`/etc/shadow`的讀取權限，以便在使用公鑰登入時檢查帳號的有效性。
|
||||
|
||||
**注意**:如果使用者已將 SSH 公鑰添加到 Gitea 中，使用這些密鑰可能會繞過登入檢查系統。因此，
|
||||
如果您希望禁用使用 PAM 進行身份驗證的使用者，應該在 Gitea 中手動禁用該帳號，使用內置的使用者管理功能。
|
||||
|
||||
1. 設定和安裝準備.
|
||||
- 建議您建立一個管理使用者.
|
||||
- 建議取消自動註冊.
|
||||
1. 一旦資料庫已初始化完成，使用新建立的管理員帳號登入.
|
||||
1. 導航至使用者設定（右上角的圖標），然後選擇
|
||||
`Site Administration` -> `Authentication Sources`, 並選擇
|
||||
`Add Authentication Source`.
|
||||
1. 填寫欄位如下:
|
||||
- 認證類型:`PAM`。
|
||||
- 名稱:任何有效的值都可以，如果您願意，可以使用"System Authentication"。
|
||||
- PAM 服務名稱:從/etc/pam.d/目錄下選擇適用於所需認證的正確文件[^1]。
|
||||
- PAM 電子郵件域:使用者認證時要附加的電子郵件後綴。例如，如果登入系統期望一個名為 gituse 的使用者，
|
||||
並且將此欄位設定為 mail.com，那麼 Gitea 在驗證一個 GIT 實例的使用者時將期望 user emai 欄位為gituser@mail.com[^2]。
|
||||
|
||||
**Note**: PAM 支援通過[build-time flags](installation/from-source.md)添加,
|
||||
而官方提供的二進制文件通常不會預設啟用此功能。PAM 需要確保系統上有必要的 libpam 動態庫，並且編譯器可以訪問必要的 PAM 開發頭文件。
|
||||
|
||||
[^1]:
|
||||
例如，在 Debian "Bullseye"上使用標準 Linux 登入，可以使用`common-session-noninteractive`。這個值對於其他版本的 Debian，
|
||||
包括 Ubuntu 和 Mint，可能也是有效的，請查閱您所使用發行版的文件以確認。
|
||||
|
||||
[^2]: **PAM 的必選項** 請注意:在上面的範例中，使用者將作為`gituser`而不是`[email protected]`登入到 Gitea 的 Web 介面。
|
||||
|
||||
## 簡單郵件傳輸協議(Simple Mail Transfer Protocol,SMTP)
|
||||
|
||||
此選項允許 Gitea 以 Gitea 使用者身份登入 SMTP 主機。請設定以下欄位:
|
||||
|
||||
- 身份驗證名稱 **(必選)**
|
||||
|
||||
- 分配給新授權方法的名稱
|
||||
|
||||
- SMTP 驗證類型 **(必選)**
|
||||
|
||||
- 用於連接 SMTP 主機的驗證類型，plain 或 login
|
||||
|
||||
- 主機名 **(必選)**
|
||||
|
||||
- SMTP 服務的主機地址
|
||||
- 例如:`smtp.mydomain.com`
|
||||
|
||||
- 端口號 **(必選)**
|
||||
|
||||
- SMTP 服務的端口號
|
||||
- 例如: `587`
|
||||
|
||||
- 允許的域名
|
||||
|
||||
- 如果使用公共 SMTP 主機或有多個域的 SMTP 主機，限制哪些域可以登入
|
||||
限制哪些域可以登入。
|
||||
- 範例: `gitea.com,mydomain.com,mydomain2.com`
|
||||
|
||||
- 強制使用 SMTPS
|
||||
- 預設情況下將使用 SMTPS 連接到端口 465.如果您希望將 smtp 用於其他端口，自行設定
|
||||
- 否則，如果伺服器提供' STARTTLS '擴展名，則將使用此擴展名
|
||||
- 跳過 TLS 驗證
|
||||
- 禁用 TLS 驗證身份.
|
||||
- 該認證源處於激活狀態
|
||||
- 啟用或禁用此身份驗證源
|
||||
|
||||
## FreeIPA
|
||||
|
||||
- 要使用 FreeIPA 憑據登入 Gitea，需要為 Gitea 建立一個綁定帳戶。
|
||||
建立一個綁定帳戶:
|
||||
- 在 FreeIPA 伺服器上建立一個 gitea.ldif 文件，並將`dc=example,dc=com`替換為您的`dn`，然後提供一個適當安全的密碼。
|
||||
|
||||
```sh
|
||||
dn: uid=gitea,cn=sysaccounts,cn=etc,dc=example,dc=com
|
||||
changetype: add
|
||||
objectclass: account
|
||||
objectclass: simplesecurityobject
|
||||
uid: gitea
|
||||
userPassword: secure password
|
||||
passwordExpirationTime: 20380119031407Z
|
||||
nsIdleTimeout: 0
|
||||
```
|
||||
|
||||
- 導入 LDIF 文件（如果需要，請將 localhost 更改為 IPA 伺服器）。系統會提示您輸入 Directory Manager 的密碼。:
|
||||
|
||||
```sh
|
||||
ldapmodify -h localhost -p 389 -x -D \
|
||||
"cn=Directory Manager" -W -f gitea.ldif
|
||||
```
|
||||
|
||||
- 為`gitea_users`添加 IPA 組:
|
||||
|
||||
```sh
|
||||
ipa group-add --desc="Gitea Users" gitea_users
|
||||
```
|
||||
|
||||
- **提示**:對於 IPA 憑證錯誤，運行' kinit admin '並提供域管理帳戶密碼.
|
||||
- 以管理員身份登入 Gitea，點擊 Admin Panel 下的`Authentication`。然後單擊`Add New Source`並填寫詳細資訊，更改所有適當的地方。
|
||||
|
||||
## SPNEGO with SSPI (Kerberos/NTLM, for Windows only)
|
||||
|
||||
Gitea 支援通過 Windows 內置的安全支援提供程式介面（Security Support Provider Interface，SSPI）實現 SPNEGO 單點登入認證（由 RFC4559 定義的方案），用於伺服器的 Web 部分。SSPI 僅在 Windows 環境中工作，即當伺服器和客戶端都在 Windows 操作系統上運行時。
|
||||
|
||||
在激活 SSPI 單點登入認證（SSO）之前，您需要準備您的環境:
|
||||
|
||||
- 在 Active Directory 中建立一個單獨的使用者帳號，gitea.exe 進程將在該帳號下運行（例如，在 domain.local 域下建立一個名為 user 的帳號:
|
||||
- 為運行 gitea.exe 的主機建立一個服務主體名稱（Service Principal Name，SPN），其類別為 HTTP:
|
||||
|
||||
- 以特權域使用者（例如域管理員）的身份啟動“命令提示符”或“PowerShell”。
|
||||
- 運行下面的命令，將 host.domain.local 替換為 Web 應用程式將運行的伺服器的完全限定域名（FQDN），將 domain\user 替換為在前一步中建立的帳號名稱:
|
||||
|
||||
```sh
|
||||
setspn -A HTTP/host.domain.local domain\user
|
||||
```
|
||||
|
||||
在遵循上述步驟之前，請確保您按照以下流程進行操作:
|
||||
|
||||
1. 用之前建立的使用者登入（如果已經登入，請先註銷）。
|
||||
2. 確保在`custom/conf/app.ini`文件的`[server]`部分中，`ROOT_URL`設定為 Web 應用程式將運行的伺服器的完全限定域名（FQDN），與之前建立服務主體名稱時使用的一致（例如，`host.domain.local`）。
|
||||
3. 啟動 Web 伺服器（運行 `gitea.exe web`）。
|
||||
4. 在 `Site Administration -> Authentication Sources` 中添加一個 `SPNEGO with SSPI` 認證源，以啟用 SSPI 認證。
|
||||
5. 在域中的客戶端計算機上，使用任何域使用者登入（與運行`gitea.exe`的伺服器不同）。
|
||||
6. 如果您使用 Chrome 或 Edge 瀏覽器，請將 Web 應用程式的 URL 添加到“本地站點”（`Internet選項 -> 安全 -> 本地站點 -> 站點`）。
|
||||
7. 啟動 Chrome 或 Edge 瀏覽器，導航到 Gitea 的 FQDN URL（例如，`http://host.domain.local:3000`）。
|
||||
8. 在控制面板中點擊“Sign In”按鈕，然後選擇 SSPI，將會自動使用當前登入到計算機的使用者進行登入。
|
||||
9. 如果無法正常工作，請確保:
|
||||
- 您不是在運行`gitea.exe`的同一臺伺服器上運行 Web 瀏覽器。應該在與伺服器不同的域加入計算機（客戶端）上運行 Web 瀏覽器。如果客戶端和伺服器都在同一臺計算機上運行，則 NTLM 將優先於 Kerberos。
|
||||
- 主機上只有一個`HTTP/...`的 SPN。
|
||||
- SPN 中只包含主機名，不包含端口號。
|
||||
- 將 Web 應用程式的 URL 添加到"本地站點"。
|
||||
- 伺服器和客戶端的時鐘差異不超過 5 分鐘（取決於組策略）。
|
||||
- 在 Internet Explorer 中啟用了"整合 Windows 身份驗證"（在"高級設定"下）。
|
||||
|
||||
遵循這些步驟，您應該能夠成功啟用和使用 SSPI 單點登入認證（SSO）。
|
||||
|
||||
## 反向代理認證
|
||||
|
||||
Gitea 支援通過讀取反向代理傳遞的 HTTP 頭中的登入名或者 email 地址來支援反向代理來認證。預設是不啟用的，你可以用以下設定啟用。
|
||||
|
||||
```ini
|
||||
[service]
|
||||
ENABLE_REVERSE_PROXY_AUTHENTICATION = true
|
||||
```
|
||||
|
||||
預設的登入使用者名稱的 HTTP 頭是 `X-WEBAUTH-USER`，你可以透過修改 `REVERSE_PROXY_AUTHENTICATION_USER` 來變更它。如果使用者不存在，可以自動建立使用者，當然你需要修改 `ENABLE_REVERSE_PROXY_AUTO_REGISTRATION=true` 來啟用它。
|
||||
|
||||
預設的登入使用者 Email 的 HTTP 頭是 `X-WEBAUTH-EMAIL`，你可以透過修改 `REVERSE_PROXY_AUTHENTICATION_EMAIL` 來變更它。如果使用者不存在，可以自動建立使用者，當然你需要修改 `ENABLE_REVERSE_PROXY_AUTO_REGISTRATION=true` 來啟用它。你也可以透過修改 `ENABLE_REVERSE_PROXY_EMAIL` 來啟用或停用這個 HTTP 頭。
|
||||
|
||||
如果設定了 `ENABLE_REVERSE_PROXY_FULL_NAME=true`，則使用者的全名會從 `X-WEBAUTH-FULLNAME` 讀取，這樣在自動建立使用者時將使用這個欄位作為使用者全名，你也可以透過修改 `REVERSE_PROXY_AUTHENTICATION_FULL_NAME` 來變更 HTTP 頭。
|
||||
|
||||
你也可以透過修改 `REVERSE_PROXY_TRUSTED_PROXIES` 來設定反向代理的 IP 地址範圍，加強安全性，預設值是 `127.0.0.0/8,::1/128`。 通過 `REVERSE_PROXY_LIMIT`， 可以設定最多信任幾級反向代理。
|
||||
|
||||
你可以透過以下設定為 API 啟用此認證方法：
|
||||
|
||||
```ini
|
||||
[service]
|
||||
ENABLE_REVERSE_PROXY_AUTHENTICATION_API = true
|
||||
```
|
||||
|
||||
:::note
|
||||
當此方法用於 API 時，反向代理負責處理 CSRF 保護。
|
||||
:::
|
||||
+146
@@ -0,0 +1,146 @@
|
||||
---
|
||||
date: "2018-06-06T09:33:00+08:00"
|
||||
slug: "backup-and-restore"
|
||||
sidebar_position: 11
|
||||
|
||||
aliases:
|
||||
- /zh-tw/backup-and-restore
|
||||
---
|
||||
|
||||
# 備份與恢復
|
||||
|
||||
Gitea 已經實現了 `dump` 命令可以用來備份所有需要的文件到一個 zip 壓縮文件。該壓縮文件可以被用來進行資料恢復。
|
||||
|
||||
## 備份一致性
|
||||
|
||||
為了確保 Gitea 實例的一致性，在備份期間必須關閉它。
|
||||
|
||||
Gitea 包括資料庫、文件和 Git 儲存庫，當它被使用時所有這些都會發生變化。例如，當遷移正在進行時，在資料庫中建立一個事務，而 Git 儲存庫正在被複制。如果備份發生在遷移的中間，Git 儲存庫可能是不完整的，儘管資料庫聲稱它是完整的，因為它是在之後被轉儲的。避免這種競爭條件的唯一方法是在備份期間停止 Gitea 實例。
|
||||
|
||||
## 備份命令 (`dump`)
|
||||
|
||||
先轉到 git 使用者的權限: `su git`. 再 Gitea 目錄運行 `./gitea dump`。一般會顯示類似如下的輸出：
|
||||
|
||||
```
|
||||
2016/12/27 22:32:09 Creating tmp work dir: /tmp/gitea-dump-417443001
|
||||
2016/12/27 22:32:09 Dumping local repositories.../home/git/repositories
|
||||
2016/12/27 22:32:22 Dumping database...
|
||||
2016/12/27 22:32:22 Packing dump files...
|
||||
2016/12/27 22:32:34 Removing tmp work dir: /tmp/gitea-dump-417443001
|
||||
2016/12/27 22:32:34 Finish dumping in file gitea-dump-1482906742.zip
|
||||
```
|
||||
|
||||
最後生成的 `gitea-dump-1482906742.zip` 文件將會包含如下內容：
|
||||
|
||||
- `app.ini` - 如果原先儲存在預設的 custom/ 目錄之外，則是設定文件的可選副本
|
||||
- `custom/` - 所有保存在 `custom/` 目錄下的設定和自訂的文件。
|
||||
- `data/` - 資料目錄（APP_DATA_PATH），如果使用文件會話，則不包括會話。該目錄包括 `attachments`、`avatars`、`lfs`、`indexers`、如果使用 SQLite 則包括 SQLite 文件。
|
||||
- `repos/` - 儲存庫目錄的完整副本。
|
||||
- `gitea-db.sql` - 資料庫 dump 出來的 SQL。
|
||||
- `log/` - Logs 文件，如果用作遷移不是必須的。
|
||||
|
||||
中間備份文件將會在臨時目錄進行建立，如果您要重新指定臨時目錄，可以用 `--tempdir` 參數，或者用 `TMPDIR` 環境變量。
|
||||
|
||||
## 備份資料庫
|
||||
|
||||
`gitea dump` 建立的 SQL 轉儲使用 XORM，Gitea 管理員可能更喜歡使用本地的 MySQL 和 PostgreSQL 轉儲工具。使用 XORM 轉儲資料庫時仍然存在一些問題，可能會導致在嘗試恢復時出現問題。
|
||||
|
||||
```sh
|
||||
# mysql
|
||||
mysqldump -u$USER -p$PASS --database $DATABASE > gitea-db.sql
|
||||
# postgres
|
||||
pg_dump -U $USER $DATABASE > gitea-db.sql
|
||||
```
|
||||
|
||||
### 使用 Docker （`dump`）
|
||||
|
||||
在使用 Docker 時，使用 `dump` 命令有一些注意事項。
|
||||
|
||||
必須以 `gitea/conf/app.ini` 中指定的 `RUN_USER = <OS_USERNAME>` 執行該命令；並且，為了讓備份文件夾的壓縮過程能夠順利執行，`docker exec` 命令必須在 `--tempdir` 內部執行。
|
||||
|
||||
範例：
|
||||
|
||||
```none
|
||||
docker exec -u <OS_USERNAME> -it -w <--tempdir> $(docker ps -qf 'name=^<NAME_OF_DOCKER_CONTAINER>$') bash -c '/usr/local/bin/gitea dump -c </path/to/app.ini>'
|
||||
```
|
||||
|
||||
\*注意：`--tempdir` 指的是 Gitea 使用的 Docker 環境的臨時目錄；如果您沒有指定自訂的 `--tempdir`，那麼 Gitea 將使用 `/tmp` 或 Docker 容器的 `TMPDIR` 環境變量。對於 `--tempdir`，請相應調整您的 `docker exec` 命令選項。
|
||||
|
||||
結果應該是一個文件，儲存在指定的 `--tempdir` 中，類似於：`gitea-dump-1482906742.zip`
|
||||
|
||||
## 恢復命令 (`restore`)
|
||||
|
||||
當前還沒有恢復命令，恢復需要人工進行。主要是把文件和資料庫進行恢復。
|
||||
|
||||
例如：
|
||||
|
||||
```sh
|
||||
unzip gitea-dump-1610949662.zip
|
||||
cd gitea-dump-1610949662
|
||||
mv app.ini /etc/gitea/conf/app.ini
|
||||
mv data/* /var/lib/gitea/data/
|
||||
mv log/* /var/lib/gitea/log/
|
||||
mv repos/* /var/lib/gitea/repositories/
|
||||
chown -R gitea:gitea /etc/gitea/conf/app.ini /var/lib/gitea
|
||||
|
||||
# mysql
|
||||
mysql --default-character-set=utf8mb4 -u$USER -p$PASS $DATABASE <gitea-db.sql
|
||||
# sqlite3
|
||||
sqlite3 $DATABASE_PATH <gitea-db.sql
|
||||
# postgres
|
||||
psql -U $USER -d $DATABASE < gitea-db.sql
|
||||
|
||||
service gitea restart
|
||||
```
|
||||
|
||||
如果安裝方式發生了變化（例如 二進制 -> Docker），或者 Gitea 安裝到了與之前安裝不同的目錄，則需要重新生成儲存庫 Git 鉤子。
|
||||
|
||||
在 Gitea 運行時，並從 Gitea 二進制文件所在的目錄執行：`./gitea admin regenerate hooks`
|
||||
|
||||
這樣可以確保儲存庫 Git 鉤子中的應用程式和設定文件路徑與當前安裝一致。如果這些路徑沒有更新，儲存庫的 `push` 操作將失敗。
|
||||
|
||||
### 使用 Docker (`restore`)
|
||||
|
||||
在基於 Docker 的 Gitea 實例中，也沒有恢復命令的支援。恢復過程與前面描述的步驟相同，但路徑不同。
|
||||
|
||||
範例：
|
||||
|
||||
```sh
|
||||
# 在容器中打開 bash 會話
|
||||
docker exec --user git -it 2a83b293548e bash
|
||||
# 在容器內解壓您的備份文件
|
||||
unzip gitea-dump-1610949662.zip
|
||||
cd gitea-dump-1610949662
|
||||
# 恢復 Gitea 數據
|
||||
mv data/* /data/gitea
|
||||
# 恢復倉庫本身
|
||||
mv repos/* /data/git/repositories/
|
||||
# 調整文件權限
|
||||
chown -R git:git /data
|
||||
# 重新生成 Git 鉤子
|
||||
/usr/local/bin/gitea -c '/data/gitea/conf/app.ini' admin regenerate hooks
|
||||
```
|
||||
|
||||
Gitea 容器中的預設使用者是 `git`（1000:1000）。請用您的 Gitea 容器 ID 或名稱替換 `2a83b293548e`。
|
||||
|
||||
### 使用 Docker-rootless (`restore`)
|
||||
|
||||
在 Docker-rootless 容器中的恢復工作流程只是要使用的目錄不同：
|
||||
|
||||
```sh
|
||||
# 在容器中打開 bash 會話
|
||||
docker exec --user git -it 2a83b293548e bash
|
||||
# 在容器內解壓您的備份文件
|
||||
unzip gitea-dump-1610949662.zip
|
||||
cd gitea-dump-1610949662
|
||||
# 恢復 app.ini
|
||||
mv data/conf/app.ini /etc/gitea/app.ini
|
||||
# 恢復 Gitea 數據
|
||||
mv data/* /var/lib/gitea
|
||||
# 恢復倉庫本身
|
||||
mv repos/* /var/lib/gitea/git/repositories
|
||||
# 調整文件權限
|
||||
chown -R git:git /etc/gitea/app.ini /var/lib/gitea
|
||||
# 重新生成 Git 鉤子
|
||||
/usr/local/bin/gitea -c '/etc/gitea/app.ini' admin regenerate hooks
|
||||
```
|
||||
@@ -0,0 +1,93 @@
|
||||
---
|
||||
date: "2023-05-23T09:00:00+08:00"
|
||||
slug: "cmd-embedded"
|
||||
sidebar_position: 20
|
||||
|
||||
aliases:
|
||||
- /zh-tw/cmd-embedded
|
||||
---
|
||||
|
||||
# 嵌入資源提取工具
|
||||
|
||||
Gitea 的可執行文件包含了運行所需的所有資源：模板、圖片、樣式表和翻譯文件。你可以透過在 `custom` 目錄下的相應路徑中放置替換文件來覆蓋其中的任何資源（詳見 [自訂 Gitea 設定](../administration/customizing-gitea.md)）。
|
||||
|
||||
要獲取嵌入資源的副本以進行編輯，可以使用 CLI 中的 `embedded` 命令，通過操作系統的 shell 執行。
|
||||
|
||||
**注意：** 嵌入資源提取工具包含在 Gitea 1.12 及以上版本中。
|
||||
|
||||
## 資源列表
|
||||
|
||||
要列出嵌入在 Gitea 可執行文件中的資源，請使用以下語法：
|
||||
|
||||
```sh
|
||||
gitea embedded list [--include-vendored] [patterns...]
|
||||
```
|
||||
|
||||
`--include-vendored` 標誌使命令包括被供應的文件，這些文件通常被排除在外；即來自外部庫的文件，這些文件是 Gitea 所需的（例如 [octicons](https://octicons.github.com/) 等）。
|
||||
|
||||
可以提供一系列文件搜索模式。Gitea 使用 [gobwas/glob](https://github.com/gobwas/glob) 作為其 glob 語法。以下是一些範例：
|
||||
|
||||
- 列出所有模板文件，無論在哪個虛擬目錄下：`**.tmpl`
|
||||
- 列出所有郵件模板文件：`templates/mail/**.tmpl`
|
||||
列出 `public/assets/img` 目錄下的所有文件：`public/assets/img/**`
|
||||
|
||||
不要忘記為模式使用引號，因為空格、`*` 和其他字符可能對命令行解釋器有特殊含義。
|
||||
|
||||
如果未提供模式，則列出所有文件。
|
||||
|
||||
### 範例：列出所有嵌入文件
|
||||
|
||||
列出所有路徑中包含 `openid` 的嵌入文件：
|
||||
|
||||
```sh
|
||||
$ gitea embedded list '**openid**'
|
||||
public/assets/img/auth/openid_connect.svg
|
||||
public/assets/img/openid-16x16.png
|
||||
templates/user/auth/finalize_openid.tmpl
|
||||
templates/user/auth/signin_openid.tmpl
|
||||
templates/user/auth/signup_openid_connect.tmpl
|
||||
templates/user/auth/signup_openid_navbar.tmpl
|
||||
templates/user/auth/signup_openid_register.tmpl
|
||||
templates/user/settings/security_openid.tmpl
|
||||
```
|
||||
|
||||
## 提取資源
|
||||
|
||||
要提取嵌入在 Gitea 可執行文件中的資源，請使用以下語法：
|
||||
|
||||
```sh
|
||||
gitea [--config {file}] embedded extract [--destination {dir}|--custom] [--overwrite|--rename] [--include-vendored] {patterns...}
|
||||
```
|
||||
|
||||
`--config` 選項用於告知 Gitea `app.ini` 設定文件的位置（如果不在預設位置）。此選項僅在使用 `--custom` 標誌時使用。
|
||||
|
||||
`--destination` 選項用於指定提取文件的目標目錄。預設為當前目錄。
|
||||
|
||||
`--custom` 標誌告知 Gitea 直接將文件提取到 `custom` 目錄中。為使其正常工作，該命令需要知道 `app.ini` 設定文件的位置（通過 `--config` 指定），並且根據設定的不同，需要從 Gitea 通常啟動的目錄運行。有關詳細資訊，請參閱 [自訂 Gitea 設定](../administration/customizing-gitea.md)。
|
||||
|
||||
`--overwrite` 標誌允許覆蓋目標目錄中的任何現有文件。
|
||||
|
||||
`--rename` 標誌告知 Gitea 將目標目錄中的任何現有文件重命名為 `filename.bak`。之前的 `.bak` 文件將被覆蓋。
|
||||
|
||||
至少需要提供一個文件搜索模式；有關模式的語法和範例，請參閱上述 `list` 子命令。
|
||||
|
||||
### 重要提示
|
||||
|
||||
請確保**只提取需要自訂的文件**。位於 `custom` 目錄中的文件不會受到 Gitea 的升級過程的影響。當 Gitea 升級到新版本（通過替換可執行文件）時，許多嵌入文件將發生變化。Gitea 將尊重並使用在 `custom` 目錄中找到的任何文件，即使這些文件是舊的和不相容的。
|
||||
|
||||
### 範例：提取郵件模板
|
||||
|
||||
將郵件模板提取到臨時目錄：
|
||||
|
||||
```sh
|
||||
$ mkdir tempdir
|
||||
$ gitea embedded extract --destination tempdir 'templates/mail/**.tmpl'
|
||||
Extracting to tempdir:
|
||||
tempdir/templates/mail/auth/activate.tmpl
|
||||
tempdir/templates/mail/auth/activate_email.tmpl
|
||||
tempdir/templates/mail/auth/register_notify.tmpl
|
||||
tempdir/templates/mail/auth/reset_passwd.tmpl
|
||||
tempdir/templates/mail/issue/assigned.tmpl
|
||||
tempdir/templates/mail/issue/default.tmpl
|
||||
tempdir/templates/mail/notify/collaborator.tmpl
|
||||
```
|
||||
@@ -0,0 +1,534 @@
|
||||
---
|
||||
date: "2023-05-23T09:00:00+08:00"
|
||||
slug: "command-line"
|
||||
sidebar_position: 1
|
||||
|
||||
aliases:
|
||||
- /zh-tw/command-line
|
||||
---
|
||||
|
||||
# 命令行
|
||||
|
||||
## 用法
|
||||
|
||||
`gitea [全域選項] 命令 [命令或全域選項] [參數...]`
|
||||
|
||||
## 全域選項
|
||||
|
||||
所有全域選項均可被放置在命令級別。
|
||||
|
||||
- `--help`，`-h`：顯示幫助文本並退出。可選。
|
||||
- `--version`，`-v`：顯示版本資訊並退出。可選。 (範例：`Gitea version 1.1.0+218-g7b907ed built with: bindata, sqlite`)。
|
||||
- `--custom-path path`，`-C path`：Gitea 自訂文件夾的路徑。可選。 (預設值：`AppWorkPath`/custom 或 `$GITEA_CUSTOM`)。
|
||||
- `--config path`，`-c path`：Gitea 設定文件的路徑。可選。 (預設值：`custom`/conf/app.ini)。
|
||||
- `--work-path path`，`-w path`：Gitea 的 `AppWorkPath`。可選。 (預設值：LOCATION_OF_GITEA_BINARY 或 `$GITEA_WORK_DIR`)
|
||||
|
||||
注意：預設的 custom-path、config 和 work-path 也可以在構建時更改（如果需要）。
|
||||
|
||||
## 命令
|
||||
|
||||
### web
|
||||
|
||||
啟動伺服器：
|
||||
|
||||
- 選項：
|
||||
- `--port number`，`-p number`：端口號。可選。 (預設值：3000)。覆蓋設定文件中的設定。
|
||||
- `--install-port number`：運行安裝頁面的端口號。可選。 (預設值：3000)。覆蓋設定文件中的設定。
|
||||
- `--pid path`，`-P path`：Pid 文件的路徑。可選。
|
||||
- `--quiet`，`-q`：只在控制檯上輸出 Fatal 日誌，用於在設定日誌之前發出的日誌。
|
||||
- `--verbose`：在控制檯上輸出跟蹤日誌，用於在設定日誌之前發出的日誌。
|
||||
- 範例：
|
||||
- `gitea web`
|
||||
- `gitea web --port 80`
|
||||
- `gitea web --config /etc/gitea.ini --pid /some/custom/gitea.pid`
|
||||
- 注意：
|
||||
- Gitea 不應以 root 使用者身份運行。要綁定到低於 1024 的端口，您可以在 Linux 上使用 setcap 命令：`sudo setcap 'cap_net_bind_service=+ep' /path/to/gitea`。每次更新 Gitea 都需要重新執行此操作。
|
||||
|
||||
### admin
|
||||
|
||||
管理員操作：
|
||||
|
||||
- 命令：
|
||||
- `user`：
|
||||
- `list`：
|
||||
- 選項：
|
||||
- `--admin`：僅列出管理員使用者。可選。
|
||||
- 描述：列出所有現有使用者。
|
||||
- 範例：
|
||||
- `gitea admin user list`
|
||||
- `delete`：
|
||||
- 選項：
|
||||
- `--email`：要刪除的使用者的電子郵件。
|
||||
- `--username`：要刪除的使用者的使用者名稱。
|
||||
- `--id`：要刪除的使用者的 ID。
|
||||
- 必須提供 `--id`、`--username` 或 `--email` 中的一個。如果提供多個，則所有條件必須匹配。
|
||||
- 範例：
|
||||
- `gitea admin user delete --id 1`
|
||||
- `create`：
|
||||
- 選項：
|
||||
- `--name value`：使用者名稱。必填。自 Gitea 1.9.0 版本起，請改用 `--username` 標誌。
|
||||
- `--username value`：使用者名稱。必填。Gitea 1.9.0 新增。
|
||||
- `--password value`：密碼。必填。
|
||||
- `--email value`：郵箱。必填。
|
||||
- `--admin`：如果提供此選項，將建立一個管理員使用者。可選。
|
||||
- `--access-token`：如果提供，將為使用者建立存取權杖。可選。（預設值：false）。
|
||||
- `--must-change-password`：如果提供，建立的使用者將在初始登入後需要選擇一個新密碼。可選。（預設值：true）。
|
||||
- `--random-password`：如果提供，將使用隨機生成的密碼作為建立使用者的密碼。`--password` 的值將被忽略。可選。
|
||||
- `--random-password-length`：如果提供，將用於設定隨機生成密碼的長度。可選。（預設值：12）
|
||||
- 範例：
|
||||
- `gitea admin user create --username myname --password asecurepassword --email [email protected]`
|
||||
- `change-password`：
|
||||
- 選項：
|
||||
- `--username value`，`-u value`：使用者名稱。必填。
|
||||
- `--password value`，`-p value`：新密碼。必填。
|
||||
- 範例：
|
||||
- `gitea admin user change-password --username myname --password asecurepassword`
|
||||
- `must-change-password`：
|
||||
- 參數：
|
||||
- `[username...]`：需要更改密碼的使用者
|
||||
- 選項：
|
||||
- `--all`，`-A`：強制所有使用者更改密碼
|
||||
- `--exclude username`，`-e username`：排除給定的使用者。可以多次設定。
|
||||
- `--unset`：撤銷對給定使用者的強制密碼更改
|
||||
- `regenerate`：
|
||||
- 選項：
|
||||
- `hooks`：重新生成所有儲存庫的 Git Hooks。
|
||||
- `keys`：重新生成 authorized_keys 文件。
|
||||
- 範例：
|
||||
- `gitea admin regenerate hooks`
|
||||
- `gitea admin regenerate keys`
|
||||
- `auth`：
|
||||
- `list`：
|
||||
- 描述：列出所有存在的外部認證源。
|
||||
- 範例：
|
||||
- `gitea admin auth list`
|
||||
- `delete`：
|
||||
- 選項：
|
||||
- `--id`：要刪除的源的 ID。必填。
|
||||
- 範例：
|
||||
- `gitea admin auth delete --id 1`
|
||||
- `add-oauth`：
|
||||
- 選項：
|
||||
- `--name`：應用程式名稱。
|
||||
- `--provider`：OAuth2 提供者。
|
||||
- `--key`：客戶端 ID（Key）。
|
||||
- `--secret`：客戶端密鑰。
|
||||
- `--auto-discover-url`：OpenID Connect 自動發現 URL（僅在使用 OpenID Connect 作為提供程式時需要）。
|
||||
- `--use-custom-urls`：在 GitLab/GitHub OAuth 端點上使用自訂 URL。
|
||||
- `--custom-tenant-id`：在 OAuth 端點上使用自訂租戶 ID。
|
||||
- `--custom-auth-url`：使用自訂授權 URL（GitLab/GitHub 的選項）。
|
||||
- `--custom-token-url`：使用自訂令牌 URL（GitLab/GitHub 的選項）。
|
||||
- `--custom-profile-url`：使用自訂設定文件 URL（GitLab/GitHub 的選項）。
|
||||
- `--custom-email-url`：使用自訂電子郵件 URL（GitHub 的選項）。
|
||||
- `--icon-url`：OAuth2 登入源的自訂圖標 URL。
|
||||
- `--skip-local-2fa`：允許源覆蓋本地 2FA。（可選）
|
||||
- `--scopes`：請求此 OAuth2 源的附加範圍。（可選）
|
||||
- `--required-claim-name`：必須設定的聲明名稱，以允許使用者使用此源登入。（可選）
|
||||
- `--required-claim-value`：必須設定的聲明值，以允許使用者使用此源登入。（可選）
|
||||
- `--group-claim-name`：提供此源的組名的聲明名稱。（可選）
|
||||
- `--admin-group`：管理員使用者的組聲明值。（可選）
|
||||
- `--restricted-group`：受限使用者的組聲明值。（可選）
|
||||
- `--group-team-map`：組與組織團隊之間的 JSON 映射。（可選）
|
||||
- `--group-team-map-removal`：根據組自動激活團隊成員資格的刪除。（可選）
|
||||
- 範例：
|
||||
- `gitea admin auth add-oauth --name external-github --provider github --key OBTAIN_FROM_SOURCE --secret OBTAIN_FROM_SOURCE`
|
||||
- `update-oauth`：
|
||||
- 選項：
|
||||
- `--id`：要更新的源的 ID。必填。
|
||||
- `--name`：應用程式名稱。
|
||||
- `--provider`：OAuth2 提供者。
|
||||
- `--key`：客戶端 ID（Key）。
|
||||
- `--secret`：客戶端密鑰。
|
||||
- `--auto-discover-url`：OpenID Connect 自動發現 URL（僅在使用 OpenID Connect 作為提供程式時需要）。
|
||||
- `--use-custom-urls`：在 GitLab/GitHub OAuth 端點上使用自訂 URL。
|
||||
- `--custom-tenant-id`：在 OAuth 端點上使用自訂租戶 ID。
|
||||
- `--custom-auth-url`：使用自訂授權 URL（GitLab/GitHub 的選項）。
|
||||
- `--custom-token-url`：使用自訂令牌 URL（GitLab/GitHub 的選項）。
|
||||
- `--custom-profile-url`：使用自訂設定文件 URL（GitLab/GitHub 的選項）。
|
||||
- `--custom-email-url`：使用自訂電子郵件 URL（GitHub 的選項）。
|
||||
- `--icon-url`：OAuth2 登入源的自訂圖標 URL。
|
||||
- `--skip-local-2fa`：允許源覆蓋本地 2FA。（可選）
|
||||
- `--scopes`：請求此 OAuth2 源的附加範圍。
|
||||
- `--required-claim-name`：必須設定的聲明名稱，以允許使用者使用此源登入。（可選）
|
||||
- `--required-claim-value`：必須設定的聲明值，以允許使用者使用此源登入。（可選）
|
||||
- `--group-claim-name`：提供此源的組名的聲明名稱。（可選）
|
||||
- `--admin-group`：管理員使用者的組聲明值。（可選）
|
||||
- `--restricted-group`：受限使用者的組聲明值。（可選）
|
||||
- 範例：
|
||||
- `gitea admin auth update-oauth --id 1 --name external-github-updated`
|
||||
- `add-smtp`：
|
||||
- 選項：
|
||||
- `--name`：應用程式名稱。必填。
|
||||
- `--auth-type`：SMTP 認證類型（PLAIN/LOGIN/CRAM-MD5）。預設為 PLAIN。
|
||||
- `--host`：SMTP 主機。必填。
|
||||
- `--port`：SMTP 端口。必填。
|
||||
- `--force-smtps`：SMTPS 始終在端口 465 上使用。設定此選項以強制在其他端口上使用 SMTPS。
|
||||
- `--skip-verify`：跳過 TLS 驗證。
|
||||
- `--helo-hostname`：發送 HELO 時使用的主機名。留空以發送當前主機名。
|
||||
- `--disable-helo`：禁用 SMTP helo。
|
||||
- `--allowed-domains`：留空以允許所有域。使用逗號（','）分隔多個域。
|
||||
- `--skip-local-2fa`：跳過 2FA 登入。
|
||||
- `--active`：啟用此認證源。
|
||||
備註：
|
||||
`--force-smtps`、`--skip-verify`、`--disable-helo`、`--skip-local-2fs` 和 `--active` 選項可以採用以下形式使用：
|
||||
- `--option`、`--option=true` 以啟用選項
|
||||
- `--option=false` 以禁用選項
|
||||
如果未指定這些選項，則在 `update-smtp` 中不會更改值，或者在 `add-smtp` 中將使用預設的 `false` 值。
|
||||
- 範例：
|
||||
- `gitea admin auth add-smtp --name ldap --host smtp.mydomain.org --port 587 --skip-verify --active`
|
||||
- `update-smtp`：
|
||||
- 選項：
|
||||
- `--id`：要更新的源的 ID。必填。
|
||||
- 其他選項與 `add-smtp` 共享
|
||||
- 範例：
|
||||
- `gitea admin auth update-smtp --id 1 --host smtp.mydomain.org --port 587 --skip-verify=false`
|
||||
- `gitea admin auth update-smtp --id 1 --active=false`
|
||||
- `add-ldap`：添加新的 LDAP（通過 Bind DN）認證源
|
||||
- 選項：
|
||||
- `--name value`：認證名稱。必填。
|
||||
- `--not-active`：停用認證源。
|
||||
- `--security-protocol value`：安全協議名稱。必填。
|
||||
- `--skip-tls-verify`：禁用 TLS 驗證。
|
||||
- `--host value`：LDAP 伺服器的地址。必填。
|
||||
- `--port value`：連接到 LDAP 伺服器時使用的端口。必填。
|
||||
- `--user-search-base value`：使用者帳戶將在其中搜索的 LDAP 基礎路徑。必填。
|
||||
- `--user-filter value`：聲明如何查找試圖進行身份驗證的使用者記錄的 LDAP 過濾器。必填。
|
||||
- `--admin-filter value`：指定是否應授予使用者管理員特權的 LDAP 過濾器。
|
||||
- `--restricted-filter value`：指定是否應將使用者設定為受限狀態的 LDAP 過濾器。
|
||||
- `--username-attribute value`：使用者 LDAP 記錄中包含使用者名稱的屬性。
|
||||
- `--firstname-attribute value`：使用者 LDAP 記錄中包含使用者名稱字的屬性。
|
||||
- `--surname-attribute value`：使用者 LDAP 記錄中包含使用者姓氏的屬性。
|
||||
- `--email-attribute value`：使用者 LDAP 記錄中包含使用者電子電子郵件地址的屬性。必填。
|
||||
- `--public-ssh-key-attribute value`：使用者 LDAP 記錄中包含使用者公共 SSH 密鑰的屬性。
|
||||
- `--avatar-attribute value`：使用者 LDAP 記錄中包含使用者頭像的屬性。
|
||||
- `--bind-dn value`：在搜索使用者時綁定到 LDAP 伺服器的 DN。
|
||||
- `--bind-password value`：綁定 DN 的密碼（如果有）。
|
||||
- `--attributes-in-bind`：在綁定 DN 上下文中獲取屬性。
|
||||
- `--synchronize-users`：啟用使用者同步。
|
||||
- `--page-size value`：搜索頁面大小。
|
||||
- 範例：
|
||||
- `gitea admin auth add-ldap --name ldap --security-protocol unencrypted --host mydomain.org --port 389 --user-search-base "ou=Users,dc=mydomain,dc=org" --user-filter "(&(objectClass=posixAccount)(|(uid=%[1]s)(mail=%[1]s)))" --email-attribute mail`
|
||||
- `update-ldap`：更新現有的 LDAP（通過 Bind DN）認證源
|
||||
- 選項：
|
||||
- `--id value`：認證源的 ID。必填。
|
||||
- `--name value`：認證名稱。
|
||||
- `--not-active`：停用認證源。
|
||||
- `--security-protocol value`：安全協議名稱。
|
||||
- `--skip-tls-verify`：禁用 TLS 驗證。
|
||||
- `--host value`：LDAP 伺服器的地址。
|
||||
- `--port value`：連接到 LDAP 伺服器時使用的端口。
|
||||
- `--user-search-base value`：使用者帳戶將在其中搜索的 LDAP 基礎路徑。
|
||||
- `--user-filter value`：聲明如何查找試圖進行身份驗證的使用者記錄的 LDAP 過濾器。
|
||||
- `--admin-filter value`：指定是否應授予使用者管理員特權的 LDAP 過濾器。
|
||||
- `--restricted-filter value`：指定是否應將使用者設定為受限狀態的 LDAP 過濾器。
|
||||
- `--username-attribute value`：使用者 LDAP 記錄中包含使用者名稱的屬性。
|
||||
- `--firstname-attribute value`：使用者 LDAP 記錄中包含使用者名稱字的屬性。
|
||||
- `--surname-attribute value`：使用者 LDAP 記錄中包含使用者姓氏的屬性。
|
||||
- `--email-attribute value`：使用者 LDAP 記錄中包含使用者電子電子郵件地址的屬性。
|
||||
- `--public-ssh-key-attribute value`：使用者 LDAP 記錄中包含使用者公共 SSH 密鑰的屬性。
|
||||
- `--avatar-attribute value`：使用者 LDAP 記錄中包含使用者頭像的屬性。
|
||||
- `--bind-dn value`：在搜索使用者時綁定到 LDAP 伺服器的 DN。
|
||||
- `--bind-password value`：綁定 DN 的密碼（如果有）。
|
||||
- `--attributes-in-bind`：在綁定 DN 上下文中獲取屬性。
|
||||
- `--synchronize-users`：啟用使用者同步。
|
||||
- `--page-size value`：搜索頁面大小。
|
||||
- 範例：
|
||||
- `gitea admin auth update-ldap --id 1 --name "my ldap auth source"`
|
||||
- `gitea admin auth update-ldap --id 1 --username-attribute uid --firstname-attribute givenName --surname-attribute sn`
|
||||
- `add-ldap-simple`：添加新的 LDAP（簡單身份驗證）認證源
|
||||
- 選項：
|
||||
- `--name value`：認證名稱。必填。
|
||||
- `--not-active`：停用認證源。
|
||||
- `--security-protocol value`：安全協議名稱。必填。
|
||||
- `--skip-tls-verify`：禁用 TLS 驗證。
|
||||
- `--host value`：LDAP 伺服器的地址。必填。
|
||||
- `--port value`：連接到 LDAP 伺服器時使用的端口。必填。
|
||||
- `--user-search-base value`：使用者帳戶將在其中搜索的 LDAP 基礎路徑。
|
||||
- `--user-filter value`：聲明如何查找試圖進行身份驗證的使用者記錄的 LDAP 過濾器。必填。
|
||||
- `--admin-filter value`：指定是否應授予使用者管理員特權的 LDAP 過濾器。
|
||||
- `--restricted-filter value`：指定是否應將使用者設定為受限狀態的 LDAP 過濾器。
|
||||
- `--username-attribute value`：使用者 LDAP 記錄中包含使用者名稱的屬性。
|
||||
- `--firstname-attribute value`：使用者 LDAP 記錄中包含使用者名稱字的屬性。
|
||||
- `--surname-attribute value`：使用者 LDAP 記錄中包含使用者姓氏的屬性。
|
||||
- `--email-attribute value`：使用者 LDAP 記錄中包含使用者電子電子郵件地址的屬性。必填。
|
||||
- `--public-ssh-key-attribute value`：使用者 LDAP 記錄中包含使用者公共 SSH 密鑰的屬性。
|
||||
- `--avatar-attribute value`：使用者 LDAP 記錄中包含使用者頭像的屬性。
|
||||
- `--user-dn value`：使用者的 DN。必填。
|
||||
- 範例：
|
||||
- `gitea admin auth add-ldap-simple --name ldap --security-protocol unencrypted --host mydomain.org --port 389 --user-dn "cn=%s,ou=Users,dc=mydomain,dc=org" --user-filter "(&(objectClass=posixAccount)(cn=%s))" --email-attribute mail`
|
||||
- `update-ldap-simple`：更新現有的 LDAP（簡單身份驗證）認證源
|
||||
- 選項：
|
||||
- `--id value`：認證源的 ID。必填。
|
||||
- `--name value`：認證名稱。
|
||||
- `--not-active`：停用認證源。
|
||||
- `--security-protocol value`：安全協議名稱。
|
||||
- `--skip-tls-verify`：禁用 TLS 驗證。
|
||||
- `--host value`：LDAP 伺服器的地址。
|
||||
- `--port value`：連接到 LDAP 伺服器時使用的端口。
|
||||
- `--user-search-base value`：使用者帳戶將在其中搜索的 LDAP 基礎路徑。
|
||||
- `--user-filter value`：聲明如何查找試圖進行身份驗證的使用者記錄的 LDAP 過濾器。
|
||||
- `--admin-filter value`：指定是否應授予使用者管理員特權的 LDAP 過濾器。
|
||||
- `--restricted-filter value`：指定是否應將使用者設定為受限狀態的 LDAP 過濾器。
|
||||
- `--username-attribute value`：使用者 LDAP 記錄中包含使用者名稱的屬性。
|
||||
- `--firstname-attribute value`：使用者 LDAP 記錄中包含使用者名稱字的屬性。
|
||||
- `--surname-attribute value`：使用者 LDAP 記錄中包含使用者姓氏的屬性。
|
||||
- `--email-attribute value`：使用者 LDAP 記錄中包含使用者電子電子郵件地址的屬性。
|
||||
- `--public-ssh-key-attribute value`：使用者 LDAP 記錄中包含使用者公共 SSH 密鑰的屬性。
|
||||
- `--avatar-attribute value`：使用者 LDAP 記錄中包含使用者頭像的屬性。
|
||||
- `--user-dn value`：使用者的 DN。
|
||||
- 範例：
|
||||
- `gitea admin auth update-ldap-simple --id 1 --name "my ldap auth source"`
|
||||
- `gitea admin auth update-ldap-simple --id 1 --username-attribute uid --firstname-attribute givenName --surname-attribute sn`
|
||||
|
||||
### cert
|
||||
|
||||
生成自簽名的 SSL 證書。將輸出到當前目錄下的`cert.pem`和`key.pem`文件中，並且會覆蓋任何現有文件。
|
||||
|
||||
- 選項：
|
||||
- `--host value`：逗號分隔的主機名和 IP 地址列表，此證書適用於這些主機。支援使用通配符。必填。
|
||||
- `--ecdsa-curve value`：用於生成密鑰的 ECDSA 曲線。可選。有效選項為 P224、P256、P384、P521。
|
||||
- `--rsa-bits value`：要生成的 RSA 密鑰的大小。可選。如果設定了--ecdsa-curve，則忽略此選項。（預設值：3072）。
|
||||
- `--start-date value`：證書的建立日期。可選。（格式：`Jan 1 15:04:05 2011`）。
|
||||
- `--duration value`：證書有效期。可選。（預設值：8760h0m0s）
|
||||
- `--ca`：如果提供此選項，則證書將生成自己的證書頒發機構。可選。
|
||||
- 範例：
|
||||
- `gitea cert --host git.example.com,example.com,www.example.com --ca`
|
||||
|
||||
### dump
|
||||
|
||||
將所有文件和資料庫導出到一個 zip 文件中。輸出文件將保存在當前目錄下，類似於`gitea-dump-1482906742.zip`。
|
||||
|
||||
- 選項：
|
||||
- `--file name`，`-f name`：指定要建立的導出文件的名稱。可選。（預設值：gitea-dump-[timestamp].zip）。
|
||||
- `--tempdir path`，`-t path`：指定臨時目錄的路徑。可選。（預設值：/tmp）。
|
||||
- `--skip-repository`，`-R`：跳過儲存庫的導出。可選。
|
||||
- `--skip-custom-dir`：跳過自訂目錄的導出。可選。
|
||||
- `--skip-lfs-data`：跳過 LFS 資料的導出。可選。
|
||||
- `--skip-attachment-data`：跳過附件資料的導出。可選。
|
||||
- `--skip-package-data`：跳過包資料的導出。可選。
|
||||
- `--skip-log`：跳過日誌資料的導出。可選。
|
||||
- `--database`，`-d`：指定資料庫的 SQL 語法。可選。
|
||||
- `--verbose`，`-V`：如果提供此選項，顯示附加詳細資訊。可選。
|
||||
- `--type`：設定導出的格式。可選。（預設值：zip）
|
||||
- 範例：
|
||||
- `gitea dump`
|
||||
- `gitea dump --verbose`
|
||||
|
||||
### generate
|
||||
|
||||
用於在設定文件中生成隨機值和令牌。對於自動部署時生成值非常有用。
|
||||
|
||||
- 命令:
|
||||
- `secret`:
|
||||
- 選項:
|
||||
- `INTERNAL_TOKEN`: 用於內部 API 調用身份驗證的令牌。
|
||||
- `JWT_SECRET`: 用於 LFS 和 OAUTH2 JWT 身份驗證的密鑰（LFS_JWT_SECRET 是此選項的別名，用於向後相容）。
|
||||
- `SECRET_KEY`: 全域密鑰。
|
||||
- 範例:
|
||||
- `gitea generate secret INTERNAL_TOKEN`
|
||||
- `gitea generate secret JWT_SECRET`
|
||||
- `gitea generate secret SECRET_KEY`
|
||||
|
||||
### keys
|
||||
|
||||
提供一個 SSHD AuthorizedKeysCommand。需要在 sshd 設定文件中進行設定:
|
||||
|
||||
```ini
|
||||
...
|
||||
# -e 的值和 AuthorizedKeysCommandUser 應與運行 Gitea 的用戶名匹配
|
||||
AuthorizedKeysCommandUser git
|
||||
AuthorizedKeysCommand /path/to/gitea keys -e git -u %u -t %t -k %k
|
||||
```
|
||||
|
||||
該命令將返回適用於提供的密鑰的合適 authorized_keys 行。您還應在 `app.ini` 的 `[server]` 部分設定值 `SSH_CREATE_AUTHORIZED_KEYS_FILE=false`。
|
||||
|
||||
注意: opensshd 要求 Gitea 程式由 root 擁有，並且不可由組或其他人寫入。程式必須使用絕對路徑指定。
|
||||
注意: Gitea 必須在運行此命令時處於運行狀態才能成功。
|
||||
|
||||
### migrate
|
||||
|
||||
遷移資料庫。該命令可用於在首次啟動伺服器之前運行其他命令。此命令是冪等的。
|
||||
|
||||
### doctor check
|
||||
|
||||
對 Gitea 實例進行診斷，可以修復一些可修復的問題。
|
||||
預設只運行部分檢查，額外的檢查可以參考：
|
||||
|
||||
- `gitea doctor check --list` - 列出所有可用的檢查
|
||||
- `gitea doctor check --all` - 運行所有可用的檢查
|
||||
- `gitea doctor check --default` - 運行預設的檢查
|
||||
- `gitea doctor check --run [check(s),]...` - 運行指定的名字的檢查
|
||||
|
||||
有些問題可以透過設定 `--fix` 選項進行自動修復。
|
||||
額外的日誌可以透過 `--log-file=...` 進行設定。
|
||||
|
||||
#### doctor recreate-table
|
||||
|
||||
有時，在遷移時，舊的列和預設值可能會在資料庫模式中保持不變。這可能會導致警告，如下所示:
|
||||
|
||||
```
|
||||
2020/08/02 11:32:29 ...rm/session_schema.go:360:Sync() [W] Table user Column keep_activity_private db default is , struct default is 0
|
||||
```
|
||||
|
||||
您可以透過以下方式讓 Gitea 重新建立這些表，並將舊資料複製到新表中，並適當設定預設值：
|
||||
|
||||
```
|
||||
gitea doctor recreate-table user
|
||||
```
|
||||
|
||||
您可以使用以下方式讓 Gitea 重新建立多個表：
|
||||
|
||||
```
|
||||
gitea doctor recreate-table table1 table2 ...
|
||||
```
|
||||
|
||||
如果您希望 Gitea 重新建立所有表，請直接調用：
|
||||
|
||||
```
|
||||
gitea doctor recreate-table
|
||||
```
|
||||
|
||||
強烈建議在運行這些命令之前備份您的資料庫。
|
||||
|
||||
### doctor convert
|
||||
|
||||
將現有的 MySQL 資料庫從 utf8 轉換為 utf8mb4，或者把 MSSQL 資料庫從 varchar 轉換為 nvarchar。
|
||||
|
||||
### manager
|
||||
|
||||
管理運行中的伺服器操作：
|
||||
|
||||
- 命令:
|
||||
- `shutdown`: 優雅地關閉運行中的進程
|
||||
- `restart`: 優雅地重新啟動運行中的進程（對於 Windows 伺服器尚未實現）
|
||||
- `flush-queues`: 刷新運行中的進程中的隊列
|
||||
- 選項:
|
||||
- `--timeout value`: 刷新過程的超時時間（預設值: 1m0s）
|
||||
- `--non-blocking`: 設定為 true，以在返回之前不等待刷新完成
|
||||
- `logging`: 調整日誌命令
|
||||
- 命令:
|
||||
- `pause`: 暫停日誌記錄
|
||||
- 注意:
|
||||
- 如果日誌級別低於此級別，日誌級別將被臨時提升為 INFO。
|
||||
- Gitea 將在一定程度上緩衝日誌，並在超過該點後丟棄日誌。
|
||||
- `resume`: 恢復日誌記錄
|
||||
- `release-and-reopen`: 使 Gitea 釋放和重新打開用於日誌記錄的文件和連接（相當於向 Gitea 發送 SIGUSR1 信號）。
|
||||
- `remove name`: 刪除指定的日誌記錄器
|
||||
- 選項:
|
||||
- `--group group`, `-g group`: 從中刪除子記錄器的組（預設為`default`）
|
||||
- `add`: 添加日誌記錄器
|
||||
- 命令:
|
||||
- `console`: 添加控制檯日誌記錄器
|
||||
- 選項:
|
||||
- `--group value`, `-g value`: 要添加日誌記錄器的組 - 預設為"default"
|
||||
- `--name value`, `-n value`: 新日誌記錄器的名稱 - 預設為模式
|
||||
- `--level value`, `-l value`: 新日誌記錄器的日誌級別
|
||||
- `--stacktrace-level value`, `-L value`: 堆棧跟蹤日誌級別
|
||||
- `--flags value`, `-F value`: 日誌記錄器的標誌
|
||||
- `--expression value`, `-e value`: 日誌記錄器的匹配表達式
|
||||
- `--prefix value`, `-p value`: 日誌記錄器的前綴
|
||||
- `--color`: 在日誌中使用顏色
|
||||
- `--stderr`: 將控制檯日誌輸出到 stderr - 僅適用於控制檯
|
||||
- `file`: 添加文件日誌記錄器
|
||||
- 選項:
|
||||
- `--group value`, `-g value`: 要添加日誌記錄器的組 - 預設為"default"
|
||||
- `--name value`, `-n value`: 新日誌記錄器的名稱 - 預設為模式
|
||||
- `--level value`, `-l value`: 新日誌記錄器的日誌級別
|
||||
- `--stacktrace-level value`, `-L value`: 堆棧跟蹤日誌級別
|
||||
- `--flags value`, `-F value`: 日誌記錄器的標誌
|
||||
- `--expression value`, `-e value`: 日誌記錄器的匹配表達式
|
||||
- `--prefix value`, `-p value`: 日誌記錄器的前綴
|
||||
- `--color`: 在日誌中使用顏色
|
||||
- `--filename value`, `-f value`: 日誌記錄器的文件名
|
||||
- `--rotate`, `-r`: 輪轉日誌
|
||||
- `--max-size value`, `-s value`: 在輪轉之前的最大大小（以位元組為單位）
|
||||
- `--daily`, `-d`: 每天輪轉日誌
|
||||
- `--max-days value`, `-D value`: 保留的每日日誌的最大數量
|
||||
- `--compress`, `-z`: 壓縮輪轉的日誌
|
||||
- `--compression-level value`, `-Z value`: 使用的壓縮級別
|
||||
- `conn`: 添加網路連接日誌記錄器
|
||||
- 選項:
|
||||
- `--group value`, `-g value`: 要添加日誌記錄器的組 - 預設為"default"
|
||||
- `--name value`, `-n value`: 新日誌記錄器的名稱 - 預設為模式
|
||||
- `--level value`, `-l value`: 新日誌記錄器的日誌級別
|
||||
- `--stacktrace-level value`, `-L value`: 堆棧跟蹤日誌級別
|
||||
- `--flags value`, `-F value`: 日誌記錄器的標誌
|
||||
- `--expression value`, `-e value`: 日誌記錄器的匹配表達式
|
||||
- `--prefix value`, `-p value`: 日誌記錄器的前綴
|
||||
- `--color`: 在日誌中使用顏色
|
||||
- `--reconnect-on-message`, `-R`: 對於每個消息重新連接主機
|
||||
- `--reconnect`, `-r`: 連接中斷時重新連接主機
|
||||
- `--protocol value`, `-P value`: 設定要使用的協議：tcp、unix 或 udp（預設為 tcp）
|
||||
- `--address value`, `-a value`: 要連接到的主機地址和端口（預設為:7020）
|
||||
- `smtp`: 添加 SMTP 日誌記錄器
|
||||
- 選項:
|
||||
- `--group value`, `-g value`: 要添加日誌記錄器的組 - 預設為"default"
|
||||
- `--name value`, `-n value`: 新日誌記錄器的名稱 - 預設為模式
|
||||
- `--level value`, `-l value`: 新日誌記錄器的日誌級別
|
||||
- `--stacktrace-level value`, `-L value`: 堆棧跟蹤日誌級別
|
||||
- `--flags value`, `-F value`: 日誌記錄器的標誌
|
||||
- `--expression value`, `-e value`: 日誌記錄器的匹配表達式
|
||||
- `--prefix value`, `-p value`: 日誌記錄器的前綴
|
||||
- `--color`: 在日誌中使用顏色
|
||||
- `--username value`, `-u value`: 郵件伺服器使用者名稱
|
||||
- `--password value`, `-P value`: 郵件伺服器密碼
|
||||
- `--host value`, `-H value`: 郵件伺服器主機（預設為: 127.0.0.1:25）
|
||||
- `--send-to value`, `-s value`: 要發送到的電子電子郵件地址
|
||||
- `--subject value`, `-S value`: 發送電子郵件的主題標題
|
||||
- `processes`: 顯示 Gitea 進程和 Goroutine 資訊
|
||||
- 選項:
|
||||
- `--flat`: 以平面表格形式顯示進程，而不是樹形結構
|
||||
- `--no-system`: 不顯示系統進程
|
||||
- `--stacktraces`: 顯示與進程關聯的 Goroutine 的堆棧跟蹤
|
||||
- `--json`: 輸出為 JSON 格式
|
||||
- `--cancel PID`: 向具有 PID 的進程發送取消命令（僅適用於非系統進程）
|
||||
|
||||
### dump-repo
|
||||
|
||||
`dump-repo` 從 Git/GitHub/Gitea/GitLab 中轉儲儲存庫資料：
|
||||
|
||||
- 選項：
|
||||
- `--git_service service`：Git 服務，可以是 `git`、`github`、`gitea`、`gitlab`。如果 `clone_addr` 可以被識別，則可以忽略此選項。
|
||||
- `--repo_dir dir`，`-r dir`：儲存資料的儲存庫目錄路徑。
|
||||
- `--clone_addr addr`：將被克隆的 URL，目前可以是 git/github/gitea/gitlab 的 http/https URL。例如：https://github.com/lunny/tango.git
|
||||
- `--auth_username lunny`：訪問 `clone_addr` 的使用者名稱。
|
||||
- `--auth_password <password>`：訪問 `clone_addr` 的密碼。
|
||||
- `--auth_token <token>`：訪問 `clone_addr` 的個人令牌。
|
||||
- `--owner_name lunny`：如果非空，資料將儲存在具有所有者名稱的目錄中。
|
||||
- `--repo_name tango`：如果非空，資料將儲存在具有儲存庫名稱的目錄中。
|
||||
- `--units <units>`：要遷移的專案，一個或多個專案應以逗號分隔。允許的專案有 wiki, issues, labels, releases, release_assets, milestones, pull_requests, comments。如果為空，則表示所有專案。
|
||||
|
||||
### restore-repo
|
||||
|
||||
`restore-repo` 從磁盤目錄中還原儲存庫資料：
|
||||
|
||||
- 選項：
|
||||
- `--repo_dir dir`，`-r dir`：還原資料的儲存庫目錄路徑。
|
||||
- `--owner_name lunny`：還原目標所有者名稱。
|
||||
- `--repo_name tango`：還原目標儲存庫名稱。
|
||||
- `--units <units>`：要還原的專案，一個或多個專案應以逗號分隔。允許的專案有 wiki, issues, labels, releases, release_assets, milestones, pull_requests, comments。如果為空，則表示所有專案。
|
||||
|
||||
### actions generate-runner-token
|
||||
|
||||
生成一個供 Runner 使用的新令牌，用於向伺服器註冊。
|
||||
|
||||
- 選項：
|
||||
- `--scope {owner}[/{repo}]`，`-s {owner}[/{repo}]`：限制 Runner 的範圍，沒有範圍表示該 Runner 可用於所有儲存庫，但你也可以將其限制為特定的儲存庫或所有者。
|
||||
|
||||
要註冊全域 Runner：
|
||||
|
||||
```
|
||||
gitea actions generate-runner-token
|
||||
```
|
||||
|
||||
要註冊特定組織的 Runner，例如 `org`：
|
||||
|
||||
```
|
||||
gitea actions generate-runner-token -s org
|
||||
```
|
||||
|
||||
要註冊特定儲存庫的 Runner，例如 `username/test-repo`：
|
||||
|
||||
```
|
||||
gitea actions generate-runner-token -s username/test-repo
|
||||
```
|
||||
+1561
File diff suppressed because it is too large.
Load diff
+83
@@ -0,0 +1,83 @@
|
||||
---
|
||||
date: "2017-04-15T14:56:00+02:00"
|
||||
slug: "customizing-gitea"
|
||||
sidebar_position: 100
|
||||
|
||||
aliases:
|
||||
- /zh-tw/customizing-gitea
|
||||
---
|
||||
|
||||
# 自訂 Gitea 設定
|
||||
|
||||
Gitea 引用 `custom` 目錄中的自訂設定文件來覆蓋設定、模板等預設設定。
|
||||
|
||||
如果從二進制部署 Gitea ，則所有預設路徑都將相對於該 gitea 二進制文件；如果從發行版安裝，則可能會將這些路徑修改為 Linux 文件系統標準。Gitea
|
||||
將會自動建立包括 `custom/` 在內的必要應用目錄，應用本身的設定存放在
|
||||
`custom/conf/app.ini` 當中。在發行版中可能會以 `/etc/gitea/` 的形式為 `custom` 設定一個符號鏈接，查看設定詳情請移步：
|
||||
|
||||
- [快速備忘單](../administration/config-cheat-sheet.md)
|
||||
- [完整設定清單](https://github.com/go-gitea/gitea/blob/main/custom/conf/app.example.ini)
|
||||
|
||||
如果您在 binary 同目錄下無法找到 `custom` 文件夾，請檢查您的 `GITEA_CUSTOM`
|
||||
環境變量設定， 因為它可能被設定到了其他地方（可能被一些啟動腳本設定指定了目錄）。
|
||||
|
||||
- [環境變量清單](../administration/environment-variables.md)
|
||||
|
||||
**注：** 必須完全重啟 Gitea 以使設定生效。
|
||||
|
||||
## 使用自訂 /robots.txt
|
||||
|
||||
將 [想要展示的內容](http://www.robotstxt.org/) 存放在 `custom` 目錄中的
|
||||
`robots.txt` 文件來讓 Gitea 使用自訂的`/robots.txt` （預設：空 404）。
|
||||
|
||||
## 使用自訂的公共文件
|
||||
|
||||
將自訂的公共文件（比如頁面和圖片）作為 webroot 放在 `custom/public/` 中來讓 Gitea 提供這些自訂內容（符號鏈接將被追蹤）。
|
||||
|
||||
舉例說明：`image.png` 存放在 `custom/public/assets/`中，那麼它可以透過鏈接 http://gitea.domain.tld/assets/image.png 訪問。
|
||||
|
||||
## 修改預設頭像
|
||||
|
||||
替換以下目錄中的 png 圖片： `custom/public/assets/img/avatar\_default.png`
|
||||
|
||||
## 自訂 Gitea 頁面
|
||||
|
||||
您可以改變 Gitea `custom/templates` 的每個單頁面。您可以在 Gitea 源碼的 `templates` 目錄中找到用於覆蓋的模板文件，應用將根據
|
||||
`custom/templates` 目錄下的路徑結構進行匹配和覆蓋。
|
||||
|
||||
包含在 `{{` 和 `}}` 中的任何語句都是 Gitea 的模板語法，如果您不完全理解這些元件，不建議您對它們進行修改。
|
||||
|
||||
### 添加鏈接和頁籤
|
||||
|
||||
如果您只是想添加額外的鏈接到頂部導航欄或額外的選項卡到儲存庫視圖，您可以將它們放在您 `custom/templates/custom/` 目錄下的 `extra_links.tmpl` 和 `extra_tabs.tmpl` 文件中。
|
||||
|
||||
舉例說明：假設您需要在網站放置一個靜態的“關於”頁面，您只需將該頁面放在您的
|
||||
"custom/public/"目錄下（比如 `custom/public/impressum.html`）並且將它與 `custom/templates/custom/extra_links.tmpl` 鏈接起來即可。
|
||||
|
||||
這個鏈接應當使用一個名為“item”的 class 來匹配當前樣式，您可以使用 `{{AppSubUrl}}` 來獲取 base URL:
|
||||
`<a class="item" href="{{AppSubUrl}}/assets/impressum.html">Impressum</a>`
|
||||
|
||||
同理，您可以將頁籤添加到 `extra_tabs.tmpl` 中，使用同樣的方式來添加頁籤。它的具體樣式需要與
|
||||
`templates/repo/header.tmpl` 中已有的其他選項卡的樣式匹配
|
||||
([source in GitHub](https://github.com/go-gitea/gitea/blob/main/templates/repo/header.tmpl))
|
||||
|
||||
### 頁面的其他新增內容
|
||||
|
||||
除了 `extra_links.tmpl` 和 `extra_tabs.tmpl`，您可以在您的 `custom/templates/custom/` 目錄中存放一些其他有用的模板，例如：
|
||||
|
||||
- `header.tmpl`，在 `<head>` 標記結束之前的模板，例如添加自訂 CSS 文件
|
||||
- `body_outer_pre.tmpl`，在 `<body>` 標記開始處的模板
|
||||
- `body_inner_pre.tmpl`，在頂部導航欄之前，但在主 container 內部的模板，例如添加一個 `<div class="full height">`
|
||||
- `body_inner_post.tmpl`，在主 container 結束處的模板
|
||||
- `body_outer_post.tmpl`，在底部 `<footer>` 元素之前.
|
||||
- `footer.tmpl`，在 `<body>` 標籤結束處的模板，可以在這裡填寫一些附加的 Javascript 腳本。
|
||||
|
||||
## 自訂 gitignores，labels， licenses， locales 以及 readmes
|
||||
|
||||
將自訂文件放在 `custom/options` 下相應子的文件夾中即可
|
||||
|
||||
## 更改 Gitea 外觀
|
||||
|
||||
內置主題是“gitea-light”、“gitea-dark”和“gitea-auto”（自動適應操作系統設定）。
|
||||
|
||||
預設主題可以透過 `app.ini` 的 [ui](../administration/config-cheat-sheet.md) 部分中的 `DEFAULT_THEME` 進行更改。
|
||||
@@ -0,0 +1,77 @@
|
||||
---
|
||||
date: "2023-05-23T09:00:00+08:00"
|
||||
slug: "email-setup"
|
||||
sidebar_position: 12
|
||||
|
||||
aliases:
|
||||
- /zh-tw/email-setup
|
||||
---
|
||||
|
||||
# Email 設定
|
||||
|
||||
Gitea 具有郵件功能，用於發送事務性郵件（例如註冊確認郵件）。它可以設定為使用 Sendmail（或相容的 MTA，例如 Postfix 和 msmtp）或直接使用 SMTP 伺服器。
|
||||
|
||||
## 使用 Sendmail
|
||||
|
||||
使用 `sendmail` 命令作為郵件傳輸代理（mailer）。
|
||||
|
||||
注意：對於在官方 Gitea Docker 鏡像中使用，請使用 SMTP 版本進行設定（請參考下一節）。
|
||||
|
||||
注意：對於面向互聯網的網站，請查閱您的 MTA 文件以瞭解通過 TLS 發送郵件的說明。同時設定 SPF、DMARC 和 DKIM DNS 記錄，以使發送的郵件被各個電子郵件提供商接受為合法郵件。
|
||||
|
||||
```ini title="app.ini"
|
||||
[mailer]
|
||||
ENABLED = true
|
||||
FROM = [email protected]
|
||||
PROTOCOL = sendmail
|
||||
SENDMAIL_PATH = /usr/sbin/sendmail
|
||||
SENDMAIL_ARGS = "--" ; 大多數 "sendmail" 程序都接受選項，使用 "--" 將防止電子郵件地址被解釋為選項。
|
||||
```
|
||||
|
||||
## 使用 SMTP
|
||||
|
||||
直接使用 SMTP 伺服器作為中繼。如果您不想在實例上設定 MTA，但在電子郵件提供商那裡有一個帳戶，這個選項非常有用。
|
||||
|
||||
```ini title="app.ini"
|
||||
[mailer]
|
||||
ENABLED = true
|
||||
FROM = [email protected]
|
||||
PROTOCOL = smtps
|
||||
SMTP_ADDR = mail.mydomain.com
|
||||
SMTP_PORT = 587
|
||||
USER = [email protected]
|
||||
PASSWD = `password`
|
||||
```
|
||||
|
||||
重啟 Gitea 以使設定更改生效。
|
||||
|
||||
要發送測試郵件以驗證設定，請轉到 Gitea > 站點管理 > 設定 > SMTP 郵件設定。
|
||||
|
||||
有關所有選項的完整列表，請查看[設定速查表](../administration/config-cheat-sheet.md)。
|
||||
|
||||
請注意：只有在使用 TLS 或 `HOST=localhost` 加密 SMTP 伺服器通信時才支援身份驗證。TLS 加密可以透過以下方式進行：
|
||||
|
||||
- 通過端口 587 的 STARTTLS（也稱為 Opportunistic TLS）。初始連接是明文的，但如果伺服器支援，則可以升級為 TLS。
|
||||
- 通過預設端口 465 的 SMTPS 連接。連接到伺服器從一開始就使用 TLS。
|
||||
- 使用 `PROTOCOL=smtps` 進行強制的 SMTPS 連接。（這兩種方式都被稱為 Implicit TLS）
|
||||
這是由於 Go 內部庫對 STRIPTLS 攻擊的保護機制。
|
||||
|
||||
請注意，自 2018 年起，[RFC8314](https://tools.ietf.org/html/rfc8314#section-3) 推薦使用 Implicit TLS。
|
||||
|
||||
### Gmail
|
||||
|
||||
以下設定應該適用於 Gmail 的 SMTP 伺服器：
|
||||
|
||||
```ini title="app.ini"
|
||||
[mailer]
|
||||
ENABLED = true
|
||||
HOST = smtp.gmail.com:465 ; 對於 Gitea >= 1.18.0，刪除此行
|
||||
SMTP_ADDR = smtp.gmail.com
|
||||
SMTP_PORT = 465
|
||||
FROM = [email protected]
|
||||
USER = example.user
|
||||
PASSWD = `***`
|
||||
PROTOCOL = smtps
|
||||
```
|
||||
|
||||
請注意，您需要建立並使用一個 [應用密碼](https://support.google.com/accounts/answer/185833?hl=en) 並在您的 Google 帳戶上啟用 2FA。您將無法直接使用您的 Google 帳戶密碼。
|
||||
+49
@@ -0,0 +1,49 @@
|
||||
---
|
||||
date: "2017-04-08T11:34:00+02:00"
|
||||
slug: "environment-variables"
|
||||
sidebar_position: 10
|
||||
|
||||
aliases:
|
||||
- /zh-tw/environment-variables
|
||||
---
|
||||
|
||||
# 環境變量清單
|
||||
|
||||
這裡是用來控制 Gitea 行為表現的的環境變量清單，您需要在執行如下 Gitea 啟動命令前設定它們來確保設定生效：
|
||||
|
||||
```
|
||||
GITEA_CUSTOM=/home/gitea/custom ./gitea web
|
||||
```
|
||||
|
||||
## Go 的設定
|
||||
|
||||
因為 Gitea 使用 Go 語言編寫，因此它使用了一些相關的 Go 的設定參數：
|
||||
|
||||
- `GOOS`
|
||||
- `GOARCH`
|
||||
- [`GOPATH`](https://go.dev/cmd/go/#hdr-GOPATH_environment_variable)
|
||||
|
||||
您可以在[官方文件](https://go.dev/cmd/go/#hdr-Environment_variables)中查閱這些設定參數的詳細資訊。
|
||||
|
||||
## Gitea 的文件目錄
|
||||
|
||||
- `GITEA_WORK_DIR`：工作目錄的絕對路徑
|
||||
- `GITEA_CUSTOM`：預設情況下 Gitea 使用預設目錄 `GITEA_WORK_DIR`/custom，您可以使用這個參數來設定 _custom_ 目錄
|
||||
- `GOGS_WORK_DIR`： 已廢棄，請使用 `GITEA_WORK_DIR` 替代
|
||||
- `GOGS_CUSTOM`： 已廢棄，請使用 `GITEA_CUSTOM` 替代
|
||||
|
||||
## 操作系統設定
|
||||
|
||||
- `USER`：Gitea 運行時使用的系統使用者，它將作為一些 repository 的訪問地址的一部分
|
||||
- `USERNAME`： 如果沒有設定 `USER`， Gitea 將使用 `USERNAME`
|
||||
- `HOME`： 使用者的 home 目錄，在 Windows 中會使用 `USERPROFILE` 環境變量
|
||||
|
||||
### 僅限於 Windows 的設定
|
||||
|
||||
- `USERPROFILE`： 使用者的主目錄，如果未設定則會使用 `HOMEDRIVE` + `HOMEPATH`
|
||||
- `HOMEDRIVE`: 用於訪問 home 目錄的主驅動器路徑（C 盤）
|
||||
- `HOMEPATH`：在指定主驅動器下的 home 目錄相對路徑
|
||||
|
||||
## Miscellaneous
|
||||
|
||||
- `SKIP_MINWINSVC`：如果設定為 1，在 Windows 上不會以 service 的形式運行。
|
||||
+194
@@ -0,0 +1,194 @@
|
||||
---
|
||||
date: "2023-05-23T09:00:00+08:00"
|
||||
slug: "external-renderers"
|
||||
sidebar_position: 60
|
||||
|
||||
aliases:
|
||||
- /zh-tw/external-renderers
|
||||
---
|
||||
|
||||
# 外部渲染器
|
||||
|
||||
Gitea 通過外部二進制文件支援自訂文件渲染（例如 Jupyter notebooks、asciidoc 等），只需要進行以下步驟：
|
||||
|
||||
- 安裝外部二進制文件
|
||||
- 在您的 `app.ini` 文件中添加一些設定
|
||||
- 重新啟動 Gitea 實例
|
||||
|
||||
此功能支援整個文件的渲染。如果您想要在 Markdown 中渲染程式碼塊，您需要使用 JavaScript 進行一些操作。請參閱 [自訂 Gitea 設定](../administration/customizing-gitea.md) 頁面上的一些範例。
|
||||
|
||||
## 安裝外部二進制文件
|
||||
|
||||
為了通過外部二進制文件進行文件渲染，必須安裝它們的關聯套件。
|
||||
如果您正在使用 Docker 鏡像，則您的 `Dockerfile` 應該包含以下內容：
|
||||
|
||||
```docker
|
||||
FROM docker.gitea.com/gitea:@dockerVersion@
|
||||
[...]
|
||||
|
||||
COPY custom/app.ini /data/gitea/conf/app.ini
|
||||
[...]
|
||||
|
||||
RUN apk --no-cache add asciidoctor freetype freetype-dev gcc g++ libpng libffi-dev pandoc python3-dev py3-pyzmq pipx
|
||||
# 安裝其他您需要的外部渲染器的軟件包
|
||||
|
||||
RUN pipx install jupyter docutils --include-deps
|
||||
# 在上面添加您需要安裝的任何其他 Python 軟件包
|
||||
```
|
||||
|
||||
## `app.ini` 文件設定
|
||||
|
||||
在您的自訂 `app.ini` 文件中為每個外部渲染器添加一個 `[markup.XXXXX]` 部分：
|
||||
|
||||
```ini
|
||||
[markup.asciidoc]
|
||||
ENABLED = true
|
||||
FILE_EXTENSIONS = .adoc,.asciidoc
|
||||
RENDER_COMMAND = "asciidoctor -s -a showtitle --out-file=- -"
|
||||
; 輸入不是標準輸入而是文件
|
||||
IS_INPUT_FILE = false
|
||||
|
||||
[markup.jupyter]
|
||||
ENABLED = true
|
||||
FILE_EXTENSIONS = .ipynb
|
||||
RENDER_COMMAND = "jupyter nbconvert --stdin --stdout --to html --template basic"
|
||||
IS_INPUT_FILE = false
|
||||
|
||||
[markup.restructuredtext]
|
||||
ENABLED = true
|
||||
FILE_EXTENSIONS = .rst
|
||||
RENDER_COMMAND = "timeout 30s pandoc +RTS -M512M -RTS -f rst"
|
||||
IS_INPUT_FILE = false
|
||||
```
|
||||
|
||||
如果您的外部標記語言依賴於在生成的 HTML 元素上的額外類和屬性，您可能需要啟用自訂的清理策略。Gitea 使用 [`bluemonday`](https://godoc.org/github.com/microcosm-cc/bluemonday) 包作為我們的 HTML 清理器。下面的範例可以用於支援從 [`pandoc`](https://pandoc.org/) 輸出的伺服器端 [KaTeX](https://katex.org/) 渲染結果。
|
||||
|
||||
```ini
|
||||
[markup.sanitizer.TeX]
|
||||
; Pandoc 渲染 TeX 段落為帶有 "math" 類的 <span> 元素，根據上下文可能還帶有 "inline" 或 "display" 類。
|
||||
; - 請注意，這與我們的 Markdown 解析器中內置的數學支持不同，後者使用 <code> 元素。
|
||||
ELEMENT = span
|
||||
ALLOW_ATTR = class
|
||||
REGEXP = ^\s*((math(\s+|$)|inline(\s+|$)|display(\s+|$)))+
|
||||
|
||||
[markup.markdown]
|
||||
ENABLED = true
|
||||
FILE_EXTENSIONS = .md,.markdown
|
||||
RENDER_COMMAND = pandoc -f markdown -t html --katex
|
||||
```
|
||||
|
||||
您必須在每個部分中定義 `ELEMENT` 和 `ALLOW_ATTR`。
|
||||
|
||||
要定義多個條目，請添加唯一的字母數字後綴（例如，`[markup.sanitizer.1]` 和 `[markup.sanitizer.something]`）。
|
||||
|
||||
要僅為特定的外部渲染器應用清理規則，它們必須使用渲染器名稱，例如 `[markup.sanitizer.asciidoc.rule-1]`、`[markup.sanitizer.<renderer>.rule-1]`。
|
||||
|
||||
**注意**：如果規則在渲染器 ini 部分之前定義，或者名稱與渲染器不匹配，它將應用於所有渲染器。
|
||||
|
||||
完成設定更改後，請重新啟動 Gitea 以使更改生效。
|
||||
|
||||
**注意**：在 Gitea 1.12 之前，存在一個名為 `markup.sanitiser` 的單個部分，其中的鍵被重新定義為多個規則，但是，這種設定方法存在重大問題，需要通過多個部分進行設定。
|
||||
|
||||
### 範例：HTML
|
||||
|
||||
直接渲染 HTML 文件：
|
||||
|
||||
```ini
|
||||
[markup.html]
|
||||
ENABLED = true
|
||||
FILE_EXTENSIONS = .html,.htm
|
||||
RENDER_COMMAND = cat
|
||||
; 輸入不是標準輸入，而是文件
|
||||
IS_INPUT_FILE = true
|
||||
|
||||
[markup.sanitizer.html.1]
|
||||
ELEMENT = div
|
||||
ALLOW_ATTR = class
|
||||
|
||||
[markup.sanitizer.html.2]
|
||||
ELEMENT = a
|
||||
ALLOW_ATTR = class
|
||||
```
|
||||
|
||||
請注意：此範例中的設定將允許渲染 HTML 文件，並使用 `cat` 命令將文件內容輸出為 HTML。此外，設定中的兩個清理規則將允許 `<div>` 和 `<a>` 元素使用 `class` 屬性。
|
||||
|
||||
在進行設定更改後，請重新啟動 Gitea 以使更改生效。
|
||||
|
||||
### 範例：Office DOCX
|
||||
|
||||
使用 [`pandoc`](https://pandoc.org/) 顯示 Office DOCX 文件：
|
||||
|
||||
```ini
|
||||
[markup.docx]
|
||||
ENABLED = true
|
||||
FILE_EXTENSIONS = .docx
|
||||
RENDER_COMMAND = "pandoc --from docx --to html --self-contained --template /path/to/basic.html"
|
||||
|
||||
[markup.sanitizer.docx.img]
|
||||
ALLOW_DATA_URI_IMAGES = true
|
||||
```
|
||||
|
||||
在此範例中，設定將允許顯示 Office DOCX 文件，並使用 `pandoc` 命令將文件轉換為 HTML 格式。同時，清理規則中的 `ALLOW_DATA_URI_IMAGES` 設定為 `true`，允許使用 Data URI 格式的圖片。
|
||||
|
||||
模板文件的內容如下：
|
||||
|
||||
```
|
||||
$body$
|
||||
```
|
||||
|
||||
### 範例：Jupyter Notebook
|
||||
|
||||
使用 [`nbconvert`](https://github.com/jupyter/nbconvert) 顯示 Jupyter Notebook 文件：
|
||||
|
||||
```ini
|
||||
[markup.jupyter]
|
||||
ENABLED = true
|
||||
FILE_EXTENSIONS = .ipynb
|
||||
RENDER_COMMAND = "jupyter-nbconvert --stdin --stdout --to html --template basic"
|
||||
|
||||
[markup.sanitizer.jupyter.img]
|
||||
ALLOW_DATA_URI_IMAGES = true
|
||||
```
|
||||
|
||||
在此範例中，設定將允許顯示 Jupyter Notebook 文件，並使用 `nbconvert` 命令將文件轉換為 HTML 格式。同樣，清理規則中的 `ALLOW_DATA_URI_IMAGES` 設定為 `true`，允許使用 Data URI 格式的圖片。
|
||||
|
||||
在進行設定更改後，請重新啟動 Gitea 以使更改生效。
|
||||
|
||||
## 自訂 CSS
|
||||
|
||||
在 `.ini` 文件中，可以使用 `[markup.XXXXX]` 的格式指定外部渲染器，並且由外部渲染器生成的 HTML 將被包裝在一個帶有 `markup` 和 `XXXXX` 類的 `<div>` 中。`markup` 類提供了預定義的樣式（如果 `XXXXX` 是 `markdown`，則使用 `markdown` 類）。否則，您可以使用這些類來針對渲染的 HTML 內容進行定製樣式。
|
||||
|
||||
因此，您可以編寫一些 CSS 樣式：
|
||||
|
||||
```css
|
||||
.markup.XXXXX html {
|
||||
font-size: 100%;
|
||||
overflow-y: scroll;
|
||||
-webkit-text-size-adjust: 100%;
|
||||
-ms-text-size-adjust: 100%;
|
||||
}
|
||||
|
||||
.markup.XXXXX body {
|
||||
color: #444;
|
||||
font-family: Georgia, Palatino, "Palatino Linotype", Times, "Times New Roman",
|
||||
serif;
|
||||
font-size: 12px;
|
||||
line-height: 1.7;
|
||||
padding: 1em;
|
||||
margin: auto;
|
||||
max-width: 42em;
|
||||
background: #fefefe;
|
||||
}
|
||||
|
||||
.markup.XXXXX p {
|
||||
color: orangered;
|
||||
}
|
||||
```
|
||||
|
||||
將您的樣式表添加到自訂目錄中，例如 `custom/public/assets/css/my-style-XXXXX.css`，並使用自訂的頭文件 `custom/templates/custom/header.tmpl` 進行導入：
|
||||
|
||||
```html
|
||||
<link rel="stylesheet" href="{{AppSubUrl}}/assets/css/my-style-XXXXX.css" />
|
||||
```
|
||||
|
||||
通過以上步驟，您可以將自訂的 CSS 樣式應用到特定的外部渲染器，使其具有所需的樣式效果。
|
||||
@@ -0,0 +1,86 @@
|
||||
---
|
||||
date: "2022-08-01T00:00:00+00:00"
|
||||
slug: "fail2ban-setup"
|
||||
sidebar_position: 16
|
||||
|
||||
aliases:
|
||||
- /zh-tw/fail2ban-setup
|
||||
---
|
||||
|
||||
# 設定 Fail2ban
|
||||
|
||||
**Fail2ban 檢查客戶端登入日誌，將多次登入失敗的客戶端識別為攻擊者並在一段時間內阻止其訪問服務。如果你的實例是公開的，這一點尤其重要。請管理員仔細設定 fail2ban，錯誤的設定將導致防火牆阻止你訪問自己的伺服器。**
|
||||
|
||||
Gitea 會在日誌文件 `log/gitea.log` 中記錄登入失敗的 CLI、SSH 或 HTTP 客戶端 IP 地址，而你需要將 Gitea 的日誌輸出模式從預設的 `console` 更改為 `file`。這表示將日誌輸出到文件，使得 fail2ban 可以定期掃描日誌內容。
|
||||
|
||||
當使用者的身份驗證失敗時，日誌中會記錄此類資訊：
|
||||
|
||||
```log
|
||||
2018/04/26 18:15:54 [I] Failed authentication attempt for user from xxx.xxx.xxx.xxx
|
||||
```
|
||||
|
||||
```log
|
||||
2020/10/15 16:08:44 [E] invalid credentials from xxx.xxx.xxx.xxx
|
||||
```
|
||||
|
||||
## 設定規則
|
||||
|
||||
添加日誌過濾器規則到設定文件 `/etc/fail2ban/filter.d/gitea.conf`:
|
||||
|
||||
```ini
|
||||
[Definition]
|
||||
failregex = .*(Failed authentication attempt|invalid credentials|Attempted access of unknown user).* from <HOST>
|
||||
ignoreregex =
|
||||
```
|
||||
|
||||
添加監獄規則到設定文件 `/etc/fail2ban/jail.d/gitea.conf`:
|
||||
|
||||
```ini
|
||||
[gitea]
|
||||
enabled = true
|
||||
filter = gitea
|
||||
logpath = /var/lib/gitea/log/gitea.log
|
||||
maxretry = 10
|
||||
findtime = 3600
|
||||
bantime = 900
|
||||
action = iptables-allports
|
||||
```
|
||||
|
||||
如果你的 Gitea 實例運行在 Docker 容器中，並且直接將容器端口暴露到外部網路，
|
||||
你還需要添加 `chain="FORWARD"` 到監獄規則設定文件 `/etc/fail2ban/jail.d/gitea-docker.conf`
|
||||
以適應 Docker 的網路轉發規則。但如果你在容器的宿主機上使用 Nginx 反向代理連接到 Gitea 則無需這樣設定。
|
||||
|
||||
```ini
|
||||
[gitea-docker]
|
||||
enabled = true
|
||||
filter = gitea
|
||||
logpath = /var/lib/gitea/log/gitea.log
|
||||
maxretry = 10
|
||||
findtime = 3600
|
||||
bantime = 900
|
||||
action = iptables-allports[chain="FORWARD"]
|
||||
```
|
||||
|
||||
最後，運行 `systemctl restart fail2ban` 即可應用更改。現在，你可以使用 `systemctl status fail2ban` 檢查 fail2ban 運行狀態。
|
||||
|
||||
上述規則規定客戶端在 1 小時內，如果登入失敗的次數達到 10 次，則通過 iptables 鎖定該客戶端 IP 地址 15 分鐘。
|
||||
|
||||
## 設定反向代理
|
||||
|
||||
如果你使用 Nginx 反向代理到 Gitea 實例，你還需要設定 Nginx 的 HTTP 頭部值 `X-Real-IP` 將真實的客戶端 IP 地址傳遞給 Gitea。否則 Gitea 程式會將客戶端地址錯誤解析為反向代理伺服器的地址，例如迴環地址 `127.0.0.1`。
|
||||
|
||||
```
|
||||
proxy_set_header X-Real-IP $remote_addr;
|
||||
```
|
||||
|
||||
額外注意，在 Gitea 的設定文件 `app.ini` 中存在下列預設值：
|
||||
|
||||
```
|
||||
REVERSE_PROXY_LIMIT = 1
|
||||
REVERSE_PROXY_TRUSTED_PROXIES = 127.0.0.0/8,::1/128
|
||||
```
|
||||
|
||||
`REVERSE_PROXY_LIMIT` 限制反向代理伺服器的層數，設定為 `0` 表示不使用這些標頭。
|
||||
`REVERSE_PROXY_TRUSTED_PROXIES` 表示受信任的反向代理伺服器網路地址，
|
||||
經過該網路地址轉發來的流量會經過解析 `X-Real-IP` 頭部得到真實客戶端地址。
|
||||
（參考 [configuration cheat sheet](../administration/config-cheat-sheet.md)）
|
||||
+24
@@ -0,0 +1,24 @@
|
||||
---
|
||||
date: "2023-05-23T09:00:00+08:00"
|
||||
slug: "git-lfs-setup"
|
||||
sidebar_position: 12
|
||||
|
||||
aliases:
|
||||
- /zh-tw/git-lfs-setup
|
||||
---
|
||||
|
||||
# Git LFS 設定
|
||||
|
||||
要使用 Gitea 內置的 LFS 支援，您需要更新 `app.ini` 文件：
|
||||
|
||||
```ini
|
||||
[server]
|
||||
; 啟用 git-lfs 支持。true 或 false，默認為 false。
|
||||
LFS_START_SERVER = true
|
||||
|
||||
[lfs]
|
||||
; 存放 LFS 文件的路徑，默認為 data/lfs。
|
||||
PATH = /home/gitea/data/lfs
|
||||
```
|
||||
|
||||
**注意**：LFS 伺服器支援需要伺服器上安裝 Git v2.1.2 以上版本。
|
||||
@@ -0,0 +1,89 @@
|
||||
---
|
||||
date: "2023-04-09T11:00:00+02:00"
|
||||
slug: "https-setup"
|
||||
sidebar_position: 12
|
||||
|
||||
---
|
||||
|
||||
# HTTPS設定
|
||||
|
||||
## 使用內置伺服器
|
||||
|
||||
在啟用HTTPS之前，確保您擁有有效的SSL/TLS證書。
|
||||
建議在測試和評估情況下使用自簽名證書，請運行 `gitea cert --host [HOST]` 以生成自簽名證書
|
||||
|
||||
如果您在伺服器上使用阿帕奇（Apache）或Nginx，建議參考 [反向代理指南](reverse-proxies.md)。
|
||||
|
||||
要使用Gitea內置HTTPS支援，您必須編輯`app.ini`文件。
|
||||
|
||||
```ini
|
||||
[server]
|
||||
PROTOCOL = https
|
||||
ROOT_URL = https://git.example.com:3000/
|
||||
HTTP_PORT = 3000
|
||||
CERT_FILE = cert.pem
|
||||
KEY_FILE = key.pem
|
||||
```
|
||||
|
||||
請注意，如果您的證書由第三方證書頒發機構簽名（即不是自簽名的），則 cert.pem 應包含證書鏈。伺服器證書必須是 cert.pem 中的第一個條目，後跟中介（如果有）。不必包含根證書，因為連接客戶端必須已經擁有根證書才能建立信任關係。要了解有關設定值的更多資訊，請查看 [設定備忘單](../administration/config-cheat-sheet.md)。
|
||||
|
||||
對於“CERT_FILE”或“KEY_FILE”欄位，當文件路徑是相對路徑時，文件路徑相對於“GITEA_CUSTOM”環境變量。它也可以是絕對路徑。
|
||||
|
||||
### 設定HTTP重定向
|
||||
|
||||
Gitea伺服器僅支援監聽一個端口；要重定向HTTP請求致HTTPS端口，您需要啟用HTTP重定向服務：
|
||||
|
||||
```ini
|
||||
[server]
|
||||
REDIRECT_OTHER_PORT = true
|
||||
; Port the redirection service should listen on
|
||||
PORT_TO_REDIRECT = 3080
|
||||
```
|
||||
|
||||
如果您使用Docker，確保端口已設定在 `docker-compose.yml` 文件
|
||||
|
||||
## 使用 ACME (預設: Let's Encrypt)
|
||||
|
||||
[ACME](https://tools.ietf.org/html/rfc8555) 是一種證書頒發機構標準協議，允許您自動請求和續訂 SSL/TLS 證書。[Let`s Encrypt](https://letsencrypt.org/) 是使用此標準的免費公開信任的證書頒發機構伺服器。僅實施“HTTP-01”和“TLS-ALPN-01”挑戰。為了使 ACME 質詢通過並驗證您的域所有權，“80”端口（“HTTP-01”）或“443”端口（“TLS-ALPN-01”）上 gitea 域的外部流量必須由 gitea 實例提供服務。可能需要設定 [HTTP 重定向](#設定http重定向) 和端口轉發才能正確路由外部流量。否則，到端口“80”的正常流量將自動重定向到 HTTPS。**您必須同意**ACME提供商的服務條款（預設為Let's Encrypt的 [服務條款](https://letsencrypt.org/documents/LE-SA-v1.2-2017年11月15日.pdf)。
|
||||
|
||||
使用預設 Let's Encrypt 的最小設定如下：
|
||||
|
||||
```ini
|
||||
[server]
|
||||
PROTOCOL=https
|
||||
DOMAIN=git.example.com
|
||||
ENABLE_ACME=true
|
||||
ACME_ACCEPTTOS=true
|
||||
ACME_DIRECTORY=https
|
||||
;; Email can be omitted here and provided manually at first run, after which it is cached
|
||||
ACME_EMAIL=[email protected]
|
||||
```
|
||||
|
||||
小型設定請使用 [smallstep CA](https://github.com/smallstep/certificates), 點擊 [教學](https://smallstep.com/docs/tutorials/acme-challenge) 瞭解更多資訊。
|
||||
|
||||
```ini
|
||||
[server]
|
||||
PROTOCOL=https
|
||||
DOMAIN=git.example.com
|
||||
ENABLE_ACME=true
|
||||
ACME_ACCEPTTOS=true
|
||||
ACME_URL=https://ca.example.com/acme/acme/directory
|
||||
;; Can be omitted if using the system's trust is preferred
|
||||
;ACME_CA_ROOT=/path/to/root_ca.crt
|
||||
ACME_DIRECTORY=https
|
||||
ACME_EMAIL=[email protected]
|
||||
```
|
||||
|
||||
要了解關於設定, 請前往 [設定備忘單](../administration/config-cheat-sheet.md)獲取更多資訊
|
||||
|
||||
## 使用反向代理伺服器
|
||||
|
||||
按照 [reverse proxy guide](reverse-proxies.md) 的規則設定你的反向代理伺服器
|
||||
|
||||
然後，按照下面的嚮導啟用 HTTPS：
|
||||
|
||||
- [nginx](https://nginx.org/en/docs/http/configuring_https_servers.html)
|
||||
- [apache2/httpd](https://httpd.apache.org/docs/2.4/ssl/ssl_howto.html)
|
||||
- [caddy](https://caddyserver.com/docs/tls)
|
||||
|
||||
注意：僅在代理層啟用 HTTPS 被稱為 [TLS 終止代理](https://en.wikipedia.org/wiki/TLS_termination_proxy)。代理伺服器接受傳入的 TLS 連接，解密內容，然後將現在未加密的內容傳遞給 Gitea。只要代理和 Gitea 實例在同一臺計算機上或在私有網路中的不同計算機上（代理暴露給外部網路），這通常是可以接受的。如果您的 Gitea 實例與代理隔離在公共網路上，或者如果您想要全端到端的加密，您還可以直接在 Gitea 中 [啟用內置伺服器的 HTTPS 支援](#使用內置伺服器)，並將連接轉發到 HTTPS 上。
|
||||
+263
@@ -0,0 +1,263 @@
|
||||
---
|
||||
date: "2023-05-23T09:00:00+08:00"
|
||||
slug: "logging-config"
|
||||
sidebar_position: 40
|
||||
aliases:
|
||||
- /zh-tw/logging-configuration
|
||||
---
|
||||
|
||||
# 日誌設定
|
||||
|
||||
Gitea 的日誌設定主要由以下三種類型的元件組成：
|
||||
|
||||
- `[log]` 部分用於一般設定
|
||||
- `[log.<mode-name>]` 部分用於設定不同的日誌輸出方式，也稱為 "writer mode"，模式名稱同時也作為 "writer name"
|
||||
- `[log]` 部分還可以包含遵循 `logger.<logger-name>.<CONFIG-KEY>` 模式的子日誌記錄器的設定
|
||||
|
||||
預設情況下，已經有一個完全功能的日誌輸出，因此不需要重新定義。
|
||||
|
||||
## 收集日誌以獲取幫助
|
||||
|
||||
要收集日誌以獲取幫助和報告問題，請參閱 [需要幫助](help/support.md)。
|
||||
|
||||
## `[log]` 部分
|
||||
|
||||
在 Gitea 中，日誌設施的設定在 `[log]` 部分及其子部分。
|
||||
|
||||
在頂層的 `[log]` 部分，可以放置以下設定項：
|
||||
|
||||
- `ROOT_PATH`：（預設值：**%(GITEA_WORK_DIR)/log**）：日誌文件的基本路徑。
|
||||
- `MODE`：（預設值：**console**）：要用於預設日誌記錄器的日誌輸出列表。
|
||||
- `LEVEL`：（預設值：**Info**）：要持久化的最嚴重的日誌事件，不區分大小寫。可能的值為：`Trace`、`Debug`、`Info`、`Warn`、`Error`、`Fatal`。
|
||||
- `STACKTRACE_LEVEL`：（預設值：**None**）：對於此類及更嚴重的事件，將在記錄時打印堆棧跟蹤。
|
||||
|
||||
它還可以包含以下子日誌記錄器：
|
||||
|
||||
- `logger.router.MODE`：（預設值：**,**）：用於路由器日誌記錄器的日誌輸出列表。
|
||||
- `logger.access.MODE`：（預設值：**_empty_**）：用於訪問日誌記錄器的日誌輸出列表。預設情況下，訪問日誌記錄器被禁用。
|
||||
- `logger.xorm.MODE`：（預設值：**,**）：用於 XORM 日誌記錄器的日誌輸出列表。
|
||||
|
||||
將子日誌記錄器的模式設定為逗號（`,`）表示使用預設的全域 `MODE`。
|
||||
|
||||
## 快速範例
|
||||
|
||||
### 預設（空）設定
|
||||
|
||||
空設定等同於預設設定：
|
||||
|
||||
```ini
|
||||
[log]
|
||||
ROOT_PATH = %(GITEA_WORK_DIR)/log
|
||||
MODE = console
|
||||
LEVEL = Info
|
||||
STACKTRACE_LEVEL = None
|
||||
logger.router.MODE = ,
|
||||
logger.xorm.MODE = ,
|
||||
logger.access.MODE =
|
||||
|
||||
; 這是“控制檯”模式的配置選項（由上面的 MODE=console 使用）
|
||||
[log.console]
|
||||
MODE = console
|
||||
FLAGS = stdflags
|
||||
PREFIX =
|
||||
COLORIZE = true
|
||||
```
|
||||
|
||||
這等同於將所有日誌發送到控制檯，並將預設的 Golang 日誌也發送到控制檯日誌中。
|
||||
|
||||
這只是一個範例，預設情況下不需要將其寫入設定文件中。
|
||||
|
||||
### 禁用路由日誌並將一些訪問日誌記錄到文件中
|
||||
|
||||
禁用路由日誌，將訪問日誌（>=Warn）記錄到 `access.log` 中：
|
||||
|
||||
```ini
|
||||
[log]
|
||||
logger.router.MODE =
|
||||
logger.access.MODE = access-file
|
||||
|
||||
[log.access-file]
|
||||
MODE = file
|
||||
LEVEL = Warn
|
||||
FILE_NAME = access.log
|
||||
```
|
||||
|
||||
### 為不同的模式設定不同的日誌級別
|
||||
|
||||
將預設日誌（>=Warn）記錄到 `gitea.log` 中，將錯誤日誌記錄到 `file-error.log` 中：
|
||||
|
||||
```ini
|
||||
[log]
|
||||
LEVEL = Warn
|
||||
MODE = file, file-error
|
||||
|
||||
; 默認情況下，"file" 模式會將日誌記錄到 %(log.ROOT_PATH)/gitea.log，因此我們不需要設置它
|
||||
; [log.file]
|
||||
|
||||
[log.file-error]
|
||||
LEVEL = Error
|
||||
FILE_NAME = file-error.log
|
||||
```
|
||||
|
||||
## 日誌輸出（模式和寫入器）
|
||||
|
||||
Gitea 提供以下日誌寫入器：
|
||||
|
||||
- `console` - 輸出日誌到 `stdout`（或 `stderr`，如果已在設定中設定）
|
||||
- `file` - 輸出日誌到文件
|
||||
- `conn` - 輸出日誌到套接字（網路或 Unix 套接字）
|
||||
|
||||
### 公共設定
|
||||
|
||||
某些設定適用於所有日誌輸出模式：
|
||||
|
||||
- `MODE` 是日誌輸出寫入器的模式。它將預設為 ini 部分的模式名稱。因此，`[log.console]` 將預設為 `MODE = console`。
|
||||
- `LEVEL` 是此輸出將記錄的最低日誌級別。
|
||||
- `STACKTRACE_LEVEL` 是此輸出將打印堆棧跟蹤的最低日誌級別。
|
||||
- `COLORIZE` 對於 `console`，預設為 `true`，否則預設為 `false`。
|
||||
|
||||
#### `EXPRESSION`
|
||||
|
||||
`EXPRESSION` 表示日誌事件必須匹配才能被輸出寫入器記錄的正則表達式。
|
||||
日誌消息（去除顏色）或 `longfilename:linenumber:functionname` 必須匹配其中之一。
|
||||
注意：整個消息或字符串不需要完全匹配。
|
||||
|
||||
請注意，此表達式將在寫入器的 goroutine 中運行，而不是在日誌事件的 goroutine 中運行。
|
||||
|
||||
#### `FLAGS`
|
||||
|
||||
`FLAGS` 表示在每條消息之前打印的前置日誌上下文資訊。
|
||||
它是一個逗號分隔的字符串集。值的順序無關緊要。
|
||||
|
||||
預設值為 `stdflags`（= `date,time,medfile,shortfuncname,levelinitial`）。
|
||||
|
||||
可能的值為：
|
||||
|
||||
- `none` 或 `,` - 無標誌。
|
||||
- `date` - 當地時區的日期：`2009/01/23`。
|
||||
- `time` - 當地時區的時間：`01:23:23`。
|
||||
- `microseconds` - 微秒精度：`01:23:23.123123`。假定有時間。
|
||||
- `longfile` - 完整的文件名和行號：`/a/b/c/d.go:23`。
|
||||
- `shortfile` - 文件名的最後一個部分和行號：`d.go:23`。
|
||||
- `funcname` - 調用者的函數名：`runtime.Caller()`。
|
||||
- `shortfuncname` - 函數名的最後一部分。覆蓋 `funcname`。
|
||||
- `utc` - 如果設定了日期或時間，則使用 UTC 而不是本地時區。
|
||||
- `levelinitial` - 提供的級別的初始字符，放在方括號內，例如 `[I]` 表示 info。
|
||||
- `level` - 在方括號內的級別，例如 `[INFO]`。
|
||||
- `gopid` - 上下文的 Goroutine-PID。
|
||||
- `medfile` - 文件名的最後 20 個字符 - 相當於 `shortfile,longfile`。
|
||||
- `stdflags` - 相當於 `date,time,medfile,shortfuncname,levelinitial`。
|
||||
|
||||
### Console 模式
|
||||
|
||||
在此模式下，日誌記錄器將將日誌消息轉發到 Gitea 進程附加的 stdout 和 stderr 流。
|
||||
|
||||
對於 console 模式的日誌記錄器，如果不在 Windows 上，或者 Windows 終端可以設定為 ANSI 模式，或者是 cygwin 或 Msys 管道，則 `COLORIZE` 預設為 `true`。
|
||||
|
||||
設定：
|
||||
|
||||
- `STDERR`：**false**：日誌記錄器是否應將日誌打印到 `stderr` 而不是 `stdout`。
|
||||
|
||||
### File 模式
|
||||
|
||||
在此模式下，日誌記錄器將將日誌消息保存到文件中。
|
||||
|
||||
設定：
|
||||
|
||||
- `FILE_NAME`：要將日誌事件寫入的文件，相對於 `ROOT_PATH`，預設為 `%(ROOT_PATH)/gitea.log`。異常情況：訪問日誌預設為 `%(ROOT_PATH)/access.log`。
|
||||
- `MAX_SIZE_SHIFT`：**28**：單個文件的最大大小位移。28 表示 256Mb。詳細資訊見下文。
|
||||
- `LOG_ROTATE` **true**：是否輪轉日誌文件。
|
||||
- `DAILY_ROTATE`：**true**：是否每天旋轉日誌。
|
||||
- `MAX_DAYS`：**7**：在此天數之後刪除旋轉的日誌文件。
|
||||
- `COMPRESS`：**true**：預設情況下是否使用 gzip 壓縮舊的日誌文件。
|
||||
- `COMPRESSION_LEVEL`：**-1**：壓縮級別。詳細資訊見下文。
|
||||
|
||||
`MAX_SIZE_SHIFT` 通過將給定次數左移 1 (`1 << x`) 來定義文件的最大大小。
|
||||
在 v1.17.3 版本時的確切行為可以在[這裡](https://github.com/go-gitea/gitea/blob/v1.17.3/modules/setting/log.go#L185)中查看。
|
||||
|
||||
`COMPRESSION_LEVEL` 的有用值範圍從 1 到（包括）9，其中較高的數字表示更好的壓縮。
|
||||
請注意，更好的壓縮可能會帶來更高的資源使用。
|
||||
必須在前面加上 `-` 符號。
|
||||
|
||||
### Conn 模式
|
||||
|
||||
在此模式下，日誌記錄器將通過網路套接字發送日誌消息。
|
||||
|
||||
設定：
|
||||
|
||||
- `ADDR`：**:7020**：設定要連接的地址。
|
||||
- `PROTOCOL`：**tcp**：設定協議，可以是 "tcp"、"unix" 或 "udp"。
|
||||
- `RECONNECT`：**false**：在連接丟失時嘗試重新連接。
|
||||
- `RECONNECT_ON_MSG`：**false**：為每條消息重新連接主機。
|
||||
|
||||
### "Router" 日誌記錄器
|
||||
|
||||
當 Gitea 的路由處理程式工作時，Router 日誌記錄器記錄以下消息類型：
|
||||
|
||||
- `started` 消息將以 TRACE 級別記錄
|
||||
- `polling`/`completed` 路由將以 INFO 級別記錄。異常情況："/assets" 靜態資源請求也會以 TRACE 級別記錄。
|
||||
- `slow` 路由將以 WARN 級別記錄
|
||||
- `failed` 路由將以 WARN 級別記錄
|
||||
|
||||
### "XORM" 日誌記錄器
|
||||
|
||||
為了使 XORM 輸出 SQL 日誌，還應將 `[database]` 部分中的 `LOG_SQL` 設定為 `true`。
|
||||
|
||||
### "Access" 日誌記錄器
|
||||
|
||||
"Access" 日誌記錄器是自 Gitea 1.9 版本以來的新日誌記錄器。它提供了符合 NCSA Common Log 標準的日誌格式。雖然它具有高度可設定性，但在更改其模板時應謹慎。此日誌記錄器的主要好處是，Gitea 現在可以使用標準日誌格式記錄訪問日誌，因此可以使用標準工具進行分析。
|
||||
|
||||
您可以透過使用 `logger.access.MODE = ...` 來啟用此日誌記錄器。
|
||||
|
||||
如果需要，可以透過更改 `ACCESS_LOG_TEMPLATE` 的值來更改 "Access" 日誌記錄器的格式。
|
||||
|
||||
請注意，訪問日誌記錄器將以 `INFO` 級別記錄，將此日誌記錄器的 `LEVEL` 設定為 `WARN` 或更高級別將導致不記錄訪問日誌。
|
||||
|
||||
#### ACCESS_LOG_TEMPLATE
|
||||
|
||||
此值表示一個 Go 模板。其預設值為
|
||||
|
||||
```tmpl
|
||||
{{.Ctx.RemoteHost}} - {{.Identity}} {{.Start.Format "[02/Jan/2006:15:04:05 -0700]" }} "{{.Ctx.Req.Method}} {{.Ctx.Req.URL.RequestURI}} {{.Ctx.Req.Proto}}" {{.ResponseWriter.Status}} {{.ResponseWriter.Size}} "{{.Ctx.Req.Referer}}" "{{.Ctx.Req.UserAgent}}"`
|
||||
```
|
||||
|
||||
模板接收以下選項：
|
||||
|
||||
- `Ctx` 是 `context.Context`
|
||||
- `Identity` 是 `SignedUserName`，如果使用者未登入，則為 "-"
|
||||
- `Start` 是請求的開始時間
|
||||
- `ResponseWriter` 是 `http.ResponseWriter`
|
||||
|
||||
更改此模板時必須小心，因為它在標準的 panic 恢復陷阱之外運行。此模板應該儘可能簡單，因為它會為每個請求運行一次。
|
||||
|
||||
## 釋放和重新打開、暫停和恢復日誌記錄
|
||||
|
||||
如果您在 Unix 上運行，您可能希望釋放和重新打開日誌以使用 `logrotate` 或其他工具。
|
||||
可以透過向運行中的進程發送 `SIGUSR1` 信號或運行 `gitea manager logging release-and-reopen` 命令來強制 Gitea 釋放並重新打開其日誌文件和連接。
|
||||
|
||||
或者，您可能希望暫停和恢復日誌記錄 - 可以透過使用 `gitea manager logging pause` 和 `gitea manager logging resume` 命令來實現。請注意，當日志記錄暫停時，低於 INFO 級別的日誌事件將不會儲存，並且只會儲存有限數量的事件。在暫停時，日誌記錄可能會阻塞，儘管是暫時性的，但會大大減慢 Gitea 的運行速度，因此建議僅暫停很短的時間。
|
||||
|
||||
### 在 Gitea 運行時添加和刪除日誌記錄
|
||||
|
||||
可以使用 `gitea manager logging add` 和 `remove` 子命令在 Gitea 運行時添加和刪除日誌記錄。
|
||||
此功能只能調整正在運行的日誌系統，不能用於啟動未初始化的訪問或路由日誌記錄器。如果您希望啟動這些系統，建議調整 app.ini 並（優雅地）重新啟動 Gitea 服務。
|
||||
|
||||
這些命令的主要目的是在運行中的系統上輕鬆添加臨時日誌記錄器，以便調查問題，因為重新啟動可能會導致問題消失。
|
||||
|
||||
## 使用 `logrotate` 而不是內置的日誌輪轉
|
||||
|
||||
Gitea 包含內置的日誌輪轉功能，對於大多數部署來說應該已經足夠了。但是，如果您想使用 `logrotate` 工具：
|
||||
|
||||
- 在 `app.ini` 中將 `LOG_ROTATE` 設定為 `false`，禁用內置的日誌輪轉。
|
||||
- 安裝 `logrotate`。
|
||||
- 根據部署要求設定 `logrotate`，有關設定語法細節，請參閱 `man 8 logrotate`。
|
||||
在 `postrotate/endscript` 塊中通過 `kill -USR1` 或 `kill -10` 向 `gitea` 進程本身發送 `USR1` 信號，
|
||||
或者運行 `gitea manager logging release-and-reopen`（使用適當的環境設定）。
|
||||
確保設定適用於由 Gitea 日誌記錄器生成的所有文件，如上述部分所述。
|
||||
- 始終使用 `logrotate /etc/logrotate.conf --debug` 來測試您的設定。
|
||||
- 如果您正在使用 Docker 並從容器外部運行，您可以使用
|
||||
`docker exec -u $OS_USER $CONTAINER_NAME sh -c 'gitea manager logging release-and-reopen'`
|
||||
或 `docker exec $CONTAINER_NAME sh -c '/bin/s6-svc -1 /etc/s6/gitea/'`，或直接向 Gitea 進程本身發送 `USR1` 信號。
|
||||
|
||||
下一個 `logrotate` 作業將包括您的設定，因此不需要重新啟動。
|
||||
您還可以立即使用 `logrotate /etc/logrotate.conf --force` 重新加載 `logrotate`。
|
||||
+254
@@ -0,0 +1,254 @@
|
||||
---
|
||||
date: "2023-05-23T09:00:00+08:00"
|
||||
slug: "mail-templates"
|
||||
sidebar_position: 45
|
||||
aliases:
|
||||
- /zh-tw/mail-templates
|
||||
---
|
||||
|
||||
# 郵件模板
|
||||
|
||||
為了定製特定操作的電子郵件主題和內容，可以使用模板來自訂 Gitea。這些功能的模板位於 [`custom` 目錄](../administration/customizing-gitea.md) 下。
|
||||
如果沒有自訂的替代方案，Gitea 將使用內部模板作為預設模板。
|
||||
|
||||
自訂模板在 Gitea 啟動時加載。對它們的更改在 Gitea 重新啟動之前不會被識別。
|
||||
|
||||
## 支援模板的郵件通知
|
||||
|
||||
目前，以下通知事件使用模板：
|
||||
|
||||
| 操作名稱 | 用途 |
|
||||
| ---------- | ---------------------------------------------------------------------- |
|
||||
| `new` | 建立了新的工單或合併請求。 |
|
||||
| `comment` | 在現有工單或合併請求中建立了新的評論。 |
|
||||
| `close` | 關閉了工單或合併請求。 |
|
||||
| `reopen` | 重新打開了工單或合併請求。 |
|
||||
| `review` | 在合併請求中進行審查的首要評論。 |
|
||||
| `approve` | 對合併請求進行批准的首要評論。 |
|
||||
| `reject` | 對合併請求提出更改請求的審查的首要評論。 |
|
||||
| `code` | 關於合併請求的程式碼的單個評論。 |
|
||||
| `assigned` | 使用者被分配到工單或合併請求。 |
|
||||
| `default` | 未包括在上述類別中的任何操作，或者當對應類別的模板不存在時使用的模板。 |
|
||||
|
||||
特定消息類型的模板路徑為：
|
||||
|
||||
```sh
|
||||
custom/templates/mail/{操作類型}/{操作名稱}.tmpl
|
||||
```
|
||||
|
||||
其中 `{操作類型}` 是 `issue` 或 `pull`（針對合併請求），`{操作名稱}` 是上述列出的操作名稱之一。
|
||||
|
||||
例如，有關合併請求中的評論的電子郵件的特定模板是：
|
||||
|
||||
```sh
|
||||
custom/templates/mail/pull/comment.tmpl
|
||||
```
|
||||
|
||||
然而，並不需要為每個操作類型/名稱組合建立模板。
|
||||
使用回退系統來選擇適當的模板。在此列表中，將使用 _第一個存在的_ 模板：
|
||||
|
||||
- 所需**操作類型**和**操作名稱**的特定模板。
|
||||
- 操作類型為 `issue` 和所需**操作名稱**的模板。
|
||||
- 所需**操作類型**和操作名稱為 `default` 的模板。
|
||||
- 操作類型為` issue` 和操作名稱為 `default` 的模板。
|
||||
|
||||
唯一必需的模板是操作類型為 `issue` 操作名稱為 `default` 的模板，除非使用者在 `custom` 目錄中覆蓋了它。
|
||||
|
||||
## 模板語法
|
||||
|
||||
郵件模板是 UTF-8 編碼的文本文件，需要遵循以下格式之一：
|
||||
|
||||
```
|
||||
用於主題行的文本和宏
|
||||
------------
|
||||
用於郵件正文的文本和宏
|
||||
```
|
||||
|
||||
或者
|
||||
|
||||
```
|
||||
用於郵件正文的文本和宏
|
||||
```
|
||||
|
||||
指定 _主題_ 部分是可選的（因此也是虛線分隔符）。在使用時，_主題_ 和 _郵件正文_ 模板之間的分隔符需要至少三個虛線；分隔符行中不允許使用其他字符。
|
||||
|
||||
_主題_ 和 _郵件正文_ 由 [Golang 的模板引擎](https://go.dev/pkg/text/template/) 解析，並提供了為每個通知組裝的 _元資料上下文_。上下文包含以下元素：
|
||||
|
||||
| 名稱 | 類型 | 可用性 | 用途 |
|
||||
| ------------------ | ---------------- | -------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `.FallbackSubject` | string | 始終可用 | 預設主題行。參見下文。 |
|
||||
| `.Subject` | string | 僅在正文中可用 | 解析後的 _主題_。 |
|
||||
| `.Body` | string | 始終可用 | 工單、合併請求或評論的消息，從 Markdown 解析為 HTML 並進行了清理。請勿與 _郵件正文_ 混淆。 |
|
||||
| `.Link` | string | 始終可用 | 源工單、合併請求或評論的地址。 |
|
||||
| `.Issue` | models.Issue | 始終可用 | 產生通知的工單（或合併請求）。要獲取特定於合併請求的資料（例如 `HasMerged`），可以使用 `.Issue.PullRequest`，但需要注意，如果工單 _不是_ 合併請求，則該欄位將為 `nil`。 |
|
||||
| `.Comment` | models.Comment | 如果適用 | 如果通知是針對添加到工單或合併請求的評論，則其中包含有關評論的資訊。 |
|
||||
| `.IsPull` | bool | 始終可用 | 如果郵件通知與合併請求關聯（即 `.Issue.PullRequest` 不為 `nil` ），則為 `true`。 |
|
||||
| `.Repo` | string | 始終可用 | 儲存庫的名稱，包括所有者名稱（例如 `mike/stuff`） |
|
||||
| `.User` | models.User | 始終可用 | 事件來源儲存庫的所有者。要獲取使用者名稱（例如 `mike`），可以使用 `.User.Name`。 |
|
||||
| `.Doer` | models.User | 始終可用 | 執行觸發通知事件的操作的使用者。要獲取使用者名稱（例如 `rhonda`），可以使用 `.Doer.Name`。 |
|
||||
| `.IsMention` | bool | 始終可用 | 如果此通知僅是因為在評論中提到了使用者而生成的，並且收件人未訂閱源，則為 `true`。如果收件人已訂閱工單或儲存庫，則為 `false`。 |
|
||||
| `.SubjectPrefix` | string | 始終可用 | 如果通知是關於除工單或合併請求建立之外的其他內容，則為 `Re：`；否則為空字符串。 |
|
||||
| `.ActionType` | string | 始終可用 | `"issue"` 或 `"pull"`。它將與實際的 _操作類型_ 對應，與選擇的模板無關。 |
|
||||
| `.ActionName` | string | 始終可用 | 它將是上述操作類型之一（`new` ，`comment` 等），並與選擇的模板對應。 |
|
||||
| `.ReviewComments` | []models.Comment | 始終可用 | 審查中的程式碼評論列表。評論文本將在 `.RenderedContent` 中，引用的程式碼將在 `.Patch` 中。 |
|
||||
|
||||
所有名稱區分大小寫。
|
||||
|
||||
### 模板中的主題部分
|
||||
|
||||
用於郵件主題的模板引擎是 Golang 的 [`text/template`](https://go.dev/pkg/text/template/)。
|
||||
有關語法的詳細資訊，請參閱鏈接的文件。
|
||||
|
||||
主題構建的步驟如下：
|
||||
|
||||
- 根據通知類型和可用的模板選擇一個模板。
|
||||
- 解析並解析模板（例如，將 `{{.Issue.Index}}` 轉換為工單或合併請求的編號）。
|
||||
- 將所有空格字符（例如 `TAB`，`LF` 等）轉換為普通空格。
|
||||
- 刪除所有前導、尾隨和多餘的空格。
|
||||
- 將字符串截斷為前 256 個字母（字符）。
|
||||
|
||||
如果最終結果為空字符串，**或者**沒有可用的主題模板（即所選模板不包含主題部分），將使用 Gitea 的**內部預設值**。
|
||||
|
||||
內部預設（回退）主題相當於：
|
||||
|
||||
```
|
||||
{{.SubjectPrefix}}[{{.Repo}}] {{.Issue.Title}} (#{{.Issue.Index}})
|
||||
```
|
||||
|
||||
例如：`Re: [mike/stuff] New color palette (#38)`
|
||||
|
||||
即使存在有效的主題模板，Gitea 的預設主題也可以在模板的元資料中作為 `.FallbackSubject` 找到。
|
||||
|
||||
### 模板中的郵件正文部分
|
||||
|
||||
用於郵件正文的模板引擎是 Golang 的 [`html/template`](https://go.dev/pkg/html/template/)。
|
||||
有關語法的詳細資訊，請參閱鏈接的文件。
|
||||
|
||||
郵件正文在郵件主題之後進行解析，因此還有一個額外的 _元資料_ 欄位，即在考慮所有情況之後實際呈現的主題。
|
||||
|
||||
期望的結果是 HTML（包括結構元素，如`<html>`，`<body>`等）。可以透過 `<style>` 塊、`class` 和 `style` 屬性進行樣式設定。但是，`html/template` 會進行一些 [自動轉義](https://go.dev/pkg/html/template/#hdr-Contexts)，需要考慮這一點。
|
||||
|
||||
不支援附件（例如圖像或外部樣式表）。但是，也可以引用其他模板，例如以集中方式提供 `<style>` 元素的內容。外部模板必須放置在 `custom/mail` 下，並相對於該目錄引用。例如，可以使用 `{{template styles/base}}` 包含 `custom/mail/styles/base.tmpl`。
|
||||
|
||||
郵件以 `Content-Type: multipart/alternative` 發送，因此正文以 HTML 和文本格式發送。通過剝離 HTML 標記來獲取文本版本。
|
||||
|
||||
## 故障排除
|
||||
|
||||
郵件的呈現方式直接取決於郵件應用程式的功能。許多郵件客戶端甚至不支援 HTML，因此顯示生成郵件中包含的文本版本。
|
||||
|
||||
如果模板無法呈現，則只有在發送郵件時纔會注意到。
|
||||
如果主題模板失敗，將使用預設主題，如果從 _郵件正文_ 中成功呈現了任何內容，則將使用該內容，忽略其他內容。
|
||||
|
||||
如果遇到問題，請檢查 [Gitea 的日誌](../administration/logging-config.md) 以獲取錯誤消息。
|
||||
|
||||
## 範例
|
||||
|
||||
`custom/templates/mail/issue/default.tmpl`:
|
||||
|
||||
```html
|
||||
[{{.Repo}}] @{{.Doer.Name}}
|
||||
{{if eq .ActionName "new"}}
|
||||
創建了
|
||||
{{else if eq .ActionName "comment"}}
|
||||
評論了
|
||||
{{else if eq .ActionName "close"}}
|
||||
關閉了
|
||||
{{else if eq .ActionName "reopen"}}
|
||||
重新打開了
|
||||
{{else}}
|
||||
更新了
|
||||
{{end}}
|
||||
{{if eq .ActionType "issue"}}
|
||||
工單
|
||||
{{else}}
|
||||
合併請求
|
||||
{{end}}
|
||||
#{{.Issue.Index}}: {{.Issue.Title}}
|
||||
------------
|
||||
<!DOCTYPE html>
|
||||
<html>
|
||||
<head>
|
||||
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
|
||||
<title>{{.Subject}}</title>
|
||||
</head>
|
||||
|
||||
<body>
|
||||
{{if .IsMention}}
|
||||
<p>
|
||||
您收到此郵件是因為 @{{.Doer.Name}} 提到了您。
|
||||
</p>
|
||||
{{end}}
|
||||
<p>
|
||||
<p>
|
||||
<a href="{{AppUrl}}/{{.Doer.LowerName}}">@{{.Doer.Name}}</a>
|
||||
{{if not (eq .Doer.FullName "")}}
|
||||
({{.Doer.FullName}})
|
||||
{{end}}
|
||||
{{if eq .ActionName "new"}}
|
||||
創建了
|
||||
{{else if eq .ActionName "close"}}
|
||||
關閉了
|
||||
{{else if eq .ActionName "reopen"}}
|
||||
重新打開了
|
||||
{{else}}
|
||||
更新了
|
||||
{{end}}
|
||||
<a href="{{.Link}}">{{.Repo}}#{{.Issue.Index}}</a>。
|
||||
</p>
|
||||
{{if not (eq .Body "")}}
|
||||
<h3>消息內容：</h3>
|
||||
<hr>
|
||||
{{.Body}}
|
||||
{{end}}
|
||||
</p>
|
||||
<hr>
|
||||
<p>
|
||||
<a href="{{.Link}}">在 Gitea 上查看</a>。
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
```
|
||||
|
||||
該模板將生成以下內容：
|
||||
|
||||
### 主題
|
||||
|
||||
> [mike/stuff] @rhonda 在合併請求 #38 上進行了評論：New color palette
|
||||
|
||||
### 郵件正文
|
||||
|
||||
> [@rhonda](#)（Rhonda Myers）更新了 [mike/stuff#38](#)。
|
||||
>
|
||||
> #### 消息內容
|
||||
>
|
||||
> \_**************\*\*\*\***************\_**************\*\*\*\***************
|
||||
>
|
||||
> Mike, I think we should tone down the blues a little.
|
||||
>
|
||||
> \_**************\*\*\*\***************\_**************\*\*\*\***************
|
||||
>
|
||||
> [在 Gitea 上查看](#)。
|
||||
|
||||
## 高級用法
|
||||
|
||||
模板系統包含一些函數，可用於進一步處理和格式化消息。以下是其中一些函數的列表：
|
||||
|
||||
| 函數名 | 參數 | 可用於 | 用法 |
|
||||
| ---------------- | ----------- | ---------- | ------------------------------------------------ |
|
||||
| `AppUrl` | - | 任何地方 | Gitea 的 URL |
|
||||
| `AppName` | - | 任何地方 | 從 `app.ini` 中設定，通常為 "Gitea" |
|
||||
| `AppDomain` | - | 任何地方 | Gitea 的主機名 |
|
||||
| `EllipsisString` | string, int | 任何地方 | 將字符串截斷為指定長度；根據需要添加省略號 |
|
||||
| `SanitizeHTML` | string | 僅正文部分 | 通過刪除其中的危險 HTML 標籤對文本進行清理 |
|
||||
| `SafeHTML` | string | 僅正文部分 | 將輸入作為 HTML 處理；可用於輸出原始的 HTML 內容 |
|
||||
|
||||
這些都是 _函數_，而不是元資料，因此必須按以下方式使用：
|
||||
|
||||
```html
|
||||
像這樣使用： {{SanitizeHTML "Escape<my
|
||||
>text"}} 或者這樣使用： {{"Escape<my
|
||||
>text" | SanitizeHTML}} 或者這樣使用： {{AppUrl}} 但不要像這樣使用：
|
||||
{{.AppUrl}}</my
|
||||
></my
|
||||
>
|
||||
```
|
||||
@@ -0,0 +1,50 @@
|
||||
---
|
||||
date: "2023-05-23T09:00:00+08:00"
|
||||
slug: "repo-indexer"
|
||||
sidebar_position: 45
|
||||
aliases:
|
||||
- /zh-tw/repo-indexer
|
||||
---
|
||||
|
||||
# 儲存庫索引器
|
||||
|
||||
## 設定儲存庫索引器
|
||||
|
||||
通過在您的 [`app.ini`](../administration/config-cheat-sheet.md) 中啟用此功能，Gitea 可以透過儲存庫的文件進行搜索：
|
||||
|
||||
```ini
|
||||
[indexer]
|
||||
; ...
|
||||
REPO_INDEXER_ENABLED = true
|
||||
REPO_INDEXER_PATH = indexers/repos.bleve
|
||||
MAX_FILE_SIZE = 1048576
|
||||
REPO_INDEXER_INCLUDE =
|
||||
REPO_INDEXER_EXCLUDE = resources/bin/**
|
||||
```
|
||||
|
||||
請記住，索引內容可能會消耗大量系統資源，特別是在首次建立索引或全域更新索引時（例如升級 Gitea 之後）。
|
||||
|
||||
### 按大小選擇要索引的文件
|
||||
|
||||
`MAX_FILE_SIZE` 選項將使索引器跳過所有大於指定值的文件。
|
||||
|
||||
### 按路徑選擇要索引的文件
|
||||
|
||||
Gitea 使用 [`gobwas/glob` 庫](https://github.com/gobwas/glob) 中的 glob 模式匹配來選擇要包含在索引中的文件。
|
||||
|
||||
限制文件列表可以防止索引被派生或無關的文件（例如 lss、sym、map 等）污染，從而使搜索結果更相關。這還有助於減小索引的大小。
|
||||
|
||||
`REPO_INDEXER_EXCLUDE_VENDORED`（預設值為 true）將排除供應商文件不包含在索引中。
|
||||
|
||||
`REPO_INDEXER_INCLUDE`（預設值為空）是一個逗號分隔的 glob 模式列表，用於在索引中**包含**的文件。空列表表示“_包含所有文件_”。
|
||||
`REPO_INDEXER_EXCLUDE`（預設值為空）是一個逗號分隔的 glob 模式列表，用於從索引中**排除**的文件。與該列表匹配的文件將不會被索引。`REPO_INDEXER_EXCLUDE` 優先於 `REPO_INDEXER_INCLUDE`。
|
||||
|
||||
模式匹配工作方式如下：
|
||||
|
||||
- 要匹配所有帶有 `.txt` 擴展名的文件，無論在哪個目錄中，請使用 `**.txt`。
|
||||
- 要匹配僅在儲存庫的根級別中具有 `.txt` 擴展名的所有文件，請使用 `*.txt`。
|
||||
- 要匹配 `resources/bin` 目錄及其子目錄中的所有文件，請使用 `resources/bin/**`。
|
||||
- 要匹配位於 `resources/bin` 目錄下的所有文件，請使用 `resources/bin/*`。
|
||||
- 要匹配所有名為 `Makefile` 的文件，請使用 `**Makefile`。
|
||||
- 匹配目錄沒有效果；模式 `resources/bin` 不會包含/排除該目錄中的文件；`resources/bin/**` 會。
|
||||
- 所有文件和模式都規範化為小寫，因此 `**Makefile`、`**makefile` 和 `**MAKEFILE` 是等效的。
|
||||
+454
@@ -0,0 +1,454 @@
|
||||
---
|
||||
date: "2018-05-22T11:00:00+00:00"
|
||||
slug: "reverse-proxies"
|
||||
sidebar_position: 16
|
||||
aliases:
|
||||
- /zh-tw/reverse-proxies
|
||||
---
|
||||
|
||||
# 反向代理
|
||||
|
||||
## 通用設定
|
||||
|
||||
1. 在您的 `app.ini` 文件中添加設定 `[server] ROOT_URL = https://git.example.com/`
|
||||
2. 將 `https://git.example.com/foo` 反向代理到 `http://gitea:3000/foo`
|
||||
3. 確保反向代理不會解碼 URI。`https://git.example.com/a%2Fb`的請求應該被傳遞給 `http://gitea:3000/a%2Fb`。
|
||||
4. 確保 `Host` 和 `X-Forwarded-Proto` 頭被正確的傳遞給 Gitea，使 Gitea 可以看到正在訪問的真實 URL。
|
||||
5. 確保 Web 伺服器有完整的憑證（包括所有中間憑證和根憑證），以便 `git clone` 和 `git pull` 正常工作。
|
||||
6. Gitea 會在 `/-/ws` 使用 WebSocket 連線，用於通知計數等即時更新。請確保反向代理使用 HTTP/1.1，並轉發 `Upgrade` 和 `Connection` 頭，參見下面的示例。否則 Gitea 會改為定期輪詢。
|
||||
|
||||
## 使用子路徑
|
||||
|
||||
通常，**不推薦**將 Gitea 放到子路徑。人們很少使用此設定，並且在極少數情況下可能會出現一些問題。
|
||||
|
||||
為了讓 Gitea 在子路徑工作（例如：`https://common.example.com/gitea/`），需要在上面的通用設定之外進行一些額外的設定：
|
||||
|
||||
1. 在 `app.ini` 文件中使用設定 `[server] ROOT_URL = https://common.example.com/gitea/`。
|
||||
2. 將 `https://common.example.com/gitea/foo` 反向代理到 `http://gitea:3000/foo`。
|
||||
3. 容器映像註冊表需要在根目錄級別有一個固定的子路徑 `v2`，您必須做下列設定：
|
||||
- 將 `https://common.example.com/v2` 反向代理到 `http://gitea:3000/v2`。
|
||||
- 確保 URI 和標頭也被正確的傳遞（見上面的通用設定）
|
||||
|
||||
## 使用 Nginx 作為反向代理服務
|
||||
|
||||
如果您想使用 Nginx 作為 Gitea 的反向代理服務，您可以參照以下 `nginx.conf` 設定中 `server` 的 `http` 部分。
|
||||
|
||||
確保 `client_max_body_size` 足夠大，否則在上傳大文件時會出現 "client_max_body_size" 錯誤。
|
||||
|
||||
```nginx
|
||||
server {
|
||||
...
|
||||
location / {
|
||||
client_max_body_size 512M;
|
||||
proxy_pass http://localhost:3000;
|
||||
proxy_http_version 1.1;
|
||||
proxy_set_header Connection $http_connection;
|
||||
proxy_set_header Upgrade $http_upgrade;
|
||||
proxy_set_header Host $host;
|
||||
proxy_set_header X-Real-IP $remote_addr;
|
||||
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
|
||||
proxy_set_header X-Forwarded-Proto $scheme;
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## 使用 Nginx 作為反向代理服務並將 Gitea 路由至一個子路徑
|
||||
|
||||
如果您已經有一個域名並且想與 Gitea 共享該域名，您可以增加以下 `nginx.conf` 設定中 `server` 的 `http` 部分，為 Gitea 添加路由規則：
|
||||
|
||||
```nginx
|
||||
server {
|
||||
...
|
||||
location ~ ^/(gitea|v2)($|/) {
|
||||
client_max_body_size 512M;
|
||||
|
||||
# 確保 nginx 使用未轉義 URI， 按原樣保持 "%2F"。 確保 nginx 去除 "/gitea" 子路徑前綴， 按原樣傳遞 "/v2"。
|
||||
rewrite ^ $request_uri;
|
||||
rewrite ^/(gitea($|/))?(.*) /$3 break;
|
||||
proxy_pass http://127.0.0.1:3000$uri;
|
||||
proxy_http_version 1.1;
|
||||
|
||||
# 其他的常規 HTTP 表頭，見上面“使用 Nginx 作為反向代理服務”小節的配置
|
||||
proxy_set_header Connection $http_connection;
|
||||
proxy_set_header Upgrade $http_upgrade;
|
||||
proxy_set_header Host $host;
|
||||
proxy_set_header X-Real-IP $remote_addr;
|
||||
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
|
||||
proxy_set_header X-Forwarded-Proto $scheme;
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
然後您**必須**在 Gitea 的設定文件中正確的添加類似 `[server] ROOT_URL = http://git.example.com/git/` 的設定項。
|
||||
|
||||
## 使用 Nginx 直接提供靜態資源
|
||||
|
||||
我們可以透過將資源分為靜態和動態兩種類型來調節性能。
|
||||
|
||||
CSS 文件、JavaScript 文件、圖片和字體是靜態內容。首頁、儲存庫視圖和工單列表是動態內容。
|
||||
|
||||
Nginx 可以直接提供靜態資源，並且只代理動態資源請求給 Gitea。
|
||||
Nginx 為提供靜態內容進行了優化，而代理大響應可能與這一優化行為相反。
|
||||
（見[https://serverfault.com/q/587386](https://serverfault.com/q/587386)）
|
||||
|
||||
將 Gitea 源程式碼儲存庫的一個快照下載到 `/path/to/gitea`。
|
||||
在此之後，在本地儲存庫目錄運行 `make frontend` 來生成靜態資源。在這個情況下，我們只對 `public/` 目錄感興趣，您可以刪除剩下的其他目錄。
|
||||
（為了生成靜態資源，您需要安裝一個[帶 npm 的 Node ](https://nodejs.org/en/download/)和 `make`）
|
||||
|
||||
取決於您的使用者量的大小，您可以將流量分離到兩個不同的伺服器，或者為靜態資源設定一個 cdn。
|
||||
|
||||
### 單伺服器節點，單域名
|
||||
|
||||
將 `[server] STATIC_URL_PREFIX = /_/static` 寫入您的 Gitea 設定文件，並設定 nginx：
|
||||
|
||||
```nginx
|
||||
server {
|
||||
listen 80;
|
||||
server_name git.example.com;
|
||||
|
||||
location /_/static/assets/ {
|
||||
alias /path/to/gitea/public/;
|
||||
}
|
||||
|
||||
location / {
|
||||
# 其他指令見上面「使用 Nginx 作為反向代理服務」小節
|
||||
proxy_pass http://localhost:3000;
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### 雙伺服器節點，雙域名
|
||||
|
||||
將 `[server] STATIC_URL_PREFIX = http://cdn.example.com/gitea` 寫入您的 Gitea 設定文件，並設定 nginx：
|
||||
|
||||
```nginx
|
||||
# 運行 Gitea 的服務器
|
||||
server {
|
||||
listen 80;
|
||||
server_name git.example.com;
|
||||
|
||||
location / {
|
||||
# 其他指令見上面「使用 Nginx 作為反向代理服務」小節
|
||||
proxy_pass http://localhost:3000;
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
```nginx
|
||||
# 提供靜態資源的服務器
|
||||
server {
|
||||
listen 80;
|
||||
server_name cdn.example.com;
|
||||
|
||||
location /gitea/ {
|
||||
alias /path/to/gitea/public/;
|
||||
}
|
||||
|
||||
location / {
|
||||
return 404;
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Nginx Proxy Manager
|
||||
|
||||
如果使用 Nginx Proxy Manager 作為 Gitea 的反向代理，設定與原生 Nginx 略有不同。
|
||||
|
||||
它會[預設給自訂 location 加上一些指令](https://github.com/NginxProxyManager/nginx-proxy-manager/blob/master/docker/rootfs/etc/nginx/conf.d/include/proxy.conf)，因此上面 Nginx 設定裡對應的指令不要再寫一遍。否則會因為指令重複（尤其是 `proxy_set_header Host $host`）出現 `400 bad request`。
|
||||
|
||||
建立 `/` 自訂 location 時，只需在其設定中加入：
|
||||
|
||||
```nginx
|
||||
client_max_body_size 512M;
|
||||
```
|
||||
|
||||
在代理主機上啟用 `Websockets Support`，Nginx Proxy Manager 會自行加入 WebSocket 相關指令。再額外添加 `proxy_http_version` 會導致 Nginx 拒絕啟動。
|
||||
|
||||
## 使用 Apache HTTPD 作為反向代理服務
|
||||
|
||||
如果您想使用 Apache HTTPD 作為 Gitea 的反向代理服務，您可以為您的 Apache HTTPD 作如下設定（在 Ubuntu 中，設定文件通常在 `/etc/apache2/httpd.conf` 目錄下）：
|
||||
|
||||
```apacheconf
|
||||
<VirtualHost *:80>
|
||||
...
|
||||
ProxyPreserveHost On
|
||||
ProxyRequests off
|
||||
AllowEncodedSlashes NoDecode
|
||||
ProxyPass / http://localhost:3000/ nocanon upgrade=websocket
|
||||
RequestHeader set "X-Forwarded-Proto" expr=%{REQUEST_SCHEME}
|
||||
</VirtualHost>
|
||||
```
|
||||
|
||||
:::note
|
||||
必須啟用以下 Apache HTTPD 元件：`proxy`， `proxy_http`。
|
||||
|
||||
`upgrade=websocket` 需要 Apache HTTPD 2.4.48 或更高版本。更舊的版本**必須**去掉它，否則 Apache HTTPD 將無法啟動。
|
||||
:::
|
||||
|
||||
如果希望用 Let's Encrypt 的 webroot 驗證，請在 `ProxyPass` 之前加入 `ProxyPass /.well-known !`，避免把這些請求代理到 Gitea。
|
||||
|
||||
## 使用 Apache HTTPD 作為反向代理服務並將 Gitea 路由至一個子路徑
|
||||
|
||||
如果您已經有一個域名並且想與 Gitea 共享該域名，您可以增加以下設定為 Gitea 添加路由規則（在 Ubuntu 中，設定文件通常在 `/etc/apache2/httpd.conf` 目錄下）：
|
||||
|
||||
```apacheconf
|
||||
<VirtualHost *:80>
|
||||
...
|
||||
<Proxy *>
|
||||
Order allow,deny
|
||||
Allow from all
|
||||
</Proxy>
|
||||
AllowEncodedSlashes NoDecode
|
||||
# 注意: 路徑和 URL 後面都不要寫路徑符號 '/'
|
||||
ProxyPass /git http://localhost:3000 nocanon upgrade=websocket
|
||||
ProxyPreserveHost On
|
||||
RequestHeader set "X-Forwarded-Proto" expr=%{REQUEST_SCHEME}
|
||||
</VirtualHost>
|
||||
```
|
||||
|
||||
然後您**必須**在 Gitea 的設定文件中正確的添加類似 `[server] ROOT_URL = http://git.example.com/git/` 的設定項。
|
||||
|
||||
:::note
|
||||
必須啟用以下 Apache HTTPD 元件：`proxy`， `proxy_http`。`upgrade=websocket` 需要 Apache HTTPD 2.4.48 或更高版本，更舊的版本請去掉它。
|
||||
:::
|
||||
|
||||
## 使用 Apache HTTPD 直接提供靜態資源
|
||||
|
||||
我們可以通過將資源分為靜態和動態兩種類型來調節性能。
|
||||
|
||||
CSS 文件、JavaScript 文件、圖片和字體是靜態內容。首頁、倉庫視圖和工單列表是動態內容。
|
||||
|
||||
Apache HTTPD 可以直接提供靜態資源，並且只代理動態資源請求給 Gitea。
|
||||
|
||||
將 Gitea 源代碼倉庫的一個快照下載到 `/path/to/gitea/`。
|
||||
在此之後，在本地倉庫目錄運行 `make frontend` 來生成靜態資源。在這個情況下，我們只對 `public/` 目錄感興趣，您可以刪除剩下的其他目錄。
|
||||
（為了生成靜態資源，您需要安裝一個[帶 npm 的 Node ](https://nodejs.org/en/download/)和 `make`）
|
||||
|
||||
取決於您的用戶量的大小，您可以將流量分離到兩個不同的服務器，或者為靜態資源設定一個 cdn。
|
||||
|
||||
### 單伺服器節點，單域名
|
||||
|
||||
將 `[server] STATIC_URL_PREFIX = /_/static` 寫入您的 Gitea 設定文件：
|
||||
|
||||
```apacheconf
|
||||
<VirtualHost *:80>
|
||||
...
|
||||
<Proxy *>
|
||||
Order allow,deny
|
||||
Allow from all
|
||||
</Proxy>
|
||||
|
||||
ProxyPass /_/static/ !
|
||||
Alias /_/static/ /path/to/gitea/public/
|
||||
<Directory /path/to/gitea/public/>
|
||||
Options FollowSymlinks
|
||||
AllowOverride None
|
||||
Require all granted
|
||||
</Directory>
|
||||
|
||||
AllowEncodedSlashes NoDecode
|
||||
# 注意: 路徑和 URL 後面都不要寫路徑符號 '/'
|
||||
ProxyPass / http://localhost:3000/ nocanon upgrade=websocket
|
||||
ProxyPreserveHost On
|
||||
RequestHeader set "X-Forwarded-Proto" expr=%{REQUEST_SCHEME}
|
||||
</VirtualHost>
|
||||
```
|
||||
|
||||
:::note
|
||||
必須啟用以下 Apache HTTPD 元件：`proxy`， `proxy_http`。`upgrade=websocket` 需要 Apache HTTPD 2.4.48 或更高版本，更舊的版本請去掉它。
|
||||
:::
|
||||
|
||||
## 使用 Caddy 作為反向代理服務
|
||||
|
||||
如果您想使用 Caddy 作為 Gitea 的反向代理服務，您可以在 `Caddyfile` 中添加如下設定：
|
||||
|
||||
```
|
||||
git.example.com {
|
||||
reverse_proxy localhost:3000
|
||||
}
|
||||
```
|
||||
|
||||
## 使用 Caddy 作為反向代理服務並將 Gitea 路由至一個子路徑
|
||||
|
||||
如果您已經有一個域名並且想與 Gitea 共享該域名，您可以在您的 `Caddyfile` 文件中增加以下設定，為 Gitea 添加路由規則：
|
||||
|
||||
```
|
||||
git.example.com {
|
||||
route /git/* {
|
||||
uri strip_prefix /git
|
||||
reverse_proxy localhost:3000
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
然後您**必須**在 Gitea 的設定文件中正確的添加類似 `[server] ROOT_URL = http://git.example.com/git/` 的設定項。
|
||||
|
||||
## 使用 IIS 作為反向代理服務
|
||||
|
||||
如果您想使用 IIS 作為 Gitea 的反向代理服務，你需要為 IIS 設定 URL 重寫來作為反向代理。
|
||||
|
||||
1. 在 IIS 中設定一個空網頁，比如命名為 `Gitea Proxy`。
|
||||
2. 根據[微軟社區中為 IIS 設定 URL 重寫的指南](https://techcommunity.microsoft.com/t5/iis-support-blog/setup-iis-with-url-rewrite-as-a-reverse-proxy-for-real-world/ba-p/846222#M343)的前兩步進行設定，也就是：
|
||||
|
||||
- 使用 Microsoft Web Platform Installer 5.1 (WebPI) 安裝 Application Request Routing（簡稱 ARR），或者在 [IIS.net](https://www.iis.net/downloads/microsoft/application-request-routing) 下載這個外掛。
|
||||
- 一但這個模組被安裝到 IIS 上，你將會在 IIS 管理控制檯看到一個叫做 URL Rewrite 的新圖標。
|
||||
- 安裝 Windows 功能 `WebSocket Protocol`，否則 ARR 無法代理 Gitea 的 WebSocket 端點。
|
||||
- 打開 IIS 管理控制檯，在左邊的列表中點擊 `Gitea Proxy` 網頁。在中間選中並且雙擊 URL Rewrite 的圖標來加載 URL 重寫的面板。
|
||||
- 在管理控制檯的右邊選擇 `Add Rule` 操作，並且在 `Inbound and Outbound Rules` 分類中選擇 `Reverse Proxy Rule`。
|
||||
- 在 Inbound Rules 中， 將 server name 設定為 Gitea 正在運行的主機以及對應端口。例如，如果你在 localhost 的 3000 端口上運行 Gitea，則設定為 `127.0.0.1:3000`。
|
||||
- 啟用 SSL Offloading
|
||||
- 在 Outbound Rules 中，確保設定了 `Rewrite the domain names of the links in HTTP response`，並且將 `From:` 設定為上面的 server name，將 `To:` 設定為你的外部訪問名稱，例如：`git.example.com`
|
||||
- 關閉 Application Request Routing 的 `Server Proxy Settings` 中的 `Reverse rewrite host in response headers`（在 IIS 管理員中選擇伺服器節點，打開 `Application Request Routing Cache`，再開啟右側的 `Server Proxy Settings`）。若保持開啟，ARR 會把 `Location` 頭裡的主機改回內部位址，導致登入或表單提交後的重新導向把瀏覽器送到 `127.0.0.1:3000` 而不是 `git.example.com`。
|
||||
- 現在，根據下面的內容為您的網頁編輯 `web.config`（將 `127.0.0.1:3000` 和 `git.example.com` 改為適當的值）
|
||||
|
||||
```xml
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<configuration>
|
||||
<system.web>
|
||||
<httpRuntime requestPathInvalidCharacters="" />
|
||||
</system.web>
|
||||
<system.webServer>
|
||||
<security>
|
||||
<requestFiltering>
|
||||
<hiddenSegments>
|
||||
<clear />
|
||||
</hiddenSegments>
|
||||
<denyUrlSequences>
|
||||
<clear />
|
||||
</denyUrlSequences>
|
||||
<fileExtensions allowUnlisted="true">
|
||||
<clear />
|
||||
</fileExtensions>
|
||||
</requestFiltering>
|
||||
</security>
|
||||
<rewrite>
|
||||
<rules useOriginalURLEncoding="false">
|
||||
<rule name="ReverseProxyInboundRule1" stopProcessing="true">
|
||||
<match url="(.*)" />
|
||||
<action type="Rewrite" url="http://127.0.0.1:3000{UNENCODED_URL}" />
|
||||
<serverVariables>
|
||||
<set name="HTTP_X_ORIGINAL_ACCEPT_ENCODING" value="HTTP_ACCEPT_ENCODING" />
|
||||
<set name="HTTP_ACCEPT_ENCODING" value="" />
|
||||
</serverVariables>
|
||||
</rule>
|
||||
</rules>
|
||||
<outboundRules>
|
||||
<rule name="ReverseProxyOutboundRule1" preCondition="ResponseIsHtml1">
|
||||
<!-- set the pattern correctly here - if you only want to accept http or https -->
|
||||
<!-- change the pattern and the action value as appropriate -->
|
||||
<match filterByTags="A, Form, Img" pattern="^http(s)?://127.0.0.1:3000/(.*)" />
|
||||
<action type="Rewrite" value="http{R:1}://git.example.com/{R:2}" />
|
||||
</rule>
|
||||
<rule name="RestoreAcceptEncoding" preCondition="NeedsRestoringAcceptEncoding">
|
||||
<match serverVariable="HTTP_ACCEPT_ENCODING" pattern="^(.*)" />
|
||||
<action type="Rewrite" value="{HTTP_X_ORIGINAL_ACCEPT_ENCODING}" />
|
||||
</rule>
|
||||
<preConditions>
|
||||
<preCondition name="ResponseIsHtml1">
|
||||
<add input="{RESPONSE_CONTENT_TYPE}" pattern="^text/html" />
|
||||
</preCondition>
|
||||
<preCondition name="NeedsRestoringAcceptEncoding">
|
||||
<add input="{HTTP_X_ORIGINAL_ACCEPT_ENCODING}" pattern=".+" />
|
||||
</preCondition>
|
||||
</preConditions>
|
||||
</outboundRules>
|
||||
</rewrite>
|
||||
<urlCompression doDynamicCompression="true" />
|
||||
<handlers>
|
||||
<clear />
|
||||
<add name="StaticFile" path="*" verb="*" modules="StaticFileModule,DefaultDocumentModule,DirectoryListingModule" resourceType="Either" requireAccess="Read" />
|
||||
</handlers>
|
||||
<!-- Map all extensions to the same MIME type, so all files can be
|
||||
downloaded. -->
|
||||
<staticContent>
|
||||
<clear />
|
||||
<mimeMap fileExtension="*" mimeType="application/octet-stream" />
|
||||
</staticContent>
|
||||
</system.webServer>
|
||||
</configuration>
|
||||
```
|
||||
|
||||
## 使用 HAProxy 作為反向代理服務
|
||||
|
||||
如果您想使用 HAProxy 作為 Gitea 的反向代理服務，您可以將下面的內容加入您的 HAProxy 設定。
|
||||
|
||||
在 frontend 部分加入一個 acl 來將對 gitea.example.com 的請求重定向到正確的後端。
|
||||
|
||||
```
|
||||
frontend http-in
|
||||
...
|
||||
acl acl_gitea hdr(host) -i gitea.example.com
|
||||
use_backend gitea if acl_gitea
|
||||
...
|
||||
```
|
||||
|
||||
添加之前定義好的 backend 部分
|
||||
|
||||
```
|
||||
backend gitea
|
||||
server localhost:3000 check
|
||||
```
|
||||
|
||||
如果您將 http 內容重定向到 https，上面的設定文件也能夠使用。只需要記住，在 HAProxy 和 Gitea 之間的連接將由 http 完成，所以你不需要在 Gitea 的設定文件中啟用 https。
|
||||
|
||||
## 使用 HAProxy 作為反向代理服務並將 Gitea 路由至一個子路徑
|
||||
|
||||
如果您已經有一個域名並且想與 Gitea 共享該域名，您可以在您的 HAProxy 中加入如下設定，為 Gitea 添加路由規則：
|
||||
|
||||
```
|
||||
frontend http-in
|
||||
...
|
||||
acl acl_gitea path_beg /gitea
|
||||
use_backend gitea if acl_gitea
|
||||
...
|
||||
```
|
||||
|
||||
在這個設定下，http://example.com/gitea/ 將被重定向到您的 Gitea 實例。
|
||||
|
||||
接下來，對於 backend 部分：
|
||||
|
||||
```
|
||||
backend gitea
|
||||
http-request replace-path /gitea\/?(.*) \/\1
|
||||
server localhost:3000 check
|
||||
```
|
||||
|
||||
添加的 http-request 在需要的時候會自動加入反斜槓/，並且通過將 http://example.com/gitea 正確設定為根來在內部路徑中刪除 /gitea，使其能夠正常工作。
|
||||
|
||||
然後您**必須**在 Gitea 的設定文件中正確的添加類似 `[server] ROOT_URL = http://example.com/gitea/` 的設定項。
|
||||
|
||||
## 使用 Traefik 作為反向代理服務
|
||||
|
||||
如果您想使用 traefik 作為 Gitea 的反向代理服務，您可以在 `docker-compose.yaml` 中添加 label 部分（假設使用 docker 作為 traefik 的 provider）：
|
||||
|
||||
```yaml
|
||||
gitea:
|
||||
image: docker.io/gitea/gitea
|
||||
...
|
||||
labels:
|
||||
- "traefik.enable=true"
|
||||
- "traefik.http.routers.gitea.rule=Host(`example.com`)"
|
||||
- "traefik.http.services.gitea-websecure.loadbalancer.server.port=3000"
|
||||
```
|
||||
|
||||
這份設定假設您使用 traefik 來處理 HTTPS 服務，並在其和 Gitea 之間使用 HTTP 進行通信。
|
||||
|
||||
## 使用 Traefik 作為反向代理服務並將 Gitea 路由至一個子路徑
|
||||
|
||||
如果您已經有一個域名並且想與 Gitea 共享該域名，您可以在您的 `docker-compose.yaml` 文件中增加以下設定，為 Gitea 添加路由規則（假設使用 docker 作為 traefik 的 provider）：
|
||||
|
||||
```yaml
|
||||
gitea:
|
||||
image: docker.io/gitea/gitea
|
||||
...
|
||||
labels:
|
||||
- "traefik.enable=true"
|
||||
- "traefik.http.routers.gitea.rule=Host(`example.com`) && PathPrefix(`/gitea`)"
|
||||
- "traefik.http.services.gitea-websecure.loadbalancer.server.port=3000"
|
||||
- "traefik.http.middlewares.gitea-stripprefix.stripprefix.prefixes=/gitea"
|
||||
- "traefik.http.routers.gitea.middlewares=gitea-stripprefix"
|
||||
```
|
||||
|
||||
這份設定假設您使用 traefik 來處理 HTTPS 服務，並在其和 Gitea 之間使用 HTTP 進行通信。
|
||||
|
||||
然後您**必須**在 Gitea 的設定文件中正確的添加類似 `[server] ROOT_URL = http://example.com/gitea/` 的設定項。
|
||||
+30
@@ -0,0 +1,30 @@
|
||||
---
|
||||
date: "2023-05-23T09:00:00+08:00"
|
||||
slug: "search-engines-indexation"
|
||||
sidebar_position: 60
|
||||
aliases:
|
||||
- /zh-tw/search-engines-indexation
|
||||
---
|
||||
|
||||
# 搜索引擎索引
|
||||
|
||||
預設情況下，您的 Gitea 安裝將被搜索引擎索引。
|
||||
如果您不希望您的儲存庫對搜索引擎可見，請進一步閱讀。
|
||||
|
||||
## 使用 robots.txt 阻止搜索引擎索引
|
||||
|
||||
為了使 Gitea 為頂級安裝提供自訂的`robots.txt`（預設為空的 404），請在 [`custom`文件夾或`CustomPath`]（administration/customizing-gitea.md）中建立一個名為 `public/robots.txt` 的文件。
|
||||
|
||||
有關如何設定 `robots.txt` 的範例，請參考 [https://moz.com/learn/seo/robotstxt](https://moz.com/learn/seo/robotstxt)。
|
||||
|
||||
```txt
|
||||
User-agent: *
|
||||
Disallow: /
|
||||
```
|
||||
|
||||
如果您將 Gitea 安裝在子目錄中，則需要在頂級目錄中建立或編輯 `robots.txt`。
|
||||
|
||||
```txt
|
||||
User-agent: *
|
||||
Disallow: /gitea/
|
||||
```
|
||||
@@ -0,0 +1,137 @@
|
||||
---
|
||||
date: "2023-05-23T09:00:00+08:00"
|
||||
slug: "signing"
|
||||
sidebar_position: 50
|
||||
aliases:
|
||||
- /zh-tw/signing
|
||||
---
|
||||
|
||||
# GPG 提交簽名
|
||||
|
||||
Gitea 將通過檢查提交是否由 Gitea 資料庫中的密鑰簽名，或者提交是否與 Git 的預設密鑰匹配，來驗證提供的樹中的 GPG 提交簽名。
|
||||
|
||||
密鑰不會被檢查以確定它們是否已過期或撤銷。密鑰也不會與密鑰伺服器進行檢查。
|
||||
|
||||
如果找不到用於驗證提交的密鑰，提交將被標記為灰色的未鎖定圖標。如果提交被標記為紅色的未鎖定圖標，則表示它使用帶有 ID 的密鑰簽名。
|
||||
|
||||
請注意：提交的簽署者不必是提交的作者或提交者。
|
||||
|
||||
此功能要求 Git >= 1.7.9，但要實現全部功能，需要 Git >= 2.0.0。
|
||||
|
||||
## 自動簽名
|
||||
|
||||
有許多地方 Gitea 會生成提交：
|
||||
|
||||
- 儲存庫初始化
|
||||
- Wiki 更改
|
||||
- 使用編輯器或 API 進行的 CRUD 操作
|
||||
- 從合併請求進行合併
|
||||
|
||||
根據設定和伺服器信任，您可能希望 Gitea 對這些提交進行簽名。
|
||||
|
||||
## 安裝和生成 Gitea 的 GPG 密鑰
|
||||
|
||||
如何安裝簽名密鑰由伺服器管理員決定。Gitea 目前使用伺服器的 `git` 命令生成所有提交，因此將使用伺服器的 `gpg` 進行簽名（如果設定了）。管理員應該審查 GPG 的最佳實踐 - 特別是可能建議僅安裝簽名的子密鑰，而不是主簽名和認證的密鑰。
|
||||
|
||||
## 通用設定
|
||||
|
||||
Gitea 的簽名設定可以在 `app.ini` 的 `[repository.signing]` 部分找到：
|
||||
|
||||
```ini
|
||||
...
|
||||
[repository.signing]
|
||||
SIGNING_KEY = default
|
||||
SIGNING_NAME =
|
||||
SIGNING_EMAIL =
|
||||
INITIAL_COMMIT = always
|
||||
CRUD_ACTIONS = pubkey, twofa, parentsigned
|
||||
WIKI = never
|
||||
MERGES = pubkey, twofa, basesigned, commitssigned
|
||||
|
||||
...
|
||||
```
|
||||
|
||||
### `SIGNING_KEY`
|
||||
|
||||
首先討論的選項是 `SIGNING_KEY`。有三個主要選項：
|
||||
|
||||
- `none` - 這將阻止 Gitea 對任何提交進行簽名
|
||||
- `default` - Gitea 將使用 `git config` 中設定的預設密鑰
|
||||
- `KEYID` - Gitea 將使用具有 ID `KEYID` 的 GPG 密鑰對提交進行簽名。在這種情況下，您應該提供 `SIGNING_NAME` 和 `SIGNING_EMAIL`，以便顯示此密鑰的資訊。
|
||||
|
||||
`default` 選項將讀取 `git config` 中的 `commit.gpgsign` 選項 - 如果設定了該選項，它將使用 `user.signingkey`、`user.name` 和 `user.email` 的結果。
|
||||
|
||||
通過在 Gitea 的儲存庫中調整 Git 的 `config` 文件，可以使用 `SIGNING_KEY=default` 為每個儲存庫提供不同的簽名密鑰。然而，這顯然不是一個理想的使用者介面，因此可能會發生更改。
|
||||
|
||||
:::warning
|
||||
**自 1.17 起**，Gitea 在自己的主目錄 `[git].HOME_PATH`（預設為 `%(APP_DATA_PATH)/home`）中運行 git，並使用自己的設定文件 `{[git].HOME_PATH}/.gitconfig`。
|
||||
|
||||
如果您有自己定製的 Gitea git 設定，您應該將這些設定設定在系統 git 設定文件中（例如 `/etc/gitconfig`）或者 Gitea 的內部 git 設定文件 `{[git].HOME_PATH}/.gitconfig` 中。
|
||||
|
||||
與 git 命令相關的主目錄文件（如 `.gnupg`）也應該放在 Gitea 的 git 主目錄 `[git].HOME_PATH` 中。
|
||||
如果您希望將 `.gnupg` 目錄放在 `{[git].HOME_PATH}/` 之外的位置，請考慮設定 `$GNUPGHOME` 環境變量為您首選的位置，否則 Gitea 將會從 `{[git].HOME_PATH}/.gnupg` 查找私鑰。
|
||||
:::
|
||||
|
||||
### `INITIAL_COMMIT`
|
||||
|
||||
此選項確定在建立儲存庫時，Gitea 是否應該對初始提交進行簽名。可能的取值有：
|
||||
|
||||
- `never`：從不簽名
|
||||
- `pubkey`：僅在使用者擁有公鑰時進行簽名
|
||||
- `twofa`：僅在使用者使用 2FA 登入時進行簽名
|
||||
- `always`：始終簽名
|
||||
|
||||
除了 `never` 和 `always` 之外的選項可以組合為逗號分隔的列表。如果所有選擇的選項都為 true，則提交將被簽名。
|
||||
|
||||
### `WIKI`
|
||||
|
||||
此選項確定 Gitea 是否應該對 Wiki 的提交進行簽名。可能的取值有：
|
||||
|
||||
- `never`：從不簽名
|
||||
- `pubkey`：僅在使用者擁有公鑰時進行簽名
|
||||
- `twofa`：僅在使用者使用 2FA 登入時進行簽名
|
||||
- `parentsigned`：僅在父提交已簽名時進行簽名。
|
||||
- `always`：始終簽名
|
||||
|
||||
除了 `never` 和 `always` 之外的選項可以組合為逗號分隔的列表。如果所有選擇的選項都為 true，則提交將被簽名。
|
||||
|
||||
### `CRUD_ACTIONS`
|
||||
|
||||
此選項確定 Gitea 是否應該對 Web 編輯器或 API CRUD 操作的提交進行簽名。可能的取值有：
|
||||
|
||||
- `never`：從不簽名
|
||||
- `pubkey`：僅在使用者擁有公鑰時進行簽名
|
||||
- `twofa`：僅在使用者使用 2FA 登入時進行簽名
|
||||
- `parentsigned`：僅在父提交已簽名時進行簽名。
|
||||
- `always`：始終簽名
|
||||
|
||||
除了 `never` 和 `always` 之外的選項可以組合為逗號分隔的列表。如果所有選擇的選項都為 true，則更改將被簽名。
|
||||
|
||||
### `MERGES`
|
||||
|
||||
此選項確定 Gitea 是否應該對 PR 的合併提交進行簽名。可能的選項有：
|
||||
|
||||
- `never`：從不簽名
|
||||
- `pubkey`：僅在使用者擁有公鑰時進行簽名
|
||||
- `twofa`：僅在使用者使用 2FA 登入時進行簽名
|
||||
- `basesigned`：僅在基礎儲存庫中的父提交已簽名時進行簽名。
|
||||
- `headsigned`：僅在頭分支中的頭提交已簽名時進行簽名。
|
||||
- `commitssigned`：僅在頭分支中的所有提交到合併點的提交都已簽名時進行簽名。
|
||||
- `approved`：僅對已批准的合併到受保護分支的提交進行簽名。
|
||||
- `always`：始終簽名
|
||||
|
||||
除了 `never` 和 `always` 之外的選項可以組合為逗號分隔的列表。如果所有選擇的選項都為 true，則合併將被簽名。
|
||||
|
||||
## 獲取簽名密鑰的公鑰
|
||||
|
||||
用於簽署 Gitea 提交的公鑰可以透過 API 獲取：
|
||||
|
||||
```sh
|
||||
/api/v1/signing-key.gpg
|
||||
```
|
||||
|
||||
在存在特定於儲存庫的密鑰的情況下，可以透過以下方式獲取：
|
||||
|
||||
```sh
|
||||
/api/v1/repos/:username/:reponame/signing-key.gpg
|
||||
```
|
||||
Reference in new issue
Block a user