Re: request for testing: bootstrapping time
On Mon, Jun 03, 2019 at 10:18:38AM -0400, sven falempin wrote:
> On Mon, Jun 3, 2019 at 1:44 AM Otto Moerbeek wrote:
> >
> > Hi,
> >
> > If you ever wanted to be more involved in OpenBSD here's a chanche:
> >
> > https://marc.info/?l=openbsd-tech=155950103825035=2
> >
> > It requires setting up a test machine running a recent snapshot, so
> > that's a nice first step. Then get the sources and apply the patch,
> > build and test
> >
> > You'll find help getting src and bulding the system in the FAQ.
> >
> > Much appreciated!
> >
> > -Otto
> >
>
> Dear readers,
>
> I'd like to share some result regarding ntpd , I did not yet configure
> DNSSEC and will try that later.
> I use a local unbound, and have some issue regarding time on some devices.
>
> on 6.0 I was unable to use constraint: it was not working.
> my current production version is 6.4, and I have 'problems' similar to
> the one nicely explain above,
> I still feel like a STDERR warning would be nice for -s flag failure,
> because reading log in rcctl like management script
> when time is not set is 'incomplete'.
>
> This is an important feature to TEST. ( thank you Otto for working on ntpd )
>
> I m running a slightly modified HEAD version in the test, see __why not__
> this is a * pre test *
>
> First I stopped ntpd and changed the date , then run with -ds
>
> badblock# rcctl stop ntpd && date 20180603.00 && ntpd -s
> ntpd(ok)
> Sun Jun 3 00:00:00 EDT 2018
> ntp engine ready
> trying to resolve www.google.com
> resolve www.google.com done: 2
> trying to resolve pool.ntp.org
> resolve pool.ntp.org done: 4
> constraint request to 2607:f8b0:4020:804::2004
> constraint request to 172.217.13.196
> tls connect failed: 2607:f8b0:4020:804::2004 (www.google.com):
> connect: No route to host
> no constraint reply from 2607:f8b0:4020:804::2004 received in time,
> next query 900s
> constraint reply from 172.217.13.196: offset 31567971.561072
> reply from 206.108.0.131: offset 31567971.791870 delay 0.016370, next query
> 8s
> set local clock to Mon Jun 3 08:53:04 EDT 2019 (offset 31567971.791870s)
> reply from 154.11.146.39: offset 15783985.894667 delay
> 31567971.873626, next query 5s
> reply from 209.115.181.107: offset 15783985.890166 delay
> 31567971.885181, next query 7s
> reply from 205.206.70.2: offset 15783985.888720 delay
> 31567971.886449, next query 6s
> reply from 154.11.146.39: offset -0.000489 delay 0.082025, next query 6s
> reply from 205.206.70.2: offset -0.011286 delay 0.087997, next query 6s
> reply from 206.108.0.131: offset 0.003587 delay 0.022641, next query 8s
> reply from 209.115.181.107: offset -0.006413 delay 0.091241, next query 9s
> reply from 154.11.146.39: offset 0.013697 delay 0.110286, next query 7s
> reply from 205.206.70.2: offset -0.010733 delay 0.091208, next query 9s
> reply from 206.108.0.131: offset 0.010468 delay 0.036784, next query 9s
> reply from 209.115.181.107: offset -0.01 delay 0.096816, next query 8s
> peer 154.11.146.39 now valid
>
> as we can read here in basic scenario the constraint will force the
> setup, when everything s fine, ….everything s fine !
> Assuming you have a nicely place anchor
> Let 's do : echo 'block on egress proto {tcp,udp} from any to any port
> ntp' | pfctl -f - -a 'top'
> or echo 'block on egress proto {tcp,udp} from any to any port ntp' >>
> /etc/pf.conf && pfctl -f /etc/pf.conf in a default setup.
> Things can get more interesting. I m not sure why but I had to modify
> my /etc/hosts to force ipv4 , no matter.
> Nevertheless:
>
> badblock# ntpd -sd
> ntp engine ready
> trying to resolve www.google.com
> resolve www.google.com done: 1
> trying to resolve pool.ntp.org
> resolve pool.ntp.org done: 4
> constraint request to 172.217.13.132
> constraint reply from 172.217.13.132: offset 31568246.201761
> set local clock to Sun Jun 3 00:42:25 EDT 2018 (offset 0.00s)
>
> ^Cntp engine exiting
> Terminating
> badblock# date
> Sun Jun 3 00:42:35 EDT 2018
> badblock# ntpd -sd
> ntp engine ready
> trying to resolve www.google.com
> resolve www.google.com done: 1
> trying to resolve pool.ntp.org
> resolve pool.ntp.org done: 4
> constraint request to 172.217.13.132
> constraint reply from 172.217.13.132: offset 31568246.593501
> set local clock to Sun Jun 3 00:42:39 EDT 2018 (offset 0.00s)
> ^Cntp engine exiting
> Terminating
>
> The clock suddenly refuse to be set up correctly with the HTTP header.
> And it is logged that clock is set : set local clock to Sun Jun 3
> 00:42:39 EDT 2018 (offset 0.00s)
> wrongly.
>
> Given the above proposition, the ULTRA_VIOLENCE mode may not be working
> as the clock wont be offset by the http header.
>
> I hope this *pretest* log may help other user to test this important
> bootstrapping.
> The above result is for me a problem, and I will have to thwart this
> first ( and find time for DNSSEC setup).
>
> NB: it is possible to have a network where HTTPS is
Re: request for testing: bootstrapping time
On Mon, Jun 3, 2019 at 1:44 AM Otto Moerbeek wrote:
>
> Hi,
>
> If you ever wanted to be more involved in OpenBSD here's a chanche:
>
> https://marc.info/?l=openbsd-tech=155950103825035=2
>
> It requires setting up a test machine running a recent snapshot, so
> that's a nice first step. Then get the sources and apply the patch,
> build and test
>
> You'll find help getting src and bulding the system in the FAQ.
>
> Much appreciated!
>
> -Otto
>
Dear readers,
I'd like to share some result regarding ntpd , I did not yet configure
DNSSEC and will try that later.
I use a local unbound, and have some issue regarding time on some devices.
on 6.0 I was unable to use constraint: it was not working.
my current production version is 6.4, and I have 'problems' similar to
the one nicely explain above,
I still feel like a STDERR warning would be nice for -s flag failure,
because reading log in rcctl like management script
when time is not set is 'incomplete'.
This is an important feature to TEST. ( thank you Otto for working on ntpd )
I m running a slightly modified HEAD version in the test, see __why not__
this is a * pre test *
First I stopped ntpd and changed the date , then run with -ds
badblock# rcctl stop ntpd && date 20180603.00 && ntpd -s
ntpd(ok)
Sun Jun 3 00:00:00 EDT 2018
ntp engine ready
trying to resolve www.google.com
resolve www.google.com done: 2
trying to resolve pool.ntp.org
resolve pool.ntp.org done: 4
constraint request to 2607:f8b0:4020:804::2004
constraint request to 172.217.13.196
tls connect failed: 2607:f8b0:4020:804::2004 (www.google.com):
connect: No route to host
no constraint reply from 2607:f8b0:4020:804::2004 received in time,
next query 900s
constraint reply from 172.217.13.196: offset 31567971.561072
reply from 206.108.0.131: offset 31567971.791870 delay 0.016370, next query 8s
set local clock to Mon Jun 3 08:53:04 EDT 2019 (offset 31567971.791870s)
reply from 154.11.146.39: offset 15783985.894667 delay
31567971.873626, next query 5s
reply from 209.115.181.107: offset 15783985.890166 delay
31567971.885181, next query 7s
reply from 205.206.70.2: offset 15783985.888720 delay
31567971.886449, next query 6s
reply from 154.11.146.39: offset -0.000489 delay 0.082025, next query 6s
reply from 205.206.70.2: offset -0.011286 delay 0.087997, next query 6s
reply from 206.108.0.131: offset 0.003587 delay 0.022641, next query 8s
reply from 209.115.181.107: offset -0.006413 delay 0.091241, next query 9s
reply from 154.11.146.39: offset 0.013697 delay 0.110286, next query 7s
reply from 205.206.70.2: offset -0.010733 delay 0.091208, next query 9s
reply from 206.108.0.131: offset 0.010468 delay 0.036784, next query 9s
reply from 209.115.181.107: offset -0.01 delay 0.096816, next query 8s
peer 154.11.146.39 now valid
as we can read here in basic scenario the constraint will force the
setup, when everything s fine, ….everything s fine !
Assuming you have a nicely place anchor
Let 's do : echo 'block on egress proto {tcp,udp} from any to any port
ntp' | pfctl -f - -a 'top'
or echo 'block on egress proto {tcp,udp} from any to any port ntp' >>
/etc/pf.conf && pfctl -f /etc/pf.conf in a default setup.
Things can get more interesting. I m not sure why but I had to modify
my /etc/hosts to force ipv4 , no matter.
Nevertheless:
badblock# ntpd -sd
ntp engine ready
trying to resolve www.google.com
resolve www.google.com done: 1
trying to resolve pool.ntp.org
resolve pool.ntp.org done: 4
constraint request to 172.217.13.132
constraint reply from 172.217.13.132: offset 31568246.201761
set local clock to Sun Jun 3 00:42:25 EDT 2018 (offset 0.00s)
^Cntp engine exiting
Terminating
badblock# date
Sun Jun 3 00:42:35 EDT 2018
badblock# ntpd -sd
ntp engine ready
trying to resolve www.google.com
resolve www.google.com done: 1
trying to resolve pool.ntp.org
resolve pool.ntp.org done: 4
constraint request to 172.217.13.132
constraint reply from 172.217.13.132: offset 31568246.593501
set local clock to Sun Jun 3 00:42:39 EDT 2018 (offset 0.00s)
^Cntp engine exiting
Terminating
The clock suddenly refuse to be set up correctly with the HTTP header.
And it is logged that clock is set : set local clock to Sun Jun 3
00:42:39 EDT 2018 (offset 0.00s)
wrongly.
Given the above proposition, the ULTRA_VIOLENCE mode may not be working
as the clock wont be offset by the http header.
I hope this *pretest* log may help other user to test this important
bootstrapping.
The above result is for me a problem, and I will have to thwart this
first ( and find time for DNSSEC setup).
NB: it is possible to have a network where HTTPS is possible but NTP
blocked or invalid (or hacked), and
/etc/ssl/cert.pem + a valid ip/domain ( why not constraint https://a
valid ip/ ) trust level is above the BIOS for me.
Best.
tl;dr
And by the way, restricting or having custom certificate would be a
strong feature ntpd -c /etc/ssl/restricted.pem ,
also
Re: Request for testing
On Fri, Jan 04, 2019 at 06:42:18PM +0100, Otto Moerbeek wrote: > On Fri, Jan 04, 2019 at 06:31:50PM +0200, Mihai Popescu wrote: > > > > 2. Apply diff, build and install userland. > > Is Xenocara/X considered as userland? > > > > > MALLOC_OPTIONS=++ chrome > > Do one needs to compile chromium port for this? > > > > I can do some testing of application, but I am not sure if I can > > finish kernel/userland compile actions correctly. > > > > ATM you need to build the base system, but no need to build chrome if you > install it from a snap. > > But this diff will be in snaps soon, so then it amounts to installing > a snap and making sure yourt packages are up to date (as old packages > may use an older libc without the diff). > > -Otto > The diff is in snaps. You can use snaps dated later than now for testing. -Otto
Re: Request for testing
On Fri, Jan 04, 2019 at 06:31:50PM +0200, Mihai Popescu wrote: > > 2. Apply diff, build and install userland. > Is Xenocara/X considered as userland? > > > MALLOC_OPTIONS=++ chrome > Do one needs to compile chromium port for this? > > I can do some testing of application, but I am not sure if I can > finish kernel/userland compile actions correctly. > ATM you need to build the base system, but no need to build chrome if you install it from a snap. But this diff will be in snaps soon, so then it amounts to installing a snap and making sure yourt packages are up to date (as old packages may use an older libc without the diff). -Otto
Re: Request for testing
> 2. Apply diff, build and install userland. Is Xenocara/X considered as userland? > MALLOC_OPTIONS=++ chrome Do one needs to compile chromium port for this? I can do some testing of application, but I am not sure if I can finish kernel/userland compile actions correctly.
Re: Request for testing
On Fri, Jan 04, 2019 at 02:23:19PM +0100, Otto Moerbeek wrote: > I'm looking for tests that cover a variety of use-cases. So use > whatever multi-threaded applications you would normally use. Play with > the options mentioned in the test request and report your findings. > > -Otto > Sorry I didn't get back to you. Some things came up ... and out. Ate the wrong thing at a party. I will update -current and try to get something out. Pun intended. Could you actually name some applications that are right for what you need. Or explain how to get that out of ports? Thanks, Chris Bennett
Re: Request for testing
On Fri, Jan 04, 2019 at 03:52:31PM +0300, Consus wrote: > On 13:05 Fri 04 Jan, Otto Moerbeek wrote: > > On Fri, Jan 04, 2019 at 01:05:37PM +0300, Consus wrote: > > > > > On 08:17 Fri 04 Jan, Otto Moerbeek wrote: > > > > Hi, > > > > > > > > If you ever thought about getting more involved and learning a bit > > > > about buikdling a current OpenBSD, there's a call for testing at > > > > > > > > https://marc.info/?l=openbsd-tech=154521488707434=2 > > > > > > > > Testing would provide me with valuable data about performance of > > > > memory management in multi-threaded applications. > > > > > > Whay kind of performance (e.g. more/less responssive application)? Any > > > particular improvements should be looked for? Does number of CPUs > > > matter? > > > > > > > Responsiveness would be a main thing to look for. You might also have > > some other benchmark. Number of CPUs likely matters, that's one of the > > things I'm trying to find out. > > > > -Otto > > Okay, I'll test some stuff on Ryzen 1800X by the end of this week. If > you have some particular test in mind, shoot. > I'm looking for tests that cover a variety of use-cases. So use whatever multi-threaded applications you would normally use. Play with the options mentioned in the test request and report your findings. -Otto
Re: Request for testing
On 13:05 Fri 04 Jan, Otto Moerbeek wrote: > On Fri, Jan 04, 2019 at 01:05:37PM +0300, Consus wrote: > > > On 08:17 Fri 04 Jan, Otto Moerbeek wrote: > > > Hi, > > > > > > If you ever thought about getting more involved and learning a bit > > > about buikdling a current OpenBSD, there's a call for testing at > > > > > > https://marc.info/?l=openbsd-tech=154521488707434=2 > > > > > > Testing would provide me with valuable data about performance of > > > memory management in multi-threaded applications. > > > > Whay kind of performance (e.g. more/less responssive application)? Any > > particular improvements should be looked for? Does number of CPUs > > matter? > > > > Responsiveness would be a main thing to look for. You might also have > some other benchmark. Number of CPUs likely matters, that's one of the > things I'm trying to find out. > > -Otto Okay, I'll test some stuff on Ryzen 1800X by the end of this week. If you have some particular test in mind, shoot.
Re: Request for testing
On Fri, Jan 04, 2019 at 01:05:37PM +0300, Consus wrote: > On 08:17 Fri 04 Jan, Otto Moerbeek wrote: > > Hi, > > > > If you ever thought about getting more involved and learning a bit > > about buikdling a current OpenBSD, there's a call for testing at > > > > https://marc.info/?l=openbsd-tech=154521488707434=2 > > > > Testing would provide me with valuable data about performance of > > memory management in multi-threaded applications. > > Whay kind of performance (e.g. more/less responssive application)? Any > particular improvements should be looked for? Does number of CPUs > matter? > Responsiveness would be a main thing to look for. You might also have some other benchmark. Number of CPUs likely matters, that's one of the things I'm trying to find out. -Otto
Re: Request for testing
On 08:17 Fri 04 Jan, Otto Moerbeek wrote: > Hi, > > If you ever thought about getting more involved and learning a bit > about buikdling a current OpenBSD, there's a call for testing at > > https://marc.info/?l=openbsd-tech=154521488707434=2 > > Testing would provide me with valuable data about performance of > memory management in multi-threaded applications. Whay kind of performance (e.g. more/less responssive application)? Any particular improvements should be looked for? Does number of CPUs matter?
