Posts by freedom

  • Error while updating to 1.5.3 (2018120800) - Failed to get unit file state for networking.service

    Hello again,


    as Nuxwin stated here, I updated the i-mscp instance to the new build number, while a new error occured.


    Distro: Debian Jessie 8.7

    I-MSCP Version: 1.5.3 (error with newest build number in the last step)


    In the last step of the updating process, the installer aborted with the following error.


    Code
    1. [ERROR] main::setupDbTasks: Modules::ServerIP::add: Failed to get unit file state for networking.service: No such file or directory at /usr/local/src/imscp-1.5.3-2018120800/engine/PerlLib/iMSCP/Provider/Service/Debian/Systemd.pm line 64.
    2. ...propagated at /usr/local/src/imscp-1.5.3-2018120800/engine/PerlLib/iMSCP/DbTasksProcessor.pm line 496.
    4. [ERROR] autoinstaller::Functions::install: An error occurred while performing installation steps


    Didn't had such problems before. And we don't want to update to Debian Stretch, because we're already setting up an new server with the newest Debian and I-MSCP Version. We just want to update the old one, as stated from Nuxwin, to prevend any more complications while we're migrating our pages and projects one by one. The error points to an missing file in the update folder, is this correct?


    Kind regards,

    freedom

  • Wrong SQL query in SSLcertificate.pm module (core)

    I was able to find and fix the error. We removed one customer with the Domain ID 21 some weeks ago, without revoking the certificate before. We thought that the certificate would be removed aswell and everything was working until today.


    The above cert_id 98 was aimed to domain_id 21, which was deleted some time ago and because of that i-mscp responds correctly with an error. After removing the not needed cert_id 98 from the table ssl_certs, which had the status "toadd", we were able to restart everything and everything works now.


    We can start again to migrate our customers to the new server with i-mscp now.

    I don't know if its a bug, or was just a problem on our side with the not removed mysql entry from the not needed ssl cert after removing the corresponding domain, so I thought I give the answer here aswell.

    The problem is solved.

  • Wrong SQL query in SSLcertificate.pm module (core)

    Hello,


    today we want to move one customer account to a new one, because of migration progresses in our company. I-MSCP got stucked while adding the new domain and we tried to reconfigure imscp to check where a problem is, or the problem is already fixed with that. Unfortunately, the problem is still existing and the reconfiguration failed.


    After we searched the logs and checked a Let's encrypt renewal log, it seems that there was already a problem, which causes the problem now aswell.


    Log from the renewal:

    Code
    1. [Sat Jan 12 00:00:15 2019] [error] main: Couldn't process Let's Encrypt renewal tasks: Modules::SSLcertificate::_loadData: DBD::mysql::db do failed: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'FROM ssl_certs WHERE cert_id = '98'' at line 1 at /var/www/imscp/gui/plugins/LetsEncrypt/cron/../../../../engine/PerlLib/Modules/SSLcertificate.pm line 256.
    2. ...propagated at /var/www/imscp/gui/plugins/LetsEncrypt/cron/../../../../engine/PerlLib/iMSCP/DbTasksProcessor.pm line 496.


    Log from todays reconfigure:

    Code
    1. [Sat Jan 12 17:15:18 2019] [error] main::setupDbTasks: Modules::SSLcertificate::_loadData: DBD::mysql::db do failed: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'FROM ssl_certs WHERE cert_id = '98'' at line 1 at /var/www/imscp/engine/setup/../PerlLib/Modules/SSLcertificate.pm line 256.
    2. ...propagated at /var/www/imscp/engine/setup/../PerlLib/iMSCP/DbTasksProcessor.pm line 496.

    Both errors are pointing to an MYSQL Syntax Error with cert_id 98. We already tried to investigate but could not find the problem yet.


    Does anyone have an idea why the plugin is not able to do it's work? Everything worked before that point.


    Thank you for your time.

  • Update from MySQL 5.6 to MariaDB, or wait until Update to Debian Stretch?

    Nuxwin


    Thank you for your answer. We would like to update to MariaDB 10.1 in the first place and we would like to finish the distrubtion update to Debian Stretch later on. So if I understand you correct, it is possible without i-mscp related problems to update from MySQL 5.6 to MariaDB 10.1 with Debian Jessie, if we force the autoinstaller to show all vendors when we override the imscp.conf, right?

  • Update from MySQL 5.6 to MariaDB, or wait until Update to Debian Stretch?

    Hello community,


    just a few days ago we updated from mysql 5.5 to 5.6 on Debian Jessie with I-MSCP 1.5.3, thanks to Nuxwin. Today I have a few questions regarding the options to update to MariaDB, since with Debian Stretch, MySQL will be replaced with MariaDB.


    We alread have plans for the full distribution update to Debian Stretch, but until this can work, we have to check some of our software. I searched for a I-MSCP Autoinstaller Update to MariaDB and found the following: Von MySQL 5.5 zu 5.6 oder MariaDB 10


    Quote from Nuxwin

    Switch between SQL vendors is not allowed through installer because generally, this require manual intervention from the administrator.


    You can always force the installer to show you all available SQL vendors by resetting value of both SQL_SERVER and SQL_PACKAGE parameters to an empty value in the /etc/imscp/imscp.conf configuration file but if you do, nothing garantie that the upgrade will work as expected.


    In all cases, do a backup first.


    So the question now is: Would it be better to update using that option from MySQL 5.6 to MariaDB 10.0, MariaDB 10.1 or should we just wait for the distribution update, where MySQL will be replaced with MariaDB from stretch? I checked some systems and used Google for more information and it seems like atleast an update to MariaDB 10.0 should be possible without any problems, but I think I-MSCP wouldn't disabled the easy vendor switch then, right?


    Thanks for your time. :)

  • Following a MySQL upgrade failure (version 5.5 to 5.6) with i-MSCP 1.4.7, upgrade to i-MSCP 1.5.3 is failing

    Hi Nuxwin,


    No /etc/imscp/imscpOld.conf was found and I edited the /etc/imscp/imscp.conf. I changed the SQL_SERVER to mysql_5.6.


    After that I used perl imscp-autoinstall -d again for i-mscp 1.5.3. Seems to be still a conflict with the aborted mysql update before and now i-mscp wants to configure mysql 5.5 and crashed in this case.


    Output from perl imscp-autoinstall -d:



    I think I totally failed because I tried to update to i-mscp 1.5.3 after the mysql update from i-mscp 1.4.7 only works half the way. Would be happy if you can help me to find the problem and got a working i-mscp 1.5.3 with mysql 5.6 again.


    I will send you server access data right now via conversation. Hope we can fix this. :)

  • Following a MySQL upgrade failure (version 5.5 to 5.6) with i-MSCP 1.4.7, upgrade to i-MSCP 1.5.3 is failing

    Hello,


    Distro: Debian 8 (Jessie)

    I-MSCP Version: 1.4.7

    SQL Server: 5.6 / after failure currently 5.5


    I got a problem with our i-mscp enviroment after trying to update to mysql 5.6. I followed the instruction from https://i-mscp.net/index.php/T…SCP-MySQL-update-5-5-5-6/ to update the mysql version for i-mscp 1.4.7. Everything seems to work, but the process aborted with an unknown error at mysql-community-server. But the mysql server updated successfully to 5.6 and every service was online and ready.


    Since the failure got me and we wanted to upgrade to 1.5.3 anyways, I disabled every i-mscp plugin via the database and started the update for i-mscp 1.5.3. Because of that aborted mysql update, i-mscp didn't realize the mysql 5.6 server, so it uninstalled that package and tried to installed mysql 5.5 again and crashed as expected in this case, because of the information on here: Nach MySQL Update geht nichts mehr.


    Seems like i got the same problem and I'm unable to find the working solution.

    Maybe Nuxwin could give a hint, how can I solve the problem, because he already solved the case for another customer.


    Any ideas would be great. :)


    Thanks for your time.

  • Is it possible to change apache2 vhost with websocket, wihout i-mscp overriding it?

    Hi community,


    We recently installed rocketchat and got that functional behind a apache2 proxy (in i-mscp), secured with an lets encrypt ssl cert from the lets encrypt plugin. But Rocketchat needs additional entries in the vhost files, to allow websocket connections.

    Code
    1. ProxyPass /websocket ws://127.0.0.1:3000/websocket
    2. ProxyPassMatch ^/sockjs/(.*)/websocket ws://127.0.0.1:3000/sockjs/$1/websocket


    Is it possible to add this additional lines to the affected vhosts, so they're update safe and safe for ssl cert updates? We know that i-mscp is regenerarting the vhost files in such cases, so any changes would be deleted.


    Does anyone has a update-safe solution? :)


    Kind regards

    freedom

  • Moving /var to same partition as /home possible? (disk space issue)

    @flames


    Thanks. I used google but unfortunately my OVH Server can't start in single user mode and the rescue mode can't be the solution (i can only mount one drive to /mnt/ and the steps above won't work in this case).
    Are the steps above still okay in normal boot mode, so I can use i-mscp after?

    Or should I just use the symlink variation?.


    EDIT:


    It worked right now. I used init 1 to get in single user mode because ovh doesn't support it from the interface. I followed the instructions from the first answer here (https://serverfault.com/questi…nother-existing-partition) to mount the new var folder to /home/var. Everything worked as expected and the disk issue is solved permanently after I deleted the /var.old folder.


    Code
    1. /dev/root 20G 4.9G 14G 27% /
    2. devtmpfs 7.9G 0 7.9G 0% /dev
    3. tmpfs 7.9G 0 7.9G 0% /dev/shm
    4. tmpfs 7.9G 12M 7.9G 1% /run
    5. tmpfs 5.0M 0 5.0M 0% /run/lock
    6. tmpfs 7.9G 0 7.9G 0% /sys/fs/cgroup
    7. /dev/md3 1.8T 52G 1.7T 4% /var
    8. tmpfs 7.9G 0 7.9G 0% /var/chroot/InstantSSH/shared_jail/dev/shm
    9. tmpfs 1.6G 4.0K 1.6G 1% /run/user/117
    10. tmpfs 1.6G 0 1.6G 0% /run/user/0

    Thanks to @flames. Problem is solved now. I wasn't sure if moving /var and mounting it would be possible so easily with i-mscp. But everything worked fine. :)