Limitations on Deployment HTTP Range Request Download

[Bastian-Krause]

Hi,

we are using hawkBit with RAUC in rauc-hawkbit-updater. In a recent PR, streaming installation of update bundles is implemented: rauc-hawkbit-updater passes the authentication header and the hawkBit deployment download URL to RAUC. RAUC performs HTTP Range Requests (~128 KB range per request, due to NBD reads per squashfs block, see RAUC's streaming docs) while installing the update bundle.

While testing this, I hit these hawkBit errors:

Registered DOS attack! Client [0:0:0:0:0:0:0:1] is above configured READ request threshold (200)!
Cannot assign 1 ActionStatus entities to Action '1' because of the configured quota limit 1000. Currently, there are 1000 ActionStatus entities assigned.

That means hawkBit's default configuration limits HTTP Range Requests effectively to ~1000 requests per action and 200 requests per second. For the time being, I disabled both limitations via:

--hawkbit.server.security.dos.filter.enabled=false
--hawkbit.server.security.dos.maxStatusEntriesPerAction=-1

While this works, I am not so sure if this is the desired approach for our use case. What do you think?

Furthermore, one ActionStatus entity per Range Request is generated, meaning a medium sized update bundle of 150 MB generates >1000 ActionStatuses when requested in 128 KB chunks. Could you elaborate why hawkBit needs to generate an ActionStatus per Range Request? I could not find reasoning in the commits/PRs. Could these Range Request ActionStatuses be dropped maybe? Or made configurable somehow?

[Bastian-Krause]

Can anyone comment on the questions above?

[Bastian-Krause]

A comment on this issue would still be very welcome.

I'd be willing to create a PR to change the ActionStatus behavior for HTTP Range Requests, but only if you tell me whether to drop ActionStatuses for this case entirely or make them configurable.

[MartB]

@Bastian-Krause Is this still a limitation? Would be great to get a comment from the responsible maintainers!

I don't see any issue with dropping the Range Request ActionStatuses so I will change this should I end up deploying hawkbit.

[Bastian-Krause]

@MartB I did not hear back since I opened this issue and I did not see any changes relevant to these issues. A comment would be welcome.

[zyga]

I've also hit this limitation. I think logging action status makes no sense.

In general I would also say that having hawkbit serve the range requests would be best avoided. Ideally there would be a way to provide an URL to a CDN service, to keep the application server out of the loop.