Using –login-path with MySQL Cluster Manager


Protective convenience
Recent versions of MySQL has an added security feature, the –login-path option. This feature puts your username and password in an encrypted file, and you refer clients to this file instead of typing plain text passwords on the console, or putting them in scripts. This makes it harder for an attacker to snoop passwords, but also more convenient for you as the user as there is less password typing involved.

In this blog I’ll show you how to use feature with MCM.

2 scenarios
As a user there are two scenarios where one would typically use the –login-path feature. Between

  • the mysql client and mysqld
  • the mcm client and mcmd

To get going quickly, I’ll bootstrap a cluster using the –bootstrap option for mcmd.

Our test cluster is up and running in about 30 seconds – with 2 mysqlds, 2 datanodes, a ndb_mgmd, and a ndbapi slot ready to go.

The tool used to create the encrypted file on disk is called mysql_config_editor. It places your logins in a single file in your home directory by default. On linux this file is ~/.mylogin.conf. Each defined login is associated with a logical name chosen by the user. In a MySQL Cluster context an example logical name could be “mysqld50” for a mysqld with cluster nodeid 50, but you are free to choose as you please.

In addition, you can set the $MYSQL_TEST_LOGIN_FILE environment variable to specify an alternative file for mysql_config_editor to use.

More details are available in the –login-path documentation, should you want.

Let’s decide we want to use one .mylogin.conf file per cluster in our MCM setup. By default MCM places all cluster specific data in a subfolder hierarchy under its mcm_data/clusters folder. Since our testing cluster is all on a single host, we can place our alternate .mylogin.conf here. In a real-world setup you would likely be better off placing the alternate login file somewhere in your home directory, or another globally reachable or mounted location. The cluster specific subfolder hierarchy under mcm_data is local to each machine, and isn’t distributed to other hosts across the MCM site. Any file created here will not be available on another host. Since this is a single host cluster, we disregard this, and carry on specifying the alternate login file:

mysql client to mysqld
Next, we define the login paths for our 2 mysqlds on ports 3306 and 3307. Let’s name them “mysqld50” and “mysqld51” respectively:

Using the print –all options we may inspect the generated file:

We can now refer to these login paths when we connect to the mysqlds:

As expected, login path “mysqld51” connected us to mysqld 51 running on port 3307. That’s sorted, then!

mcm client to mcmd
Now, let’s repeat for the mcm client connections to mcmd in a different shell. We’ll want to keep the mcmd login around even if we should delete the cluster, so we place the login file directly under mcm_data instead:

Again, using print –all to verify:

We can now use –login-file to connect to mcmd with the mcm client as well:

And we’re all set, using –login-path with MCM.

1,186 total views, 8 views today

About Thomas Nielsen

Thomas Nielsen is a software engineer, and the Team Lead for MySQL Cluster Manager, at Oracle. He has worked on different high availability products and technologies in databases, as well as JavaDB, before joining the MySQL Cluster team. He holds an engineering degree from the Norwegian University of Science and Technology, and his past-time passion is gliding instruction and cross country soaring.

Leave a Reply