so i upgraded to ISPC 3.2.6 today, and i'm now getting the following errors in /var/log/maillog fatal: unsupported dictionary type: texthash warning: process /usr/libexec/postfix/smtp pid 42151 exit status 1 Sep 30 22:14:02 dns postfix/master[40982]: warning: /usr/libexec/postfix/smtp: bad command startup -- throttlingerror and mailq shows stuff is backing up, not getting through. anyone see this after the ispconfig_update.sh was run? it didn't give any errors during the update. thanks.
here's a diff between the /etc/postfix/main.cf and main.cf~ files (both have the same the same timestamp, so i'm assuming the ~ file is the previous version (3.2.5) [root@xyz postfix]# diff main.cf main.cf~ 689c689 < smtpd_recipient_restrictions = permit_mynetworks, reject_unknown_recipient_domain, reject_unlisted_recipient, check_recipient_access proxy:mysql:/etc/postfix/mysql-verify_recipients.cf, permit_sasl_authenticated, reject_non_fqdn_recipient, reject_unauth_destination, check_recipient_access proxy:mysql:/etc/postfix/mysql-virtual_recipient.cf, check_recipient_access mysql:/etc/postfix/mysql-virtual_policy_greylist.cf, check_policy_service unixrivate/quota-status --- > smtpd_recipient_restrictions = permit_mynetworks, reject_unknown_recipient_domain, reject_unlisted_recipient, check_recipient_access proxy:mysql:/etc/postfix/mysql-verify_recipients.cf, permit_sasl_authenticated, reject_non_fqdn_recipient, reject_unauth_destination, check_recipient_access proxy:mysql:/etc/postfix/mysql-virtual_recipient.cf, check_sender_access hash:/etc/postfix/sender_checks 698c698 < smtpd_sender_restrictions = check_sender_access proxy:mysql:/etc/postfix/mysql-virtual_sender.cf, check_sender_access regexp:/etc/postfix/tag_as_originating.re, permit_mynetworks, permit_sasl_authenticated, reject_non_fqdn_sender, reject_unlisted_sender, check_sender_access regexp:/etc/postfix/tag_as_foreign.re --- > smtpd_sender_restrictions = check_sender_access regexp:/etc/postfix/tag_as_originating.re, permit_mynetworks, check_sender_access proxy:mysql:/etc/postfix/mysql-virtual_sender.cf, permit_sasl_authenticated, reject_non_fqdn_sender, reject_unlisted_sender, check_sender_access regexp:/etc/postfix/tag_as_foreign.re 700c700 < smtpd_client_restrictions = check_client_access proxy:mysql:/etc/postfix/mysql-virtual_client.cf, permit_inet_interfaces, permit_mynetworks, permit_sasl_authenticated, reject_unauth_pipelining , permit --- > smtpd_client_restrictions = check_client_access mysql:/etc/postfix/mysql-virtual_client.cf, permit_inet_interfaces, permit_mynetworks, permit_sasl_authenticated, reject_unauth_pipelining, permit 726c726 < smtpd_helo_restrictions = permit_mynetworks, check_helo_access regexp:/etc/postfix/helo_access, permit_sasl_authenticated, reject_invalid_helo_hostname, reject_non_fqdn_helo_hostname, check_helo_access regexp:/etc/postfix/blacklist_helo, ,reject_unknown_helo_hostname, permit --- > smtpd_helo_restrictions = permit_mynetworks, check_helo_access regexp:/etc/postfix/helo_access, permit_sasl_authenticated, reject_invalid_helo_hostname, reject_non_fqdn_helo_hostname, check_helo_access regexp:/etc/postfix/blacklist_helo, reject_unknown_helo_hostname, permit 739c739 < smtp_sasl_password_maps = proxy:mysql:/etc/postfix/mysql-virtual_sender-relayauth.cf, texthash:/etc/postfix/sasl_passwd --- > smtp_sasl_password_maps = proxy:mysql:/etc/postfix/mysql-virtual_sender-relayauth.cf, hash:/etc/postfix/sasl_passwd 746,747d745 < smtpd_restriction_classes = greylisting < greylisting = check_policy_service inet:127.0.0.1:10023 i tried changing "texthash" to "hash" in the offchance it was that simple - maybe it worked, but then greylisting starting refusing connections on 10023 tried copying the main.cf~ back to main.cf, and now it's complaining that port 10026 is refused help?
Is CentOS 6 still supported? Change that, and you'll also have to run postmap on any such map files each time they change. Is postgrey running?
thanks for the quick response. did NOT postmap the map files (will try). yes, postgrey is running (restarts with double OKs, and status shows it's running)
ran postmap on the sasl_passwd file, that may have resolved that part. but still getting postgrey issues (i think): Sep 30 22:49:54 dns postfix/smtpd[47960]: warning: connect to 127.0.0.1:10023: Connection refused Sep 30 22:49:54 dns postfix/smtpd[47960]: warning: problem talking to server 127.0.0.1:10023: Connection refused
I'm not sure if CentOS 6 is still supported - 3.2.5 worked fine on it, and it was an upgrade from 3.2.x, and there are still Perfect Server tutorials for CentOS 6.x listed on the tutorial page under ISPConfig, so... ? that said, 3.2.5 was working fine. i updated my CentOS 8 server first, no issues (it has fewer accounts on it, so it was sacrificed first). then i did the CentOS 6 machine, and it didn't complain.
thanks for the help, but I ended up reverting back to 3.2.5 (see another of my posts for that effort). I guess i'll be moving accounts to the newer server sooner than later.
See Centos 8 perfect server guide, I've added some steps for postgrey there, might be that these are required for the old centOS 6 as well: https://www.howtoforge.com/tutorial...l-amavisdnew-spamassassin-clamav-and-postgrey
Centos 6 went EOL 12/20. Given that Centos 8 EOL has been brought forward to 12/21. Time to reconsider which distro to move to? Debian or Ubuntu ISPConfig support appears to be better. Otherwise it's taking your chances with Centos Stream which is not intended to be as stable as 6/7/8 or Debian/Ubuntu LTS.
My CentOS 6 server was a leftover test platform that got put into emergency use overnight - it's what I had built, configured and nearly production ready after a bunch of testing when another server died. Overnight migration and implementation (it was successful, and nearly seamless considering the vast differences in platforms and packages). I had migration plans that a failed motherboard relegated useless. My CentOS 8 Stream server was chosen before the EOL of either version was changed - I had till 2029 to rely on it, and it was still downstream from RHEL (I go back to RHEL3, ran RHEL4 for a LONG time). CentOS has been a stable alternative for me for years, and changing it from downstream of RHEL to upstream with a shorter life expectancy is just distasteful - it's a money grab that I'm betting will go sideways on them and do more damage than good. My plan at this point is to probably convert to RockyLinux (AlmaLinux being an alternative, but I think there will be too much money and corporate influence involved with AlmaLinux, based on it's board members). Both versions are mean to be 1:1 direct binary replacements for CentOS, and therefore should continue to be the low-cost alternative to RHEL for universities, test platforms that feed RHEL environments, and general previous RHEL service providers that don't need a support contract with a large company to get their work done. While having the CentOS founder that put CentOS in the bind its in now heading RockyLinux, they've also put safeguards into the governing body to prevent a repeat of that mess, and the funding sponsors of the site are companies that will benefit from it's existence without having to have it built their way for their purposes. I know ubunto and debian are alternatives, but it's not a learning curve I'm willing to entertain at this point - not saying they're drastically different, just that I didn't want the frustration at this point. And I've been a "community" supporter for a long time, and RH and CentOS fit that bill nicely, and RH was the first Linux variety I sipped on back in the early 90's - I still have some original install CDs around here somewhere Thanks.
I should follow up that Oracle Linux and the free developer licensing for RHEL are options, but both have controlling companies that can (and have) made restrictive decisions based on monetary motives - not likely to get into the same bed as them for the same reasons as AlmaLinux, though more so.
