forked from saltstack-formulas/dhcpd-formula
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathpillar.example
188 lines (174 loc) · 6.2 KB
/
pillar.example
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
# -*- coding: utf-8 -*-
# vim: ft=yaml
---
dhcpd:
# Change some defaults
lookup:
enable: false
domain_name: example.org
domain_name_servers:
- ns1.example.org
- ns2.example.org
default_lease_time: 600
max_lease_time: 7200
log_facility: local7
failover_peers:
dhcp-failover:
primary: true
address: 10.152.187.5
port: 647
peer_address: 10.152.187.6
peer_port: 647
split: 128
mclt: 3600
listen_interfaces:
- em1
- em2
subnets:
10.152.187.0:
comment: |
No service will be given on this subnet, but declaring it helps the
DHCP server to understand the network topology.
netmask: 255.255.255.0
pools:
- failover_peer: dhcp-failover
range:
- 10.152.187.1
- 10.152.187.254
10.254.239.0:
comment: This is a very basic subnet declaration.
netmask: 255.255.255.224
range:
- 10.254.239.10
- 10.254.239.20
routers:
- rtr-239-0-1.example.org
- rtr-239-0-2.example.org
10.254.239.32:
comment: |
This declaration allows BOOTP clients to get dynamic addresses,
which we don't really recommend.
netmask: 255.255.255.224
dynamic_bootp: true
range:
- 10.254.239.40
- 10.254.239.60
broadcast_address: 10.254.239.31
routers: rtr-239-32-1.example.org
10.5.5.0:
comment: A slightly different configuration for an internal subnet.
netmask: 255.255.255.224
range:
- 10.5.5.26
- 10.5.5.30
domain_name_servers:
- ns1.internal.example.org
domain_name: internal.example.org
routers:
- 10.5.5.1
broadcast_address: 10.5.5.31
default_lease_time: 600
max_lease_time: 7200
hosts:
jake:
comment: |
Hosts can be specified for subnets, taking subnets defaults
hardware: ethernet 08:00:a7:26:c0:a9
fixed_address: 10.5.5.27
# End of subnets
hosts:
passacaglia:
comment: |
Hosts which require special configuration options can be listed in
host statements. If no address is specified, the address will be
allocated dynamically (if possible), but the host-specific information
will still come from the host declaration.
# We're lucky we don't need the MAC as a key...
hardware: ethernet 0:0:c0:5d:bd:95
filename: vmunix.passacaglia
server_name: toccata.fugue.com
fantasia:
comment: |
Fixed IP addresses can also be specified for hosts. These addresses
should not also be listed as being available for dynamic assignment.
Hosts for which fixed IP addresses have been specified can boot using
BOOTP or DHCP. Hosts for which no fixed address is specified can only
be booted with DHCP, unless there is an address range on the subnet
to which a BOOTP client is connected which has the dynamic-bootp flag
set.
hardware: ethernet 08:00:07:26:c0:a5
fixed_address: fantasia.fugue.com
joe:
comment: |
The hostname for a host can be passed in the DHCP response. Using the
host_name key sets option host-name in the dhcpd configuration.
hardware: ethernet 08:00:2b:4c:29:32
fixed_address: joe.fugue.com
host_name: joe
classes:
foo:
comment: |
You can declare a class of clients and then do address allocation
based on that. The example below shows a case where all clients
in a certain class get addresses on the 10.17.224/24 subnet, and all
other clients get addresses on the 10.0.29/24 subnet.
# I'm suprised this works...
match: if substring (option vendor-class-identifier, 0, 4) = "SUNW"
firstuserclass:
comment: |
You can also have a class assignment take no action, but simply
extract a dhcp option to be matched later in a subclass definition
based on that. The example below shows filtering out the first value
listed in the user-class DHCP option 77. This is then used by a subclass
defined later to act on those values.
match: pick-first-value (option user-class);
iotthingsclass:
comment: |
A class without an IF clause can be used to push a matched field
to a subclass definition that can have scope itself, or be used
for an allow/deny control inside a subnet pool.
match: hardware
subclass:
firstuserclass:
iPXE:
comment: |
This is an example of a using a subclass of a class filter
In this example, the matched user-class value of 'iPXE' from
the class named 'firstuserclass' (defined in the above example),
will cause a different secondary boot filename to be specified.
filename: "http://192.168.0.1/boot/boot.ipxe"
auto-proxy-config: "example_data_for_customized_option_see_below"
iotthingsclass:
# These examples are subclasses without scope used for allow/deny
# inside of a subnet declaration
'00:21:29:a1:c3:a1': noscope
'00:21:29:a1:c3:a2': noscope
shared_networks:
224-29:
subnets:
10.17.224.0:
netmask: 255.255.255.0
routers: rtr-224.example.org
10.0.29.0:
netmask: 255.255.255.0
routers: rtr-29.example.org
pools:
# And no, those quotation marks won't get stripped:
- allow: members of "foo"
range:
- 10.17.224.10
- 10.17.224.250
- deny: members of "foo"
range:
- 10.0.29.10
- 10.0.29.230
# DHCP allow customized options, which, once declared, can be used as same
# as the default options on every level, e.g. as global or subnet option.
# These options will be declared on top of dhcpd.conf.
# They consist of a NAME (Attention! '_' will be replaced by '-'), a CODE
# number and a DATATYPE (e.g. string, text, integer, ip-address)
customized_options:
# unique option name, e.g. 'auto_proxy_config' will be 'auto-proxy-config'
auto_proxy_config:
code: 252
type: string