7 ms·

From https://wiki.archlinux.org/index.php/systemd-timesyncd https://wiki.archlinux.org/index.php/systemd-timesyncd : > In contrast to NTP implementations such

From https://wiki.archlinux.org/index.php/systemd-timesyncd https://wiki.archlinux.org/index.php/systemd-timesyncd : > In contrast to NTP implementations such as chrony or the NTP reference server [systemd-timesyncd] only implements a client side, and does not bother with the full NTP complexity, focusing only on querying time from one remote server and synchronizing the local clock to it.

h1d 9y ago
How does any average users and admins want NTP server feature on their machine? It just sounds like running a more complicated (meaning, more attack vectors) software for no reason.
- dozzie 9y ago
  Reference NTP server is less complicated than entangled steaming pile of "let's not" that is systemd. I trust the reference implementation more than I trust the team behind systemd with regard to network communication.
  - moe 9y ago
    Why is this is getting downvoted? systemd has a horrible security track record and should not be allowed on any server that is connected to the internet. The last remote-root exploit from 2 months ago: https://www.theregister.co.uk/2017/06/29/systemd_pwned_by_dns_query/ https://www.theregister.co.uk/2017/06/29/systemd_pwned_by_dn... The major distros urgently need to get rid of systemd and return to proven, modular init systems. systemd was the biggest single mistake in UNIX history.
    - rnhmjoj 9y ago
      I hate the binary logs of journald, the unnecessary complexity of stuff like systemd-hostnamed, dbus and the ignore-invalid-options policy but the init system it's actually very good. I don't want to return to a pile bash scripts with `sleep n` to get the system to boot, even if it's a proven method.
      - moe 9y ago
        Many other dependency/supervisor driven init systems exist (upstart, minit, daemontools, etc.). Upstart even was the Ubuntu default for a while. One of them should be adopted and fleshed out before systemd causes even more damage.
        ty_a 9y ago
        There should be competition but no one is willing to step up to the plate. That's the real issue.
        dozzie 9y ago
        That's false. There are several daemon managers designed to run as PID 1, starting with upstart the parent mentioned and you silently dismissed. The problem lays elsewhere.
        edoceo 9y ago
        Try OpenRC, really, give it a try. Simple, sane bash-like scripts, logging like you're used to and so easy to debug, and when you need to do your own custom stuff, simple and just works. Gentoo showed me this tool a few years ago. So happy. For years now I've heard loud stories about systemd +1 or -1. Same arguments over and over. Meanwhile, dozens of my servers and desktops and laptops keep humming along, I've like just never had to fuck with it. I should buy the OpenRC team some pizza. Thank you!
      - dozzie 9y ago
        This "pile bash scripts with sleep n" was at least debuggable and could be inspected and traced in different ways. With systemd, when something doesn't work as expected (which is often when you do anything that deviates even a little from standard), tough luck.
        digi_owl 9y ago
        The sad part is that much of the "standard" is not really standard, but what systemd thinks is "standard". Or that they cling to "standard on paper" rather than "standard in use", and thus end up rolling back decades of real life usage in the process. With systemd, perfect very much is the enemy of good. And both unix and Linux go where it is not by being perfect but by being good.
  - LukeShu 9y ago
    > Reference NTP server is less complicated than [systemd-timesyncd]. Reference ntpd source: ~130 kloc systemd timesyncd source: ~2 kloc Reference ntpd binary: ~700 KB systemd timesyncd binary: ~38 KB I get that you don't like systemd, or trust that team. But it's hard to say that ntpd is less complicated than timesyncd with a straight face. Maybe it is better engineered, more correct, more secure, or something; but not less complicated.
    - kakwa_ 9y ago
      Well, to configure ntpd as a basic client, the general workflow is the natural workflow of any daemon launched by init. 1) Install the package 2) Modify the configuration file if needed 3) Enable the service Taken alone timesyncd can be considered simpler to configure (no package to install, short configuration file), but it follows its own workflow, specially the command to enable or disable it (timedatectl set-ntp true), and to a lesser extent the location of its configuration file. For me it makes it harder to configure because, now, I must remember precisely all the steps where I could only remember a loss pattern, common with all other services, for ntpd. As itself, it's not that bad, it's a few commands, I can remember them, but it would definitely suck if every single service had its own pattern.
      - LukeShu 9y ago
        You can do everything the common pattern way with timesyncd as well. 1) Install the package (it's probably part of the systemd package you already have) 2) Modify the configuration file if needed (/etc/systemd/timesyncd.conf) 3) Enable the service (`systemctl enable systemd-timesyncd`; the same as any other service) Sure, you can use timedatectl to enable it (which makes a D-Bus call to timedated, which then makes the same call that `systemctl enable --now` does). But you don't have to. It's a weird feature of timedated/timedatectl because they try to be the Swiss-army-knife of messing with time settings on the box.
- yokaze 9y ago
  Systemd-timesyncd uses SNTP. SNTP is designed for desktop or embedded systems for a reason. It's more a convenience of not having to set your clock, or not having much resources. Accuracy: 100ms, no clock slewing. Try to correlate your logs with that, or run any distributed applications. https://unix.stackexchange.com/questions/305643/ntpd-vs-systemd-timesyncd-how-to-achieve-reliable-ntp-syncing https://unix.stackexchange.com/questions/305643/ntpd-vs-syst... https://github.com/coreos/bugs/issues/391 https://github.com/coreos/bugs/issues/391 Talking about attack vectors: SNTP has no no authentication, so you can practically set the clock on a server, if you have sufficient network access. That's fine for me on my laptop, but I don't see much point favouring well established solutions for saving a couple of MB RAM on a server.
- pwg 9y ago
  > How does any average users and admins want NTP server feature on their machine? To run one internal NTP reference that synchronizes to one or more external sources, with all other internal machines syncing with that one internal reference. Or, to hook an external hardware time clock up to one machine, then have the other internal local machines sync with that one machine that has an external hardware time clock. However, depending upon how one defines "average" user/admin will determine if either of the two above are things that such a user/admin might find useful.

h1d 9y ago

How does any average users and admins want NTP server feature on their machine? It just sounds like running a more complicated (meaning, more attack vectors) software for no reason.

dozzie 9y ago
Reference NTP server is less complicated than entangled steaming pile of "let's not" that is systemd. I trust the reference implementation more than I trust the team behind systemd with regard to network communication.
- moe 9y ago
  Why is this is getting downvoted? systemd has a horrible security track record and should not be allowed on any server that is connected to the internet. The last remote-root exploit from 2 months ago: https://www.theregister.co.uk/2017/06/29/systemd_pwned_by_dns_query/ https://www.theregister.co.uk/2017/06/29/systemd_pwned_by_dn... The major distros urgently need to get rid of systemd and return to proven, modular init systems. systemd was the biggest single mistake in UNIX history.
  - rnhmjoj 9y ago
    I hate the binary logs of journald, the unnecessary complexity of stuff like systemd-hostnamed, dbus and the ignore-invalid-options policy but the init system it's actually very good. I don't want to return to a pile bash scripts with `sleep n` to get the system to boot, even if it's a proven method.
    - moe 9y ago
      Many other dependency/supervisor driven init systems exist (upstart, minit, daemontools, etc.). Upstart even was the Ubuntu default for a while. One of them should be adopted and fleshed out before systemd causes even more damage.
      - ty_a 9y ago
        There should be competition but no one is willing to step up to the plate. That's the real issue.
        dozzie 9y ago
        That's false. There are several daemon managers designed to run as PID 1, starting with upstart the parent mentioned and you silently dismissed. The problem lays elsewhere.
      - edoceo 9y ago
        Try OpenRC, really, give it a try. Simple, sane bash-like scripts, logging like you're used to and so easy to debug, and when you need to do your own custom stuff, simple and just works. Gentoo showed me this tool a few years ago. So happy. For years now I've heard loud stories about systemd +1 or -1. Same arguments over and over. Meanwhile, dozens of my servers and desktops and laptops keep humming along, I've like just never had to fuck with it. I should buy the OpenRC team some pizza. Thank you!
    - dozzie 9y ago
      This "pile bash scripts with sleep n" was at least debuggable and could be inspected and traced in different ways. With systemd, when something doesn't work as expected (which is often when you do anything that deviates even a little from standard), tough luck.
      - digi_owl 9y ago
        The sad part is that much of the "standard" is not really standard, but what systemd thinks is "standard". Or that they cling to "standard on paper" rather than "standard in use", and thus end up rolling back decades of real life usage in the process. With systemd, perfect very much is the enemy of good. And both unix and Linux go where it is not by being perfect but by being good.
- LukeShu 9y ago
  > Reference NTP server is less complicated than [systemd-timesyncd]. Reference ntpd source: ~130 kloc systemd timesyncd source: ~2 kloc Reference ntpd binary: ~700 KB systemd timesyncd binary: ~38 KB I get that you don't like systemd, or trust that team. But it's hard to say that ntpd is less complicated than timesyncd with a straight face. Maybe it is better engineered, more correct, more secure, or something; but not less complicated.
  - kakwa_ 9y ago
    Well, to configure ntpd as a basic client, the general workflow is the natural workflow of any daemon launched by init. 1) Install the package 2) Modify the configuration file if needed 3) Enable the service Taken alone timesyncd can be considered simpler to configure (no package to install, short configuration file), but it follows its own workflow, specially the command to enable or disable it (timedatectl set-ntp true), and to a lesser extent the location of its configuration file. For me it makes it harder to configure because, now, I must remember precisely all the steps where I could only remember a loss pattern, common with all other services, for ntpd. As itself, it's not that bad, it's a few commands, I can remember them, but it would definitely suck if every single service had its own pattern.
    - LukeShu 9y ago
      You can do everything the common pattern way with timesyncd as well. 1) Install the package (it's probably part of the systemd package you already have) 2) Modify the configuration file if needed (/etc/systemd/timesyncd.conf) 3) Enable the service (`systemctl enable systemd-timesyncd`; the same as any other service) Sure, you can use timedatectl to enable it (which makes a D-Bus call to timedated, which then makes the same call that `systemctl enable --now` does). But you don't have to. It's a weird feature of timedated/timedatectl because they try to be the Swiss-army-knife of messing with time settings on the box.
yokaze 9y ago
Systemd-timesyncd uses SNTP. SNTP is designed for desktop or embedded systems for a reason. It's more a convenience of not having to set your clock, or not having much resources. Accuracy: 100ms, no clock slewing. Try to correlate your logs with that, or run any distributed applications. https://unix.stackexchange.com/questions/305643/ntpd-vs-systemd-timesyncd-how-to-achieve-reliable-ntp-syncing https://unix.stackexchange.com/questions/305643/ntpd-vs-syst... https://github.com/coreos/bugs/issues/391 https://github.com/coreos/bugs/issues/391 Talking about attack vectors: SNTP has no no authentication, so you can practically set the clock on a server, if you have sufficient network access. That's fine for me on my laptop, but I don't see much point favouring well established solutions for saving a couple of MB RAM on a server.
pwg 9y ago
> How does any average users and admins want NTP server feature on their machine? To run one internal NTP reference that synchronizes to one or more external sources, with all other internal machines syncing with that one internal reference. Or, to hook an external hardware time clock up to one machine, then have the other internal local machines sync with that one machine that has an external hardware time clock. However, depending upon how one defines "average" user/admin will determine if either of the two above are things that such a user/admin might find useful.