Bug #1570
closed
nfd-start fails on Ubuntu
100%
Description
System: Ubuntu 12.04 and 13.10
On a fresh Ubuntu virtual machine, I installed the latest NFD and copied nfd.conf.sample to nfd.conf. When I enter nfd-start, it quits with:
FATAL: [NRD] FileStore: error opening file for reading: /home/remap/.ndn/ndnsec-tpm-file/RUBdnuW+hM85LYTqLNQXRHAzE4Qxqctc76H%xlSAiVM=.pri
Full startup output:
1398970316.614601 INFO: [StrategyChoice] Set default strategy /localhost/nfd/strategy/best-route
1398970316.615851 INFO: [StrategyChoiceEntry] Set strategy /localhost/nfd/strategy/best-route for / prefix
1398970316.660809 INFO: [InternalFace] registering callback for /localhost/nfd/fib
1398970316.660863 INFO: [InternalFace] registering callback for /localhost/nfd/faces
1398970316.660972 INFO: [InternalFace] registering callback for /localhost/nfd/strategy-choice
1398970316.661004 INFO: [InternalFace] registering callback for /localhost/nfd/status
1398970316.661029 INFO: [FaceTable] Added face id=1 remote=internal:// local=internal://
1398970316.884094 WARNING: [CommandValidator] Wildcard identity is intended for demo purpose only and SHOULD NOT be used in production environment
1398970316.884396 INFO: [CommandValidator] Giving privilege "faces" to identity wildcard
1398970316.884711 INFO: [CommandValidator] Giving privilege "fib" to identity wildcard
1398970316.884992 INFO: [CommandValidator] Giving privilege "strategy-choice" to identity wildcard
1398970316.886679 INFO: [UdpFace] Creating multicast UDP face for group 224.0.23.170:56363
1398970316.887329 INFO: [FaceTable] Added face id=2 remote=udp4://224.0.23.170:56363 local=udp4://10.211.55.25:56363
1398970316.889915 INFO: [EthernetFace] Creating ethernet face on eth0: 00:1c:42:f8:93:b8 <--> 01:00:5e:00:17:aa
1398970316.897333 INFO: [FaceTable] Added face id=3 remote=ether://01:00:5e:00:17:aa local=dev://eth0
1398970316.903820 WARNING: [CommandValidator] Wildcard identity is intended for demo purpose only and SHOULD NOT be used in production environment
1398970316.908131 INFO: [CommandValidator] Giving privilege "faces" to identity wildcard
1398970316.908232 INFO: [CommandValidator] Giving privilege "fib" to identity wildcard
1398970316.908271 INFO: [CommandValidator] Giving privilege "strategy-choice" to identity wildcard
1398970318.483241 INFO: [RibManager] Setting interest filter on: /localhost/nfd/rib
1398970318.485110 FATAL: [NRD] FileStore: error opening file for reading: /home/remap/.ndn/ndnsec-tpm-file/RUBdnuW+hM85LYTqLNQXRHAzE4Qxqctc76H%xlSAiVM=.pri
Updated by Alex Afanasyev almost 10 years ago
- Category set to Tools
- Assignee set to Junxiao Shi
- Target version set to v0.1
ok. i know what the problem. NFD is started with sudo, it created the key (since it didn't exist) as superuser. Then nrd tried to start and failed to read the file.
Junxiao. Can you change both nfd and nrd to start as the same user in nfd-start. I personally prefer nfd-start not to assume anything on my behalf and start as the user I'm currently running. If I want, I will run nfd-start as superuser...
Updated by Junxiao Shi almost 10 years ago
- Tracker changed from Task to Bug
Key pair should be created during installation, not automatically when NFD is started for the first time.
Otherwise, if operator invokes sudo nfd-start followed by nfdc ... (without sudo), nfdc ... won't be able to read the key.
Updated by Alex Afanasyev almost 10 years ago
Right now we do not require any useful signing/verification for default (demo) purposes. It doesn't make sense to require users to create a key that they will not use in any meaningful way.
It is also incorrect that superuser (sudo) is using user's keys. The ugly solution is to reset HOME variable in the script.
Btw. I just remembered another problem I was having with nfd-start, which is related to forced sudo. I run it, it asked for the password, but while I was slow in typing the password, nrd started (and of course failed, since I didn't have time to start nfd yet).
What about if instead of simply running sudo in the script, we check if the script is run as super user and if not, we just fail (or so some magic to elevate privileges).
Updated by Anonymous almost 10 years ago
On the Raspberry Pi (Raspbian Wheezy), I ran "nfd-start" (not "sudo nfd-start") and it works great. The files in ~/.ndn are owned by the user. But when I run nfd-start on Ubuntu, the files in ~/.ndn are owned by root. I'm curious if you know why the difference?
Updated by Alex Afanasyev almost 10 years ago
Was it clean raspberry PI installation? Can you remove ~/.ndn and then try again?
Depending on sudo settings, on some systems sudo also updates $HOME variable, which may or may not happen in Rapsberry Pi case.
Updated by Anonymous almost 10 years ago
Yes, it was a clean install with a fresh image of Raspbian on the SD card. I just removed ~/.ndn and did nfd-start again. Here's the result:
$ ls -l ~/.ndn
total 20
-rw-r--r-- 1 pi pi 15360 May 2 17:38 ndnsec-public-info.db
drwxr-xr-x 2 pi pi 4096 May 2 17:38 ndnsec-tpm-file
$ ls -l ~/.ndn/ndnsec-tpm-file/
total 12
-r-------- 1 pi pi 1643 May 2 17:38 iTjMjg7zWdbZbdc778HNDIiZ+fLdb1nkZtJe8bFWfXg=.pri
-r--r--r-- 1 pi pi 398 May 2 17:38 iTjMjg7zWdbZbdc778HNDIiZ+fLdb1nkZtJe8bFWfXg=.pub
-rw-r--r-- 1 pi pi 116 May 2 17:38 mapping.txt
Updated by Junxiao Shi almost 10 years ago
- Status changed from New to In Progress
- Estimated time set to 1.00 h
Confirmed.
Updated by Junxiao Shi almost 10 years ago
- Status changed from In Progress to Code review
Updated by Junxiao Shi almost 10 years ago
- Status changed from Code review to Closed
- % Done changed from 60 to 100