I was playing with OpenLMI – I mean, testing OpenLMI – on my home network, and learned that I need to upgrade my local setup.

I don’t have a local nameserver, and have fallen into the (bad) habit of not assigning hostnames to temporary testbed systems and addressing them by IP address. This means that these systems have the default name of “localhost.localdomain”.

I was having OpenLMI connection problems. With the help of some patient engineers, we discovered that this was due to a SSL security certificate validation failure which was occuring because the connection hostname didn’t match the certificate subject.

There are several ways to avoid this:

• The right way to do is is to have a proper domain environment such as FreeIPA or MS Active Directory managing your certificates. We strongly recommend this approach.
• At a minimum you should should have a nameserver and make sure you assign hostames to all your systems, even the temporary testbeds. When you do this the manual certificate management procedures described in the installation article will work.
• If you are still having trouble, you can avoid checking the certificates by using the noverify option to bypass certificate validation:
  • lmi -h system.domain.org –noverify
  • lmishell –noverify
    c = connect(“systemname”,”username”,”password”)

It should go without saying, but don’t do this in production!

Note that if you change the hostname on a system you will need to regenerate the certificates. Changing hostname is more likely to happen in a test and demo environment than in a production environment.

If you are running both OpenLMI and LMIShell on the same system you have different behaviors when logged in as root. When logged in as root and accessing the local system, OpenLMI bypasses certificate authentication – you already have full access to the system! If you are not logged in as root, you will be prompted for username and password. In general, the best practice is to use the pegasus user with OpenLMI.