Ça va p-e paraître un truc fait à la barbare mais un script bash lancé depuis le .profile avec une commande qui supprime l’entrée dans le .profile après ce que tu veux lui faire faire et un rm /chemin/vers/ce/script.sh en dernière commande?
À mon humble avis là t’es sûr qu’il ne se lancera qu’une seule fois.
Ben le lancement du script marche bien avec la crontab en fait, avec l’entrée @reboot.
je ne peux pas jouer avec profile car il fait partie des fichiers fortement surveillé par l’HIDS 
C’est gênant genre tu vas te faire rouspéter ou c’est une blagounette pour faire peur au collègue?
ben déjà c’est gênant genre c est un peu degueu en fait 
et je ne suis pas sur que l’enforce avec apparmor entre autre ne va pas bloquer une partie des commandes, dont justement ce qui touche à systemd.
Du coup la méthode pull avec Ansible est à mon humble avis la méthode la moins invasive et la plus safe, ta machine une fois up va aller chercher son playbook et réaliser ces opérations sur un répertoire Git …
C’est ainsi que j’effectue des reconfigurations du type hostname, ip, etc … lors d’un provisionnement de machine si j’ai pas la possibilité d’installer (ou la volonté) d’installer Cloud-init.
Avec Ansible, il me faut une plate-forme dédiée et supplémentaire.
Avec le preseed, j’ajoute tous les packages dont j’ai besoin (sauf le backport de systemd).
ensuite avec le late_command, je réalise toutes les commandes d’installations des fichiers de conf pré-définis, les modifications de droits, les banners, les modifications de fstab, grub, auditd, sshd, pamd, rsyslog, webmin, shorewall, shorewall6, isc-dhcp-server, bind9.
dans le script de reboot c’est juste les modifications liés à systemd pour shorewall/shorewall6/shorewall-init, desactiver rsync, puis effacer les répertoires de travail des fichiers de conf et de scripts.
pour l’exécution du script de reboot, la difficulté était de configurer crontab en late_command dans le preseed. Il y a en effet des requis pour l’écriture du fichier, un simple echo « text » > crontab ou /var/spool/cron/crontab/root ne suffit pas.
j’ai donc préparer un fichier complet et installé avec un:
cat crontab | crontab -u root - qui contient le fameux @reboot /root/scripts/reboot_exec.sh
et pour supprimer, dans le script de rebot, un simple crontab -r suffit.
Apparemment, le fichier crontab doit contenir les commentaires de base (ou peut être une ligne vide en fin de fichier), sinon ça ne marche pas.
maintenant, ne me reste plus qu’à configurer le vlan orange, les dhclient ipv4 et v6 et l’igmp.
Cette discussion m’a beaucoup aidé.
Pour compléter voici la fin de preseed pour ubuntu 20.04 desktop avec ubiquity pour lancer un script.sh au premier boot.
ubiquity ubiquity/success_command string \
cp /cdrom/script.sh /target/root/script.sh ; \
chmod +x /target/root/script.sh ; \
echo "@reboot /root/script.sh" > /target/var/spool/cron/crontabs/root ; \
chmod 600 /target/var/spool/cron/crontabs/root ; \
chown root:crontab /target/var/spool/cron/crontabs/root ; \
in-target apt update -y ; \
in-target apt upgrade -y ; \
--ubiquity-success-command
De mes nombreuses installations j’ai remarqué qu’un echo "line1 \n line2" avec ou sans option e dans le preseed resulte d’un ignore de ubiquity/success_command. Sinon pas eu besoin d’y ajouter les commentaires de base, le script s’execute.
Pas besoin normallement de ubiquity, tu peux faire l’opération avec d-i preseed/late_command string ....