Posts by Nuxwin

    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.

    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.


    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 Iceman 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.

    Well, Nuxwin already told you. Its up to you, to backup the database (and files if you want to be one the safe side) before you do a upgrade/update.

    The mail backup inside the backups folder should only contain the mails and so on. I doubt that the contacts are saved there as well (but I am not sure).

    The contacts are saved in the roundcube database. No backup is made for it. That why in the imscp upgrade instructions it is clearly stated that you need make a backup of your data prior upgrading...

    Dio un error el servidor, que está corriendo en Debian 9 y i-MSCP 1.5.3 Build: 2018120800 Codename: Ennio Morricone, y lo reinicié, ahora en la cuenta de uno de los dominios han desaparecido las libreta de direcciones, tengo una copia, pero no se que fichero restaurar para que la recupere

    Good morning,


    You're talking about what exactly? Contacts from Roundcube? If yes, you need to restore you imscp_roundcube database.

    Nuxwin

    I can understand... you want to go on using new techniques (whatever)... but you cannot do the development auf 1.6, 1.5.4 and maintenance of 1.5.3 alltogether alone. That's the impression I got when having a look at the project in the last months...

    New techiques like you say are not just about switching to something other just for fun... If I want rewrite almost everything , this is because I want make the maintenance and development more easy. Right now, each time we want to modify and/or enhance something, that a hell because layers are too close all together (hard dependencies). Of course, such work cannot be done in few weeks and of course, I cannot deliver all the things as fast as I would want...


    Finding people able to "really" contribute to the project is not easy as those are generally not close to Perl language, and also because somehow, I must admit that I'm too rigid with CS rules and so on... But hey, you know me since ~10 years now. That problem is not new ;)


    BTW: My FB is full of posts about i-MSCP. Open your eyes ;)

    Hi Nuxwin,


    ok, thanks for the answer.

    Is there a plan to modify some of the most-common CMS systems. Or is the "software-veraltung" feature in general obsolet? It's not an urgent issue, but only to know.


    Thanks

    If you read my answer again, you'll discover that sentence:

    BTW: It is planned to drop the software installer as it is not maintained. It will be replaced by a 3rd-party solution.

    It is not clear enough?

    Hi guys

    I also had the problem of delivering PHP 7.2 to customers (eg. TYPO3 9 needs 7.2 or higher).

    It is possible even with old infrastructure (imscp 1.2.x, phpswitcher 2.1.1) to adopt some parts and get a php 7.2 - need some try&error because of the debian patches for php but in the end it worked... not the latest, but 7.2.9 at least... maybe not the best solution, but one I can live with for the moment (it was February 2019).


    /J

    joximu For you, me and some other people, of course, all is possible... even using PHP 7.3.. with the current version of the PhpSwitcher plugin. We need only know Perl sufficiently... Well because too many users cannot wait the for the next i-MSCP version, I'll prepare a new PhpSwitcher version (intermediate version), which will make it possible to register PHP versions from Ondrey Sury repository, that is 5.6 up to 7.3... I'll try to do my best to deliver it tomorrow..