|
Home > |
|---|
•Command history is supported, using up/down arrows, [Home], [End], [Page Up], [Page Down].
•Non-ambiguous command shortnames are
supported. You must type the exact shortname that is listed in the syntax
help, or else type the full command with no abbreviations.
Additionally, for syntax help, the alias “?” is available.
•Commands and options are case-insensitive.
•Limited scripting is possible
However, handling of return codes is not fully supported at this time. The utility is not a full-featured shell, so features like command-completion or parsing of partial commands are not supported.
Commands and options entered by the user are not sensitive to case. If a user accidentally leaves the Caps-Lock key on, or by habit capitalizes some commands or options, they should not have to re-enter or edit the command line.
Command parameters, however, are passed to command executables with the same case as entered on the command line. Command executables must deal with case issues as appropriate for the command.
For example, you can type:
lunacm:> partition login -password mYpa55word!
or
lunacm:> partition LOGIN -PASSWorD mYpa55word!
and successfully login to your Partition. Note that the command and sub-commands can be any combination of uppercase and lowercase letters. The command parser interprets it correctly. However, the password string itself is passed on to the access-control handler, which is very particular about lettercase. Therefore, an item like a password must be typed letter-perfect with the appropriate case applied.
Note: The above example is for Password Authenticated SafeNet HSMs. For Trusted Path Authenticated HSM, do not type the password - you are directed to the SafeNet PED, which prompts for the required PED Key.
It might happen that a command parameter consists of two or more parts, separated by spaces. This can be misconstrued by the command parser as two (or more) additional parameters. To ensure that a multi-part parameter is parsed as a single entity, enclose it in quotation marks " ".
LunaCM's cache can become unsynchronized if you access an HSM in more than one application session and make administrative changes.
For example, you might attempt a role login against a connected SafeNet Network HSM application partition, in a lunacm instance that had been open for a while, and you (or someone else) had just made a partition policy change in lunash, such as changing max bad login attempts from default 10 down to (say) 3. The policy change comes into effect immediately, though any other open sessions might be unaware of the change. A failed attempt in the open lunacm instance might state that you still had nine unsuccessful attempts remaining, when in fact you had only two, because the lunacm instance was not up-to-date with the change made via lunash.
Relaunching lunacm, or using "clientconfig restart" updates the cache and fixes the mismatch.