Forums/Knowledge Base/ClusterControl

Server Requirements (on-premise, AMIs, other images)

Johan
posted this on October 28, 2011 16:17

This article describes the requirements on a server that is part of ClusterControl.

The following is described below:

  • Resolving Hostnames and IP addresses
  • Sudo / root - Operating System user
  • Passwordless SSH
  • SELinux 
  • AppArmor

Resolving Hostnames and IP addresses

We recommend that you use IP addresses!! If you use IP addresses you can skip this section.

Each server that is part of the infrastructure must have:

  • a real hostname (unless you have specified SKIP_NAME_RESOLVE in the configurator)
  • Note that SKIP_NAME_RESOLVE is recommended!
If you want to use real hostnames instead of IP addresses then you must ensure that hostname -i  does not print out 127.0.0.1 or 127.0.1.1.

In that case you need a good /etc/hosts file. The file should be identical on all servers in your cluster.

Below is a GOOD example:

# Do not remove the following line, or various programs
# that require network functionality will fail.
127.0.0.1        localhost.localdomain localhost
10.0.1.10       clustercontrol
10.0.1.11       server_a
10.0.1.12       server_b

The /etc/hosts file must be the copied out (and be idenitcal) on all machines in the Cluster. MySQL Cluster, MySQL Replication, Galera, and ClusterControl will not work as expected otherwise.

Below is a VERY BAD example (having hostname on the same line as 127.0.0.1 or 127.0.1.1 is bad practice):

# Do not remove the following line, or various programs
# that require network functionality will fail.
127.0.0.1        clustercontrol localhost.localdomain localhost
10.0.1.10       clustercontrol
10.0.1.11       server_a
10.0.1.12       server_b

Sudo / root - Operating System user

If you install as user 'root' you can skip this section.

If you install as another user than 'root' the following must be true:

  • The Operating System User (OS User) must exists on all hosts
  • The OS User must not be 'mysql'
  • The OS User must be able to do password less sudo (see below for how that is setup)

Password-less 'sudo' Howto

On all machines (unless you prepare your image) you must do:

> sudo visudo 
#add the following line at the end. Replace OSUSER with the OS User you have entered in the Configurator:
OSUSER ALL=(ALL) NOPASSWD: ALL
# save and exit the file.

Open a new terminal to verify it works. You should now be able to do (e.g):

sudo ls /usr 

without entering a password.

Also test:

ssh -qt osuser@ipaddress "sudo ls /usr"

where osuser is the name of the user you intend to use during the installation, and ipaddress is the ip address of a computer in your cluster.
If you have to enter a password,  then you have to login to that machine and run 'sudo visudo' and do as stated above.

SSH - passwordless

The Operating System User (OS User) specified in the Configurator must be able to ssh from the ClusterControl server to all other servers without password.

The deployment script , deploy.sh, will allow you to setup password less SSH so normally you don't have to do anything here.

If you want to prepare images (AMIs, VMWARE etc)  you should as in the example below. The example shows how to setup passwordless SSH from the server clustercontrol to your images.

#Make sure you are the OS User and do:
clustercontrol> ssh-keygen -t rsa

#press enter when it asks passwords etc

clustercontrol> cat $HOME/.ssh/id_rsa.pub > $HOME/.ssh/authorized_keys
clustercontrol> cat $HOME/.ssh/id_rsa.pub > $HOME/.ssh/authorized_keys2

#Set the correct permissions

chmod 600 $HOME/.ssh/authorized_key
chmod 600 $HOME/.ssh/authorized_keys2
chmod 700 $HOME/.ssh

#Make sure you have the files $HOME/.ssh/authorized_keys and $HOME/.ssh/authorized_keys2
# on the images you want to SSH password less to, with the permissions set above.
# The id_rsa.pub file only needs to be on the server you want to SSH passwordless from.

 You should now be able to ssh from clustercontrol to the other server(s).

ssh <username>@<serverip>

If you can't, check permissions of the .ssh dir and the files in it.

Some users have also set the following in their /etc/ssh/sshd_config file:

RSAAuthentication=Yes

Don't forget to restart you sshd daemon ( /etc/init.d/sshd restart ) if you make changes in the ssd_config file

SELinux

The Deployment scripts (deploy.sh) allows you to disable SELinux so normally you don't have to do anything here.

MySQL requires that SELInux accepts MySQL as a service and that is allowed to open ports.

Often, SELinux is set in enforcing mode, which typically means that the MySQL Server won't start or that no client are able to connect to it.

For MySQL Cluster it means often that the Data nodes are stuck in start phase 0 or 1.

Setting SELinux in permissive mode

Edit /etc/selinux/config

# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
#     enforcing - SELinux security policy is enforced.
#     permissive - SELinux prints warnings instead of enforcing.
#     disabled - No SELinux policy is loaded.
SELINUX=permissive
# SELINUXTYPE= can take one of these two values:
#     targeted - Targeted processes are protected,
#     mls - Multi Level Security protection.
SELINUXTYPE=targeted

Make sure you have

SELINUX=permissive

or

SELINUX=disabled

The server requires a reboot for this option to kick in.

You can also temporarily disable SELinux:

echo '0' > /selinux/enforce

If you want to use SELinux then you need to set it up so it works with MySQL (port 3306). It is not covered here.

AppArmor

Todo: Suggestions and recommendations are welcome