Bug#289267: [pkg-ntp-maintainers] Bug#289267: [debian-ntp] Bug#289267: ntp: NTP on ifup
* Peter Eisentraut Well, I don't know what Ubuntu has done or does, but the current behavior was requested in Debian bug reports. If we don't run ntpdate on ifup, when would we run it? During boot, after the network is normally started, and before system services are started. If there's no network available before services are started, the clock should not be stepped by ntpdate at all. IMHO. Regards -- Tore Anderson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#289267: [pkg-ntp-maintainers] Bug#289267: [debian-ntp] Bug#289267: ntp: NTP on ifup
* Peter Eisentraut The ntpdate README.Debian says: ntpdate is run whenever a network interface is brought up. To adjust this behavior, the file /etc/network/if-up.d/ntpdate should be edited. That file in turn says: # ... Feel free to change this, especially if you regularly # bring up new network interfaces. If people don't read the documentation, we can't help them. Why would you expect me to read the documentation of the ntpdate program when it is a completely unrelated command, ifup, that I am running? To look at it the opposite way, if I wanted to adjust my clock, I would go read the NTP documentation, not the networking documentation. And I would certainly not expect the ntpdate invocation to result in an ifup being run. That said, the ntpdate default configuration is optimized for a desktop. On a server you would use ntpd anyway, so there is no need for ntpdate. I think this is a reasonable compromise. I agree, but on Ubuntu ntpdate is part of the default server installation (the meta package ubuntu-minimal depends on it, and it's priority important). It is more exusable to mimic their behaviour in Debian if the ntpdate program isn't installed by default. -- Tore Anderson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#289267: [pkg-ntp-maintainers] Bug#289267: [debian-ntp] Bug#289267: ntp: NTP on ifup
Tore Anderson schrieb: * Peter Eisentraut That said, the ntpdate default configuration is optimized for a desktop. On a server you would use ntpd anyway, so there is no need for ntpdate. I think this is a reasonable compromise. It is more exusable to mimic their behaviour in Debian if the ntpdate program isn't installed by default. I would agree here. Don't install it by default, since Debian has no way at moment to detect first connection usable for NTP, which is required to run ntpdate the way it is intended. I would install it anyway on most machines, since lots of software can actually cope with time going backwards and. An machine with software not able to cope just needs one reboot more to really have the time correct AND that software usable. That is ok for all cases I need ntpdate for which are: - network plugging of completely new machine installed from image - activation of reserve hardware - periodic update of an long time offline machine. For all other cases ntpd is better. Regards Ingo Oeser -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#289267: [pkg-ntp-maintainers] Bug#289267: [debian-ntp] Bug#289267: ntp: NTP on ifup
Am Freitag, 15. Dezember 2006 14:29 schrieb Tore Anderson: Why would you expect me to read the documentation of the ntpdate program when it is a completely unrelated command, ifup, that I am running? You are expected to read the README.Debian file of every package you install. I agree, but on Ubuntu ntpdate is part of the default server installation (the meta package ubuntu-minimal depends on it, and it's priority important). I don't know what Ubuntu has to do with this. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#289267: [pkg-ntp-maintainers] Bug#289267: [debian-ntp] Bug#289267: ntp: NTP on ifup
* Peter Eisentraut You are expected to read the README.Debian file of every package you install. Right. You have way too much faith in our users, including me. I don't know what Ubuntu has to do with this. You should try reading the whole bug report, then. I would expect you to have no problem with it, if you've read all those README.Debian files... :-P This bug is about copying Ubuntu's current behaviour, which is to run ntpdate on every ifup. The text I initially replied to was from Ingo Oeser: The proposed solution of using /etc/networking/if-up.d/ works without any problem for most of your users. Actually unbuntu Dapper Drake is just doing it this way and I never had any problems. We fixed it for our customers the same way. I said the way Ubuntu does it is unsafe and that it causes major problems if you're unlucky like me. Scott James Remnant of Ubuntu has acknowledged this, too: We think it's a bug in our current install; but one that is less than the previous bug of the clock being not changed at all. Debian certainly shouldn't follow suit, unless they're also happy to have an open bug that the clock is slewed whenever a network interface comes up. (I'm fairly sure he meant stepped instead of slewed here, btw.) But he pretty much sums up what I'm trying to advocate here. I'm interested in Debian and Ubuntu being as excellent operating systems as possible, and I feel this behaviour run counter to that, at least when they're used on servers where you really really don't want magic things like this to happen. Regards -- Tore Anderson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#289267: [pkg-ntp-maintainers] Bug#289267: [debian-ntp] Bug#289267: ntp: NTP on ifup
Am Freitag, 15. Dezember 2006 15:57 schrieb Tore Anderson: This bug is about copying Ubuntu's current behaviour, which is to run ntpdate on every ifup. The text I initially replied to was from Ingo Well, I don't know what Ubuntu has done or does, but the current behavior was requested in Debian bug reports. If we don't run ntpdate on ifup, when would we run it? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#289267: [pkg-ntp-maintainers] Bug#289267: [debian-ntp] Bug#289267: ntp: NTP on ifup
Tore Anderson wrote: I also have an objection to the if-up.d script per se, though, but this is not as strong. I simply do not expect things to happen to my clock when I fiddle around with my network interfaces. The ntpdate README.Debian says: ntpdate is run whenever a network interface is brought up. To adjust this behavior, the file /etc/network/if-up.d/ntpdate should be edited. That file in turn says: # ... Feel free to change this, especially if you regularly # bring up new network interfaces. If people don't read the documentation, we can't help them. That said, the ntpdate default configuration is optimized for a desktop. On a server you would use ntpd anyway, so there is no need for ntpdate. I think this is a reasonable compromise. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#289267: [pkg-ntp-maintainers] Bug#289267: [debian-ntp] Bug#289267: ntp: NTP on ifup
* Kurt Roeckx -b means always step, -B means slew, and you asked for -B before? Ranked in order of preference (as defaults, at least): 1) No gratuitous clock adjustments whatsoever (no if-up.d script) 2) No gratuitous clock stepping whatsoever (use of -B) 3) No gratituous clock stepping unless large offset (default ntpdate) 4) Gratituous clock stepping (use of -b) Ubuntu went with #4 for their Dapper release. It now seems to be using -b if it's a static interfacce. Do you mean a interface not using DHCP here? If so I wonder what that has got to with anything... ntpdate shouldn't be changing time when ntpd is running, and ntp doesn't get restrarted by default, so I guess I'm still not getting it. If the scripts turns into a no-op when ntpd is installed I have no objection to it (although I really think -b isn't called for in any case). That didn't happen in Ubuntu though... All I'm asking is that if you implement something similar in Debian, please be more careful then they were. Clock stepping is _dangerous_ and should IMO be done only as the system is brought up, and especially not as a result of fiddling with something that one would think is completely unrelated to system time, such as network interfaces. Regards -- Tore Anderson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#289267: [pkg-ntp-maintainers] Bug#289267: [debian-ntp] Bug#289267: ntp: NTP on ifup
On Tue, Dec 12, 2006 at 08:41:12AM +0100, Tore Anderson wrote: * Kurt Roeckx Can I suggest you run ntpd with the -x option in that case? I already do. Both ntpdate and ntpd will by default slew the time if it's smaller the 128 ms, and step when it's bigger. I know. Maybe I should have been clearer though, what I'm objecting to is primarily the suggestion to mimic the way Ubuntu does it, as they invoke ntpdate with the -b parameter in the if-up.d script, ensuring that the clock will _always_ leap. -b means always step, -B means slew, and you asked for -B before? It now seems to be using -b if it's a static interfacce. I also have an objection to the if-up.d script per se, though, but this is not as strong. I simply do not expect things to happen to my clock when I fiddle around with my network interfaces. I have always thought the primary task of ntpdate is to quickly get time roughly correct at bootup, so that ntpd will have a much easier job of getting the box completely into sync. When this combo is working ntpd will ~never step time, even without -x (barring bad hardware). If no NTP server is available at bootup, well, then you'll just have to wait for a network connection and possibly step the time then. And isn't that _exactly_ what ntpd'll do when run without the -x option? Then why throw ntpdate into the mix here? It's after all less precise than ntpd so chances are you'll end up with a clock that's more out of sync than before... ntpdate shouldn't be changing time when ntpd is running, and ntp doesn't get restrarted by default, so I guess I'm still not getting it. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#289267: [pkg-ntp-maintainers] Bug#289267: [debian-ntp] Bug#289267: ntp: NTP on ifup
On Mon, Dec 11, 2006 at 12:32:52PM +0100, Tore Anderson wrote: * Ingo Oeser The proposed solution of using /etc/networking/if-up.d/ works without any problem for most of your users. Actually unbuntu Dapper Drake is just doing it this way and I never had any problems. We fixed it for our customers the same way. This is scary. I just had a rather unpleasant experience with this behaviour on a router box here. Time was a little bit out of sync, upped an interface, and then the time was stepped, something that made OSPF die in horror as it can't quite cope with the situation where time goes backwards (no wonder). Can I suggest you run ntpd with the -x option in that case? Both ntpdate and ntpd will by default slew the time if it's smaller the 128 ms, and step when it's bigger. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#289267: [pkg-ntp-maintainers] Bug#289267: [debian-ntp] Bug#289267: ntp: NTP on ifup
* Kurt Roeckx Can I suggest you run ntpd with the -x option in that case? I already do. Both ntpdate and ntpd will by default slew the time if it's smaller the 128 ms, and step when it's bigger. I know. Maybe I should have been clearer though, what I'm objecting to is primarily the suggestion to mimic the way Ubuntu does it, as they invoke ntpdate with the -b parameter in the if-up.d script, ensuring that the clock will _always_ leap. I also have an objection to the if-up.d script per se, though, but this is not as strong. I simply do not expect things to happen to my clock when I fiddle around with my network interfaces. I have always thought the primary task of ntpdate is to quickly get time roughly correct at bootup, so that ntpd will have a much easier job of getting the box completely into sync. When this combo is working ntpd will ~never step time, even without -x (barring bad hardware). If no NTP server is available at bootup, well, then you'll just have to wait for a network connection and possibly step the time then. And isn't that _exactly_ what ntpd'll do when run without the -x option? Then why throw ntpdate into the mix here? It's after all less precise than ntpd so chances are you'll end up with a clock that's more out of sync than before... -- Tore Anderson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
