TLDR: run migrations against new db and set environment variables:
Add this from sample.env to env with accurate db names, user and passwords:
POSTGRES_HOST=localhost
POSTGRES_PORT=5432
POSTGRES_DB=sqfour
| #!/bin/bash | |
| # Script to remove all Zone.Identifier files from the directory | |
| # These files are Windows metadata files created when downloading from the internet | |
| echo "Searching for Zone.Identifier files in directory..." | |
| # Find and count Zone.Identifier files | |
| ZONE_FILES=$(find . -name "*:Zone.Identifier" -type f) | |
| COUNT=$(echo "$ZONE_FILES" | grep -c "Zone.Identifier" 2>/dev/null || echo "0") |
| #!/usr/bin/env pwsh | |
| Write-Host "=== Azure Bastion Connection Helper ===" -ForegroundColor Cyan | |
| Write-Host "" | |
| # Step 1: Get all VMs with their bastion-related info | |
| Write-Host "Loading VMs and Bastions..." -ForegroundColor Yellow | |
| $vms = az vm list -d --query "[].{Name:name, ResourceGroup:resourceGroup, PowerState:powerState, VnetId:networkProfile.networkInterfaces[0].id}" | ConvertFrom-Json | |
| if ($vms.Count -eq 0) { |
After introducing Private DNS zones into a VNet-integrated environment with custom DNS servers, DNS resolution behavior changes due to zone precedence and authority rules.
This can result in previously working DNS lookups failing, not because DNS is broken, but because resolution is being intercepted earlier in the lookup chain.