DevOps on Yarang's Tech Lair

Building a Blog AI Auto-Comment System (3/3): Deployment and Troubleshooting

Sun, 03 May 2026 01:20:00 +0900


## Overview

In [Part 1](/ko/post/ai-auto-comment-system-part1-architecture/), we covered the architecture and implementation, and in [Part 2](/ko/post/ai-auto-comment-system-part2-security/), we looked at security enhancements. In this 3rd part, we record the process of deploying to an actual OCI ARM server and the troubleshooting encountered.

In particular, we share in detail the actual debugging process where we tracked and resolved the issue of **GITHUB_TOKEN not loading** over 4 steps. The core of this article is how we narrowed down the cause in a situation where "it's set up, so why isn't it working?"

---

## Infrastructure Configuration

### Server Configuration

| Server | Role | Specs |
|------|------|------|
| ec1 (x86) | Web Server (nginx, Hugo blog) | OCI |
| arm1 (ARM) | Worker Server (Flask, Claude Code) | OCI ARM |

The blog is built and served with Hugo on ec1, while the AI comment worker runs on arm1. The GitHub Webhook is delivered directly to arm1.

### Worker Server Directory Structure

/var/www/auto-comment-worker/ # Application ├── scripts/ │ └── auto-comment-worker.py ├── deploy/ │ └── auto-comment-worker.service ├── venv/ # Python virtual environment └── logs/

/etc/auto-comment-worker/ # Credentials ├── github-token # 640, ubuntu:ubuntu └── credentials/ └── webhook-secret # 600, ubuntu:ubuntu

/home/ubuntu/.local/bin/claude # Claude Code CLI


---

## systemd Service Configuration

### Service File

```ini
[Unit]
Description=Auto Comment Worker for Blog
After=network.target

[Service]
Type=simple
User=ubuntu
WorkingDirectory=/var/www/auto-comment-worker
Environment=PORT=8081
Environment=CLAUDE_CODE_PATH=/home/ubuntu/.local/bin/claude
Environment=BLOG_OWNERS=yarang
Environment=GITHUB_TOKEN_FILE=/etc/auto-comment-worker/github-token
Environment=GITHUB_WEBHOOK_SECRET_FILE=/etc/auto-comment-worker/credentials/webhook-secret
ExecStart=/var/www/auto-comment-worker/venv/bin/python /var/www/auto-comment-worker/scripts/auto-comment-worker.py
Restart=always
RestartSec=10

# Logging
StandardOutput=journal
StandardError=journal
SyslogIdentifier=auto-comment-worker

# Security
NoNewPrivileges=true
PrivateTmp=true
ProtectSystem=strict
ProtectHome=false
ReadWritePaths=/var/www/auto-comment-worker /var/log/auto-comment-worker
ReadOnlyPaths=

# Resource Limits
MemoryMax=512M
CPUQuota=50%
TasksMax=100

[Install]
WantedBy=multi-user.target

Key Configuration Explanation

Type=simple: Since the Flask worker runs in the foreground, simple is appropriate. forking is used for processes that daemonize.

User=ubuntu: Although a dedicated service account could be created, it runs as ubuntu because the Claude Code CLI depends on the ubuntu user’s home directory configuration.

ProtectHome=false: Usually set to true, but allows home directory access because Claude Code requires the ~/.agent_forge_for_zai.json configuration file.

ReadOnlyPaths= (Empty value): Initially specified /etc/auto-comment-worker, but left empty due to conflict with ProtectSystem=strict.

Service Management Commands

# Copy service file
sudo cp deploy/auto-comment-worker.service /etc/systemd/system/

# Register and start service
sudo systemctl daemon-reload
sudo systemctl enable auto-comment-worker
sudo systemctl start auto-comment-worker

# Check status
sudo systemctl status auto-comment-worker

# Check logs (real-time)
sudo journalctl -u auto-comment-worker -f

# Check recent logs
sudo journalctl -u auto-comment-worker --since "10 minutes ago"

nginx Reverse Proxy

Webhook Endpoint Configuration

server {
 listen 443 ssl;
 server_name your-domain.com;

 # SSL Configuration
 ssl_certificate /etc/letsencrypt/live/your-domain.com/fullchain.pem;
 ssl_certificate_key /etc/letsencrypt/live/your-domain.com/privkey.pem;

 # Webhook Proxy
 location /webhook {
 proxy_pass http://localhost:8081;
 proxy_set_header Host $host;
 proxy_set_header X-Real-IP $remote_addr;
 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
 proxy_set_header X-Forwarded-Proto $scheme;

 # GitHub Webhook signature header forwarding (Required!)
 proxy_set_header X-Hub-Signature-256 $http_x_hub_signature_256;

 # Timeout (Waiting for Claude Code response)
 proxy_read_timeout 120s;
 proxy_connect_timeout 10s;
 }

 # Health check
 location /health {
 proxy_pass http://localhost:8081;
 }
}

proxy_read_timeout 120s is set generously because the Claude Code CLI can take up to 60 seconds to generate an AI response. Since the default timeout for GitHub Webhooks is 10 seconds, asynchronous processing could be considered in practice.

Deployment Process

Manual Deployment (After rsync Failure)

Initially, we attempted deployment with rsync, but it failed because the target directory did not exist on the server:

rsync: [Receiver] mkdir "/var/www/auto-comment-worker/scripts" failed:
No such file or directory

As an alternative, we proceeded with scp-based manual deployment:

# 1. Create directory on server
ssh ubuntu@arm1 "sudo mkdir -p /var/www/auto-comment-worker/scripts"
ssh ubuntu@arm1 "sudo chown -R ubuntu:ubuntu /var/www/auto-comment-worker"

# 2. Transfer files
scp scripts/auto-comment-worker.py ubuntu@arm1:/var/www/auto-comment-worker/scripts/
scp deploy/auto-comment-worker.service ubuntu@arm1:/tmp/

# 3. Install service file
ssh ubuntu@arm1 "sudo cp /tmp/auto-comment-worker.service /etc/systemd/system/"

# 4. Set up Python virtual environment
ssh ubuntu@arm1 "cd /var/www/auto-comment-worker && python3 -m venv venv"
ssh ubuntu@arm1 "cd /var/www/auto-comment-worker && venv/bin/pip install flask flask-limiter marshmallow requests"

# 5. Configure authentication files
ssh ubuntu@arm1 "sudo mkdir -p /etc/auto-comment-worker/credentials"
# Token file is created directly on the server (not transferred via scp)

# 6. Start service
ssh ubuntu@arm1 "sudo systemctl daemon-reload && sudo systemctl enable --now auto-comment-worker"

Heredoc Variable Expansion Pitfall

A common mistake when writing installation scripts with heredoc:

# Single quotes: Variables are NOT expanded!
ssh ubuntu@arm1 << 'ENDSSH'
echo $CREDENTIALS_DIR # Prints empty string
ENDSSH

# No quotes: Variables are expanded locally
ssh ubuntu@arm1 << ENDSSH
echo $CREDENTIALS_DIR # Expanded to local variable value
ENDSSH

To avoid this problem, we switched to executing commands individually instead of using a script.

Troubleshooting: GITHUB_TOKEN Loading Failure

This was the issue that consumed the most time while deploying this system. When the comment Webhook arrived, the following error repeated:

INFO:__main__:GITHUB_TOKEN configured: False
INFO:__main__:GitHub API response status: 401
ERROR:__main__:Failed to get Discussion GraphQL ID

We record the process of tracking down the cause step by step.

Step 1: LoadCredential Path Issue

Initially, we used the LoadCredential directive in systemd:

LoadCredential=github-token:/etc/auto-comment-worker/github-token
Environment=GITHUB_TOKEN_FILE=%d/github-token

%d is a systemd special variable replaced with the credentials directory path. However, this variable was not interpreted as intended, causing the token file path to be set incorrectly.

Solution: Instead of LoadCredential, we specified the absolute path directly.

Environment=GITHUB_TOKEN_FILE=/etc/auto-comment-worker/github-token

Step 2: File Ownership Issue

GITHUB_TOKEN configured: False still appeared. Checking the file revealed:

$ ls -la /etc/auto-comment-worker/github-token
-rw------- 1 root root 93 May 3 01:10 github-token

Since the file owner is root and permissions are 600, the service running as the ubuntu user cannot read this file.

Solution:

sudo chown ubuntu:ubuntu /etc/auto-comment-worker/github-token
sudo chmod 640 /etc/auto-comment-worker/github-token

Step 3: ReadOnlyPaths Conflict

Even after changing ownership, GITHUB_TOKEN configured: False persisted. The cause was the ReadOnlyPaths setting in the systemd service file:

# This setting blocked file reading
ReadOnlyPaths=/etc/auto-comment-worker

ProtectSystem=strict already mounts the entire filesystem read-only. Adding ReadOnlyPaths on top of that can cause mount namespace conflicts in some environments.

Solution: Changed ReadOnlyPaths to an empty value.

ReadOnlyPaths=

Step 4: Python File Permission Validation Code (Root Cause)

Even after resolving all previous 3 steps, the token still did not load. The final cause was the overly strict file permission validation in the Python code:

# File permission 640 → Group read bit (0o040) is set → Denied!
if st.st_mode & (stat.S_IRWXO | stat.S_IRWXG):
 raise PermissionError("Token file must be 600 or 400")

Because we changed to chmod 640 in Step 2, the group read bit was set, triggering this validation. However, the error message did not appear in the logs, delaying discovery — because the PermissionError occurred at the module import time, preventing the service from starting at all.

Solution: As explained in Part 2, we modified it to check only stat.S_IWOTH.

Importance of Debugging Logs

The debugging logs added to track this issue:

logger.info(f"GITHUB_TOKEN configured: {bool(GITHUB_TOKEN)}")
logger.info(f"GitHub API response status: {response.status_code}")
logger.info(f"GitHub API response body: {response.text[:500]}")

Without these logs, it would have taken much longer to identify the cause. Always log token load success/failure and API response status for authentication-related code.

Debugging Flow Summary

[1] LoadCredential %d not interpreted → Changed to absolute path
 ↓ (Still failed)
[2] File owner root:root → Changed to ubuntu:ubuntu
 ↓ (Still failed)
[3] ReadOnlyPaths conflict → Removed
 ↓ (Still failed)
[4] Python permission check S_IRWXG → Relaxed to S_IWOTH
 ↓
 [Resolved!]

Lessons learned from this 4-step debugging:

Change one at a time and verify: If you change multiple settings at once, you won’t know which one is the cause.
Trust logs, but suspect where there are no logs: Exceptions at module load time may not appear in standard logs.
Security validation code can also be a source of bugs: When security code blocks normal operation — balancing security and operations.

Health Check

A health check endpoint to verify the service is running correctly:

@app.route('/health', methods=['GET'])
def health():
 """Health check"""
 return jsonify({'status': 'healthy'})

Monitoring systems periodically call /health to verify the service status:

curl -s http://localhost:8081/health
# {"status": "healthy"}

Future Improvements

Asynchronous Processing: Asynchronize AI response generation using Celery or Redis Queue to respond within the GitHub Webhook timeout (10 seconds).
Retry Logic: Exponential backoff retry on GitHub API call failures.
Monitoring Dashboard: Monitor response time, success rate, and error rate with Prometheus + Grafana.
Automated Deployment: Build an automated deployment pipeline with GitHub Actions on code changes.
Testing: Write integration tests mocking Webhook payloads.

Conclusion

Over three parts, we have recorded the entire build process of the blog AI auto-comment system:

Part 1: Full architecture of giscus → GitHub Webhook → Flask → Claude Code → GraphQL
Part 2: File-based authentication, HMAC verification, input sanitization, systemd security
Part 3: Actual deployment, nginx proxy, 4-step debugging process

The greatest value of this system is that it automates communication with blog readers. While it is difficult for blog operators to respond to every comment immediately, an AI assistant can provide a first response, improving the reader experience.

The full code is available at the GitHub repository.

This article is Part 3 (the final part) of the AgentForge blog auto-comment system series.

Building a Blog AI Auto-Comment System (2/3) — Security Hardening

Sun, 03 May 2026 01:10:00 +0900

Overview

In Part 1, we covered the architecture and implementation of the AI auto-comment system. In this Part 2, we will focus on security aspects.

Systems that receive external Webhooks, manage GitHub API tokens, and process user input require special attention to security. We will explain the process of switching from environment variables to file-based authentication, the reasons behind it, and the design of each security layer.

Security Threat Model

Threats that this system must defend against:

Threat	Attack Vector	Defense
Spoofed Webhook	Attacker sends fake Webhook	HMAC-SHA256 signature verification
Token Leak	Environment variable exposure, log exposure	File-based authentication + permission restrictions
XSS/Injection	Malicious comment content	Input sanitization
Excessive Requests	DDoS, abuse	Flask-Limiter rate limiting
Privilege Escalation	Worker process compromise	systemd security directives
Infinite Loop	AI responding to itself	Marker-based comment detection

File-Based Authentication Management

Problems with Environment Variables

Initially, we managed GitHub tokens and Webhook secrets as environment variables:

# Initial (unsafe)
Environment=GITHUB_TOKEN=ghp_xxxxx
Environment=GITHUB_WEBHOOK_SECRET=my-secret-key

Problems with the environment variable approach:

/proc/PID/environ: Process environment variables are exposed as a file in Linux
Log exposure: Risk of environment variables being logged during debugging
Child process inheritance: When running Claude Code with subprocess.run, all environment variables are inherited
systemd configuration file: If the service file contains plaintext secrets, there is a risk of committing them to git

Switching to File-Based

Store credentials in the file system and specify only file paths in environment variables:

# Improved — only path exposed
Environment=GITHUB_TOKEN_FILE=/etc/auto-comment-worker/github-token
Environment=GITHUB_WEBHOOK_SECRET_FILE=/etc/auto-comment-worker/credentials/webhook-secret

Directory structure of the server:

/etc/auto-comment-worker/
├── github-token # GitHub Personal Access Token (640)
└── credentials/
 └── webhook-secret # GitHub Webhook HMAC Secret (600)

Token File Loading Code

import stat

GITHUB_TOKEN_FILE = os.environ.get('GITHUB_TOKEN_FILE', '')
if GITHUB_TOKEN_FILE and os.path.exists(GITHUB_TOKEN_FILE):
 # Check file permissions
 st = os.stat(GITHUB_TOKEN_FILE)
 if st.st_mode & stat.S_IWOTH:
 raise PermissionError("Token file must not be world-writable")
 with open(GITHUB_TOKEN_FILE, 'r') as f:
 GITHUB_TOKEN = f.read().strip()
else:
 GITHUB_TOKEN = os.environ.get('GITHUB_TOKEN', '')

Core design decisions:

Prefer file if it exists: Environment variables are used only as a fallback
Permission verification: Check permissions before reading the file
strip(): Remove newline characters at the end of the file

File Permission Validation — A Trial and Error Journey

I spent the most time on this part. The initial code was too strict:

# Initial code — too strict
if st.st_mode & (stat.S_IRWXO | stat.S_IRWXG):
 raise PermissionError("Token file must be 600 or 400")

Problem with this code: S_IRWXO | S_IRWXG checks all group permissions (read/write/execute) and all other permissions. That is, if the file permission is 640 (owner read/write, group read), it is rejected.

# Bit mask analysis
S_IRWXG = 0o070 # Group read+write+execute
S_IRWXO = 0o007 # Other read+write+execute

# 640 = 0o640
0o640 & (0o070 | 0o007) = 0o640 & 0o077 = 0o040 # Not 0 → Rejected!

For actual security, what matters is that other users cannot modify the file. Group read permission allows users in the same group to read the file and is not a security issue.

After revision:

# After revision — focus on actual threat
if st.st_mode & stat.S_IWOTH:
 raise PermissionError("Token file must not be world-writable")

You only need to check stat.S_IWOTH (0o002). This confirms only “Does it have write permission for others?”.

Permission	Octal	Initial Code	After Revision
`600`	`0o600`	Allowed	Allowed
`640`	`0o640`	Rejected	Allowed
`644`	`0o644`	Rejected	Allowed
`646`	`0o646`	Rejected	Rejected
`666`	`0o666`	Rejected	Rejected

HMAC-SHA256 Signature Verification

GitHub Webhook sends a signature created by HMAC-SHA256 hashing the request body with the Webhook secret in the X-Hub-Signature-256 header. We verify this to confirm that the request actually came from GitHub.

def verify_webhook_signature(payload: bytes, signature: str) -> bool:
 """GitHub webhook signature verification"""
 if not signature:
 logger.warning("Missing webhook signature")
 return False

 if not WEBHOOK_SECRET:
 logger.warning("WEBHOOK_SECRET not configured - skipping validation")
 return True # Allow for development mode

 try:
 hash_algorithm, github_signature = signature.split('=', 1)
 if hash_algorithm != 'sha256':
 return False

 mac = hmac.new(
 WEBHOOK_SECRET.encode(),
 msg=payload,
 digestmod=hashlib.sha256
 )
 expected_signature = mac.hexdigest()

 # Prevent timing attacks
 if not hmac.compare_digest(expected_signature, github_signature):
 return False

 return True
 except Exception as e:
 logger.error(f"Signature verification error: {e}")
 return False

Key points:

hmac.compare_digest(): Uses constant-time comparison instead of normal == comparison to prevent timing attacks.
raw bytes usage: Uses request.data (original bytes). If parsed with request.json and re-serialized, it may differ from the original.
Development mode: Skips validation if the secret is not set. The secret must be set in production.

nginx Header Forwarding

For signature verification to work properly, nginx must forward the X-Hub-Signature-256 header:

location /webhook {
 proxy_pass http://localhost:8081;
 proxy_set_header Host $host;
 proxy_set_header X-Real-IP $remote_addr;
 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
 proxy_set_header X-Hub-Signature-256 $http_x_hub_signature_256;
}

Unless X-Hub-Signature-256 is explicitly forwarded, custom headers may not be passed with just the default proxy_pass.

Request Validation (marshmallow Schema)

Validate the structure of the Webhook payload using a marshmallow schema:

class WebhookSchema(Schema):
 action = fields.Str(required=True, validate=validate.Equal('created'))
 comment = fields.Dict(required=True)
 discussion = fields.Dict(required=True)
 repository = fields.Dict(required=True)
 sender = fields.Dict(required=False)

action = 'created' only: Rejects comment edit (edited) or delete (deleted) events.
Required field validation: Returns 400 error if comment, discussion, repository are missing.
ValidationError → Audit log: Invalid requests are logged in the audit log.

Input Sanitization

User comments are external input, so they must be processed:

def sanitize_comment(body: str) -> str:
 """User input sanitization"""
 body = re.sub(r'<[^>]+>', '', body) # Remove HTML tags
 body = html.escape(body) # Escape special characters
 body = body[:1000] # Length limit
 return body

Where this sanitization is applied:

Comment body (comment_body)
Discussion title and body (discussion_title, discussion_body)
Original author name (original_author)
Quoted part when posting AI response

Username Masking

We do not log the full username:

def mask_username(username: str) -> str:
 """Username masking"""
 if not username or len(username) < 4:
 return "***"
 return f"{username[:3]}***"

Logs will only display masked names like yar***. This strikes a balance between privacy protection and debugging convenience.

Rate Limiting

Apply rate limiting per endpoint using Flask-Limiter:

limiter = Limiter(
 app=app,
 key_func=get_remote_address,
 default_limits=["10 per minute"],
 storage_uri="memory://"
)

@app.route('/webhook', methods=['POST'])
@limiter.limit("10 per minute")
def github_webhook():
 ...

10 requests per minute limit: A figure considering normal Webhook call frequency
get_remote_address: Limits based on client IP
memory://: In-memory storage (suitable for single process)

systemd Security Directives

Part 3 will cover systemd deployment in detail, but security-related directives are explained here:

[Service]
# Security hardening
NoNewPrivileges=true # Prevent privilege escalation
PrivateTmp=true # Provide isolated /tmp
ProtectSystem=strict # Read-only file system
ProtectHome=false # Allow home directory access (for Claude Code config)
ReadWritePaths=/var/www/auto-comment-worker /var/log/auto-comment-worker

# Resource limits
MemoryMax=512M # Memory limit
CPUQuota=50% # CPU usage limit
TasksMax=100 # Process count limit

Directive	Effect
`NoNewPrivileges=true`	Privilege escalation via `setuid`, `setgid`, etc. is impossible
`PrivateTmp=true`	Isolated `/tmp` namespace, separated from other processes
`ProtectSystem=strict`	Mounts entire file system as read-only
`ReadWritePaths`	Specifies only paths allowed for writing
`MemoryMax=512M`	Protects the entire system in OOM situations

Conflict between ProtectSystem=strict and ReadOnlyPaths

Initially, adding ReadOnlyPaths=/etc/auto-comment-worker caused an issue where the token file could not be read. Since ProtectSystem=strict already sets the entire file system to read-only, a separate ReadOnlyPaths is unnecessary. It was removed because it could cause conflicts in some environments.

Conclusion

In this Part 2, we covered file-based authentication management, the file permission validation journey, HMAC-SHA256 signature verification, input sanitization, rate limiting, and systemd security directives.

The most important lesson in security: “Too strict validation is as harmful as too loose validation.” The initial code, which only allowed 600 permissions, was secure, but in the actual operating environment, it rejected files with 640 permissions, preventing the service from starting. Focusing only on actual threats (world-writable) is the correct approach.

In the next Part 3, we will cover Deployment and Troubleshooting — systemd service configuration, nginx reverse proxy, and errors actually encountered and the resolution process.

This post is Part 2 of the AgentForge blog automatic comment system series.

Building a Blog AI Auto-Comment System (1/3) — Architecture and Implementation

Sun, 03 May 2026 01:00:00 +0900

Overview

I built a system where AI automatically responds to blog comments. When a reader leaves a comment on a blog post, the AI assistant analyzes the post context and automatically generates a technically accurate yet friendly reply.

This series consists of three parts:

Part 1 (This post): Overall architecture design and core code implementation
Part 2: File-based authentication, permission management, security hardening
Part 3: systemd deployment, nginx proxy, troubleshooting

System Architecture

Overall Data Flow

Reader writes a comment
 ↓
[giscus] → Creates a comment on GitHub Discussions
 ↓
[GitHub Webhook] → Sends HTTP POST
 ↓
[nginx reverse proxy] → Header forwarding
 ↓
[Flask Worker] → Signature verification → Comment analysis
 ↓
[Claude Code CLI] → Generates AI response
 ↓
[GitHub GraphQL API] → Posts reply to Discussion
 ↓
[giscus] → Displays reply on blog

The key point in this architecture is that giscus uses GitHub Discussions as a comment storage. Therefore, we can receive new comment events via GitHub Webhook and post responses using the same GitHub API.

Components

Component	Role	Technology
giscus	Blog comment widget	Based on GitHub Discussions
GitHub Webhook	Event delivery	`discussion_comment` event
nginx	Reverse proxy	Header forwarding, SSL termination
Flask Worker	Webhook receiving and processing	Python, Flask, Flask-Limiter
Claude Code	AI response generation	`--print` mode CLI call
GitHub GraphQL	Response posting	Mutation API

giscus Configuration

To integrate giscus into a Hugo blog, the following configuration is required in hugo.toml:

[params]
 [params.comments]
 enabled = true
 provider = "giscus"
 [params.comments.giscus]
 repo = "yarang/blogs"
 repoId = "YOUR_REPO_ID"
 category = "General"
 categoryId = "YOUR_CATEGORY_ID"
 mapping = "pathname"
 strict = "0"
 reactionsEnabled = "1"
 emitMetadata = "0"
 inputPosition = "bottom"
 lang = "ko"
 theme = "noborder_gray"

mapping = "pathname" maps Discussions based on the post URL path. This creates an independent Discussion for each blog post.

GitHub Webhook Configuration

In the GitHub repository Settings > Webhooks:

Payload URL: https://your-domain/webhook
Content type: application/json
Secret: Secret for HMAC-SHA256 signature (covered in detail in the security post)
Events: Select Discussion comments

The Webhook sends a discussion_comment event to the Flask worker whenever a comment is created.

Flask Worker Implementation

Project Structure

auto-comment-worker/
├── scripts/
│ └── auto-comment-worker.py # Main worker
├── deploy/
│ └── auto-comment-worker.service # systemd service
├── venv/ # Python virtual environment
└── logs/
 └── audit.log # Audit log

Core Dependencies

from flask import Flask, request, jsonify
from flask_limiter import Limiter
from flask_limiter.util import get_remote_address
from marshmallow import Schema, fields, validate, ValidationError

Flask: Provides Webhook endpoints as a lightweight web framework
Flask-Limiter: Prevents abuse with rate limiting (10 times per minute)
marshmallow: Safe data parsing via request schema validation

Webhook Endpoint

@app.route('/webhook', methods=['POST'])
@limiter.limit("10 per minute")
def github_webhook():
 """Receives GitHub Webhook"""
 # 1. Signature verification
 signature = request.headers.get('X-Hub-Signature-256')
 if not verify_webhook_signature(request.data, signature):
 log_audit('SIGNATURE_INVALID', {'ip': request.remote_addr})
 return jsonify({'status': 'unauthorized'}), 401

 # 2. Request schema validation
 schema = WebhookSchema()
 try:
 payload = schema.load(request.json)
 except ValidationError as err:
 return jsonify({'status': 'invalid'}), 400

 # 3. Extract and filter comment information
 comment = payload.get('comment', {})
 discussion = payload.get('discussion', {})
 original_author = comment.get('user', {}).get('login', 'User')

 # Ignore if it's the blog owner's comment
 if _is_blog_owner(original_author):
 return jsonify({'status': 'owner_comment_ignored'}), 200

 # Ignore if AI generated comment (prevent infinite loop)
 if _is_ai_generated_comment(comment.get('body', '')):
 return jsonify({'status': 'ai_comment_ignored'}), 200

 # 4. Generate and post AI response
 discussion_graphql_id = get_discussion_graphql_id(
 repo_owner, repo_name, discussion_number
 )
 context = f"Title: {discussion_title}\n\nContent: {discussion_body}"
 reply = analyze_comment(context, comment_body)
 post_reply_graphql(discussion_graphql_id, comment_body, original_author, reply)

The core flow consists of 4 steps:

Signature verification: Verifies if the request came from GitHub using HMAC-SHA256
Schema validation: Validates payload structure with marshmallow
Filtering: Ignores comments from the blog owner and the AI itself (prevents infinite loops)
Response: Generates AI response with Claude Code and posts via GraphQL API

Preventing Infinite Loops

If AI responds to a comment created by AI, it will fall into an infinite loop. To prevent this, we use marker-based detection:

def _is_ai_generated_comment(body: str) -> bool:
 """Identifies if the comment was generated by AI"""
 ai_markers = [
 '🤖 AI Assistant',
 'AI Assistant',
 'AgentForge',
 'Automatically generated by Claude Code',
 'was automatically generated'
 ]
 body_lower = body.lower()
 return any(marker.lower() in body_lower for marker in ai_markers)

When posting the AI response, you must include one of these markers in the body:

body = f"""---
**🤖 AI Assistant**

{safe_reply}

*This comment was automatically generated by AgentForge + Claude Code.*
---
"""

Calling Claude Code CLI

Use Claude Code’s --print mode to generate an AI response non-interactively:

def analyze_comment(context: str, comment: str) -> str:
 """Run Claude Code with AgentForge settings"""
 prompt = f"""## Blog Post Context
{context[:2000]}

## Reader Comment
{comment}

Please write a response to this comment.
- As a technical blog assistant, be professional yet friendly
- Concise within 200 characters
- Provide additional info or links if needed
"""

 cmd = [
 CLAUDE_CODE_PATH,
 '--settings', AGENTFORGE_CONFIG,
 '--print', prompt
 ]

 result = run(cmd, capture_output=True, text=True, timeout=60)

 if result.returncode == 0 and result.stdout.strip():
 return result.stdout.strip()

 return "Thanks for your opinion! I think it would be great to discuss the technical aspects further. 🙏"

Specify the AgentForge dedicated configuration file with the --settings flag. You can manage the model, token limits, etc. in this configuration file.

The --print flag runs Claude Code in non-interactive mode and outputs the result to stdout. Unlike interactive mode, it terminates after a single prompt-response.

GitHub GraphQL API Integration

Since giscus uses GitHub Discussions, the response must also be posted via the GitHub GraphQL API.

Retrieve Discussion GraphQL ID:

def get_discussion_graphql_id(repo_owner, repo_name, discussion_number):
 query = """
 query($owner: String!, $name: String!, $number: Int!) {
 repository(owner: $owner, name: $name) {
 discussion(number: $number) {
 id
 }
 }
 }
 """
 variables = {
 "owner": repo_owner,
 "name": repo_name,
 "number": discussion_number
 }

 response = requests.post(
 GITHUB_API_URL,
 json={"query": query, "variables": variables},
 headers={
 "Authorization": f"Bearer {GITHUB_TOKEN}",
 "Content-Type": "application/json"
 },
 timeout=10
 )

 if response.status_code == 200:
 data = response.json()
 return data["data"]["repository"]["discussion"]["id"]
 return None

The Webhook payload only includes the Discussion’s REST API ID. However, to post a comment, the GraphQL Node ID is required. Therefore, we first retrieve the Discussion’s Node ID via a GraphQL query, then use it to post the comment.

Post Response (Mutation):

def post_reply_graphql(discussion_graphql_id, original_comment, original_author, reply):
 query = """
 mutation($discussionId: ID!, $body: String!) {
 addDiscussionComment(input: {
 discussionId: $discussionId, body: $body
 }) {
 comment { id, databaseId }
 }
 }
 """
 # ... (Send request)

The addDiscussionComment mutation adds a new comment to the entire Discussion. It is a Discussion-level comment, not a reply to a specific comment.

Input Sanitization

Since user comments are external input, they must be sanitized:

def sanitize_comment(body: str) -> str:
 """User input sanitization"""
 if not body:
 return body
 body = re.sub(r'<[^>]+>', '', body) # Remove HTML tags
 body = html.escape(body) # Escape HTML entities
 body = body[:1000] # Length limit
 return body

To prevent XSS attacks, HTML tags are removed, remaining special characters are escaped, and the length is limited to 1000 characters.

Audit Logging

We keep audit logs to track security events:

def log_audit(event_type: str, details: dict):
 """Record security event audit log"""
 with open(AUDIT_LOG, 'a') as f:
 f.write(json.dumps({
 'timestamp': datetime.utcnow().isoformat(),
 'event': event_type,
 'details': details
 }) + '\n')

Event types recorded:

SIGNATURE_INVALID: Webhook signature verification failed
INVALID_PAYLOAD: Invalid request payload
WEBHOOK_RECEIVED: Webhook received successfully
AI_RESPONSE_SENT: AI response posted successfully

Conclusion

In this Part 1, we covered the overall architecture and core implementation code connecting giscus, GitHub Webhook, Flask worker, Claude Code CLI, and GitHub GraphQL API.

In the upcoming Part 2, we will cover security hardening for this system — file-based authentication management, file permission verification, HMAC-SHA256 signature verification, and more in detail.

This post is Part 1 of the AgentForge blog automatic comment system series.

SSL Certificate Multi-Domain Support: Adding blog.agentthread.dev

Tue, 10 Mar 2026 23:36:38 +0900

SSL Certificate Multi-Domain Support: Adding blog.agentthread.dev

Overview

Extended the SSL certificate for blog.fcoinfup.com to support the blog.agentthread.dev domain, allowing both domains to use the same certificate.

Background

Created the blog.agentthread.dev domain through Cloudflare and connected it to the same server as blog.fcoinfup.com (130.162.133.47). To serve identical content on both domains, the SSL certificate was extended to support multiple domains.

Work Details

1. DNS Configuration

Cloudflare DNS Record Creation:

blog.agentthread.dev → 130.162.133.47 (A record)

Existing Domain:

blog.fcoinfup.com → CNAME → oci-yarang-ec1.fcoinfup.com → 130.162.133.47

2. SSL Certificate Extension

Existing Certificate Info:

Certificate Name: blog.fcoinfup.com
Domain: blog.fcoinfup.com (single domain)
Encryption: ECDSA
Expiration: 2026-06-08

Extended Certificate Info:

Certificate Name: blog.fcoinfup.com
Domains: blog.fcoinfup.com, blog.agentthread.dev
Encryption: ECDSA
Expiration: 2026-06-08 (89 days remaining)

3. Certbot Commands

Certificate Extension:

sudo certbot certonly --expand -d blog.fcoinfup.com -d blog.agentthread.dev

Or renew existing certificate:

sudo certbot renew --force-renewal --cert-name blog.fcoinfup.com

4. Nginx Configuration Update

Update server_name directive:

server {
 listen 443 ssl http2;
 server_name blog.fcoinfup.com blog.agentthread.dev;

 ssl_certificate /etc/letsencrypt/live/blog.fcoinfup.com/fullchain.pem;
 ssl_certificate_key /etc/letsencrypt/live/blog.fcoinfup.com/privkey.pem;

 # Other settings...
}

Reload Nginx:

sudo nginx -t # Test configuration
sudo systemctl reload nginx

Technical Details

SSL/TLS Certificate

Type: ECDSA (Elliptic Curve Digital Signature Algorithm)
CA: Let’s Encrypt
SAN (Subject Alternative Name): blog.fcoinfup.com, blog.agentthread.dev
Expiration: 2026-06-08

Web Server

Software: nginx
HTTP→HTTPS Redirect: Automatic redirect enabled
HTTP/2: Enabled

DNS

Provider: Cloudflare
Record Type: A
TTL: 3600 seconds (1 hour)
Proxy: Disabled (DNS only)

Results

Accessible URLs

Both domains are accessible via HTTPS:

https://blog.fcoinfup.com ✅
https://blog.agentthread.dev ✅

HTTP Automatic Redirect

http://blog.fcoinfup.com → https://blog.fcoinfup.com
http://blog.agentthread.dev → https://blog.agentthread.dev

SSL Verification

$ curl -I https://blog.agentthread.dev
HTTP/2 200
server: nginx
content-type: text/html

Auto-Renewal

Let’s Encrypt certificates automatically renew every 90 days. The Certbot timer handles renewal automatically.

Check Renewal Status:

sudo systemctl status certbot.timer
sudo certbot renew --dry-run

Security Recommendations

Regular certificate expiration checks
HTTP security headers configuration (HSTS, CSP, etc.)
Strong encryption curves (currently using ECDSA)
Regular web server updates

Conclusion

The blog.agentthread.dev domain has been successfully added, and secure HTTPS access is available through a valid SSL certificate. Both domains serve identical content, allowing users to choose their preferred domain for access.

Korean Version: 한국어 버전

[Cloud Monitor] MCP Tool Structure and Pros/Cons Analysis

Tue, 03 Mar 2026 15:02:49 +0900

[server-monitor] MCP Tool Structure and Pros/Cons Analysis

Overview

This document analyzes the structure, advantages, and disadvantages of the MCP (Model Context Protocol) tools implemented in the server-monitor project. A total of 13 MCP tools are provided, categorized into 8 existing Discord MCP tools and 5 new Cloud Monitor MCP tools.

Architecture Overview
Detailed Tool Analysis
Architecture Structure
Advantages
Disadvantages and Improvements
Conclusion

Architecture Overview

FastMCP-based Architecture

graph TB
 subgraph MCP Server
 A[FastMCP Server] --> B[Discord Tools]
 A --> C[Cloud Monitor Tools]
 B --> D[Gateway Service]
 C --> D
 D --> E[Discord API]
 end

 subgraph Cloud Monitor
 F[SSH Monitor] --> G[OCI Servers]
 F --> H[Mac mini]
 G --> I[Ubuntu]
 H --> J[macOS]
 end

 subgraph Discord
 K[Bot] --> L[Channels]
 K --> M[Threads]
 end

MCP Tool Categories

Category	Tool Count	Main Functions
Discord MCP	8	Message, thread management
Cloud Monitor MCP	5	Server monitoring, metrics collection
Total	13	Integrated monitoring platform

Detailed Tool Analysis

1. Existing Discord MCP Tools (8)

1.1 Message Management Tools

Tool Name	Parameters	Returns	Features
`discord_send_message`	`channel_id`, `content`, `thread_id?`	Result message	Basic message sending
`discord_get_messages`	`channel_id`, `limit?`, `after?`	Message list	Message retrieval
`discord_wait_for_message`	`channel_id`, `timeout_seconds?`	Wait status	Async message waiting (SSE not implemented)

1.2 Thread Management Tools

Tool Name	Parameters	Returns	Features
`discord_create_thread`	`channel_id`, `message_id`, `name?`	Thread info	Thread creation
`discord_list_threads`	`channel_id`	Thread list	Active thread lookup
`discord_archive_thread`	`thread_id`	Result message	Thread archiving (not implemented)

1.3 Concurrency Management Tools

Tool Name	Parameters	Returns	Features
`discord_acquire_thread`	`thread_id`, `agent_name`, `timeout?`	Lock acquisition result	Multi-agent lock
`discord_release_thread`	`thread_id`, `agent_name`	Lock release result	Agent lock release

2. New Cloud Monitor MCP Tools (5)

2.1 Server Management Tools

Tool Name	Parameters	Returns	Features
`cloud_get_server_status`	`server_name`	Server status info	Connection status, OS, metrics
`cloud_list_servers`	`group?`	Server list	Group filtering support
`cloud_list_ssh_config_hosts`	`group?`	SSH host list	SSH config auto-parsing

2.2 Monitoring Tools

Tool Name	Parameters	Returns	Features
`cloud_get_metrics`	`server_name`, `metric_types?`	Metrics data	Optional metric lookup
`cloud_set_alert`	`metric_type`, `level`, `threshold`	Setting result	Dynamic threshold configuration

Architecture Structure

1. FastMCP Structure

graph LR
 subgraph "FastMCP Layer"
 A[@mcp.tool decorator] --> B[Tool Function]
 B --> C[Parameter Validation]
 C --> D[Business Logic]
 D --> E[Result Formatting]
 E --> F[Return Response]
 end

 subgraph "Common Components"
 G[Gateway Request] --> H[HTTP Client]
 I[Config Manager] --> J[Cloud Monitor Config]
 K[Error Handler] --> L[Uniform Error Response]
 end

2. Communication Flow

sequenceDiagram
 participant MCP as MCP Server
 participant GW as Gateway Service
 participant Discord as Discord API
 participant Server as Target Server

 MCP->>GW: HTTP Request
 GW->>Discord: API Call
 Discord-->>GW: Response
 GW-->>MCP: JSON Response

 MCP->>Server: SSH Connection
 Server-->>MCP: Metrics Data
 MCP->>GW: Alert Message
 GW->>Discord: Embed Message

3. Data Flow

Configuration (config.yaml)
 ↓
Server Info parsing
 ↓
SSH Connection
 ↓
Metrics Collection
 ↓
Threshold Check
 ↓
Alert Generation
 ↓
Discord Notification

Advantages

1. Scalability

Modular Structure: Each tool operates independently and is easy to extend
Plugin Architecture: Adding new tools only requires adding decorators
Cloud Provider Abstraction: SSH-based support for various environments

2. Integration

Unified Platform: Discord and Cloud Monitor managed together on a single MCP server
Automatic Linkage: Automatic Discord alerts on server anomalies
Consistent Interface: All tools follow the same parameter pattern

3. Usability

Intuitive Tool Names: Clear function expression like cloud_get_server_status
Optional Parameters: Most parameters are optional for convenience
Detailed Error Messages: Clearly indicates the cause of failures
JSON Response: Structured data return for easy parsing

4. Reliability

Timeout Handling: Timeout set for all requests
Connection Pooling: SSH connection reuse for performance
Exception Handling: Comprehensive try-catch blocks
Status Tracking: Continuous server status monitoring

5. Maintainability

Centralized Configuration: Central management via config.yaml
Environment Variable Support: Sensitive info separated into environment variables
Logging System: Detailed logging for easy debugging
Version Management: Clear module version distinction

Disadvantages and Improvements

Issues

Synchronous Processing: Some tools operate sequentially
Connection Latency: New connection created each SSH connection
Memory Usage: All processing on single event loop

Improvements

# Async processing improvement example
async def concurrent_monitoring(servers):
 tasks = [monitor_server(server) for server in servers]
 return await asyncio.gather(*tasks)

# Connection pooling introduction
class ConnectionPool:
 def __init__(self, max_connections=10):
 self.pool = asyncio.Queue(maxsize=max_connections)

Issues

Undifferentiated Errors: All errors handled the same way
Lack of Recovery Mechanism: No auto-recovery logic on failures
Insufficient Detailed Logging: Insufficient logs for debugging

Improvements

# Differentiated error handling
class CloudMonitorError(Exception):
 pass

class ConnectionError(CloudMonitorError):
 pass

class MetricCollectionError(CloudMonitorError):
 pass

# Auto-recovery mechanism
async def resilient_monitoring(server_info, max_retries=3):
 for attempt in range(max_retries):
 try:
 return await monitor_server(server_info)
 except ConnectionError:
 await asyncio.sleep(2 ** attempt)
 raise CloudMonitorError("Max retries exceeded")

Issues

Lack of Metadata: Tool descriptions too brief
Insufficient Validation: Lack of input value check logic
No Batch Processing: Cannot process multiple servers simultaneously

Improvements

# Detailed metadata
@mcp.tool(
 name="cloud_batch_monitoring",
 description="Retrieve multiple server statuses at once",
 parameters={
 "server_names": {
 "type": "array",
 "items": {"type": "string"},
 "description": "List of server names to monitor"
 }
 }
)
async def cloud_batch_monitoring(server_names: List[str]) -> str:
 # Batch processing logic
 pass

Issues

Credential Exposure: Sensitive info potentially exposed in logs
No Access Control: Anyone can call tools
Insufficient Input Validation: Insufficient defense against malicious input

Improvements

# Access control
def require_role(required_role):
 def decorator(func):
 async def wrapper(*args, **kwargs):
 if not has_role(required_role):
 raise PermissionError("Access denied")
 return await func(*args, **kwargs)
 return wrapper
 return decorator

# Input validation
@mcp.tool()
async def secure_monitoring(server_name: str):
 if not is_valid_server_name(server_name):
 raise ValueError("Invalid server name")
 # ...

Issues

Lack of Documentation: No detailed documentation for tool usage
No Examples: No actual usage examples
Inconsistent Return Values: Some tools return JSON, others return strings

Improvements

# Consistent return value format
@mcp.tool()
async def cloud_get_server_status_v2(server_name: str) -> dict:
 """
 Retrieve server status.

 Args:
 server_name (str): Server name

 Returns:
 dict: {
 "success": bool,
 "data": Optional[dict],
 "error": Optional[str],
 "timestamp": str
 }
 """
 # ...
 return {
 "success": True,
 "data": status,
 "error": None,
 "timestamp": datetime.now().isoformat()
 }

Conclusion

1. Overall Assessment

The MCP tools in the server-monitor project have the following strengths:

✅ Excellent Integration: Perfect combination of Discord integration and server monitoring
✅ Scalable Structure: Modular architecture using FastMCP
✅ Practicality: Provides all functions needed for actual server monitoring
✅ Ease of Use: Intuitive tool names and simple interface

2. Improvement Priority

Improvement plans by priority:

High: Performance improvement (async processing, connection pooling)
Medium: Error handling enhancement and auto-recovery mechanisms
Low: Security enhancement and detailed documentation

3. Future Direction

Microservices Architecture: Separate each tool into independent services
Real-time Monitoring: Real-time data collection via WebSocket/SSE
Auto-scaling: Automatic scaling based on server changes
Machine Learning: ML model integration for anomaly detection

4. Final Assessment

Overall, a well-designed MCP tool system that provides stability and functionality suitable for actual production environments. While there are areas for improvement, the core functionality is highly complete, and it has the potential to develop into an even more powerful monitoring platform through continuous improvements.

Written: 2026-03-03 Author: server-monitor-team

Korean Version: 한국어 버전

DevOps on Yarang's Tech Lair

Building a Blog AI Auto-Comment System (3/3): Deployment and Troubleshooting

Key Configuration Explanation

Service Management Commands

nginx Reverse Proxy

Webhook Endpoint Configuration

Deployment Process

Manual Deployment (After rsync Failure)

Heredoc Variable Expansion Pitfall

Troubleshooting: GITHUB_TOKEN Loading Failure

Step 1: LoadCredential Path Issue

Step 2: File Ownership Issue

Step 3: ReadOnlyPaths Conflict

Step 4: Python File Permission Validation Code (Root Cause)

Importance of Debugging Logs

Debugging Flow Summary

Health Check

Future Improvements

Conclusion

Building a Blog AI Auto-Comment System (2/3) — Security Hardening

Overview

Security Threat Model

File-Based Authentication Management

Problems with Environment Variables

Switching to File-Based

Token File Loading Code

File Permission Validation — A Trial and Error Journey

HMAC-SHA256 Signature Verification

nginx Header Forwarding

Request Validation (marshmallow Schema)

Input Sanitization

Username Masking

Rate Limiting

systemd Security Directives

Conflict between ProtectSystem=strict and ReadOnlyPaths

Conclusion

Building a Blog AI Auto-Comment System (1/3) — Architecture and Implementation

Overview

System Architecture

Overall Data Flow

Components

giscus Configuration

GitHub Webhook Configuration

Flask Worker Implementation

Project Structure

Core Dependencies

Webhook Endpoint

Preventing Infinite Loops

Calling Claude Code CLI

GitHub GraphQL API Integration

Input Sanitization

Audit Logging

Conclusion

SSL Certificate Multi-Domain Support: Adding blog.agentthread.dev

SSL Certificate Multi-Domain Support: Adding blog.agentthread.dev

Overview

Background

Work Details

1. DNS Configuration

2. SSL Certificate Extension

3. Certbot Commands

4. Nginx Configuration Update

Technical Details

SSL/TLS Certificate

Web Server

DNS

Results

Accessible URLs

HTTP Automatic Redirect

SSL Verification

Auto-Renewal

Security Recommendations

Conclusion

[Cloud Monitor] MCP Tool Structure and Pros/Cons Analysis

[server-monitor] MCP Tool Structure and Pros/Cons Analysis

Overview

Table of Contents

Architecture Overview

FastMCP-based Architecture

MCP Tool Categories