Topic: Problem modifying sqpsmtpd INSTANCE figure

[toothandnail]

I monitor 6 SME servers. All of them have fail2ban active, and I recently added the geoip/xt geoip contribs to all of them. That cut down quite a bit on the number of fail2ban messages I was getting, though I’m not all that convinced that the whitelist option (!=) works as well as it might.

In the last couple of weeks, three of the servers have started having problems sending mail. After trolling through log files, I found all three suffering lots of

Code: [Select]

Too many connections: 10 >= 10.  Waiting one second
entries in the sqpsmtpd log. All of them are being hit by multiple connections, many of them not even being able to make an SSL connection. As an experiment, I wanted to change the INSTANCES figure in the sqpsmtpd runenv. My attempts to create a template fragment to do that have failed miserably. So far, reading the developer’s manual, I’ve not found where I messed up. I’m hoping someone can give me an example of how it should be done.

To complete the experiment, I edited the live runenv and restarted the service. That allowed mail entered through an email client to be sent, even if sometimes slowly.

While it may only be a temporary improvement, I would like to make the change while I investigate other methods of improving the situation. So I really need a way to make changes to the sqpsmtpd or qpsmtpd INSTANCE figures properly.

[ReetP]

live runenv

Never do things like that....

Have a search for the item you want (or aak first) eg

Code: [Select]

grep -irn instance /etc/e-smith/templates
S/Qpsmtpd

Instances=40
InstancesPerIP=8

Etc.

Email-update

[ReetP]

(You do still have a rocket account at chat.koozali.org....)

[toothandnail]

Never do things like that....

Not something I would normally do, but when my initial attempts to modify the instances failed, it was a quick and easy to undo way of checking whether increasing the avsailable connections would help. If nothing else, it is at best, a short term solution, since the attacks could easily be scaled up, and I don't know how much I could increase the instances without the server starting to run out of resources.

Have a search for the item you want (or aak first) eg

Code: [Select]

grep -irn instance /etc/e-smith/templates
S/Qpsmtpd

Instances=40
InstancesPerIP=8

Etc.

Email-update

I guess I should have put a bit more detail into what I had tried. I located the standard templates for both qpsmtpd and sqpmstpd, built a suitable directory structure under /etc/e-smith/templates-custom and copied a modified version of the INSTANCES file there. I must be missing something - expanding the template did not modify the runenv as I'd hoped. I'm still looking at the manual, hoping to find what I missed, but so far haven't found anythnng useful.  At least my experiment showed that increasing the instances figure stopped the timeout errors people were getting when trying to send mail. How long that will last, I don't know.

I've not dealt much with templates using multiple fragments, so maybe I've missed something there. Still reading, but I was hoping for a hint...

[toothandnail]

(You do still have a rocket account at chat.koozali.org....)

I do. I've been lurking there when I have some free time. I was hoping to become more active, since I've finally managed to get a working bare-metal SME 11 Alpha. Got tied up trying to find a way of fighting these wonderful attacks.

[ReetP]

I must be missing something

Yup.

I was on mobile & had little time to be precise. Needed some extra reading.

No need for templates or meddling.

A grep shows you the config entries required. If you did as suggested you'd see stuff like:

Code: [Select]

/etc/e-smith/templates/var/service/qpsmtpd/runenv/INSTANCES:
2:    return "INSTANCES=" . ($qpsmtpd{Instances} || "40");

/etc/e-smith/templates/var/service/qpsmtpd/runenv/INSTANCES_
PER_IP:2:    return "INSTANCES_PER_IP=" . ($qpsmtpd{Instance
sPerIP} || "5");

/etc/e-smith/templates/var/service/sqpsmtpd/runenv/INSTANCES
:2:    return "INSTANCES=" . ($sqpsmtpd{Instances} || $qpsmt
pd{Instances} || "10");

/etc/e-smith/templates/var/service/sqpsmtpd/runenv/INSTANCES
_PER_IP:3:      ($sqpsmtpd{InstancesPerIP} || $qpsmtpd{Insta
ncesPerIP} || "5");

Shows you possible config entries eg

Code: [Select]

$sqpsmtpd{InstancesPerIP}
So something like:

Code: [Select]

config setprop qpsmtpd Instances 40 InstancesPerIP 10
Then.

Code: [Select]

signal-event email-update
Done.

https://wiki.koozali.org/DB_Variables_Configuration#Qpsmptd


Note - which templates get expanded where & when are determined down in /etc/e-smith/events/whatever

Worth a read and on the wiki or ask on Rocket.

[toothandnail]

So something like:

Code: [Select]

config setprop qpsmtpd Instances 40 InstancesPerIP 10
Then.

Code: [Select]

signal-event email-update
Done.

https://wiki.koozali.org/DB_Variables_Configuration#Qpsmptd


Note - which templates get expanded where & when are determined down in /etc/e-smith/events/whatever

Worth a read and on the wiki or ask on Rocket.

Thanks. That helped a lot. I'd been working my way through the developer's manaual. Changing instances has if not cured the problem on two of the three affected systems, certainly eased it. One of them is still slow sending mail, but it is no longer giving time-outs connecting to the SMTP server. The third system seems to have another problem, which I'm going to have to try and cure. For some reason, after I increaded the Instances and Instances_Per_IP, the logs are showing 10 as the maximum. I had a look and got this result:

Code: [Select]

[root@cygnus ~]# config show sqpsmtpd
sqpsmtpd=service
    Authentication=enabled
    BadCountries=GB
    INSTANCES=50
    INSTANCES_PER_IP=10
    Instances=10
    InstancesPerIP=5
    TCPPort=465
    XTGeoipRev=enabled
    access=public
    status=enabled
I'm going to try resetting the service to default, then try changing the instances again.

[ReetP]

Code: [Select]

    INSTANCES=50
    INSTANCES_PER_IP=10
    Instances=10
    InstancesPerIP=5
Your CAPSLOCK is stuck on.

Do what I said. Don't use CAPS.