Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 20 Mar 2015 14:47:57 +0000
From:      Miguel Clara <miguelmclara@gmail.com>
To:        Garrett Cooper <yaneurabeya@gmail.com>
Cc:        freebsd-current <freebsd-current@freebsd.org>
Subject:   Re: Shared object "libsodium.so.13" not found, required by "dnscrypt-proxy"
Message-ID:  <CADGo8CUDLc%2BfQw%2BNVJi4LCPXQwXA9uiAU8ORpy2AHsB4W6hcAw@mail.gmail.com>
In-Reply-To: <2A8C0814-E644-4350-85B8-17B468D79BFF@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>

next in thread | previous in thread | raw e-mail | index | archive | help
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 i=
n
>> "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 NEWORKING
>> which has to be after SERVERS. Can you say fubar! Clearly broken. And th=
is
>> 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 w=
hen
>> 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 mos=
t
>> of these pieces around by changing REQUIRE: to BEFORE:, but I noticed th=
at
>> 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-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 befo=
re
>> 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 developers=
 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 an=
y
> nameserver (or kerberos or whatever provider), it is not an issue. As lon=
g
> as rcorder finds a provider, it will be used to set the order, but the la=
ck
> 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 th=
e
> 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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CADGo8CUDLc%2BfQw%2BNVJi4LCPXQwXA9uiAU8ORpy2AHsB4W6hcAw>