Re: [ntp:questions] 1 Machine, 2 NICs, 2 Instances of ntpd; Possible?
Maarten Wiltink [EMAIL PROTECTED] writes: Danny Mayer [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] 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 ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] 1 Machine, 2 NICs, 2 Instances of ntpd; Possible?
Unruh [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Maarten Wiltink [EMAIL PROTECTED] 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 ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] 1 Machine, 2 NICs, 2 Instances of ntpd; Possible?
Maarten Wiltink wrote: 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). I think you will find that nearly all the code in ntpd is client code or common to both client and server. The client function is the difficult bit. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] 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 ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] 1 Machine, 2 NICs, 2 Instances of ntpd; Possible?
Johnson, John-P63914 wrote: One instance of ntpd is all that is necessary to perform both of these tasks at the same time. I realize that what I am trying to do is very easily accomplished with one instance of ntpd. However, I assure you that the manner in which I am trying to accomplish it is absolutely necessary for my particular application. There is something here that you are not telling us. I found a definitive answer in the code. ntp_io.c, line 1232 /* * Check to see if we are going to use the interface * If we don't use it we mark it to drop any packet * received but we still must create the socket and * bind to it. This prevents other apps binding to it * and potentially causing problems with more than one * process fiddling with the clock */ This explains why an instance was still receiving packets from an interface that was not specified with '-I'. Not quite. It's more complicated than that. There are other addresses involved like the wildcard addresses and the loopback addresses. Danny ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] 1 Machine, 2 NICs, 2 Instances of ntpd; Possible?
Maarten Wiltink wrote: David Woolley [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] 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. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] 1 Machine, 2 NICs, 2 Instances of ntpd; Possible?
David Woolley [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Maarten Wiltink wrote: David Woolley [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] 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 ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] 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 [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Maarten Wiltink wrote: David Woolley [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] 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 ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] 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. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] 1 Machine, 2 NICs, 2 Instances of ntpd; Possible?
Steve Kostecke [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] 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 ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] 1 Machine, 2 NICs, 2 Instances of ntpd; Possible?
On 2008-03-11, Maarten Wiltink [EMAIL PROTECTED] wrote:
Steve Kostecke [EMAIL PROTECTED] 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 [EMAIL PROTECTED]
NTP Public Services Project - http://support.ntp.org/
___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] 1 Machine, 2 NICs, 2 Instances of ntpd; Possible?
Steve Kostecke [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] On 2008-03-11, Maarten Wiltink [EMAIL PROTECTED] 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 ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] 1 Machine, 2 NICs, 2 Instances of ntpd; Possible?
One instance of ntpd is all that is necessary to perform both of these tasks at the same time. I realize that what I am trying to do is very easily accomplished with one instance of ntpd. However, I assure you that the manner in which I am trying to accomplish it is absolutely necessary for my particular application. I found a definitive answer in the code. ntp_io.c, line 1232 /* * Check to see if we are going to use the interface * If we don't use it we mark it to drop any packet * received but we still must create the socket and * bind to it. This prevents other apps binding to it * and potentially causing problems with more than one * process fiddling with the clock */ This explains why an instance was still receiving packets from an interface that was not specified with '-I'. Thank you very much for the help. Cheers Johnny ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] 1 Machine, 2 NICs, 2 Instances of ntpd; Possible?
[EMAIL PROTECTED] (Johnson, John-P63914) writes: One instance of ntpd is all that is necessary to perform both of these tasks at the same time. I realize that what I am trying to do is very easily accomplished with one instance of ntpd. However, I assure you that the manner in which I am trying to accomplish it is absolutely necessary for my particular application. Uh, and we believe you why? It is very hard to imagine a situation where what you want is absolutely necessary. I found a definitive answer in the code. ntp_io.c, line 1232 /* * Check to see if we are going to use the interface * If we don't use it we mark it to drop any packet * received but we still must create the socket and * bind to it. This prevents other apps binding to it * and potentially causing problems with more than one * process fiddling with the clock */ This explains why an instance was still receiving packets from an interface that was not specified with '-I'. Thank you very much for the help. Cheers Johnny ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] 1 Machine, 2 NICs, 2 Instances of ntpd; Possible?
On 2008-03-11, Maarten Wiltink [EMAIL PROTECTED] wrote: Steve Kostecke [EMAIL PROTECTED] 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 [EMAIL PROTECTED] NTP Public Services Project - http://support.ntp.org/ ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] 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
___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] 1 Machine, 2 NICs, 2 Instances of ntpd; Possible?
Steve Kostecke [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] [...] 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 ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] 1 Machine, 2 NICs, 2 Instances of ntpd; Possible?
Maarten Wiltink [EMAIL PROTECTED] 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... ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] 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. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] 1 Machine, 2 NICs, 2 Instances of ntpd; Possible?
David Woolley [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Maarten Wiltink wrote: separating NTP client and server parts [...] 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 ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] 1 Machine, 2 NICs, 2 Instances of ntpd; Possible?
We don't know what you are trying to do since you haven't told us. I apologize for the lack of clarity. 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. Thank you Johnny ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] 1 Machine, 2 NICs, 2 Instances of ntpd; Possible?
On 2008-03-10, Johnson, John-P63914 [EMAIL PROTECTED] 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. Once instance of ntpd is all that is necessary to perform both of these tasks at the same time. Why do you feel you need two instances? -- Steve Kostecke [EMAIL PROTECTED] NTP Public Services Project - http://support.ntp.org/ ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] 1 Machine, 2 NICs, 2 Instances of ntpd; Possible?
Johnson, John-P63914 wrote: We don't know what you are trying to do since you haven't told us. I apologize for the lack of clarity. 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. Thank you Johnny I don't see why you need, or believe you need, two instances of ntpd. One should do it all. If you'll tell us what platform you are running on, perhaps someone can assist you with setting up the routing; it's not terribly difficult on any of the platforms I've worked with. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] 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 [EMAIL PROTECTED] NTP Public Services Project - http://support.ntp.org/ ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
[ntp:questions] 1 Machine, 2 NICs, 2 Instances of ntpd; Possible?
Hello, I have a machine with two network interfaces. I need to have two instances of ntpd running, one for each interface. Initially I attempted to partition the two by restricting all access from network B to ntpd instance A and vice versa in their respective ntp.conf's. However, I soon discovered this wasn't going to work because both instances were binding on both interfaces, resulting in conflict. I tried to remedy this by installing NTP 4.2.4p4 and using the -I option to specify to which interface a particular ntpd instance should bind. With limited experimentation, I seem to be running into the same problem of each instance receiving packets from both networks. Is what I am trying to do feasible? Cheers Johnny ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] 1 Machine, 2 NICs, 2 Instances of ntpd; Possible?
Johnson, John-P63914 wrote: Hello, I have a machine with two network interfaces. I need to have two instances of ntpd running, one for each interface. What problem are you trying to solve? There is only ONE system clock and only one copy of ntpd can discipline that clock. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] 1 Machine, 2 NICs, 2 Instances of ntpd; Possible?
Johnson, John-P63914 wrote: Hello, I have a machine with two network interfaces. I need to have two instances of ntpd running, one for each interface. Why would you want that? What problem are you trying solve? You shouldn't be doing this. Initially I attempted to partition the two by restricting all access from network B to ntpd instance A and vice versa in their respective ntp.conf's. However, I soon discovered this wasn't going to work because both instances were binding on both interfaces, resulting in conflict. Correct that's by design. However see bug #983 and #984 for some changes that I have made. It's currently being held up by a syntax question. I tried to remedy this by installing NTP 4.2.4p4 and using the -I option to specify to which interface a particular ntpd instance should bind. With limited experimentation, I seem to be running into the same problem of each instance receiving packets from both networks. Right. It's no different from before. Is what I am trying to do feasible? We don't know what you are trying to do since you haven't told us. Danny Cheers Johnny ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] 1 Machine, 2 NICs, 2 Instances of ntpd; Possible?
[EMAIL PROTECTED] (Johnson, John-P63914) writes: Hello, I have a machine with two network interfaces. I need to have two instances of But it has only one clock! Exactly what do you hope to accompplish? ntpd running, one for each interface. Initially I attempted to ntp is for disciplinign clocks, not running on interfaCES partition the two by restricting all access from network B to ntpd instance A and vice versa in their respective ntp.conf's. However, I soon discovered this wasn't going to work because both instances were binding on both interfaces, resulting in conflict. I tried to remedy this by installing NTP 4.2.4p4 and using the -I option to specify to which interface a particular ntpd instance should bind. With limited experimentation, I seem to be running into the same problem of each instance receiving packets from both networks. Is what I am trying to do feasible? So far it makes no sense to me. Cheers Johnny ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
