Re: [gentoo-dev] Signed push & clock drift rejection

[Kent Fredric]

On Mon, 18 Jul 2016 22:21:22 -0400
waltd...@waltdnes.org wrote:

>   I'm amazed that "robust linux servers" are deathly afraid of simply
> setting the time, and being done with it.

There's problems at the software level everywhere that are not so
simply solved.

A more obvious example is in the event your system time gets *ahead* of
real-time.

Then its likely that some actions have been performed that have to only
happen once at a given time, and a time going back in time results in
"double spending" of some seconds, and that's obviously not great.


pgpaUEzP87dAa.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Signed push & clock drift rejection

[waltdnes]

On Mon, Jul 18, 2016 at 11:27:09PM +0300, Andrew Savchenko wrote
> 
> As I wrote earlier in this thread, ntp server is not a guarantee
> that such problems will not happen. If hardware clocked was
> significantly offset during boot, it may take several _hours_ for
> ntp to fix this via clock skew. Apparantly commit may be made
> during these several hours.

  I'm amazed that "robust linux servers" are deathly afraid of simply
setting the time, and being done with it.  And while we're at it, if a
developer is doing development on a server machine, he may have other
problems to worry about.  At home I occasionally manually run a script
that includes the 2 lines...

/usr/bin/sudo /usr/bin/openrdate -n -s ca.pool.ntp.org
/usr/bin/sudo /sbin/hwclock --systohc

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications

Re: [gentoo-dev] Signed push & clock drift rejection

[Bill Kenworthy]

On 19/07/16 07:06, Mart Raudsepp wrote:
> Ühel kenal päeval, E, 18.07.2016 kell 16:25, kirjutas james:
>> On 07/18/2016 03:03 PM, Marc Schiffbauer wrote:
>>> * Rafael Goncalves Martins schrieb am 18.07.16 um 03:12 Uhr:
 On Sat, Jul 16, 2016 at 11:33 AM, Andrew Savchenko  wrote:
> Set it for a minute or two. This will protect from commits from
> really out-of-sync systems (like 14 days mentioned above) and
> will
> keep usablity hight for others.

 I second this "request" :)

 remote: Your system clock is off by 6 seconds (limit 5)
>>>
>>> Why not fix your system clock? No ntpd running?
>>>
>>> Check 'ntpq -pn'
>>>
>>> -Marc
>>>
>>
>> net-misc/openntpd is simple and might do the job well enough, or is
>> net-misc/ntp a hard requirement ?
>>
> 
> or just
> 
> systemctl enable systemd-timesyncd.service
> systemctl start systemd-timesyncd.service
> 
> if you are fortunate enough to run systemd.
> If not, well, some other ntp client indeed, no need to debate fortunes
> further :)
> 
> If there's no RTC clock ticking and syncing during/after suspend,
> something seems off in my experience. Disabled ACPI? :D
> 
> I didn't find any indications of why this is actually a problem in the
> announcement or replies, and I couldn't read the backlog for the
> explanation that I saw might have skimmed through. I think if we want
> to nitpick what the actual drift allowed is, we need to know the
> reasons this restriction is needed and what could be the difference to
> that unspecified potential rsync issue between a seconds of drifts and
> a couple minutes or an hour or so of drift.
> I'm sure infra will adjust if possible and choose what's best :)
> 
> 
> Mart
> 

or configure ntpd appropriately - look into the -g argument to ntpd, or
"tinker panic 0", burst and iburst  in the config file to quickly step
if the error is greater than 1000s.  Chrony has worked better than ntp
for me in libvirt managed qemu instances but may still not sync for
quite awhile.

If you have a raspberry pi or similar (no hwclock) use swclock instead
to prime the system time with a close value - just ran into this on a pi
where the default date (1st Jan 1970) was outside a networks certificate
range so it couldn't get a network connection to set the time so it
could access the network :)  Systemd can do this too - but I have read
(cant find the reference) that its time mechanism is non-standard (who
would have thought!) and is very primitive compared to alternatives -
good enough for non-critical applications though.

BillK

Re: [gentoo-dev] Signed push & clock drift rejection

[Mart Raudsepp]

Ühel kenal päeval, E, 18.07.2016 kell 16:25, kirjutas james:
> On 07/18/2016 03:03 PM, Marc Schiffbauer wrote:
> > * Rafael Goncalves Martins schrieb am 18.07.16 um 03:12 Uhr:
> > > On Sat, Jul 16, 2016 at 11:33 AM, Andrew Savchenko  > > o.org> wrote:
> > > > Set it for a minute or two. This will protect from commits from
> > > > really out-of-sync systems (like 14 days mentioned above) and
> > > > will
> > > > keep usablity hight for others.
> > > 
> > > I second this "request" :)
> > > 
> > > remote: Your system clock is off by 6 seconds (limit 5)
> > 
> > Why not fix your system clock? No ntpd running?
> > 
> > Check 'ntpq -pn'
> > 
> > -Marc
> > 
> 
> net-misc/openntpd is simple and might do the job well enough, or is
> net-misc/ntp a hard requirement ?
> 

or just

systemctl enable systemd-timesyncd.service
systemctl start systemd-timesyncd.service

if you are fortunate enough to run systemd.
If not, well, some other ntp client indeed, no need to debate fortunes
further :)

If there's no RTC clock ticking and syncing during/after suspend,
something seems off in my experience. Disabled ACPI? :D

I didn't find any indications of why this is actually a problem in the
announcement or replies, and I couldn't read the backlog for the
explanation that I saw might have skimmed through. I think if we want
to nitpick what the actual drift allowed is, we need to know the
reasons this restriction is needed and what could be the difference to
that unspecified potential rsync issue between a seconds of drifts and
a couple minutes or an hour or so of drift.
I'm sure infra will adjust if possible and choose what's best :)


Mart

Re: [gentoo-dev] Signed push & clock drift rejection

[Rich Freeman]

On Sat, Jul 16, 2016 at 5:33 AM, Andrew Savchenko  wrote:
>
> On Fri, 15 Jul 2016 18:03:30 + Robin H. Johnson wrote:
>>
>> The tolerances are presently set to:
>> - 5 seconds of clock drift.
>
> Set it for a minute or two. This will protect from commits from
> really out-of-sync systems (like 14 days mentioned above) and will
> keep usablity hight for others.

I'll defer to infra on how much they can accept, but I tend to think
that we can afford to be a bit more liberal.  However, I don't think
we want to accept things like systems coming out of suspend that are
off by hours.

>
>> - 'git push' must be completed in 60 seconds.
>
> Why?! What is wrong if push will take 120 seconds? I often commit
> from quite an old box and git push takes 20-40 seconds, while this
> is within your limits, the margin is not safe.
>
> What if someone needs to commit via 2G GPRS or similar slow network
> link? Afaik we have developers on quite slow and unstable links.
>
> Just set this limit to 5 minutes to make it a sane protection of a
> stale push.
>

Somebody can correct me if I'm wrong, but I'm pretty sure that only
one person can be pushing anything at time.  So, regardless of any
rsync limitations, I'm not sure we really want developers to be
spending 5 minutes doing a push.  That means that if anybody else does
a commit during that 5 minutes they're going to have to rebase it.
For repos that don't get heavy use I think we could be more liberal.


-- 
Rich

Re: [gentoo-dev] Signed push & clock drift rejection

[Ulrich Mueller]

> On Mon, 18 Jul 2016, Rafael Goncalves Martins wrote:

> On Sat, Jul 16, 2016 at 11:33 AM, Andrew Savchenko  wrote:
>> Why such tight requirement? Why not a minute, which will not hurt
>> git, but will help with system _temporarily_ out-of-sync.
>> 
>> Some hardware clocks are real mess and can drift more that for 5
>> seconds in a few days (e.g. when system was shut down). And for NTP
>> it will take time to correct system clock _properly_. While stuff
>> like running ntpdate before ntp server if system is out of sync is
>> possible, but it is not recommended nor possible on some workloads.
>> So IRL NTP may take several hours to sync system properly.
>> 
>> Set it for a minute or two. This will protect from commits from
>> really out-of-sync systems (like 14 days mentioned above) and will
>> keep usablity hight for others.

> I second this "request" :)

> remote: Your system clock is off by 6 seconds (limit 5)

+1

Same here, push was rejected because of 8 seconds clock offset.
This happened shortly after resuming from suspend, so apparently ntpd
had not caught up yet.

Ulrich


pgpXjS8TSWs0Y.pgp
Description: PGP signature

Re: [gentoo-dev] Signed push & clock drift rejection

[Andrew Savchenko]

On Mon, 18 Jul 2016 22:03:35 +0200 Marc Schiffbauer wrote:
> * Rafael Goncalves Martins schrieb am 18.07.16 um 03:12 Uhr:
> > On Sat, Jul 16, 2016 at 11:33 AM, Andrew Savchenko  
> > wrote:
> > > Set it for a minute or two. This will protect from commits from
> > > really out-of-sync systems (like 14 days mentioned above) and will
> > > keep usablity hight for others.
> > 
> > I second this "request" :)
> > 
> > remote: Your system clock is off by 6 seconds (limit 5)
> 
> Why not fix your system clock? No ntpd running?

As I wrote earlier in this thread, ntp server is not a guarantee
that such problems will not happen. If hardware clocked was
significantly offset during boot, it may take several _hours_ for
ntp to fix this via clock skew. Apparantly commit may be made
during these several hours.

Best regards,
Andrew Savchenko


pgpvM1ghkq_nq.pgp
Description: PGP signature

Re: [gentoo-dev] Signed push & clock drift rejection

[james]

On 07/18/2016 03:03 PM, Marc Schiffbauer wrote:

* Rafael Goncalves Martins schrieb am 18.07.16 um 03:12 Uhr:

On Sat, Jul 16, 2016 at 11:33 AM, Andrew Savchenko  wrote:

Set it for a minute or two. This will protect from commits from
really out-of-sync systems (like 14 days mentioned above) and will
keep usablity hight for others.


I second this "request" :)

remote: Your system clock is off by 6 seconds (limit 5)


Why not fix your system clock? No ntpd running?

Check 'ntpq -pn'

-Marc



net-misc/openntpd is simple and might do the job well enough, or is
net-misc/ntp a hard requirement ?

I just use the  default (gentoo) time servers, for now, but perhaps 
using specified servers in different regions might work too?



hth,
James

Re: [gentoo-dev] Signed push & clock drift rejection

[Marc Schiffbauer]

* Rafael Goncalves Martins schrieb am 18.07.16 um 03:12 Uhr:
> On Sat, Jul 16, 2016 at 11:33 AM, Andrew Savchenko  wrote:
> > Set it for a minute or two. This will protect from commits from
> > really out-of-sync systems (like 14 days mentioned above) and will
> > keep usablity hight for others.
> 
> I second this "request" :)
> 
> remote: Your system clock is off by 6 seconds (limit 5)

Why not fix your system clock? No ntpd running?

Check 'ntpq -pn'

-Marc

-- 
0xCA3E7BF67F979BE5 - F7FB 78F7 7CC3 79F6 DF07
 6E9E CA3E 7BF6 7F97 9BE5


signature.asc
Description: PGP signature

Re: [gentoo-portage-dev] [PATCH v2] GitSync.update: respect sync-depth (bug 552814)

[Zac Medico]

On 07/14/2016 11:43 AM, Zac Medico wrote:
> On 07/14/2016 10:08 AM, Brian Dolbec wrote:
>> looks fine
> 
> Pushed:
> 
> https://gitweb.gentoo.org/proj/portage.git/commit/?id=84413bb1dd9df322568ce25efc5b7854a43d03c7
> 

Now optimized to use `git reset --merge`:

https://gitweb.gentoo.org/proj/portage.git/commit/?id=55aef9bf297ef8cbf29921acb454449d01313818
-- 
Thanks,
Zac