Bonjour,
Je crée un meta-paquet .deb qui va rajouter une entrée sur /etc/hosts.
Vu que c’est pas une opération anodine, je préfère éviter d’utiliser des scripts de postinst et prerm pour faire ça.
Je me dis que chez debian, y’a toujours un outil pour faire ça propre mais lequel ?
D’avance, merci !
Bonjour,
Il me semblait que les méta-paquets était des paquets avec que des dépendances, mais sans aucun contenu.
La première idée qui me vient en tête pour faire ça proprement dans Debian, c’est le DNS.
Merci @Almtesh de ta réponse.
Quand je pensais meta-paquet c’était plus dans le sens ou ça ne faisait rien seul mais tu as sans doute raison.C’est plus une lib, même si y’a que des fichiers de conf.
Je vais essayé de te donner un peu plus de contexte.
Mon besoin est pour la distribution Primtux (basé sur Debian).
On essai, au sein de la distrib de mettre à disposition des contenu web accessible en offline.
Jusqu’à présent, ça fonctionnait bien mais les dernières versions de chrome et Firefox bloque pas mal de choses.(requète XHR notamment)
L’idée était donc de délivrer ce contenu via nginx.
On rajoute via la « lib » une conf nginx et pour que ça soit un peu plus agréable, un nom de domaine.
La finalité, l’utilisateur peut accéder à son applicatif web via une url du genre http://primtux.app/appli
Si tu veux avoir plus de détail : http://forum.primtux.fr/viewtopic.php?pid=23319#p23319
Bref, ça me semble un peu lourd d’avoir un serveur DNS juste pour ça.
J’ai créé un source en rapide pour se faire une idée : Ferry Jérémie / lib-nginx-primtux · GitLab
Attends, tu veux dire que primtux.app renverrait vers l’hôte local ? Le nom de domaine primtux.app ne vous appartient pas, c’est assez étrange de le détourner et je ne vous le conseille pas.
Essaie de choisir un autre nom ou utilise directement localhost, je trouve que c’est plus clair qu’on sache que c’est bien un site local, l’Internet est déjà assez confusant comme ça sans qu’on ait accès à un site qui ressemble à un site sur Internet alors que ça ne sort pas de la machine locale.
Oui, c’était un exemple.
Si c’était primtux.app.local (ou primtux.app.localhost), ça te paraîtrai déjà mieux ?
Bonjour,
Le TLD .local est réservé à l’usage de mDNS. Tu peux l’utiliser si ton service s’annonce sur le réseau via mDNS (avahi)
.localhost est acceptable mais est-ce bien nécessaire d’installer et de faire tourner nginx pour une appli web qui doit s’exécuter localement ?
Je connais pas bien avahi mais si je comprend bien ça pourrait correspondre à mes attentes ? (ajouter un fichier de conf avahi)
Su tu as un exemple, je suis preneur.
Tu proposes quoi à la place de Nginx? Je rappel que les applis locales sont bloqués sur le protocole file.
Ex: si tu lances par ex https://github.com/mothsART/editInteractiveSVG sans serveur, tu vas être bloqué avec des appels du genre :
Access to XMLHttpRequest at ‹ file:///home/jferry/projects/editInteractiveSVG/examples/organes.html › from origin ‹ null › has been blocked by CORS policy: Cross origin requests are only supported for protocol schemes: http, data, chrome, chrome-extension, chrome-untrusted, https.
Je ne vais pas décortiquer ton code mais visiblement c’est du python qui lance déjà son propre serveur HTTP. Je comprends donc pas ton histoire de protocole « file » et de XHR
L’exemple était peut-être mal choisi : en effet, pour ce projet, j’ai fait en rapide un mini-serveur en python piloté par systemd pour une demande d’inclusion sous archlinux.
Pour Primtux, ou il y aura potentiellement n sites en local qui pourront tourner en //, un nginx déjà présent si CTparental est installé, je suis moins emballé.
Bonjour,
pourquoi donc ?
un petit echo "localhost primtux.localhost" >> /etc/hosts # ou echo "localhost primtux.localhost" | tee -a /etc/hosts dans le postinst ne paraît pas si dangereux à première vue
Pour moi l’outil propre pour ce genre d’opération, c’est justement les scripts postinst/prerm 
Mais probablement à générer via les outils fournis par debhelper, appelés dans le fchier debian/rules du paquet source.
Ce n’est pas forcément si simple à gérer bien proprement, en particulier avec le comportement rapidement bancal de echo en fonction du shell utilisé.
Et il faut ensuite pouvoir retirer la ligne du fichier lors de la désinstallation du paquet.
En fait ce qu’il nous manque ici c’est un répertoire /etc/hosts.d/, comme on a pour pas mal d’autres fichiers de configuration qui pourraient être éditées par plusieurs sources. Auquel cas ce serait trivial de fournir via le paquet .deb une entrée dans un fichier dédié /etc/hosts.d/primtux.
Avec sh ou bash, ça doit faire sensiblement la même chose (pas essayé dash, zsh ou d’autres). Sinon spécifier le shell à utiliser dans le script postinst.
sed -i '/localhost primtux.localhost/d' dans le postrm ?
+1
primtux.app.localdomain plutôt car localhost c’est un host pas un domaine.
ensuite si le lien est directement file://path/to/file il n’y a pas de raison que ça ne marche pas. L’exemple que tu as cité est une cross reference, en gros un lien http/https qui pointe en réalité sur un fichier local; et effectivement mieux vaut interdire ce genre de chose.
Bidouiller avec le fichier host ce n’est pas non plus une bonne chose.
si tu veux vraiment un DNS, la solution de Bruno me semble plus pertinente. Eventuellement l’utilisation de DNSMasq pourrait etre envisagé, mais tout ça reste du bricolage.
les lien file:// sont utilisable directement , ne serait ce que firefox qui est capable de sauvegarder une page web complète. Il sufit de créer une page HTML statique avec un menu de lien vers tes contenus.
Par contre si tes contenus sont dynamique, il te faudra un interpréteur, serveur web ou autre.
mais c’est une mauvaise idée de faire du contenu dynamique en offline.
Non. Il ne vaut mieux pas utiliser .localdomain et localhost es bien un domaine utilisable localement.
Voir RFC2606 et RFC6761
Ce n’est pas forcément une mauvais e idée si l’on utilise le serveur web intégré du langage utilisé (python php, NodeJS, …). Cela permet de le lancer à la demande et de l’arrêter quand on quitte l’application.
Il suffirait de l’utilisation d’un site web concu pour ce gener de cas pour avoir une faille importante. Un simple script dans la page web suffirait à compromettre le pc de façon irr&émédiable, sans meme le voir.
Ce sont des applications web fournies par la distribution. Cela ne présente donc pas plus de risque que n’importe quel logiciel.
Bon, y’a eu tout un coup plein d’activités.
Déjà merci à tous.
@anon96191775 a bien cerné mon appréhension. Je pars toujours du principe que si on peut faire autrement que postinst/preinst, faut le faire. Y’a en effet, énormément de cas ou l’ajout d’un fichier de conf est suffisant. (l’ex du /etc/hosts.d/primtux)
Vu les réponses, je pense qu’au final, dans mon cas j’ai pas trop le choix.
@Zargos : y’a plein de cas ou le dynamique n’a pas forcément besoin d’être géré côté serveur.
Dans mon cas, j’ai des fichiers html qui correspondent chacun à des projets et donc, en les ouvrant, ça va enrichir mon interface.
En soit, ça ne nécessite rien côté serveur (et du coup, c’est safe. Je vais essayé avec file:// sur mon fetch mais j’ai des doutes.
@anon70622873 m’a convaincu pour le localhost.
@Zargos : déso de la réponse tardive mais j’ai testé avec « file:// » et les réponses sont sans appel :
Sous chromium :
Access to XMLHttpRequest at ‹ file:///home/jferry/projects/editInteractiveSVG/examples/organes.html › from origin ‹ null › has been blocked by CORS policy: Cross origin requests are only supported for protocol schemes: http, data, chrome, chrome-extension, chrome-untrusted, https.
Sous Firefox :
Blocage d’une requête multiorigines (Cross-Origin Request) : la politique « Same Origin » ne permet pas de consulter la ressource distante située sur file:///home/jferry/projects/editInteractiveSVG/examples/weather.html. Raison : la requête CORS n’utilise pas http.