Today
Front-end, in one read.
The latest from the sources worth following, newest first.
DEV CommunityThe Giantsread at source
Aimeos 2026.10: MCP tools for Laravel e-commerce
Aimeos is an open-source e-commerce framework for Laravel applications. Version 2026.10 adds MCP tools that let AI agents search products, update orders and manage customers in your shop. An agent could retrieve selected products, draft improved descriptions and save the changes after your approval. Aimeos provides the tools for reading and updating shop data; your integration handles the agent workflow and approval step. What's new MCP tools for AI agents Model Context Protocol (MCP) gives AI applications a standard way to discover and call tools. The new ai-admin-mcp extension provides tools for more than 20 shop domains, including products, categories, orders, customers and stock. Depending on the domain, agents can search and aggregate records, save and delete items, and change category trees. composer require aimeos/ai-admin-mcp Each tool validates its arguments and checks permissions using the Aimeos context supplied by your integration. In admin/mcp/resource you configure which user groups may call which tool. The package doesn't include an MCP transport or SDK. Each tool exposes an input schema and returns its results as PHP arrays. Your integration registers the tool definitions with an MCP server and routes calls to their execution methods. Expose only the tools you need. The MCP package README shows how to retrieve the tool catalog, inspect definitions and execute calls. WebMCP in the storefront WebMCP is a proposed browser standard that lets websites describe actions for AI agents. The Aimeos storefront now uses it on the forms for addresses, saved baskets, coupons and product watch lists. Browser agents that support WebMCP can fill these forms for the customer. Few browsers support it yet, and for regular visitors the forms work as before. Choose an AI provider for each task In the admin backend, you can write and translate texts, generate images and remove image backgrounds with AI. In 2026.10, these features use Prisma ( aimeos/prisma ) , our PHP library for AI providers. You can configure a different provider and model for each task. Switching providers later is a configuration change. Imports and exports Customer, product, category and supplier imports can combine file data with configured values. For example, set a fixed product.status in the import mapping and omit the repetitive status column from your CSV. Order, product and subscription exports can be extended with project-specific data before the files are written, for example fields your ERP or CRM system expects. Framework support Laravel 10 to 13 remain supported, Symfony 8 and TYPO3 14 are now supported too. Security hardening Customer password hashes are excluded from loaded customer items and API responses. Admin APIs apply tighter checks to shared items and customer group assignments. HTML sanitization and output encoding strengthen XSS protection. Remote image and CMS media fetching blocks internal addresses to protect against SSRF. Checkout steps require POST requests. Guest orders can't be linked to existing accounts by e-mail, and site settings can't overwrite internal configuration keys. For published vulnerabilities and affected versions, see the core security advisories . How Aimeos fits into your application You can install Aimeos (LGPLv3) into an existing Laravel application as a Composer package. It uses your routes, middleware, authentication, queues and Blade views. Use the JSON:API for a custom frontend, or start with the server-rendered HTML components included with Aimeos. GraphQL and now MCP cover administration. Aimeos is multi-vendor, multi-language, and multi-currency capable so you can run several shops with their own catalogs, prices, languages and currencies. Aimeos is self-hosted, so you control your shop database and hosting, with no Aimeos fees per transaction. Data sent to external AI services depends on the provider and features you configure. Get started You can install different packages, depending on your needs: # Full shop system composer create-project aimeos/aimeos # Headless API composer create-project aimeos/aimeos-headless # Laravel package only composer require aimeos/aimeos-laravel New to Aimeos? Follow the Laravel setup guide or explore the demo shop . Upgrading an existing shop? Read the upgrade guidance before updating your dependencies. Building an agent integration? Install aimeos/ai-admin-mcp and use the tool catalog example to connect the tools to your MCP server. You can find the application source on GitHub . If you like Aimeos, give it a star! :-)
DEV CommunityThe Giantsread at source
AWS Landing Zone Explained: Why Every Enterprise Cloud Needs a City Plan Before It Scales
Picture a city full of energy, where new buildings rise almost overnight and appear wherever there is space. Roads were added only when traffic became unbearable. Nobody issued ID cards, there were no building codes, and the only record of who lived where existed in a few people's heads. For a while, the city worked. Then it got big. Many AWS environments grow in the same way. A team opens one account to launch a product quickly. A second team joins, then a third. Developers experiment next to production databases, admin access gets shared to save time, and nobody is quite sure who created that expensive cluster last quarter. The early speed is real. So is the hidden debt building up underneath it. This is the problem an AWS landing zone solves. Think of it as the master plan for your cloud: the districts, laws, ID cards, roads, and records office that a city needs before thousands of people move in. This article walks through that plan in plain language, maps each part to the AWS service behind it, and explains why it matters to the business, not only to the engineering team. What is an AWS landing zone? An AWS landing zone is a secure, well-architected multi-account AWS environment, set up with identity, security, networking, and logging foundations before applications move in. Most organizations build and govern it with AWS Control Tower, which creates accounts from approved templates and applies guardrails to every account from day one. 1. When the Cloud Grows Faster Than the Plan An unplanned cloud rarely fails on day one. It fails gradually, and the symptoms usually appear in four places: • Security risk spreads easily. When everything lives in one account, one wrong permission or one compromised credential can reach production, testing, and experiments at the same time. • Access gets out of hand. Users and access keys pile up over time, and removing access when someone leaves becomes a manual hunt. • New projects wait. Every new team needs a safe environment. Without a standard way to create one, each request turns into a small custom project. • Audits become painful. When an auditor asks who changed a setting, the answer depends on whether logging was switched on, and on whether anyone could have deleted the logs. As we explored in Prove It or Pay for It , evidence that has to be reconstructed by hand is expensive evidence. None of this happens because teams are careless. Each shortcut made sense on the day it was taken: one shared account was faster to set up, one admin role was easier to manage, and logging could always be switched on later. The problem is that shortcuts compound. By the time the environment is large enough to hurt, untangling it is a project of its own. 2. Why an AWS Landing Zone Matters for Compliance in the UAE and Saudi Arabia Cloud adoption across the GCC is accelerating, driven by national programs such as Saudi Vision 2030 and the UAE's digital government agenda. The same governments are also building some of the most detailed cloud and cybersecurity rulebooks anywhere. For government entities, banks and financial institutions , and critical infrastructure operators, governance is no longer something to add later. It is part of the price of entry. Saudi Arabia The National Cybersecurity Authority (NCA) sets the national baseline through its Essential Cybersecurity Controls (ECC). Its Cloud Cybersecurity Controls (CCC) extend the ECC specifically for cloud, with requirements both for cloud service providers and for the organizations that use them, which the NCA calls cloud service tenants. The CCC applies to government organizations and to private sector organizations that own, operate, or host critical national infrastructure. Banks and other financial institutions also answer to the Saudi Central Bank (SAMA) and its cybersecurity framework, which we cover on our SAMA compliance page. United Arab Emirates In the UAE, requirements come from both federal and emirate-level authorities: • UAE Cyber Security Council. Its National Cloud Security Policy, first released in 2023 and since updated, sets requirements for both cloud consumers and cloud service providers. It applies to federal ministries and authorities and to non-government critical information infrastructure entities. Where an emirate runs its own critical infrastructure protection program, that emirate's lead authority handles applicability and enforcement. • Telecommunications and Digital Government Regulatory Authority (TDRA). The UAE Information Assurance Regulation sets management and technical security controls for information and the systems that handle it, including information stored or processed through cloud services. • Dubai Electronic Security Center (DESC). Its Information Security Regulation (ISR) defines security practices for Dubai Government entities. Its Cloud Service Provider (CSP) Security Standard is the certification that Dubai government and semi-government organizations must ensure their cloud provider meets. AWS holds this certification for its Middle East (UAE) Region. • Data protection and sector regulators. The federal Personal Data Protection Law (Federal Decree-Law №45 of 2021) and sector regulators, such as the Central Bank of the UAE and the financial free-zone regulators in DIFC and ADGM, add further obligations depending on industry and location. If data residency is shaping your provider decision, our guide on how to evaluate a cloud service provider in the UAE covers it in depth, and Cost-Efficient and Sovereign looks at how data rules interact with cloud spend across the GCC. What the regulators have in common The details differ by country, sector, and data classification, but these frameworks keep returning to the same expectations. This is where a landing zone earns its place: it turns those expectations into structure that exists by default, instead of evidence assembled by hand before an audit. An important distinction A landing zone supports compliance, but it does not deliver compliance on its own. A cloud provider's certifications cover the provider's side of the shared responsibility model. How you configure, operate, and evidence your own environment remains your responsibility, so always confirm which frameworks apply to you with your compliance team 3. What Is an AWS Landing Zone? An AWS landing zone is a well-architected, multi-account AWS environment, set up with security, identity, networking, and logging foundations before applications move in. In city terms, it is the master plan drawn up before construction begins. A landing zone is not a single product. It is a design built from several pieces working together. AWS Control Tower is the managed service most organizations use to build and govern it. For highly regulated environments, AWS also provides the open-source Landing Zone Accelerator on AWS, which is designed to work alongside Control Tower and adds deeper, configuration-driven control over networking and security. Choosing between the two and designing the structure itself is usually where cloud consulting support adds the most value. Already running applications on AWS? A landing zone is easiest to build before the first application goes live, but it is not too late afterwards. AWS Control Tower can register existing organizations and enroll existing accounts, so an unplanned city can be brought under a master plan step by step. AWS Control Tower, Landing Zone Accelerator or a custom build? There are three common ways to build an AWS landing zone. AWS recommends starting with AWS Control Tower and adding Landing Zone Accelerator on AWS when compliance requirements call for deeper control. Some older guides refer to the AWS Landing Zone solution. That was an earlier AWS offering, and AWS has since stopped active development on it and directs organizations to AWS Control Tower as its successor, so new designs start with Control Tower. 4. Key Components of an AWS Landing Zone Architecture Each part of a well-planned city has a direct equivalent in a landing zone. Here is how they fit together. The city council: AWS Organizations and the management account Every city needs a council that sets the rules, approves new districts, and pays the bills. In AWS, this role belongs to AWS Organizations and its management account. In a Control Tower landing zone, the management account handles consolidated billing, provisions new accounts, and manages organizational units and controls. One rule matters here: the council does not run shops. AWS does not recommend running production applications in the management account, partly because service control policies do not apply to users and roles in that account. Keep it small, quiet, and tightly protected, with very few people able to sign in. Districts and neighbourhoods: multi-account architecture A city separates residential areas from industrial zones for good reason, and AWS accounts work the same way. Each account is a natural isolation boundary, so a failure or a mistake in one account stays there instead of spreading across one large, shared environment. Service quotas are also tracked per account, so one busy team cannot exhaust limits for everyone else. Accounts are grouped into organizational units (OUs), which act like districts. A typical design includes a Security OU for logging and audit accounts, an Infrastructure OU for shared networking, a Workloads OU for production and development, and a Sandbox OU where teams can experiment safely. A useful rule of thumb: group accounts by the rules they need, not by the company org chart. City laws: guardrails and service control policies Laws only work when they apply to everyone, automatically. In a landing zone, these laws are called controls, often referred to as guardrails. AWS Control Tower classifies each control by when it acts: before a resource is built, at the moment of an action, or after a change has happened. In a real landing zone, the three types work together. A few examples: • Before deployment: a proactive control can reject an infrastructure template that would create a storage bucket without encryption configured, so the resource is never created. • At the moment of action: a preventive control can stop anyone from changing the audit logging configuration or the bucket policy protecting the log archive, including administrators inside member accounts. • After the fact: a detective control can flag an existing resource that has drifted out of policy, such as a storage volume that is not encrypted, so the team can fix it. A useful detail for technical readers: service control policies (SCPs) never grant permissions. They set the maximum permissions available in member accounts, which is why they make such effective guardrails. AWS Control Tower also offers optional preventive controls implemented with resource control policies (RCPs). Where SCPs limit what the identities in your accounts can do, RCPs limit what can be done to your resources, including requests that come from outside your organization. Used together, they help you build a strict data perimeter: for example, allowing only identities from your own organization to access resources such as Amazon S3 buckets, even if a bucket policy is accidentally made too permissive. Guardrails are one layer of a wider AWS security strategy , not a replacement for it. Resident ID cards: IAM Identity Center In a planned city, every resident carries one ID card that opens only the doors they are entitled to. AWS IAM Identity Center plays this role. It is AWS's recommended service for managing human access across multiple accounts, and it can connect to the identity provider your company already uses. Access is defined through permission sets, which describe what a role can do, and then assigned to groups for specific accounts. A developer might hold broad rights in a development account and read-only access in production. People sign in through a single portal and receive temporary credentials, which removes the need for long-lived access keys scattered across accounts. Roads and utilities: networking Roads connect districts, but you do not let every household build its own highway. Many landing zones place shared networking, such as a central connectivity hub built with AWS Transit Gateway, in a dedicated network account. Traffic between accounts and to on-premises systems then follows planned, inspectable routes, which is the foundation of strong infrastructure security . Network design deserves its own article, and we have written one: Beyond Security Groups: Building a Layered AWS Network Defense for Regulated Enterprises. CCTV and the records office: centralized logging A well-run city keeps records that cannot be quietly erased. In an AWS Control Tower landing zone, a dedicated Log Archive account stores a copy of the AWS CloudTrail and AWS Config log files from the other accounts in a central Amazon S3 bucket. A separate, restricted Audit account gives security and compliance teams programmatic access to review the other accounts. Because the logs live outside the accounts that generate them, a mistake or a compromised account in one district cannot wipe the city's records. Many landing zones also turn on Amazon GuardDuty for threat detection and AWS Security Hub to bring security findings from every account into one view. Collecting logs is only half the job, though. Someone has to watch them, which is where 24/7 monitoring through a NOC and SOC comes in. The planning office: AWS Control Tower and Account Factory Every city needs a planning office that approves new buildings from standard, pre-approved designs. AWS Control Tower brings the building blocks above together and automates much of the setup. Its Account Factory works like a vending machine for new accounts: teams request an account from a template with pre-approved settings, including network configuration and AWS Region selections, and receive it with the guardrails already applied. Teams that manage infrastructure as code can use Account Factory for Terraform, which fits naturally into existing DevOps workflows. SUDO Consultants is an AWS Premier Tier partner with more than 100 AWS certifications across our team and wide AWS service delivery expertise . For most organizations we work with in the UAE and Saudi Arabia, AWS Control Tower is the fastest route to a well-governed foundation. Note for practitioners AWS Control Tower landing zone version 4.0 introduced more flexibility. For example, a Security OU is no longer required, and mandatory controls are no longer applied by default. Check which landing zone version you are running before following older guides. The whole city at a glance Putting it all together: people enter through one identity service, guardrails apply from the top of the organization, applications live in their own districts, traffic travels through a shared network hub, and every account's records flow to one protected office. 5. Business Benefits of an AWS Landing Zone Once the master plan is in place, the benefits reach well beyond the engineering team: • Faster project setup. New teams receive a governed account from a standard template instead of waiting for a custom build. • Easier audits. Logs, access assignments, and control status already exist in one place, so evidence is collected rather than reconstructed. • Contained risk. An incident in a development account stays in its own district instead of reaching production, which also makes resilient infrastructure easier to design. • Clearer cost ownership. Every account has a purpose and an owner, so spend maps directly to teams and products, a strong starting point for an AWS cost optimization review. • Room to grow. Adding the fiftieth account follows the same process as adding the fifth. What an AWS landing zone costs and how long it takes AWS Control Tower has no separate charge. Organizations pay for the AWS services it enables, such as AWS CloudTrail, AWS Config and Amazon S3 storage for logs, so the monthly cost grows with the number of accounts, regions, and controls in use. Landing Zone Accelerator on AWS also carries no additional charge. AWS publishes a sample estimate of roughly USD 430 a month for its sample configuration with AWS Control Tower in a sandbox environment with no activity, in the US East (N. Virginia) Region. Actual costs vary by Region, design, and activity, so we recommend an estimate built on the planned account structure. On timing, a baseline AWS Control Tower setup can be ready within hours, while a regulated design with a full account structure, network hub, and tailored controls usually takes several weeks of planning, building, and testing. 6. A Practical Example Imagine a regional retail group with an online store, a loyalty app, and a data team, all sharing two AWS accounts. A developer testing a new feature accidentally changes a security group that production also depends on, and the checkout page goes down for an hour. Afterwards, the team struggles to explain to management who made the change and why it was even possible. With a landing zone, the same developer works in a development account inside the Workloads OU. Their access comes from IAM Identity Center and stops at that account's boundary. Guardrails block risky changes, the activity is recorded in the Log Archive account, and production never feels the mistake. The incident report becomes a short note instead of a crisis meeting. This scenario is illustrative and does not describe a specific customer. 7. How to Set Up an AWS Landing Zone: Five Practical Steps 1. Map what you have. List your AWS accounts, their owners, who holds admin access, what runs where, and which regulations apply to each application. An AWS Well-Architected Review is a structured way to find the biggest gaps. If you are still planning your move to AWS, a cloud migration readiness assessment is the right place to design the landing zone from day one. 2. Draw the district map. Design your OU and account structure around how policies differ between applications, for example, regulated versus non-regulated data, or production versus development. Keep it simple: a structure that is easy to explain is easier to govern. 3. Lay the foundation. Set up AWS Control Tower from a clean management account, and choose the home Region with care, because it is difficult to change later and shapes data residency from day one. For heavy compliance requirements, Landing Zone Accelerator on AWS adds deeper control alongside it. 4. Add laws gradually. Start with a small set of well-understood controls, test them in the Sandbox OU, then extend them to production and development accounts. Document every exception, because exceptions are exactly what auditors ask about. 5. Keep the plan alive. Cities change, and so will your landing zone. Review access, controls, and structure on a regular schedule and resolve drift as soon as it appears, or work with a managed cloud services partner to operate it day to day. 8. Common Mistakes to Avoid • Recreating shared admin access in the new structure. Moving to many accounts does not help if everyone still receives full administrator rights everywhere. Define permission sets per role and per environment. • Changing landing zone resources by hand. AWS warns that modifying or deleting Control Tower-managed resources outside supported methods can leave the landing zone in an unknown state. • Treating the landing zone as a one-time project. Without ongoing ownership, configurations drift, and the city slowly becomes unplanned again. • Copying someone else's map. Your OUs and controls should reflect your own business, risk, and regulatory needs, not another company's template. Conclusion: Plan the City Before the Crowd Arrives Nobody would build a city by pouring concrete first and drawing the map later, yet that is how many cloud environments are built. A landing zone reverses the order. It gives every team a safe place to build, gives leadership confidence that the rules apply automatically, and gives auditors and regulators clear answers instead of a scramble for evidence. Whether an organization is starting fresh on AWS or bringing order to an environment that grew too fast, a well-planned AWS landing zone is the place to begin. Frequently Asked Questions About AWS Landing Zones What is the difference between an AWS landing zone and AWS Control Tower? A landing zone is the design: the accounts, guardrails, identity, networking, and logging that form a governed AWS foundation. AWS Control Tower is the managed AWS service most organizations use to build and operate that design, so Control Tower is one way to create a landing zone rather than an alternative to it. How much does an AWS landing zone cost? AWS Control Tower and Landing Zone Accelerator on AWS carry no separate charge. The cost comes from the services they enable, such as logging, configuration recording, and security monitoring, and it depends on the number of accounts, regions, and controls in the design. How long does it take to set up an AWS landing zone? A baseline AWS Control Tower setup can be ready within hours. A design for a regulated organization, with a tailored account structure, network hub, and controls, usually takes several weeks, including planning and testing. Can existing AWS accounts be moved into a landing zone? Yes. AWS Control Tower can register existing organizational units and enroll existing accounts, so an environment that grew without a plan can be brought under governance step by step, starting with non-production accounts. Does an AWS landing zone help with NCA and DESC compliance? A landing zone supports compliance by building access control, central logging, and continuous monitoring into the environment by default. It does not deliver compliance on its own, so each organization confirms which NCA, SAMA, DESC, or other requirements apply with its compliance team. When should an organization use Landing Zone Accelerator on AWS? Landing Zone Accelerator suits organizations with strict regulatory requirements, such as government entities and financial institutions, that need deeper control over networking, encryption, and security settings. It is deployed alongside AWS Control Tower rather than replacing it. Why Choose SUDO Consultants We help organizations plan, build, and run AWS foundations that stay secure and well governed as they grow: • AWS Premier Tier Services partner. SUDO Consultants holds AWS Premier Tier Services status in the AWS Partner Network. • Certified team. Our team holds more than 100 AWS certifications. • Proven AWS expertise. Four AWS competencies, including DevOps, Generative AI, and Resilience, and 13 AWS service delivery validations. • Local presence. Headquartered in Dubai Media City, with an office in Kingdom Tower, Riyadh. • End-to-end support. We design, migrate, secure, and operate AWS environments, from landing zone design to managed cloud services . Planning your landing zone? SUDO Consultants helps organizations across the UAE, Saudi Arabia, and beyond design, build, and operate secure AWS foundations. If you are planning a landing zone, or want a second opinion on the one you already have, talk to our team.
DEV CommunityThe Giantsread at source
Your Agent Said "Done". The Trace Shows Nothing Changed.
Picture a routine cleanup run on a staging repo. Fourteen tool calls. Fourteen status: ok spans. Then the post-run diff is empty. Nothing was deleted. Nothing was renamed. The agent still reported success. This is the failure class that traces miss most often. The call succeeded. The world did not change. The bug is in your status field, not your model Most trace schemas record three things: tool name, arguments, output. Status comes from the caller's try/except. That tells you the function returned. It does not tell you the effect happened. A prune_branches call returns ok when zero branches match the filter. A migrate_rows call returns ok when the batch was already migrated. A write_config call returns ok when it rewrote identical bytes. All three are legitimate no-ops. All three look identical to real work in a trace. When an agent loops, retries, or replans, this ambiguity compounds fast. You cannot tell "it worked" from "it politely did nothing." Add a witness: probe the state you mutate You do not need distributed tracing to fix this. You need one cheap, read-only state probe per mutating tool. A probe returns a small snapshot. Hash it. Compare before and after. Store the digest pair in the span. # witness.py — record a state probe before and after every mutating tool call import hashlib import json import time import uuid def digest ( value ) -> str : raw = json . dumps ( value , sort_keys = True , default = str ). encode () return hashlib . sha256 ( raw ). hexdigest ()[: 12 ] def record_effect ( trace_path , tool_name , args , call , probe ): """ probe: zero-arg callable returning a small, read-only state snapshot. """ before = digest ( probe ()) span_id = uuid . uuid4 (). hex [: 8 ] status , output = " ok " , None t0 = time . monotonic () try : output = call ( ** args ) except Exception as exc : # keep the span even when the tool explodes status , output = " error " , { " error " : repr ( exc )} elapsed_ms = round (( time . monotonic () - t0 ) * 1000 , 2 ) after = digest ( probe ()) span = { " span_id " : span_id , " tool " : tool_name , " args_digest " : digest ( args ), " status " : status , " elapsed_ms " : elapsed_ms , " effect " : { " before " : before , " after " : after , " changed " : before != after }, " output_digest " : digest ( output ), } with open ( trace_path , " a " , encoding = " utf-8 " ) as fh : fh . write ( json . dumps ( span ) + " \n " ) return output Wiring it up is one line per tool: probe = lambda : { " branches " : sorted ( repo . branches ()), " head " : repo . head_sha (), } record_effect ( " trace.jsonl " , " prune_branches " , { " older_than_days " : 90 }, repo . prune , probe , ) Good probes are boring. Three rules keep them honest: Read-only. A probe must never mutate. Bounded. Return counts, ids, hashes — not full tables. Stable. Sort collections so ordering noise does not fake a change. Avoid updated_at timestamps in the probe. They burn the whole trick by changing on every touch. Four cells, four different bugs The value shows up when you cross status with the effect flag. You get a 2x2 that separates failure modes you were previously merging. status effect changed label what it usually means ok yes clean_success expected; keep moving ok no silent_success no-op, over-broad filter, or wrong target error yes phantom_failure partial write, timeout after commit, retry hazard error no clean_failure expected; safe to retry silent_success is the cell that wastes the most engineer hours. The agent believes it made progress. It replans, retries, and burns context on a task that finished zero work. phantom_failure is the dangerous cell. Something changed, but the caller thinks it failed. Any retry now risks a duplicate effect. The checker: fail the run, not the review A trace is only useful if a script can read it. Keep the classifier in its own file and exit non-zero. # check_effects.py — classify a JSONL trace and fail CI on suspicion import collections import json import sys def classify ( span ): if span . get ( " effect " ) is None : return " unprobed " ok = span [ " status " ] == " ok " changed = span [ " effect " ][ " changed " ] if ok and changed : return " clean_success " if ok and not changed : return " silent_success " if changed : return " phantom_failure " return " clean_failure " rows = [ json . loads ( line ) for line in open ( sys . argv [ 1 ], encoding = " utf-8 " )] counts = collections . Counter ( classify ( s ) for s in rows ) for name , n in counts . most_common (): print ( f " { n : > 4 } { name } " ) suspicious = [ s for s in rows if classify ( s ) in ( " silent_success " , " phantom_failure " )] print ( " \n Suspicious spans: " ) for s in suspicious : print ( f " { s [ ' span_id ' ] } { s [ ' tool ' ] : 24 } { classify ( s ) : 16 } { s [ ' elapsed_ms ' ] } ms " ) sys . exit ( 1 if suspicious else 0 ) Run it the same way every time: python check_effects.py trace.jsonl Now a silent no-op is a red build, not a mystery in a UI timeline. A debug loop you can reuse This is the part worth writing down. Same order, every time. Re-run the failing task with witnesses enabled. Read the counter output before reading any span. Open the first silent_success span, not the last failure. Check whether the filter matched nothing, or matched the wrong object. Fix the argument selection, then re-run the identical task. Confirm the same span flipped to clean_success . Only then look at whether the agent's final answer changed. Step 3 is the counterintuitive one. The first no-op is almost always the root cause. Later spans are downstream noise from a confused planner. Step 5 matters for reproducibility. Change one thing per run. A trace diff with five variables is not evidence. Where a free model and a free server actually help Two parts of this loop are a good fit for cheap infrastructure, and one of them is boring enough that people skip it. First: writing probes. Every tool schema already describes the state it touches. Asking a model to draft a candidate probe from a schema is a small, one-shot job. Bad drafts are obvious and cost nothing to throw away. This is where free model access is useful — the task is small, repeatable, and you review every output anyway. Second: running the loop. You need a box that holds trace.jsonl , runs check_effects.py , and serves a page of span rows. That is not production. It is a scratch environment you will rebuild. A free server option removes the provisioning step, which is exactly the step that kills these experiments before the second iteration. MonkeyCode offers an open-source project with free model access and a free server option, which is why it came up here. Disclosure: This article was prepared as part of MonkeyCode's product outreach. Treat the free tiers as an accelerator, not an architecture. Check the project page for current limits and terms before you build a workflow on them. Anything that must be permanent belongs in your own infrastructure. Where the witness approach breaks down Be honest about the edges before you adopt this. Probes cost time. Every mutating call now does two extra reads. On a hot path, that is measurable. Non-idempotent probes lie. A probe that consumes a queue message destroys the thing it measures. "Changed" is not "correct." A span can flip to clean_success while writing the wrong value. The witness proves motion, not intent. Large state defeats the digest. Hashing a million rows teaches you nothing useful. Probes can leak secrets into your trace store. Digest them, or redact the snapshot before writing. External systems may lag. An eventually consistent read makes silent_success a false alarm. Wait, or probe a source that is immediate. Skip this approach if your agent is purely read-only. Skip it if the tools expose no cheap state. Skip it if your team needs sub-millisecond overhead and cannot afford a second read. The takeaway A span that says ok documents a return value. A span that says ok plus a changed digest documents work. You only need one of those when the agent insists the job is done. Add the probe, cross the two columns, and let the counter tell you which spans are lying. If you want to try the loop without provisioning anything, the project's free model access and free server option are the shortest path to your first silent_success count.
DEV CommunityThe Giantsread at source
Master the Migration: Upgrading Your RHEL Workload - Part 1
Upgrading Red Hat Enterprise Linux 8 to 9: A Practical Guide Using Leapp Introduction As Linux administrators and engineers, we eventually reach a point where critical systems must be upgraded without unnecessarily disrupting business operations. At first, upgrading a perfectly functioning operating system may seem unnecessary. After all, why disturb a system that is working as expected? However, enterprise environments cannot rely indefinitely on systems simply because they continue to function. Security vulnerabilities, software lifecycle policies, vendor support requirements, and evolving technology standards make operating system upgrades an essential part of infrastructure management. But upgrading RHEL is only part of the story! In this series, I’ll go beyond the traditional upgrade approach and explore different paths to modernize your Linux infrastructure. We will go from conventional in-place upgrades and fresh installations to the emerging world of Image Mode with bootc. What are the trade-offs? Which approach works best for different environments? And how can we minimize downtime while keeping critical workloads running? I’ll explore these questions hands-on, uncover the challenges, and share practical lessons along the way. The journey from traditional Linux management to modern, image-based operating systems starts here. Stay tuned. You won’t want to miss what’s next! In this article however, I will explain why upgrading from Red Hat Enterprise Linux (RHEL) 8 to RHEL 9 matters, the precautions to take before beginning the process, and how to approach an in-place upgrade using Leapp. The objective is to share practical experience, highlight common challenges, and help Linux administrators plan and execute upgrades with greater confidence. Why Upgrade from RHEL 8 to RHEL 9? An operating system upgrade is more than a version change. It is an opportunity to improve security, maintain vendor supportability, and prepare infrastructure for future requirements. Here are some reasons to consider upgrading. Improved Security and Compliance: Security and compliance teams continually assess infrastructure for vulnerabilities, outdated software, and deviations from organizational security policies. RHEL 9 introduces newer security capabilities, updated cryptographic policies, and security improvements that can help organizations meet their security and regulatory requirements. However, an upgrade alone does not guarantee compliance. Administrators must also review system configurations, access controls, security policies, and application requirements after the migration. Lifecycle Planning and Vendor Support: Every operating system has a defined support lifecycle. As a platform approaches the end of its maintenance or support period, organizations must plan how to maintain security updates, technical support, and application compatibility. Running an unsupported operating system can increase operational risk, particularly when it hosts business-critical applications. Upgrading to a supported release helps organizations maintain access to the appropriate vendor updates and support services, subject to their subscription and support agreements. Access to Newer Tools and Technologies: Newer operating system releases provide updated system libraries, development tools, virtualization capabilities, and platform features. RHEL 9 also introduces changes that may benefit modern application development, automation, and infrastructure management. These improvements can help organizations prepare for evolving workloads and technology requirements. However, administrators must verify that their applications, drivers, monitoring agents, and third-party software are compatible with the target release. Understanding the Risks Before Upgrading Although upgrading offers several benefits, it is not an activity that should be undertaken without proper planning. A major-version upgrade can affect application dependencies, system libraries, network configurations, security policies, and third-party software. Before proceeding, consult the relevant application teams, software vendors, and official Red Hat documentation to confirm that the proposed upgrade is supported. For business-critical infrastructure, the upgrade should first be tested in a development or staging environment that closely resembles production. Understanding Leapp Traditionally, moving between major operating system versions has often involved provisioning a new server, reinstalling applications, migrating data, and switching production workloads to the replacement system. Although this approach remains appropriate in many environments, it can require significant planning and may introduce additional migration complexity. Red Hat provides Leapp as a framework for supported in-place upgrades between specific RHEL major versions. Leapp assesses the existing system, identifies potential upgrade blockers, prepares the target operating system packages, and facilitates the upgrade process through a dedicated boot environment. The process generally involves: Reviewing the supported upgrade path. Preparing the source operating system. Running a pre-upgrade assessment. Resolving reported inhibitors. Executing the upgrade. Verifying the upgraded operating system. Performing post-upgrade cleanup and validation. Leapp does not eliminate the need for backups, compatibility testing, or recovery planning. A successful upgrade depends on proper preparation and the condition of the source system. Confirm the Supported Upgrade Path Before running any commands, establish whether your current RHEL installation can be upgraded to the intended target release. For a typical RHEL 8 to RHEL 9 upgrade, the source system should be on the latest supported RHEL 8 minor release, commonly RHEL 8.10, with the necessary updates installed. At the time of writing, upgrades are supported from 8.10 to 9.8 Also verify whether the upgrade is supported for your system architecture, installed packages, subscription configuration, and infrastructure platform. Review the System Requirements Before starting an in-place upgrade, confirm that the server meets the relevant requirements. Operating System and Architecture For this practical exercise, the environment is based on the x86_64 architecture. The procedure may differ for other architectures, so consult the relevant Red Hat documentation before applying the same approach elsewhere. Subscription and Repository Access Ensure the system has a valid RHEL subscription or an appropriately configured repository source or Satellite. For disconnected environments, confirm that the required installation media or local repository mirrors contain the packages needed for the upgrade. A Red Hat Developer Subscription can be suitable for eligible development and testing environments, subject to its applicable terms. I used it for this process. Available Disk Space Check that sufficient space is available in the relevant filesystems, particularly: /var /var/lib/leapp /boot / /usr The exact space requirements depend on the environment and upgrade configuration. Review the pre-upgrade report and official documentation rather than relying on a fixed estimate. Console Access Ensure that out-of-band or hypervisor console access is available. Examples include: Dell iDRAC HPE iLO A hypervisor console A supported serial console Console access is particularly important because the upgrade process includes rebooting the system. If networking fails during the migration, remote SSH access may no longer be available. Verified Backup and Recovery Plan Before proceeding, ensure that a suitable backup or recovery mechanism is available and that the recovery procedure has been tested. A backup that has never been restored is not a fully validated recovery plan. Pre-Upgrade Planning Checklist A structured checklist helps reduce the risk of unexpected downtime. In as much as this is not very exhaustive, tailor this to what your organization use. Before the Upgrade Test the upgrade in a development or staging environment. Confirm that application owners have been notified. Validate application compatibility with the target RHEL release. Obtain the necessary management and change-control approvals. Take a backup or snapshot and verify the recovery procedure. Update the source system to the latest supported RHEL 8 minor release. Confirm that the appropriate kernel is installed and running. Verify subscription status and repository accessibility. Review third-party repositories and packages. Confirm console access. Document current services, network settings, mount points, and application dependencies. During the Upgrade Run the Leapp pre-upgrade assessment. Review and resolve all upgrade inhibitors. Review any additional warnings that could affect the workload. Run the upgrade only after the system is ready. Monitor progress through the available console. Keep the recovery plan accessible. After the Upgrade Verify the operating system release and running kernel. Confirm that SELinux is operating in the intended mode. Validate networking, DNS, routing, and authentication. Verify critical system services. Test application functionality. Confirm database and storage availability. Revalidate monitoring, logging, and security controls. Review temporary files, obsolete packages, and upgrade logs. Update operational documentation and monitoring baselines. Performing Backups Once you have management approvals and the upgrade has been tested, the next step is to protect the existing environment. The backup method should be selected according to the server's role, storage layout, and recovery requirements. Let's consider a few scenarioes: Virtual Machines A hypervisor snapshot may provide a convenient recovery point. However, snapshots are not a substitute for an independent backup. Follow the hypervisor vendor's guidance and ensure that application consistency requirements are addressed. Physical Servers Depending on the environment, recovery options may include: Red Hat-compatible ReaR recovery images. Storage or logical-volume snapshots. File-level backups. Full-system backup solutions. At a minimum, protect critical configuration files, application data, and other information required to rebuild the service. Database Servers Database workloads require special attention. Take an appropriate logical backup or consistent database snapshot in addition to the system-level backup. Follow the database vendor's instructions for ensuring that the backup can be restored. Application Servers Review the application vendor's backup and recovery guidance. Where practical, install and test the application on a separate RHEL 9 system before upgrading the production server. This helps identify unsupported dependencies before they become an operational problem. Prepare and Update the RHEL 8 System Before upgrading, verify the system's current state. Start by obtaining an administrative shell: sudo -i Check the operating system release: cat /etc/redhat-release Check the running kernel: uname -r Review the subscription status: subscription-manager status Inspect enabled repositories: dnf repolist --enabled Review repository configuration carefully, especially if the server uses Satellite, custom repository definitions, or third-party software sources. Update the System After confirming that the repositories are correct and the backup is available, update the source operating system according to your organization's patching procedures. For a standard RHEL 8 environment, the following commands can be used as a starting point: dnf clean all dnf update -y Review the transaction before allowing it to proceed in a production environment. If a reboot is required, schedule it through the normal change-control process if you have not done so already for the upgrade: reboot After the system returns, verify the release and running kernel again: cat /etc/redhat-release uname -r Confirm that the system is healthy before continuing. Make these changes only when they are required by the supported upgrade procedure for your environment. Review Leapp Prerequisites Before installing or updating Leapp, inspect the existing environment for obsolete upgrade tooling, package conflicts, and unsupported third-party dependencies. dnf remove leapp python2-leapp snactor leapp-upgrade-el7toel8 --disableexcludes = all -y rpm -e --nodeps leapp-deps-el8 leapp-repository-deps-el8 Older Leapp packages left over from previous major-version migrations can cause confusion or interfere with the intended procedure hence we had to remove them. Once the older Leapp application is removed as show in the diagram above, install the newer version from the enabled repo dnf install -y leapp-upgrade vdo kmod-kvdo --disableexcludes = all This installs the Leapp binaries and capabilities to manage old vdo disks with the logical volume manager. Also check the installed storage, virtualization, security, and application components for known compatibility restrictions. This raise the file descriptor limit. The default value is 1024 and the upgrade process will need to open a lot of files during the upgrade. Ensure it is run on the same shell where the upgrade will be initiated. ulimit -n 65535 Set the crypto policy to LEGACY to ensure that legacy applications work, you can change this back to default or whatever crypto policy in place in your environment after the upgrade: update-crypto-policies --set LEGACY Disable Firewall zone drifting. This is an old feature of the firewall on older RHEL which allows packets destined for undefined zones to end up on the default firewall zone and these packets could be accepted on these zones. This feature is not accepted on RHEL 9 or other newer versions. If not disabled, Leapp will mark it as an inhibitor to the upgrade. Disable with the command below: sed -i s/^AllowZoneDrifting = . * /AllowZoneDrifting = no/ /etc/firewalld/firewalld.conf Third-Party Software Third-party software can introduce upgrade blockers. Examples include: Docker CE and associated packages. Kubernetes components. Custom kernel modules. Security agents. Monitoring agents. Backup software. Proprietary application dependencies. In as much as uninstalling before and reinstalling the application after the upgrade works for most cases, it might not be necessary. Check the vendor's compatibility matrix and supported migration instructions first. Run the Leapp Pre-Upgrade Assessment The pre-upgrade assessment is one of the most important stages of the migration. It evaluates the system and generates a report identifying potential issues. On a connected system using the standard Red Hat subscription and repository workflow, the assessment is generally initiated with: leapp preupgrade Without RHSM access, Leapp can use local repositories or ISO images: leapp upgrade --no-rhsm --enablerepo rhel-9-baseos --enablerepo rhel-9-appstream You will need to define those repositories under /etc/yum.repos.d/ (or supply the RHEL 9 ISO) before running the command. Red Hat Satellite is the better option for fleets, because it also centralises content views and approvals. For environments using custom repositories, disconnected installation media, or a particular target minor release, additional configuration may be required. Use the exact command and repository configuration documented for your environment. After the assessment completes, in most cases like the example in the image above, you will see some inhibitors(errors), inspect the report: less /var/log/leapp/leapp-report.txt Review the answer file when applicable: less /var/log/leapp/answerfile The report may identify inhibitors, warnings, and other findings that require attention. There are situations where there is no inhibitor and in such case, you can go ahead with the upgrade. An inhibitor is an issue that prevents the upgrade from proceeding until it has been resolved. Troubleshooting Common Upgrade Inhibitors The exact issues reported by Leapp depend on the installed packages, configuration, and source system history. The following examples illustrate common categories of problems. A. Unanswered Questions in the Answer File Leapp may require explicit answers to certain questions before it can proceed. Review the answer file and identify the section associated with the reported issue. For example, if the report identifies the VDO confirmation section as requiring an answer, the documented response may be supplied using: leapp answer --section remove_pam_pkcs11_module_check.confirm = True Use this example only when the corresponding question is present and its answer is appropriate for the system. Do not copy answer-file commands blindly. Different inhibitors require different responses, and some findings require configuration changes rather than a simple confirmation. B. Unsupported Kernel Modules Legacy or unsupported kernel modules can prevent a migration. Examples that may be encountered in particular environments include pata_acpi and floppy . First, determine whether the module is loaded and whether the system actually requires it. For example: lsmod | grep -E 'pata_acpi|floppy' modprobe -r pata_acpi && echo "blacklist pata_acpi" > /etc/modprobe.d/blacklist-pata_acpi.conf modprobe -r floppy && echo "blacklist floppy" > /etc/modprobe.d/blacklist-floppy.conf If the module is confirmed to be unnecessary and the supported remediation calls for disabling it, follow the documented procedure. Do not unload or blacklist kernel modules indiscriminately. Doing so can affect hardware, storage, or system functionality. C. Legacy Network Configuration Older network scripts and custom interface configurations can cause compatibility problems. Inspect the network connections: nmcli connection show Review legacy network configuration files: ls -l /etc/sysconfig/network-scripts/ mv /etc/sysconfig/network-scripts/ifcfg-lo.bak /root/ Where appropriate, NetworkManager provides a command to migrate supported connection profiles: nmcli connection migrate "ens192" Replace ens192 with the actual connection profile name. Before changing a production network configuration, back up the relevant files and ensure that console access is available. Never assume that every legacy network script should be removed. Determine which files are active and whether the reported issue applies to the system. D. Configuration Management and Watchdog Services Configuration-management agents, automated remediation services, and hardware watchdogs can interfere with a maintenance operation if they trigger changes or reboots unexpectedly. Identify the services installed on the system and determine whether the upgrade procedure requires any of them to be temporarily stopped. Coordinate this with the relevant operations teams. Do not disable monitoring, watchdogs, or configuration-management services without a clear reason and a plan to restore them after the upgrade. E. RPM Database Warnings Leapp may report issues involving the RPM database or package metadata. Before attempting a repair, inspect the reported error and confirm the recommended remediation. If a database backup and rebuild are appropriate for the specific issue, an example of the backup procedure is: tar -C /var/lib -czf \ "/root/rpmdb-backup- $( date +%F-%H%M%S ) .tar.gz" rpm A database rebuild should be performed only when justified by the diagnostic findings and applicable vendor guidance. rpm --verifydb rpm --rebuilddb Do not rebuild the RPM database merely because an unrelated warning appears in the upgrade report. F. Root SSH Login and Authentication Configuration Authentication configuration can introduce compatibility or security issues during a major-version upgrade. Review any reported findings involving SSH, PAM, or authentication modules. Do not enable root SSH login simply to work around an upgrade problem. If a report identifies a specific authentication configuration as incompatible, follow the documented remediation while maintaining the organization's security requirements. G. The Newest Installed Kernel is not the Running Kernel This happens in a situation where you have a more recent kernel installed but an older kernel is booting up. Run the following commands to verify: uname -r grubby --default-kernel In a normal system, both would return the same kernel. However, when both of them are not agreeing, find out the default kernel and then sue the following commmand to fix: grubby --set-default /boot/vmlinuz-4.18.kernel.x86_64 grubby --default-kernel Then reboot If the problem is not fixed, reboot and rebuild grub. First, confirm the disk partition holding the boot device, reinstall grub on it and regenerate the grub configuration file. In the example below, I assume the /boot partition is on the /dev/sda drive. grub2-install /dev/sda grub2-mkconfig -o /boot/grub2/grub.cfg Execute the In-Place Upgrade Once all inhibitors have been resolved, review the report again and confirm that the system is ready. Before starting, verify that: The backup is available. The recovery procedure is understood. The source system is healthy. The target release is supported. The required repositories are accessible. The application owners are ready to validate the workload. Console access is available. For a standard connected system, the upgrade is generally initiated using: leapp upgrade Without RHSM access, Leapp can use local repositories or ISO images: leapp upgrade --no-rhsm --enablerepo rhel-9-baseos --enablerepo rhel-9-appstream You will need to define those repositories under /etc/yum.repos.d/ (or supply the RHEL 9 ISO) before running the command. Red Hat Satellite is the better option for fleets, because it also centralises content views and approvals. Use the target-version and repository options required by the specific supported upgrade procedure. For example, custom repository configurations may require additional parameters. Do not reuse a command copied from another environment without confirming that its target version and repositories match your system. Monitor the process and wait for the expected completion state before proceeding. What Happens During the Upgrade? The upgrade process involves several stages. 1. Transaction preparation Leapp evaluates the required packages and prepares the changes necessary to transition the system to the target release. 2. Upgrade environment preparation The process prepares a dedicated boot environment for performing the migration. 3. Package migration During the upgrade, the system replaces or updates packages and components as required by the target operating system. 4. Reboot and finalization The system reboots into the upgrade environment and performs the migration. It subsequently boots into the upgraded operating system if the process completes successfully. The exact behavior and duration depend on the system, installed packages, and repository configuration. Avoid interrupting the process unless required by an established recovery procedure. Troubleshooting an Upgrade That Does Not Complete If the system fails to complete the upgrade, begin by examining the logs rather than immediately attempting another upgrade. Depending on the failure stage, useful locations may include: less /var/log/leapp/leapp-report.txt less /var/log/leapp/leapp-upgrade.log less /run/initramfs/rdsosreport.txt The files available and their relevance depend on how far the upgrade progressed. For a system that boots successfully, inspect the system journal: journalctl -b For earlier boot attempts, review the relevant previous boot where journal history is available: journalctl --list-boots Then inspect the appropriate boot: journalctl -b -1 Use the error messages to determine whether the problem involves package dependencies, boot configuration, storage, networking, or another component. If the server cannot boot normally, use the available console and follow the recovery procedure appropriate to the failure stage. Do not assume that a failed upgrade can always be reversed with a simple rollback command. Recovery may require restoring a validated backup or following the documented recovery procedure for the environment. Verify the Upgraded System After the system boots successfully, verify the operating system and confirm that the migration completed as expected. Check the Operating System Release cat /etc/os-release You can also run: cat /etc/redhat-release Confirm that the system reports the intended RHEL 9 release. Check the Running Kernel uname -r Confirm that the running kernel is appropriate for the upgraded operating system. Check System Services Review failed services: systemctl --failed Inspect the system journal for relevant errors: journalctl -p err -b Investigate any failures affecting the operating system or business applications. Verify Network Connectivity Check the network configuration: ip address ip route Confirm that DNS resolution and connectivity to required services are working. For example: getent hosts labs.ifeatu.africa Replace labs.ifeatu.africa with a hostname relevant to your environment. Validate Applications Work with application owners to confirm that: Critical services start successfully. Databases are accessible. Application endpoints respond correctly. Authentication works. Scheduled jobs operate as expected. Monitoring and alerting are functioning. Backup jobs remain operational. Performance is within acceptable limits. A successful operating system boot is not sufficient evidence that the entire business service is healthy. Post-Upgrade Cleanup & Operations Once the upgraded system has been validated, review any remaining cleanup tasks. Clean up all RHEL 8 Kernels after confirming the booted RHEL 9 Kernel is active: uname -r rpm -qa 'kernel*' | grep '\.el8' dnf remove $( rpm -qa 'kernel*' | grep '\.el8' ) Clean up other leftovers from the previous installations - in this case, I will be removing items from old RHEL 7 and RHEL 8 installations: rpm -qa | grep -e '\.el[78]' | grep -vE '^(gpg-pubkey|libmodulemd|katello-ca-consumer)' | sort sudo dnf remove -y $( rpm -qa | grep -e '\.el[78]' | grep -vE '^(gpg-pubkey|libmodulemd|katello-ca-consumer)' ) Retain the upgrade logs according to your organization's troubleshooting, audit, and retention requirements. Review security settings and confirm that any temporary changes made during troubleshooting have been reversed where appropriate. Restore normal monitoring and configuration-management operations. Rollback Leapp does not provide a built-in uninstall. Your rollback is whatever you prepared for earlier in this backup. Trust me I have seen situations where everything works fine but a single feature of the application which is not available after the upgrade was the reason for a rollback. Depending on what you planned for, you can: VM snapshot: revert the snapshot (accept the data loss since the snapshot was taken) LVM snapshot: merge the snapshot back and reboot ReaR or backup: restore the full system image Decide in advance what "point of no return" means: for example, "if the app is not healthy within 60 minutes of the reboot, revert." That decision is much easier before the maintenance window than during it. Final Lessons and Recommendations Congratulations you made it to this point. An in-place RHEL upgrade from RHEL 8 to 9 is a technical exercise, but its success depends just as much on preparation and coordination as it does on executing commands. From planning to post-upgrade validation, administrators should focus on the following principles: Plan before executing: Confirm the supported upgrade path, application compatibility, and maintenance window. Back up and test recovery: Ensure that a reliable recovery option is available before making major system changes. Use the pre-upgrade report: Resolve inhibitors and investigate warnings instead of treating the assessment as a formality. Understand your dependencies: Third-party applications, drivers, repositories, and configuration-management tools can affect the outcome. Maintain console access: Do not rely exclusively on SSH during an operation that changes core operating system components. Validate business services: Confirm application functionality, networking, authentication, monitoring, and security after the upgrade. Follow official documentation: Use the supported procedure for the exact source release, target release, architecture, and environment. Conclusion Upgrading from RHEL 8 to RHEL 9 is an important infrastructure lifecycle activity that can improve security, maintain supportability, and prepare systems for future technology requirements. However, a successful upgrade requires more than running a few commands. It demands careful planning, compatibility checks, tested backups, systematic troubleshooting, and thorough post-upgrade validation. Leapp provides a structured approach to supported in-place upgrades, but administrators must understand the environment and resolve the issues identified by the assessment before proceeding. I am documenting this process to share practical lessons from Linux administration, help other engineers troubleshoot real-world challenges, and make enterprise operating system upgrades easier to plan and execute confidently. The next in this series will be upgrading from RHEL 9 to 10.
DEV CommunityThe Giantsread at source
GitMood
AI Mode conversation: A new chance to win every month October MLH × DEV Writing Challenge Your hackathon may end after the weekend, but your project story is just getting started. Publish what you built on DEV and help other developers learn from your process. Current challenge window · Eastern Time Oct 1–31, 2026 Colorful illustrations of a trophy, writing window, heart, and top-seven badge How it works 1 Build at an MLH hackathon Create a project at an MLH event. It can be ambitious, experimental, practical, delightfully weird, or all of the above. 2 Tell the story on DEV Publish a post during the current challenge window explaining what you built, how it works, and what you learned. Include #mlhacks. 3 Help people discover it Share your DEV post with teammates, friends, and your wider network. Community response is one part of how projects are selected. Ready to publish? Use the official DEV submission template to turn your project into a clear, complete story. Open submission template $100 Per selected project Give your project another chance to shine Each month, the DEV editorial team will select at least one favorite project. Additional projects may be selected depending on submission volume. Selections consider technical substance, originality, clear storytelling, and community popularity. Great work deserves an audience, so make your post useful, memorable, and easy to share. Your network can help your project stand out Once your DEV post is live, share its link on social media, in your hackathon community, and with the people who cheered you on while you built it. Authentic discussion and engagement help the editorial team see which projects resonate. This page is an overview of the monthly program. Additional participation terms and badge details will be added when finalized. A new chance to win every month October MLH × DEV Writing Challenge Your hackathon may end after the weekend, but your project story is just getting started. Publish what you built on DEV and help other developers learn from your process. Current challenge window · Eastern Time Oct 1–31, 2026 Colorful illustrations of a trophy, writing window, heart, and top-seven badge How it works 1 Build at an MLH hackathon Create a project at an MLH event. It can be ambitious, experimental, practical, delightfully weird, or all of the above. 2 Tell the story on DEV Publish a post during the current challenge window explaining what you built, how it works, and what you learned. Include #mlhacks. 3 Help people discover it Share your DEV post with teammates, friends, and your wider network. Community response is one part of how projects are selected. Ready to publish? Use the official DEV submission template to turn your project into a clear, complete story. Open submission template $100 Per selected project Give your project another chance to shine Each month, the DEV editorial team will select at least one favorite project. Additional projects may be selected depending on submission volume. Selections consider technical substance, originality, clear storytelling, and community popularity. Great work deserves an audience, so make your post useful, memorable, and easy to share. Your network can help your project stand out Once your DEV post is live, share its link on social media, in your hackathon community, and with the people who cheered you on while you built it. Authentic discussion and engagement help the editorial team see which projects resonate. This page is an overview of the monthly program. Additional participation terms and badge details will be added when finalized. The October MLH × DEV Writing Challenge is a recurring monthly contest that rewards developers who document the projects they build at Major League Hacking (MLH) events. Sponsored by DEV Community and MLH, the challenge awards $100 USD per selected project along with exclusive community profile badges. 🛠️ How It Works Build: Create any software project during an official MLH event. Your build can be a practical tool, an advanced experiment, or a completely unique concept. Write: Document your journey during the open challenge window (October 1–31, 2026). You must use the official DEV Submission Template to detail what you built, how you engineered it, and what you learned. Tag & Publish: Add the #mlhacks tag to your post so the editorial team can find it. Share: Promote your live post across social media and within hackathon spaces. Strong community interaction helps your project stand out to the judges. ⚖️ Evaluation & Selection Criteria The DEV editorial team reviews submissions at the close of the window, picking at least one favorite monthly winner. Selection metrics include: • Technical Substance: Deep dive into how you engineered the code and solved problems. • Originality: The uniqueness or creativity of your project's concept. • Storytelling Quality: How clearly and engagingly you walk readers through your build process. • Community Popularity: Authentic peer discussion, comments, and post reactions. Challenge Attribute Details & Requirements Current Window October 1 – October 31, 2026 (Eastern Time) Primary Reward $100 USD cash prize + Exclusive DEV Badges Mandatory Tag #mlhacks Prerequisite Must be a project built at an MLH hackathon event Judging Criteria Technical substance, originality, clear storytelling, and community engagement Are you planning to write a submission for a project you built recently? If you tell me what your project does and what stack you used, I can help you outline your technical story for the DEV template. • Major League Hacking Major League Hacking | Hackathons and Developer Programs | Major League Hacking Major League Hacking (MLH) and DEV form a global developer community … hosting 1000+ annual events. Hackathons provide hands-on de... • DEV Community Congrats to Our First MLH x DEV Writing Challenge Winner! 9 Oct 2026 — OmniML wins with transparent AI. We just wrapped the very first month of the MLH x DEV Writing Challenge, our new way of celebrati... • DEV Community DEV Online Hackathons and Writing Challenges - DEV Community DEV Writing Challenge (#mlhacks, Extensive catalog of DEV mini hackathons and writing challenges covering AI agents, frontend CSS/ Show all make one project Here is a comprehensive project blueprint for a "delightfully weird" yet practical web app that fits the MLH style. This project, "GitMood," transforms a developer's real-time coding frustration or triumph into a public, interactive musical soundtrack. 🎨 Project Concept: GitMood What it is: A web application and CLI tool that analyzes the "emotional sentiment" of your recent git commit messages and automatically generates a live, dynamic music playlist or soundscape matching your current developer mood. • Angry/Frustrated Commits ("fix typo again please work") → Plays heavy metal or chaotic arcade tracks. • Victoriosos/Proud Commits ("feature fully implemented and tested!") → Plays epic orchestral music or upbeat synthwave. • Tired/Midnight Commits ("i don't even know what this line does anymore") → Plays low-fi hip-hop or rain sounds. 🛠️ The Tech Stack (Hackathon Friendly) • Frontend: React.js / Next.js with Tailwind CSS (for a dark-mode, neon-accented dashboard). • Backend: Node.js (Express) to handle GitHub Webhooks. • AI/Sentiment Processing: Hugging Face API (free, open-source models like Twitter-roBERTa-base for Sentiment Analysis) to score the commit messages. • Audio Integration: Spotify Web API or YouTube Embed API to fetch and play music tracks dynamically. 🚀 Step-by-Step Build Plan for Your Hackathon The GitHub Hook (The Input) • Set up a simple Express server that listens for incoming GitHub Webhook data. • Whenever you run git push, GitHub sends a JSON payload containing your commit message straight to your server. The Sentiment Engine (The Brain) • Pass the string of the commit message to a lightweight NLP sentiment analyzer. • Extract an emotional score: Positive, Neutral, or Negative. • Bonus Hack: Look for specific keywords (e.g., swear words, "help", "finally", "refactor") to fine-tune the mood. The Audio Router (The Output) • Map the sentiment score to a specific musical genre. • Use the Spotify API to trigger a playlist playback or render a custom audio visualizer on your React frontend that adapts its colors based on the mood. 📑 DEV Challenge Submission Template Outline If you write this project up for the challenge, here is exactly how to structure your story using the template guidelines: • The Pitch: Give it a funny hook. "We've all been there at 3 AM, writing angry commit messages. What if your code could scream or celebrate with you?" • How I Built It: Explain how you wired the GitHub webhook to trigger the Hugging Face AI pipeline in under 24 hours. • Challenges Overcame: Talk about handling asynchronous API calls or dealing with rate-limiting on the music players. • What I Learned: Reflect on how easy it is to implement lightweight AI sentiment tools into everyday git workflows. This is a submission for the MLH x DEV Writing Challenge What I Built Demo Partner Technologies Hackathon Experience
The Mozilla BlogBrowsers, engines, etc.3 min read
Skip the busywork with Smart Window
The days might be getting shorter, but your to-do list is only getting longer. Whether you’re getting a head start on holiday shopping or planning your next career move, Smart Window’s newest features will help you keep up. Firefox’s opt-in AI browsing experience can now use information from tabs you choose to help fill out […] The post Skip the busywork with Smart Window appeared first on The Mozilla Blog .
AdactioTop Front-end Bloggersread at source
Typewalk – Lettering in public spaces
Capture lettering on signs, shop windows, and façades, then explore walks to the best finds in your city. adactio.com/links/22817
Hacker News: Show HNLibraries, Frameworks, etc.read at source
Show HN: Tiny Tube – A self hosted video sharing server in a single Go binary
Comments
Hacker News Front PageThe Giantsread at source
Software may be getting worse, but it used to be horrible
Hacker News Front PageThe Giantsread at source
Python's experimental JIT to be removed
Flavio CopesMore Front-end Bloggersread at source
Chrome Alternatives in 2026: 50 Web Browsers Compared
Find a Chrome alternative for your computer and workflow. Use the browser chooser, then compare 50 browsers by engine, features, and practical tradeoffs.
Hacker News Front PageThe Giantsread at source
Wikipedia's Cleanup of AI-Generated Content
Hacker News Front PageThe Giantsread at source
AI promised less work. I've never worked more
Flavio CopesMore Front-end Bloggersread at source
How to work with coding agents from your phone
Use Codex, Claude Code, Cursor, Grok Bot, and other coding agents from your phone. Compare mobile apps, cloud tasks, and remote terminals.
AdactioTop Front-end Bloggersread at source
CSS-Tricks has a new owner! | CSS-Tricks
This is very good news! adactio.com/links/22816
Hacker News Front PageThe Giantsread at source
Roblox downloaded 145GB models from us (including adult content) without asking
Hacker News: Show HNLibraries, Frameworks, etc.read at source
Show HN: Software Hate Index (real-time ranking of SaaS complaints)
Comments
HeyDesignerDeveloper/Designer Newsread at source
Design as a garden
Fast is a design decision, The software factory forgot about design, The state of typography in design systems, Software for one.
Net NinjaYouTube ChannelsVideoWatch on YouTube
GitHub Copilot App Tutorial #3 - Viewing Files & Previewing
Flavio CopesMore Front-end Bloggersread at source
How to protect secrets when coding agents deploy your app
Learn how coding agents can expose secrets, compare ways to manage access, and add safeguards to builds, deployment pipelines, and production code.
HTML All The ThingsPodcastsAudioListen
What Skills Will Stay in Demand as AI Improves?
What skills will stay in demand as AI changes how we work? For developers, preparing for the future might mean looking beyond the next framework and building skills that open doors across different roles. Matt and Mike discuss five areas worth developing: ideation and…
Hacker News: Show HNLibraries, Frameworks, etc.read at source
Show HN: ESP-Watchtower – $3 ESP8266 Home Network Sentinel and Canary Honeypot
Comments
Frontend Masters BlogMore Front-end Bloggers12 min read
What should you put on a dynamic custom social media card image?
There is technology to dynamically create custom social media cards (like this one!) — but what you put on it really depends.
AbduzeedoMulti Author Blogsread at source
Franki Branding: Inside Koto's New Identity
Koto's Franki branding turns restaurant discovery into a shared joke, with a yellow, rounded system built around the line Make Time Dance. The first thing you notice is the yellow. It is not a highlig...
Hacker News: Show HNLibraries, Frameworks, etc.read at source
Show HN: Live speech-to-text on an ESP32-P4 microcontroller, no cloud
Comments
Hacker News: Show HNLibraries, Frameworks, etc.read at source
Show HN: Shittyscreenshares.com
Comments
AbduzeedoMulti Author Blogsread at source
WA3RM: Inside Lundgren+Lindqvist Packaging Design
Explore Lundgren+Lindqvist's packaging design and visual identity for WA3RM, turning paper mill waste heat into silk-screened tomato boxes. Most sustainability pitches sound the same. Companies talk e...
Chris HawkesYouTube ChannelsVideoWatch on YouTube
Claude Just Became a One-Person Marketing Agency
AdactioTop Front-end Bloggersread at source
Monday session
AbduzeedoMulti Author Blogsread at source
Typography: Eredivisie Display by Blaze Type
Discover how Blaze Type and GraphicHunters crafted the Eredivisie Display typography system, turning a sports logo into a bold broadcast font. Sports leagues need a voice that holds up everywhere. Whe...
AbduzeedoMulti Author Blogsread at source
App and web design: Calmaria a quiet place to breathe
Calmaria by abdz.do unveils a clean web design and full parity across iOS, Android, foldables, smartwatches, and the web. Every day, a thousand notifications ask for your attention. Calmaria asks for ...
Level AccessCompany/Startup Blogs7 min read
What Is a Digital Accessibility Platform?
A digital accessibility platform is software an organization uses to find, fix, prevent, and report on accessibility barriers across its websites, applications, and The post What Is a Digital Accessibility Platform? appeared first on Level Access .
SitePointThe Giantsread at source
Building Location-Aware Interfaces Without Mixing Up Language, Currency, and Region
null Continue reading Building Location-Aware Interfaces Without Mixing Up Language, Currency, and Region on SitePoint .
DigitalOcean BlogMulti Author Blogs5 min read
Three layers, all config: how DigitalOcean Managed Agents enforce NVIDIA OpenShell-aligned boundaries
A few weeks ago, we handed an AI agent one of the scariest jobs in infrastructure: moving huffl’s production backend from Supabase to DigitalOcean. huffl.ai is a real product. Underneath it sits 31 tables, 145,432 rows, three storage buckets, and about 31,000 vector embeddings.…
Engineering at MetaCompany/Startup Blogs7 min read
Meta Networking at the 2026 OCP Global Summit: Open Innovation for Scale-Up, Scale-Out, and Scale-Across AI Networks
At the 2026 Open Compute Project (OCP) Global Summit, Meta shared the networking innovations that are directly supporting our latest AI models, including Muse Wonder and Muse Spark, and our gigawatt-scale Prometheus cluster. Highlights IcePack & IceCube: Meta’s first liquid-cooled network rack with 102.4T switch blades (128×800G, Broadcom Tomahawk 6C and NVIDIA Spectrum-6 variants), running [...] Read More... The post Meta Networking at the 2026 OCP Global Summit: Open Innovation for Scale-Up, Scale-Out, and Scale-Across AI Networks appeared first on Engineering at Meta .
SitePointThe Giantsread at source
Best AI Recruiting Agents in 2026: 6 Compared
The best AI recruiting agents in 2026, compared on autonomy, approvals, channels, scheduling and pricing. Pin covers sourcing through scheduling. Free plan. Continue reading Best AI Recruiting Agents in 2026: 6 Compared on SitePoint .
Dave RupertTop Front-end Bloggersread at source
Arc-like automatic picture-in-picture in Chromium
There’s a lot to miss about Arc (RIP), but the feature I miss the most has got to be automatic picture-in-picture. You start a video and when you change tabs to jump to another task, the video anchored itself to the corner of your desktop. Go back to the video tab and it slurps up into the video player area. A perfect experience with no interruption. I switched back to Edge (for work) and missed Auto-PiP a lot. I tried building a custom browser extension to restore the functionality myself but hit a platform limitation with the mix of WebExtensions , PageVisibility , and MediaSession APIs you need to get it to work seamlessly. You had to configure each site in a dropdown and run a script each MediaSession… it asked a lot of the user. There’s been a handful of Chromium flags and experiments to add “Auto-PiP” over the years, but nothing did it as well as Arc did… until… about://flags#browser-initiated-automatic-picture-in-picture Chrome 142 introduced a new browser-initiated-automatic-picture-in-picture flag and it behaves the same as Arc. The browser does all the work popping the video in-and-out when expected. I couldn’t believe this near-exact replica was hiding in plain sight all this time! But I couldn’t use it because the flag didn’t exist in Edge 😭 I started up a couple internal threads about it last year but it went nowhere. When the topic came up again this year, I mentioned to Greg Whitworth , “Y’know there’s a flag in Chrome that does Auto-PiP great…” and that next week the flag showed up in Canary and I’m happy to say it’s available today in mainline Edge 156. If you missed that feature in Arc and didn’t know it existed in Chrome or felt crushed by it not existing in Edge… then head over and turn on the flag today, I think you’ll be happy. The only thing it’s missing for me are the juicy physics-based animations that let you two-finger swipe and throw the picture-in-picture window around and pinch-zoom to resize. But it feels like the bones are there. And it feels like a good time to remind my fellow Edge users that Edge has a little feedback form inside the Three Dots menu > Help and Feedback > Send Feedback.
CSS-TricksThe Giantsread at source
CSS-Tricks has a new owner!
Yes, I've got the keys to the castle, so to speak. And, even after 12 years of working on the site, I'll admit I'm a little overwhelmed and nervous about that. CSS-Tricks has a new owner! originally handwritten and published with love on CSS-Tricks . You should really get the newsletter as well.
Flavio CopesMore Front-end Bloggersread at source
How to use MCP Tasks and Elicitations in Claude Code
Build a local MCP server with background tasks and confirmation forms in Claude Code. Learn how polling, cancellation, and reconnecting work.
SitePointThe Giantsread at source
6 Tools for Building Email Automations You Can Test and Debug
null Continue reading 6 Tools for Building Email Automations You Can Test and Debug on SitePoint .
SitePointThe Giantsread at source
6 Email Tools Developers Can Use to Build, Test, and Monitor Better Email
null Continue reading 6 Email Tools Developers Can Use to Build, Test, and Monitor Better Email on SitePoint .
AbduzeedoMulti Author Blogsread at source
Brand Identity: Eames Institute by Manual
San Francisco studio Manual builds a living brand identity for the Eames Institute of Infinite Curiosity, pairing archival type with the curious e. Designing for Ray and Charles Eames is a massive tra...
SitePointThe Giantsread at source
Browser Fingerprinting Explained: How Websites Identify You and How Developers Can Reduce It
null Continue reading Browser Fingerprinting Explained: How Websites Identify You and How Developers Can Reduce It on SitePoint .
SitePointThe Giantsread at source
The Privacy Risks of Browser Extensions: What Developers Should Know
null Continue reading The Privacy Risks of Browser Extensions: What Developers Should Know on SitePoint .
SitePointThe Giantsread at source
Passwordless Authentication and Identity Theft: Can Passkeys Make the Web Safer?
null Continue reading Passwordless Authentication and Identity Theft: Can Passkeys Make the Web Safer? on SitePoint .
SyntaxPodcastsAudioListen
1050 - Everyone Is Hacking Their TV
Wes, Scott, and CJ run through the week’s biggest web dev news: everyone’s hacking their TVs, VoidZero open-sourced its Void framework with Cloudflare deploys, OpenCode got hacked, and Anthropic built its own git replacement. Plus DeepSeek V4.1 Flash, Cloudflare’s security audit…
Flavio CopesMore Front-end Bloggersread at source
The complete guide to Convex
Learn Convex by building a real-time app with TypeScript, queries, mutations, authentication, indexes, search, file storage, background jobs, and tests.
Flavio CopesMore Front-end Bloggersread at source
How to use Grok Build
A detailed Grok Build tutorial covering installation, prompts, plans, permissions, tests, Git, skills, MCP, subagents, sessions, and headless automation.
Flavio CopesMore Front-end Bloggersread at source
A pull request workflow for code written by agents
Review agent-written code with a practical pull request workflow: focused tests, independent review, human approval, merge queues, and deployment checks.
Net NinjaYouTube ChannelsVideoWatch on YouTube
GitHub Copilot App Tutorial #2 - Adding Projects
Net NinjaYouTube ChannelsVideoWatch on YouTube
GitHub Copilot App Tutorial #1 - Intro & Setup
HeyDesignerDeveloper/Designer Newsread at source
Nobody asked for the sparkle button
Entering Atomic Design from the screen, Apple’s Dimensional Drawings, Code review was never about the code.
Flavio CopesMore Front-end Bloggersread at source
Prompt caching, compression, and compaction in coding agents
Learn how prompt caching, transport compression, and context compaction affect coding agent costs, speed, memory, and usage, with practical examples.
AbduzeedoMulti Author Blogsread at source
Inside Senhor Paulinho’s Brand Identity for Arado 2026
Arado 2026 by Senhor Paulinho is a brand identity system for Madrasta Dance built on hand-drawn typography, ink textures, and yellow posters. Portuguese graphic designer Paulo Graça (known as Senhor P...
AbduzeedoMulti Author Blogsread at source
Brand Identity: Rothfield by Studio Julius
Studio Julius builds a calibrated brand identity, custom 16-unit icon system, and tactile studio tools for Australian partner Rothfield. Working behind the scenes rarely gets the spotlight. For decade...
AbduzeedoMulti Author Blogsread at source
Typography: Exemplar by Letters from Sweden
Letters from Sweden has unveiled Exemplar, an expansive multi-script typography family thirty years in the making and carved into Italian Carrara marble. In 1994, type designer Göran Söderström began ...
Jim Nielsen’s BlogMore Front-end Bloggersread at source
Why My Dad Didn’t Have a Cell Phone
Here’s Dave Rupert writing about all those emails, texts, phone calls, etc. we’re getting these days: Once upon a time it had utility, now it’s all noise and grifter slop demanding our attention and giving us to-dos That last part really hit: “giving us to-dos”. I feel this. So many of the messenger apps on my phone are other people laying claim to my time and attention. It reminds me of an interaction I had with my Dad years ago. This was back when cell phones were starting to become ubiquitous. Not smartphones , mind you. Cell phones, i.e. telephones that were mobile. Texting wasn’t really a thing yet. These were devices for making voice calls wherever you went. As a teen, it seemed like everyone had one: my teachers, my friends, even my friends’ parents. But not my parents. They were “behind the times”. (Everyone was getting cell phones and we didn’t even have caller ID on our landline!) One night at family dinner I asked, “Dad, why don’t you have a cell phone?” His response? “Why would I want to allow other people to contact me whenever they want?” I still think about that. Reply via: Email · Mastodon · Bluesky
SitePointThe Giantsread at source
9 Checks Before Shipping a Product Email: A Workflow for Developers and Designers
Nine pre-send checks for product emails: authentication, rendering, accessibility, links, tokens, and deliverability - a workflow for developers and designers. Continue reading 9 Checks Before Shipping a Product Email: A Workflow for Developers and Designers on SitePoint .
AdactioTop Front-end Bloggersread at source
Imagining the sci-fi cabal meeting where Adrian Tchaikovsky and Ray Nayler divvied up their assignments: “Okay, we can both do octopuses and crows, but let’s toss a coin for mammoths; loser has to do spiders.”
The Mozilla BlogBrowsers, engines, etc.3 min read
Firefox reunites meme royalty to remind you what the internet used to feel like
A group of familiar faces from the early web just got back together to ask an important question: What happened to the internet? Sure, there was a time when it was a little less polished, and a lot less speedy, but it was yours. Overly Attached Girlfriend may have wanted to know everything about you, […] The post Firefox reunites meme royalty to remind you what the internet used to feel like appeared first on The Mozilla Blog .