There is elevate tool that allows you to upgrade from CentOS 7.9 to AlmaLinuŃ… 8.x (the latest 8.x)
https://wiki.almalinux.org/elevate/ELevate-quickstart-guide.html
While for various reasons I need to upgrade to a specific version of AlmaLinux (not the latest one) - i.e. to 8.3. Is it possible?
It seems there is the following option:
leapp preupgrade --target <target_os_version>
Described here:
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/upgrading_from_rhel_7_to_rhel_8/reviewing-the-pre-upgrade-report_upgrading-from-rhel-7-to-rhel-8
Related
I'm trying to develop .NET Core in openSuse. I did install the SDK and everything in tutorials. Now, when I try to run dotnet new console command, I get this error:
No usable version of the libssl was found
Aborted (core dumped)
I found this answer: (.NET Core 2.1 SDK Linux x64 No usable version of the libssl was found), but didn't get what should I do to solve problem. They seems are deep-linuxer (which I'm not, I'm just trying to learn linux). Have any idea how to run the command?
UPDATE: System info:
openSUSE Leap 15.0
Kernel Version 4.12.14-lp150.12.22-default
OS Type:64-bit
I was having the same problem running sqlpackage on Ubuntu 20.04 while dotnet was working regularly.
dotnet is distributed through apt as well as sqlserver, but for some reasons sqlpackage is instead distributed via zip here (https://learn.microsoft.com/en-us/sql/tools/sqlpackage-download?view=sql-server-ver15) and is still affected by missing libssl1.0.
Solved with
wget http://security.ubuntu.com/ubuntu/pool/main/o/openssl1.0/libssl1.0.0_1.0.2n-1ubuntu5.6_amd64.deb
sudo dpkg -i libssl1.0.0_1.0.2n-1ubuntu5.6_amd64.deb
Can you install the libopenssl1_0_0 packages? .NET Core should pick it up and use it.
A slightly longer explanation for anyone who is curious:
OpenSSL is one of the most common cryptographic libraries used on Linux. It has multiple versions. Version 1.0 is kind of old, but heavily used. 1.1 is the newer version that was (relatively) recently released. 1.0 and 1.1 are not compatible. An application that expects 1.0 can not build against 1.1, nor run against it.
.NET Core 2.1, and all earlier versions only support OpenSSL 1.0.
Many Linux distributions are starting to make OpenSSL 1.1 the new default. But most of them still have a package for 1.0. So you just need to find and install that. On Fedora it's compat-openssl10. For openSuSE, it's libopenssl1_0_0. Then .NET Core will find it, pick it up and use it automatically.
Edit: As of March 2019, this shouldn't be required. We have updated .NET Core 2.1 and later to pick up and work with either OpenSSL 1.1 or 1.0 (whatever is available). So this problem should no longer happen with recent releases of .NET Core.
Ubuntu 22.04
wget http://security.ubuntu.com/ubuntu/pool/main/o/openssl1.0/libssl1.0.0_1.0.2n-1ubuntu5_amd64.deb
sudo dpkg -i libssl1.0.0_1.0.2n-1ubuntu5_amd64.deb
Still get this on Fedora 30 (with compat-openssl10 installed) when using the sqlpackage tool (https://learn.microsoft.com/en-us/sql/tools/sqlpackage-download?view=sql-server-2017).
$ dotnet --info
.NET Core SDK (reflecting any global.json):
Version: 2.2.203
Commit: e5bab63eca
Runtime Environment:
OS Name: fedora
OS Version: 30
OS Platform: Linux
RID: linux-x64
Base Path: /usr/share/dotnet/sdk/2.2.203/
Host (useful for support):
Version: 2.2.4
Commit: f95848e524
.NET Core SDKs installed:
2.2.203 [/usr/share/dotnet/sdk]
.NET Core runtimes installed:
Microsoft.AspNetCore.All 2.2.4 [/usr/share/dotnet/shared/Microsoft.AspNetCore.All]
Microsoft.AspNetCore.App 2.2.4 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.NETCore.App 2.2.4 [/usr/share/dotnet/shared/Microsoft.NETCore.App]
To install additional .NET Core runtimes or SDKs:
https://aka.ms/dotnet-download
Dotnet works fine on it's own. But running sqlpackage does not work:
$ sqlpackage /tsn:localhost /tu:xx /tp:yyy /A:Import /tdn:mydb /sf:mydb.bacpac
Importing to database 'mydb' on server 'localhost'.
No usable version of the libssl was found
Aborted (core dumped)
I looking up "No usable version of the libssl was found" in github. You'll find many variants of the .Net core security library in C, each varient has very specific dll loads for exact libssl libraries and everything has to match perfect despite it being named differently in many.
For raspberry pi / debian it wants libssl 1.0.2 exactly, nothing else.
sudo apt-get install libssl1.0.2
should do the trick for the pi! I can't speak to other variants.
At present we are on Apache/2.2.15 (UNIX) version. To fix the vulnerabilities we are suggested to upgrade to new version. I got new version from online using "wget" command and followed steps mentioned on this link http://httpd.apache.org/docs/2.2/install.html#download.
Once I am done, checked version using httpd -v. It gives me old version Apache/2.2.15 (UNIX). If I check using /usr/local/apache2/bin/httpd - v. It gives me new version. Did I successfully upgraded the version or not? If not what should I do?
I tried "yum install httpd" - It says "Nothing to do".
You now have two versions of Apache installed. You have the one installed with the system package manager (yum) in /usr/sbin/httpd. You have one installed manually in /usr/local/apache2/....
Which one you get will be determined entirely by which path you use.
In general, mixing system-managed packages with manually installed packages is a recipe for trouble. If you want to stick with the newer version in /usr/local, you should remove the system version, and realize that you will lose some manageability. For example, you will no longer be able to use yum install ... to install new Apache modules, and you will not be able to verify the installed files using tools like rpmverify.
If your distribution currently has Apache 2.2.x, that suggests your distribution is fairly old. For example, RHEL (and CentOS) 7 (and similar variants) have version 2.4.6 packaged, so you may want to update your host to something newer than whatever you're running now.
Yes, its successfully upgraded as per the screenshot.
httpd 2.2.15 is the version with RHEL 6 repository, here HTTPD_HOME is /etc/httpd (Highest version provided for HTTPD via RPM RHEL 6 is 2.2.15)
httpd 2.4.6 is the version with EPEL-HTTPD24 repository, here HTTPD_HOME is /usr/local/apache2/
We have gitlab ver 7.13.1 on linux red hat 6.3 vm . We need the feature of reverting merge request . To which version should we upgrade our gitlab ?
Regards, Nir
The latest, there are lots of security issues that need to be addresses in even the newer versions.
The latest would be best.
But there are a few caveats to look for when upgrading from pre 8.0 :
If you're using Gitlab CI upgrade to 8.0 first (see this)
If you're using Gilab GEO then upgrade to 8.17 (see this)
If you're using both, upgrade to 8.0 first, then to 8.17
Finally upgrade to 9.0.2 (latest version at this date).
I need to use QOpenglWidget and it is available for qt 5.4 and higher. When I run qmake --version it shows that I am using version 5.2.1. I tired download qt 5.7 but nothing changes. How can I upgrade the version of the qt on this machine to 5.4 or higher ?
My version of ubuntu is 14.04 and I don't have the permission to upgrade it. What I did was to change all the subdirectories with cmake-gui to find the proper cmake(QT5_DIR, ...) files in Qt5.7.0. Thanks for the comments.
It is possible to upgrade easily from 6.2 > the latest stable version? Seems like you cannot skip versions, and have to upgrade as 6.3 > 6.4 > 6.5 etc..
This seems like a massive task!
We considered installing a separate VM with the latest version on running alongside, and cloning repo > new repo.
You can certainly skip most versions. Though there are only documented steps for certain jumps. You should be fine in your case though.
For source installs: https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/update/6.x-or-7.x-to-7.14.md
Once you have updated to the 7.14 you can switch to using the omnibus packages to make upgrading easier going forward:
https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/doc/update/README.md#upgrading-from-a-non-omnibus-installation-to-an-omnibus-installation
And then you will be able to upgrade to the latest stable which is 8.0.
Alternatively if you want to stick with the source install you can do the following after getting to 7.14: https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/update/7.14-to-8.0.md