常见问题¶

Salt 是只开放核心源码的吗？¶

No. Salt is 100% committed to being open-source, including all of our APIs. It is developed under the Apache 2.0 license, allowing it to be used in both open and proprietary projects.

I think I found a bug! What should I do?¶

The salt-users mailing list as well as the salt IRC channel can both be helpful resources to confirm if others are seeing the issue and to assist with immediate debugging.

To report a bug to the Salt project, please follow the instructions in reporting a bug.

我需要在防火墙上开放哪些端口？¶

Minions需要通过TCP端口4505和4506与Master进行通讯。此外，Minions并不需要开放额外的端口来接受数据。关于防火墙设置的更多细节你可以点击 这里。

我看到了一些怪异的行为(包括但不局限在安装包不能正确的安装他们的用户权限)¶

这通常是由SELinux引起的。尝试禁用SElinux或者切换到permissive模式，然后看看是否这些怪异的表现消失了。

当我运行 state.highstate 命令时，为什么我的脚本每次都会执行？¶

在编写state时，你可能用的是 cmd.run ，而不是 cmd.wait 。只有当监视对象的状态发生了变化时， cmd.wait state才会执行。

而 cmd.run state 每次 都会执行，(除非它不满足 unless 或者 onlyif 参数时才不会执行)。

更多信息可以在文档中的 cmd states 找到。

当我运行 test.ping 时, 为什么Minions没有返回任何结果？返回``False``比这有用多了。¶

当你运行 test.ping 时，Master告诉Minions执行相应的命令或函数，Minion等待接受返回的结果，一旦有返回结果便会输出在屏幕上。如果Minion没有接受到任何返回数据，它将什么也不显示。

为了应对这种Minions无响应的情况，这里有两种方法。一个就是详细输出选项 (-v) ，当Minions运行命令超时无返回结果时会显示"Minion did not return"。

salt -v '*' pkg.install zsh

另一个方法是用 manage.down runner:

salt-run manage.down

另外，如果Master在高负载下，可能CLI会在没有展示任何目标Minions的返回数据时就退出了。然而，这并不意味着Minions没有返回; 这仅仅意味着Salt CLI等待响应超时了。一旦作业完成，Minions仍然返回他们的数据返回给Master。如果从CLI输出中缺少任何预期的Minions， jobs.list_jobs runner可以用来显示作业的IDs表示作业已经运行, 并且 jobs.lookup_jid runner可以用来得到那个作业的返回数据。

salt-run jobs.list_jobs
salt-run jobs.lookup_jid 20130916125524463507

如果你发现在CLI经常丢失Minion的返回数据，只能在作业的runners找到，那么这可能是一个迹象表明在master配置文件中 worker_threads 的值需要升高。另外，运行你的Salt CLI命令行使用 -t 选项，将会使Salt等待返回数据的时间更长。例如，下面的命令将会等待Minions返回的时间多达60秒:

salt -t 60 '*' test.ping

Salt默认的Minion id是怎么样生成的?¶

如果Minion id并没有明确的配置(使用 id 参数配置)，Salt将使用主机名作为缺省的id。 究竟Salt是如何精确地在各种操作系统上来命名缺省id，详细描述 请点这里。

我尝试通过Salt管理软件包和服务，为什么我得到了一个the state is not available的错误输出？¶

Salt会自动检测Minion的操作系统并安装正确的软件包或服务管理模块。但是，对于一些社区的custom spins OS和衍生操作系统，这些检测很容易失败。在这种情况下，你可以向我们的 tracker 提交issue，其中包含以下信息：

1. 以下命令的输出信息：

   salt <minion_id> grains.items | grep os
   

2. 如果在Minion上存在文件 /etc/lsb-release ，贴出这个文件的内容。

为什么我自定义的modules/states/等在Minions上不可用？¶

只有当 state.highstate， saltutil.sync_modules ， 或者 saltutil.sync_all 执行时用户自定义的模块才会同步。 同样， 只有当 state.highstate, saltutil.sync_states ， 或 saltutil.sync_all 执行时自定义的states才会同步。

其他的自定义类型 (renderers, outputters等) 也类似， 关于 saltutil 模块的更多内容请查看文档。

即使已经安装了相应模块，为什么仍然会提示module X isn't available？¶

这很可能是PATH问题。你是自己编译模块的依赖么？RHEL/CentOS等，会特别覆盖root用户的path在``/etc/init.d/functions``文件中，将其设置为``/sbin:/user/sbin:/bin:/usr/bin``，使得banian安装到``/usr/local/bin``，当Salt通过使用initscript启动时是不可用的。在版本2014.1.0, Salt将会有一个与PATH相关的更好的解决方案，但是目前重编译软件并安装到在PATH中的路径应该同样能解决这个问题。可选地，你可以使用一个:mod:file.symlink <salt.states.file.symlink> state创建一个软连接到PATH中的路径。

/usr/bin/foo:
  file.symlink:
    - target: /usr/local/bin/foo

我可以运行不同版本的Salt在Master端和Minion端吗？¶

这个依赖于版本。通常情况下，建议Master和Minion版本匹配。

当升级Salt的时候，master(s)应该首先升级。masters向后兼容，minions运行版本比masters版本新是不能保证运行正常的。

只要可能，新masters向后兼容旧minions的特性就会被保留下来。一般来说，唯一例外的情况是有安全漏洞的情况下。

最近一个破坏向后兼容性的例子包含0.17.1版本(因为修复了一个安全性问题被修复，所有向后兼容性被破坏)，和2014.1.0版本(保留2014.1.0 masters和0.17 minions之间的兼容性，但是破坏了2014.1.0 minions和老版本masters之间的兼容性)。

Salt是否支持备份文件管理？¶

是的。Salt提供一个非常易用的flie.managed states，允许你通过 backup_mode 备份文件, backup_mode可以配置在每个state的底层，或者在minion配置中(注意如果设置在minion配置中仅仅说明默认方法被启用，你仍然需要指定需要备份的文件!).

Is it possible to deploy a file to a specific minion, without other minions having access to it?¶

The Salt fileserver does not yet support access control, but it is still possible to do this. As of Salt 2015.5.0, the file_tree external pillar is available, and allows the contents of a file to be loaded as Pillar data. This external pillar is capable of assigning Pillar values both to individual minions, and to nodegroups. See the documentation for details on how to set this up.

Once the external pillar has been set up, the data can be pushed to a minion via a file.managed state, using the contents_pillar argument:

/etc/my_super_secret_file:
  file.managed:
    - user: secret
    - group: secret
    - mode: 600
    - contents_pillar: secret_files:my_super_secret_file

In this example, the source file would be located in a directory called secret_files underneath the file_tree path for the minion. The syntax for specifying the pillar variable is the same one used for pillar.get, with a colon representing a nested dictionary.

使用Salt重启Salt守护进程的最佳方式是什么？¶

Updating the salt-minion package requires a restart of the salt-minion service. But restarting the service while in the middle of a state run interrupts the process of the minion running states and sending results back to the master. It's a tricky problem to solve, and we're working on it, but in the meantime one way of handling this (on Linux and UNIX-based operating systems) is to use at (a job scheduler which predates cron) to schedule a restart of the service. at is not installed by default on most distros, and requires a service to be running (usually called atd) in order to schedule jobs. Here's an example of how to upgrade the salt-minion package at the end of a Salt run, and schedule a service restart for one minute after the package update completes.

salt-minion:
  pkg.installed:
    - name: salt-minion
    - version: 2014.1.7-3.el6
    - order: last
  service.running:
    - name: salt-minion
    - require:
      - pkg: salt-minion
  cmd.wait:
    - name: echo service salt-minion restart | at now + 1 minute
    - watch:
      - pkg: salt-minion

at:
  pkg.installed:
    - name: at
  service.running:
    - name: atd
    - enable: True

restart_minion:
  cmd.run:
    - name: |
        exec 0>&- # close stdin
        exec 1>&- # close stdout
        exec 2>&- # close stderr
        nohup /bin/sh -c 'sleep 10 && salt-call --local service.restart salt-minion' &
    - python_shell: True
    - order: last

schedule-start:
  cmd.run:
    - name: 'start powershell "Restart-Service -Name salt-minion"'
    - order: last

salt -G kernel:Windows cmd.run 'start powershell "Restart-Service -Name salt-minion"'

Salting Salt Master¶

为了通过states配置一个master server，Salt master同样可以被"salted"，可以像Salt mininons一样在Salt master执行state。Salting the Salt master需要在Salt master同一机器上安装Salt minion。一旦Salt minion安装完毕，minion配置文件必须指向本地Salt master:

master: 127.0.0.1

一旦Salt master已经用一个Salt minion "salted"过了，就可以想其他minion一样作为目标。如果minion在salted master运行中，该minion可以通过任何平时的 salt 命令作为目标。此外， salt-call 命令可以执行state操作在salted master，无需minion运行。

更多关于salting the Salt master的信息可以在salt-formula找到:

https://github.com/saltstack-formulas/salt-formula

Is Targeting using Grain Data Secure?¶

Because grains can be set by users that have access to the minion configuration files on the local system, grains are considered less secure than other identifiers in Salt. Use caution when targeting sensitive operations or setting pillar values based on grain data.

When possible, you should target sensitive operations and data using the Minion ID. If the Minion ID of a system changes, the Salt Minion's public key must be re-accepted by an administrator on the Salt Master, making it less vulnerable to impersonation attacks.