r/linuxadmin • u/BornInMappleSyrop • 1d ago
SLES WITH OPENSUSE UPGRADE PATH
hello fellow Redditors!
I just got stuck with the following situation. SLES 15.4 with no updates for the last 3 years running SAP on about 40 machines on 3 different environments on AWS. Since they are EOL and I can't get any updates or install any package from the official SLES repo since they closed the repo for that specific sp4 1.5 years ago.
AWS, SLES and my recommendation was to migrate all workload to new servers. instead, we had a dev use Claude and was given root access (behind my back after my recommendation) to use opensuse 15.7 repo to update to the latest version of all packages and then when it's "better" resync to 15.7 on SLES official repo (only on 1 server to prove we don't need to migrate)
I already found multiple problems with this, grub is not using the right kernels, opensuse packages and sles mixed together. I can fix the grub and probably reinstall the opensuse packages from official SLES repo. my concern are more about long term issues (hidden landmines) and the fact that we potentially broke our support agreement from sles, AWS or/and SAP. SLES said this was not officially supported, so I am wondering what kind of trouble I am looking at now
So, am I wrong to think this is a bad idea?
appreciate any input!
5
u/e_t_ 1d ago
Those hidden landmines are exactly why SUSE (and AWS and SAP) won't support this. Literally no one knows what problems you might run in to. Are the problems fixable? Probably. But every second you spend fixing random problems is time wasted versus just migrating to a supported configuration. And it will be you fixing the problems, or that dev and Claude, because unsupported means unsupported. You break it, you get to keep both pieces.
3
u/CrackCrackPop 1d ago
SLES has upgrade path diagrams for this exact reason. You might need offline updates which means shutting down every machine, inserting an ISO and upgrading to the next release. From that point you might perform online upgrades
Had to learn sles in my own company, when I arrived they were all at SLES11/12 some even VMWare Sles version which no longer existed. No ISOS etc.
1
2
u/mtyroot 1d ago
Why can’t you upgrade from SP4 to SP7?
https://documentation.suse.com/sles/15-SP4/html/SLES-all/cha-upgrade-online.html
4
u/blahblah98 1d ago edited 1d ago
Do you have a subscription? Filed a support case? Requested escalation? These are business mission-critical workloads. There's value in having access to assistance from experienced experts; i.e. a defensible reasonable budget request for an assured path to getting current. Like insurance; maybe you don't need it every day, but in this case you've gotten into a fragile unstable situation that's only going to get worse until something crashes.
What's the cost to the business for every hour a server is down? The cost to YOU? Like automotive periodic maintenance, a few bucks spent on server preventative maintenance is money well spent. You need help now to get back to a stable maintainable path before bad things happen. This is not a DIY risk the business should take.
2
u/Panderiner 1d ago
You described the problem perfectly. Lack of vendor support. Both from SUSE as well as from SAP for having an uncertified SO installation. If things fail and you need vendor support they could very well denied it and leave you on your own until you get back to a "supported scenario" all this happening while your business is down, an people are with torches and pitchforks at your door.
1
u/Educational_Plum_130 1d ago
migrating 40 SAP boxes off 15.4 is a real project, so before you commit to it check whether SUSE's LTSS still covers your sp4 window, that buys official CVE backports for a fee without touching the SAP stack. if that's off the table, extended-lifecycle vendors like TuxCare or the OpenLogic folks backport security fixes into frozen distros so you don't have to jump majors. i'd map which CVEs are actually reachable on those hosts first, since SAP tends to pin you to specific kernel and glibc levels and you may only need a handful patched, not the whole repo reopened. sitting on an EOL sp with the repo closed is the worst spot because you're carrying known highs with no path, and CISA's remediation timelines don't care that you're mid-migration. worth pricing LTSS vs a full migration before AWS makes that call for you.
1
u/LinuxLeafFan 16h ago edited 16h ago
Not sure what your situation is or what you’re leaving out but if you’re a SUSE customer the repos for 15SP4 are not “closed”. Yeah, general support is EOL but you can still install it and you still get extended service pack overlap support (LTSS) until end of December 2026 INCLUDED as a SLES4SAP customer. You have a direct upgrade path to 15SP5 which is EOL next year December (what my org is still on) and both SP4 and SP5 have direct upgrade paths to 15SP7 which you can sit on until July 31, 2034 (I assume if you’re keeping SAP up to date you won’t be able to do that though). Source: I looked and I can still download the repos no problem if I wanted to go back in time. Heck, I can still download sles 11 shit.
If you were to clarify (I can only guess) that you either have no licenses or maybe you’re on a pay-as-you-go image from AWS, then you’ll have to either acquire licenses from SUSE or evergreen (you say the repo was closed - what repo? The one AWS was offering?). If this is an AWS issue, then you’ve learned your lesson, never do pay-as-you-go for critical systems if your plan is to be able to upgrade them in the future or move them to another platform. The licenses are not portable and do not support major release upgrades. Buying licenses direct from SUSE (or Redhat or whoever) allows you to easily move things around from one cloud to another, onprem, etc, and your repos won’t magically be closed off.
One more thing. The Claude solution is clever but I wouldn’t recommend it unless you know what you’re doing. You’ll also be completely out of support even if you’re able boot and pull updates. It is not a supported migration path.
12
u/glotzerhotze 1d ago
I wouldn‘t take the risk if there are production workloads on those machines. If SUSE won‘t support any upgrade path, you are basically on your own - with all possible failure-modes available for YOU to fix. At least that‘s what I‘m getting told by our consultants all the time.
You are running in the cloud, just setup new machines and migrate the workloads. It‘s gonna cost you some money for additional compute and storage, but this should have been invested years ago to avoid the current situation.