Profile Management System
The profile system allows users to manage multiple daemon connections, environment-specific configurations, and security postures. Profiles are stored in a central registry located atcli/profiles.toml within the state root crates/palyra-cli/src/app/mod.rs#26-27.
Profile Data Model
Each profile is represented by theCliConnectionProfile struct, which encapsulates connection metadata, local path overrides, and security metadata crates/palyra-cli/src/app/mod.rs#93-113.
| Field | Description |
|---|---|
mode | Execution context: local, remote, or custom crates/palyra-cli/src/args/profile.rs#24-28. |
risk_level | Sensitivity tier: low, elevated, high, or critical crates/palyra-cli/src/args/profile.rs#32-37. |
strict_mode | When enabled, requires explicit flags for destructive or sensitive actions crates/palyra-cli/src/app/mod.rs#108. |
state_root | Isolated directory for logs, caches, and identity for this specific profile crates/palyra-cli/src/app/mod.rs#95. |
config_path | Path to the palyra.toml daemon configuration associated with this profile crates/palyra-cli/src/app/mod.rs#94. |
Profile Lifecycle and Portability
The CLI supports advanced cloning and migration workflows to facilitate environment promotion (e.g., moving a tested configuration fromstaging to prod).
- Cloning:
palyra profile clonecreates a deep copy of a profile, including its associated configuration files and state root structure crates/palyra-cli/src/commands/profile.rs#186-197. - Export/Import: Profiles can be exported as
ProfilePortabilityBundleobjects crates/palyra-cli/src/commands/profile.rs#141-149.- Redacted Mode: Secrets are replaced with
<redacted>tokens crates/palyra-cli/src/commands/profile.rs#30. - Encrypted Mode: The bundle is protected using
aes_256_gcmwith keys derived viapbkdf2_hmac_sha256(120,000 iterations) crates/palyra-cli/src/commands/profile.rs#25-27.
- Redacted Mode: Secrets are replaced with
Profile Resolution Logic
The CLI resolves the active profile through a tiered priority system:- Global flag:
--profile <name> - Environment variable:
PALYRA_CLI_PROFILEcrates/palyra-cli/src/app/mod.rs#24 - Registry default:
default_profilefield inprofiles.tomlcrates/palyra-cli/src/app/mod.rs#86
Doctor Diagnostics Engine
Thedoctor command is the primary diagnostic tool for the Palyra ecosystem. It executes a suite of DoctorCheck routines categorized by system domain to identify misconfigurations, connectivity issues, and security vulnerabilities.
Diagnostic Categories
Diagnostics are implemented incrates/palyra-cli/src/commands/doctor/recovery.rs. Key check areas include:
- Toolchain & Environment: Verifies presence of
bwrap(Linux sandboxing),openssl, and validPATHentries. - Connectivity Snapshots: Performs mTLS handshake checks against the Gateway and validates the
admin_tokencrates/palyra-cli/src/commands/doctor/recovery.rs#206-208. - Access Registry: Validates the integrity of
access_registry.jsonand checks for schema version mismatches crates/palyra-cli/src/commands/doctor/recovery.rs#30. - Persistence Integrity: Scans for corrupted SQLite journals or malformed TOML/JSON configuration files.
Implementation: Doctor Execution Flow
Therun_doctor function orchestrates the diagnostic process, optionally moving into a repair phase if the --repair flag is provided.
Doctor Diagnostic Data Flow
This diagram illustrates how system state is ingested by the Doctor engine to produce an execution report. Sources: crates/palyra-cli/src/commands/doctor.rs, crates/palyra-cli/src/commands/doctor/recovery.rsRepair and Rollback Recovery
When the Doctor identifies “Fixable” issues, it generates aDoctorRepairPlan. Repairs are treated as atomic transactions where possible, creating backups before modification.
Repair Flow
- Plan Generation: The engine identifies steps like
InitializeMissingConfig,NormalizeAuthRegistry, orBackfillAccessRegistrycrates/palyra-cli/src/commands/doctor/recovery.rs#178-236. - Backup Creation: Files targeted for modification are backed up to a unique recovery run directory:
recovery/runs/<ULID>/crates/palyra-cli/src/commands/doctor/recovery.rs#23. - Manifest Recording: A
DoctorRecoveryManifestis written, tracking thebefore_sha256andafter_sha256of every changed object crates/palyra-cli/src/commands/doctor/recovery.rs#141-155.
Rollback Mechanism
Users can revert any repair operation using therun_id (ULID) generated during the repair.
- Command:
palyra doctor --rollback-run <ULID>crates/palyra-cli/src/commands/doctor/recovery.rs#56. - Process: The engine reads the manifest, verifies the current file hashes match the
after_sha256records, and restores the files from thebackup_pathcrates/palyra-cli/src/commands/doctor/recovery.rs#163-167.
Entity Mapping: Recovery System
This diagram bridges the recovery concepts to the internal structures used to track changes. Sources: crates/palyra-cli/src/commands/doctor/recovery.rs, crates/palyra-cli/src/commands/doctor.rsSecurity Auditing
Thepalyra security audit command leverages the Doctor engine to perform a security-specific evaluation crates/palyra-cli/src/commands/security.rs#70-72. It combines Doctor checks with a SecretAuditPayload to identify:
- Admin Auth Exposure: Checks if
admin.require_authis disabled crates/palyra-cli/src/commands/security.rs#152-160. - Insecure Binds: Detects remote network binds without accompanying TLS configuration crates/palyra-cli/src/commands/security.rs#169-177.
- Secret Leakage: Scans for inline API keys in config files that should be moved to the Vault crates/palyra-cli/src/commands/security.rs#62-63.