Script bash à Tester (encore)

Programmation
#1

Bonjour à tous,

Tout d’abord, je remercie MR Freeze pour ses précieux conseils lors de mes précédents posts :041 , mais je crains ne jamais avoir son niveau de maîtrise en bash (ou en informatique en général !).

Voici un script qui a pour but d’aider les admins microsoft (mes collègues de taf) à utiliser debian (intall + paramétrage de différents services).

Si quelqu’un a la courage monter une VM et de tester quelques services merci d’avance, sinon je ne tiens pas spécialement à recevoir de conseil sur la qualité intrinsèque de mon code. Je sais qu’il est trop long, qu’il est mal écrit, pas élégant mais c’est mon bébé et quasiment tout fonctionne (sauf l’interfaçage de squid avec l’AD, Magento pas vraiment testé et les inventaires de fusion inventory ==> probablement à cause de certif).
Ce que je souhaiterai pour mon noël (en retard) c’est que de bonnes âmes exécutent mon script, pas la peine de le lire (sauf si vous y tenez et que ça vous plaît) et me fassent des retours sur l’interface utilisateur (et me rapportent les bugs) :114

Il est prévu pour tourner sous Jessie x64 NetInstall + outils de base du système + serveur ssh…

Bonne année !
SuperServeur3.9.9.5.txt (294 KB)

#2

Bonsoir,

Bon si quelqu’un peut m’indiquer où poster (sur quel forum) pour avoir des réponses je suis preneur…

Merci d’avance

#3

Je découvre ce fil, et n’ai pas énormément de temps. Par curiosité, j’ai ouvert ton script, et voici quelques remarques rapides. Je m’y attellerai plus tard si je trouve le temps.

[ul][li]pour des raisons de compatibilités, il est préférable d’utiliser sh que bash ;[/li]
[li]sauf erreur de ma part, la ligne de coding: UTF8 n’est valable que pour Python, donc rien à faire ici ;[/li]
[li]si tu veux mettre une licence, mets-la correctement (tu peux trouver plein de tuto sur le net pour ça) ;[/li]
[li]si tu publies en Open Source, ton script a plus ou moins pour but d’être lu, alors soigne l’indentation, et ajoute des commentaires ;[/li]
[li]le motd indique “SuperServeur.bsh” : le ‘b’ est-il volontaire ? Les scripts bash ont l’extension bash. Et si tu passes en sh, l’extension est simplement sh ;[/li]
[li]le test [ $USER != root ] est pas portable en sh, et peux déranger sur des systèmes où le superutilisateur n’est pas nommé root. Préfère un test sur l’UID : [ “$UID” -ne “0” ][/li]
[li]tu testes si l’utilisateur utilise ssh et l’en empêche. C’est bien, mais il peut aussi utiliser telnet, voire teamviewer (déjà vu !) ;[/li]
[li]après, il y a des choses étranges de fonctions que tu commences à définir, mais qui ne se terminent pas, ou alors des définitions de fonctions moultement imbriquées. Par exemple ce bloc :

function EthQuest () { function Quest1 () { function testip () {
C’est moi ou il y a un truc qui ne va pas ? J’avoue ne pas avoir regardé en détails.[/li][/ul]

J’arrête là pour le moment.

A+
Moi

#4

Bonjour Dunatotatos,

Merci d’avoir pris le temps de regarder :023 , j’ai pris note des remarques, j’ai apporté quelques modifs au début du script.
En ce qui concerne les fonctions imbriquées, c’est le seul moyen que j’ai trouvé pour utiliser whiptail avec contrôle de saisie + retour arrière avec le bouton cancel sans sauter de question dans un questionnaire.
Il y a probablement une façon + élégante de procéder mais je ne la connais pas. Soit dit en passant, il faudrait effectivement que je supprime ethquest !

Concernant la portablité du script vers ksh ou sh je ne pourrais jamais avoir autant de fonctionnalités qu’avec bash et un script d’installation aussi complexe serait trop difficile à porter vers un autre os…

Merci encore pour tes remarques pertinentes :clap: !
SuperServeur3.9.9.4.txt (294 KB)

#5

J’ai encore jeté un oeil rapide aujourd’hui, et une remarque me vient à l’esprit. Il semblerait que la plupart de ton script soit de l’installation et de la configuration de paquets. Plutôt que d’écrire la configuration en dur dans ton script, il serait plus propre et plus lisible de faire un dossier séparé contenant les templates de ces configurations. Tu peux créer un “langage de template” permettant d’ajouter des variables dans tes templates de configuration que tu remplaces grâce à des sed. (ou peut-être quelque-chose de plus propre, si bison est porté en sh, par exemple).
Ça permet de séparer les modèles et le contrôleur dans ton script (si l’architecture MVC te dit quelque-chose), de simplifier la maintenance, voire de modifier facilement la configuration par défaut, et de rendre ton script modulaire.

Je regarde ton histoire de whiptail plus tard, je suis sûr qu’il y a moyen de faire mieux.

Un script de cette longueur, essaie de le diviser en plusieurs petits scripts. Il est indigeste, comme ça ^^ Si tu mets en place un langage de template, tu peux imaginer diviser ton projet comme ça :
[ul][li]un script qui prend un “contexte” (ie : des couples de clefs/valeurs), et qui crée un fichier de configuration à partir d’un template et du contexte ;[/li]
[li]un script par paquet qui vérifie son installation, l’installe le cas échéant, puis le configure en appelant le script précédant ;[/li]
[li]un script qui permet de rassembler les tâches redondantes du script précédent (DRY) ;[/li]
[li]il y a peut-être moyen de sérialiser un peu l’interface utilisateur, un script séparé serait approprié ;[/li]
[li]le script principal qui fait appel aux différentes parties les unes après les autres dans le bon ordre.[/li][/ul]

N’ayant pas lu totalement ton script, je ne suis pas sûr de la faisabilité d’une telle architecture. Tu es mieux placé que moi pour le savoir. Mais divise-le, c’est nécessaire ! L’avantage de l’architecture que je te présente est de pouvoir mettre en place un système de dépendance entre scripts voire de paralléliser les processus :007
Je ne sais pas à quel niveau de programmation tu es, mais fait bien attention à ne pas tomber dans le piège du débutant. QUand je parle de diviser ton script, ne le divise pas séquentiellement, mais sémantiquement. Un projet correctement divisé contient au final moins de lignes de code)
Franchement, pour un projet de cette ampleur, je n’aurais jamais pensé utilisé le bash. Ça a du être un boulot monstre et des heures d’arrachage de cheveux. (Quoique, j’ai plus tendance à m’arracher la barbe que les cheveux.)

A+
Duna

#6

Bonsoir,

Merci encore pour tes remarques et le temps que tu passes à répondre à mon post ainsi qu’aux autres posts dans la section programmation ! C’est juste impressionnant, quand je me balade sur le forum tu es partout et surtout extrêmement pertinent(e). BRAVO.

Si j’ai choisi de ne pas scinder le script en plusieurs dossiers c’est simplement parce que le but du projet est de rendre accessible au + grand nombre les services de base pour une infra réseau avec des outils Linux.
Je m’explique : si j’avais procédé comme tu me le suggères il aurait fallut que l’utilisateur du programme sache comment utiliser tar pour extraire le programme. ensuite il aurait dû fouiller dans un fichier README.txt pour savoir quel exécutable lancer et donc savoir utiliser nano ou vi, et enfin il aurait dû l’exécuter en tapant ./LeNomDeLexe.
Mais mon objectif est que l’admin Microsoft, habitué aux interfaces graphiques soit guidé et accompagné dans l’utilisation du script. C’est à dire qu’il puisse simplement utiliser le programme en le copiant avec un client SFTP et qu’il le lance avec la commande bash LeNomDuScript à partir d’une version NetInsall de Debian avec juste les utilitaires recommandés du systèmes et openssh-server installé lors de l’intall de OS.

L’objectif n’est donc pas spécialement de rédiger un code élégant et optimisé (il n’y a pas spécialement de calcul dans le script) mais plus d’automatiser l’install, la conf et dans une certaine mesure l’utilisation de certains services que je juge (peut-être à tord) basiques pour monter un SI.
==> pas d’install de paquet surnuméraires après l’install de l’OS et zéro compétences requises en ligne de commande pour lancer le script :stuck_out_tongue:

J’ai déjà essayé de convertir des admin Crosoft à l’utilisation/administration de linux sans succès aucun. Je m’y suis probablement mal pris alors j’ai changé mon fusil d’épaule et créé le projet SuperServeur, clairement des gars/nana comme toi ne sont pas la cible du projet (pas besoin :laughing: )…

Je te remercie tout de même pour tes suggestions qui ne tombent pas dans l’oreille d’un sourd, mais vu l’avancement du projet, que je mène seul depuis 3 ans en parallèle à d’autres projets musicaux entres autres je n’aurai pas le courage de remanier tout ça et qui plus est comme expliqué plus haut ce serait peut-être contre productif.

Pour info mon niveau de programmation est en dessous de tout et je ne sais même pas ce que signifie MVC ! Je fais ce que je peux avec mes moyens je suis plus admin sys que programmeur, lorsque je script dans mon taf c’est surtout pour des backups dons j’utilise scp, smbclient, samba, mysqldump et autres paquets du même genre. J’ai un niveau extrêmement modeste et je m’en rends compte mais j’aime la philosophie du libre et l’utilisation de debian en particulier. Je ne vois pas non plus ce que signifie diviser le script sémantiquement, tu as un niveau stratosphérique pour moi, j’ai un bac +2 équivalent à un bac -2 vu la gueule de la formation suivie (AFPA)…

Pour whitpatil (natif sous debian mais inférieur à dialog) j’ai peut être une idée, il faudrait unset les variables lues car le bouton cancel utilise la variable $? et si $?=1 alors les regex ont une valeur égale au fameux bouton cancel. Je regarderai quand j’aurai le temps (j’ai une famille et du taf donc pas beaucoup de latitudes pour ce genre de trucs).

Cordialement,

Vincentsan

#7

Arrête, je vais rougir ! Tes compliments me font plaisir, mais il y a bien meilleur que moi sur ce forum. Je ne fais pour le moment que des pâtés de sable.

Je comprends tes arguments pour la non-division du script. La plupart ne sont pas valables, parce-que tu as moyen de tout laisser dans un seul fichier, tout en divisant (template de configuration dans des variables au début du script, sérialisation par définitions de fonctions, …) Le seul argument valable à mon sens est que le refactoring demanderait bien trop de travail pour un résultat incertain. Je précise tout de même qu’écrire du code propre n’est pas directement lié à l’optimisation de l’utilisation des ressources d’un PC. D’ailleurs, on peut difficilement parler de Bash et d’optimisation ^^ Écrire du code propre permet de simplifier la maintenance (voire tout juste la rendre possible) que ce soit pour quelqu’un d’autre ou pour soi-même, d’améliorer la portabilité (le code & try, ça marche pour les petits scripts maisons qu’on utilise un jour et jette le lendemain, mais pas pour les projets distribués), simplifie le debugging, clarifie l’esprit, plante des arbres, termine les guerres et résoud les problèmes de faim dans le monde.

Pense juste à ces points la prochaine fois que tu codes un nouveau script. Personne n’a écrit un compilateur optimisé et lisible le premier jour, alors fais mieux pour chaque nouveau projet, et tu vas décoller ! (Pour info, ma formation n’a rien à voir avec l’informatique. Ce que je pense connaître, je l’ai appris via des tutos, de la documentation, beaucoup d’erreurs, et grâce aux membres de ce forum.)

Enfin, quand je parle de division sémantique plutôt que séquentielle, voici un exemple.
Imaginons ce script inutile :

echo $(( 1 + 2 )) echo $(( 1 + 3 ))

Une division séquentielle (par des fonctions) sertait ça :

[code]func1() {
echo $(( 1 + 2 ))
}

func2() {
echo $(( 1 + 3 ))
}

func1
func2[/code]
C’est inutile. Ça ne simplifie pas l’écriture, ça rajoute des lignes et n’optimise pas le temps d’exécution, la mémoire consommée ou une autre ressource.

Une division sémantique ressemble plutôt à ça :

[code]
print_sum() {
echo $(( $1 + $2 ))
}

print_sum 1 2
print_sum 1 3[/code]
Ici, la division a un sens, puisqu’une tâche répétitive a été sérialisée.
L’exemple est ici sans intérêt. Mais il faut imaginer que print_sum est une fonction un peu plus complexe, et que des erreurs se sont glissées dans le copier-coller lors de la tentative d’écriture du premier script ^^

Enjoy !

A+
Duna

#8

Hello, Dunatotatos,

J’ai fait un nouveau post ici :
https://www.debian-fr.org/whiptail-trucs-et-astuces-t54289.html

Si tu as une idée d’amélioration je t’en remercie !!!
J’ai pas encore eu le temps de regarder la sémantique… Mais promis ça viendra.

Merci pour tout :stuck_out_tongue:

#9

Hello,

Je suis un peu déçu lorsque je vois le nombre de téléchargement(s) du fichier. Je vais ouvrir un nouveau post e tourner ma requête différemment. En tout cas un grand merci à Dunatotanos !!!

A+

#10

Le peu de téléchargement vient certainement du fait que ton script est un gros truc que les gens n’ont pas envie de lire parce-qu’il est trop long. Et exécuter quelque-chose qu’on a trouvé sur Internet sans vérifier de quoi il s’agit, ce n’est pas spécialement recommandé…
(D’ailleurs, j’ai bien téléchargé ton script, l’ai ouvert pour voir un peu la gueule du code, mais me suis bien gardé de l’exécuter, surtout avec des droits root !)

Si tu veux des avis, poste des snippets, plutôt qu’un gros scripts, fais des copier-coller des interfaces, ou utilise n’importe quel moyen pour diviser un gros problèmes en moults petites questions. Et là, les réponses arriveront bien plus rapidement.