.. _configuring-local-nano-client: Configuring local Nano Client ############################## The ``local.yml`` configuration is the base of a running Nano which handles the Nano instance, dependencies and localhost security. For security reasons, Nano can not update this configuration file. To ensure that this rule won't be circumvented it is recommended to set this file to read-only. Updating this file requires the Nano to be restarted in order to see the changes. ``log_config`` *************** Nano uses the builtin Python logging module for it's internal logging tasks. For configuring the logging module, please refer to the `official Python docs `_ . ``remote_admin_policy`` ************************ default: ``"restrict"`` This option sets the way Nano handles the remote configuration commands issued by the Nano owner. .. FIXME: admin_password and restrict are different Three settings are accepted here: - ``allow`` accepts all admin commands - ``restrict`` will prompt the owner to input a passcode of 5 digits along with each command - ``deny`` rejects all admin commands The remote configuration commands update the settings found in the ``remote.yml`` configuration file. Enabling this security policy may greatly limit the damage an adversary could do by gaining access to the account of the owner. The downside however is that even the owner will be unable to change configurations remotely, which could be highly inconvenient depending on the location of the hardware which runs the Nano client. ``localhost_network_security`` ******************************* default: ``"ec"`` This configuration determines how the different processes in a nano instance authenticate and communicate with each other. By default Nano ensures authentication and confidentiality during process communication. This can be changed to only require basic authentication which consumes less system resources. Two settings are accepted here: - ``ec`` authenticates processes and encrypts communication with dynamically generated x5519 curves - ``basic`` authenticates processes with dynamically generated plain passwords ``path_unicode_normalization`` ******************************* default: ``"default"`` This configuration determines how paths from remote systems are normalized before writing to storage. Valid settings accepted here: - ``default`` will be ``NFD`` on Mac and ``NFC`` on other platforms - ``keep`` will not normalize, just keep the remote paths as-is - ``NFC``, ``NFD``, ``NFKC``, ``NFKD`` can be selected directly to be used ``restrict_sensitive_path_access`` ******************************* default: ``true`` Deny creating and serving drive roots of common places with sensitive data. | .. DANGER:: The configurations below handle software dependency - incorrect setup will stop Nano from booting up ``config_dir`` *************** default: ``""`` An absolute path pointing to a writable directory where necessary configurations will be stored, such as drive, authentication etc. ``data_dir`` ************* default: ``""`` An absolute path pointing to a writable directory where necessary data will be stored like sessions, state, etc. ``pid_dir`` ************ default: ``"pid"`` An absolute or relative path pointing to a writable directory where subprocess tracking information will be stored. This directory must be on a local filesystem. .. NOTE:: If the ``pid_dir`` is relative, it will be appended to ``data_dir`` ``solr_dir`` ************* default: ``""`` An absolute or relative path pointing to a writable directory where Apache Solr stores index data and configurations. These paths can be overridden by more specific configurations (see below). The directory should be on the local filesystem. (NFS is theoretically possible, but not supported well) This location should be secured as properly as the data itself from local access (other users). ``solr_data_dir`` ****************** default: ``"data"`` An absolute or relative path pointing to a writable directory where Apache Solr data files will be stored. .. NOTE:: If the ``solr_data_dir`` is relative, it will be appended to ``solr_dir`` ``solr_logs_dir`` ****************** default: ``"data"`` An absolute or relative path pointing to a writable directory where Apache Solr log files will be stored. .. NOTE:: If the ``solr_logs_dir`` is relative, it will be appended to ``solr_dir`` .. FIXME: add solr_heap_size ``tika_dir`` ************* default: ``""`` An absolute or relative path pointing to a writable directory where Apache Tika stores log files and configurations. This path can be overridden by more specific configurations (see below). The directory should be on the local filesystem. (NFS is theoretically possible, but not supported well) This location should be secured as properly as the data itself from local access (other users). ``tika_logs_dir`` ****************** default: ``"logs"`` An absolute or relative path pointing to a writable directory where Apache Tika log files will be stored. .. NOTE:: If the ``tika_logs_dir`` is relative, it will be appended to ``tika_dir`` .. FIXME: add tika_heap_size .. FIXME: add picoture_heap_size ``java_dir`` ************* default: ``""`` An absolute path pointing to a directory where JRE is located. Some dependency software which Nano uses are Java based and require a JVM to run. If left empty, Nano will try to lookup the JRE from default locations: - Use JRE that's bundled with the client - Use JRE indicated by JAVA_HOME environment variable - Use JRE found in PATH (java executable) ``solr_bundle_dir`` ******************** default: "" An absolute path pointing to a directory where Apache Solr is located. If left empty, Nano will try to use the client's bundled software. ``tika_bundle_dir`` ********************** default: "" An absolute path pointing to a directory where Apache Tika is located. If left empty, Nano will try to use the client's bundled software.