Forem: Chus

Troubleshooting Datacenter: Resolving Apache Service Reachability On Server

Chus — Wed, 29 Apr 2026 15:30:40 +0000

A server was supposed to be serving web content via Apache on port 5002, anyone trying to connect was met with a "No route to host" or "Connection refused" error.

Here is a breakdown of how to investigate and eventually restore the service.

Investigating with Telnet

The telnet command in Linux is a networking tool used to communicate with a remote host using the TELNET protocol. While it was originally designed for remote login and management, its lack of encryption (sending data like passwords in plain text) has made it largely obsolete for that purpose there. For secure remote access, always use the SSH (ssh) command instead.
Today, it is primarily used as a quick diagnostic tool to check if a specific TCP port is open and reachable on a remote server.

The standard command structure is:

telnet [hostname/server_ip] [port]

hostname/Ip: The address of the remote server
port: The target service port (e.g., 80 for HTTP). If omitted, it defaults to port 23.

To Exit/Close, Type quit at the telnet> prompt and press Enter.

SSH Into Server

To log into a remote server:

ssh username@server_ip

Check Apache Status using:

sudo systemctl status httpd

If Apache wasn't Running, Start it:

sudo systemctl start httpd

If The output revealed that another process was using port 5002, causing Apache to fail with the error Address already in use.

Resolving Port Binding Conflicts

A port binding conflict in Linux occurs when a service or application attempts to listen on a network port that is already in use by another process, preventing the new service from starting.

Here is the technical workflow used to resolve binding conflicts.

Scan for conflict:

[user@hostname ~]$ sudo ss -tulnp | grep 5002 
tcp LISTEN 0 10 127.0.0.1:5002 0.0.0.0:* users:(("sendmail",pid=19948,fd=4))

Resolution: After identifying the conflicting Process ID (PID), terminate the process to release the bind, allowing the port to become available for its intended service (from the above sendmail is the service with pid=19948 that is conflicting with our Apache on host 5002).

To Stop the service or kill the process ID

sudo systemctl stop sendmail
# If it won't stop, kill the PID manually:
sudo kill -9 19948

Start or Restart Apache:

sudo systemctl start httpd

sudo systemctl restart httpd

Ensure Network Access

Adjusting Network Access Rules using iptables. A running service does not guarantee external reachability if the system's firewall blocks incoming traffic.

Explicitly add a rule to allow ingress TCP traffic on port 5002. This bridges the gap between the service being "up" and the service being "accessible."

sudo iptables -I INPUT -p tcp --dport 5002 -j ACCEPT

Final End-to-End Verification

The final stage is the verification of the fix from an external source, typically the Jump Host (a secure intermediary server used to access and manage devices in a separate, secure, or private network zone). Using curl provides a definitive test of the entire communication stack.

Final Test: Use the curl utility to request the server's URL

curl http://[hostname/server_ip]:port

Result: A successful return of the site's HTML content confirms that the service is running, correctly bound to the port, and bypasses the firewall correctly

Summary

Investigate using telnet
Identified and terminated the unauthorized process occupying port 5002, successfully releasing the port bind for the web service using ss.
Re-initialized the Apache service after verifying configuration alignment, ensuring it was successfully listening on the designated port using systemctl.
Updated the iptables configuration to explicitly permit external ingress traffic on port 5002, bridging the gap between local service activity and external accessibility.
Confirmed full restoration of the communication path via curl from the jump host, verifying that the web server is once again reachable and performing as expected using curl.

100 Days of Solana — Days 1–4: Keys, Lamports, and My First Browser Wallet

Chus — Mon, 27 Apr 2026 03:04:27 +0000

I've been doing the #100DaysOfSolana challenge and I want to share what the first four days looked like — because the mental shift from Web2 to Web3 hit me harder and faster than I expected.

Day 1 — Generate a Keypair and Get Devnet SOL

I generated my first Solana keypair using the CLI and airdropped free SOL to it on devnet. There was no sign-up form. No email. No password. My entire identity on the network is just 64 bytes — a private key and the public key derived from it. That's it. The blockchain doesn't know who I am.

Day 2 — Create a Wallet and Check Its Balance Programmatically

On this day, I wrote a TypeScript script that loads a saved keypair from disk and fetches its devnet SOL balance using @solana/kit. The balance comes back in lamports, not SOL — and the RPC is just a plain JSON HTTP call. No special SDK magic required if you don't want it. It felt surprisingly close to calling a REST API.

Day 3 — Understand SOL and Lamports

I dug into the unit system — 1 SOL = 1,000,000,000 lamports (like satoshis in Bitcoin or wei in Ethereum). Everything on Solana is paid and measured in lamports internally. Even rent for storing data on-chain is denominated in lamports. The precision exists so micro-transactions are practical without floating-point weirdness.

Day 4 — Connect a Browser Wallet

I built a browser dapp (Vite + React + TypeScript) that detects installed Solana wallets, connects to Phantom with user approval, reads the connected address, and shows the live devnet balance — updated in real time via a WebSocket. The dapp detect any compatible wallet using browser-level interface.

The Concept That Clicked for Me

The whole cryptography model finally made sense across these four days.

In Web2, your identity lives on someone else's server — a username-password pair that a company stores and controls. Lose access to their system, lose your account.

In Solana (and Web3 broadly), your identity is a keypair you generate yourself. The private key never leaves your device. The public key is your address — it's what you share. When you "sign" something, you're using math (Ed25519) to prove you hold the private key without ever revealing it. The network verifies the signature against your public key. No server in between. No account recovery email.

The dapp I built on Day 4 makes this tangible: it calls window.phantom.solana.connect(), Phantom pops up its own approval UI (fully sandboxed), and if you approve, it hands back only your public key. The dapp never sees your private key — not even for a millisecond. That's the guarantee cryptographic signing gives you.

That shift — from trust the server to verify the math — is the real unlock of this whole ecosystem.

Things I'm curious about

how accounts actually store state on-chain beyond just a balance.
rent-exemption and why accounts need a minimum balance to exist.
how transactions are structured and signed.

Identity on Solana: SSH Keys Concept

Chus — Mon, 27 Apr 2026 00:50:52 +0000

If you’ve ever run ssh-keygen to push code to GitHub or access a remote server, you already understand 90% of how identity works on Solana.

In the Web2 world, "identity" is usually something a company lends to you. You have a row in a PostgreSQL database owned by Google or Meta. If they delete that row, your identity vanishes. In the Web3 world—specifically on Solana—identity is something you math into existence.

Here is how we move from "Login with Google" to "Login with Cryptography."

1. The Keypair: Your Global Passport

In Web2, your identity is a Username + Password stored on a centralized server. On Solana, your identity is a Keypair.

A keypair consists of two parts:

The Public Key (Your Address): Think of this like your IBAN (International Bank Account Number) or your email address. You share this with the world so people know where to send SOL or tokens.
The Private Key (Your Signature): This is your "password," but it’s never stored on a server. It stays on your machine (or in your wallet).

When you "log in" to a Solana app, you aren't sending a password to be checked against a database. Instead, you are using your private key to digitally sign a piece of data. The network uses your public key to verify that signature. If the math checks out, you are who you say you are.

N/B: We use a private key to sign transactions (such as sending crypto or messages), while the public key is used to verify those transactions and receive funds.

2. Accounts: The Folders of the Network

On Solana, everything is an Account. If the Solana blockchain is a giant global operating system, accounts are the files.
In Web2, a database might have a users table with columns for balance, username, and profile_pic. On Solana, your public key points to an account on the network that stores:

Lamports: The smallest unit of SOL (named after Leslie Lamport). 1 SOL = 1,000,000,000 lamports.
Owner: The program (smart contract) that is allowed to change the account's data.
Data: A buffer of bytes where information (like your token balances) is stored.

3. Ownership vs. Permission

The biggest "click" moment for a Web2 developer is realizing there is no "Forgot Password" button.

In Web2: You own your account because a company grants you access. They can lock you out or reset your password.
In Web3: You own your account because you hold the private key. Because the network is decentralized, no one—not even the creators of Solana—can "admin" your account.

During my first week diving into Solana, I realized that managing these keys manually is risky. That’s where the "Wallet" comes in. Tools like Phantom (a browser wallet) act as a "Identity Proxy." They hold your private keys securely and provide a UI for you to "Sign" transactions when a web app requests it.

Summary

Identity on Solana isn't a record in a company's database; it’s a cryptographic proof. It’s self-custodied, meaning you are the sole gatekeeper of your digital presence.

If you're coming from a Web2 background, stop thinking about "Accounts" as entries in a table and start thinking about them as cryptographically secured files that only you have the key to edit.