Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?
On Tue, Dec 29, 2020 at 01:24:33PM +0100, Michał Górny wrote: > As noted in another fork of this thread, libtls is now provided > by dev-libs/libretls which works against OpenSSL. The latest version of libressl also supports linking libtls statically against libssl and libcrypto, allowing it to be used alongside openssl while still using libressl guts. Of course, then you'd end up with basically two ssl implementations loaded, so dunno it's very efficient, but just to point it out :).
[gentoo-dev] libressl / libtls
Current versions of libressl link libcrypto and libssl into libtls statically, allowing libtls to be installed concurrently with openssl without any ABI breakage. Would it be possible to have a use flag such as 'libtlsonly' or whatever for the ebuild which only installs libtls, allowing it to exist on a system primarily using openssl for applications that depend upon it such as openntpd? Or have a separate ebuild just for libtls (which couldn't be installed with the full libressl ebuild or vice versa) to meet that requirement? Thanks…
Re: [gentoo-dev] uid/gid request for net-misc/openntpd
On Wed, Sep 11, 2019 at 09:53:49PM -0400, Mike Gilbert wrote: > Added. Much appreciated, thanks.
Re: [gentoo-dev] uid/gid request for net-misc/openntpd
It was suggested to use uid/gid 321 for this purpose? Any objections to this selection? If not, how do I get https://api.gentoo.org/uid-gid.txt updated to mark it as requested or reserved? Thanks... On Mon, Sep 02, 2019 at 01:09:40PM -0700, Paul B. Henson wrote: > Per https://bugs.gentoo.org/show_bug.cgi?id=693050 openntpd is going to > switch to a dedicated openntpd user/group rather than sharing the ntp > user/group with net-misc/ntp. > > Could I please get a static uid/gid assigned for this? For now, I'm just > going to hardcode them in the ebuild, and transition it to the new > acct-user/acct-group mechanism at a later point.
[gentoo-dev] uid/gid request for net-misc/openntpd
Per https://bugs.gentoo.org/show_bug.cgi?id=693050 openntpd is going to switch to a dedicated openntpd user/group rather than sharing the ntp user/group with net-misc/ntp. Could I please get a static uid/gid assigned for this? For now, I'm just going to hardcode them in the ebuild, and transition it to the new acct-user/acct-group mechanism at a later point. Thanks...
Re: [gentoo-dev] Amazon Corretto openjdk builds?
On Wed, Jun 26, 2019 at 12:50:11PM -0700, Georgy Yakovlev wrote: > As a maintainer of most jdks in gentoo I'm not looking at adding even > more JDK versions this time as there is little to no reason of doing > that. Cool, thanks for the perspective. > if there is significant performance or technical difference I could > take a look at it, so let me know if I'm wrong in my assessment. The main difference from just an initial look is that the Amazon release is officially "Java SE compatible" as it passes the TCK certification. AdoptOpenJDK evidentally has some issue with oracle (a problem with oracle 8-/? Imagine that) such that they aren't able to use the TCK for testing. Then from an applications view, one of our most important java apps is the shibboleth idp, which officially supports amazon's release but not the adoptopenjdk one. They do support Redhat's OpenJDK build for RHEL and CentOS, I assume the adoptopenjdk built will work too but just adds an additional fuzzy if opening a support ticket. Thanks again...
[gentoo-dev] Amazon Corretto openjdk builds?
Is anybody looking at Amazon's new openjdk distribution? https://aws.amazon.com/corretto/ Advertised as production ready with long term support, no-cost. I'm not sure how it compares to the current AdoptJDK builds, but seems like it might be another good option.
Re: [gentoo-dev] Last rites: dev-java/oracle-{jre,jdk}-bin
On Wed, Apr 17, 2019 at 07:44:53PM -0700, Georgy Yakovlev wrote: > I've modified the mask for now, but I still believe we should drop it. > I do not maintain it at all, I only work on openjdk and a bit of icedtea. Speaking of openjdk, all versions are masked and the ebuilds contain: if use gentoo-vm ; then ewarn "WARNING! You have enabled the gentoo-vm USE flag, making this JDK" ewarn "recognised by the system. This will almost certainly break things." else When will openjdk be a viable vm? As you say, the Oracle license is screwy now, and icedtea isn't really current. Thanks...
Re: [gentoo-dev] Upcoming posting restrictions on the gentoo-dev mailing list
On Thu, Jan 11, 2018 at 05:07:22PM +, Peter Stuge wrote: > Maybe this is a discussion for -project, then? > > Andreas K. Huettel wrote: > > * and keep commenting opinionated on technical things they plainly have no > > clue about (while whining when are told they sprout bulls##t). > > You Sir are IMHO neither fit for the office of council nor of comrel, > solely based on your communication style in that one mail. It's not libel if it's true ;) (at least in the USA; your free speech may vary). I'm not necessarily in favor of censoring the list, but I've got nothing agaist calling out clueless entitlement when you come across it.
Re: [gentoo-dev] Upcoming posting restrictions on the gentoo-dev mailing list
On Tue, Jan 09, 2018 at 10:20:56PM +0100, Andreas K. Huettel wrote: > * Subscribing to the list and receiving list mail remains as it is now. > * Posting to the list will only be possible to Gentoo developers and > whitelisted additional participants. Any chance you'd consider automatically white-listing all current proxy maintainers :)? > * Whitelisting requires that one developer vouches for you. We intend this > to be as unbureaucratic as possible. Or should I go harass the dev that usually commits my changes? Arguably, being a proxy maintainer already implies at least one dev thinks you're not a total idiot, as random users can't add themselves to the package metadata on their own. Thanks...
Re: [gentoo-dev] openntpd-5.9_p1 with USE=libressl
On Sun, May 22, 2016 at 01:07:01PM +, Nils Gillmann wrote: > I am not one of the devs, but I run a system with libressl and openntpd. > It does build, but it is affected by this bug I reported: > https://bugs.gentoo.org/show_bug.cgi?id=583652 Ah, that bug had not yet been wrangled, so I hadn't seen it. I missed the version dependency; I uploaded a fixed ebuild to the bug, and it looks like my proxy dev has already committed it. It should pull in a new enough version automatically now, thanks for the report.
[gentoo-dev] openntpd-5.9_p1 with USE=libressl
I recently added subject ebuild with a new libressl use flag. Unfortunately I don't have a libressl system to test with and don't really have the time right now to spin one up just for this :(. I was wondering if one of the devs working with libressl would be kind enough to make sure this at least compiles cleanly with libressl enabled before I try to get it stabilized? Thanks much...
Re: [gentoo-dev] libressl status]
On Fri, Apr 03, 2015 at 01:59:25AM +0200, Hanno Böck wrote: Is there a way to split libtls off libressl? To revive this rather old thread, I just wanted to provide an update. After some discussion with upstream portable openntpd, the libressl team decided to go ahead and create a standalone libtls package that will eventually work with openssl: https://github.com/libressl-portable/portable/pull/83 This work has already been pulled into libressl head, and there has also been some work on adding the missing libressl APIs to openssl: https://github.com/busterb/openssl/commits/libressl-apis I believe these are going to get submitted to openssl for review soon. Unfortunately, there are still some security features missing in openssl that haven't been worked on (for openntpd purposes, specifically the ability for the openssl RNG to function in an empty chroot; if I understand correctly it needs access to /dev/(u)random while running). So it's not quite there yet, but it is being worked on, so I'm hopeful at some point in the not too distant future we can have openntpd with tls constraint support without having to deal with openssl vs libressl headaches :).
Re: [gentoo-dev] libressl status
[Sorry if this is a dupe, my first send didn't seem to go through] On Fri, Apr 03, 2015 at 01:59:25AM +0200, Hanno Böck wrote: Is there a way to split libtls off libressl? To revive this rather old thread, I just wanted to provide an update. After some discussion with upstream portable openntpd, the libressl team decided to go ahead and create a standalone libtls package that will eventually work with openssl: https://github.com/libressl-portable/portable/pull/83 This work has already been pulled into libressl head, and there has also been some work on adding the missing libressl APIs to openssl: https://github.com/busterb/openssl/commits/libressl-apis I believe these are going to get submitted to openssl for review soon. Unfortunately, there are still some security features missing in openssl that haven't been worked on (for openntpd purposes, specifically the ability for the openssl RNG to function in an empty chroot; if I understand correctly it needs access to /dev/(u)random while running). So it's not quite there yet, but it is being worked on, so I'm hopeful at some point in the not too distant future we can have openntpd with tls constraint support without having to deal with openssl vs libressl headaches :).
Re: [gentoo-dev] libressl status
On Fri, Apr 03, 2015 at 01:59:25AM +0200, Hanno Böck wrote: Is there a way to split libtls off libressl? To revive this rather old thread, I just wanted to provide an update. After some discussion with upstream portable openntpd, the libressl team decided to go ahead and create a standalone libtls package that will eventually work with openssl: https://github.com/libressl-portable/portable/pull/83 This work has already been pulled into libressl head, and there has also been some work on adding the missing libressl APIs to openssl: https://github.com/busterb/openssl/commits/libressl-apis I believe these are going to get submitted to openssl for review soon. Unfortunately, there are still some security features missing in openssl that haven't been worked on (for openntpd purposes, specifically the ability for the openssl RNG to function in an empty chroot; if I understand correctly it needs access to /dev/(u)random while running). So it's not quite there yet, but it is being worked on, so I'm hopeful at some point in the not too distant future we can have openntpd with tls constraint support without having to deal with openssl vs libressl headaches :).
RE: [gentoo-dev] libressl status
From: hasufell Sent: Sunday, April 05, 2015 4:34 AM However, openntpd still compiles with openssl. Well, the current stable openntpd in portage compiles with openssl but that's not surprising as it is ancient and predates libressl :). The current unstable openntpd actually has no ssl dependencies and needs neither openssl nor libressl to compile and function. It is the most recent upstream portable release that added an optional dependency on libressl for tls constraint functionality, that version is not yet in portage. It will work without libressl just as well as the current unstable openntpd does, you just won't have access to the new feature. So it's not really critical, but at some point it would be nice to get it working one way or the other. By that you are effectively forking libressl and causing a huge mess downstream for both developers and users. What are the downsides of the approach pkgsrc is tentatively taking, where there are no modifications to libressl but the libraries are installed in an alternative location? Packages that require libressl can just use the appropriate linker options to find those libraries rather than the openssl ones? worse. This is something that has to be resolved upstream. If they don't cooperate long-term, then their fork will just die out for sure (and for good). However, I currently don't see strong signs for that. I don't think their fork will ever die; even if no one outside of openbsd uses the portable version, it is now the official ssl provider for openbsd and I am sure will continue to be used by them as well as the portable versions of any of their other applications such as openntpd...
Re: [gentoo-dev] libressl status
On Fri, Apr 03, 2015 at 01:59:25AM +0200, Hanno Böck wrote: Tricky thing here, because then you'd need to rename the libs. E.g. libssl to liblibressl or something. But then every program with a build environment to link to libssl would first have to be patched to link to our specialized libressl variant. Yah, I dunno. But I don't have a warm fuzzy about them being interchangable any time soon or even longterm. It's not a goal AFAIK. Is there a way to split libtls off libressl? Because that might be at least for this case an option: Continue to use openssl, but have libtls laying around. Not sure if it is possible to have libtls using libcrypt/libssl functions from openssl. I'm pretty sure libtls won't currently compile against openssl, although I haven't taken a detailed look as to why. It is true that openntpd has no direct dependency on libressl, only the libtls API, so theoretically if libressl's libtls could be patched to work with openssl or if openssl released their own API compatible libtls it would be happy. I asked a similar question on the pkgsrc mailing list: http://mail-index.netbsd.org/tech-pkg/2015/03/30/msg014532.html They're pretty much decided on allowing both openssl and libressl to be installed concurrently and for a given application to use one or the other. The specific method for that packaging system is what they call a prefix; basically instead of /usr/pkg/lib/libssl it would be /usr/pkg/libressl/lib/libssl, and packages that needed it would get the right magic flags for the headers and libraries to be found. All openntpd does is use libtls to make an HTTPS HEAD request. It might be simpler to just have it use libcurl or some other existing https library instead of trying to get libressl/libtls working, although that would decrease the security aspect of it only using openbsd audited code.
Re: [gentoo-dev] libressl status
On Fri, Apr 03, 2015 at 01:31:53PM +0200, hasufell wrote: Not anymore. We will go for libressl USE flag for the same reason there is a libav USE flag now (working subslots etc). Um, ok. That still only allows one or the other to be installed though, right? So if you want a package that only works with openssl and one that only works with libressl, you are left wanting :)? decision... I guess you could still try to provide a compatibility patch for openssl. I mentioned that to Brent Cook, who is currently maintaining the portable version, and I don't think that's something he'd pull in upstream. I suppose we could have a local gentoo patch. I guess I'll just let this simmer for now and see how things develop. My preference (I think, at least at the moment) would be for both implementations to be able to coexist, like openssl and gnutls. It looks like that's the way it's heading in pkgsrc (the other place I'm maintaining openntpd), which should make things relatively simple there. If that's not going to be an option with Gentoo hopefully the best alternative will become clearer at some point ;). Thanks...
[gentoo-dev] libressl status
What is the current status/thoughts regarding libressl? Reviewing the bug and some past threads, it sounds like the initial plan was to make openssl a virtual and let either classic openssl or libressl fulfull it? I'm not sure if things have changed from that viewpoint, but it really doesn't seem they're going to be plug and play compatible 8-/. libressl offers functionality openssl doesn't and vice versa, and playing nicely with each other doesn't seem to be on the agenda of either. It seems it might make more sense to treat them more like openssl and gnutls, where they both provide similar ssl functionality but a given package might use one, the other, or either? The specific reason for my current inquiry is that the latest openntpd release includes the new support from openbsd for constraints, where basically you can verify ntp time sources by checking their time relative to a trusted TLS server (which provides the time in HTTP headers). This functionality requires libtls, part of libressl. openssl provides no compatible functionality, so this is a case where they're not plug-and-play, openntpd requires libressl specifically. Thanks...
RE: [gentoo-dev] Recommend cronie instead of vixie-cron in handbook?
From: Pacho Ramos [mailto:pa...@gentoo.org] Sent: Tuesday, December 10, 2013 12:55 PM This has reminded me that maybe we should switch to cronie from vixie-cron as default and recommended cron provider in Handbook. Last time I checked, vixie-cron upstream was died while cronie forked it fixing some bugs :/ What do you think? I'd say go one step further and get rid of vixie-cron completely, is there anything it does that cronie can't do as well or better? It's getting pretty crusty, with a lot of open bugs that haven't been resolved. While updating the handbook might get new users to use a better cron, masking vixie-cron (and perhaps a news item?) could get existing users to migrate to a supported and maintained cron as well…
Re: [gentoo-dev] logging in openntpd 20080406-r3+
On Fri, Nov 22, 2013 at 03:44:42PM -0800, Paul B. Henson wrote: I've tested a variety of scenarios, from the network interface being down/unplugged, providing invalid NTP servers, etc., and I haven't seen a delay longer than 15 seconds. I tracked down the failure mode where openntpd will take forever to start. If you use host names in your config rather than IP addresses, and dns lookups fail, there's a scenario where it will just sit there repeatedly making dns lookups until the end of time 8-/. Basically, the 15 second timeout in the current version only checks for the timeout to lapse while waiting for a response from the unpriv'd child process. If the child process has an ntp server to ask for the time, and it takes more than 15 seconds to get a response, the parent gives up on the initial time setting and backgrounds. However, in this failure scenario, the child asks for a dns lookup, the parent times out trying and tells the child sorry no go, and then the child asks again. And again. There is never a 15 second period where the child is unresponsive, the delay is always in the parent waiting for the dns lookup. Bug 493358 has a patch to fix this. With the patch, openntpd will background within approximately 15 seconds plus however long your resolver is configured to take to timeout a dns query. Perhaps now we can just ditch the syslog use flag and remove the option to run in debugging mode with stderr redirected? I don't think there was any need for it other than to resolve the delayed startup bug, which I'm reasonably confident this does...
Re: [gentoo-dev] logging in openntpd 20080406-r3+
On Sun, Dec 01, 2013 at 09:59:37AM -0700, Christoph Junghans wrote: back to the original mechanism where openntpd runs normally as a daemon and logs to syslog This is exactly what the syslog use flag in openntpd-20080406-r5 does. (And syslog is enabled by default in most profiles.) The syslog use flag is a bit of a kludge, it makes the ebuild delete a hardcoded chunk of the init script when it installs it, plus the logrotate file is still installed unconditionally and could conflict with syslog logging, so I don't really think that's a good solution. And syslog isn't enabled in the default profile: virtz # eselect profile list Available profile symlink targets: [1] default/linux/amd64/13.0 * virtz # ACCEPT_KEYWORDS=~amd64 emerge -pv =net-misc/openntpd-20080406-r5 Calculating dependencies... done! [ebuild U ] net-misc/openntpd-20080406-r5 [20080406] USE=ssl (-selinux) -syslog% 12 kB I've seen two reasons for the current kludgy init script: * boot delays * openrc likes pid files Boot delays are avoided by not passing the -s option; and if the -s option causes a delay longer than 15 seconds that's a bug that should be fixed, not kludged around. It's far cleaner to just add pid file support directly to the daemon rather than try to kludge around it in an init script. There's really no valid reason not to just put the ebuild back to its original state, there's no need for a syslog use flag, and running in debug mode with hardcoded stderr logging isn't exactly a reasonably alternate logging mode. My offer to debug boot delays in excess of 15 seconds upon supply of a reproducible configuration that causes them still stands too... I hope djc, as the original person concerned, can comment on that. I saw a message from him early in the thread, but haven't seen any reproducible configuration resulting in an extended delay.
Re: [gentoo-dev] logging in openntpd 20080406-r3+
On Sat, Nov 30, 2013 at 09:21:32PM -0800, Paul B. Henson wrote: and logs to syslog, I'll put together a patch that adds a -p argument to optionally create a pid file after daemonizing... Bug 493082 contains a patch to openntpd adding a pid file option, along with an updated ebuild that uses it...
Re: [gentoo-dev] logging in openntpd 20080406-r3+
On Sun, Dec 01, 2013 at 02:17:18PM -0800, Paul B. Henson wrote: Bug 493082 contains a patch to openntpd adding a pid file option, along with an updated ebuild that uses it... Someone had asked me offlist about using SIGUSR1 instead of SIGINFO for dumping peer status, and as long as I had my fingers in the code I made a patch for that too, bug 493084.
Re: [gentoo-dev] logging in openntpd 20080406-r3+
On Sun, Dec 01, 2013 at 11:28:25PM +0100, Michał Górny wrote: For current OpenRC -- maybe. For systemd and hopefully future OpenRC capable of service supervision, PID file is just useless cruft and foreground option is much more fun. Dunno about the future of openrc, but as far as systemd I'm currently in the meh camp ;), so somebody else can worry about a foreground option :). Although it would be pretty trivial to implement.
Re: [gentoo-dev] logging in openntpd 20080406-r3+
On Sat, Nov 30, 2013 at 09:14:30AM +0100, Michał Górny wrote: You know, usually it's enough to ping upstream. AFAIR there was a similar problem in irqbalance, and they have added plain '--foreground' for us. I don't know there really is an upstream for portable openntpd right now, there's been forward development in the openbsd tree, but the last official release of the portable version was in 2006 8-/. Unless you consider debian upstream as far as their patches on top of vanilla portable. I'm not sure what all's changed in the openbsd version, but I guess no one's really cared enough to work on making it portable. The last status I see is from 2008: http://marc.info/?l=openbsd-miscm=122731899504602 where someone said it would be nontrivial. I think adding a pid option would be better than adding a foreground option, at least for openrc purposes; although a foreground option that wasn't debugging mode and still logged to syslog would be better than the current gentoo state.
Re: [gentoo-dev] logging in openntpd 20080406-r3+
On Sat, Nov 30, 2013 at 04:20:09PM +, Diego Elio Pettenò wrote: If you really don't want PID files (and it probably means you have never had to deal with medium-scale deployments, but never mind), you can make it so that `-p` is an optional parameter, and if not passed no pidfile is created. And voilà, you can make an unconditional patch If Christoph says he'd be willing to stop running in debug mode and go back to the original mechanism where openntpd runs normally as a daemon and logs to syslog, I'll put together a patch that adds a -p argument to optionally create a pid file after daemonizing... But I don't really want to spend the time though if there's not a reasonably firm agreement on it. My offer to debug boot delays in excess of 15 seconds upon supply of a reproducible configuration that causes them still stands too...
Re: [gentoo-dev] logging in openntpd 20080406-r3+
On Fri, Nov 29, 2013 at 09:49:03AM +0100, Lars Wendler wrote:
I think there's some confusion on what the -d option actually does, so
let me cite the relevant parts from man 8 ntpd:
[...]
Now let's discuss if this can be considered as debug mode or not.
Let me cite the relevant code ;) :
ntpd.c:
while ((ch = getopt(argc, argv, df:nsSv)) != -1) {
switch (ch) {
case 'd':
lconf.debug = 1;
The person that wrote the code clearly intended -d to enable debugging. We
can discuss exactly what enabling debugging does, but I really don't think
there's any question as to whether or not -d should be considered debug
mode...
If logging once was done via syslog this should not be changed.
So rather than making this available via USE flag being disabled
by default I'd rather prefer to have the USE flag being enabled by
default.
Also, running in debug mode precludes logging to syslog, as in debug mode
it just spews to stderr. Cause, well, it's for debugging, not routine
operation.
If openrc has issues managing services that don't drop pid files, maybe
that should be looked into, or maybe openntpd could be patched to drop
a pid file. But running in debug mode to prevent daemonizing, and then
manually backgrounding it, is simply kludgy and distasteful :(...
Re: [gentoo-dev] logging in openntpd 20080406-r3+
On Thu, Nov 28, 2013 at 08:55:56AM -0700, Christoph Junghans wrote: run openntpd with two different ways of logging, via syslog (like Paul wants) and with a separate log file to avoid boot delays (like djc wants). We could easily make syslog logging the default, like My point is that running in debug mode to avoid boot delays is broken. As I've explained, the delays come about because the user explicitly requested that openntpd set the time at start up. Don't use the -s option, no boot delay. The option to run in debug mode with a hardcoded log file just shouldn't exist at all. It actually breaks the -s option, as openntpd is backgrounded before it can set the time, and other processes potentially start without a valid time. From my testing, the boot delay is capped at 15 seconds anyway. If people are experiencing longer delays, the solution is to track down the bug that's causing the delay to exceed the 15 second timeout, not to kludge around it. If someone can provide a configuration that reliably reproduces a delay longer than 15 seconds, I've offered to look into it.
Re: [gentoo-dev] logging in openntpd 20080406-r3+
On Thu, Nov 28, 2013 at 06:48:30AM -0500, Rich Freeman wrote: Having 47 devs agree with you doesn't really accomplish much if none of them care to maintain the package in question. Well, I would kinda hope that if 47 devs told 1 dev they were making a poor design decision, that 1 dev would reconsider their position... So, do you have any opinion on running a daemon in the foreground in debug mode with stderr hardcoded to a specific file then backgrounding it at the service start level to work around a delay issue caused by the user explicitly requesting that the daemon perform an operation prior to backgrounding itself?
Re: [gentoo-dev] logging in openntpd 20080406-r3+
On Fri, Nov 22, 2013 at 09:36:38PM +0100, Peter Stuge wrote: Paul B. Henson wrote: In openntpd ebuilds starting with version 20080406-r3, logging was changed from using the default standard syslog to running the daemon in debug mode, logging to stderr, and having start_stop_daemon background the process itself and redirect the output to a log file. I think this is broken. Yes, I think it is really f-ing broken too. Well, looks like it's just you and me in that camp :(, quite disappointing no other devs stepped up with an opinion on this. Guess I'll just fix this in my local overlay and the rest of the users can fend for themselves.
[gentoo-dev] logging in openntpd 20080406-r3+
In openntpd ebuilds starting with version 20080406-r3, logging was changed from using the default standard syslog to running the daemon in debug mode, logging to stderr, and having start_stop_daemon background the process itself and redirect the output to a log file. I think this is broken. First of all, this change was made due to complaints about boot delays. A delay at boot *only* occurs if you have added the -s option to set the time immediately at start up. If and only if the -s option is used, openntpd will delay up to 15 seconds trying to reach a time server in order to initially set the time before daemonizing into the background. If the -s option is not used, openntpd will immediately daemonize with no delay. Note that the -s option is *not* the default when the ebuild is installed. If you explicitly add the -s option, you are requesting that the time be set at start up before any other processes are started. It's kind of stupid for somebody to request that ntpd set the time and then complain that there is a delay while it's trying to do so. If somebody does not want a boot delay, the answer is to tell them to remove the -s option, not to Rube Goldberg the startup script and logging. Second, this change actually *breaks* functionality for people who *do* want the time set at start up before other processes are run. With the original behavior, ntpd would set the time before the startup script would return, and any process starting afterwards would be assured of the correct time (unless there was a network failure or ntp outage). With this implementation, ntpd is forked off into the background and the next startup script immediately run, potentially before ntpd has had a chance to actually set the time. Third, -d is debugging mode, not let's just not background and log to stderr mode. At the very least, -d results in a ton of additional log output that would not normally be generated. Without auditing the code, I don't know what other changes to the normal behavior it might result in, but in general, running a production service in debug mode is not typically a good idea. I opened a bug about these issues (491134), and the latest version does add a new syslog use flag allowing you to use the standard logging rather than running in debug mode (although the implementation is a bit fragile, a hardcoded sed in the ebuild that deletes specific lines from the init script after it is copied in). This version does still unconditionally copy in a logrotate config file that could potentially conflict with somebody's existing configuration. I was unable to come to an agreement with the current maintainer of the ebuild on this design, and would like some general feedback from the larger community of developers on this topic. Thanks much.
RE: [gentoo-dev] logging in openntpd 20080406-r3+
From: Dirkjan Ochtman [mailto:d...@gentoo.org]
Sent: Friday, November 22, 2013 12:30 PM
- Without -s, it can take a *very* long time to get close to an
acceptable time error, whereas my initial expectation was that
starting my ntpd should fix the time error fairly quickly. But for
me this, this is partly about starting ntpd while the machine is
online, not just at boot.
In general, ntpd tries not to violate the presumption that time is
monotonically increasing. Rather, it adjusts the clock rate such that your
system time approaches real time; if your current time is too far behind, the
clock runs faster, and each second takes less than a second, if your time is
too far ahead, each second takes more than a second. However, if your time is
very far off, that will take a considerable amount of time (heh heh) to
synchronize. The -s option makes makes ntpd simply set the time to exactly
whatever the current time is, regardless of what the system clock happens to
say. This could be a huge jump, possibly into the past from the perspective
of the system. Generally, this is only done at boot, typically before other
processes are started that might need the correct time. Depending on what
services your system is running, something might be quite unhappy if suddenly
it is eight minutes earlier than it appeared to be when the process started.
- Second, with -s, the boot delays can be quite long. I'm pretty sure
I've seen delays that are quite a bit longer than 15s, probably in the
case where there's no network or maybe where DNS doesn't resolve well;
I've tested a variety of scenarios, from the network interface being
down/unplugged, providing invalid NTP servers, etc., and I haven't seen a delay
longer than 15 seconds. If you look at the source code in ntpd.c:
while ((ch = getopt(argc, argv, df:nsSv)) != -1) {
[...]
case 's':
lconf.settime = 1;
If you supply the -s option lconf.settime is set, and:
if (!lconf.settime) {
log_init(lconf.debug);
if (!lconf.debug)
if (daemon(1, 0))
fatal(daemon);
} else
timeout = SETTIME_TIMEOUT * 1000;
rather than immediately daemonizing, it sets a 15 second timeout
(SETTIME_TIMEOUT is defined to 15 in ntpd.h).
It then enters the main loop, where if a response is not received within 15
seconds:
if ((nfds = poll(pfd, 1, timeout)) == -1)
if (nfds == 0 lconf.settime) {
lconf.settime = 0;
timeout = INFTIM;
log_init(lconf.debug);
log_debug(no reply received in time, skipping initial
time setting);
if (!lconf.debug)
if (daemon(1, 0))
fatal(daemon);
}
It backgrounds anyway and aborts the initial time set. I'm not saying there
isn't some bug or scenario which would result in a longer delay, but if so,
that is a bug in ntpd, not an issue to be worked around in the startup script.
in any case, when you're trying to debug issues in a data center
environment, waiting for a bunch of machines to come up is not much
fun. (Or when you've had a machine go down and you're waiting to see
if it comes up again.)
In my data center, NTP is considered a critical service and provisioned with
fault tolerance. If a box trying to boot cannot reach an NTP server, that is as
much of a problem as whatever is wrong with the box booting. I don't believe
I've ever seen a boot delay caused by NTP on any of our production systems
ever. If you can provide a reproducible failure mode where ntpd takes longer
than 15 seconds to start I'd be willing to take a look and see what's going on.
Ideally though, this should be reproducible on a system already running, not
something only happening during boot, as it would be more difficult to debug
the process at that state.
Now, for my use case, it is not all that important that the time error
is minimized before resuming the boot process, but I really wanted to
minimize boot delays.
Then I advise you not to use the -s option, in which case there will never be a
delay, no matter what.
Also, I'm really not sure how the change to logging to stderr/file and
running in debug mode helps with the boot delays.
Basically, the new startup script does something like:
/usr/sbin/ntpd -d [-s] 2/var/log/ntpd.log
The process is immediately put into the background and the startup sequence
continues. This eliminates the boot delay, but at the cost of not actually
setting the time before other processes are started (if the -s option is
provided), using really kludgy logging, and always running the process in debug
mode.
Personally, I think it should all be put back to the way it was to begin with,
Re: [gentoo-dev] Kerberos Maintainence
On Tue, 12 Feb 2008, Sune Kloppenborg Jeppesen wrote: On Monday 10 December 2007 15:41:47 Doug Klima wrote: [snip] Short version, we need a Heimdal and MIT-KRB5 maintainer. Preferably 2 since Heimdal and MIT are different. Did we get any maintainers for these packages? metadata/herds is still empty. If we don't get any maintainers I think we should consider Gentoo Kerberos for the future. One of my staff members is currently being mentored to become a developer, he is going to offer to maintain MIT Kerberos once he's done. We're running Kerberos on Gentoo here and it's rather important to us. I'm not sure of the current state of his mentorship, but he did just have his first baby Monday so it's probably not the top thing on his mind :)... -- Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/ Operating Systems and Network Analyst | [EMAIL PROTECTED] California State Polytechnic University | Pomona CA 91768 -- gentoo-dev@lists.gentoo.org mailing list
