Why Installing openSUSE on a Production Server Doesn't Go to Plan
Installing openSUSE on a production server rarely fails at the file-copying stage — it fails later, when zypper starts resolving dependencies between connected repositories.
The priorities of the main set and additional sources overlap, and instead of the expected package, a build from another repository arrives.
The package conflict manifests not at installation time but when services start: the server comes up, but some services do not come online, and troubleshooting begins with logs, not with package configuration.
The second most common Linux installation error in a production environment is an overlooked node role. An application and a database host need different AppArmor profiles, different partition layouts, and different service sets, yet server deployment follows the same checklist.
A profile written for one role starts blocking legitimate operations on another: the service enters a restart loop, and the log shows access denial instead of the cause.
The most costly is manual server configuration done "on the spot." Configuration edits, additionally installed packages, disabled kernel modules — all of this lives only on the first node and is recorded nowhere.
When a second node appears, it is rebuilt from memory and becomes a machine that behaves differently for the same task: different service behavior, different access rules, different response under load. Debugging such a discrepancy consumes more time than the initial setup.
We explain how this is addressed: by checking dependencies before production launch, by separate AppArmor profiles for each role, and by a configuration description that makes the second node build exactly like the first.
Predictable Updates and Rollback: What Changes in Operations
A fleet on a single SUSE Linux Enterprise and openSUSE branch stops being a set of "special" machines: configuration automation describes the node declaratively — the same repositories, AppArmor profiles, and access rules.
A new node is put into operation in tens of minutes instead of a checklist an engineer walks through from memory.
Deployment: One Run Instead of Manual Passes
Configuration is versioned together with packages and profiles, so the test environment and production differ only in environment parameters. Differences in node behavior stop being a source of surprises, and server fleet management comes down to editing a single description.
Maintenance Windows: Updates on Schedule
zypper updates packages in an agreed window, and a snapshot of the root file system is taken before work begins. If a service does not come up after reboot, returning to the snapshot takes minutes — the window closes on time rather than dragging until morning.
Update Rollback: An Operation, Not Disaster Recovery
Node state is returned to the point before the update — together with packages and configuration. Recovery time after a failure is measured in minutes and can be stated in advance rather than determined during the investigation.
The "Drifted" Machine Failure Class Disappears
Unified AppArmor rules and a single package branch eliminate library mismatches, forgotten exceptions, and local edits no one remembers. The share of post-update incidents falls: a predictable configuration is updated, not a unique one.
openSUSE Installation Modes: Minimal, Full, Network
The installation mode determines not only the starting package set but also how much work the system will require later: the wider the set, the larger the attack surface, the bigger the updates, and the more frequent the reboots for kernel changes. Below are the options actually chosen between, with their boundaries of applicability.
In openSUSE, package sets are grouped into patterns that are selected in the installer, and network mode pulls them from the repository during deployment.
Automated installation records the same choice in a profile, so the result is reproduced on nodes without manual steps and "forgotten" checkboxes.
| Option | When It Fits | Limitations |
|---|---|---|
| Minimal installation: base and kernel | Servers, virtual machines, gateways — the role is installed separately | No graphics or application patterns: utilities are added manually via zypper |
| Full installation with desktop | Engineer workstations, demonstration stands | Pulls in graphics and office patterns: more packages and larger updates |
| Network deployment mode | Fleet of identical machines, reinstallation without media | Requires its own boot server and a stable channel; repositories are specified manually |
| Automated installation by profile | Dozens of nodes, reproducible environments, role replication | An error in the configuration description multiplies across the entire fleet |
| Ready-made image with a preinstalled set | Typical roles: web node, database, terminal | Changes are made by rebuilding the image, not by installing an additional package |
The edition is chosen after the mode: for long-lived servers, take a branch with infrequent updates and a long-term support kernel; for workstations with new hardware, take one with frequent updates.
Mixing both lines in one fleet is inconvenient: different kernel behavior and different support timelines break unified update rules.
Work Order: From Inventory to Handover for Maintenance
Work proceeds strictly sequentially, and a skipped step surfaces later — during operations, when the node fleet has grown. Therefore, we start not with installation but with inventory: until there is an infrastructure map, any configuration scheme turns into a set of guesses.
Implementation Stages
- Infrastructure audit. We collect a list of nodes, roles, services, network zones, and external dependencies. The output is a map showing what is moved into the common template and what remains unique to a specific machine.
- Configuration scheme design. We break the system down into profiles: base image, role, node overrides. We record what is described declaratively, what is done with native openSUSE and SLES tools, and where separate AppArmor policies are needed.
- Preparation of the reference image and roles. We build the build image, automate package installation via zypper, templatize system parameters, and move secrets out of the repository into secure storage.
- Testing on the stand. We deploy a copy of the environment and run scenarios: clean installation, update over the previous branch, rollback, operation of security profiles. We catch errors here, not on production nodes.
- Deployment on target nodes. We proceed in groups with checkpoints between them — if metrics deviate, the group stops, and the others are not affected.
- Handover for maintenance. We provide build documentation, update regulations, rollback procedures, and transfer knowledge to your team — so that role edits do not require us every time.
Configurations, Regulations, and Documentation: What We Hand Over
We hand over not a set of files but a working system: configurations that bring a node up from scratch, and regulations by which the on-call shift maintains it further — without the implementation author.
Everything is stored in a repository under version control: changes undergo review, and rollback to the previous state takes minutes.
- Configurations and roles. Node descriptions — packages, zypper repositories, services, mount parameters, AutoYaST profiles, and automation roles. A new server replicates the reference rather than being assembled by hand.
- Infrastructure diagrams. Network topology, disk and logical volume partitioning, mount points, service placement — these help a new engineer get oriented on day one.
- Access policies. Accounts and groups, sudo scheme, SSH keys, AppArmor profiles in enforcement mode, a "who goes where" matrix: permissions are granted by role, not by situation.
- Maintenance regulations. Update frequency, reboot procedure, maintenance windows, checking repository and free space status, and the procedure for failures.
- Backup. What we copy — configs, data, service state, at what frequency, where copies are stored, and how and by whom restoration is verified.
- Instructions for the on-call shift. Typical operations and incident responses step by step, with commands and signs that the scenario went differently.
- Server documentation. An inventory with node roles, owners, dependencies, and addresses, maintained up to date rather than written once.
Case Study: A Fleet of Forty Servers Was Migrated Without Service Downtime
The customer came with a fleet of forty servers on openSUSE and SLES: some machines were assembled manually according to internal instructions, and some were additionally configured directly on live systems.
Installing one node took 3-4 hours — disk partitioning, network, packages, security profiles — all with an engineer accompanying it.
Updates were more costly. The kernel and system libraries were changed in groups of 8-10 machines during a night window, because after reboot some services did not come up due to configuration discrepancies.
Drift accumulated: a third of the machines had different limits, AppArmor rules, and package versions, and planned service downtime took 25-40 minutes.
What Was Changed
We assembled a unified automatic installation profile: partitioning, network, repositories, and package set are defined by a template, and the machine role is supplied as a parameter.
zypper was switched to internal mirrors, AppArmor rules were enabled in enforcement mode with a separate profile for each service, and before changes we create a restore point — rollback takes one command.
Deployment of a new node was reduced from 3-4 hours to 12 minutes; only physical connection and verification remained as manual steps. Updating the entire fleet takes one run in 25-30 minutes instead of a four-hour window.
Downtime was eliminated by rolling migration: a node is taken out of balancing, updated, and returned to operation. For stateless services, downtime is zero; on databases, replica switching takes 30-40 seconds.
The number of machines deviating from the reference dropped from a third to zero — configuration is now described rather than reproduced from memory.
What to Do If the Fleet Is Already Deployed on Another Distribution
A running fleet on another distribution is not a reason to rebuild everything at once. Changing the distribution differs from a clean installation in that services are already in production and every step must be rollback-able. Therefore, we migrate roles one by one, not machines.
We start with inventory: what roles exist and what relies on features of the previous platform.
Package installation is moved to zypper almost mechanically — repositories, priorities, updates — but custom scripts and update hooks will have to be rewritten, not "patched for compatibility." The most costly divergences are roles where settings lived in patches to distribution packages.
Mandatory access control is a separate point. AppArmor profiles are built by file paths and permissions, not by labels, so policies transfer more easily than in context-based systems, but they must be tested: what was previously allowed implicitly is now blocked. First, learning mode on a traffic copy, then enforcement.
Some roles are not fully compatible. Those tightly tied to the package set and kernel version are cheaper to rebuild as declarative configuration management roles than to carry over as is.
YaST is useful both as a source of reference network and storage settings and as a check that the migration did not break the base layer.
Phased transition: a pilot node for each role in a non-production environment, then a canary group behind the load balancer, then waves by zone with a pause and comparison of service metrics.
Rollback is returning the load balancer to the previous pool; old nodes live until the new group completes a full cycle under load.
Doubts About Compatibility, Updates, and Rollback
Before work starts, customers ask roughly the same five questions: how to update on a live system, what to do if an update fails, how safe third-party repositories are, whether a separate stand is needed, and what will remain with the team after handover. We answer the same way as in a technical session — without vague wording.
Are Updates Without Any Downtime Possible at All?
Yes, if there is more than one node in the environment. We roll out one at a time: the node is taken out of balancing, updated, service checks are run, and only then is it returned to operation. For a single node, we honestly plan a window — there is nothing to promise zero downtime with.
What Happens If an Update Breaks the System?
Before each update, we take a snapshot of the root partition and link it to the bootloader. Rollback is a reboot into the previous snapshot, minutes, without reinstallation and without data loss. We do not remove the previous kernel until the new environment has run for a day.
Won't Packages from Third-Party Repositories Break the System?
Package compatibility is checked before rollout: we configure repository priorities in zypper, pin versions of critical packages, and cut off sources that pull conflicting dependencies. We connect external repositories selectively, not "just in case."
Is a Separate Test Stand Mandatory?
Yes. The stand replicates the production environment configuration, and updates, AppArmor rules, and repository changes first pass there. If there is no stand, we set it up as part of the work; otherwise, any update becomes an experiment on live users.
What Will Remain with Our Team After Handover?
Update and rollback regulations, environment diagram, access description, and typical failure descriptions.
We conduct a review with your engineers and record it so that a new person on the team can reproduce the procedures without us — knowledge transfer is part of the scope of work, not a separate line item.
Let's Discuss the Task and Come Back with an Estimate and Work Plan
To make the estimate substantive rather than "roughly like this," we need a snapshot of the fleet and the constraints under which we will work. The more precise the input data, the fewer assumptions in the implementation plan and the fewer edits after the start.
What to send in the first message:
- list of servers: number of machines, distribution and its branch (openSUSE Leap, SLES), whether installation is already underway or only planned;
- server roles: where web, where databases, where virtualization — this determines the update order and the set of YaST profiles;
- how packages and configurations are managed: zypper manually, Ansible, Salt, or custom scripts — what to keep, what to replace;
- maintenance windows: acceptable downtime per server group, availability of backups and rollback points;
- logging and security requirements: whether AppArmor is needed, sudo action auditing, log export to an external system;
- access and network: isolated environment without external access, own mirror repository, method of granting access to engineers;
- stands and sites: one environment or several, whether there is a copy of the production environment for policy testing.
Based on this list, we come back with a work estimate: breakdown by stages, the order and duration of each, what we do in a downtime window and what without stopping services.
Some items on the list may be missing — we will gather some on a call and record them in the plan as assumptions so they do not surface in the middle of the work.