Blogs

Blog Tags Help

Enter a tag to filter the current view
Entries Comments

Lotus Nut

A blog for the Lotus Nut!

All entries tagged with administration

Removing notes.ini settings via the console

Chris Whisonant  

The other week I was made aware of something I did not know was possible. It turns out that the reason I never knew it was possible was that it is new with Domino 8. I found this out after attempting the trick on a Domino 7.0.3 server... :)

With previous releases of Domino, if you wanted to remove a line from the notes.ini, you had to manually edit the file. But now, with Domino 8, you can type set config Notes_ini_Setting= and this will remove the line completely. In previously releases, the line would still exist but it would just have a null value. Below is a screen capture of me doing this.



You can see that I show config to verify the entry exists. Then I set it to = null. Then I show config again and get "Invalid value for command option" (which means the entry does not exist. Finally, I set it back to its original value and show config again to validate that it exists.

Note: If you really want to make sure the entry is gone (and doesn't re-appear or stay enforced), be sure to look through your configuration documents and also remove the entry from the notes.ini section.

Domino 8.0.1: 101 - Mandated ID Encryption Standard (SnTT)

Chris Whisonant  

Continuing my series on Domino 8 Administration features, new with Domino 8.0.1 is the option to mandate the encryption standard for ID files. Full details can be found at the infocenter. With Notes 8.0 and Domino 8.0.1, there is an option to use AES for ID file encryption. Here's how strong AES is:

"The design and strength of all key lengths of the AES algorithm (i.e., 128, 192 and 256) are sufficient to protect classified information up to the SECRET level. TOP SECRET information will require use of either the 192 or 256 key lengths. The implementation of AES in products intended to protect national security systems and/or information must be reviewed and certified by NSA prior to their acquisition and use."
Implementation of AES requires a Domino 8.0.1 server. A Security Settings document is used to configure how the ID file's encryption will be enforced on your server. In a new or existing Security Settings document, you will need to go to the Password Management tab and then scroll to the bottom to the ID File Encryption Settings section:


For both the Mandated and Allowed encryption standards fields, you have the following choices (the same choices as when you change your password in Notes 8.0):
  • Compatible with all releases (64 bit RC2)
  • Compatible with release 6 and later (128 bit RC2)
  • Compatible with release 8 and later (128 bit AES)
  • Compatible with release 8 and later (256 bit AES)
First of all, this is great that companies can now mandate this. But the super swank option is the "Key derivation strength (iterations)" field. In layman's terms, the higher you set this value (the default is 5000), the longer a dictionary attack will take against the ID file. It won't be impervious to an attack, but you shouldn't be using passwords that are in dictionaries... From the infocenter:

Key derivation strengthening is a technique used to make it more costly for malicious attackers to guess likely passwords through a brute force dictionary attack. They work by increasing the time it takes to generate a key from a password. The value for this field is the number of times an HMAC algorithm is applied as part of the operation that generates a key from the password. Specifying a larger number for this value increases the duration of each attempt during a dictionary attack. The default setting for this field is 5000, which is acceptable in most environments. Organizations with higher security requirements may wish to specify a higher value.
So, once you have your servers at 8.0.1 and then have clients at 8.0 or higher, you can begin enforcing this. However, you may also phase this in with a tiered approach. For instance, if you have admins and/or developers that may have access to sensitive data, you may wish to get them on the Notes 8.0 + client and apply a special security settings document to their policy.

Fragmentation and Domino

Chris Whisonant  

Over at IdeaJam, someone posted an idea on certifying NTFS defragmentation utilities for Domino. Below is my comment there - I would love to see what some of you think about this. Also, here is an example of what I see time and again when looking at fragmentation on Domino systems:



I don't care what file system you use, if you are using Domino you will have fragmentation. Even the WAFL fs has a defrag utility, even though it may be less susceptible.

The "problem" with Domino databases is that right after you defrag the volume, the file system starts to fragment because you're adding to the databases and that data has to go somewhere. It cannot go into a contiguous block because there may not be block space available due to the defrag tool keeping all files contiguous when defragging. And this isn't necessarily a problem with Domino - it's more of an issue with the file system and how it allocates storage.

To deal with this and achieve good uptime, I had hoped that a copy-style compact would be a poor man's defrag. Initially, it would seem that this would work because a new copy of the database would be created. However, this is not so because Domino doesn't (or can't?) always allocate a contiguous block that will store the entire database. Besides, Domino creates the database and has to start allocating space for the individual documents. Even if Domino could allocate a contiguous block, it would still suffer from fragmentation when new documents are added. (note: I didn't put this at my Idea Jam comment, but I would note that other transactions on the system will likely start to allocate blocks where the copy-style compact would be placing the data, so this is why more fragmentation may occur).

If Domino could get around this and use a contiguous block, I would propose something like "load compact -c +10" so that you get 10% white space in the new copy. Then you could have some white space in which new documents can be created and not cause further fragmentation.

Taking Domino out of the equation, something that may actually be faster than a defrag is to move all of the databases (or at least the largest or most heavily fragmented) off of the disk onto another volume and then run a defrag on the remaining files on that drive. Then just move the data back and the file system should allocate contiguous blocks for the new data while it's creating them one at a time.

Any other thoughts?