help-gnunet
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Help-gnunet] nsswitch not resolving VPN records


From: Christian Grothoff
Subject: Re: [Help-gnunet] nsswitch not resolving VPN records
Date: Fri, 24 Feb 2017 20:22:53 +0100
User-agent: Mozilla/5.0 (X11; Linux i686; rv:45.0) Gecko/20100101 Icedove/45.6.0

On 02/24/2017 02:04 PM, Ivan Vilata-i-Balaguer wrote:
> Christian Grothoff (2017-02-23 23:08:44 +0100) wrote:
> 
>> Dear Ivan,
>>
>> First of all, 0.10.1-4 is like 3+ years old, so I'm likely to have
>> forgotten about some of the 350+ issues we've fixed since.  Generally,
>> we right now recommend people (especially devs) to use the code from
>> Git, even though that's naturally somewhat unstable.  That said, I
>> just had reason to test the VPN resolution logic, and for me it works
>> right now (in Git master).
> 
> Oh, so you probably fixed this issue already upstream.

_Maybe_. What you write below makes it sound like it's an issue with
your setup.

>> Anyway, about your specific problem: When the gnunet-service-gns gets
>> a 'VPN' record and is expected to produce an 'A' (or 'AAAA') record,
>> it must talk to gnunet-service-vpn to obtain the IPv4/IPv6 address.
>> You can do the same kind of operation using the 'gnunet-vpn'
>> command-line tool (specify info from VPN record, it should return the
>> IP).  If gnunet-service-vpn is
>>
>> * not running (even though it should be started automatically),
>> * not working (i.e. interface not up, SUID gnunet-helper-vpn not
>>   properly installed)
>> * or somehow not accessible (access control policy on UNIX domain
>>   socket, iptables blocking TCP port, etc)
>>
>> it will block/retry until VPN becomes available (which of course usually
>> means "never" in the 3 cases above).
>>
>> To diagnose, you might try running 'gnunet-vpn' with the matching
>> information from the VPN record as the same user that executes
>> gnunet-service-gns.  If that works, eh, well, then I don't know and
>> would have to start debugging (but I don't debug 0.10.1 anymore).
> 
> Ok, so I got:
> 
>     $ gnunet-gns -u www.gnu -t VPN
>     www.gnu:
>     Got `VPN' record: 6 XXXXXXXX bcd
> 
> So I ran:
> 
>     $ gnunet-vpn -t -p XXXXXXXX -s bcd -V
> 
> But the program got stuck there.  Actually there was no
> ``gnunet-service-vpn`` running and ``gnunet-helper-vpn`` was not SUID,
> so I enabled the SUID bit.

Ah, with the helper not being SUID, the VPN will refuse to launch
properly. However, you may have to manually restart GNUnet (or at least
the VPN service process) after you fix the SUID bit, as it won't
continuously probe for it (IIRC).

> I even enabled the PL/VPN system service
> with ``gnunet-setup`` for the ``gnunet`` user, but still the same
> result.

As in, no 'gnunet-service-vpn' running, or 'gnunet-vpn' not terminating?
 Try something like

$ gnunet-arm -i vpn

to start the VPN service. If that doesn't work, maybe consult the logs
to see if the VPN service is complaining about more than the missing SUID.

> Anyway, I get from your initial paragraph that it makes no sense trying
> to work around issues in such an old release that may have been fixed
> later.  I'll try to build a newer version when I find more time!
> 
> BTW, are you planning to launch some stable release soon?

Well, what I plan and what happens tend to rarely agree ;-).
But, we have made good progress recently, so now there are less than 10
RC issues left on my list (albeit there are some serious non-GNUnet
distractions coming up as well, so 10 may not sound like much, but...).

It'll be ready when it is ready.

Attachment: 0xE29FC3CC.asc
Description: application/pgp-keys

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]