A step-by-step SSH hardening guide for a first VPS on the RHEL 10 family (AlmaLinux, Rocky, CentOS Stream). Key-only authentication, no root login, brute-force limits, a safe port move, and SELinux left enforcing, with every command shown and the lockout traps called out.
A checkout flow that reserves inventory, charges a card, and creates a shipment touches three services, each with its own database. If the charge succeeds but the shipment service is down, the order is now paid with no shipment record, and nothing rolled back the inventory reservation either. That’s not an edge case. Any transaction that crosses a service boundary has this failure mode, because there’s no single database transaction wrapping all three writes. ...
Somewhere in your stack there’s a payment flow that died between “card charged” and “order marked paid,” and nothing remembers the gap. Or a “remind the customer in 48 hours” job that lived in a scheduler’s memory until the scheduler restarted. Or an onboarding that spans five services and three days, and the only way to answer “where is it now?” is grepping logs across all five and reconstructing the timeline by hand. None of these are exotic failures. They’re the standard cost of building long-running business processes out of queues, cron jobs, and status tables, and every team that does it long enough hits all three. ...
I used to build VMs by hand. Click through the wizard, guess an IP, forget which VLAN it went on, and a month later nobody remembers why vm-1042 exists. This post is the replacement: OpenTofu + Terragrunt cloning from a golden template on vSphere, driven by a least-privilege SSO user. Everything here survived a real production estate, including the parts that cost me actual debugging time: the permission model in vCenter is full of silent traps, and I’ll point at every one of them. ...
This is Part 2 of the Solana Authorities series. In Part 1 we covered the authority pattern itself: what authorities are, how they differ from ownership, and what None means. Now we go deep on the two authorities every SPL token has. Disabling the mint authority does not disable the freeze authority. A token with a “renounced” mint can still have every holder locked out of their tokens. These are two independent fields in a single 82-byte account, and checking only one of them is not enough. ...
This is Part 1 of the Solana Authorities series. If you work with tokens, NFTs, staking, or governance on Solana, this series maps every authority field you will encounter, what each one controls, and what happens when you hand it off or burn it. The problem Every Solana intro tutorial mentions “the mint authority” once, in passing, when teaching spl-token create-token. Almost no tutorial explains: That the mint has a separate freeze authority that can disable transfers for any holder. That Token-2022 added roughly a dozen additional authority slots through extensions, several of which can move user funds without consent. That stake accounts have two authorities (stake and withdraw), and losing the withdraw authority is permanent loss of principal, not just rewards. That Metaplex metadata has its own update authority that controls how wallets and marketplaces render an NFT, independent of who holds it. That governance programs (SPL Governance, Squads, Realms) are themselves just programs that hold authorities on behalf of a DAO, and the security model collapses to whatever those programs enforce. Most rugs, freezes, and operational mistakes on Solana trace back to one of these fields being misunderstood. ...
This is Part 6 of the Solana Program Lifecycle series. In Part 5 we covered the upgrade authority lifecycle, from a single keypair through Squads multisig and SPL Governance to the irreversible --final flag. Now we step back and look at the whole pipeline: how a program moves from a file on your laptop to live bytecode on mainnet. The short answer: it is more than solana program deploy. The deploy command is the last step, not the whole thing. Developers who skip straight to mainnet tend to discover this when a partial buffer upload stalls at 3 AM, or when a CPI that worked perfectly in local testing silently fails because the account it needed never existed outside mainnet. ...
This is Part 5 of the Solana Program Lifecycle series. In Part 4 we walked through the deploy and upgrade flows: the Buffer account, the chunked writes, and the activation step that copies bytecode into the ProgramData account. Every upgrade instruction checks one thing before it proceeds: who is allowed to do this. That one thing is the upgrade_authority_address field: 33 bytes in the ProgramData account that control who can replace the program’s bytecode. This post traces the full lifecycle of that field, from the keypair that deployed the program to the irreversible --final flag that writes None and freezes the program forever. ...
This is Part 4 of the Solana Program Lifecycle series. In Part 3 we saw that a program is two accounts: a 36-byte Program Account that points to a ProgramData Account holding the actual bytecode. Now we look at how those two accounts get created and replaced. The short version: there is a third account involved. A temporary one. It exists only during the deploy or upgrade, and if anything goes wrong, it can sit on chain holding your SOL until you reclaim it. ...
This is Part 3 of the Solana Program Lifecycle series. In Part 1 we covered the account model. In Part 2 we covered compute units. Now let’s look at something most developers never think about until something breaks: how programs actually live onchain. Because here’s the thing: a Solana program isn’t one account. It’s two. And the relationship between them is what makes upgrades possible without breaking everything that depends on the program. ...