grenade/architecture
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs(generic): reflect actual firewalld zone usage (default zone only)

Browse Source 
The infrastructure uses only the default zone created at OS install
(FedoraServer on servers, FedoraWorkstation on workstations). Remove the
aspirational internal/wg zone guidance and have deploy.sh resolve the
default zone via firewall-cmd --get-default-zone on the target.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
rob thijssen
2026-04-22 12:07:29 +03:00
parent ecfefa6433
commit 9db5743531
1 changed files with 8 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files

13
generic.md
View File

@@ -372,21 +372,24 @@ For each component with a firewalld service definition:
1. `rsync` the XML to `/etc/firewalld/services/<app>-<component>.xml` on the target. 1. `rsync` the XML to `/etc/firewalld/services/<app>-<component>.xml` on the target.
2. `firewall-cmd --reload` to pick up the new definition. 2. `firewall-cmd --reload` to pick up the new definition.
3. Check if the service is already enabled in the target zone (default zone unless the manifest specifies otherwise): 3. Resolve the host's default zone (`firewall-cmd --get-default-zone`) and check if the service is already enabled there:
``` ```
firewall-cmd --zone=<zone> --query-service=<app>-<component> zone=$(firewall-cmd --get-default-zone)
firewall-cmd --zone=$zone --query-service=<app>-<component>
``` ```
4. If not, enable it persistently **and** in the runtime config: 4. If not, enable it persistently **and** in the runtime config:
``` ```
firewall-cmd --permanent --zone=<zone> --add-service=<app>-<component> firewall-cmd --permanent --zone=$zone --add-service=<app>-<component>
firewall-cmd --zone=<zone> --add-service=<app>-<component> firewall-cmd --zone=$zone --add-service=<app>-<component>
``` ```
5. On component removal (future concern), the reverse: `--remove-service` then delete the XML. 5. On component removal (future concern), the reverse: `--remove-service` then delete the XML.
Steps must be idempotent — re-running a deploy is a no-op on the firewall layer if the service is already installed and enabled. Steps must be idempotent — re-running a deploy is a no-op on the firewall layer if the service is already installed and enabled.
### Zone selection ### Zone selection
Most services bind to internal WireGuard interfaces. Put the WireGuard interface in a dedicated `internal` or `wg` zone and open services there. Public-facing services (rare — nginx is usually the only one) go in the default `public`/`FedoraServer` zone. The manifest may optionally specify a `zone:` per component; default to `internal` if unset. The infrastructure uses **only the default zone** created at OS install time — `FedoraServer` on servers, `FedoraWorkstation` on workstations. There are no custom zones (no `internal`, no `wg`), and `deploy.sh` should not create any. Always add services to whatever `firewall-cmd --get-default-zone` reports on the target host.
If a future need arises to segment traffic by interface (e.g., restricting a component to the WireGuard interface only), revisit this section before introducing custom zoning — don't add it silently.
### Port ranges, ICMP, sources ### Port ranges, ICMP, sources
If a service needs port ranges, ICMP types, or source-IP restrictions, put them in the same XML using firewalld's standard elements (`<port port="x-y" />`, `<source address="..."/>`). Don't split these across multiple named services. If a service needs port ranges, ICMP types, or source-IP restrictions, put them in the same XML using firewalld's standard elements (`<port port="x-y" />`, `<source address="..."/>`). Don't split these across multiple named services.