Plesk update from 10 to 11: SQL engine 'intentionally disabled' not supported

[Michael Pöllinger]

[Res.] Plesk update from 10 to 11: SQL engine 'intentionally disabled' not supported

Hi community.

This is a reopened thread in Plesk Panel 11 due to original post was openend under Plesk 10.
So sorry for quoting so much.

Into my messages log do i see this error after a upgrade of Plesk 11.

Jun 29 11:30:01 serverhost postfix/smtpd[23126]: SQL engine 'intentionally disabled' not supported
Jun 29 11:30:01 serverhost postfix/smtpd[23126]: auxpropfunc error no mechanism available

How could i correct this?

The fix from Nikolay isn´t applicable

As the error message suggests there is no real error and it does not affect mail subsystem.

Plesk 11 uses its own SASL auxprop plugin. Previously used 'sql' plugin is not used anymore, but still present in the system. Unfortunately, both 'sql' plugin and libsasl implementation used in Postfix seem to have bugs. The first one doesn't allow configuration in which it will be simply disabled (and will not emit error messages). The second one has two issues. The first problem is that logging level setup for plugins is not working. The second problem is that a number of default plugins (including 'sql') is always loaded, even if they are not listed in configuration. Combination of these problems results in such error messages.

You could try to "fix" your problem by removing 'sql' SASL auxprop plugin from the system. But I, personally, would not, since I'm not sure of possible adverse effects (at least without testing it first).

P.S. You probably should have posted this thread in Plesk 11 forum section.

And the manually fix from Cheech doesn´t work for me

Hi ,

i had the same issue and i fixed it in this way:

1. Search for smtp.conf: result on my Debian Squeeze System: /usr/lib/sasl2/smtpd.conf and /etc/postfix/sasl/smtpd.conf
2. renamed the /usr/lib/sasl2/smtpd.conf to /usr/lib/sasl2/smtpd.old
3. restart Postfix with /etc/init.d/postfix restart

Now all SQLite error messages are gone and Postfix is still working fine.

Looks like Postfix can only work with one smtp.conf

I tried also to copy the /etc/postfix/sasl/smtpd.conf to /etc/postfix/sasl/smtpd.conf but this was not working.

regards
Cheech

Does anyone have the same problem after Updating from Plesk 10 to 11?

kind regards
Michael

 

[Michael Pöllinger]

Same error here on CentOS 5.8. but without sqlite line

Aug 12 04:59:01 wds70016 postfix/smtpd[12000]: SQL engine 'intentionally disabled' not supported
Aug 12 04:59:01 wds70016 postfix/smtpd[12000]: auxpropfunc error no mechanism available

cat /usr/lib64/sasl2/smtpd.conf

pwcheck_method: saslauthd
mech_list: plain login
saslauthd_version: 2

cat /usr/lib64/sasl2/smtpd.conf

pwcheck_method: auxprop saslauthd
auxprop_plugin: plesk
saslauthd_path: /var/spool/postfix/private/plesk_saslauthd
mech_list: DIGEST-MD5 CRAM-MD5 PLAIN LOGIN
auto_transition: yes
sql_engine: intentionally disabled
log_level: 4

Everything worked fine before updated from Plesk 10 to 11





Some infos i just googled:
MySQL support isn´t installed in postfix per base-repo
To install postfix with mysql support it must be taken from centosplus-repo

yum info postfix
[...]
Installed Packages
Name : postfix
Arch : x86_64
Epoch : 2
Version : 2.8.4
Release : 12052415
Size : 12 M
Repo : installed
Summary : Postfix Mail Transport Agent
License : IBM Public License
Description: Postfix is a Mail Transport Agent (MTA), supporting LDAP, SMTP AUTH (SASL),
: TLS

With MySQL found here:

http://rpmfind.net/linux/RPM/centos...tfix-2.3.3-2.3.centos.mysql_pgsql.x86_64.html

Could someone from parallels give us a recommendation / tip what has been changed and perhaps how we can resolve it?

kind regards
Michael

 

[Nikolay.]

Could someone from parallels give us a recommendation / tip what has been changed and perhaps how we can resolve it?

I explained what changed in the previous post (see above). Sorry for my ignorance, but I don't understand why would you want to "fix" this "issue" when nothing is really broken, and everything is working perfectly?

 

[Michael Pöllinger]

Hi Nikolay.

I´m always sceptical to solutions which say: delete xyz, perhaps it works.
I just wanna have asked if there is an official "Parallels" way to go.

So i followed your suggestion and moved the library libsqlite.so out of /var/lib64/sasl2 and restarted deamons.
It seems now to work correctly.

Sorry if i misjudged your reply, but while i was searching for a solution, a customer called that he couldn´t send mails.
So i thougt thats based on that problem.

Thank you very much for the tip and explanation to solve the problem.

Kind regards
Michael

 

[PleskSpider]

SQL engine 'intentionally disabled' not supported / auxpropfunc error no mechanism...

Yes, I too, would like an official response to this problem.

I assumed a fix would be pushed out by now, as it has been filling my logs with the same messages over and over for weeks. The error is the result of an official Plesk upgrade and deserves an official response as to corrective measures.

Thank you in advance.

 

[PleskSpider]

Bump!

What about it?

 

[DocF]

Same here after upgrading from 10 to 11 on CentOs 6.03.

Nov 16 11:03:57 sirius postfix/smtpd[11757]: SQL engine 'intentionally disabled'
not supported
Nov 16 11:03:57 sirius postfix/smtpd[11757]: auxpropfunc error no mechanism
available
Nov 16 11:11:53 sirius postfix/smtpd[13105]: SQL engine 'intentionally disabled'
not supported
Nov 16 11:11:53 sirius postfix/smtpd[13105]: auxpropfunc error no mechanism
available
Nov 16 11:12:29 sirius postfix/smtpd[13138]: SQL engine 'intentionally disabled'
not supported
Nov 16 11:12:29 sirius postfix/smtpd[13138]: auxpropfunc error no mechanism
available

Any updates on this?

 

[mikescar]

I too would like a supported way to clear this from my logs. I have a server that is becoming unresponsive at random intervals and anything I can get out of /var/log/messages that is not necessary, I would like to fix.

 

[Nikolay.]

It's highly unlikely that you will receive "supported fix" from Parallels in the foreseeable future. You should address your OS vendor to patch bugs in Postfix/libsasl/sql auxprop plugin, since they are the root cause. Or you can simply filter your logs and don't bother with this problem...