The customers can now setup an alternative DocumentRoot for each of their domains. This feature is mostly needed for
PHP frameworks such as Symfony or Zend Framework where the default skeleton defines a specific subfolder for the
public resources.
The alternative DocumentRoot must pre-exist and must be located in the default /htdocs directory of the domain for
which it is being set.
Note that if the domain is redirected to another domain, there is not possibility to setup an alternative DocumentRoot.
In such a case, the customer must first disable the redirection for his domain. Be also aware that this feature is only
implemented at the customer level, and only for the edit pages. When a domain or subdomain is being created, there is no
possibility to setup an alternative DocumentRoot because at this time, the /htdocs directory doesn't exist yet on
the file system. This is by design.
Due to a bug present in the Apache2 mod_proxy_fcgi module, the ProxyErrorOverride directive causes a infinite loop
when a PHP application (such as ownCloud) handles the error documents via PHP. This new version fix the problem by
patching the module with a patch taken from the upstream repository.
See https://bz.apache.org/bugzilla/show_bug.cgi?id=55415 for further details about the issue.
Be aware that it is assumed that you use the Apache2 packages provided by your distribution.
For keeping our own version of the mod_proxy_fcgi module when Apache2 is being updated via APT, we've added a dpkg
diversion (see dpkg-divert(8)). If after an APT update, you encounter a problem with Apache2, and more specially with
the mod_proxy_fcgi module, you should process as follow:
First, be sure that the /usr/lib/apache2/modules/mod_proxy_fcgi.so-DIST file exists. If the file doesn't exists, this
propably means that there is no dpkg diversion and thus, you can skip this step
# service apache2 stop
# rm /usr/lib/apache2/modules/mod_proxy_fcgi.so
# dpkg-divert --rename --remove /usr/lib/apache2/modules/mod_proxy_fcgi.so
Doing this will remove the diversion and reinstall the mod_proxy_fcgi.so module which is provided by your distribution
package. Of course now, your version of the mod_proxy_fcgi module will have the bug specified above.
# cd <imscp_archive_dir>/autoinstaller/postinstall
# sh fix_apache2_mod_proxy_fcgi.sh
This will rebuild the mod_proxy_fcgi module and re-recreate the dpkg diversion.
Due to many problems that appeared, following changes made in the version 1.3.2 regarding the mount/umount events propagation, it has been decided to revert them. If you're upgrading from a version >= 1.3.2, you must run the following commands before starting the installer:
umount -l /var/www/virtual
umount -l /var/www
mount -a
These commands will revert the changes introduced in previous i-MSCP versions. Note that before running these commands, it is recommended to stop the following services:
- apache2
- Ftp service (either protfpd or vsftpd, depending on your setup)
- imscp_panel
The file is no longer needed and therefore, has been deleted.
To fulfil the i-MSCP requirements in regard of the mount/umount events propagation, and to say compatible with virtual
environments such as OpenVZ, both, the /var/www directory and the /var/www/virtual directory are now mounted
on themselves as follow:
/var/wwwis mounted on himself as slave subtree/var/www/virtualshared is mounted on himself as shared subtree
The /etc/imscp/mounts/mounts.conf file will contains the following entries:
# fstab-like configuration file - auto-generated by i-MSCP
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
/var/www /var/www none bind,slave
/var/www/virtual /var/www/virtual none bind,shared
...
Note that directory paths can differ according your installation layout.
Due to major changes made in the iMSCP::Mount library, versions of InstantSSH plugin older than 5.0.0 are not compatible with this new version. Thus, if you use that plugin, you need to disable it first. Once the update done, you must upgrade your InstantSSH plugin with the last available version.
Note: If you also use the CronJobs plugin, you must disable it as well.
Before running the i-MSCP installer, you must stop the imscp_panel service manually.
Due to a security issue which has been fixed in that new version, the customers can now connect to AWStats interface only by using their control panel login data.
Due to two major updates for the database, and depending on amount of traffic data you have in your i-MSCP database, the update process may take several minutes.
The listening ports for the i-MSCP frontEnd were changed to make them compatible with CloudFlare. The new ports are:
- http: 8880
- https: 8443
Note that this change only affects new i-MSCP installations.
The i-MSCP frontEnd is now run through its own PHP FPM instance. Previously, the frontEnd was run through PHP CGI with
spawn-fcgi.
The policy for the accepted characters in passwords that are set through the i-MSCP installer (setup dialogs), including inside the preseed file, has been updated for unification reasons. From now, only ASCII alphabet characters and numbers are accepted. Special characters are no longer allowed. Indeed, while some services accept any special characters, some others only allow a specific range of them. Having multiple policies for password validation is difficult to maintain in time. Therefore, we've choosen to restrict the character range to one that is accepted by all services.
Note that this change shouldn't affect existing installations of i-MSCP as long as the services are not reconfigured.
It is now possible to choose the configuration mode for IP addresses that are added through the i-MSCP administration
interface. These modes are auto and manual.
Note that the manual mode is only appropriate on servers for which network interfaces are configured through DHCP, or
when you must set a specific netmask for the target IP address.
Be also aware that the configuration mode for the server primary IP address is set to `manual' by default.
In this mode, i-MSCP will automatically configures the target IP address if not already present in the interfaces
configuration file. This involve the following tasks:
- Adding the IP address configuration into the
interfacesfile - Bringing the network interface up
- Removing the IP address configuration from the
interfacesfile - Bringing the network interface down
In this mode, i-MSCP will remove any entry which would have been previously added for the target IP address in the
interfaces configuration file and skip its configuration. In such case, the configuration is left to the administrator.
Note that in this mode, i-MSCP won't try to bring up nor bring down the network interface.
It is no longer possible to configure additional IP addresses through the installer. From now, the installer will only ask you for the server's primary IP address.
Note that by default, the server's primary IP address will always be set with the manual configuration mode. You're
free to change the configuration mode through the administration interface.
It is now possible to set/edit the netmask for each IP address.
Note that if you choose the manual configuration mode for the IP address, the netmask is only informational.
It is now possible to edit the NIC for each IP address.
Note that if you choose the manual configuration mode for the IP address, the NIC is only informational.
The pages for disabled domains have now their own skeleton directory (e.g. /etc/imscp/skel/domain_disabled_pages) which is copied into the root Web directory (e.g. /var/www/virtual) during installation.
The pages for disabled domains are now stored outside of the customer home directories.
The PHP opcode cache (OPcache or APC) is now enabled by default if you use PHP as Apache2 module (ITK), or through PHP-FPM.
To make this change, two new parameters were added into the /etc/imscp/php/php.data configuration file which are:
This parameter allows the administrator to enable/disable the PHP opcode cache for the customers. Default value is
1 (enabled).
Note: If you change the value of this parameter, you must not forget to run the imscp-reconfigure script.
This parameter allows the administrator to setup the amount of memory that can be used by the PHP opcode cache. You
must not forget that the PHP opcode cache is shared across all customers. This is by design and this cannot be changed.
Default value for this parameter is 256 MiB. However, if you host several PHP applications, and if you have enough
memory available on your server, it is recommended to increase this value accordingly.
Note: If you change the value of this parameter you must not forget to run the imscp-reconfigure script.
First of all, if you're updating from a version older than 1.2.16, you should read the 1.2.x errata file. You can find
that file in the ./docs directory of the i-MSCP archive.
Prior to any update attempt, you must deactivate all plugins through the plugin interface. Once the update is done, you must update all your plugins to latest available version, and re-activate them one by one. 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.
The external mail feature has been greatly simplified. From now, activating the external mail feature for a domain only configures i-MSCP mail server to relay mail through external MX. The MX and SPF DNS resource records for external mail servers are no longer created by i-MSCP. The customers must now create those DNS resource records by themselves, either through their registrar interface if they use the DNS server provided by their registrar, or through the custom DNS resource records interface if their DNS are managed by i-MSCP server.
Note that following those changes, the external mail feature has been reseted, meaning that customers will have to reactive it if needed.
VsFTPd doesn't support non-ascii characters in usernames. Therefore, to be compatible with VsFTPD and ProFTPD, the internationalized domain names (IDN) that are part of FTP usernames will be converted to IDNA form. This means that only ASCII usernames will be accepted.
You must not forgot to warn your customers about this change.
Starting with this version, usage of SQL root user is prohibited. Instead, a dedicated SQL user for i-MSCP is created. This change intends to solve issues with SQL servers that are configured to use passwordless authentication. With such a configuration, password for the SQL root user is not set while package installation. Instead, the authentication is done through a unix socket (a mapping between the local unix user and the SQL user is done.)
Note that while installing or reconfiguring i-MSCP, the installer will still ask you for the SQL root user info when needed. However, this user will be only used to create and grant privileges to i-MSCP SQL users. This means that i-MSCP will never store any data related to the SQL root user, nor change any of its properties.
Be also aware that in latest versions of the i-MSCP PhpMyAdmin package, usage of SQL root user has been prohibited for security reasons. If you want connect to PhpMyAdmin to work on all databases, you should now use the i-MSCP master SQL user.
The imscp-setup script has been renamed to imscp-reconfigure.
This new parameters allows the administrator to disable mount of customers httpd log directories. To disable them, you can process as follow:
# sed -i'' 's/^\(MOUNT_CUSTOMER_LOGS\s\+=\).*/\1 no/' /etc/imscp/apache/apache.data
# cp /etc/imscp/apache/apache.data /etc/imscp/apache/apache.old.data
# perl /var/www/imscp/engine/setup/imscp-reconfigure -danv
Be aware that when mount of httpd log directories is disabled, the 'logs' directory located in the home directory of customers is also removed.
Starting with this version, permissions on customer files are no longer set recursively by default. This allows to avoid long running processes when a customer has thousands of files in his Web folders or mail directory.
To enable recursion, you must now pass the --fix-permissions option to the installer (or any script supporting it).
The --fix-permissions option is supported by the following scripts:
- imscp-autoinstall (i-MSCP installer)
- imscp-reconfigure (i-MSCP reconfiguration script)
- set-engine-permissions.pl (Script that set engine permissions)
Note: If you're migrating i-MSCP data from one server to another, you must not forget to set this option while running the imscp-reconfigure script.
This imscp_mountall service mounts i-MSCP file systems when the server is rebooted. This service reads entries in a
fstab-like file located at /etc/imscp/mounts/mounts.conf. Unlike the entries that are added in the system fstab file,
the entries added in this file are always processed in sequential order.
Third-party software components that want add entries in that file must use the API provided by the iMSCP::Mount library.
It is now possible to setup MX DNS resource records through the custom DNS resource records interface. Be aware that default MX DNS resource records, as the SPF DNS resource records, are removed only if the external mail feature is turned on for the target domain.
It is now possible to add DKIM/DMARC TXT DNS resource records.
To fulfit specific requirements, the SPF DNS resource record type has been added to the list of allowed custom DNS resource records. It is now possible to setup custom SPF records using SPF and TXT DNS resource records. However you must be aware that when a custom SPF DNS resource record is detected (SPF or TXT), the default SPF DNS resource records set by i-MSCP are automatically removed.
Note: As per the RFC 7208, the SPF DNS resource record is deprecated. However it is still required in some contexts.
It is now possible to set a TTL value for any custom DNS resource record. Previsously, this was only possible for the SRV DNS resource record. The TTL value must be expressed in seconds. Note that for safety reasons, it is not allowed to specify a value lower than 60 seconds.
If you do not specify a fully-qualified domain name for one of these fields (domain name ending by DOT) they will be
automatically completed with your domain name (domain for which you add the record). For instance, if you add a DNS
resource record for the test.tld domain, and specify the following label for the name field:
sub
it will be automatically completed with your domain name as follow:
sub.test.tld.
You must also be aware that the out-of-zone records are not allowed. Simply put, if you specify:
google.fr.
for the name field, it will not pass validations.
Anyway, even if that were allowed, the DNS resource record would be ignored by the DNS server. For instance, adding
such DNS resource record for the test.tld zone:
google.fr. IN A 192.168.1.110
would lead to:
root@jessie:/var/cache/bind# named-compilezone -i none -s relative -o - test.tld test.tld.db
test.tld.db:27: ignoring out-of-zone data (google.fr)
zone test.tld/IN: loaded serial 2016031403
...