Bug 1476379

Summary:	[RFE] Add randomness to SCAP client runs to avoid DDOS of the server
Product:	Red Hat Satellite	Reporter:	Rich Jerrido <rjerrido>
Component:	SCAP Plugin	Assignee:	satellite6-bugs <satellite6-bugs>
Status:	CLOSED ERRATA	QA Contact:	Jameer Pathan <jpathan>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	Unspecified	CC:	bkearney, egolov, jcallaha, ktordeur, mcorr, mhulan, oprazak
Target Milestone:	6.5.0	Keywords:	FutureFeature, Triaged
Target Release:	Unused
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	puppet-foreman_scap_client-0.3.19	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2019-05-14 12:36:36 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Rich Jerrido 2017-07-28 18:22:30 UTC

Description of problem:


As a user, I may have hundreds or potentially thousands of systems associated with a hostgroup. 

As OpenSCAP policies in Satellite are associated with hostgroups, if I have a large number of clients in a hostgroup and an OpenSCAP policy is defined, ALL of  the clients will attempt to upload their OpenSCAP reports at the same time. 


Ideally, I'd like to see some randomness added into the cron job, which allows the clients to splay their reporting. 


Today, an example cron job on a client is 

# HEADER: This file was autogenerated at 2017-07-25 14:19:34 -0400 by puppet.
# HEADER: While it can still be managed manually, it is definitely not recommended.
# HEADER: Note particularly that the comments starting with 'Puppet Name' should
# HEADER: not be deleted, as doing so could cause duplicate cron jobs.
# Puppet Name: foreman_scap_client_1
0 1 * * 1 /usr/bin/foreman_scap_client 1

I'd like it to be similar to the below (which adds a 30-600 second random delay) 

# HEADER: This file was autogenerated at 2017-07-25 14:19:34 -0400 by puppet.
# HEADER: While it can still be managed manually, it is definitely not recommended.
# HEADER: Note particularly that the comments starting with 'Puppet Name' should
# HEADER: not be deleted, as doing so could cause duplicate cron jobs.
# Puppet Name: foreman_scap_client_1
0 1 * * 1 python -c 'from random import randint; from time import sleep; sleep(randint(30,600))' ; /usr/bin/foreman_scap_client 1

lastly, I'd want the range of randomness configurable by the end-user.

Comment 1 Ondřej Pražák 2017-07-31 08:38:36 UTC

Created redmine issue http://projects.theforeman.org/issues/20449 from this bug

Comment 2 Marek Hulan 2017-08-07 13:08:06 UTC

The number can be configured by puppet-foreman_scap_client with default value to 600 so user could still change the configuration by overriding this smart class parameter. The only thing I don't like on this approach is the python code. Maybe we could improve the foreman_scap_client to use sleep function from ruby. We'd pass the interval as optional second argument.

Comment 3 Rich Jerrido 2017-08-22 09:42:56 UTC

(In reply to Marek Hulan from comment #2)
> The number can be configured by puppet-foreman_scap_client with default
> value to 600 so user could still change the configuration by overriding this
> smart class parameter. The only thing I don't like on this approach is the
> python code. Maybe we could improve the foreman_scap_client to use sleep
> function from ruby. We'd pass the interval as optional second argument.

Doens't have to be python. That was just an example.

Comment 4 Satellite Program 2018-07-27 08:02:47 UTC

Moving this bug to POST for triage into Satellite 6 since the upstream issue http://projects.theforeman.org/issues/20449 has been resolved.

Comment 7 Jameer Pathan 2019-01-30 12:09:22 UTC

verified

@satellite 6.5.0 snap 13
@puppet-foreman_scap_client-0.3.19-1.el7sat.noarch

observation:
- randomness added into the cron job, which allows the clients to splay their reporting. 
- the range of randomness configurable by the end-user.

Comment 10 errata-xmlrpc 2019-05-14 12:36:36 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2019:1222