diff --git a/goss/s-kea1.yaml b/goss/s-kea1.yaml new file mode 100644 index 0000000..9a0a59f --- /dev/null +++ b/goss/s-kea1.yaml @@ -0,0 +1,90 @@ +file: + /etc/kea/kea-ctrl-agent.conf: + exists: true + mode: "0644" + size: 2470 + owner: _kea + group: root + filetype: file + contains: [] + /etc/kea/kea-dhcp4.conf: + exists: true + mode: "0644" + size: 11346 + owner: _kea + group: root + filetype: file + contains: [] + /tmp/kea4-ctrl-socket: + exists: true + mode: "0755" + size: 0 + owner: _kea + group: _kea + filetype: socket + contains: [] + /usr/local/lib/kea: + exists: true + mode: "0755" + size: 4096 + owner: root + group: root + filetype: directory + contains: [] +package: + isc-kea-common: + installed: true + versions: + - 2.4.1-isc20231123184533 + isc-kea-ctrl-agent: + installed: true + versions: + - 2.4.1-isc20231123184533 + isc-kea-dhcp4: + installed: true + versions: + - 2.4.1-isc20231123184533 + isc-kea-hooks: + installed: true + versions: + - 2.4.1-isc20231123184533 + libmariadb3: + installed: true + versions: + - 1:10.11.4-1~deb12u1 + mariadb-common: + installed: true + versions: + - 1:10.11.4-1~deb12u1 + mysql-common: + installed: true + versions: + - 5.8+1.1.0 +port: + tcp:8000: + listening: true + ip: + - 172.16.64.20 +service: + isc-kea-ctrl-agent.service: + enabled: true + running: true + isc-kea-dhcp4-server.service: + enabled: true + running: true +interface: + enp0s3: + exists: true + addrs: + - 192.168.99.20/24 + mtu: 1500 + enp0s8: + exists: true + addrs: + - 172.16.0.20/24 + mtu: 1500 + enp0s9: + exists: true + addrs: + - 172.16.64.20/24 + mtu: 1500 diff --git a/goss/s-kea2.yaml b/goss/s-kea2.yaml new file mode 100644 index 0000000..9fe75be --- /dev/null +++ b/goss/s-kea2.yaml @@ -0,0 +1,90 @@ +file: + /etc/kea/kea-ctrl-agent.conf: + exists: true + mode: "0644" + size: 2470 + owner: _kea + group: root + filetype: file + contains: [] + /etc/kea/kea-dhcp4.conf: + exists: true + mode: "0644" + size: 11346 + owner: _kea + group: root + filetype: file + contains: [] + /tmp/kea4-ctrl-socket: + exists: true + mode: "0755" + size: 0 + owner: _kea + group: _kea + filetype: socket + contains: [] + /usr/local/lib/kea: + exists: true + mode: "0755" + size: 4096 + owner: root + group: root + filetype: directory + contains: [] +package: + isc-kea-common: + installed: true + versions: + - 2.4.1-isc20231123184533 + isc-kea-ctrl-agent: + installed: true + versions: + - 2.4.1-isc20231123184533 + isc-kea-dhcp4: + installed: true + versions: + - 2.4.1-isc20231123184533 + isc-kea-hooks: + installed: true + versions: + - 2.4.1-isc20231123184533 + libmariadb3: + installed: true + versions: + - 1:10.11.4-1~deb12u1 + mariadb-common: + installed: true + versions: + - 1:10.11.4-1~deb12u1 + mysql-common: + installed: true + versions: + - 5.8+1.1.0 +port: + tcp:8000: + listening: true + ip: + - 172.16.64.21 +service: + isc-kea-ctrl-agent.service: + enabled: true + running: true + isc-kea-dhcp4-server.service: + enabled: true + running: true +interface: + enp0s3: + exists: true + addrs: + - 192.168.99.21/24 + mtu: 1500 + enp0s8: + exists: true + addrs: + - 172.16.0.21/24 + mtu: 1500 + enp0s9: + exists: true + addrs: + - 172.16.64.21/24 + mtu: 1500 diff --git a/roles/kea-master/templates/.kea-dhcp4-j1.conf.swp b/roles/kea-master/templates/.kea-dhcp4-j1.conf.swp deleted file mode 100644 index a877164..0000000 Binary files a/roles/kea-master/templates/.kea-dhcp4-j1.conf.swp and /dev/null differ diff --git a/roles/kea-master/templates/kea-ctrl-agent-j1.conf b/roles/kea-master/templates/kea-ctrl-agent-j1.conf deleted file mode 100644 index 196b855..0000000 --- a/roles/kea-master/templates/kea-ctrl-agent-j1.conf +++ /dev/null @@ -1,66 +0,0 @@ -// This is an example of a configuration for Control-Agent (CA) listening -// for incoming HTTP traffic. This is necessary for handling API commands, -// in particular lease update commands needed for HA setup. -{ - "Control-agent": - { - // We need to specify where the agent should listen to incoming HTTP - // queries. - "http-host": "172.16.64.1", - - // This specifies the port CA will listen on. - "http-port": 8000, - - "control-sockets": - { - // This is how the Agent can communicate with the DHCPv4 server. - "dhcp4": - { - "comment": "socket to DHCPv4 server", - "socket-type": "unix", - "socket-name": "/tm/kea4-ctrl-socket" - }, - - // Location of the DHCPv6 command channel socket. - # "dhcp6": - # { - # "socket-type": "unix", - # "socket-name": "/tmp/kea6-ctrl-socket" - # }, - - // Location of the D2 command channel socket. - # "d2": - # { - # "socket-type": "unix", - # "socket-name": "/tmp/kea-ddns-ctrl-socket", - # "user-context": { "in-use": false } - # } - }, - - // Similar to other Kea components, CA also uses logging. - "loggers": [ - { - "name": "kea-ctrl-agent", - "output_options": [ - { - "output": "stdout", - - // Several additional parameters are possible in addition - // to the typical output. Flush determines whether logger - // flushes output to a file. Maxsize determines maximum - // filesize before the file is rotated. maxver - // specifies the maximum number of rotated files being - // kept. - "flush": true, - "maxsize": 204800, - "maxver": 4, - // We use pattern to specify custom log message layout - "pattern": "%d{%y.%m.%d %H:%M:%S.%q} %-5p [%c/%i] %m\n" - } - ], - "severity": "INFO", - "debuglevel": 0 // debug level only applies when severity is set to DEBUG. - } - ] - } -} diff --git a/roles/kea-master/templates/kea-dhcp4-j1.conf b/roles/kea-master/templates/kea-dhcp4-j1.conf deleted file mode 100644 index 8ac1124..0000000 --- a/roles/kea-master/templates/kea-dhcp4-j1.conf +++ /dev/null @@ -1,226 +0,0 @@ -// This is an example configuration of the Kea DHCPv4 server 1: -// -// - uses High Availability hook library and Lease Commands hook library -// to enable High Availability function for the DHCP server. This config -// file is for the primary (the active) server. -// - uses memfile, which stores lease data in a local CSV file -// - it assumes a single /24 addressing over a link that is directly reachable -// (no DHCP relays) -// - there is a handful of IP reservations -// -// It is expected to run with a standby (the passive) server, which has a very similar -// configuration. The only difference is that "this-server-name" must be set to "server2" on the -// other server. Also, the interface configuration depends on the network settings of the -// particular machine. - -{ - -"Dhcp4": { - - // Add names of your network interfaces to listen on. - "interfaces-config": { - // The DHCPv4 server listens on this interface. When changing this to - // the actual name of your interface, make sure to also update the - // interface parameter in the subnet definition below. - "interfaces": [ "enp0s8" ] - }, - - // Control socket is required for communication between the Control - // Agent and the DHCP server. High Availability requires Control Agent - // to be running because lease updates are sent over the RESTful - // API between the HA peers. - "control-socket": { - "socket-type": "unix", - "socket-name": "/tmp/kea4-ctrl-socket" - }, - - // Use Memfile lease database backend to store leases in a CSV file. - // Depending on how Kea was compiled, it may also support SQL databases - // (MySQL and/or PostgreSQL). Those database backends require more - // parameters, like name, host and possibly user and password. - // There are dedicated examples for each backend. See Section 7.2.2 "Lease - // Storage" for details. - "lease-database": { - // Memfile is the simplest and easiest backend to use. It's an in-memory - // database with data being written to a CSV file. It is very similar to - // what ISC DHCP does. - "type": "memfile" - }, - - // Let's configure some global parameters. The home network is not very dynamic - // and there's no shortage of addresses, so no need to recycle aggressively. - "valid-lifetime": 43200, // leases will be valid for 12h - "renew-timer": 21600, // clients should renew every 6h - "rebind-timer": 32400, // clients should start looking for other servers after 9h - - // Kea will clean up its database of expired leases once per hour. However, it - // will keep the leases in expired state for 2 days. This greatly increases the - // chances for returning devices to get the same address again. To guarantee that, - // use host reservation. - // If both "flush-reclaimed-timer-wait-time" and "hold-reclaimed-time" are - // not 0, when the client sends a release message the lease is expired - // instead of being deleted from lease storage. - "expired-leases-processing": { - "reclaim-timer-wait-time": 3600, - "hold-reclaimed-time": 172800, - "max-reclaim-leases": 0, - "max-reclaim-time": 0 - }, - - // HA requires two hook libraries to be loaded: libdhcp_lease_cmds.so and - // libdhcp_ha.so. The former handles incoming lease updates from the HA peers. - // The latter implements high availability feature for Kea. Note the library name - // should be the same, but the path is OS specific. - "hooks-libraries": [ - // The lease_cmds library must be loaded because HA makes use of it to - // deliver lease updates to the server as well as synchronize the - // lease database after failure. - { - "library": "/usr/local/lib/kea/hooks/libdhcp_lease_cmds.so" - }, - - { - // The HA hook library should be loaded. - "library": "/usr/local/lib/kea/hooks/libdhcp_ha.so", - "parameters": { - // Each server should have the same HA configuration, except for the - // "this-server-name" parameter. - "high-availability": [ { - // This parameter points to this server instance. The respective - // HA peers must have this parameter set to their own names. - "this-server-name": "kea1", - // The HA mode is set to hot-standby. In this mode, the active server handles - // all the traffic. The standby takes over if the primary becomes unavailable. - "mode": "hot-standby", - // Heartbeat is to be sent every 10 seconds if no other control - // commands are transmitted. - "heartbeat-delay": 10000, - // Maximum time for partner's response to a heartbeat, after which - // failure detection is started. This is specified in milliseconds. - // If we don't hear from the partner in 60 seconds, it's time to - // start worrying. - "max-response-delay": 30000, - // The following parameters control how the server detects the - // partner's failure. The ACK delay sets the threshold for the - // 'secs' field of the received discovers. This is specified in - // milliseconds. - "max-ack-delay": 5000, - // This specifies the number of clients which send messages to - // the partner but appear to not receive any response. - "max-unacked-clients": 0, - // This specifies the maximum timeout (in milliseconds) for the server - // to complete sync. If you have a large deployment (high tens or - // hundreds of thousands of clients), you may need to increase it - // further. The default value is 60000ms (60 seconds). - "sync-timeout": 60000, - "peers": [ - // This is the configuration of this server instance. - { - "name": "kea1", - // This specifies the URL of this server instance. The - // Control Agent must run along with this DHCPv4 server - // instance and the "http-host" and "http-port" must be - // set to the corresponding values. - "url": "http://172.16.64.1:8000/", - // This server is primary. The other one must be - // secondary. - "role": "primary" - }, - // This is the configuration of the secondary server. - { - "name": "kea2", - // Specifies the URL on which the partner's control - // channel can be reached. The Control Agent is required - // to run on the partner's machine with "http-host" and - // "http-port" values set to the corresponding values. - "url": "http://172.16.64.2:8000/", - // The other server is secondary. This one must be - // primary. - "role": "standby" - } - ] - } ] - } - } - ], - - // This example contains a single subnet declaration. - "subnet4": [ - { - // Subnet prefix. - "subnet": "172.16.64.0/24", - - // There are no relays in this network, so we need to tell Kea that this subnet - // is reachable directly via the specified interface. - "interface": "enp0s8", - - // Specify a dynamic address pool. - "pools": [ - { - "pool": "172.16.64.100-172.16.64.150" - } - ], - - // These are options that are subnet specific. In most cases, you need to define at - // least routers option, as without this option your clients will not be able to reach - // their default gateway and will not have Internet connectivity. If you have many - // subnets and they share the same options (e.g. DNS servers typically is the same - // everywhere), you may define options at the global scope, so you don't repeat them - // for every network. - "option-data": [ - { - // For each IPv4 subnet you typically need to specify at least one router. - "name": "routers", - "data": "172.16.64.1" - }, - { - // Using cloudflare or Quad9 is a reasonable option. Change this - // to your own DNS servers is you have them. Another popular - // choice is 8.8.8.8, owned by Google. Using third party DNS - // service raises some privacy concerns. - "name": "domain-name-servers", - "data": "172.16.64.1" - } - ], - - // Some devices should get a static address. Since the .100 - .199 range is dynamic, - // let's use the lower address space for this. There are many ways how reservation - // can be defined, but using MAC address (hw-address) is by far the most popular one. - // You can use client-id, duid and even custom defined flex-id that may use whatever - // parts of the packet you want to use as identifiers. Also, there are many more things - // you can specify in addition to just an IP address: extra options, next-server, hostname, - // assign device to client classes etc. See the Kea ARM, Section 8.3 for details. - // The reservations are subnet specific. - #"reservations": [ - # { - # "hw-address": "1a:1b:1c:1d:1e:1f", - # "ip-address": "192.168.1.10" - # }, - # { - # "client-id": "01:11:22:33:44:55:66", - # "ip-address": "192.168.1.11" - # } - #] - } - ], - // fichier de logs - "loggers": [ - { - // This section affects kea-dhcp4, which is the base logger for DHCPv4 component. It tells - // DHCPv4 server to write all log messages (on severity INFO or higher) to a file. The file - // will be rotated once it grows to 2MB and up to 4 files will be kept. The debuglevel - // (range 0 to 99) is used only when logging on DEBUG level. - "name": "kea-dhcp4", - "output_options": [ - { - "output": "stdout", - "maxsize": 2048000, - "maxver": 4 - } - ], - "severity": "INFO", - "debuglevel": 0 - } - ] -} -} diff --git a/roles/kea-slave/templates/.kea-dhcp4-j1.conf.swp b/roles/kea-slave/templates/.kea-dhcp4-j1.conf.swp deleted file mode 100644 index a877164..0000000 Binary files a/roles/kea-slave/templates/.kea-dhcp4-j1.conf.swp and /dev/null differ diff --git a/roles/kea-slave/templates/kea-ctrl-agent-j1.conf b/roles/kea-slave/templates/kea-ctrl-agent-j1.conf deleted file mode 100644 index 196b855..0000000 --- a/roles/kea-slave/templates/kea-ctrl-agent-j1.conf +++ /dev/null @@ -1,66 +0,0 @@ -// This is an example of a configuration for Control-Agent (CA) listening -// for incoming HTTP traffic. This is necessary for handling API commands, -// in particular lease update commands needed for HA setup. -{ - "Control-agent": - { - // We need to specify where the agent should listen to incoming HTTP - // queries. - "http-host": "172.16.64.1", - - // This specifies the port CA will listen on. - "http-port": 8000, - - "control-sockets": - { - // This is how the Agent can communicate with the DHCPv4 server. - "dhcp4": - { - "comment": "socket to DHCPv4 server", - "socket-type": "unix", - "socket-name": "/tm/kea4-ctrl-socket" - }, - - // Location of the DHCPv6 command channel socket. - # "dhcp6": - # { - # "socket-type": "unix", - # "socket-name": "/tmp/kea6-ctrl-socket" - # }, - - // Location of the D2 command channel socket. - # "d2": - # { - # "socket-type": "unix", - # "socket-name": "/tmp/kea-ddns-ctrl-socket", - # "user-context": { "in-use": false } - # } - }, - - // Similar to other Kea components, CA also uses logging. - "loggers": [ - { - "name": "kea-ctrl-agent", - "output_options": [ - { - "output": "stdout", - - // Several additional parameters are possible in addition - // to the typical output. Flush determines whether logger - // flushes output to a file. Maxsize determines maximum - // filesize before the file is rotated. maxver - // specifies the maximum number of rotated files being - // kept. - "flush": true, - "maxsize": 204800, - "maxver": 4, - // We use pattern to specify custom log message layout - "pattern": "%d{%y.%m.%d %H:%M:%S.%q} %-5p [%c/%i] %m\n" - } - ], - "severity": "INFO", - "debuglevel": 0 // debug level only applies when severity is set to DEBUG. - } - ] - } -} diff --git a/roles/kea-slave/templates/kea-dhcp4-j1.conf b/roles/kea-slave/templates/kea-dhcp4-j1.conf deleted file mode 100644 index 8ac1124..0000000 --- a/roles/kea-slave/templates/kea-dhcp4-j1.conf +++ /dev/null @@ -1,226 +0,0 @@ -// This is an example configuration of the Kea DHCPv4 server 1: -// -// - uses High Availability hook library and Lease Commands hook library -// to enable High Availability function for the DHCP server. This config -// file is for the primary (the active) server. -// - uses memfile, which stores lease data in a local CSV file -// - it assumes a single /24 addressing over a link that is directly reachable -// (no DHCP relays) -// - there is a handful of IP reservations -// -// It is expected to run with a standby (the passive) server, which has a very similar -// configuration. The only difference is that "this-server-name" must be set to "server2" on the -// other server. Also, the interface configuration depends on the network settings of the -// particular machine. - -{ - -"Dhcp4": { - - // Add names of your network interfaces to listen on. - "interfaces-config": { - // The DHCPv4 server listens on this interface. When changing this to - // the actual name of your interface, make sure to also update the - // interface parameter in the subnet definition below. - "interfaces": [ "enp0s8" ] - }, - - // Control socket is required for communication between the Control - // Agent and the DHCP server. High Availability requires Control Agent - // to be running because lease updates are sent over the RESTful - // API between the HA peers. - "control-socket": { - "socket-type": "unix", - "socket-name": "/tmp/kea4-ctrl-socket" - }, - - // Use Memfile lease database backend to store leases in a CSV file. - // Depending on how Kea was compiled, it may also support SQL databases - // (MySQL and/or PostgreSQL). Those database backends require more - // parameters, like name, host and possibly user and password. - // There are dedicated examples for each backend. See Section 7.2.2 "Lease - // Storage" for details. - "lease-database": { - // Memfile is the simplest and easiest backend to use. It's an in-memory - // database with data being written to a CSV file. It is very similar to - // what ISC DHCP does. - "type": "memfile" - }, - - // Let's configure some global parameters. The home network is not very dynamic - // and there's no shortage of addresses, so no need to recycle aggressively. - "valid-lifetime": 43200, // leases will be valid for 12h - "renew-timer": 21600, // clients should renew every 6h - "rebind-timer": 32400, // clients should start looking for other servers after 9h - - // Kea will clean up its database of expired leases once per hour. However, it - // will keep the leases in expired state for 2 days. This greatly increases the - // chances for returning devices to get the same address again. To guarantee that, - // use host reservation. - // If both "flush-reclaimed-timer-wait-time" and "hold-reclaimed-time" are - // not 0, when the client sends a release message the lease is expired - // instead of being deleted from lease storage. - "expired-leases-processing": { - "reclaim-timer-wait-time": 3600, - "hold-reclaimed-time": 172800, - "max-reclaim-leases": 0, - "max-reclaim-time": 0 - }, - - // HA requires two hook libraries to be loaded: libdhcp_lease_cmds.so and - // libdhcp_ha.so. The former handles incoming lease updates from the HA peers. - // The latter implements high availability feature for Kea. Note the library name - // should be the same, but the path is OS specific. - "hooks-libraries": [ - // The lease_cmds library must be loaded because HA makes use of it to - // deliver lease updates to the server as well as synchronize the - // lease database after failure. - { - "library": "/usr/local/lib/kea/hooks/libdhcp_lease_cmds.so" - }, - - { - // The HA hook library should be loaded. - "library": "/usr/local/lib/kea/hooks/libdhcp_ha.so", - "parameters": { - // Each server should have the same HA configuration, except for the - // "this-server-name" parameter. - "high-availability": [ { - // This parameter points to this server instance. The respective - // HA peers must have this parameter set to their own names. - "this-server-name": "kea1", - // The HA mode is set to hot-standby. In this mode, the active server handles - // all the traffic. The standby takes over if the primary becomes unavailable. - "mode": "hot-standby", - // Heartbeat is to be sent every 10 seconds if no other control - // commands are transmitted. - "heartbeat-delay": 10000, - // Maximum time for partner's response to a heartbeat, after which - // failure detection is started. This is specified in milliseconds. - // If we don't hear from the partner in 60 seconds, it's time to - // start worrying. - "max-response-delay": 30000, - // The following parameters control how the server detects the - // partner's failure. The ACK delay sets the threshold for the - // 'secs' field of the received discovers. This is specified in - // milliseconds. - "max-ack-delay": 5000, - // This specifies the number of clients which send messages to - // the partner but appear to not receive any response. - "max-unacked-clients": 0, - // This specifies the maximum timeout (in milliseconds) for the server - // to complete sync. If you have a large deployment (high tens or - // hundreds of thousands of clients), you may need to increase it - // further. The default value is 60000ms (60 seconds). - "sync-timeout": 60000, - "peers": [ - // This is the configuration of this server instance. - { - "name": "kea1", - // This specifies the URL of this server instance. The - // Control Agent must run along with this DHCPv4 server - // instance and the "http-host" and "http-port" must be - // set to the corresponding values. - "url": "http://172.16.64.1:8000/", - // This server is primary. The other one must be - // secondary. - "role": "primary" - }, - // This is the configuration of the secondary server. - { - "name": "kea2", - // Specifies the URL on which the partner's control - // channel can be reached. The Control Agent is required - // to run on the partner's machine with "http-host" and - // "http-port" values set to the corresponding values. - "url": "http://172.16.64.2:8000/", - // The other server is secondary. This one must be - // primary. - "role": "standby" - } - ] - } ] - } - } - ], - - // This example contains a single subnet declaration. - "subnet4": [ - { - // Subnet prefix. - "subnet": "172.16.64.0/24", - - // There are no relays in this network, so we need to tell Kea that this subnet - // is reachable directly via the specified interface. - "interface": "enp0s8", - - // Specify a dynamic address pool. - "pools": [ - { - "pool": "172.16.64.100-172.16.64.150" - } - ], - - // These are options that are subnet specific. In most cases, you need to define at - // least routers option, as without this option your clients will not be able to reach - // their default gateway and will not have Internet connectivity. If you have many - // subnets and they share the same options (e.g. DNS servers typically is the same - // everywhere), you may define options at the global scope, so you don't repeat them - // for every network. - "option-data": [ - { - // For each IPv4 subnet you typically need to specify at least one router. - "name": "routers", - "data": "172.16.64.1" - }, - { - // Using cloudflare or Quad9 is a reasonable option. Change this - // to your own DNS servers is you have them. Another popular - // choice is 8.8.8.8, owned by Google. Using third party DNS - // service raises some privacy concerns. - "name": "domain-name-servers", - "data": "172.16.64.1" - } - ], - - // Some devices should get a static address. Since the .100 - .199 range is dynamic, - // let's use the lower address space for this. There are many ways how reservation - // can be defined, but using MAC address (hw-address) is by far the most popular one. - // You can use client-id, duid and even custom defined flex-id that may use whatever - // parts of the packet you want to use as identifiers. Also, there are many more things - // you can specify in addition to just an IP address: extra options, next-server, hostname, - // assign device to client classes etc. See the Kea ARM, Section 8.3 for details. - // The reservations are subnet specific. - #"reservations": [ - # { - # "hw-address": "1a:1b:1c:1d:1e:1f", - # "ip-address": "192.168.1.10" - # }, - # { - # "client-id": "01:11:22:33:44:55:66", - # "ip-address": "192.168.1.11" - # } - #] - } - ], - // fichier de logs - "loggers": [ - { - // This section affects kea-dhcp4, which is the base logger for DHCPv4 component. It tells - // DHCPv4 server to write all log messages (on severity INFO or higher) to a file. The file - // will be rotated once it grows to 2MB and up to 4 files will be kept. The debuglevel - // (range 0 to 99) is used only when logging on DEBUG level. - "name": "kea-dhcp4", - "output_options": [ - { - "output": "stdout", - "maxsize": 2048000, - "maxver": 4 - } - ], - "severity": "INFO", - "debuglevel": 0 - } - ] -} -}