fdpSQL est l'acronyme de Freeradius & DHCP Powering SQL. C'est une machine virtualisée sur laquelle est installé un MariaDB Server (moteur MySQL) qui héberge les bases de données de radius, kea et adh5 depuis le 2 août 2018, migrées depuis le cluster NDB.
La mise en place du service est assez simple, il suffit d'installer le paquet mariadb-server suivi d'un mysql_secure_installation pour configurer le SGBD.
Ensuite il faut créer les bases de données. Il y en a trois : adh5-prod, radius et dhcp.1)
A la suite de quoi la base d'adh5 doit être remplie avec le backup effectué par Jobs sur Gitlab, la base kea doit suivre le schéma de base importable depuis une des deux instances de kea sur l'infra en suivant la documentation et la base radius doit suivre le schéma de base avec addition de certaines vues.
De plus, quatre utilisateurs doivent avoir accès à la base : adh5 (pour adh5), dhcp pour Kea, radius pour Freeradius et backup_adh5 pour Jobs. Ces droits doivent être répartis de la façon suivante :
| Utilisateur | Type d'accès | Base | Tables |
|---|---|---|---|
| adh5 | ALL PRIVILEGES | adh5-prod | * |
| dhcp | ALL PRIVILEGES | dhcp | * |
| radius | ALL PRIVILEGES | radius | * |
| INSERT | adh5-prod | ordinateurs, portables | |
| backup_adh5 | SELECT | adh5-prod | * |
Le mot de passe à attribuer pour chaque utilisateur est renseigné dans la configuration de chacun des services sur les machines hôtes.
Il est nécessaire que les utilisateurs doivent être créés en spécifiant l'adresse IP et le nom d'hôte des machines sur lesquels sont hébergés les services (sans oublier le .priv).
Des ressources venant appuyer cette page de Wiki sont disponibles sur Gitlab dans divers/schemas_sql. Il est fortement recommandé de suivre ses guidelines pour toute réinstallation de la base de données.
La réponse à cette question est évidente pour toute personne impatiente ayant été surprise par un problème sur l'infra impliquant de relancer le cluster NDB. Sans ce cluster opérationnel, la connexion au réseau et la distribution d'adresses IP est impossible, donc les adhérents n'ont pas accès à Internet. La documentation du cluster permet de comprendre qu'il présente une certaine complexité à être relancé et, bien qu'il soit mis en place pour prévenir une rupture du service, cela est parfois inévitable.
Alors, pour faire en sorte que l'infra redevienne opérationnelle le plus rapidement possible, cette solution, a priori temporaire, a été mise en place dans l'attente de concevoir un autre système d'hébergement de base de données assurant théoriquement une haute disponibilité, une protection de l'intégrité des données et leur sécurité ainsi qu'une praticité d'utilisation convenable.
La node n'est pas accessible publiquement mais contient des données critiques. Il est donc important de maintenir à jour le SGBD régulièrement et en suivant la procédure.
La sauvegarde est assurée automatiquement par Jobs et est hébergée sur Gitlab dans divers/sauvegarde-sql-adh5.
Il faut lancer une nouvelle sauvegarde manuelle depuis l'interface Jenkins et s'assurer qu'elle n'est pas corrompue.
Cette étape est optionnelle mais fortement recommandée pour les personnes les moins à l'aise ni en capacité de rattraper une erreur de manipulation.
Cloner la node fdpSQL depuis Proxmox, s'y connecter et effectuer les étapes de mise à jour. Compléter éventuellement le wiki avec des précisions. Vérifier que rien n'est cassé et passer à la mise à jour sur la node de production.
Version 10.1.26
— Clément Taverne 2018/08/03 14:17