xah30
dbee9d8b93
Two bugs visible after user's first Install-admin-access click:
1) `visudo -c` rejected the fragment because sudoers tags must be UPPERCASE.
We wrote `setenv:` (lowercase) which sudoers does not recognise as a tag
and treats as a command path, producing a syntax error at column 29 of
/etc/sudoers.d/aura-gui:2 — and worse, the broken file stayed on disk
so every subsequent `sudo` complained about the syntax error too (sudo
still functions but the warning is noise).
Fix: drop the `setenv:` tag entirely. We never needed it — the GUI only
passes RUST_LOG to the child via env(), which `sudo -E` would forward
but we deliberately chose not to (smaller surface). Removing the tag
also removes the failure mode.
2) Product rename per user feedback ("переименуй пакет на просто Aura"):
- tauri.conf.json `productName` and window title: `aura-gui` -> `Aura`
- bundle now produces /Applications/Aura.app and Aura_0.1.0_aarch64.dmg
- identifier `ru.undergr0und.aura` was already correct, no change
- sudoers file is now /etc/sudoers.d/aura (was aura-gui), so the success
message and revert hint are updated accordingly
The internal MacOS/ binary is still named `aura-gui` (Tauri uses the Cargo
crate name there) — not user-visible, only the dev internals see it.
Manual cleanup also performed on the dev host:
- /Applications/aura-gui.app removed
- /etc/sudoers.d/aura-gui (the broken fragment from the first failed
install attempt) removed via `osascript ... with administrator
privileges` so sudo is no longer logging syntax errors
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
aura-gui — desktop client for AuraVPN
A Tauri 2 + React TypeScript app that runs in the system tray. It's the GUI front-end for the
existing aura CLI: import a provisioned bundle (.tgz), pick a profile, hit Connect, watch
the live tunnel status. No clash-verge replacement and no protocol patching — just a thin
manager around the existing CLI.
Status
v0.1 (MVP) — scaffolding + core flows. Working:
- ✅ Profile list / import / delete (drop in a
provision-client.tgzand you're set) - ✅ Connect / Disconnect (spawns / kills
aura clientper profile) - ✅ Live status panel (peer, tx/rx packets, default action, rules) via admin socket
- ✅ System tray with Open / Disconnect / Quit menu
- ✅ Close button hides to tray (app stays alive in background)
Deferred for v0.2:
- Auto-start at login (launchd plist / systemd user unit / Windows Run key)
- Code signing + notarization (macOS) / Authenticode (Windows)
- Per-profile route overrides editor
- Live log streaming (currently polled, frontend tails the in-memory ring)
- Admin status query on Windows (uses Unix sockets today; need named pipe support)
Layout
aura-gui/
├── src-tauri/ (Rust 2 backend, separate Cargo manifest)
│ ├── src/
│ │ ├── lib.rs (Tauri commands + tray + window plumbing)
│ │ ├── profiles.rs ([app_data]/profiles/ I/O + .tgz import)
│ │ ├── cli_proc.rs (spawns aura client + stderr ring buffer)
│ │ └── admin.rs (JSON-line admin socket client)
│ ├── Cargo.toml
│ └── tauri.conf.json
├── src/ (React TS frontend)
│ ├── App.tsx
│ └── App.css
├── package.json
└── README.md (this file)
The src-tauri/ crate is intentionally excluded from the workspace at the repo root
(workspace.exclude = ["aura-gui"]) so cargo check --workspace from the project root keeps
checking just the protocol crates and doesn't pull tauri/wry/webview into every CI run.
Build
# Backend deps come down with cargo at build time
cd aura-gui
npm install # ~10 s, downloads vite + React 19
npm run build # frontend tsc + vite build → dist/
npm run tauri build # full bundle: .dmg / .deb / .msi / .AppImage
For dev:
npm run tauri dev
The first build downloads ~200 MB of native deps (tauri, wry, webview) — subsequent builds are fast (incremental).
Profile storage
Per-platform app-data dir:
| OS | Path |
|---|---|
| macOS | ~/Library/Application Support/ru.undergr0und.aura/profiles/ |
| Linux | ~/.config/AuraVPN/profiles/ |
| Windows | %APPDATA%\AuraVPN\profiles\ |
Each profile is a directory with the same shape as aura provision-client emits:
profiles/<id>/
├── client.toml
├── ca.crt
├── client.crt
├── client.key
└── bridges.signed (optional, v3.3+)
The id is the basename of the imported .tgz (e.g. client-1.tgz → profiles/client-1/).
Aura binary path
The GUI shells out to aura client for each connection. It defaults to:
/Users/xah30/AuraVPN/target/release/auraif present (dev convenience),/usr/local/bin/auraon Unix,C:\Program Files\AuraVPN\aura.exeon Windows.
Change it at runtime via the "Change…" button at the bottom of the window. The setting is session-only for now (persisting it to a config file is a v0.2 todo).
Sudo / admin privileges
aura client creates a TUN device, which needs root on Unix and Administrator on Windows.
Currently the GUI does not run with elevated privileges — the operator must launch it from
a privileged shell, or via sudo open -a aura-gui on macOS, etc.
v0.2 will add a polkit / authorization-services prompt for the privileged step.
Why not just patch clash-verge?
We thought about it. AuraVPN is an L3 IP-tunnel (like WireGuard); clash-verge / mihomo / sing-box outbounds are L4 per-flow proxies (like Trojan / VLESS / Hysteria). Bridging the two requires either a user-space TCP/IP stack inside the outbound (gVisor) or extensive mihomo patching. Neither was a small lift, and a self-contained tray app turned out to be the shortest path to "vpn that always-on in a clash-verge-ish UX".
A v0.3 stretch goal is to ship a local SOCKS5 listener alongside the TUN, so clash-verge users who already use SOCKS5 outbounds can point at AuraVPN as a SOCKS5 proxy. That requires the gVisor netstack — separate piece of work.