Ghost in the Edge: How a 30-Second EIP Fix Ended a Production Outage That Defied Every Diagnostic

Author: , Posted on Sunday, March 29th, 2026 at 6:13:49am

A deep-dive into a phantom AWS networking failure where every indicator said the server was healthy, every diagnostic came back clean, and the fix turned out to be one CLI command that most troubleshooting guides never mention.

March 29, 2026 · Vermont, USA → us-east-1 · ~18 min read


The Sunday Morning Alert

It started the way production incidents always start: quietly, at a bad time. Early on a Sunday morning, routine monitoring showed that web3 — a public-facing Amazon Linux 2 EC2 instance in us-east-1 — was responding intermittently. Pings were dropping. SSH connections were sluggish and unreliable. HTTP requests were timing out.

The initial ping test told the story in numbers:

Twenty-seven percent packet loss to a production endpoint. On its own, ICMP loss isn’t conclusive — routers regularly deprioritize ping traffic. But SSH confirmed the problem was real: connections established but were crippled, with visible lag and frequent stalls. This wasn’t cosmetic. This was a production outage affecting all public traffic.


Ruling Out the Obvious

The first instinct in any EC2 networking incident is to look at the instance itself. Is the NIC failing? Has the kernel wedged something? Did a reboot break the driver? We ran through the standard checklist methodically, and everything came back clean.

ENA Driver and NIC Health

The Elastic Network Adapter statistics — the gold standard for diagnosing EC2 networking problems — showed nothing wrong:

Every counter that matters was zero. No bandwidth allowance exhaustion, no packet-per-second throttling, no conntrack overflow, no DMA mapping errors, no missed interrupts. The ENA driver logged a completely normal initialization sequence on boot with no resets, link flaps, or timeout storms. On paper, this NIC was in perfect health.

Interface Counters

The interface-level statistics told the same story:

Zero errors, zero drops, zero missed packets at the interface level. Whatever was happening to traffic wasn’t being caught by the local NIC’s counters.

Firewall and Routing

The routing table was textbook-simple: a default gateway through the VPC router, a local subnet route, and the metadata service endpoint. No stray routes, no blackholes, no policy routing complexity.

Firewall rules were minimal — just a single ipset-based blocklist with a default ACCEPT policy on all chains. No NAT rules. No nftables ruleset. Nothing that could explain blanket public-path degradation.

The Reboot Question

An important clarification came early: the problem started before any reboot. The reboot was attempted as a remediation, not a root cause. This was significant because it immediately deprioritized kernel driver regression, post-reboot NIC initialization failures, and DHCP lease problems — the usual suspects when trouble appears after a restart.

A full stop/start cycle — which, unlike a reboot, migrates the instance to a completely different physical hypervisor — was also performed. The problem persisted. Whatever was wrong wasn’t tied to the underlying hardware host.

Key Distinction: Reboot vs. Stop/Start

An EC2 reboot restarts the operating system on the same physical host. A stop/start deallocates the instance entirely and relaunches it on a new hypervisor, giving you a new underlying server, new NUMA topology, and potentially a different rack. The fact that stop/start didn’t help was a strong signal: this wasn’t a host-level hardware or hypervisor problem.


The Decisive Clue: Private vs. Public Path

The breakthrough came from comparing SSH socket statistics between two simultaneous connections to the same server — one arriving over the private VPC path from a jump host, and one arriving over the public internet.

Look at those numbers. The private path was running at full wire speed with a congestion window of 20, zero retransmissions, and sub-millisecond RTT. The public path had collapsed to a congestion window of 2, had 25 retransmissions on a single session, and was barely pushing a megabit. Same server, same kernel, same NIC, same moment in time. The server was healthy. The private network was healthy. Something between the AWS edge and the public internet was broken.

The MTR Comparison That Sealed It

To confirm, we ran MTR tests from the same Mac client to two different EC2 instances — one to web3 (the problem host) and one to dev10 (a healthy host in the same region). Both tests traversed the same ISP path through Vermontel, the same upstream routers, and the same initial hops:

Test Target Final Hop Loss Avg Latency Verdict
dev10 (prod06.thewyz.net) 0.0% 19.7ms ✅ CLEAN
web3 (web2.thewyz.net) 14.0% 17.3ms ❌ DEGRADED

Same client. Same ISP. Same upstream path through Vermontel. One AWS host was clean, the other was losing 14% of packets at the final hop. The MTR from within web3 to the client’s public IP also showed dramatic latency spikes — hop 5, sitting between the AWS edge network (AS16509) and the client’s ISP, averaged 363ms with spikes to 7,197ms:

That hop — 206.82.104.8 — sat at the boundary between AWS’s internal edge network and the transit path toward Vermontel. It was the inflection point where packets went from healthy to sick.

One More Confirmation

We also verified that web3 was reachable cleanly from dev10 inside AWS. That meant the instance itself, its VPC path, its security groups, and its internal networking were all fine. The problem was exclusively on the public-facing path — specifically, on the path associated with web3’s Elastic IP.


Understanding the Invisible Layer: How EC2 Public IPs Actually Work

To understand why this happened and why the fix worked, you need to understand something that AWS doesn’t heavily advertise: EC2 instances never actually have public IP addresses.

When you assign a public IPv4 address — whether it’s an auto-assigned public IP or an Elastic IP — that address doesn’t live on the instance’s network interface. Run ifconfig or ip addr on an EC2 instance and you’ll only see the private IP. The public address exists only as a NAT mapping maintained by the Internet Gateway (IGW) at the edge of AWS’s network.

As AWS’s own documentation states, public IPv4 addresses are “technically implemented as a network address translation mechanism at the edge of AWS’s network.” Here’s the packet flow for every single public request hitting an EC2 instance:

Inbound: A packet arrives at AWS’s edge network addressed to the EIP (e.g., 52.201.74.79). The IGW translates the destination from the EIP to the instance’s private IP (10.1.0.207) and forwards it into the VPC. The instance sees only a packet addressed to its private IP.

Outbound: The instance sends a packet from its private IP. The VPC router forwards it to the IGW. The IGW translates the source from the private IP to the EIP and sends it out to the internet.

This 1:1 NAT mapping is maintained by the Internet Gateway — a managed, horizontally scaled AWS service that operates at the edge of the VPC. It’s the invisible layer between your instance and the public internet. You never see it. You can’t SSH into it. You can’t reboot it. You can’t even ping it. But every public packet to and from your instance passes through it.


The Fix: 30 Seconds, Two Commands

With the diagnosis pointing squarely at the edge-layer mapping rather than the instance, we tried the simplest possible intervention: disassociating the Elastic IP from the instance and immediately re-associating it.

That was it. Same EIP. Same instance. No DNS change. No server migration. No configuration change. The entire operation took less than 30 seconds.

Immediately after re-association, the public path was clean. Pings returned to 20ms with zero loss. SSH was instantaneous. HTTP traffic flowed normally. The production outage was over.


What Actually Went Wrong: A Technical Speculation

AWS does not publish the internal architecture of the Internet Gateway or its EIP NAT subsystem in detail. What follows is informed speculation based on publicly available information about AWS networking architecture, observed behavior, and general principles of large-scale NAT and edge networking systems.

The IGW as a Distributed NAT Fabric

AWS’s Internet Gateway is not a single device. It’s a horizontally scaled, distributed service that operates at the edge of each VPC. When an EIP is associated with an instance, the IGW creates an internal mapping record that ties the public address to the instance’s private address and ENI. This mapping determines not just the address translation, but also the physical path that packets take through AWS’s edge infrastructure.

AWS’s edge network connects to the public internet through a mesh of peering points, transit agreements, and edge routers across each region. The AS16509 hops visible in traceroute output represent this edge infrastructure. Different EIPs — even in the same region and AZ — may be mapped to different physical edge nodes based on load balancing, IP range assignments, and internal topology decisions.

Hypothesis 1: Stale or Wedged Edge-Node Mapping

The most likely explanation is that the EIP’s association had become bound to a specific edge node or NAT processing path that was experiencing degradation. This could happen through several mechanisms.

Large-scale NAT systems often maintain persistent forwarding state for each mapping. This state includes not just the address translation rule, but also the specific forwarding path — which edge router, which line card, which interface. If the underlying node experiences a partial failure (think: a single line card dropping packets intermittently, or a buffer overflow in a specific forwarding ASIC), the NAT mapping would continue to send traffic through the degraded path because the mapping itself was still “valid.”

Disassociating and re-associating the EIP forced the IGW to tear down the existing mapping and create a new one from scratch. The new mapping was assigned to a different (healthy) edge path, and traffic immediately recovered.

Hypothesis 2: Asymmetric Path Degradation

The MTR data showed different behavior depending on direction and source. Traffic from dev10 (another AWS host) to web3 was clean — because that traffic never leaves the AWS fabric. Traffic from web3 to the client showed massive latency spikes at the edge boundary. This pattern is consistent with a specific outbound edge path being degraded.

In large BGP-based routing fabrics, the outbound path (AWS → internet) and the inbound path (internet → AWS) are often asymmetric. AWS’s edge routers select outbound paths based on BGP best-path calculations, local preference settings, and traffic engineering policies. An EIP mapped to a particular edge node would have its outbound traffic follow that node’s BGP-selected path. If that specific path was congested or partially failed, all traffic through that mapping would suffer — while other EIPs mapped to different edge nodes would be unaffected.

This perfectly explains why dev10 (different EIP, different edge mapping) was clean from the same client, while web3 was degraded.

Hypothesis 3: AWS Internal Maintenance or Micro-Outage

AWS operates a massive edge network that peers with thousands of ISPs and transit providers. Within this infrastructure, maintenance events — BGP session resets, line card replacements, firmware updates, fiber cuts — happen continuously. Most are invisible because traffic is rerouted seamlessly.

However, if an EIP’s NAT mapping was pinned to a specific edge path during a micro-outage, and the IGW’s internal health-checking didn’t detect the partial degradation (perhaps because the node was still forwarding some packets, just with high loss), the mapping could remain stuck on the bad path indefinitely. The stop/start didn’t help because it moves the instance to a new hypervisor — it doesn’t remap the EIP’s edge path. Only disassociating and re-associating the EIP forced the edge-layer remapping.

Why Stop/Start Didn’t Fix It

This is the crucial architectural point. When you stop and start an EC2 instance, several things change: the underlying physical host, the hypervisor slot, and potentially the rack. But the EIP association is maintained transparently across stop/start cycles — that’s the entire point of Elastic IPs. AWS preserves the mapping so your public endpoint remains stable.

The problem is that “preserving the mapping” likely also preserves the edge-layer forwarding state. The IGW doesn’t rebuild the NAT mapping from scratch during a stop/start — it maintains the existing mapping and simply updates the internal private-IP target when the instance comes back on a new host. The edge path stays the same. The degraded forwarding path stays the same.

Only explicitly breaking and recreating the EIP association forces the IGW to fully tear down and rebuild the mapping — including the edge forwarding path selection.

The Car Analogy

Imagine you’re driving to work every day using GPS navigation. One day, a bridge on your usual route develops a dangerous pothole that causes intermittent tire damage. Your GPS keeps routing you over that bridge because the bridge is technically “open.” Buying a new car (stop/start = new hypervisor) doesn’t help — the GPS still picks the same route. Even moving to a different house on the same street (instance resize) doesn’t help. The fix is to close and reopen the GPS app (disassociate/re-associate the EIP), forcing it to recalculate the route from scratch and pick a different bridge.


The Diagnostic Trail: Why Each Test Mattered

What made this incident challenging was that every standard diagnostic returned clean results. Here’s a summary of what each test told us — and, critically, what it didn’t tell us:

Diagnostic Result What It Proved
ethtool -S eth0 ✅ ALL ZEROS ENA driver and NIC hardware are healthy
ip -s link show ✅ NO ERRORS Interface is passing packets cleanly at local level
ip route ✅ NORMAL No routing anomalies inside the instance
iptables -L -n -v ✅ MINIMAL No firewall rules blocking or degrading traffic
Private SSH (jump host) ✅ 2.09 Gbps Instance internals, VPC networking, private path perfect
Public SSH (Mac/ISP) ❌ 1.12 Mbps Public path is severely degraded
MTR to dev10 (good host) ✅ 0% LOSS ISP path to AWS is healthy. Problem is host-specific
MTR to web3 (bad host) ❌ 14% LOSS Something specific to web3’s public endpoint is broken
dev10 → web3 (AWS internal) ✅ CLEAN Problem is not on the instance. It’s on the public edge path
Stop/start (hypervisor migration) ❌ NO CHANGE Problem is not hardware. EIP mapping preserved bad path
EIP disassociate/re-associate ✅ FIXED Problem was in the EIP’s edge-layer forwarding state

The TCP Evidence That Tells the Whole Story

The netstat -s output captured during the incident provides a TCP-level view of the damage. These counters represent cumulative pain across all connections on the instance:

Counter Value Significance
Segments retransmitted 444 Substantial retransmission load for a lightly-trafficked host
TCPLostRetransmit 215 Retransmitted segments themselves lost — double loss
Fast retransmits 79 TCP detected loss via duplicate ACKs, not just timeouts
TCPSackRecoveryFail 35 SACK-based recovery couldn’t fix the loss
IpOutNoRoutes 61 Some packets had no route — possibly edge-layer churn

The TCPLostRetransmit counter at 215 is particularly telling. This means the kernel retransmitted a segment, and the retransmission itself was lost. That only happens with sustained, non-trivial packet loss — exactly what you’d expect from a degraded forwarding path at the edge layer. The SACK recovery failures (35 events) compound this: even TCP’s most sophisticated loss-recovery mechanism (Selective Acknowledgment) was unable to recover gracefully because the underlying path was continuously dropping packets.

The per-socket state on the degraded public SSH connection showed the TCP congestion control algorithm had given up trying to grow the window. The cwnd:2 and ssthresh:2 values mean TCP’s congestion window had collapsed to its minimum — the connection was operating in permanent slow-start-like behavior, unable to sustain throughput because every attempt to open the window was met with more loss.


Why This Diagnosis Was So Hard

This incident was tricky because it violated several standard assumptions that guide network troubleshooting:

Assumption: if the NIC is healthy, the network is healthy. Not true. The NIC only sees packets after the edge-layer NAT. A degraded edge path drops or delays packets before they ever reach the NIC on the inbound side, and after they leave the NIC on the outbound side. The NIC’s counters will be spotless even as the public path bleeds packets.

Assumption: a stop/start fixes host-level problems. It does — for hypervisor, hardware, and NIC problems. It does not reset the EIP’s edge-layer forwarding state. The EIP association is maintained across stop/start cycles by design.

Assumption: if the problem isn’t the ISP, it must be the instance. Not necessarily. The IGW’s edge-layer NAT is a third party in the conversation — neither the ISP nor the instance. It’s an invisible, unmonitorable intermediary that you can’t SSH into, can’t traceroute through, and can’t inspect with any standard tool.

Assumption: if another host works from the same client, the problem is on the failing instance. Close, but not quite. It could also be on the failing instance’s EIP mapping — a distinction that matters enormously for selecting the right fix.


Broader Lessons for AWS Operators

Add EIP Reassociation to Your Troubleshooting Playbook

Most AWS troubleshooting guides for EC2 networking focus on security groups, NACLs, route tables, ENA driver health, and instance-level firewalls. Almost none mention EIP disassociation and re-association as a diagnostic or remediation step. Based on this incident, it should be among the first things you try when you see public-path-specific degradation with clean private-path behavior. It takes 30 seconds and has no downside when the public path is already broken.

Always Compare Private and Public Paths

The single most valuable diagnostic in this incident was the side-by-side ss -ti comparison of a private-path SSH socket and a public-path SSH socket. If you have a jump host or bastion in the same VPC, use it. Compare congestion windows, retransmission counts, and throughput. If the private path is perfect and the public path is degraded, you know the problem is above the instance — somewhere in the edge/IGW/transit layer.

Test From Multiple External Paths

This incident would have been resolved faster if we had initially tested from a second ISP path (a cellular hotspot, a VPN endpoint, or a remote colleague). Confirming that the problem was specific to one EIP’s edge path — rather than a general AWS issue or a general ISP issue — would have pointed directly at EIP reassociation as the fix.

Don’t Migrate When You Can Remap

The initial plan was a full server migration from Amazon Linux 2 to Rocky Linux 10 — a multi-hour project under production outage pressure. That migration is still strategically correct (AL2 reaches end of support on June 30, 2026), but doing it as an emergency response to a networking incident would have been unnecessarily risky. The actual fix took 30 seconds. The migration can now happen on a scheduled maintenance window with proper testing and validation.


References and Further Reading


Timeline

Time (ET) Event
~03:00 Symptoms first noticed — intermittent SSH, ICMP loss
~03:30 Reboot attempted — no improvement
~04:00 Full stop/resize/start cycle — no improvement
~04:30 ENA, interface, firewall, routing diagnostics — all clean
~05:00 TCP socket comparison reveals private-path healthy, public-path degraded
~05:05 MTR comparison: dev10 clean, web3 degraded from same client
~05:10 Jump host confirms private access to web3 is perfect
~05:15 dev10 → web3 confirmed clean (AWS internal path healthy)
~05:16 EIP disassociated and re-associated
~05:17 SERVICE RESTORED — all public paths clean

Total time from first symptom to resolution: approximately 2 hours 17 minutes. Time spent on the actual fix: approximately 30 seconds.


Final Thought

The lesson of this incident isn’t “EIPs are unreliable.” They’re not — this was a rare edge case, probably a one-in-a-million interaction between a specific EIP mapping and a specific edge node state. The lesson is that AWS’s abstraction layers are deep, and when something goes wrong in a layer you can’t see, the symptoms can be profoundly confusing. Adding EIP reassociation to your mental toolkit — right alongside “have you tried turning it off and on again” — could save you hours of misdiagnosis on a day when hours matter.

Published March 29, 2026 · Written during a live production incident · No servers were harmed in the writing of this post (one was fixed)

When Everyone Starts Thinking the Same: Outsmarting the Modern Mob Mind

Author: , Posted on Tuesday, October 21st, 2025 at 3:54:52am

A practical guide for everyday readers on recognizing herd mentality online and choosing wiser actions.

We live in a time where one viral post can move markets, ruin reputations, or spark revolutions before breakfast.

What once took months of meetings and pamphlets now happens in minutes on a phone. This is mob psychology reborn – not in city squares, but inside our screens.

The Power and the Peril

When people unite, extraordinary things happen: disaster relief gets funded, injustice is exposed, and neighbors rally to help. But the same energy can turn destructive—spreading misinformation, division, and blame faster than truth can catch up.

Human minds synchronize easily. When “everyone” around us believes or feels something strongly, our brains whisper,

“They can’t all be wrong.”

That’s when independent thinking goes quiet.

The Quiet Costs of Herd Thinking

When crowd reflexes take over, we risk losing what makes us wise:

  • Perspective: Nuance disappears when ideas must fit a headline.
  • Patience: Outrage punishes before facts are known.
  • Independence: Belonging feels safer than thinking.
  • Empathy: Avatars replace faces; compassion fades.

Six Ways to Outsmart the Herd

  1. Pause before sharing. If a post makes you furious or ecstatic, that’s a signal to slow down. Ask: “Who benefits if I react?”
  2. Diversify your feed. Follow credible voices that disagree with one another. A balanced diet keeps your mind resilient.
  3. Ask, don’t attack. Swap the impulse to “win” for curiosity: “What makes you think that?” It cools tempers and opens dialogue.
  4. Reward calm voices. Share thoughtful posts and people who admit uncertainty. You retrain the algorithm with every share.
  5. Make space for quiet. Walk, read long-form, talk face-to-face. Real thinking needs silence.
  6. Remember the human. Behind every comment is a person with fear, history, and hope. Seeing that breaks the illusion of “us vs. them.”

A call to conscious participation

We can’t rewind technology, but we can refine our humanity. The same tools that amplify mobs can amplify mindfulness, kindness, and truth—if we use them deliberately.

The next time the crowd shouts, take a breath and ask:

“Am I thinking – or just joining?”

Good Is Winning: The Quiet Arithmetic of Hope

Author: , Posted on Monday, October 13th, 2025 at 9:55:51am

In a world that feels divided and chaotic, the numbers tell a different story — one of steady, human progress.

Every era asks the same uneasy question: Is evil winning? The answer, grounded in fact and history, is no. Good is not only holding the line — it’s winning, quietly and steadily.

When we measure the world not by headlines but by hard numbers — health, education, safety, and compassion translated into data — we see a clear story: the arc of humanity bends toward cooperation, not cruelty.

Violence Has Fallen

Global homicide rates have declined since the 1990s, according to the United Nations Office on Drugs and Crime. Even with modern conflicts making tragic headlines, deaths from war represent a tiny fraction of global mortality — roughly 1 in 700 deaths in 2019.
Violence grabs attention because it’s visible and immediate; peace, by contrast, is quiet. Yet statistically, most people on Earth live their entire lives without direct experience of war or violent crime.

Humanity Is Living Longer

In 1900, average life expectancy hovered near 30 years. Today, it exceeds 73 years globally. Despite the pandemic’s setback, the recovery was swift — proof of coordinated global response, science, and solidarity on a scale unimaginable a century ago.

Child survival has improved dramatically. Since 1990, under-five mortality dropped by 61%, saving millions of young lives each year. This is compassion turned into policy, infrastructure, and medicine.

Poverty Is Shrinking

Extreme poverty — once the norm for most humans — is now the exception. In 1990, nearly 30% of humanity lived in extreme poverty. As of 2022, that figure fell to about 9%. That’s 1.5 billion people lifted up, mostly through education, trade, and global cooperation.

Even outside China, the trend holds: sustained improvement across Africa, South Asia, and Latin America shows what consistent investment in human potential can do.

Knowledge and Cooperation Are Rising

Literacy is the quiet revolution. Global adult literacy climbed from 81% to 87% since 2000, and youth literacy now exceeds 92%. Every reader added to the world is another mind capable of empathy, innovation, and understanding — the raw materials of good.

And when disaster strikes, coordinated humanity responds. Deaths from natural disasters today are a fraction of those a century ago, thanks to early warning systems, international relief, and shared data — proof that collaboration saves lives.

The Math of Good

When you step back, the pattern is unmistakable.

  • Fewer people die violently.
  • More people live longer, safer, and healthier lives.
  • More minds can read, learn, and connect.
  • Fewer children die from preventable causes.
  • More of us are choosing cooperation over conflict.

That is what winning looks like — not a sudden victory, but a persistent, quiet triumph. Evil shouts; good builds. And the scaffolding of progress — hospitals, schools, vaccines, rights — stands because billions of ordinary people choose to act decently every day.

The world isn’t perfect, but it’s profoundly better than it was.

The arithmetic is in, and the numbers are clear: good is winning.

Population Growth vs. Resource Consumption: A Critical Imbalance

Author: , Posted on Saturday, August 9th, 2025 at 3:37:04pm

Over the last quarter-century, humanity has witnessed remarkable demographic growth—and an even greater surge in resource consumption.

Population Growth Since 2000
In the year 2000, the global population stood at approximately 6.17 billion people. By 2025, it is estimated to reach about 8.23 billion—an increase of roughly 2.06 billion, or about 33%.

Resource Consumption Growth
While population has grown significantly, global resource extraction has risen even faster:
– Total global extraction of materials has tripled over the past 50 years and is projected to increase by another 60% by 2045–2060.
– Only around 25% of this increase is due to population growth; the remaining 75% is the result of higher per-capita consumption.
– Per-person material use rose from 8.1 metric tons in 1990 to 12.2 metric tons in 2017—an increase of about 50%.
– Humanity now consumes resources at a rate equivalent to 1.7 Earths, meaning we are using resources 70% faster than the planet can regenerate.

Inequality in Consumption
Consumption is far from evenly distributed:
– High-income countries average around 27 metric tons of materials per person per year.
– Low-income countries average just 2 metric tons per person.
– The richest 20% of people have doubled their use of energy, meat, timber, and metals since 2000, and quadrupled car ownership. The poorest 20% have seen minimal change.

Drivers of Increased Consumption
The formula I = P × A × T (Impact = Population × Affluence × Technology) explains the imbalance. Even with some efficiency improvements, overall impact has risen because economic growth and affluence have outpaced gains in sustainable technology.

Projected Future Impacts
If current trends continue:
– By 2050, the global population could approach 9.7 billion.
– Resource consumption could double from 2020 levels, exceeding sustainable limits even further.
– Ecological overshoot will deepen, accelerating climate change, biodiversity loss, and water scarcity.
– The gap between high- and low-income nations in resource use will likely widen, exacerbating global inequality and geopolitical tensions.

Conclusion
Population growth is a challenge, but the more urgent issue is the rise in per-capita resource consumption, particularly in affluent societies. Without significant changes in consumption patterns, efficiency, and equitable distribution, the planet’s ecological systems may face irreversible damage within the century.

Sustainable solutions will require a combined focus on stabilizing population growth, reducing wasteful consumption, and accelerating innovations in renewable energy, circular economies, and resource efficiency.

How To Fix `do_sigver_init:no default digest` and Upgrading to AWS Signature Version 4 for S3 Uploads in Perl

Author: , Posted on Monday, July 28th, 2025 at 8:03:35am

When performing direct S3 file uploads using custom Perl scripts, I recently encountered the following cryptic error:

Alongside this, the AWS S3 server returned:

This post explains:

* What causes the error
* Why it’s tied to deprecated AWS Signature Version 2 (SigV2)
* How to fully upgrade a Perl curl‑based S3 upload to Signature Version 4 (SigV4) using only core Perl modules


💥 The Problem

OpenSSL 3.0 Breaks Legacy HMAC Signatures

The OpenSSL error stems from a breaking change in OpenSSL 3.0+: digest algorithms (like **SHA‑1**) must now be explicitly declared when performing cryptographic operations. Legacy command‑line usage such as:

fails under OpenSSL 3+ with:

AWS Signature V2 Is Deprecated

The second error shows the deeper issue: the upload was signed using **Signature Version 2**, now deprecated and unsupported in most AWS regions.

SigV2 looks like:

AWS now requires **Signature Version 4**, which uses HMAC‑SHA256, a canonical request, and more secure metadata.


✅ The Solution: ✨ Rewrite the S3 Upload to Use Signature Version 4

Below is the refactored Perl subroutine uploadFile that uses SigV4 without relying on OpenSSL or any non‑core CPAN modules—just **Digest::SHA**, **MIME::Base64**, and **POSIX**.

🧩 Required Perl Modules

Add these at the top of your script:

🛠 Updated Signature Code (V4)

📡 Updated curl Command

*Using UNSIGNED-PAYLOAD skips hashing large files and is valid over HTTPS. If your bucket enforces payload signing, replace that value with the SHA‑256 of the file.*


🚀 Result

* No more **OpenSSL** errors.
* No more SigV2 deprecation warnings.
* Fully secure, modern, Perl‑only SigV4 uploads to Amazon S3 via curl.


🧠 Key Takeaways

Aspect Legacy (SigV2) Modern (SigV4)
Crypto HMAC‑SHA1 via openssl HMAC‑SHA256 via Digest::SHA
Timestamp header Date x-amz-date
Auth header AWS : AWS4-HMAC-SHA256 … Signature=…
Perl dependencies External openssl, base64 Core modules only
Security / compliance Deprecated AWS‑recommended standard

How To Use HAProxy with a Tungsten Connector Farm

Author: , Posted on Thursday, June 5th, 2025 at 1:32:51pm

Using the Tungsten Connector with HAProxy

Tungsten Connector can be combined with an HAProxy installation to provide a high-availability entry point, which in turn routes intelligently to the underlying datasources inside the cluster.

There are three ways to monitor MySQL health in HAProxy—two are recommended and one is not (mysql-check, which floods Connector logs with failures):

  • check (native TCP check)
    ✅ RECOMMENDED
    Add check to every server line so HAProxy opens a TCP handshake on a schedule. Success marks the node “up”; failure marks it “down”. Without it, HAProxy assumes the node is always reachable.
  • External check script (via xinetd)
    ✅ RECOMMENDED
    Runs custom SQL for deep health and consistency checks.
  • mysql-check (native MySQL handshake)
    ❌ NOT RECOMMENDED
    Sends a handshake and optional auth packet but cannot verify schema consistency and spams the logs.

See the example HAProxy configuration file below for a full haproxy.cfg file.

Additional detail is in the official HAProxy docs.

The two recommended methods are illustrated below:

Configuring HAProxy Using the Basic Native Check

✅ RECOMMENDED  — no MySQL user required.

Configuring HAProxy Using an External Check Script

✅ RECOMMENDED

Install the script on every Connector host; HAProxy polls each one on port 9200.

Step 1 — Create the MySQL health-check user

Step 2 — Add credentials to /opt/continuent/tungsten/tungsten-connector/conf/user.map

Step 3 — Deploy /opt/continuent/share/connectorchk.sh

Step 4 — Install xinetd

Step 5 — Register the service

Step 6 — Create /etc/xinetd.d/connectorchk as the root user

Step 7 — Restart and verify

Example haproxy.cfg

Monitoring HAProxy Status

Ensure stats socket is enabled in haproxy.cfg:

(Restart HAProxy after editing haproxy.cfg.)

Check runtime stats with nc:

You need nc installed, and the command must run with root privileges to access
the UNIX socket.

Effortless Exports: A New Perl Script for Tidy Apple Reminders on macOS Sonoma +

Author: , Posted on Thursday, May 29th, 2025 at 4:42:20pm

If you live inside Apple Reminders but wish you could archive or share your lists in a clean, readable format, this short Perl utility – saverem — is for you. It grabs every list in your Reminders app, arranges the items hierarchically (with notes intact), and writes the result to a timestamped log in ~/backups. Add the optional –show flag and it echoes the same well-formatted text to the terminal while it logs.

Why Yet Another Reminders Tool?

  • Zero friction: No AppleScript, no UI automation—just the lightweight reminders-cli binary Keith Thibodeaux maintains on GitHub/brew.
  • Readable logs: Headings (>>> Heading) become top-level sections; children are indented and notes nest neatly beneath each task.
  • Versioned snapshots: Every run writes reminders-YYYYMMDDHHMMSS.txt, so you always know when a list changed.
  • Optional live view: Add -s or –show to mirror the log to STDOUT—perfect for piping into other tools.

Quick Start

  1. Add “>>> ” in front of all Parent Items in the Apple Reminders app
  2. Install reminders-cli (if you haven’t already):
  3. Save the script
    Put it anywhere in ~/bin, mark it executable, and give it a short name such as saverem:
  4. Run it
  5. Automate
    Add a simple cron entry to run it daily:

    Note: You must code-sign the script to prevent permission popups when it runs ;-}

What the Output Looks Like

Readable, greppable, and copy-pastable—exactly what you need for project notes or audits.

Customizing and Extending

  • Change the backup directory – Edit $dir near the top if you’d rather store logs in iCloud, Dropbox, or an external
  • Filter lists – Swap out the @lists = \reminders show-lists line for a hard-coded array if you want only certain lists
  • JSON or Markdown output – Because the structure is already captured in a tied hash (Tie::IxHash), emitting JSON/YAML/Markdown is just a few print statements away.

Full Script

Below is the complete code, ready to paste into ~/bin/saverem:

Feel free to adapt and share—just keep the attribution header intact so others can track down the original project. Happy exporting!

Dear Apple: Stop the Enshittification of macOS

Author: , Posted on Tuesday, May 6th, 2025 at 11:52:15am


For decades, Apple earned the loyalty of professional users by building systems that were fast, stable, and empowering. macOS once represented the ideal blend of power and polish—a UNIX foundation dressed in a minimalist, intuitive interface. Systems like Snow Leopard were lauded not for how much they did, but for how well they did it.

That Apple is gone.

Today, macOS has become a tangled mix of locked-down behaviors, inconsistent UI metaphors, broken legacy support, and background services no one asked for. What used to be a sleek, responsive operating system is now bloated with half-baked features and hidden restrictions. And the worst part? Apple pretends this is progress.

Here’s what’s been quietly sacrificed in the name of “security” and “ecosystem synergy”:

  • Stability and Trustworthiness
    With each major release, users have come to expect new bugs, broken workflows, and discontinued features. Disk Utility was gutted. Mail rules silently fail. Mission Control has been mangled. Stability—the one thing professionals need—has been pushed aside for cosmetic changes.
  • User Control
    Remember when you could simply turn off system features? Now you fight SIP, TCC, notarization, and sealed system volumes just to maintain basic control. Gatekeeper treats its users like idiots. Settings are scattered, buried, or removed altogether.
  • Coherent, Consistent UI
    System Settings is a joke. It looks like it was ported from an iPad in a weekend and never tested. Its layout is illogical, search barely works, and it breaks decades of user muscle memory. This isn’t design. It’s neglect.
  • Professional Respect
    Apple used to build tools for professionals. Now it builds products for passive consumption. Ports? Gone. Terminal users? Ignored. Developers? Annoyed. Creatives? Herded into cloud subscriptions. It’s clear that Apple now optimizes for services revenue, not empowering creators.

And yet, the bones of something great still remain. Beneath the clutter, macOS is still UNIX. Still scriptable. Still automatable. But the trend is undeniable: Apple is slowly turning the Mac into a sealed appliance. A beautiful box that tells you what you can do, not asks you what you want to do.

We’re not asking for a return to 2009. We’re asking for a return to values that made Apple great:

  • Performance and reliability over feature churn
  • Clarity and control over needless abstraction
  • Respect for power users, not infantilization
  • Design that works, not design that sells

If Apple continues down this road, it will lose the very people who made the Mac worth buying. And when the power users leave, the rest will follow—because an ecosystem without its builders, troubleshooters, and evangelists eventually collapses under its own weight.

So here’s the feedback Apple doesn’t want to hear but needs to:

Stop the enshittification. Bring back the discipline, the coherence, and the user-first mindset that defined your golden era. Because right now, the most “pro” thing about a Mac is the marketing budget.

We’re still here. Still waiting. Still willing to believe.

Just give us a reason.

Reimagining Global Security: Redirecting $2.7 Trillion in Military Spending to Humanitarian Progress

Author: , Posted on Sunday, May 4th, 2025 at 5:28:46am

Author: Eric M. Stone
Date: April 28, 2025

Abstract

This paper explores the theoretical redirection of $2.7 trillion in global military spending to humanitarian causes beginning in 2026. We model the year‑over‑year impact on global poverty, health, education, climate‑change mitigation, and infrastructure over a 20‑year period. We further analyze the political, social, and psychological obstacles to such a reallocation and propose actionable strategies to overcome resistance and foster global goodwill. Our findings suggest that with proper governance, oversight, and cultural transformation, humanity could achieve a historically unprecedented renaissance.

Keywords

humanitarian aid, global spending, military budget, poverty eradication, climate change, psychological resistance, political transition

Table of Contents

  1. Introduction
  2. Methodology
  3. Year‑over‑Year Impact Modeling (2026–2046)
  4. Analysis of Human Resistance and Obstacles
  5. Strategies to Overcome Resistance
  6. Discussion: Feasibility and Risks
  7. Conclusion
  8. References

1. Introduction

1.1 Context and Motivation

Global military expenditure surpassed $2.7 trillion in 2024, according to the Stockholm International Peace Research Institute (SIPRI). This staggering investment in arms, personnel, and warfare‑related infrastructure persists despite numerous advances in diplomacy, global governance, and interdependence among nations. While countries justify such expenditures in the name of national defense and security, the opportunity cost to humanity is immense.

At the same time, almost 700 million (≈ 692 million in 2024) live in extreme poverty. Over 2 billion lack access to clean water, over 700 million go to bed hungry each night, and 244 million children and youth remain out of school. Climate change threatens every continent with rising sea levels, food instability, displacement, and disaster. The paradox is clear: while humanity possesses the resources and knowledge to solve its greatest challenges, it continues to allocate its wealth toward destructive rather than constructive ends.

This paper proposes a bold hypothesis:

What if humanity redirected this military expenditure to humanitarian development instead? What could be achieved within a generation if the same political will, economic resources, and cultural commitment currently devoted to defense were instead invested in education, healthcare, environmental sustainability, and infrastructure for peace?

1.2 Hypothesis

We hypothesize that redirecting global military expenditure to humanitarian sectors would:

  1. Eradicate extreme poverty globally within 5 years
  2. Ensure universal healthcare and education within 10 years
  3. Substantially mitigate climate change and restore degraded ecosystems
  4. Initiate a global economic boom based on sustainability, cooperation, and inclusion
  5. Reduce the root causes of armed conflict, including scarcity, exclusion, and inequality

Achieving such outcomes would represent a civilizational renaissance, but would require overcoming entrenched systems, psychological inertia, political resistance, and cultural narratives rooted in fear and nationalism.

The remainder of this paper is dedicated to modeling what this transformation would look like, identifying the barriers to its realization, and offering actionable strategies to navigate the transition from a militarized global economy to a humanitarian‑centered one.

2. Methodology

2.1 Modeling Approach

This study relies on a structured modeling framework grounded in current global humanitarian data and economic assumptions. The following key sources informed the baseline data and parameter estimates:

  • United Nations Development Programme (UNDP) for poverty, development, and economic impact metrics
  • World Health Organization (WHO) for healthcare access, disease burden, and life‑expectancy data
  • UNESCO for education access, literacy rates, and school‑infrastructure benchmarks
  • Intergovernmental Panel on Climate Change (IPCC) for climate‑related projections and mitigation needs
  • Stockholm International Peace Research Institute (SIPRI) for verified global military‑expenditure data

Assumptions

  • An annual redirection of $2.7 trillion USD begins in 2026, sustained through 2046
  • 3% annual growth in impact efficiency is assumed due to scaling, infrastructure maturity, and innovation feedback loops
  • All reallocated funds are assumed to be non‑corrupt, transparently deployed, and publicly auditable

Target Domains Modeled

  • Poverty Eradication — direct cash transfers, housing, job programs
  • Healthcare — universal access to essential services, maternal care, vaccination, and mental‑health support
  • Education — school construction, teacher training, curricula deployment, scholarships
  • Water & Sanitation — clean water access, latrine building, hygiene campaigns
  • Climate Change Mitigation — renewable energy, reforestation, resilience infrastructure
  • Infrastructure Resilience — disaster‑proof housing, transportation networks, communications systems

A 20‑year, year‑by‑year milestone matrix was developed to track measurable outputs and expected societal benefits in each domain. The projections incorporate compound progress effects, where improvements in one sector (e.g., education) accelerate progress in others (e.g., health, income).

2.2 Analysis of Human Resistance

To better understand the friction such a reallocation might face, this study integrates findings from:

  • Political science: patterns of defense lobbying, sovereign security doctrines, and military diplomacy
  • Behavioral economics: loss aversion, status‑quo bias, tribalism, and fear‑based decision‑making
  • Social psychology: group identity, fear conditioning, and authoritarian dynamics

The model includes predictive friction coefficients for different regions and political contexts, assuming varying levels of resistance to rapid disarmament and humanitarian reinvestment.

2.3 Strategy Proposal

Drawing from historical global transitions (e.g., post‑WWII reconstruction, Cold War disarmament treaties, COVID‑19 vaccine rollouts), the methodology incorporates tested approaches to:

  • Economic transition planning for defense‑heavy regions
  • Public‑persuasion campaigns using storytelling, framing, and appeals to security reframing
  • International cooperation frameworks, including treaties, incentives, and watchdog mechanisms
  • Localized empowerment models, ensuring communities maintain agency in deploying funds

The goal is not only to model what could be achieved, but how it might realistically be implemented.

3. Year‑over‑Year Impact Modeling (2026–2046)

This section models the cumulative effects of redirecting $2.7 trillion annually from global military expenditures into coordinated humanitarian efforts. The model assumes a 3% annual increase in deployment efficiency due to scaling, institutional learning, and improved global cooperation.

The following highlights projected milestones across five core domains: poverty, healthcare, education, climate resilience, and infrastructure.

2026

  • $540 B allocated to extreme‑poverty‑alleviation programs (direct cash transfers, rural employment, shelter)
  • Launch of Global Basic Healthcare Initiative covering 20+ least‑developed countries
  • Construction of 50,000 schools and training centers worldwide
  • Reforestation projects initiated in Amazon and Congo Basins
  • Emergency water and sanitation rollout in Sub‑Saharan Africa and South Asia

2027

  • Global extreme‑poverty rates fall by 30%
  • Malaria deaths halved through universal net coverage, medicine access, and clean water
  • Solar and wind infrastructure initiated in 25 low‑energy countries
  • Full sanitation coverage delivered to 500 million people

2028

  • Universal access to primary healthcare achieved across 60 low‑income countries
  • Global literacy rates rise by 15% with 50,000+ new schools operational
  • Major drought‑resilience programs completed on three continents
  • Launch of clean‑cooking initiatives to eliminate biomass dependency

2029

  • Hunger reduced by 50% through targeted food distribution and sustainable agriculture
  • Universal primary school enrollment achieved globally
  • Emergency disaster‑response time reduced by 70% worldwide
  • Global polio eradication complete; major progress on neglected tropical diseases

2030

  • Extreme poverty eradicated globally
  • Secondary‑school access reaches 85% of children worldwide
  • Renewable energy exceeds 40% of global electricity supply
  • Construction begins on global climate‑resilient housing initiatives

2031–2035: Expansion Years

2031

  • Maternal mortality reduced by 60%—skilled birth attendance near universal
  • Global access to safe drinking water reaches 98%

2032

  • Mental‑health services integrated in 70% of public‑health systems
  • Global scholarship programs provide universal access to secondary education
  • Millions transition to climate‑resilient jobs

2033

  • Child mortality reduced by 70%
  • Average life expectancy increases by 5 years globally

2034

  • 90% of global electricity from renewables
  • 2 billion trees planted across reforestation zones

2035

  • Universal secondary education achieved
  • Refugee housing and relocation systems scaled globally
  • Over 1 billion people transitioned from informal to formal economic systems

2036–2046: The Global Renaissance

2036

  • Preventive medicine becomes the global healthcare norm
  • Universal university‑level access via public funding and digital education

2037

  • Global hunger eradicated
  • Transcontinental clean‑energy grid goes online

2038

  • Advanced healthcare systems standard in 90% of nations
  • Major biodiversity‑restoration projects take root

2039

  • Ocean microplastic extraction successes replicated globally
  • Global slum population reduced by 75%

2040

  • 80% of global energy generation is renewable
  • All major infectious diseases brought under control

2041

  • Universal internet access achieved
  • Urban infrastructure retrofitted for extreme climate resilience

2042

  • Global average life expectancy surpasses 85 years

2043

  • Human Development Index exceeds 0.9 in 75% of countries

2044

  • Over 50% of global agriculture becomes regenerative and carbon‑sequestering

2045

  • Global GDP per capita doubles from 2025 levels

2046 – Global Renaissance Achieved!

  • Armed conflict reduced by 80%
  • Extreme poverty, hunger, and energy scarcity eradicated
  • Climate warming stabilized below 1.5 °C
  • Universal access to healthcare, education, and safe housing secured

This model illustrates that with disciplined investment, transparent governance, and sustained global cooperation, the redirection of military budgets could transform the human condition on a planetary scale.

4. Analysis of Human Resistance and Obstacles

While the economic, environmental, and humanitarian case for redirecting military expenditure is compelling, history shows that logical arguments alone rarely drive systemic change. To realistically envision a peaceful reallocation of $2.7 trillion annually, we must understand the roots of resistance embedded in human behavior, political structures, and cultural narratives.

4.1 Psychological Barriers

  • Loss Aversion: People instinctively resist giving up perceived sources of protection. The idea of reducing military spending may trigger fear—even if the new direction promises greater security.
  • Status‑Quo Bias: Humans tend to overvalue the current system simply because it exists, equating military strength with safety.
  • Tribalism and In‑Group Loyalty: Cooperation across national, ethnic, or religious lines is often met with suspicion, undermining collective action.

4.2 Political and Institutional Resistance

  • The Military‑Industrial Complex: Defense sectors are deeply integrated with political institutions, employing millions and wielding media influence.
  • Asymmetric Threat Narratives: Governments justify defense spending using exaggerated external threats, sustaining high budgets.
  • Sovereignty and Strategic Autonomy Concerns: Nations fear losing leverage, perceiving unilateral disarmament as dangerous.

4.3 Cultural and Societal Resistance

  • Glorification of Militarism: Media and national symbols elevate military achievements, making humanitarian values appear “soft”.
  • Fear‑Based Media Ecosystems: Headlines emphasize conflict, reinforcing the need for defense spending; humanitarian progress is underreported.
  • Institutional Distrust: Public skepticism toward governments and NGOs can hamper large‑scale reallocations.

4.4 Summary

Resistance to redirecting military expenditure is not merely economic or strategic—it is deeply psychological and sociocultural. Understanding this resistance is a prerequisite to overcoming it. The next section proposes specific strategies to address these obstacles.

5. Strategies to Overcome Resistance

Humanity must shift minds, realign incentives, and cultivate a new global story of security and progress to redirect $2.7 trillion annually from military budgets to humanitarian goals.

5.1 Psychological Reframing

  • Redefine Security: Frame safety as human wellbeing—access to food, water, healthcare, and education—not weapons.
  • Appeal to Shared Human Identity: Emphasize vulnerabilities that transcend borders, such as climate risk and pandemics.
  • Use Empathy‑Based Communication: Share compelling stories of transformation from war zones and refugee camps.

5.2 Economic Transition Planning

  • Defense‑to‑Humanitarian Conversion Programs: Provide pathways for defense manufacturers and workers to pivot to renewable‑energy and medical‑technology sectors.
  • Incentives for Peace Dividends: Offer visible funds for health, education, or infrastructure tied to defense‑budget reductions.
  • Global Green‑Blue Job‑Creation Pacts: Retrain defense‑industry workers for green‑energy, conservation, and development roles.

5.3 Political and Legal Frameworks

  • Multilateral Demilitarization Treaties: Phased reductions in military budgets synchronized with humanitarian investments.
  • Transparency and Accountability Systems: Real‑time public dashboards, citizen engagement, and rigorous auditing.
  • Decentralized Governance of Aid: Community‑managed participatory budgeting to increase ownership and reduce suspicion.

5.4 Cultural and Narrative Interventions

  • Redefine Heroism and Sacrifice: Celebrate teachers, nurses, environmental stewards, and social workers.
  • Global Media Campaigns for Peace: Portray peacebuilding and humanitarianism as courageous and effective.
  • Educational Reform: Integrate conflict resolution and systems thinking into school curricula.

5.5 Coalition Building

  • Cross‑Sector Alliances: Unite faith groups, labor unions, universities, medical associations, environmentalists, and youth movements.
  • Youth‑Led Movements: Empower Gen Z and Gen Alpha to drive demand for redirection.

5.6 Summary

A combination of emotional resonance, economic practicality, and cultural storytelling can normalize a new vision of peace as progress.

6. Discussion: Feasibility and Risks

The potential outcomes modeled in this paper are extraordinary. However, realizing this vision involves navigating formidable risks and practical constraints. This section explores implementation feasibility and identifies key risk domains.

6.1 Historical Feasibility

  • Post‑World War II Reconstruction (Marshall Plan)
  • Global Eradication of Smallpox
  • Millennium & Sustainable Development Goals
  • COVID‑19 Vaccine Development & Distribution

These examples demonstrate that massive, multinational coordination and resource reallocation are feasible with leadership, accountability, and urgency.

6.2 Risk Factors

  1. Political Fragmentation: uneven adoption could create power vacuums
  2. Corruption and Misuse of Funds: governance structures may be overwhelmed
  3. Institutional Inertia: entrenched stakeholders may sabotage implementation
  4. Cultural Resistance and Backlash: populations may reject perceived “globalist” efforts
  5. Emerging Conflicts or Rogue Actors: isolated conflicts may threaten momentum

Mitigations include phased treaties, transparent auditing, transition programs, adaptive messaging, and rapid diplomacy.

6.3 Technical and Operational Hurdles

  • Scaling infrastructure and workforce without causing inflation or shortages
  • Deploying digital logistics and tracking platforms for real‑time management

6.4 Summary

This transition is an engineering, economic, and cultural challenge of historic proportion—but history shows that extraordinary change is possible when humanity aligns purpose with resources.

7. Conclusion

The redirection of global military expenditure represents one of the most profound decisions humanity could make in the 21st century. Reallocating these resources could eradicate poverty, achieve universal healthcare and education, transition to renewable energy, reduce conflict, and catalyze a global economic renaissance.

Technical capacity, funding, and institutional frameworks already exist or can be rapidly developed. The greatest barriers are psychological, political, and cultural. Targeted strategies—new narratives of security, cooperative governance, transparent execution, and sustained public engagement—are essential.

The choice is immediate, practical, and moral. The time to act is now.

8. References

  • Kahneman, Daniel. Thinking, Fast and Slow. New York: Farrar, Straus and Giroux, 2011.
  • Harari, Yuval Noah. Sapiens: A Brief History of Humankind. New York: Harper, 2014.
  • Piketty, Thomas. Capital and Ideology. Cambridge, MA: Harvard University Press, 2020.
  • SIPRI Yearbook 2024: Armaments, Disarmament and International Security. Stockholm International Peace Research Institute, 2024.
  • United Nations Development Programme. Human Development Report 2023-24: Breaking the Gridlock - Re‑imagining Co‑operation in a Polarized World. New York: UNDP, 2023.
  • UNESCO. Global Education Monitoring Report 2023: Technology in Education. Paris: UNESCO Publishing, 2023.
  • World Health Organization. Global Health Estimates 2024: Life Expectancy and Leading Causes of Death and Disability. Geneva: WHO, 2024.
  • Intergovernmental Panel on Climate Change. Sixth Assessment Report. Geneva: IPCC, 2023.

Note: This paper was produced with the help of ChatGPT.

How To Install mod_evasive on Apache 2.4 in Rocky Linux 9

Author: , Posted on Tuesday, April 15th, 2025 at 9:05:38am

If you’re running Apache 2.4 on Rocky Linux 9 and want to protect your web server against basic DoS, DDoS, or brute-force attacks, installing mod_evasive is a solid option. Unfortunately, the module isn’t included by default, and some manual work is required to get it running. Here’s a quick guide to getting it installed and patched for Apache 2.4.

Step-by-Step Installation

Note: All commands are run as the root user. You may also use sudo in front of each command.

Configure mod_evasive to your needs. You’ll typically add a configuration block like this to your Apache config:

Create the log directory and ensure Apache has permission to write to it:

Download and unpack the source:

For Apache 2.4, the source code needs a small patch to compile cleanly. Let’s handle that next:

Once patched, you can build and install the module using apxs:

This compiles the module, installs it into Apache’s modules directory, and updates your configuration to load it automatically.

Restart the Apache web server:

Reference

More information, including source updates and configuration details, is available on the official GitHub repository: https://github.com/jzdziarski/mod_evasive