03-02-2020, 11:02:31
Je vais détailler un peu plus.
En fait, la norme c'est d'avoir un paquet (.deb) serveur et un paquet client ainsi que des exe distincts.
Là, tu as un script qui gère les 2. Ca peut paraitre sympa pour un utilisateur débutant... mais c'est finalement une couche supplémentaire pour faire la même chose et ça va embrouiller ceux qui sont plus expérimentés.
Dans tous les cas, l'utilisateur va devoir utiliser la ligne de commande et au lieu de faire "apt-get install" (ou via une GUI) qui est quand même vachement standardisé, il va devoir lancer ton script.
La, si on met une doc dans le wiki pour installer la partie serveur, ton script sert à rien.
Y'a 2 intérêt que je vois à un script serveur (et ça devrait se cantonner à ça) :
- récupérer le port du serveur de cache (utile surtout si il a été customisé)
- configurer un cron
Du coup, ça sera l'installation du paquet qui aura pour dépendance cron-apt et apt-cacher-ng.
Si on peut éviter (sauf cas vraiment à la marge : par exemple, la GUI primtuxstore pilotera apt) d'inclure des installations de paquet dans des scripts, c'est mieux.
Pour les dépendances, je suis assez stricte car on supporte plusieurs versions de Primtux basés sur des Debian/Ubuntu différentes et par expérience, moins on a de dépendances et moins on est susceptible d'avoir des blagues lié à un environnement particulier.
Ben, justement : si on lance ton script plusieurs fois, il se passe quoi ?
Imaginons par exemple que pour des raisons de sécu, le gestionnaire du parc décide de changer de port ou que le serveur a changer d'IP.
Il faut que ton script puisse avoir un argument (optionnel : sinon il prend 3142 par défaut) sur le port et mette à jour ton fichier.
Pour les mêmes raisons déjà évoqués tout à l'heure, je suis pas fan. Apt fait très bien son job, ça sert à rien de mettre une couche d'abstraction supplémentaire.
Mon avis est assez tranchant concernant la POO : ça entraine plus de soucis que ça n'en résoud.
Le dev pour moi, peut se résumer à : 1, des structures de données et 2 des algorithmes (des méthodes) :La POO mélange les 2 concepts en 1 et on le voit bien avec les nouveaux langages, c'est un concept en perte de vitesse car finalement peu convaincant.
Des méthodes courtes qui font des actions précisent, c'est la clé d'un truc qui marche (peu d'effets de bord car tout est cloisonné), c'est potentiellement testable (on peut facilement tester unitairement chaque chose), les correctifs sont souvent plus petits et donc facile à comprendre dans un diff git.
En fait, la norme c'est d'avoir un paquet (.deb) serveur et un paquet client ainsi que des exe distincts.
Là, tu as un script qui gère les 2. Ca peut paraitre sympa pour un utilisateur débutant... mais c'est finalement une couche supplémentaire pour faire la même chose et ça va embrouiller ceux qui sont plus expérimentés.
Dans tous les cas, l'utilisateur va devoir utiliser la ligne de commande et au lieu de faire "apt-get install" (ou via une GUI) qui est quand même vachement standardisé, il va devoir lancer ton script.
La, si on met une doc dans le wiki pour installer la partie serveur, ton script sert à rien.
Y'a 2 intérêt que je vois à un script serveur (et ça devrait se cantonner à ça) :
- récupérer le port du serveur de cache (utile surtout si il a été customisé)
- configurer un cron
Du coup, ça sera l'installation du paquet qui aura pour dépendance cron-apt et apt-cacher-ng.
Si on peut éviter (sauf cas vraiment à la marge : par exemple, la GUI primtuxstore pilotera apt) d'inclure des installations de paquet dans des scripts, c'est mieux.
Pour les dépendances, je suis assez stricte car on supporte plusieurs versions de Primtux basés sur des Debian/Ubuntu différentes et par expérience, moins on a de dépendances et moins on est susceptible d'avoir des blagues lié à un environnement particulier.
Citation :Il crée un fichier avec un nom bien spécifique (00aptproxyANC), ce serait incroyable qu'un user ait mis un fichier perso avec un tel nom...
Ben, justement : si on lance ton script plusieurs fois, il se passe quoi ?
Imaginons par exemple que pour des raisons de sécu, le gestionnaire du parc décide de changer de port ou que le serveur a changer d'IP.
Il faut que ton script puisse avoir un argument (optionnel : sinon il prend 3142 par défaut) sur le port et mette à jour ton fichier.
Citation :J'avais pensé ajouter à l'install client de rajoute le paquet python-nmap et / ou pip install nmap.
Pour les mêmes raisons déjà évoqués tout à l'heure, je suis pas fan. Apt fait très bien son job, ça sert à rien de mettre une couche d'abstraction supplémentaire.
Citation :Sinon, le script suffit il ainsi ? Ou faut il le réécrire avec des classes ?
Mon avis est assez tranchant concernant la POO : ça entraine plus de soucis que ça n'en résoud.
Le dev pour moi, peut se résumer à : 1, des structures de données et 2 des algorithmes (des méthodes) :La POO mélange les 2 concepts en 1 et on le voit bien avec les nouveaux langages, c'est un concept en perte de vitesse car finalement peu convaincant.
Des méthodes courtes qui font des actions précisent, c'est la clé d'un truc qui marche (peu d'effets de bord car tout est cloisonné), c'est potentiellement testable (on peut facilement tester unitairement chaque chose), les correctifs sont souvent plus petits et donc facile à comprendre dans un diff git.