From owner-freebsd-current@FreeBSD.ORG Sat Mar 21 04:59:35 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 944AEC7D for ; Sat, 21 Mar 2015 04:59:35 +0000 (UTC) Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 42FF223F for ; Sat, 21 Mar 2015 04:59:35 +0000 (UTC) Received: by igbud6 with SMTP id ud6so4319198igb.1 for ; Fri, 20 Mar 2015 21:59:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=6KABM2ZU01H40Lf6bnSHtiCJcB9I3EYHI1Cox7sfa0U=; b=Vd21foxIsOUIRhlJVHpwLxf7UEJFSpdnUvtVFPrCEomultnl042huNzpoId6SYMX20 8YmGoBgDpfX1aPnnG0Ad+T2vOEhoAodRCDackXS3UwqcG9/GX23FFEZODY0y3l3Rn7Mh OTXYziHOC5qqnU0oA6Zwr2mk49cdru0w3ay/qRpa8SOqxuUOsu96NziBeobIXd48siIv m2g5PzfyZQrZlyoTw1lgbFHlKcREa/8inE0BIG4v/COAzsXAxKjrIKfRhIwAKUGitISJ 3RlgC3vsjvo2r7noZnp7+GLoQb3fsHWyMgSPCsYtdLDJiq6/ygTDtbP189V0dkiVB8EO 5nOQ== MIME-Version: 1.0 X-Received: by 10.43.157.67 with SMTP id lp3mr8502467icc.23.1426913974614; Fri, 20 Mar 2015 21:59:34 -0700 (PDT) Sender: kob6558@gmail.com Received: by 10.107.174.86 with HTTP; Fri, 20 Mar 2015 21:59:34 -0700 (PDT) In-Reply-To: References: <64AF7708-217B-4AC0-A47A-AD1B0BFF7EDC@gmail.com> <885DA4D0-9644-4F06-97C9-04EAD7B4958C@gmail.com> <98CF988A-D9DB-49AD-8CFF-3B438F892730@gmail.com> <2A8C0814-E644-4350-85B8-17B468D79BFF@gmail.com> Date: Fri, 20 Mar 2015 21:59:34 -0700 X-Google-Sender-Auth: SkS-0phhwO1TY9skBikokSitQxE Message-ID: Subject: Re: Shared object "libsodium.so.13" not found, required by "dnscrypt-proxy" From: Kevin Oberman To: Miguel Clara Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-current , Garrett Cooper X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2015 04:59:35 -0000 On Fri, Mar 20, 2015 at 7:14 PM, Miguel Clara wrote: > > On Fri, Mar 20, 2015 at 7:01 PM, Kevin Oberman > wrote: > >> On Fri, Mar 20, 2015 at 7:47 AM, Miguel Clara >> wrote: >> >>> >>> On Thu, Feb 26, 2015 at 2:52 AM, Garrett Cooper >>> wrote: >>> >>>> >>>> On Feb 25, 2015, at 18:08, Kevin Oberman wrote: >>>> >>>> On Wed, Feb 25, 2015 at 2:30 PM, Garrett Cooper >>>> wrote: >>>> >>>>> On Feb 25, 2015, at 14:19, Miguel Clara >>>>> 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