txlyre
synced commits to feat/postgres-install at txlyre/3x-ui from mirror
c9670e36d6 fix(install): address Copilot review on Postgres install flow
- Use mktemp (unguessable, 0600) instead of /tmp/x-ui-pg-creds.$$ and
cleanup in both success and failure paths to close the symlink/race
attack on the predictable filename.
- In install_postgres_local, capture the prior umask and restore it
after writing PG_CRED_FILE; return 1 if the write fails so the
caller does not source nothing and label the install with empty
PG_* vars.
- On reinstall, reuse the existing xui DB owner instead of generating
a fresh role each run, so existing tables stay accessible after a
re-run; only the password is rotated. Falls back to a fresh random
role when the DB does not exist or is owned by postgres.
52cecd303f feat(install): random PostgreSQL role + post-install credentials display
The local-Postgres installer used to bake in a static role name (`xui`)
and only printed `PostgreSQL ([email protected]:5432/xui)` at the end of
install, leaving operators without the random password or any hint of
how to connect from the shell.
Two changes:
- install_postgres_local now generates an 8-char random role name
alongside the random password, and double-quotes identifiers in the
CREATE/ALTER statements (a random alphanumeric may start with a digit,
which Postgres rejects for unquoted identifiers).
- After a successful local install, a dedicated "PostgreSQL Credentials"
block is rendered in the summary — DB / user / pass / host / port /
DSN / env-file path, plus ready-to-paste psql commands for both the
postgres superuser and the new role. Credentials cross the subshell
boundary via a 0600 tmpfile (PG_CRED_FILE) that the parent shell
sources and unlinks; the PG_* vars are unset after display.
Only fires for the local-install flow; the external-DSN path is
unchanged.
272854df91 Client/inbound resilience + Postgres pool tuning + schema fixes (#4607)
* fix(clients): fall back to inbound scan when ClientRecord is missing
DeleteByEmail looked up the email in client_records and returned the
raw "record not found" gorm error when nothing matched, even though
the client could still live inside an inbound's settings.clients JSON
(legacy entries that SyncInbound never picked up, or rows deleted out
from under a stale inbound). The user-visible delete then fails
mysteriously while xray happily keeps serving the client.
When GetRecordByEmail returns ErrRecordNotFound, walk inbounds whose
settings JSON references the email and run DelInboundClientByEmail on
each. The traffic / IP rows are cleaned up at the end unless keepTraffic
is set. If no inbound carries the email either, surface a clear
"client %q not found in any inbound or client record" error instead.
* chore(logging): include request + caller context in jsonMsgObj warnings
The generic "X-UI: Something went wrong. Error: record not found" log
gave no clue about which endpoint, client, or controller line emitted
it. Prepend a context block:
[POST /panel/api/clients/del/ADMIN ip=109.124.234.127
handler=controller.(*ClientController).delete client.go:146]
Handler frame is located by scanning the stack for the first caller
outside util.go, so it points at the right controller method whether
the path went through jsonMsg, jsonObj, or jsonMsgObj directly.
* fix(clients): tolerate orphan client_inbounds rows in Delete
DeleteByEmail's previous fix only covered the case where GetRecordByEmail
returned ErrRecordNotFound. When the ClientRecord exists but a client_inbounds
row points to an inbound that has been removed out-of-band (failed mid-delete,
manual SQL, pre-SyncInbound migration), Delete bubbled the raw gorm
"record not found" from inboundSvc.GetInbound and aborted before any cleanup
ran — leaving the client un-deletable through the UI/API.
Match the tolerance bulkDelInboundClients already has: when GetInbound
returns gorm.ErrRecordNotFound for a join row, log a warning and continue.
The unconditional Delete(&model.ClientInbound{}) later in the function then
removes the stale row, and the ClientRecord delete succeeds.
* fix(schemas): accept empty-string fingerprint on externalProxy
The External Proxy form offers a "Default" option with value '' for the
uTLS fingerprint dropdown, but UtlsFingerprintSchema.optional() rejects
empty strings (only undefined or a valid enum member). Saving an inbound
with externalProxy rows failed with `expected one of "360"|"chrome"|...`.
Preprocess '' to undefined before the optional enum, matching the existing
pattern used for VmessSecuritySchema.
* chore(logging): drop noisy orphan client_inbounds warning
Per-row WARNINGs spammed logs whenever a client referenced multiple
already-deleted inbounds. The continue keeps the orphan-tolerant
behavior; just no longer announces each skipped row.
* feat(clients): per-client VMess security in client form
Restores the VMess `security` selector on the client form (auto, aes-128-gcm,
chacha20-poly1305, none, zero) and surfaces it only when at least one attached
inbound is VMess. The value rides into the share link via the existing
`scy=` field in genVmessLink; the panel persists it on ClientRecord and in
the inbound's settings.clients so the link generator can read it back.
Adds the pages.clients.vmessSecurity i18n key in en-US and fa-IR.
* fix(xray-config): strip panel-only fields from inbound config
Two fields the panel stores but Xray doesn't accept on the inbound side:
- VMess clients[].security — panel persists it so the share-link generator
can write `scy=...`, but xray's vmess inbound spec has no per-client
security. The field was leaking into the inbound JSON pushed to xray-core.
- VLESS settings.encryption — per the xray spec the inbound only takes
`decryption`; `encryption` is for the matching client outbound. The panel
keeps it for operator reference, but it must not appear in the inbound
payload.
Add two strip helpers next to HealShadowsocksClientMethods and wire them
into GenXrayInboundConfig via a per-protocol switch, so both local and
remote runtime paths get the cleaned config.
* chore(db): backend-aware pool sizes with env overrides
Per-backend defaults:
- Postgres: 25 max open / 25 max idle. Matching idle to open removes
pool churn under bursts (Postgres handles concurrency at the server,
idle connections are cheap).
- SQLite: 1 max open / 1 max idle. Single-writer model means a wider
cap just queues behind busy_timeout; tight cap is honest.
Both back ends share ConnMaxLifetime=1h and ConnMaxIdleTime=30m so
stale connections (vault rotation, pgbouncer drops, load-balancer
idle eviction) rotate out without operator intervention.
Operators can override either default at boot via:
XUI_DB_MAX_OPEN_CONNS=...
XUI_DB_MAX_IDLE_CONNS=...
envInt parses these; missing/empty/non-positive values fall back to
the per-backend default.
* fix(schemas): accept boolean acceptProxyProtocol on TCP stream
TcpStreamSettingsSchema declared `acceptProxyProtocol: z.literal(true).optional()`,
so saving an inbound where the AntD Switch sat in the off state failed
validation with `Invalid input` because the Switch always emits a plain
boolean.
Switch to `z.boolean().default(false)` — same shape ws/sockopt/httpupgrade
already use, and matches the actual wire payload (golden fixtures and
other settings blocks all store `acceptProxyProtocol: false`).
Snapshots for stream.test and inbound-full.test pick up the new defaulted
field on TCP fixtures.
3046d96145 refactor(inbound-tag): add short protocol segment, rename tcpudp suffix
Tag shape becomes "[n<id>-]inbound-[<listen>:]<port>-<proto>-<net>"
where <proto> is a 2-char alias (vmess→vm, vless→vl, trojan→tr,
shadowsocks→ss, mixed→mx, wireguard→wg, hysteria→hy, tunnel→tn;
http stays as "http"), and <net> uses "tcpudp" for the TCP+UDP combo
instead of the previous "mixed" (which clashed visually with the
mixed protocol name).
Examples:
local VLESS TCP 443 → inbound-443-vl-tcp
local Hysteria UDP 443 → inbound-443-hy-udp
local Mixed protocol dual → inbound-22912-mx-tcpudp
local Tunnel allow=tcp,udp → inbound-51542-tn-tcpudp
node 1 VLESS TCP 443 → n1-inbound-443-vl-tcp
protocolShortName returns the raw protocol identifier for anything not
in the table, so future protocols still get a tag without a code edit.
Existing inbound tags are left alone — only newly generated tags adopt
the shape.
7ade9d9a1f refactor(inbound-tag): node-prefixed + transport-suffixed canonical shape
Tag scheme moves to "[n<nodeID>-]inbound-[<listen>:]<port>-<transport>"
so two long-standing collision classes go away on the create path:
- tcp/443 and udp/443 on the same listener (independent sockets)
- same listen+port living on the central panel and on a remote node
Examples:
local TCP 443 → inbound-443-tcp
local UDP 443 → inbound-443-udp
node 1 TCP 443 → n1-inbound-443-tcp
Refactor:
- composeInboundTag is the single source of truth, called from
generateInboundTag. Transport segment is now always present
(used to appear only on collision); n<id>- prefix is added when
Inbound.NodeID != nil.
- addInbound / importInbound drop their inline "inbound-<port>"
fallback; an empty Tag now flows through resolveInboundTag, which
keeps caller-supplied tags verbatim when free and otherwise
delegates to generateInboundTag.
- setRemoteTrafficLocked indexes tagToCentral under both the stored
tag and the prefix-stripped form, so a node sending its bare tag
still resolves to a row we may have rewritten at materialization.
The create branch now picks between snap.Tag and the n<id>-
prefixed form before falling back to the warn-once skip.
- Tests updated for the always-on transport suffix, and two new
cases cover the node-prefix behaviour.
Existing inbounds keep their tags — only newly generated tags adopt
the new shape, so user routing rules pointing at "inbound-443" still
match the row they always did until the row is recreated.
- View comparison for these 10 commits »
17 hours ago