Todd C. Miller wrote:
> On Thu, 16 Apr 2020 17:18:15 -0600, "Theo de Raadt" wrote:
>
> > I agree we should try 1 hour.
> >
> > > +#~ * * * * -s -n rpki-client -v && bgpctl
> > > reload
> >
> > I would prefer if you use -ns rather than the two seperate options.
>
>
On Thu, 16 Apr 2020 17:18:15 -0600, "Theo de Raadt" wrote:
> I agree we should try 1 hour.
>
> > +#~ * * * * -s -n rpki-client -v && bgpctl reload
>
> I would prefer if you use -ns rather than the two seperate options.
The option parsing doesn't currently support bundling
On Thu, Apr 16, 2020 at 05:18:15PM -0600, Theo de Raadt wrote:
> Job Snijders wrote:
>
> > In cases where rpki-client for some reason ends up taking longer than an
> > hour, the next execution attempt of the command will be skipped. Better
> > to just try again an hour later, this helps avoid co
Job Snijders wrote:
> In cases where rpki-client for some reason ends up taking longer than an
> hour, the next execution attempt of the command will be skipped. Better
> to just try again an hour later, this helps avoid concurrent rpki-client
> processes crossing streams.
Agree. As discussed p
Now that cron(8) was put on a quick steroids programme, we have new
options available! Awesome work Todd, Theo.
On Mon, Apr 13, 2020 at 02:43:27PM +, Job Snijders wrote:
> I'm reviewing some of the timers associated with the workings of the
> end-to-end propagation from ROA to VRP. I think sug
On Tue, Apr 14, 2020 at 01:05:44PM -0600, Todd C. Miller wrote:
> On Mon, 13 Apr 2020 21:45:21 -0600, Bob Beck wrote:
>
> > Like this one plenty. I think it's ok the values change on reload.
>
> Here's a cleaned up version that includes the man page. The random
> interval can now be one of "~"
On Mon, 13 Apr 2020 21:45:21 -0600, Bob Beck wrote:
> Like this one plenty. I think it's ok the values change on reload.
Here's a cleaned up version that includes the man page. The random
interval can now be one of "~", "low~high", "low~", or "~high" where
if low and/or high are omitted, the a
Bob Beck wrote:
> On Mon, Apr 13, 2020 at 09:23:23PM -0600, Todd C. Miller wrote:
> > On Mon, 13 Apr 2020 20:27:30 -0600, Bob Beck wrote:
> >
> > > In my hearts desire I'd love for "R" to be chosen for each line once at
> > > start
> > > up. (so in
> > > the above example the things are randoml
On Mon, Apr 13, 2020 at 09:23:23PM -0600, Todd C. Miller wrote:
> On Mon, 13 Apr 2020 20:27:30 -0600, Bob Beck wrote:
>
> > In my hearts desire I'd love for "R" to be chosen for each line once at
> > start
> > up. (so in
> > the above example the things are randomly distributed). but not sure ho
On Mon, 13 Apr 2020 20:27:30 -0600, Bob Beck wrote:
> In my hearts desire I'd love for "R" to be chosen for each line once at start
> up. (so in
> the above example the things are randomly distributed). but not sure how har
> d that is..
>
> If it saves code and effort I really think this is only
A couple thoughts:
1) I'm not sure how useful random months or days of the week are, but for
consistency maybe?
2) if I do something like
R * * * * /usr/local/bin/thing1
R * * * * /usr/local/bin/thing2
R * * * * /usr/local/bin/thing3
...
R * * * * /usr/local/bin/thing1000
I still have the th
On Mon, 13 Apr 2020 10:00:52 -0600, Bob Beck wrote:
> +1000. a new random time chosen at cron start.
>
> We see this all the time, and it would be a lot better than the hacks for all
> the things
>
> "R" for random sounds good to me
How about this? If you guys like it I'll update the man page
On Mon, Apr 13, 2020 at 09:56:52AM -0600, Todd C. Miller wrote:
> On Mon, 13 Apr 2020 09:37:14 -0600, "Theo de Raadt" wrote:
>
> > While I understand what RANDOM is trying to do, I am not a fan. I've
> > thought often of an improvement, where the minute marker in a crontab
> > file could be a let
On Mon, 13 Apr 2020 09:37:14 -0600, "Theo de Raadt" wrote:
> While I understand what RANDOM is trying to do, I am not a fan. I've
> thought often of an improvement, where the minute marker in a crontab
> file could be a letter 'R', which indicates the specific random value
> for this cron start.
Reason I don't like 2048 is, 34.1 minutes, why why why.
Should it not be 2047 or 2049? *cough* What's going on is here, is
it should be 3600 - the maximum plausible runtime. But I'm still not
thrilled changing the value there on it's own either.
rpki-client itself shold probably self-prote
I also don't like 2048 value.
Why 2048? Why a power of 2. A value passed on from ancestors?
I think it should be picked more carefully to look like a 'safe window'.
Claudio Jeker wrote:
> I do not use the sleep RANDOM thing because I prefer to have rpki-client
> run always at the same interval (1h) and I just selected a random minute
> in the hour.
While I understand what RANDOM is trying to do, I am not a fan. I've
thought often of an improvement, where t
On Mon, Apr 13, 2020 at 02:43:27PM +, Job Snijders wrote:
> Hi,
>
> I'm reviewing some of the timers associated with the workings of the
> end-to-end propagation from ROA to VRP. I think suggesting to run
> rpki-client only once a day can make for needless brittleness.
>
> Running rpki-client
Stuart Henderson wrote:
> > 30 5 1 * * /bin/sh /etc/monthly
> > #0 * * * * sleep $((RANDOM \% 2048)) &&
> > /usr/libexec/spamd-setup
> >
> > -#0 9 * * * -n sleep $((RANDOM \% 4096)) &&
> > rpki-client -v && bgpctl reloa
> 30 5 1 * * /bin/sh /etc/monthly
> #0 * * * * sleep $((RANDOM \% 2048)) &&
> /usr/libexec/spamd-setup
>
> -#0 9 * * * -n sleep $((RANDOM \% 4096)) &&
> rpki-client -v && bgpctl reload
> +#0 * * *
On Mon, Apr 13, 2020 at 02:43:27PM +, Job Snijders wrote:
> I'm reviewing some of the timers associated with the workings of the
> end-to-end propagation from ROA to VRP. I think suggesting to run
> rpki-client only once a day can make for needless brittleness.
>
> Running rpki-client just onc
Hi,
I'm reviewing some of the timers associated with the workings of the
end-to-end propagation from ROA to VRP. I think suggesting to run
rpki-client only once a day can make for needless brittleness.
Running rpki-client just once a day also results in only making a rsync
fetch attempt once a da
22 matches
Mail list logo
