Install specific version of cPanel

[christec]

Under the Advanced Options Pre-Installation section of the Installation Guide a build type can be selected by creating the file /etc/cpupdate.config which would contain the type:
* CPANEL=stable
* CPANEL=release
* CPANEL=current
* CPANEL=edge

Is it possible to specify a specific version and/or release? (e.g. 11.24.4-RELEASE_36167)

[cPanelDavidG]

Originally Posted by christec

Under the Advanced Options Pre-Installation section of the Installation Guide a build type can be selected by creating the file /etc/cpupdate.config which would contain the type:
* CPANEL=stable
* CPANEL=release
* CPANEL=current
* CPANEL=edge

Is it possible to specify a specific version and/or release? (e.g. 11.24.4-RELEASE_36167)

We only make the latest versions of each build available for installation/download. Old builds are unavailable for installation/download.

[hodfords]

It would be good if you could make old releases available as many enterprise businesses will generally standardise service and protocols, will have thoroughly tested a set of services and solutions on one particular release and signed off on the test report -- if tests need to be conducted every quarter as new releases become available then it makes it very difficult resource-wise for any business to choose Cpanel. Cpanel will thus have troubles targeting the enterprise grade service providers.

[cPanelDavidG]

Originally Posted by hodfords

It would be good if you could make old releases available as many enterprise businesses will generally standardise service and protocols, will have thoroughly tested a set of services and solutions on one particular release and signed off on the test report -- if tests need to be conducted every quarter as new releases become available then it makes it very difficult resource-wise for any business to choose Cpanel. Cpanel will thus have troubles targeting the enterprise grade service providers.

Actually, if you're looking for a build that doesn't change for periods of approximately half a year, you may wish to consider the STABLE build. The STABLE build usually only changes once for each major release, which recently has been every other quarter. STABLE is most commonly used by our Enterprise-Scale customers who want stability in the software's feature set.

To test the software before new updates reach STABLE as these new major releases propagate, you are welcome to use our EDGE, CURRENT or RELEASE builds. EDGE always has the newest technologies, but is minimally tested and is only intended for testing and development purposes (so you know what's coming down the pipeline). CURRENT is less frequently updated than EDGE and RELEASE even less so (as it is closer to STABLE in feature propagation). Features propagate from EDGE to CURRENT then RELEASE and eventually STABLE.

If the licensing cost of running a test server, to test our software and how it interacts with your environment before propagating updates to your server fleet, is an issue then email me at sales@cpanel.net with ATTN: DavidG in the subject line as we may be able to work something out.

[hodfords]

Thank you for getting back so quick. We are pretty familiar with WHM / CPanel and I think the product is mature enough for old releases to be made available.

The customer should be able to choose when they decide to upgrade their platforms and not have this dicatated by Cpanel's release schedules.

In the interest of expedience and reliability, a company that manages a large number of servers will try to standardise and automate all installation / maintenance / upgrade processes. Customised programming / protocols / one-click installation scripts will be developed so that when a new server needs to be setup there is a single script that can install all the necessary software to make the server live in the minimum amount of the time with guaranteed functionality. This not only reduces the resources for highly-skilled personnel but also reduces human error. Standardisation is the only a company can grow without limits.

If each time a new Cpanel release becomes available new scripts need to be developed and tested - then logistically it doesn't make sense for any serious business. Moreover - if a moderate operation manages ~100 servers and there were a 100 servers on ver. 11.11 and then 5 using 11.20 and another 10 on 11.30 - it makes customised installation / maintenance / upgrade scripts remarkably difficult to develop and would be much harder then to have all 100 odd servers using one single release.

This is why php, mysql, and other softwares make available past releases - simply to afford scalability and reproducability for end-users.

[cPanelDavidG]

Originally Posted by hodfords

Thank you for getting back so quick. We are pretty familiar with WHM / CPanel and I think the product is mature enough for old releases to be made available.

The customer should be able to choose when they decide to upgrade their platforms and not have this dicatated by Cpanel's release schedules.

We offer this choice in WHM. Just go to the Update Config. screen in WHM and set your updates to "Never" to prevent updates from automatically being installed (even if another script wants to update cPanel). This allows you to perform any tests you need to perform before proceeding to upgrade.

Originally Posted by hodfords

In the interest of expedience and reliability, a company that manages a large number of servers will try to standardise and automate all installation / maintenance / upgrade processes. Customised programming / protocols / one-click installation scripts will be developed so that when a new server needs to be setup there is a single script that can install all the necessary software to make the server live in the minimum amount of the time with guaranteed functionality. This not only reduces the resources for highly-skilled personnel but also reduces human error. Standardisation is the only a company can grow without limits.

Agreed. We have customers that deploy customizations to thousands of cPanel/WHM servers and they're able to do so because they maintain control over when updates are installed to maintain that needed standardization.

You may be interested in also reviewing our new documentation about how to copy settings among servers as part of the installation process. This will help you to more easily maintain standardization as you deploy new cPanel/WHM servers in your facility. You can find this information in our Apache pre-configuration guide and Advanced Installation guide posted at:

cPanel Installation Guide

Originally Posted by hodfords

If each time a new Cpanel release becomes available new scripts need to be developed and tested - then logistically it doesn't make sense for any serious business. Moreover - if a moderate operation manages ~100 servers and there were a 100 servers on ver. 11.11 and then 5 using 11.20 and another 10 on 11.30 - it makes customised installation / maintenance / upgrade scripts remarkably difficult to develop and would be much harder then to have all 100 odd servers using one single release.

If your scripts are relying on our APIs, hooks and other supported means of product integration, they shouldn't be breaking between cPanel updates. If they are, please let me know as that is something we would need to look into.

If your software is still relying on old cPanel 10 (and earlier) methods of passing parameters to URLs and reading HTML, both of which will likely break between cPanel updates, I'll be glad to work with your development team in migrating to APIs hooks etc. which work much more reliably between cPanel updates.

If you are customizing the appearance of the software, I'll be glad to work with your design team to migrate from using themes to the more durable method of using styles instead. Custom themes are a headache compared to custom styles and I'll be glad to work with your staff on this.

While the offer of working out what can be done for a test server remains, I think a good long-term strategy would be to work together so we can avoid the need for your staff to perpetually spend time between each major cPanel update re-implementing your customizations.

Anyone wanting this assistance can just email sales@cpanel.net

[Spiral]

Originally Posted by hodfords

Customised programming / protocols / one-click installation scripts will be developed so that when a new server needs to be setup there is a single script that can install all the necessary software to make the server live in the minimum amount of the time with guaranteed functionality. This not only reduces the resources for highly-skilled personnel but also reduces human error. Standardisation is the only a company can grow without limits.

If each time a new Cpanel release becomes available new scripts need to be developed and tested - then logistically it doesn't make sense for any serious business. Moreover - if a moderate operation manages ~100 servers and there were a 100 servers on ver. 11.11 and then 5 using 11.20 and another 10 on 11.30 - it makes customised installation / maintenance / upgrade scripts remarkably difficult to develop and would be much harder then to have all 100 odd servers using one single release.

This is why php, mysql, and other softwares make available past releases - simply to afford scalability and reproducibility for end-users.

That is not really the reason for access to outdated old releases
and you seem to be under a few misconceptions if you think you need
to rewrite deployment and automation scripts anytime a new version
of Cpanel is released. Though internal components have changed
significantly over the years, the amount of changes in terms of hooks,
and API calls for scripts to connect 3rd party automation has been
very minimal in changes are rarely needs any updates and that goes
even more so in recent years where things remain more standardized
and processes and functions remain unbroken between releases.

None of your scripts should really need any updates unless you are
working with scripts that are from the earlier days of Cpanel before
much of these methods were standardized which in that case, I
would look at revising your automation scripts for an entirely
different set of reasons.

As I said, 3rd party script changes for automated server deployments
would need very little changes beyond minor tweaks now and then.
Anything more substantial is actually quite rare and I can say that
first hand and we even use EDGE in our server deployments too
where you could expect things to be the most unstable and changed!


Point in fact