DAOS NLO Encryption and Decryption
Daniel Nashed 28 May 2014 08:18:57
We have been asking for this functionality since DAOS was releases and now there is finally a solution.In some cases customers have to either switch of DAOS NLO encryption for a server or enable it later on. Or even want to move from one server.id to another server.id.
There are two SPRs (#PMAO9C6R9G / #GFAL9AKKJZ) described in the following technote [Updated HCL Link: https://support.hcltechsw.com/csm?id=kb_article&sysparm_article=KB0038523 ]
The TN also describes how to use this new functionality.
There are a couple of details that you should be aware of. First of all the two SPRs are not included in shipping code and are also not yet listed in the fixlist database.
But they have been submitted to the 9.0.1 code-stream as far I understood.
The output of the commands are printed to the console (using xprintf which is the equivalent of the internal console write call).
I have asked if the output can be written to a file via -o opton in future. But for now you have to use the redirect invoking the daosmgr command.
The TN also mentioned this fix-numbers. So if you need this functionality urgently you can try to request a hotfix from IBM.
And as described in the TN you should use the migration to either encrypted or unencrypted offline. The move is a major migration. All NLOs will be rewritten most cases. This should be planned for a weekend and should be a one time action only.
What are the szenarios and reasons to change the encryption of the NLOs?
In many cases NLOs are encrypted because when DAOS was introduced to an environment someone forgot to set the notes.ini parameter to disable DAOS_ENCRYPT_NLO=0.
But most customers don't require encryption of NLOs.
If the NSF files on your Domino server are not encrypted and the server.id is not protected by a password, it does not make much sense to have the NLOs encrypted.
It is even harder to find the right information in a NLO than in a NSF file. And if you copy the NLOs to a different machine including the server.id if it has no password, you can read the NLO anyway.
So in most cases not having NLO encryption enabled is a best practice for a couple of reasons and the encryption only adds security when the server.id is protected as well.
Encryption adds not that much overhead at runtime but there are a couple of other reasons.
First of all if you want to use another cluster member to copy missing NLOs as more simple restore scenario when a NLO is missing this is only possible if NLOs are not encrypted.
Second if you have storage like a NetApp where you have enabled block-level deduplication and point multiple DAOS stores to the same NetApp volume you can save a lot of disk storage because the same NLOs will have the same blocks. This does only work if the NLO is not encrypted because the same NLO on different servers will be encrypted with a different key (actually even on the same server when encrypted later the file could be different because of a different "session key").
On top of that some backup solutions support block-level deduplication. And that could save space on the backup side as well if encryption is disabled.
With encryption enabled there is amost no block-level deduplication.
In addition moving DAOS stored among servers when you switch the server.id is much more simple without encryption.
But if you have the new options in the daosmgr you could now re-encrypt NLO files with a new server.id.
I would only do this if you really really need it. In normal cases in such a migration scenario I would use the new functionality to disable NLO encryption for the above reasons.
IMHO it is still good to have NLO encryption enabled by default to avoid discussions about DAOS security.
But in reality in at least 80% customer environments NLO encryption is not required overhead and complexity.
I know others think differently about it and that's just my humble opinion...
On the other side we also have customers who started without encryption and now need to encrypt all databases, NLOs and also protect the server.id with a password (including the need for a solution to apply the password on server start in a secure way).
Thanks to IBM to make this change and have it implemented in a flexible way to do it both ways including a verification options for encryption status of all NLOs.
-- Daniel
- Comments [7]
![[HCL Domino]](../lotus-domino.gif){kind=small}
![[Domino on Linux]](../domino-linux.gif){kind=small}
![[Nash!Com]](../nashcom.gif){kind=small}
![[Daniel Nashed]](../daniel-nsh.gif){kind=small}