Michail - these things should really be in the bug tracker. You are splattering information everywhere with no consistency making it very difficult to keep track and it takes a lot of time to try and tie it up and then respond correctly. Time which could be better spent on say building the new DMARC plugin that I am trying to do....
We also have this:
https://forums.contribs.org/index.php/topic,54708.0.htmlAnd this:
https://forums.contribs.org/index.php/topic,54571.0.htmlAnd bugs.
Please stick to one thread or bug per topic. They are all essentially related to one issue which is cvm-unix which is the plugin is used by both sqpsmtpd and qpsmtpd.
not on why it doesn't always startup after a crash...
JP can probably correct me if I am wrong on some of the following stuff.
As we stated in 11792 the service will automagically restart.
There is no evidence that it does not. Please refer to the bug for comments.
the reason I'm posting them here is due to the reference in /var/log/qpsmtpd/current about an uninitialized value $ret.
https://github.com/smtpd/qpsmtpd/blob/master/plugins/auth/auth_cvm_unix_localOr /usr/share/qpsmtpd/plugins/auth/auth_cvm_unix_local
Clearly the socket is created or you would get connection failed here.
107 connect(SOCK, sockaddr_un($self->{_cvm_socket})) or do {
108 $self->log(LOGERROR, "skip: socket connection attempt for: $user");
109 return DENY, "authcvm, connection failed";
110 };
Your 'error' is here:
123 my $ret = <SOCK>;
124 my ($s) = unpack("C", $ret);
And correctly returned here:
126 if (!defined $s) {
127 $self->log(LOGERROR, "skip: no response from cvm for $user");
128 return DECLINED;
129 }
Have a read of the code in the plugin.
Yes, it could possibly be considered a bug, but that is really in the plugin which is upstream and they rarely accept patches. The plugin does not stop, and reports the correct error. Why it does not get a return from the socket I do not know - presumably it dies. But the $ret error is effectively log noise.
However, this is still related to cvm-unix used by both qpsmtp and sqpsmtpd so one bug will cover both areas.
We are aware of the cvm-unix issue. We are looking at updating the code but the latest code is not designed to run on Cent 7 and we currently have some build issues. Even then it may not fix the issue and as a result we are also looking at other alternatives to using it. Unfortunately we are all overwhelmed with stuff at the minute so our dev time is limited.
See:
https://bugs.koozali.org/show_bug.cgi?id=11315Note per your previous comments on 11792
Stability regarding the core functionality should be our main concern here. Never had issues with 9.2, could this be a CentOS 7 thing?
It is our main concern. However. We did as much testing as we could before release, but despite multiple calls for support and help we were hampered by lack of users helping us.
We try our best to ensure that things are tested as well as possible, but good QA means lots of testing, and quite simply almost nobody bothered. And now people jump up and down and ask why things were not picked up which is 'irritating'.
This is open source. It is a collective responsibility. That means
everyone is responsible. Not just the few who actually bothered to write the code, and test it.
For anyone experiencing this issues you can do the following to mitigate it:
1. Use full checking on s/qpmsptd - do not bypass any of the filters/plugins that are designed to keep the bad people out
2. Use failban to block multiple login attempts
3. Use Geoip IP or xt_tables to limit attacks
My qpsmtpd geoip:
BadCountries=RU,VN,TF,CN,RO,MX,MY,ID,IR,JP,KR,AR,PH,HK,TH,IL,AE,TW,RS,CO,BO,BD,BG,SN,NG,UA,CZ,LT,SK,IQ,NP,IN,TR,EE,BR,PA
Note - when I first upgraded I had a few of these errors. Since installing fail2ban and geoip I have had none..... YMMV.
We will let users know as and when we have a fix - either an updated cvm rpm, or alternative authentication.