Ici on n'a que votre IP, votre pseudo et votre adresse mail que nous ne traitons pas.
Quand vous êtes enregistrés, une seule requête permet de vous afficher les messages que vous n'avez pas lus.
Primtux8 est arrivée! Rendez-vous ici
Vous pouvez désormais vous inscrire librement en cliquant sur "S'enregistrer".

Note de ce sujet :
  • Moyenne : 0 (0 vote(s))
  • 1
  • 2
  • 3
  • 4
  • 5
Créer un serveur de cache apt pour les parcs utilisant primtux
#17
mothsart a écrit :Je vais détailler un peu plus.
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.
Oui on est d'accord, le but c'est d'avoir un GUI, mais je ne vais pas me lancer dans son codage avant de savoir si le script est accepté ou non.

Dès qu'il sera validé, je coderai en GTK et ferai un DEB
Par contre, je trouve plus concret de laisser qu'un script avec au démarrage un client / serveur


mothsart a écrit :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
OK pour le cron, je mets ça en place,
la conf du port je m'en doutais d'où son passage sous forme d'une variable
Par contre, où ça va devenir chaud c'est de détecter depuis le client le serveur si on ne connait ni son IP, ni son port....
Récupérer le port ne pose pas de soucis, mais sa transmission au client , c'est quasi impossible . Car même si stocké dans un fichier, je ne vois pas comment le client va scanner tous les PC du parc à la recherche de ce fichier (?)



Citation :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.
Devrait pas poser trop de soucis vu que l'IP et le port passe en variable
Donc si l'user relance le script car l'ip du serveur a changé, il faut bien que le fichier précédent soit effacé et remplacer par le nouveau. Ce que fait le script actuel.

OK pas de classes, je laisse tomber et garde la structure actuelle
Merci pour les remontées, ça permet d'évoluer Wink
-----------------------------------------------
Classe unique (du CP au CM2, direction)
All you need : #!/bin/bash
Répondre


Messages dans ce sujet

Atteindre :


Utilisateur(s) parcourant ce sujet : 1 visiteur(s)