Per my own testing on dozens of SmartOS VM's and issue #473 "Problem
3", the salt-minion service manifest definition doesn't work. This
change fixes that. I think it may have broke in 2014.7 so back porting
to that ver.
"bdist" doesn't do the right thing in the absence of
version files produced by "sdist".
Run "sdist" then extract out the contents of the tarball
into place
Some users reported an errror that SMF couldn't find auditconfig despite
the fact that the PATH is set correctly. Invoking with the full path
seems to fix the issue.
Mimicking the breakout of requirements files in the main project,
this allows me to keep a file of extra requirements that get put in the
esky (e.g. halite) while only needing to point the build process at
either the zeromq or raet requirements file.
This fixes an issue @njones11 was having with
multiple cron.present states.
"crontab -l <username>" would fail, so the temp file
would be empty, a given cronjob would go in
and then the "su - <username> crontab <temp file>" would
succeed.
This evaded debugging attempts because if you invoked the salt
minion manually from a login shell, an audit context would
already exist and the "crontab -l <username>" would succeed.
The hint was a message in the debug log of:
[ERROR ] Command 'crontab -l legion' failed with return code: 1
[ERROR ] stderr: crontab: The audit context for your shell has not
been set.
We explicitly set up an audit context when launching the salt minion
which allows "crontab -l <username>" to succeed.
This may fix other issues and something similar
should perhaps be applied to pkg/smartos/salt-minion.xml
"5417" was chosen arbitrarily
detect if this is a global or non-global zone
global zones are always minions
if the user passes in the name/address of the master
we configure a minimal minion file and launch the minion
Don't assume that the top directory is named "salt"
The user might choose to name it "salt-<version>"
or "saltstack" or whatever else.
install.sh is already that flexible; this fixes _syspaths.py
We ran into some weird issues with these SMF manifests
with certain critical binaries not being found in the PATH.
This PATH is derived from root's default PATH when logging
in to a SmartOS zone.
This includes:
Notes on how I created a build environment
The _syspaths.py that allows the esky build to be installed anywhere
"Template" SMF manifests and an install script to import them
A script for building both the esky zip and a deployable tarball
Manifests in pkg/solaris are using /etc/salt which is innapropriate
for SmartOS design (/etc is removed @reboot). I suggest to add a
new directory in order to preserve existing Solaris installations
(and SmartOS one which are based on those manifests).
