nod32smfi issues

Hi Marcos, that's not what I was referring to, I was asking for your help in defining:

S:1s;R:1s;E:5m

To meet my server requirements.

 

Hello,
we recommend to set as high values as possible to avoid potential problems. This setting will be described in more detailes in the manual for a new version of NOD32 for LMS available soon.

 

Yah Hi Marcos, I understand that. But I need the help yesterday not tomorrow ... no offense, but this is taking quite a bit of long time.

Can you help me to understand how best to incorporate the settings? How high is too high?

Thanks in advance.

 

There are no specific settings, try using those I mentioned last time. They were advised by our Linux expert.

 

Ok then, so we'll just run with the temp fail connection if filter is unavailable and set the time for sending info from the MTA to the filter to 2 minutes, same 2 minute timeout on waiting for a reply from the filter, and then keeping 5 minutes overall timeout between sending the end-of-message to the filter and waiting for the final acknowledgment.

In your experience, how large a file can these timeout settings permit nod32lms to scan?

 

I haven't done any testing yet, I'd still like to know some statistics on the runs.

Thanks

 

Hello Zhen-Xjell,

I understand that you weren't totally happy with the above replies from Eset. First of all, it would be easier to send a message to support@eset.com if you have a specific issue that needs addressing as it's very difficult for our busy support team to always keep our finger on the pulse with issues discussed on this Forum.

In answer to your question "In your experience, how large a file can these timeout settings permit nod32lms to scan?".... this is a very subjective question which will vary from one user to another. Please allow me to quote a section from our nod32lms user guide:

Chapter 5. NOD32LMS basic configuration

With this setting, sendmail will communicate with the nod32smfi daemon via local (i.e. unix) socket /var/run/nod32smfi.sock. Flag F=T will result in temporary fail connection if the filter is unavailable. Flag T=S:2m defines timeout 2 minutes for sending information from MTA to a filter. Flag T=R:2m defines timeout 2 minutes for reading reply from the filter. Flag T=E:5m means overall timeout 5 minutes between sending end-of-message to filter and waiting for the final acknowledgment.

Note: In case the timeouts for the nod32smfi filter are set too small, Sendmail can temporarily reject the message which will attempt to pass through at a later time. This will lead to the continuous rejection of one and the same message later. In order to avoid the problem, the timeouts have to be set properly. In order to do this, one has to get into account 'confMAX_MESSAGE_SIZE' parameter defined in a sendmail.mc file that will provide not accepting messages bigger than the appropriate parameter value (given in bytes). Taking into account this value and the maximum time for processing of this amount of data by MTA(this can be measured) one can evaluate the appropriate timeouts for nod32smfi filter.

Finally, uncomment and modify the following line in the /etc/mail/sendmail.cf file:

• InputMailFilters=nod32smfi

Since nod32smfi filter can modify the content of the e-mail message body, in case of multiple Sendmail filters, it is good to put the definition of the nod32smfi filter at the end of the filter chain.

Here is a link to the full guide: http://u4.eset.com/manuals/guide_nod32lms.lnx.pdf

So, it's kind of impossible to tell you what Eset would recommend. You can try one of 2 things: start with the minimum default times (Xnod32smfi, S=local:/var/run/nod32smfi.sock, F=T, T=S:2m;R:2m;E:5m) and just keep increasing them and trying again and again until you find the optimum settings or just go for the maximum times: Xnod32smfi, S=local:/var/run/nod32smfi.sock, F=T, T=S:2000m;R:2000m;E:5000m.

I hope this helps you Zhen-Xjell and you'll again think what lovely chaps we are at Eset.

Regards,
Bandicoot.

 

Thanks Bandicoot, I did infact send emails to the address you cite above. I appreciate your help at this point, but my nod32lms license expired as of last week and I'm in the market for a different product now.

As to the socket flags, I know they are standard sendmail flags. However in configuring them, I was seeking some fine tuning instructions from support to help customize the CC installation. Incorrect settings cause loss of email -- a scary thing in production.

Just let me reaffirm to those who read this that I personally have enjoyed nod32 for years. It is a wonderful product. I also appreciate that nod32 was involved in our 100,000 registered member contest giveaway:

http://castlecops.com/postlite64005-.html

Thanks for your time.

 

Ok, I'd like to thank NOD32 for picking this back up and working with me. My wife and I just had our first born child and so I put debugging this on the side. However, if possible I'd like to start this up again and fine tune those parameters. Are the new defaults enough? Is there a mechanism today that will queue emails if the socket fails instead of losing them?

Thanks, and I look forward to a wonderful conclusion.

 

Hello Mr. Xjell (and congrats to you and your wife for the new baby!)

Here is a link: http://www.elandsys.com/resources/sendmail/libmilter/ that is a link for the Sendmail folks. I think you'll find this should cover all the questions that you've asked.

So the answer to your question is (from the link above): If a filter is unavailable, or unresponsive, and no flags have been specified, the MTA will continue normal handling of the current connection.

This means the line inside the sendmail configuration file has to be, in this case, as follows:

Xnod32smfi, S=local:/var/run/nod32smfi.sock, T=S:1s;R:1s;E:5m

In this case, if the filter is unavailable, the message will be processed in the normal way but will not be scanned by nod32.

Just to recap on your original question: We don't know whether defaults are enough as this depends on the CPU of your machine and its 'load' by other applications (other than NOD32LMS). We recommend to consecutively move up the limits from the configuration as I detailed in my last post.

Regards,
Bandicoot.

 

Thanks. So let me just confirm a final time, the problem I had before when the socket was no longer available and emails were then lost is no longer apparent?

 

The point is that once the filter will not be available, the e-mail will not be scanned. This means that any possible virus inside will not be cleaned, etc.

Bandicoot.

 

So then any emails being sent from the server will be sent without scanning, and will not be lost? I can test this by shutting down the socket?

 

Yes.

Bandicoot.

 

Ok I'll start running tests today.

 

Actually I'm going to go with the "default" settings you quoted earlier:

T=S:1s;R:1s;E:5m has always caused me issues, so I'm attempting T=S:2m;R:2m;E:5m now. I'll monitor thruout the day.

/me crosses fingers

 

Ok, when nod32smfi socket exists, all is well. When I shut it down (not waiting for it to die), any emails that try to go out get this message:

Apr 15 19:06:03 bugsbunny sm-mta[32640]: j3FN63VD032640: Milter (nod32smfi): local socket name /var/run/nod32smfi.sock unsafe
Apr 15 19:06:03 bugsbunny sm-mta[32640]: j3FN63VD032640: Milter (nod32smfi): to error state
Apr 15 19:06:03 bugsbunny sm-mta[32640]: j3FN63VD032640: Milter: initialization failed, temp failing commands


Basically a "paul@castlecops.com: 4.3.2 Please try again later" message.

In /var/spool/clientmqueue I get this from that message (snippets):

Deferred: 451 4.3.2 Please try again later

So the email did not go out, and there is nothing waiting in /var/spool/mqueue.

So at this point I'm clearing the clientmqueue:

sendmail -Ac -v -q

 

The socket is still present and no problems as yet.

Question... do you have a shell script which can be cron'd to monitor the health of the socket?

 

Another update, so far so good still:

T=S:2m;R:2m;E:5m seems to work well.

Last night I moved the servers and rebooted them via a planned outage. I forgot to include nod32smfi in the rc3.d folder, but upon startup all is well.

Any word on a monitoring script?

 

Firstly, I hope you mean daemon nod32smfi, not socket. Socket /var/run/nod32smfi.sock is the so called socket file that is used for communication between daemon nod32smfi and sendmail Mail Transfer Agent.

Anyway, in here is a short script called 'wake_up' that can be used to wake up daemon nod32smfi after it dies:

#!/bin/sh

loc_daemon_start_flag=0

ps -C nod32smfi > /dev/null
retval1=$?
if [ "$retval1" = "1" ]
then
if [ -s /sbin/startproc ]
then
/sbin/startproc /usr/sbin/nod32smfi >/dev/null
loc_daemon_start_flag=1
fi

if [ "$loc_daemon_start_flag" = "0" ]
then
/sbin/service nod32smfi start >/dev/null
fi
fi

In order to do this, it's necessary to write into crontab table (crontab -e) the follwoing line:

* * * * * path_to_wake_up_script

where path_to_wake_up_script is the absolute path to the script from an attachment. After this, the periodical scheduler will run the script every minute, that will look into the status of nod32smfi daemon (whether it's alive
or dead) and invoke a new process if necessary.

Bandicoot.

 

Ahh yes master Bandicoot... daemon nod32smfi and socket nod32smfi.sock. I'm learning how to function with little sleep lately....

Thanks for the shell script. Much nicer than what I would have done. Shall install after "some sleep" and will report back.

 

Today it went...

May 19 12:08:52 bugsbunny sm-mta[26344]: j4JG8qD4026344: Milter (nod32smfi): to error state
May 19 12:08:52 bugsbunny sm-mta[26344]: j4JG8qD4026344: Milter: initialization failed, temp failing commands
May 19 12:08:53 bugsbunny sm-mta[26345]: j4JG8rDX026345: Milter (nod32smfi): error connecting to filter: Connection refused by /var/run/nod32smfi.sock

Even tho nod32smfi.sock existed, the connection was being dropped:

service nod32smfi restart
Stopping Sendmail's filter for NOD32: nod32smfi [FAILED]
Starting Sendmail's filter for NOD32: nod32smfi [ OK ]

I don't have the cron in place yet.

 

Well, the good news is, we've found a bug in the nod32smfi source code. The bad news is, it's not directly the problem you're having. The 2nd good news is you can help us to trace the problem which may also resolve your issue. We'll send you a debugged nod32smfi binary if you could refresh my memory as to what Linux system you're using and what version please?

Bandicoot.

 

Ok I'll take a good spanking. I've missed your reply entirely. My apologies!

Yes I'm very glad to help if its not _way too late_.

I was finding this thread to reply that I'm not running the cron script and its only failed once or twice since my last post (nod32smfi).

I'm thinking of fine tuning the sendmail.cf settings to help it from shutting down.

Anyway, I'm glad you found a bug.

Redhat Linux:

NOD32 Update Mirror Creator, Version 2.07,
(C) 2004 Eset, s.r.o.
Update started on 09-16-2005, 19:22:00.
Checking remote update packages at 'www.nod32.com'... ok / 2k (100%)
Checking local update packages in '/path/to/mirror/'... ok (17 nups found).
Local copy is up to date.
Update finished at 19:22:01, total time: 1 sec (00:00:01).

NOD32 Antivirus System Update, Version 2.01,
(C) 2004 Eset, spol. s r.o.

Installed version:
Virus signature database version: 1.1219 (20050916)
Virus signature database build: 6110

Update launched: Fri Sep 16 19:22:01 2005

+-+-------------------------------+---------------------+---------------------+
| | Module | Available version | Installed version |
+-+-------------------------------+---------------------+---------------------+
| | Virus signature database | 1.1219 (6110) | 1.1219 (6110) |
| | Advanced heuristics | 1.018 (108 | 1.018 (108 |
| | Archive support | 1.034 (1132) | 1.034 (1132) |
| | pwscan | 1.001 (1012) | 1.001 (1012) |
| | utilmod | 1.008 (1066) | 1.008 (1066) |
| | charon | 1.002 (1037) | 1.002 (1037) |
+-+-------------------------------+---------------------+---------------------+

 

Hello Zhen-Xjell,

That's OK. Must be that new baby of yours keeping you busy!

I would recommend that you upgrade to the latest version 2.16-2 and if nod32smfi is still dying, I can send you a binary with debugging symbols. I don't think I've got your email address, so if you could drop a line to support@eset.us, I'll send it to you.

In the near future, we plan to release a brand new nod32ls version, where all the code is re-written, but it may help now if we find a bug in the old code.

Bandicoot.