Looking at the SQL Server 2019 preview published by the Redmond folks, it seems that only SLES12 SP2 is recognised.
Looking at SUSE’s Lifecycle notices, SLES12 has general support up to the 31st of October 2024 or, SLES12 SP4 has general support up to 6 months after SLES12 SP5 release.
SLES12 SP2 has general support up to the 31st of March 2018 and Long Term Support until the 31st of March 2021.
Hopefully the Redmond folks will offer a SQL Server version suitable for SLES15 before October 2024 …
[HR][/HR]We have absolutely no control over how the folks in the woods around Seattle tick …
I’ve spent as much time as I can on this…
There are a few problems with what is available,
First it should be recognized that the repo and its contents, plus the instructions are all Microsoft and likely setup and written by someone unfamiliar with openSUSE… only by someone who read some documentation but not a regular User.
First major issue is that a gpg cert somewhere in the authentication chain is self-signed which is breaking simple, normal and direct commands to add and refresh the repo. Whatever is happening, I cannot find a zypper configuration that works, and may be the reason why the documentation describes installing a repo configuration which in turn installs the repo instead of installing the repo directly. If this is why the convoluted repo configuration, such are the devices of the uninformed.
The other major issue is that the repodata metadata is faulty in some way. If you look at the repo.xml, it’s big… that’s a lot of stuff to have to verify is correct.
The remaining method which will probably work but I’m not going to do for at least the next few days is to replicate the repos to a local location and set up your own repository with its own level of security. Since I don’t expect the packages to change, it’s possibly an acceptable risk.
Bottom line though, the Microsoft repos should be fixed by Microsoft themselves.
If you want to copy the actual MSSQL repos(bypassing the configuration repos in the documentation), they’re here…
They’re all here… MSSQL for SLES 11, SLES 12, SLES15 and of course SLES15 is supposed to be similar to openSUSE 15
openssl 1.02 is in the OSS,
All those steps to uninstall and install related to openssl can likely be replaced with the following single command, and select option 1
For anyone who might care, note that this downgrades your system openssl from 1.1.0 to 1.0.2 (as of today).
zypper in openssl-1_0_0
I’m not clear on your requirement to possibly downgrade your ldap2, did you really find that necessary and could that be because you’re running an old version of AD?
Regarding adding new PATH to access the location of your User Tools…
Generally I keep my User paths separate from my system paths, anything that should be specific to a logged in User generally points to a location in that User’s directory tree while anything that points to a location that requires root permissions I consider equivalent to “system” so would be configured for system-wide access.
Perhaps someone might comment if my reasoning is flawed,
But consistent with my personal policy, I’d configure those PATH additions in an /etc/profile.local file instead of as a BASHrc configuration.
All steps identified originated from six or seven complete installs of OpenSuse 15.1 to eliminate any library and/or dependency issues after many failed MS SQL Server 2017 installations. My goal was to provide everyone the working steps for a clean MS SQL Server 2017 on Linux installation on a fresh OpenSuse 15.1 installation (before any other software installs).
MS SQL Server 2017 on Linux WILL NOT run with current packages of ‘openssl’, ‘openldap2’, ‘libldap’, and ‘openldap2-client’ and these MUST be downgraded to match OpenSuse 42.3.
Keeping these packages from being updated and maintaining them at these levels ARE a must–otherwise, MS SQL Server breaks again. (Been there and done that too!)
As for the paths, I kept things simple for others–these can be changed to match your environments.
Also, my database environments exist apart from the User and System paths and are segmented into a designated areas comprised on two 4Tb partitions that will house Oracle 12c, MS SQL Server 2017, PostgreSQL 10, and Neo4j 3.5 databases. As such, one partition named ‘data’ is where I installed PowerShell (i.e. /data/microsoft/powershell/) and is also where MS SQL Server and Neo4j databases exist as well.
I still have a lot of work to do…the data migrations will be fun…and hopefully boring!
I wonder how it would run on Docker (container). Does any of you have any experience or what would your expectation be?
At the moment I run SQL on a Windows VMs on KVM/QEMu hosts but I’m looking for better storage-performance and I expect to get that running SQL directly on Linux. But it seems MS’s SQL Linux support is rather half-hearted especially for suse. I see they have updated their support for RHEL (8.3) and Ubuntu (20.04) but still stock on suse ver. 12 :\ (who to blame MS or SLES?)
But maybe running it on Docker + openSUSE 15.3 is the way to go.
Would love to hear your thoughts on the matter.
I will spin up my own test-installation when I get a moment to spare.