On Fri, Mar 20, 2015 at 7:47 AM, Miguel Clara <miguelmclara_at_gmail.com> wrote: > > 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-proxy > This is still broken and only works by random luck. At this time there appears to be nothing providing DNS. At least the default /etc/rc.d/local_unbound does not.nor does anything else in /etc/rc.d. It looks like this change effectively removes all BEFORE constraints, so it may start any time after SERVERS and cleanvar. But, it if really expects to start before name service comes up, it's not going to happen as those start before SERVERS. The effect is probably only that any DNS queries made prior to it starting are not encrypted. Since name service must start before SERVERS, I see no way to really prevent this, but I think the port should be corrected and a message added to warn that queries made while servers are starting may not be encrypted. "rcorder /etc/rc.d/* /usr/src/etc/rc.d/* > /dev/null" should report the lack of a provider for DNS. -- Kevin Oberman, Network Engineer, RetiredReceived on Fri Mar 20 2015 - 18:01:05 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:56 UTC