search

vmware-archive / salt-windows-install

Open source installer for Windows
saltstack.org
BSD 2-Clause "Simplified" License
75 stars 39 forks source link

windows masterless mode not supported well #30

Open liyingbo opened 9 years ago

liyingbo commented 9 years ago

I am new to salt. I have spent more than a week to fight with SaltStack for all kinds of software dependencies. It looks like SaltStack have not completed the development to Windows solution, especially for masterless mode. Almost all the versions (v2015.5.4, v2.15.5.5, v2015.8.0) have problem with windows standalone minion. I followed the instructions on link https://docs.saltstack.com/en/latest/topics/installation/windows.html

For example,

C:\salt>salt-call --local state.highstate -l debug [DEBUG ] Reading configuration from c:\salt\conf\minion [DEBUG ] Configuration file path: c:\salt\conf\minion [DEBUG ] Reading configuration from c:\salt\conf\minion [DEBUG ] LazyLoaded jinja.render [DEBUG ] LazyLoaded yaml.render [DEBUG ] LazyLoaded jinja.render [DEBUG ] LazyLoaded yaml.render [DEBUG ] LazyLoaded state.highstate [DEBUG ] LazyLoaded grains.get [DEBUG ] LazyLoaded saltutil.isrunning [DEBUG ] LazyLoaded roots.envs [ERROR ] No suitable version of pygit2/libgit2, GitPython, or Dulwich is installed. [DEBUG ] Could not LazyLoad git.envs [DEBUG ] Could not LazyLoad roots.init [DEBUG ] Could not LazyLoad git.envs [DEBUG ] Updating roots fileserver cache [DEBUG ] Could not LazyLoad git.envs [DEBUG ] Could not LazyLoad git.envs [DEBUG ] Reading configuration from c:\salt\conf\minion [DEBUG ] LazyLoaded jinja.render [DEBUG ] LazyLoaded yaml.render [INFO ] Loading fresh modules for state activity [DEBUG ] LazyLoaded jinja.render [DEBUG ] LazyLoaded yaml.render [DEBUG ] Could not LazyLoad git.envs [DEBUG ] Could not LazyLoad git.envs [INFO ] Fetching file from saltenv 'base', * skipped * latest already in cache 'salt://top.sls' [DEBUG ] Jinja search path: ['c:\salt\var\cache\salt\minion\files\base'] [DEBUG ] Rendered data from file: c:\salt\var\cache\salt\minion\files\base\top.sls: base: '':

      ID: nginx
Function: pkg.installed
  Result: False
 Comment: Package nginx not found in the repository.
 Started: 16:34:00.615000
Duration: 15.0 ms
 Changes:
      ID: winscp
Function: pkg.installed
  Result: False
 Comment: Package winscp not found in the repository.
 Started: 16:34:00.630000
Duration: 16.0 ms
 Changes:

Summary

Succeeded: 0

Failed: 2

Total states run: 2

I have already install pyOpenssl with “pip install pyOpenssl” but still has problem. I used google search online, find this is an open issue, has not been fixed yet.

C:\salt>salt-call -l debug --local pkg.refresh_db [DEBUG ] Reading configuration from c:\salt\conf\minion [DEBUG ] Configuration file path: c:\salt\conf\minion [DEBUG ] Reading configuration from c:\salt\conf\minion [DEBUG ] LazyLoaded jinja.render [DEBUG ] LazyLoaded yaml.render [DEBUG ] LazyLoaded jinja.render [DEBUG ] LazyLoaded yaml.render [DEBUG ] LazyLoaded pkg.refresh_db [DEBUG ] LazyLoaded cp.is_cached [DEBUG ] LazyLoaded roots.envs [ERROR ] No suitable version of pygit2/libgit2, GitPython, or Dulwich is installed. [DEBUG ] Could not LazyLoad git.envs [DEBUG ] Could not LazyLoad roots.init [DEBUG ] Could not LazyLoad git.envs [DEBUG ] Updating roots fileserver cache [DEBUG ] LazyLoaded nested.output local: True

Here are the dependent software have been installed on Vagrant guest VM. A lot of other software not shown here. I have switched from V2015.8.0 to V2015.5.5 to V2015.5.4. All have similar problems.

I currently have Linux host and Windows 7 host. Try to deploy on Windows 7 guest. Someone told me to start from a masterless minion.

Shall I start from a windows mater or Linux master? Salt windows standalone mode seems is not well supported yet. Or have to wait for a few months till Salt has stable version for windows masterless mode? Please suggest.

twangboy commented 9 years ago

It looks like thw software defs arent there. In 2015.8 have you pulled down software defs? Have you run pkg.refresh_db?

liyingbo commented 9 years ago

I am currently working with V2015.5.4. I switched from V2015.8.0.xxx to V2015.5.5, then to V2015.5.4. After I downloaded and installed a pygit2, it became this. But "salt-call --local state.highstate -l debug" always has problem.

C:\salt>salt-call pkg.refresh_db (this cmd works before) [ERROR ] No suitable version of pygit2/libgit2, GitPython, or Dulwich is installed. local: True

salt-call: error: no such option: --version-report

C:\salt>salt-call --versions-report Salt: 2015.5.4 Python: 2.7.8 (default, Jun 30 2014, 16:08:48) [MSC v.1500 64 bit (AMD64)] Jinja2: 2.7.3 M2Crypto: 0.21.1 msgpack-python: 0.4.5 msgpack-pure: Not Installed pycrypto: 2.6.1 libnacl: Not Installed PyYAML: 3.10 ioflo: Not Installed PyZMQ: 2.1.10 RAET: Not Installed ZMQ: 2.1.10 Mako: Not Installed Tornado: 4.2.1 timelib: Not Installed

Here is my minion file:

Primary configuration settings

##########################################

ipc_mode: tcp

Per default the minion will automatically include all config files

from minion.d/*.conf (minion.d is a directory in the same directory

as the main minion config file).

default_include: minion.d/*.conf

Set the location of the salt master server, if the master server cannot be

resolved, then the minion will fail to start.

test

master: salt

Set the number of seconds to wait before attempting to resolve

the master hostname if name resolution fails. Defaults to 30 seconds.

Set to zero if the minion should shutdown and not retry.

retry_dns: 30

Set the port used by the master reply and authentication server

master_port: 4506

The user to run salt

user: root

Specify the location of the daemon process ID file

pidfile: /var/run/salt-minion.pid

The root directory prepended to these options: pki_dir, cachedir, log_file,

sock_dir, pidfile.

root_dir: c:\salt

The directory to store the pki information in

pki_dir: /etc/salt/pki/minion

pki_dir: /conf/pki/minion

Explicitly declare the id for this minion to use, if left commented the id

will be the hostname as returned by the python call: socket.getfqdn()

Since salt uses detached ids it is possible to run multiple minions on the

same machine but with different ids, this can be useful for salt compute

clusters.

id: myteamcity

Append a domain to a hostname in the event that it does not exist. This is

useful for systems where socket.getfqdn() does not actually result in a

FQDN (for instance, Solaris).

append_domain:

Custom static grains for this minion can be specified here and used in SLS

files just like all other grains. This example sets 4 custom grains, with

the 'roles' grain having two values that can be matched against:

grains:

roles:

- webserver

- memcache

deployment: datacenter4

cabinet: 13

cab_u: 14-15

Where cache data goes

cachedir: /var/cache/salt/minion

Verify and set permissions on configuration directories at startup

verify_env: True

The minion can locally cache the return data from jobs sent to it, this

can be a good way to keep track of jobs the minion has executed

(on the minion side). By default this feature is disabled, to enable

set cache_jobs to True

cache_jobs: False

set the directory used to hold unix sockets

sock_dir: /var/run/salt/minion

Backup files that are replaced by file.managed and file.recurse under

'cachedir'/file_backups relative to their original location and appended

with a timestamp. The only valid setting is "minion". Disabled by default.

#

Alternatively this can be specified for each file in state files:

#

/etc/ssh/sshd_config:

file.managed:

- source: salt://ssh/sshd_config

- backup: minion

#

backup_mode: minion

When waiting for a master to accept the minion's public key, salt will

continuously attempt to reconnect until successful. This is the time, in

seconds, between those reconnection attempts.

acceptance_wait_time: 10

If this is set, the time between reconnection attempts will increase by

acceptance_wait_time seconds per iteration, up to this maximum. If this

is not set, the time between reconnection attempts will stay constant.

acceptance_wait_time_max: None

Windows platforms lack posix IPC and must rely on slower TCP based inter-

process communications. Set ipc_mode to 'tcp' on such systems

ipc_mode: ipc

#

Overwrite the default tcp ports used by the minion when in tcp mode

tcp_pub_port: 4510

tcp_pull_port: 4511

The minion can include configuration from other files. To enable this,

pass a list of paths to this option. The paths can be either relative or

absolute; if relative, they are considered to be relative to the directory

the main minion configuration file lives in (this file). Paths can make use

of shell-style globbing. If no files are matched by a path passed to this

option then the minion will log a warning message.

# #

Include a config file from some other path:

include: /etc/salt/extra_config

#

Include config from several files and directories:

include:

- /etc/salt/extra_config

- /etc/roles/webserver

Minion module management

##########################################

Disable specific modules. This allows the admin to limit the level of

access the master has to the minion

disable_modules: [cmd,test]

disable_returners: []

#

Modules can be loaded from arbitrary paths. This enables the easy deployment

of third party modules. Modules for returners and minions can be loaded.

Specify a list of extra directories to search for minion modules and

returners. These paths must be fully qualified!

module_dirs: []

returner_dirs: []

states_dirs: []

render_dirs: []

#

A module provider can be statically overwritten or extended for the minion

via the providers option, in this case the default module will be

overwritten by the specified module. In this example the pkg module will

be provided by the yumpkg5 module instead of the system default.

#

providers:

pkg: yumpkg5

#

Enable Cython modules searching and loading. (Default: False)

cython_enable: False

#

State Management Settings

###########################################

The state management system executes all of the state templates on the minion

to enable more granular control of system state management. The type of

template and serialization used for state management needs to be configured

on the minion, the default renderer is yaml_jinja. This is a yaml file

rendered from a jinja template, the available options are:

yaml_jinja

yaml_mako

yaml_wempy

json_jinja

json_mako

json_wempy

#

renderer: yaml_jinja

#

The failhard option tells the minions to stop immediately after the first

failure detected in the state execution, defaults to False

failhard: False

#

autoload_dynamic_modules Turns on automatic loading of modules found in the

environments on the master. This is turned on by default, to turn of

autoloading modules when states run set this value to False

autoload_dynamic_modules: True

#

clean_dynamic_modules keeps the dynamic modules on the minion in sync with

the dynamic modules on the master, this means that if a dynamic module is

not on the master it will be deleted from the minion. By default this is

enabled and can be disabled by changing this value to False

clean_dynamic_modules: True

#

Normally the minion is not isolated to any single environment on the master

when running states, but the environment can be isolated on the minion side

by statically setting it. Remember that the recommended way to manage

environments is to isolate via the top file.

environment: None

#

If using the local file directory, then the state top file name needs to be

defined, by default this is top.sls.

state_top: top.sls

#

Run states when the minion daemon starts. To enable, set startup_states to:

'highstate' -- Execute state.highstate

'sls' -- Read in the sls_list option and execute the named sls files

'top' -- Read top_file option and execute based on that file on the Master

startup_states: ''

#

list of states to run when the minion starts up if startup_states is 'sls'

sls_list:

- edit.vim

- hyper

#

top file to execute if startup_states is 'top'

top_file: ''

top_file: 'C:\salt\file_roots\top.sls'

File Directory Settings

##########################################

The Salt Minion can redirect all file server operations to a local directory,

this allows for the same state tree that is on the master to be used if

copied completely onto the minion. This is a literal copy of the settings on

the master but used to reference a local directory on the minion.

Set the file client, the client defaults to looking on the master server for

files, but can be directed to look at the local file directory setting

defined below by setting it to local.

file_client: remote

The file directory works on environments passed to the minion, each environment

can have multiple root directories, the subdirectories in the multiple file

roots cannot match, otherwise the downloaded files will not be able to be

reliably ensured. A base environment is required to house the top file.

Example:

file_roots:

base:

- /srv/salt/

dev:

- /srv/salt/dev/services

- /srv/salt/dev/states

prod:

- /srv/salt/prod/services

- /srv/salt/prod/states

#

Default:

file_roots:

base:

- /srv/salt

file_roots: base:

The hash_type is the hash to use when discovering the hash of a file in

the minion directory, the default is md5, but sha1, sha224, sha256, sha384

and sha512 are also supported.

hash_type: md5

The Salt pillar is searched for locally if file_client is set to local. If

this is the case, and pillar data is defined, then the pillar_roots need to

also be configured on the minion:

pillar_roots:

base:

- /srv/pillar

Security settings

###########################################

Enable "open mode", this mode still maintains encryption, but turns off

authentication, this is only intended for highly secure environments or for

the situation where your keys end up in a bad state. If you run in open mode

you do so at your own risk!

open_mode: False

Enable permissive access to the salt keys. This allows you to run the

master or minion as root, but have a non-root group be given access to

your pki_dir. To make the access explicit, root must belong to the group

you've given access to. This is potentially quite insecure.

permissive_pki_access: False

The state_verbose and state_output settings can be used to change the way

state system data is printed to the display. By default all data is printed.

The state_verbose setting can be set to True or False, when set to False

all data that has a result of True and no changes will be suppressed.

state_verbose: True

#

The state_output setting changes if the output is the full multi line

output for each changed state if set to 'full', but if set to 'terse'

the output will be shortened to a single line.

state_output: full

#

Fingerprint of the master public key to double verify the master is valid,

the master fingerprint can be found by running "salt-key -F master" on the

salt master.

master_finger: ''

Thread settings

###########################################

Disable multiprocessing support, by default when a minion receives a

publication a new process is spawned and the command is executed therein.

multiprocessing: True

Logging settings

###########################################

The location of the minion log file.

This can be a path for the log file, or, this can be, since 0.11.0, a system

logger address, for example:

tcp://localhost:514/LOG_USER

tcp://localhost/LOG_DAEMON

udp://localhost:5145/LOG_KERN

udp://localhost

file:///dev/log

file:///dev/log/LOG_SYSLOG

file:///dev/log/LOG_DAEMON

#

The above examples are self explanatory, but:

<file|udp|tcp>://<host|socketpath>:/

#

Make sure you have a properly configured syslog or you won't get any warnings

#

log_file: /var/log/salt/minion

# #

The level of messages to send to the console.

One of 'garbage', 'trace', 'debug', info', 'warning', 'error', 'critical'.

Default: 'warning'

log_level: warning

#

The level of messages to send to the log file.

One of 'garbage', 'trace', 'debug', info', 'warning', 'error', 'critical'.

Default: 'warning'

log_level_logfile:

#

The date and time format used in log messages. Allowed date/time formating

can be seen on http://docs.python.org/library/time.html#time.strftime

log_datefmt: '%H:%M:%S'

log_datefmt_logfile: '%Y-%m-%d %H:%M:%S'

#

The format of the console logging messages. Allowed formatting options can

be seen on http://docs.python.org/library/logging.html#logrecord-attributes

log_fmt_console: '[%(levelname)-8s] %(message)s'

log_fmt_logfile: '%(asctime)s,%(msecs)03.0f [%(name)-17s][%(levelname)-8s] %(message)s'

#

Logger levels can be used to tweak specific loggers logging levels.

For example, if you want to have the salt library at the 'warning' level,

but you still wish to have 'salt.modules' at the 'debug' level:

log_granular_levels: {

'salt': 'warning',

'salt.modules': 'debug'

}

#

log_granular_levels: {}

Module configuration

###########################################

Salt allows for modules to be passed arbitrary configuration data, any data

passed here in valid yaml format will be passed on to the salt minion modules

for use. It is STRONGLY recommended that a naming convention be used in which

the module name is followed by a . and then the value. Also, all top level

data must be applied via the yaml dict construct, some examples:

#

You can specify that all modules should run in test mode:

test: True

#

A simple value for the test module:

test.foo: foo

#

A list for the test module:

test.bar: [baz,quo]

#

A dict for the test module:

test.baz: {spam: sausage, cheese: bread}

Update settings

###########################################

Using the features in Esky, a salt minion can both run as a frozen app and

be updated on the fly. These options control how the update process

(saltutil.update()) behaves.

#

The url for finding and downloading updates. Disabled by default.

update_url: False

#

The list of services to restart after a successful update. Empty by default.

update_restart_services: []

Keepalive settings

############################################

ZeroMQ now includes support for configuring SO_KEEPALIVE if supported by

the OS. If connections between the minion and the master pass through

a state tracking device such as a firewall or VPN gateway, there is

the risk that it could tear down the connection the master and minion

without informing either party that their connection has been taken away.

Enabling TCP Keepalives prevents this from happening.

#

Overall state of TCP Keepalives, enable (1 or True), disable (0 or False)

or leave to the OS defaults (-1), on Linux, typically disabled. Default True, enabled.

tcp_keepalive: True

#

How long before the first keepalive should be sent in seconds. Default 300

to send the first keepalive after 5 minutes, OS default (-1) is typically 7200 seconds

on Linux see /proc/sys/net/ipv4/tcp_keepalive_time.

tcp_keepalive_idle: 300

#

How many lost probes are needed to consider the connection lost. Default -1

to use OS defaults, typically 9 on Linux, see /proc/sys/net/ipv4/tcp_keepalive_probes.

tcp_keepalive_cnt: -1

#

How often, in seconds, to send keepalives after the first one. Default -1 to

use OS defaults, typically 75 seconds on Linux, see

/proc/sys/net/ipv4/tcp_keepalive_intvl.

tcp_keepalive_intvl: -1

Windows Software settings

############################################

Location of the repository cache file on the master

win_repo_cachefile: 'salt://win/repo/winrepo.p'

file_client: local win_repo_cachefile: 'c:\salt\srv\win\repo\winrepo.p' win_repo: 'c:\salt\srv\win\repo\' win_gitrepos:

fileserver_backend:

gitfs_remotes:

liyingbo commented 9 years ago

comment out a few lines in minion:

fileserver_backend:

•roots

•git

gitfs_remotes:

•https://github.com/saltstack-formulas/epel-formula.git

•https://github.com/saltstack-formulas/nginx-formula.git

then, it works better: C:\salt>salt-call pkg.refresh_db local: True

C:\salt>salt-call --local state.highstate -l debug [DEBUG ] Reading configuration from c:\salt\conf\minion [DEBUG ] Configuration file path: c:\salt\conf\minion [DEBUG ] Reading configuration from c:\salt\conf\minion [DEBUG ] LazyLoaded jinja.render [DEBUG ] LazyLoaded yaml.render [DEBUG ] LazyLoaded jinja.render [DEBUG ] LazyLoaded yaml.render [DEBUG ] LazyLoaded state.highstate [DEBUG ] LazyLoaded grains.get [DEBUG ] LazyLoaded saltutil.isrunning [DEBUG ] LazyLoaded roots.envs [DEBUG ] Could not LazyLoad roots.init [DEBUG ] Updating roots fileserver cache [DEBUG ] Reading configuration from c:\salt\conf\minion [DEBUG ] LazyLoaded jinja.render [DEBUG ] LazyLoaded yaml.render [INFO ] Loading fresh modules for state activity [DEBUG ] LazyLoaded jinja.render [DEBUG ] LazyLoaded yaml.render [INFO ] Fetching file from saltenv 'base', * skipped * latest already in cache 'salt://top.sls' [DEBUG ] Jinja search path: ['c:\salt\var\cache\salt\minion\files\base'] [DEBUG ] Rendered data from file: c:\salt\var\cache\salt\minion\files\base\top.sls: base: '':

local:

      ID: nginx
Function: pkg.installed
  Result: False
 Comment: Package nginx not found in the repository.
 Started: 16:26:11.237000
Duration: 12.0 ms
 Changes:
      ID: winscp
Function: pkg.installed
  Result: False
 Comment: Package winscp not found in the repository.
 Started: 16:26:11.250000
Duration: 10.0 ms
 Changes:

Summary

Succeeded: 0

Failed: 2

Total states run: 2

C:\salt>salt-call winrepo.genrepo {} local:

C:\salt>salt-call --versions-report Salt: 2015.5.4 Python: 2.7.8 (default, Jun 30 2014, 16:08:48) [MSC v.1500 64 bit (AMD64)] Jinja2: 2.7.3 M2Crypto: 0.21.1 msgpack-python: 0.4.5 msgpack-pure: Not Installed pycrypto: 2.6.1 libnacl: Not Installed PyYAML: 3.10 ioflo: Not Installed PyZMQ: 2.1.10 RAET: Not Installed ZMQ: 2.1.10 Mako: Not Installed Tornado: 4.2.1 timelib: Not Installed

C:\salt>

What is the problem of my current configuration?

Please help! Thanks!