| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Co-Authored-By: Claude.ai
|
|
domain = {{ pihole_domain }} rendered as an unquoted bareword containing
a dot (e.g. "pi.hole"), which is invalid TOML. TOML parsing is
all-or-nothing, not line-by-line, so pihole-FTL rejected the entire
config file on that one line and silently fell back to its compiled-in
defaults — including binding its webserver directly to ports 80/443.
That collided with caddy, which wants the same ports, causing caddy to
crash-loop and get reported as "changed" (needing a restart) on every
subsequent ansible run.
Quoting the domain value lets the file parse successfully, which in turn
surfaces a second, previously-unreachable bug: the custom webserver port
(pihole_port) was rendered as a bare number, but Pi-hole v6 FTL requires
each listener address to carry a trailing flag character (o = optional,
s = TLS). Without it FTL rejects the value the same way and reverts to
the 80/443 default. Appending "o" fixes that.
Both bugs had to be fixed together: the quoting bug was blocking the
parser from ever reaching the port line, so the port fix alone had no
effect until parsing succeeded end-to-end.
Co-Authored-By: Claude.ai
|
|
|
|
Add radvd to gateway role to advertise Pi as high-preference IPv6
default router using the stable ULA prefix (fd1e:.../64). With
FritzBox also sending RAs, devices end up with ECMP between Pi and
FritzBox. To solve this, add network_ipv6_gateway (Pi's link-local)
as a static route with metric 100 to all managed hosts — beats RA
metric 425, ensuring all IPv6 default traffic goes through Pi.
Fix IPv6 MASQUERADE in gateway-apply-rules:
- Direct mode: add MASQUERADE on end0 (LAN devices use ULA source
addresses not known to FritzBox, so Pi must NAT them)
- FORWARD rules: restrict to RELATED,ESTABLISHED only — previously
the broad ACCEPT rule passed un-NAT'd packets alongside masqueraded
copies, causing duplicate SYNs, conntrack corruption, and RSTs
- MASQUERADE/clear rules: match by interface not by source subnet
(devices may use any source address, not just the ULA prefix)
- VPN mode return traffic: explicitly restrict to wg+→end0 direction
Add network_ipv6_gateway var (optional) to network role NM templates
(ethernet, wifi, bridge) — injects a static IPv6 default route at
metric 100 when set. Add rpi5 static route to FritzBox link-local so
Pi keeps IPv6 after FritzBox RA is disabled.
Force SSH to IPv4 for *.local hosts (AddressFamily inet) — prevents
Ansible from hanging on mDNS returning multiple IPv6 addresses.
Update gateway and pihole READMEs with two-step IPv6 setup process.
Co-Authored-By: Claude.ai
|
|
Remove static IPv6 support from network role — all hosts use SLAAC
(method=auto). Simplifies NM templates, argument_specs, and resolved.conf.
gateway sysctl accept_ra=2 is now unconditional when gateway_enabled.
Co-authored-by: Claude.ai
|
|
|
|
|
|
|
|
|
|
|
|
Since ipv6 seems to be causing a lot of issues with the new ISP
|
|
|
|
|
|
`false != ""` is True in Jinja2 — nginx config was created even when
`pihole_by_nginx: false`. Use `| bool` filter to coerce correctly.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The dotfile/vim/password_store required to run as user with root
permissions, that's why reverting these changes on rpi and resolving to
using a more normal role (in pihole where it was broken)
|
|
|
|
The ansible vars fail on CI because the validate arguments task runs way
before the setting of the variables, which causes the ansible undefined
vars on CI to cause errors.
This is a way better approach of having the static values as defaults
and allowing setting the variables to ansible vars in the host/group vars
|
|
|
|
|
|
|
|
|
|
This modularity means that each role can be installed in a playbook by
itself as long as the other roles exist around it.
This also straps the ensure dependency packages exist in any of the
roles tasks, they should be moved to their own roles and configured
properly if needed.
|
|
|
|
|
|
|
|
|
|
|
|
The pihole lookup DNS queries when the VPN connection is up was slow.
One of the culprits was the quad9 servers were taking long time when
using VPN
The other issue was the previous routing tables that used to work with
the fritzbox (with DHCP) which wasn't fully working was conflicting with
the VPN route tables and causing loops and delays.
Now most of the VPN queries are working fast but some requests are
taking some time, probably due to the VPN trying to check/block ads and
malware!
Also minor fixing to the pre tasks and documentation
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
