Re: 1.0.1 and ntpsnmpd

[Ian Bruene via devel]

ntpsnmpd is now fully part of the build. Manpage installs properly. 
make-tarball includes it (mostly because it slurps up everything).


--
/"In the end; what separates a Man, from a Slave? Money? Power? No. A 
Man Chooses, a Slave Obeys."/ -- Andrew Ryan


/"Utopia cannot precede the Utopian. It will exist the moment we are fit 
to occupy it."/ -- Sophia Lamb


___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: What are people putting in /etc/ntp.d/*.conf?

[Achim Gratz via devel]

Hal Murray via devel writes:
> e...@thyrsus.com said:
>> Gary and Mark asked me for something like such an Apache-like feature
>> because it makes life easier for configuration-assistant software and distro
>> packages. 
>
> Is that true in our case?  It seems like it might be, but our config file is 
> generally simple enough that a single text file seems reasonable and putting 
> chunks in separate files makes things more complicated.

It makes things more complicated if you as a human keep everything in
order.  A single configuration file that has to be comprehended and
edited by automated config tools is more complictaed for a machine to
handle.

> I'd be a lot happier if we had one good example.  What other packages add on 
> to ours in a way where adding to the config file would be useful?  Do we have 
> any extensions at the package level?

There was a very good example in the thread: Having two distro packages set up
different aspects of the daemon operation without having to touch the
same set of files.  ANother one would be to drop in the key
configuration, maybe via some sort of deployment automation without
stepping on the distro-owned files.

Full disclosure: I am still using a single /etc/ntp.conf, partly with
old syntax, but that's down to inertia.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables

___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Is gitlab flaky?

[Hal Murray via devel]

When I push something, I normally get 2 messages telling me it worked.

Occasionally, I get 1 telling me it didn't.  The last time, it worked when I 
poked Try-Again.

This time, I got:
  Subject: ntpsec | Pipeline #18075609 has succeeded for master | eef92d62
  Subject: ntpsec | Pipeline #18075609 has failed for master | eef92d62

Pipeline #18075609 ( https://gitlab.com/NTPsec/ntpsec/pipelines/18075609 ) 
triggered by Hal Murray ( https://gitlab.com/hal.murray )
had 1 failed build.

Job #54445477

Stage: deploy
Name: pages:deploy


-- 
These are my opinions.  I hate spam.



___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: 1.0.1 and ntpsnmpd

[Richard Laager via devel]

On 02/26/2018 09:50 AM, Mark Atwood via devel wrote:
> Does the Debian packaging have it be it's own package?

It's unclear to me what exactly you're asking, so I'll give various
information which may help:

No NTPsec ntpsnmpd has shipped in a released version, so the Debian
package doesn't do anything with it currently, because it doesn't exist.

The ntp package (NTP Classic) does not ship any ntpsnmpd. It explicitly
configures with --without-ntpsnmpd. It does ship a documentation file
for it, presumably for lack of special-casing that.

If ntpsnmpd is experimental and there is no precedent from NTP Classic,
my first inclination is to not bother shipping it at all, for now. That
just punts the problem to the future, though, when it's not marked
experimental.

>From the "d" at the end of the name, I assume ntpsnmpd has to run as a
daemon, as opposed to being invoked as a script by snmpd. Off the top of
my head, I'd probably ship it in a separate package. I assume most
people using ntpd will not want ntpsnmpd.

If that's the route I plan to go, then I'll probably do it sooner,
rather than later, as adding new binary package names requires extra
review (which can take a long time). That way, we start the clock on
ntpsec-snmp (or whatever) while it is still experimental.

-- 
Richard
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: 1.0.1 and ntpsnmpd

[Richard Laager via devel]

On 02/26/2018 06:16 PM, Sanjeev Gupta wrote:
> Richard, I am using cacti.

That's what I was hoping to hear, since I also run Cacti. Are you
willing to share your templates?

1) That'd probably be good for the project in general.
2) That would give me a way to test, both short-term and long-term, the
ntpsnmpd packaging.

-- 
Richard
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: 1.0.1 and ntpsnmpd

[Sanjeev Gupta via devel]

(apologies for the top posts)

Richard, I am using cacti.  Have been planning to add it to observium as
well, will try tonight.


-- 
Sanjeev Gupta
+65 98551208 http://www.linkedin.com/in/ghane

On Tue, Feb 27, 2018 at 8:14 AM, Richard Laager  wrote:

> On 02/26/2018 06:13 PM, Sanjeev Gupta wrote:
> > For what it is worth, I am running the ntpsnmpd code on a number of
> > debian and ubuntu machines for some time, including one with an actual
> > GPS.  No issues so far.
> >
> > I just like to see graphs.
>
> What are you using to graph the NTP SNMP data?
>
> --
> Richard
>
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: 1.0.1 and ntpsnmpd

[Sanjeev Gupta via devel]

Hi,

For what it is worth, I am running the ntpsnmpd code on a number of debian
and ubuntu machines for some time, including one with an actual GPS.  No
issues so far.

I just like to see graphs.


-- 
Sanjeev Gupta
+65 98551208 http://www.linkedin.com/in/ghane

On Tue, Feb 27, 2018 at 8:09 AM, Richard Laager via devel 
wrote:

> On 02/26/2018 09:50 AM, Mark Atwood via devel wrote:
> > Does the Debian packaging have it be it's own package?
>
> It's unclear to me what exactly you're asking, so I'll give various
> information which may help:
>
> No NTPsec ntpsnmpd has shipped in a released version, so the Debian
> package doesn't do anything with it currently, because it doesn't exist.
>
> The ntp package (NTP Classic) does not ship any ntpsnmpd. It explicitly
> configures with --without-ntpsnmpd. It does ship a documentation file
> for it, presumably for lack of special-casing that.
>
> If ntpsnmpd is experimental and there is no precedent from NTP Classic,
> my first inclination is to not bother shipping it at all, for now. That
> just punts the problem to the future, though, when it's not marked
> experimental.
>
> From the "d" at the end of the name, I assume ntpsnmpd has to run as a
> daemon, as opposed to being invoked as a script by snmpd. Off the top of
> my head, I'd probably ship it in a separate package. I assume most
> people using ntpd will not want ntpsnmpd.
>
> If that's the route I plan to go, then I'll probably do it sooner,
> rather than later, as adding new binary package names requires extra
> review (which can take a long time). That way, we start the clock on
> ntpsec-snmp (or whatever) while it is still experimental.
>
> --
> Richard
> ___
> devel mailing list
> devel@ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel
>
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: 1.0.1 and ntpsnmpd

[Richard Laager via devel]

On 02/26/2018 06:13 PM, Sanjeev Gupta wrote:
> For what it is worth, I am running the ntpsnmpd code on a number of
> debian and ubuntu machines for some time, including one with an actual
> GPS.  No issues so far.
> 
> I just like to see graphs.

What are you using to graph the NTP SNMP data?

-- 
Richard
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: 1.0.1 and ntpsnmpd

[Ian Bruene via devel]

On 02/26/2018 06:13 PM, Sanjeev Gupta via devel wrote:

Hi,

For what it is worth, I am running the ntpsnmpd code on a number of 
debian and ubuntu machines for some time, including one with an actual 
GPS.  No issues so far.


I just like to see graphs.


Hooray! Someone is using the code!

1. This means it is useful.

2. This gives some confirmation of stability.

Related to point 2; do you have rough numbers of how long / many 
instances of this have been running?


--
/"In the end; what separates a Man, from a Slave? Money? Power? No. A 
Man Chooses, a Slave Obeys."/ -- Andrew Ryan


/"Utopia cannot precede the Utopian. It will exist the moment we are fit 
to occupy it."/ -- Sophia Lamb


___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: 1.0.1 and ntpsnmpd

[Mark Atwood via devel]

Re ntpsnmpd

My inclination is to include it, but document it as experimental, but also
document in the release announcement as worth trying.

Does waf build it by default?

Does the Debian packaging have it be it's own package?

..m

On Sun, Feb 25, 2018 at 5:18 PM Hal Murray via devel 
wrote:

>
> > You need to be running an SNMP daemon and an NTP daemon.
>
> I've got plenty of ntp servers to experiment with.
>
> >> Is there a HOWTO that tells me how to set things up?
> > I'll get to work on that.
>
> There may be two targets for that document.  One is SNMP wizards who don't
> know much about ntpd.  The other is NTP wizards who don't know much about
> SNMP.
>
> > "Why SNMP?" I'm not sure I can tell you much more that a few minutes of
> > quality time with a wiki could.
>
> There is a lot of stuff out there.  A few good URLs would help people like
> me
> get started.  I think "curated" is the right term.
>
> I assume I also have to setup a system to collect the data and show status
> or
> email alerts or whatever.  What do you call that?  I think there are
> several
> packages available.  Do they all support NTP?  Do they monitor NTP servers
> directly with NTP packets?
>
> At any rate, I/we need the HOWTO level info for setting up the NTP side
> and I
> need a HOWTO for getting the collection end off the ground.
>
> (In case it's not obvious, I don't mean you have to write them.  Links to
> existing info is fine.)
>
> 
>
> In case it's not on your list...
>
> ntpd can monitor other ntp servers.  Just put "noselect" on a server line
> pointed at the system you want to monitor.  Then ntpq -p will give you a
> line
> of info and logging to peerstats and rawstats will get the normal data.
>
>
> --
> These are my opinions.  I hate spam.
>
>
>
> ___
> devel mailing list
> devel@ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel
>
-- 

Mark Atwood
http://about.me/markatwood
+1-206-604-2198
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: prep for 1.0.1

[Mark Atwood via devel]

I am inclined towards quarterly release schedule as well, modified with
doing a release when we discover an important enough issue, and we will
delay a release if we discover an important enough issue.

On Wed, Feb 21, 2018 at 1:41 PM Hal Murray via devel 
wrote:

>
> rlaa...@wiktel.com said:
> > If you're going to move to time-based, you might consider quarterly
> > releases?
>
> I'd be happy with quarterly releases.
>
> The next question is how seriously do we take the release date?  I think
> there are two approaches.  The first is to try hard to release as
> scheduled.
> That means we have to be conservative and leave plenty of time for testing
> and the associated cleanups.  The other approach is to leave less time for
> testing but slip the release if/when we find interesting problems.
>
>
> > Longer release cycles allow developers and users of git to test some
> changes
> > longer, but that's only helpful if you have a freeze.
>
> I'm assuming there will be a freeze.  Or at least a cooling off period
> where
> the changes are small and reviewed carefully, maybe smaller and more
> carefully reviewed and tested as we get closer to the release.
>
> ---
>
> There might be a need for more time between releases if we ever make a big
> change.  I don't have any good examples right now.
>
>
>
>
> --
> These are my opinions.  I hate spam.
>
>
>
> ___
> devel mailing list
> devel@ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel
>
-- 

Mark Atwood
http://about.me/markatwood
+1-206-604-2198
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: 1.0.1 and ntpsnmpd

[Ian Bruene via devel]

On 02/26/2018 09:50 AM, Mark Atwood via devel wrote:

Does waf build it by default?

Does the Debian packaging have it be it's own package?


It is built as part of the other python utilities. The manpage isn't 
part of the build yet as I do not know which section it should go in.


--
/"In the end; what separates a Man, from a Slave? Money? Power? No. A 
Man Chooses, a Slave Obeys."/ -- Andrew Ryan


/"Utopia cannot precede the Utopian. It will exist the moment we are fit 
to occupy it."/ -- Sophia Lamb


___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Future projects (post release)

[Mark Atwood via devel]

Putting the globals into a controlled struct make them easier to reason
about, both for humans and for source code analysis.  And even if the
resulting struct is little more than the "globals dumping ground", it does
force that they all be declared in one single place, in a place where you
have to admit "this is a global".

On Wed, Feb 21, 2018 at 10:58 AM Hal Murray via devel 
wrote:

>
> > I've been looking at the code around mode 6 generation and discovered
> that
> > in some areas it's still globals all the way down. Translating  these
> > globals will make future refactoring/translating easier.
>
> I'm missing the big idea.
>
> The current case is that we have a lot of global variables.
>
> What does packaging them in a struct solve?  We aren't going to pass a
> pointer to the struct around all over the place.
>
> Should we cleanup the names so it's obvious which variables are global?
> Should we reorganize the header files so it's easier to find all of them?
>
>
> --
> These are my opinions.  I hate spam.
>
>
>
> ___
> devel mailing list
> devel@ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel
>
-- 

Mark Atwood
http://about.me/markatwood
+1-206-604-2198
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: What are people putting in /etc/ntp.d/*.conf?

[Eric S. Raymond via devel]

Hal Murray :
> 
> e...@thyrsus.com said:
> > Gary and Mark asked me for something like such an Apache-like feature
> > because it makes life easier for configuration-assistant software and distro
> > packages. 
> 
> Is that true in our case?  It seems like it might be, but our config file is 
> generally simple enough that a single text file seems reasonable and putting 
> chunks in separate files makes things more complicated.
> 
> I'd be a lot happier if we had one good example.  What other packages add on 
> to ours in a way where adding to the config file would be useful?  Do we have 
> any extensions at the package level?

Not yet.  We might if refclockd ever becomes a reality.  There's also a
possibility near Daniel's NTS daemon (not yet written either).
-- 
http://www.catb.org/~esr/;>Eric S. Raymond

My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.


___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: 1.0.1 and ntpsnmpd

[Ian Bruene via devel]

On 02/25/2018 07:18 PM, Hal Murray via devel wrote:

Is there a HOWTO that tells me how to set things up?

I'll get to work on that.

There may be two targets for that document.  One is SNMP wizards who don't
know much about ntpd.  The other is NTP wizards who don't know much about
SNMP.


Unfortunately I am neither. I know the intersection of the two, and some 
of the basics needed to get SNMP running.



"Why SNMP?" I'm not sure I can tell you much more that a few minutes of
quality time with a wiki could.

There is a lot of stuff out there.  A few good URLs would help people like me
get started.  I think "curated" is the right term.


These are decent. Unfortunately proper documentation about SNMP is not 
exactly commonplace; early on I had to reverse engineer more than I'd 
like by poking the master agent and seeing what it did.


https://en.wikipedia.org/wiki/Simple_Network_Management_Protocol

https://www.thegeekstuff.com/2012/09/snmp-introduction/

http://www.net-snmp.org/wiki/index.php/TUT:snmpd_configuration


I assume I also have to setup a system to collect the data and show status or
email alerts or whatever.  What do you call that?  I think there are several
packages available.  Do they all support NTP?  Do they monitor NTP servers
directly with NTP packets?


I... am not sure what you are talking about.

Rough structure of an SNMP system:

SNMP daemon (like snmpd): Master agent. Everything routes through this, 
and it handles the permissions.


Sub-agent daemon (ntpsnmpd): responds to commands and data requests 
relayed to it by the master.


Clients: Includes utilities like snmpwalk/get/set, as well as more 
sophisticated software. Talks to the master agent to send or retrieve 
data, and does something with that data.


Management Information Base (MIB): Document specifying the structure and 
meaning of a subset of the data tree. Usually the client will have a 
copy of this so that it knows what to look for.



At any rate, I/we need the HOWTO level info for setting up the NTP side and I
need a HOWTO for getting the collection end off the ground.

(In case it's not obvious, I don't mean you have to write them.  Links to
existing info is fine.)



In case it's not on your list...

ntpd can monitor other ntp servers.  Just put "noselect" on a server line
pointed at the system you want to monitor.  Then ntpq -p will give you a line
of info and logging to peerstats and rawstats will get the normal data.




--
/"In the end; what separates a Man, from a Slave? Money? Power? No. A 
Man Chooses, a Slave Obeys."/ -- Andrew Ryan


/"Utopia cannot precede the Utopian. It will exist the moment we are fit 
to occupy it."/ -- Sophia Lamb


___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Future projects (post release)

[Eric S. Raymond via devel]

Mark Atwood via devel :
> Putting the globals into a controlled struct make them easier to reason
> about, both for humans and for source code analysis.  And even if the
> resulting struct is little more than the "globals dumping ground", it does
> force that they all be declared in one single place, in a place where you
> have to admit "this is a global".

+1

Ian and I had a long chat about this on IRC.
-- 
http://www.catb.org/~esr/;>Eric S. Raymond

My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.


___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel