-
Notifications
You must be signed in to change notification settings - Fork 0
Expand file tree
/
Copy path.env.example
More file actions
120 lines (107 loc) · 6.29 KB
/
Copy path.env.example
File metadata and controls
120 lines (107 loc) · 6.29 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
# =============================================================================
# UTMStack MCP Server — example environment configuration
# =============================================================================
# MOST USERS DO NOT NEED THIS FILE. Run `utmstack-mcp init` instead: it
# validates your credentials against the live API and writes them to a 0600
# config file (~/.config/utmstack-mcp/config.json, or %APPDATA%\utmstack-mcp
# on Windows). This .env path exists for development and for environments
# where configuration is injected as environment variables.
#
# cp .env.example .env
#
# The server loads ".env" from the CURRENT WORKING DIRECTORY only. It no longer
# reads a .env from a parent directory: that silently pulled credentials in
# from outside the application directory, and under PyInstaller it resolved
# into the extraction temp dir, making the behaviour unpredictable for the
# shipped binary. Real .env files are gitignored — never commit secrets.
#
# Configuration is resolved in this order, first match wins:
# 1. UTMSTACK_SERVERS in the environment
# 2. UTMSTACK_SERVERS_FILE pointing at a JSON file
# 3. ~/.config/utmstack-mcp/config.json (what `utmstack-mcp init` writes)
# 4. .env in the current working directory
#
# There are TWO ways to configure servers:
# A) MULTI-SERVER (preferred) — one UTMSTACK_SERVERS JSON array; manage many
# deployments at once and pick one per call with the tools' `server=` arg
# (or switch the default with use_server / list them with list_servers).
# B) SINGLE-SERVER (legacy) — the individual UTMStackXxx variables below.
# Used as a fallback "default" server only when UTMSTACK_SERVERS is unset.
#
# Each legacy variable also has an UPPER_SNAKE alias; either name works.
# Values shown here are placeholders/examples, not real credentials.
# =============================================================================
# -----------------------------------------------------------------------------
# A) MULTI-SERVER (preferred)
# -----------------------------------------------------------------------------
# A JSON array of server objects. Per-entry keys (aliases in parentheses):
# name identifier used by `server=`/use_server (required)
# url (baseUrl, cnn) base URL, e.g. https://host (required)
# user (username) + pass console-login credentials (recommended auth: same
# (password) login the web UI uses; works on all deployments and
# is required for run_agent_command)
# apiKey (key) API key, sent as the "Utm-Api-Key" header
# jwt (token) a ready JHipster id_token (static; can't be refreshed)
# verifySSL true/false (default TRUE). Instances often self-sign;
# prefer caBundle over turning this off.
# caBundle (ca_bundle) path to a CA cert that signs the server's certificate —
# the supported way to trust a self-signed deployment
# allowAgentCommands true/false (default FALSE). Enables run_agent_command,
# which is a root/SYSTEM shell on the endpoint.
# default true marks the default server (else the first entry)
#
# Auth precedence per server: user+pass > jwt > apiKey.
# Because JSON spans lines, keep it single-quoted. Example (two servers):
#
# UTMSTACK_SERVERS='[
# {"name":"prod","url":"https://prod.example.com","user":"admin","pass":"s3cret","default":true},
# {"name":"dev","url":"https://10.0.0.2","apiKey":"replace-with-api-key","caBundle":"/etc/ssl/certs/lab-ca.pem"}
# ]'
#
# Alternatively, keep the JSON in a file and point to it (keeps secrets out of
# the process environment); UTMSTACK_SERVERS takes precedence if both are set:
# UTMSTACK_SERVERS_FILE=/absolute/path/to/utmstack-servers.json
# -----------------------------------------------------------------------------
# B) SINGLE-SERVER (legacy fallback — used only when UTMSTACK_SERVERS is unset)
# -----------------------------------------------------------------------------
# Base URL of your UTMStack server (with scheme; trailing slash is fine).
# Alias: UTMSTACK_URL
UTMSTackCnn=https://your-utmstack.example.com/
# Optional display name for this single server (default: "default").
# Alias: UTMSTACK_NAME
# UTMSTackName=prod
# API key. Create one in UTMStack: Settings -> API keys.
# Sent on every REST request as the "Utm-Api-Key" header.
# Alias: UTMSTACK_API_KEY
UTMStackKey=replace-with-your-api-key
# Verify the server's TLS certificate. Accepts: true / 1 / yes (else false).
# Defaults to TRUE. Setting this to false disables verification on the same
# connection that carries your password to /api/authenticate, so anyone on the
# network path can read it — the server warns loudly when you do. To trust a
# self-signed certificate properly, point UTMStackCABundle at its CA instead.
# Alias: (none — read only as UTMStackVerifySSL)
UTMStackVerifySSL=true
# Path to a CA bundle (.pem) that signs your server's certificate. Preferred
# over disabling verification. Alias: UTMSTACK_CA_BUNDLE
# UTMStackCABundle=/etc/ssl/certs/utmstack-ca.pem
# Enable run_agent_command (remote shell on endpoints). Defaults to false.
# UTMSTACK_ALLOW_AGENT_COMMANDS=false
# --- Agent command execution (the `run_agent_command` tool only) -------------
# Running commands on an agent uses UTMStack's interactive console, which talks
# STOMP-over-SockJS on /ws and authenticates with a JWT (a JHipster id_token).
# The Utm-Api-Key above does NOT work for that channel. All other tools work
# without these. Provide credentials ONE of two ways (user/pass takes precedence):
#
# Option A (recommended): username + password. The server logs in via
# POST /api/authenticate, caches the token, and can re-mint it if the
# server invalidates it mid-session.
# Option B: a ready-made JWT. Convenient, but cannot be refreshed once it
# expires, so command execution fails until you replace it.
# --- Option A: console login credentials ---
# Aliases: UTMSTACK_USER / UTMSTACK_PASS
UTMStackUser=your-console-username
UTMStackPass=your-console-password
# --- Option B: pre-obtained JWT id_token ---
# Get one from: POST /api/authenticate (response field "token" or "id_token").
# Alias: UTMSTACK_JWT
# UTMStackJWT=eyJhbGciOiJI...your-id-token...