SatoriHoshiAiko
commented
2 years ago Hi,
So I ran
./v-rebuild-databases ./v-rebuild-mail-domains
And adjusted Settings in Rainloop to use the server domain as an accessible e-mail, as well as Checked off a couple things with IMAP/SMTP using SSL verification, and also to not outlook for domain.
Change Password works and I no longer get blocked by authentication errors.
The two built in vesta commands managed to correct the bug.
Describe the problem:
/var/log/roundcube/errors.log
DB Error: [1305] FUNCTION roundcube.update_passwd does not exist
Context:
After several installations of multiple hosts, round cube change password plugin fails.
I attempted using Rainloop, which also starts to fail.
It would appear to be SSL related, although I don't know the insides and outs to confirm.
I run 3 separate IP addresses, change password worked on accounts for one IP address, and a second domain on that IP address. I was able to create accounts on a different host with different IP using the mail server of my system hostname for a while.
Noticeably, config.inc.php loses permission and along the path I hav had to chmod the /etc/roundcube folder to 644
I have attempted to minimize sweeping changes to isolate the issue. None of the vestaCP forum suggestions are applicable, this is still an unanswered issue abroad.
Oddly, changing the template from hosting to force-https-php-webmail, immediately breaks it, and setting a domain to "hosting" template corrected it early on.
Eventually however, it fully breaks when adding more hosts, e-mail accounts.
I tried to stay on top of using chown -R on the /home/admin/web folder to make sure it is not a system user problem.
IT worked after fresh install, breaks when changing template, works when changing back to hosting, again configured.inc.php needs file permission changes, works again, works a while for hosts on same IP, works for host on separate IP, adding a new more domains, broken again and the original server domains or working e-mails suddenly are malfunctioned to system wide broken.
One thing I have noticed is that this could be SSL related in that, using roundcube or rain loop on a different host IP, or different certificate, might cause it to break, and then both for the host and/or IP using roundcube, as well as for the origin host that was originally working.
Adding new domains is finicky, it will break when adding new hosts.
Some hosts are configured to use cloudflare Origin SSL, system domain is Let'sEncrypt. This is not of itself an issue because I was able to use a system domain as LE and a second Clouflare Origin SSL on same IP. And even went as far as setting up other cloudflare SSL on other IPs routing behind the server domain as well.
Original domains I can log in but now change password after adding other LE hosts. These newer hosts I cannot even create a new e-mail without authentication failed using correct information.
It this a MySQL issue?
Other noticeable problems..
I tried doing an nginx non-www to www rewrite on e.g. the server domain, traditionally by adding a separate server name for each in server domain.com.nginx.ssl.conf
Redirecting to www breaks this whole exim4, and my thought is that it is going through nginx proxy, being redirected to www at the front end, and then when it reaches exit, there is no existing route for e-mail @www.serverdomain.com
Really frustrating because I am otherwise relying on cloudflare to do the www rewrite with some instability. And actually it needs to be accessible without www. if asked, or else the mail server more or less becomes unfindable. This is just kind of expected behavior, but not enjoyable, it should be possible to redirect www without breaking the exim4 mail routes.
Finally, I have not separated IPs for domain SMTP this go around.
Please help this is so messy and I feel like it should just work without constantly breaking the exim4 or roundcube password change plugin (vesta driver)
Debian 11.2
Recommendation: If the vesta password driver is consistently buggy, would it be possible to force this directly to mySQL without using the failing driver?
Notable, I have not touched the connection to mySQL because of course that breaks things too when e.g. changing root password for mySQL, which this is poor practice but I left it as is in hopes that it would prevent the sudden breakage from all different actions.
file /usr/local/vesta/conf/vesta.conf
WEB_SYSTEM='apache2' WEB_RGROUPS='www-data' WEB_PORT='8080' WEB_SSL_PORT='8443' WEB_SSL='mod_ssl' PROXY_SYSTEM='nginx' PROXY_PORT='80' PROXY_SSL_PORT='443' STATS_SYSTEM='webalizer,awstats' FTP_SYSTEM='proftpd' DNS_SYSTEM='bind9' MAIL_SYSTEM='exim4' ANTIVIRUS_SYSTEM='clamav-daemon' ANTISPAM_SYSTEM='spamassassin' IMAP_SYSTEM='dovecot' CRON_SYSTEM='cron' FIREWALL_SYSTEM='iptables' FIREWALL_EXTENSION='fail2ban' BACKUP_SYSTEM='local' LANGUAGE='en' VERSION='0.9.8' DB_SYSTEM='mysql' UPDATE_HOSTNAME_SSL='yes' DB_PMA_URL='https://satorinet.love/phpmyadmin/' MAX_DBUSER_LEN=80 ALLOW_BACKUP_ANYTIME='yes' NOTIFY_ADMIN_FULL_BACKUP='starchild@satorinet.love'