Bonjour Debian.
Je suis chargé d’adapter un script d’installation fonctionnant bien sous Debian Squeeze vers CentOS 7.
Le script est plutôt bien commenté, mais très long, donc pour l’instant je ne pige pas vraiment ce qu’il fait.
À quoi je dois faire attention pour ne pas me vautrer dans l’adaptation de ce script ?
Est-ce qu’il y a des trucs que je peux considérer comme étant identiques a priori et donc ne pas m’embêter avec pour gagner du temps ?
Bonjour,
Que de vieilles distros ! 
Si le script n’est pas confidentiel et ne contient pas d’infos sensibles, à la limite poste le ici
PS: les miroirs des dépôts CentOS 7 sont encore actifs ?
Oui oui, c’est CentOS 6 et 8 qui sont obsolètes, CentOS 7 est la version en cours. EOL en 2024.
C’est un script public et libre, mais il est trop long (1800 lignes) pour être posté ici (surtout qu’il n’y a pas de balise de code - en tous cas de ce que j’ai testé - qui permette d’avoir un ascenseur interne au code de façon à ce qu’il ne prenne pas toute la place dans le message).
On peut le trouver là (mais sans coloration syntaxique).
Je sais bien que les gestionnaires de paquets sont différents, j’avoue que je n’avais pas pensé à aller voir sur pkgs.org pour la correspondance, merci.
Pour les chemins d’installation, il faut les vérifier un par un ?
En faisant un grep sur debconf, dbconfig, cela me permettra de voir tout ce qui peut poser problème ? Comment j’identifie les scripts pre/post rem et inst ?
J’avais pas pensé à l’init par défaut, qui est bien systemd sur CentOS 7, comment je repère ce qui peut poser problème ?
Surtout que je pige pas grand chose à systemd (à part taper systemctl start - ou enable - quand c’est nécessaire).
Ah oui, exact. Cela dit, 2024 ça arrive vite, ça vaut peut-être le coup de passer sur les « successeurs » de CentOS (j’ai pas trop regardé, mais je crois qu’il s’agit de Rocky Linux, notamment).
Normalement si tu mets 3 backquotes (AltGr+7) au-dessus et en dessous du code, ça devrait être bon, mais c’est vrai que même ainsi, 1800 lignes ça fera beaucoup trop.
Le script n’a pas l’air d’utiliser les gestionnaires de paquets pour installer les logiciels désirés, à la place il en récupère des archives sur le web, puis les extrait, etc. Donc ces éléments ne seront peut-être pas des problèmes.
C’est la section SysV-style INIT qui posera problème, si les fonctions définies dedans sont appelées.
S’il s’agit d’une VM ou d’un conteneur, tu peux toujours faire un instantané du système, tenter d’utiliser le script comme d’habitude, voir si ça convient, et si non, réinitialiser le système dans son état précédent.
Mais vu la complexité et l’ancienneté du script, est-ce que ça ne vaudrait pas le coup de s’en passer ? C’est pour installer quels logiciels ? Est-ce qu’il n’y a pas des méthodes plus à jour et adaptées à CentOS 7 ?
Bonjour,
dans le script:
#!/bin/bash
# This file is part of marionnet
# Copyright (C) 2010 2011 2012 2013 2014 2015 2016 Jean-Vincent Loddo
# Copyright (C) 2010 2011 2012 2013 2014 2015 2016 Université Paris 13
Ce qui signifie qu’à priori, dans le(s) package(s) Marionnet CentOS tu devrais pouvoir retrouver le même script, non?
Ben d’après les auteurs non…
D’ailleurs je ne trouve pas marionnet dans les packets CentOS 7.
Ils m’ont demandé de leur envoyer mon script si j’arrive à l’adapter.
Comme dit dans le message précédent, d’après les auteurs, non.
Il y en aura une quand je l’aurais réalisée, en gros.
C’est la méthode officielle pour installer Marionnet, si on ne veut pas prendre leur image VirtualBox Debian Squeeze toute prête (et on m’a demandé de mettre Marionnet sur du CentOS 7 avec KDE).
j’aime bien ce genre de prescription, où il faut faire un truc qui n’est pas prévu par le tenant du produit 
Bon j’ai commencé par tester sur une Debian Buster puisqu’il y a encore un paquet Marionnet, histoire d’avoir un point de comparaison (je n’ai jamais utilisé ce logiciel).
Dans la configuration post-installation ils disent de rajouter des lignes dans /etc/rc.local qui n’existe pas dans Buster (si je comprends bien, rc.local est pour sysvinit et pas systemd).
systemctl status rc-local
● rc-local.service - /etc/rc.local Compatibility
Loaded: loaded (/lib/systemd/system/rc-local.service; static; vendor preset:
Drop-In: /usr/lib/systemd/system/rc-local.service.d
└─debian.conf
Active: inactive (dead)
Docs: man:systemd-rc-local-generator(8)
Je suis en train de regarder la doc sur comment on gère rc.local sur les versions qui utilisent systemd (dans /etc/ j’ai bien rc0.d, rc1.d, …rc6.d, rcS.d, c’est rc.local qui n’existe pas), mais est-ce que c’est une bonne idée ou bien je devrais abandonner rc.local et tenter de trouver comment lancer le daemon marionnet depuis systemd ?
En toute logique:
systemctl enable marionnet
systemctl start marionnet
systemctl stop marionnet
systemctl restart marionnet
Pour les status:
systemctl is-enabled marionnet
systemctl status marionnet
Les chiffres après rc correspondent aux modes, ou run levels du système, sous sysV. Par exemple, le run level 3 correspond au mode multi-utilisateur avec la couche réseau disponible, mais pas encore de serveur d’affichage, si tant est que le système en ait un.
Du coup tu peux mettre ton script dans le répertoire /etc/rc5.d/, ça devrait être bon.
Sous systemd c’est plutôt les targets, le mode multi-utilisateurs est multi-user.target. Voir ici pour plus d’explications et une table de correspondance entre les run levels sysV et les targets systemd.
Puisque CentOS 7 (comme Buster) utilise systemd, autant partir directement là-dessus, ce sera toujours ça de moins à faire. systemd est rétrocompatible avec les scripts de démarrage sysV, mais j’ignore pour combien de temps la rétro compatibilité sera assurée.
Tu peux commencer par faire la gestion du démon à la sauce sysV, tout en le gérant avec les commandes systemd que donne @Zargos , pour vérifier le bon fonctionnement. D’ailleurs systemd aura probablement créé un fichier « à la systemd » à partir du script rc, tu pourras le voir avec systemctl cat marionnet