Am 10.01.2013 19:46, schrieb Cristian Rodríguez:

ntpd lacks of systemd units..probably because there are non-standard or crazy SUSE additions like running the ntp in chroot

Running ntp in a chroot environment is not "crazy" or "non-standard". It is a necessity. -- Stefan Seyfried "If your lighter runs out of fluid or flint and stops making fire, and you can't be bothered to figure out about lighter fluid or flint, that is not Zippo's fault." -- bkw -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Fri, Jan 11, 2013, at 12:34 PM, Stefan Seyfried wrote:

Running ntp in a chroot environment is not "crazy" or "non-standard". It is a necessity.

+1! fwiw, until such time that proper ntp-systemd integration in the distro happens, using the distro's bins, rpm -qa | grep -i ntp-4 ntp-4.2.6p5-3.10.1.x86_64 with a config that includes, e.g., cat /etc/ntp.conf ... driftfile /drift/ntp.drift logfile /var/log/ntp statsdir /cache/ntpstats/ keys /etc/ntp.keys ... this simple unit/procedure I got from a friend works nicely, cat /etc/systemd/system/ntp.service [Unit] Description=ntpd After=syslog.target network.target [Service] ExecStart=/usr/sbin/ntpd -u ntp:ntp -i /var/chroot/ntp -n -g -p /run/ntpd.pid [Install] WantedBy=multi-user.target don't forget to reload systemctl --system daemon-reload and make sure the mount points exist, etc. adding to fstab works well enough, cat /etc/fstab ... /etc/ntp.conf /var/chroot/ntp/etc/ntp.conf none bind 0 0 /etc/resolv.conf /var/chroot/ntp/etc/resolv.conf none bind 0 0 /etc/services /var/chroot/ntp/etc/services none bind 0 0 /lib /var/chroot/ntp/lib none bind 0 0 /proc /var/chroot/ntp/proc none bind 0 0 then, mount -a systemctl start ntp.service systemctl status ntp.service ntp.service - ntpd Loaded: loaded (/etc/systemd/system/ntp.service; enabled) Active: active (running) since Tue, 08 Jan 2013 07:42:44 -0800; 3 days ago Main PID: 2836 (ntpd) CGroup: name=systemd:/system/ntp.service └ 2836 /usr/sbin/ntpd -u ntp:ntp -i /var/chroot/ntp -n -g -p /run/ntpd.pid hth -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

El 12/01/13 06:30, Carlos E. R. escribió:

The problem is systemd not being a plug in replacement for systemv, contrary to what is announced.

It is clearly documented that non-standard init scripts are not supported and will never be. In any case, timedatectl is much, much better than what we already have. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Sat, 12 Jan 2013 14:48:00 +0100 "Carlos E. R." wrote:

...

It is clearly documented that non-standard init scripts are not supported and will never be.

That is an unaceptable support regression.

It is not. Christian means any script. You have a way to call any script from service files, but running it has limitations. The systemd sets some new rules how programs can behave, but that is nothing completely new. There is PAM, apparmor etc, that will stop some scripts written prior to their introduction. In computing, sooner or later, security reasons will dictate introduction of new functions, and scripts that use flawed functions will stop working. I don't think that you consider security related application breakage as regression :) Of course, systemd authors are very capable in their field of expertise, which gives them feeling that they know all, and that, on occasions clashes with reality, but taking complexity of system control and what they did by now, that doesn't happen very often. -- Regards, Rajko. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Good points! Could you kindly make them without hijacking my thread? Personally, I'm still interested in chrony as the focus of my thread. Thanks. On Sat, Jan 12, 2013, at 09:28 AM, Michael Catanzaro wrote:

On Sat, 2013-01-12 at 09:07 -0600, Rajko wrote:

...

On Sat, 12 Jan 2013 14:48:00 +0100 "Carlos E. R." wrote:

...

...

It is clearly documented that non-standard init scripts are not supported and will never be.

That is an unaceptable support regression.

It is not.

There's no sense in debating this since systemd is already here to stay - now we have to make it work. If ntpd can be made to work fine with an initscript then great; if not it needs to be fixed. And right now it needs fixed.

timedated and timedatectl would be nice if they worked - right now they're broken. (If you check the source, it's expecting to find an ntp unit file - which is not exactly an unreasonable expectation, though something that could be patched if that'd be easier than providing a unit. Though maybe something else is wrong too.) This is bad because GNOME requires us to have a working timedated, else the time/date panel in GNOME Control Center is completely broken (as it is in 12.2) - which is major broken functionality. And yes I know 12.2 doesn't have timedatectl, but it does have timedated and it doesn't work: https://bugzilla.novell.com/show_bug.cgi?id=796055

(Keep in mind that I don't always know what I'm talking about in that report, and as of yet nobody's swooped in to correct potential misstatements - but that's the general problem.)

Also, and this particular point is not really related to systemd but it's important enough to mention - NTP is by default broken regardless. Install with a live CD, select an NTP server, set NTP to run as a daemon... and congrats, all of your settings are completely ignored and you're set to undisciplined local clock. (But for some reason it works fine for DVD installs.) If you're not reasonably skilled with computers you have no change at getting network time to work, since that's a pretty confusing YaST module. (And if you use KDE, you might not even notice that everything's broken.) https://bugzilla.novell.com/show_bug.cgi?id=784760

And here's one that may or may not be covered by a variety of outstanding NTP bugs (maybe https://bugzilla.novell.com/show_bug.cgi?id=774502 ?)

Jan 12 10:35:41 victory-road ntp[683]: 12 Jan 10:35:41 sntp[746]: Error looking up bigben.cac.washington.edu: Name or service not known Jan 12 10:35:41 victory-road ntp[683]: Unable to resolve hostname(s) Jan 12 10:35:41 victory-road ntp[683]: Time could not be synchronized

This is the default NTP behavior in openSUSE (once you set it to look up a real public server). It's not a big deal since NTP works fine after that initial failure, but still, shouldn't be happening and the only error I get when I boot.

systemd has happened whether we all like it or not; ntpd needs to work with it. Other major distros have had no problem with this.

-- Michael Catanzaro Email had 1 attachment: + signature.asc 1k (application/pgp-signature) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Sun, 2013-01-13 at 12:57 -0800, darx@sent.com wrote:

I guess that's a "no", huh?

On Sat, Jan 12, 2013, at 09:33 AM, darx@sent.com wrote:

...

Could you kindly make them without hijacking my thread?

I did split it into a new topic by altering the subject line. Best wishes and good luck getting chrony accepted. :-) -- Michael Catanzaro

В Sat, 12 Jan 2013 11:28:01 -0600 Michael Catanzaro пишет:

On Sat, 2013-01-12 at 09:07 -0600, Rajko wrote:

...

On Sat, 12 Jan 2013 14:48:00 +0100 "Carlos E. R." wrote:

...

...

It is clearly documented that non-standard init scripts are not supported and will never be.

That is an unaceptable support regression.

It is not.

There's no sense in debating this since systemd is already here to stay - now we have to make it work. If ntpd can be made to work fine with an initscript then great; if not it needs to be fixed. And right now it needs fixed.

timedated and timedatectl would be nice if they worked - right now they're broken. (If you check the source, it's expecting to find an ntp unit file - which is not exactly an unreasonable expectation, though something that could be patched if that'd be easier than providing a unit.

What is wrong with adding unit that calls initscript? This will fix timedated NTP information and leave time to work on native ntpd.service implementation.

Though maybe something else is wrong too.)

Yes, on 12.2 timezone information is wrong. timedated takes it from /etc/timezone which does not exits. You can of course create it, but will not be kept in sync by YaST2. Current upstream systemd dropped this and simply assumes /etc/localtime is always a link to correct timezone file. I do not know whether a) version in 12.3 already have this change b) YaST2 12.3 is modified to create link. /etc/localtime is plain file on 12.2.

Also, and this particular point is not really related to systemd but it's important enough to mention - NTP is by default broken regardless.

One problem that seems to be totally ignored is https://bugzilla.novell.com/show_bug.cgi?id=791106 Many people are affected, and it severely breaks dual boot with Windows.

On Sat, 2013-01-12 at 22:56 +0400, Andrey Borzenkov wrote:

What is wrong with adding unit that calls initscript? This will fix timedated NTP information and leave time to work on native ntpd.service implementation.

I don't myself see anything wrong with that. (Though the initscript would then no longer want to live in /etc/init.d.)

...

Though maybe something else is wrong too.)

Yes, on 12.2 timezone information is wrong. timedated takes it from /etc/timezone which does not exits. You can of course create it, but will not be kept in sync by YaST2.

Current upstream systemd dropped this and simply assumes /etc/localtime is always a link to correct timezone file. I do not know whether

a) version in 12.3 already have this change b) YaST2 12.3 is modified to create link. /etc/localtime is plain file on 12.2.

I believe that's already fixed for 12.3 - yay!

...

Also, and this particular point is not really related to systemd but it's important enough to mention - NTP is by default broken regardless.

One problem that seems to be totally ignored is https://bugzilla.novell.com/show_bug.cgi?id=791106 Many people are affected, and it severely breaks dual boot with Windows.

Not a solution, but Windows seems to support hardware clock in UTC much better than Linux supports hardware clock in localtime. There's a registry key to change that which might be worth trying out. -- Michael Catanzaro

On 14/01/13 02:39, Andrey Borzenkov wrote:

÷ Sun, 13 Jan 2013 14:27:29 -0600 Michael Catanzaro ÐÉÛÅÔ:

...

On Sat, 2013-01-12 at 22:56 +0400, Andrey Borzenkov wrote:

...

What is wrong with adding unit that calls initscript? This will fix timedated NTP information and leave time to work on native ntpd.service implementation. I don't myself see anything wrong with that. (Though the initscript would then no longer want to live in /etc/init.d.)

Sorry? It ntpd.service that will live somewhere else; and it will call /etc/init.d/ntp.

...

...

One problem that seems to be totally ignored is https://bugzilla.novell.com/show_bug.cgi?id=791106 Many people are affected, and it severely breaks dual boot with Windows.

Not a solution, but Windows seems to support hardware clock in UTC much better than Linux supports hardware clock in localtime. There's a registry key to change that which might be worth trying out.

You miss the point. System stores time in RTC as UTC even though it was explicitly configured to store time in RTC as local time. This is a bug. It is unrelated to whether I dual boot or not. There is a program "ptktime" (Perl/Tk Time Client) I have used for several years that shows the difference between the hardware clock and ntp.

On some boxes it shows ~-3600 seconds difference after booting up. "systemctl restart ntp.service" synchronizes the clocks. Next time I reboot I'll recheck if ntpd is actually running - I think it is but I'll verify that. Regards Sid. -- Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support Senior Staff Specialist, Cricket Coach Microsoft Windows Free Zone - Linux used for all Computing Tasks -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Dnia czwartek, 10 stycznia 2013 20:52:30 plinnell pisze:

On Thu, 10 Jan 2013 09:25:03 -0800

darx@sent.com wrote:

...

I have/use a Roaming Laptop (Opensuse 12.2/KDE) that connects to a variety of networks, with varying assigned IPs, frequently offline.

It's a very common use-case.

For network managemet, I use NetworkManager.

I need to manage clock-sync, conditionally using different servers depending on LAN/IP state. E.g.,

(1) @ local only / offline, use NO server, local clock only (2) @ LAN ip = specific IP (e.g., @ my office LAN,

10.11.12.13), use ntp server = 10.11.12.100

(3) @ a roaming-assigned, random IP, use a set of external/public stratum servers.

Opensuse 12.2/Factory 'officially' package/release ntpd.

I currently launch ntpd with a systemd unit file.

Conditional ntp config could be implemented by building logic into

(1) systemd unit (2) NetworkManager up/down/change scripts

Discussing upstream @ both 'systemd' and 'ntp', neither is recommended. From both, for such roaming use cases, the use of "chrony" (http://chrony.tuxfamily.org/FAQ.html#question_2.1) is recommended. Particularly as ntpd sync/slew is not reliable if the host machine is often disconnected.

Checking opensuse* for chrony packaging, I find we do NOT package it for 12.2 at all, and for -factory there's no official release, only in network:time.

For such a frequent/common use case, I'm requesting that chrony be considered for promotion/inclusion as an official product, and enabled for both factory and current stable release.

See: https://build.opensuse.org/request/show/147993

Note it needs to be accepted by the maintainers of network:time.

Peter

Accordind to rpmlint: | chrony.i586: W: non-standard-uid /var/lib/chrony chrony | chrony.i586: W: non-standard-uid /var/log/chrony chrony | A file in this package is owned by an unregistered user id. To register the | user, please branch the devel:openSUSE:Factory:rpmlint rpmlint package, add | the user to the "config" file and send a submitrequest. If we are going to get this package into Factory OSS, then please add new user to rpmlint. Beside it, package looks fine. I'm accepting #rq147993 -- Pozdrawiam / Best regards, Mariusz Fik openSUSE Community Member GPG: 5FCE 7241 B3B9 32FD 455B C30E 42D6 6C88 9E83 7C3D