Mis à jour d'une base de données mysql installé via paquet

Bonjour à tous ;

Je suis entrain de debianizer un hack que j’ai créé.

Ce hack (Paquet B) doit mettre à jour (ajout de champs) une base de données qui a été installée par un paquet que je nomerais ici A.

Je voulais donc savoir qu’elle était la meilleurs solution pour que la base de données du paquet A soit mise à jour par le paquet B, notamment au niveau de l’authentification.

J’ai pensé à deux solutions :

  • Utilisation de l’user debian-sys-maint ;
  • Demande à l’adminisrateur du couple login/password via debconf avec une priorité critique pour la question.

Si quelqu’un à des solution plus judicieuses, je suis bien entendu preneur. De même, si quelqu’un connaît la solution qui respecte le plus la charte debian (la force intérieur) qu’il me le dise.

Vous en remerciant par avance.

Le deuxiême AMA est incompatible avec la charte debian: je n’ai jamais vu un debconf demander autrechose que d’initialiser un mot de passe. Jamais en fournir un.
Sinon, je ne connais pas la manière classique pour scripter la configuration d’une base mysql, mais tu peux peut être regarder les scripts post-install de paquets qui reposent sur une base mysql, et faire comme eux (je n’en ai pas en tête) ?
Mais c’est vrai que toi tu veux modifier une base existante, c’est peut être un peu différent.

[quote=“mattotop”]Le deuxiême AMA est incompatible avec la charte debian: je n’ai jamais vu un debconf demander autrechose que d’initialiser un mot de passe. Jamais en fournir un.
Sinon, je ne connais pas la manière classique pour scripter la configuration d’une base mysql, mais tu peux peut être regarder les scripts post-install de paquets qui reposent sur une base mysql, et faire comme eux (je n’en ai pas en tête) ?
Mais c’est vrai que toi tu veux modifier une base existante, c’est peut être un peu différent.[/quote]

Bonjour ;

Je te remercie de m’avoir répondu.

En ce qui concerne la deuxième proposition, je me doutais bien que cela n’allait pas coller avec la charte. Pourtant, cette procédure ne me semble pas plus désavantageuse qu’une autre… La sécurité peut être ???.

Une troisième solution serait d’intégrer via script post-install, une subroutine perl qui parse le fichier de configuration dans lequel est situé le nom de la bd, le nom de l’user ainsi que le passe crypté via algo blowfish. Quand pense tu ?

Je sais que sous sarge, l’utilisation de l’user de debian-sys-maint ne posait pas de problèmes particulier mais il me semble que dans la version mysql disponible sous etch, les droits de cet user ont été restreint. De plus cette méthode ne me plaît pas beaucoup. Pour ce qui est de la méthode pour scripter, elle est assez simple. Soit on passe par le moniteur sql via bash soit on utilise le module dbi si codage en perl.

J’ai bien pensé à regarder des paquets installant des bases de données mais ces derniers initialisent des couple login/mot de passe, il ne vont pas à la pêche d’identifiant existants.

Vous remerciant par avance pour vos lumières. :wink: :cry:

C’est une évidence de sécurité que de partir du principe que debconf ne demandera jamais de mot de passe. Si un paquet fait ça, ça te met la puce à l’oreille.
Sinon, je n’ai pas de meilleure idée que ça, désolé, tu es plus avancé que moi dans l’empaquettage, manifestement et pour le peu que j’en connaisse.

bonsoir,
c’est intéressant … on trouve un certain nombre de “paquets” (ex: TAR.GZ) comme ça qui demande parfois le mot de pass root pour continuer le script d’installation.
Il y a aussi un outil bien debian qui permet à l’utilisateur de saisir un mot de passe root, via une interface graphique: j’ai nommé la clicke des dialog, gdialog, xdialog …
Il y a encore la possibilité lors de l’installation de notifier l’utilisateur que le paquet ne sera pas actif tant que certaines variables n’auront pas été renseigner dans un fichier de conf spécifié, ce qui demanderai à relancer l’installation aprés, via un /usr/bin/installtrucmuche déjà présent, mais qui teste que les variables sont renseignées, ou exit 1.

De toutes façons, j’ai pas l’impression que le problème soit là … C’est peut-être plus dur de mettre à jour un DB ou de faire un .DEB que de
permettre via un script ou un binaire l’installation du .deb qui va modifier la DB.
me gourges ?

première partie: hein ?
deuxiême partie: pas mieux…
:wink:

hello :wink:
première ligne : comment ?
deuxième ligne: tu dis ?
:smiley: