On Fri, Mar 20, 2015 at 7:14 PM, Miguel Clara <miguelmclara_at_gmail.com> wrote: > > On Fri, Mar 20, 2015 at 7:01 PM, Kevin Oberman <rkoberman_at_gmail.com> > wrote: > >> 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. >> > > You're right about the order issue, still a lot to fix and indeed > local_unbound doens't include the change so it seems that it works for me > because I'm removing the need for local_unbound unbound or named, and one > of those was probably introducing the issues. > > But I don't understand why this would affect encryption, unless > local_unbound/unbound is not configured properly, if dnscrypt is stoped > local_unbound can't forward the queries and so it won't work... > In my case local_unbound would forward to 127.0.0.2 port 53... since that's > not listening it will simply fail... so you don't really loose encryption > it just fails... when dnscrypt start the queries start being forward and > local_unbound does its job! > This assumes ofc that the nameserver in resolv.conf is set to 127.0.0.1 > *only* (local_unbound/unbound). > Sorry. I don't use dnscrypt_proxy and misunderstood how it works. You are right. -- Kevin Oberman, Network Engineer, Retired E-mail: rkoberman_at_gmail.comReceived on Sat Mar 21 2015 - 03:59:35 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:56 UTC