Roundcube and ISPConfig 3 issues with rewriting "localhost" lookup

[jasonmacer]

Good morning everyone.

As a precursor, I am going to also cross post this on the roundcube thread as well. I will change the ending questions, but the premise will remain the same.

I have had ISPConfig3 and roundcube running for quite some time; however, I just this past week actually needed to integrate the ispconfig3 plugin so users could change their passwords. Better late than never, I'd guess.

This server is running CentOS 7.9, and during this process I did upgrade ISPConfig 3 to 3.2.11p2 and PHP was upgraded to 8.1, from 7.4. I also then went back in and install 7.4 and 5.x to handle some other scripts and sites until we can get everything migrated and upgraded to 8.x frameworks.

I did have a few issues with some php 7.4 settings in apache not being removed when I upgraded to 8.1. This kept forcing non-ispconfig3 virtual directories to continue using php 7.4 which meant that roundcube 1.6.x would not work. When I finally figured out it was the /etc/httpd/conf.d/ php conf file AND the /etc/httpd/conf.modules.d/ php conf file I was able to upgrade the links to the new php 8.x nomenclatures and after a httpd restart 1.6.6 start working.

Fast forward to working on roundcube 1.6.6 && ispconfig3 3.2.11p2 && the most recent ispconfig3_plugins.

in the /usr/share/roundcube/plugins/ispconfig3_accounts/config/config.ini.php file I set the following:

$config['identity_limit'] = false;
$config['remote_soap_user'] = 'rcUser';
$config['remote_soap_pass'] = 'rcUserPassword';
$config['soap_url'] = 'https://<SERVER_IP_ADDRESS>:XXXX/remote/';
$config['soap_validate_cert'] = false;

You will notice that the 'soap_url' is looking at a different port. This did cause some problems as I could not find ANYWHERE that said "...the soap api port is the same as your webpanel access port and is set when you run the configure.sh or upgrade.sh script for ispconfig..." Or, something to that effect. I cannot tell you how much time I wasted troubleshooting this. A netstat showed no port 8080 being listened to, though it did show 8081; however, that port did not work either. I actually went back and re-ran the upgrade script as a dry run and when it came to the the port section I figured "What the heck, i'll give my new port a try ..." Suddenly wham, bam, and Bob's your uncle: It worked!

I went back to domain.com/webmail (this is the link on all sites that forwards to roundcube) and attempted to change the password.... it worked! Lo and behold I was amazed and happy, that is until I logged out and then attempted to log back in. Now, for some reason roundcube was giving me an error "Could not connect to data store," and when I checked the logs/errors.log file for roundcube, this is what I saw:

[15-Mar-2024 10:46:58 -0500]: <7jnvgg06> IMAP Error: Login failed for my-user@cooldomain.com against ispconfig.domain.com from . Could not connect to ispconfig.domain.com:143: php_network_getaddresses: getaddrinfo for ispconfig.domain.com failed: Name or service not known in /usr/share/roundcube/program/lib/Roundcube/rcube_imap.php on line 211 (POST /webmail/?_task=login&_action=login)

Now, the biggest issue here is that prior to changing the password for the user, I was able to log in and out for multiple users without any problems; however, after changing one password now I am getting this error. However, when I go through the /usr/share/roundcube/config/config.ini.php and defaults.ini.php the only "imap" login section is in config.ini.php and it is the 'imap_host' variable which is set to 'localhost:143' and no ispconfig.domain.com.

ispconfig.domain.com is not set anywhere so I was able to work around this issue by adding it to /etc/host and after a restart it works again; however, I am trying to figure out why after using this plugin all of the sudden roundcube has stopped looking at 127.0.0.1:143 and is now looking at ispconfig.domain.com:143. Is there an apache variable being set somewhere by the ispconfig roundcube plugin that is causing this? line 211 of the rcube_imap.php file simply is an error setter, and does not actually give much detail. I'm fairly confident that the issue is within the plugin, which is why I am asking here first.

I'm open to thoughts and suggestions.

Thanks, and have a great weekend!

Jason

[Churro]

The Roundcube plugins in this repository do not attempt an IMAP connection and only interact with the SOAP API of ISPConfig. Therefore, it is highly unlikely that an IMAP-related error occurring in Roundcube is related to the use of these plugins. I suspect it's a coincidence that this happened after changing the password, but technically all that's happening is that the plugin is performing the same action as when you change the password in ISPConfig itself. Nothing beyond that.

I would suggest using grep or similar tools to identify files that contain ispconfig.domain.com.

[jasonmacer]

@Churro that thought had also occurred to me and when I "grep -R ispconfig.domain.com /var/www/ispconfig" I get 0 results.

I agree that it does appear to be a coincidence as I can change the ip/domain in the SOAP URL in side the plugin config, it will work again until I change another password and it would do the same thing. The "work around" was to add ispconfig.domain.com into the /etc/hosts file and direct it to the machines public Ip address.

I actually have a grep -R ispconfig.domain.com /var/www/ running now so we'll see if it returns anything.

Something I did not try, and should have, was to see if I was getting the same issues if I opened it in a different browser or in an "incognito" browser. I do not really feel like undoing my changes, but I might need to in order to possibly identify the culprit. If it were to work without issue in either a new browser that hasn't accessed the instance, or in an incognito tab, then there is some variable being set, and it is pulling that ispconfig.domain.com from somewhere.

I'll see what this grep comes up with and at least update this with the results.