Posts by innodapt

    Schöne Grüße

    Bitte verzeihen Sie mein Deutsch…

    Meine Konfiguration ähnelt Ihrer. (i-MSCP 1.5.3 build 2018120800 auf Ubuntu 14.04.1) PHPSwitcher 4.0.3 arbeitet für mich an dieser Konfiguration, daher sollten wir in der Lage sein, eine Lösung zu finden.

    1) Welche Version von PHPSwitcher haben Sie installiert?

    2) Haben Sie versucht, PHPSwitcher zu deaktivieren und wieder zu aktivieren?


    Fellow travelers: I successfully upgraded from 1.3.16 to 1.5.x on my production server (Ubuntu Trusty Tahr) this morning. Per the errata and best practices, I made sure I had good backups of “all the things,” disabled all plugins and ran the applicable shell commands to prepare for the upgrade, specifically:

    1. # pkill -KILL -f vlogger
    2. (per errata for 1.4.1)
    3. # service cron stop
    4. # service imscp_daemon stop
    5. # pkill -TERM -f imscp
    6. (per errata for 1.4.6)

    Initially, I had planned to upgrade to 1.5.3 (the current stable release at this time), however this upgrade was stymied by a recently discovered issue with Composer. Thankfully, the current development release (1.5.x) addresses this issue, resulting in a trouble-free direct upgrade.

    My advice: Follow best practices (make your backups), read the errata, and should you hit a hitch—DON’T PANIC! This forum is your friend.


    Thank you so much for this fix! I was upgrading from 1.3.16 to 1.5.3 and my heart dropped when I got the “SHA384 is not supported by your openssl extension…” error. I found this thread searching for an explanation, and “VIOLA!” (as we say here—I am a composer and conductor.)

    I am happy to report that with this fix, I was able to upgrade directly from 1.3.16 to 1.5.x with ease. Hooray!


    Background: I have an issue with an ISP in our region that has arbitrarily blocked our IP for emails heading into their domain. While we work to get that sorted, my data center has provided a relay host so that our messages can be delivered. This, of course, involves adding entries to /etc/postfix/imscp/transport, which we have done manually as a work-around. This led me to this thread:

    I am working on a listener to enforce entries in /etc/postfix/imscp/transport, but while I am a coder from way back, I am really a coder from waaaaaay back. If I can get this working, it will be my first humble code contribution to the i-MSCP universe. Here is what I have so far (based on

    I have two questions:

    • Is “afterSetupServerHostname” a good trigger for this event, or would you recommend something else?
    • I do not have a clue how to trigger the necessary “postmap /etc/postfix/imscp/transport” from this file. Feeling pretty stupid here, but at least I am smart enough to know when I am stupid—and that is one good step in the direction of being a little less being stupid!

    Thank you so very much for your help with this, and for all you do to make our lives better through i-MSCP!

    I just set up a Xenial VM to “inspect what I suspected.” It turns out /etc/mtab is in fact symlinked to ../proc/self/mounts by default on Ubuntu LTS Server 16.04.1 “Xenial Xerus”

    So… unless your symlink is missing, @UncleSam, it looks like you have a different problem. :(

    @Nuxwin has provided a solution for us Ubuntu users:

    # cd /etc
    # mv mtab mtab-disabled
    # ln -s /proc/mounts mtab
    # service imscp_mountall restart

    It turns out this is happening because evidently /etc/mtab is not symlinked to /proc/mounts by default on Ubuntu LTS 14.04 as it is on Debian. Creating the link manually (as above) should solve the problem for all affected “Trusty Tahr” users.

    Future versions of the installer will include this fix for Trusty Tahr.

    Thanks, @Nuxwin for a real fix and @UncleSam for confirming the problem on Ubuntu 16.04.1