Page tree
Skip to end of metadata
Go to start of metadata

Long-Term Support

cPanel & WHM version 11.30 officially introduces the Long-Term Support initiative.

Changes to the /scripts directory

In cPanel & WHM version 11.30, we changed the way cPanel & WHM uses the /scripts directory:

  • New cPanel & WHM installations will not install /scripts, but will install a symlink  in /usr/local/cpanel/scripts.
  • Existing installations that upgrade to cPanel & WHM version 11.30 will have /scripts copied to /usr/local/cpanel/scripts.
    • Excludes will be honored during the move.
    • /scripts will be moved to /scripts.$timestamp as a backup ( $timestamp represents a string based on the time of the backup).
    • /scripts will be symlinked to /usr/local/cpanel/scripts

After you upgrade to cPanel & WHM version 11.30, examine the contents of /scripts.$timestamp. Once you have verified that the directory contains no necessary files, delete it with the rm -rf /scripts.* command.

11.30 upgrade cron jobs modification

When you upgrade to cPanel & WHM version 11.30, it will modify existing cron jobs. However, the modification will only affect command paths that reside in the /scripts directory.

For example, 39 3 * * * /scripts/upcp --cron would change to 39 3 * * * /usr/local/cpanel/scripts/upcp --cron.

The modification should not impact the scheduled time of cron jobs.

Downgrade to version 11.28

Downgrades to releases prior to cPanel & WHM version 11.30 are no longer possible. cPanel & WHM 11.28 is no longer publicly available. The downgrade utility, /usr/local/cpanel/scripts/downgrade_cpanel, was deactivated in 11.30.1.4. Use of the utility from earlier 11.30 releases will result in a server downgrade to the cPanel & WHM 11.30 release version in the STABLE tier.


Changes to RPM updates

In cPanel & WHM version 11.30, we have made some changes to the ways in which cPanel-managed RPM updates are handled.

Prior to cPanel & WHM version 11.30, cPanel-managed RPMs were updated based on your tier (EDGE, CURRENT, RELEASE or STABLE) and independent settings.

Now, cPanel-managed RPMs are specific to versions of cPanel. This means that your cPanel-managed RPMs update only when cPanel & WHM updates.

Changes to the /etc/cpupdate.conf file

Previous format (version 11.28 and earlier)

Formerly, the CPANEL directive in /etc/cpupdate.conf determined:

  • Which tier the server would run (edge, current, release, or stable), and
  • Whether the server would automatically update via a daily cron job running the update script ( /usr/local/cpanel/scripts/upcp).

For example, the entry: CPANEL=manual-stable meant:

  • cPanel & WHM would get updates from the stable tier, and
  • cPanel & WHM would update only when the server administrator executed /usr/local/cpanel/scripts/upcp on the command line.


New format

In cPanel & WHM version 11.30, this information has been split into two directives:

  • CPANEL — Determines the update tier.
    • This directive accepts the following values:
      • edge
      • current
      • release
      • stable
  • UPDATES(New) Determines whether the update will occur automatically (daily), manually, or never.
    • This directive accepts the following values:


ValueDescription
dailycPanel & WHM can update via any of the following:
1) a daily /usr/local/cpanel/scripts/upcp cron job
2) the administrator running /usr/local/cpanel/scripts/upcp on the command line
3) the administrator using the WHM Update Preferences screen
manualcPanel & WHM can update via any of the following:
1) the administrator running /usr/local/cpanel/scripts/upcp on the command line
2) the administrator using the WHM Update Preferences screen
nevercPanel & WHM cannot update.


Configuration for new installations of cPanel & WHM

When cPanel & WHM version 11.30 installs on a new server, it will default to automatic daily updates for the release tier:

  • CPANEL=release
  • UPDATES=daily


Configuration for existing installations of cPanel & WHM (updating from a previous version)

For existing installations, if no UPDATES field appears in /etc/cpupdate.conf, cPanel & WHM will update /etc/cpupdate.conf as follows:


If the old CPANEL value is set to...The new CPANEL value will become...The new UPDATES value will become...
missingreleasedaily
manualstablemanual
manual-$tier$tiermanual
dnsonlystabledaily
dnsonly-betacurrentdaily
edgeedgemanual
betaedgemanual
nightlyedgemanual
neverstablenever


  • $tier represents the cPanel & WHM release tier (edge, current, release, or stable).

Note:

You should check the contents of cpupdate.conf after you install cPanel & WHM version 11.30. The upgrade may alter the file's contents.



Remove the x and x2 themes

As of cPanel & WHM version 11.30, we will no longer support the x and x2 themes. When you update to cPanel & WHM version 11.30, the themes and the code that handles those themes will remain on your server. However, new installations will no longer include the x and x2 themes.


Deprecated scripts

In cPanel & WHM version 11.30, we recommend that you discontinue the use of certain scripts:

  • Do not directly call /usr/local/cpanel/scripts/updatenow to update your server. Instead, run /usr/local/cpanel/scripts/upcp You can also use /usr/local/cpanel/scripts/upcp --force to make sure cPanel & WHM are re-synced even if the version stays the same.


Removal of the cPanel Rollback System

In cPanel & WHM version 11.30, we removed all functionality for the deprecated cPanel Rollback system. The following utilities are removed when you upgrade:

  • The scripts /usr/local/cpanel/bin/cprollback and /usr/local/cpanel/bin/genrollback, which are no longer used.
  • Neither /scripts/cpanel-rollback nor /scripts/genrollback is distributed with new installations of cPanel.

The following cPanel Rollback items are not removed by the upgrade:

  • The /usr/local/cpanel-rollback directory
  • The /var/cpanel/genrollback directory
  • The /var/cpanel/rollback.conf file

We suggest that you review and remove the cPanel Rollback items that remain on your server.

Added RHEL and CentOS 6 support

As of cPanel & WHM 11.30, we officially support RHEL 6.x and CentOS 6.x.

cPanel & WHM 11.30 and Red Hat Enterprise Linux

Red Hat Network registration is required

Before you install cPanel & WHM on a Red Hat Enterprise Linux server, you must register the server with the Red Hat Network with the  rhn_register command.

If you do not register the server before you install cPanel & WHM, then the installation will fail.

The repository rhel-optional is required on Red Hat version 6

Before you install cPanel & WHM on a Red Hat 6 server, you must subscribe the server to the Server Optional channel (via http://rhn.redhat.com).

If you do not subscribe the server to this channel, which installs the rhel-optional repository, then the cPanel & WHM installation will fail.


The mbox format is not supported with Red Hat 6 and CentOS 6

cPanel & WHM 11.30 does not support mbox on Red Hat 6 or CentOS 6 servers.

Warning:

In cPanel & WHM 11.32, the mbox format will not be supported on any operating system.


Changed default MySQL version

MySQL 5.1 is now the default version of MySQL for new installs of cPanel & WHM.

Legacy operating system freeze

In accordance with our EOL policy, cPanel will no longer install on operating systems we do not support. You can find the current list of operating systems and their corresponding end of life dates at our System Requirements page.


Operating SystemcPanel End of Life Date
CentOS 3.x, RedHat Enterprise Linux 3.xApril 30, 2011
CentOS 4.x, RedHat Enterprise Linux 4.xAugust 31, 2012
CentOS 5.x, RedHat Enterprise Linux 5.xSeptember 30, 2014
FreeBSD 7.3September 30, 2012
FreeBSD 8.0May 31, 2011


What happens when an operating system reaches EOL?

An OS that reaches End of Life will continue to function. An existing cPanel & WHM installation on a system that reaches EOL will continue to function.

However, you will be unable to perform the following tasks on an operating system that has reached its EOL:

  • Perform a fresh installation of cPanel & WHM. New installations are prevented once the OS reaches the end of its lifetime
  • Upgrade to a newer version of cPanel & WHM. Upgrades are prevented starting at EOL.
  • Obtain fixes — security or otherwise — from cPanel. Fixes will not be available following EOL.

Making cPanel-installed files immutable prevents update

If you wish to prevent cPanel & WHM from updating a file, do not make the file immutable. Instead, add an entry for the file to the /etc/cpanelsync.exclude file.

We have added a check to the maintenance process that will place an entry in the update log (/var/cpanel/updatelogs) when immutable files on the server prevent an update of cPanel & WHM.

Preventing cPanel & WHM from changing a file's permissions during update

If you wish to prevent a change of the files permissions by your cPanel & WHM update, enter the filename into the cpanelsync.no_chmod file.

New 4-segment cPanel & WHM version numbers

As of cPanel & WHM version 11.30, cPanel & WHM version numbers will consist of four segments:

  • The first and second segments still represent the parent and major values. (These are unchanged.)
  • The third segment no longer consists of an auto-incremented build ID number. It now represents a milestone‚Äö√Ñ√Æa group of changes to cPanel & WHM that may include new features and bug fixes.
  • The fourth segment is the auto-incrementing build ID. This value is relative to the milestone. (When the milestone increments, the build ID will reset to 0.)

For example, in version 11.29.1.4:

  • "11" is the parent number.
  • "29" is the major version number.
  • "1" is the cPanel & WHM milestone.
  • "4" is the build of the milestone.

This version number would be reported in the cPanel & WHM user interfaces as "11.29.1 (build 4)."

Backwards compatibility for version numbers

cPanel & WHM version 11.30 will also provide backwards-compatible renditions of the new cPanel & WHM version numbers. This should help ease the transition for third-party applications that integrate with cPanel & WHM.

However, since these renditions will be limited, we strongly encourage third-party developers to update their products for compatibility with the new version format.


Bug fixes

When we discover critical issues after we publish a version of cPanel & WHM, we will fix them and backport the fix.

In some circumstances, we may need to rebuild all currently published milestones. However, if only one or two milestones are affected, we will rebuild those milestones only.

For example, consider a scenario in which these are the most recently published tiers of cPanel & WHM:


EDGE11.30.1.5
CURRENT1.30.1.5
RELEASE11.30.0.8
STABLE11.30.0.8

If we found a critical issue that affected both the 11.30.0 and 11.30.1 milestone releases (such as a 0-day root exploit), then we would backport the fix to, and republish, 11.30.1 and 11.30.0. By contrast, an issue that only impacts the 11.30.1 release would result in a new build of 11.30.1 only.

We will queue non-critical issues for delivery in a future milestone build.

Changed cPanel DNSOnly versioning and release tree

Formerly, cPanel DNSOnly™ was a separate build from cPanel & WHM. New versions of DNSOnly were not released on the same schedule as cPanel & WHM.

As of cPanel & WHM version 11.30, we will release versions of cPanel DNSOnly on the same schedule as cPanel & WHM. This means that server owners running DNSOnly can update it at the same time they update their cPanel & WHM servers.

We have also changed the names of the DNSOnly release tiers. They are now the same as cPanel & WHM's release tier names. ( EDGE, CURRENT, RELEASE, STABLE)

If you use DNSOnly beta, you will be reset to CURRENT. If you are using DNSOnly, you will be reset to STABLE.

Removed 2 legacy language tags

As of cPanel & WHM 11.30, the following language tags are no longer available:

  • INDXFullVersion
  • INDXRevision

As a result, third-party themes that use these language tags might encounter display issues. To avoid display issues, theme developers should update relevant third-party themes to remove references to the unavailable language tags.

Removed languages from the cPanel interface

Three languages were not fully implemented in cPanel. As a result, we have removed these languages as of cPanel & WHM version 11.30:

  • Italian
  • Japanese
  • Bengali

GDBM locale files changed to CDB format

In previous versions, cPanel & WHM stored locale data in GDBM format. As of cPanel & WHM version 11.30, this data is stored in CDB format.

cPanel & WHM will convert the GDBM files in /var/cpanel/locale to CDB files when you upgrade the upgrade to cPanel & WHM version 11.30.

This change makes the following scripts obsolete:

  • scripts/dumbpgdbm
  • scripts/comparegdbm

It also adds two new scripts:

  • /usr/local/cpanel/scripts/comparecdb — Compares the contents of 2 CDB files
  • /usr/local/cpanel/scripts/dumpcdb — Displays the contents of a CDB file

All other utilities and scripts will work without change, since they modify the raw YAML files rather than the GDBM files.

Change to SQL Databases report within cPanel interface

The MAXSQL entry in a cPanel account's configuration (cpuser) file limits the number of databases that a user can create.

In cPanel & WHM, if only MySQL databases are installed, the MAXSQL value represents the total number of MySQL databases available for an account. If the MAXSQL value is 10, the user can create 10 MySQL databases

However, if both MySQL and PostgreSQL databases are installed, the MAXSQL value is applied—separately—to the total number of MySQL databases and to the total number of PostgreSQL databases available for an account. In this case, if the MAXSQL value is 10, the user can create:

  • 10 MySQL databases
  • 10 PostgreSQL databases

In previous versions of cPanel & WHM, the SQL Databases section of the Stats display only compared the number of MySQL databases created to the total number of MySQL databases available for an account. The display ignored installed PostgreSQL databases. For instance,

  • if the MAXSQL value was 10 and
  • the account user created 4 MySQL databases and 9 PostgreSQL databases,
  • the interface would report: 4/10.

As of cPanel & WHM 11.30, if PostgreSQL databases are installed, the SQL Databases section of the Stats display compares the combined number of MySQL and PostgreSQL databases created to the total number of MySQL and PostgreSQL databases available for an account. For instance,

  • if the MAXSQL value is 10 and
  • the account user creates 4 MySQL databases and 9 PostgreSQL databases,
  • the interface will report: 13/20.

Improvements to chkservd

chkservd is the process that cPanel & WHM uses to determine whether a process is online and needs to be restarted.

In cPanel & WHM version 11.30, we have improved chkservd 's reliability in certain situations.

For example, chkservd will be more precise in not monitoring services that have been voluntarily shut down temporarily, while continuing to monitor services that are still running. This will result in fewer false warnings about services failing.

Changes to the Cpanel::Version module

We have updated the Cpanel::Version module. Developers of themes and applications that interact with cPanel should note that the following calls are now deprecated:

  • getrevision
  • gettree
  • getbuild
  • getthemerevisions (This has been replaced by get_version_full; see below.)
  • getversiononly
  • getversion

To determine the release tier that is on your server, run Cpanel::Update::Config::get_tier. However, you should be aware that the tier only signifies how much testing that instance of cPanel & WHM has received. The tier, by itself, no longer signifies a change in how cPanel & WHM functions. All tiers for a given version receive exactly the same functionality.

To determine the version for your cPanel & WHM installation, run Cpanel::get_version_full. This will return the three-value version number (parent value, major value, and minor value).

If your custom code must work with cPanel both before and after cPanel & WHM version 11.30, check to see whether $cpanel::Version::VERSION is greater than four values.

The logic for Cpanel::Version::compare() has moved into a standalone module. As a result, you should use Cpanel::Version::Compare::compare() instead.


Added support for MySQL TRIGGER and VIEW privileges

As of cPanel & WHM version 11.30 we support for the MySQL TRIGGER and VIEW privileges.

  • Systems that use MySQL 5.0 and higher can use the VIEW privilege. This privilege will grant the database user the CREATE VIEW and SHOW VIEW MySQL privileges.
  • When you use MySQL 5.0, the SUPER privilege is required for the TRIGGER privilege. Due to this caveat, we will not support the TRIGGER privilege on systems with MySQL 5.0.
  • Systems using MySQL 5.1 and higher can enable and use the TRIGGER privilege. However, this privilege is not available if binary logging is enabled for the MySQL service.

Neither TRIGGER nor VIEW is available to systems using MySQL 4.0 or 4.1.

Resources:


Added Auto Responders start and stop time options

As of cPanel & WHM 11.30, the cPanel Auto Responders feature will include start and stop time options.

  • When users select a start time for an auto responder, they can choose to start the auto responder immediately, or set a custom time.
  • When users a stop time for an auto responder, they can choose to never stop the auto responder, or set a custom time.

Pluggable DNS clustering

In cPanel & WHM version 11.30, we added pluggable DNS clustering. This allows you to use a custom Perl module to integrate cPanel & WHM-managed DNS services with non-cPanel & WHM DNS services.

This experimental feature is still under development. We will publish full documentation for it at a later date.

Handling of the Roundcube database schema during Roundcube updates

cPanel & WHM has changed the way it handles the Roundcube database schema during updates. The Roundcube update process has changed in the following ways:

1. cPanel & WHM will prevent users from interacting with Roundcube during Roundcube updates.

2. The Roundcube update process will now back up the database, then update the database schema in place. This is a change from the previous process, which:

  1. Backed up, then dropped the database.
  2. Created a new database, with a new schema.
  3. Restored the data.

This change should result in significant improvements to data integrity.

3. The Roundcube update process now upgrades the individual SQLite databases with the /usr/local/cpanel/bin/update-roundcube-sqlite script. This is a change from the previous process, which did not upgrade the SQLite databases.

4. The /usr/local/cpanel/bin/update-roundcube script will only update the MySQL-configured Roundcube installation.

  • If you invoke the update-roundcube script and you have a SQLite-configured Roundcube installation, the script will fail and invoke update-roundcube-sqlite.
  • Likewise, if you invoke update-roundcube-sqlite and you have a MySQL-based implementation, the script will fail and invoke update-roundcube.

5. Roundcube requires InnoDB support. If InnoDB is disabled, Roundcube will not update.

Changes to new VPS installations

cPanel & WHM VPS Optimized no longer adds the skip-innodb parameter to the /etc/my.cnf file for new VPS installations.

This means that the InnoDB engine is no longer disabled by default on VPS systems.

  • No labels