To list Salt minions:
To accept one:
salt-key -a <nodeInternalAddress>
To list unaccepted in chronological order:
cd /etc/salt/pki/master/minions_pre ls -lt
Salt maintains a downloadable install script which should work in just about every distribution of Linus. When I ran salt master install script, it didn't actually install the salt master. In the future `aptitude install salt-master` (etc...) works just fine.
Installing and starting the Salt Minion (which is described in its own section) will send keys to the Master which require acceptance before the minion can be manipulated by it. The command `salt-key -L` will list all the salt keys, including an unaccepted section with keys from minions asking to be accepted. The command `salt-key -a Salt_Key" will accept an individual key called "Salt_Key" that shows up in the previous list, and `salt-key -A` will accept all keys.
Keys are based on the `id` established in the '/etc/salt/minion' configuration file. If you change the id you will need to accept the key again for the new id.
The salt state files are in /srv/salt, and in that directory you'll find we recently we subdivided that space by environments, dev, stage, prod, and poc. The first three are self-explanitory, the 'poc' is a production environment for the testing product.
Using grains to set up nodegroups for resin and ldap.
The Salt Master requires an EIP, but amazon doesn't automatically associate it after bootup. To solve this problem we put a script in /etc/init.d/elastic-ip that associates the EIP on bootup. It uses an IAM user with specific and limited access to associate EIP's only. But that required the latest version of the ec2-api-tools, which I eventually just downloaded and installed in /opt (the ones available in apt were all to old).
To facilitate the use of salt in the ec2 environment, we deployed a salt ec2 grain plugin at _grains in the salt directories, which can be found here https://github.com/saltstack/salt-contrib/blob/master/grains/ec2_info.py