Project

General

Profile

Actions

Feature #2925

closed

Set default location of SQLite3 PIB and file-based TPM with environment variable

Added by Alex Afanasyev almost 9 years ago. Updated over 7 years ago.

Status:
Closed
Priority:
Normal
Category:
Security
Target version:
Start date:
Due date:
% Done:

100%

Estimated time:

Description

This issue is to add several new environment variables to override default and client.conf configuration:

  • NDN_CLIENT_TRANSPORT: equivalent of transport in client.conf
  • NDN_CLIENT_PIB: equivalent of pib in client.conf
  • NDN_CLIENT_TPM: equivalent of tpm in client.conf
Actions #1

Updated by Junxiao Shi almost 9 years ago

  • Tracker changed from Task to Feature
  • Subject changed from Introduce explicit environment variable to set default location of PIB and file-based TPM to Set default location of SQLite3 PIB and file-based TPM with environment variable
  • Description updated (diff)

Potential problem: user may believe this directory can be moved, which causes the following:

  1. PIB_DIR=/dir1 ./app
  2. user moves /dir1 to /dir2
  3. PIB_DIR=/dir2 ./app

User expects the application to continue working with the same PIB.

But since the environ affects the TPM as well, changing the environ causes a change in tpmLocator which triggers a PIB reset. This is inconsistent with user's expectation.

Actions #2

Updated by Alex Afanasyev almost 9 years ago

I had impression that TPM location (for file-based TPM) is relative to PIB, unless specified explicitly. If I'm wrong, we may need to actually implement this guarantee.

Actions #3

Updated by Davide Pesavento almost 8 years ago

may I suggest NDN_PIB_DIR as the name of the env variable?

Actions #4

Updated by Alex Afanasyev almost 8 years ago

  • Status changed from New to In Progress
  • Assignee set to Alex Afanasyev
  • Target version set to v0.4
Actions #5

Updated by Alex Afanasyev almost 8 years ago

  • Description updated (diff)
Actions #6

Updated by Alex Afanasyev almost 8 years ago

  • % Done changed from 0 to 100
Actions #7

Updated by Alex Afanasyev almost 8 years ago

  • Status changed from In Progress to Code review
Actions #8

Updated by Junxiao Shi almost 8 years ago

  • Description updated (diff)

If we have NDN_PIB_DIR, do we still need TEST_HOME?

I'm thinking about taking NDN_PIB_DIR as a replacement of $HOME/.ndn for both PIB+TPM and client.conf.

Actions #9

Updated by Alex Afanasyev almost 8 years ago

Location of client.conf doesn't need to be (and for test cases, it should not, otherwise they will break) tied to location of PIB/TPM. We may introduce different variable than TEST_HOME, but I would like not to tangle them together.

Actions #10

Updated by Junxiao Shi almost 8 years ago

An alternate is to specify the location of client.conf in NDN_CLIENT_CONF_PATH.

An advantage over NDN_PIB_DIR is that it allows all configuration options to be customized through the use of the environ combined with something on the filesystem.

Note that NDN_PIB_DIR still relies on the filesystem for storing PIB+TPM, and there isn't much benefit in not writing a client.conf.

NDN_PIB_DIR can cause confusion when NDN_PIB_DIR environ and PIB/TPM locator in effective client.conf points to different locations, or when client.conf specifies a PIB/TPM that is not file-based.

Imagine there's a MySQL-based PIB.
You can select that with NDN_CLIENT_CONF_PATH but not NDN_PIB_DIR.

Actions #11

Updated by Alex Afanasyev almost 8 years ago

What about another option: three variables corresponding to the config file.

  • NDN_TRANSPORT (or NDN_CLIENT_TRANSPORT): equivalent of transport in client.conf
  • NDN_PIB (or NDN_CLIENT_PIB): equivalent of pib in client.conf
  • NDN_TPM (or NDN_CLIENT_TPM): equivalent of tpm in client.conf

There is a little bit of a hassle of just specifying location of the client.conf, as one needs to create that file.

Actions #12

Updated by Junxiao Shi almost 8 years ago

note-11 solution is as good as NDN_CLIENT_CONF_PATH.

I prefer the environ names with _CLIENT_ component.

Actions #13

Updated by Alex Afanasyev almost 8 years ago

  • Description updated (diff)
Actions #14

Updated by Junxiao Shi almost 8 years ago

More design questions:

Should Face default constructor throw an error if NDN_CLIENT_TRANSPORT is valid but the transport key in configuration file is invalid?

Should Face constructor that takes an explicit Transport instance throw an error if NDN_CLIENT_TRANSPORT or transport key in configuration file is invalid?

Actions #15

Updated by Alex Afanasyev almost 8 years ago

If config is overridden by the environment, the config file should be inactive. If env correct, no exceptions should be thrown.

Actions #16

Updated by Junxiao Shi almost 8 years ago

note-15 only answers the first question in note-14. The second question remains.

Actions #17

Updated by Alex Afanasyev almost 8 years ago

I think you are asking questions with obvious answers. If Transport is explicitly specified (unless it is nullptr), config file is not opened, so no error can be triggered.

Actions #18

Updated by Alex Afanasyev over 7 years ago

  • Status changed from Code review to Closed
Actions

Also available in: Atom PDF