<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Guides :: Workspace Docs</title><link>https://samplayskeys.github.io/Workspace/guides/index.html</link><description/><generator>Hugo</generator><language>en-us</language><lastBuildDate>Sat, 01 Aug 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://samplayskeys.github.io/Workspace/guides/index.xml" rel="self" type="application/rss+xml"/><item><title>Checking OpenShift Certificates</title><link>https://samplayskeys.github.io/Workspace/guides/openshift/checking-certificates/index.html</link><pubDate>Sat, 01 Aug 2026 00:00:00 +0000</pubDate><guid>https://samplayskeys.github.io/Workspace/guides/openshift/checking-certificates/index.html</guid><description>This guide covers methods for checking the expiration dates of critical OpenShift certificates, including the API server and Ingress controller. While OpenShift typically auto-rotates most internal certificates, manually verifying them can be useful for troubleshooting and custom monitoring.&#10;Key Certificate Locations Critical certificates are stored as Kubernetes Secrets across different namespaces:</description></item><item><title>Chaining GitHub Actions Workflows Without a PAT or GitHub App</title><link>https://samplayskeys.github.io/Workspace/guides/github-actions/chaining-workflows-without-pat/index.html</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://samplayskeys.github.io/Workspace/guides/github-actions/chaining-workflows-without-pat/index.html</guid><description>How to trigger one workflow from another when you can’t (or don’t want to) use Personal Access Tokens or GitHub Apps.&#10;The Problem You have two workflows:&#10;Workflow A — Detects branches and auto-creates PRs against main Workflow B — Runs tests on PRs opened against main Manual PRs trigger Workflow B. But when Workflow A creates a PR, Workflow B never runs.</description></item><item><title>Fixing Podman Start issues with Krunkit on MacOS</title><link>https://samplayskeys.github.io/Workspace/guides/dev-environment/podman-machine-krunkit-abort-trap/index.html</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://samplayskeys.github.io/Workspace/guides/dev-environment/podman-machine-krunkit-abort-trap/index.html</guid><description>Podman on macOS can run its Linux VM through libkrun via the krunkit binary (installed from Homebrew). When required shared libraries are missing, krunkit crashes immediately and Podman reports an unhelpful abort-trap error instead of the underlying dyld failure.&#10;This guide documents the symptoms, troubleshooting steps, fix, and prevention for that failure mode.&#10;Symptoms Starting a libkrun-backed Podman machine fails:</description></item><item><title>HCL BigFix Agent Architecture Guide</title><link>https://samplayskeys.github.io/Workspace/guides/bigfix/planning/index.html</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://samplayskeys.github.io/Workspace/guides/bigfix/planning/index.html</guid><description>Overview HCL BigFix is a multi-platform endpoint management platform that enables IT operations and security teams to discover, manage, patch, and secure global IT estates. Whether operating on-premises, in the cloud, or in hybrid environments, BigFix uses a unique single-agent, hierarchical architecture to manage thousands of devices efficiently with minimal bandwidth overhead.</description></item><item><title>Installing Podman on MacOS</title><link>https://samplayskeys.github.io/Workspace/guides/dev-environment/podman-desktop-macos/index.html</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://samplayskeys.github.io/Workspace/guides/dev-environment/podman-desktop-macos/index.html</guid><description>Podman Desktop is the graphical front end for Podman on macOS. Containers do not run natively on macOS — Podman launches a lightweight Linux VM (a Podman machine) and runs containers inside it. The desktop app handles onboarding, machine management, and optional Docker compatibility so existing Docker workflows keep working.&#10;This guide covers installation, first-run setup, Docker compatibility, rootless vs rootful mode, and common gotchas — including the krunkit abort trap failure on Homebrew installs.</description></item><item><title>NVIDIA Container Toolkit &amp; CDI Setup on Proxmox GPU Passthrough VMs</title><link>https://samplayskeys.github.io/Workspace/guides/gpu/nvidia-container-toolkit-cdi-proxmox/index.html</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://samplayskeys.github.io/Workspace/guides/gpu/nvidia-container-toolkit-cdi-proxmox/index.html</guid><description>Overview NVIDIA Container Toolkit with CDI (Container Device Interface) enables Docker containers to access physical GPUs. On Proxmox VMs with GPU PCI passthrough, CDI specs must be explicitly generated and Docker must be configured to use them.&#10;Prerequisites Proxmox VM with NVIDIA GPU PCI passthrough configured (IOMMU, vfio-pci) NVIDIA driver installed and nvidia-smi working on the host Docker installed Step-by-Step 1. Install NVIDIA Container Toolkit curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list | \ sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' | \ sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list sudo apt-get update sudo apt-get install -y nvidia-container-toolkit 2. Generate CDI Specs sudo nvidia-ctk cdi generate --output=/etc/cdi/nvidia.yaml Verify the spec was created:</description></item><item><title>NVIDIA vGPU Manager: build, integrated registry, and ClusterPolicy (OpenShift Virtualization)</title><link>https://samplayskeys.github.io/Workspace/guides/openshift/nvidia-vgpu-manager-internal-registry-and-clusterpolicy/index.html</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://samplayskeys.github.io/Workspace/guides/openshift/nvidia-vgpu-manager-internal-registry-and-clusterpolicy/index.html</guid><description>This note validates a common on-cluster workflow against NVIDIA’s published steps, then records that workflow when Quay (or another external registry) is not used and images land in the integrated OpenShift image registry instead.&#10;Primary NVIDIA reference: NVIDIA GPU Operator with OpenShift Virtualization — Building the vGPU Manager image and Creating a ClusterPolicy.&#10;Related workspace guide: Using the integrated OpenShift container image registry.&#10;End-to-end workflow (integrated registry) 1. Download the vGPU Manager .run NVIDIA Licensing Portal → Software Downloads → Driver downloads → Linux KVM complete vGPU package for the Product Version you intend to support. Unzip and locate NVIDIA-Linux-x86_64-*-vgpu-kvm.run (or the AIE variant renamed per NVIDIA). 2. Clone NVIDIA’s build context and copy the installer git clone https://gitlab.com/nvidia/container-images/driver cd driver Change into the vgpu-manager subdirectory for your OS line (NVIDIA’s OpenShift example historically used vgpu-manager/rhel8; confirm the right path for your OCP / RHCOS generation):</description></item><item><title>Using the integrated OpenShift container image registry</title><link>https://samplayskeys.github.io/Workspace/guides/openshift/using-integrated-openshift-registry/index.html</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://samplayskeys.github.io/Workspace/guides/openshift/using-integrated-openshift-registry/index.html</guid><description>OpenShift ships with a cluster-internal container registry (the Image Registry Operator, namespace openshift-image-registry). You can push images there instead of an external registry (for example Quay.io), as long as workloads that need the image can pull from the namespace where the image lives.&#10;This is the same pattern NVIDIA documents for hosting built images (for example vGPU Manager) on the cluster’s own registry.&#10;What you get In-cluster pull hostname (from any pod on the cluster):&#10;image-registry.openshift-image-registry.svc:5000&#10;Full image reference:&#10;image-registry.openshift-image-registry.svc:5000/&lt;project&gt;/&lt;image&gt;:&lt;tag&gt;&#10;Example: image-registry.openshift-image-registry.svc:5000/nvidia-gpu-operator/vgpu-manager:9.0.0.0&#10;Private by default: images are not public on the internet; access is via Kubernetes RBAC and image pull credentials where needed.</description></item><item><title>VSCode Setup for Enterprise Development</title><link>https://samplayskeys.github.io/Workspace/guides/dev-environment/vscode/index.html</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://samplayskeys.github.io/Workspace/guides/dev-environment/vscode/index.html</guid><description>This guide covers setting up Visual Studio Code (VSCode) as your primary development environment on enterprise devices for working with OpenShift, Ansible, Python, YAML, and Bash.&#10;Prerequisites Before configuring VSCode, ensure the following core tools are installed on your system. While VSCode is assumed to be installed, these underlying dependencies are required for functionality.</description></item></channel></rss>