Date: Sat, 21 Mar 2015 02:14:38 +0000 From: Miguel Clara <miguelmclara@gmail.com> To: Kevin Oberman <rkoberman@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: <CADGo8CX7H0zdcMk_GCqLHtZYwG2Zu-fXegf-AyiDRP44eU4T4g@mail.gmail.com> In-Reply-To: <CAN6yY1s%2BHSeV6dix0svfV-CxT8x14PDvg=1VacA1-LHKn7U3nw@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>
next in thread | previous in thread | raw e-mail | index | archive | help
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&r= 2=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 NEWORKI= NG >>>> which has to be after SERVERS. Can you say fubar! Clearly broken. And = this >>>> means that removing SERVERS will re-shuffle the order more appropriate= ly. >>>> > >>>> > It seems that the behavior of rcorder is not as documented as well a= s >>>> being undefined when circular dependencies occur. The man page says th= at >>>> rcorder aborts when it encounters a circular dependency, but that is n= ot >>>> 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=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 not= iced >>>> that it changes the rcorder a bit, so I haven=E2=80=99t been super gun= g 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 th= e >>>> case if the rc.d script was removed from your system, which existed be= fore >>>> my changes). >>>> - Other rc.d scripts not being present might break assumptions. >>>> >>>> I need to create dummy providers for certain logical stages (DNS is on= e >>>> 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 fla= t on >>>> their face, but as I=E2=80=99ve seen at several jobs, getting develope= rs to fail, >>>> then retry is hard :(=E2=80=A6). >>>> >>>> Another short-term hack: >>>> >>>> Install dummy/no-op providers so the ordering is preserved, then remov= e >>>> 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 a= ny >>> 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 l= ong >>> 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 ignor= ed >>> 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 the= se >>> 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 bomb= s >>> that break working ports without their being touched or even re-install= ed. >>> 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 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: >> >> @@ -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 sta= rt > before SERVERS. The effect is probably only that any DNS queries made pri= or > 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 adde= d > 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 por 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). The ultimate proof is that I never have internet when dnscrypt fails to start cause I don't really have dns, no matter if local_unbound is running or not, but again this is my case with my config. Back to the main issue... yes this is a mess and its something that I feel should really be fixed. -- > Kevin Oberman, Network Engineer, Retired >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CADGo8CX7H0zdcMk_GCqLHtZYwG2Zu-fXegf-AyiDRP44eU4T4g>