La question qui se pose est : pourquoi mémoriser la date de dernière authentification ?

Le principal intérêt est de mettre en place un premier niveau de gouvernance : cette date permet d'identifier les comptes qui sont obsolètes dans l'annuaire, par exemple qui n'ont pas été utilisés pour s'authentifier depuis plusieurs mois.

Par défaut, cette information n'est pas disponible sur OpenLDAP (comme cela peut l'être dans un AD).

On peut analyser les logs systèmes (avec un niveau de log OpenLDAP à 256), mais ce n'est pas optimal.

A partir de la version 8, Red Hat et CentOS n'utilisent plus iptables mais firewalld.

Par défaut, celui-ci est activé. On peut voir la liste des ports ouverts :

firewall-cmd --list-all
public (active)
target: default
icmp-block-inversion: no
interfaces: enp1s0
sources:
services: cockpit dhcpv6-client ssh
ports:
protocols:
masquerade: no
forward-ports:
source-ports:
icmp-blocks:
rich rules:

Les ports correspondant aux services listés sont ouverts :

Par défaut, CentOS 7 (et RHEL) embarquent une version 5.4.16 de PHP, qui est datée et peut présenter des problèmes de sécurité.

On trouve sur le web pas mal de tutoriels qui expliquent comment passer en version 7.x, en ajoutant les dépôts REMI.

Dans mon cas, le serveur est dans un réseau d'entreprise qui dispose de ses propres serveurs de dépôts, et on ne peut donc pas accéder aux dépôts externes.

On a quand même pu passer en version 7.3, en récupérant les rpm puis en les installant.

Je décris ici les étapes à mener.

J'ai récemment migré mon serveur d'une version 18.04 LTS Ubuntu vers une version 20.04.

Lors de la migration, j'ai du passer sur la version snap de LXD, en version 4. Et suite à cette migration, les containers n'avaient plus d'adresse IP (que ce soit en V4 ou en V6).

Après de nombreuses recherches sur les forums LXD, j'ai trouvé la source du problème, en analysant les différents symptômes.

Sur le serveur, le service dnsmasq ne tournait pas. ce qu'on peut vérifier par :

Analyse et résolution d'un problème curieux, arrivé après un reboot sur un serveur Rise1 OVH.

Contexte

Après installation LXD, et transfert d'images entre 2 machines, tout fonctionnait bien. Le storage par défaut a été créé lors de l'installation (par la commande lxd init) de type btrfs.

Au redémarrage, les containers ne veulent plus redémarrer :

lxc start openldap
Error: Common start logic: no such device
Try `lxc info --show-log openldap` for more info

On essaie donc la commande :