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 [email protected] against ispconfig.domain.com from <MYIPADDRESS>. 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 possibly 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. Or, is this some variable that was set when i setup the server in the initial install script, and has been set somewhere inside the database? I have been through the control panel "DNS", "Tools", and "System" tabs/settings, and am not seeing ispconfig.domain.com being sat in any of the options there. Like I said, I have a work around, but I am still open to thoughts and suggestions as this reaction doesn't seem like it should happen unless somewhere ispconfig.domain.com has been set as the server name somewhere. Thanks, and have a great weekend! Jason
I would be helpfull if you provided the actual config file in question. What is the hostname of the systeme and what is the rDNS Record for the IP?
@pyte please see the following: System: CentOS 7.9 Hostname: vhost001.my-domain.com rDNS: wisp-ip-add-re-ss-city.state.cox.net ISPConfig 3 version: 3.2.11p2 I am assuming the ispconfig3_account plugin config which is what allows the changing of passwords for the email users in ISPConfig3. plugins/ispconfig3_account/config/config.inc.php: <?php $config['identity_limit'] = false; $config['remote_soap_user'] = 'rcUser'; $config['remote_soap_pass'] = 'rcUserPassword'; $config['soap_url'] = 'https://server.my-domain.com:<port>/remote/'; $config['soap_validate_cert'] = false; As I said, when i change the "soap_url" it would start working again UNTIL i set a password again and then it started looking for the "ispconfig.my-domain.com" address, which I do not have setup. I do not know if this is setup during installation/updating script, or even where this is found. I did a very long grep session that actually timed out and never found anything. My workaround was adding "ispconfig.my-domain.com ispconfig" in to the hosts file and giving it the public IP address. What could I be missing that forces the system to start looking for this ispconfig.my-domain.com? :man-facepalming:
If the settings in "config.inc.php" are correct the issue has to be somewhere else in your configuration. No part of the code for this plugin will cause such behaviour. So it's either some weird DNS stuff going on or something else on the system is not setup the way to expect it. Is the hostname set by hostnamectl correct? Is the /etc/hostname and /etc/mailname configured correctly? Are there any entries in the /etc/hosts file that are suspicous? You can try to perform a clean install on a test system and setup the same configuration and see if it causes the same issue, but i highly doubt it.
@pyte Sorry i'm just seeing this, but here goes: hostname = vhost001.my-domain.com hostnamectl = vhost001.my-domain.com /etc/hostname = vhost001.my-domain.com /etc/mailname = <THIS DOES NOT EXIST> /etc/hosts file = To make it work I DID add ispconfig.my-domain.com. This just fixed everything I do not know if not having a "mailname" in there will cause the issue, but I'm almost thinking it is something in the setup script of ispconfig when I first installed it. I will wait for the next update and re-run the script. To me that has to be in a setting somewhere, so I guess I'll just continue looking. Thanks for the reply.
