Although I have a basic Salt Master setup completed I never verified the configuration actually pushses. Preferably configurations will be kept in Git, and when I push these commits will be pushable to the target systems.

Following along with an a Linode Guide there appears to be a command sudo salt-run manage.up. This however timed out. While tailing with journal -u salt-master -f is got the message:

Jan 04 20:16:28 kal salt-master[7676]: [WARNING ] Authentication failure of type “user” occurred.

Which was quiet interesting. Not suprisingly this message does not really provide enough information to actually diagnose the actual issue at hand. There are a number of Github issues related to this error message, including many very old threads. From what I could gather this is an issue with the way sudo handles the environment. After verifying via a correct login environment, for my configuration this is not hte problem.

Perhaps it is an issue with how I configured the master server? sudo_acl is the defult value.

Turns out because the default user under my install runs as salt requests from all other users, including root on the master will result in failures. This can be fixed by either running the command as salt like sudo -u salt salt-run manage.up or modifying publisher_acl to allow the user to execute commands like the following.

publisher_acl:
  myuser:
    - .*    

Well, in theory that worked. Looks like salt-run will exeucte jobs locally on master and try writing to parts of the file system a user should not have access too. Although due to the confused depuety problem it might be exaclty why this type of escalation might not be valid.

Pushing the changes

After getting through the Ubuntu permissions this part was easy. Although Salt will perform these actions in due time, by defualt between 60-120 seconds you can force the updates earlier for faster deployments. Effectively there are two steps to force Salt to update the state across the cluster before. First is to notify Salt the Git repository has changes. Then the second is to push the changes to the target nodes. Like the following.

sudo -u salt salt-run fileserver.update
sudo -u salt salt '*' state.apply

Probably best to just let Salt do it’s thing though, despite the wait being annoying while testing changes.