I m facing issues in schedules. I have a user in the Asia/Dubai timezone that has created a schedule for Thu., Oct. 17 2019, 1:00 AM Asia/Dubai timezone, custom repeat every 4 weeks on thursday.
As the result I see …
First Run: Thu, Oct 17, 2019 1:00 AM +04
Next Run: Fri, Oct 18, 2019 1:00 AM +04
where both is supposed to be Thu, Oct 17, 2019 1:00 AM +04, as it is when configuring the same schedule for 8:00 AM. Please see screenshot below:
I’m sorry, I may have been too imprecise. The mentioned user account has the timezone Asia/Dubai applied and the schedule set up in that timezone as well.
The issue is that the next run is scheduled for Fri, Oct 18 instead of Thu, Oct 17. That seems to happen only when the time of the schedule is configured to 1:00 AM but not when configured to e.g. 8:00 AM as you can see in the screenshot.
The OS set up to run in Europe/Berlin (CET) timezone.
As suggested in the post you must run your OS in UTC and setup the user timezone within the GSA everything else will shift the UTC timezone and mess your schedules up.
Do debug this issue please open the details page of the wrong displayed scheduled and take a look at the http requests of the details page. There should be some request with cmd=get_schedule&schedule_id=<uuid-of-the-schedule>. If you take a look at the plain response (e.g. by opening the request in another tab) you can check the ical data of your schedule.
but has a different <next_time> than the one in the GSA GUI. Nevertheless it is not the expected schedule of Thursday 1:00 AM GST recurring every 4 weeks.
I did some further investigation and it looks to me that the issue seems to come up in other east bound timezone configurations as well in case the UTC first day of start is a day earlier than the origin timezone first day of start.
I have not noted that the OS needs to run in UTC in addition to the fact that everything internally is UTC. I have earlier today changed the OS to run in UTC but with no change in the reported behaviour.
Startdate is 20191016T210000Z (timezone is UTC).
Your recurrence rule is RRULE:FREQ=WEEKLY;INTERVAL=4;BYDAY=TH which means thursday every 4 weeks. So next run date in ical format is 2019-10-17T21:00:00Z.
Therefore 2019-10-17T01:00:00+04:00 as start date and 2019-10-18T01:00:00+04:00 as next run date seems to be correct technically.
So if I got you correct that would mean that for recurrence configured in schedules, UTC needs to be considered.
In my case I would need to configure BYDAY=WE to have the scan been executed as expected on Thursdays. In addition it may happen that I need to change recurrence settings once DST changes apply. Did I get that the right way?
The ical data is always stored in UTC because getting the timezone information into the ical data is very very error prone and can lead to a lot of issues. Therefore selecting a weekday is always based on the corresponding UTC datetime. But I would also consider this as a bug in our software.
Well from a users perspective I would call it a bug or at least a huge step back compared to previous versions of OpenVAS/GVM as this has worked like a charm.
Anyway, thanks a lot for helping me to identify the cause.
Btw. it wasn’t possible to run a schedule on a specific workday before GVM 10. But of course this bug broke the run every X week use case for specific timezones.
