04 / CASE STUDY
AiServer homelab
Operating and documenting a segmented, self-hosted environment.
A private Ubuntu and Docker lab for service operations, monitoring, and network troubleshooting.
Private access → Ubuntu host → Docker services
Health reporting · Service visibility · Self-hosted AI
No addresses, endpoints or management links shown.
Challenge
Maintain a private learning environment for self-hosted services, with enough monitoring and documentation to troubleshoot problems without exposing management access publicly.
Environment
The lab uses Ubuntu Linux and Docker containers to run services. Tailscale provides private access; Secure Shell (SSH) administration uses a dedicated non-root account with permissions limited to approved tasks.
Built
The lab combines Discord health reports with Uptime Kuma for availability checks, Dozzle for container logs, Glance for a service overview and WUD for container-update visibility. Ollama and Open WebUI provide local AI tools. A private Homelab Operations Wiki organizes operational references. Its offline compiler turns Markdown into navigable HTML, checks links and source integrity, and applies credential-pattern safeguards before writing the reader.
Tested
Documented functional checks cover Discord health reporting, container operation and permitted versus blocked diagnostic actions. Offline wiki-compiler tests cover navigation, source references and integrity validation; fail-closed gates reject invalid builds rather than replace a working reader.
Method
I use the lab for configuration, functional testing and documentation. AI assistance supported lab administration, troubleshooting and documentation; the relay case below separates my work from AI-assisted implementation.
Concepts
Least-privilege administration means granting only the access needed for a task. The lab applies that approach to container operations while keeping public documentation separate from private infrastructure.
Outcomes
The lab brings self-hosted tools, service visibility and operational references into one private learning environment. The relay case below records a concrete troubleshooting result: five receivers became selectable after a targeted change.
Takeaways
Check both permitted and blocked actions when narrowing administrative access. Preserve source references in operational documentation and reject invalid reader builds before replacing a working copy. A running service and a successful health check do not by themselves establish security.
Scope and privacy
This page presents a sanitized overview of a private learning environment. Internal addresses, credentials, and management configurations are omitted. The evidence covers documented functional tests, not a comprehensive security audit or measured uptime guarantee. Credential-pattern checks are safeguards, not proof that all secrets are absent.
DOCUMENTED TROUBLESHOOTING / SEPTEMBER 2026
Cross-VLAN Discovery: Troubleshooting a DIAL Relay
Evidence: September 2026 working-configuration report. AI assisted troubleshooting and relay implementation; Juan handled lab configuration, functional testing and documentation.
Why this relay was needed
A virtual local area network (VLAN) separates devices into different network segments. Keeping trusted clients separate from Internet of Things (IoT) devices can interfere with consumer discovery designed for the same network. Vendor guidance illustrates the issue: Sonos requires its products and app controllers to share a VLAN; Bose’s Portable Smart Speaker guidance requires the app device and speaker to share a wireless network; and Google’s Chromecast discovery guidance specifies the same Wi-Fi network and notes specialized discovery in YouTube and Netflix.
This project addresses the YouTube Discovery and Launch (DIAL) / Simple Service Discovery Protocol (SSDP) discovery path used by the documented receivers, complementing rather than replacing Multicast DNS (mDNS) / Bonjour discovery. DIAL uses SSDP discovery followed by Hypertext Transfer Protocol (HTTP) requests. mDNS and Bonjour are another way devices discover services on a local network. Google Cast also uses Bonjour/mDNS discovery, including the _googlecast._tcp service; Google notes that YouTube and Netflix use specialized discovery mechanisms. This case is not general Google Cast mDNS troubleshooting or a universal speaker-compatibility fix. Discovery protocols and the permissions needed for subsequent device control require separate consideration; relaying discovery alone does not establish either compatibility or secure access.
Problem
Cross-VLAN YouTube discovery was inconsistent, often showing only an already-connected or actively playing receiver rather than the full set previously visible. Juan’s account and working-configuration report describe missing, gray or inconsistent receivers despite a DIAL relay carrying discovery between the Trusted and IoT networks. The goal was selective discovery without removing network separation.
Evidence
The documented packet capture showed responses for all five receivers reaching the client. Transport alone did not explain the symptom: the relay discarded each responder’s source Internet Protocol (IP) address and User Datagram Protocol (UDP) port, returning distinct responses with the same relay identity even though LOCATION URLs, the addresses used to retrieve receiver details, were rewritten.
- Trusted networkClient sends DIAL discovery
- Linux relayRelays requests; preserves responder IP/port on replies
- IoT networkFive receivers return distinct responses
Fix
A targeted C-code change in handle_msearch_proxy_recv() captured the responder address and port and used them for the outgoing response. The existing LOCATION rewriting and HTTP proxy were retained.
Before — identity discarded
/* recv_with_addrinfo address/port outputs */
NULL, NULL, NULL,
struct in_addr fromAddress = iface->ifaddr;
u_short fromPort = msearch_proxies[proxyidx].localport;After — identity preserved
struct in_addr responderAddress;
u_short responderPort;
/* recv_with_addrinfo address/port outputs */
&responderAddress, &responderPort, NULL,
struct in_addr fromAddress = responderAddress;
u_short fromPort = responderPort;Abbreviated C excerpts from the supplied report; argument fragments are not standalone programs.
Validation
After recompiling and starting the patched relay, Juan’s report records all five receivers as white/selectable. They remained available after both terminal sessions closed. The report also records blocked direct gateway connection tests on Transmission Control Protocol (TCP) ports 22, 80 and 443 from the IoT side.
Limitations
The packet observation and successful patch support responder-identity loss as the likely cause of the discovery problem, although the client’s internal deduplication behavior was not proven: the report did not establish exactly how the app decides that responses represent the same device. Validation covered the five documented receivers and blocked gateway connections on TCP ports 22, 80 and 443, not a complete isolation audit. The relay continued operating after the terminal sessions closed; that confirms operation without an open terminal session, not reboot persistence. A restart of the server was not part of the documented test.