d-bis/proxmox
4
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Complete markdown files cleanup and organization

Browse Source 
- Organized 252 files across project
- Root directory: 187 → 2 files (98.9% reduction)
- Moved configuration guides to docs/04-configuration/
- Moved troubleshooting guides to docs/09-troubleshooting/
- Moved quick start guides to docs/01-getting-started/
- Moved reports to reports/ directory
- Archived temporary files
- Generated comprehensive reports and documentation
- Created maintenance scripts and guides

All files organized according to established standards.
This commit is contained in:
defiQUG
2026-01-06 01:46:25 -08:00
parent 1edcec953c
commit cb47cce074
1327 changed files with 217220 additions and 801 deletions
Download Patch File Download Diff File Expand all files Collapse all files

66
reports/analyses/DHCP_CONTAINERS_LIST.md Normal file
View File

@@ -0,0 +1,66 @@
# DHCP Containers - Complete List
**Generated**: 2026-01-05
**Source**: CONTAINER_INVENTORY_20260105_142842.md
---
## DHCP Containers Found
| VMID | Name | Host | Status | Current DHCP IP | Hostname | Notes |
|------|------|------|--------|----------------|----------|-------|
| 3500 | oracle-publisher-1 | ml110 | running | 192.168.11.15 | oracle-publisher-1 | ⚠️ IP in reserved range (physical servers) |
| 3501 | ccip-monitor-1 | ml110 | running | 192.168.11.14 | ccip-monitor-1 | 🔴 **CRITICAL: IP conflict with r630-04 physical server** |
| 100 | proxmox-mail-gateway | r630-02 | running | 192.168.11.4 | proxmox-mail-gateway | - |
| 101 | proxmox-datacenter-manager | r630-02 | running | 192.168.11.6 | proxmox-datacenter-manager | - |
| 102 | cloudflared | r630-02 | running | 192.168.11.9 | cloudflared | - |
| 103 | omada | r630-02 | running | 192.168.11.20 | omada | - |
| 104 | gitea | r630-02 | running | 192.168.11.18 | gitea | - |
| 6200 | firefly-1 | r630-02 | running | 192.168.11.7 | firefly-1 | - |
| 7811 | mim-api-1 | r630-02 | stopped | N/A | mim-api-1 | - |
---
## Summary
- **Total DHCP containers**: 9
- **Running**: 8
- **Stopped**: 1 (VMID 7811)
---
## Critical Issues
### 1. IP Conflict - VMID 3501
- **VMID**: 3501 (ccip-monitor-1)
- **Current IP**: 192.168.11.14
- **Conflict**: This IP is assigned to physical server r630-04
- **Action Required**: Must change IP immediately to resolve conflict
### 2. Reserved IP Range - VMID 3500
- **VMID**: 3500 (oracle-publisher-1)
- **Current IP**: 192.168.11.15
- **Issue**: IP is in reserved range (192.168.11.10-25) for physical servers
- **Action Required**: Change IP to outside reserved range
---
## IP Assignment Plan
Starting from **192.168.11.28** (since .26 and .27 are already in use):
| VMID | Name | Current DHCP IP | Proposed Static IP | Priority |
|------|------|----------------|-------------------|----------|
| 3501 | ccip-monitor-1 | 192.168.11.14 | 192.168.11.28 | 🔴 **HIGH** (IP conflict) |
| 3500 | oracle-publisher-1 | 192.168.11.15 | 192.168.11.29 | 🔴 **HIGH** (reserved range) |
| 100 | proxmox-mail-gateway | 192.168.11.4 | 192.168.11.30 | 🟡 Medium |
| 101 | proxmox-datacenter-manager | 192.168.11.6 | 192.168.11.31 | 🟡 Medium |
| 102 | cloudflared | 192.168.11.9 | 192.168.11.32 | 🟡 Medium |
| 103 | omada | 192.168.11.20 | 192.168.11.33 | 🟡 Medium |
| 104 | gitea | 192.168.11.18 | 192.168.11.34 | 🟡 Medium |
| 6200 | firefly-1 | 192.168.11.7 | 192.168.11.35 | 🟡 Medium |
| 7811 | mim-api-1 | N/A (stopped) | 192.168.11.36 | 🟢 Low (stopped) |
---
**Last Updated**: 2026-01-05

298
reports/analyses/DNS_CONFLICT_RESOLUTION.md Normal file
View File

@@ -0,0 +1,298 @@
# DNS Conflict Resolution Plan
## Critical Issue Summary
**Problem**: 9 hostnames pointing to the same Cloudflare tunnel (`10ab22da-8ea3-4e2e-a896-27ece2211a05`) without proper ingress rules.
**Impact**: Services failing, routing conflicts, difficult troubleshooting.
## Root Cause Analysis
### DNS Zone File Shows:
```
9 hostnames → 10ab22da-8ea3-4e2e-a896-27ece2211a05.cfargotunnel.com
```
### Current Tunnel Status
- **Tunnel ID**: `10ab22da-8ea3-4e2e-a896-27ece2211a05`
- **Status**: ⚠️ DOWN (needs configuration)
- **Location**: Should be in VMID 102 on r630-02
- **Target**: Should route to central Nginx at `192.168.11.21:80`
### Affected Services
| Hostname | Service | Expected Target |
|----------|---------|-----------------|
| `dbis-admin.d-bis.org` | Admin UI | `http://192.168.11.21:80` |
| `dbis-api.d-bis.org` | API v1 | `http://192.168.11.21:80` |
| `dbis-api-2.d-bis.org` | API v2 | `http://192.168.11.21:80` |
| `mim4u.org.d-bis.org` | MIM4U Site | `http://192.168.11.21:80` |
| `www.mim4u.org.d-bis.org` | MIM4U WWW | `http://192.168.11.21:80` |
| `rpc-http-prv.d-bis.org` | Private HTTP RPC | `http://192.168.11.21:80` |
| `rpc-http-pub.d-bis.org` | Public HTTP RPC | `http://192.168.11.21:80` |
| `rpc-ws-prv.d-bis.org` | Private WS RPC | `http://192.168.11.21:80` |
| `rpc-ws-pub.d-bis.org` | Public WS RPC | `http://192.168.11.21:80` |
## Resolution Steps
### Step 1: Verify Tunnel Configuration Location
```bash
# Check if tunnel config exists in VMID 102
ssh root@192.168.11.12 "pct exec 102 -- ls -la /etc/cloudflared/ | grep 10ab22da"
```
### Step 2: Create/Update Tunnel Configuration
The tunnel needs a complete ingress configuration file:
**File**: `/etc/cloudflared/tunnel-services.yml` (in VMID 102)
```yaml
tunnel: 10ab22da-8ea3-4e2e-a896-27ece2211a05
credentials-file: /etc/cloudflared/credentials-services.json
ingress:
# Admin Interface
- hostname: dbis-admin.d-bis.org
service: http://192.168.11.21:80
originRequest:
httpHostHeader: dbis-admin.d-bis.org
# API Endpoints
- hostname: dbis-api.d-bis.org
service: http://192.168.11.21:80
originRequest:
httpHostHeader: dbis-api.d-bis.org
- hostname: dbis-api-2.d-bis.org
service: http://192.168.11.21:80
originRequest:
httpHostHeader: dbis-api-2.d-bis.org
# MIM4U Services
- hostname: mim4u.org.d-bis.org
service: http://192.168.11.21:80
originRequest:
httpHostHeader: mim4u.org.d-bis.org
- hostname: www.mim4u.org.d-bis.org
service: http://192.168.11.21:80
originRequest:
httpHostHeader: www.mim4u.org.d-bis.org
# RPC Endpoints - HTTP
- hostname: rpc-http-prv.d-bis.org
service: http://192.168.11.21:80
originRequest:
httpHostHeader: rpc-http-prv.d-bis.org
- hostname: rpc-http-pub.d-bis.org
service: http://192.168.11.21:80
originRequest:
httpHostHeader: rpc-http-pub.d-bis.org
# RPC Endpoints - WebSocket
- hostname: rpc-ws-prv.d-bis.org
service: http://192.168.11.21:80
originRequest:
httpHostHeader: rpc-ws-prv.d-bis.org
- hostname: rpc-ws-pub.d-bis.org
service: http://192.168.11.21:80
originRequest:
httpHostHeader: rpc-ws-pub.d-bis.org
# Catch-all (MUST be last)
- service: http_status:404
# Metrics
metrics: 127.0.0.1:9090
# Logging
loglevel: info
# Grace period
gracePeriod: 30s
```
### Step 3: Create Systemd Service
**File**: `/etc/systemd/system/cloudflared-services.service`
```ini
[Unit]
Description=Cloudflare Tunnel for Services (RPC, API, Admin, MIM4U)
After=network.target
[Service]
TimeoutStartSec=0
Type=notify
ExecStart=/usr/local/bin/cloudflared --config /etc/cloudflared/tunnel-services.yml tunnel run
Restart=on-failure
RestartSec=5s
[Install]
WantedBy=multi-user.target
```
### Step 4: Fix TTL Values
In Cloudflare Dashboard:
1. Go to **DNS** → **Records**
2. For each CNAME record, change TTL from **1** to **300** (5 minutes) or **Auto**
3. Save changes
**Affected Records**:
- All 9 CNAME records pointing to `10ab22da-8ea3-4e2e-a896-27ece2211a05.cfargotunnel.com`
### Step 5: Verify Nginx Configuration
Ensure Nginx on `192.168.11.21:80` has server blocks for all hostnames:
```nginx
# Example server block
server {
listen 80;
server_name dbis-admin.d-bis.org;
location / {
proxy_pass http://<backend>;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
}
```
## Automated Fix Script
Create a script to deploy the fix:
```bash
#!/bin/bash
# fix-shared-tunnel.sh
PROXMOX_HOST="192.168.11.12"
VMID="102"
TUNNEL_ID="10ab22da-8ea3-4e2e-a896-27ece2211a05"
echo "Fixing shared tunnel configuration..."
# 1. Create config file
ssh root@${PROXMOX_HOST} "pct exec ${VMID} -- bash -c 'cat > /etc/cloudflared/tunnel-services.yml << \"EOF\"
tunnel: ${TUNNEL_ID}
credentials-file: /etc/cloudflared/credentials-services.json
ingress:
- hostname: dbis-admin.d-bis.org
service: http://192.168.11.21:80
originRequest:
httpHostHeader: dbis-admin.d-bis.org
- hostname: dbis-api.d-bis.org
service: http://192.168.11.21:80
originRequest:
httpHostHeader: dbis-api.d-bis.org
- hostname: dbis-api-2.d-bis.org
service: http://192.168.11.21:80
originRequest:
httpHostHeader: dbis-api-2.d-bis.org
- hostname: mim4u.org.d-bis.org
service: http://192.168.11.21:80
originRequest:
httpHostHeader: mim4u.org.d-bis.org
- hostname: www.mim4u.org.d-bis.org
service: http://192.168.11.21:80
originRequest:
httpHostHeader: www.mim4u.org.d-bis.org
- hostname: rpc-http-prv.d-bis.org
service: http://192.168.11.21:80
originRequest:
httpHostHeader: rpc-http-prv.d-bis.org
- hostname: rpc-http-pub.d-bis.org
service: http://192.168.11.21:80
originRequest:
httpHostHeader: rpc-http-pub.d-bis.org
- hostname: rpc-ws-prv.d-bis.org
service: http://192.168.11.21:80
originRequest:
httpHostHeader: rpc-ws-prv.d-bis.org
- hostname: rpc-ws-pub.d-bis.org
service: http://192.168.11.21:80
originRequest:
httpHostHeader: rpc-ws-pub.d-bis.org
- service: http_status:404
metrics: 127.0.0.1:9090
loglevel: info
gracePeriod: 30s
EOF'"
# 2. Create systemd service
ssh root@${PROXMOX_HOST} "pct exec ${VMID} -- bash -c 'cat > /etc/systemd/system/cloudflared-services.service << \"EOF\"
[Unit]
Description=Cloudflare Tunnel for Services
After=network.target
[Service]
TimeoutStartSec=0
Type=notify
ExecStart=/usr/local/bin/cloudflared --config /etc/cloudflared/tunnel-services.yml tunnel run
Restart=on-failure
RestartSec=5s
[Install]
WantedBy=multi-user.target
EOF'"
# 3. Reload systemd and start service
ssh root@${PROXMOX_HOST} "pct exec ${VMID} -- systemctl daemon-reload"
ssh root@${PROXMOX_HOST} "pct exec ${VMID} -- systemctl enable cloudflared-services.service"
ssh root@${PROXMOX_HOST} "pct exec ${VMID} -- systemctl start cloudflared-services.service"
# 4. Check status
ssh root@${PROXMOX_HOST} "pct exec ${VMID} -- systemctl status cloudflared-services.service"
echo "Done! Check tunnel status in Cloudflare dashboard."
```
## Testing
After applying the fix:
```bash
# Test each hostname
for host in dbis-admin dbis-api dbis-api-2 mim4u.org www.mim4u.org rpc-http-prv rpc-http-pub rpc-ws-prv rpc-ws-pub; do
echo "Testing ${host}.d-bis.org..."
curl -I "https://${host}.d-bis.org" 2>&1 | head -1
done
```
## Verification Checklist
- [ ] Tunnel configuration file created
- [ ] Systemd service created and enabled
- [ ] Tunnel service running
- [ ] All 9 hostnames accessible
- [ ] TTL values updated in Cloudflare
- [ ] Nginx routing correctly
- [ ] No 404 errors for valid hostnames
## Long-term Recommendations
1. **Separate Tunnels**: Consider splitting into separate tunnels:
- RPC tunnel (4 hostnames)
- API tunnel (3 hostnames)
- Web tunnel (2 hostnames)
2. **TTL Standardization**: Use consistent TTL values (300 or 3600)
3. **Monitoring**: Set up alerts for tunnel health
4. **Documentation**: Document all tunnel configurations
## Summary
**Issue**: 9 hostnames sharing one tunnel without proper ingress rules
**Fix**: Create complete ingress configuration with all hostnames
**Status**: ⚠️ Requires manual configuration
**Priority**: 🔴 HIGH - Services are likely failing

105
reports/analyses/IP_ASSIGNMENT_PLAN.md Normal file
View File

@@ -0,0 +1,105 @@
# IP Assignment Plan - DHCP to Static Conversion
**Generated**: 2026-01-05
**Starting IP**: 192.168.11.28
**Purpose**: Assign static IPs to all DHCP containers starting from 192.168.11.28
---
## Assignment Priority
### Priority 1: Critical IP Conflicts (Must Fix First)
| VMID | Name | Host | Current DHCP IP | New Static IP | Reason | Priority |
|------|------|------|----------------|---------------|--------|----------|
| 3501 | ccip-monitor-1 | ml110 | 192.168.11.14 | **192.168.11.28** | 🔴 **CRITICAL**: IP conflict with r630-04 physical server | **HIGHEST** |
| 3500 | oracle-publisher-1 | ml110 | 192.168.11.15 | **192.168.11.29** | 🔴 **CRITICAL**: IP in reserved range (physical servers) | **HIGHEST** |
### Priority 2: Reserved Range Conflicts
| VMID | Name | Host | Current DHCP IP | New Static IP | Reason | Priority |
|------|------|------|----------------|---------------|--------|----------|
| 103 | omada | r630-02 | 192.168.11.20 | **192.168.11.30** | ⚠️ IP in reserved range | **HIGH** |
| 104 | gitea | r630-02 | 192.168.11.18 | **192.168.11.31** | ⚠️ IP in reserved range | **HIGH** |
### Priority 3: Infrastructure Services
| VMID | Name | Host | Current DHCP IP | New Static IP | Reason | Priority |
|------|------|------|----------------|---------------|--------|----------|
| 100 | proxmox-mail-gateway | r630-02 | 192.168.11.4 | **192.168.11.32** | Infrastructure service | Medium |
| 101 | proxmox-datacenter-manager | r630-02 | 192.168.11.6 | **192.168.11.33** | Infrastructure service | Medium |
| 102 | cloudflared | r630-02 | 192.168.11.9 | **192.168.11.34** | Infrastructure service (Cloudflare tunnel) | Medium |
### Priority 4: Application Services
| VMID | Name | Host | Current DHCP IP | New Static IP | Reason | Priority |
|------|------|------|----------------|---------------|--------|----------|
| 6200 | firefly-1 | r630-02 | 192.168.11.7 | **192.168.11.35** | Application service | Medium |
| 7811 | mim-api-1 | r630-02 | N/A (stopped) | **192.168.11.36** | Application service (stopped) | Low |
---
## Complete Assignment Map
| VMID | Name | Host | Current IP | New IP | Status |
|------|------|------|------------|--------|--------|
| 3501 | ccip-monitor-1 | ml110 | 192.168.11.14 | 192.168.11.28 | ⏳ Pending |
| 3500 | oracle-publisher-1 | ml110 | 192.168.11.15 | 192.168.11.29 | ⏳ Pending |
| 103 | omada | r630-02 | 192.168.11.20 | 192.168.11.30 | ⏳ Pending |
| 104 | gitea | r630-02 | 192.168.11.18 | 192.168.11.31 | ⏳ Pending |
| 100 | proxmox-mail-gateway | r630-02 | 192.168.11.4 | 192.168.11.32 | ⏳ Pending |
| 101 | proxmox-datacenter-manager | r630-02 | 192.168.11.6 | 192.168.11.33 | ⏳ Pending |
| 102 | cloudflared | r630-02 | 192.168.11.9 | 192.168.11.34 | ⏳ Pending |
| 6200 | firefly-1 | r630-02 | 192.168.11.7 | 192.168.11.35 | ⏳ Pending |
| 7811 | mim-api-1 | r630-02 | N/A | 192.168.11.36 | ⏳ Pending |
---
## IP Range Summary
- **Starting IP**: 192.168.11.28
- **Ending IP**: 192.168.11.36
- **Total IPs needed**: 9
- **Available IPs in range**: 65 (plenty of room)
---
## Validation
### IP Conflict Check
- ✅ 192.168.11.28 - Available
- ✅ 192.168.11.29 - Available
- ✅ 192.168.11.30 - Available
- ✅ 192.168.11.31 - Available
- ✅ 192.168.11.32 - Available
- ✅ 192.168.11.33 - Available
- ✅ 192.168.11.34 - Available
- ✅ 192.168.11.35 - Available
- ✅ 192.168.11.36 - Available
### Reserved Range Check
- ✅ All new IPs are outside reserved range (192.168.11.10-25)
- ✅ All new IPs are outside already-used static IPs
---
## Execution Order
1. **First**: Fix critical conflicts (3501, 3500)
2. **Second**: Fix reserved range conflicts (103, 104)
3. **Third**: Convert infrastructure services (100, 101, 102)
4. **Fourth**: Convert application services (6200, 7811)
---
## Notes
- **192.168.11.14 conflict**: VMID 3501 must be moved immediately as it conflicts with r630-04 physical server
- **192.168.11.15 conflict**: VMID 3500 is in reserved range and should be moved
- **Service dependencies**: 1536 references found across 374 files - will need comprehensive update
- **Cloudflare tunnel**: VMID 102 (cloudflared) IP change may require tunnel config update
- **Nginx Proxy Manager**: VMID 105 routes may need update if target service IPs change
---
**Last Updated**: 2026-01-05

181
reports/analyses/IP_CONFLICT_192.168.11.14_RESOLUTION.md Normal file
View File

@@ -0,0 +1,181 @@
# IP Conflict Resolution: 192.168.11.14
**Date**: 2026-01-05
**Status**: 🔄 **CONFLICT IDENTIFIED - RESOLUTION IN PROGRESS**
---
## Conflict Summary
| Property | Value |
|----------|-------|
| **IP Address** | 192.168.11.14 |
| **Assigned To** | r630-04 Proxmox host |
| **Currently Used By** | Unknown device (Ubuntu system) |
| **r630-04 Status** | Powered OFF, runs Debian/Proxmox |
| **Conflict Type** | IP address hijacked/misconfigured |
---
## Investigation Results
### Device Using 192.168.11.14
| Property | Value |
|----------|-------|
| **MAC Address** | `bc:24:11:ee:a6:ec` |
| **MAC Vendor** | Proxmox Server Solutions GmbH |
| **OS** | Ubuntu (OpenSSH_8.9p1 Ubuntu-3ubuntu0.13) |
| **SSH Port** | ✅ OPEN |
| **Proxmox Port** | ❌ CLOSED |
| **Cluster Status** | ❌ NOT IN CLUSTER |
| **Container Search** | ❌ NOT FOUND in cluster containers |
### r630-04 Physical Server
| Property | Value |
|----------|-------|
| **Status** | ✅ Powered OFF (confirmed) |
| **OS** | ✅ Debian/Proxmox (confirmed) |
| **Assigned IP** | 192.168.11.14 (should be) |
| **Current IP** | N/A (powered off) |
---
## Root Cause Analysis
### Most Likely Scenario
**Orphaned LXC Container**:
- An LXC container running Ubuntu is using 192.168.11.14
- Container was likely created on r630-04 before it was powered off
- Container may have been:
- Created with static IP 192.168.11.14
- Not properly removed when r630-04 was shut down
- Running on a different host but configured with r630-04's IP
### Alternative Scenarios
1. **Container on Different Host**
- Container exists on ml110, r630-01, or r630-02
- Not visible in cluster view (orphaned)
- Needs to be found and removed/reconfigured
2. **Misconfigured Device**
- Another device manually configured with this IP
- Needs to be identified and reconfigured
---
## Resolution Plan
### Step 1: Locate the Container/Device
**Actions**:
```bash
# Check all Proxmox hosts for containers with this MAC or IP
for host in 192.168.11.10 192.168.11.11 192.168.11.12; do
echo "=== Checking $host ==="
ssh root@$host "pct list --all"
ssh root@$host "for vmid in \$(pct list | grep -v VMID | awk '{print \$1}'); do
pct config \$vmid 2>/dev/null | grep -E 'bc:24:11:ee:a6:ec|192.168.11.14' && echo \"VMID \$vmid on $host\";
done"
done
# Check QEMU VMs as well
for host in 192.168.11.10 192.168.11.11 192.168.11.12; do
ssh root@$host "qm list --all"
ssh root@$host "for vmid in \$(qm list | grep -v VMID | awk '{print \$1}'); do
qm config \$vmid 2>/dev/null | grep -E 'bc:24:11:ee:a6:ec|192.168.11.14' && echo \"VMID \$vmid on $host\";
done"
done
```
### Step 2: Resolve the Conflict
**Option A: If Container Found**
1. Identify the container (VMID and host)
2. Stop the container
3. Change container IP to different address (e.g., 192.168.11.28)
4. Restart container with new IP
5. Verify r630-04 can use 192.168.11.14 when powered on
**Option B: If Container Not Found**
1. Check if device is on network segment we haven't checked
2. Check router/switch ARP tables
3. Consider blocking the IP at router level
4. Reassign IP when r630-04 is powered on
### Step 3: Verify Resolution
**Actions**:
1. Power on r630-04
2. Configure r630-04 with IP 192.168.11.14
3. Verify no IP conflict
4. Add r630-04 to cluster
5. Update documentation
---
## Impact Assessment
### Current Impact
- **Low**: Doesn't affect current operations (r630-04 is off)
- **Medium**: Blocks r630-04 from using its assigned IP
- **High**: Will cause network issues when r630-04 is powered on
### Resolution Priority
**Priority**: 🔴 **HIGH**
- Must be resolved before powering on r630-04
- Prevents network conflicts
- Enables proper r630-04 cluster integration
---
## Recommended Actions
### Immediate (Before Powering On r630-04)
1. **Locate the conflicting device**
- Search all Proxmox hosts thoroughly
- Check for orphaned containers
- Check router ARP tables
2. **Resolve the conflict**
- Stop/remove conflicting container
- Reassign IP if needed
- Document the change
3. **Verify IP is available**
- Confirm 192.168.11.14 is free
- Test connectivity
### When Powering On r630-04
1. **Configure r630-04**
- Set IP to 192.168.11.14
- Verify no conflicts
- Join to cluster
2. **Verify cluster integration**
- Check cluster status
- Verify storage access
- Test migrations
---
## Next Steps
1. **Execute container search** (see Step 1 above)
2. **Identify conflicting device**
3. **Resolve IP conflict**
4. **Document resolution**
5. **Prepare r630-04 for cluster join**
---
**Last Updated**: 2026-01-05
**Status**: 🔄 **RESOLUTION IN PROGRESS**
**Blocking**: r630-04 cannot use assigned IP until conflict resolved

176
reports/analyses/MIM4U_DOMAIN_CONFLICT.md Normal file
View File

@@ -0,0 +1,176 @@
# MIM4U Domain Conflict Resolution
## Conflict Identified
**Issue**: `mim4u.org` exists as both:
1. **Root domain** in Cloudflare (Active, 2 visitors)
2. **Subdomain** of d-bis.org: `mim4u.org.d-bis.org` and `www.mim4u.org.d-bis.org`
## Current Configuration
### In d-bis.org DNS Zone:
```
mim4u.org.d-bis.org. 1 IN CNAME 10ab22da-8ea3-4e2e-a896-27ece2211a05.cfargotunnel.com.
www.mim4u.org.d-bis.org. 1 IN CNAME 10ab22da-8ea3-4e2e-a896-27ece2211a05.cfargotunnel.com.
```
### Separate Domain:
- `mim4u.org` (root domain) - Active in Cloudflare
- Status: Active, 2 visitors
- DNS records: Unknown (needs analysis)
## Impact
1. **User Confusion**: Users might try `mim4u.org` but services are at `mim4u.org.d-bis.org`
2. **SSL Certificates**: Different certificates needed for root vs subdomain
3. **Tunnel Configuration**: Root domain may need separate tunnel or redirect
4. **SEO/DNS**: Potential duplicate content issues
## Resolution Options
### Option 1: Use Root Domain (mim4u.org) as Primary ⭐ Recommended
**Action**:
1. Configure `mim4u.org` (root) to point to services
2. Redirect `mim4u.org.d-bis.org` → `mim4u.org`
3. Update tunnel configuration to use `mim4u.org` instead of `mim4u.org.d-bis.org`
**Pros**:
- Cleaner URLs (shorter)
- Better branding
- Standard practice
**Cons**:
- Requires DNS changes
- Need to update all references
### Option 2: Use Subdomain (mim4u.org.d-bis.org) as Primary
**Action**:
1. Keep `mim4u.org.d-bis.org` as primary
2. Redirect `mim4u.org` (root) → `mim4u.org.d-bis.org`
3. No changes to tunnel configuration
**Pros**:
- No tunnel changes needed
- Keeps d-bis.org structure
**Cons**:
- Longer URLs
- Less intuitive
### Option 3: Keep Both (Not Recommended)
**Action**:
1. Configure both independently
2. Point to same services
3. Maintain separate DNS records
**Pros**:
- Maximum flexibility
**Cons**:
- Duplicate maintenance
- Potential confusion
- SEO issues
## Recommended Solution: Option 1
### Step-by-Step Implementation
#### 1. Analyze Current mim4u.org Configuration
```bash
# Check DNS records for mim4u.org (root)
dig +short mim4u.org
dig +short www.mim4u.org
dig +short mim4u.org ANY
# Check if tunnel exists
# In Cloudflare Dashboard: Zero Trust → Networks → Tunnels
```
#### 2. Create/Update Tunnel for mim4u.org
If using root domain, create tunnel configuration:
```yaml
# /etc/cloudflared/tunnel-mim4u.yml
tunnel: <TUNNEL_ID_MIM4U>
credentials-file: /etc/cloudflared/credentials-mim4u.json
ingress:
- hostname: mim4u.org
service: http://192.168.11.21:80
originRequest:
httpHostHeader: mim4u.org
- hostname: www.mim4u.org
service: http://192.168.11.21:80
originRequest:
httpHostHeader: www.mim4u.org
- service: http_status:404
```
#### 3. Update DNS Records
**In Cloudflare Dashboard for mim4u.org**:
- Create CNAME: `@` → `<tunnel-id>.cfargotunnel.com` (proxied)
- Create CNAME: `www` → `<tunnel-id>.cfargotunnel.com` (proxied)
**In Cloudflare Dashboard for d-bis.org**:
- Update `mim4u.org.d-bis.org` → Redirect to `https://mim4u.org`
- Update `www.mim4u.org.d-bis.org` → Redirect to `https://www.mim4u.org`
#### 4. Update Tunnel Configuration
Remove from shared tunnel (`10ab22da-8ea3-4e2e-a896-27ece2211a05`):
- Remove `mim4u.org.d-bis.org` entry
- Remove `www.mim4u.org.d-bis.org` entry
Add to new/separate tunnel for `mim4u.org` root domain.
#### 5. Update Application Configuration
Update any hardcoded references:
- Config files
- Environment variables
- Documentation
- SSL certificates
## Testing
After implementation:
```bash
# Test root domain
curl -I https://mim4u.org
curl -I https://www.mim4u.org
# Test subdomain redirect
curl -I https://mim4u.org.d-bis.org
# Should return 301/302 redirect to mim4u.org
# Verify SSL certificates
openssl s_client -connect mim4u.org:443 -servername mim4u.org < /dev/null
```
## Checklist
- [ ] Analyze current mim4u.org DNS records
- [ ] Decide on resolution option
- [ ] Create/update tunnel for mim4u.org (if using root)
- [ ] Update DNS records
- [ ] Update tunnel configurations
- [ ] Test accessibility
- [ ] Update documentation
- [ ] Update application configs
- [ ] Monitor for issues
## Summary
**Current State**: Conflicting configuration (root + subdomain)
**Recommended**: Use `mim4u.org` (root) as primary, redirect subdomain
**Priority**: Medium (not blocking but should be resolved)
**Effort**: Low-Medium (requires DNS and tunnel updates)

185
reports/analyses/PHASE1_IP_CONFLICT_RESOLUTION.md Normal file
View File

@@ -0,0 +1,185 @@
# Phase 1.1: IP Conflict Resolution - 192.168.11.14
**Date**: 2026-01-05
**Status**: 🔄 **INVESTIGATION COMPLETE - RESOLUTION PENDING**
---
## Investigation Results
### Device Information
| Property | Value |
|----------|-------|
| **IP Address** | 192.168.11.14 |
| **MAC Address** | `bc:24:11:ee:a6:ec` |
| **MAC Vendor** | Proxmox Server Solutions GmbH |
| **OUI** | `bc:24:11` |
| **SSH Banner** | `OpenSSH_8.9p1 Ubuntu-3ubuntu0.13` |
| **OS Type** | Ubuntu (NOT Debian/Proxmox) |
| **Port 22 (SSH)** | ✅ OPEN |
| **Port 8006 (Proxmox)** | ❌ CLOSED |
| **Cluster Status** | ❌ NOT IN CLUSTER |
### Key Findings
1. **MAC Address Analysis**:
- MAC vendor: **Proxmox Server Solutions GmbH**
- This confirms it's a **Proxmox-generated MAC address**
- Pattern `bc:24:11` is typical for LXC containers
- **Conclusion**: This is likely an **LXC container**, not a physical server
2. **Container Search Results**:
- ✅ Checked all containers on ml110, r630-01, r630-02
- ❌ **No container found** with MAC `bc:24:11:ee:a6:ec`
- ❌ **No container found** with IP 192.168.11.14
- Found similar MAC pattern in VMID 5000 (but different MAC and IP)
3. **SSH Analysis**:
- Responds with Ubuntu SSH banner
- Proxmox hosts use Debian
- **Conclusion**: Device is running Ubuntu, not Proxmox
---
## Conclusion
**192.168.11.14 is NOT the r630-04 Proxmox host.**
### Most Likely Scenario
**Orphaned LXC Container**:
- An LXC container running Ubuntu is using 192.168.11.14
- Container is not registered in the Proxmox cluster view
- Container may be:
- On a Proxmox host not in the cluster (r630-03, r630-04, or another host)
- Orphaned (deleted from cluster but network interface still active)
- Created outside Proxmox management
### Alternative Scenarios
1. **r630-04 Running Ubuntu Instead of Proxmox**
- r630-04 was reinstalled with Ubuntu
- Not running Proxmox VE
- Would explain why it's not in the cluster
2. **Different Physical Device**
- Another server/device configured with this IP
- Unlikely given Proxmox MAC vendor
---
## Resolution Steps
### Step 1: Identify Container Location
**Actions**:
```bash
# Check all Proxmox hosts (including non-cluster members)
for host in 192.168.11.10 192.168.11.11 192.168.11.12 192.168.11.13 192.168.11.14; do
echo "=== Checking $host ==="
ssh root@$host "pct list --all 2>/dev/null | grep -E 'VMID|192.168.11.14'"
ssh root@$host "qm list --all 2>/dev/null | grep -E 'VMID|192.168.11.14'"
done
# Check for containers with this MAC
for host in 192.168.11.10 192.168.11.11 192.168.11.12; do
ssh root@$host "for vmid in \$(pct list | grep -v VMID | awk '{print \$1}'); do
pct config \$vmid 2>/dev/null | grep -q 'bc:24:11:ee:a6:ec' && echo \"Found in VMID \$vmid on $host\";
done"
done
```
### Step 2: Physical r630-04 Verification
**Actions**:
- Check physical r630-04 server power status
- Access console/iDRAC to verify:
- Is server powered on?
- What OS is installed?
- What IP address is configured?
- Is Proxmox installed?
### Step 3: Resolve IP Conflict
**Options**:
**Option A: If it's an orphaned container**
- Identify which host it's on
- Stop and remove the container
- Reassign 192.168.11.14 to actual r630-04 Proxmox host
**Option B: If r630-04 is running Ubuntu**
- Decide if Proxmox should be installed
- If yes: Reinstall r630-04 with Proxmox VE
- If no: Update documentation, assign different IP to r630-04
**Option C: If it's a different device**
- Identify the device
- Reassign IP to appropriate device
- Update network documentation
---
## Impact Assessment
### Current Impact
- **Low**: IP conflict doesn't affect current operations
- **Medium**: Confusion about r630-04 status
- **High**: Blocks proper r630-04 Proxmox host configuration
### Resolution Priority
**Priority**: 🔴 **HIGH**
- Blocks r630-04 from joining cluster
- Prevents proper network documentation
- May cause confusion in future deployments
---
## Next Actions
1. **Immediate**:
- [ ] Check physical r630-04 server status
- [ ] Access console/iDRAC to verify actual configuration
- [ ] Check if container exists on r630-03 or r630-04
2. **Short-term**:
- [ ] Resolve IP conflict based on findings
- [ ] Update network documentation
- [ ] Verify r630-04 Proxmox installation status
3. **Long-term**:
- [ ] Complete network audit
- [ ] Document all device assignments
- [ ] Implement IPAM (IP Address Management) system
---
## Related Documentation
- `R630-04_IP_CONFLICT_DISCOVERY.md` - Initial discovery
- `R630-04_DIAGNOSTIC_REPORT.md` - Diagnostic findings
- `ECOSYSTEM_IMPROVEMENT_PLAN.md` - Overall improvement plan
---
## Physical Verification Results ✅
**Date**: 2026-01-05
**r630-04 Status**:
- ✅ **Powered OFF** (confirmed)
- ✅ **Runs Debian/Proxmox** (confirmed)
- ❌ **NOT using 192.168.11.14** (something else is)
**Conclusion**:
- r630-04 is the correct Proxmox host but is currently powered off
- The device responding on 192.168.11.14 is **NOT r630-04**
- This confirms an **IP conflict** - another device is using r630-04's assigned IP
---
**Last Updated**: 2026-01-05
**Status**: ✅ **PHYSICAL VERIFICATION COMPLETE**
**Next Step**: Identify and resolve IP conflict (find what's using 192.168.11.14)

226
reports/analyses/R630-04_IP_CONFLICT_DISCOVERY.md Normal file
View File

@@ -0,0 +1,226 @@
# R630-04 IP Conflict Discovery
**Date**: 2026-01-05
**IP Address**: 192.168.11.14
**Status**: ⚠️ **CRITICAL - IP CONFLICT IDENTIFIED**
---
## Executive Summary
**CRITICAL DISCOVERY**: **192.168.11.14 is NOT the r630-04 Proxmox host.**
The device responding on 192.168.11.14 is running **Ubuntu**, but Proxmox VE is **Debian-based**. This indicates an IP conflict or misconfiguration.
---
## Evidence
### 1. SSH Banner Analysis
**What We See**:
```
OpenSSH_8.9p1 Ubuntu-3ubuntu0.13
```
**What We Expect** (Proxmox hosts):
- ml110: `Debian GNU/Linux 13 (trixie)` ✅
- r630-01: `Debian GNU/Linux 13 (trixie)` ✅
- r630-02: `Debian GNU/Linux 13 (trixie)` ✅ (assumed)
- r630-04: Should be Debian, but shows **Ubuntu** ❌
### 2. Cluster Verification
**Active Cluster Members**:
- ml110 (192.168.11.10) - Debian ✅
- r630-01 (192.168.11.11) - Debian ✅
- r630-02 (192.168.11.12) - Debian ✅
- r630-04 (192.168.11.14) - **NOT IN CLUSTER** ❌
### 3. Container/VM Search
**Result**: **NO containers or VMs** in the cluster are configured with IP 192.168.11.14
**Checked**:
- All LXC containers on ml110, r630-01, r630-02
- All QEMU VMs on ml110, r630-01, r630-02
- No matches found
---
## Possible Scenarios
### Scenario A: Orphaned VM/Container (Most Likely)
**Description**: A VM or container running Ubuntu is using 192.168.11.14 but is not registered in Proxmox.
**Possible Causes**:
- VM/container created outside Proxmox management
- Proxmox database corruption (VM exists but not in cluster view)
- VM on a different Proxmox host not in the cluster
- Standalone VM running on r630-04 hardware
**How to Verify**:
```bash
# Check all Proxmox hosts for VMs
for host in 192.168.11.10 192.168.11.11 192.168.11.12; do
ssh root@$host "qm list; pct list"
done
# Check for orphaned VMs
ssh root@192.168.11.10 "find /var/lib/vz -name '*.conf' | xargs grep -l '192.168.11.14'"
```
### Scenario B: Different Physical Device
**Description**: A different physical server or network device is using 192.168.11.14.
**Possible Causes**:
- Another server configured with this IP
- Network device (switch, router) using this IP
- Misconfigured device on the network
**How to Verify**:
```bash
# Get MAC address
arp -n 192.168.11.14
# or
ip neigh show 192.168.11.14
# Check MAC vendor to identify device type
```
### Scenario C: r630-04 Running Ubuntu (Not Proxmox)
**Description**: r630-04 was reinstalled with Ubuntu instead of Proxmox VE.
**Possible Causes**:
- Server was reinstalled with Ubuntu
- Proxmox was removed/replaced
- Server is running plain Ubuntu (not Proxmox)
**How to Verify**:
- Physical inspection of r630-04
- Console/iDRAC access to check actual OS
- Check if Proxmox is installed: `dpkg -l | grep pve`
### Scenario D: IP Conflict / Wrong IP Assignment
**Description**: The actual r630-04 Proxmox host is using a different IP, and something else is using 192.168.11.14.
**Possible Causes**:
- r630-04 Proxmox host is actually using a different IP
- Another device was assigned 192.168.11.14
- Network misconfiguration
**How to Verify**:
- Check all Proxmox hosts for their actual IPs
- Verify r630-04 physical server network configuration
- Check DHCP/static IP assignments
---
## Recommended Actions
### Immediate Actions
1. **Identify What's Actually Using 192.168.11.14**
```bash
# Get MAC address
ping -c 1 192.168.11.14
arp -n 192.168.11.14
# Try to identify device
# Check MAC vendor database
```
2. **Find the Actual r630-04 Proxmox Host**
- Check physical r630-04 server
- Verify its actual IP address
- Check if Proxmox is installed
- Verify network configuration
3. **Check for Orphaned VMs**
```bash
# On each Proxmox host
ssh root@192.168.11.10 "qm list --all"
ssh root@192.168.11.11 "qm list --all"
ssh root@192.168.11.12 "qm list --all"
# Check for VMs not in cluster view
```
4. **Verify Network Configuration**
- Check router/switch ARP tables
- Verify IP assignments in Omada controller
- Check for duplicate IP assignments
### Long-term Actions
1. **Resolve IP Conflict**
- If orphaned VM: Remove or reassign IP
- If different device: Reassign IP or update documentation
- If r630-04 is Ubuntu: Decide if Proxmox should be installed
2. **Update Documentation**
- Correct IP assignments
- Document actual r630-04 status
- Update network topology
3. **Network Audit**
- Complete IP address audit
- Verify all device assignments
- Check for other conflicts
---
## Network Topology Impact
### Current Understanding
| IP Address | Expected Device | Actual Device | Status |
|------------|----------------|---------------|--------|
| 192.168.11.10 | ml110 (Proxmox) | ml110 (Proxmox Debian) | ✅ Correct |
| 192.168.11.11 | r630-01 (Proxmox) | r630-01 (Proxmox Debian) | ✅ Correct |
| 192.168.11.12 | r630-02 (Proxmox) | r630-02 (Proxmox Debian) | ✅ Correct |
| 192.168.11.14 | r630-04 (Proxmox) | **Unknown (Ubuntu)** | ❌ **CONFLICT** |
### What We Need to Find
1. **Where is the actual r630-04 Proxmox host?**
- Is it powered off?
- Is it using a different IP?
- Does it exist at all?
2. **What is using 192.168.11.14?**
- VM/container?
- Different physical device?
- Misconfigured network device?
---
## Next Steps Checklist
- [ ] Get MAC address of device using 192.168.11.14
- [ ] Identify device type from MAC vendor
- [ ] Check physical r630-04 server status
- [ ] Verify r630-04 actual IP address
- [ ] Check for orphaned VMs on all Proxmox hosts
- [ ] Review network device configurations
- [ ] Check Omada controller for IP assignments
- [ ] Resolve IP conflict
- [ ] Update documentation with correct information
---
## Related Documentation
- `R630-04_DIAGNOSTIC_REPORT.md` - Initial diagnostic report
- `RESERVED_IP_CONFLICTS_ANALYSIS.md` - IP conflict analysis
- `docs/archive/historical/OMADA_CLOUD_CONTROLLER_IP_ASSIGNMENTS.md` - IP assignments
---
**Last Updated**: 2026-01-05
**Status**: ⚠️ **REQUIRES INVESTIGATION**
**Priority**: **HIGH** - IP conflict needs resolution