Discussion :

[NuM82]

Bonjour à tou(te)s,
Etant encore profane sous linux, j’éprouve de nombreuses difficultés pour réaliser exactement ce que je désire. Heureusement que le web est là pour me permettre d’avancer mais, hélas, on n’y trouve pas toujours tout….
J’ai créé un serveur sous Debian Jessie (plus exactement Raspbian) sur lequel j’ai installé différents programmes que j’ai configuré plus ou moins aisément.
L’idée serait d’avoir un fichier unique de configuration contenant les paramètres sous la forme :

Emplacement/fichier_de_conf|paramètre valeur

Par exemple :

/etc/default/inadyn|RUN_DAEMON="yes"
/etc/inadyn.conf|system default@no-ip.com
/etc/inadyn.conf|username mon_compte_utilisatur
/etc/inadyn.conf|password mon_mot_de_passe
/etc/inadyn.conf|alias mon_host
/etc/inadyn.conf|period 600
/etc/mysql/my.cnf|bind-address = 0.0.0.0
/etc/ssmtp/ssmtp.conf|AuthUser=mon_adresse_email
/etc/ssmtp/ssmtp.conf|AuthPass=mon_mot_de_passe_email

Le programme permettrait d’ouvrir les différents fichiers de conf et de les modifier avec les valeurs inscrites dans les fichiers au bon endroit en supprimant les valeurs par défaut.

Je pensais faire cela en shell mais je ne suis pas sûr que cela soit le mieux pour faire ce genre d’opération.

Merci pour votre contribution.

[Jipété]

L’idée serait d’avoir un fichier unique de configuration contenant les paramètres sous la forme :
[...]
Le programme permettrait d’ouvrir les différents fichiers de conf et de les modifier avec les valeurs inscrites dans les fichiers au bon endroit en supprimant les valeurs par défaut.

Mais à quoi ça servirait ?

Parce que, que tu paramètres un seul gros fichier de conf puis que tu écrives un script qui va le lire pour ensuite aller modifier les fichiers de conf propres à chaque prog, script qu'il va falloir tester et débugguer et retester pendant un temps dément, à mon avis tu as plus vite fait de modifier directement les fichiers de conf des prog's à la mano et sans te prendre la tête, d'autant plus qu'une fois un fichier de conf bien configuré, il n'y a plus à y revenir.

Donc ton script ne servirait qu'une fois pour chaque prog : aucun intérêt, à part pour apprendre à programmer en shell.
Ou alors je n'ai rien compris.

[NuM82]

Mais à quoi ça servirait ?

Cela servirait à centraliser l'ensemble des modifications ou réglages d'un serveur pour permettre de ne rien oublier quand plusieurs années après, on doit remettre les mains dedans ...

Actuellement, je contourne le problème en copiant les fichiers de conf.
Un seul fichier à modifier me semble bien plus simple pour ne rien oublier plutôt qu'une multitude de fichiers éparpillés.
Le script permettrait (à mon avis) d'aller plus vite pour l'installation d'un nouveau serveur similaire.

[N_BaH]

Actuellement, je contourne le problème en copiant les fichiers de conf.

ça semble le plus simple et pratique, en effet.

Un seul fichier à modifier me semble bien plus simple pour ne rien oublier plutôt qu'une multitude de fichiers éparpillés.

pourquoi les copies devraient-elles être éparpillés ?
crée un répertoire dédié, qui reproduira sous une forme ou une autre la hiérarchie des répertoires/fichiers de conf.
tu peux y ajouter un paramètre temporel pour retrouver tes anciennes conf fonctionnelle.
ça requiert un peu d'organisation, tu y gagneras.

Le script permettrait (à mon avis) d'aller plus vite pour l'installation d'un nouveau serveur similaire.

hmm, non.
copier ce qui existe dans le répertoire dédié me paraît plus rapide.

[chrtophe]

Cela servirait à centraliser l'ensemble des modifications ou réglages d'un serveur pour permettre de ne rien oublier quand plusieurs années après, on doit remettre les mains dedans ...

Quand après plusieurs années tu dois remettre les mains dedans, les fichiers peuvent avoir changé de noms, d'emplacement, ou morcelés en plusieurs sous-fichiers. Des petites changements pas spécifiquement bloquant pour un sysadmin, mais suffisant pour planter un script.

Tu peux par contre tout à fait envisager de te créer une matrice pour réinstaller un serveur dans une config bien précise. En cas de mise à jour de version (système ou appli), celle-ci devra être modifiée en conséquence.

C'est d'ailleurs le principe des dockerfiles utilisé par Docker.

[NuM82]

Merci pour vos retours.
Effectivement, le fichier unique ne me semble plus la solution idéale et pratique que j'espérais.
Vos regards extérieurs m'ont ouvert les yeux ... j'étais parti pour tuer une mouche au bazooka!
Je vais me documenter sur le principe des dockerfiles pour ma culture et non pour l'exploitation dans mon cas.

[jack-ft]

Le programme permettrait d’ouvrir les différents fichiers de conf et de les modifier avec les valeurs inscrites dans les fichiers au bon endroit en supprimant les valeurs par défaut.

Je pensais faire cela en shell mais je ne suis pas sûr que cela soit le mieux pour faire ce genre d’opération.

Si tu veux vraiment tout mettre dans un seul fichier, voici une ébauche de la possibilité qui me paraît la plus simple:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
# inadyn
 
inadyn=/etc/default/inadyn
 
rm -rf $inadyn
 
cat > $inadyn << EOT
RUN_DAEMON="yes"
EOT
 
inadyn_conf=/etc/inadyn.conf
 
rm -rf $inadyn_conf
 
cat > $inadyn_conf << EOT
system default@no-ip.com
username mon_compte_utilisatur
password mon_mot_de_passe
alias mon_host
period 600
EOT
 
# mysql
 
my_cnf=/etc/mysql/my.cnf
 
rm -rf $my_cnf
 
cat > $my_cnf << EOT
bind-address = 0.0.0.0
EOT
 
# ssmtp
 
ssmtp_conf=/etc/ssmtp/ssmtp.conf
 
rm -rf $ssmtp_conf
 
cat > $ssmtp_conf << EOT
AuthUser=mon_adresse_email
AuthPass=mon_mot_de_passe_email
EOT

Améliorations possibles (voire nécessaires)

• Gérer les erreurs (fichier ou répertoire inexistant, insuffisance de droits, etc.)
• Gérer les droits des fichiers produits (propriétaire, groupe, droits unix)
• Gérer un ou plusieurs backups des versions précédentes des fichiers
• Proposer une interaction (comparaison entre existant et nouvelle version avant écrasement)

Avantages:

• Tout dans un même fichier
• Simple à maintenir (pour l'instant)

Inconvénients

• Dangereux (détruit ou déplace des fichiers existants)
• Fait fi de toute configuration préalable
• Tout dans un même fichier: si un programme ou un administrateur veut modifier une valeur, il doit le faire dans le script... même s'il n'est pas au courant qu'il existe un script qui centralise la gestion des valeurs...
• Le script contient les mots de passe en clair.

[NuM82]

Merci jack-ft pour ta contribution.

Si j'ai bien compris ton code, il effectue les tâches suivantes :

• suppression du fichier de conf.
• écriture d'un nouveau fichier de conf contenant les nouvelles valeurs.

Le soucis est que les paramètres qui ne doivent pas être actualisés sont perdus.

Je cherchais à mettre à jour certaines valeurs et pas toutes.