Re: 1 Machine, 2 NICs, 2 Instances of ntpd;Possible? - NTP

This is a discussion on Re: 1 Machine, 2 NICs, 2 Instances of ntpd;Possible? - NTP ; > I want one ntpd instance to discipline the local clock with time from servers > on network A. I want the other instance to serve the local time to clients > on network B. Additionally, I was considering running ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 22

Thread: Re: 1 Machine, 2 NICs, 2 Instances of ntpd;Possible?

  1. Re: 1 Machine, 2 NICs, 2 Instances of ntpd;Possible?


    > I want one ntpd instance to discipline the local clock with time from

    servers
    > on network A. I want the other instance to serve the local time to

    clients
    > on network B.


    Additionally, I was considering running the ntpd instance A with the -q
    option
    as a cron job.

    Now, is what I am trying to do feasible?

  2. Re: 1 Machine, 2 NICs, 2 Instances of ntpd; Possible?

    John Johnson wrote:

    >John Johnson wrote:
    >
    >> I want one ntpd instance to discipline the local clock with time from
    >> servers on network A. I want the other instance to serve the local
    >> time to clients on network B.

    >
    > Additionally, I was considering running the ntpd instance A with the
    > -q option as a cron job.
    >
    > Now, is what I am trying to do feasible?


    No.

    One ntpd is all you need. It will poll your time sources, discipline the
    clock, and serve your clients.

    --
    Steve Kostecke
    NTP Public Services Project - http://support.ntp.org/

  3. Re: 1 Machine, 2 NICs, 2 Instances of ntpd; Possible?

    "Steve Kostecke" wrote in message
    news:slrnftb2eh.cjq.kostecke@stasis.kostecke.net.. .
    > John Johnson wrote:

    [...]
    >> Now, is what I am trying to do feasible?

    >
    > No.
    >
    > One ntpd is all you need.


    I think you must be using a different definition of the word 'feasible'
    from everybody else.

    As a software guy, I've wondered before about the monolithic nature of
    the NTP package. Splitting it into a client and server part might make
    some people (think OpenBSD) very happy. The objection when raised earlier
    was that the server may be asked for statistics about things that happen
    in the client; ISTM this could be solved.

    Also, the much-sought feature of re-resolving dried up associations could
    be done from a cron job with ntpq/ntpdc. Determining for certain what
    configuration to use might be a problem.

    Groetjes,
    Maarten Wiltink



  4. Re: 1 Machine, 2 NICs, 2 Instances of ntpd; Possible?

    On 2008-03-11, Maarten Wiltink wrote:

    > "Steve Kostecke" wrote in message
    >
    >> John Johnson wrote:
    >>
    >>> Now, is what I am trying to do feasible?

    >>
    >> One ntpd is all you need.

    >
    > I think you must be using a different definition of the word
    > 'feasible' from everybody else.


    Here's one:

    | From WordNet (r) 2.0 (August 2003) [wn]:
    |
    | feasible
    | adj : capable of being done with means at hand and circumstances
    | as they are [syn: {executable}, {practicable},
    | {viable}, {workable}]
    | adv : in a practicable manner; so as to be feasible [syn:
    | {practicably}]

    > As a software guy, I've wondered before about the monolithic nature of
    > the NTP package. Splitting it into a client and server part might make
    > some people (think OpenBSD) very happy.


    There is considerable overlap between an "NTP Client" and an "NTP
    Server".

    "NTP Clients" and "NTP Servers" both:

    1. Poll time sources (e.g. "NTP Servers", ref-clocks)
    2. Discipline the system clock
    3. Utilize NTP Authentication

    "NTP Servers" also:

    1. Reply to polls from "NTP Clients" and other "NTP Servers"

    > The objection when raised earlier was that the server may be asked for
    > statistics about things that happen in the client; ISTM this could be
    > solved.


    By adding another layer of complexity ...

    > Also, the much-sought feature of re-resolving dried up associations could
    > be done from a cron job with ntpq/ntpdc. Determining for certain what
    > configuration to use might be a problem.


    A 're-resolve' command in ntpq would be useful.

    --
    Steve Kostecke
    NTP Public Services Project - http://support.ntp.org/

  5. Re: 1 Machine, 2 NICs, 2 Instances of ntpd; Possible?

    "Steve Kostecke" wrote in message
    news:slrnftd13r.l44.kostecke@stasis.kostecke.net.. .
    > On 2008-03-11, Maarten Wiltink wrote:


    >> As a software guy, I've wondered before about the monolithic nature of
    >> the NTP package. Splitting it into a client and server part might make
    >> some people (think OpenBSD) very happy.

    >
    > There is considerable overlap between an "NTP Client" and an "NTP
    > Server".
    >
    > "NTP Clients" and "NTP Servers" both:
    >
    > 1. Poll time sources (e.g. "NTP Servers", ref-clocks)
    > 2. Discipline the system clock


    This _is_ what I'd call the 'client part'. The server part would
    assume or require that the clock is being disciplined by a client
    implementation.


    > 3. Utilize NTP Authentication


    You may have a point there. But I have a feeling that they use it
    differently, one as a client and one as a server. (No surprise there.)


    [...]
    >> The objection when raised earlier was that the server may be asked for
    >> statistics about things that happen in the client; ISTM this could be
    >> solved.

    >
    > By adding another layer of complexity ...


    Yes. Decoupling always adds complexity at the interface. But as a software
    guy I appreciate the focus it adds to the decoupled modules.


    >> Also, the much-sought feature of re-resolving dried up associations
    >> could be done from a cron job with ntpq/ntpdc. Determining for certain
    >> what configuration to use might be a problem.

    >
    > A 're-resolve' command in ntpq would be useful.


    I don't have the details handy, but aren't there already commands to
    remove and create associations? Probably only in ntpdc, though.

    Groetjes,
    Maarten Wiltink



  6. Re: 1 Machine, 2 NICs, 2 Instances of ntpd; Possible?

    On 2008-03-11, Maarten Wiltink wrote:

    > "Steve Kostecke" wrote in message
    >
    >> There is considerable overlap between an "NTP Client" and an "NTP
    >> Server".
    >>
    >> "NTP Clients" and "NTP Servers" both:
    >>
    >> 1. Poll time sources (e.g. "NTP Servers", ref-clocks)
    >> 2. Discipline the system clock

    >
    > This _is_ what I'd call the 'client part'. The server part would
    > assume or require that the clock is being disciplined by a client
    > implementation.


    The main functional difference between an ntpd which is operating as an
    "NTP Client" and one operating as an "NTP Server" is that latter
    receives polls from clients, time stamps them and sends them back.

    Currently NTP uses port 123/UDP for both the source and destination
    port. What you are proposing would require the use of a different source
    port to work on a single-homed host. This would result in a DOS when
    polling a server that enforces the NTP port.

    Another thing to consider is the fact that you would now have two
    processes which both require high priority access to the system clock.

    >> 3. Utilize NTP Authentication

    >
    > You may have a point there. But I have a feeling that they use it
    > differently, one as a client and one as a server. (No surprise there.)


    NTP Authentication authenticates the server to the client. So that code
    is going to be used, albeit somewhat differently, by both ends of an
    authenticated association.

    >>> The objection when raised earlier was that the server may be asked
    >>> for statistics about things that happen in the client; ISTM this
    >>> could be solved.

    >>
    >> By adding another layer of complexity ...

    >
    > Yes. Decoupling always adds complexity at the interface. But as a
    > software guy I appreciate the focus it adds to the decoupled modules.


    That would make sense of there was a substantial difference between the
    modules. In this case I doubt that the difference is all that great.

    I'd point out that the source is available for anyone to modify, but
    that statement seems to interpreted as an attempt to stifle discussion.
    So I ... oops

    >>> Also, the much-sought feature of re-resolving dried up associations
    >>> could be done from a cron job with ntpq/ntpdc. Determining for certain
    >>> what configuration to use might be a problem.

    >>
    >> A 're-resolve' command in ntpq would be useful.

    >
    > I don't have the details handy, but aren't there already commands to
    > remove and create associations? Probably only in ntpdc, though.


    'addserver' & 'unconfig' are currently available only in ntpdc.

    FWIW: ntpdc is version specific and it's use has been discouraged on
    more than one occasion.

    --
    Steve Kostecke
    NTP Public Services Project - http://support.ntp.org/

  7. Re: 1 Machine, 2 NICs, 2 Instances of ntpd; Possible?

    Steve Kostecke wrote:
    > FWIW: ntpdc is version specific and it's use has been discouraged on
    > more than one occasion.


    FWIW: I routinely use ntpdc to add/remove associations ('addserver' and
    'unconfig') and to fudge time1 values. It seems to work fine for those
    purposes. Before using it, however, I would recommend patching it with the
    patch described by myself here:
    http://bugs.ntp.org/1003

    Dennis

    --
    Dennis Hilberg, Jr. \ timekeeper(at)dennishilberg(dot)com
    NTP Server Information: \ http://saturn.dennishilberg.com/ntp.php

  8. Re: 1 Machine, 2 NICs, 2 Instances of ntpd; Possible?

    "Steve Kostecke" wrote in message
    news:slrnftdkhp.knr.kostecke@stasis.kostecke.net.. .
    [...]
    > Currently NTP uses port 123/UDP for both the source and destination
    > port. What you are proposing would require the use of a different source
    > port to work on a single-homed host. This would result in a DOS when
    > polling a server that enforces the NTP port.


    I'm no IP wizard, but isn't there a SO_REUSEPORT flag or something
    like that?

    Anyway, I frankly doubt that requiring a specific source port is
    still a good thing. Dit it ever accomplish anything above testing
    that the sender has root on the remote machine? By now, it mostly
    serves to chase off innocent NATted clients.


    > Another thing to consider is the fact that you would now have two
    > processes which both require high priority access to the system clock.


    I can see how that would be a party killer. But the current, monolithic
    NTP can't discipline the clock and answer polls at the exact same time,
    either. The obvious choice would be to give the client part priority
    over the server part. Things might actually get *better*.


    >> [...] Decoupling always adds complexity at the interface. But as a
    >> software guy I appreciate the focus it adds to the decoupled modules.

    [...]
    > I'd point out that the source is available for anyone to modify, but
    > that statement seems to interpreted as an attempt to stifle discussion.


    Well, I appreciate the source being available and all, but unfortunately
    I already have a hobby to take up six nights a week. Plus, while patches
    might be accepted, I doubt that a major rewrite of the entire codebase
    would. Sorry. Sometimes I wish I were still twenty-two and had the
    patience to do it, and the perseverence to get it changed. At thirty-
    seven, all I have left is the questionable sideline-based wisdom to
    see room for improvement.

    Groetjes,
    Maarten Wiltink



  9. Re: 1 Machine, 2 NICs, 2 Instances of ntpd; Possible?

    Maarten Wiltink wrote:
    > I'm no IP wizard, but isn't there a SO_REUSEPORT flag or something
    > like that?


    It still (IIRC) lacks sufficient ubiquity and the semantics on the
    various platforms may not match what is desired.

    rick jones
    --
    denial, anger, bargaining, depression, acceptance, rebirth...
    where do you want to be today?
    these opinions are mine, all mine; HP might not want them anyway...
    feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

  10. Re: 1 Machine, 2 NICs, 2 Instances of ntpd; Possible?

    Maarten Wiltink wrote:

    >
    > This _is_ what I'd call the 'client part'. The server part would
    > assume or require that the clock is being disciplined by a client
    > implementation.


    It needs to share rather more than the clock. Things like:

    stratum
    root distance
    root dispersion
    system peer
    local reference time
    leap bits
    etc.

  11. Re: 1 Machine, 2 NICs, 2 Instances of ntpd; Possible?

    "David Woolley" wrote in message
    news:47d70081$0$510$5a6aecb4@news.aaisp.net.uk...
    > Maarten Wiltink wrote:




    >> [...] The server part would
    >> assume or require that the clock is being disciplined by a client
    >> implementation.

    >
    > It needs to share rather more than the clock. Things like:
    >
    > stratum
    > root distance
    > root dispersion
    > system peer
    > local reference time
    > leap bits
    > etc.


    Yes. Those are all client-part statistics that could easily be made
    available to a server-part for dishing out to anyone interested in
    evaluating the status and quality indicators of your server. As part
    of _requiring_ that the clock be disciplined by an NTP client part.
    You're not going to trust that; you're going to check it.

    Of course there is overhead in having the server part query for
    the client part's statistics, and transferring them. That's not
    the point. Nor do I have any illusions about any of this ever
    happening.

    Groetjes,
    Maarten Wiltink



  12. Re: 1 Machine, 2 NICs, 2 Instances of ntpd; Possible?

    Maarten Wiltink wrote:
    > "David Woolley" wrote in message
    > news:47d70081$0$510$5a6aecb4@news.aaisp.net.uk...


    >> stratum
    >> root distance
    >> root dispersion
    >> system peer
    >> local reference time
    >> leap bits
    >> etc.

    >
    > Yes. Those are all client-part statistics that could easily be made
    > available to a server-part for dishing out to anyone interested in
    > evaluating the status and quality indicators of your server. As part


    These things are needed for the core protocol. You cannot act as a
    valid server to even the most primitive of valid clients without them.
    They are not diagnostic information for ntpq, they are needed to
    construct a valid server packet.

    Without them you don't even have a compliant SNTP server; you basically
    have an RDATE like server with sub-second resolution.

  13. Re: 1 Machine, 2 NICs, 2 Instances of ntpd; Possible?

    "David Woolley" wrote in message
    news:47d79152$0$508$5a6aecb4@news.aaisp.net.uk...
    > Maarten Wiltink wrote:
    >> "David Woolley" wrote in message
    >> news:47d70081$0$510$5a6aecb4@news.aaisp.net.uk...


    >>> stratum
    >>> root distance
    >>> root dispersion
    >>> system peer
    >>> local reference time
    >>> leap bits
    >>> etc.

    >>
    >> Yes. Those are all client-part statistics that could easily be made
    >> available to a server-part for dishing out to anyone interested in
    >> evaluating the status and quality indicators of your server. ...

    >
    > These things are needed for the core protocol. You cannot act as a
    > valid server to even the most primitive of valid clients without them.
    > They are not diagnostic information for ntpq, they are needed to
    > construct a valid server packet.


    Not all statistics are diagnostics. Some are, as you say, core.


    > Without them you don't even have a compliant SNTP server; you
    > basically have an RDATE like server with sub-second resolution.


    An SNTP or local clock server might have to make some of them up.
    System peer? Root dispersion?

    Groetjes,
    Maarten Wiltink



  14. Re: 1 Machine, 2 NICs, 2 Instances of ntpd; Possible?

    Maartin and others,

    The intended model for monitoring and control is clearly articulated in
    the control and monitoring protocol defined in rfc 1305. This model
    provides status words and event codes explicitly designed for remote
    access and as a demarcation between the idiosyncratic inner workings of
    the implementation and the external view. This and the NTP packet itself
    is the only intended external view of the running program. Anything else
    is speculation and subject to change, specifically the details other
    than the status words, events and fixed configuration information on the
    ntpq billboards.

    The intent of the original design which continues today is that a small
    perl script can be used to query ntpd, parse the codes and traps and
    either beep the administrator or respond as an SNMP agent. We did that
    some years ago as a concept test and it worked fine, but the old rickety
    code has neen lost to antiquity. That project should be relaunched by a
    competent perlman.

    The code has been recently audited to be sure the status words and event
    codes are aligned to the current implentation. A few small adjustments
    have been made to align small differences that have accumulated since
    1992. The codes and events are summarized in the current web documentation.

    Having said this, folks will continue to pry the details other than the
    above from the ntpq billboards. Those details specifically called out in
    the NTPv4 specirication will continue as advertised, but the specific
    text names are not guaranteed. They are intended for eyeball, not
    machine decode. Those not called out in the specification are subject to
    change, either in name or function or both.

    Dave

    Maarten Wiltink wrote:

    > "David Woolley" wrote in message
    > news:47d79152$0$508$5a6aecb4@news.aaisp.net.uk...
    >
    >>Maarten Wiltink wrote:
    >>
    >>>"David Woolley" wrote in message
    >>>news:47d70081$0$510$5a6aecb4@news.aaisp.net.uk...

    >
    >
    >>>>stratum
    >>>>root distance
    >>>>root dispersion
    >>>>system peer
    >>>>local reference time
    >>>>leap bits
    >>>>etc.
    >>>
    >>>Yes. Those are all client-part statistics that could easily be made
    >>>available to a server-part for dishing out to anyone interested in
    >>>evaluating the status and quality indicators of your server. ...

    >>
    >>These things are needed for the core protocol. You cannot act as a
    >>valid server to even the most primitive of valid clients without them.
    >>They are not diagnostic information for ntpq, they are needed to
    >>construct a valid server packet.

    >
    >
    > Not all statistics are diagnostics. Some are, as you say, core.
    >
    >
    >
    >>Without them you don't even have a compliant SNTP server; you
    >>basically have an RDATE like server with sub-second resolution.

    >
    >
    > An SNTP or local clock server might have to make some of them up.
    > System peer? Root dispersion?
    >
    > Groetjes,
    > Maarten Wiltink
    >
    >


  15. Re: 1 Machine, 2 NICs, 2 Instances of ntpd; Possible?

    David L. Mills wrote:
    > Maartin and others,
    >
    > The intended model for monitoring and control is clearly articulated in
    > the control and monitoring protocol defined in rfc 1305. This model


    I can't speak for Maartin, but I was talking about the operation of the
    protocol itself. The values in question are needed to correctly
    construct a server response packet, so, it you split client and server,
    you must communicate this information between them.

    > provides status words and event codes explicitly designed for remote
    > access and as a demarcation between the idiosyncratic inner workings of
    > the implementation and the external view. This and the NTP packet itself
    > is the only intended external view of the running program. Anything else
    > is speculation and subject to change, specifically the details other
    > than the status words, events and fixed configuration information on the
    > ntpq billboards.
    >
    > The intent of the original design which continues today is that a small
    > perl script can be used to query ntpd, parse the codes and traps and
    > either beep the administrator or respond as an SNMP agent. We did that
    > some years ago as a concept test and it worked fine, but the old rickety
    > code has neen lost to antiquity. That project should be relaunched by a
    > competent perlman.
    >
    > The code has been recently audited to be sure the status words and event
    > codes are aligned to the current implentation. A few small adjustments
    > have been made to align small differences that have accumulated since
    > 1992. The codes and events are summarized in the current web documentation.
    >
    > Having said this, folks will continue to pry the details other than the
    > above from the ntpq billboards. Those details specifically called out in
    > the NTPv4 specirication will continue as advertised, but the specific
    > text names are not guaranteed. They are intended for eyeball, not
    > machine decode. Those not called out in the specification are subject to
    > change, either in name or function or both.
    >
    > Dave
    >
    > Maarten Wiltink wrote:
    >
    >> "David Woolley" wrote in message
    >> news:47d79152$0$508$5a6aecb4@news.aaisp.net.uk...
    >>
    >>> Maarten Wiltink wrote:
    >>>
    >>>> "David Woolley" wrote in message
    >>>> news:47d70081$0$510$5a6aecb4@news.aaisp.net.uk...

    >>
    >>
    >>>>> stratum
    >>>>> root distance
    >>>>> root dispersion
    >>>>> system peer
    >>>>> local reference time
    >>>>> leap bits
    >>>>> etc.
    >>>>
    >>>> Yes. Those are all client-part statistics that could easily be made
    >>>> available to a server-part for dishing out to anyone interested in
    >>>> evaluating the status and quality indicators of your server. ...
    >>>
    >>> These things are needed for the core protocol. You cannot act as a
    >>> valid server to even the most primitive of valid clients without them.
    >>> They are not diagnostic information for ntpq, they are needed to
    >>> construct a valid server packet.

    >>
    >>
    >> Not all statistics are diagnostics. Some are, as you say, core.
    >>
    >>
    >>
    >>> Without them you don't even have a compliant SNTP server; you
    >>> basically have an RDATE like server with sub-second resolution.

    >>
    >>
    >> An SNTP or local clock server might have to make some of them up.
    >> System peer? Root dispersion?
    >>
    >> Groetjes,
    >> Maarten Wiltink
    >>
    >>


  16. Re: 1 Machine, 2 NICs, 2 Instances of ntpd; Possible?

    Maarten Wiltink wrote:

    >
    > An SNTP or local clock server might have to make some of them up.
    > System peer? Root dispersion?


    A conforming SNTP server is required to have a locally attached
    reference clock. The only other situation in which SNTP is allowed is
    where only the client is SNTP, but the server is full NTP.

    In the former case, system peer is the reference clock and the upstream
    root dispersion is zero.

    In the latter case, the server has to have the real values available.

  17. Re: 1 Machine, 2 NICs, 2 Instances of ntpd;Possible?

    Maarten Wiltink wrote:
    >
    > As a software guy, I've wondered before about the monolithic nature of
    > the NTP package. Splitting it into a client and server part might make
    > some people (think OpenBSD) very happy. The objection when raised earlier
    > was that the server may be asked for statistics about things that happen
    > in the client; ISTM this could be solved.
    >


    Maarten, NTP is unusual in that it does not lend itself to separation of
    client from server. This is not about statistics but about the nature of
    how it operates and is used. I know of no other client/server software
    that could not be separated, the nearest being a proxy server.

    > Also, the much-sought feature of re-resolving dried up associations could
    > be done from a cron job with ntpq/ntpdc. Determining for certain what
    > configuration to use might be a problem.
    >


    I'll be working on it. I just need to get other things done too.

    Danny
    > Groetjes,
    > Maarten Wiltink
    >
    >
    > _______________________________________________
    > questions mailing list
    > questions@lists.ntp.org
    > https://lists.ntp.org/mailman/listinfo/questions
    >


  18. Re: 1 Machine, 2 NICs, 2 Instances of ntpd;Possible?

    "Danny Mayer" wrote in message
    news:47D9ECFF.6030201@ntp.isc.org...
    > Maarten Wiltink wrote:


    >> As a software guy, I've wondered before about the monolithic nature
    >> of the NTP package. Splitting it into a client and server part ...


    > Maarten, NTP is unusual in that it does not lend itself to separation
    > of client from server. This is not about statistics but about the
    > nature of how it operates and is used. ...


    Could you say more about that? I realise that it's not as clean cut as
    the division between an FTP client and server, and that NTP may be
    better served by a model like for example the server always requiring
    some interchangeable client module(s?) being plugged into it (whether
    network associations or hardware reference clocks, as mentioned).

    The client part might operate without a server, or perhaps a downgraded
    server that does not serve time but only offers status monitoring.

    There are several different useage scenarios for NTP. Someone with a
    web server farm might be interested in a client that keeps his servers
    on time, but lets them be web servers, not time servers.

    I realise that there is a mechanism to do this. I realise that I'm
    speaking from the sideline. I'm just pointing out that everybody gets
    all the code, all the time, and then has to restrict out the bits they
    don't want. It seems like a somewhat unstructured way to build a big
    system to me.


    >> Also, the much-sought feature of re-resolving dried up associations
    >> could be done from a cron job with ntpq/ntpdc. Determining for certain
    >> what configuration to use might be a problem.

    >
    > I'll be working on it. I just need to get other things done too.


    I'm sure we all do appreciate that. (-:

    Groetjes,
    Maarten Wiltink



  19. Re: 1 Machine, 2 NICs, 2 Instances of ntpd;Possible?

    "Maarten Wiltink" writes:

    >"Danny Mayer" wrote in message
    >news:47D9ECFF.6030201@ntp.isc.org...
    >> Maarten Wiltink wrote:


    >>> As a software guy, I've wondered before about the monolithic nature
    >>> of the NTP package. Splitting it into a client and server part ...


    >> Maarten, NTP is unusual in that it does not lend itself to separation
    >> of client from server. This is not about statistics but about the
    >> nature of how it operates and is used. ...


    >Could you say more about that? I realise that it's not as clean cut as
    >the division between an FTP client and server, and that NTP may be
    >better served by a model like for example the server always requiring
    >some interchangeable client module(s?) being plugged into it (whether
    >network associations or hardware reference clocks, as mentioned).


    >The client part might operate without a server, or perhaps a downgraded
    >server that does not serve time but only offers status monitoring.


    Sure, but the server cannot operate without the client. YOu can certainly
    write an SNTP client, which is never a server. But servers need the full
    client functionality.

    >There are several different useage scenarios for NTP. Someone with a
    >web server farm might be interested in a client that keeps his servers
    >on time, but lets them be web servers, not time servers.


    >I realise that there is a mechanism to do this. I realise that I'm
    >speaking from the sideline. I'm just pointing out that everybody gets
    >all the code, all the time, and then has to restrict out the bits they
    >don't want. It seems like a somewhat unstructured way to build a big
    >system to me.



    >>> Also, the much-sought feature of re-resolving dried up associations
    >>> could be done from a cron job with ntpq/ntpdc. Determining for certain
    >>> what configuration to use might be a problem.

    >>
    >> I'll be working on it. I just need to get other things done too.


    >I'm sure we all do appreciate that. (-:


    >Groetjes,
    >Maarten Wiltink




  20. Re: 1 Machine, 2 NICs, 2 Instances of ntpd;Possible?

    "Unruh" wrote in message
    news:7nuCj.88488$w57.1957@edtnps90...
    > "Maarten Wiltink" writes:

    [...]
    >> The client part might operate without a server, or perhaps a downgraded
    >> server that does not serve time but only offers status monitoring.

    >
    > Sure, but the server cannot operate without the client. YOu can
    > certainly write an SNTP client, which is never a server. But servers
    > need the full client functionality.


    Some implementation of it, anyway. And a full NTP client can exist without
    a full server around it. At which point the code sculptor in me starts
    envisioning separate modules and clearly defined interfaces and pretty
    interlocking and interchangeable parts.

    Groetjes,
    Maarten Wiltink



+ Reply to Thread
Page 1 of 2 1 2 LastLast