/salt, Remote execution and configuration management system
0.16.3, Package name:
salt-0.16.3, Maintainer: pkgsrc-users
Salt is a distributed remote execution system used to execute commands
and query data. It was developed in order to bring the best solutions
found in the world of remote execution together and make them better,
faster and more malleable. Salt accomplishes this via its ability to
handle larger loads of information, and not just dozens, but hundreds,
or even thousands of individual servers. It handles them quickly and
through a simple yet manageable interface.
Required to run:
Master sites: SHA1:
Version history: (Expand)
- (2013-08-18) Updated to version: salt-0.16.3
- (2013-06-15) Updated to version: salt-0.15.3
- (2013-05-12) Updated to version: salt-0.15.1
- (2013-05-05) Updated to version: salt-0.15.0
- (2013-04-28) Updated to version: salt-0.14.1
- (2012-12-06) Updated to version: salt-0.10.5
CVS history: (Expand)
| 2014-03-11 15:05:19 by Jonathan Perkin | Files touched by this commit (350) |
Remove example rc.d scripts from PLISTs.
These are now handled dynamically if INIT_SYSTEM is set to "rc.d", or
| 2014-01-27 19:41:15 by Thomas Klausner | Files touched by this commit (72) |
Do not set FETCH_USING, should not be set in a package Makefile.
| 2014-01-25 11:30:32 by Thomas Klausner | Files touched by this commit (533) | |
Mark packages as not ready for python-3.x where applicable;
either because they themselves are not ready or because a
dependency isn't. This is annotated by
PYTHON_VERSIONS_INCOMPATIBLE= 33 # not yet ported as of x.y.z
PYTHON_VERSIONS_INCOMPATIBLE= 33 # py-foo, py-bar
respectively, please use the same style for other packages,
and check during updates.
Use versioned_dependencies.mk where applicable.
Use REPLACE_PYTHON instead of handcoded alternatives, where applicable.
Reorder Makefile sections into standard order, where applicable.
Remove PYTHON_VERSIONS_INCLUDE_3X lines since that will be default
with the next commit.
Whitespace cleanups and other nits corrected, where necessary.
| 2013-08-17 20:30:02 by Emile iMil Heitor | Files touched by this commit (3) | |
Updated salt to version 0.16.3.
Many changes and updates since version 0.15.3, see:
| 2013-06-15 17:04:39 by Emile iMil Heitor | Files touched by this commit (3) | |
Updated to version 0.15.3, bugfix release
| 2013-05-11 20:26:19 by Emile iMil Heitor | Files touched by this commit (2) | |
Updated to version 0.15.1
This release fixes a serious security issue found in the way that RSA keys
were being generated.
It recommended that existing Salt keys be regenerated once 0.15.1 has been
deployed on the master and all minions.
A 'key_regen' routine has been added to 0.15.1 to make this transition easier.
The following sequence is a convenient way to regenerate all keys in an
You will be prompted to restart the master. Once completed, all keys in the
environment will have been regenerated and you will need to accept the new
keys using the following command:
| 2013-05-05 14:26:23 by Emile iMil Heitor | Files touched by this commit (5) | |
. Fixed rc.d script by adding comment_interpreter
. Updated salt to version 0.15.0
From SaltStack website:
Salt 0.15.0 comes with many smaller features and a few larger ones.
The Salt Mine
First there was the peer system, allowing for commands to be executed from a
minion to other minions to gather data live. Then there was the external job
cache for storing and accessing long term data. Now the middle ground is being
filled in with the Salt Mine. The Salt Mine is a system used to execute
functions on a regular basis on minions and then store only the most recent
data from the functions on the master, then the data is looked up via targets.
The mine caches data that is public to all minions, so when a minion posts
data to the mine all other minions can see it.
0.13.0 saw the addition of initial IPV6 support but errors were encountered
and it needed to be stripped out. This time the code covers more cases and
must be explicitly enabled. But the support is much more extensive than before.
Copy Files From Minions to the Master
Minions have long been able to copy files down from the master file server,
but until now files could not be easily copied from the minion up to the
A new function called cp.push can push files from the minions up to the master
server. The uploaded files are then cached on the master in the master
cachedir for each minon.
Better Template Debugging
Template errors have long been a burden when writing states and pillar. 0.15.0
will now send the compiled template data to the debug log, this makes tracking
down the intermittent stage templates much easier. So running state.sls or
state.highstate with -l debug will now print out the rendered templates in the
State Event Firing
The state system is now more closely tied to the master's event bus. Now when
a state fails the failure will be fired on the master event bus so that the
reactor can respond to it.
Major Syndic Updates
The Syndic system has been basically re-written. Now it runs in a completely
asynchronous way and functions primarily as an event broker. This means that
the events fired on the syndic are now pushed up to the higher level master
instead of the old method used which waited for the client libraries to return.
This makes the syndic much more accurate and powerful, it also means that all
events fired on the syndic master make it up the pipe as well making a reactor
on the higher level master able to react to minions further downstream.
Peer System Updates
The Peer System has been updated to run using the client libraries instead of
firing directly over the publish bus. This makes the peer system much more
consistent and reliable.
Minion Key Revocation
In the past when a minion was decommissioned the key needed to be manually
deleted on the master, but now a function on the minion can be used to revoke
the calling minion's key:
Function Return Codes
Functions can now be assigned numeric return codes to determine if the
function executed successfully. While not all functions have been given return
codes, many have and it is an ongoing effort to fill out all functions that
might return a non-zero return code.
Functions in Overstate
The overstate system was originally created to just manage the execution of
states, but with the addition of return codes to functions, requisite logic
can now be used with respect to the overstate. This means that an overstate
stage can now run single functions instead of just state executions.
Pillar Error Reporting
Previously if errors surfaced in pillar, then the pillar would consist of only
and empty dict. Now all data that was successfully rendered stays in pillar
and the render error is also made available. If errors are found in the
pillar, states will refuse to run.
Using Cached State Data
Sometimes states are executed purely to maintain a specific state rather than
to update states with new configs. This is grounds for the new cached state
system. By adding cache=True to a state call the state will not be generated
fresh from the master but the last state data to be generated will be used.
If no previous state data is available then fresh data will be generated.
The new monitoring states system has been started. This is very young but
allows for states to be used to configure monitoring routines. So far only one
monitoring state is available, the disk.status state. As more capabilities are
added to Salt UI the monitoring capabilities of Salt will continue to be
| 2013-04-28 11:46:25 by Emile iMil Heitor | Files touched by this commit (4) | |
Update salt from 0.10.5 to 0.14.1
. Salt - As a Cloud Controller
. Libvirt State
. New get Functions
Full changelog is available at:
http://docs.saltstack.com/topics/releas … ht=changes