blob: 019afe84bfd0059d1319dd42a35b28d7a73ed0ad (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
|
# PI Phase 3.1 End-to-End Verification
Task 3.1 for the Raspberry Pi cluster was verified across:
- `pi0.lan.buetow.org`
- `pi1.lan.buetow.org`
- `pi2.lan.buetow.org`
- `pi3.lan.buetow.org`
Client-side verification was performed from this workstation on the LAN, not from a separate unmanaged client. That was sufficient to validate LAN reachability, but browser-specific behavior on a distinct client remains an environmental limitation.
Verified behavior:
- Static farm content from `pi0` and `pi1` matched byte-for-byte with the same SHA-256 hash.
- `pi0` and `pi1` both served the static landing page over HTTP.
- Pi-hole DNS on `pi2` and `pi3` resolved `google.com` successfully.
- Pi-hole block behavior returned `0.0.0.0` for `doubleclick.net` on both DNS nodes.
- Pi-hole admin UI on both DNS nodes returned `302 Found` to `/admin/login`.
- Taking `lighttpd` down on `pi0` caused `pi0` HTTP to fail while `pi1` continued serving the same content.
- Taking Pi-hole down on `pi2` caused DNS and admin access on `pi2` to fail while `pi3` continued answering queries and serving the admin UI.
- `lighttpd` was restored on `pi0` and the Pi-hole stack was restored on `pi2` before finishing.
Resource and stability checks:
- `lighttpd` on `pi0` and `pi1` stayed lightweight during normal checks, with both hosts showing roughly 780 MiB available RAM.
- Pi-hole on `pi2` and `pi3` stayed healthy after restart and reported normal startup logs.
- Recent `journalctl -u lighttpd` output on `pi0` showed only the intentional stop/start events from the redundancy test.
- Recent Pi-hole container logs on `pi2` and `pi3` showed normal startup and web server initialization messages.
LAN port scan:
- `nmap -Pn -p 80,53 pi0 pi1 pi2 pi3` showed `80/tcp` open on all four Pis.
- `53/tcp` was filtered on `pi0` and `pi1`.
- `53/tcp` was open on `pi2` and `pi3`.
Notes:
- The workstation initially lacked `nmap`, so it was installed locally before the LAN scan.
- Browser rendering and a truly separate LAN client were not available in this environment, so the verification used direct HTTP, DNS, and port-scan checks from the LAN workstation instead.
|
