Compare commits

...

8 Commits

Author SHA1 Message Date
3b88857c0b modif reseau proxy 2024-01-18 11:19:52 +01:00
72c5498e64 maj role fw 2024-01-18 11:11:34 +01:00
e1cc021ee2 mise a jour role kea-master et kea-slave modif des fichiers de config 2024-01-18 10:59:19 +01:00
76528fad6f maj playbooks lb 2024-01-18 10:36:06 +01:00
bc7cdc993f maj playbooks lb 2024-01-18 10:01:18 +01:00
01e06119a5 mkvm : mode normal pour option -s 2024-01-18 00:14:03 +01:00
99672bef0d reorganisation roles kea-master et kea-slave 2024-01-17 22:25:55 +01:00
f9e801c39e MAJ doc README.md 2024-01-17 18:06:26 +01:00
34 changed files with 1446 additions and 105 deletions

View File

@ -1,13 +1,13 @@
# gsb2024
2024-01-13 ps
2024-01-17 18h04 ps
Environnement et playbooks **ansible** pour le projet **GSB 2024**
## Quickstart
Prérequis :
* une machine Linux Debian Bookworm ou Windows
* une machine **Linux Debian Bookworm** ou **Windows**
* VirtualBox
* git
* fichier machines virtuelles **ova** :
@ -38,6 +38,8 @@ Prérequis :
* **s-lb-web2** : Serveur Wordpress 2 Load Balancer
* **s-lb-db** : Serveur Mariadb pour Wordpress
* **s-nas** : Serveur NFS pour application Wordpress avec LB
* **s-kea1** : Serveur DHCP Kea HA 1
* **s-kea2** : Serveur DHCP Kea HA 2
## Les playbooks
@ -98,37 +100,40 @@ bash chname <nouveau_nom_de_machine>` , puis redémarrer
### Pour chaque machine
#### Etape 1
#### Etape 1 - Nommage machine
- créer la machine avec **mkvm -r**, les cartes réseau sont paramétrées par **mkvm** selon les spécifications
- ouvrir une session sur la machine considérée
- renommer la machine soit
* en utilisant le script de renommage comme suit :
` /root/tools/ansible/gsb2024/scripts/chname <nouveau_nom_de_machine>`
* soit avec :
* soit (ici on renomme la machine en **s-infra**) avec :
```shell
NHOST=mavm
sed -i "s/bookworm/${NHOST}/g" /etc/host{s,name}
sudo reboot # on redemarre
export HOST=s-infra
curl 192.168.99.99/gsbstore/inst1|bash
reboot # on redemarre
```
#### Etape 2
#### Etape 2 - installation outils, depot gsb2024 et lancement playbook
- utiliser le script **gsb-start** : `bash gsb-start`
- ou sinon:
```shell
mkdir -p tools/ansible ; cd tools/ansible
git clone https://gitea.lyc-lecastel.fr/gsb/gsb2024.git
cd gsb2024/pre
DEPL=192.168.99.99 bash gsbboot
cd ../.. ; bash pull-config
curl 192.168.99.99/gsbstore/inst2|bash
```
- le script recupere le dépot **gsb2024.git**
- il lance ensuite le script **pull-config** avec le script porant le nom de la machine
- on peut alors redémarrer
#### Etape 3
#### Etape 3 - Redémarrage et tests
- redémarrer
- **Remarque** : une machine doit avoir été redémarrée pour prendre en charge la nouvelle configuration
- **Remarque** : une machine doit avoir été redémarrée pour prendre en charge la nouvelle configuration, en particulier la couche réseau et l'adressage.
- selon les situations, il est possible qu'un seul playbook ne soit pas suffisant pour installer complètement une machine. Dans ce cas de figure, le second playbook s'appelle **s-machine-post.yml**.
Il est à lancer depuis ''tools/ansible/gsb2024'' :
```shell
ansible-playbook -i localhost, -c local s-machine-post.yml
```
## Les tests

View File

@ -4,7 +4,6 @@
@def $DEV_PRIVATE = enp0s8;
@def $DEV_WORLD = enp0s9;
@def $DEV_WORLD = enp0s9;
@def $DEV_VPN= wg0;
@def $NET_PRIVATE = 172.16.0.0/24;
@ -32,7 +31,7 @@ table filter {
# well-known internet hosts
saddr ($NET_PRIVATE) proto tcp dport ssh ACCEPT;
# we provide DNS and SMTP services for the internal net
# we provide DNS services for the internal net
interface $DEV_PRIVATE saddr $NET_PRIVATE {
proto (udp tcp) dport domain ACCEPT;
proto udp dport bootps ACCEPT;

View File

@ -29,7 +29,7 @@ table filter {
# well-known internet hosts
saddr ($NET_PRIVATE) proto tcp dport ssh ACCEPT;
# we provide DNS and SMTP services for the internal net
# we provide DNS services for the internal net
interface $DEV_PRIVATE saddr $NET_PRIVATE {
proto (udp tcp) dport domain ACCEPT;
proto udp dport bootps ACCEPT;

View File

@ -0,0 +1,8 @@
#variable kea
kea_ver: "2.4.1"
kea_dbname: ""
kaa_dbuser: ""
kea_dbpasswd: ""
kea_dhcp4_dir: "/etc/kea/kea-dhcp4.conf"
kea_ctrl_dir: "/etc/kea/kea-ctrl-agent.conf"

View File

@ -0,0 +1,66 @@
// 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.20",
// 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": "/tmp/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.
}
]
}
}

View File

@ -0,0 +1,226 @@
// 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": [ "enp0s9" ]
},
// 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": "s-kea1.gsb.lan",
// 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": "s-kea1.gsb.lan",
// 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.20:8000/",
// This server is primary. The other one must be
// secondary.
"role": "primary"
},
// This is the configuration of the secondary server.
{
"name": "s-kea2.gsb.lan",
// 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.21: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": "enp0s9",
// 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.254"
},
{
// 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.0.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
}
]
}
}

View File

@ -0,0 +1,18 @@
---
- name: restart isc-kea-dhcp4-server
service:
name: isc-kea-dhcp4-server.service
state: restarted
enabled: yes
- name: restart isc-kea-ctrl-agent
service:
name: isc-kea-ctrl-agent.service
state: restarted
enabled: yes
- name: restart mariadb-server
service:
name: mariadb-server
state: restarted
enabled: yes

View File

@ -0,0 +1,75 @@
---
- name: installation des dépendances
apt:
name:
- liblog4cplus-2.0.5
- libmariadb3
- libpq5
- mariadb-common
- mysql-common
state: present
- name: telechargemement du paquet isc-kea-common
get_url:
url: "https://dl.cloudsmith.io/public/isc/kea-2-4/deb/debian/pool/bookworm/main/i/is/isc-kea-common_2.4.1-isc20231123184533/isc-kea-common_2.4.1-isc20231123184533_amd64.deb"
dest: "/tmp"
- name: telechargement du paquet isc-kea-dhcp4
get_url:
url: "https://dl.cloudsmith.io/public/isc/kea-2-4/deb/debian/pool/bookworm/main/i/is/isc-kea-dhcp4_2.4.1-isc20231123184533/isc-kea-dhcp4_2.4.1-isc20231123184533_amd64.deb"
dest: "/tmp"
- name: telechargement du paquet isc-kea-ctrl-agent
get_url:
url: "https://dl.cloudsmith.io/public/isc/kea-2-4/deb/debian/pool/bookworm/main/i/is/isc-kea-ctrl-agent_2.4.1-isc20231123184533/isc-kea-ctrl-agent_2.4.1-isc20231123184533_amd64.deb"
dest: "/tmp"
- name: telechargement du paquet isc-kea-hooks
get_url:
url: "https://dl.cloudsmith.io/public/isc/kea-2-4/deb/debian/pool/bookworm/main/i/is/isc-kea-hooks_2.4.1-isc20231123184533/isc-kea-hooks_2.4.1-isc20231123184533_amd64.deb"
dest: "/tmp"
- name: Update apt
apt:
update_cache: yes
- name: Installation paquet isc-kea-common
apt:
deb: "/tmp/isc-kea-common_2.4.1-isc20231123184533_amd64.deb"
state: present
- name: Installation isc-kea-dhcp4
apt:
deb: "/tmp/isc-kea-dhcp4_2.4.1-isc20231123184533_amd64.deb"
state: present
- name: Installation isc-kea-ctrl-agent
apt:
deb: "/tmp/isc-kea-ctrl-agent_2.4.1-isc20231123184533_amd64.deb"
state: present
- name: Installation isc-kea-hooks
apt:
deb: "/tmp/isc-kea-hooks_2.4.1-isc20231123184533_amd64.deb"
state: present
- name: Copie du repertoire des hooks dans le repertoire /usr/local/bin/kea/hooks
copy:
src: /usr/lib/x86_64-linux-gnu/kea/
dest: /usr/local/lib/kea/
- name: Copie du fichier de configuration kea-dhcp4.conf
copy:
src: kea-dhcp4.conf
dest: /etc/kea/kea-dhcp4.conf
notify:
- restart isc-kea-dhcp4-server
- name: Copie du fichier de configuration kea-ctrl-agent
copy:
src: kea-ctrl-agent.conf
dest: /etc/kea/kea-ctrl-agent.conf
notify:
- restart isc-kea-ctrl-agent

Binary file not shown.

View File

@ -0,0 +1,66 @@
// 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.
}
]
}
}

View File

@ -0,0 +1,226 @@
// 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
}
]
}
}

14
roles/kea-slave/README.md Normal file
View File

@ -0,0 +1,14 @@
# Rôle Kea
***
Rôle du Kea pour la haute disponibilité dhcp
## Tables des matières
1. [Que fait le rôle Kea ?]
## Que fait le rôle Kea ?
Il permet de configurer les serveur kea en mode haute disponibilité.
### Installation et configuration de kea
Le rôle kea va installer les packets kea dhcp4, hook, admin une fois les packets installer. Nous allons configurer les 2 serveurs kea pour qu'il distribut les ip de n-user et soit en haute disponibilité.

View File

@ -0,0 +1,8 @@
#variable kea
kea_ver: "2.4.1"
kea_dbname: ""
kaa_dbuser: ""
kea_dbpasswd: ""
kea_dhcp4_dir: "/etc/kea/kea-dhcp4.conf"
kea_ctrl_dir: "/etc/kea/kea-ctrl-agent.conf"

View File

@ -0,0 +1,66 @@
// 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.21",
// 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": "/tmp/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.
}
]
}
}

View File

@ -0,0 +1,226 @@
// 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": [ "enp0s9" ]
},
// 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": "s-kea2.gsb.lan",
// 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": "s-kea1.gsb.lan",
// 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.20:8000/",
// This server is primary. The other one must be
// secondary.
"role": "primary"
},
// This is the configuration of the secondary server.
{
"name": "s-kea2.gsb.lan",
// 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.21: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": "enp0s9",
// 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.254"
},
{
// 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.0.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
}
]
}
}

View File

@ -0,0 +1,18 @@
---
- name: restart isc-kea-dhcp4-server
service:
name: isc-kea-dhcp4-server.service
state: restarted
enabled: yes
- name: restart isc-kea-ctrl-agent
service:
name: isc-kea-ctrl-agent.service
state: restarted
enabled: yes
- name: restart mariadb-server
service:
name: mariadb-server
state: restarted
enabled: yes

View File

@ -0,0 +1,75 @@
---
- name: installation des dépendances
apt:
name:
- liblog4cplus-2.0.5
- libmariadb3
- libpq5
- mariadb-common
- mysql-common
state: present
- name: telechargemement du paquet isc-kea-common
get_url:
url: "https://dl.cloudsmith.io/public/isc/kea-2-4/deb/debian/pool/bookworm/main/i/is/isc-kea-common_2.4.1-isc20231123184533/isc-kea-common_2.4.1-isc20231123184533_amd64.deb"
dest: "/tmp"
- name: telechargement du paquet isc-kea-dhcp4
get_url:
url: "https://dl.cloudsmith.io/public/isc/kea-2-4/deb/debian/pool/bookworm/main/i/is/isc-kea-dhcp4_2.4.1-isc20231123184533/isc-kea-dhcp4_2.4.1-isc20231123184533_amd64.deb"
dest: "/tmp"
- name: telechargement du paquet isc-kea-ctrl-agent
get_url:
url: "https://dl.cloudsmith.io/public/isc/kea-2-4/deb/debian/pool/bookworm/main/i/is/isc-kea-ctrl-agent_2.4.1-isc20231123184533/isc-kea-ctrl-agent_2.4.1-isc20231123184533_amd64.deb"
dest: "/tmp"
- name: telechargement du paquet isc-kea-hooks
get_url:
url: "https://dl.cloudsmith.io/public/isc/kea-2-4/deb/debian/pool/bookworm/main/i/is/isc-kea-hooks_2.4.1-isc20231123184533/isc-kea-hooks_2.4.1-isc20231123184533_amd64.deb"
dest: "/tmp"
- name: Update apt
apt:
update_cache: yes
- name: Installation paquet isc-kea-common
apt:
deb: "/tmp/isc-kea-common_2.4.1-isc20231123184533_amd64.deb"
state: present
- name: Installation isc-kea-dhcp4
apt:
deb: "/tmp/isc-kea-dhcp4_2.4.1-isc20231123184533_amd64.deb"
state: present
- name: Installation isc-kea-ctrl-agent
apt:
deb: "/tmp/isc-kea-ctrl-agent_2.4.1-isc20231123184533_amd64.deb"
state: present
- name: Installation isc-kea-hooks
apt:
deb: "/tmp/isc-kea-hooks_2.4.1-isc20231123184533_amd64.deb"
state: present
- name: Copie du repertoire des hooks dans le repertoire /usr/local/bin/kea/hooks
copy:
src: /usr/lib/x86_64-linux-gnu/kea/
dest: /usr/local/lib/kea/
- name: Copie du fichier de configuration kea-dhcp4.conf
copy:
src: kea-dhcp4.conf
dest: /etc/kea/kea-dhcp4.conf
notify:
- restart isc-kea-dhcp4-server
- name: Copie du fichier de configuration kea-ctrl-agent
copy:
src: kea-ctrl-agent.conf
dest: /etc/kea/kea-ctrl-agent.conf
notify:
- restart isc-kea-ctrl-agent

Binary file not shown.

View File

@ -0,0 +1,66 @@
// 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.
}
]
}
}

View File

@ -0,0 +1,226 @@
// 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
}
]
}
}

View File

@ -1,8 +0,0 @@
#variable kea
kea_ver: "2.4.1"
kea_dbname: ""
kea_dbuser: ""
kea_dbpasswd: ""
kea_dhcp4_dir: "/etc/kea/kea-dhcp4.conf"
kea_ctrl_dir: "/etc/kea/kea-ctrl-agent.conf"

View File

@ -1,5 +0,0 @@
- name: restart zabbix agent
service:
name: zabbix-agent
state: restarted
enabled: yes

View File

@ -1,65 +0,0 @@
- name: installation des dépendances
apt:
name:
- liblog4cplus-2.0.5
- libmariadb3
- libpq5
- mariadb-common
- mysql-common
state: present
- name: telechargemement du paquet isc-kea-common
get_url:
url: "https://dl.cloudsmith.io/public/isc/kea-2-4/deb/debian/pool/bookworm/main/i/is/isc-kea-common_2.4.1-isc20231123184533/isc-kea-common_2.4.1-isc20231123184533_amd64.deb"
dest: "/tmp"
- name: telechargement du paquet isc-kea-dhcp4
get_url:
url: "https://dl.cloudsmith.io/public/isc/kea-2-4/deb/debian/pool/bookworm/main/i/is/isc-kea-dhcp4_2.4.1-isc20231123184533/isc-kea-dhcp4_2.4.1-isc20231123184533_amd64.deb"
dest: "/tmp"
- name: telechargement du paquet isc-kea-ctrl-agent
get_url:
url: "https://dl.cloudsmith.io/public/isc/kea-2-4/deb/debian/pool/bookworm/main/i/is/isc-kea-ctrl-agent_2.4.1-isc20231123184533/isc-kea-ctrl-agent_2.4.1-isc20231123184533_amd64.deb"
dest: "/tmp"
- name: telechargement du paquet isc-kea-hooks
get_url:
url: "https://dl.cloudsmith.io/public/isc/kea-2-4/deb/debian/pool/bookworm/main/i/is/isc-kea-hooks_2.4.1-isc20231123184533/isc-kea-hooks_2.4.1-isc20231123184533_amd64.deb"
dest: "/tmp"
- name: Update apt
apt:
update_cache: yes
- name: Installation paquet isc-kea-common
apt:
deb: "/tmp/isc-kea-common_2.4.1-isc20231123184533_amd64.deb"
state: present
- name: Installation isc-kea-dhcp4
apt:
deb: "/tmp/isc-kea-dhcp4_2.4.1-isc20231123184533_amd64.deb"
state: present
- name: Installation isc-kea-ctrl-agent
apt:
deb: "/tmp/isc-kea-ctrl-agent_2.4.1-isc20231123184533_amd64.deb"
state: present
- name: Installation isc-kea-ctrl-agent
apt:
deb: "/tmp/isc-kea-ctrl-agent_2.4.1-isc20231123184533_amd64.deb"
state: present
- name: Installation isc-kea-hooks
apt:
deb: "/tmp/isc-kea-ctrl-agent_2.4.1-isc20231123184533_amd64.deb"
state: present
- name: Installation isc-kea-hooks
apt:
deb: "/tmp/isc-kea-ctrl-agent_2.4.1-isc20231123184533_amd64.deb"
state: present

View File

@ -69,8 +69,13 @@
args:
chdir: /root/nxc
- name: Creation reseau docker proxy
- name: vérification si le réseau proxy existe
command: docker network ls --filter name=proxy
register: net_proxy
- name: création du réseau proxy
command: docker network create proxy
when: net_proxy.stdout.find('proxy') == -1
#- name: Démarrage du docker-compose...
#command: /bin/bash docker-compose up -d

13
s-kea1.yml Normal file
View File

@ -0,0 +1,13 @@
---
- hosts: localhost
connection: local
roles:
- base
#- goss
#- ssh-cli
- kea-master
#- zabbix-cli
#- journald-snd
#- snmp-agent
- post

13
s-kea2.yml Normal file
View File

@ -0,0 +1,13 @@
---
- hosts: localhost
connection: local
roles:
- base
# - goss
# - ssh-cli
- kea-slave
# - zabbix-cli
# - journald-snd
# - snmp-agent
- post

View File

@ -9,5 +9,5 @@
- goss
- lb-bd
- post
- snmp-agent
#- zabbix-cli
- ssh-cli

View File

@ -6,6 +6,6 @@
- base
- post-lb
- lb-web
- snmp-agent
# - zabbix-cli
- ssh-cli

View File

@ -6,6 +6,6 @@
- base
- post-lb
- lb-web
- snmp-agent
# - zabbix-cli
- ssh-cli

View File

@ -6,7 +6,7 @@
- base
- goss
- lb-front
- snmp-agent
#- zabbix-cli
- ssh-cli
- post

View File

@ -9,7 +9,7 @@
roles:
- base
- snmp-agent
#- zabbix-cli
- lb-nfs-server
- ssh-cli
# - syslog-cli

View File

@ -137,5 +137,5 @@ else
exit 2
fi
if [[ $startmode == 1 ]] ; then
vboxmanage startvm "${vm}" --type headless
vboxmanage startvm "${vm}"
fi

View File

@ -18,4 +18,4 @@ echo ping r-vp2 interface interface interne
ping -c3 172.16.128.254
echo ping s-agence
ping -c3 172.16.128.11
ping -c3 172.16.128.10