0 Fork 0

mirror of https://github.com/kevinveenbirkenbach/computer-playbook.git synced 2026-11-12 13:47:01 +00:00

Files

T

kevinveenbirkenbachandClaude Opus 4.7 4bd23d5f1b chore(roles): mark non-invokable roles with nocheck:required-by-coverage (Bundle D)

Adds `# nocheck: required-by-coverage — TODO: declare proper required_by`
markers to meta/services.yml of 74 non-invokable system roles (dev-*, pkgmgr*,
sys-aur*, sys-front-inj-*, sys-front-tls-*, sys-svc-{cdn,certbot,certs,
cln-domains,dns,journalctl,mail*,proxy,rdbms,ssh,sshd}, sys-timer*, sys-stk-*,
user-*, …).

This is the passthrough layer that lets the upcoming `required_by` lint
(Bundle C) hard-fail any *new* non-invokable role without an explicit coverage
declaration, while existing roles get a documented TODO grace period instead
of an immediate CI break.

No runtime effect — comments only.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

2026-05-23 04:23:45 +02:00

defaults

refactor(secrets): centralize infinito secrets paths and remove role-local csv vars

2025-12-28 14:38:25 +01:00

README.md

sys-token-store

Description

sys-token-store is a lightweight Ansible helper role for resolving and persisting per-user application tokens in a unified and idempotent way.

It provides a single source of truth for application tokens while keeping runtime usage simple and consistent across roles.

The role is intentionally not a secret generator.
It only stores and propagates tokens that already exist (e.g. created by bootstrap processes or provided externally).

Overview

This role stores and manages per-user application tokens in a local YAML store file (idempotent read/write helpers).

Features

Automated provisioning: Configured by Ansible without manual steps.

Core Principles

Single logic for all roles
- Always resolve tokens as: users → token store → empty
No implicit token generation
- Empty tokens are rejected
Idempotent persistence
- Store file is only rewritten when content actually changes
Lookup-based runtime resolution
- Tokens are resolved through lookup('users'), which hydrates from the store on each lookup call
Case-sensitive keys
- User keys and application IDs must match exactly

Token Resolution Order

When resolving a token, the following order is used:

lookup('users', '<user>').tokens.<application_id>
Token store file (tokens.yml)
Empty string ('')

No automatic fallback generation happens.

Store Format

Tokens are stored in a single YAML file:

users:
  administrator:
    tokens:
      web-app-matomo: "46e50b0eb52d0d141a7d6cf9b3d0b3e2"

Default location:

/var/lib/infinito/secrets/tokens.yml

Permissions are restricted to root by default.

Provided Tasks

`write.yml`

Persists a token so it is available through the users lookup on subsequent reads.

This is the canonical way to store tokens.

Input

sys_token_store_user_key
sys_token_store_app
sys_token_store_token (must be non-empty)

Effects

Updates the token store file (idempotent)
Makes the token available via lookup('users', '<user>').tokens['<app>']
Exports sys_token_store_token

Empty tokens are rejected explicitly.

Usage Examples

Persist a token

- include_role:
    name: sys-token-store
    tasks_from: write.yml
  vars:
    sys_token_store_user_key: administrator
    sys_token_store_app: web-app-matomo
    sys_token_store_token: "{{ matomo_token_value }}"

After this, the token is available as:

lookup('users', 'administrator').tokens['web-app-matomo']

What This Role Does Not Do

❌ No token generation
❌ No encryption
❌ No user management
❌ No application-specific logic

It is a generic infrastructure helper.

Best Practices

Keep all user and application keys lowercase
Use stable application_id values
Let application roles create tokens
Let sys-token-store handle persistence

Credits

Developed and maintained by Kevin Veen-Birkenbach. Learn more at veen.world. Part of the Infinito.Nexus Project. Licensed under the Infinito.Nexus Community License (Non-Commercial).