It is recommended that you back up Navigator Encrypt configuration directory after installation, and again after any configuration updates.

  Warning: Failure to back up the configuration directory makes your backed-up encrypted data unrecoverable in the event of data loss.

To validate the Navigator Encrypt deployment, run the following command:

$ sudo navencrypt status --integrity

This command verifies that:

• The mount encryption key (MEK) exists for each mount point.
• Each mount point in /etc/navencrypt/ztab has a corresponding entry in the control file (/etc/navencrypt/control).
• Each mount point directory exists.
• For loop devices, the file used for encrypted storage exists.

The output is similar to the following:

$ sudo navencrypt status --integrity
Checking MEKs integrity

        Mountpoint: /dev/loop0
                MEK file exist: ......................   [YES]
        Mountpoint: /dev/loop1
                MEK file exist: ......................   [YES]

Checking Ztab Mountpoints integrity

         Mountpoint: /dev/loop0
                 ztab vs control correspondence: .....   [YES]
                 Mountpoint directory exists: ........   [YES]
         Mountpoint: /dev/loop1
                 ztab vs control correspondence: .....   [YES]
                 Mountpoint directory exists: ........   [YES]

Checking Datastore backend files

         Datastore: '/root/my_storage_test'
                 Backend file exist: .................   [YES]

Navigator Encrypt deposits its mount encryption keys (MEKs) and control file (/etc/navencrypt/control) in Cloudera Navigator Key Trustee Server. If these files are accidentally deleted, they can be restored from Key Trustee Server using the following commands:

• To restore MEKs:

  $ sudo navencrypt key --restore-keys

• To restore the control file:

  $ sudo navencrypt control --restore-control-file

$ sudo /usr/sbin/navencrypt status -d

  Note: The navencrypt status command reports that the navencrypt module is not running if no volumes are encrypted or the kernel module is not loaded.

$ sudo /usr/sbin/navencrypt set --mode={enforcing|permissive|admin}

You cannot change the Navigator Encrypt access mode unless the Navigator Encrypt module is running. To view the status of the Navigator Encrypt module, run navencrypt status --module.

$ sudo /etc/init.d/navencrypt-mount status

$ sudo systemctl status navencrypt-mount

You can perform two operations with the navencrypt key command: change and verify.

$ sudo /usr/sbin/navencrypt key --verify
$ sudo /usr/sbin/navencrypt key --verify --only-module
$ sudo /usr/sbin/navencrypt key --verify --only-keytrustee

  Note: The navencrypt key command fails if no volumes are encrypted or the kernel module is not loaded.

$ sudo /usr/sbin/navencrypt key –-change

You can use the --trustees, --votes, and --recoverable options for the new key as described in Registration Options.

All rules reference a process fingerprint (a SHA256 digest) that is used to authenticate the process into the file system. If the filesystem detects a fingerprint that is different from the one stored in the ACL, the Linux process is denied access and treated as an untrusted process.

Occasionally this process fingerprint must be updated, such as when software is upgraded. When the fingerprint must be updated, the Navigator Encrypt administrator re-authenticates the process on the ACL by executing the command navencrypt acl --update.

$ sudo /usr/sbin/navencrypt acl --list
Type MASTER passphrase:
# -  Type Category    Path         Profile  Process
1 !! ALLOW @mysql *            /usr/sbin/mysqld
2 ALLOW @log * /usr/sbin/mysqld
3 !! ALLOW @apache * /usr/lib/apache2/mpm-prefork/

In the example above, the double exclamation (!!) characters indicate that a process fingerprint has changed and must be updated. Similarly, double E (EE) characters indicate a process read error. This error can be caused by a process that does not exist or that has permission issues.

  Note:

For RHEL-compatible OSes, the prelink application may also be responsible for ACL fingerprint issues. Prelinking is intended to speed up a system by reducing the time a program needs to begin. Cloudera highly recommends disabling any automated prelink jobs, which are enabled by default in some systems. As an alternative, Cloudera recommends that you integrate a manual prelink run into your existing change control policies to ensure minimal downtime for applications accessing encrypted data.

To disable prelinking, modify the /etc/sysconfig/prelink file and change PRELINKING=yes to PRELINKING=no. Then, run the /etc/cron.daily/prelink script as root. Once finished, automatic prelinking is disabled.

For more information about how prelinking affects your system, see prelink.

For RHEL 7, use systemctl [start|stop|status|restart] navencrypt-mount.

  Note: Do not manually unmount the encryption mount point (for example, using umount). If you do so, you must manually close the dm-crypt device using the following procedure:

1. Run dmsetup table to list the dm-crypt devices.
2. Run cryptsetup luksClose <device_name> to close the device for the unmounted mount point.

When executing the stop operation, the encrypted mount point is unmounted, and your data becomes inaccessible.

$ sudo /etc/init.d/navencrypt-mount status

$ sudo /etc/init.d/navencrypt-mount stop

$ sudo /etc/init.d/navencrypt-mount start

$ sudo /usr/sbin/mount.navencrypt /path/to_encrypted_data/ /path/to/mountpoint

This command can be executed only if the navencrypt-prepare command was previously executed.

If the kernel headers were not installed on your host, or if the wrong version of the kernel headers were installed, the Navigator Encrypt module was not built at installation time. To avoid reinstalling the system, install the correct headers and execute the navencrypt-module-setup command. This attempts to build the module and install it.

This method is also an efficient way to install any new Navigator Encrypt module feature or fix without otherwise modifying your current Navigator Encrypt environment.

$ tree /etc/navencrypt/
/etc/navencrypt/
├── control -> /etc/navencrypt/jSpi9SM65xUIIhrau1Nn8ZXmQhrrQ9e363EUz8HKiRs
├── jSpi9SM65xUIIhrau1Nn8ZXmQhrrQ9e363EUz8HKiRs
├── rules
├── ztab
locust
└── keytrustee
        ├── clientname
        ├── deposits
        │   ├── dev.loop0
        │   ├── media.31E5-79B9locustlocust[system ~]# . /etc/*release[system ~]# . /etc/*release
        │   ├── mnt.a
        │   ├── mnt.encrypted
        │   └── mnt.tomount
        ├── pubring.gpg
        ├── pubring.gpg~
        ├── random_seed
        ├── secring.gpg
        ├── trustdb.gpg
        └── ztrustee.conf

Every mount point has an internal randomly-generated encryption passphrase.

When troubleshooting problems with Navigator Encrypt, it is helpful to gather information about the installation and environment. Navigator Encrypt provides a command to facilitate this:

$ sudo navencrypt-collect

This command collects and outputs to the console the following information:

• Information about the system on which Navigator Encrypt is installed
• Entries from /etc/navencrypt/ztab
• The contents of the keytrustee.conf file
• Recent entries from the Navigator Encrypt log file
• Configured software repositories
• Checksums of all /usr/src/navencrypt* and /usr/sbin/navencrypt* files

You can use this information to compare Navigator Encrypt installations and to provide to Cloudera Support for troubleshooting. The navencrypt-collect command only outputs this information on the console, and does not generate any files or upload to Cloudera.

To save the information to a file, use the redirect operator (>). For example:

$ sudo navencrypt-collect > navencrypt.info

See Best Practices for Upgrading Navigator Encrypt Hosts for considerations when upgrading operating systems (OS) and kernels on hosts that have Navigator Encrypt installed.