Documentation Home> AllDocumentationEditAttach

cPanel & WHM 11.30 Release Notes

Last updated August 1, 2011.

These Release Notes detail feature updates in cPanel & WHM version 11.30.

Long-Term Support

The 11.30 release of cPanel & WHM officially introduces the Long-Term Support initiative. Read more about cPanel & WHM Long-Term Support.

Changes to the /scripts directory

In version 11.30, cPanel & WHM will change the way it uses the /scripts directory:

  • New cPanel & WHM installations will not install /scripts, installing in its place a symlink to /usr/local/cpanel/scripts.
  • Existing installations upgrading to 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 upgrading to version 11.30, examine the contents of /scripts.$timestamp. Once you have verified that the directory contains no necessary files, delete it using the following command:

  • rm -rf /scripts.*

Cron jobs modification when upgrading to version 11.30

Upgrading to cPanel & WHM version 11.30 will modify existing cron jobs. However, the modification will only affect command paths residing in the /scripts directory.

For instance,

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.

Downgrading to version 11.28

Downgrades to releases prior to 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 the server "downgrading" to the 11.30 release version in the STABLE tier.

Changes to RPM updates

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

Prior to 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.

You can learn more by reading our RPM management system documentation.

Changes to /etc/cpupdate.conf

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 version 11.30, this information has been split into 2 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:

Value Description
daily cPanel & 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
manual cPanel & 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
never cPanel & 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...
missing release daily
manual stable manual
manual-$tier $tier manual
dnsonly stable daily
dnsonly-beta current daily
edge edge manual
beta edge manual
nightly edge manual
never stable never

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

  • Note: You should check the contents of cpupdate.conf after installing cPanel & WHM 11.30. The upgrade may alter the file's contents.

Removing the x and x2 themes

As of cPanel & WHM 11.30, we will no longer support the x and x2 themes. When you update to cPanel & WHM 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 version 11.30, we recommend that you discontinue use of certain scripts:

  • Directly calling /usr/local/cpanel/scripts/updatenow is not the correct way to update your server. Instead, you should run /usr/local/cpanel/scripts/upcp. Optionally, you can 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

cPanel & WHM version 11.30.0 removes all functionality for the deprecated cPanel Rollback system. The following utilities are removed during 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 these remaining cPanel Rollback items from your server.

Added RHEL and CentOS 6 support

As of cPanel & WHM 11.30, we will 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 (using the command rhn_register).

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.

ALERT! Warning: In the forthcoming 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 System cPanel End of Life Date
CentOS 3.x, RedHat Enterprise Linux 3.x April 30, 2011
CentOS 4.x, RedHat Enterprise Linux 4.x August 31, 2012
CentOS 5.x, RedHat Enterprise Linux 5.x September 30, 2014
FreeBSD 7.3 September 30, 2012
FreeBSD 8.0 May 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 /etc/cpanelsync.exclude.

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

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

If you wish to prevent the cPanel & WHM update from changing a file's permissions, enter the filename into the cpanelsync.no_chmod file.

New 4-segment cPanel & WHM version numbers

Starting with version 11.30, cPanel & WHM version numbers will consist of 4 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

Version 11.30 will also provide backwards-compatible (3-segment) 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.

Publishing bug fixes

When we discover critical issues after publishing 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:

EDGE 11.30.1.5
CURRENT 1.30.1.5
RELEASE 11.30.0.8
STABLE 11.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 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 are using DNSONLY beta, you will be reset to current. If you are using DNSONLY, you will be reset to stable.

Removed 2 legacy language tags

The following language tags are no longer available, beginning with cPanel & WHM 11.30:

  • INDXFullVersion
  • INDXRevision

As a result, third-party themes using 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 from cPanel & WHM:

  • Italian
  • Japanese
  • Bengali

GDBM locale files changed to CDB format

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

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

This change makes the following scripts obsolete:

  • scripts/dumbpgdbm
  • scripts/comparegdbm

It also adds 2 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 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 running on your server, call 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, call 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 version 11.30, check to see whether $cpanel::Version::VERSION is greater than 4 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

In 11.30 we are adding support for the MySQL TRIGGER and VIEW privileges.

  • Systems using 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 using 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 using 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 selecting a start time for an auto responder, users can choose to start the auto responder immediately, or set a custom time.
  • When selecting a stop time for an auto responder, users can choose to never stop the auto responder, or set a custom time.

Pluggable DNS clustering

In version 11.30, we've 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, using 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.

Edit | Attach | Print version | History: r7 < r6 < r5 < r4 < r3 | Backlinks | Raw View | More topic actions
Topic revision: r7 - 01 Aug 2011 - 12:24:51 - Main.MelanieSeibert