mirror of
https://gitea.com/gitea/docs.git
synced 2026-09-20 04:58:52 +00:00
docs: add zh-tw folder (#195)
Signed-off-by: appleboy <[email protected]> Reviewed-on: https://gitea.com/gitea/docs/pulls/195 Reviewed-by: Lunny Xiao <[email protected]> Co-authored-by: appleboy <[email protected]> Co-committed-by: appleboy <[email protected]>
This commit is contained in:
appleboy
Lunny Xiao
+33
@@ -0,0 +1,33 @@
|
||||
---
|
||||
date: "2019-12-28"
|
||||
slug: adding-legal-pages
|
||||
sidebar_position: 110
|
||||
aliases:
|
||||
- /zh-tw/adding-legal-pages
|
||||
---
|
||||
|
||||
# 添加法律頁面
|
||||
|
||||
某些司法管轄區（例如歐盟）要求在網站上添加某些法律頁面（例如隱私政策）。請按照以下步驟將它們添加到您的 Gitea 實例中。
|
||||
|
||||
## 獲取頁面
|
||||
|
||||
Gitea 源代碼附帶示例頁面，位於 `contrib/legal` 目錄中。將它們複製到 `custom/public/assets/`。例如，要添加隱私政策：
|
||||
|
||||
```bash
|
||||
wget -O /path/to/custom/public/assets/privacy.html https://raw.githubusercontent.com/go-gitea/gitea/main/contrib/legal/privacy.html.sample
|
||||
```
|
||||
|
||||
現在您需要編輯頁面以符合您的要求。特別是您必須更改電子郵件地址、網站地址和“您的 Gitea 實例”的引用以匹配您的情況。
|
||||
|
||||
您絕對不能放置一般的服務條款或隱私聲明，暗示 Gitea 項目對您的服務器負責。
|
||||
|
||||
## 使其可見
|
||||
|
||||
創建或附加到 `/path/to/custom/templates/custom/extra_links_footer.tmpl`：
|
||||
|
||||
```go
|
||||
<a class="item" href="{{AppSubUrl}}/assets/privacy.html">隱私政策</a>
|
||||
```
|
||||
|
||||
重新啟動 Gitea 以查看更改。
|
||||
+277
@@ -0,0 +1,277 @@
|
||||
---
|
||||
date: "2016-12-01T16:00:00+02:00"
|
||||
slug: "authentication"
|
||||
sidebar_position: 10
|
||||
aliases:
|
||||
- /zh-tw/authentication
|
||||
---
|
||||
|
||||
# 認證
|
||||
|
||||
## LDAP（輕量級目錄訪問協議）
|
||||
|
||||
LDAP via BindDN 和簡單身份驗證 LDAP 共享以下字段：
|
||||
|
||||
- 授權名稱 **（必填）**
|
||||
|
||||
- 分配給新授權方法的名稱。
|
||||
|
||||
- 主機 **（必填）**
|
||||
|
||||
- 可以訪問 LDAP 服務器的地址。
|
||||
- 例如：`mydomain.com`
|
||||
|
||||
- 端口 **（必填）**
|
||||
|
||||
- 連接到服務器時使用的端口。
|
||||
- 例如：`389` 用於 LDAP 或 `636` 用於 LDAP SSL
|
||||
|
||||
- 啟用 TLS 加密（可選）
|
||||
|
||||
- 是否在連接到 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`
|
||||
|
||||
- 綁定密碼（可選）
|
||||
|
||||
- 上面指定的綁定 DN 的密碼（如果有）。_注意：密碼使用服務器上的 SECRET_KEY 加密存儲。仍然建議確保綁定 DN 具有盡可能少的權限。_
|
||||
|
||||
- 用戶搜索基礎 **（必填）**
|
||||
|
||||
- 將搜索用戶帳戶的 LDAP 基礎。
|
||||
- 例如：`ou=Users,dc=mydomain,dc=com`
|
||||
|
||||
- 用戶過濾器 **（必填）**
|
||||
- 聲明如何查找嘗試進行身份驗證的用戶記錄的 LDAP 過濾器。`%[1]s` 匹配參數將替換為登錄表單中給定的登錄名。
|
||||
- 例如：`(&(objectClass=posixAccount)(|(uid=%[1]s)(mail=%[1]s)))`
|
||||
- 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
|
||||
|
||||
添加以下字段：
|
||||
|
||||
- 用戶 DN **（必填）**
|
||||
|
||||
- 用作用戶 DN 的模板。`%s` 匹配參數將替換為登錄表單中給定的登錄名。
|
||||
- 例如：`cn=%s,ou=Users,dc=mydomain,dc=com`
|
||||
- 例如：`uid=%s,ou=Users,dc=mydomain,dc=com`
|
||||
|
||||
- 用戶搜索基礎（可選）
|
||||
|
||||
- 將搜索用戶帳戶的 LDAP 基礎。
|
||||
- 例如：`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`
|
||||
|
||||
- 包含用戶列表的組屬性（可選）
|
||||
|
||||
- 列出/包含組成員的組對象的屬性。
|
||||
- 例如：`memberUid` 或 `member`
|
||||
|
||||
- 組中列出的用戶屬性（可選）
|
||||
|
||||
- 用於在組對象中引用用戶的用戶屬性。
|
||||
- 例如：如果組對象包含 `member: bender` 並且用戶對象包含 `uid: bender`，則為 `uid`。
|
||||
- 例如：如果組對象包含 `member: uid=bender,ou=users,dc=planetexpress,dc=com`，則為 `dn`。
|
||||
|
||||
- 驗證 LDAP 中的組成員資格（可選）
|
||||
|
||||
- 聲明如何在上述 DN 中查找有效組的 LDAP 過濾器。
|
||||
- 例如：`(|(cn=gitea_users)(cn=admins))`
|
||||
|
||||
## PAM（可插拔身份驗證模塊）
|
||||
|
||||
此過程啟用 PAM 身份驗證。用戶仍然可以使用用戶管理手動添加到系統中。PAM 提供了一種機制，可以通過測試它們來自動將用戶添加到當前數據庫中。要使用普通的 Linux 密碼，運行 Gitea 的用戶還必須具有對 `/etc/shadow` 的讀取訪問權限，以便在使用公鑰登錄時檢查帳戶的有效性。
|
||||
|
||||
**注意**：如果用戶已將 SSH 公鑰添加到 Gitea 中，則使用這些密鑰 _可能_ 會繞過登錄檢查系統。因此，如果您希望禁用使用 PAM 身份驗證的用戶，您 _應該_ 也使用內置用戶管理器手動禁用 Gitea 中的帳戶。
|
||||
|
||||
1. 配置和準備安裝。
|
||||
- 建議您創建一個管理用戶。
|
||||
- 可能還需要取消選擇自動註冊。
|
||||
1. 數據庫初始化後，以新創建的管理用戶身份登錄。
|
||||
1. 導航到用戶設置（右上角的圖標），然後選擇 `站點管理` -> `身份驗證源`，然後選擇 `添加身份驗證源`。
|
||||
1. 填寫以下字段：
|
||||
- `身份驗證類型`：`PAM`
|
||||
- `名稱`：此處的任何值都應有效，如果您願意，可以使用“系統身份驗證”。
|
||||
- `PAM 服務名稱`：選擇 `/etc/pam.d/` 下列出的執行所需身份驗證的文件。[^1]
|
||||
- `PAM 電子郵件域`：附加到用戶身份驗證的電子郵件後綴。例如，如果登錄系統期望用戶名為 `gituser`，並且此字段設置為 `mail.com`，則 Gitea 將期望經過身份驗證的 GIT 實例的 `用戶電子郵件` 字段為 `[email protected]`。[^2]
|
||||
|
||||
**注意**：PAM 支持是通過 [構建時標誌](installation/from-source.md#build) 添加的，官方提供的二進制文件未啟用此功能。PAM 需要必要的 libpam 動態庫可用，並且需要編譯器可以訪問必要的 PAM 開發標頭。
|
||||
|
||||
[^1]: 例如，使用 Debian "Bullseye" 上的標準 Linux 登錄，使用 `common-session-noninteractive` - 此值可能對其他版本的 Debian（包括 Ubuntu 和 Mint）有效，請參閱您的發行版文檔。
|
||||
[^2]: **這是 PAM 的必填字段**。請注意：在上述示例中，用戶將以 `gituser` 而不是 `[email protected]` 登錄 Gitea Web 界面。
|
||||
|
||||
## SMTP（簡單郵件傳輸協議）
|
||||
|
||||
此選項允許 Gitea 以 Gitea 用戶身份登錄到 SMTP 主機。要配置此項，請設置以下字段：
|
||||
|
||||
- 授權名稱 **（必填）**
|
||||
|
||||
- 分配給新授權方法的名稱。
|
||||
|
||||
- SMTP 身份驗證類型 **（必填）**
|
||||
|
||||
- 用於連接到 SMTP 主機的身份驗證類型，PLAIN 或 LOGIN。
|
||||
|
||||
- 主機 **（必填）**
|
||||
|
||||
- 可以訪問 SMTP 主機的地址。
|
||||
- 例如：`smtp.mydomain.com`
|
||||
|
||||
- 端口 **（必填）**
|
||||
|
||||
- 連接到服務器時使用的端口。
|
||||
- 例如：`587`
|
||||
|
||||
- 允許的域
|
||||
|
||||
- 如果使用公共 SMTP 主機或具有多個域的 SMTP 主機，則限制哪些域可以登錄。
|
||||
- 例如：`gitea.com,mydomain.com,mydomain2.com`
|
||||
|
||||
- 強制 SMTPS
|
||||
|
||||
- 默認情況下，將使用 SMTPS 連接到端口 465，如果您希望對其他端口使用 SMTPS，請設置此值。
|
||||
- 否則，如果服務器提供 `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 服務器）。將提示輸入目錄管理員密碼：
|
||||
|
||||
```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，然後單擊管理面板下的“身份驗證”。然後單擊 `添加新源` 並填寫詳細信息，根據需要更改所有內容。
|
||||
|
||||
## SPNEGO 與 SSPI（Kerberos/NTLM，僅適用於 Windows）
|
||||
|
||||
Gitea 支持通過 Windows 中內置的安全支持提供程序接口（SSPI）為服務器的 Web 部分進行 SPNEGO 單點登錄身份驗證（RFC4559 定義的方案）。SSPI 僅在 Windows 環境中工作 - 當服務器和客戶端都運行 Windows 時。
|
||||
|
||||
在激活 SSPI 單點登錄身份驗證（SSO）之前，您必須準備好環境：
|
||||
|
||||
- 在活動目錄中創建一個單獨的用戶帳戶，該帳戶下將運行 `gitea.exe` 進程（例如，域 `domain.local` 下的 `user`）：
|
||||
|
||||
- 為運行 `gitea.exe` 的主機創建一個類別為 `HTTP` 的服務主體名稱：
|
||||
|
||||
- 以特權域用戶（例如域管理員）身份啟動 `命令提示符` 或 `PowerShell`
|
||||
- 運行以下命令，將 `host.domain.local` 替換為運行 Web 應用程序的服務器的完全限定域名（FQDN），將 `domain\user` 替換為上一步中創建的帳戶名稱：
|
||||
|
||||
```sh
|
||||
setspn -A HTTP/host.domain.local domain\user
|
||||
```
|
||||
|
||||
- 使用創建的用戶登錄（如果已登錄，請登出）
|
||||
|
||||
- 確保 `custom/conf/app.ini` 的 `[server]` 部分中的 `ROOT_URL` 是運行 Web 應用程序的服務器的完全限定域名 - 與創建服務主體名稱時使用的相同（例如 `host.domain.local`）
|
||||
|
||||
- 啟動 Web 服務器（`gitea.exe web`）
|
||||
|
||||
- 通過在 `站點管理 -> 身份驗證源` 中添加 `SPNEGO 與 SSPI` 身份驗證源來啟用 SSPI 身份驗證
|
||||
|
||||
- 使用任何域用戶登錄到同一域中的客戶端計算機（客戶端計算機，不同於運行 `gitea.exe` 的服務器）
|
||||
|
||||
- 如果您使用的是 Chrome 或 Edge，請將 Web 應用程序的 URL 添加到本地內部網站（`Internet 選項 -> 安全 -> 本地內部網站 -> 網站`）
|
||||
|
||||
- 啟動 Chrome 或 Edge 並導航到 Gitea 的 FQDN URL（例如 `http://host.domain.local:3000`）
|
||||
|
||||
- 單擊儀表板上的 `登錄` 按鈕，選擇 SSPI 以使用當前登錄到計算機的相同用戶自動登錄
|
||||
|
||||
- 如果不起作用，請確保：
|
||||
- 您未在運行 Gitea 的同一服務器上運行 Web 瀏覽器。您應該在域加入的計算機（客戶端）上運行 Web 瀏覽器，該計算機與服務器不同。如果客戶端和服務器都在同一計算機上運行，NTLM 將優先於 Kerberos。
|
||||
- 主機只有一個 `HTTP/...` SPN
|
||||
- SPN 僅包含主機名，不包含端口
|
||||
- 您已將 Web 應用程序的 URL 添加到 `本地內部網站區域`
|
||||
- 服務器和客戶端的時鐘不應相差超過 5 分鐘（取決於組策略）
|
||||
- Internet Explorer 中應啟用 `集成 Windows 身份驗證`（在 `高級設置` 下）
|
||||
|
||||
## 反向代理
|
||||
|
||||
Gitea 支持反向代理標頭身份驗證，它將讀取標頭作為受信任的登錄用戶名或用戶電子郵件地址。默認情況下未啟用此功能，您可以通過以下方式啟用它
|
||||
|
||||
```ini
|
||||
[service]
|
||||
ENABLE_REVERSE_PROXY_AUTHENTICATION = true
|
||||
```
|
||||
|
||||
默認登錄用戶名在 `X-WEBAUTH-USER` 標頭中，您可以通過更
|
||||
+172
@@ -0,0 +1,172 @@
|
||||
---
|
||||
date: "2017-01-01T16:00:00+02:00"
|
||||
slug: "backup-and-restore"
|
||||
sidebar_position: 11
|
||||
aliases:
|
||||
- /zh-tw/backup-and-restore
|
||||
---
|
||||
|
||||
# 備份和恢復
|
||||
|
||||
Gitea 目前有一個 `dump` 命令，可以將安裝保存到 ZIP 文件中。此文件可以解壓縮並用於恢復實例。
|
||||
|
||||
## 備份一致性
|
||||
|
||||
為了確保 Gitea 實例的一致性，必須在備份期間關閉它。
|
||||
|
||||
Gitea 由數據庫、文件和 git 存儲庫組成，這些都會在使用時發生變化。例如，當遷移正在進行時，數據庫中會創建一個事務，同時 git 存儲庫正在被複製。如果備份發生在遷移過程中，git 存儲庫可能不完整，儘管數據庫聲稱它是完整的，因為它是在之後轉儲的。避免此類競爭條件的唯一方法是在備份期間停止 Gitea 實例。
|
||||
|
||||
## 備份命令 (`dump`)
|
||||
|
||||
切換到運行 Gitea 的用戶：`su git`。在 Gitea 安裝目錄中運行 `./gitea dump -c /path/to/app.ini`。應該會有類似以下的輸出：
|
||||
|
||||
```log
|
||||
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/gitea-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` - 數據庫的 SQL 轉儲
|
||||
- `log/` - 各種日誌。它們在恢復或遷移時不需要。
|
||||
|
||||
中間備份文件創建在臨時目錄中，可以通過 `--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>` 執行；並且，為了在沒有權限錯誤的情況下壓縮備份文件夾，必須在 `--tempdir` 內執行 `docker exec` 命令。
|
||||
|
||||
示例：
|
||||
|
||||
```bash
|
||||
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/data/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 Hooks。
|
||||
|
||||
在 Gitea 運行並從 Gitea 二進制文件所在的目錄中，執行：`./gitea admin regenerate hooks`
|
||||
|
||||
這確保存儲庫 Git Hooks 中的應用程序和配置文件路徑與當前安裝一致且適用。如果這些路徑未更新，存儲庫 `push` 操作將失敗。
|
||||
|
||||
如果您仍然有問題，請考慮運行 `./gitea doctor check` 以檢查可能的錯誤（或使用 `--fix` 選項運行）。
|
||||
|
||||
### 使用 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/gitea-repositories/
|
||||
# 調整文件權限
|
||||
chown -R git:git /data
|
||||
# 重新生成 Git Hooks
|
||||
/usr/local/bin/gitea -c '/data/gitea/conf/app.ini' admin regenerate hooks
|
||||
```
|
||||
|
||||
gitea 容器中的默認用戶是 `git`（1000:1000）。請將 `2a83b293548e` 替換為您的 gitea 容器 ID 或名稱。
|
||||
|
||||
### 使用 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/gitea-repositories
|
||||
# 調整文件權限
|
||||
chown -R git:git /etc/gitea/app.ini /var/lib/gitea
|
||||
# 重新生成 Git Hooks
|
||||
/usr/local/bin/gitea -c '/etc/gitea/app.ini' admin regenerate hooks
|
||||
```
|
||||
|
||||
### 使用 `gitea dump` 轉換數據庫類型
|
||||
|
||||
`gitea dump` 命令可以生成一個 SQL 文件，可以由另一種數據庫類型讀取，這在您在第一次安裝期間未選擇正確的數據庫時很有用。
|
||||
|
||||
請注意，此轉換過程尚未經過充分測試，因此建議在第一次安裝期間選擇最終的數據庫類型，而不要嘗試之後更改。
|
||||
|
||||
停止 Gitea 服務器，然後確保您擁有原始數據庫的完整備份。
|
||||
|
||||
在嘗試轉換之前，確保原始數據庫是乾淨的。運行 `gitea doctor check --all --fix` 和 `gitea doctor recreate-table` 以解決常見問題。
|
||||
|
||||
使用 `--database` 標誌獲取目標格式的 Gitea 轉儲，在此示例中為 PostgreSQL：`gitea dump --database postgres`，然後從生成的 ZIP 文件中提取 `gitea-db.sql` 文件。
|
||||
|
||||
創建 PostgreSQL Gitea 用戶和 Gitea 數據庫。然後，使用以下命令將 SQL 文件作為 Gitea 用戶導入到 Gitea 數據庫中：
|
||||
|
||||
```sh
|
||||
sudo -u postgres psql -d gitea
|
||||
gitea=# SET synchronous_commit TO off
|
||||
gitea=# SET on_error_stop TO on
|
||||
gitea=# \i gitea-db.sql
|
||||
```
|
||||
|
||||
禁用 `synchronous_commit` 使 PostgreSQL 對崩潰的抵抗力降低，但使導入速度更快。由於我們已經有原始數據庫的備份，並且我們可以檢查導入是否成功完成，因此這應該是一個不錯的權衡。
|
||||
|
||||
導入完成後，設置 Gitea 以使用 PostgreSQL 並重新啟動 Gitea 服務器。祝你好運！
|
||||
@@ -0,0 +1,94 @@
|
||||
---
|
||||
date: "2020-01-25T21:00:00-03:00"
|
||||
slug: "cmd-embedded"
|
||||
sidebar_position: 20
|
||||
aliases:
|
||||
- /zh-tw/cmd-embedded
|
||||
---
|
||||
|
||||
# 嵌入式數據提取工具
|
||||
|
||||
Gitea 的可執行文件包含運行所需的所有資源：模板、圖像、樣式表和翻譯。可以通過將替換文件放置在 `custom` 目錄中的匹配路徑中來覆蓋其中的任何資源（請參閱 [自定義 Gitea](../administration/customizing-gitea.md)）。
|
||||
|
||||
要獲取嵌入資源的副本以供編輯，可以從操作系統的 shell 界面使用 CLI 的 `embedded` 命令。
|
||||
|
||||
:::note
|
||||
嵌入式數據提取工具包含在 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/**`
|
||||
|
||||
不要忘記對模式使用引號，因為空格、`*` 和其他字符可能對您的命令 shell 有特殊含義。
|
||||
|
||||
如果未提供任何模式，則列出所有文件。
|
||||
|
||||
### 示例：列出所有嵌入文件
|
||||
|
||||
列出所有路徑中包含 `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` 選項告訴 Gitea 文件必須提取到的目錄。默認是當前目錄。
|
||||
|
||||
`--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
|
||||
```
|
||||
+230
@@ -0,0 +1,230 @@
|
||||
---
|
||||
date: "2017-01-01T16:00:00+02:00"
|
||||
slug: "command-line"
|
||||
sidebar_position: 1
|
||||
aliases:
|
||||
- /zh-tw/command-line
|
||||
---
|
||||
|
||||
# Gitea 命令行
|
||||
|
||||
## 用法
|
||||
|
||||
`gitea [全局選項] 命令 [命令或全局選項] [參數...]`
|
||||
|
||||
## 全局選項
|
||||
|
||||
所有全局選項都可以放在命令級別。
|
||||
|
||||
- `--help`, `-h`: 顯示幫助文本並退出。可選。
|
||||
- `--version`, `-v`: 顯示版本並退出。可選。（示例：`Gitea version 1.1.0+218-g7b907ed built with: bindata, sqlite`）。
|
||||
- `--work-path path`, `-w path`: Gitea 的工作路徑。可選。（默認：二進制文件的路徑或 `$GITEA_WORK_DIR`）
|
||||
- `--custom-path path`, `-C path`: Gitea 的自定義文件夾路徑。可選。（默認：`WorkPath`/custom 或 `$GITEA_CUSTOM`）。
|
||||
- `--config path`, `-c path`: Gitea 配置文件路徑。可選。（默認：`CustomPath`/conf/app.ini）。
|
||||
|
||||
注意：默認的 custom-path、config 和 work-path 也可以在構建時更改（如果需要）。
|
||||
|
||||
## 命令
|
||||
|
||||
### web
|
||||
|
||||
啟動服務器：
|
||||
|
||||
- 選項：
|
||||
- `--port number`, `-p number`: 端口號。可選。（默認：3000）。覆蓋配置文件。
|
||||
- `--install-port number`: 運行安裝頁面的端口號。可選。（默認：3000）。覆蓋配置文件。
|
||||
- `--pid path`, `-P path`: Pidfile 路徑。可選。
|
||||
- `--quiet`, `-q`: 只在控制台上發出致命日誌，適用於日誌設置之前的日誌。
|
||||
- `--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。可以通過 `--must-change-password=false` 禁用。
|
||||
- `--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`: 新密碼。必需。
|
||||
- `--must-change-password`: 用戶在登錄後需要設置新密碼，默認：true。可以通過 `--must-change-password=false` 禁用。
|
||||
- 示例：
|
||||
- `gitea admin user change-password --username myname --password asecurepassword`
|
||||
- `must-change-password`:
|
||||
- 參數：
|
||||
- `[username...]`: 必須更改密碼的用戶
|
||||
- 選項：
|
||||
- `--all`, `-A`: 強制所有用戶更改密碼
|
||||
- `--exclude username`, `-e username`: 排除給定的用戶。可以多次設置。
|
||||
- `--unset`: 撤銷給定用戶的強制密碼更改
|
||||
- `generate-access-token`:
|
||||
- 選項：
|
||||
- `--username value`, `-u value`: 用戶名。必需。
|
||||
- `--token-name value`, `-t value`: 令牌名稱。必需。
|
||||
- `--scopes value`: 逗號分隔的範圍列表。範圍遵循格式 `[read|write]:<block>` 或 `all`，其中 `<block>` 是可見組之一，您可以在打開顯示可用路由的 API 頁面時看到（例如 `repo`）。
|
||||
- 示例：
|
||||
- `gitea admin user generate-access-token --username myname --token-name mytoken`
|
||||
- `gitea admin user generate-access-token --help`
|
||||
- `regenerate`
|
||||
- 選項：
|
||||
- `hooks`: 為所有存儲庫重新生成 Git 鉤子
|
||||
- `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（密鑰）。
|
||||
- `--secret`: 客戶端密鑰。
|
||||
- `--auto-discover-url`: OpenID Connect 自動發現 URL（僅在使用 OpenID Connect 作為提供者時需要）。
|
||||
- `--use-custom-urls`: 使用自定義 URL 用於 GitLab/GitHub OAuth 端點。
|
||||
- `--custom-tenant-id`: 使用自定義租戶 ID 用於 OAuth 端點。
|
||||
- `--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`: 自定義圖標 URL 用於 OAuth2 登錄源。
|
||||
- `--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（密鑰）。
|
||||
- `--secret`: 客戶端密鑰。
|
||||
- `--auto-discover-url`: OpenID Connect 自動發現 URL（僅在使用 OpenID Connect 作為提供者時需要）。
|
||||
- `--use-custom-urls`: 使用自定義 URL 用於 GitLab/GitHub OAuth 端點。
|
||||
- `--custom-tenant-id`: 使用自定義租戶 ID 用於 OAuth 端點。
|
||||
- `--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`: 自定義圖標 URL 用於 OAuth2 登錄源。
|
||||
- `--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-loca-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 記錄的屬性。
|
||||
- `--avatar-attribute value`: 包含用戶頭像的用戶 LDAP 記錄的屬性。
|
||||
- `--bind-dn value`: 在搜索用戶時綁定到 LDAP 服務器的 DN。
|
||||
- `--bind-password value`: 綁定 DN 的密碼（如果有）。注意：密碼使用服務器上的 SECRET_KEY 加密存儲。仍然建議確保 Bind 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
|
||||
+138
@@ -0,0 +1,138 @@
|
||||
---
|
||||
date: "2016-12-26T16:00:00+02:00"
|
||||
slug: "config-cheat-sheet"
|
||||
sidebar_position: 30
|
||||
aliases:
|
||||
- /zh-tw/config-cheat-sheet
|
||||
---
|
||||
|
||||
# 配置備忘單
|
||||
|
||||
這是一份 Gitea 配置文件的備忘單。它包含了大多數可以配置的設置以及它們的默認值。
|
||||
|
||||
對 Gitea 配置文件的任何更改應該在 `custom/conf/app.ini` 或任何相應的位置進行。從發行版安裝時，通常會在 `/etc/gitea/conf/app.ini` 中找到。
|
||||
|
||||
這裡提供的默認值是最佳努力（不是自動生成的）。它們在 [app.example.ini](https://github.com/go-gitea/gitea/blob/main/custom/conf/app.example.ini) 中準確記錄（s/main/\<tag|release\>）。任何格式為 `%(X)s` 的字符串都是由 [ini](https://github.com/go-ini/ini/#recursive-values) 提供的功能，用於遞歸讀取值。
|
||||
|
||||
在下面的默認值中，形式為 `$XYZ` 的值指的是環境變量。（但是，請參閱 `environment-to-ini`。）形式為 _`XxYyZz`_ 的值指的是作為默認配置一部分列出的值。這些符號形式不會在您自己的 `app.ini` 文件中工作，僅在此處作為文檔列出。
|
||||
|
||||
包含 `#` 或 `;` 的值必須使用 `` ` `` 或 `"""` 引號。
|
||||
|
||||
:::info
|
||||
Gitea 配置更改需要完全重啟才能生效。
|
||||
:::
|
||||
|
||||
## 默認配置（非 `app.ini` 配置）
|
||||
|
||||
這些值是環境依賴的，但構成了許多值的基礎。它們將在運行 `gitea help` 或啟動時作為默認配置的一部分報告。它們在那裡發出的順序略有不同，但我們將在這裡按設置順序列出它們。
|
||||
|
||||
- _`AppPath`_：這是運行 gitea 二進制文件的絕對路徑。
|
||||
- _`AppWorkPath`_：這指的是 `gitea` 二進制文件的“工作路徑”。它是通過使用以下層次結構中的第一個設置來確定的：
|
||||
- `app.ini` 中的 `WORK_PATH` 選項
|
||||
- 傳遞給二進制文件的 `--work-path` 標誌
|
||||
- 環境變量 `$GITEA_WORK_DIR`
|
||||
- 構建時設置的內置值（請參閱從源代碼構建）
|
||||
- 否則，它默認為 _`AppPath`_ 的目錄
|
||||
- 如果上述任何一個是相對路徑，則它們將相對於 _`AppPath`_ 的目錄變為絕對路徑
|
||||
- _`CustomPath`_：這是自定義模板和其他選項的基本目錄。
|
||||
它是通過使用以下層次結構中的第一個設置來確定的：
|
||||
- 傳遞給二進制文件的 `--custom-path` 標誌
|
||||
- 環境變量 `$GITEA_CUSTOM`
|
||||
- 構建時設置的內置值（請參閱從源代碼構建）
|
||||
- 否則，它默認為 _`AppWorkPath`_`/custom`
|
||||
- 如果上述任何一個是相對路徑，則它們將相對於 _`AppWorkPath`_ 的目錄變為絕對路徑
|
||||
- _`CustomConf`_：這是 `app.ini` 文件的路徑。
|
||||
- 傳遞給二進制文件的 `--config` 標誌
|
||||
- 構建時設置的內置值（請參閱從源代碼構建）
|
||||
- 否則，它默認為 _`CustomPath`_`/conf/app.ini`
|
||||
- 如果上述任何一個是相對路徑，則它們將相對於 _`CustomPath`_ 的目錄變為絕對路徑
|
||||
|
||||
此外，還有 _`StaticRootPath`_，可以在構建時設置為內置值，但否則默認為 _`AppWorkPath`_
|
||||
|
||||
## 總體（`DEFAULT`）
|
||||
|
||||
- `APP_NAME`：**Gitea: Git with a cup of tea**：應用程序名稱，用於頁面標題。
|
||||
- `RUN_USER`：**_當前操作系統用戶名_/`$USER`/`$USERNAME` 例如 git**：Gitea 將以此用戶運行。
|
||||
這應該是一個專用的系統（非用戶）帳戶。不正確設置此項將導致 Gitea 無法啟動。
|
||||
- `RUN_MODE`：**prod**：應用程序運行模式，影響性能和調試：`dev` 或 `prod`，默認為 `prod`。模式 `dev` 使 Gitea 更易於開發和調試，除 `dev` 以外的值被視為 `prod`，適用於生產使用。
|
||||
- `WORK_PATH`：**_the-work-path_**：工作目錄，請參閱上面的 AppWorkPath 註釋。
|
||||
|
||||
## 存儲庫（`repository`）
|
||||
|
||||
- `ROOT`：**%(APP_DATA_PATH)s/gitea-repositories**：存儲所有存儲庫數據的根路徑。
|
||||
相對路徑解釋為 **_`AppWorkPath`_/%(ROOT)s**。
|
||||
- `SCRIPT_TYPE`：**bash**：此服務器支持的腳本類型。通常這是 `bash`，
|
||||
但有些用戶報告只有 `sh` 可用。
|
||||
- `DETECTED_CHARSETS_ORDER`：**UTF-8, UTF-16BE, UTF-16LE, UTF-32BE, UTF-32LE, ISO-8859, windows-1252, ISO-8859, windows-1250, ISO-8859, ISO-8859, ISO-8859, windows-1253, ISO-8859, windows-1255, ISO-8859, windows-1251, windows-1256, KOI8-R, ISO-8859, windows-1254, Shift_JIS, GB18030, EUC-JP, EUC-KR, Big5, ISO-2022, ISO-2022, ISO-2022, IBM424_rtl, IBM424_ltr, IBM420_rtl, IBM420_ltr**：檢測到的字符集的優先順序 - 如果檢測到的字符集具有相同的置信度，則列表中較早的字符集將優先於較晚的字符集。添加 `defaults` 將在該點放置未命名的字符集。
|
||||
- `ANSI_CHARSET`：**_empty_**：默認的 ANSI 字符集，用於覆蓋非 UTF-8 字符集。
|
||||
- `FORCE_PRIVATE`：**false**：強制每個新存儲庫為私有。
|
||||
- `DEFAULT_PRIVATE`：**last**：創建新存儲庫時的默認私有設置。
|
||||
\[last, private, public\]
|
||||
- `DEFAULT_PUSH_CREATE_PRIVATE`：**true**：使用推送創建時的默認私有設置。
|
||||
- `MAX_CREATION_LIMIT`：**-1**：每個用戶的全局最大創建限制，
|
||||
`-1` 表示無限制。
|
||||
- `PREFERRED_LICENSES`：**Apache License 2.0,MIT License**：首選許可證，放在列表頂部。名稱必須與 options/license 或 custom/options/license 中的文件名匹配。
|
||||
- `DISABLE_HTTP_GIT`：**false**：禁用通過 HTTP 協議與存儲庫交互的功能。
|
||||
- `USE_COMPAT_SSH_URI`：**false**：在使用默認 SSH 端口時強制使用 ssh:// 克隆 URL 而不是 scp 風格的 URI。
|
||||
- `GO_GET_CLONE_URL_PROTOCOL`：**https**：`go get` 請求返回存儲庫 URL 的協議，默認為 https。
|
||||
- `ACCESS_CONTROL_ALLOW_ORIGIN`：**_empty_**：Access-Control-Allow-Origin 標頭的值，
|
||||
默認不顯示。
|
||||
|
||||
:::warning
|
||||
如果您未給出正確的值，這可能對您的網站有害。
|
||||
:::
|
||||
|
||||
- `DEFAULT_CLOSE_ISSUES_VIA_COMMITS_IN_ANY_BRANCH`：**false**：如果非默認分支上的提交標記為已關閉，則關閉問題。
|
||||
- `ENABLE_PUSH_CREATE_USER`：**false**：允許用戶將本地存儲庫推送到 Gitea 並自動為用戶創建它們。
|
||||
- `ENABLE_PUSH_CREATE_ORG`：**false**：允許用戶將本地存儲庫推送到 Gitea 並自動為組織創建它們。
|
||||
- `DISABLED_REPO_UNITS`：**_empty_**：全局禁用的存儲庫單元的逗號分隔列表。允許的值：\[repo.issues, repo.ext_issues, repo.pulls, repo.wiki, repo.ext_wiki, repo.projects, repo.packages, repo.actions\]
|
||||
- `DEFAULT_REPO_UNITS`：**repo.code,repo.releases,repo.issues,repo.pulls,repo.wiki,repo.projects,repo.packages,repo.actions**：默認的新存儲庫單元的逗號分隔列表。允許的值：\[repo.code, repo.releases, repo.issues, repo.pulls, repo.wiki, repo.projects, repo.packages, repo.actions\]。注意：目前無法停用代碼和版本。如果您指定默認存儲庫單元，您應該仍然列出它們以確保未來的兼容性。外部 wiki 和問題跟踪器無法默認啟用，因為它需要額外的設置。無論是否在默認列表中，禁用的存儲庫單元都不會添加到新存儲庫中。
|
||||
- `DEFAULT_FORK_REPO_UNITS`：**repo.code,repo.pulls**：默認的分叉存儲庫單元的逗號分隔列表。允許的值和規則與 `DEFAULT_REPO_UNITS` 相同。
|
||||
- `DEFAULT_MIRROR_REPO_UNITS`：**repo.code,repo.releases,repo.issues,repo.wiki,repo.projects,repo.packages**：默認的鏡像存儲庫單元的逗號分隔列表。允許的值和規則與 `DEFAULT_REPO_UNITS` 相同。
|
||||
- `DEFAULT_TEMPLATE_REPO_UNITS`：**repo.code,repo.releases,repo.issues,repo.pulls,repo.wiki,repo.projects,repo.packages**：默認的模板存儲庫單元的逗號分隔列表。允許的值和規則與 `DEFAULT_REPO_UNITS` 相同。
|
||||
- `PREFIX_ARCHIVE_FILES`：**true**：通過將它們放在以存儲庫命名的目錄中來為存檔文件添加前綴。
|
||||
- `DISABLE_MIGRATIONS`：**false**：禁用遷移功能。
|
||||
- `DISABLE_STARS`：**false**：禁用星標功能。
|
||||
- `DEFAULT_BRANCH`：**main**：所有存儲庫的默認分支名稱。
|
||||
- `ALLOW_ADOPTION_OF_UNADOPTED_REPOSITORIES`：**false**：允許非管理員用戶採用未採用的存儲庫
|
||||
- `ALLOW_DELETION_OF_UNADOPTED_REPOSITORIES`：**false**：允許非管理員用戶刪除未採用的存儲庫
|
||||
- `DISABLE_DOWNLOAD_SOURCE_ARCHIVES`：**false**：不允許從 UI 下載源代碼存檔文件
|
||||
- `ALLOW_FORK_WITHOUT_MAXIMUM_LIMIT`：**true**：允許無最大數量限制的分叉存儲庫
|
||||
|
||||
### 存儲庫 - 編輯器（`repository.editor`）
|
||||
|
||||
- `LINE_WRAP_EXTENSIONS`：**.txt,.md,.markdown,.mdown,.mkd,.livemd,**：在 Monaco 編輯器中應換行的文件擴展名列表。用逗號分隔擴展名。要換行沒有擴展名的文件，只需放置一個逗號
|
||||
- `PREVIEWABLE_FILE_MODES`：**markdown**：具有預覽 API 的有效文件模式，例如 `api/v1/markdown`。用逗號分隔值。如果文件擴展名不匹配，則不會顯示編輯模式中的預覽選項卡。
|
||||
|
||||
### 存儲庫 - 拉取請求（`repository.pull-request`）
|
||||
|
||||
- `WORK_IN_PROGRESS_PREFIXES`：**WIP:,\[WIP\]**：用於拉取請求標題中標記為進行中的前綴列表。這些是大小寫不敏感的匹配。
|
||||
- `CLOSE_KEYWORDS`：**close**, **closes**, **closed**, **fix**, **fixes**, **fixed**, **resolve**, **resolves**, **resolved**：用於拉取請求評論中自動關閉相關問題的關鍵字列表
|
||||
- `REOPEN_KEYWORDS`：**reopen**, **reopens**, **reopened**：用於拉取請求評論中自動重新打開相關問題的關鍵字列表
|
||||
- `DEFAULT_MERGE_STYLE`：**merge**：設置存儲庫創建的默認合併樣式，有效選項：`merge`, `rebase`, `rebase-merge`, `squash`, `fast-forward-only`
|
||||
- `DEFAULT_MERGE_MESSAGE_COMMITS_LIMIT`：**50**：在默認的合併消息中，包含最多這麼多的提交。設置為 `-1` 以包含所有提交
|
||||
- `DEFAULT_MERGE_MESSAGE_SIZE`：**5120**：在默認的合併消息中，限制提交消息的大小。設置為 `-1` 以無限制。僅在 `POPULATE_SQUASH_COMMENT_WITH_COMMIT_MESSAGES` 為 `true` 時使用。
|
||||
- `DEFAULT_MERGE_MESSAGE_ALL_AUTHORS`：**false**：在默認的合併消息中，遍歷所有提交以包含所有作者，否則僅使用有限列表中的作者
|
||||
- `DEFAULT_MERGE_MESSAGE_MAX_APPROVERS`：**10**：在默認的合併消息中，限制列為 `Reviewed-by:` 的審批者數量。設置為 `-1` 以包含所有。
|
||||
- `DEFAULT_MERGE_MESSAGE_OFFICIAL_APPROVERS_ONLY`：**true**：在默認的合併消息中，僅包括正式允許審查的審批者。
|
||||
- `POPULATE_SQUASH_COMMENT_WITH_COMMIT_MESSAGES`：**false**：在默認的壓縮合併消息中，包含組成拉取請求的所有提交的提交消息。
|
||||
- `ADD_CO_COMMITTER_TRAILERS`：**true**：如果提交者與作者不匹配，則在合併提交消息中添加共同作者和共同提交者的尾部。
|
||||
- `TEST_CONFLICTING_PATCHES_WITH_GIT_APPLY`：**false**：PR 補丁使用三方合併方法進行測試，以發現是否存在衝突。如果此設置設置為 **true**，則將使用 `git apply` 重新測試衝突的補丁 - 這是 1.18（及更早版本）中的先前行為，但效率較低。如果您發現需要此設置，請報告。
|
||||
- `RETARGET_CHILDREN_ON_MERGE`：**true**：在合併父拉取請求時，將子拉取請求重新定位到父拉取請求分支目標。僅適用於目標相同存儲庫的合併 PR。
|
||||
|
||||
### 存儲庫 - 問題（`repository.issue`）
|
||||
|
||||
- `LOCK_REASONS`：**Too heated,Off-topic,Resolved,Spam**：可以鎖定拉取請求或問題的原因列表
|
||||
- `MAX_PINNED`：**3**：每個存儲庫的最大固定問題數量。設置為 0 以禁用固定問題。
|
||||
|
||||
### 存儲庫 - 上傳（`repository.upload`）
|
||||
|
||||
- `ENABLED`：**true**：是否啟用存儲庫文件上傳
|
||||
- `TEMP_PATH`：**data/tmp/uploads**：上傳的路徑（內容在 Gitea 重啟時會被刪除）
|
||||
- `ALLOWED_TYPES`：**_empty_**：允許的文件擴展名（`.zip`）、MIME 類型（`text/plain`）或通配符類型（`image/*`、`audio/*`、`video/*`）的逗號分隔列表。空值或 `*/*` 允許所有類型。
|
||||
- `FILE_MAX_SIZE`：**50**：每個文件的最大大小（以 MB 為單位）。
|
||||
- `MAX_FILES`：**5**：每次上傳的最大文件數量
|
||||
|
||||
### 存儲庫 - 發行（`repository.release`）
|
||||
|
||||
- `ALLOWED_TYPES`：**_empty_**：允許的文件擴展名（`.zip`）、MIME 類型（`text/plain`）
|
||||
+287
@@ -0,0 +1,287 @@
|
||||
---
|
||||
date: "2017-04-15T14:56:00+02:00"
|
||||
slug: "customizing-gitea"
|
||||
sidebar_position: 100
|
||||
aliases:
|
||||
- /zh-tw/customizing-gitea
|
||||
---
|
||||
|
||||
# 自定義 Gitea
|
||||
|
||||
自定義 Gitea 通常使用 `CustomPath` 文件夾進行 - 默認情況下，這是工作目錄（WorkPath）中的 `custom` 文件夾，但如果您的構建設置不同，則可能會有所不同。這是覆蓋配置設置、模板等的中心位置。您可以使用 `gitea help` 檢查 `CustomPath`。您還可以在 _站點管理_ 頁面的 _配置_ 標籤中找到路徑。您可以通過設置 `GITEA_CUSTOM` 環境變量或使用 `gitea` 二進制文件上的 `--custom-path` 選項來覆蓋 `CustomPath`。（該選項將覆蓋環境變量。）
|
||||
|
||||
如果 Gitea 是從二進制文件部署的，則所有默認路徑都將相對於 Gitea 二進制文件。如果從發行版安裝，這些路徑可能會修改為 Linux 文件系統標準。Gitea 將嘗試創建所需的文件夾，包括 `custom/`。發行版可能會使用 `/etc/gitea/` 提供 `custom` 的符號鏈接。
|
||||
|
||||
應用程序設置可以在 `CustomConf` 文件中找到，默認情況下為 `$GITEA_CUSTOM/conf/app.ini`，但如果您的構建設置不同，則可能會有所不同。同樣，`gitea help` 將允許您查看此變量，您可以使用 `gitea` 二進制文件上的 `--config` 選項來覆蓋它。
|
||||
|
||||
- [快速備忘單](../administration/config-cheat-sheet.md)
|
||||
- [完整列表](https://github.com/go-gitea/gitea/blob/main/custom/conf/app.example.ini)
|
||||
|
||||
如果無法找到 `CustomPath` 文件夾，請檢查 `gitea help`，請檢查 `GITEA_CUSTOM` 環境變量；這可以用於覆蓋默認路徑到其他位置。例如，`GITEA_CUSTOM` 可能由啟動腳本設置。您可以在站點管理頁面的“配置”標籤下檢查是否設置了該值。
|
||||
|
||||
- [環境變量列表](../administration/environment-variables.md)
|
||||
|
||||
:::note
|
||||
Gitea 必須完全重啟才能看到配置更改。
|
||||
:::
|
||||
|
||||
## 提供自定義公共文件
|
||||
|
||||
要使 Gitea 提供自定義公共文件（如頁面和圖像），請使用文件夾 `$GITEA_CUSTOM/public/` 作為 webroot。將遵循符號鏈接。
|
||||
目前，僅提供以下文件：
|
||||
|
||||
- `public/robots.txt`
|
||||
- `public/.well-known/` 文件夾中的文件
|
||||
- `public/assets/` 文件夾中的文件
|
||||
|
||||
例如，存儲在 `$GITEA_CUSTOM/public/assets/` 中的文件 `image.png` 可以通過 url `http://gitea.domain.tld/assets/image.png` 訪問。
|
||||
|
||||
## 更改徽標
|
||||
|
||||
要構建自定義徽標和/或圖標，克隆 Gitea 源代碼庫，替換 `assets/logo.svg` 和/或 `assets/favicon.svg`，然後運行 `make generate-images`。`assets/favicon.svg` 僅用於圖標。這將更新以下輸出文件，然後您可以將它們放置在服務器上的 `$GITEA_CUSTOM/public/assets/img` 中：
|
||||
|
||||
- `public/assets/img/logo.svg` - 用於站點圖標、應用程序圖標
|
||||
- `public/assets/img/logo.png` - 用於 Open Graph
|
||||
- `public/assets/img/avatar_default.png` - 用作默認頭像圖像
|
||||
- `public/assets/img/apple-touch-icon.png` - 用於 iOS 設備的書籤
|
||||
- `public/assets/img/favicon.svg` - 用於圖標
|
||||
- `public/assets/img/favicon.png` - 用於不支持 SVG 圖標的瀏覽器
|
||||
|
||||
如果源圖像不是矢量格式，您可以嘗試使用工具（如[這個](https://www.aconvert.com/image/png-to-svg/)）將光柵圖像轉換為矢量圖像。
|
||||
|
||||
## 自定義 Gitea 頁面和資源
|
||||
|
||||
Gitea 的可執行文件包含運行所需的所有資源：模板、圖像、樣式表和翻譯。可以通過將替換文件放置在 `custom` 目錄中的匹配路徑中來覆蓋其中的任何資源。例如，要替換為 C++ 存儲庫提供的默認 `.gitignore`，我們需要替換 `options/gitignore/C++`。為此，必須將替換文件放置在 `$GITEA_CUSTOM/options/gitignore/C++` 中（請參閱本文檔頂部有關 `CustomPath` 目錄位置的說明）。
|
||||
|
||||
Gitea 的每個頁面都可以更改。動態內容是使用 [go 模板](https://pkg.go.dev/html/template) 生成的，可以通過將替換文件放置在 `$GITEA_CUSTOM/templates` 目錄下來修改。
|
||||
|
||||
要獲取任何嵌入文件（包括模板），可以使用 [`gitea embedded` 工具](../administration/cmd-embedded.md)。或者，它們可以在 Gitea 源代碼的 [`templates`](https://github.com/go-gitea/gitea/tree/main/templates) 目錄中找到（注意：示例鏈接來自 `main` 分支。確保使用與您使用的版本兼容的模板）。
|
||||
|
||||
請注意，任何包含在 `{{` 和 `}}` 之間的語句都是 Gitea 的模板語法，應在完全理解這些組件之前不要觸摸。
|
||||
|
||||
### 自定義起始頁/首頁
|
||||
|
||||
從 `templates` 為您的 Gitea 版本複製 [`home.tmpl`](https://github.com/go-gitea/gitea/blob/main/templates/home.tmpl) 到 `$GITEA_CUSTOM/templates`。
|
||||
根據需要進行編輯。
|
||||
不要忘記重啟您的 Gitea 以應用更改。
|
||||
|
||||
### 添加鏈接和標籤
|
||||
|
||||
如果您只想在頂部導航欄或頁腳中添加額外的鏈接，或在存儲庫視圖中添加額外的標籤，可以將它們放在 `extra_links.tmpl`（添加到導航欄的鏈接）、`extra_links_footer.tmpl`（添加到頁腳左側的鏈接）和 `extra_tabs.tmpl` 中，放置在您的 `$GITEA_CUSTOM/templates/custom/` 目錄中。
|
||||
|
||||
例如，假設您在德國，必須添加著名的法律要求的“Impressum”/關於頁面，列出誰對網站內容負責：
|
||||
只需將其放置在您的 "$GITEA_CUSTOM/public/assets/" 目錄下（例如 `$GITEA_CUSTOM/public/assets/impressum.html`），並將鏈接放置在 `$GITEA_CUSTOM/templates/custom/extra_links.tmpl` 或 `$GITEA_CUSTOM/templates/custom/extra_links_footer.tmpl` 中。
|
||||
|
||||
為了匹配當前樣式，鏈接應具有類名“item”，您可以使用 `{{AppSubUrl}}` 獲取基本 URL：
|
||||
`<a class="item" href="{{AppSubUrl}}/assets/impressum.html">Impressum</a>`
|
||||
|
||||
有關更多信息，請參閱 [添加法律頁面](../administration/adding-legal-pages.md)。
|
||||
|
||||
您可以以相同的方式添加新標籤，將它們放在 `extra_tabs.tmpl` 中。
|
||||
匹配其他標籤樣式所需的確切 HTML 位於文件 `templates/repo/header.tmpl` 中
|
||||
（[GitHub 中的源代碼](https://github.com/go-gitea/gitea/blob/main/templates/repo/header.tmpl)）
|
||||
|
||||
### 頁面的其他添加
|
||||
|
||||
除了 `extra_links.tmpl` 和 `extra_tabs.tmpl`，還有其他有用的模板，您可以將它們放在 `$GITEA_CUSTOM/templates/custom/` 目錄中：
|
||||
|
||||
- `header.tmpl`，在 `<head>` 標籤結束之前，您可以添加自定義 CSS 文件。
|
||||
- `body_outer_pre.tmpl`，在 `<body>` 開始之後。
|
||||
- `body_inner_pre.tmpl`，在頂部導航欄之前，但已經在主容器 `<div class="full height">` 內。
|
||||
- `body_inner_post.tmpl`，在主容器結束之前。
|
||||
- `body_outer_post.tmpl`，在底部 `<footer>` 元素之前。
|
||||
- `footer.tmpl`，在 `<body>` 標籤結束之前，是添加 JavaScript 的好地方。
|
||||
|
||||
### 使用 Gitea 變量
|
||||
|
||||
可以在自定義模板中使用各種 Gitea 變量。
|
||||
|
||||
首先，_臨時_ 啟用開發模式：在您的 `app.ini` 中將 `RUN_MODE = prod` 更改為 `RUN_MODE = dev`。然後將 `{{ $ | DumpVar }}` 添加到任何模板中，重啟 Gitea 並刷新該頁面；這將轉儲所有可用變量。
|
||||
|
||||
找到您需要的數據，並使用相應的變量；例如，如果您需要存儲庫的名稱，則可以使用 `{{.Repository.Name}}`。
|
||||
|
||||
如果您需要以某種方式轉換這些數據，並且不熟悉 Go，一個簡單的解決方法是將數據添加到 DOM 並添加一個小的 JavaScript 腳本塊來操作數據。
|
||||
|
||||
### 示例：PlantUML
|
||||
|
||||
您可以使用 PlantUML 服務器將 [PlantUML](https://plantuml.com/) 支持添加到 Gitea 的 markdown 中。
|
||||
數據被編碼並發送到 PlantUML 服務器，該服務器生成圖片。有一個在線演示服務器位於 http://www.plantuml.com/plantuml，但如果您（或您的用戶）有敏感數據，您可以設置自己的 [PlantUML 服務器](https://plantuml.com/server)。要設置 PlantUML 渲染，從 https://gitea.com/davidsvantesson/plantuml-code-highlight 複製 JavaScript 文件並將它們放在您的 `$GITEA_CUSTOM/public/assets/` 文件夾中。然後將以下內容添加到 `custom/footer.tmpl`：
|
||||
|
||||
```html
|
||||
<script>
|
||||
$(async () => {
|
||||
if (!$(".language-plantuml").length) return;
|
||||
await Promise.all([
|
||||
$.getScript("https://your-gitea-server.com/assets/deflate.js"),
|
||||
$.getScript("https://your-gitea-server.com/assets/encode.js"),
|
||||
$.getScript(
|
||||
"https://your-gitea-server.com/assets/plantuml_codeblock_parse.js"
|
||||
),
|
||||
]);
|
||||
// 用您的 plantuml 服務器地址替換調用
|
||||
parsePlantumlCodeBlocks("https://www.plantuml.com/plantuml");
|
||||
});
|
||||
</script>
|
||||
```
|
||||
|
||||
然後您可以將以下塊添加到您的 markdown 中：
|
||||
|
||||
```plantuml
|
||||
Alice -> Bob: Authentication Request
|
||||
Bob --> Alice: Authentication Response
|
||||
|
||||
Alice -> Bob: Another authentication Request
|
||||
Alice <-- Bob: Another authentication Response
|
||||
```
|
||||
|
||||
該腳本將檢測帶有 `class="language-plantuml"` 的標籤，但您可以通過提供第二個參數給 `parsePlantumlCodeBlocks` 來更改此設置。
|
||||
|
||||
### 示例：STL 預覽
|
||||
|
||||
您可以通過添加以下內容直接在 Gitea 中顯示 STL 文件：
|
||||
|
||||
```html
|
||||
<script>
|
||||
function lS(src) {
|
||||
return new Promise(function (resolve, reject) {
|
||||
let s = document.createElement("script");
|
||||
s.src = src;
|
||||
s.addEventListener("load", () => {
|
||||
resolve();
|
||||
});
|
||||
document.body.appendChild(s);
|
||||
});
|
||||
}
|
||||
|
||||
if ($('.view-raw>a[href$=".stl" i]').length) {
|
||||
$("body").append(
|
||||
'<link href="/assets/Madeleine.js/src/css/Madeleine.css" rel="stylesheet">'
|
||||
);
|
||||
Promise.all([
|
||||
lS("/assets/Madeleine.js/src/lib/stats.js"),
|
||||
lS("/assets/Madeleine.js/src/lib/detector.js"),
|
||||
lS("/assets/Madeleine.js/src/lib/three.min.js"),
|
||||
lS("/assets/Madeleine.js/src/Madeleine.js"),
|
||||
]).then(function () {
|
||||
$(".view-raw")
|
||||
.attr("id", "view-raw")
|
||||
.attr("style", "padding: 0;margin-bottom: -10px;");
|
||||
new Madeleine({
|
||||
target: "view-raw",
|
||||
data: $('.view-raw>a[href$=".stl" i]').attr("href"),
|
||||
path: "/assets/Madeleine.js/src",
|
||||
});
|
||||
$('.view-raw>a[href$=".stl"]').remove();
|
||||
});
|
||||
}
|
||||
</script>
|
||||
```
|
||||
|
||||
到文件 `templates/custom/footer.tmpl`
|
||||
|
||||
您還需要下載庫 [Madeleine.js](https://github.com/beige90/Madeleine.js) 的內容並將其放置在 `$GITEA_CUSTOM/public/assets/` 文件夾下。
|
||||
|
||||
您應該最終得到類似於以下結構的文件夾：
|
||||
|
||||
```
|
||||
$GITEA_CUSTOM/templates
|
||||
-- custom
|
||||
`-- footer.tmpl
|
||||
|
||||
$GITEA_CUSTOM/public/assets/
|
||||
-- Madeleine.js
|
||||
|-- LICENSE
|
||||
|-- README.md
|
||||
|-- css
|
||||
| |-- pygment_trac.css
|
||||
| `-- stylesheet.css
|
||||
|-- examples
|
||||
| |-- ajax.html
|
||||
| |-- index.html
|
||||
| `-- upload.html
|
||||
|-- images
|
||||
| |-- bg_hr.png
|
||||
| |-- blacktocat.png
|
||||
| |-- icon_download.png
|
||||
| `-- sprite_download.png
|
||||
|-- models
|
||||
| |-- dino2.stl
|
||||
| |-- ducati.stl
|
||||
| |-- gallardo.stl
|
||||
| |-- lamp.stl
|
||||
| |-- octocat.stl
|
||||
| |-- skull.stl
|
||||
| `-- treefrog.stl
|
||||
`-- src
|
||||
|-- Madeleine.js
|
||||
|-- css
|
||||
| `-- Madeleine.css
|
||||
|-- icons
|
||||
| |-- logo.png
|
||||
| |-- madeleine.eot
|
||||
| |-- madeleine.svg
|
||||
| |-- madeleine.ttf
|
||||
| `-- madeleine.woff
|
||||
`-- lib
|
||||
|-- MadeleineConverter.js
|
||||
|-- MadeleineLoader.js
|
||||
|-- detector.js
|
||||
|-- stats.js
|
||||
`-- three.min.js
|
||||
```
|
||||
|
||||
然後重啟 Gitea 並在您的 Gitea 實例上打開 STL 文件。
|
||||
|
||||
## 自定義 Gitea 郵件
|
||||
|
||||
`$GITEA_CUSTOM/templates/mail` 文件夾允許更改 Gitea 的每封郵件的正文。
|
||||
可以在 Gitea 源代碼的 [`templates/mail`](https://github.com/go-gitea/gitea/tree/main/templates/mail) 目錄中找到要覆蓋的模板。
|
||||
通過在 `$GITEA_CUSTOM/templates/mail` 下製作文件副本來覆蓋，使用與源相匹配的完整路徑結構。
|
||||
|
||||
任何包含在 `{{` 和 `}}` 之間的語句都是 Gitea 的模板語法，應在完全理解這些組件之前不要觸摸。
|
||||
|
||||
## 向 Gitea 添加分析
|
||||
|
||||
可以向 Gitea 添加 Google Analytics、Matomo（以前稱為 Piwik）和其他分析服務。要添加跟踪代碼，請參閱本文檔的“頁面的其他添加”部分，並將 JavaScript 添加到 `$GITEA_CUSTOM/templates/custom/header.tmpl` 文件中。
|
||||
|
||||
## 自定義 gitignores、標籤、許可證、本地化和 readmes
|
||||
|
||||
將自定義文件放置在 `custom/options` 下的相應子文件夾中。
|
||||
|
||||
:::note
|
||||
文件不應具有文件擴展名，例如 `Labels` 而不是 `Labels.txt`
|
||||
:::
|
||||
|
||||
### gitignores
|
||||
|
||||
要添加自定義 .gitignore，請將包含現有 [.gitignore 規則](https://git-scm.com/docs/gitignore) 的文件添加到 `$GITEA_CUSTOM/options/gitignore`
|
||||
|
||||
## 自定義 git 配置
|
||||
|
||||
從 Gitea 1.20 開始，您可以通過 `git.config` 部分自定義 git 配置。
|
||||
|
||||
### 啟用簽名 git 推送
|
||||
|
||||
要啟用簽名 git 推送，請設置以下兩個選項：
|
||||
|
||||
```ini
|
||||
[git.config]
|
||||
receive.advertisePushOptions = true
|
||||
receive.certNonceSeed = <randomstring>
|
||||
```
|
||||
|
||||
`certNonceSeed` 應設置為隨機字符串並保持秘密。
|
||||
|
||||
### 標籤
|
||||
|
||||
從 Gitea 1.19 開始，您可以將遵循 [YAML 標籤格式](https://github.com/go-gitea/gitea/blob/main/options/label/Advanced.yaml) 的文件添加到 `$GITEA_CUSTOM/options/label`：
|
||||
|
||||
```yaml
|
||||
labels:
|
||||
- name: "foo/bar" # 在下拉列表中顯示的標籤名稱
|
||||
exclusive: true # 是否使用專用命名空間進行範圍標籤。範圍分隔符為 /
|
||||
color: aabbcc # 十六進制顏色編碼
|
||||
description: Some label # 標籤意圖的長描述
|
||||
```
|
||||
|
||||
仍然可以使用 [舊文件格式](https://github.com/go-gitea/gitea/blob/main/options
|
||||
@@ -0,0 +1,115 @@
|
||||
---
|
||||
date: "2019-10-15T10:10:00+05:00"
|
||||
slug: "email-setup"
|
||||
sidebar_position: 12
|
||||
aliases:
|
||||
- /zh-tw/email-setup
|
||||
---
|
||||
|
||||
# 電子郵件設置
|
||||
|
||||
Gitea 具有發送交易電子郵件（如註冊確認）的郵件功能。它可以配置為使用 Sendmail（或兼容的 MTA，如 Postfix 和 msmtp）或直接使用 SMTP 服務器。
|
||||
|
||||
## 使用 Sendmail
|
||||
|
||||
使用 `sendmail` 命令作為郵件程序。
|
||||
|
||||
:::note
|
||||
要在官方 Gitea Docker 映像中使用，請配置為 SMTP 版本（請參閱以下部分）。
|
||||
:::
|
||||
|
||||
:::note
|
||||
對於面向互聯網的網站，請參閱您的 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 > 站點管理 > 配置 > 摘要 -> 郵件配置。
|
||||
|
||||
有關完整的選項列表，請參閱 [配置備忘單](../administration/config-cheat-sheet.md)
|
||||
|
||||
:::note
|
||||
僅當 SMTP 服務器通信使用 TLS 加密或 `HOST=localhost` 時，才支持身份驗證。TLS 加密可以通過：
|
||||
:::
|
||||
|
||||
- STARTTLS（也稱為機會性 TLS）通過端口 587。初始連接在明文上完成，但如果服務器支持，則升級為 TLS。
|
||||
- SMTPS 連接（SMTP over TLS）通過默認端口 465。從一開始就使用 TLS 連接到服務器。
|
||||
- 使用 `PROTOCOL=smtps` 強制 SMTPS 連接。（這些都稱為隱式 TLS。）
|
||||
這是由於 Go 內部庫對 STRIPTLS 攻擊的保護。
|
||||
|
||||
請注意，自 2018 年以來，[RFC8314](https://tools.ietf.org/html/rfc8314#section-3) 建議使用隱式 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
|
||||
```
|
||||
|
||||
請注意，您需要通過在 Google 帳戶上啟用 2FA 來創建和使用 [應用程序密碼](https://support.google.com/accounts/answer/185833?hl=en)。您將無法直接使用您的 Google 帳戶密碼。
|
||||
|
||||
### ProtonMail
|
||||
|
||||
此功能目前僅適用於選定的 Proton for Business 客戶以及擁有自定義域地址的 Visionary 和 Family 計劃用戶。請參閱 [ProtonMail 的 SMTP 文檔](https://proton.me/support/smtp-submission) 以獲取更多信息。此限制可以通過使用 ProtonMail Bridge 應用程序來繞過。
|
||||
|
||||
請注意，使用 SMTP 發送的電子郵件不是 [端到端加密](https://proton.me/support/proton-mail-encryption-explained) 的。然而，它們仍然像 Proton Mail 收件箱中的其他電子郵件一樣存儲為零訪問加密。
|
||||
|
||||
以下配置應適用於 ProtonMail 的 SMTP 服務器：
|
||||
|
||||
1. 在您的瀏覽器（或桌面應用程序）中，登錄到您的 Proton Mail 帳戶，然後選擇 **設置 → 所有設置 → Proton Mail → IMAP/SMTP → SMTP 令牌**。
|
||||
2. 單擊 **生成令牌**。
|
||||
3. 輸入以下詳細信息以創建新的 SMTP 令牌：
|
||||
- **令牌名稱**：選擇一個令牌名稱。這僅供您參考，不會影響令牌的功能。
|
||||
- **電子郵件地址**：選擇一個活動的自定義域地址與您的令牌配對。複製此電子郵件地址並將其用於 `app.ini` 中的 `FROM` 和 `USER` 配置。
|
||||
4. 單擊 **生成**。
|
||||
5. 輸入您的 Proton Mail 帳戶密碼。
|
||||
|
||||
您的 SMTP 用戶名和 SMTP 令牌（密碼）將生成。您現在可以將它們作為 `USER` 和 `PASSWD` 輸入到您的 `app.ini` 配置中。
|
||||
|
||||
```ini title="app.ini"
|
||||
[mailer]
|
||||
ENABLED = true
|
||||
FROM = [email protected]
|
||||
PROTOCOL = smtp+starttls
|
||||
SMTP_ADDR = smtp.protonmail.ch
|
||||
SMTP_PORT = 587
|
||||
USER = [email protected]
|
||||
PASSWD = `TOKEN`
|
||||
```
|
||||
|
||||
關閉彈出窗口後，出於安全原因，您將無法再次看到此 SMTP 令牌（密碼）。如果需要旋轉密碼，您可以隨時生成更多令牌。
|
||||
|
||||
注意：您的 Proton Mail 登錄或郵箱密碼將無法與 SMTP 一起使用。
|
||||
+50
@@ -0,0 +1,50 @@
|
||||
---
|
||||
date: "2017-04-08T11:34:00+02:00"
|
||||
slug: "environment-variables"
|
||||
sidebar_position: 10
|
||||
aliases:
|
||||
- /zh-tw/environment-variables
|
||||
---
|
||||
|
||||
# Environment variables
|
||||
|
||||
This is an inventory of Gitea environment variables. They change Gitea behaviour.
|
||||
|
||||
Initialize them before Gitea command to be effective, for example:
|
||||
|
||||
```sh
|
||||
GITEA_CUSTOM=/home/gitea/custom ./gitea web
|
||||
```
|
||||
|
||||
## From Go language
|
||||
|
||||
As Gitea is written in Go, it uses some variables that influence the behaviour of Go's runtime, such as:
|
||||
|
||||
- `GOMEMLIMIT`
|
||||
- `GOGC`
|
||||
- `GOMAXPROCS`
|
||||
- `GODEBUG`
|
||||
|
||||
For documentation about each of the variables available, refer to the
|
||||
[official Go documentation on runtime environment variables](https://pkg.go.dev/runtime#hdr-Environment_Variables).
|
||||
|
||||
## Gitea files
|
||||
|
||||
- `GITEA_WORK_DIR`: Absolute path of working directory.
|
||||
- `GITEA_CUSTOM`: Gitea uses `WorkPath`/custom folder by default. Use this variable to change _custom_ directory.
|
||||
|
||||
## Operating system specifics
|
||||
|
||||
- `USER`: System user that Gitea will run as. Used for some repository access strings.
|
||||
- `USERNAME`: if no `USER` found, Gitea will use `USERNAME`
|
||||
- `HOME`: User home directory path. The `USERPROFILE` environment variable is used in Windows.
|
||||
|
||||
### Only on Windows
|
||||
|
||||
- `USERPROFILE`: User home directory path. If empty, uses `HOMEDRIVE` + `HOMEPATH`
|
||||
- `HOMEDRIVE`: Main drive path used to access the home directory (C:)
|
||||
- `HOMEPATH`: Home relative path in the given home drive path
|
||||
|
||||
## Miscellaneous
|
||||
|
||||
- `SKIP_MINWINSVC`: If set to 1, do not run as a service on Windows.
|
||||
+184
@@ -0,0 +1,184 @@
|
||||
---
|
||||
date: "2018-11-23:00:00+02:00"
|
||||
slug: "external-renderers"
|
||||
sidebar_position: 60
|
||||
aliases:
|
||||
- /zh-tw/external-renderers
|
||||
---
|
||||
|
||||
# External renderers
|
||||
|
||||
Gitea supports custom file renderings (i.e., Jupyter notebooks, asciidoc, etc.) through external binaries,
|
||||
it is just a matter of:
|
||||
|
||||
- installing external binaries
|
||||
- add some configuration to your `app.ini` file
|
||||
- restart your Gitea instance
|
||||
|
||||
This supports rendering of whole files. If you want to render code blocks in markdown you would need to do something with javascript. See some examples on the [Customizing Gitea](../administration/customizing-gitea.md) page.
|
||||
|
||||
## Installing external binaries
|
||||
|
||||
In order to get file rendering through external binaries, their associated packages must be installed.
|
||||
If you're using a Docker image, your `Dockerfile` should contain something along this lines:
|
||||
|
||||
```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
|
||||
# install any other package you need for your external renderers
|
||||
|
||||
RUN pipx install jupyter docutils --include-deps --global
|
||||
# add above any other python package you may need to install
|
||||
```
|
||||
|
||||
## `app.ini` file configuration
|
||||
|
||||
add one `[markup.XXXXX]` section per external renderer on your custom `app.ini`:
|
||||
|
||||
```ini
|
||||
[markup.asciidoc]
|
||||
ENABLED = true
|
||||
FILE_EXTENSIONS = .adoc,.asciidoc
|
||||
RENDER_COMMAND = "asciidoctor -s -a showtitle --out-file=- -"
|
||||
; Input is not a standard input but a 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
|
||||
```
|
||||
|
||||
If your external markup relies on additional classes and attributes on the generated HTML elements, you might need to enable custom sanitizer policies. Gitea uses the [`bluemonday`](https://godoc.org/github.com/microcosm-cc/bluemonday) package as our HTML sanitizer. The example below could be used to support server-side [KaTeX](https://katex.org/) rendering output from [`pandoc`](https://pandoc.org/).
|
||||
|
||||
```ini
|
||||
[markup.sanitizer.TeX]
|
||||
; Pandoc renders TeX segments as <span>s with the "math" class, optionally
|
||||
; with "inline" or "display" classes depending on context.
|
||||
; - note this is different from the built-in math support in our markdown parser which uses <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
|
||||
```
|
||||
|
||||
You must define `ELEMENT` and `ALLOW_ATTR` in each section.
|
||||
|
||||
To define multiple entries, add a unique alphanumeric suffix (e.g., `[markup.sanitizer.1]` and `[markup.sanitizer.something]`).
|
||||
|
||||
To apply a sanitisation rules only for a specify external renderer they must use the renderer name, e.g. `[markup.sanitizer.asciidoc.rule-1]`, `[markup.sanitizer.<renderer>.rule-1]`.
|
||||
|
||||
**Note**: If the rule is defined above the renderer ini section or the name does not match a renderer it is applied to every renderer.
|
||||
|
||||
Once your configuration changes have been made, restart Gitea to have changes take effect.
|
||||
|
||||
**Note**: Prior to Gitea 1.12 there was a single `markup.sanitiser` section with keys that were redefined for multiple rules, however,
|
||||
there were significant problems with this method of configuration necessitating configuration through multiple sections.
|
||||
|
||||
### Example: HTML
|
||||
|
||||
Render HTML files directly:
|
||||
|
||||
```ini
|
||||
[markup.html]
|
||||
ENABLED = true
|
||||
FILE_EXTENSIONS = .html,.htm
|
||||
RENDER_COMMAND = cat
|
||||
; Input is not a standard input but a file
|
||||
IS_INPUT_FILE = true
|
||||
|
||||
[markup.sanitizer.html.1]
|
||||
ELEMENT = div
|
||||
ALLOW_ATTR = class
|
||||
|
||||
[markup.sanitizer.html.2]
|
||||
ELEMENT = a
|
||||
ALLOW_ATTR = class
|
||||
```
|
||||
|
||||
### Example: Office DOCX
|
||||
|
||||
Display Office DOCX files with [`pandoc`](https://pandoc.org/):
|
||||
|
||||
```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
|
||||
```
|
||||
|
||||
The template file has the following content:
|
||||
|
||||
```
|
||||
$body$
|
||||
```
|
||||
|
||||
### Example: Jupyter Notebook
|
||||
|
||||
Display Jupyter Notebook files with [`nbconvert`](https://github.com/jupyter/nbconvert):
|
||||
|
||||
```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
|
||||
```
|
||||
|
||||
## Customizing CSS
|
||||
|
||||
The external renderer is specified in the .ini in the format `[markup.XXXXX]` and the HTML supplied by your external renderer will be wrapped in a `<div>` with classes `markup` and `XXXXX`. The `markup` class provides out of the box styling (as does `markdown` if `XXXXX` is `markdown`). Otherwise you can use these classes to specifically target the contents of your rendered HTML.
|
||||
|
||||
And so you could write some 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;
|
||||
}
|
||||
```
|
||||
|
||||
Add your stylesheet to your custom directory e.g `custom/public/assets/css/my-style-XXXXX.css` and import it using a custom header file `custom/templates/custom/header.tmpl`:
|
||||
|
||||
```html
|
||||
<link rel="stylesheet" href="{{AppSubUrl}}/assets/css/my-style-XXXXX.css" />
|
||||
```
|
||||
+118
@@ -0,0 +1,118 @@
|
||||
---
|
||||
date: "2018-05-11T11:00:00+02:00"
|
||||
slug: "fail2ban-setup"
|
||||
sidebar_position: 16
|
||||
aliases:
|
||||
- /zh-tw/fail2ban-setup
|
||||
---
|
||||
|
||||
# Fail2ban Setup
|
||||
|
||||
**Remember that fail2ban is powerful and can cause lots of issues if you do it incorrectly, so make
|
||||
sure to test this before relying on it so you don't lock yourself out.**
|
||||
|
||||
Gitea returns an HTTP 200 for bad logins in the web logs, but if you have logging options on in
|
||||
`app.ini`, then you should be able to go off of `log/gitea.log`, which gives you something like this
|
||||
on a bad authentication from the web or CLI using SSH or HTTP respectively:
|
||||
|
||||
```log
|
||||
2018/04/26 18:15:54 [I] Failed authentication attempt for user from xxx.xxx.xxx.xxx
|
||||
```
|
||||
|
||||
```log
|
||||
2020/10/15 16:05:09 modules/ssh/ssh.go:143:publicKeyHandler() [W] Failed authentication attempt from xxx.xxx.xxx.xxx
|
||||
```
|
||||
|
||||
(DEPRECATED: This may be a false positive as the user may still go on to correctly authenticate.)
|
||||
|
||||
```log
|
||||
2020/10/15 16:05:09 modules/ssh/ssh.go:155:publicKeyHandler() [W] Failed authentication attempt from xxx.xxx.xxx.xxx
|
||||
```
|
||||
|
||||
(DEPRECATED: This may be a false positive as the user may still go on to correctly authenticate.)
|
||||
|
||||
```log
|
||||
2020/10/15 16:05:09 modules/ssh/ssh.go:198:publicKeyHandler() [W] Failed authentication attempt from xxx.xxx.xxx.xxx
|
||||
```
|
||||
|
||||
(DEPRECATED: This may be a false positive as the user may still go on to correctly authenticate.)
|
||||
|
||||
```log
|
||||
2020/10/15 16:05:09 modules/ssh/ssh.go:213:publicKeyHandler() [W] Failed authentication attempt from xxx.xxx.xxx.xxx
|
||||
```
|
||||
|
||||
(DEPRECATED: This may be a false positive as the user may still go on to correctly authenticate.)
|
||||
|
||||
```log
|
||||
2020/10/15 16:05:09 modules/ssh/ssh.go:227:publicKeyHandler() [W] Failed authentication attempt from xxx.xxx.xxx.xxx
|
||||
```
|
||||
|
||||
(DEPRECATED: This may be a false positive as the user may still go on to correctly authenticate.)
|
||||
|
||||
```log
|
||||
2020/10/15 16:05:09 modules/ssh/ssh.go:249:sshConnectionFailed() [W] Failed authentication attempt from xxx.xxx.xxx.xxx
|
||||
```
|
||||
|
||||
(From 1.15 this new message will available and doesn't have any of the false positive results that above messages from publicKeyHandler do. This will only be logged if the user has completely failed authentication.)
|
||||
|
||||
```log
|
||||
2020/10/15 16:08:44 ...s/context/context.go:204:HandleText() [E] invalid credentials from xxx.xxx.xxx.xxx
|
||||
```
|
||||
|
||||
Add our filter in `/etc/fail2ban/filter.d/gitea.local`:
|
||||
|
||||
```ini
|
||||
# gitea.local
|
||||
[Definition]
|
||||
failregex = .*(Failed authentication attempt|invalid credentials|Attempted access of unknown user).* from <HOST>
|
||||
ignoreregex =
|
||||
```
|
||||
|
||||
Add our jail in `/etc/fail2ban/jail.d/gitea.local`:
|
||||
|
||||
```ini
|
||||
[gitea]
|
||||
enabled = true
|
||||
filter = gitea
|
||||
logpath = /var/lib/gitea/log/gitea.log
|
||||
maxretry = 10
|
||||
findtime = 3600
|
||||
bantime = 900
|
||||
action = iptables-allports
|
||||
```
|
||||
|
||||
If you're using Docker, you'll also need to add an additional jail to handle the **FORWARD**
|
||||
chain in **iptables**. Configure it in `/etc/fail2ban/jail.d/gitea-docker.local`:
|
||||
|
||||
```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"]
|
||||
```
|
||||
|
||||
Then simply run `service fail2ban restart` to apply your changes. You can check to see if
|
||||
fail2ban has accepted your configuration using `service fail2ban status`.
|
||||
|
||||
Make sure and read up on fail2ban and configure it to your needs, this bans someone
|
||||
for **15 minutes** (from all ports) when they fail authentication 10 times in an hour.
|
||||
|
||||
If you run Gitea behind a reverse proxy with Nginx (for example with Docker), you need to add
|
||||
this to your Nginx configuration so that IPs don't show up as 127.0.0.1:
|
||||
|
||||
```
|
||||
proxy_set_header X-Real-IP $remote_addr;
|
||||
```
|
||||
|
||||
The security options in `app.ini` need to be adjusted to allow the interpretation of the headers
|
||||
as well as the list of IP addresses and networks that describe trusted proxy servers
|
||||
(See the [configuration cheat sheet](../administration/config-cheat-sheet.md#security-security) for more information).
|
||||
|
||||
```
|
||||
REVERSE_PROXY_LIMIT = 1
|
||||
REVERSE_PROXY_TRUSTED_PROXIES = 127.0.0.1/8 ; 172.17.0.0/16 for the docker default network
|
||||
```
|
||||
+42
@@ -0,0 +1,42 @@
|
||||
---
|
||||
date: "2019-10-06T08:00:00+05: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
|
||||
```
|
||||
|
||||
:::note
|
||||
LFS 服務器支持需要在服務器上安裝至少 Git v2.1.2
|
||||
:::
|
||||
|
||||
# Git LFS 純 SSH 協議
|
||||
|
||||
LFS 純 SSH 協議支持純粹通過 SSH 進行 LFS 連接
|
||||
（無需為 Gitea 服務器公開 HTTP 端點）。
|
||||
可以通過配置選項 `server.LFS_ALLOW_PURE_SSH` 啟用對它的支持：
|
||||
|
||||
```ini
|
||||
[server]
|
||||
LFS_ALLOW_PURE_SSH = true
|
||||
```
|
||||
|
||||
:::note
|
||||
由於 `git-lfs` 客戶端中存在一個未解決的錯誤，該選項目前默認設置為 false，該錯誤會導致 SSH 傳輸掛起：https://github.com/git-lfs/git-lfs/pull/5816
|
||||
可以通過在所有客戶端機器上設置 git 配置來解決此問題：
|
||||
`git config --global lfs.ssh.automultiplex false`
|
||||
:::
|
||||
+93
@@ -0,0 +1,93 @@
|
||||
---
|
||||
date: "2018-06-02T11:00:00+02:00"
|
||||
slug: "https-setup"
|
||||
sidebar_position: 12
|
||||
aliases:
|
||||
- /zh-tw/https-setup
|
||||
---
|
||||
|
||||
# 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 中的第一個條目，後面依次是中間證書（如果有）。根證書不必包含在內，因為連接的客戶端必須已經擁有它以建立信任關係。
|
||||
要了解更多有關配置值的信息，請查看 [配置備忘單](./config-cheat-sheet.md#server-server)。
|
||||
|
||||
對於 `CERT_FILE` 或 `KEY_FILE` 字段，文件路徑在相對路徑時相對於 `GITEA_CUSTOM` 環境變量。它也可以是絕對路徑。
|
||||
|
||||
### 設置 HTTP 重定向
|
||||
|
||||
Gitea 服務器只能監聽一個端口；要將 HTTP 請求重定向到 HTTPS 端口，您需要啟用 HTTP 重定向服務：
|
||||
|
||||
```ini
|
||||
[server]
|
||||
REDIRECT_OTHER_PORT = true
|
||||
; 重定向服務應監聽的端口
|
||||
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 挑戰通過並驗證您的域所有權，必須由 gitea 實例服務外部流量到端口 `80`（`HTTP-01`）或端口 `443`（`TLS-ALPN-01`）。設置 [HTTP 重定向](#setting-up-http-redirection) 和端口轉發可能需要正確路由外部流量。否則，正常流量到端口 `80` 將自動重定向到 HTTPS。**您必須同意** ACME 提供商的服務條款（默認為 Let's Encrypt 的 [服務條款](https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf)）。
|
||||
|
||||
使用默認 Let's Encrypt 的最小設置：
|
||||
|
||||
```ini
|
||||
[server]
|
||||
PROTOCOL=https
|
||||
DOMAIN=git.example.com
|
||||
ENABLE_ACME=true
|
||||
ACME_ACCEPTTOS=true
|
||||
ACME_DIRECTORY=https
|
||||
;; 電子郵件可以在此處省略，並在首次運行時手動提供，之後將被緩存
|
||||
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
|
||||
;; 如果使用系統的信任，則可以省略
|
||||
;ACME_CA_ROOT=/path/to/root_ca.crt
|
||||
ACME_DIRECTORY=https
|
||||
ACME_EMAIL=[email protected]
|
||||
```
|
||||
|
||||
要了解更多有關配置值的信息，請查看 [配置備忘單](./config-cheat-sheet.md#server-server)。
|
||||
|
||||
## 使用反向代理
|
||||
|
||||
按照 [反向代理指南](../administration/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)
|
||||
|
||||
:::note
|
||||
僅在代理級別啟用 HTTPS 被稱為 [TLS 終止代理](https://en.wikipedia.org/wiki/TLS_termination_proxy)。代理服務器接受傳入的 TLS 連接，解密內容，並將現在未加密的內容傳遞給 Gitea。只要代理和 Gitea 實例位於同一台機器上，或者位於私有網絡內的不同機器上（代理暴露於外部網絡），這通常是可以的。如果您的 Gitea 實例與代理之間隔著公共網絡，或者您希望完全端到端加密，您也可以 [使用內置服務器直接在 Gitea 中啟用 HTTPS 支持](#using-the-built-in-server) 並通過 HTTPS 轉發連接。
|
||||
:::
|
||||
+263
@@ -0,0 +1,263 @@
|
||||
---
|
||||
date: "2019-04-02T17:06:00+01:00"
|
||||
slug: "logging-config"
|
||||
sidebar_position: 40
|
||||
aliases:
|
||||
- /zh-tw/logging-configuration
|
||||
---
|
||||
|
||||
# 日誌配置
|
||||
|
||||
Gitea 的日誌配置主要包括 3 種組件：
|
||||
|
||||
- `[log]` 部分用於一般配置
|
||||
- `[log.<mode-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 =
|
||||
|
||||
; 這是“console”模式的配置選項（上面由 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]
|
||||
; 默認情況下，MODE（實際上是此日誌記錄器的輸出寫入器）取自部分名稱，因此我們也不需要設置它
|
||||
; MODE = file
|
||||
|
||||
[log.file-error]
|
||||
MODE = file
|
||||
LEVEL = Error
|
||||
FILE_NAME = file-error.log
|
||||
```
|
||||
|
||||
## 日誌輸出（模式和寫入器）
|
||||
|
||||
Gitea 提供以下日誌輸出寫入器：
|
||||
|
||||
- `console` - 日誌記錄到 `stdout`（或如果在配置中設置，則記錄到 `stderr`）
|
||||
- `file` - 日誌記錄到文件
|
||||
- `conn` - 日誌記錄到套接字（網絡或 unix）
|
||||
|
||||
### 通用配置
|
||||
|
||||
某些配置對所有日誌輸出模式都是通用的：
|
||||
|
||||
- `MODE` 是日誌輸出寫入器的模式。它將默認為 ini 部分中的模式名稱。因此 `[log.console]` 將默認為 `MODE = console`。
|
||||
- `LEVEL` 是此輸出的最低級別。
|
||||
- `STACKTRACE_LEVEL` 是此輸出將打印堆棧跟蹤的最低級別。
|
||||
- `COLORIZE` 將默認為 `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]` 表示信息。
|
||||
- `level` - 括號中的級別 `[INFO]`。
|
||||
- `gopid` - 上下文的 Goroutine-PID。
|
||||
- `medfile` - 文件名的最後 20 個字符 - 相當於 `shortfile,longfile`。
|
||||
- `stdflags` - 相當於 `date,time,medfile,shortfuncname,levelinitial`。
|
||||
|
||||
### 控制台模式
|
||||
|
||||
在此模式下，日誌記錄器將轉發日誌消息到附加到 Gitea 進程的 stdout 和 stderr 流。
|
||||
|
||||
對於控制台模式的日誌記錄器，如果不是在 Windows 上，或者 Windows 終端可以設置為 ANSI 模式或是 cygwin 或 Msys 管道，則 `COLORIZE` 將默認為 `true`。
|
||||
|
||||
設置：
|
||||
|
||||
- `STDERR`：**false**：日誌記錄器是否應打印到 `stderr` 而不是 `stdout`。
|
||||
|
||||
### 文件模式
|
||||
|
||||
在此模式下，日誌記錄器將日誌消息保存到文件中。
|
||||
|
||||
設置：
|
||||
|
||||
- `FILE_NAME`：寫入日誌事件的文件，相對於 `ROOT_PATH`，默認為 `%(ROOT_PATH)/gitea.log`。例外：訪問日誌將默認為 `%(ROOT_PATH)/access.log`。
|
||||
- `MAX_SIZE_SHIFT`：**28**：單個文件的最大大小移位。28 代表 256Mb。詳細信息請參見下文。
|
||||
- `LOG_ROTATE` **true**：是否旋轉日誌文件。TODO：如果為 false，是否會在每日旋轉時刪除，還是什麼都不做？。
|
||||
- `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（最佳壓縮）。也可以選擇 [DefaultCompression](https://pkg.go.dev/compress/gzip#pkg-constants)（-1）和 [HuffmanOnly](https://pkg.go.dev/compress/flate#HuffmanOnly)（-2）。
|
||||
請注意，更好的壓縮可能會帶來更高的資源使用。
|
||||
|
||||
### 連接模式
|
||||
|
||||
在此模式下，日誌記錄器將通過網絡套接字發送日誌消息。
|
||||
|
||||
設置：
|
||||
|
||||
- `ADDR`：**:7020**：設置要連接的地址。
|
||||
- `PROTOCOL`：**tcp**：設置協議，可以是“tcp”、“unix”或“udp”。
|
||||
- `RECONNECT`：**false**：連接丟失時嘗試重新連接。
|
||||
- `RECONNECT_ON_MSG`：**false**：為每條消息重新連接主機。
|
||||
|
||||
### “路由器”日誌記錄器
|
||||
|
||||
當 Gitea 的路由處理程序工作時，路由器日誌記錄器記錄以下消息類型：
|
||||
|
||||
- `started` 消息將在 TRACE 級別記錄
|
||||
- `polling`/`completed` 路由將在 INFO 級別記錄。例外：“/assets” 靜態資源請求也在 TRACE 級別記錄。
|
||||
- `slow` 路由將在 WARN 級別記錄
|
||||
- `failed` 路由將在 WARN 級別記錄
|
||||
|
||||
### “XORM”日誌記錄器
|
||||
|
||||
要使 XORM 輸出 SQL 日誌，應在 `[database]` 部分中將 `LOG_SQL` 設置為 `true`。
|
||||
|
||||
### “訪問”日誌記錄器
|
||||
|
||||
訪問日誌記錄器是 Gitea 1.9 以來的新日誌記錄器。它提供了符合 NCSA 通用日誌格式的日誌格式。它高度可配置，但更改其模板時應謹慎。此日誌記錄器的主要好處是 Gitea 現在可以以標準日誌格式記錄訪問，因此可以使用標準工具。
|
||||
|
||||
您可以使用 `logger.access.MODE = ...` 啟用此日誌記錄器。
|
||||
|
||||
如果需要，可以通過更改 `ACCESS_LOG_TEMPLATE` 的值來更改訪問日誌記錄器的格式。
|
||||
|
||||
請注意，訪問日誌記錄器將在 `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`
|
||||
|
||||
更改此模板時必須謹慎，因為它在標準的恐慌恢復陷阱之外運行。模板應該盡可能簡單，因為它在每個請求中運行。
|
||||
|
||||
## 釋放和重新打開、暫停和恢復日誌記錄
|
||||
|
||||
如果您在 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`。
|
||||
+252
@@ -0,0 +1,252 @@
|
||||
---
|
||||
date: "2019-10-23T17:00:00-03: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/{action type}/{action name}.tmpl
|
||||
```
|
||||
|
||||
其中 `{action type}` 是 `issue` 或 `pull`（對於拉取請求）之一，`{action name}` 是上面列出的名稱之一。
|
||||
|
||||
例如，有關拉取請求評論的郵件的特定模板為：
|
||||
|
||||
```sh
|
||||
custom/templates/mail/pull/comment.tmpl
|
||||
```
|
||||
|
||||
但是，不需要為每個操作類型/名稱組合創建模板。
|
||||
使用回退系統來選擇事件的適當模板。使用此列表中的 _第一個存在的_ 模板：
|
||||
|
||||
- 所需 **操作類型** 和 **操作名稱** 的特定模板。
|
||||
- 操作類型 `issue` 和所需 **操作名稱** 的模板。
|
||||
- 操作類型 `issue` 和操作名稱 `default` 的模板。
|
||||
|
||||
唯一必需的模板是操作類型 `issue` 和操作名稱 `default`，它已嵌入 Gitea 中，除非用戶在 `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 的 **內部默認值**。
|
||||
|
||||
內部默認（回退）主題相當於：
|
||||
|
||||
```sh
|
||||
{{.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` 下，並相對於該目錄引用。例如，`custom/mail/styles/base.tmpl` 可以使用 `{{template styles/base}}` 包含。
|
||||
|
||||
郵件以 `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"}}
|
||||
created
|
||||
{{else if eq .ActionName "comment"}}
|
||||
commented on
|
||||
{{else if eq .ActionName "close"}}
|
||||
closed
|
||||
{{else if eq .ActionName "reopen"}}
|
||||
reopened
|
||||
{{else}}
|
||||
updated
|
||||
{{end}}
|
||||
{{if eq .ActionType "issue"}}
|
||||
issue
|
||||
{{else}}
|
||||
pull request
|
||||
{{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>
|
||||
You are receiving this because @{{.Doer.Name}} mentioned you.
|
||||
</p>
|
||||
{{end}}
|
||||
<p>
|
||||
<p>
|
||||
<a href="{{AppUrl}}/{{.Doer.LowerName}}">@{{.Doer.Name}}</a>
|
||||
{{if not (eq .Doer.FullName "")}}
|
||||
({{.Doer.FullName}})
|
||||
{{end}}
|
||||
{{if eq .ActionName "new"}}
|
||||
created
|
||||
{{else if eq .ActionName "close"}}
|
||||
closed
|
||||
{{else if eq .ActionName "reopen"}}
|
||||
reopened
|
||||
{{else}}
|
||||
updated
|
||||
{{end}}
|
||||
<a href="{{.Link}}">{{.Repo}}#{{.Issue.Index}}</a>.
|
||||
</p>
|
||||
{{if not (eq .Body "")}}
|
||||
<h3>Message content</h3>
|
||||
<hr>
|
||||
{{.Body}}
|
||||
{{end}}
|
||||
</p>
|
||||
<hr>
|
||||
<p>
|
||||
<a href="{{.Link}}">View it on Gitea</a>.
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
```
|
||||
|
||||
此模板生成如下內容：
|
||||
|
||||
### 主題
|
||||
|
||||
> [mike/stuff] @rhonda commented on pull request #38: New color palette
|
||||
|
||||
### 郵件正文
|
||||
|
||||
> [@rhonda](#) (Rhonda Myers) updated [mike/stuff#38](#).
|
||||
>
|
||||
> #### Message content
|
||||
>
|
||||
> \_******\*\*******\*\*\*\*******\*\*******\_******\*\*******\*\*\*\*******\*\*******
|
||||
>
|
||||
> Mike, I think we should tone down the blues a little.
|
||||
> \_******\*\*******\*\*\*\*******\*\*******\_******\*\*******\*\*\*\*******\*\*******
|
||||
>
|
||||
> [View it on 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,56 @@
|
||||
---
|
||||
date: "2019-09-06T01:35:00-03:00"
|
||||
slug: "repo-indexer"
|
||||
sidebar_position: 45
|
||||
aliases:
|
||||
- /zh-tw/repo-indexer
|
||||
---
|
||||
|
||||
# 存儲庫索引器
|
||||
|
||||
## 無需索引器的內置存儲庫代碼搜索
|
||||
|
||||
用戶可以在不設置存儲庫索引器的情況下進行存儲庫級別的代碼搜索。
|
||||
內置代碼搜索基於 `git grep` 命令，對於小型存儲庫來說快速且高效。
|
||||
通過設置存儲庫索引器可以實現更好的代碼搜索支持。
|
||||
|
||||
## 設置存儲庫索引器
|
||||
|
||||
Gitea 可以通過在您的 [`app.ini`](../administration/config-cheat-sheet.md) 中啟用此功能來搜索存儲庫文件：
|
||||
|
||||
```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` 是等效的。
|
||||
+385
@@ -0,0 +1,385 @@
|
||||
---
|
||||
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-Fowarded-Proto` 標頭正確傳遞給 Gitea，以使 Gitea 看到實際訪問的 URL。
|
||||
|
||||
### 使用子路徑
|
||||
|
||||
通常**不建議**將 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 實例，請將以下 `server` 部分添加到 `nginx.conf` 的 `http` 部分中。
|
||||
|
||||
確保 `client_max_body_size` 足夠大，否則在上傳大文件時會出現“413 Request Entity Too Large”錯誤。
|
||||
|
||||
```nginx
|
||||
server {
|
||||
...
|
||||
location / {
|
||||
client_max_body_size 512M;
|
||||
proxy_pass http://localhost:3000;
|
||||
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 共享域名，
|
||||
您可以通過將以下 `server` 部分添加到 `nginx.conf` 的 `http` 部分中來設置 Nginx 以在子路徑下服務 Gitea：
|
||||
|
||||
```nginx
|
||||
server {
|
||||
...
|
||||
location ~ ^/(gitea|v2)($|/) {
|
||||
client_max_body_size 512M;
|
||||
|
||||
# 使 nginx 使用未轉義的 URI，保持“%2F”不變，刪除“/gitea”子路徑前綴，保持“/v2”不變。
|
||||
rewrite ^ $request_uri;
|
||||
rewrite ^/(gitea($|/))?(.*) /$3 break;
|
||||
proxy_pass http://127.0.0.1:3000$uri;
|
||||
|
||||
# 其他常見的 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;
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
然後您**必須**在配置中正確設置 `[server] ROOT_URL = http://git.example.com/gitea/`。
|
||||
|
||||
## Nginx 和直接服務靜態資源
|
||||
|
||||
我們可以通過將請求分為靜態和動態來調整性能。
|
||||
|
||||
CSS 文件、JavaScript 文件、圖像和網頁字體是靜態內容。
|
||||
首頁、存儲庫視圖或問題列表是動態內容。
|
||||
|
||||
Nginx 可以直接服務靜態資源，僅代理動態請求到 Gitea。
|
||||
Nginx 對於服務靜態內容進行了優化，而代理大響應可能正好相反
|
||||
（請參閱 [https://serverfault.com/q/587386](https://serverfault.com/q/587386)）。
|
||||
|
||||
將 Gitea 源存儲庫的快照下載到 `/path/to/gitea/`。
|
||||
之後，在存儲庫目錄中運行 `make frontend` 以生成靜態資源。我們只對此任務的 `public/` 目錄感興趣，因此您可以刪除其餘部分。
|
||||
（您需要安裝 [Node with npm](https://nodejs.org/en/download/) 和 `make` 來生成靜態資源）
|
||||
|
||||
根據您的用戶基數規模，您可能希望將流量分為兩個不同的服務器，
|
||||
或使用 cdn 來存儲靜態文件。
|
||||
|
||||
### 單節點和單域
|
||||
|
||||
在您的配置中設置 `[server] STATIC_URL_PREFIX = /_/static`。
|
||||
|
||||
```nginx
|
||||
server {
|
||||
listen 80;
|
||||
server_name git.example.com;
|
||||
|
||||
location /_/static/assets/ {
|
||||
alias /path/to/gitea/public/;
|
||||
}
|
||||
|
||||
location / {
|
||||
proxy_pass http://localhost:3000;
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### 兩個節點和兩個域
|
||||
|
||||
在您的配置中設置 `[server] STATIC_URL_PREFIX = http://cdn.example.com/gitea`。
|
||||
|
||||
```nginx
|
||||
# 運行 Gitea 的應用服務器
|
||||
server {
|
||||
listen 80;
|
||||
server_name git.example.com;
|
||||
|
||||
location / {
|
||||
proxy_pass http://localhost:3000;
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
```nginx
|
||||
# 靜態內容交付服務器
|
||||
server {
|
||||
listen 80;
|
||||
server_name cdn.example.com;
|
||||
|
||||
location /gitea/ {
|
||||
alias /path/to/gitea/public/;
|
||||
}
|
||||
|
||||
location / {
|
||||
return 404;
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## 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
|
||||
RequestHeader set "X-Forwarded-Proto" expr=%{REQUEST_SCHEME}
|
||||
</VirtualHost>
|
||||
```
|
||||
|
||||
:::note
|
||||
必須啟用以下 Apache HTTPD 模塊：`proxy`、`proxy_http`。
|
||||
:::
|
||||
|
||||
如果您希望使用 Let's Encrypt 進行 webroot 驗證，請在 `ProxyPass` 之前添加 `ProxyPass /.well-known !` 行，以禁用將這些請求代理到 Gitea。
|
||||
|
||||
## Apache HTTPD 與子路徑
|
||||
|
||||
如果您已經有一個站點，並且希望 Gitea 共享域名，您可以通過將以下內容添加到您的 Apache HTTPD 配置中（通常位於 Ubuntu 的 `/etc/apache2/httpd.conf`）來設置 Apache HTTPD 以在子路徑下服務 Gitea：
|
||||
|
||||
```apacheconf
|
||||
<VirtualHost *:80>
|
||||
...
|
||||
<Proxy *>
|
||||
Order allow,deny
|
||||
Allow from all
|
||||
</Proxy>
|
||||
AllowEncodedSlashes NoDecode
|
||||
# 注意：在 /git 或端口之後沒有尾隨斜杠
|
||||
ProxyPass /git http://localhost:3000 nocanon
|
||||
ProxyPreserveHost On
|
||||
RequestHeader set "X-Forwarded-Proto" expr=%{REQUEST_SCHEME}
|
||||
</VirtualHost>
|
||||
```
|
||||
|
||||
然後您**必須**在配置中正確設置 `[server] ROOT_URL = http://git.example.com/git/`。
|
||||
|
||||
:::note
|
||||
必須啟用以下 Apache HTTPD 模塊：`proxy`、`proxy_http`。
|
||||
:::
|
||||
|
||||
## Caddy
|
||||
|
||||
如果您希望 Caddy 服務您的 Gitea 實例，您可以將以下服務器塊添加到您的 Caddyfile 中：
|
||||
|
||||
```
|
||||
git.example.com {
|
||||
reverse_proxy localhost:3000
|
||||
}
|
||||
```
|
||||
|
||||
## Caddy 與子路徑
|
||||
|
||||
如果您已經有一個站點，並且希望 Gitea 共享域名，您可以通過將以下內容添加到您的 Caddyfile 中的服務器塊來設置 Caddy 以在子路徑下服務 Gitea：
|
||||
|
||||
```
|
||||
git.example.com {
|
||||
route /git/* {
|
||||
uri strip_prefix /git
|
||||
reverse_proxy localhost:3000
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
然後在您的配置中設置 `[server] ROOT_URL = http://git.example.com/git/`。
|
||||
|
||||
## IIS
|
||||
|
||||
如果您希望使用 IIS 運行 Gitea。您需要設置 IIS 並使用 URL Rewrite 作為反向代理。
|
||||
|
||||
1. 在 IIS 中設置一個空網站，命名為 `Gitea Proxy`。
|
||||
2. 按照 [Microsoft 的技術社區指南設置 IIS 並使用 URL Rewrite](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）安裝應用程序請求路由（簡稱 ARR），或從 [IIS.net](https://www.iis.net/downloads/microsoft/application-request-routing) 下載擴展。
|
||||
- 安裝模塊後，您將在 IIS 管理控制台中看到一個名為 URL Rewrite 的新圖標。
|
||||
- 打開 IIS 管理控制台，從左側樹視圖中單擊 `Gitea Proxy` 網站。從中間窗格中選擇並雙擊 URL Rewrite 圖標以加載 URL Rewrite 界面。
|
||||
- 從管理控制台的右側窗格中選擇 `Add Rule` 操作，並從 `Inbound and Outbound Rules` 類別中選擇 `Reverse Proxy Rule`。
|
||||
- 在 Inbound Rules 部分中，將服務器名稱設置為運行 Gitea 的主機及其端口。例如，如果您在本地主機上運行 Gitea，端口為 3000，則以下應該可以工作：`127.0.0.1:3000`
|
||||
- 啟用 SSL 卸載
|
||||
- 在 Outbound Rules 中，確保設置 `Rewrite the domain names of the links in HTTP response`，並將 `From:` 字段設置為上述內容，將 `To:` 設置為您的外部主機名，例如：`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">
|
||||
<!-- 在此處正確設置模式 - 如果您只想接受 http 或 https -->
|
||||
<!-- 根據需要更改模式和操作值 -->
|
||||
<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>
|
||||
<!-- 將所有擴展名映射到相同的 MIME 類型，以便可以下載所有文件。 -->
|
||||
<staticContent>
|
||||
<clear />
|
||||
<mimeMap fileExtension="*" mimeType="application/octet-stream" />
|
||||
</staticContent>
|
||||
</system.webServer>
|
||||
</configuration>
|
||||
```
|
||||
|
||||
## HAProxy
|
||||
|
||||
如果您希望 HAProxy 服務您的 Gitea 實例，您可以將以下內容添加到您的 HAProxy 配置中
|
||||
|
||||
在前端部分添加一個 acl 以將調用重定向到 gitea.example.com 到正確的後端
|
||||
|
||||
```
|
||||
frontend http-in
|
||||
...
|
||||
acl acl_gitea hdr(host) -i gitea.example.com
|
||||
use_backend gitea if acl_gitea
|
||||
...
|
||||
```
|
||||
|
||||
添加先前定義的後端部分
|
||||
|
||||
```
|
||||
backend gitea
|
||||
server localhost:3000 check
|
||||
```
|
||||
|
||||
如果您將 http 內容重定向到 https，配置方式相同，只需記住 HAProxy 和 Gitea 之間的連接將通過 http 完成，因此您不必在 Gitea 的配置中啟用 https。
|
||||
|
||||
## HAProxy 與子路徑
|
||||
|
||||
如果您已經有一個站點，並且希望 Gitea 共享域名，您可以通過將以下內容添加到您的 HAProxy 配置中來設置 HAProxy 以在子路徑下服務 Gitea：
|
||||
|
||||
```
|
||||
frontend http-in
|
||||
...
|
||||
acl acl_gitea path_beg /gitea
|
||||
use_backend gitea if acl_gitea
|
||||
...
|
||||
```
|
||||
|
||||
使用該配置 http://example.com/gitea/ 將重定向到您的 Gitea 實例。
|
||||
|
||||
然後為後端部分
|
||||
|
||||
```
|
||||
backend gitea
|
||||
http-request replace-path /gitea\/?(.*) \/\1
|
||||
server localhost:3000 check
|
||||
```
|
||||
|
||||
添加的 http-request 將自動添加尾隨斜杠（如果需要），並在內部刪除 /gitea 從路徑中刪除，以便通過正確設置 http://example.com/gitea 作為根來使其與 Gitea 正確工作。
|
||||
|
||||
然後您**必須**在配置中正確設置 `[server] ROOT_URL = http://example.com/gitea/`。
|
||||
|
||||
## Traefik
|
||||
|
||||
如果您希望 traefik 服務您的 Gitea 實例，您可以將以下標籤部分添加到您的 `docker-compose.yaml`（假設提供者是 docker）。
|
||||
|
||||
```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 和 traefik 之間使用 HTTP。
|
||||
|
||||
## Traefik 與子路徑
|
||||
|
||||
如果您已經有一個站點，並且希望 Gitea 共享域名，您可以通過將以下內容添加到您的 `docker-compose.yaml`（假設提供者是 docker）來設置 Traefik 以在子路徑下服務 Gitea：
|
||||
|
||||
```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
|
||||
+30
@@ -0,0 +1,30 @@
|
||||
---
|
||||
date: "2019-12-31T13:55:00+05: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,138 @@
|
||||
---
|
||||
date: "2019-08-17T10:20:00+01:00"
|
||||
slug: "signing"
|
||||
sidebar_position: 50
|
||||
aliases:
|
||||
- /zh-tw/signing
|
||||
---
|
||||
|
||||
# GPG 提交簽名
|
||||
|
||||
Gitea 會通過檢查提交是否由 Gitea 資料庫中的密鑰簽名，或提交是否符合 Git 的預設密鑰來驗證 GPG 提交簽名。
|
||||
|
||||
密鑰不會被檢查是否已過期或被撤銷，也不會與密鑰伺服器進行檢查。
|
||||
|
||||
如果找不到密鑰來驗證提交，提交將被標記為灰色未鎖定圖標。如果提交被標記為紅色未鎖定圖標，則表示該提交是由具有 ID 的密鑰簽名的。
|
||||
|
||||
:::note
|
||||
提交的簽名者不必是提交的作者或提交者。
|
||||
:::
|
||||
|
||||
## 自動簽名
|
||||
|
||||
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` 為每個儲存庫提供不同的簽名密鑰。然而，這顯然不是理想的 UI，因此可能會有所變化。
|
||||
|
||||
:::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` 下的 gpg 密鑰。
|
||||
:::
|
||||
|
||||
### `INITIAL_COMMIT`
|
||||
|
||||
此選項決定 Gitea 在創建儲存庫時是否應該簽署初始提交。可能的值是：
|
||||
|
||||
- `never`: 從不簽署
|
||||
- `pubkey`: 僅在用戶擁有公鑰時簽署
|
||||
- `twofa`: 僅在用戶使用雙因素身份驗證登錄時簽署
|
||||
- `always`: 始終簽署
|
||||
|
||||
除了 `never` 和 `always` 之外的選項可以作為逗號分隔的列表進行組合。提交將在所有選定選項都為真時簽署。
|
||||
|
||||
### `WIKI`
|
||||
|
||||
此選項決定 Gitea 是否應該簽署 Wiki 的提交。可能的值是：
|
||||
|
||||
- `never`: 從不簽署
|
||||
- `pubkey`: 僅在用戶擁有公鑰時簽署
|
||||
- `twofa`: 僅在用戶使用雙因素身份驗證登錄時簽署
|
||||
- `parentsigned`: 僅在父提交已簽署時簽署。
|
||||
- `always`: 始終簽署
|
||||
|
||||
除了 `never` 和 `always` 之外的選項可以作為逗號分隔的列表進行組合。提交將在所有選定選項都為真時簽署。
|
||||
|
||||
### `CRUD_ACTIONS`
|
||||
|
||||
此選項決定 Gitea 是否應該簽署來自網頁編輯器或 API CRUD 操作的提交。可能的值是：
|
||||
|
||||
- `never`: 從不簽署
|
||||
- `pubkey`: 僅在用戶擁有公鑰時簽署
|
||||
- `twofa`: 僅在用戶使用雙因素身份驗證登錄時簽署
|
||||
- `parentsigned`: 僅在父提交已簽署時簽署。
|
||||
- `always`: 始終簽署
|
||||
|
||||
除了 `never` 和 `always` 之外的選項可以作為逗號分隔的列表進行組合。更改將在所有選定選項都為真時簽署。
|
||||
|
||||
### `MERGES`
|
||||
|
||||
此選項決定 Gitea 是否應該簽署來自 PR 的合併提交。可能的選項是：
|
||||
|
||||
- `never`: 從不簽署
|
||||
- `pubkey`: 僅在用戶擁有公鑰時簽署
|
||||
- `twofa`: 僅在用戶使用雙因素身份驗證登錄時簽署
|
||||
- `basesigned`: 僅在基礎儲存庫中的父提交已簽署時簽署。
|
||||
- `headsigned`: 僅在頭分支中的頭提交已簽署時簽署。
|
||||
- `commitssigned`: 僅在頭分支中到合併點的所有提交都已簽署時簽署。
|
||||
- `approved`: 僅簽署已批准的合併到受保護分支。
|
||||
- `always`: 始終簽署
|
||||
|
||||
除了 `never` 和 `always` 之外的選項可以作為逗號分隔的列表進行組合。合併將在所有選定選項都為真時簽署。
|
||||
|
||||
## 獲取簽名密鑰的公鑰
|
||||
|
||||
用於簽署 Gitea 提交的公鑰可以從 API 獲取：
|
||||
|
||||
```sh
|
||||
/api/v1/signing-key.gpg
|
||||
```
|
||||
|
||||
在有儲存庫特定密鑰的情況下，可以從以下位置獲取：
|
||||
|
||||
```sh
|
||||
/api/v1/repos/:username/:reponame/signing-key.gpg
|
||||
```
|
||||
Reference in New Issue
Block a user