FoggyMtnDrifter

Rocky Linux: A User's Guide to Contributing

Michael Kinder — Sun, 14 Apr 2024 00:00:00 GMT

I've always been passionate about open source software. The idea of collaborative communities building powerful tools freely available to everyone resonated deeply with me. Yet, for a long time, I was just a user, a beneficiary. I'd never taken the plunge into actually contributing to an open source project.

That all changed when the CentOS landscape shifted. Like many, I was caught off guard by the news around CentOS 8. Reading Greg Kurtzer's announcement of Rocky Linux on the CentOS blog, something clicked. This was my chance to put my belief in open source into action.

With a mix of excitement and apprehension, I joined the Rocky Linux Slack (which later transitioned to Mattermost). I had zero open source contribution experience, yet I found a welcoming community eager to bring enthusiastic people on board. I started by talking to the then Web Team Lead, and soon I was making small contributions to the Rocky Linux website.

My involvement grew quickly. As my contributions increased, so did my sense of ownership in the project. Before I knew it, I was leading the Web Team, overseeing the development and maintenance of the main Rocky Linux site. It was incredibly rewarding!

I've since scaled back my involvement in that specific role, but remain integral in shaping the project's visual identity as the Design Team Lead. The thrill of helping a crucial open source project remains the same.

How You Can Make a Difference

My story isn't about being a technical genius. It's about the power of the Rocky Linux community, a community that throws its doors wide open and says, "Come build with us!" If you're intrigued by this project, here's your roadmap for getting involved:

Join the Mattermost Chat: The heart of the Rocky Linux community beats on Mattermost. Dive right in!
Explore Your Interests: Find channels that align with your skills or areas you want to learn about. Maybe you like to write; documentation is always needed. Love to design? Join me on the Design Team. If you're a developer, well, the possibilities are endless.
Let Your Voice Be Heard: Don't be shy! Introduce yourself within the channels, let people know you're interested in helping out. You'll be amazed at how quickly you'll be guided towards ways to contribute.

Open Doors, Open Community

The core of Rocky Linux is its inclusivity. Whether you're a seasoned expert, a student wanting to learn, or someone who just wants to give back to the open source world, there's a place for you.

Don't think you have to become a team lead like I did to make a difference. Every pull request reviewed, every documentation page written, every design asset created; it all matters. We're not just building an operating system; we're building a vibrant community.

What are you waiting for? Join us! You might be surprised by how much you can achieve and who you might become.

Installing Virtual Machine Manager on Void Linux

Michael Kinder — Mon, 22 Apr 2024 00:00:00 GMT

If you're a fellow Void Linux enthusiast like me, you know the thrill of a lean, customizable system. But sometimes, you might want to run other operating systems within your streamlined Void environment. That's where virtual machines (VMs) come to the rescue, and Virtual Machine Manager makes it super easy to set them up.

In this guide, I'll walk you through the steps I took to get this working.

Step 1: Installing the Essentials

sudo xbps-install libvirt virt-manager qemu polkit

This gets us all the pieces we need; libvirt for virtualization magic, virt-manager for a friendly interface, qemu as our trusty emulator, and polkit for handling permissions.

Step 2: Getting the Right Permissions

We need to make sure our regular user account can play with virtual machines. Let's add ourselves to the libvirt and kvm groups:

sudo usermod -a -G libvirt,kvm your_username

(Remember to replace your_username with your actual username.)

Step 3: A Quick Log Out and Back In

Just to be sure the group changes stick, log out of your account and log back in.

Step 4: A Tiny Bit of Configuration

Let's setup a config file for libvirt so it knows what's up:

mkdir ~/.config/libvirt && sudo cp -rv /etc/libvirt/libvirt.conf ~/.config/libvirt/ && sudo chown your_username:your_user_group ~/.config/libvirt/libvirt.conf

Step 5: Tweaking libvirt Settings

Open ~/.config/libvirt/libvirt.conf in your favorite text editor and find the line that says uri_default. Change it to:

uri_default = "qemu:///system"

Step 6: QEMU Permissions

Edit /etc/libvirt/qemu.conf, setting the user and group to match your username and libvirt respectively. This lets you manage the VMs you create.

Step 7: Starting the Services

Void Linux uses runit for services. Let's enable the ones we need:

sudo ln -s /etc/sv/dbus /var/service/
sudo ln -s /etc/sv/polkitd /var/service/
sudo ln -s /etc/sv/libvirtd /var/service/
sudo ln -s /etc/sv/virtlockd /var/service/
sudo ln -s /etc/sv/virtlogd /var/service/

Step 8: Launch Time!

That's it! Go ahead, launch Virtual Machine Manager, and get ready to spin up new virtual machines!

Bonus Tip: Pump Up the Graphics

Want smoother graphics in your VMs? Edit a VM's settings, go to "Video", select "Virtio", and check the "3D Acceleration" box.

Integrating Gitea & Vercel

Michael Kinder — Tue, 18 Jun 2024 00:00:00 GMT

I'm a strong supporter of open source software and find that the tools I choose strongly influence my development workflow. For managing my code, I use Gitea. It's a fantastic, open source version control platform that's lightweight and offers the features and security I need. One of the aspects I love is Gitea Actions, which makes it easy to streamline my deployment process to Vercel.

Why Gitea?

Gitea excels as a self-hosted, open source version control platform. If you like having flexibility and control over your development setup, it's a compelling alternative to larger, corporate-owned code hosting solutions. With Gitea Actions (which are compatible with GitHub Actions), I can tap into the rich ecosystem of Actions from the broader development community without sacrificing the benefits of an independent, open source platform.

Streamlining Deployment with Vercel

Let's talk about how I use Gitea Actions for deployment. Here's my preview.yaml workflow that enables streamlined feedback cycles. Whenever I open a pull request to the main branch, this workflow triggers a preview deployment on Vercel. This lets me test and gather feedback before merging changes:

name: Vercel Preview Deployment
env:
  VERCEL_ORG_ID: ${{ secrets.VERCEL_ORG_ID }}
  VERCEL_PROJECT_ID: ${{ secrets.VERCEL_PROJECT_ID }}

on:
  pull_request:
    branches:
      - main

jobs:
  Deploy-Preview:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - uses: actions/setup-node@v4
        with:
          node-version: ">=18.14.1"
      - name: Install Vercel CLI
        run: npm install --global vercel@latest
      - name: Pull Vercel Environment Information
        run: vercel pull --yes --environment=preview --token=${{ secrets.VERCEL_TOKEN }}
      - name: Build Project Artifacts
        run: vercel build --token=${{ secrets.VERCEL_TOKEN }}
      - name: Deploy Project Artifacts to Vercel
        id: deploy
        run: |
          echo "::group::Deploying"
          DEPLOY_OUTPUT=$(vercel deploy --prebuilt --token=${{ secrets.VERCEL_TOKEN }} 2>&1)
          echo "$DEPLOY_OUTPUT"
          echo "::endgroup::"
          PREVIEW_URL=$(echo "$DEPLOY_OUTPUT" | grep -o 'Preview: https://[1]*' | awk '{print $2}')
          echo "PREVIEW_URL=$PREVIEW_URL" >> $GITHUB_ENV
          echo "::set-output name=preview_url::$PREVIEW_URL"
          if [[ -z "$PREVIEW_URL" ]]; then exit 1; fi
        continue-on-error: false
      - name: Comment on PR on Success
        if: ${{ success() && env.PREVIEW_URL }}
        uses: actions/github-script@v5
        with:
          script: |
            const previewUrl = '${{ env.PREVIEW_URL }}';
            github.rest.issues.createComment({
              issue_number: context.payload.pull_request.number,
              owner: context.repo.owner,
              repo: context.repo.repo,
              body: `Preview deployment successful.\n\nView Preview: ${previewUrl}`
            });
      - name: Comment on PR on Error
        if: ${{ failure() }}
        uses: actions/github-script@v5
        with:
          script: |
            github.rest.issues.createComment({
              issue_number: context.payload.pull_request.number,
              owner: context.repo.owner,
              repo: context.repo.repo,
              body: 'Deployment encountered an issue. Please refer to the workflow logs for more information.'
            });

Production Deployments

Once the preview is approved, my production.yaml workflow deploys changes to my live site. It's very similar to the preview workflow, but tailored for the production environment:

name: Vercel Production Deployment
env:
  VERCEL_ORG_ID: ${{ secrets.VERCEL_ORG_ID }}
  VERCEL_PROJECT_ID: ${{ secrets.VERCEL_PROJECT_ID }}
on:
  push:
    branches:
      - main
jobs:
  Deploy-Production:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - uses: actions/setup-node@v4
        with:
          node-version: ">=18.14.1"
      - name: Install Vercel CLI
        run: npm install --global vercel@latest
      - name: Pull Vercel Environment Information
        run: vercel pull --yes --environment=production --token=${{ secrets.VERCEL_TOKEN }}
      - name: Build Project Artifacts
        run: vercel build --prod --token=${{ secrets.VERCEL_TOKEN }}
      - name: Deploy Project Artifacts to Vercel
        run: vercel deploy --prebuilt --prod --token=${{ secrets.VERCEL_TOKEN }}

Open Source in Practice

Those workflows show how I use open source tools to maintain a flexible and efficient approach to development. Gitea's adaptability and the seamless integration with GitHub Actions demonstrates the power of open source in creating custom workflows without sacrificing efficiency.

My Thoughts on This Approach

Using Gitea Actions has been a great experience for streamlining my deployment process. It highlights how open source development enables customization and the ability to tap into community resources. If you're seeking a flexible development environment that emphasizes open source principles, Gitea and Vercel make a powerful combination.

Introducing ClearProxy

Michael Kinder — Thu, 22 May 2025 00:00:00 GMT

As a long-time user of Caddy Server, I've always appreciated its simplicity, automatic HTTPS capabilities, and robust performance. However, one pain point kept nagging at me: maintaining Caddyfile configurations across multiple servers and projects. That's what led me to create ClearProxy, a modern web-based management interface for Caddy that focuses on making reverse proxy configuration as straightforward as possible.

The Journey

The idea for ClearProxy was born out of a simple desire: I wanted the power of Caddy without the hassle of manually editing configuration files. While Caddy's Caddyfile syntax is clean and intuitive, managing multiple proxy configurations across different environments can become tedious. I wanted a solution that would:

Provide a beautiful, intuitive interface for managing proxy hosts
Maintain Caddy's core philosophy of simplicity and security
Offer advanced features for power users without overwhelming beginners

Technical Implementation

I built ClearProxy using modern web technologies that prioritize performance and developer experience:

SvelteKit for the frontend, offering a responsive and snappy user interface
SQLite for reliable data storage without the complexity of a separate database server
Docker for easy deployment and consistent environments
Caddy's Admin API for seamless integration with the Caddy server

The architecture is deliberately simple: two containers working in harmony - one running the ClearProxy application and another running Caddy server. This setup ensures that users get all the benefits of Caddy (automatic HTTPS, modern security defaults) while enjoying a user-friendly management interface.

Key Features

Some of the features I'm most proud of include:

Intuitive Proxy Management: Add and configure proxy hosts with just a few clicks
Automatic HTTPS: Leveraging Caddy's built-in ACME client for SSL/TLS certificates
Basic Authentication: Easily secure proxied hosts when needed
Advanced Configuration: Raw Caddyfile syntax support for power users
Access Logging: Built-in monitoring capabilities

The Rewards

Building ClearProxy has been incredibly rewarding for a couple reasons:

Learning Experiences: The project pushed me to dive deep into Caddy's internals, modern web development practices, and container orchestration. Every challenge was an opportunity to learn something new.
Open Source Collaboration: The project is open source, and I'm hoping and looking forward to collaborating with other developers to make it better.

Looking Forward

ClearProxy is more than just a personal tool - it's becoming a project that makes Caddy more accesible to everyone. Future plans include:

Enhanced monitoring and analytics
Support for more advanced Caddy features
Improved documentation and tutorials
Community-requested features and improvements

Try It Yourself

If you're using Caddy and want to simplify your proxy management, give ClearProxy a try. The project is available on GitHub, and getting started is as simple as running a few Docker commands.

mkdir clearproxy && cd clearproxy
curl -L https://raw.githubusercontent.com/foggymtndrifter/clearproxy/main/docker-compose.yml -o docker-compose.yml
docker compose up -d

Conclusion

Building ClearProxy has been a journey of solving a personal pain point that turned into something much bigger. It's a testament to the power of open source and the satisfaction that comes from creating tools that make developers' lives easier. If you're using Caddy or looking for a more modern reverse proxy solution, I encourage you to give ClearProxy a try and join our community.

Building a Custom Comment System with GitHub Discussions

Michael Kinder — Thu, 29 Jan 2026 00:00:00 GMT

I recently decided to replace Giscus on my blog with a custom-built comment system. While Giscus is fantastic, I wanted more control over the user experience and the ability to support guest comments without requiring GitHub authentication. Here's how I built it.

The Goal

I wanted a comment system that:

Uses GitHub Discussions as the backend (free, reliable, and I already use GitHub)
Supports both authenticated GitHub users and anonymous guests
Has a clean UI that matches my site's aesthetic
Includes basic spam protection (honeypot + CAPTCHA)
Sorts comments newest-first

The Architecture

The system has three main components:

Backend API routes (Astro SSR endpoints)
Frontend component (Svelte for reactivity)
OAuth flow (GitHub authentication)

Backend: API Routes

I created several API routes in src/pages/api/:

`/api/comments/[slug].ts`

This is the workhorse. It handles both fetching and posting comments.

GET: Fetches all comments for a post by searching GitHub Discussions for a discussion matching the post's pathname.

const searchQuery = `repo:${siteConfig.comments.repo} in:title ${term}`
const result = await octokit.graphql(query, { term: searchQuery })

The key insight here: GitHub's search API is powerful. By searching for discussions with the post's pathname in the title, I can reliably find the right discussion.

POST: Creates a new comment. This is where it gets interesting:

If the user is authenticated (has a GitHub token cookie), post as them
If not, post as a bot account and append _(Posted by DisplayName)_ to the comment body
The GET endpoint strips this attribution and uses it to display the guest's name

OAuth Routes

Three simple routes handle GitHub authentication:

/api/auth/signin - Redirects to GitHub OAuth
/api/auth/callback - Exchanges code for token, stores in HTTP-only cookie
/api/auth/signout - Clears the token cookie

Frontend: Svelte Component

I chose Svelte for the comment UI because it's lightweight and has excellent reactivity. The component handles:

Displaying comments with proper nesting (replies)
A collapsible comment form
Switching between "Post as Guest" and "Sign in with GitHub" modes
Client-side CAPTCHA validation for guests

{#if authMode === 'guest' && !user}
  <div>
    <label for="captcha">Human Check: What is {num1} + {num2}?</label>
    <input id="captcha" type="number" bind:value={captchaAnswer} required />
  </div>
{/if}

Guest Comments: The Attribution Trick

The clever part about guest comments is how they're stored. Since GitHub Discussions doesn't natively support "guest" authors, I:

Post the comment using a bot account
Append the guest's display name in a specific format: _(Posted by Jane Doe)_
On fetch, parse this attribution and transform the comment object
Strip the attribution from the HTML before displaying

This means the comment lives in GitHub Discussions, but appears to be from the guest user in my UI.

Spam Protection

I implemented two layers of protection:

Honeypot

A hidden field that bots might fill but humans won't:

<input type="text" name="website_honey" class="hidden" bind:value={honeyPot} />

If this field has a value, the submission is rejected.

Math CAPTCHA

For guest comments only, a simple math question:

if (!userToken) {
  if (parseInt(num1) + parseInt(num2) !== parseInt(answer)) {
    return new Response('Incorrect math answer', { status: 400 })
  }
}

It's basic, but effective against simple bots without annoying users with complex CAPTCHAs.

UI Polish

I spent time making the UI feel native to my site:

Generic avatars for guests (using DiceBear's initials API)
Changed "OWNER" badge to "ADMIN"
Newest-first sorting (reversed the GitHub API response)
Collapsible form (using native <details> element)
Matched the styling to my "Buy me a coffee" modal

Configuration

The system is configured in site.config.ts:

comments: {
  repo: 'FoggyMtnDrifter/website',
  repoId: 'R_kgDORBPuRw',
  category: 'General',
  categoryId: 'DIC_kwDORBPuR84C1bYd',
}

You'll also need environment variables:

GITHUB_CLIENT_ID=your_oauth_app_client_id
GITHUB_CLIENT_SECRET=your_oauth_app_secret
GITHUB_PERSONAL_ACCESS_TOKEN=your_bot_token

Lessons Learned

GitHub's GraphQL API is powerful - The search query approach works better than trying to filter discussions directly
HTTP-only cookies are your friend - Storing OAuth tokens securely is critical
Simple spam protection works - You don't need reCAPTCHA for a personal blog
Native HTML is underrated - Using <details> for the collapsible form meant zero JavaScript for that feature

The Result

I now have a comment system that:

Costs nothing (uses GitHub's free tier)
Supports both authenticated and guest users
Matches my site's aesthetic perfectly
Has basic spam protection
Gives me full control over the UX

The best part? All comments are stored in GitHub Discussions, so they're backed up, searchable, and I can manage them using GitHub's excellent moderation tools.

If you're building an Astro site and want more control than Giscus provides, this approach is definitely worth considering. The code is all on my GitHub repo if you want to dig deeper.