Date: Fri, 20 Mar 2015 12:01:03 -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: <CAN6yY1s%2BHSeV6dix0svfV-CxT8x14PDvg=1VacA1-LHKn7U3nw@mail.gmail.com> In-Reply-To: <CADGo8CUDLc%2BfQw%2BNVJi4LCPXQwXA9uiAU8ORpy2AHsB4W6hcAw@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>
next in thread | previous in thread | raw e-mail | index | archive | help
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 NEWORKIN= G >>> which has to be after SERVERS. Can you say fubar! Clearly broken. And t= his >>> means that removing SERVERS will re-shuffle the order more appropriatel= y. >>> > >>> > It seems that the behavior of rcorder is not as documented as well as >>> being undefined when circular dependencies occur. The man page says tha= t >>> rcorder aborts when it encounters a circular dependency, but that is no= t >>> the case. It probably is best that it not die, but that leaves things i= n 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 noti= ced >>> that it changes the rcorder a bit, so I haven=E2=80=99t been super gung= ho in >>> implementing my change. >>> >>> I think there are a couple bugs present on 9-STABLE/10-STABLE/11-CURREN= T: >>> >>> - 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 bef= ore >>> 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=E2=80=99ve seen at several jobs, getting developer= s 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 i= s >> 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 an= y >> will work for ordering and having none is a no-op, so if you don't run a= ny >> nameserver (or kerberos or whatever provider), it is not an issue. As lo= ng >> as rcorder finds a provider, it will be used to set the order, but the l= ack >> of any or all providers just means that the specified provider is ignore= d >> and if a REQUIRES or BEFORE lists no existing providers, the statement i= s >> 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 t= he >> ordering process may change the way the ordering flips. That is why thes= e >> 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-installe= d. >> 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 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, Retired
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAN6yY1s%2BHSeV6dix0svfV-CxT8x14PDvg=1VacA1-LHKn7U3nw>