Shared object "libsodium.so.13" not found, required by "dnscrypt-proxy"

[Miguel Clara]

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@/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.
>

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
>