DEV Community: Muhammad Dhiyaul Atha

EcoID: An Offline Plant Identifier That Gets You Outside

Muhammad Dhiyaul Atha — Fri, 09 Oct 2026 20:55:09 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass.

What I Built

EcoID is an offline-first plant identification tool for field observations.

The idea is simple: take a laptop or phone outside, photograph a real plant, and use a local AI model to get identification candidates. Then look at the plant yourself and verify the result.

EcoID is designed for:

students learning about local plants
field researchers and citizen scientists
gardeners and small-scale farmers
people who want to explore nature without sending their photos to a cloud service

The current model supports five plant classes:

Mango — Mangifera indica
Coconut — Cocos nucifera
Banana — Musa acuminata
Papaya — Carica papaya
Cassava — Manihot esculenta

The AI does not present its output as a fact. It returns ranked identification candidates with confidence scores. The user then chooses whether the result is:

Verified
Rejected
Uncertain

This human-in-the-loop flow matters because a model prediction is only a suggestion until somebody looks at the actual plant.

EcoID stores field observations locally, including the original photo, model prediction, alternative predictions, confidence score, verification status, notes, optional GPS coordinates, capture time from EXIF metadata, and user corrections.

The project is designed to make the computer useful for a short moment, then get the person back to observing the real world.

Demo

EcoID runs locally on a laptop or a phone-accessible local network. There is no public hosted demo because local execution is part of the project's privacy and offline design.

The trained model and downloaded dataset are not committed to the repository. Model weights and image data are kept outside Git because of their size and individual dataset licensing terms.

After training or obtaining the ONNX model locally:

python -m app --model models/ecoid-global-20261010.onnx --open

The app opens at:

http://127.0.0.1:8765

The main flow is:

Capture or upload a photo
        ↓
Run local inference
        ↓
Review possible identifications
        ↓
Verify, reject, or mark uncertain
        ↓
Save the field observation
        ↓
Review observations in history and on the local map

Code

The source code is available on GitHub:

github.com/Bangkah/EcoID/tree/main

The source code is released under the MIT License. Dataset images retain their original licenses and attribution requirements.

The main parts of the project are:

app/ai/ — preprocessing, inference, model contracts, and result post-processing
app/observation/ — drafts, verification, EXIF metadata, maps, statistics, and exports
app/storage/ — local SQLite persistence and image storage
app/ui/ — the local HTTP server and browser interface
scripts/ — dataset preparation, training, export, evaluation, and benchmarking
tests/ — unit, integration, offline, and browser tests

The architecture is:

How I Built It

Local image preprocessing

Every image follows the same preprocessing path:

Decode the image
Apply EXIF orientation
Convert to RGB
Resize to 224x224
Normalize with ImageNet mean and standard deviation
Convert to a float32 tensor with shape (1, 3, 224, 224)

Keeping preprocessing in one shared module helps avoid train/serve skew between the training pipeline and the production inference path.

Open-source AI and local inference

EcoID uses a MobileNetV3-Small image classifier exported to ONNX and executed with ONNX Runtime on the CPU.

The UI and storage layers depend only on a small model contract, so the inference backend can be replaced without rewriting the rest of the application.

The output is converted into a Top-3 list of candidates. If the confidence score is below the configured threshold, the result is marked as LOW_CONFIDENCE.

The initial threshold was calibrated using validation data. The current configuration is:

threshold = 0.73

On the current validation set, this produced:

53.7% coverage
97.5% selective accuracy
80.0% negative rejection

These numbers are provisional and should be recalibrated when the field dataset grows.

Training results

The first real dataset download produced 2,447 usable licensed images, approximately 370 MB in total. The dataset was collected from iNaturalist using CC0, CC BY, and CC BY-SA images, with attribution metadata preserved.

The validated dataset contains approximately 2,000 training images across the five target classes, 300 validation images, and 149 negative samples across lookalike, non-plant, and low-quality groups.

The dataset pipeline includes:

license metadata
author attribution
photographer-based split separation
duplicate and near-duplicate checks
validation and evaluation splits
negative examples
dataset structure validation

The initial MobileNetV3-Small training run achieved:

best validation accuracy: 80.3%
five target plant classes
local CPU inference after ONNX export

On a separate 50-image evaluation set (10 images per class), the model achieved:

Top-1 accuracy: 86.0% (43/50)
Top-3 accuracy: 94.0% (47/50)
negative rejection: 77.1% (84/109)
selective accuracy at threshold 0.73: 94.1%
coverage: 68.0%

This evaluation set was collected from licensed iNaturalist images and is useful as a reproducible benchmark. It is not a substitute for a field evaluation with locally captured phone photos.

The ONNX export was verified against the PyTorch model:

maximum logit difference: approximately 1.9e-6
Top-1 agreement: 20/20 samples

The repository also generates contact sheets for mandatory manual label review. Automated dataset validation passed with zero errors, but a complete human review of all contact sheets remains a dataset-quality task.

Human verification

A prediction is first stored as a temporary draft. It becomes a permanent observation only after the user makes a verification decision.

This prevents an abandoned or uncertain prediction from silently becoming part of the observation history.

The flow is:

photo → identification draft → human verification → saved observation

Draft photos that are abandoned are automatically removed after 24 hours.

Offline storage

The application stores everything locally:

~/.ecoid/
├── ecoid.db
├── images/
├── thumbs/
└── drafts/

The application does not require a cloud API for inference. The browser UI also uses a strict Content Security Policy and does not load external scripts, fonts, or images.

GPS is opt-in. A user can attach a photo's EXIF location, use device geolocation, or enter coordinates manually.

Performance

The model was benchmarked on a Windows laptop using CPU inference:

Stage	Average
Decode and resize	6.3 ms
ONNX inference	5.8 ms
Softmax and Top-K	0.4 ms
Total	12.4 ms

The measured p95 total latency was 33.8 ms per image, below the project's target of 10 seconds per image.

Testing

The project includes:

Python 3.11 and 3.12 test coverage
Ruff linting
byte-compilation checks
tests with non-UTF-8 default encoding
browser tests with real headless Chromium
offline tests that block non-loopback sockets and DNS lookups
UI tests for capture, verification, history, map, statistics, export, and deletion

The current local test result is:

222 tests passed
25 browser tests skipped unless browser testing is enabled

The CI workflow is defined in .github/workflows/ci.yml.

Why Does Open Innovation Matter?

Plant identification is a good example of why open innovation matters.

A closed cloud API could return a label quickly, but it would also introduce several limitations:

photos would leave the device
the application would depend on an internet connection
the model's behavior would be difficult to inspect
users would have less control over their field data
the tool might not work in remote areas

Using open-source tools and local inference makes a different design possible. The complete pipeline can be inspected and adapted:

image preprocessing is visible
model inputs and outputs are explicit
confidence thresholds can be calibrated
observations remain on the user's device
the backend can be replaced
the application can run without a reliable internet connection

Open innovation also makes the project easier to learn from. Someone can inspect the training scripts, run the synthetic smoke test, replace the model, add new plant classes, or adapt the observation workflow for another field research problem.

The goal is not to pretend that a small classifier can replace botanical expertise. The goal is to build a transparent tool that helps people notice, record, and learn from the plants around them.

Limitations and Next Steps

This is an initial working model, not a finished botanical identification system.

The most important remaining limitation is domain coverage. The 50-image independent evaluation set is sourced from licensed iNaturalist images, while a dedicated evaluation set of locally captured Indonesian field photos is still needed.

The next steps are:

Add Indonesian field photos and compare them with the current 50-image iNaturalist benchmark.
Perform the manual visual quality-control pass on all contact sheets.
Remove or document near-duplicate training images.
Re-run calibration using the expanded validation set.
Re-run final evaluation on a fixed, independent test set.
Record a physical field demonstration with the trained model.

My Agent Session

This project was developed with an AI coding assistant using Copilot SDK in VS Code.

The agent helped inspect the repository, understand the architecture, connect the AI pipeline to the local observation workflow, run the dataset pipeline, train the initial model, verify ONNX parity, calibrate the confidence threshold, and validate the test suite.

The agent session is optional for this submission and is not linked here.

Prize Categories

I am entering the overall Hacktoberfest Open-Source AI Challenge.

I am not entering a partner category because EcoID does not currently use a partner-specific technology.

UnvibeComplex Code to Real Workflows: Finding and Fixing a Secret-Handling Boundary Bug in UnvibeCode

Muhammad Dhiyaul Atha — Thu, 08 Oct 2026 12:02:26 +0000

From CI/CD Secrets to External APIs: Finding a Boundary Bug in UnvibeCode

When evaluating AI-powered developer tools, we often focus on the big picture: how well a repository is mapped, how useful the generated architecture diagrams are, or how accurate the code summaries can be.

However, the reliability of an open-source project is also determined by small details that are easy to overlook—CI/CD scripts, environment variables, and requests to external APIs.

While analyzing UnvibeCode, I found an interesting example of a bug at the boundary between configuration and runtime behavior: a secret was correctly passed by GitHub Actions and successfully read by the Python script, but it was never actually used in the outgoing HTTP request.

This article explains:

how the bug was discovered;
why the existing test suite did not catch it;
how the issue can be fixed;
and what this teaches us about testing pipelines that rely on secrets.

Note: This analysis is based on source-code inspection and the repository's quality suite. No production credentials or tokens were accessed, displayed, or used.

Tracing the Secret Flow

UnvibeCode includes a GitHub Actions workflow for archiving repository traffic statistics:

.github/workflows/archive-github-traffic.yml
        |
        v
.github/scripts/archive_github_traffic.py
        |
        v
GitHub Traffic API

The workflow requires a secret named TRAFFIC_TOKEN.

1. The Secret Is Passed by the Workflow

The workflow maps the GitHub Actions secret to an environment variable:

env:
  TRAFFIC_TOKEN: ${{ secrets.TRAFFIC_TOKEN }}
  GITHUB_REPOSITORY: ${{ github.repository }}

At this stage, everything appears correct. GitHub Actions makes the secret available to the environment in which the Python script runs.

2. The Python Script Reads the Secret

The script retrieves the environment variable and exits if it is missing:

TOKEN = os.environ.get("TRAFFIC_TOKEN", "").strip()

if not TOKEN:
    fail(
        "TRAFFIC_TOKEN is not set. Add a repository secret named "
        "TRAFFIC_TOKEN with read access to repository traffic."
    )

Again, the flow appears correct: the secret is available and the application successfully reads it.

3. The Secret Is Lost When the Request Is Built

The problem appears in the api_get() function:

headers = {
    "Accept": "application/vnd.github+json",
    "Authorization": f"*****",
    "User-Agent": "unvibecode-traffic-archiver",
}

The f"*****" value is not an f-string that incorporates the TOKEN variable. It is simply a string literal.

As a result, the TOKEN value that was successfully read earlier never reaches the Authorization header.

The request is then sent to several GitHub Traffic API endpoints, including:

traffic/views?per=day
traffic/clones?per=day
traffic/popular/referrers
traffic/popular/paths

If the API rejects the resulting authorization header, the workflow fails before the traffic data can be written to the CSV output.

Why Is This Bug Easy to Miss?

This finding highlights three distinct stages that should be considered when reviewing secrets in CI/CD pipelines:

Availability — Is the secret available to the workflow?
Readability — Does the application read the correct environment variable?
Usage — Does the actual runtime value reach the external API boundary?

In this case, the first two stages appeared correct. The bug only became visible at the third stage.

This is why simply reviewing configuration files is not enough. We need to trace the data flow all the way to the outgoing request.

Why Didn't the Existing Tests Catch It?

I ran the repository's quality suite, which completed successfully with:

906 passed

The test suite validates several important aspects of the repository, including:

workflow-pack structure;
scenario counts;
skill metadata;
local Markdown links;
required automation files.

However, there was no test that invoked api_get() with urlopen mocked and then inspected the resulting request headers.

In other words, the existing tests demonstrated that the repository structure and related metadata were valid, but they did not verify that the secret was actually used when the HTTP request was constructed.

This is an important distinction:

A test suite can provide strong structural coverage while still missing a critical runtime integration bug.

Recommended Fix

The authorization header should use the runtime token:

headers = {
    "Accept": "application/vnd.github+json",
    "Authorization": f"Bearer {TOKEN}",
    "User-Agent": "unvibecode-traffic-archiver",
}

The change itself is small, but it should be accompanied by a regression test.

A suitable test should:

provide a dummy token through the environment;
mock urlopen;
call api_get();
inspect the generated request;
verify that the Authorization header contains the runtime token;
ensure that the token is never printed to stdout or stderr;
continue to verify that a missing token produces a clear error.

The core assertion could be:

assert request.headers["Authorization"] == "Bearer test-token"

The actual test should use a dummy value such as test-token, never a real credential.

Engineering Lessons

1. A Secret Being Available Does Not Mean It Is Being Used

An environment variable can be correctly configured and successfully read without ever reaching the component that needs it.

For external integrations, the final boundary—such as an HTTP header, SDK argument, or subprocess invocation—must be explicitly verified.

2. Test the External Boundary, Not Just Internal Logic

For code that communicates with an API, mock the network client or network function at the point where the request leaves the application.

Verify at least:

HTTP method;
URL;
authorization headers;
relevant request parameters;
and, where appropriate, request payloads.

This approach avoids making real API calls while keeping the test fast, deterministic, and safe.

3. Never Print Secrets for Debugging

When inspecting authentication behavior, assert against the request object or sanitized metadata.

Do not print the raw token into CI logs—even temporarily.

A debugging statement such as:

print(TOKEN)

can turn a functional debugging session into a credential-exposure incident.

4. Analysis Tools Help Trace the Path, but They Do Not Replace Verification

UnvibeCode can make it easier to connect workflows, files, and dependencies and identify the path a secret takes through a repository.

However, the final conclusion still needs to be validated against the actual source code and, where possible, a test at the runtime boundary.

Static analysis can show that a variable is present.

A boundary test can show that its value is actually transmitted.

Those are different guarantees.

Conclusion

This is not an example of a secret being leaked into the repository. The problem is almost the opposite: the configured secret was never actually used.

That distinction matters.

The secret was not exposed.
The API request could nevertheless fail.
The workflow appeared to be correctly configured.
The existing tests could still pass because they did not inspect the outgoing request.

When auditing CI/CD pipelines, don't stop at the question:

"Is the secret configured?"

Ask the more important question:

"Does the secret actually reach the external boundary where it is required?"

That boundary is often where a seemingly correct configuration turns into a runtime failure.

References

Disclosure: This article was written with AI assistance for language editing and presentation. The technical finding, repository inspection, and final conclusions are based on analysis of the source code and the repository's test results.

[Boost]

Muhammad Dhiyaul Atha — Sun, 04 Oct 2026 00:47:19 +0000

Muhammad Dhiyaul Atha

Oct 3

Building a Privacy-First AI CRM Assistant for My Friend's Business

#devchallenge #weekendchallenge #hf26challenge #hacktoberfest

3 min read

Building a Privacy-First AI CRM Assistant for My Friend's Business

Muhammad Dhiyaul Atha — Sat, 03 Oct 2026 21:20:23 +0000

Matt runs a growing business, but his daily intake operation was becoming a bottleneck.

His team receives business inquiries through email, website forms, and messaging channels. The incoming information is highly inconsistent. Some inquiries are valuable sales opportunities, some are support questions, some are junk, and others simply lack enough information to make a decision.

He needed a system to ingest these inquiries, identify what they are, extract useful structured information, and draft the next response. However, sending sensitive client business data to closed-source cloud LLMs was a major privacy concern.

For the Hacktoberfest Weekend Challenge: Build for a Friend, I decided to build him a secure, locally hosted AI CRM Intake Automation System written in Go.

What I Built

I designed a practical backend system that ingests incoming messages, uses local open-source AI to classify them, extracts structured data, and prepares the next steps for a human to review.

Here is what the system does:

Ingestion & Classification: Determines if a message is a Sales Lead, Support Ticket, Junk, or Incomplete.
Extraction: Pulls out names, contact info, and business needs.
Drafting: Prepares a response based on the classification.
Human-in-the-Loop: Alerts Matt's team to review and approve the action before any CRM record is updated or any email is sent.

Demo

The prototype can process an inquiry locally and produce structured output for the next stage of the workflow.

Code

You can check out the project and its code structure here:
GitHub: CRM Automation System

How I Built It

I built the workflow engine in Go around a simple principle:

The AI analyzes the data, but deterministic code executes the actions.

The LLM is responsible for classification, extraction, and drafting. It does not directly send emails, modify CRM records, or execute arbitrary actions. The deterministic Go backend handles validation, duplicate protection, idempotency, database updates, and the audit trail.

Human-in-the-Loop

Consequential actions require human approval. Before an email is sent or a CRM record is updated, the workflow pauses and creates a pending approval for the operator to review.

// internal/workflow/approval_service.go
package workflow

import (
    "context"
    "fmt"
    "time"
)

func (s *ActionService) ApproveAction(
    ctx context.Context,
    actionID, approverID string,
) (ActionRecord, error) {
    action, err := s.repo.Get(ctx, actionID)
    if err != nil {
        return ActionRecord{}, err
    }

    if action.State != ActionStatePendingApproval {
        return ActionRecord{}, fmt.Errorf(
            "invalid approval transition from %s",
            action.State,
        )
    }

    updated := action
    updated.State = ActionStateApproved
    updated.ApprovedBy = approverID
    updated.UpdatedAt = time.Now()

    if err := s.repo.Update(ctx, updated); err != nil {
        return ActionRecord{}, err
    }

    if err := s.audit.Append(
        ctx,
        createAuditEvent(
            action.InquiryID,
            action.ID,
            "approval.granted",
            DecisionAllow,
            "approval",
        ),
    ); err != nil {
        return ActionRecord{}, err
    }

    return updated, nil
}

Why Does Open Innovation Matter?

For this project, using open-source AI locally through Ollama wasn't just a technical choice; it was a business requirement.

Data Privacy

Business inquiries can contain sensitive information such as budgets and personal contact details. By keeping AI inference local, the system does not need to send that data to a third-party LLM provider.

Cost Control

Running an open-weight model locally avoids per-token API costs for every inquiry, including messages that eventually turn out to be spam or incomplete.

Control and Predictability

Running the model locally gives me more control over the model, prompting, and output format. The Go backend validates the structured JSON response before processing it.

Conclusion

This project reinforced my interest in building AI systems where models are useful for analysis and drafting, while deterministic software and human approval remain responsible for consequential actions.

Happy hacking! 🌟

My Hacktoberfest 2026 Journey: Contributing to DevOps Daily

Muhammad Dhiyaul Atha — Thu, 01 Oct 2026 20:03:26 +0000

Hacktoberfest is back, and this year I decided to join the 7-Day DevOps Contribution Challenge hosted by @devopsdaily

I’m still learning my way around open-source contribution workflows, so I’m using this challenge as an opportunity to practice working with real repositories, following existing project conventions, and getting more comfortable with the Git workflow.

This article documents my progress so far, including how I tested my changes locally and the pull requests I submitted along the way.

Day 1: Registering as an Expert on DevOps Daily

On Day 1, the challenge focused on adding a personal expert profile to the platform's repository. Here’s what I did:

1. Creating the JSON Profile

I created a data file at content/experts/muhammad-dhiyaul-atha.json containing my professional background, social links, and core specialties in backend development, containerization, and automated deployment infrastructure.

2. Preparing the Avatar

I uploaded my avatar image in .png format to public/images/experts/muhammad-dhiyaul-atha.png to ensure the profile renders correctly.

3. Local Testing

I ran the local development server using pnpm dev to verify that the system successfully read the files.

4. Opening the Pull Request (PR)

After confirming everything was clean, I created a dedicated branch, committed, and pushed the changes:

git checkout -b hacktoberfest/add-muhammad-dhiyaul-atha
git add content/experts/muhammad-dhiyaul-atha.json public/images/experts/muhammad-dhiyaul-atha.png
git commit -m "Add Muhammad Dhiyaul Atha to experts directory"
git push origin hacktoberfest/add-muhammad-dhiyaul-atha

I then opened PR #1790 on @thedevopsdaily.

Day 2: Contributing a Favorite DevOps Tool (Lazydocker)

For Day 2, the challenge was to modify a TypeScript component and add a new tool to the curated Toolbox.

1. Choosing the Tool

I chose Lazydocker, a Go-based terminal user interface (TUI) that makes managing Docker containers and Docker Compose easier from the command line.

2. Modifying `app/toolbox/page.tsx`

I added a new configuration object to the tools array under the containers category:

{
  name: 'Lazydocker',
  description: 'A simple terminal UI for both docker and docker-compose, written in Go.',
  href: 'https://github.com/jesseduffield/lazydocker',
  category: 'containers',
  icon: Terminal,
  badges: [
    { text: 'Docker', variant: 'outline' },
    { text: 'Open Source', variant: 'secondary' },
  ],
},

3. Submitting the Second PR

Following the same Git workflow, I created a new branch, pushed the changes, and opened PR #1807 on @thedevopsdaily.

Day 3: Adding a Quiz Question to the Linux Quiz

On Day 3, the task was to contribute a multiple-choice question to an existing quiz file on the platform. Here’s what I did:

1. Selecting the Quiz File

I chose content/quizzes/linux-quiz.json and drafted an intermediate-level question focused on modern network troubleshooting in Linux using the ss command.

2. Drafting the Question & Updating Metadata

I added a new question object to the questions array:

{
  "id": "linux-check-listening-ports",
  "title": "Checking Listening Ports",
  "description": "Which command-line tool is commonly used on modern Linux distributions to inspect socket statistics and display active listening ports along with their corresponding process names?",
  "options": [
    "netstat -an",
    "ss -tulpn",
    "lsof -port",
    "ps aux --ports"
  ],
  "correctAnswer": 1,
  "explanation": "ss (socket statistics) is the modern, faster replacement for netstat. The flags -tulpn display TCP/UDP connections, listening sockets, and the numeric PIDs/program names holding them.",
  "difficulty": "intermediate",
  "points": 15
}

I also updated the totalPoints (increased to 202) and incremented the intermediate difficulty level count in the file's metadata.

3. Local Testing & Validation

Before committing, I ran the repository's test and validation commands to verify the quiz schema and metadata:

pnpm test tests/quiz-validation.test.ts

pnpm quiz:validate

4. Opening the Pull Request (PR)

After confirming everything passed successfully, I created a dedicated branch, committed, and pushed the changes:

git checkout -b hacktoberfest/add-quiz-question
git add content/quizzes/linux-quiz.json
git commit -m "Add quiz question on checking listening ports to linux-quiz"
git push origin hacktoberfest/add-quiz-question

I then opened the Pull Request on @thedevopsdaily.

Day 4: Adding Flashcards to Linux Fundamentals

On Day 4, the objective was to contribute one or two study flashcards to an existing set to help others learn DevOps and system administration concepts. Here’s what I did:

1. Selecting the Flashcard Set

I chose content/flashcards/linux-fundamentals.json since it covers essential Linux topics and fits well with my background in Linux system administration.

2. Drafting and Adding the Flashcards

I added two new flashcard objects to the end of the cards array, covering network troubleshooting with ss and systemd logs with journalctl:

{
  "id": "linux-check-listening-ports",
  "front": "How do you inspect active listening ports and their processes on modern Linux?",
  "back": "Use the ss command with flags -tulpn (ss -tulpn). It is the modern, faster replacement for netstat, displaying TCP/UDP connections, listening sockets, and the numeric PIDs/program names holding them.",
  "category": "Networking",
  "tags": ["ss", "ports", "networking", "troubleshooting"]
},
{
   "id": "journalctl-systemd-logs",
   "front": "How do you query and follow systemd logs using journalctl?",
   "back": "journalctl -u service-name views logs for a specific service. Add -f to follow live output (like tail -f), -n 50 for the last 50 lines, and --since today for recent logs. It reads binary journal logs maintained by systemd.",
   "category": "Monitoring",
   "tags": ["journalctl", "systemd", "logs", "troubleshooting"]
    }

I also updated the cardCount metadata at the top of the file, increasing it from 20 to 22.

3. Local Testing & Preview

I started the local development server to test the flashcards page and ensure the new cards rendered correctly:

pnpm dev

4. Opening the Pull Request (PR)

After confirming everything passed successfully, I created a dedicated branch, committed, and pushed the changes:

git checkout -b hacktoberfest/add-flashcard
git add content/flashcards/linux-fundamentals.json
git commit -m "Add flashcard for checking listening ports using ss to linux-fundamentals"
git push origin hacktoberfest/add-flashcard

I then opened the Pull Request on @thedevopsdaily.

Day 5: Sharing a Practical DevOps Gotcha on CI/CD Security

On Day 5, the objective shifted from adding static data (like quizzes or flashcards) to sharing a practical tip, "gotcha," or lesson learned the hard way by improving an existing guide on the platform.

1. Choosing the Right Article to Improve

I browsed through content/guides/introduction-to-cicd/ and selected 09-security-best-practices-and-production-patterns.md. Having dealt firsthand with workflow permission issues while setting up automated tasks and repository stats updaters, I knew exactly what kind of pitfall often catches developers off guard.

2. Drafting the Gotcha Section

Inside the section covering Least Privilege Access, I inserted a concise and technically accurate warning regarding GitHub Actions default token permissions:

Gotcha: If your GitHub Actions workflow fails with a "403 Forbidden" error when trying to push commits or update repository files, check the GITHUB_TOKEN permissions. Repositories can use read-only defaults for the token. If the workflow needs to write repository contents, explicitly grant the required permission, such as contents: write, in the workflow.

3. Verifying and Isolating the Branch

To keep my contribution clean and prevent stray build artifacts or previous commits from leaking into this pull request, I made sure to check out a dedicated branch from a clean state:

git checkout main
git pull origin main
git checkout -b hacktoberfest/add-tip

4. Committing and Opening the Pull Request

After verifying the changes locally, I staged only the modified guide file, committed with a clear message, and pushed to my fork:

git add content/guides/introduction-to-cicd/09-security-best-practices-and-production-patterns.md
git commit -m "docs: add github token permission gotcha"
git push -u origin hacktoberfest/add-tip

I then opened the Pull Request on @thedevopsdaily.

Conclusion

So far, this challenge has been a useful way to practice the basics of contributing to an existing open-source project.

The work itself has been relatively small, but there have still been things to learn: understanding an unfamiliar codebase, following its existing structure, testing changes locally, creating focused branches, and preparing pull requests.

I’m still in the middle of the challenge, so there is a lot more to learn and contribute. I’ll continue updating this article as I work through the remaining days of the challenge.

If you're also participating in Hacktoberfest this year, I'd be interested to hear what you've been working on.

Happy hacking! 🌟

My Experience Deploying Projects Smoothly with Tencent EdgeOne Makers

Muhammad Dhiyaul Atha — Sun, 13 Sep 2026 11:23:07 +0000

Exploring modern cloud infrastructure, edge computing, and streamlined deployment platforms has always been an exciting journey for developers. Recently, as part of the DevHandal 2026 Batch 2 program, I had the opportunity to dive deep into Tencent EdgeOne Makers, and it has genuinely changed how I approach shipping web projects efficiently.

In this article, I want to share my honest review, technical impressions, and why this platform is becoming an exceptional choice for developers looking for fast, secure, and hassle-free website deployment.

Why Tencent EdgeOne Makers Stands Out

When working on modern web applications, setting up Content Delivery Networks (CDNs), security layers like Web Application Firewalls (WAF), DDoS mitigation, and global edge routing usually takes a considerable amount of configuration overhead. Traditional setups often require juggling multiple services across different cloud providers.

EdgeOne Makers simplifies all of that by consolidating these essential features into a unified, developer-friendly ecosystem. Some of the standout features that caught my attention during my exploration include:

Global Edge Performance: Static and dynamic assets are cached and served closer to users worldwide. This architectural approach results in significantly lower latency, faster Time to First Byte (TTFB), and an overall instant page load experience.
Built-in Security Protection: Robust security measures come right out of the box. It keeps applications safe from common web vulnerabilities, malicious traffic, and DDoS attacks without requiring complex external plugins or expensive enterprise firewalls.
Streamlined Developer Workflow: The integration pipeline allows developers to spin up, configure, and deploy applications rapidly, making it ideal for both rapid prototyping and production-grade applications.

Getting Started and Deployment Experience

Deploying a project on the platform is remarkably straightforward. Whether you choose to manage your configurations via their intuitive command-line interface (CLI) or through the web dashboard, the process is streamlined to let developers focus purely on writing application code rather than wrestling with server maintenance.

When I tested deploying my project, the workflow felt natural. Here is a quick breakdown of the steps and best practices I followed:

Clean Project Initialization: Structuring project files logically so that the edge runtime can route static assets and serverless functions seamlessly.
Smooth CLI Commands: Leveraging fast local testing tools and straightforward deployment commands that push code straight to the edge network in a matter of seconds.
Generous Free Tier and Quotas: Having access to a robust free tier makes it stress-free to experiment, build, and showcase projects without worrying about unexpected upfront server costs.

My overall experience using Tencent EdgeOne Makers has been fantastic. It successfully removes the friction and complexity of traditional server management, enabling developers to ship secure, high-performance applications with absolute ease. If you haven't tried it yet, I highly recommend exploring EdgeOne Makers for your next web project. It is a powerful tool that elevates both developer productivity and end-user performance. Furthermore, the supportive ecosystem and continuous updates make it a reliable choice for long-term scalability, ensuring that hobbyists and professional developers alike can build resilient web solutions with minimal hassle. Additionally, participating in this developer program has opened up new insights into modern edge architectures.

Three Bugs That Almost Killed My Honeypot Before It Ever Caught Anyone

Muhammad Dhiyaul Atha — Thu, 10 Sep 2026 09:30:55 +0000

I built Bangk-Shield, an edge-native honeypot that runs on Cloudflare Workers. The idea is simple: sit in front of a site, watch for SQLi/RCE/SSRF/LFI/XSS/recon probes, and instead of quietly blocking them, answer with a convincing fake payload and a locally-flavored roast — while logging the real attacker's fingerprint.

The pitch is fun. The bug hunt getting it to actually work was not. Here are three failures that taught me more about edge runtimes and silent regressions than any tutorial would have.

Bug #1: The Worker That Attacked Itself

First local test run. I hit two endpoints with curl and watched the wrangler dev log:

[wrangler:info] GET /etc/passwd 500 Internal Server Error (13820ms)
[wrangler:info] GET /.env 500 Internal Server Error (13833ms)
[wrangler:info] GET /etc/passwd 500 Internal Server Error (13831ms)
[wrangler:info] GET /.env 500 Internal Server Error (13844ms)
...hundreds more lines...
[wrangler:info] GET /etc/passwd 500 Internal Server Error (20822ms)
⎔ Shutting down local server...

Two curl calls. Hundreds of log lines. Latency climbing from 13.8 seconds to 20.8 seconds before the dev server gave up and died. That climb is the tell — nothing about a single HTTP request naturally gets 7 seconds slower over its own lifetime. Something was calling itself.

The culprit was in my "passthrough" logic — the code path that forwards legitimate traffic to the real origin server:

// The bug
function passthrough(request, env) {
  if (env && env.ASSETS) {
    return env.ASSETS.fetch(request);
  }
  return fetch(request); // <-- this
}

In local dev, with no real origin configured, fetch(request) re-fetches the exact same URL — which, in wrangler dev, is the Worker's own address. The Worker calls itself. That call also fails to resolve a real backend, hits the same fail-open catch block, and calls fetch(request) again. Recursion, with no base case, burning CPU and stacking subrequests until the runtime hit a limit and returned 500.

The scary part isn't that it happened in dev. It's that this same failure mode is a documented Cloudflare Workers gotcha in production too, if a Worker's outbound fetch happens to match one of its own routes.

The fix had three parts, because I wanted defense in depth, not just a patch:

async function passthrough(request, env) {
  // 1. Loop guard — if we already forwarded this request once, stop.
  if (request.headers.get('x-bangk-shield-forwarded')) {
    return new Response('Bangk-Shield: forwarding loop detected.', { status: 508 });
  }

  if (env && env.ASSETS) return env.ASSETS.fetch(request);

  // 2. Explicit origin — never re-fetch the same host as this Worker.
  if (env && env.ORIGIN_URL) {
    const target = new URL(env.ORIGIN_URL);
    const forwardUrl = new URL(request.url);
    forwardUrl.protocol = target.protocol;
    forwardUrl.hostname = target.hostname;
    forwardUrl.port = target.port;

    const forwarded = new Request(forwardUrl.toString(), request);
    forwarded.headers.set('x-bangk-shield-forwarded', '1');
    return fetch(forwarded);
  }

  // 3. No origin configured — say so, instead of guessing and looping.
  return new Response(
    'Bangk-Shield is active, but no ORIGIN_URL is configured for legitimate traffic.',
    { status: 200 }
  );
}

Lesson: a "safe default" that just re-fetches the incoming request isn't safe. It's an assumption that something else out there is going to intercept and redirect the call before it loops. In a reverse-proxy pattern, that assumption needs to be an explicit contract (an origin URL, a binding), not implicit behavior you hope the runtime handles for you.

Bug #2: The Detector That Never Detected Path Attacks

This one didn't crash anything. It just silently did nothing, which is worse.

After a rewrite that moved detection rules into a scored, combo-bonus rule engine, I built the request context like this:

const context = {
  query: safeDecode(url.search).toLowerCase(),
  headers: userAgent.toLowerCase(),
  body: ''
};

Looks reasonable. Except: there's no path field. And the rule engine matches signals against context[target], where target comes from each signal's where array in the rules config — things like "where": ["path", "query", "body"].

Every rule that targeted path — /etc/passwd, /.env, /wp-admin, all the classic recon and LFI probes that live in the URL path rather than the query string — evaluated context['path'], got undefined, and silently failed to match. No error. No warning. The honeypot just let path-based attacks walk straight through to the real origin, forever, while confidently reporting "no threats detected."

This is the kind of bug that unit tests catch and manual clicking doesn't, because manually poking /?id=1' OR 1=1 in the query string "worked," so the feature "looked done."

The fix was one line:

const context = {
  path: safeDecode(path).toLowerCase(),   // <-- this was missing
  query: safeDecode(url.search).toLowerCase(),
  headers: userAgent.toLowerCase(),
  body: ''
};

But the fix isn't really the interesting part — the verification is. I wrote a small standalone test harness that fed known attack shapes straight into the scoring function and asserted whether they crossed the trigger threshold:

testCase('/etc/passwd in path (must trigger alone)', {
  path: '/etc/passwd', query: '', headers: 'curl/8.0', body: '',
}, true);

testCase('/.env alone (score too low, must pass through)', {
  path: '/.env', query: '', headers: 'curl/8.0', body: '',
}, false);

Running that harness against the old context shape would have failed instantly and obviously — instead of failing silently in production traffic six months later. Lesson: for a security tool, "it compiles and the demo works" is not a test suite. If a detector can fail closed (i.e., fail into "everything looks safe"), you need an explicit assertion that proves the opposite case still fires.

Bug #3: The Watermark That Lied

Every honeypot response includes a cryptographic watermark — a hash derived from the visitor's IP, User-Agent, date, and a rotating salt. The point is defensive: if someone screenshots a fake "leaked database" response and claims it's a real breach, the site owner can reproduce the hash and prove it's a decoy.

The spec (written into the project's PRD) was explicit about the exact format, because a mismatch means the hash can never be reproduced later:

Canonical: bangk-shield/v1|<ip>|<ua>|<yyyy-mm-dd>|<salt>
Output:    bs1-<first 16 hex chars of SHA-256(canonical)>

The shipped code did this instead:

const canonical = `bangk-shield|${ip}|${ua}|${dateStr}|${salt}`; // missing /v1
return `bs-${hashHex.slice(0, 16)}`;                              // missing the 1

Small diff. Big consequence: any CI test vector built against the spec format would fail against this code forever, and worse, nobody would notice until someone tried to reproduce a watermark from a real incident and got a hash that simply didn't match anything.

The second half of this bug was sneakier. The spec said the salt should live in Workers KV as a rotatable object:

// wm:salt:current
{ "salt": "a1b2c3...", "since": "2026-09-08T10:00:00Z" }

But the code read the KV value and used it directly as the salt string:

const salt = env.WATERMARK_SALT || 'default-dev-salt'; // never even reads KV

Two problems stacked on top of each other: the salt wasn't actually coming from KV at all (so "rotate without redeploy" didn't work), and if I'd naively "fixed" that by just doing await env.BANGK_KV.get('wm:salt:current'), the salt would have become the literal string '{"salt":"a1b2c3...","since":"..."}' — every watermark computed with the entire JSON blob as the salt, silently, with no error thrown anywhere.

The fix parses defensively and stays backward-compatible with plain strings during migration:

function extractSaltValue(raw) {
  if (typeof raw === 'string') {
    try {
      const parsed = JSON.parse(raw);
      if (parsed?.salt) return parsed.salt;
      return raw; // valid JSON, wrong shape — treat as a plain salt
    } catch {
      return raw; // not JSON at all — legacy plain-string salt
    }
  }
  return raw?.salt ?? null;
}

Lesson: any time two independent things (a spec doc and an implementation, or a producer and a consumer of the same data) both need to agree on a format, that agreement should be enforced somewhere machine-checkable — a schema, a fixed test vector, a shared constant — not just "well-documented." Documentation drifts. Code that has to pass a byte-for-byte comparison doesn't.

What Actually Changed My Process

None of these three bugs were exotic. They were all boring, one-line-diff mistakes. What made them dangerous was that each one failed silently — the Worker kept returning 200s, the demo kept looking fine, and the failure mode only showed up under conditions I hadn't manually tested (a request with no real origin behind it, an attack in the path instead of the query, a salt fetched from the "real" storage instead of the dev fallback).

Three things I do differently now, on this project and since:

Fail-closed the build, fail-open the runtime. A honeypot must never take down the site it's protecting — so the request path stays fail-open (any internal error just forwards traffic). But the build pipeline that compiles detection rules now fails hard on anything suspicious: invalid regex, patterns that can never match because of a later .toLowerCase(), ReDoS-prone patterns. Silent failure in the runtime is safe; silent failure in the config is not.
Test the shape of the data, not just the happy path. The path-detection bug and the salt-shape bug were both "the code runs, produces a 200, and does the wrong thing." A quick harness that asserts on expected trigger/no-trigger outcomes for known attack payloads catches this class of bug in seconds instead of after deployment.
Treat spec-vs-code drift as a bug class of its own. Once I had a real PRD with byte-exact format requirements, I started explicitly diffing "what the spec says" against "what the code does" as a review step — not just reading the code in isolation and asking "does this look reasonable?"

The project is still in beta. But it's a beta that now has a test harness, a build-time linter that can fail on purpose, and a much shorter list of ways it can lie to me about whether it's actually working.

Membangun Infrastruktur Enterprise: Part 2 - Sinkronisasi Waktu Server dengan NTP (Chrony)

Muhammad Dhiyaul Atha — Thu, 11 Jun 2026 13:26:59 +0000

Setelah berhasil melakukan konfigurasi dasar pada Main Server di Part 1, langkah krusial selanjutnya sebelum mengonfigurasi Active Directory (ADDS) adalah memastikan waktu pada sistem server benar-benar akurat. Artikel ini akan membahas langkah demi langkah instalasi dan konfigurasi NTP (Network Time Protocol) menggunakan Chrony di Ubuntu Server 26.04.

1. Teori Dasar: Mengapa NTP Sangat Krusial Sebelum ADDS?

Banyak administrator jaringan pemula melewatkan konfigurasi NTP dan langsung melompat ke instalasi Active Directory. Hal ini sering kali berujung pada kegagalan sistem yang membingungkan.

Protokol Kerberos: Active Directory Domain Services (ADDS) menggunakan protokol Kerberos untuk proses autentikasi keamanan. Kerberos menggunakan stempel waktu (timestamp) untuk mencegah serangan siber jenis replay attacks.
Toleransi Batas Waktu (Time Skew): Secara bawaan, Kerberos membatasi perbedaan waktu maksimal antara Domain Controller, server, dan komputer client sebesar 5 menit. Jika perbedaan waktu melebihi ambang batas ini, proses login user, replikasi database domain, hingga proses Join Domain pada komputer klien akan pasti ditolak dan gagal.

Oleh karena itu, server harus bertindak sebagai sumber waktu yang andal (NTP Server) bagi seluruh perangkat di dalam jaringan a3n4.com.

2. Sintaks & Langkah Konfigurasi

Pastikan Anda sudah berada di terminal Ubuntu Server 26.04 dengan hak akses root:

sudo su

Langkah A: Menonaktifkan NTP Bawaan Ubuntu

Secara bawaan, Ubuntu menggunakan layanan systemd-timesyncd untuk sinkronisasi waktu internal. Karena kita ingin server ini bertindak sebagai NTP Server mandiri (melayani request dari jaringan lokal), kita harus mematikan layanan bawaan tersebut.

timedatectl set-ntp off

Langkah B: Instalasi Chrony

Chrony adalah aplikasi NTP modern yang sangat direkomendasikan untuk Linux karena proses sinkronisasinya yang lebih cepat dan presisi dibanding daemon NTP lama.

apt update && apt install chrony -y

Langkah C: Konfigurasi Chrony Server

Buka dan edit file konfigurasi utama Chrony menggunakan nano:

nano /etc/chrony/chrony.conf

Tambahkan baris berikut di bagian bawah file untuk mengizinkan jaringan lokal 192.168.190.0/24 menyalin waktu dari server ini, serta memaksa server tetap memberikan waktu meskipun koneksi internet terputus:

allow 192.168.190.0/24
local stratum 10

Simpan file (Ctrl + O, lalu Enter) dan keluar (Ctrl + X).

Langkah D: Restart & Aktivasi Layanan

Terapkan konfigurasi baru dengan merestart layanan Chrony dan pastikan statusnya berjalan otomatis saat booting.

systemctl enable chrony
systemctl restart chrony
systemctl status chrony

3. Pengujian & Verifikasi

Langkah A: Memeriksa Port NTP (123)

NTP berjalan di atas protokol UDP port 123. Pastikan socket port tersebut sudah terbuka dan didengarkan (listen) oleh Chrony.

ss -unlp | grep 123

Langkah B: Verifikasi Sumber Waktu & Pelacakan

Pastikan Chrony sukses terhubung ke server waktu publik di internet untuk menyinkronkan jam internalnya.

chronyc sources
chronyc tracking

Kesimpulan

Dengan menyelesaikan konfigurasi NTP menggunakan Chrony, kita telah memastikan bahwa jam internal pada Ubuntu Server 26.04 berjalan dengan akurasi tinggi dan siap melayani permintaan sinkronisasi dari komputer client. Sinkronisasi waktu ini meminimalkan risiko kegagalan otentikasi di masa mendatang.

Apa Selanjutnya?

Waktu server sudah akurat dan siap. Di artikel berikutnya (Part 3), kita akan masuk ke tahap paling krusial dari seluruh proyek ini: Membangun Active Directory Domain Services (ADDS) menggunakan Samba untuk menginisiasi domain utama kita, a3n4.com.

Baca Part 3: Membangun Active Directory Domain Controller (ADDS) dengan Samba ➡️

Membangun Infrastruktur Enterprise: Part 1 - Konfigurasi Main Server (Ubuntu Server 26.04)

Muhammad Dhiyaul Atha — Thu, 11 Jun 2026 13:24:34 +0000

Sebelum melangkah ke layanan kompleks seperti Active Directory atau VPN, kita wajib membangun pondasinya terlebih dahulu. Artikel ini akan membahas langkah demi langkah instalasi dasar, konfigurasi IP Statis, penyelarasan hostname, dan update sistem pada Ubuntu Server 26.04 di lingkungan VirtualBox dengan target nama domain utama: a3n4.com.

1. Teori Dasar: Mengapa "Main Server" Harus Benar?

Sebuah Main Server yang akan mengemban tugas sebagai Domain Controller (ADDS), DNS, dan DHCP tidak boleh memiliki konfigurasi yang berubah-ubah.

IP Statis (Static IP): Jika server menggunakan DHCP (IP dinamis), ketika server reboot dan IP-nya berubah, seluruh komputer client di jaringan akan kehilangan koneksi ke DNS dan Domain Controller.
Fully Qualified Domain Name (FQDN): Identitas server harus jelas (contoh: server.a3n4.com). Tanpa FQDN yang valid, layanan berbasis Kerberos seperti ADDS akan mengalami error resolusi nama.
Topologi VirtualBox: Demi kelancaran lab ini, pastikan Pengaturan Jaringan (Network Settings) pada VM Ubuntu Server dan Ubuntu Client Anda di VirtualBox diatur ke Internal Network (atau Bridged Adapter jika lab Anda membutuhkan akses internet langsung dari router fisik).

2. Sintaks & Langkah Konfigurasi

Pastikan Anda sudah masuk ke terminal Ubuntu Server 26.04 sebagai root:

sudo su

Langkah A: Pembaruan Repositori & Sistem

Sebelum menyentuh konfigurasi, pastikan semua paket sistem berada di versi terbaru dan paling stabil.

apt update && apt upgrade -y

Langkah B: Konfigurasi IP Statis (Netplan)

Ubuntu 26.04 menggunakan Netplan untuk manajemen jaringan. Cari nama file konfigurasi Anda di direktori /etc/netplan/:

ls /etc/netplan/

(Biasanya bernama 50-cloud-init.yaml atau 01-netcfg.yaml). Edit file tersebut menggunakan teks editor nano:

nano /etc/netplan/50-cloud-init.yaml

Ubah atau sesuaikan isinya menjadi seperti ini. Pada lingkungan VirtualBox, nama interface umumnya terdeteksi sebagai enp0s3. (Penting: Gunakan indentasi 2 atau 4 spasi, jangan gunakan tombol TAB karena YAML sangat sensitif terhadap spasi):

network:
  version: 2
  renderer: networkd
  ethernets:
    enp0s3: # Sesuaikan dengan nama interface VirtualBox Anda (cek via 'ip a')
      dhcp4: no
      addresses:
        - 192.168.190.50/24
      routes:
        - to: default
          via: 192.168.190.2 # Sesuaikan dengan IP Gateway internal VirtualBox Anda
      nameservers:
        addresses:
          - 8.8.8.8
          - 1.1.1.1

Simpan file (Ctrl + O, lalu Enter) dan keluar (Ctrl + X). Terapkan konfigurasi baru tersebut:

netplan apply

Langkah C: Konfigurasi Hostname & FQDN

Sekarang kita ubah nama server kita menjadi server dan memetakannya ke domain a3n4.com.

hostnamectl set-hostname server
nano /etc/hosts

Tambahkan atau ubah baris di dalam file /etc/hosts sehingga menjadi seperti ini:

127.0.0.1   localhost
192.168.190.50  server.a3n4.com  server

3. Pengujian & Verifikasi

Untuk memastikan konfigurasi dasar ini tidak bermasalah, lakukan pengujian berikut:

Cek IP Address:

ip a s enp0s3

Uji Koneksi Jaringan:

ping -c 3 192.168.190.2

(Ganti dengan IP gateway Anda, atau gunakan google.com jika menggunakan mode Bridged)

Cek FQDN (Resolusi Hostname):

hostname -f

Kesimpulan

Dengan menyelesaikan konfigurasi Main Server ini, kita telah berhasil mengamankan alamat IP statis 192.168.190.50 dan memberikan identitas FQDN server.a3n4.com di dalam lingkungan VirtualBox. Server kini dalam kondisi prima dan siap dipasangi layanan tingkat lanjut tanpa khawatir terjadi konflik jaringan atau perubahan IP dinamis.

Apa Selanjutnya?

Sebuah server enterprise tidak akan bisa berjalan jika waktunya melenceng, karena sistem keamanan domain (terutama protokol Kerberos pada ADDS) sangat bergantung pada sinkronisasi waktu. Di artikel berikutnya (Part 2), kita akan membahas bagaimana mengonfigurasi NTP (Network Time Protocol) menggunakan Chrony serta melakukan pengujian langsung menggunakan Ubuntu Client.

Baca Part 2: Sinkronisasi Waktu Server dengan NTP (Chrony) ➡️

Step-by-Step Deployment Active Directory (AD DS) pada Windows Server 2025 via PowerShel

Muhammad Dhiyaul Atha — Fri, 15 May 2026 15:20:57 +0000

Banyak orang masih menggunakan GUI untuk mengonfigurasi Windows Server. Padahal, menggunakan PowerShell jauh lebih cepat, ringan, dan minim error navigasi. Di artikel ini, saya akan membagikan alur praktikum saya dalam membangun Forest baru imsak.com di Windows Server 2025 sepenuhnya menggunakan terminal.

Environment Praktikum

Platform: VirtualBox (Internal Network)
OS: Windows Server 2025
Target Domain: imsak.com
Static IP: 172.20.80.10

Tahapan Konfigurasi

1. Identitas Server (Hostname)

Langkah pertama adalah mengubah nama komputer agar lebih mudah dikenali dalam jaringan forest. Di sini saya mengubahnya menjadi A3N4.

Rename-Computer -NewName "A3N4" -Restart

2. Networking: Static IP & DNS Loopback

Domain Controller wajib memiliki IP statis. Selain itu, DNS harus diarahkan ke 127.0.0.1 (loopback) karena server ini sendiri yang akan mengelola record DNS domain.

# Mengatur IP Statis
New-NetIPAddress -InterfaceIndex 3 -IPAddress 172.20.80.10 -PrefixLength 24 -DefaultGateway 172.20.80.1

# Mengatur DNS ke Loopback
Set-DnsClientServerAddress -InterfaceIndex 3 -ServerAddresses ("127.0.0.1")

3. Instalasi Fitur AD DS

Sebelum bisa mempromosikan server menjadi DC, kita perlu memasang binary dan modul manajemen Active Directory.

Install-WindowsFeature -Name AD-Domain-Services -IncludeManagementTools

4. Membangun Forest Baru (Promosi Domain)

Ini adalah inti dari praktikum. Kita akan membuat Forest baru bernama imsak.com.

Install-ADDSForest -DomainName "imsak.com" -DomainNetbiosName "IMSAK" -InstallDns:$true -Force

Setelah perintah dijalankan, masukkan **SafeModeAdministratorPassword* yang kuat. Sistem akan otomatis melakukan restart setelah proses selesai.*

Verifikasi & Pengujian

Setelah server aktif kembali, kita perlu memastikan semuanya berjalan normal.

5. Cek Login Otoritas

Pastikan user yang masuk adalah user domain.

whoami
# Output: imsak\administrator

6. Resolusi Nama DNS

Tes apakah DNS sudah mengenali domain baru kita.

Resolve-DnsName imsak.com

7. Status Layanan (Health Check)

Memastikan layanan utama AD DS (NTDS, DNS, ADWS) sudah berstatus Running.

Get-Service adws,dns,ntds | Select-Object Name, Status

Kesimpulan

Deploy Active Directory di Windows Server 2025 via PowerShell memberikan pengalaman manajemen server yang lebih profesional. Dengan mengikuti alur yang terstruktur, kita bisa meminimalisir kesalahan konfigurasi dan mempercepat proses deployment.

Apakah kamu punya kendala saat mencoba Windows Server 2025? Yuk diskusi di kolom komentar!

Implementasi Kea DHCPv4 pada RHEL 10: Solusi Modern Pengelolaan Jaringan

Muhammad Dhiyaul Atha — Thu, 30 Apr 2026 11:31:39 +0000

1. Pendahuluan

Kea mulai diadopsi sebagai pengganti ISC DHCP dengan arsitektur yang lebih modern. Kea menawarkan performa lebih tinggi dan struktur konfigurasi berbasis JSON yang lebih modular. Artikel ini mendokumentasikan langkah-langkah konfigurasi Kea di lingkungan virtual (VirtualBox) dengan client Windows 10.

2. Topologi & Skenario Jaringan

Server (RHEL 10):
- Adapter 1: NAT (Akses Internet)
- Adapter 2: Internal Network (enp0s8) - IP Statis: 10.0.2.1
Client (Windows 10):
- Adapter 1: Internal Network - DHCP Client

3. Konfigurasi Interface Server

Sebelum menjalankan Kea, interface yang mengarah ke client harus memiliki IP statis.

# Menambahkan IP statis ke interface internal
sudo ip addr add 10.0.2.1/24 dev enp0s8
sudo ip link set enp0s8 up

4. Konfigurasi Kea DHCPv4

Edit file /etc/kea/kea-dhcp4.conf. Fokus utama adalah mengarahkan interfaces ke enp0s8 dan menentukan pools alamat IP.

"Dhcp4": {
    "interfaces-config": {
        "interfaces": [ "enp0s8" ]
    },
    "lease-database": {
        "type": "memfile",
        "name": "/var/lib/kea/kea-leases4.csv"
    },
    "subnet4": [
        {
            "subnet": "10.0.2.0/24",
            "pools": [ { "pool": "10.0.2.100 - 10.0.2.200" } ],
            "option-data": [
                { "name": "routers", "data": "10.0.2.1" },
                { "name": "domain-name-servers", "data": "8.8.8.8, 8.8.4.4" }
            ]
        }
    ]
}

5. Keamanan & Aktivasi Service

Membuka port DHCP pada firewall dan merestart service Kea.

# Konfigurasi Firewall
sudo firewall-cmd --add-service=dhcp --permanent
sudo firewall-cmd --reload

# Restart Service
sudo systemctl restart kea-dhcp4

6. Pengujian pada Client

Pada client Windows 10, lakukan pembaruan IP melalui Command Prompt.

ipconfig /release
ipconfig /renew

7. Analisis Log & Database Lease

Verifikasi terakhir adalah memeriksa apakah server mencatat penyewaan IP tersebut dalam database lokal.

# Melihat log aktivitas DORA secara real-time
sudo journalctl -u kea-dhcp4 -f

# Melihat database penyewaan IP
sudo cat /var/lib/kea/kea-leases4.csv

Kesimpulan

Keberhasilan implementasi Kea DHCP sangat bergantung pada ketepatan penentuan interface fisik dan pengaturan IP statis pada sisi server. Dengan berpindah ke Kea, administrator jaringan mendapatkan kontrol lebih baik melalui struktur data JSON yang rapi.

Setup Identity Management (FreeIPA) di RHEL 10: Fondasi Infrastruktur Server Terpusat

Muhammad Dhiyaul Atha — Wed, 29 Apr 2026 15:21:59 +0000

Di lingkungan enterprise, manajemen identitas terpusat adalah komponen penting untuk menjaga keamanan dan skalabilitas sistem. Jika di ekosistem Windows kita mengenal Active Directory Domain Services (AD DS), maka di dunia Linux tersedia solusi setara yaitu Identity Management (IdM) berbasis FreeIPA.

Pada artikel ini, saya akan membagikan pengalaman melakukan deployment FreeIPA di RHEL 10, lengkap dengan troubleshooting yang saya temui.

1. Environment Setup

Untuk tutorial ini, saya menggunakan spesifikasi sistem berikut agar performa Identity Management tetap stabil:

OS: Red Hat Enterprise Linux 10.
Hardware: Laptop dengan Intel i7-14650HX dan RTX 4050.
Network: Pastikan sistem menggunakan IP statis.

2. The FQDN Rule: Don't Get Stuck!

Salah satu syarat wajib untuk setup "AD DS" versi Linux ini adalah penggunaan Fully Qualified Domain Name (FQDN). Installer tidak akan menerima nama tunggal karena sistem identitas seperti Kerberos membutuhkan domain yang lengkap.

Masalah: Menggunakan nama seperti atha akan memicu error must be fully-qualified.
Solusi: Set hostname dengan format <hostname>.<domain>:
```
sudo hostnamectl set-hostname server.atha.local
```

3. Step-by-Step Installation

Gunakan perintah berikut untuk memulai instalasi server beserta DNS-nya. Saya sangat menyarankan menentukan forwarder secara eksplisit untuk menghindari masalah resolusi.

sudo ipa-server-install --setup-dns --forwarder=1.1.1.1 --forwarder=1.0.0.1

Tips Tambahan:

NetBIOS: Default-nya adalah ATHA, ini berguna untuk integrasi dengan sistem Windows.
NTP: Biarkan menggunakan pool bawaan sistem kecuali Anda memiliki server waktu khusus.

4. Troubleshooting: Belajar dari Kesalahan

Selama proses sharing ini, ada beberapa kendala yang sempat saya alami dan bisa menjadi pelajaran buat teman-teman:

DNS Timeout: Jika installer gagal saat validasi forwarder, biasanya ada masalah pada kueri IPv6 di jaringan Anda. Menggunakan flag --forwarder manual adalah solusinya.
The "yes" Confirmation: Jangan terkecoh di akhir ringkasan konfigurasi. Sistem menunggu input yes secara eksplisit. Jika hanya ditekan Enter, instalasi akan otomatis batal (Aborted).

5. Final Steps & Verification

Setelah instalasi selesai, buka akses layanan pada firewall agar sistem berjalan lancar:

sudo firewall-cmd --add-service={freeipa-ldap,freeipa-ldaps,dns,ntp,http,https,kerberos} --permanent
sudo firewall-cmd --reload

Gunakan perintah kinit admin untuk memverifikasi tiket Kerberos Anda.

Membangun sistem identitas terpusat dengan FreeIPA memberikan kontrol penuh atas keamanan jaringan. Sebagai mahasiswa Teknik Informatika yang fokus pada Backend dan Security, pemahaman ini sangat membantu saya dalam mengelola infrastruktur server yang lebih profesional.

Semoga tutorial ini bermanfaat bagi teman-teman yang juga sedang mengulik ekosistem RHEL!

DEV Community: Muhammad Dhiyaul Atha

EcoID: An Offline Plant Identifier That Gets You Outside

What I Built

Demo

Code

How I Built It

Local image preprocessing

Open-source AI and local inference

Training results

Human verification

Offline storage

Performance

Testing

Why Does Open Innovation Matter?

Limitations and Next Steps

My Agent Session

Prize Categories

UnvibeComplex Code to Real Workflows: Finding and Fixing a Secret-Handling Boundary Bug in UnvibeCode

From CI/CD Secrets to External APIs: Finding a Boundary Bug in UnvibeCode

Tracing the Secret Flow

1. The Secret Is Passed by the Workflow

2. The Python Script Reads the Secret

3. The Secret Is Lost When the Request Is Built

Why Is This Bug Easy to Miss?

Why Didn't the Existing Tests Catch It?

Recommended Fix

Engineering Lessons

1. A Secret Being Available Does Not Mean It Is Being Used

2. Test the External Boundary, Not Just Internal Logic

3. Never Print Secrets for Debugging

4. Analysis Tools Help Trace the Path, but They Do Not Replace Verification

Conclusion

References

[Boost]

Building a Privacy-First AI CRM Assistant for My Friend's Business

Building a Privacy-First AI CRM Assistant for My Friend's Business

What I Built

Demo

Code

How I Built It

Human-in-the-Loop

Why Does Open Innovation Matter?

Data Privacy

Cost Control

Control and Predictability

Conclusion

My Hacktoberfest 2026 Journey: Contributing to DevOps Daily

Day 1: Registering as an Expert on DevOps Daily

1. Creating the JSON Profile

2. Preparing the Avatar

3. Local Testing

4. Opening the Pull Request (PR)

Day 2: Contributing a Favorite DevOps Tool (Lazydocker)

1. Choosing the Tool

2. Modifying app/toolbox/page.tsx

3. Submitting the Second PR

Day 3: Adding a Quiz Question to the Linux Quiz

1. Selecting the Quiz File

2. Drafting the Question & Updating Metadata

3. Local Testing & Validation

4. Opening the Pull Request (PR)

Day 4: Adding Flashcards to Linux Fundamentals

1. Selecting the Flashcard Set

2. Drafting and Adding the Flashcards

3. Local Testing & Preview

4. Opening the Pull Request (PR)

Day 5: Sharing a Practical DevOps Gotcha on CI/CD Security

1. Choosing the Right Article to Improve

2. Drafting the Gotcha Section

3. Verifying and Isolating the Branch

4. Committing and Opening the Pull Request

Conclusion

My Experience Deploying Projects Smoothly with Tencent EdgeOne Makers

Why Tencent EdgeOne Makers Stands Out

Getting Started and Deployment Experience

Three Bugs That Almost Killed My Honeypot Before It Ever Caught Anyone

Bug #1: The Worker That Attacked Itself

Bug #2: The Detector That Never Detected Path Attacks

Bug #3: The Watermark That Lied

What Actually Changed My Process

2. Modifying `app/toolbox/page.tsx`