C’est une solution assez compliqué dès que l’application chercher à faire de la réécriture d’url (c’est ce qui m’a fait abandonner cette solution). Sinon il suffit d’ajouter des “sections” [mono]location[/mono] dans la conf de nginx pour le faire (tu peut même le faire par [mono]include[/mono]).
Si tu es en manque d’inspiration j’ai 2 idées pour toi
[ul]
[li]automatiser les installations : pouvoir donner à ton script un fichier qui décris l’installation. C’est très pratique si ton script le génère aussi. Ça permet, de reproduire facilement les installations et ça permet à celui qui est en galère de fournir ce fichier quand il pose des questions.[/li]
[li]générer un compte rendu d’installation : c’est pas la même chose, là il s’agit de logguer tout ce que fait le script (du moins tout ce qu’il fait d’utile et pourquoi), pareil ça simplifie l’aide de ceux qui ont des problèmes[/li][/ul]
[quote=“MisterFreez”]
C’est une solution assez compliqué dès que l’application chercher à faire de la réécriture d’url (c’est ce qui m’a fait abandonner cette solution). Sinon il suffit d’ajouter des “sections” [mono]location[/mono] dans la conf de nginx pour le faire (tu peut même le faire par [mono]include[/mono]).[/quote]
C’est ce que j’ai pensé au départ, mais ça ferait un fichier de configuration de nginx avec plusieurs [mono]include[/mono] pas forcément utilisés. Donc bon, c’est pas grave s’il n’y a rien au bout de l’include, mais c’est pas propre pour un débutant qui cherche à comprendre sa config.
Ma deuxième idée serait de proposer cette possibilité, et d’ajouter des lignes commentées dans le fichier de config : à l’utilisateur de les placer où il faut. Mais on perd un peu l’intérêt du script.
Ça c’est super intéressant! En python je saurais faire, un bash c’est autre chose, il faut que je prenne le temps d’y réfléchir.
C’est dans le TODO. Mes premiers essais étaient infructueux. Avec dialog, c’est trop galère de rediriger des logs correctement.
[quote=“thuban”][quote=“MisterFreez”]
C’est une solution assez compliqué dès que l’application chercher à faire de la réécriture d’url (c’est ce qui m’a fait abandonner cette solution). Sinon il suffit d’ajouter des “sections” [mono]location[/mono] dans la conf de nginx pour le faire (tu peut même le faire par [mono]include[/mono]).[/quote]
C’est ce que j’ai pensé au départ, mais ça ferait un fichier de configuration de nginx avec plusieurs [mono]include[/mono] pas forcément utilisés. Donc bon, c’est pas grave s’il n’y a rien au bout de l’include, mais c’est pas propre pour un débutant qui cherche à comprendre sa config.
Ma deuxième idée serait de proposer cette possibilité, et d’ajouter des lignes commentées dans le fichier de config : à l’utilisateur de les placer où il faut. Mais on perd un peu l’intérêt du script.[/quote]
Tu peut utiliser un wildcard pour inclure tous les fichiers d’un dossier donné.
Ça c’est super intéressant! En python je saurais faire, un bash c’est autre chose, il faut que je prenne le temps d’y réfléchir.[/quote]
La technique la plus simple pour le faire c’est d’arrêter d’appeler directement xdialog, mais d’utiliser des fonctions à toi qui selon si on a passé ou non un fichier de conf vont utiliser xdialog ou donner directement la réponse. Ça permet aussi d’avoir une installation partiellement automatisée.
C’est dans le TODO. Mes premiers essais étaient infructueux. Avec dialog, c’est trop galère de rediriger des logs correctement.[/quote]
J’ai pas regardé comment il marche mais ça doit pouvoir se faire
Oui j’ai commencé rapidement 2 ou 3 trucs, ça impose effectivement de revoir la logique du script. Sinon ça n’a pas grand intérêt, mis à part pré-cocher les cases et valider automatiquement.
Question : pour dropcenter, kriss , pluxml et blogotext, j’hésite à tout mettre en https plutôt qu’en http. En effet, il faut rentrer des mots pour se connecter à ses comptes.
Que me conseillez-vous? Cela en vaut-il vraiment la peine? Ils transitent bien en clair sinon?
Suite à la suggestion de Misterfreez, j’ai commencé à bosser sur une version sans dialog, qui permettrait de lire un fichier d’instructions. C’est prometteur, moins joli, mais chouette.
Nouvelles de fin de week end. Une nouvelle version de hostathome est “terminée” et ne demande plus qu’à être testée. Le fichier s’appelle hostathome2.sh [1], j’attend vos commentaires avant de remplacer l’ancien par le nouveau.
Au menu :
Plus de [mono]dialog[/mono], tout se fait directement en bash. Cela facilite les logs, et surtout permet d’implémenter l’idée de Michel.
Logs du scripts générés automatiquement
Les messages du type “ouvrir les ports” ou “copiez le contenu de mail.txt” sont enregistrés dans un fichier à part. Il serait bon de l’agrémenter à l’avenir.
Possibilité d’automatiser toute la procédure, en passant en argument à hostathome un fichier de configuration. Cela permet donc d’installer un serveur rapidement sur plusieurs machines. Je ne suis pas sûr de la démarche suivie pour faire ça, donc les propositions d’amélioration sont les bienvenues.
En gros, vous pouvez générer les certificats ssl sans avoir à agir pendant l’éxécution du script, installer les services de la même façon…
Pour les conseils, propositions d’amélioration, jets de pierre, c’est à vous de jouer
Petite question : bien que n’ayant pas lu en intégralité ton script (aîe pas tapé!), celui-ci offre t-il la possibilité de choisir les services a installer ou doit-on tout installer?
@M3t4linux : Justement, il permet d’installer uniquement les service que tu souhaites. Après il ne permet pas encore de choisir parmis plusieurs alternatives pour un même service (exemple : nginx seul, pas apache de proposé).
@Misterfreez : oui on s’en passe très bien. As-tu regardé au fichier hostathome2.sh? Du coup si d’ici le week end personne ne m’a rapporté de gros bugs, je remplace l’ancien par le nouveau sans dialog.
Si ça ne représente pas trop de travail, ce serait dommage d’abandonner la version dialog, elle a quelque chose de rassurant pour les adeptes du graphique
Je ne l’ai pas lu (pourquoi ne pas avoir créé une branche ?).
Je me suis probablement mal exprimé au sujet de dialog. Je ne l’aime pas parce que j’aime pas les ihm, mais je comprends que ça peut plaire et je dis qu’il est tout à fait possible de le garder.
[quote=“MisterFreez”]Je ne l’ai pas lu (pourquoi ne pas avoir créé une branche ?).
[/quote]
Parce que je ne suis pas encore très à l’aise avec les gestionnaires de version. Mis à part pull, update, push, reverse et commit…
Sinon oui, c’est possible de garder (juste les logs qui ne seront pas actifs). En attendant la nouvelle version est compatible avec plus de terminaux, ne requiert pas l’installation d’un programme tiers, peut être stoppée à tout moment avec ctrl-c… Et en fait, je ne suis âs sûr que dialog soit vraiment plus rassurant pour un débutant : il faut piger que c’est avec espace que l’on coche, et non avec entrée. Pour changer de boutons il faut utiliser TAB. C’est quand même moins explicite que de mettre des numéros et appuyer sur entrée.
Je ne pensais pas à moi en te suggérant de conserver la version dialog. Vous me connaissez assez pour savoir ce que je pense du graphique pour gérer mon système, mais je pense que si l’on pouvait conserver sans trop de mal les deux versions, nombre de newbies seraient moins effrayé par dialog, quite à les faire passer sous la version bash s’ils ont des ennuis et que tu as besoin des logs pour les dépanner
[quote=“ggoodluck47”]
Je ne pensais pas à moi en te suggérant de conserver la version dialog.[/quote]
Je sais bien
C’était pour avoir votre avis sur le côté “rassurant” de la nouvelle interface. C’est trop “brut de pomme?”
[quote=“thuban”][quote=“ggoodluck47”]
Je ne pensais pas à moi en te suggérant de conserver la version dialog.[/quote]
Je sais bien
C’était pour avoir votre avis sur le côté “rassurant” de la nouvelle interface. C’est trop “brut de pomme?”[/quote]
Non, mais c’est moins “flatteur” et un newbie ne sait pas quoi faire avec les logs, tu ne lui apporte donc pas grand chose
Question : A ton avis ce script (le bash) fonctionnerait-il sous “raspian” ?
