Posts by Nuxwin

eXo

https://lists.linuxcontainers.…ers/2015-July/009639.html

Quote from joximu

Hi

I use theese values - in the /etc/dovecot/dovecot.conf (at the end...)

Code

1. protocol imap {
2.   mail_max_userip_connections = 80
3. }
4. protocol pop3 {
5. mail_max_userip_connections = 80
6. }
7. service imap {
8. executable = imap postlogin
9. process_limit = 2048
10. }
11. service pop3 {
12. }
13. service postlogin {
14. executable = script-login -d rawlog
15. unix_listener postlogin {
16. }
17. }
18. service auth {
19. client_limit = 1024
20. }
21. service anvil {
22. client_limit = 1027
23. }
25. #100
26. default_process_limit = 256
28. #1000
29. #default_client_limit = 1000
31. #256M
32. default_vsz_limit = 512M

Display More

with theese values I have less problems than before... server with lots of mail users...

/Joxi

Display More

Exactly why in next version, those parameters will be part of core

https://github.com/i-MSCP/imsc…dovecot/dovecot.data.dist

https://github.com/i-MSCP/imsc…bian/dovecot/dovecot.conf

Quote from scieri

The server had installed MariaDB 10.2 and after the auto update it had 10.1

Impossible, unless you forced such downgrade...

Quote from Iceman

I wonder about the missing ini files. Did you check if the paths are correct?

Plus whats that about the too many arugments? Did you check the installer for it?

Did you check ICU itself? Is it working properly? I found one topic here, where ICU itself was at "fault".

Nothing to do with the ini file, at least for the icu-config problem The icu-config problem has been already reported on our forums and a solution has been already given. See Error Compiling PHP Versions for PHP Switcher

Furthermore, he don't tell us what's the purpose of the ./phpinstaller.sh script so we cannot help much.

Quote from DylanBejgli

Solved, I had to reinstall the server.

Good morning,

We you show us the output of the following command (executed from your i-MSCP server)?

Edit:  MiGro94 Ok thank

Quote from Mr.X

Hi Iceman,

thanks for your reply. I've read the wiki and checked the forum before. But couldn't find something similar to this.

In our wiki, we don't mention that Buster is supported, and if you look at the INSTALL.md file of the latest stable version, you can see that the list of supported Debian versions are Debian Jessie (7.x) and Debian Stretch (8.x). See https://github.com/i-MSCP/imsc…supported-debian-versions

So, basically put, you're using an i-MSCP version, and a PhpSwitcher plugin version that were not tested under Debian Buster. Current i-MSCP stable version is compatible with Debian Stretch, not with Debian Buster. Therefore, I'm primarly wondering why you did that update without more thinking about your current environment... Debian Buster has just been released.

Regarding the configuration failure when you try to re-compile your PHP versions, this can be due to many things... I cannot say more without investigating directly on your server.

Quote from cynric

I do have trouble with the i-MSCP service Lets Encrypt certs though. These were are still present from the old server and linkes to its hostname. If I click renew that won't work because Lets Encrypt expects the validation to be on the old server's hostname. I probably need to remove the existing certs from i-MSCP to have it request new ones instead. How can I do that?

Best try to delete the related row in the letsencrypt table of the imscp database, then, retry. You should also remove the related row in the ssl_certs table of the imscp database.

Quote from cynric

The next thing that gives me a headache is switching the mailserver over. Rsyncing the contents worked well, but my old mailserver is running in dual stack mode and my DNS "mail." records (which is the target of my MX record) A and AAAA currently point to it. The server switch tutorial suggested using rinetd to redirect service requests to the new server. However rinetd does apparently not support IPv6. So if I stop Postfix and Dovecot and just setup the IPv4 redirect (while still having the old IPv6 mail record out there), will this work? Or will it lead to remote servers trying to deliver mails via IPv6 and failing miserably?

You mean, for the DNS propagation time? What was the TTL set for your DNS record? If the TTL is not so big, I would advise to just shutdown the SMTP server (old server). Most SMTP servers will retry mail delivering for the next 5 days... So yes, mail delivery will be a bit delayed that way but this is the easy way.

Another way would be to setup the old mail server relayhost parameter and remove the local maps for the mail account/domains. Then the mail would be redirected to the new server which would accept or not the mails according its local maps. That being said, I don't know any MX that prefer IPv6 over IPv4...

Edit: Sorry DrCarsonBeckett We posted at the same time and so I didn't see your answer before...

cynric

Good morning,

First, I'm assuming that you're comfortable with rsync(1) and mysql(1) command line tools, and that you have a fresh/base installation of Debian Stretch (new server).

To migrate one i-MSCP instance to another server, you need to follow the following steps:

1. Install the SQL server on the new server. It MUST be the same vendor/version as on the old server.
2. Backup your /etc/mysql directory on your new server (just for safety).
3. Rsync both, the /etc/mysql and /var/lib/mysql directories from the old server to the new server. Note that you MUST NOT do that while the SQL server is running on the old server.
4. Start the SQL server on the new server and check that all is working as expected (connecting through mysql(1) command line tool, querying and so on)...
5. Update the servers_ips table in the i-MSCP database manually through the mysql(1) command line tool. You need update the IP address and network interface name...
6. Set both the admin_sys_name and admin_sys_gname columns to NULL in the admin table of the i-MSCP database (for all rows): UPDATE admin SET admin_sys_name = NULL, admin_sys_gname = NULL;
7. Set both the admin_sys_uid and admin_sys_gid columns to 0 in the admin table of the i-MSCP database (for all rows): UPDATE admin SET admin_sys_uid = 0, admin_sys_gid = 0;
8. Disable all plugins in the i-MSCP database: UPDATE plugin SET plugin_status = 'disabled' WHERE plugin_status NOT IN ('disabled', 'uninstalled');
9. Rsync the /etc/imscp directory from the old server to the new server.
10. Rsync the /var/www/imscp directory from the old server to the new server.
11. Rsync the /var/www/virtual directory from the old server to the new server.
12. Rsync the /var/mail/virtual directory from the old server to the new server. You SHOULD NOT do that while both the SMTP (Postfix) and IMAP/POP servers are running on the old server.
13. Update the /etc/imscp/imscp.conf configuration file (hostname, IP address)...

Once all that is done, you need to download the identical i-MSCP version archive on the new server and run the installer as follows: perl imscp-autoinstall -dx. This command will install all missing distribution packages, and rebuild all configuration files for the various services and so on... This will also fix all permissions recursively, including new UNIX ownership for your customers as those will get resetted.

After the installation, you'll have to re-enable the plugins. Generally the way to go is to force an update command for each of them, manually because if those are correctly implemented, this will install the missing distribution packages and reconfigure the whole:

1. Shutdown the i-MSCP daemon: service imscp_daemon stop
2. Update the plugin status to force update: UPDATE plugin SET plugin_status = 'toupdate';
3. Execute the tasks processor manually: perl /var/www/imscp/engine/imscp-rqst-mngr -dv

Of course, you could have some issues while the process, depending on the plugins you're using... If so, we can always help you.

Once all is working as expected, don't forget to start the i-MSCP daemon again.

Bonjour,

i-MSCP version?

LetsEncrypt plugin version?

Essayez de supprimer totalement le certificat SSL en désactivant Let's Encrypt pour le domaine concerné. Un fois fait, ré-activé Let's Encrypt pour le domaine.