pangolin_mirror/docs-v2
1
0
Fork 0
mirror of https://github.com/fosrl/docs-v2.git synced 2026-04-15 22:36:41 +00:00
Code Issues Packages Projects Releases Wiki Activity

update connection log

Browse Source
This commit is contained in:
miloschwartz
2026-04-03 14:35:41 -04:00
parent cf23a8e3da
commit 3344ce67e0
2 changed files with 12 additions and 16 deletions
Download Patch File Download Diff File Expand all files Collapse all files

20
manage/analytics/connection.mdx
View File

@@ -31,18 +31,14 @@ Each connection log entry contains the following fields:
| Field | Type | Description |
|-------|------|-------------|
| `id` | number | Unique identifier for the log row |
| `sessionId` | string | Identifier for the tunnel session |
| `siteResourceId` | number \| null | The private [site resource](/manage/resources/understanding-resources) associated with the session (foreign key to `siteResources`) |
| `orgId` | string \| null | Organization ID |
| `siteId` | number \| null | Site ID |
| `clientId` | number \| null | Pangolin client ID |
| `userId` | string \| null | User ID, when the session is tied to a user |
| `sourceAddr` | string | Source address for the session (for example client-side endpoint) |
| `destAddr` | string | Destination address for the session (for example resource-side endpoint) |
| `protocol` | string | Transport protocol (for example `tcp` or `udp`) |
| `startedAt` | number | Unix timestamp when the session started |
| `endedAt` | number \| null | Unix timestamp when the session ended, if the session has closed |
| `timestamp` | number | Unix timestamp (in seconds) when the session started |
| `protocol` | string | Transport protocol for the session (`tcp` or `udp`) |
| `siteResourceId` | number \| null | The ID of the [private resource](/manage/resources/understanding-resources) for the session (if applicable) |
| `clientId` | number \| null | The Pangolin [client ID](/manage/clients/understanding-clients) for the session |
| `userId` | string \| null | The user ID when the session is tied to an authenticated user |
| `sourceAddr` | string | Source address for the session (typically the client-side endpoint) |
| `destAddr` | string | Destination address for the session (typically the resource-side endpoint) |
| `duration` | number \| null | How long the session lasted (in seconds), when the session has ended |
| `bytesTx` | number \| null | Bytes transmitted in the session |
| `bytesRx` | number \| null | Bytes received in the session |

8
manage/sites/site-provisioning.mdx
View File

@@ -20,17 +20,17 @@ The same friction shows up in other scenarios:
- **Developer and lab environments**: Spin up VMs or containers repeatedly without clicking through the dashboard for each site; tear them down and provision again with bounded keys (usage limits and expiry; see below).
- **MSP and multi-customer rollouts**: Standardize your onboarding bundle (endpoint + provisioning key + blueprint) while still giving each customer site isolated credentials after exchange.
With **provisioning keys**, you create one long-lived token in Pangolin, embed it in your image or distribute it with a single script, and each Newt instance exchanges that token for its own [site ID and secret](/manage/sites/credentials) on first connect.
With provisioning keys, you create one long-lived token in Pangolin, embed it in your image or distribute it with a single script, and each Newt instance exchanges that token for its own [site ID and secret](/manage/sites/credentials) on first connect.
## How provisioning works
Put the provisioning key in a **JSON config file** with a `provisioningKey` field (the value is the key string from Pangolin, often shown with an `spk` prefix). Point Newt at that file with **`--config-file`**, for example:
Put the provisioning key in a JSON config file with a `provisioningKey` field (the value is the key string from Pangolin, often shown with an `spk` prefix). Point Newt at that file with `--config-file`, for example:
```bash
newt --config-file /var/newt.json
```
A minimal file might only set **`endpoint`** and **`provisioningKey`** until the exchange completes; afterward the same file holds **`id`** and **`secret`** instead of the key. Other Newt options are documented on [Configure Sites](/manage/sites/configure-site).
A minimal file might only set `endpoint` and `provisioningKey` until the exchange completes; afterward the same file holds `id` and `secret` instead of the key. Other Newt options are documented on [Configure Sites](/manage/sites/configure-site).
```json
{
@@ -41,7 +41,7 @@ A minimal file might only set **`endpoint`** and **`provisioningKey`** until the
When Newt contacts Pangolin and exchanges the provisioning key for a device-specific ID and secret, it updates the same config file: the provisioning key entry is removed and replaced with the new credentials. After a successful provision, the provisioning key is no longer on the host; only the normal site ID and secret remain for future connections.
From there Newt authenticates over the websocket, optionally **applies declarative YAML** if you configured a blueprint, then brings the tunnel online. The high-level sequence is summarized below.
From there Newt authenticates over the websocket, optionally applies declarative YAML if you configured a blueprint, then brings the tunnel online. The high-level sequence is summarized below.
<Frame>
<img src="/images/site-provisioning-flow.png" alt="Flow: provision with pre-shared key, exchange for ID and secret, apply YAML, pending approval, admin approves" centered />