On Thu, Feb 26, 2015 at 2:52 AM, Garrett Cooper <yaneurabeya_at_gmail.com> wrote: > > On Feb 25, 2015, at 18:08, Kevin Oberman <rkoberman_at_gmail.com> wrote: > > On Wed, Feb 25, 2015 at 2:30 PM, Garrett Cooper <yaneurabeya_at_gmail.com> > wrote: > >> On Feb 25, 2015, at 14:19, Miguel Clara <miguelmclara_at_gmail.com> wrote: >> >> ... >> >> > I noticed this too, but in that case why doesn't it affect all users? >> (or all the ones using dnscrypt+local_unbound) maybe something changed in >> "NETWORKING" recently? >> > >> > Hum: >> > >> https://svnweb.freebsd.org/base/head/etc/rc.d/NETWORKING?r1=275299&r2=278704 >> > >> > Interesting, as I am using the most recent version which does not >> REQUIRE local_unbound >> > >> > I'm even more confused now :| >> > >> > >> > So it has to come after SERVERS but before local_unbound. But >> NETWORKING depends on local_unbound they are both dependent on NEWORKING >> which has to be after SERVERS. Can you say fubar! Clearly broken. And this >> means that removing SERVERS will re-shuffle the order more appropriately. >> > >> > It seems that the behavior of rcorder is not as documented as well as >> being undefined when circular dependencies occur. The man page says that >> rcorder aborts when it encounters a circular dependency, but that is not >> the case. It probably is best that it not die, but that leaves things in an >> unknown and inconsistant state, which is also a very bad idea. I guess when >> a circular dependency is encountered, a dichotomy occurs. >> >> Now you know why I’m so curious about all of this stuff. >> >> When I was working on ^/projects/building-blocks, I was able to move most >> of these pieces around by changing REQUIRE: to BEFORE:, but I noticed that >> it changes the rcorder a bit, so I haven’t been super gung ho in >> implementing my change. >> >> I think there are a couple bugs present on 9-STABLE/10-STABLE/11-CURRENT: >> >> - Things go awry if named is removed/not installed. >> - Things go awry if local_unbound is removed (which would have been the >> case if the rc.d script was removed from your system, which existed before >> my changes). >> - Other rc.d scripts not being present might break assumptions. >> >> I need to create dummy providers for certain logical stages (DNS is one >> of them) to solve part of this problem and provide third parties with a >> mechanism that can be depended on (I wish applications were written in a >> more robust manner to fail gracefully and retry instead of failing flat on >> their face, but as I’ve seen at several jobs, getting developers to fail, >> then retry is hard :(…). >> >> Another short-term hack: >> >> Install dummy/no-op providers so the ordering is preserved, then remove >> the hacks after all of the bugs have been shaken out. >> >> Thanks! >> > > Garret, > > Also undocumented (except in rcorder.c) is that the lack of a provider is > not an error. This effectively makes a list of providers into an OR. So, > for name service the normal list is "named local_unbound unbound" and any > will work for ordering and having none is a no-op, so if you don't run any > nameserver (or kerberos or whatever provider), it is not an issue. As long > as rcorder finds a provider, it will be used to set the order, but the lack > of any or all providers just means that the specified provider is ignored > and if a REQUIRES or BEFORE lists no existing providers, the statement is > simply ignored. > > The real problem is that there is no defined rule for behavior in the > event of a circular dependency and any change to any decision point in the > ordering process may change the way the ordering flips. That is why these > things are such a royal pain to debug. A change in any rc.d script may > cause the ordering of seemingly unrelated scripts to change, perhaps > drastically, and the error messages, while not misleading, is only a > starting point in tracking this down. This means there may be time bombs > that break working ports without their being touched or even re-installed. > And the triggering change my, itself be correct. > > > Or etc/rc.d/named... > > PROVIDES: DNS > > I'm going to post a fix up for this on arch_at_/rc_at_ because it needs to be > solved in a saner way -- especially for systems that are pedantic about > rcorder, like our version at $work. > > I re-sync my source and noticed the change while doing the mergemaster part... with this I can now change dnscrypt to: _at__at_ -4,7 +4,7 _at__at_ # # PROVIDE: dnscrypt_proxy # REQUIRE: SERVERS cleanvar -# BEFORE: named local_unbound unbound +# BEFORE: DNS And this makes the rcorder ok for dnscrypt-proxyReceived on Fri Mar 20 2015 - 13:48:18 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:56 UTC