6 Commits

Author	SHA1	Message	Date
Devon Stewart	d730d4f2b8	Using cfg_salt['master'] is never the right answer ... - When it's iterable, the minion could be running on the master - When it's a string, there's no advantage over just specifying `salt:minion:master`	2015-11-15 12:11:20 -08:00
genus	4ff1a746d6	Add master_type option	2015-07-29 19:48:56 +03:00
genus	a738198d8b	Add verify_master_pubkey_sign	2015-07-24 17:58:41 +03:00
Javier Domingo	4344a1311b	Cleanup template for easier user reading ... The user will already have it's /etc/salt/minion file, so it doesn't need all this info, and it makes easier to know what has been generated and what not	2015-05-08 22:33:43 +02:00
Andrew Vant	11efee54c3	Added mine_functions to f_defaults.conf.	2015-04-03 14:34:34 -04:00
Brian Jackson	7649c26a0d	Switch config file.recurse to clean by default and tell it to ignore _* ... Salt writes it's schedule file to /etc/salt/{minion,master}.d/_schedule.conf We don't want to stomp all over Salt's files, but we do want a pristine starting point to lay down our managed config. So we use clean: True on the file.recurse call, but we tell it to ignore files that start with an _ We have to rename the current config file (_defaults.conf) because it will be ignored by the rule that ignores Salt's _* config files. This also means we need to clean up old config files (_defaults.conf) and restart the service if we cleaned it up.	2015-03-27 17:58:05 -05:00