Skip to main content

What are cPanel release tiers & How can we change that?

We are all at least generally familiar with the software development cycles, and different software developers use different release schedules according to the testing phase the software is in at the time. For example, some developers use an alpha, beta, release candidate (RC) type of release schedule, and each of these may have varying levels of releases.

The cPanel release schedule is very similar to the manner in which Linux distributions are released. cPanel updates in a variety of release tiers. Server administrators may then choose which release version is applicable to their system requirements.

The following are cPanel’s current release tiers:
###########################################
Stable
Release
Current
Edge
Long-term support

Each of the above cPanel release tiers represents various stages of the software development cycle. While the final decision to which release version to deploy is entirely up to the organizational decision-makers, including the system administrators, the selected version should be selected to meet the goals set for the server network and its assigned tasks. What function does each release tier serve?

While most of the cPanel release tiers include fully functioning software, the software contains varying features and stability. Please remember that software continues to evolve with the developers constantly tweaking features and adding functionality. Each release tier is at a specific level of testing in the development cycle. There are some advantages and some disadvantages to each tier.

Stable
------

The stable release tier includes cPanel at its most tested and verified stage. This release has been in service for some time and has been deployed on numerous systems and tested thoroughly. Updates to this release are not as frequent as the other tiers.

Release
-------

The release tier is the most recent release of cPanel. At this stage, the software has been well tested and it includes all of the features for the specific version. Release updates are more frequent than for the stable tier.

Current
-------

A current release may be considered by some as being in the RC stage of development. At this stage, the software lacks some of the features and functionality that is found in the release tier. It is also updated frequently.

Edge
----

The edge release tier contains software that has been subjected to very little testing, and many of its features are subject to further modification. At this stage of the product’s development, there will be very little public information presented. This is essentially a design and programming stage.

Long-term support
-----------------

Long-term support is the cPanel release tier for those sysadmins who do not wish to upgrade from one release to the next. This release tier will continue as long as cPanel supports the version. As an example of a long-term support tier, Microsoft® encountered users who chose to continue with Windows® XP® for as long as the company continued to support the software.

How can I change the cPanel’s current release tiers
###################################################

User Interface
--------------

WHM >> Home » Server Configuration » Update Preferences >> Select the appropriate Release Tier and click the save button.

From Backend.
------------

Execute the below command in the terminal and find which tier is currently installed.

# grep "^CPANEL=" /etc/cpupdate.conf
CPANEL=release

Change that to whatever you want either stable, current or edge.
cPanel & WHM would update only when the server administrator executed /usr/local/cpanel/scripts/upcp on the command line

# /scripts/upcp.

Done!!! now you check the same by grepping the /etc/cpupdate.conf file ..


Comments

Post a Comment

Popular posts from this blog

K8s External Secrets integration between AWS EKS and Secrets Manager(SM) using IAM Role.

What is K8s External Secrets and how it will make your life easier? Before saying about External Secrets we will say about k8s secrets and how it will work. In k8s secrets we will create key value pairs of the secrets and set this as either pod env variables or mount them as volumes to pods. For more details about k8s secrets you can check my blog http://jinojoseph.blogspot.com/2020/08/k8s-secrets-explained.html   So in this case if developers wants to change the ENV variables , then we have to edit the k8s manifest yaml file, then we have to apply the new files to the deployment. This is a tiresome process and also chances of applying to the wrong context is high if you have multiple k8s clusters for dev / stage and Prod deployments. So in-order to make this easy , we can add all the secrets that is needed in the deployment, in the AWS Secret Manager and with the help of External secrets we can fetch and create those secrets in the k8s cluster. So what is K8s external Secret? It i...
Post a Comment
Read more

Password reset too simplistic/systematic issue

Some time when we try to reset the password of our user in linux it will show as simple and systematic as below: BAD PASSWORD: it is too simplistic/systematic no matter how hard password you give it will show the same. Solution: ######### Check if your password is Ok with the below command, jino@ndz~$ echo 'D7y8HK#56r89lj&8*&^%&^%#56rlKJ!789l' | cracklib-check D7y8HK#56r89lj&8*&^%&^%#56rlKJ!789l: it is too simplistic/systematic Now Create a password with the below command : jino@ndz~$ echo $(tr -dc '[:graph:]' 7\xi%!W[y*S}g-H7W~gbEB4cv,9:E:K; You can see that this password will be ok with the cracklib-check. jino@ndz~$ echo '7\xi%!W[y*S}g-H7W~gbEB4cv,9:E:K;' | cracklib-check                 7\xi%!W[y*S}g-H7W~gbEB4cv,9:E:K;: OK Thats all, Thanks.
Post a Comment
Read more

Setting /etc/hosts entries during the initial deployment of an Application using k8s yaml file

Some times we have to enter specific hosts file entries to the container running inside the POD of a kubernetes deployment during the initial deployment stage itself. If these entries are not in place, the application env variables mentioned in the yaml file , as hostnames , will not resolve to the IP address and the application will not start properly. So to make sure the /etc/hosts file entries are already there after the spin up of the POD you can add the below entries in your yaml file. cat > api-deployment.yaml apiVersion: apps/v1 kind: Deployment metadata: spec:   template:     metadata:     spec:       volumes:       containers:       - image: registryserver.jinojoseph.com:5000/jinojosephimage:v1.13         lifecycle:           postStart:             exec:               command:...
Post a Comment
Read more