Coder Legion - Recent posts tagged server

Go type yourself!

Fri, 30 Oct 2026 17:47:29 +0000

DHH said that typescript is pure "type masterbation". And though I agree with his premise, It is a fixable problem. And I say we use the type system to do just that.

There is a familiar complaint about TypeScript: too much of the code is types talking to other types. Generic wrappers, schemas restating the same shapes, never tricks to force a switch to be complete. Very little of it does anything at run time.

The complaint is fair, but it usually lands on the wrong target. The TypeScript in a typical full-stack feature is not careless. It is what you have to write to get the guarantees, because TypeScript can't see the parts that matter: what crosses the network, which errors can happen, and whether you handled all of them.

Here is a small, ordinary feature. A page loads a post's title and shows a different message for each way loading can fail.

In TypeScript

// shared/types.ts — the wire contract, stated as types AND as a runtime schema
import { z } from "zod";

export const PostRow = z.object({ title: z.string(), owner: z.string() });
export type PostRow = z.infer<typeof PostRow>;

export type LoadError =
  | { kind: "NotFound"; id: string }
  | { kind: "Forbidden" }
  | { kind: "Unavailable" };

export type Result<T, E> = { ok: true; value: T } | { ok: false; error: E };
export type ApiResponse = Result<string, LoadError>;

// the same contract again, so the client can check at runtime what TS only assumes
export const ApiResponseSchema = z.discriminatedUnion("ok", [
  z.object({ ok: z.literal(true), value: z.string() }),
  z.object({ ok: z.literal(false), error: z.discriminatedUnion("kind", [
    z.object({ kind: z.literal("NotFound"), id: z.string() }),
    z.object({ kind: z.literal("Forbidden") }),
    z.object({ kind: z.literal("Unavailable") }),
  ]) }),
]);

export function assertNever(x: never): never {
  throw new Error(`Unhandled: ${JSON.stringify(x)}`);
}

// app/api/post/route.ts
export async function GET(req: Request): Promise<Response> {
  const id = new URL(req.url).searchParams.get("id") ?? "";
  const viewer = await getViewer(req);
  let row: PostRow | undefined;
  try {
    row = PostRow.optional().parse(
      db.prepare("SELECT title, owner FROM posts WHERE id = ?").get(id));
  } catch {
    return Response.json({ ok: false, error: { kind: "Unavailable" } } satisfies ApiResponse);
  }
  if (!row) return Response.json({ ok: false, error: { kind: "NotFound", id } } satisfies ApiResponse);
  if (row.owner !== viewer) return Response.json({ ok: false, error: { kind: "Forbidden" } } satisfies ApiResponse);
  return Response.json({ ok: true, value: row.title } satisfies ApiResponse);
}

// client
type ClientError = LoadError | { kind: "Transport" };

async function loadTitle(id: string): Promise<Result<string, ClientError>> {
  let res: Response;
  try { res = await fetch(`/api/post?id=${encodeURIComponent(id)}`); }
  catch { return { ok: false, error: { kind: "Transport" } }; }
  const parsed = ApiResponseSchema.safeParse(await res.json());
  return parsed.success ? parsed.data : { ok: false, error: { kind: "Transport" } };
}

function label(r: Awaited<ReturnType<typeof loadTitle>>): string {
  if (r.ok) return r.value;
  switch (r.error.kind) {
    case "NotFound":    return `No post ${r.error.id}`;
    case "Forbidden":   return "Not yours";
    case "Unavailable": return "Try again later";
    case "Transport":   return "Network trouble";
    default:            return assertNever(r.error);
  }
}

In scrml

<program db="./app.db">

type LoadError:enum = { NotFound(id: string), Forbidden, Unavailable }

function loadTitle(id: string, viewer: string) ! LoadError {
    let row = ?{`SELECT title, owner FROM posts WHERE id = ${id}`}.get() !{
        _ :> { fail .Unavailable }
    }
    if (row is not) { fail .NotFound(id) }
    if (row.owner != viewer) { fail .Forbidden }
    return row.title
}

<msg> = ""

function show(id: string) {
    @msg = loadTitle(id, "me") !{
        .NotFound(mid) :> "No post " + mid
        .Forbidden     :> "Not yours"
        .Unavailable   :> "Try again later"
        .Transport(_)  :> "Network trouble"
    }
}

<button onclick=show("1")>Load</>
<p>${@msg}</p>

</program>

Now is'nt that just so much nicer to read?

Where the TypeScript went

TypeScript	scrml
`LoadError` as a union of objects tagged with `kind`	`type LoadError:enum`: variants with payloads are part of the language
`Result<T, E>`, and `ok: true/false` wrapping at every return	`! LoadError` on the signature, `fail .X` in the body. A function that can fail is a language feature, not a library type
A Zod schema restating the wire type so the client can check it at run time	Nothing. `loadTitle` runs on the server because it touches the database, and the compiler writes the encoding for its result and its errors
An API route, a URL, `fetch`, a `try` around `fetch`, and a hand-made `"Transport"` error	`loadTitle(id, "me")` is an ordinary call. A network failure arrives as the built-in `.Transport` variant
`assertNever` and a `default:` branch to make the `switch` complete	The compiler refuses an incomplete handler. Delete the `.Forbidden` line and the build fails: `E-TYPE-080: Non-exhaustive error handler for LoadError. Missing variant(s): Forbidden`
`satisfies ApiResponse` on every `Response.json`	Nothing to satisfy, because no response is written by hand
`Awaited<ReturnType<typeof loadTitle>>`	Nothing to derive, because no type is threaded through generics

The point

None of the TypeScript above is bad. Every line restates something TypeScript cannot see on its own:

the shape of what crosses the wire;
the set of errors a call can produce;
whether every one of them was handled.

You write those types because the compiler is blind to the server, the network and the client as one program.

scrml's compiler is not blind to them. It compiles the server function, the encoding between server and browser, and the client in one pass. So it already knows the error set, already writes the encoding, and can check exhaustiveness itself. You don't need fewer guarantees. You just don't have to restate them by hand.

My Servers Get Scanned Every 40 Seconds. Here's How I Stopped Caring — And Fixed It Anyway

Fri, 11 Sep 2026 17:01:14 +0000

I'm exhausted. Genuinely, professionally exhausted. Every server I stand up, no matter how boring, no matter how "it's just a staging box, nobody even knows the IP" — gets scanned before the SSL cert finishes provisioning. I used to take it personally. I used to open /var/log/auth.log, see four hundred failed logins from some IP block in a country I've never shipped a package to, and think: why me specifically?

It's not you specifically. That's actually the first thing you need to internalize before any of the technical advice below will make sense to you emotionally instead of just intellectually. Internet-wide scanning is background radiation now. GreyNoise's Global Observation Grid clocked roughly 212 exploitation attempts per second across the back half of 2025, from nearly 3 billion malicious sessions and 3.8 million unique source IPs hitting internet-facing infrastructure. You are not being hunted. You are being sampled, by the same dumb scripts that are sampling literally everyone else with a public IP, including your neighbor's smart fridge.

Once that sinks in, the panic turns into engineering, which is a much more useful emotional state. So let's do the engineering.

Myth #1: Changing the SSH Port Is "Security"

No. It isn't. I need you to hear this from someone who has changed the SSH port on every server they've ever owned: it is not security, it is noise reduction. A full port scan finds your "hidden" SSH port in about four seconds, and any attacker who is actually targeting you specifically — as opposed to sweeping the entire IPv4 space with a botnet — will find it just as fast.

What it does do, and this is legitimately worth doing, is cut out the overwhelming majority of low-effort automated scanners that only ever probe port 22 because probing every port on every IP is expensive even for a botnet. Cleaner logs. Less fail2ban noise. Fewer 3 AM "wait, is this real" moments. Do it, but do it with your eyes open: you're sweeping the porch, not installing a deadbolt.

The Actual Deadbolt: SSH Hardening That Isn't Theater

Here's the sshd config that actually matters, and I want you to notice something about it: none of it is exotic. It's the boring stuff nobody does because it involves editing a file instead of installing a shiny dashboard.

# /etc/ssh/sshd_config.d/99-hardening.conf

PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
AuthenticationMethods publickey
PermitEmptyPasswords no
MaxAuthTries 3
MaxSessions 4
LoginGraceTime 20

AllowAgentForwarding no
AllowTcpForwarding no
X11Forwarding no
PermitTunnel no

AllowUsers your_actual_username

ClientAliveInterval 300
ClientAliveCountMax 2

Generate an Ed25519 key if you're still rocking RSA-4096 out of nostalgia — it's smaller, it's faster, and the public key is about 68 characters instead of 800-plus:

ssh-keygen -t ed25519 -C "you@host"

Test your new config in a second terminal before you reload sshd. I'm not going to explain why. If you've never locked yourself out of a box at 2 AM over a typo in sshd_config, you will, and that day will teach you faster than I ever could. Just do the test-in-a-second-terminal thing now and skip the lesson.

sudo sshd -t && sudo systemctl reload sshd

Password authentication being off is the single highest-leverage change on this entire list. GreyNoise's edge report noted a credential-spraying botnet targeting exposed RDP that grew from 2,000 to 300,000 participating IPs in 72 days — a 150x jump in about two and a half months, with the majority of it riding on compromised residential connections. That's the fate of anything on the internet still accepting admin / Password123! in 2026. Don't be the box that's still allowing it out of laziness.

Default-Deny Firewall, Because "Allow Everything, Block What I Notice" Isn't a Strategy

Whatever you use — nftables, ufw, firewalld — the policy should be deny by default, allow the minimum set of ports you actually serve. Not "allow everything and block IPs after they annoy me." Deny-by-default means the scanners hitting the other 65,530 ports just get silently dropped, which also, pleasantly, makes your box slightly harder to fingerprint.

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw limit 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable

That limit instead of allow on SSH isn't a typo — ufw's rate-limiting will auto-block an IP that hits the port more than six times in thirty seconds. It's a free, built-in speed bump before fail2ban even wakes up.

Fail2ban vs CrowdSec: Pick a Fighter

This is where I watch people either overthink it or underthink it, so let's settle it cleanly.

Fail2ban watches your logs, notices repeated failures, and bans the offending IP at the firewall. It's been quietly doing this job for over a decade, it has zero external dependencies, it phones home to nobody, and on a 512MB box it barely registers. If you're running one server with SSH and maybe a web app, fail2ban is completely sufficient and there's a real argument for not overengineering past it.

# /etc/fail2ban/jail.local
[sshd]
enabled = true
maxretry = 3
bantime = 1h
findtime = 10m
ignoreip = your.own.ip.address

That last line matters more than any other line in this entire article. Add your own IP to ignoreip before you enable anything. Locking yourself out of your own server over your own typo is a rite of passage nobody actually enjoys.

CrowdSec does the same local detection but adds a crowdsourced reputation layer: your agent optionally shares anonymized attack signals and receives a community blocklist in return, so an IP that hammered someone else's Ghost blog in Estonia last week gets pre-emptively blocked on your box before it ever sends you a single packet. It splits detection from enforcement — an engine that decides, and separate "bouncers" that actually carry out the ban at the firewall, at your reverse proxy, or in front of multiple servers from one shared decision list.

If you're running a single personal box, fail2ban is fine — go ahead, sleep well. If you're running anything public-facing at scale, multiple servers, or you're just tired of every server relearning the same lessons independently, CrowdSec's shared blocklist and centralized decision-making genuinely earns its extra moving parts.

Patch the Old Stuff. No, Really, the Old Stuff

Here's the part that should offend your sense of narrative logic: GreyNoise's 2026 State of the Edge report found that pre-2015 CVEs generated roughly four times more exploitation traffic than CVEs disclosed in 2023–2024. Shellshock. Old PHP-CGI bugs. Ancient WebLogic flaws. Vulnerabilities old enough to vote are still out there generating millions of exploitation attempts, because there are still millions of boxes nobody ever patched, and scanning for a decade-old known-good exploit is cheaper and more reliable for an attacker than gambling on something novel.

Your bot army isn't targeting you with next-generation zero-days. It's targeting you with the software equivalent of trying every car door in the parking lot, because somewhere, someone genuinely still left it unlocked. Run unattended-upgrades, set a reboot window, and stop assuming "it's old, nobody cares about it anymore" is a security posture. It is, statistically, the opposite of one.

The IP-Reputation Illusion Is Over

If your entire defense strategy is "block IPs that look sketchy," I have bad news. GreyNoise's residential-proxy research, based on 4 billion malicious sessions over 90 days, found that nearly 4 in 10 attacking IPs are residential — ordinary home broadband, mobile data, small-business routers, quietly compromised and rented out as attack infrastructure. One residential proxy network Google's Threat Intelligence Group took down in January 2026 was running 9 to 11 million daily active proxies used by over 550 distinct threat groups, including state-sponsored ones. Your grandmother's router might, statistically, be more dangerous than she is.

The takeaway isn't "give up on IP blocking." It's "don't let IP blocking be your only layer," because the entire premise that you can infer intent from an IP address is, as GreyNoise's own CEO put it, broken at scale. Behavior-based detection (what CrowdSec's scenario engine does, what a WAF does) matters more now than reputation lists alone.

Troll Them Back: Tarpits Are Underrated and Extremely Funny

This is my favorite category, because most security advice is defensive and boring, and tarpits let you be defensive and petty, which is a combination I fully endorse.

Endlessh is an SSH tarpit: point it at port 22 (move your real sshd elsewhere), and it exploits a genuinely funny loophole in the SSH RFC — the server is allowed to send junk banner lines before the real version string, with no upper limit on how long it can stall. Endlessh sends an infinite trickle of random banner bytes, a few bytes every few seconds, and just… holds the connection open. Forever. Automated SSH brute-forcers, which are almost always single-threaded per target and not built to handle a server that never actually says hello, just sit there, burning a thread, going nowhere, for as long as you let them.

docker run -d -p 22:2222 -p 127.0.0.1:2222:2222 --name endlessh figiel/endlessh

Nepenthes and its cousin Iocaine do the same thing for web crawlers instead of SSH bots: an infinite maze of auto-generated fake pages, all linking back into themselves, all stuffed with Markov-chain gibberish that's just structured enough to look like content. Point a misbehaving scraper at it and it doesn't get an error, it doesn't get a block page — it gets an infinite hallway with no exit, and it keeps walking because nothing in its logic tells it to stop. It's less "you shall not pass" and more "you shall pass, forever, into nothing." Deploy it behind a Disallow in robots.txt and let anything that ignores that directive enjoy the consequences.

Neither of these replaces real hardening. Think of them as the security equivalent of leaving out a bowl of pennies for door-to-door scammers — it wastes nobody's time who matters, and it wastes a genuinely satisfying amount of time for everyone else.

Least Exposure: Turn Off What You're Not Using

Every listening service is an entry point you now have to defend, patch, and think about at 3 AM. Run ss -tulpn, look at every single line, and ask yourself honestly whether you meant to expose it.

ss -tulpn

Uninstall what you don't need. Remove build tools and compilers from production hosts — if an attacker does get a foothold, you'd rather they didn't have gcc sitting there ready to compile their next stage for them. This is unglamorous work and it will not show up in a conference talk, but it closes more real doors than any single clever tool on this list.

The Layered Reality Check

None of the above is a silver bullet, and if anyone tries to sell you one tool as "solves scanning forever," check their LinkedIn for how many "growth hacker" job titles they've had. Scanners aren't going away. GreyNoise isn't reporting billions of sessions because attackers are winning some grand campaign against you personally — they're reporting it because sweeping the entire internet costs them almost nothing and occasionally, somewhere, it works. Your job isn't to make yourself unscannable. It's to make yourself boring: patched, key-only, minimally exposed, quietly logged, and — if you're feeling generous — wasting a few bot-hours a day in a tarpit out of pure spite.

Stack the boring layers. Skip the panic. Let the bots enjoy the maze.

How to Configure Nginx as an HTTPS Proxy Server?

Tue, 02 Jun 2026 16:03:57 +0000

Hello, I'm Ganesh. I'm building git-lrc, an AI code reviewer that runs on every commit. It is free, unlimited, and source-available on Github. Star Us to help devs discover the project. Do give it a try and share your feedback for improving the product.

In previous article we could able to setup basic nginx server and server simple html page.

Now let's setup https for our nginx server.

Requirements

Before we start setting up https we should do the following:

Buy a domain name from any registrar.
Set up dns records to point to our server ip.
Setup Certificate for our domain name.
Install nginx on our server.
Set up nginx server to serve our website.

Buying Domain Name

We can buy domain name from any registrar like Namecheap, GoDaddy, etc.

It depends on which name it is and the charges will be around

Setting Up DNS Records

Once buy setup the dns records to point to our server ip.

Example:
For your server the ip address is [IP_ADDRESS].
And your domain name is [EMAIL_ADDRESS]

So, you need to set up a dns record to point to your server ip.

Setting up Certificate

Now let's setup certificate for our domain name.

example.com

so, we setup

sudo certbot --nginx -d `example.com` --email [EMAIL_ADDRESS] --agree-tos --no-eff-email

Here is simple workflow on how certificate is fetched and how

Key generation

The Certbot generates a private key and a CSR (Certificate Signing Request) entirely on your machine.

The private key is the core security guarantee.

HTTP-01 Challenge

Let's Encrypt needs to verify you actually control example.com. It sends Certbot a random token.

Certbot places it at:

/var/www/html/.well-known/acme-challenge/<random-token>

Nginx (already running on port 80) serves this file publicly.

Let's Encrypt fetches the token

LE makes a plain HTTP request to http://example.com/.well-known/acme-challenge/<token>.

If it gets the right response back, it's satisfied that you own the domain.

This is why DNS must be pointing to your server before you run Certbot — if the domain pointed elsewhere, LE would fetch the token from the wrong machine and the challenge would fail.

Certificate issued & saved

LE signs and returns your certificate.

Certbot saves four files to /etc/letsencrypt/live/example.com/:

File	What it is
`fullchain.pem`	Your cert + intermediate CA chain (this is what Nginx uses)
`privkey.pem`	Your private key (Nginx uses this too)
`cert.pem`	Just your cert alone
`chain.pem`	Just the CA chain alone

Nginx config is rewritten

Certbot patches your server block to add the listen 443 ssl lines and the cert paths, and adds a new server { listen 80; } block that redirects all HTTP traffic to HTTPS.

Then it reloads Nginx for you.

Setting up with nginx

Assuming your application running in local host 8090. and you are setting up https for your domain name example.com.

server {
    listen 443 ssl http2;
    server_name example.com;

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

    # All requests — public, no auth
    location / {
        proxy_pass http://localhost:8090;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto https;
    }
}

Add to symlink to sites enabled

sudo ln -s /etc/nginx/sites-available/example.com /etc/nginx/sites-enabled/

Restarting nginx

sudo nginx -t && sudo systemctl reload nginx

Conclusion

We could get https for our domain name example.com.

Any feedback or contributors are welcome! It’s online, source-available, and ready for anyone to use.
⭐ Star it on GitHub: https://github.com/HexmosTech/git-lrc

Public key retrieval is not allowed / Needs improvement

Mon, 25 May 2026 04:13:39 +0000

Today, in this article we will discuss the error message "Public key retrieval is not allowed". This error message is indicating that the system is configured to disallow the retrieval of a public key. This is likely a security measure to prevent unauthorized access to sensitive information. It is recommended to check with the administrator or technical support for further assistance.

What does error "Public key retrieval is not allowed" mean? #

The error message "Public key retrieval is not allowed" usually occurs when an application or service is trying to access a public key from the server it is trying to connect to, but the operation is not allowed due to security or access control measures that prevent the retrieval of the public key.

In cryptography, public keys are used for encryption and digital signatures, while private keys are used for decryption and signing. When you attempt to connect to a server, the system must first retrieve the server's public key to establish a secure connection. If the server's public key cannot be retrieved, the system may not be able to establish a secure connection, and the error message "Public key retrieval is not allowed" will be displayed.

The cause of this error can vary. This may happen be due to a firewall, network restriction, or a policy set by the system administrator. To resolve this issue, you may need to contact your system administrator or network administrator to request access to the public key or check the firewall or network configurations.

Why is the Error Generated? #

The "Public key retrieval is not allowed" error message can occur due to various causes. Some of the most common causes are:

Firewall restriction: Your system may not be able to retrieve the server's public key if the connection is being blocked by a firewall. The firewall may be configured to block connections to the server or to block the retrieval of the public key.
For example; you are trying to connect to a server over a secure connection using SSL/TLS, but the firewall is blocking the connection.
Network restriction: The system may not be able to retrieve the server's public key if there are restrictions in place on the network that prevent the retrieval. This could be due to a policy set by the network administrator or due to a misconfiguration of the network.
Say, you try to retrieve the public key of a server that is located in a different country, but the connection is blocked by the network administrator due to security policies. Then you will receives the error message "Public key retrieval is not allowed."
Access control measures: The server may have security measures in place that prevent unauthorized access to the public key. This could be due to a policy set by the system administrator or due to security software installed on the server e.g. you are trying to connect to a server that has security measures in place to prevent unauthorized access to the public key.
```
import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.SQLException;

public class MySQLConnectionExample {

  public static void main(String[] args) {
    try {
      // Load the MySQL Connector/J driver
      Class.forName("com.mysql.cj.jdbc.Driver");

      // Establish a connection to the MySQL server
      Connection conn = DriverManager.getConnection(
        "jdbc:mysql://localhost:3306/test_db?useSSL=true",
        "username",
        "password"
      );

      System.out.println("Connected to the MySQL server successfully!");

      // Close the connection
      conn.close();
    } catch (SQLException | ClassNotFoundException e) {
      System.out.println("An error occurred while connecting to the MySQL server: " + e.getMessage());
    }
  }
}
```
In this example, we first load the MySQL Connector/J driver using the Class.forName method. Then, we use the DriverManager.getConnection method to establish a connection to the MySQL server. The connection URL includes the useSSL=true parameter, which indicates that we want to use SSL/TLS to secure the connection. We also specify the username and password to use when connecting to the server.
Here when the client is unable to retrieve the public key an error occurs, an exception will be thrown and an error message will be displayed.
IP/domain restrictions: The server may be configured to only allow public key retrieval from specific IP addresses or domains. If you are not on the approved list, it may not be able to retrieve the public key.
An example is that you are trying to connect to a server that is configured to only allow public key retrieval from specific IP addresses or domains and your system is not on the approved list, so the will receive the error.
Incorrect server configuration: The server may be misconfigured, which could prevent the retrieval of the public key. This could be due to an error in the server's settings or due to an incorrect configuration of the server's software. For example, you try to connect to a server that is misconfigured, which prevents the retrieval of the public key.
Certificate issues: The server may have an expired or revoked certificate, which could prevent the retrieval of the public key. In this case, the system may not be able to establish a secure connection with the server. For example, you will try to connect to a server that has an expired or revoked certificate, which prevents the retrieval of the public key.

Note It is important to understand the cause of the "Public key retrieval is not allowed" error in order to resolve it effectively. Depending on the cause, you may need to make apply the appropiate solution.

How to Solve the Error? #

The possible solutions for the causes of the "Public key retrieval is not allowed" error message are as follows:

Firewall restriction: To resolve this issue, you can check the firewall configuration and ensure that the connection to the server is not being blocked. You may also need to open specific ports or add an exception to the firewall to allow the connection.
Network restriction: To resolve this issue, you may need to contact the network administrator and request that the restriction be lifted or that the necessary changes be made to the network configuration.

Access control measures: To resolve this issue, you may need to request access to the public key from the system administrator or the security software provider. The system administrator may need to change the security measures in place to allow you to retrieve the public key. Like, the error in previous coding example occurs due to useSSL=true parameter. Therefore, we change it to useSSL=false as done below.

import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.SQLException;

public class MySQLConnectionExample {

  public static void main(String[] args) {
    try {
      // Load the MySQL Connector/J driver
      Class.forName("com.mysql.cj.jdbc.Driver");

      // Establish a connection to the MySQL server
      Connection conn = DriverManager.getConnection(
        "jdbc:mysql://localhost:3306/test_db?useSSL=false",
        "username",
        "password"
      );

      System.out.println("Connected to the MySQL server successfully!");

      // Close the connection
      conn.close();
    } catch (SQLException | ClassNotFoundException e) {
      System.out.println("An error occurred while connecting to the MySQL server: " + e.getMessage());
    }
  }
}

If you change the value of useSSL in the connection string from true to false, then the connection will no longer attempt to use SSL encryption. This change can resolve the "Public key retrieval is not allowed" error if the issue was caused by a problem with the server's SSL certificate.

IP/domain restrictions: To resolve this issue, one may need to check the server configuration and ensure that your IP address or domain is on the approved list. If the IP address or domain is not on the approved list, you may need to request that it be added.
Incorrect server configuration: To resolve this issue, you may need to check the server configuration and make any necessary changes to ensure that the server is configured correctly. You may also need to check the server software and ensure that it is installed and configured correctly.
Certificate issues: To resolve this issue, you may need to check the server certificate and ensure that it is valid and up-to-date. If the certificate is expired or revoked, you may need to request a new certificate from a trusted certificate authority.

The Conclusion

In conclusion, the "Public key retrieval is not allowed" error message indicates that the your are unable to retrieve the server's public key, which is required to establish a secure connection using SSL/TLS. This error can be caused by various factors, including firewall restrictions, network restrictions, access control measures, IP/domain restrictions, incorrect server configuration, and certificate issues. To resolve the issue you may need to check for the cause of the error in your specific situation and apply the suitable solution.

The References

Some resources for reference or further information are given below:

MySQL Connector/J documentation:
https://dev.mysql.com/doc/connector-j/8.0/en/connector-j-reference-using-ssl.html
Java API documentation:
https://docs.oracle.com/en/java/javase/14/docs/api/java.sql/java/sql/Driver.html
MySQL official forums:
https://forums.mysql.com/

How to Configure Nginx as a Proxy Server?

Fri, 01 May 2026 11:10:59 +0000

In previous article we could able to server simple html page.

Now lets see how to use nginx as a proxy server.

Setting Up a Simple Proxy Server

One of the frequent uses of nginx is setting it up as a proxy server, which means a server that receives requests, passes them to the proxied servers, retrieves responses from them, and sends them to the clients.

We will configure a basic proxy server, which serves requests on behalf of another server running in port 8080.

Here is example of how to configure it.

# This is a comment in the Main Context
worker_processes 1; 

events { 
    # This is a simple directive inside the 'events' context
    worker_connections 1024; 
}

http { 
    # We are now inside the 'http' context

    server { 
        location / {
            proxy_pass http://localhost:8080; # Proxies traffic to the backend on 8080

        }
    }
}

This will be a simple server that listens on the port 8080.

Add Static Files For Existing Proxy Server

let's assume we have a static files in /var/www/html directory and we want to server another application running on port 8080.

so, we can configure both these in nginx it self.

# This is a comment in the Main Context
worker_processes 1; 

events { 
    # This is a simple directive inside the 'events' context
    worker_connections 1024; 
}

http { 
    # We are now inside the 'http' context

    server { 
        location / {
            proxy_pass http://localhost:8080; # Proxies traffic to the backend on 8080

        }

        location /static/ {
            root /var/www/html; # Serves static files from /var/www/html
        }
    }
}

This way we will be able to serve both static files and other server running in port 8080.

Conclusion

We could able to setup simple proxy server and serve both static files and other server running on different port.

Any feedback or contributors are welcome! It’s online, source-available, and ready for anyone to use.
⭐ Star it on GitHub: https://github.com/HexmosTech/git-lrc

Why CI/CD Changed Software Development Forever

Fri, 24 Apr 2026 11:13:00 +0000

There was a time when deploying software was scary.

Really scary.

Developers would write code for weeks…

Then manually deploy everything at once and pray:

“Hope nothing breaks in production.”

Sometimes it worked.

Sometimes…

Production exploded

That’s exactly the problem CI/CD helped solve.

Let’s break it down simply

Before CI/CD: Releases Were Painful

Earlier, shipping software often looked like this:

Developers wrote code for weeks
Changes piled up
Big release day arrived
Team manually deployed everything

And then:

Unexpected bugs
Broken builds
Failed deployments
Long downtime

Releasing software felt risky.

⚠️ Common Problems Before CI/CD

Without automation:

Testing was often manual
Bugs were caught late
Deployments were error-prone
Rollbacks were messy
“Works on my machine” became a lifestyle

Sound familiar?

What is CI/CD?

CI/CD stands for:

✅ Continuous Integration (CI)

Developers push code frequently.

Every change automatically:

Builds the project
Runs tests
Checks if anything broke

Problems are caught early.

Continuous Delivery / Deployment (CD)

After code passes checks:

It can be:

Prepared for release automatically
Or deployed automatically

Shipping becomes faster and safer.

What Happens in a CI/CD Pipeline?

Typical flow:

Code Push → Build → Test → Security Checks → Deploy

Simple idea.

Powerful impact.

Why This Changed Everything

Before:

❌ Big risky releases

Now:

✅ Small frequent safe releases

That changes software development completely.

⚡ Real Benefits of CI/CD

Faster Development

Developers ship features quicker.

No waiting for huge release cycles.

Better Code Quality

Automated tests catch issues early.

Less broken code reaching users.

Safer Deployments

Every deployment follows a repeatable process.

No random manual mistakes.

Faster Bug Fixes

Critical issue?

Push fix.

Pipeline runs.

Deploy.

Done.

Real-World Example

Imagine updating a payment feature.

Without CI/CD:

Manual tests
Manual deploy
High risk

With CI/CD:

Push code
Tests run automatically
Deploy safely

Huge difference.

Tools You’ve Probably Heard Of

Popular CI/CD tools:

GitHub Actions
GitLab CI/CD
Jenkins
CircleCI

Different tools.

Same mission:

Automate software delivery.

Why Modern Teams Can’t Ignore It

Today apps update constantly.

Think about:

Netflix
Amazon
Spotify

They can’t do manual deployments all day.

CI/CD makes modern scale possible.

⚠️ Is CI/CD Just for Big Companies?

No.

Even small projects benefit.

Because automation early saves pain later.

Huge lesson.

The Big Shift

CI/CD changed development from:

❌ “Deploy carefully and hope”

✅ “Deploy confidently and often”

That’s a mindset shift.

Not just a tool shift.

Final Thought

CI/CD didn’t just make deployments faster.

It changed how software gets built.

Less fear.
More automation.
Faster delivery.

And honestly…

Modern software would look very different without it

Cool SQL Server Features You Can Use in Real World.

Fri, 27 Feb 2026 08:17:57 +0000

If you ever had to “fix a batch” of invoices, reset workflow statuses, or reprocess failed documents, you know the pain, one mistake and you either update too much, or you update the right rows but lose the evidence of what changed.

SQL Server has a few features that make these scripts safer, easier to review, and much easier to debug later. Below is a clean demo that you can paste in SSMS and use in your daily work.

SET NOCOUNT ON;
SET XACT_ABORT ON;

BEGIN TRY
    BEGIN TRAN;

    /* 1) Demo table (drop + create) */
    IF OBJECT_ID('dbo.DocumentRepositoryDemo', 'U') IS NOT NULL
        DROP TABLE dbo.DocumentRepositoryDemo;

    CREATE TABLE dbo.DocumentRepositoryDemo
    (
        DocumentRepositoryID bigint IDENTITY(1,1) NOT NULL CONSTRAINT PK_DocumentRepositoryDemo PRIMARY KEY,
        OriginalInvoiceID    varchar(50) NOT NULL,
        WorkflowStatus       int NOT NULL,
        HasResponse          bit NOT NULL,
        IsForwardedTP        bit NOT NULL,
        ModifiedAtUtc        datetime2(3) NULL,
        ModifiedBy           sysname NULL
    );

    /* 2) Seed some fake data */
    INSERT dbo.DocumentRepositoryDemo
        (OriginalInvoiceID, WorkflowStatus, HasResponse, IsForwardedTP, ModifiedAtUtc, ModifiedBy)
    VALUES
        ('7601002721400-318242', 2, 1, 1, SYSUTCDATETIME(), SUSER_SNAME()),
        ('7601002721400-318161', 3, 1, 0, SYSUTCDATETIME(), SUSER_SNAME()),
        ('7601001392038-318127', 4, 0, 1, SYSUTCDATETIME(), SUSER_SNAME()),
        ('7601000777447-967851', 9, 0, 0, SYSUTCDATETIME(), SUSER_SNAME()),
        ('7601000777447-968159', 1, 1, 1, SYSUTCDATETIME(), SUSER_SNAME());

    /* 3) Target list (table variable) */
    DECLARE @InvoiceIds TABLE
    (
        OriginalInvoiceID varchar(50) NOT NULL PRIMARY KEY
    );

    INSERT INTO @InvoiceIds (OriginalInvoiceID)
    VALUES
        ('7601002721400-318242'),
        ('7601002721400-318161'),
        ('7601000777447-968159');

    /* 4) Change tracking (audit table variable) */
    DECLARE @Changed TABLE
    (
        DocumentRepositoryID bigint,
        OriginalInvoiceID    varchar(50),
        OldWorkflowStatus    int,
        NewWorkflowStatus    int,
        OldHasResponse       bit,
        NewHasResponse       bit,
        OldIsForwardedTP     bit,
        NewIsForwardedTP     bit,
        ChangedAtUtc         datetime2(3),
        ChangedBy            sysname
    );

    /* 5) Update + capture before/after with OUTPUT */
    UPDATE dr
        SET dr.WorkflowStatus = 5,
            dr.HasResponse = 0,
            dr.IsForwardedTP = 0,
            dr.ModifiedAtUtc = SYSUTCDATETIME(),
            dr.ModifiedBy = SUSER_SNAME()
    OUTPUT
        deleted.DocumentRepositoryID,
        deleted.OriginalInvoiceID,
        deleted.WorkflowStatus, inserted.WorkflowStatus,
        deleted.HasResponse, inserted.HasResponse,
        deleted.IsForwardedTP, inserted.IsForwardedTP,
        inserted.ModifiedAtUtc,
        inserted.ModifiedBy
    INTO @Changed
    (
        DocumentRepositoryID,
        OriginalInvoiceID,
        OldWorkflowStatus, NewWorkflowStatus,
        OldHasResponse, NewHasResponse,
        OldIsForwardedTP, NewIsForwardedTP,
        ChangedAtUtc,
        ChangedBy
    )
    FROM dbo.DocumentRepositoryDemo dr
    INNER JOIN @InvoiceIds i
        ON i.OriginalInvoiceID = dr.OriginalInvoiceID
    WHERE dr.WorkflowStatus <> 5
       OR dr.HasResponse <> 0
       OR dr.IsForwardedTP <> 0;

    /* 6) Results */
    SELECT *
    FROM @Changed
    ORDER BY OriginalInvoiceID, DocumentRepositoryID;

    SELECT COUNT(*) AS RowsUpdated
    FROM @Changed;

    COMMIT TRAN
END TRY
BEGIN CATCH
    IF XACT_STATE() <> 0
        ROLLBACK TRAN
    THROW
END CATCH

What makes this “SQL Server cool” (and why it matters)

SQL Server normally prints messages like “(1 row affected)” after every statement. That is fine in ad hoc work, but noisy in scripts that do multiple steps.

With SET NOCOUNT ON:

result sets stay clean (only the output you intentionally select),
less chatter between server and client,
stored procedures often become easier to consume from apps and jobs.

SET XACT_ABORT ON

With XACT_ABORT ON, when a runtime error happens (conversion, constraint violation, etc.), SQL Server forces the transaction into a state where it cannot silently continue. In practice, this reduces the chance you end up with a transaction left open, or partially executed logic that you forget to undo.

It pairs perfectly with TRY/CATCH because it pushes you toward “all or nothing”.

3) TRY/CATCH + XACT_STATE(), predictable rollback logic

XACT_STATE() helps because it tells you the transaction state:

1 there is an active, committable transaction
-1 the transaction is uncommittable, you must rollback
0 no active transaction

That is why this pattern is so common:

IF XACT_STATE() <> 0
    ROLLBACK TRAN;

4) Table variables as “scoped in memory tables”

This script uses two table variables:

@InvoiceIds is a safe target list

@Changed is an audit collector

Why that’s useful:

you avoid long IN (...) lists inside the update,
your target list can be validated and deduped (the PRIMARY KEY
prevents duplicates),
you keep the update set based, readable, and reviewable.

Important detail for accuracy: table variables are often called “in memory”, but they can spill to tempdb depending on size and query plan. Still, they are great for small and medium sets.

5) OUTPUT deleted, inserted, instant before/after audit

This is one of the most underrated features for operational work.

OUTPUT gives you:

deleted.* values before the update
inserted.* values after the update

So you can:

show exactly what changed,
store it into @Changed, optionally persist
it into a real audit table.

This is the difference between “I ran a script” and “I can prove exactly what the script did”.

Takeaways :

NOCOUNT keeps scripts readable and reduces noise.
XACT_ABORT makes failure behavior safer.
TRY/CATCH plus XACT_STATE() gives you consistent rollback behavior.
Table variables make targeting and audit capture clean and scoped.
OUTPUT gives you real auditing with almost no extra effort.
Avoiding unnecessary updates is a performance win and a safety win.

Coder Legion - Recent posts tagged server

Go type yourself!

In TypeScript

In scrml

Where the TypeScript went

The point

My Servers Get Scanned Every 40 Seconds. Here's How I Stopped Caring — And Fixed It Anyway

Myth #1: Changing the SSH Port Is "Security"

The Actual Deadbolt: SSH Hardening That Isn't Theater

Default-Deny Firewall, Because "Allow Everything, Block What I Notice" Isn't a Strategy

Fail2ban vs CrowdSec: Pick a Fighter

Patch the Old Stuff. No, Really, the Old Stuff

The IP-Reputation Illusion Is Over

Troll Them Back: Tarpits Are Underrated and Extremely Funny

Least Exposure: Turn Off What You're Not Using

The Layered Reality Check

How to Configure Nginx as an HTTPS Proxy Server?

Buying Domain Name

Setting Up DNS Records

Setting up Certificate

Setting up with nginx

Conclusion

Public key retrieval is not allowed / Needs improvement

Table of Contents:

What does error "Public key retrieval is not allowed" mean? #

Why is the Error Generated? #

How to Solve the Error? #

The Conclusion

The References

How to Configure Nginx as a Proxy Server?

Setting Up a Simple Proxy Server

Add Static Files For Existing Proxy Server

Conclusion

Why CI/CD Changed Software Development Forever

Before CI/CD: Releases Were Painful

⚠️ Common Problems Before CI/CD

What is CI/CD?

✅ Continuous Integration (CI)

Continuous Delivery / Deployment (CD)

What Happens in a CI/CD Pipeline?

Why This Changed Everything

⚡ Real Benefits of CI/CD

Faster Development

Better Code Quality

Safer Deployments

Faster Bug Fixes

Real-World Example

Tools You’ve Probably Heard Of

Why Modern Teams Can’t Ignore It

⚠️ Is CI/CD Just for Big Companies?

The Big Shift

Final Thought

Cool SQL Server Features You Can Use in Real World.