8 ms·

Wrote this comment a while ago for anyone wondering about this: Just installed it in a VM, changes that jumped out at me: • No Python (that you should develop

by chomp 7y ago

Wrote this comment a while ago for anyone wondering about this: Just installed it in a VM, changes that jumped out at me: • No Python (that you should develop against) installed out of the box. There's a /usr/libexec/platform-python (3.6) that yum (dnf) runs against, and then python2/python3 packages you can optionally install if you want to run python scripts. • Kernel 4.18 • No more ntpd, chrony only • /etc/sysconfig/network-scripts is a ghost town, save for a lonely ifcfg file for my network adapter. No more /etc/init.d/network, so /etc/init.d is finally cleaned out. It looks like static routes still go in route-<adapter> and you ifdown/ifup to pull those in (it calls nmcli). • Pretty colors when running dmesg!

sparkling 7y ago
It makes a lot of sense that OS-stuff points to a seperate Python interpreter, don't you think? I like this approach.
- lima 7y ago
  Exactly, and with App Streams you won't be stuck on an old Python version! This is an awesome feature. You already have that on CentOS/RHEL 7 with Software Collections, and App Streams make it a first-class citizen.
- Diederich 7y ago
  Aye; this should have been done a long time ago. I wanted to say 'since the beginning' (whenever that was), but maybe there were good reasons 20 years ago that I can't recall. It probably made sense when disk space was a lot more constrained.
  - toyg 7y ago
    It just wasn't the practice back in the day. Does redhat ship a "platform-perl"?
    - vetinari 7y ago
      As far as I remember, there is no perl at all in minimal install of v7.
- vbezhenar 7y ago
  Do you think that there should be separate platform-sh interpreter for system shell scripts, and so on? That kind of strange for me. Probably difference is that shell is "complete" program, while Python is not.
  - auscompgeek 7y ago
    The difference with system shell scripts is that you can't accidentally clobber libraries that the system tools require to work - shell scripts don't really have any notion of installable libraries.
    - owl57 7y ago
      It's not like you can't clobber PATH with ease and in diverse ways… It's just less easy to unclobber: huge hacks like Nix are born in this quest.
      - pfranz 7y ago
        > huge hacks like Nix are born in this quest. Would you mind elaborating on this? Maybe I'm using Linux wrong, but Nix seems like a huge step forward fixing a lot of my frustrations. Admittedly, I haven't used it in production. One huge benefit of language-specific package managers is having multiple versions of packages on the same system and you can choose which you'd like for the project (without changing the OS). I feel like 10 years ago I heard a lot of grumbling about languages like Ruby or Python should just use apt/rpm, but I haven't see any OS package manager put much effort into this use-case (this is ignoring mac/win support). The closest I've seen is something like Red Hat's Software Collections. Personally, I feel strongly that any software that's critical to your company should be decoupled from the OS. This is borne through painful and much delayed OS updates and following it makes things much easier long term. My personal use-case is that different projects (working on multiple in tandem) need different stacks of versions. Also giving the ability to swap versions on the fly. Here's one package manager specifically designed for it https://github.com/nerdvegas/rez https://github.com/nerdvegas/rez Swapping versions in Linux is pretty heavy out of the box (with rpm/apt); download, remove old versions files, write new versions files. Only one installed at a time. a/b comparing libraries is a pain. For the things I need, I build things into folders like libjpeg-turbo/2.0.2 and nasm/2.14.02 and set the ./configure flags to point to these...basically a more ad hoc approach to what Nix does. Where am I going wrong?
- ckuhl 7y ago
  Oh it definitely does. I remember seriously messing up a Linux Mint installation a while back because I upgraded all of the 3rd party dependencies that were preinstalled (because hey, newer is better, right?).
- tannhaeuser 7y ago
  Yes and no. It absolutely makes sense to ensure that admin scripts used by RHEL run in a predictable, tested environment; even more so since Python has dropped backward portability. OTOH not even being able to rely on Python's presence is exactly the kind of thing that makes Python unsuitable as the shell replacement it is being promoted as.
  - Skunkleton 7y ago
    Is python being promoted as a wholesale shell replacement? There certainly are plenty of overlapping usecases, but shell is a better fit for many of these tasks. Until something like ipython can replace the interactive shell, I don't see python replacing shell scripts entirely.
  - CameronNemo 7y ago
    Installing a python interpreter is one package. If you just want to write a quick script using the standard library, it is cheap as all hell.
- SloopJon 7y ago
  Red Hat Developer blog post on the topic: https://developers.redhat.com/blog/2019/05/07/what-no-python-in-red-hat-enterprise-linux-8/ https://developers.redhat.com/blog/2019/05/07/what-no-python... This is an instance of what they're calling application streams, as explained in another post: https://developers.redhat.com/blog/2018/11/15/rhel8-introducing-appstreams/ https://developers.redhat.com/blog/2018/11/15/rhel8-introduc...
avar 7y ago
> Pretty colors when running dmesg! Neat, but a great isolated example of the ancient software people who use RHEL have to deal with. RHEL 7 has dmesg from util-linux 2.23, the "colors by default" feature[1] first came out with 2.24 released on October 21st, 2013, which is around the time[3] the first beta of RHEL 7 came out. 1. https://github.com/karelzak/util-linux/commit/9bc2b51a06dc9cf6244106ac489ab08a91fd4360 https://github.com/karelzak/util-linux/commit/9bc2b51a06dc9c... 2. https://github.com/karelzak/util-linux/releases/tag/v2.24 https://github.com/karelzak/util-linux/releases/tag/v2.24 3. https://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux#RHEL_7 https://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux#RHEL_...
- CoolGuySteve 7y ago
  I've always felt that RHEL really excels at that old school corporate Unix feel of having to deal with stodgy tools that are either really old and/or lack basic ease of use features. Reminds me of the time I wrote a script that called 'hostname -x' on SunOS instead of Solaris and it changed the hostname to '-x' and broke X11. RHEL is the nostalgia Linux. But seriously, has anyone ever empirically verified that the Debian Stable/RHEL model of shipping a bunch of really old packages and then layering years of patches over top actually generates more stable, more secure code? My intuition after a couple decades of software dev is that bugs will fester longer in the old version and the patches themselves will start having bugs as the top of tree diverges more and more from the shipped package over time.
  - geofft 7y ago
    It doesn't generate more secure code—as you say, patches themselves may have bugs, and way fewer people are looking at the patched branches. Active development happens on HEAD, and dodgy code is often rewritten before anyone goes actually looking for bugs (security or otherwise). Many years ago I helped with a paper on how the practice of applying only "important" security bug fixes doesn't work: https://arxiv.org/abs/0904.4058 https://arxiv.org/abs/0904.4058 But the goal of the long-term-stable approach isn't security or stability per se: it's striking a tradeoff between operator work and risks to security and stability. You could, of course, snapshot Fedora (or Debian testing, or Arch, or whatever) from 2013 and keep running it. Nobody is stopping you, and it'll still run on new machines. And then you have to do zero work to keep your system up-to-date, but you'll likely have tons of security and stability bugs. On the other extreme, you could run Fedora rawhide (or Debian unstable, or current Arch, or whatever) and update nightly, which would mean you get security fixes as fast as possible (they're almost always developed on HEAD and backported to release branches), and you get performance and stability fixes that people haven't deemed worth backporting, but you also risk API-incompatible changes that break the actual applications you care about. You'll need to set up really good CI to make sure you have coverage of everything in your application, and it's not just a matter of automation: you'll need a well-staffed team to respond quickly every time that CI goes red, figure out what changed, and update your applications to match. (And, of course, you have the risk of security issues in new code that hasn't been subject to public scrutiny yet—the inverse problem of security issues in old code that's no longer subject to public scrutiny.) The goal of a long-term stable distro is to be in the middle of those two, to give you something that changes rarely (stability in the sense of "no surprises," not "doesn't crash in prod") but often enough that you get major, identified security fixes and particularly safe performance (and stability-as-in-"no longer crashes in prod") fixes. And yes, part of the goal of a long-term stable distro is that it provides you measurable security and stability over unmeasurable but potentially greater security and stability. They don't fix every CVE, but they do fix the flashy ones. You can look at it cynically and say, this is the distro for people who want to tell their boss "Yes, we patched Heartbleed and Shellshock" but don't inherently care about security. But on the other hand, flashy vulnerabilities are more likely to be exploited, so it's not a particularly bad tradeoff.
Tor3 7y ago
> Pretty colors when running dmesg! My most disliked feature. The colors in everything always clashes with both my background color (the best one for my eyes) and my vision in general. The first thing I do on any new system is to figure out how to turn of the colors. Otherwise I can't see any of the output.
- Bjartr 7y ago
  Wouldn't it use the colors your terminal is configured to use?
  - Tor3 7y ago
    My terminal isn't configured to use any colors. It's just xterm. The only colors configured are background and foreground, and those colors various tools insist on as default are always clashing with them (and with my vision too). There are no color environment variables enabled, or anything else indicating that colors should be used, but even so colors are coming out of various command line tools lately.
    - rashkov 7y ago
      I think that if you configure the rest of the colors, then the commands will use those. I’ve set my urxvt term to use the solarized theme and I don’t have any problems with viewing colorized output. I’d have to test it, but I’m reasonably sure of this.
    - Bjartr 7y ago
      If you run the script described in this post[1] you can display the colors that your terminal is configured to use. Just because you've overridden foreground and background doesn't mean you've altered the other colors xterm uses by default. [1] https://bbs.archlinux.org/viewtopic.php?id=51818&p=1 https://bbs.archlinux.org/viewtopic.php?id=51818&p=1
- dharmab 7y ago
  The color choices are client-side. You can use something like base16-shell to customize it.
paulcarroty 7y ago
> No Python (that you should develop against) installed out of the box. Great news, don't like Python by default. All Linux basic services works great without it.
Qerub 7y ago
• No Docker. But we got https://podman.io/ https://podman.io/ instead.
- deleted 7y ago
  [deleted]
- xorcist 7y ago
  Like Docker, but less insanity. Looks promising.
rwmj 7y ago
So I hope I can answer some of these [disclaimer: I work for Red Hat]: Python: This is about the module system. Modules let you install different versions of parts of the stack. For example, different Python, different Apache version, different QEMU. These will move much faster than base RHEL because they're now decoupled. You can install one version of each module from a choice of several versions available at any one time -- it's not parallel install (for that there is still Software Collections). The reason for not having parallel install is basically because people use containers or VMs so they don't really need it, and parallel install brings a lot of complexity. For Python we tried to remove all the Python dependencies from the base image, didn't quite do it because of dnf (although that is in the works with at least the base dnf 3 being rewritten in C++). So we need a reliable System Python which isn't in a module (else dnf would break if you install modular Python 2.7). Basically don't use System Python unless you're writing base system utilities, instead "yum install python3" should pull in the right module. Kernel: As usual the version number isn't that interesting, as a lot of work will be done through backports. ntpd: Can't say I'm very happy about this myself :-( Network scripts: It's NetworkManager all the way. Again, mixed feelings about this, but I can't say I loved network scripts either.
- noinsight 7y ago
  > For Python we tried to remove all the Python dependencies from the base image Do you know why? I think it would be cool to not have any interpreted languages in the base image and FreeBSD manages to do that but I don't consider it that critical. For me it would be more interesting to not have Perl at all than Python... I guess the situation with Python 2.7 on RHEL 7 was/is that painful?
  - rwmj 7y ago
    There's been a huge effort to get the base RHEL image size right down, so obviously getting rid of Python would help there. As for why we need to reduce the size of the base image, the answer is - as always - because containers.
    - Crontab 7y ago
aorth 7y ago
> • No more ntpd, chrony only Not surprising. I've been preferring Chrony to ntpd on systems without systemd-timesyncd (like CentOS 6 and 7) for at least two years since I read this Core Infrastructure article about Chrony: https://www.coreinfrastructure.org/blogs/securing-network-time/ https://www.coreinfrastructure.org/blogs/securing-network-ti...
eikenberry 7y ago
Anyone have any thoughts on why chrony vs openntpd? Back when the ntpd security became a thing I evaluated chrony and openntpd as replacements and went with openntpd. It seemed to be simpler, used fewer system resources and had the openbsd teams reputation behind it.
- jlgaddis 7y ago
  For me, it comes down to the type of hosts I'm dealing with and how accurate I'd prefer their time to be. Years ago, I ran the reference implementation everywhere... but not anymore. OpenNTPD's goals are to be "good enough" and provide "reasonable accuracy". On an OpenBSD laptop and several "play" VMs (running OpenBSD), it was indeed "good enough". For individual desktops or laptops and the random "standalone" machine, OpenNTPD is simpler and "just works" (I like that it can "verify" the time using HTTPS hosts of my choosing). Nowadays, only my stratum 1 NTP servers still run the reference implementation. Everything else -- especially hosts which I may need to correlate events based on timestamps -- runs chrony. A comparison of the three implementations [0] is available on chrony's website. From a quick glance, I don't see anything blatantly incorrect or "biased. The comparison was discussed here on HN ~18 months ago [1]. Basically, if accuracy to the second is good enough, OpenNTPD is fine. If you want more precision than that, go with chrony. It'll be MUCH more accurate and it really isn't any "harder" than OpenNTPD. You'll probably want to stick with ntpd if you're using reference clocks, although chrony supports a subset of them. If you're a nerd that wants the absolutely most accurate time you can get, Google "PTP 1588" as well. [0]: https://chrony.tuxfamily.org/comparison.html https://chrony.tuxfamily.org/comparison.html [1]: https://news.ycombinator.com/item?id=15324386 https://news.ycombinator.com/item?id=15324386
  - eikenberry 7y ago
    Thanks for the detailed response.
- beagle3 7y ago
  YMMV, but in my experience, if for whatever reason your clock is wrong by an hour in one direction (either ahead or after, don't remember), openntpd will take ages to skew it back, whereas chrony (and ntpd) do the right thing.

by chomp 7y ago

sparkling 7y ago

It makes a lot of sense that OS-stuff points to a seperate Python interpreter, don't you think? I like this approach.

lima 7y ago
Exactly, and with App Streams you won't be stuck on an old Python version! This is an awesome feature. You already have that on CentOS/RHEL 7 with Software Collections, and App Streams make it a first-class citizen.
Diederich 7y ago
Aye; this should have been done a long time ago. I wanted to say 'since the beginning' (whenever that was), but maybe there were good reasons 20 years ago that I can't recall. It probably made sense when disk space was a lot more constrained.
- toyg 7y ago
  It just wasn't the practice back in the day. Does redhat ship a "platform-perl"?
  - vetinari 7y ago
    As far as I remember, there is no perl at all in minimal install of v7.
vbezhenar 7y ago
Do you think that there should be separate platform-sh interpreter for system shell scripts, and so on? That kind of strange for me. Probably difference is that shell is "complete" program, while Python is not.
- auscompgeek 7y ago
  The difference with system shell scripts is that you can't accidentally clobber libraries that the system tools require to work - shell scripts don't really have any notion of installable libraries.
  - owl57 7y ago
    It's not like you can't clobber PATH with ease and in diverse ways… It's just less easy to unclobber: huge hacks like Nix are born in this quest.
    - pfranz 7y ago
      > huge hacks like Nix are born in this quest. Would you mind elaborating on this? Maybe I'm using Linux wrong, but Nix seems like a huge step forward fixing a lot of my frustrations. Admittedly, I haven't used it in production. One huge benefit of language-specific package managers is having multiple versions of packages on the same system and you can choose which you'd like for the project (without changing the OS). I feel like 10 years ago I heard a lot of grumbling about languages like Ruby or Python should just use apt/rpm, but I haven't see any OS package manager put much effort into this use-case (this is ignoring mac/win support). The closest I've seen is something like Red Hat's Software Collections. Personally, I feel strongly that any software that's critical to your company should be decoupled from the OS. This is borne through painful and much delayed OS updates and following it makes things much easier long term. My personal use-case is that different projects (working on multiple in tandem) need different stacks of versions. Also giving the ability to swap versions on the fly. Here's one package manager specifically designed for it https://github.com/nerdvegas/rez https://github.com/nerdvegas/rez Swapping versions in Linux is pretty heavy out of the box (with rpm/apt); download, remove old versions files, write new versions files. Only one installed at a time. a/b comparing libraries is a pain. For the things I need, I build things into folders like libjpeg-turbo/2.0.2 and nasm/2.14.02 and set the ./configure flags to point to these...basically a more ad hoc approach to what Nix does. Where am I going wrong?
ckuhl 7y ago
Oh it definitely does. I remember seriously messing up a Linux Mint installation a while back because I upgraded all of the 3rd party dependencies that were preinstalled (because hey, newer is better, right?).
tannhaeuser 7y ago
Yes and no. It absolutely makes sense to ensure that admin scripts used by RHEL run in a predictable, tested environment; even more so since Python has dropped backward portability. OTOH not even being able to rely on Python's presence is exactly the kind of thing that makes Python unsuitable as the shell replacement it is being promoted as.
- Skunkleton 7y ago
  Is python being promoted as a wholesale shell replacement? There certainly are plenty of overlapping usecases, but shell is a better fit for many of these tasks. Until something like ipython can replace the interactive shell, I don't see python replacing shell scripts entirely.
- CameronNemo 7y ago
  Installing a python interpreter is one package. If you just want to write a quick script using the standard library, it is cheap as all hell.
SloopJon 7y ago
Red Hat Developer blog post on the topic: https://developers.redhat.com/blog/2019/05/07/what-no-python-in-red-hat-enterprise-linux-8/ https://developers.redhat.com/blog/2019/05/07/what-no-python... This is an instance of what they're calling application streams, as explained in another post: https://developers.redhat.com/blog/2018/11/15/rhel8-introducing-appstreams/ https://developers.redhat.com/blog/2018/11/15/rhel8-introduc...

avar 7y ago

> Pretty colors when running dmesg! Neat, but a great isolated example of the ancient software people who use RHEL have to deal with. RHEL 7 has dmesg from util-linux 2.23, the "colors by default" feature[1] first came out with 2.24 released on October 21st, 2013, which is around the time[3] the first beta of RHEL 7 came out. 1. https://github.com/karelzak/util-linux/commit/9bc2b51a06dc9cf6244106ac489ab08a91fd4360 https://github.com/karelzak/util-linux/commit/9bc2b51a06dc9c... 2. https://github.com/karelzak/util-linux/releases/tag/v2.24 https://github.com/karelzak/util-linux/releases/tag/v2.24 3. https://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux#RHEL_7 https://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux#RHEL_...

CoolGuySteve 7y ago
I've always felt that RHEL really excels at that old school corporate Unix feel of having to deal with stodgy tools that are either really old and/or lack basic ease of use features. Reminds me of the time I wrote a script that called 'hostname -x' on SunOS instead of Solaris and it changed the hostname to '-x' and broke X11. RHEL is the nostalgia Linux. But seriously, has anyone ever empirically verified that the Debian Stable/RHEL model of shipping a bunch of really old packages and then layering years of patches over top actually generates more stable, more secure code? My intuition after a couple decades of software dev is that bugs will fester longer in the old version and the patches themselves will start having bugs as the top of tree diverges more and more from the shipped package over time.
- geofft 7y ago
  It doesn't generate more secure code—as you say, patches themselves may have bugs, and way fewer people are looking at the patched branches. Active development happens on HEAD, and dodgy code is often rewritten before anyone goes actually looking for bugs (security or otherwise). Many years ago I helped with a paper on how the practice of applying only "important" security bug fixes doesn't work: https://arxiv.org/abs/0904.4058 https://arxiv.org/abs/0904.4058 But the goal of the long-term-stable approach isn't security or stability per se: it's striking a tradeoff between operator work and risks to security and stability. You could, of course, snapshot Fedora (or Debian testing, or Arch, or whatever) from 2013 and keep running it. Nobody is stopping you, and it'll still run on new machines. And then you have to do zero work to keep your system up-to-date, but you'll likely have tons of security and stability bugs. On the other extreme, you could run Fedora rawhide (or Debian unstable, or current Arch, or whatever) and update nightly, which would mean you get security fixes as fast as possible (they're almost always developed on HEAD and backported to release branches), and you get performance and stability fixes that people haven't deemed worth backporting, but you also risk API-incompatible changes that break the actual applications you care about. You'll need to set up really good CI to make sure you have coverage of everything in your application, and it's not just a matter of automation: you'll need a well-staffed team to respond quickly every time that CI goes red, figure out what changed, and update your applications to match. (And, of course, you have the risk of security issues in new code that hasn't been subject to public scrutiny yet—the inverse problem of security issues in old code that's no longer subject to public scrutiny.) The goal of a long-term stable distro is to be in the middle of those two, to give you something that changes rarely (stability in the sense of "no surprises," not "doesn't crash in prod") but often enough that you get major, identified security fixes and particularly safe performance (and stability-as-in-"no longer crashes in prod") fixes. And yes, part of the goal of a long-term stable distro is that it provides you measurable security and stability over unmeasurable but potentially greater security and stability. They don't fix every CVE, but they do fix the flashy ones. You can look at it cynically and say, this is the distro for people who want to tell their boss "Yes, we patched Heartbleed and Shellshock" but don't inherently care about security. But on the other hand, flashy vulnerabilities are more likely to be exploited, so it's not a particularly bad tradeoff.

Tor3 7y ago

> Pretty colors when running dmesg! My most disliked feature. The colors in everything always clashes with both my background color (the best one for my eyes) and my vision in general. The first thing I do on any new system is to figure out how to turn of the colors. Otherwise I can't see any of the output.

Bjartr 7y ago
Wouldn't it use the colors your terminal is configured to use?
- Tor3 7y ago
  My terminal isn't configured to use any colors. It's just xterm. The only colors configured are background and foreground, and those colors various tools insist on as default are always clashing with them (and with my vision too). There are no color environment variables enabled, or anything else indicating that colors should be used, but even so colors are coming out of various command line tools lately.
  - rashkov 7y ago
    I think that if you configure the rest of the colors, then the commands will use those. I’ve set my urxvt term to use the solarized theme and I don’t have any problems with viewing colorized output. I’d have to test it, but I’m reasonably sure of this.
  - Bjartr 7y ago
    If you run the script described in this post[1] you can display the colors that your terminal is configured to use. Just because you've overridden foreground and background doesn't mean you've altered the other colors xterm uses by default. [1] https://bbs.archlinux.org/viewtopic.php?id=51818&p=1 https://bbs.archlinux.org/viewtopic.php?id=51818&p=1
dharmab 7y ago
The color choices are client-side. You can use something like base16-shell to customize it.

paulcarroty 7y ago

> No Python (that you should develop against) installed out of the box. Great news, don't like Python by default. All Linux basic services works great without it.

Qerub 7y ago

• No Docker. But we got https://podman.io/ https://podman.io/ instead.

deleted 7y ago
[deleted]
xorcist 7y ago
Like Docker, but less insanity. Looks promising.

rwmj 7y ago

So I hope I can answer some of these [disclaimer: I work for Red Hat]: Python: This is about the module system. Modules let you install different versions of parts of the stack. For example, different Python, different Apache version, different QEMU. These will move much faster than base RHEL because they're now decoupled. You can install one version of each module from a choice of several versions available at any one time -- it's not parallel install (for that there is still Software Collections). The reason for not having parallel install is basically because people use containers or VMs so they don't really need it, and parallel install brings a lot of complexity. For Python we tried to remove all the Python dependencies from the base image, didn't quite do it because of dnf (although that is in the works with at least the base dnf 3 being rewritten in C++). So we need a reliable System Python which isn't in a module (else dnf would break if you install modular Python 2.7). Basically don't use System Python unless you're writing base system utilities, instead "yum install python3" should pull in the right module. Kernel: As usual the version number isn't that interesting, as a lot of work will be done through backports. ntpd: Can't say I'm very happy about this myself :-( Network scripts: It's NetworkManager all the way. Again, mixed feelings about this, but I can't say I loved network scripts either.

noinsight 7y ago
> For Python we tried to remove all the Python dependencies from the base image Do you know why? I think it would be cool to not have any interpreted languages in the base image and FreeBSD manages to do that but I don't consider it that critical. For me it would be more interesting to not have Perl at all than Python... I guess the situation with Python 2.7 on RHEL 7 was/is that painful?
- rwmj 7y ago
  There's been a huge effort to get the base RHEL image size right down, so obviously getting rid of Python would help there. As for why we need to reduce the size of the base image, the answer is - as always - because containers.
  - Crontab 7y ago

aorth 7y ago

> • No more ntpd, chrony only Not surprising. I've been preferring Chrony to ntpd on systems without systemd-timesyncd (like CentOS 6 and 7) for at least two years since I read this Core Infrastructure article about Chrony: https://www.coreinfrastructure.org/blogs/securing-network-time/ https://www.coreinfrastructure.org/blogs/securing-network-ti...

eikenberry 7y ago

Anyone have any thoughts on why chrony vs openntpd? Back when the ntpd security became a thing I evaluated chrony and openntpd as replacements and went with openntpd. It seemed to be simpler, used fewer system resources and had the openbsd teams reputation behind it.

jlgaddis 7y ago
For me, it comes down to the type of hosts I'm dealing with and how accurate I'd prefer their time to be. Years ago, I ran the reference implementation everywhere... but not anymore. OpenNTPD's goals are to be "good enough" and provide "reasonable accuracy". On an OpenBSD laptop and several "play" VMs (running OpenBSD), it was indeed "good enough". For individual desktops or laptops and the random "standalone" machine, OpenNTPD is simpler and "just works" (I like that it can "verify" the time using HTTPS hosts of my choosing). Nowadays, only my stratum 1 NTP servers still run the reference implementation. Everything else -- especially hosts which I may need to correlate events based on timestamps -- runs chrony. A comparison of the three implementations [0] is available on chrony's website. From a quick glance, I don't see anything blatantly incorrect or "biased. The comparison was discussed here on HN ~18 months ago [1]. Basically, if accuracy to the second is good enough, OpenNTPD is fine. If you want more precision than that, go with chrony. It'll be MUCH more accurate and it really isn't any "harder" than OpenNTPD. You'll probably want to stick with ntpd if you're using reference clocks, although chrony supports a subset of them. If you're a nerd that wants the absolutely most accurate time you can get, Google "PTP 1588" as well. [0]: https://chrony.tuxfamily.org/comparison.html https://chrony.tuxfamily.org/comparison.html [1]: https://news.ycombinator.com/item?id=15324386 https://news.ycombinator.com/item?id=15324386
- eikenberry 7y ago
  Thanks for the detailed response.
beagle3 7y ago
YMMV, but in my experience, if for whatever reason your clock is wrong by an hour in one direction (either ahead or after, don't remember), openntpd will take ages to skew it back, whereas chrony (and ntpd) do the right thing.