View Issue Details

IDProjectCategoryView StatusLast Update
0005907GNUnetGNSpublic2019-12-15 15:18
Reporterdvn Assigned ToChristian Grothoff  
PriorityurgentSeverityblockReproducibilityalways
Status closedResolutionfixed 
Product VersionGit master 
Target Version0.12.0Fixed in Version0.12.0 
Summary0005907: APT cannot resolve package servers when libnss GNS plugin enabled
Description"Something wicked happened resolving 'us.archive.ubuntu.com:http' (-5 - No address associated with hostname)"

This is an example of the type of error message I get from `apt` when the GNS plugin for libnss is enabled, a trying to update the repository list, or install packages. I'm using apt version 1.8.1, on Ubuntu, but I've also experienced this in the past on Debian with (presumably) different versions of apt.

For reference, here is the relevant line from my nsswitch.conf:

"hosts: files gns [NOTFOUND=return] mdns4_minimal [NOTFOUND=return] dns"
TagsNo tags attached.
Attached Files

Activities

dvn

2019-09-25 19:36

developer   ~0014964

I should add that `curl us.archive.ubuntu.com` works as expected. It resolves.

Christian Grothoff

2019-10-06 22:00

manager   ~0014978

That's because curl implements DNS itself and bypasses libc NSS.

"us.archive.ubuntu.com:http" -- maybe that's the issue: does it really pass ":http" as part of the hostname? If that's the case, we might have to simply modify gnunet-gns to ignore everything after the ":".

dvn

2019-10-06 22:11

developer   ~0014979

> That's because curl implements DNS itself and bypasses libc NSS.

hmm, but I am able to curl gns names when I have the nsswitch plugin enabled...

> If that's the case, we might have to simply modify gnunet-gns to ignore everything after the ":".

I will try this out.

dvn

2019-10-08 19:49

developer   ~0014986

Looking through the GNS module source, I'm unsure where the string ignore should be. Can you point me in the right direction?

Christian Grothoff

2019-10-08 20:00

manager   ~0014987

dvn, please try with the attached patch against gnunet-gns.c
colon-patch.diff (411 bytes)   
diff --git a/src/gns/gnunet-gns.c b/src/gns/gnunet-gns.c
index 5f4061f7d..510e46d14 100644
--- a/src/gns/gnunet-gns.c
+++ b/src/gns/gnunet-gns.c
@@ -201,6 +201,12 @@ run (void *cls,
 
   cfg = c;
   to_task = NULL;
+  {
+    char *colon;
+
+    if (NULL != (colon = strchr (lookup_name, ':')))
+      *colon = '\0';
+  }
   if (GNUNET_OK != GNUNET_DNSPARSER_check_name (lookup_name))
   {
     fprintf (stderr,
colon-patch.diff (411 bytes)   

dvn

2019-10-09 22:11

developer   ~0014989

that does indeed work.

we have some undesirable and inaccurate output preceding the regular APT output though:

Oct 09 13:02:08-648275 gnunet-gns-17982 WARNING Cannot resolve using GNS: GNUnet peer not running
Oct 09 13:02:08-653523 gnunet-gns-17983 WARNING Cannot resolve using GNS: GNUnet peer not running
Oct 09 13:02:08-739994 gnunet-gns-17984 WARNING Cannot resolve using GNS: GNUnet peer not running
Oct 09 13:02:08-748697 gnunet-gns-17985 WARNING Cannot resolve using GNS: GNUnet peer not running
Oct 09 13:02:08-839123 gnunet-gns-17986 WARNING Cannot resolve using GNS: GNUnet peer not running
Oct 09 13:02:08-843210 gnunet-gns-17987 WARNING Cannot resolve using GNS: GNUnet peer not running
Oct 09 13:02:08-896835 gnunet-gns-17988 WARNING Cannot resolve using GNS: GNUnet peer not running
Oct 09 13:02:08-900443 gnunet-gns-17989 WARNING Cannot resolve using GNS: GNUnet peer not running
Hit:2 http://us.archive.ubuntu.com/ubuntu disco InRelease
Hit:3 http://security.ubuntu.com/ubuntu disco-security InRelease
...

Christian Grothoff

2019-10-09 22:44

manager   ~0014990

Ok, I've applied the patch to master.
Why do you say the output is inaccurate? Is the peer running? (properly, etc.)?

I must admit I'm also a bit dubious about running gnunet-gns at all as root, as usually there shouldn't be GNUnet processes running as 'root', and the above _could_ only work if root ran a 'full peer'. So maybe an answer would be to test for 0==getuid() and bail if it is true.

As for the output being 'undesirable', what do you propose we do? Not logging anything when we give up if a peer is not running doesn't seem right either...

dvn

2019-10-10 06:49

developer   ~0014991

Argh, I typed out a long response and then it timed out when I tried to submit... I thought we fixed this in Mantis years ago! :P

Try again...

> Ok, I've applied the patch to master.
> Why do you say the output is inaccurate? Is the peer running? (properly, etc.)?
>
> I must admit I'm also a bit dubious about running gnunet-gns at all as root, as usually there shouldn't be GNUnet processes running as 'root', and the above _could_ only work if root ran a 'full peer'. So maybe an answer would be to test for 0==getuid() and bail if it is true.

Ah, yes, the output is accurate. I overlooked the fact that the command was running as root, thus unable to communicate with the gns service.

"test for 0==getuid() and bail if it is true" <--- Do you mean for the gns service or the utility? If the service, then that would mean that root could still resolve names as long as the node was setup for multi-user, correct? I'll admit that almost all of my usage and testing of gnunet has been with single-user configurations.

Christian Grothoff

2019-10-12 20:17

manager   ~0015006

I think actually libnss should probably be doing that test and bailing. Basically, no GNUnet for root.

Christian Grothoff

2019-11-30 23:35

manager   ~0015104

The GNS NSS plugin now simply rejects all requests if we are invoked as root. The result should be that they are passed to DNS-only.

schanzen

2019-12-15 15:18

administrator   ~0015169

0.12.0 released

Issue History

Date Modified Username Field Change
2019-09-25 19:34 dvn New Issue
2019-09-25 19:34 dvn Status new => assigned
2019-09-25 19:34 dvn Assigned To => Christian Grothoff
2019-09-25 19:36 dvn Note Added: 0014964
2019-10-06 22:00 Christian Grothoff Note Added: 0014978
2019-10-06 22:11 dvn Note Added: 0014979
2019-10-08 19:49 dvn Note Added: 0014986
2019-10-08 20:00 Christian Grothoff File Added: colon-patch.diff
2019-10-08 20:00 Christian Grothoff Note Added: 0014987
2019-10-09 22:11 dvn Note Added: 0014989
2019-10-09 22:44 Christian Grothoff Note Added: 0014990
2019-10-10 06:49 dvn Note Added: 0014991
2019-10-12 20:17 Christian Grothoff Note Added: 0015006
2019-11-16 19:51 Christian Grothoff Product Version => Git master
2019-11-16 19:51 Christian Grothoff Target Version => 0.12.0
2019-11-30 23:35 Christian Grothoff Status assigned => resolved
2019-11-30 23:35 Christian Grothoff Resolution open => fixed
2019-11-30 23:35 Christian Grothoff Fixed in Version => 0.12.0
2019-11-30 23:35 Christian Grothoff Note Added: 0015104
2019-12-15 15:18 schanzen Note Added: 0015169
2019-12-15 15:18 schanzen Status resolved => closed