View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0005907 | GNUnet | GNS | public | 2019-09-25 19:34 | 2019-12-15 15:18 |
| Reporter | dvn | Assigned To | Christian Grothoff | ||
| Priority | urgent | Severity | block | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Product Version | Git master | ||||
| Target Version | 0.12.0 | Fixed in Version | 0.12.0 | ||
| Summary | 0005907: 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" | ||||
| Tags | No tags attached. | ||||
| Attached Files | |||||
|
|
I should add that `curl us.archive.ubuntu.com` works as expected. It resolves. |
|
|
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 ":". |
|
|
> 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. |
|
|
Looking through the GNS module source, I'm unsure where the string ignore should be. Can you point me in the right direction? |
|
|
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,
|
|
|
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 ... |
|
|
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... |
|
|
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. |
|
|
I think actually libnss should probably be doing that test and bailing. Basically, no GNUnet for root. |
|
|
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. |
|
|
0.12.0 released |
| 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 |
