salt-minion,salt-master,multi master

入门虾扯淡，利用salt批量修改salt-minion的配置文件，前提条件客户端已经安装好salt-minion，并且已经和salt-master认证上

在salt里面大致可以分为这样几个部件：state、grains、pillar、modules、returners、schedule

state：
salt基于minon的状态管理，state系统的核心文件是sls文件，他们代表的是系统当前应该所处的某个状态，这些状态信息按照一个简单的格式来定义，在对客户端进行state状态管理时，salt-minon会按照这些sls文件中定义的状态对当前系统进行一致性的设置

grains：
这个单词我是真的不知道怎么读，它就好比是salt的一个接口，里面封装了获取系统相关硬软件的配置信息属性，而你也可以通过这个grains自定义赋予一些其他的属性，这些信息都是在salt-minion启动的时候被赋予的，除非你去手动的刷新重新获取，所以说grains是保留一些静态的属性信息，没有刷新或者重新启动是不会被改变的；举个例子来理解：就好比你入职一个公司，你的公司名是：A，你的职位名是：B，你的职责是：C，你的工资是：D ；这些信息在你入职之后是被赋予的，假如你职位变动了或者你跳槽了，以上的一些信息就会发生一次改变，而这个职位变动或者跳槽就可以理解为“手动刷新或者重新启动”

pillar：
这个单词读起来同样拗口，这个东东呢也是saltstack部署中的重要组件之一，它是对特定的minion生成特定数据的接口，这些数据包含：敏感信息的数据、salt-minion的配置信息、通过模板文件定义或者其他sls文件定义的变量的引用、其他自定义的任意数据信息。而这些信息都是被匹配到的节点才能拥有或者使用

乱扯了一大堆，贴贴代码：

1、安装master，minion
Master：

rpm -ivh http://mirrors.sohu.com/fedora-epel/5/x86_64/epel-release-5-4.noarch.rpm

yum install salt-master -y

Minion：

rpm -ivh http://mirrors.sohu.com/fedora-epel/5/x86_64/epel-release-5-4.noarch.rpm

yum install salt-minion -y

2、修改minion配置文件，指定master

vim /etc/salt/minion

SaltStack学习笔记（一）利用salt修改salt-minion配置文件

3、配置master，自动接受认证

vim /etc/salt/master

SaltStack学习笔记（一）利用salt修改salt-minion配置文件

/etc/init.d/salt-master start

/etc/init.d/salt-minion start

SaltStack学习笔记（一）利用salt修改salt-minion配置文件

4、当在管理上百台机器的时候，假如需要修改minon的某个参数时，可以使用如下方法（只是举例）
修改minion配置文件中的id的参数，每台机器我用IP作为minion的id的值。

编写一个入口文件top.sls：

SaltStack学习笔记（一）利用salt修改salt-minion配置文件

第一行： 固定写法，必须的
第二行: 匹配minion
第三行： 匹配到的minion，将会按照这个状态管理文件salt-agent.sls中定义的内容去进行状态管理

编写状态管理文件salt-agent.sls (这个名字根据入口文件中自行DIY)：

SaltStack学习笔记（一）利用salt修改salt-minion配置文件

第一行：你懂得，自己DIY，标示而已
第二行：salt自带的文件管理
第三行：文件管理的模板文件，这个路径指的是Master上的：/srv/salt/salt-agent/minion salt://等价于/srv/salt
第四行：要管理的目标文件
第五行：指明这个source是个jinja类型的模板
第六行：salt自带的等待执行的命令
第七行：要执行的命令
第八行：salt里面的监视器
第九行：监视的目标

这个文件处理的流程：1.用salt://salt-agent/minion去修改/etc/salt/minion中的内容 —> 2.监视/etc/salt/minion文件，如果这个文件发生变化 —> 3.执行service salt-minion restart命令

我操，啰嗦的太多了

来看看salt://salt-agent/minion这个模板文件，其实我只是修改了默认配置文件中的这一行内容，当然matser那项的配置要和上面修改的保持一致，不然待会就认证不上了：

SaltStack学习笔记（一）利用salt修改salt-minion配置文件

这个id的值来自于当前minion的grains中的tag这个属性的值。tag这个属性的值默认是没有的，这里可以自定义对其进行赋予，看代码

_grains/minion-conf.py 目录必须这名字“_grains”，python脚本名字还是你懂得DIY吧

SaltStack学习笔记（一）利用salt修改salt-minion配置文件

一切准备妥当，如果你的/srv/结构类似于下面的样子，就可以开始同步grains信息，执行以下命令

SaltStack学习笔记（一）利用salt修改salt-minion配置文件 SaltStack学习笔记（一）利用salt修改salt-minion配置文件

执行命令，查看minion所具有的属性：salt ‘games’ grains.items

SaltStack学习笔记（一）利用salt修改salt-minion配置文件

OK，现在万事具备，只需要对改minion进行状态管理了，走起

SaltStack学习笔记（一）利用salt修改salt-minion配置文件

在执行了 salt ‘games’ state.highstate 对games进行了状态管理，由于minion被重启，而且id被修改，所以此时被当做另外一台机器认证到了master上，所以没有任何返回，在下面进行了 salt ‘games’ test.ping 也验证了这点，此时games节点的id被修改为图中 202-73的那台机器，所以名为games的key就可以删除了。

啰啰嗦嗦一大堆，笨嘴笨嘴啊

==============

如何使用salt states快速的配置一个系统。

本文将指导完成使用salt来配置一个minion运行apache http服务器并且使这个服务正确的运行。

在往下面进行之前，请确保你的salt已经安装并且已经工作。

Setting up the salt sate tree
states以文本文件的形式存储在master上，并且按照需求通过master的文件服务器传输给minions。state文件的集合构成了state tree

在使用salt时必须为其至少设置一个所谓的中央系统也就是state tree的第一个顶级点。编辑master的配置文件将以下行取消注释：

1
2
3
file_roots:
base:
-/srv/salt
Note：如果你在部署FreeBSD的操作系统，这个 file_roots参数默认值为：/usr/local/etc/salt/states

重启salt master使这个配置改变生效：

1
2
pkill salt-master
salt-master-d
Preparing the top file
在master上，上一步中的目录并没有被创建，(默认/srv/salt)，创建一个名为top.sls文件，并添加一下内容：

1
2
3
base:
'’:
-webserver
这个top.sls文件是用来分隔环境的。默认环境是base，在base的环境集合定义了对minions的匹配，可以使用简单的来指定所有的主机。

目标minions
salt可以通过glob、pcre正则表达式，或者通过grains来进行匹配任何的目标机器，例如：

1
2
3
4
base:
‘os:Fedora’:
-match:grain
-webserver
Create an sls module
在top.sls相同的目录下，创建一个名为webserver.sls的空文件，内容如下：

1
2
3
apache: # ID的声明
pkg： # state类型的声明
-installed # state中的函数声明
第一行，是对全局ID的声明，可以是任意的标识符，在这种情况下，使用需要被安装的软件包的包名来定义。

Note:对于apache httpd web服务器的包名取决于操作系统的发行版，例如，在Fedora是httpd，但在Debian/Ubuntu是apache2

第二行，是对state的声明，定义了我们所要十一on个的salt states，在这个例子中，我们使用pkg state以确保一个给定的包被正确安装。
第三行，称为函数的声明，这个函数被定义在pkg state这个模块中。

Renderers渲染器
states的sls文件可以写成很多格式，salt只依赖于很简单的数据结构，并且不关心这些数据结构的建立，模版语言和DSLs到处都有，每个人都喜欢。
建立数据结构可以很简单的编写预期的任务，在本文中我们在jinja2的模版中使用YAML，这也是默认的格式。可以在master配置文件中修改默认渲染器

Install the package
接下来运行我们创建的state,在master上打开一个终端并且运行一下命令：

1
%salt’*'state.highstate
master将会指导所有的目标minions运行 state.highstate。当minion执行highstate，它将会下载top文件中匹配的内容，minion将表达式中匹配的内容下载、编译、执行。
一旦完成，minion将返回所有的动作执行结果和所有更改

1
2
3
4
5
6
7
8
SLS FileNamespace(sls文件名称空间)
这个例子中，这个webserver.sls文件可以简单的写作webserver。这个sls文件名称空间遵循一些简单的规则：
1.这个.sls可以被省略，例如webserver.sls可以被称谓webserver
2.子目录可以更好的组织.
a.每个子目录都代表一个点
b.webserver/dev.sls可以写作webserver.dev
3.在子目录的存在一个名为init.sls文件，所以webserver/init.sls也可以简写为webserver
4.如果webserver.sls和webserver/init.sls同时存在，那么webserver/init.sls将会被忽略，并且webserver.sls将会被成为webserver

Troubleshooting Salt
如果输出的内容不是你所预期的，以下的建议可以帮助你缩小问题。

启用日志记录
当你启用日志的debug模式，salt输出的信息将会很全

1
salt-minion-ldebug

前台运行minion
不使用daemon模式(-d)启动minion,可以从输出看到其工作的任何细节

1
salt-minion&
增加salt运行的默认超时时间，例如，修改默认超时时间为60s：

1
salt-t60
为了更好的达到这三个效果：

1
2
salt-minion-ldebug& # 在minion上运行
salt’*'state.highstate-t60 # 在master上运行

参考文档：http://docs.saltstack.com/topics/tutorials/states_pt1.html

===============

如何使用salt state快速进行系统配置(一)
Call multiple states
你可以在一个声明的ID下面定义多个state语句，例如，我们可以快速的修改webserver.sls，并且如果apache没有运行将其启动。

1
2
3
4
5
6
7
apache:
pkg:
-installed
service:
-running
-require:
-pkg:apache

在运行state.highstate之前，尝试停止apache，并且再次观察其输出内容。

Expand the sls module
正如你所见，sls模块以.sls附加为文件扩展名并且从state的根下开始引用，同一个sls模块可以同时定义在一个目录。现在通过创建一个名为webserver的目录，并且将webserver.sls移动并且重命名到webserver/init.sls，你的state目录结构应该像下面这样：

1
2
3
|-top.sls
-webserver/-init.sls

组织sls模块
你可以将其他的.sls文件放置到state文件目录。这样的组织使你的state树在文件系统上显的更加简洁，例如：如果我们创建了一个webserver/django.sls文件，那么我们可以这样来引用它 webserver.django
此外，state提供了强大的扩展功能，详情请阅读：

如何使用salt states快速进行系统配置(三)
Require other states
现在我们已经安装了apache，并且处于工作状态，让我们添加一个HTML文件来定制我们的网站。但是如果没有webserver，它将不是一个有用的网站，所以除非apache已经安装并且运行否则我们不希望salt来安装这些HTML文件。像下面内容一样，将其包含在你的webserver/init.sls：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
apache:
pkg:
-installed
service:
-running
-require:
-pkg:apache

/var/www/index.html: # 声明一个ID
file: # 声明state
-managed # state中的函数名
-source:salt://webserver/index.html # 函数的参数
-require: # 声明requisite
-pkg:apache # requisite的引用

第九行声明一个新的ID，在这个例子中它是我们自定义的HTML文件要安装的位置(Note：在不同的操作系统或发行版上apache服务的默认位置可能不同，/srv/www也可能是个好位置。)
第十行声明使用的state。
第十一行声明使用第十行中的state的函数名。这个managed函数将从master上下载文件，并且按照指定的位置进行安装。
第十二行是函数的参数，在本例中利用managed函数中的source参数，指定需要从master上下载的文件的路径和名称
第十三行是require的声明
第十四行是require所要引用的state 和 ID，在这个例子它值的例子开头处的那个ID，这个声明告诉salt在不安装apache之前不要安装HTML文件

接下来，创建index.html文件，并且保存在webserver目录下：

1
2
3
4
5
6

This filebrought to you by Salt

最后，在调用一次state.highstate，minion将获取和执行highstate以及从master的文件服务器上获取我们的HTML文件

1
salt’*'state.highstate

现在验证apache中你自定义的HTML吧！

require VS watch
现在有两个依赖的声明，“require和watch”，不是所有的state都支持”watch”。service state不支持”watch”并且不支持通过观察一个条件进行重新启动一个服务

例如，如果你使用salt配置安装apache的虚拟主机，当配置文件发送改变时要重启apache，你可以修改之前的例子：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
/etc/httpd/extra/httpd-vhosts.conf:
file:
-managed
-source:salt://webserver/httpd-vhosts.conf

apache:
pkg:
-installed
service:
-running
-watch:
-file:/etc/httpd/extra/httpd-vhosts.conf
-require:
-pkg:apache
如果在不同的操作系统或者发行版上pkg和service的名称不通，你可以单独声明一个名字，详细配置请阅读：

参考：http://docs.saltstack.com/topics/tutorials/states_pt2.html

===============================

Templating sls modules
sls模块内联执行可能依赖于你的编程逻辑。默认的模板使用jinja2模板系统作为渲染器，可以通过修改主配置文件master来改变渲染器的配置

所有的state都通过一个模板系统完成最初的读取，使用模板系统，只需要添加一个模板标记，一个使用模板标记的sls例子：

1
2
3
4
{%forusr in[‘moe’,‘larry’,‘curly’]%}
{ {usr}}:
user.present
{%endfor%}
这个使用了模板的sls文件生成后结果如下：

1
2
3
4
5
6
moe:
user.present
larry:
user.present
curly:
user.present
下面这个是一个更复杂的例子：

1
2
3
4
5
6
7
8
9
10
{%forusr in’moe’,‘larry’,‘curly’%}
{ {usr}}:
group:
-present
user:
-present
-gid_from_name:True
-require:
-group:{ {usr}}
{%endfor%}
Using grains in sls modules
通常情况下state在不同的系统有不同的表现。grains的信息也可以在sls模板文件中使用，例如，可以这样用：

1
2
3
4
5
6
7
apache:
pkg.installed:
{%ifgrains[‘os’]‘RedHat’%}
-name:httpd
{%elifgrains[‘os’]‘Ubuntu’%}
-name:apache2
{%endif%}

Calling salt modules from templates
所有的state都是在minion上加载模板系统，这允许数据可以被实时的收集到目标系统上，它还允许在sls模块中允许shell命令。

模板内容也可以有效的使用salt函数：

1
2
3
4
moe:
user:
-present
-gid:{ {salt’file.group_to_gid’}}
注意，上面这个例子要正常工作，请确保some_group_that_exists存在
下面的例子，使用network.hw_addr函数来检索eth的mac地址：

1
salt’network.hw_addr’
Advanced sls module syntax
最后，我们将讨论在一些更负载的state树中的一些令人难以置信的技巧

Include语句
前面的例子展示了如何通过多个文件进行扩展。同样，require可以使用include语句进行多个文件中的state之间的依赖，例如：

1
2
3
4
python/python-libs.sls:

python-dateutil:
pkg.installed

1
2
3
4
5
6
7
8
9
python/django.sls:

include:
-python.python-libs

django:
pkg.installed:
-require:
-pkg:python-dateutil
Extend语句
你可以使用extend语句修改之前的例子，例如当apache的vhosts文件发生了改变也重启apache

1
2
3
4
apache/apache.sls:

apache:
pkg.installed

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
apache/mywebsite.sls:

include:
-apache.apache

extend:
apache:
service:
-running
-watch:
-file:/etc/httpd/extra/httpd-vhosts.conf

/etc/httpd/extra/httpd-vhosts.conf:
file.managed:
-source:salt://apache/httpd-vhosts.conf
extend它只是起追加作用，而不是取代任何必要的组件

Name语句
你可以使用name语句的值来覆盖ID的值，例如，这个例子更加有利于维护重写

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
apache/mywebsite.sls:

include:
-apache.apache

extend:
apache:
service:
-running
-watch:
-file:mywebsite

mywebsite:
file.managed:
-name:/etc/httpd/extra/httpd-vhosts.conf
-source:salt://apache/httpd-vhosts.conf
Names语句
更强大的是使用names语句一次性的声明多个states来覆盖ID语句。这经常可以在模板中利用循环来实现，例如第一个例子中的循环可以写成下面这样的形式：

1
2
3
4
5
6
stooges:
user.present:
-names:
-moe
-larry
-curly

参考：http://docs.saltstack.com/topics/tutorials/states_pt3.html

==============================

本文将讲述salt如何通过建立一个file_roots来建立起工作的根，对于不同的”推广”"开发”"测试”"生产”等场景。

Salt fileserver path inheritance
salt允许在同一个环境下设置多个根目录，比如下面的例子，它使用本地的目录以及一个通过NFS共享的目录

In the master config file (/etc/salt/master)

1
2
3
4
file_roots:
base:
-/srv/salt
-/mnt/salt-nfs/base
在同一个环境下salt的fileserver可以包含多个根的列表。如果相同的文件在多个根下出现，那么最顶端的根将会生效，例如，如果/srv/salt/foo.txt 和 /mnt/salt-nfs/base/foo.txt都存在，那么使用salt://foo.txt时，这个foo.txt取的是 /srv/salt/foo.txt

Environment configuration
配置多个环境如下：

1
2
3
4
5
6
7
8
9
10
file_roots:
base:
-/srv/salt/prod
qa:
-/srv/salt/qa
-/srv/salt/prod
dev:
-/srv/salt/dev
-/srv/salt/qa
-/srv/salt/prod
从上可以看出/srv/salt/prod继承了所有的环境，所以这个路径可以用在任何的环境下。/srv/salt/qa可以用于两个环境下，/srv/salt/dev则只能用再一个环境下。

基于顺序的定义，新的state文件可以放置到/srv/salt/dev下，并且推送到dev主机上进行测试。

这些state文件也可以被移动到/srv/salt/qa下，那么现在他们就可以用再开发和测试环境中，并且允许他们被推送到测试主机上进行测试。

如果这些文件移动到/srv/salt/prod下，那么这些文件将可以用在现在这三个所有的环境下

Practical example
一个简单的网站，被安装到/var/www/foobarcom。下面是一个部署的top.sls：

1
2
3
4
5
6
7
8
9
base:
‘webprod’:
-webserver.foobarcom
qa:
‘webqa’:
-webserver.foobarcom
dev:
‘webdev’:
-webserver.foobarcom

使用pillar,按照角色分配给主机：

1
2
3
4
5
6
7
8
9
/srv/pillar/top.sls:

base:
‘webprod’:
-webserver.prod
‘webqa’:
-webserver.qa
‘webdev’:
-webserver.dev

1
2
3
/srv/pillar/webserver/prod.sls:

webserver_role:prod

1
2
3
/srv/pillar/webserver/qa.sls:

webserver_role:qa

1
2
3
/srv/pillar/webserver/dev.sls:

webserver_role:dev
最后，编写部署网站的sls模块：

1
2
3
4
5
6
7
8
9
10
11
12
/srv/salt/prod/webserver/foobarcom.sls:

{%ifpillar.get(‘webserver_role’,’’)%}
/var/www/foobarcom:
file.recurse:
-source:salt://webserver/src/foobarcom
-env:{ {pillar[‘webserver_role’]}}
-user:www
-group:www
-dir_mode:755
-file_mode:644
{%endif%}

根据上面的这个sls模块所定义，那么网站的源代码就应该放置在下面这个位置：
/srv/salt/dev/webserver/src/foobarcom.

首先，让我们先部署到dev的环境下，使用state.highstate

1
salt–pillar’webserver_role:dev’state.highstate
然而，如果并不想通过top.sls文件将所有的states配置部署到minions(假如当前我们已经当以很多的了state)，使用state.sls仅仅不是foobarcom这个state

1
salt–pillar’webserver_role:dev’state.sls webserver.foobarcom
一旦网站需要部署到dev和qa，那么只需要把文件从/srv/salt/dev/webserver/src/foobarcom移动到/srv/salt/qa/webserver/src/foobarcom，并且执行以下命令：

1
salt–pillar’webserver_role:qa’state.sls webserver.foobarcom
最后网站被qa测试通过，就可以将文件从/srv/salt/qa/webserver/src/foobarcom 移动到/srv/salt/prod/webserver/src/foobarcom，执行以下命令：

1
salt–pillar’webserver_role:prod’state.sls webserver.foobarcom
由于salt的fileserver的继承，即使从/srv/salt/prod移走，你仍然可以通过相同的url(salt://)同时从qa和dev环境下访问

参考：http://docs.saltstack.com/topics/tutorials/states_pt4.html

http://netkiller-github-com.iteye.com/blog/1927482

第 126 章 SaltStack
目录

126.1. 安装 Salt Stack126.1.1. 服务端安装126.1.2. 客户端安装126.1.3. 防火墙配置126.1.4. key 管理126.1.5. 测试126.2. salt 命令
http://saltstack.com/

126.1. 安装 Salt Stack
126.1.1. 服务端安装
yum install salt-master

chkconfig salt-master on
service salt-master start

126.1.2. 客户端安装
yum install salt-minion
chkconfig salt-minion on
配置 master

cp /etc/salt/minion{,.original}
sed -i ‘12,12imaster: salt.example.org’ /etc/salt/minion
cat >> /etc/hosts <<‘EOF’

192.168.2.1 salt.example.org
EOF

service salt-minion start
126.1.3. 防火墙配置
-A INPUT -p tcp -m multiport --dports 4505,4506 -m state --state NEW -j ACCEPT

126.1.4. key 管理
登陆master服务器，输入 salt-key 查看接入的 minion 客户端。

salt-key

Accepted Keys:
Unaccepted Keys:
haproxy
Rejected Keys:

接受客户端 key

salt-key -a haproxy

The following keys are going to be accepted:
Unaccepted Keys:
haproxy
Proceed? [n/Y] y
Key for minion haproxy accepted.

至此，master 与 minion 已经建立了信任关系

126.1.5. 测试
你可以运行下面命令测试你的 minion

salt ‘’ test.arg 1 “two” 3.1 txt=“hello” wow=’{a: 1, b: “hello”}’
salt '’ test.arg_repr 1 “two” 3.1 txt=“hello” wow=’{a: 1, b: “hello”}’
salt ‘’ test.collatz 3
salt '’ test.conf_test
salt ‘’ test.cross_test file.gid_to_group 0
salt '’ test.echo ‘foo bar baz quo qux’
salt ‘’ test.fib 3
salt '’ test.get_opts
salt ‘’ test.kwarg num=1 txt=“two” env=’{a: 1, b: “hello”}’
salt '’ test.not_loaded
salt ‘’ test.outputter foobar
salt '’ test.ping
salt ‘’ test.provider service
salt '’ test.providers
salt ‘’ test.rand_sleep 60
salt '’ test.retcode 42
salt ‘’ test.sleep 20
salt '’ test.tty tty0 ‘This is a test’
salt ‘’ test.tty pts3 ‘This is a test’
salt '’ test.version
salt ‘’ test.versions_information
salt '’ test.versions_report

我通常只作ping测试

salt ‘*’ test.ping

haproxy:
True

salt ‘*’ test.versions_information

haproxy:
----------
Jinja2:
unknown
M2Crypto:
0.20.2
PyYAML:
3.09
PyZMQ:
2.2.0.1
Python:
2.6.6 (r266:84292, Feb 22 2013, 00:00:18)
Salt:
0.16.0
ZMQ:
3.2.3
msgpack-pure:
None
msgpack-python:
0.1.13
pycrypto:
2.0.1

salt ‘*’ test.versions_report

haproxy:
Salt: 0.16.0
Python: 2.6.6 (r266:84292, Feb 22 2013, 00:00:18)
Jinja2: unknown
M2Crypto: 0.20.2
msgpack-python: 0.1.13
msgpack-pure: Not Installed
pycrypto: 2.0.1
PyYAML: 3.09
PyZMQ: 2.2.0.1
ZMQ: 3.2.3

126.2. salt 命令

salt ‘’ sys.doc | grep "salt '’"

salt ‘’ acl.delfacl user myuser /tmp/house/kitchen
salt '’ acl.delfacl default:group mygroup /tmp/house/kitchen
salt ‘’ acl.delfacl d:u myuser /tmp/house/kitchen
salt '’ acl.delfacl g myuser /tmp/house/kitchen /tmp/house/livingroom
salt ‘’ acl.getfacl /tmp/house/kitchen
salt '’ acl.getfacl /tmp/house/kitchen /tmp/house/livingroom
salt ‘’ acl.addfacl user myuser rwx /tmp/house/kitchen
salt '’ acl.addfacl default:group mygroup rx /tmp/house/kitchen
salt ‘’ acl.addfacl d:u myuser 7 /tmp/house/kitchen
salt '’ acl.addfacl g mygroup 0 /tmp/house/kitchen /tmp/house/livingroom
salt ‘’ acl.version
salt '’ acl.wipefacls /tmp/house/kitchen
salt ‘’ acl.wipefacls /tmp/house/kitchen /tmp/house/livingroom
salt '’ aliases.get_target
salt ‘’ aliases.has_target
salt '’ aliases.list_aliases
salt ‘’ aliases.rm_alias
salt '’ aliases.set_target
salt ‘’ alternatives.check_installed name path
salt '’ alternatives.display
salt ‘’ alternatives.install name link path priority
salt '’ alternatives.remove name path
salt ‘’ alternatives.show_current emacs
salt '’ archive.gunzip /tmp/sourcefile.txt.gz
salt ‘’ archive.gunzip temp