4 ms·

Actually my comment is correct. You can't use the standard public time servers. Systemd has expressed that they do not want to apply for a vendor pool, for good

by Others 11y ago

Actually my comment is correct. You can't use the standard public time servers. Systemd has expressed that they do not want to apply for a vendor pool, for good or for ill.

crdoconnor 11y ago
>they do not want to apply for a vendor pool So apparently there's a super good reason for this. What exactly is it?
- Twirrim 11y ago
  "systemd is not a distribution." Which is a fair point, probably one of the few I agree with in the response. Systemd is just a software component. When you install ntpd and similar you'll find it almost always comes configured with a vendor pool for the distribution e.g. 0.ubuntu.pool.ntp.org The same should be applying for systemd. That said, they really shouldn't be setting defaults like this, especially not broken ones.
  - crdoconnor 11y ago
    >"systemd is not a distribution." I'd buy this if they explicitly didn't set a default ntp server at all, but that's not a good reason to set it to Google rather than ntp.org.
    - izacus 11y ago
      "Not being allowed to" is a pretty good reason to not use ntp.org I think.
      - DanBC 11y ago
        They are allowed to use pool, they just have to apply to use them. The linked thread has someone from Google telling systemd that systemd should stop using Google's time servers.
        Merovius 11y ago
        > They are allowed to use pool, they just have to apply to use them. Which has unclear (non-technical) implications. Which Lennart Poettering doesn't want to tolerate. Which I would consider a valid opinion. > The linked thread has someone from Google telling systemd that systemd should stop using Google's time servers. For technical reasons, that Lennart Poettering doesn't agree with (i.e. these defaults won't be used in production and if you use an unconfigured self-build of systemd in production, it's your own fault).
        jamespo 11y ago
        This doesn't address why not just leave it unconfigured. Unconfigured is better than a bad default.
        dagw 11y ago
        This doesn't address why not just leave it unconfigured. He addressed that in another post. Basically from a testing and development POV he believes it's important to ship with some default that at least works out of the box, even if the default is completely unsuitable for production.
        digi_owl 11y ago
        I think the worst issue here is that the result will be on the surface correct, unlike some other test settings that will show that the protocol/code works but that the settings needs to be changed to be useful. Something akin to the blinking 0:00, that shows the time circuit is powered up but with no time set.
      - crdoconnor 11y ago
        We've been over why that's false once already.
    - DanBC 11y ago
      (I accidentally downvoted you while I was trying to upvote you. Sorry.)
  - Niten 11y ago
    That's irrelevant, however. If systemd is going to ship with a default nameserver then it should be using the correct and public NTP pool, rather than servers from a random company who hasn't made any commitment to providing reliable UTC time to a public audience. And if it's using a service like the NTP pool, it needs to have a vendor prefix. Not because this has anything at all to do with the notion of being a "distribution", but because the prefix provides a means for the pool to identify traffic originating from default-configured systemd instances, and cut it off if it suddenly starts to behave in a way that would degrade the rest of the network. Or they can simply ship with no default. But you can't have it both ways, both setting a default server and claiming not to be a vendor in every sense meaningful to an NTP server operator.
- belorn 11y ago
  The settings is according to the developers only for testing purposes, like using ipsum lorem or example.com. The choices being debated seems are to have no settings by default, require that people who want to run test suites configures the software before testing, register a "vendor pool" for this purpose, find a better ntp server than google, or do nothing.
  - digi_owl 11y ago
    Except that isum lorem and example.com will both stand out as "working, but nonsense". If whatever time server they aimed the code at would constantly resolve to a date in the 1700s or something, it would be blatantly clear that setting has to be changed. But as it stands, it will give a correct response out of the box and thus give a false sense of nothing more needed being done.

by Others 11y ago

Actually my comment is correct. You can't use the standard public time servers. Systemd has expressed that they do not want to apply for a vendor pool, for good or for ill.

crdoconnor 11y ago

>they do not want to apply for a vendor pool So apparently there's a super good reason for this. What exactly is it?

Twirrim 11y ago
"systemd is not a distribution." Which is a fair point, probably one of the few I agree with in the response. Systemd is just a software component. When you install ntpd and similar you'll find it almost always comes configured with a vendor pool for the distribution e.g. 0.ubuntu.pool.ntp.org The same should be applying for systemd. That said, they really shouldn't be setting defaults like this, especially not broken ones.
- crdoconnor 11y ago
  >"systemd is not a distribution." I'd buy this if they explicitly didn't set a default ntp server at all, but that's not a good reason to set it to Google rather than ntp.org.
  - izacus 11y ago
    "Not being allowed to" is a pretty good reason to not use ntp.org I think.
    - DanBC 11y ago
      They are allowed to use pool, they just have to apply to use them. The linked thread has someone from Google telling systemd that systemd should stop using Google's time servers.
      - Merovius 11y ago
        > They are allowed to use pool, they just have to apply to use them. Which has unclear (non-technical) implications. Which Lennart Poettering doesn't want to tolerate. Which I would consider a valid opinion. > The linked thread has someone from Google telling systemd that systemd should stop using Google's time servers. For technical reasons, that Lennart Poettering doesn't agree with (i.e. these defaults won't be used in production and if you use an unconfigured self-build of systemd in production, it's your own fault).
        jamespo 11y ago
        This doesn't address why not just leave it unconfigured. Unconfigured is better than a bad default.
        dagw 11y ago
        This doesn't address why not just leave it unconfigured. He addressed that in another post. Basically from a testing and development POV he believes it's important to ship with some default that at least works out of the box, even if the default is completely unsuitable for production.
        digi_owl 11y ago
        I think the worst issue here is that the result will be on the surface correct, unlike some other test settings that will show that the protocol/code works but that the settings needs to be changed to be useful. Something akin to the blinking 0:00, that shows the time circuit is powered up but with no time set.
    - crdoconnor 11y ago
      We've been over why that's false once already.
  - DanBC 11y ago
    (I accidentally downvoted you while I was trying to upvote you. Sorry.)
- Niten 11y ago
  That's irrelevant, however. If systemd is going to ship with a default nameserver then it should be using the correct and public NTP pool, rather than servers from a random company who hasn't made any commitment to providing reliable UTC time to a public audience. And if it's using a service like the NTP pool, it needs to have a vendor prefix. Not because this has anything at all to do with the notion of being a "distribution", but because the prefix provides a means for the pool to identify traffic originating from default-configured systemd instances, and cut it off if it suddenly starts to behave in a way that would degrade the rest of the network. Or they can simply ship with no default. But you can't have it both ways, both setting a default server and claiming not to be a vendor in every sense meaningful to an NTP server operator.
belorn 11y ago
The settings is according to the developers only for testing purposes, like using ipsum lorem or example.com. The choices being debated seems are to have no settings by default, require that people who want to run test suites configures the software before testing, register a "vendor pool" for this purpose, find a better ntp server than google, or do nothing.
- digi_owl 11y ago
  Except that isum lorem and example.com will both stand out as "working, but nonsense". If whatever time server they aimed the code at would constantly resolve to a date in the 1700s or something, it would be blatantly clear that setting has to be changed. But as it stands, it will give a correct response out of the box and thus give a false sense of nothing more needed being done.