This imscp_network
service, which was responsible to configure IP addresses on the fly and set iptables rules for the
traffic logger, has been removed.
This new service sets iptables rules for the traffic logger on server boot.
IP addresses that are added via the i-MSCP control panel are now added into the network interface configuration file. Doing this allow us to no longer depend on the MySQL server when the server is rebooted (the possibility of the MySQL server being unavailable for unknown reasons), and also, this provides a better integration with the system. To resume, IP addresses are now configured using interface definitions in the network interface configuration file, instead of being configured on the fly using data pulled from the i-MSCP database.
IP addresses are added in the network interface file using aliased (virtual) interfaces. Those types of interfaces have names of the form interface:integer. To avoid collisions with manually configured interfaces, i-MSCP uses integers starting at 1000. Thus, any IP addresses added through the i-MSCP control panel will have an entry such as:
# i-MSCP [eth0:1002] entry BEGIN
auto eth0:1002
eth0:1002 inet static
address <IP>
netmask 255.255.255.255
# i-MSCP [eth0:1002] entry ENDING
IP addresses that are already present in the network interface configuration file can also be added in the i-MSCP control panel for use with i-MSCP. In such case, i-MSCP simply skip the configuration step for them. In other words, i-MSCP doesn't manage those IP addresses.
Be aware that IP addresses which are not present in the network interface configuration file will be added by i-MSCP, using virtual interfaces. If you want to avoid this, you must add them in your network interface configuration file, even if that is not really needed due to your environment (e.g: LXC containers).
At this time, it's still not possible to setup the netmask, the broadcast and the gateway through the i-MSCP control panel. This is a feature that will be implemented in near future. However you should note that both options, the broadcast and the gateway, are normally not needed when configuring virtual interfaces.
This new version introduce support for VsFTPd (Very Secure FTP Daemon) server that can be used as alternative to the ProFTPD server.
You can switch to this new Ftpd server implementation by running the following command:
# perl imscp-autoinstall -dr ftpd
The 'ZIP' parameter which allows to choose compression algorithm for backup archives has been renamed to 'BACKUP_COMPRESS_ALGORITHM'. The new default value for that parameter is set to 'bzip2' instead of 'pbzip2'. This allows to mitigate the CPU time consumption on virtual servers.
A new 'BACKUP_COMPRESS_LEVEL' parameter has been added, which allows to choose the compression level for backup archives. The default value is set to '1' to mitigate the CPU time and the memory comsumption on virtual servers. Note that this parameter is only relevant when the 'BACKUP_COMPRESS_ALGORITHM' is set to a value other than 'no'.
The hosting plan feature at the administrator level has been removed. From now, only the resellers can setup hosting plans. Remember that i-MSCP doesn't offer any billing management system. The hosting plan feature is only provided to fulfil requirements for some plugins such as BoxBilling and KaziWhmcs, or to create new client accounts through i-MSCP interface without having to fill the limits and features.
The email address set for the administrator during i-MSCP installation is now automatically added as an alias address
in the /etc/aliases
file for the local root user. This means that any mail sent to the local root user will be
automatically forwarded to the administrator email address.
From now, if you change a PHP configuration option for a specific reseller, this will also affect all its clients. For instance, if you change the memory limit for a reseller from 256 to 128, the memory limit of all its clients will be also lowered if higher than 128.
The same thing occurs for the PHP permissions. For instance, If you change a reseller permission from 'yes' to 'no', the PHP permission will be also removed for its clients.
The rule here is: A client cannot have higher privileges than his reseller.
When using the ITK apache2 httpd server implementation, it is no longer possible to setup error reporting level through the PHP editor. This decision was taken due to the fact that it's not possible to use PHP constants in Apache2 vhost files, and that constant values differ between PHP versions. From now, if you use ITK, your clients will have to define the error reporting level at runtime.
The PHP editor now operates according the PHP configuration level that has been choosen by the administrator during the i-MSCP installation or reconfiguration phase. For instance, when the PHP configuration level is set to 'per_site', a client will be able to set different PHP configuration options for its sites (if allowed).
Support for TCP/IP has been added. Be aware that using TCP/IP instead of UDS (Unix domain socket) can require a tweaking of your kernel parameters (sysctl). This is mostly needed for servers that host several high traffic sites.
You can have a look at imscp_net_sysctl.conf for a sysctl configuration file example.
The PHP configuration options at the administrator level were removed because they were too much confusing. From now, if you want limit all clients, you must limit their resellers. For instance, you can change a PHP configuration option value for a reseller without giving him more permissions on the PHP editor. By doing this, this will override default PHP configuration option value for all its clients.
A conflict has been added for the procmail package in the distribution package files, meaning that when running the
i-MSCP installer, this package will be automatically removed. If you need Procmail, you must edit the distribution
package file docs/\<distro\>/\<distro_package_file\>.xml
and remove the following snippet:
<package_conflict>
procmail
</package_conflict>
Note also that the mailbox_command
Postfix configuration parameter, which is used by the local delivery agent, is no
longer set with the external procmail command.
Cyrus SASL is no longer used for SMTP authentication (Postfix side) when Dovecot is choosen for PO server. The Dovecot SASL implementation is used in place.
Support for MySQL 5.6.x/5.7.x, Percona 5.7.x and MariaDB 10.1 has been added. Note that support for these versions is still experimental.
Performance Schema and event scheduler features were disabled for performance reasons. If you need them, you can create
your own .cnf file in the /etc/mysql/conf.d directory. The file must be named in such a way that it will be loaded
after the /etc/mysql/conf.d/imscp.cnf
file.
Switch policy for SQL servers has changed. It is no longer possible to switch from/to MariaDB vendor from/to other vendors, excepted for MariaDB 5.5. MariaDB is taking its own road with more and more dedicated features. Therefore, it becomes difficult for us to provide an upgrade path for other SQL server vendors (MySQL, Percona) without requiring any manual intervention.
Note that it is always possible to switch to another vendor manually. Simply put, this task is now left to the administrator.
Support for both Debian Squeeze (6.x) and Ubuntu Lucid Lynx (10.04) has been removed. If you want to update to this new version, you must first update your distribution to either:
- Debian ≥ Wheezy (7.x) if you're using Debian
- Ubuntu LTS ≥ Precise Pangolin (12.04) if you're using Ubuntu
Major changes were made in the plugin API, which break compatibility with old plugin versions. Therefore, before updating to this new version, you must delete all plugins.
Once the update is done, you must reinstall each plugin by downloading the latest version available from our plugin
store. Be aware that some plugins are not yet ready for use with this new version, such as the Mailman
and
OwnDDNS
plugins which require further works.
Plugins which are known to work with this new version clearly states that they are compatible with i-MSCP version >=
1.2.3
*.
Be aware that the transitional iMSCP::HooksManager
package, which was an alias of the iMSCP::EventManager
package since i-MSCP version 1.1.14
, has been removed. Thus, if you're using that package name in one of your
listeners, you must change it to iMSCP::EventManager
, which is the real package name.
If you're using, either Debian Wheezy
or Ubuntu Precise
with a PHP version that is not provided by official
repositories, you must be aware that the php-apc
package has been added in the list of package to install. Because
that package is no longer provided for PHP versions > 5.4
, you must remove the package from the packages file
before upgrading, else, packages installation will fail.
You can find the packages file inside the i-MSCP archive, under the docs/\<distro\>
directory.
You must stop all i-MSCP services manually before updating, else, some of them will be unable to restart at the end of process.
You can stop the i-MSCP services as follow:
# service imscp_panel stop
# service imscp_daemon stop
# service imscp_network stop
Note: The imscp_panel service is only available if you're upgrading from a version released under the i-MSCP serie
1.2.x
The /root/.my.cnf
file is no longer used by i-MSCP. Because this is a local file, the i-MSCP installer will not
remove it during update. Thus, if you have a database connection problem with the i-MSCP backup scripts after update,
just remove the mysqldump section from this file.
A new plugin.plugin_config_prev
database field as been added, which allows to store the previous plugin
configuration. This field is automatically filled by the plugin manager and you should never update it manually.
From the frontend, you can access the previous plugin configuration parameters using one of the following methods:
iMSCP_Plugin::getConfigPrev() | Allows to retrieve all previous configuration parameters |
iMSCP_Plugin::getConfigPrevParam() | Allows to retrieve a single previous configuration parameter |
From the backend, you can access the previous plugin configuration parameter using the config_prev
property of the
plugin.
Be aware that usage of parameters from previous configuration is only relevant in the disable()
, update()
,
change()
and uninstall()
methods, whatever the context (from the frontEnd or the backend). Indeed, once the
change()
method has been run successfully, the plugin_config_prev
field is filled with the last configuration
applied on the plugin (the configuration coming from the plugin_config
field)
More generally, the parameters coming from the previous configuration allow to do some deconfiguration / uninstallation tasks.
From now, the plugin manager automatically decodes the plugin info, config and config_prev fields and sets them as plugin properties. Thus, it is not longer required to fetch these fields manually nor decode them.
To be more clear, the following news properties are set on plugin instances:
info | Property which contains decoded plugin info field |
config | Property which contains decoded plugin config field |
config_prev | Property which contains decoded plugin config_prev field |
The new plugin API version introduces a new plugin info field require_api
, which allows you to define the i-MSCP
plugin API version that is required by your plugin in the info.php file. Thus, by declaring this field (mandatory), it
is no longer needed to implement API version compatibility check in the main plugin class. All is now done
automatically by the plugin manager, based on the value of the require_api field.
This new version comes with a new CustomDNS
module which allows to process custom DNS records without involving a
rebuilt of files which belong to HTTP server implementations (vhost file, php files...). This also allows to process
the custom DNS records more faster than before because from now they are managed by a dedicated module.
In past, each time you wanted add or delete a custom DNS record, it was mandatory to rebuilt the full configuration of the domain (vhost file, php file ..). This involved a lot of tasks done for nothing and this was not without pose any problems such as the useless reload of Apache (e.g. when using a plugin such as OwnDDNS which needs to update the DNS zone files very often).
From now, if you want add your own DNS records, you must simply add them into the domain_dns
table with the correct
status (e.g. toadd) and trigger a backend request (only needed if you add the record through the FrontEnd).
Note: All this also apply to the listeners files.
The minimum length for usernames and passwords is now 6 characters long. Due to this change, it is possible that during the update you need to update them.
Multiple webmails are now supported. You can install either no webmail, one webmail or many webmails at same time. You can reconfigure list of webmails to install by running the following command:
# perl imscp-autoinstall -dsr webmails
At this moment Roundcube and RainLoop webmails are available.
Prior to any update attempt, it is greatly recommended to deactivate all plugins through the plugin interface. Once the update is done, you must re-activate the plugins one at a time. If something goes wrong with a plugin, you can post in the plugins support section, and our development team will fix the issue as soon as possible.
i-MSCP 1.2.0 introduces support for the Nginx Web server which is currently used only by the i-MSCP frontEnd. From now, the i-MSCP frontEnd is run through a dedicated httpd instance, and is reachable through the following http(s) ports:
8080 (http)
4443 (https)
You can set different ports by editing the /etc/imscp/imscp.conf
file, and by re-running the i-MSCP installer. Be
aware that the common http(s) ports (80 and 443) are reserved, and therefore, must not be used. If you want keep access
to the panel though these ports, you can install the following plugin which will act as a proxy:
Having the i-MSCP frontEnd running with a dedicated httpd instance means that even if your Apache instance is down, the panel will stay reachable. You can manage the i-MSCP frontEnd service with the following commands:
# service imscp_panel <action>
# service nginx <action>
Hooks files are now known as listener files. A listener file is a Perl script which contains one or many event
listeners registered on the events manager and triggered by the same. The old /etc/imscp/hooks.d
directory has been
renamed to /etc/imscp/listeners.d
directory for consistency reasons.
Many options were either added, removed or simply renamed. You can get the full list of available command line options by running the following command:
# perl imscp-autoinstall -?