Migrate to Cloudflare Workers & Add Advanced Linux Programming Blog Posts

[mattmattox]

Summary

This PR includes two major updates:

1. 🚀 Cloudflare Workers Migration

Migrates the support.tools website from Kubernetes to Cloudflare Workers for improved performance and reduced operational overhead.

Key Changes:

• ✅ Complete Cloudflare Workers setup with wrangler.toml
• ✅ Minimal worker script for static asset serving
• ✅ Updated Makefile with deployment commands
• ✅ GitHub Actions workflow for CI/CD
• ✅ Comprehensive documentation (migration guide & logs guide)
• ✅ Workers Logs enabled for monitoring

Benefits:

• 💰 Free hosting for static assets
• 🌍 Global CDN distribution
• ⚡ ~50ms latency worldwide
• 🔧 No infrastructure to manage
• 📈 Automatic scaling

Live Environments:

• https://dev.support.tools ✅
• https://mst.support.tools ✅
• https://qas.support.tools ✅
• https://tst.support.tools ✅
• https://stg.support.tools ✅
• https://support.tools ✅

2. 📚 25 Advanced Linux & Systems Programming Blog Posts

Adds comprehensive technical content covering:

• Linux kernel development & debugging
• System programming & performance optimization
• Networking & distributed systems
• Container & virtualization technologies
• Real-time & embedded systems
• Security & cryptography
• Audio, graphics & multimedia programming
• And more...

Testing

• All environments deployed successfully
• Health checks passing
• Logs working correctly
• GitHub Actions workflow tested
• Blog posts render correctly

Migration Notes

• Original Kubernetes deployment remains as fallback
• DNS already pointing to Cloudflare
• No downtime during migration

🤖 Generated with Claude Code

To address the issue, we will add a permissions block to the workflow file. Since the workflow primarily interacts with GitHub issues (issues: write) and reads repository contents (contents: read), we will explicitly define these permissions at the root level, applying them to all jobs in the workflow unless overridden. This ensures that the GITHUB_TOKEN has the least privilege necessary to perform the intended actions.

---

To fix the issue, the untrusted input (${{ github.event.workflow_run.head_branch }}) should be safely passed through an intermediate environment variable, and the shell should use its native syntax to access the variable. This approach avoids direct interpolation and eliminates the risk of code injection. Specifically:

1. Replace ${{ github.event.workflow_run.head_branch }} in the echo command with the environment variable syntax ($BRANCH).
2. Define the environment variable BRANCH using ${{ github.event.workflow_run.head_branch }}.

To address this issue, the workflow must explicitly define minimal permissions for the GITHUB_TOKEN using the permissions key. Since the workflow does not appear to use GITHUB_TOKEN for write operations, the least privilege configuration should set contents: read. This change applies to the entire workflow to ensure all jobs inherit the minimal permissions unless overridden.

To fix the problem, add a permissions block explicitly to the root level of the workflow and/or individual jobs. This block should specify the minimal permissions required for each job's functionality. For this workflow:

• At the root level, set contents: read, as checking out the repository and running commands requires read access.
• For jobs that perform deployment or interact with pull requests (e.g., Deploy-Staging), specify additional write permissions (e.g., contents: write).

---

To fix the issue, an explicit permissions block needs to be added to the Deploy-Production job in the workflow file. This block should restrict permissions to the minimum required for the job. Since the job involves deploying to production, it likely only needs contents: read for repository access.

The fix involves:

1. Adding a permissions block to the Deploy-Production job.
2. Setting contents: read to limit repository access to read-only.

---