Date: Fri, 20 Mar 2015 21:59:34 -0700 From: Kevin Oberman <rkoberman@gmail.com> To: Miguel Clara <miguelmclara@gmail.com> Cc: freebsd-current <freebsd-current@freebsd.org>, Garrett Cooper <yaneurabeya@gmail.com> Subject: Re: Shared object "libsodium.so.13" not found, required by "dnscrypt-proxy" Message-ID: <CAN6yY1vEc_4o_F83L9s%2BL21-Nv7w4U4%2BDiqXVS4%2BU93GgXvOEw@mail.gmail.com> In-Reply-To: <CADGo8CX7H0zdcMk_GCqLHtZYwG2Zu-fXegf-AyiDRP44eU4T4g@mail.gmail.com> References: <CADGo8CURnvyLD55zs5m=hgrG9g6xct0q4ZMSNiY%2BzLA1GBi0Ug@mail.gmail.com> <CAGHfRMC1_jRQxkxu-aaJJBvqb8oPvOrCiJwOWhLsR1A81YKrEw@mail.gmail.com> <CADGo8CWyyFJXR5fD%2BYe%2BSynzH0mqfh3Fsx8ULmQzOxTwR0Bd8A@mail.gmail.com> <FF6DD5BB-7D15-4224-8EF5-DA1C89908B1B@gmail.com> <B506CD41-42F8-4DAF-B2D3-B09C70A2A28D@gmail.com> <64AF7708-217B-4AC0-A47A-AD1B0BFF7EDC@gmail.com> <CADGo8CUCCjrW-3p9F4aiwRh1fbid%2BfNjikag55%2BNheJYBUt-Rg@mail.gmail.com> <885DA4D0-9644-4F06-97C9-04EAD7B4958C@gmail.com> <CADGo8CVjVig6HT6o2MYMzXizFLG62WMEFTe278nq8qoOg3-akQ@mail.gmail.com> <CAN6yY1tKDi4da25KbpATRnOE7YZOgVyw78rBrH4wofF3iqQLXQ@mail.gmail.com> <CADGo8CV4=4V31ibc9S43e3bBC1g3YL-m-NLc2Bccz_Pk4fQ49Q@mail.gmail.com> <CADGo8CV4ziyTxJJstLm9VWFueLGVjkZ=Kt6hhV1owymSMf7=yg@mail.gmail.com> <CADGo8CUeexNbOW8VbjNQ8-UGrsVny5JO4Ckv89XNg9v-aEetSA@mail.gmail.com> <CAN6yY1tpyinY1yueHY8Tr=igQbkTpwJBdz9-aUwQ5xdMqiVf-A@mail.gmail.com> <CADGo8CUo=QUV904F7PsndiB%2B6pcYBD%2B1gC7tNZkswRvRNWEB4Q@mail.gmail.com> <98CF988A-D9DB-49AD-8CFF-3B438F892730@gmail.com> <CAN6yY1tLhH1Karz2NWFJ9vU2jRcC_cFbmOnLuj2G3Mdn17hm0Q@mail.gmail.com> <2A8C0814-E644-4350-85B8-17B468D79BFF@gmail.com> <CADGo8CUDLc%2BfQw%2BNVJi4LCPXQwXA9uiAU8ORpy2AHsB4W6hcAw@mail.gmail.com> <CAN6yY1s%2BHSeV6dix0svfV-CxT8x14PDvg=1VacA1-LHKn7U3nw@mail.gmail.com> <CADGo8CX7H0zdcMk_GCqLHtZYwG2Zu-fXegf-AyiDRP44eU4T4g@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Mar 20, 2015 at 7:14 PM, Miguel Clara <miguelmclara@gmail.com> wrote: > > On Fri, Mar 20, 2015 at 7:01 PM, Kevin Oberman <rkoberman@gmail.com> > wrote: > >> On Fri, Mar 20, 2015 at 7:47 AM, Miguel Clara <miguelmclara@gmail.com> >> wrote: >> >>> >>> On Thu, Feb 26, 2015 at 2:52 AM, Garrett Cooper <yaneurabeya@gmail.com> >>> wrote: >>> >>>> >>>> On Feb 25, 2015, at 18:08, Kevin Oberman <rkoberman@gmail.com> wrote: >>>> >>>> On Wed, Feb 25, 2015 at 2:30 PM, Garrett Cooper <yaneurabeya@gmail.com= > >>>> wrote: >>>> >>>>> On Feb 25, 2015, at 14:19, Miguel Clara <miguelmclara@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=3D275299&= r2=3D278704 >>>>> > >>>>> > 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 NEWORK= ING >>>>> which has to be after SERVERS. Can you say fubar! Clearly broken. And= this >>>>> means that removing SERVERS will re-shuffle the order more appropriat= ely. >>>>> > >>>>> > It seems that the behavior of rcorder is not as documented as well >>>>> as being undefined when circular dependencies occur. The man page say= s 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 gues= s when >>>>> a circular dependency is encountered, a dichotomy occurs. >>>>> >>>>> Now you know why I=E2=80=99m 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 no= ticed >>>>> that it changes the rcorder a bit, so I haven=E2=80=99t been super gu= ng 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 exist= ed >>>>> 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 i= n a >>>>> more robust manner to fail gracefully and retry instead of failing fl= at on >>>>> their face, but as I=E2=80=99ve seen at several jobs, getting develop= ers to fail, >>>>> then retry is hard :(=E2=80=A6). >>>>> >>>>> 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 igno= red >>>> 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 th= ese >>>> 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 bom= bs >>>> that break working ports without their being touched or even re-instal= led. >>>> 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@/rc@ because it needs to >>>> be solved in a saner way -- especially for systems that are pedantic a= bout >>>> 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: >>> >>> @@ -4,7 +4,7 @@ >>> # >>> # 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 st= art >> before SERVERS. The effect is probably only that any DNS queries made pr= ior >> 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 add= ed >> to warn that queries made while servers are starting may not be encrypte= d. >> >> "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@gmail.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAN6yY1vEc_4o_F83L9s%2BL21-Nv7w4U4%2BDiqXVS4%2BU93GgXvOEw>