• We value your experience with Plesk during 2024
    Plesk strives to perform even better in 2025. To help us improve further, please answer a few questions about your experience with Plesk Obsidian 2024.
    Please take this short survey:

    https://pt-research.typeform.com/to/AmZvSXkx

  • We are developing a new feature in Plesk that will help you promote your websites or business on social media. We want to conduct a one-hour online UX test to present the prototype and collect feedback. If you are interested in the feature, please book a meeting via this link.
    Thank you in advance!
  • The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.
  • We’re working on enhancing the Monitoring feature in Plesk, and we could really use your expertise! If you’re open to sharing your experiences with server and website monitoring or providing feedback, we’d love to have a one-hour online meeting with you.

Resolved aps-cache task error

@Pleskie,

That is ok, IF your server explodes, we will get some marshmallows and enjoy the bonfire.

And, naturally, I will help to clean up the mess afterwards.

In short, if something is wrong, just mail me.

Ciao!
 
Thanks trialotto, I will keep that in mind :)

One last thing, do you know if it's possible to change the time when the daily tasks are executed? I was thinking ... maybe all of the servers from my hosting company are trying to reach the Plesk server at the same time (since they are based on the same image-installation) and that's what causes the connection error. Maybe it helps if I can change the time when the daily tasks are being executed. Could that be done, and if so how? Hope you can help me with this.
 
@Pleskie,

I would not do so, I would not recommend to change the scheduled (daily or other) tasks.

I will keep track of the issue, since I also have a similar issue somewhere on a server. If the issue gets resolved, then there is no need to change cronjobs.

I will keep you notified, deal?

Regards.....
 
(By the way ... could it cause any problems if you change a cronjob time?)

No, not really.

However, it is "good practice" to have scheduled tasks executed with some time between them, with the time depending on the duration of the scheduled tasks.

For instance, WordPress cronjobs are notorious for using a lot of resources, so (by preference) they should "separated" from other scheduled tasks.

In general, most of the "normal and Plesk related" scheduled tasks can run simultaneously.

That does not imply that it is wise to have them run simultaneously, I will illustrate that.

Consider the case in which you have 5 scheduled backups to a (remote) FTP repository, all starting at 3:15 (or something around that time).

Depending on the size of the backups and the time to create the backup, it can occur that all backups are transferred by FTP at the same time, resulting in transfer problems or failures.

A simple solution would then be to set the scheduled backup tasks 15 minutes apart from each other, i.e. schedule them with 15 minutes between them.

Hope the above helps.

Regards.....

PS I would like a marshmallow now, how is your server? Grinn...
 
No marshmallows yet ;-)

Alright, but what is "wrong" with my idea of changing the time of the daily task routine? (I assume this is only 1 tasks executing severl tasks?). It now starts every night at 4 o clock. I am on a VPS, so other VPS'es in the same datacenter will probably also start at that time. Would it help me if I set my task to start sooner, so it starts before all of the other VPS'es in the datacenter?

(by the way ... I have some @sshole shitting my maillog all day long. If I post a piece of the log, can you see what he is trying to do?)
 
You should not worry about other VPS (the host server and virtualization software take care of that).

The maillog issue: let me guess, a whole lot of line mentioning "unknown[<some IP>]"?

Yeah, I am aware of this "issue": it probably started somewhere around 5th of june and is related to malicious login attempts (yes, attempts, nothing happens, they fail).

Solution: just make sure that your plesk-postfix jail and recidive jail for Fail2Ban is activated.

It is a rather "complicated" distributed attack, so there is still some work in progress, in order to get a "thorough solution" for these kinds of attacks.

Regards...
 
Hi trialotto,

>> You should not worry about other VPS (the host server and virtualization software take care of that).

I understand that, but what I meant is ... if all of the VPS'es start connecting with the Plesk server at the exact same time (since the installations are all based on the same image file) maybe this causes a connection error.

>> Solution: just make sure that your plesk-postfix jail and recidive jail for Fail2Ban is activated.

I did this ... I even adjusted the max retry amount to 2, but Fail2Ban doesn't pick them up.

For example ... here's a piece of my 'maillog' from earlier today:

Jun 14 16:58:19 xxxxx postfix/smtpd[17668]: connect from li1535-136.members.linode.com[139.162.250.136]
Jun 14 16:58:20 xxxxx postfix/smtpd[17668]: SSL_accept error from li1535-136.members.linode.com[139.162.250.136]: Connection reset by peer
Jun 14 16:58:20 xxxxx postfix/smtpd[17668]: lost connection after CONNECT from li1535-136.members.linode.com[139.162.250.136]
Jun 14 16:58:21 xxxxx postfix/smtpd[17668]: disconnect from li1535-136.members.linode.com[139.162.250.136]
Jun 14 16:58:21 xxxxx postfix/smtpd[17668]: connect from li1535-136.members.linode.com[139.162.250.136]
Jun 14 16:58:22 xxxxx postfix/smtpd[17668]: SSL_accept error from li1535-136.members.linode.com[139.162.250.136]: Connection reset by peer
Jun 14 16:58:22 xxxxx postfix/smtpd[17668]: lost connection after CONNECT from li1535-136.members.linode.com[139.162.250.136]
Jun 14 16:58:22 xxxxx postfix/smtpd[17668]: disconnect from li1535-136.members.linode.com[139.162.250.136]
Jun 14 16:58:22 xxxxx postfix/smtpd[17668]: connect from li1535-136.members.linode.com[139.162.250.136]
Jun 14 16:58:24 xxxxx postfix/smtpd[17668]: SSL_accept error from li1535-136.members.linode.com[139.162.250.136]: Connection reset by peer
Jun 14 16:58:24 xxxxx postfix/smtpd[17668]: lost connection after CONNECT from li1535-136.members.linode.com[139.162.250.136]
Jun 14 16:58:24 xxxxx postfix/smtpd[17668]: disconnect from li1535-136.members.linode.com[139.162.250.136]
Jun 14 16:58:24 xxxxx postfix/smtpd[17668]: connect from li1535-136.members.linode.com[139.162.250.136]
Jun 14 16:58:24 xxxxx postfix/smtpd[17668]: SSL_accept error from li1535-136.members.linode.com[139.162.250.136]: -1
Jun 14 16:58:24 xxxxx postfix/smtpd[17668]: warning: TLS library problem: 17668:error:1408A10B:SSL routines:SSL3_GET_CLIENT_HELLO:wrong version number:s3_srvr.c:956:
Jun 14 16:58:24 xxxxx postfix/smtpd[17668]: lost connection after CONNECT from li1535-136.members.linode.com[139.162.250.136]
Jun 14 16:58:24 xxxxx postfix/smtpd[17668]: disconnect from li1535-136.members.linode.com[139.162.250.136]
Jun 14 16:58:24 xxxxx postfix/smtpd[17668]: connect from li1535-136.members.linode.com[139.162.250.136]
Jun 14 16:58:25 xxxxx postfix/smtpd[17668]: lost connection after CONNECT from li1535-136.members.linode.com[139.162.250.136]
Jun 14 16:58:25 xxxxx postfix/smtpd[17668]: disconnect from li1535-136.members.linode.com[139.162.250.136]
As you can see there a several login attempts from IP address 139.162.250.136 but for some reason Fail2Ban doesn't block the IP address. It doesn't even give any notice.

Earlier today I had these attacks in the maillog. I have had them earlier. I don't know what they try to do. Do you know? Also this time Fail2Ban didn't give any notice.
The mail address '[email protected]' pops up a lot of times in these attacks. Also you see somewhere it says 'helo=<YYYYYYYYY>'. The YYYYY was actually the IP address of my server!
What were they trying to do? :-/

Jun 14 14:32:02 xxxxx postfix/smtpd[17366]: connect from 118-161-250-131.dynamic.hinet.net[118.161.250.131]
Jun 14 14:32:03 xxxxx postfix/smtpd[17366]: NOQUEUE: reject: RCPT from 118-161-250-131.dynamic.hinet.net[118.161.250.131]: 454 4.7.1 <[email protected]>: Relay access denied; from=<[email protected]> to=<[email protected]> proto=SMTP helo=<85.214.251.230>
Jun 14 14:32:04 xxxxx postfix/smtpd[17366]: lost connection after RCPT from 118-161-250-131.dynamic.hinet.net[118.161.250.131]
Jun 14 14:32:04 xxxxx postfix/smtpd[17366]: disconnect from 118-161-250-131.dynamic.hinet.net[118.161.250.131]
Jun 14 14:32:04 xxxxx /usr/lib64/plesk-9.0/psa-pc-remote[357]: Message aborted.
Jun 14 14:32:04 xxxxx /usr/lib64/plesk-9.0/psa-pc-remote[357]: Message aborted.
Jun 14 14:35:24 xxxxx postfix/anvil[17368]: statistics: max connection rate 1/60s for (smtp:118.161.250.131) at Jun 14 14:32:02
Jun 14 14:35:24 xxxxx postfix/anvil[17368]: statistics: max connection count 1 for (smtp:118.161.250.131) at Jun 14 14:32:02
Jun 14 14:35:24 xxxxx postfix/anvil[17368]: statistics: max cache size 1 at Jun 14 14:32:02
Jun 14 16:37:33 xxxxx postfix/smtpd[17629]: connect from 220-135-220-150.HINET-IP.hinet.net[220.135.220.150]
Jun 14 16:37:34 xxxxx postfix/smtpd[17629]: NOQUEUE: reject: RCPT from 220-135-220-150.HINET-IP.hinet.net[220.135.220.150]: 454 4.7.1 <[email protected]>: Relay access denied; from=<[email protected]> to=<[email protected]> proto=SMTP helo=<YYYYYYYYY>
Jun 14 16:37:34 xxxxx postfix/smtpd[17629]: lost connection after RCPT from 220-135-220-150.HINET-IP.hinet.net[220.135.220.150]
Jun 14 16:37:34 xxxxx postfix/smtpd[17629]: disconnect from 220-135-220-150.HINET-IP.hinet.net[220.135.220.150]
Jun 14 16:37:34 xxxxx /usr/lib64/plesk-9.0/psa-pc-remote[357]: Message aborted.
Jun 14 16:37:34 xxxxx /usr/lib64/plesk-9.0/psa-pc-remote[357]: Message aborted.
 
@Pleskie,

I have to emphasize first that it is more logical to start a new topic thread, as opposed to mixing a lot of different topics in an existing topic thread.

I understand that, but what I meant is ... if all of the VPS'es start connecting with the Plesk server at the exact same time (since the installations are all based on the same image file) maybe this causes a connection error.

That will certainly not be the case, the host server (hosting the VPSes) will have enough bandwidth.

I did this ... I even adjusted the max retry amount to 2, but Fail2Ban doesn't pick them up.

I adviced to keep specific jails activated, but that is not a guarantee that all malicious traffic gets blocked.

I already mentioned many times, in many topic threads, that the current default Fail2Ban jails (as shipped with Plesk) are in desparate need of some fine-tuning.

However, that fine-tuning is something that is best done on a per-server basis, since every server is slightly different (in many aspects).

Note that the feedback in the form of output from the logs is much appreciated, since I am trying to work out a simple solution for this particular problem.

Regards.....
 
>> I have to emphasize first that it is more logical to start a new topic thread, as opposed to mixing a lot of different topics in an existing topic thread.

Sorry :(

>> That will certainly not be the case, the host server (hosting the VPSes) will have enough bandwidth.

Alright, clear :)

>> Note that the feedback in the form of output from the logs is much appreciated, since I am trying to work out a simple solution for this particular problem.

Can you tell me what happens in the log parts that I posted? Do you know what the hackers are trying to do here? And is there a way to prevent this?
 
Hi Pleskie,

if a thread has been RESOLVED or has been answered to fit your questions on the topic, consider to mark the THREAD AS RESOLVED and show your gratitude to persons who helped you:

=> Important Please, use forum features!

DNWYPjsDQi.gif


=> https://talk.plesk.com/help/like/



You may open as many threads as you like, but you really should not mix up content, so other users on the forum are able to find solutions, answers and work-arounds for their issues more quickly and don't get confused and irritated by threads with all sort of content, which doesn't match the thread title. ;)
 
Back
Top