Bon je vais voir comment rendre les choses pas trop embrouillantes avec 2 scripts 
J’ai testé le script sur mon Raspberry pi, donc raspbian, sans soucis. Donc tu peux y aller
S’il pose une question, les gens qui cherchent à l’aider pourront le lui demander et savoir plus facilement ce qu’il s’est passé.
dialog c’est très proche de l’interface de l’installeur debian (quand on ne choisi pas gtk) c’est aussi l’interface de configuration des paquets (comme avec dpkg-reconfigure) donc ça doit pas être si compliqué que ça.
Les menus fait à la main c’est plus proche des scripts type smxi, non ?
Je pense qu’il serait intéressant d’avoir un couplage faible entre l’interface d’entrée utilisateur et le reste du script. Ça te permettrait (a terme) de proposer une interface dialog, xdialog, gtk-dialog ou autre sans perte de fonctionnalité.
Et pour ça je te conseil d’inverser la dépendance. Actuellement ton script appel des méthodes genre installer_nginx() qui vont appeler dialog (ou le menu on s’en fiche).
Ce qu’il faudrait c’est a mon humble avec, faire un script qui demande à l’utilisateur les informations (via ce que tu veux) et qui appel une méthode installer_nginx() en lui passant tout les paramètres dont il a besoin.
Ce n’est pas plus compliqué c’est juste une autre organisation. Ensuite soit tu fait un script qui sait gérer différentes interfaces graphiques soit tu fait plusieurs scripts (hostathome-cli, hostathome-gtl, hostathome-dialog, etc).
Comme je trouvais ça pas très clair (et que je me suis mis à faire du graphviz il y a peu) j’ai fait un petit schemas de tout ça.
Dans l’image, les solutions 1 et 2 montrent comment ça doit fonctionner avec de l’inversion de dépendance. Les solutions 3 et 4 montrent comment avoir différentes interface en restant sur l’organisation actuelle.
Je comprend l’idée. Ça ne devrait pas être bien compliqué, juste assez ch*** à faire .
Par contre cela suppose des fonctions pour récupérer des informations pour chaque service (le nom de domaine n’est pas forcément le même pour différents sites), et ce à l’aide soit de dialog, soit de l’interface plus brute.
Remarquez, à long terme, ça divise ainsi le programme entre son moteur, et l’interface : cool!
[quote=“thuban”]Bon je vais voir comment rendre les choses pas trop embrouillantes avec 2 scripts 
J’ai testé le script sur mon Raspberry pi, donc raspbian, sans soucis. Donc tu peux y aller [/quote]
Alors là bravo et il devient indispensable que tu transfères au moins une référence à ta méthode sur le wiki dans “installer un serveur” C’est vraiment un plus que tu viens d’ajouter au raspberry 
@ggoodluck : ne te retiens pas 
Bon j’ai commencé, ça ne pose pas de soucis.
Par contre, tel que je vois les choses, c’est assez agaçant pour récupérer les infos avant de configurer un service. Il faut prévoir à la fois une interface dialog et une interface sans!
Re,
[quote=“thuban”]@ggoodluck : ne te retiens pas
Bon j’ai commencé, ça ne pose pas de soucis.
Par contre, tel que je vois les choses, c’est assez agaçant pour récupérer les infos avant de configurer un service. Il faut prévoir à la fois une interface dialog et une interface sans![/quote]
Ce n’est pas non plus une obligation, il y a trop longtemps que je ne programme plus pour pouvoir juger de la somme de travail. Mieux vaut une seule version peaufinée que deux à peu près ou difficile à maintenir
Séparer le moteur de l’interface est une excellent idée!
Mais pour demander à l’utilisateur d’indiquer quel est son nom de domaine et autres informations, il faut se décider entre dialog ou pas. Peut-être Misterfreez avait une autre pensée en tête que celle que j’ai comprise aussi?
1 : on choisi via une option ou alors il prend l’interface qui est installée (s’il trouve enity, il prend zenity, sinon s’il trouve gtk-dialog, il le prend, sinon… etc) ou …
Cette architecture ne résoud pas pour toi le choix de quelle interface graphique tu souhaite, elle te permet juste d’en changer facilement ou d’en avoir plusieurs.
Il faut prévoir ce que tu veux prévoir. Tu choisi la liste des interfaces que tu veux supporté et tu gère chacune ça tu ne peux pas y échapper.
La seule différence c’est que ce qui est très compliqué avec l’architecture précédente devient simple.
D’un point de vu plus architectural (du point de vu des concepts), prend le temps de te poser la question à quoi sert chaque fonction et ce qu’elle fait. Tu va voir que tes fonctions en font trop (ma fonction install_ssh(), installe le paquet ssh, demande à l’utilisateur des infos, prend en compte ces infos, redemande encore quelques info les prends en compte) alors qu’avec l’autre solution, ta fonction install_ssh(), installe ssh avec les paramètres que l’on lui passe et elle est appellé par une méthode qui récupère juste les informations d’une manière ou d’une autre.
Dernier point mais assez important, ça permet d’implémenter la killer feature de l’installeur ubuntu : poser toutes les question avant de commencer l’installation. C’est hyper pratique pour ne pas avoir à rester devant son écran à attendre qu’un traitement se finisse alors qu’on sait déjà quelles questions vont être posées ensuite et que les réponses ne dépendent pas du traitement en cours.
Je me suis un peu égaré… Bon pour commencer doucement gère une interface, choisi celle que tu veux et implémente là, ensuite on verra pour le reste.
Oui, ça j’ai bien vu 
.
Du coup ça sera déjà bien de séparer la procédure d’installation de la demande d’informations, pour tout un tas de raisons dont celle que tu dis plus haut entre autre.
De toute façon vu comment est le script actuellement, peu importe l’interface, car cette dernière pourra toujours faire appel au script en lui disant “installe nginx avec cette config”.
J’y vois plus clair maintenant. Plus qu’à prendre le temps de le faire, et je vous embête après.
Merci à tous!
Exact et tu peut faire l’inverse tester ton interface en lui faisant lancer des fonctions qui ne font rien. Par exemple si tout les fonctions d’installation/configuration sont dans un fichier functions.sh, tu peut écrire un fichier fake.sh qui déclare les même noms de fonctions et qui affichent juste le nom de la fonction avec la liste des paramètres. Tu source un fichier ou l’autre en fonction de si tu veux faire un test de l’interface ou pas.
Ça y est, le fond et la forme sont séparés.
Actuellement seul dialog est proposé comme interface.
Les logs sont actifs par défaut, et le script génère un rapport contenant les ports à ouvrir et autres informations sur les DNS.
C’est une réécriture toute fraîche, qui n’est certainement pas dénuée de bug.
À voir donc, les fichiers hah-engine.sh et hostathome-dialog.sh , toujours sur hg.yeuxdelibad.net/hostathome
Salut,
Je viens de lire le TODO et si roundcube voit le jour je vais pouvoir me séparer de mon Synology
Je suis chiant mais ça valait le coup, non ?
Ton code est astucieux et nettement plus sophistiqué, mais en même temps j’ai l’impression que chaque méthode est plus simple car elles sont plus courtes, sont mieux découpées et ont de mécaniques basse (plus de sed et de grep à tire larigot). Par contre j’ai encore quelques améliorations à te proposer (moins architecturales donc moins contraignantes à mettre en place), mais ce sera pour un autre jour parce que d’une je suis fatigué et de 2 je suis fatigué (non je ne fais pas du teasing pour rien).
[quote=“MisterFreez”]Je suis chiant mais ça valait le coup, non ?
Ton code est astucieux et nettement plus sophistiqué, mais en même temps j’ai l’impression que chaque méthode est plus simple car elles sont plus courtes, sont mieux découpées et ont de mécaniques basse (plus de sed et de grep à tire larigot). Par contre j’ai encore quelques améliorations à te proposer (moins architecturales donc moins contraignantes à mettre en place), mais ce sera pour un autre jour parce que d’une je suis fatigué et de 2 je suis fatigué (non je ne fais pas du teasing pour rien).[/quote]
Oui ça en vaut le coup! Je n’ai pas la formation en informatique que tu as, et ces conseils sont bons à prendre. Après j’en fais bien ce que je veux . Au départ je ne voulais pas avoir plusieurs fichiers séparés, mais tel qu’est le script actuellement, c’est un compromis qui me va.
Repose-toi, ton rapport attendra bien quelques jours, j’ai du boulot en attendant. Et puis parfois, le code, c’est comme la pâte à crêpe, faut le laisser reposer un peu lui aussi.
@ggoodluck : Ce qui m’embête avec roundcube, c’est mysql. Mais ça ne doit pas être insurmontable. Ça attendra la phase post-test.
Je savais bien que j’avais fait une conn****, le ssl ne s’installait pas à cause d’une erreur de syntaxe pour dialog.
J’en ai profité pour passer à owcloud 6.
Je ne comprends pas pourquoi tu mélange la sortie standard et d’erreur quand tu écris dans ton rapport ça n’a pas d’intérêt. Tu pourrais aussi améliorer la lisibilité avec une fonction comme celle là : paste.isalo.org/160
Aucun intérêt en effet.
Je me disais bien qu’il fallait une fonction pour ça! Merci, c’est pas mal du tout ce que tu proposes, j’aime bien.
Je pense que toi aussi tu n’aime pas trop ça :
REWRITEHTTPS="
server {
listen 80;
server_name $NOMDHOTE;
rewrite ^ https://\$server_name\$request_uri? permanent; # enforce https
}"
Ça peut être remplacé par :
function assign () {
read -rd '' "$1"
}
assign REWRITEHTTPS <<EOF
server {
listen 80;
server_name $NOMDHOTE;
rewrite ^ https://\$server_name\$request_uri? permanent; # enforce https
}
EOFLe heredoc c’est plus agréable
Ça peut aussi te servir dans la partie dialog avec les herestring.
Ça évite de faire des evals (c’est dangereux les eval quand on peut les éviter c’est mieux).
Tu m’en apprends encore, merci
Je ne connaissais pas cette option pour read. En gros ça rajoute des [mono]’’[/mono] de chaque côté de ce qu’on lui passe. Mais l’option -r n’est pas explicité dans l’aide de read. Ça fait quoi?
Mieux que les [mono]eval[/mono] en effet. Les 3 [mono]<<<[/mono], c’était voulu ou c’est une syntaxe que je ne connais pas encore?
Merci de prendre le temps de lire le code et corriger ces fragilités 
[quote=“man bash”] read [-ers] [-a tableau] [-d délimiteur] [-i texte] [-n nb_car] [-N nb_car] [-p invite] [-t délai] [-u fd] [nom …]
Une ligne est lue depuis l’entrée standard ou à partir du descripteur de fichier fd fourni en argument à l’option -u, puis le premier mot de cette ligne est affecté
au premier nom, le second mot au second nom, et ainsi de suite avec les mots restants et leurs séparateurs affectés au dernier nom. S’il y a moins de mots lus dans le
flux d’entrée que de variables, des valeurs vides sont affectées à celles restantes. Les caractères contenus dans la variable IFS sont utilisés pour découper la ligne
en mots. Le caractère contre-oblique () permet de supprimer toute signification spéciale pour le caractère suivant et autorise la continuation de lignes. Les
options, si fournies, ont les significations suivantes :
-a tableau
Les mots sont affectés aux indices successifs d’une variable tableau de nom tableau, en commençant à 0. tableau est détruit avant que de nouvelles valeurs ne
soient affectées. Les autres arguments nom sont ignorés.
-d délimiteur
Le premier caractère de délimiteur est utilisé pour terminer la ligne de saisie, plutôt qu’un changement de ligne.
-e Si l’entrée standard provient d’un terminal, la bibliothèque readline (consultez READLINE ci-dessus) est utilisée pour obtenir la ligne. Readline utilise les
configurations d’édition en cours (ou par défaut, si l’édition de ligne n’était pas préalablement active).
-i texte
Si readline est utilisée pour lire la ligne, texte est placé dans le tampon d’édition avant le début de l’édition.
-n nb_car
read s’arrête après avoir lu nb_car caractères plutôt que d’attendre une ligne complète en entrée, mais un délimiteur est respecté si moins de nb_car carac‐
tères ont été lus avant le délimiteur.
-N nb_car
read s’arrête après avoir lu exactement nb_car caractères plutôt que d’attendre une ligne complète en entrée, sauf si une fin de fichier (EOF) est rencontrée
ou si read dépasse son délai de réponse. Les délimiteurs rencontrés en entrée ne sont pas pris en compte et n’entraînent pas la fin de read avant que nb_car
caractères n’aient été lus.
-p invite
Afficher invite sur la sortie d’erreur standard, sans caractère final de changement de ligne, avant d’essayer de lire toute nouvelle saisie. L’invite est affi‐
chée seulement si l’entrée vient d’un terminal.
-r La contre-oblique n’agit pas comme un caractère d’échappement. La contre-oblique est considérée comme faisant partie de la ligne. En particulier une
contre-oblique suivie d’un changement de ligne n’est pas considérée comme une continuation de ligne.
-s Mode silencieux. Si une entrée arrive à partir d’un terminal, les caractères ne sont pas affichés.
-t délai
Conduire read à expirer et renvoyer un échec si une ligne complète en entrée n’a pas été lue dans le délai en secondes. délai est un nombre décimal avec éven‐
tuellement des chiffres après la virgule (NdT : point en l’occurrence). Cette option n’est effective que si read lit l’entrée à partir d’un terminal, d’un
tube, ou depuis un autre fichier spécial ; elle n’a aucun effet lors de la lecture d’un fichier normal. Si délai est nul, read termine avec succès si une
entrée est disponible pour le descripteur de fichier indiqué, en échec sinon. L’état final est supérieur à 128 si le délai est dépassé.
-u fd Lire l’entrée à partir du descripteur de fichier fd.
Si aucun nom n'est fourni, la ligne lue est affectée entièrement à la variable REPLY. Le code renvoyé est zéro, sauf si une fin de fichier (EOF) est rencontrée, si
read dépasse son délai de réponse (auquel cas le code renvoyé est plus grand que 128) ou si un descripteur de fichier incorrect est fourni en argument de -u.[/quote]
Le [mono]-d ‘’[/mono] c’est parce que sinon il ne va lire que la première ligne.
Le [mono]-r[/mono] c’est parce que sinon tu peut avoir des choses bizarres avec \b par exemple.