更新以匹配 Dashboard v0.18.0 的新功能和特性变化
This commit is contained in:
Kris
@@ -77,11 +77,11 @@ The entered DDNS `AccessID` or `AccessSecret` is incorrect.
|
||||
This error indicates that no TCP-Ping or ICMP-Ping type monitoring has been set in the services page or monitoring data has not yet been generated.
|
||||
If it has been set up, wait for some time and then check again.
|
||||
|
||||
### What to do if /terminal or /ws can't connect properly after enabling HTTPS?
|
||||
## What to do if /terminal or /ws can't connect properly after enabling HTTPS?
|
||||
|
||||
This is often due to an incomplete certificate. Add the -d parameter to the agent run command. If the log contains `x509:certificate signed by unknown authority`, replacing with a complete certificate will solve the problem.
|
||||
|
||||
### What if I'm not satisfied with the data modification/addition functionality provided by the dashboard and want to modify/add data myself?
|
||||
## What if I'm not satisfied with the data modification/addition functionality provided by the dashboard and want to modify/add data myself?
|
||||
|
||||
Common in scenarios like batch adding Agents, you can directly modify the database.
|
||||
Note that not everything in the database can be modified; incorrect modifications can lead to data corruption and inability to start the Dashboard. **Do not modify the database casually!**
|
||||
@@ -91,6 +91,11 @@ Again, **do not modify the database casually!**
|
||||
If you need to modify data in the database, **stop** the dashboard container first.
|
||||
The database type is sqlite3, located at `/opt/nezha/dashboard/data/sqlite.db`. Backup before modifying.
|
||||
|
||||
### Will the Dashboard automatically update?
|
||||
## Will the Dashboard automatically update?
|
||||
|
||||
Agents typically update automatically, but the Dashboard does not and requires manual updates.
|
||||
Agents typically update automatically, but the Dashboard does not and requires manual updates.
|
||||
|
||||
## `Agent Command Issuance Failed` When Connecting to Web Terminal
|
||||
|
||||
When the Agent is offline, or the connection between the Agent and the Dashboard is unstable, it may cause issues with connecting to the Web Terminal.
|
||||
Please check if the Agent is running normally and maintaining a stable connection with the Dashboard.
|
||||
@@ -0,0 +1,34 @@
|
||||
---
|
||||
outline: deep
|
||||
---
|
||||
# NAT Traversal Configuration
|
||||
|
||||
Nezha Server Monitoring includes built-in NAT traversal capabilities, allowing users to expose internal services running on an Agent (such as home OpenWrt routers or NAS devices) to the public internet. This functionality facilitates remote access and is currently limited to supporting HTTP protocol traversal.
|
||||
|
||||
## Preparation
|
||||
|
||||
Prior to configuring NAT traversal, please ensure the following preparatory steps are completed:
|
||||
|
||||
- Verify that the Nezha Monitoring Agent is installed and actively running on your device and maintains a stable connection with the Dashboard.
|
||||
- Acquire a public domain name, ideally using a subdomain configuration, such as `service-1.example.com`. Point this domain name to the public IP address of your Dashboard server.
|
||||
- It is important to note that each domain name can only map to the service of one Agent. For mapping services from multiple Agents, distinct domain names should be used, such as `service-2.example.com`.
|
||||
|
||||
::: warning
|
||||
If your Dashboard server uses tools like the aaPanel or similar management platforms, ensure that your domain (e.g., `service-1.example.com`) is correctly linked to the Dashboard site within these tools to avoid access issues.
|
||||
:::
|
||||
|
||||
## NAT Traversal Configuration Steps
|
||||
|
||||
1. Log into the Dashboard Admin Panel and navigate to the "NAT Traversal" section in the menu.
|
||||
2. Click the "Add" button and provide the following required details:
|
||||
- **Name**: Assign a custom name to this traversal setup, for example, `OpenWrt Login Page`.
|
||||
- **Agent ID**: Input the ID of the Agent for which traversal is needed.
|
||||
- **Internal Service Address**: Specify the internal service address that requires traversal, in the `IP:port` format, such as `127.0.0.1:80`.
|
||||
- **Domain Name**: Enter the previously configured public domain name, like `service-1.example.com`.
|
||||
3. After filling in the details, click the "Add" button and wait for the traversal setup to activate.
|
||||
4. Test the configuration by accessing `http://service-1.example.com` to ensure the internal service on the Agent is successfully accessible.
|
||||
|
||||
## Usage Notes
|
||||
|
||||
- Continuous connectivity between the Agent and the Dashboard is crucial for the NAT traversal functionality to operate correctly. If the connection to the Agent is lost, the traversal setup will temporarily cease to function.
|
||||
- Given that the NAT traversal does not encrypt traffic by itself, it is recommended to secure data transmissions by employing HTTPS protocol between the Agent and the Dashboard, as well as between the Dashboard and the client browser, to ensure data security during transmission.
|
||||
Regular → Executable
+19
-14
@@ -1,23 +1,28 @@
|
||||
---
|
||||
outline: deep
|
||||
---
|
||||
# OIDC Configuration
|
||||
Edit `config.ymal` to enable **OIDC**
|
||||
# Configuring OIDC Authentication
|
||||
|
||||
Modify the contents of `config.yaml` to configure OIDC (OpenID Connect) authentication. OIDC is an authentication layer on top of the OAuth 2.0 protocol, which allows applications to verify the identity of users based on the authentication performed by an Authorization Server. This method is widely used to implement single sign-on for modern applications.
|
||||
|
||||
## Configuration Details
|
||||
|
||||
Here is a step-by-step guide to configuring the OIDC settings in your `config.yaml`:
|
||||
|
||||
```yaml
|
||||
oauth2:
|
||||
type: oidc # (Required) Specifies the authentication type as OIDC
|
||||
oidcDisplayName: OIDC # (Optional, default is OIDC) The name displayed on the login page button
|
||||
admin: "" # (At least one of admin or adminGroups must be provided; default is empty) List of admin usernames, separated by commas. If a user is one of these, they will be considered an admin
|
||||
adminGroups: "" # (At least one of admin or adminGroups must be provided; default is empty) List of admin groups, separated by commas. If a user belongs to one of these groups, they will be considered an admin. Can be left blank if not using group management
|
||||
oidcDisplayName: OIDC # (Optional, default: OIDC) The name displayed on the login page
|
||||
admin: "" # (Fill at least one of admin or adminGroups; default: empty) Admin usernames, separated by commas. Users listed here are considered administrators
|
||||
adminGroups: "" # (Fill at least one of admin or adminGroups; default: empty) Admin groups, separated by commas. Users in these groups are considered administrators. Omit if group management is not used
|
||||
clientid: # (Required) OIDC client ID
|
||||
clientsecret: # (Required) OIDC client secret
|
||||
oidcIssuer: https://auth.example.com/realms/master # (Required) The issuer URL of the OIDC provider, can be found from the OIDC provider
|
||||
# oidcLogoutUrl: https://auth.example.com/realms/master/protocol/openid-connect/logout # (Has a bug, currently not working)
|
||||
# oidcRegisterUrl: # (Optional) Registration URL of the OIDC provider
|
||||
oidcScopes: openid,profile,email # (Optional, default is openid,profile,email) Scopes requested from OIDC, separated by commas
|
||||
oidcLoginClaim: sub # (Optional, default is sub) The username field returned from OIDC, can be preferred_username, sub, or email
|
||||
oidcGroupsClaim: groups # (Required if using adminGroups; default is groups) The field returned from OIDC containing user group information, can be groups or roles
|
||||
oidcAutoCreate: false # (Optional, default is false) Whether to automatically create a user if they do not exist
|
||||
oidcAutoLogin: false # (Optional, default is false) Automatically redirect to the OIDC login page when the URL is /login
|
||||
|
||||
oidcIssuer: https://auth.example.com/realms/master # (Required) The issuer URL of the OIDC provider, obtainable from your OIDC provider
|
||||
# oidcLogoutUrl: https://auth.example.com/realms/master/protocol/openid-connect/logout # (Currently unusable due to a bug)
|
||||
# oidcRegisterUrl: # (Optional) Registration link provided by the OIDC provider
|
||||
oidcScopes: openid,profile,email # (Optional, default: openid,profile,email) OIDC scopes requested, separated by commas
|
||||
oidcLoginClaim: sub # (Optional, default: sub) The username field returned by OIDC, can be preferred_username, sub, or email
|
||||
oidcGroupsClaim: groups # (Required if using adminGroups, default: groups) The user group information field returned by OIDC, can be groups or roles
|
||||
oidcAutoCreate: false # (Optional, default: false) Whether to automatically create a user if they do not exist
|
||||
oidcAutoLogin: false # (Optional, default: false) Whether to automatically redirect to the OIDC login page when the path is /login
|
||||
```
|
||||
@@ -1,4 +1,4 @@
|
||||
# Real-Time Channel Disconnection/Online & Terminal Connection Failure
|
||||
# Real-Time Channel Disconnection
|
||||
|
||||
- If you are using a CDN, ensure that the CDN provider offers WebSocket services and that WebSocket is enabled.
|
||||
- Confirm that your reverse proxy rules have special configurations for the `/ws` and `/terminal` paths. You can [click here](/en_US/guide/dashboard.html#configure-reverse-proxy) to view the reverse proxy configuration.
|
||||
Reference in New Issue
Block a user