Posts by innodapt

innodapt · Jan 13th 2019

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?

innodapt · Dec 11th 2018

Yes, I see that build. But the “Latest Stable Version” link at the upper right corner of this site (the forum) currently points to https://github.com/i-MSCP/imscp/releases/tag/1.5.3 (the original 1.5.3 release)

I should have thought to click the “Releases” tab to make sure there was not a later build.

innodapt · Dec 11th 2018

Quote from Nuxwin

The fix is also in latest released version You should avoid using git version and update to i-MSCP 1.5.3 (build 2018120800) RELEASED

Hmmm… My initial install attempt was based on the “Latest Stable Version” link at the top of this page, but that tgz (which seems to be 1.5.3) exhibited the “SHA384 is not supported…” Composer error. Is the link incorrect, perhaps?

innodapt · Dec 11th 2018

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:

Code

# pkill -KILL -f vlogger
(per errata for 1.4.1)
# service cron stop
# service imscp_daemon stop
# pkill -TERM -f imscp
(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.

innodapt · Dec 11th 2018

Laurent,

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!

innodapt · Jan 10th 2017

Thank you!

Studying the “how it works” now. I have been looking for an opportunity to explore the API.

innodapt · Jan 10th 2017

@Nuxwin

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 10_system_hosts.pl

Code: 10_postfix_transport.pl

# i-MSCP Listener::System::Transport listener file
# Copyright (C) 2015-2017 Laurent Declercq <l.declercq@nuxwin.com>
# and Matthew L. Hill <m.hill@innodapt.com>
#
#
# # # #### # # # #
# # # # # # # # # # #
# ##### # #### ##### ##### #
# # # # # # # # #
# # # ##### # # # # # #
#
#
# This library is free software; you can redistribute it and/or
# modify it under the terms of the GNU Lesser General Public
# License as published by the Free Software Foundation; either
# version 2.1 of the License, or (at your option) any later version.
#
# This library is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
# Lesser General Public License for more details.
#
# You should have received a copy of the GNU Lesser General Public
# License along with this library; if not, write to the Free Software
# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
#
## Allows to add entries in the postfix transport file (eg. /etc/postfix/imscp/transport).
#
package Listener::Postfix::Transport;
use strict;
use warnings;
use iMSCP::Debug;
use iMSCP::EventManager;
use iMSCP::File;
#
## Configuration variables
#
# Path to postfix transport file
my $transportFilePath = '/etc/postfix/imscp/transport';
# Parameter which allow to add one or many entries in the postfix transort file
# Please replace the entries below by your own entries
my @transportFileEntries = (
'recipientdomain.tld relay:my.smtprelay',
'user2@domain.tld smtp:some-other-host'
);
#
## Please, don't edit anything below this line
#
# Listener responsible to add entries in the postfix transport file, once it was built by i-MSCP
iMSCP::EventManager->getInstance()->register(
'afterSetupServerHostname',
sub {
return 0 unless -f $transportFilePath;
my $file = iMSCP::File->new( filename => $transportFilePath );
my $fileContent = $file->get();
unless (defined $fileContent) {
error( sprintf( 'Could not read %s file', $transportFilePath ) );
return 1;
}
my $rs = $file->set( $fileContent.( join "\n", @transportFileEntries )."\n" );
$rs ||= $file->save();
#
#### NEED TO TRIGGER A POSTMAP OF THE TRANSPORT FILE HERE ###
#
}
);
1;
__END__

Display More

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!

innodapt · Dec 29th 2016

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.

innodapt · Dec 29th 2016

Quote from Nuxwin

I see nothing in his report confirming this

Hmmm… Good point.

I will check the behavior on 16.04.1 right now in a VM, but you are wise to ask that question. @UncleSam is offline right now…

innodapt · Dec 29th 2016

@Nuxwin has provided a solution for us Ubuntu users:

Quote from Nuxwin

# 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

Posts by innodapt

1.5.3-2018120800 - Can't locate object method "remove" via package "iMSCP::File" (iMSCP::Service core library)

How safe is to upgrade from 1.3.16 to latest current stable?

How safe is to upgrade from 1.3.16 to latest current stable?

How safe is to upgrade from 1.3.16 to latest current stable?

Error in i-MSCP 1.5.3 - maintenance release (testing) on Ubuntu 18.04

Listener file for adding entries in Postfix transport(5) table

Listener file for adding entries in Postfix transport(5) table

Subdomain: Deletion in progress...

Subdomain: Deletion in progress...

Subdomain: Deletion in progress...