Forem: Emmanuel Akanji

[Boost]

Emmanuel Akanji — Fri, 22 May 2026 10:42:50 +0000

Emmanuel Akanji

May 21

The Next AI Agent Failure Won't Be a Hallucination. It Will Be a Payment.

#ai #agents #beginners #tutorial

Comments

5 min read

The Next AI Agent Failure Won't Be a Hallucination. It Will Be a Payment.

Emmanuel Akanji — Thu, 21 May 2026 15:17:16 +0000

The first generation of AI agent failures were funny.

The agent booked the wrong restaurant. The agent summarized a document badly. The agent called the wrong internal tool. The agent got stuck in a loop and wasted tokens.

The next generation will not be funny.

An agent will retry a failed payment and double-pay.

An agent will get prompt-injected into funding the wrong recipient.

An agent will use a tool it should never have had access to.

An agent will spend outside its mandate, and the team deploying it will not be able to prove who authorized the action, what policy was checked, or why the transaction was allowed.

That is the moment AI agents stop being a demo problem and become an infrastructure problem.

For the last few months, we have been building Veridex Agent Fabric for that exact moment.

Not another chatbot wrapper. Not another prompt orchestration library. A TypeScript-first agent runtime and safety stack for agents that use tools, request funds, transact across rails, and need to stay inside explicit authority boundaries.

Because the hard part of agentic payments is not making an API call.

The hard part is answering six questions every time an agent tries to do something consequential:

Who authorized this agent?
What is it allowed to do?
How much can it spend?
Which recipient, rail, protocol, and purpose are in scope?
What happens if the model is attacked, confused, or retries?
What evidence exists after the fact?

Most agent frameworks treat this as application logic.

We think it belongs in the runtime.

What We Built

Veridex Agent Fabric is a package family for building and operating payment-capable agents.

The core package is @veridex/agents: a typed runtime for model-agnostic agents with tool contracts, safety classes, memory/context compilation, checkpoints, resumable runs, policies, approvals, trace events, and MCP / ACP / A2A transport surfaces.

That runtime sits next to packages built for the parts most teams postpone until it is too late:

@veridex/agent-security protects against prompt injection, tool poisoning, secret exfiltration, runaway spend, and MCP-style agent threats.
@veridex/agents-treasury adds the primitives required for safe money movement: idempotency, spend ceilings, time-locks, sanctions screening, dual approval, signed evidence bundles, and red-team evaluations.
@veridex/agents-control-plane gives teams tenant isolation, policy packs, approval workflows, trace retention, audit export, remote APIs, and shared persistence.
@veridex/agentic-payments gives agents identity, trust-gated payments, policy-gated execution, and multi-chain signing across the agentic payment protocol landscape.
@veridex/agents-adapters lets teams bring existing systems with them: OpenAI Agents SDK, LangGraph, PydanticAI, and OpenAPI-described tools.
@veridex/agents-react exposes runtime state, approvals, traces, memory, budgets, identity, and payment state to frontend teams.

The point is not to force every developer into one framework.

The point is to make the dangerous parts explicit: tools, authority, policy, approval, memory, payment, evidence, and recovery.

Why Existing Agent Stacks Break at Money

If an agent only summarizes documents, a bad tool call is annoying.

If an agent moves money, provisions infrastructure, signs a quote, or funds a counterparty, a bad tool call is an incident.

A normal agent framework asks: did the model call the tool correctly?

A payment-capable runtime has to ask more:

Is this tool read-only, write-capable, networked, privileged, or financial?
Does this agent have permission to call it?
Does this input match the schema?
Is the requested amount inside policy?
Is the recipient in scope?
Is this a retry of a previous action?
Does it require approval?
Can the run be suspended and resumed safely?
Can an auditor reconstruct the decision later?

That is why we built the runtime around proposals rather than blind execution.

Every consequential action should pass through policy. High-risk actions should escalate. Every retry should be idempotent. Every approval should be recorded. Every payment should produce evidence.

Not because it looks good in a deck.

Because this is how you stop an autonomous system from becoming an autonomous liability.

The Core Design Principle: Authority Should Only Narrow

When an agent delegates to another agent, calls a remote tool, opens a session, or proposes a payment, its authority should never silently expand.

It should narrow.

A parent agent can create a child agent with fewer tools, tighter budgets, shorter time windows, stricter approval thresholds, and narrower recipient scope.

A payment session can be scoped to one counterparty, one protocol, one purpose, one amount ceiling, and one expiry.

A tool can declare its safety class before it ever executes.

A policy pack can deny a transaction before the model gets another chance to rationalize it.

This is the difference between "the agent has a wallet" and "the agent has bounded authority."

The first is convenient.

The second is deployable.

Evidence Is the Product

The most underrated part of agent infrastructure is evidence.

Enterprises do not just need an agent to complete a task. They need to explain what happened when something goes wrong.

For a payment-capable agent, an evidence trail should include:

the user's original authorization
the agent identity and session scope
the proposed action
the tool or payment rail involved
the policy version checked
the approval decision
the idempotency key
the execution result
the final settlement state

This is why Veridex treats trace events and evidence bundles as first-class runtime outputs.

A payment without evidence is just a transaction.

A payment with evidence is an operation a business can govern.

Proof Implementation: Trading Fabric

We built Trading Fabric as a proof implementation on top of the agent framework.

It is a multi-agent trading system: market, news, sentiment, and fundamentals analysts produce reports; bull and bear researchers debate; a risk committee evaluates; a portfolio manager makes a decision; execution can be simulated through paper trading on Sera testnet.

Repository:
https://github.com/Veridex-Protocol/trading-fabric

The point of Trading Fabric is not that every customer needs a trading agent.

The point is that it exercises the architecture:

multiple specialized agents
tool-calling analysts
structured outputs
audit trails
policy-gated decisions
execution envelopes
run artifacts
human-readable reports
replayable state

Agents that transact need more than clever prompts. They need systems that can be inspected, replayed, and constrained.

Trading Fabric is one example of that pattern.

The Framework Is Opening Up

We are preparing to open-source more of the framework and invite builders to test it.

If you are building agents that need to pay for compute, buy services, manage subscriptions, request quotes, handle treasury operations, or interact with financial rails, we want feedback from the sharp edges.

Docs:
https://docs.veridex.network/agent-fabric/overview
https://docs.veridex.network/guides/veridex-agents
https://docs.veridex.network/guides/agent-payments

Examples:
https://github.com/Veridex-Protocol/examples/tree/main/agents-gemini

Core package:
https://www.npmjs.com/package/@veridex/agents

The agent economy will not be built by giving every model a wallet and hoping policy happens somewhere else.

It will be built by making authority explicit, execution scoped, security default, and evidence unavoidable.

That is what we are building with Veridex Agent Fabric.

If you are building payment-capable agents and want to test it, reach out.

The Agentic Payment Protocol Wars

Emmanuel Akanji — Thu, 21 May 2026 15:14:09 +0000

X402 vs UCP vs ACP vs AP2 And Why the Answer Isn't Picking a Winner

I've spent the last year integrating every major agentic payment protocol into a single SDK. Not studying them from the outside actually writing the adapter code, handling the edge cases, debugging the interop failures.

Here's what the landscape actually looks like from the inside, and why the fragmentation problem is worse than most people realize.

The Protocols

x402: Coinbase (HTTP 402 Micropayments)

What it does: Resurrects the HTTP 402 status code. Server returns 402 Payment Required with a payment header. Client pays via stablecoin (USDC on Base). Server verifies payment, serves content.

How it works:

Agent requests resource → Server returns 402 + payment requirements
Agent constructs stablecoin transaction
Agent submits payment proof in retry request
Server verifies on-chain, serves resource

Strengths: Elegant. Simple. Native to HTTP. Works with any web resource.

Weaknesses: Only stablecoins on Base (expanding, but limited). Micropayment-focused, not designed for complex commerce flows. No negotiation phase, the price is the price.

Our integration: ProtocolDetector identifies 402 responses and auto-constructs payment transactions. Works out of the box.

UCP: Google/Shopify (Universal Commerce Protocol)

What it does: Commerce orchestration. The counterparty describes what it can do ("I sell API calls, compute time, and data feeds"), and the agent negotiates terms.

How it works:

Agent discovers UCP-enabled service → service publishes capabilities
Agent and service negotiate (quantity, pricing, terms)
Agreement reached → payment executed
Service delivers

Strengths: Flexible. Supports discovery, negotiation, and complex multi-item transactions. Agent can compare services and shop around.

Weaknesses: Complex. The negotiation phase adds latency. Requires both parties to implement the full UCP spec, not a drop-in for existing APIs.

Our integration: ProtocolDetector identifies UCP capability endpoints. The AgentWallet handles the negotiation loop. Policy checks apply at each stage.

ACP: OpenAI/Stripe (Agent Commerce Protocol)

What it does: Structured transaction format. The service presents a cart ("here's what you're buying, here's the price"), the agent confirms and pays.

How it works:

Service presents SharedPaymentToken with cart contents
Agent validates cart against policy
Agent authorizes payment
Service fulfills

Strengths: Familiar (it's basically Stripe Checkout for agents). Already live in ChatGPT. Strong backing from OpenAI + Stripe.

Weaknesses: Rigid. No negotiation, you accept the cart or you don't. Vendor-locked to the OpenAI/Stripe ecosystem in practice. The SharedPaymentToken format is specific to ACP.

Our integration: ProtocolDetector identifies ACP token formats. Policy evaluation occurs pre-authorization. Evidence bundle includes cart contents and authorization proof.

AP2: Google (Agent Payment Protocol v2)

What it does: Cryptographically signed delegation mandates. The principal (human/company) creates a W3C Verifiable Credential that authorizes the agent to spend up to $X on category Y.

How it works:

Principal creates signed delegation mandate (VC format)
Agent presents mandate to service
Service verifies the signature chain
Transaction executes within mandate bounds

Strengths: Strongest authorization model. The mandate is a cryptographic proof of delegation, not just a session token. Supports nested delegation (agent A delegates to agent B within tighter bounds).

Weaknesses: Complex credential management. Requires VC infrastructure. Not widely adopted yet. The specification is still evolving.

Our integration: ProtocolDetector identifies AP2 mandate presentations. Session key bounds are mapped to mandate constraints for interop.

MPP: Session-Based Budget Allocation

What it does: Pre-allocated budget pools that agents can draw from within defined bounds.

How it works:

Principal allocates a budget pool (e.g., 1000 USDC for this session)
Agent operates within pool bounds
Each transaction decrements the pool
Session ends → remaining funds returned

Strengths: Simplest model for bounded spending. No per-transaction authorization needed once the pool is set.

Weaknesses: No protocol negotiation, assumes the payment method is already agreed. Coarse-grained control.

Our integration: MPP is native to Veridex, this is essentially what our session key system does at the protocol level.

The Fragmentation Problem

Here's the reality in April 2026:

Coinbase-ecosystem services speak x402
Google-ecosystem services speak UCP or AP2
OpenAI-ecosystem services speak ACP
Crypto-native services speak MPP or raw transactions
Most services speak none of these yet

An AI agent that only speaks one protocol can only transact with services in that ecosystem. An agent that, speaks all five can transact with anyone.

But no developer wants to integrate five protocols. The protocol-specific code is complex, each has different discovery mechanisms, different negotiation flows, different payment formats, different verification methods.

Why We Built ProtocolDetector

ProtocolDetector in @veridex/agentic-payments solves this:

const wallet = await createAgentWallet({ ... });

// Developer writes this ONE integration:
const result = await wallet.pay({
  recipient: 'https://api.example.com/resource',
  amount: '5.00',
  currency: 'USDC',
});

// ProtocolDetector handles:
// 1. Probe the endpoint → detect which protocol(s) it supports
// 2. Select the optimal protocol based on cost, speed, and agent policy
// 3. Execute the protocol-specific flow
// 4. Generate a unified evidence bundle regardless of protocol used

One API. Five protocols underneath. The developer never writes protocol-specific code.

My Take

The protocol wars won't produce a single winner. Not in 2026, probably not ever.

x402 will dominate micropayments and API monetization (it's too elegant not to)
ACP will dominate the OpenAI ecosystem (they have distribution)
UCP will dominate complex commerce (Google + Shopify is a powerful combo)
AP2 will dominate enterprise delegation (cryptographic mandates are what compliance needs)
MPP will remain the default for session-based budgets

The answer isn't picking a winner. It's building the abstraction layer that speaks all of them.

That's what @veridex/agentic-payments does. 257 tests. 5 protocols. 1 API.

This analysis is based on our Agentic Payments Protocol Map research paper, which maps the full protocol landscape including AXTP, VIC, MAP, and the trust/identity prerequisites (ERC-8004, Visa TAP). Full paper available on request.

If you're building agents that need to transact across protocol ecosystems, the SDK is open: npm install @veridex/agentic-payments

The Agentic Payment Protocol Wars

Emmanuel Akanji — Thu, 21 May 2026 15:12:13 +0000

X402 vs UCP vs ACP vs AP2, And Why the Answer Isn't Picking a Winner

Here's what the landscape actually looks like from the inside, and why the fragmentation problem is worse than most people realize.

The Protocols

x402: Coinbase (HTTP 402 Micropayments)

What it does: Resurrects the HTTP 402 status code. Server returns 402 Payment Required with a payment header. Client pays via stablecoin (USDC on Base). Server verifies payment, serves content.

How it works:

Agent requests resource → Server returns 402 + payment requirements
Agent constructs stablecoin transaction
Agent submits payment proof in retry request
Server verifies on-chain, serves resource

Strengths: Elegant. Simple. Native to HTTP. Works with any web resource.

Weaknesses: Only stablecoins on Base (expanding, but limited). Micropayment-focused, not designed for complex commerce flows. No negotiation phase, the price is the price.

Our integration: ProtocolDetector identifies 402 responses and auto-constructs payment transactions. Works out of the box.

UCP: Google/Shopify (Universal Commerce Protocol)

What it does: Commerce orchestration. The counterparty describes what it can do ("I sell API calls, compute time, and data feeds"), and the agent negotiates terms.

How it works:

Agent discovers UCP-enabled service → service publishes capabilities
Agent and service negotiate (quantity, pricing, terms)
Agreement reached → payment executed
Service delivers

Strengths: Flexible. Supports discovery, negotiation, and complex multi-item transactions. Agent can compare services and shop around.

Weaknesses: Complex. The negotiation phase adds latency. Requires both parties to implement the full UCP spec, not a drop-in for existing APIs.

Our integration: ProtocolDetector identifies UCP capability endpoints. The AgentWallet handles the negotiation loop. Policy checks apply at each stage.

ACP: OpenAI/Stripe (Agent Commerce Protocol)

What it does: Structured transaction format. The service presents a cart ("here's what you're buying, here's the price"), the agent confirms and pays.

How it works:

Service presents SharedPaymentToken with cart contents
Agent validates cart against policy
Agent authorizes payment
Service fulfills

Strengths: Familiar (it's basically Stripe Checkout for agents). Already live in ChatGPT. Strong backing from OpenAI + Stripe.

Weaknesses: Rigid. No negotiation you accept the cart or you don't. Vendor-locked to the OpenAI/Stripe ecosystem in practice. The SharedPaymentToken format is specific to ACP.

Our integration: ProtocolDetector identifies ACP token formats. Policy evaluation occurs pre-authorization. Evidence bundle includes cart contents and authorization proof.

AP2: Google (Agent Payment Protocol v2)

What it does: Cryptographically signed delegation mandates. The principal (human/company) creates a W3C Verifiable Credential that authorizes the agent to spend up to $X on category Y.

How it works:

Principal creates signed delegation mandate (VC format)
Agent presents mandate to service
Service verifies the signature chain
Transaction executes within mandate bounds

Strengths: Strongest authorization model. The mandate is a cryptographic proof of delegation — not just a session token. Supports nested delegation (agent A delegates to agent B within tighter bounds).

Weaknesses: Complex credential management. Requires VC infrastructure. Not widely adopted yet. The specification is still evolving.

Our integration: ProtocolDetector identifies AP2 mandate presentations. Session key bounds are mapped to mandate constraints for interop.

MPP: Session-Based Budget Allocation

What it does: Pre-allocated budget pools that agents can draw from within defined bounds.

How it works:

Principal allocates a budget pool (e.g., 1000 USDC for this session)
Agent operates within pool bounds
Each transaction decrements the pool
Session ends → remaining funds returned

Strengths: Simplest model for bounded spending. No per-transaction authorization needed once the pool is set.

Weaknesses: No protocol negotiation assumes the payment method is already agreed. Coarse-grained control.

Our integration: MPP is native to Veridex — this is essentially what our session key system does at the protocol level.

The Fragmentation Problem

Here's the reality in April 2026:

Coinbase-ecosystem services speak x402
Google-ecosystem services speak UCP or AP2
OpenAI-ecosystem services speak ACP
Crypto-native services speak MPP or raw transactions
Most services speak none of these yet

An AI agent that only speaks one protocol can only transact with services in that ecosystem. An agent that speaks all five can transact with anyone.

Why We Built ProtocolDetector

ProtocolDetector in @veridex/agentic-payments solves this:

const wallet = await createAgentWallet({ ... });

// Developer writes this ONE integration:
const result = await wallet.pay({
  recipient: 'https://api.example.com/resource',
  amount: '5.00',
  currency: 'USDC',
});

// ProtocolDetector handles:
// 1. Probe the endpoint → detect which protocol(s) it supports
// 2. Select the optimal protocol based on cost, speed, and agent policy
// 3. Execute the protocol-specific flow
// 4. Generate a unified evidence bundle regardless of protocol used

One API. Five protocols underneath. The developer never writes protocol-specific code.

My Take

The protocol wars won't produce a single winner. Not in 2026, probably not ever.

x402 will dominate micropayments and API monetization (it's too elegant not to)
ACP will dominate the OpenAI ecosystem (they have distribution)
UCP will dominate complex commerce (Google + Shopify is a powerful combo)
AP2 will dominate enterprise delegation (cryptographic mandates are what compliance needs)
MPP will remain the default for session-based budgets

The answer isn't picking a winner. It's building the abstraction layer that speaks all of them.

That's what @veridex/agentic-payments does. 257 tests. 5 protocols. 1 API.

If you're building agents that need to transact across protocol ecosystems, the SDK is open: npm install @veridex/agentic-payments

[Boost]

Emmanuel Akanji — Sat, 28 Jun 2025 22:02:23 +0000

Aldorax

Jun 28 '25

Why We Built FlowSpec: A Better Way to Orchestrate AI Workflows

#ai #auvraai #programming

Comments

2 min read

Developing, Testing, and Deploying an ERC20 Token on Mantle Testnet using Hardhat and Ethers.js

Emmanuel Akanji — Mon, 12 Jun 2023 01:03:51 +0000

Introduction

In this article, we will guide you through the process of creating and deploying an ERC20 token called Mantlecoin (MTNL) on the Mantle blockchain using Hardhat and Ethers.js. We will cover the necessary prerequisites, environment settings, and provide a step-by-step guide on how to create, test, and deploy your token.

Mantle Blockchain: A Brief History and Overview

Mantle is a blockchain platform designed to provide a scalable and secure infrastructure for decentralized applications (dApps). It offers a unique set of features, including:

High throughput: Mantle's consensus algorithm allows for fast transaction processing and low latency, making it suitable for a wide range of applications.
Security: The platform employs advanced cryptographic techniques to ensure the security and integrity of the network.
Interoperability: Mantle supports cross-chain communication, enabling seamless interaction between different blockchain networks.
Developer-friendly: The platform provides a comprehensive set of tools and libraries to simplify the development and deployment of dApps.

Prerequisites

Node.js 14.8+ or higher
npm (version 6 or higher)
Basic knowledge of JavaScript

Additionally, to interact with the Mantle testnet, it is recommended to have some BIT tokens in your wallet. You can obtain BIT tokens by following the instructions provided by the Mantle testnet faucet.

Setting up the project

First, create a new directory for your project and navigate to it in your terminal. Then, run the following command to initialize a new Hardhat project:

npx hardhat init

This command will create a basic Hardhat project structure with the necessary files and folders.

Installing dependencies

Once you have set up your project, the next step is to install the necessary dependencies.

npm install --save-dev @nomiclabs/hardhat-ethers ethers @openzeppelin/contracts chai

Here's a breakdown of what each dependency represents:

@nomiclabs/hardhat-ethers: This is Hardhat's Ethers.js plugin, which provides integration between Hardhat and the Ethers.js library.

ethers: This library is an essential tool for interacting with Ethereum networks. It offers a simple and intuitive interface for working with smart contracts and handling Ethereum transactions.

@openzeppelin/contracts: This library provides a collection of secure and audited smart contracts, including the ERC20 implementation. Using these contracts can save you time and ensure the reliability of our Mantle token.

chai: This package is a popular assertion library for JavaScript. It is often used in conjunction with testing frameworks like Hardhat to write assertions and make test assertions more readable and expressive.

Configuring Hardhat

Open the hardhat.config.js file and add the following code to enable the Ethers.js plugin:

require("@nomiclabs/hardhat-ethers");

module.exports = {
  solidity: "0.8.4",
};

Writing the Mantlecoin contract

In your project directory, create a new file called

Mantlecoin.sol
inside the contracts folder and add the following code:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.4;

import "@openzeppelin/contracts/token/ERC20/ERC20.sol";

contract Mantlecoin is ERC20 {
    constructor(uint256 initialSupply) ERC20("Mantlecoin", "MTNL") {
        _mint(msg.sender, initialSupply);
    }
}

In this code snippet, we import the ERC20 contract from the OpenZeppelin Contracts library and create a new contract called Mantlecoin that inherits from ERC20.

The constructor takes an initialSupply argument and calls the parent constructor with the token name "Mantlecoin" and the ticker symbol "MTNL". Finally, we mint the initial supply of tokens and assign them to the contract deployer

Compiling the contract

To compile the Mantlecoin contract, run the following command in your terminal:

npx hardhat compile

This command will compile the contract and generate the necessary artifacts in the artifacts folder.

Writing Tests for Mantlecoin

To ensure that our token works as expected, let's write some tests. Create a new file called Mantlecoin.test.js inside the test folder and add the following code:

const { expect } = require("chai");
const { ethers } = require("hardhat");

describe("Mantlecoin", function () {
  let Mantlecoin, mantlecoin, owner, addr1, addr2;

  beforeEach(async () => {
    Mantlecoin = await ethers.getContractFactory("Mantlecoin");
    [owner, addr1, addr2] = await ethers.getSigners();
    mantlecoin = await Mantlecoin.deploy(1000000);
  });

  it("Should mint the initial supply to the owner", async () => {
    const ownerBalance = await mantlecoin.balanceOf(owner.address);
    expect(ownerBalance).to.equal(1000000);
  });

  it("Should transfer tokens between accounts", async () => {
    await mantlecoin.transfer(addr1.address, 500);
    const addr1Balance = await mantlecoin.balanceOf(addr1.address);
    expect(addr1Balance).to.equal(500);
  });
});

In this test file, we import the required libraries and set up a beforeEach hook to deploy a new instance of the Mantlecoin contract before each test. We then write two tests: one to check that the initial supply is minted to the owner, and another to test token transfers between accounts.

Running the tests

To run the tests, execute the following command in your terminal:

npx hardhat test

This command will run the tests and display the results in the terminal.

Deploying the Contract to the Mantle Testnet

To deploy our contract to the Mantle testnet, we need to update our hardhat.config.js file with the appropriate network configuration. Add the following code to your hardhat.config.js file:

require("@nomiclabs/hardhat-ethers");

module.exports = {
  solidity: "0.8.4",
  networks: {
    localhost: {
      url: "http://127.0.0.1:8545",
    },
    mantleTestnet: {
      url: "https://rpc.testnet.mantle.xyz/",
      chainId: 5001,
      accounts: [process.env.PRIVATE_KEY],
    },
  },
};

Replace process.env.PRIVATE_KEY with your private key or use an environment variable to store it securely.

Now, create a new file called deploy.js in the scripts folder and add the following code:

async function main() {
  const [deployer] = await ethers.getSigners();

  console.log("Deploying contracts with the account:", deployer.address);

  const Mantlecoin = await ethers.getContractFactory("Mantlecoin");
  const mantlecoin = await Mantlecoin.deploy(1000000);

  console.log("Mantlecoin address:", mantlecoin.address);
}

main()
  .then(() => process.exit(0))
  .catch((error) => {
    console.error(error);
    process.exit(1);
  });

This script deploys the Mantlecoin contract with an initial supply of 1,000,000 tokens.

To deploy the contract, run the following command:

npx hardhat run --network mantle scripts/deploy.js

This command will deploy the contract to the Mantle network and display the contract address in the terminal.

Conclusion

In this tutorial, we have provided a detailed, step-by-step guide to creating and deploying an ERC20 token called Mantlecoin (MTNL) using Hardhat and Ethers.js. By following this guide, you should now have a solid understanding of how to create, test, and deploy your own ERC20 tokens.

Continuous Integration Pipeline using Jenkins

Emmanuel Akanji — Sun, 30 Oct 2022 13:33:51 +0000

Beginning.
What is Jenkins?
Why Jenkins?
Prerequisites
Installing and configuring Jenkins Server
Configure Jenkins to retrieve source code from GitHub via Webhooks.
Set up Jenkins to use ssh to copy files to the NFS server.

Introduction

The previous projects enable us to add new web servers to our project and set up a load balancer to distribute traffic between them. However, we must still manually copy the files to the web servers. This project would allow us to automate the process of configuring multiple web servers.

Agility and the speed with which software solutions are delivered are critical factors in the world of software development. To accomplish this, we must automate as much as possible, as this will ensure quick and repeatable deployments. In this project, we will begin by automating a portion of our routine tasks using Jenkins, a free and open-source tool.
This procedure revolves heavily around the concept of b>Continuous Integration (CI)/b>.
CI is a software development practice in which developers integrate code into a shared repository on a regular basis, preferably several times per day. Each integration can then be validated using an automated build and automated tests. CD is a software release process that employs automated testing to determine whether changes to a codebase are correct and stable enough for immediate autonomous deployment to a production environment.

What is Jenkins?

Jenkins is a self-contained, open-source automation server that can be used to automate a wide range of tasks related to software development, testing, and delivery or deployment. Jenkins is a Java-based open-source tool. Jenkins is a continuous integration tool. It is used to continuously build and test your software projects, making it easier for developers to incorporate changes to the project and for users to obtain a fresh build. It also enables you to continuously deliver your software by integrating with a wide range of testing and deployment technologies.

Jenkins can be installed using native system packages, Docker, or it can run standalone on any machine that has the Java runtime environment installed.

Why Jenkins?
Jenkins is a continuous integration tool. It makes it easier for thousands of developers all over the world to build, test, and deploy their software with confidence. Because it assists in keeping track of the version control system and initiating and monitoring a build system if there are any changes.

In this project, we will use Jenkins CI to ensure that any changes made to the source code in GitHub are automatically updated on the web servers.

Prerequisites

Source Code: GitHub
Infrastructure: AWS.
Webserver Linux: Red Hat Enterprise Linux 8.
Database Server: Ubuntu 20.04 + MySQL.
Storage Server: Red Hat Enterprise Linux 8 + NFS Server.
Load Balancer: Ubuntu 20.04.
Programming Language: PHP.

To configure the above steps refer to the previous tutorial Here

Task: Enhance the architecture in the previous project by adding a Jenkins server, and configure a job to automatically deploy source code changes from Git to the NFS server.

Installing and Configuring Jenkins Server

Install Jenkins on the Jenkins server.

Make an AWS EC2 server based on Ubuntu Server 20.04 LTS and call it "Jenkins."

Results:

Install JDK(Java Development Kit) on the Jenkins server. Since Jenkins is a Java-based application.

sudo apt update
sudo apt install default-jdk-headless

Results:

Set up Jenkins

wget -q -O - https://pkg.jenkins.io/debian-stable/jenkins.io.key | sudo apt-key add -
sudo sh -c 'echo deb https://pkg.jenkins.io/debian-stable binary/ > \
    /etc/apt/sources.list.d/jenkins.list'
sudo apt update
sudo apt-get install jenkins

Results:

We have to make sure that Jenkins is running.

sudo systemctl status jenkins

Results:

By default Jenkins server uses TCP port 8080 - open it by creating a new inbound rule in your EC2 security group.

Results:

Perform initial Jenkins setup. From your browser access.

http://<Jenkins-Server-Public-IP-Address>:8080

Results:

Note:You will be prompted to provide a default admin password.

To get retrieve the default admin password, run the following command.

sudo cat /var/lib/jenkins/secrets/initialAdminPassword

Results:

Then you will be asked which plugins to install - choose suggested plugins.

Results:

Once plugin installation is done - create an admin user and you will get your Jenkin server address.

Results:

Configure Jenkins to retrieve source code from GitHub via Webhooks.

In this section, we will configure Jenkins to automatically retrieve source code from GitHub whenever there is a change in the source code. Webhooks would be used to accomplish this.

Enable webhooks in your GitHub repository settings. Go to your GitHub repository and select Settings > Webhooks > Add webhook.

Results:

Open the Jenkins web console, click "New Item," and create a Freestyle project.

Results:

To connect your GitHub repository to Jenkins, simply copy the URL from your GitHub repository.

Results:

In your Jenkins project's configurations, select Git repository, enter the URL of your GitHub repository, and click "Add" to add credentials so Jenkins can access your GitHub repository.

Results:

Save the configurations and run the build. When you click "Build Now," you'll see that the build was successful.

Results:

You can open the build and see if it has run successfully in "Console Output."

If so, congratulations! You have just completed your first Jenkins build!

Please keep in mind that this build produces nothing and only runs when we manually trigger it. Let us fix it.

In your Jenkins project, go to "Configure" your job/project and add these two configurations.
- Build Triggers > Build when a change is pushed to GitHub, triggering the job via the GitHub webhook:
Results:
- Configure "Post-build Actions" to archive all files - files generated by a build are referred to as "artifacts."
Results:
Now, go ahead and make some changes to any file in your GitHub repository (for example, the README.MD file) and push the changes to the master branch.

Results:

We should see that a new build was launched automatically (via webhook) and that its results - artifacts - were saved on the Jenkins server.

Results:

Note: You have now configured an automated Jenkins job to receive files from GitHub via webhook trigger (this method is considered 'push' because the changes are 'pushed' and file transfer is initiated by GitHub). Other methods include: triggering one job (downstream) from another (upstream), polling GitHub on a regular basis, and so on.

By default, the artifacts are stored on Jenkins server locally

ls /var/lib/jenkins/jobs/tooling_github/builds/<build_number>/archive/

Results:

Set up Jenkins to use ssh to copy files to the NFS server.

Now that we have our artifacts stored locally on the Jenkins server, we must copy them to the NFS server to the /mnt/apps directory.
Because Jenkins is highly extendable and can be configured to do almost anything, we will need a plugin called "Publish over SSH" to copy files to the NFS server.

Install the "Publish over SSH" plugin. Go to the Jenkins web console and select "Manage Jenkins" > "Manage Plugins" > "Available" > "Publish over SSH" > "Install without restart."

Results:

Set up the job/project to copy artifacts to the NFS server. Select "Manage Jenkins" from the main dashboard and then "Configure System." Scroll down to the Publish over SSH plugin configuration section and configure it to connect to your NFS server. The configuration is simple; you simply need to provide the following information:
- Provide a private key (the contents of the.pem file that you use to connect to the NFS server via SSH/Putty). arbitrary name
- Hostname - This can be your NFS server's private IP address.
- ec2-user is the username (since NFS server is based on EC2 with RHEL 8)
- Remote directory - /mnt/apps because our Web Servers use it as a mounting point to retrieve files from the NFS server

Then save the configurations.

Results:

Note: Test the configuration and ensure that the connection returns Success. Remember that TCP port 22 on the NFS server must be open in order to receive SSH connections.

Now, open the Jenkins project configuration page and add another "Post-build Actions" to copy the artifacts to the NFS server. You have chosen the option "Send build artifacts over SSH."

Results:

Now configure it to send all files generated by the build to our previously defined remote directory /mnt/apps. In our case, we want to copy all files and directories, so we use ** and then save the configurations.

If you want to apply a specific pattern to determine which files to send – use this syntax.

Results:

Now, go ahead and make some changes to any file in your GitHub repository (for example, the README.MD file) and push the changes to the master branch. The build will be triggered by the webhook, and the artifacts will be copied to the NFS server.

Results:

To ensure that the files in /mnt/apps have been updated, connect via SSH/Putty to your NFS server and check the README.MD file

cat /mnt/apps/README.md

Results:

We have just completed our first Continuous Integration solution using Jenkins CI.

#50DaysOfDevops Challenge Project 1: Configuring a web-app architecture with a network file server attached

Emmanuel Akanji — Mon, 17 Oct 2022 21:12:59 +0000

This is my first project for my #50DaysOfDevops Challenge. This article would be in series as it covers the projects I build during my Challenge.

Here i'll be explaining how I configured a simple web architecture with a database and shared network file system.

Introduction.
- Prerequisites.
Step 1 - Preparing the NFS Server.
Step 2 - Configure the database server.
Step 3 - Configure the web servers.

Introduction

A network file server allows a user on a client computer to access files over a computer network much like local storage is accessed. NFS, like many other protocols, builds on the Open Network Computing Remote Procedure Call (ONC RPC) system.
In this article I'll be implementing configuring a network file server on a simple web architecture.

Prerequisites.

In this project here are some of the requirements needed to move things forward.
Infrastructure: AWS
Webserver Linux: Red Hat Enterprise Linux 8
Database Server: Ubuntu 20.04 + MySQL
Storage Server: Red Hat Enterprise Linux 8 + NFS Server
Programming Language: PHP
Code Repository: Github

In the diagram below, there is a common pattern where several stateless Web Servers would share a common database and also access the same files using Network File Sytem (NFS) as a shared file storage. Even though the NFS server might be located on a completely separate hardware – for the Web Servers it would look like a local file system from where they can serve the same files.

Step 1 - Preparing the NFS Server

Like the explanation above this server would server like a local file system where all the web servers would access the same files. In this step, we would prepare the Network File system server.

Create a new EC2 instance with RHEL Linux 8 AMI.

Results:
Configure LVM on the server.
Create and attach 3 volumes to the server.

Results:

Connect to your Linux instance and check if the volumes are attached using the following command:
```
lsblk
```
Results:
Use gdisk utility to create a single partition on each of the 3 disks.
```
sudo gdisk /dev/nvme1n1 /dev/nvme2n1 /dev/nvme3n1
```
Results:
Then install the lvm2 package using the following command:
```
sudo yum install lvm2
```
and then run the following command to check for available partitions:
```
sudo lvmdiskscan
```
Results:

Note: Unlike Ubuntu which uses apt, for redhat the package manager is yum.
Now after checking that there's no logical volume present, we need to create a physical volume on each of the 3 disks using the following command:
```
sudo pvcreate /dev/nvme1n1 
sudo pvcreate /dev/nvme2n1 
sudo pvcreate /dev/nvme3n1
```
Results:
Now we need to verify that our physical volume has been created successfully using the following command:
```
sudo pvs
```
Results:
Now we need to create a volume group using the vgcreate utility. We will use the 3 disks we created earlier to create a volume group called NFS-vg.
```
sudo vgcreate nfs-vg /dev/nvme1n1 /dev/nvme2n1 /dev/nvme3n1
```
Results:
Use lvcreate utility to create 3 logical volumes. lv-opt lv-apps, and lv-logs. The lv-apps: would be used by the webservers, The lv-logs: would be used by web server logs, and the lv-opt: would be used by the Jenkins server.
```
sudo lvcreate -L 20G -n lv-opt nfs-vg
sudo lvcreate -L 20G -n lv-apps nfs-vg
sudo lvcreate -L 10G -n lv-logs nfs-vg
```
Results:
Now we need to verify that our logical volumes have been created successfully using the following command:
```
sudo lvs
```
Results:

Verify the entire setup

sudo vgdisplay -v #view complete setup - VG, PV, and LV
sudo lsblk

Results:

![image]

Use mkfs.xfs to format the logical volumes with xfs filesystem.

sudo mkfs -t xfs /dev/nfs-vg/lv-opt
sudo mkfs -t xfs /dev/nfs-vg/lv-apps
sudo mkfs -t xfs /dev/nfs-vg/lv-logs

Results:

Create a directory for each of the logical volumes.

sudo mkdir -p /mnt/apps
sudo mkdir -p /mnt/logs
sudo mkdir -p /mnt/opt

Results:

Mount the logical volumes to the directories we created earlier.

sudo mount /dev/nfs-vg/lv-apps /mnt/apps
sudo mount /dev/nfs-vg/lv-logs /mnt/logs
sudo mount /dev/nfs-vg/lv-opt /mnt/opt

Results:

Verify that the logical volumes have been mounted successfully.
```
sudo df -h
```
Results:
Now we need to make the mount persistent. To do that, we need to edit the /etc/fstab file and add the following lines:
```
sudo blkid
sudo nano /etc/fstab
```
Results:

Now we need to test the configurations and reload the daemon.

sudo mount -a
sudo systemctl daemon-reload

Results:

It is about time for us to install the NFS server. To do that, we need to install the nfs-utils package using the following command:

sudo yum -y update
sudo yum install -y nfs-utils
sudo systemctl start nfs-server.service
sudo systemctl enable nfs-server.service
sudo systemctl status nfs-server.service

Results:

Now we need to set up permissions that will allow our web servers to read, write and execute files on NFS:

sudo chown -R nobody: /mnt/apps
sudo chown -R nobody: /mnt/logs
sudo chown -R nobody: /mnt/opt
sudo chmod -R 777 /mnt/apps
sudo chmod -R 777 /mnt/logs
sudo chmod -R 777 /mnt/opt

Results:

Now we need to edit the /etc/exports file and add the following lines:

sudo nano /etc/exports

add the following:

/mnt/apps <Subnet-CIDR>(rw,sync,no_all_squash,no_root_squash)
/mnt/logs <Subnet-CIDR>(rw,sync,no_all_squash,no_root_squash)
/mnt/opt <Subnet-CIDR>(rw,sync,no_all_squash,no_root_squash)

and then run the command:

sudo exportfs -arv

Results:

Now we need to check the port being used by NFS and open it using Security Groups(add a new inbound Rule):
```
rpcinfo -p | grep nfs
```
Note: For the NFS server to be accessible from your client, you must also open the following ports: TCP 111, UDP 111, and UDP 2049.

Step 2: - Configure the database server

Create a new instance of ubuntu and ssh into it.
```
ssh -i "key.pem" ubuntu@<IP>
```
Results:
Install the MySQL server using the following command:
```
sudo apt install mysql-server
```
Results:
Create a database name called tooling
```
sudo mysql
CREATE DATABASE tooling;
```
Results:
Create a database user and name it webaccess
```
CREATE USER 'webaccess'@'%' IDENTIFIED BY 'password';
```
Results:

Note: The '%' should be replaced with the address of the subnet CIDR of your webservers.
Grant the webaccess user all privileges on the tooling database.
```
GRANT ALL PRIVILEGES ON tooling.* TO 'webaccess'@'%';
```
Results:
Now we need to flush all privileges.
```
FLUSH PRIVILEGES;
```
Results:
Now let's show our databases and users.
```
SHOW DATABASES;
```
Results:
Now let's navigate to the tooling database and show tables.
```
USE tooling;
SHOW TABLES;
```
Results:

Step 3: - Configure the web servers

Create a new instance of RedHat and ssh into it.
```
ssh -i "key.pem" redhat@<IP>
```
Install NFS client using the following command:
```
sudo yum install -y nfs-utils nfs4-acl-tools
```
Results:

Create a directory called /var/www/ and target the NFS server's export for apps

sudo mkdir /var/www
sudo mount -t nfs -o rw,nosuid <NFS-Server-IP>:/mnt/apps /var/www

Results:

Verify that NFS was mounted successfully.
```
sudo df -h
```
Results:
Make sure that the changes will persist on the web server after reboot.
```
sudo nano /etc/fstab
```
add the following:
```
<NFS-Server-IP>:/mnt/apps /var/www nfs defaults 0 0
```
Results:

Install Remi's repository, Apache and PHP

sudo yum install httpd -y
sudo dnf install https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm

sudo dnf install dnf-utils http://rpms.remirepo.net/enterprise/remi-release-8.rpm

sudo dnf module reset php

sudo dnf module enable php:remi-7.4

sudo dnf install php php-opcache php-gd php-curl php-mysqlnd

sudo systemctl start php-fpm

sudo systemctl enable php-fpm

setsebool -P httpd_execmem 1

Results:

Repeat the previous step for another 2 Web Servers.
To verify that Apache files and directories are available on the Web Server in /var/www and also on the NFS server in /mnt/apps. If you see the same files – it means NFS is mounted correctly. You can try to create a new file touch test.txt from one server and check if the same file is accessible from other Web Servers.
```
sudo touch test.txt
```
Results:

and on the other web servers:
Now we need to locate the log folder for Apache on the web server and mount it to the NFS server's export for logs and make sure that the changes will persist on the web server after reboot on all the web servers.
```
sudo mkdir /var/log/httpd
sudo mount -t nfs -o rw, nosuid <NFS-Server-IP>:/mnt/logs /var/log/httpd
```
and then add the following to /etc/fstab:
```
sudo nano /etc/fstab
```
add the following:
```
<NFS-Server-IP>:/mnt/logs /var/log/httpd nfs defaults 0 0
```
Results:
Now we need to install git on any of the web servers.
```
sudo yum install git
```
Results:
Now we need to clone the repository from GitHub to the web server.
```
git clone https://github.com/manny-uncharted/tooling.git
```
Results:
And now we need to copy the files from the html folder in the repository to the /var/www/html directory.
```
cd tooling
sudo cp -r html/* /var/www/html/
```
and to verify that the files were copied successfully:
```
sudo ls /var/www/html/
```
Results:

Note: If you encounter 403 Error – check permissions to your /var/www/html folder and also disable SELinux sudo setenforce 0. To make this change permanent – open following config file sudo nano /etc/sysconfig/selinux and set SELINUX=disabledthen restrt httpd.

Now we need to update the website’s configuration to connect to the database (in /var/www/html/functions.php file).
```
sudo nano /var/www/html/functions.php
```
Results:
Then we apply tooling-db.sql script to your database using this command:
```
sudo yum install mysql -y
mysql -h <private-ip-of-db> -u webaccess -p tooling < tooling-db.sql
```
Note: Ensure that you edit the /etc/mysql/mysql.conf.d/mysqld.cnf file to allow remote access to the database.

Results:

Now we need to create in MySQL a new admin user with username: myuser and password: password:

INSERT INTO users (‘id’, ‘username’, ‘password’, ’email’, ‘user_type’, ‘status’) VALUES
(2, ‘myuser’, ‘5f4dcc3b5aa765d61d8327deb882cf99’, ‘user@mail.com’, ‘admin’, 1);

Results:

Now we can then open the website in the browser and login with the new user.
Results:

Conclusion

Congratulations now you've successfully been able to configure a network file server. In my next project challenge I'll be configuring a load balancer using Apache.

Watch out for it!

Implementation of a basic web solution using WordPress

Emmanuel Akanji — Tue, 09 Aug 2022 14:54:00 +0000

WordPress is a content management system (CMS) that allows you to host and build websites. WordPress contains plugin architecture and a template system, so you can customize any website to fit your business, blog, portfolio, or online store. The focus of this tutorial is not on how to build websites with wordpress.

In this tutorial I would be showing you how to prepare storage infrastructure on two Linux servers and implement a basic web solution using WordPress. WordPress is a free and open-source content management system written in PHP and paired with MySQL or MariaDB as its backend Relational Database Management System (RDBMS).

This project consists of two parts:

Configure storage subsystem for Web and Database servers based on Linux OS. The focus of this part is to give you practical experience of working with disks, partitions and volumes in Linux.
Install WordPress and connect it to a remote MySQL database server. This part of the project will solidify your skills of deploying Web and DB tiers of Web solution.

As a DevOps engineer, a deep understanding of core components of web solutions and the ability to troubleshoot them will play essential role in your further progress and development.

Three-tier Architecture

Generally, web, or mobile solutions are implemented based on what is called the Three-tier Architecture.

Three-tier Architecture is a client-server software architecture pattern that comprise of 3 separate layers. They are:

Presentation Layer (PL): This is the user interface such as the client server or browser on your laptop.
Business Layer (BL): This is the backend program that implements business logic. Application or Webserver
Data Access or Management Layer (DAL): This is the layer for computer data storage and data access. Database Server or File System Server such as FTP server, or NFS Server.

With this project, you will have the hands-on experience that showcases Three-tier Architecture while also ensuring that the disks used to store files on the Linux servers are adequately partitioned and managed through programs such as gdisk and LVM respectively.

Requirements:

Your 3-Tier Setup
- A Laptop or PC to serve as a client
- An EC2 Linux Server as a web server (This is where you will install WordPress)
- An EC2 Linux server as a database (DB) server

Note: We are using RedHat OS for this project, you should be able to spin up an EC2 instance on your own. Also when connecting to RedHat you will need to use ec2-user user. Connection string will look like ec2-user@public-ip-address.

Creating and mounting Volumes

Create and attach a new volume to your Linux server.

Results:

Note: Ensure that the availability zone of your volume must be the same as your Linux server.
Connect to your linux server and check if the volume is attached using this command:
```
lsblk
```
Results:
Use df -h command to see all mounts and free space on your server
```
sudo df -h
```
Results:
Use gdisk utility to create a single partition on each of the 3 disks
```
sudo gdisk /dev/xvdf
```
and then use the w command and enter "y" to create a single partition.

Also repeat the same for the other two disks
```
sudo gdisk /dev/xvdg
sudo gdisk /dev/xvdh
```
Results:
Use lsblk utility to view the newly configured partition on each of the 3 disks.
```
sudo lsblk
```
Results:
Install lvm2 package using sudo yum install lvm2. Run sudo lvmdiskscan command to check for available partitions.
```
sudo yum install lvm2
sudo lvmdiskscan
```
Results:

Note: Unlike ubuntu that uses apt, for redhat the package manager is yum.
Use pvcreate utility to mark each of 3 disks as physical volumes (PVs) to be used by LVM
```
sudo pvcreate /dev/xvdf
sudo pvcreate /dev/xvdg
sudo pvcreate /dev/xvdh
```
Results:
Verify that your Physical volume has been created successfully by running sudo pvs
```
sudo pvs
```
Results:
Use vgcreate utility to add all 3 PVs to a volume group (VG). Name the VG webdata-vg
```
sudo vgcreate webdata-vg /dev/xvdf2 /dev/xvdg2 /dev/xvdh2
```
Results:
Use lvcreate utility to create 2 logical volumes. apps-lv (Use half of the PV size), and logs-lv Use the remaining space of the PV size. NOTE: apps-lv will be used to store data for the Website while, logs-lv will be used to store data for logs.
```
sudo lvcreate -n apps-lv -L 14G webdata-vg
sudo lvcreate -n logs-lv -L 14G webdata-vg
```
Results:
Verify that your Logical Volume has been created successfully by running sudo lvs
```
sudo lvs
```
Results:

Verify the entire setup

sudo vgdisplay -v #view complete setup - VG, PV, and LV
sudo lsblk

Results:

Use mkfs.ext4 to format the logical volumes with ext4 filesystem

sudo mkfs.ext4 /dev/webdata-vg/apps-lv
sudo mkfs.ext4 /dev/webdata-vg/logs-lv

Results:

Creating a directory structure.

Create /var/www/html directory to store website files
```
sudo mkdir -p /var/www/html
```
Results:
Create /home/recovery/logs to store backup of log data
```
sudo mkdir -p /home/recovery/logs
```
Results:
Mount /var/www/html on apps-lv logical volume
```
sudo mount /dev/webdata-vg/apps-lv /var/www/html/
```
Results:
Use rsync utility to backup all the files in the log directory /var/log into /home/recovery/logs (This is required before mounting the file system)
```
sudo rsync -av /var/log/. /home/recovery/logs/
```
Results:
Mount /var/log on logs-lv logical volume. (Note that all the existing data on /var/log will be deleted. That is why step of creating /var/www/html directory to store website files)
```
sudo mount /dev/webdata-vg/logs-lv /var/log
```
Results:
Restore log files back into /var/log directory
```
sudo rsync -av /home/recovery/logs/. /var/log
```
Results:

UPDATING THE `/ETC/FSTAB` FILE

Update /etc/fstab file so that the mount configuration will persist after restart of the server.
The UUID of the device will be used to update the /etc/fstab file;
```
sudo blkid
```
Results:

Update /etc/fstab in this format using your own UUID and rememeber to remove the leading and ending quotes.

sudo nano /etc/fstab

and add this

UUID=<uuid of your webdata-vg-apps> /var/www/html ext4 defaults 0 0
UUID=<uuid of your webdata-vg-logs> /var/log ext4 defaults 0 0

Results:

Test the configuration and reload the daemon
```
sudo mount -a
sudo systemctl daemon-reload
```
Results:
Verify your setup by running df -h, output must look like this:
```
sudo df -h
```
Results:

Preparing the Database Server

Launch a second RedHat EC2 instance that will have a role – ‘DB Server’
Repeat the same steps as for the Web Server, but instead of apps-lv create db-lv and mount it to /db directory instead of /var/www/html/.

ssh into the instance you just created

ssh -i <your_key_file> ec2-user@<public_ip_address>

Results:

Create and attach 3 Logical Volumes to the database server instance.
Connect to your linux server and check if the volume is attached using this command:
```
sudo lsblk
```
Results:
Use df -h command to see all mounts and free space on your server
```
sudo df -h
```
Results:
Using gdisk utility create a single partition on each of the 3 disks
```
sudo gdisk /dev/xvdf
```
and then create a new partition with the "n" command, inputting 1 (to create a single partition) and then the "w" command and enter "y" to create a single partition.

Also repeat the same for the other two disks
```
sudo gdisk /dev/xvdg
sudo gdisk /dev/xvdh
```
Results:
Use lsblk utility to view the newly configured partition on each of the 3 disks.
```
sudo lsblk
```
Results:
Install lvm2 package using sudo yum install lvm2. Run sudo lvmdiskscan command to check for available partitions.
```
sudo yum install lvm2
sudo lvmdiskscan
```
Results:

Note: Unlike ubuntu that uses apt, for redhat the package manager is yum.
Use pvcreate utility to mark each of 3 disks as physical volumes (PVs) to be used by LVM
```
sudo pvcreate /dev/xvdf2 /dev/xvdg2 /dev/xvdh2
```
Results:
Verify that your Physical volume has been created successfully by running sudo pvs
```
sudo pvs
```
Results:
Use vgcreate utility to add all 3 PVs to a volume group (VG). Name the VG webdata-vg
```
sudo vgcreate dbdata-vg /dev/xvdf2 /dev/xvdg2 /dev/xvdh2
```
Results:
Use lvcreate utility to create 2 logical volumes. apps-lv (Use half of the PV size), and logs-lv Use the remaining space of the PV size. NOTE: apps-lv will be used to store data for the Website while, logs-lv will be used to store data for logs.
```
sudo lvcreate -n db-lv -L 14G dbdata-vg
sudo lvcreate -n logs-lv -L 14G dbdata-vg
```
Results:
Verify that your Logical Volume has been created successfully by running sudo lvs
```
sudo lvs
```
Results:
We need to verify all we have done so far on the database server instance so far with these commands.
```
sudo vgdisplay -v #view complete setup - VG, PV, and LV
sudo lsblk 
```
Results:

Use mkfs.ext4 to format the logical volumes with ext4 filesystem

sudo mkfs.ext4 /dev/dbdata-vg/db-lv && sudo mkfs.ext4 /dev/dbdata-vg/logs-lv

Results:

Now that we are done configuring the database logical volumes, we would be moving on with creating the mount points for the logical volumes and the required directories.

Create /db directory to store website files
```
sudo mkdir -p /db
```
Results:
Create /home/recovery/logs to store backup of log data
```
sudo mkdir -p /home/recovery/logs
```
Results:
Mount /db on apps-lv logical volume
```
sudo mount /dev/dbdata-vg/db-lv /db
```
Results:
Like we did for the webserver instance use rsync utility to backup all the files in the log directory /var/log into /home/recovery/logs (This is required before mounting the file system)
```
sudo rsync -av /var/log/. /home/recovery/logs/
```
Results:
Mount /var/log on logs-lv logical volume. (Note that all the existing data on /var/log will be deleted. That is why step of creating /db directory to store database files)
```
sudo mount /dev/dbdata-vg/logs-lv /var/log
```
Results:
Restore log files back into /var/log directory
```
sudo rsync -av /home/recovery/logs/. /var/log
```
Results:

Now we need to update the /etc/fstab file to ensure that the configurations we made is persistent across reboots.

Update /etc/fstab file so that the mount configuration will persist after restart of the server.
The UUID of the device will be used to update the /etc/fstab file;
```
sudo blkid
```
Results:

Update /etc/fstab in this format using your own UUID and rememeber to remove the leading and ending quotes.

sudo nano /etc/fstab

and add this

UUID=<uuid of your webdata-vg-apps> /var/www/html ext4 defaults 0 0
UUID=<uuid of your webdata-vg-logs> /var/log ext4 defaults 0 0

Results:

Test the configuration and reload the daemon
```
sudo mount -a
sudo systemctl daemon-reload
```
Results:
Verify your setup by running df -h, output must look like this:
```
sudo df -h
```
Results:

Now your db server is ready to go and make other configurations as required.

Install WordPress on your Web Server EC2 Instance

Update the repository
```
sudo yum update
```
Results:

Install wget, Apache and it’s dependencies

sudo yum -y install wget httpd php php-mysqlnd php-fpm php-json

Results:

Start the apache service

sudo systemctl enable httpd
sudo systemctl start httpd

Results:

To install PHP and it’s depemdencies

sudo yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm
sudo yum install yum-utils http://rpms.remirepo.net/enterprise/remi-release-8.rpm
sudo yum module list php
sudo yum module reset php
sudo yum module enable php:remi-7.4
sudo yum install php php-opcache php-gd php-curl php-mysqlnd
sudo systemctl start php-fpm
sudo systemctl enable php-fpm
setsebool -P httpd_execmem 1

Results:

Restart Apache
```
sudo systemctl restart httpd
```
Results:

Download wordpress and copy wordpress to var/www/html

mkdir wordpress
cd   wordpress
sudo wget http://wordpress.org/latest.tar.gz
sudo tar xzvf latest.tar.gz
sudo rm -rf latest.tar.gz
cp wordpress/wp-config-sample.php wordpress/wp-config.php
cp -R wordpress /var/www/html/

Results:

Configure SELinux Policies

sudo chown -R apache:apache /var/www/html/wordpress
sudo chcon -t httpd_sys_rw_content_t /var/www/html/wordpress -R
sudo setsebool -P httpd_can_network_connect=1

Results:

Install MySQL on your DB Server EC2

Install mysql on the db-server

sudo yum update
sudo yum install mysql-server

Results:

We now need to verify that the service is up and running by using sudo systemctl status mysqld, if it is not running, restart the service and enable it so it will be running even after reboot:
```
sudo systemctl restart mysqld
sudo systemctl enable mysqld
```
Results:

Configuring the DB to work with WordPress

Here we need to configure the database to work with WordPress. By allowing the wordpress server be able to connect to the database, we need to configure the database to allow the wordpress server to connect to the database.

Get the ip-address of the wordpress server
```
curl http://checkip.amazonaws.com
```
Results:

We need to then create a user for the wordpress server to connect to the database.

sudo mysql
CREATE DATABASE wordpress;
CREATE USER `myuser`@`<Web-Server-Private-IP-Address>` IDENTIFIED BY 'mypass';
GRANT ALL ON wordpress.* TO 'myuser'@'<Web-Server-Private-IP-Address>';
FLUSH PRIVILEGES;
SHOW DATABASES;
exit

Results:

Configure WordPress to connect to remote database.

Here we are to open MySQL port 3306 on DB Server EC2. For extra security, you shall allow access to the DB server ONLY from your Web Server’s IP address, so in the Inbound Rule configuration specify source as /32.

Install MySQL client and test that you can connect from your Web Server to your DB server by using mysql-client
```
sudo yum install mysql
```
Results:
- Create login to the database on the db server
```
sudo mysql -u <user> -p -h <DB-Server-Private-IP-address>
```
Note the is the name of the user you created in mysql server on the db server.
Results:
Verify if you can successfully execute SHOW DATABASES; command and see a list of existing databases.
```
SHOW DATABASES;
```
Results:

Change permissions and configuration so Apache could use WordPress:
Here we need to create a configuration file for wordpress in order to point client requests to the wordpress directory.

sudo nano /etc/httpd/conf.d/wordpress.conf

and copy and paste the lines below:

<VirtualHost *:80>
ServerAdmin myuser@3.88.215.221
DocumentRoot /var/www/html/wordpress

<Directory "/var/www/html/wordpress">
Options Indexes FollowSymLinks
AllowOverride all
Require all granted
</Directory>

ErrorLog /var/log/httpd/wordpress_error.log
CustomLog /var/log/httpd/wordpress_access.log common
</VirtualHost>

Results:

To apply the changes, restart Apache
```
sudo systemctl restart httpd
```
Results:

Edit the wp-config file

sudo nano /var/www/html/wordpress/wp-config.php

and add the following lines:

define('DB_NAME', 'wordpress');
define('DB_USER', 'myuser');
define('DB_PASSWORD', 'mypass');
define('DB_HOST', '<db-Server-Private-IP-Address>');
define('DB_CHARSET', 'utf8mb4');
define('DB_COLLATE', '');

Results:

configure SELinux for wordpress

sudo semanage fcontext -a -t httpd_sys_rw_content_t "/var/www/html/wordpress/.*?"

Note: The semanage command is not available on CentOS 7.x.x. and you might need to install it using the following command:

sudo yum provides /usr/sbin/semanage
sudo yum install policycoreutils-python-utils

Results:

Try to access from your browser the link to your WordPress
```
http://<Web-Server-Public-IP-Address>/
```
Results:

MEAN Stack Implementation on an AWS EC2 instance

Emmanuel Akanji — Thu, 04 Aug 2022 13:25:17 +0000

This is a second part to my other article on Lamp stack Implementation in AWS .

I have already talked about a technology stack, as they are a set of tools used to develop a software product. In this article, I would be implementing a simple book register web form application on the MEAN stack on an AWS EC2 instance. We would be using AngularJs as the frontend framework, which forms the MEAN STACK.
MEAN stack is a stack of technologies that are used to build web applications and these are the technologies we will be using in this project:

MongoDB: Which is a NoSQL, document-based database used to store application data in form of a document.
ExpressJS: A server-side web application framework for Node.js.
Angular Js: A client-side web application framework for JavaScript as its used to handle client and server requests.
Node.js: A JavaScript runtime environment. It’s used to run JavaScript on a machine rather than in a browser.

In this tutorial, we would be working on the following components of the MEAN stack:

Installing NodeJs on our server.
Installing MongoDB.
Install Express and set up routes to the server.
Accessing the routes with AngularJS.

Installing NodeJs on our server

Node.js is a JavaScript runtime built on Chrome’s V8 JavaScript engine. Node.js is used in this tutorial to set up the Express routes and AngularJS controllers.

Updating the ubuntu server
```
sudo apt-get update
```
Results:
upgrading the ubuntu server
```
sudo apt-get upgrade
```
Results:

Adding the required certificates

sudo apt -y install curl dirmngr apt-transport-https lsb-release ca-certificates

curl -sL https://deb.nodesource.com/setup_12.x | sudo -E bash -

Results:

Installing NodeJs
```
sudo apt-get install nodejs
```
Results:

Now that were done with the primary steps of installing Node.js, we can move on to the next step of installing MongoDB.

Installing MongoDB

MongoDB stores data in flexible, JSON-like documents. Fields in a database can vary from document to document and data structure can be changed over time. For our example application, we are adding book records to MongoDB that contain book name, isbn number, author, and number of pages.
images/WebConsole.gif

installing mongodb key configurations settings

sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv 0C49F3730359A14518585931BC711F9BA15703C6

and then running this command to add the repository to the list of repositories:

echo "deb [ arch=amd64 ] https://repo.mongodb.org/apt/ubuntu trusty/mongodb-org/3.4 multiverse" | sudo tee /etc/apt/sources.list.d/mongodb-org-3.4.list

Results:

Installing MongoDB

sudo apt-get install -y mongodb

Note: if you are using the latest version of ubuntu jammy you can use the following command instead of the previous one:

sudo apt install gnupg
echo "deb http://security.ubuntu.com/ubuntu impish-security main" | sudo tee /etc/apt/sources.list.d/impish-security.list

sudo apt-get update

sudo apt-get install libssl1.1

and import the public key using this command

wget -qO - https://www.mongodb.org/static/pgp/server-5.0.asc | sudo apt-key add -

and add mongodb to the sources list and then install mongodb

echo "deb [ arch=amd64,arm64 ] https://repo.mongodb.org/apt/ubuntu focal/mongodb-org/5.0 multiverse" | sudo tee /etc/apt/sources.list.d/mongodb-org-5.0.list

sudo apt update

sudo apt install -y mongodb-org

after installing enable mongodb using the command

sudo systemctl enable mongod

Starting MongoDB
```
sudo service mongod start
```
Results:
Verifying that the service is up and running
```
sudo systemctl status mongod
```
Results:
Installing NPM - Node Package Manager
```
sudo apt install -y npm
```
Results:
Next we need to install body-parser package
The ‘body-parser’ package to help us process JSON files passed in requests to the server.
```
sudo npm install body-parser
```
Results:
creating a folder named books and navigating into the folder
```
mkdir books && cd books
```
Results:
In the Books directory, we need to Initialize npm project
```
npm init
```
Results:

Add a file to it named server.js

nano server.js

and then add the following code to the server.js file:

var express = require('express');
var bodyParser = require('body-parser');
var app = express();
app.use(express.static(__dirname + '/public'));
app.use(bodyParser.json());
require('./apps/routes')(app);
app.set('port', 3300);
app.listen(app.get('port'), function() {
    console.log('Server up: http://localhost:' + app.get('port'));
});

Results:

Install Express and setting up routes to the server.

Now that we've created our server, we need to install the Express framework and set up the routes to the server.

Express is a minimal and flexible Node.js web application framework that provides features for web and mobile applications. We will use Express in to pass book information to and from our MongoDB database.

We also will use Mongoose package which provides a straight-forward, schema-based solution to model your application data. We will use Mongoose to establish a schema for the database to store data of our book register.

Installing Express and Mongoose
```
sudo npm install express mongoose
```
Results:
In ‘Books’ folder, create a folder named apps
```
mkdir apps && cd apps
```

Now we need to create a file called routes.js

nano routes.js

and then add the following code to the routes.js file:

var Book = require('./models/book');
module.exports = function(app) {
app.get('/book', function(req, res) {
    Book.find({}, function(err, result) {
    if ( err ) throw err;
    res.json(result);
    });
}); 
app.post('/book', function(req, res) {
    var book = new Book( {
    name:req.body.name,
    isbn:req.body.isbn,
    author:req.body.author,
    pages:req.body.pages
    });
    book.save(function(err, result) {
    if ( err ) throw err;
    res.json( {
        message:"Successfully added book",
        book:result
    });
    });
});
app.delete("/book/:isbn", function(req, res) {
    Book.findOneAndRemove(req.query, function(err, result) {
    if ( err ) throw err;
    res.json( {
        message: "Successfully deleted the book",
        book: result
    });
    });
});
var path = require('path');
app.get('*', function(req, res) {
    res.sendfile(path.join(__dirname + '/public', 'index.html'));
});
};

Results:

In the ‘apps’ folder, create a folder named models
as this would hold all the models for the application.
```
mkdir models && cd models
```
Results:

In our models folder create a file named book.js

nano book.js

and then add the following code to the book.js file:

var mongoose = require('mongoose');
var dbHost = 'mongodb://localhost:27017/test';
mongoose.connect(dbHost);
mongoose.connection;
mongoose.set('debug', true);
var bookSchema = mongoose.Schema( {
name: String,
isbn: {type: String, index: true},
author: String,
pages: Number
});
var Book = mongoose.model('Book', bookSchema);
module.exports = mongoose.model('Book', bookSchema);

Results:

Accessing the routes with AngularJS

AngularJS provides a web framework for creating dynamic views in your web applications. In this tutorial, we use AngularJS to connect our web page with Express and perform actions on our book register.

Now we need to change the directory back to ‘Books’
```
cd ../..
```
Results:
In the books directory, create a folder named public and navigate into it.
```
mkdir public && cd public
```
Results:

Then in the public directory, create a file script.js

nano script.js

and then add the following code to the script.js file:

var app = angular.module('myApp', []);
app.controller('myCtrl', function($scope, $http) {
$http( {
    method: 'GET',
    url: '/book'
}).then(function successCallback(response) {
    $scope.books = response.data;
}, function errorCallback(response) {
    console.log('Error: ' + response);
});
$scope.del_book = function(book) {
    $http( {
    method: 'DELETE',
    url: '/book/:isbn',
    params: {'isbn': book.isbn}
    }).then(function successCallback(response) {
    console.log(response);
    }, function errorCallback(response) {
    console.log('Error: ' + response);
    });
};
$scope.add_book = function() {
    var body = '{ "name": "' + $scope.Name + 
    '", "isbn": "' + $scope.Isbn +
    '", "author": "' + $scope.Author + 
    '", "pages": "' + $scope.Pages + '" }';
    $http({
    method: 'POST',
    url: '/book',
    data: body
    }).then(function successCallback(response) {
    console.log(response);
    }, function errorCallback(response) {
    console.log('Error: ' + response);
    });
};
});

Results:

In the public directory create a file called index.html

nano index.html

and then add the following code to the index.html file:

<!doctype html>
<html ng-app="myApp" ng-controller="myCtrl">
<head>
    <script src="https://ajax.googleapis.com/ajax/libs/angularjs/1.6.4/angular.min.js"></script>
    <script src="script.js"></script>
</head>
<body>
    <div>
    <table>
        <tr>
        <td>Name:</td>
        <td><input type="text" ng-model="Name"></td>
        </tr>
        <tr>
        <td>Isbn:</td>
        <td><input type="text" ng-model="Isbn"></td>
        </tr>
        <tr>
        <td>Author:</td>
        <td><input type="text" ng-model="Author"></td>
        </tr>
        <tr>
        <td>Pages:</td>
        <td><input type="number" ng-model="Pages"></td>
        </tr>
    </table>
    <button ng-click="add_book()">Add</button>
    </div>
    <hr>
    <div>
    <table>
        <tr>
        <th>Name</th>
        <th>Isbn</th>
        <th>Author</th>
        <th>Pages</th>

        </tr>
        <tr ng-repeat="book in books">
        <td>{{book.name}}</td>
        <td>{{book.isbn}}</td>
        <td>{{book.author}}</td>
        <td>{{book.pages}}</td>

        <td><input type="button" value="Delete" data-ng-click="del_book(book)"></td>
        </tr>
    </table>
    </div>
</body>
</html>

Results:

Change the directory back to Books
```
cd ..
```
Results:
Start the server by running this command:
```
node server.js
```
Results:
The server is now up and running, we can connect it via port 3300. You can launch a separate Putty or SSH console to test what curl command returns locally.
```
curl -s http://localhost:3300
```
Results:
Expose the tcp 3300 port on your system and then get the public ip address of your system.
```
 curl -s http://169.254.169.254/latest/meta-data/public-ipv4 
```
Results:

Implementing the client-server architecture with MYSQL

Emmanuel Akanji — Wed, 27 Jul 2022 12:39:03 +0000

Client-Server refers to an architecture in which two or more computers are connected together over a network to send and receive requests between one another.

In their communication, each machine has its own role: the machine sending requests is usually referred as "Client" and the machine responding (serving) is called "Server".

In this case, our Web Server has a role of a "Client" that connects and reads/writes to/from a Database (DB) Server (MySQL, MongoDB, Oracle, SQL Server or any other), and the communication between them happens over a Local Network (it can also be Internet connection, but it is a common practice to place Web Server and DB Server close to each other in local network).

Implementing a Client Server Architecture using MySQL Database Management System (DBMS).

In this tutorial I would be demonstrating a basic client-server using MySQL Relational Database Management System (RDBMS), follow the below instructions

Create and configure two Linux-based virtual servers (EC2 instances in AWS) with names.
```
Server A name - `mysql server`
Server B name - `mysql client`
```
On mysql server Linux Server install MySQL Server software.
```
sudo apt install mysql-server
```
Results:
On mysql client Linux Server install MySQL Client software.
```
sudo apt install mysql-client
```
Results:
By default, both of your EC2 virtual servers are located in the same local virtual network, so they can communicate to each other using local IP addresses. Use mysql server's local IP address to connect from mysql client. MySQL server uses TCP port 3306 by default, so you will have to open it by creating a new entry in ‘Inbound rules’ in ‘mysql server’ Security Groups. For extra security, do not allow all IP addresses to reach your ‘mysql server’ – allow access only to the specific local IP address of your ‘mysql client’.

Results:
You might need to configure MySQL server to allow connections from remote hosts.
```
sudo nano /etc/mysql/mysql.conf.d/mysqld.cnf
```
and replace the following line:
```
bind-address = 127.0.0.1 
```
with the following line:
```
bind-address = 0.0.0.0
```
Results:
In your mysql-server ec2 instance allow the ipaddress of the mysql-client ec2 instance with port 3306 to access the mysql-server ec2 instance.
```
curl http://checkip.amazonaws.com
```
Results:
On your mysql-server create a new user using the following code
```
CREATE USER 'newuser2'@'44.203.195.178' IDENTIFIED BY 'password2';
GRANT ALL PRIVILEGES ON * . * TO 'newuser2'@'44.203.195.178';
```
Note: '44.203.195.178' is the ipaddress of your mysql-client
Results:
To connect to the mysql server, in your mysql client enter the following code.
```
mysql -u newuser2 -h 18.234.44.89 -p
```
Note: The format is
```
mysql -u <user> -h <ipaddress-of-the-server> -p
```
and run the following
```
show databases;
```
Results:

Building a career path to software development with boot.dev

Emmanuel Akanji — Tue, 26 Jul 2022 11:07:00 +0000

Hey, new to the world of software engineering and tired of watching several tutorial videos on coding after watching them, you keep asking yourself what do I learn next. There are many resources out there that gives you information on different tools and languages but most of the time they never give you a particular order in which you should learn them.

Many new learners after watching hours of YouTube videos, find out they can’t build the most basic applications when they start a project alone. There’s nothing worse than wandering around from programming language to programming language and framework to framework trapped in the “tutorial hell”. Early on in my career, I was once like that, at the sight of a new programming language I get the urge to want to try it out. Not to say it’s a bad thing but for a beginner, this won’t help you grasp the concepts you need, after learning the concepts of programming language with one language, build things on your own to ensure you’ve grasped the concepts you just learned, only then can you switch to a different language.
The best way to learn is to write real code through building projects on your own.

About Boot.dev

This is why I’m introducing you to boot.dev, it’s a one-stop platform to help you learn about computer science concepts without the bore of a college degree or the rigor or fast pace of a Bootcamp. And as our world is becoming more tech-literate every day, it is gradually becoming the in thing to learn how to code. Naturally, an understanding of computer science concepts would go a long way to differentiate you from the average developer.

So if you’re a beginner looking for where to kick-start or a competent developer looking to refresh your knowledge of computer science concepts and fundamentals, you should get started with boot.dev.

About the Curriculum offered

Boot.dev offers a simple, linear curriculum that’s designed to prepare you for an entry-level role in backend development. And below is a list of topics offered in the curriculum.

Learn to code in JavaScript.
Learn Graphics in HTML5 Canvas
Learn About HTTP
Learn Python
Learn Object Oriented Programming
Building an SEO Link Analyzer in Python
Learn Algorithms
Learn Data Structures
Learn About Advanced Algorithms
Building a Maze Solver in Python
Building a Personal Project 1
Learn Go
Building a Social Media Backend in Go
Learn about Cryptography
Learn about Functional Programming
And Finally a Capstone Project This Approach of project-based learning has been proven to help students have a good grasp of things they learn. One thing I found interesting is the JavaScript course, I personally detest JavaScript but they way it's explained here make it easy to understand and grasp. I also took great interest in their cryptography course, as I'm not from a computer science background I have to comb through the internet and YouTube for useful resources to help me learn these concepts.

How to get started

To get started with this wonderful curriculum you just need to visit boot.dev and then signup with your GitHub account if you have one or you google account, I’m sure everyone has one and if you don’t have a google account you can create one at google.com, then you signup with either of the accounts that you have.

You have access to the first 2 chapters of every course on Boot.dev are totally free and open. The more advanced chapters are also free, but only in "sandbox mode". While in sandbox mode you can read the lessons, write and run code, you just can't pass-off the assignments. To get access to the entire platform you would be required to pay either a monthly plan of $29, a yearly plan of $192, or a one-time payment of $499. I personally fill this curriculum is worth the price and should very well get you ready for your entry-level job as a backend developer.

Support

A good thing about boot.dev is its support community there on Discord that provides access to other learners like you and also access to mentors who are always ready to provide assistance whenever you get stuck, There is something magical about learning with others as the motivation provided by a good group of peers is strong. You can keep each other accountable and move forward.

Get started today! Click here

Forem: Emmanuel Akanji

[Boost]

The Next AI Agent Failure Won't Be a Hallucination. It Will Be a Payment.

The Next AI Agent Failure Won't Be a Hallucination. It Will Be a Payment.

What We Built

Why Existing Agent Stacks Break at Money

The Core Design Principle: Authority Should Only Narrow

Evidence Is the Product

Proof Implementation: Trading Fabric

The Framework Is Opening Up

The Agentic Payment Protocol Wars

X402 vs UCP vs ACP vs AP2 And Why the Answer Isn't Picking a Winner

The Protocols

x402: Coinbase (HTTP 402 Micropayments)

UCP: Google/Shopify (Universal Commerce Protocol)

ACP: OpenAI/Stripe (Agent Commerce Protocol)

AP2: Google (Agent Payment Protocol v2)

MPP: Session-Based Budget Allocation

The Fragmentation Problem

Why We Built ProtocolDetector

My Take

The Agentic Payment Protocol Wars

X402 vs UCP vs ACP vs AP2, And Why the Answer Isn't Picking a Winner

The Protocols

x402: Coinbase (HTTP 402 Micropayments)

UCP: Google/Shopify (Universal Commerce Protocol)

ACP: OpenAI/Stripe (Agent Commerce Protocol)

AP2: Google (Agent Payment Protocol v2)

MPP: Session-Based Budget Allocation

The Fragmentation Problem

Why We Built ProtocolDetector

My Take

[Boost]

Why We Built FlowSpec: A Better Way to Orchestrate AI Workflows

Developing, Testing, and Deploying an ERC20 Token on Mantle Testnet using Hardhat and Ethers.js

Introduction

Mantle Blockchain: A Brief History and Overview

Prerequisites

Setting up the project

Installing dependencies

Configuring Hardhat

Writing the Mantlecoin contract

Compiling the contract

Writing Tests for Mantlecoin

Running the tests

Conclusion

Continuous Integration Pipeline using Jenkins

Table of Contents

Introduction

What is Jenkins?

Prerequisites

Installing and Configuring Jenkins Server

Install Jenkins on the Jenkins server.

Configure Jenkins to retrieve source code from GitHub via Webhooks.

Set up Jenkins to use ssh to copy files to the NFS server.

#50DaysOfDevops Challenge Project 1: Configuring a web-app architecture with a network file server attached

Table of contents

Introduction

Prerequisites.

Step 1 - Preparing the NFS Server

Step 2: - Configure the database server

Step 3: - Configure the web servers

Conclusion

Implementation of a basic web solution using WordPress

Three-tier Architecture

Creating and mounting Volumes

Creating a directory structure.

UPDATING THE /ETC/FSTAB FILE

Preparing the Database Server

Install WordPress on your Web Server EC2 Instance

Install MySQL on your DB Server EC2

Configuring the DB to work with WordPress

Configure WordPress to connect to remote database.

MEAN Stack Implementation on an AWS EC2 instance

Installing NodeJs on our server

Installing MongoDB

Install Express and setting up routes to the server.

Accessing the routes with AngularJS

Implementing the client-server architecture with MYSQL

Implementing a Client Server Architecture using MySQL Database Management System (DBMS).

UPDATING THE `/ETC/FSTAB` FILE