i would like to know, based on what rpm packages upgrade i can upgrade my RHEL version 5.11 to 6.x
We can't use re-installation of RHEL 6.x, so wanted an option(s) to upgrade to RHEL 6.x from 5.x by upgrading all needful packages.
By upgrading kernal or core rhel release rpm, can we upgrade to latest?
Please let me know details. Thank you.
In place upgrades between 4, 5, and 6 are not supported by RedHat and you risk impacting the support that you pay for by doing so. The only supported upgrade path is from 6 to 7. The expectation is that an upgrade path will continue in future releases.
You state that you cannot re-install but don't state why. Is it because the criticality of the system or is it because of the configuration of the application? I'm guessing the latter and that the system is not all that critical (because otherwise you wouldn't want to impact your support agreement). With that said, there is a way to upgrade and the procedure is provided by RedHat but, again, it is not supported by them.
The link is: In place upgrade
Related
Postgresql website says "A dump/restore is not required for those running 14.X." (https://www.postgresql.org/docs/14/release-14-2.html#id-1.11.6.5.4)
Do I still need to use pg_upgrade or there is any other way to upgrade?
You only need to update the binaries using Ubuntu's package manager and restart Postgres (apt update then apt install postgresql-14)
pg_upgrade is only needed to upgrade between major versions (e.g. from 13 to 14 or from 14 to 15). Upgrading 14.1 to 14.2 is a minor version upgrade.
As per the docs:
Minor releases never change the internal storage format and are always compatible with earlier and later minor releases of the same major version number.
You are moving from 14.1 to 14.2 so this applies to your situation. That means you can just upgrade the binaries (so usually apt-get update && apt-get upgrade assuming you are using a repo with the latest release) and restart the service. However, it is worth reviewing the release notes particularly:
some bugs have been found that may have resulted in corrupted indexes, as explained in the first two changelog entries. If any of those cases apply to you, it's recommended to reindex possibly-affected indexes after updating.
I have a quick question related to "Kubespray".
Does "Kubespray" support CentOS 8?
I wanted to deploy "Kubespray" on "CentOS" and I came to know that the CentOS 8 has Kernel version 4.18 and If I can use "CentOS 8" for "Kubernetes" deployment, maybe I can get rid of the "c-group" issue which we are currently facing for all the CentOS distribution which has Kernal Version less than 4.18.
Thanks in Advance.
According to the official documentation Kubesprawy provides support for CentOS/RHEL 7 only. The problem is that:
Installing Kubespray on a RHEL8 systems does not work since the
default Python version is 3.6 and thus python3-libselinux should be
installed instead of libselinux-python. Even that python2 is still
available, the libselinux-python package is not.
I hope it helps.
I learn that RHEL and Centos has the exact same source code. So my question here is if one application built for RHEL 6.4, could we just install and make it running on Centos 6.4 without any update?
And another question is RHEL and Centos will always use the same version number for the same source code, right?
Yes, software built on RHEL 6.4 should work as-is on CentOS 6.4 (assuming you don't depend on one of the relatively few RHEL-specific details, mostly to do with branding).
CentOS, except where necessary, uses upstream RHEL sources unmodified. When they need to modify a package they indicate that in the release notes and in the release field of the RPM in question.
I used pkg list entire command , and i got the output for version column as follows :
0.5.11-0.175.1.0.0.24.2.
How to find the SRU from this?
Can we upgrade/ downgrade to a particular SRU ?
SRU is an abbreviation for Support Repository Update, installing new package versions from the support repo for that OS, much like installing a patch cluster for older Solaris releases.
The various fields in the version is explained in Oracle Solaris Package Versioning.
Oracle only makes SRUs available to customers with support contracts - if you have a support contract you can read more about SRU's in the Oracle Support Knowledgebase at Solaris 11 Support Repositories Explained, and see what fixes are available in each SRU for Solaris 11.1 and Solaris 11.2.
If you run 'pkg info entire' it will show the SRU name in human readable format also (if you have installed from the support repo - otherwise it shows the Release info). The 4th digit in 0.175.1.0.0.24.2 is the SRU number
In the example above it is the base Solaris 11.1 release - no SRU has been installed yet.
If an SRU had been installed on top of that you'd get a version like 0.5.11-0.175.1.21.4.1 (aka Oracle Solaris 11.1 SRU21.4.1)
You can easily upgrade to an SRU but you can't downgrade unless you have an older Boot Environment (BE) from which to upgrade to the SRU you want.
I want to upgrade database postgresql from version 8.3 to 9.0 on Jira application.
Which RPM should be used to work with Suse SLES10.3 64bit?
How to install Postgresql 9.0 in parallel to Postgresql 8.1?
The best bet to find packages for SUSE distributions is the openSUSE Build Service. The direct links there are a bit of a pain, so please look for yourself.
Parallel installation of multiple major PostgreSQL versions is not yet possible using SUSE RPMs. If you need to do that, you will probably need to build from source.