Salut à tous !
Un pote m'a fait découvrir un truc que je trouve absolument génial et que je tenais à partager avec vous : xip.io
Ca vous permet d'utiliser une "infinité" de nom de domaines différents à partir d'une IP. Pour reprendre leur exemple :
10.0.0.1.xip.io resolves to 10.0.0.1
www.10.0.0.1.xip.io resolves to 10.0.0.1
mysite.10.0.0.1.xip.io resolves to 10.0.0.1
foo.bar.10.0.0.1.xip.io resolves to 10.0.0.1En tant que développeur, ça va changer ma vie ! Et même sans être dev, si vous voulez pas acheter un domaine, c'est certes moins sexy à cause de l'IP dedans, mais ça fait le job ! Et pas besoin d'attendre la propagation DNS !
Bref, j'espère que ça pourra servir à certains d'entre vous ;)
# Commentaire supprimé
Posté par Anonyme . Évalué à 10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Est-ce que la section astuces-divers des forums ne mériterait pas plus de visibilité ?
Posté par BAud (site web personnel) . Évalué à 10.
Peut-être qu'une entrée de suivi permettrait d'en discuter efficacement ;-)
# marche pas chez moi
Posté par NeoX . Évalué à 4.
ca ne marche pas chez moi (OSX)
ca ne marche pas non plus avec un linux dans une VM sur mon reseau (DNS de Free)
dig ne renvoie rien meme avec les DNS de Google.
mais ca fonctionne depuis un linux chez Ovh (DNS OVH)
bref c'est quand meme pas gagné cette affaire.
[^] # Re: marche pas chez moi
Posté par Tonton Benoit . Évalué à 2.
Pourtant normalement avec les DNS de Google ça marche. Pour free, il filtre les domaines qui retournent une IP non publique visiblement.
[^] # Re: marche pas chez moi
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 8.
Oui, Free fait cela et pas mal d'autres résolveurs d'enterprise également. C'est pour empêcher les attaques par changement
[^] # Re: marche pas chez moi
Posté par Zenitram (site web personnel) . Évalué à 1.
Je suis surpris que Google ne le fasse pas, comme tu le dis dans ton article sur le sujet Google l'implémente dans d'autres de ses outils.
Il y a une raison pour ne pas le faire? (j'ai compris que ce n'est pas forcément le boulot du DNS, mais bon, si il peut aider à la sécurité)
# ?
Posté par XB . Évalué à 10.
Désolé je vois pas à quoi ça sert.
Si quelqu'un peut éclairer ma lanterne…
[^] # Re: ?
Posté par tfeserver tfe (site web personnel) . Évalué à 7.
Quand tu as plusieurs site à tester en local, et que sur ton ipad/telephone/autre tu ne peux pas editer le fichier de hosts, il faut passer par ce genre d'astuces: avoir un virtualhost different par site (chose que tu pourrais pas faire si tu accedes directement avec l'adresse ip).
[^] # Re: ?
Posté par XB . Évalué à 1. Dernière modification le 04 février 2015 à 10:17.
Merci pour l'explication.
[^] # Re: ?
Posté par Sufflope (site web personnel) . Évalué à 3.
Ou que t'es sur un desktop conventionnel mais que t'as pas envie de toucher à ce fichier dégueulasse à chaque fois que tu veux tester un truc.
[^] # Re: ?
Posté par kursus_hc . Évalué à 0.
Il faut aussi que le device utilisé ne soit pas sur le réseau local pour que ça ait un intérêt non ? Sinon quelle différence avec :
http://localIP/site1
http://localIP/site2
etc
[^] # Re: ?
Posté par claudex . Évalué à 5.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: ?
Posté par kursus_hc . Évalué à 2. Dernière modification le 04 février 2015 à 14:14.
Toujours pas compris désolé,
http://localIP/site1 n'est pas un virtual host, c'est un simple dossier nommé site1 dans le répertoire web. Je comprends l'utilité si l'on n'est pas sur le réseau local, mais sinon quel avantage ?
[^] # Re: ?
Posté par Larry Cow . Évalué à 2.
Si les contenus hébergés sur /site1 et /site2 imposent tous deux d'être à la racine du serveur, tu fais comment?
[^] # Re: ?
Posté par kursus_hc . Évalué à 1.
Ben tu écris une ligne dans ton .htaccess non ? Je serais curieux de connaître un cas de figure ou cette solution ne fonctionne pas.
[^] # Re: ?
Posté par Larry Cow . Évalué à 5.
Dans le cas où les deux doivent tourner en même temps?
Je veux lier une appli (pas écrite par mes soins) qui s'attend à être sur / à une autre qui s'attend à la même chose. Je manque d'imagination, mais je ne vois pas tellement en quoi un .htaccess va t'aider ici, si?
[^] # Re: ?
Posté par kursus_hc . Évalué à -2.
Que veut dire "qui s'attend à être sur /" au juste ? La racine est une abstraction. Pour moi une app "qui s'attend à être sur /" est mal codée. Par curiosité dans quel contexte rencontres-tu ça ?
[^] # Re: ?
Posté par groumly . Évalué à 6.
Mal codee, mal codee, c'est vite dit.
Si ta resource c'est /api/v1/user/1234 et que tu lui balances /appli/api/blabla, t'as de grande chances de te prendre un 404 quand meme, a juste titre.
Alors, oui, rewrite rules, context path et tout le tralala, mais ca fait chier de faire des configs one off en permanence. Sans parler des applis natives ou t'as autre chose a faire que de changer ton base path toutes les 15 minutes.
Ya le header Host, il est pas fait pour les chiens, il a meme ete cree specialement pour ca.
Dit autrement, ton routage de requetes est plus simple a gerer par virtual host que par url paths.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: ?
Posté par claudex . Évalué à 5.
Et c'est aussi plus proche de ce qui se retrouvera en prod, ce qui n'est pas plus mal pour tester.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: ?
Posté par 2PetitsVerres . Évalué à -4.
Et une application qui ne marche plus si on la met dans /usr/local au lieu de /usr, c'est normal aussi ? Et une application qu'il faut absolument mettre dans C:\Program Files, c'est bon aussi ?
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: ?
Posté par groumly . Évalué à 1.
Ca a pas grand chose a voir.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: ?
Posté par Larry Cow . Évalué à 3.
Je partage assez cela, mais là n'est pas la question : les applis mal codées ça existe, et on n'a pas toujours le loisir de mettre les mains dedans.
Plus concrètement, ce que j'ai pu rencontrer un peu plus souvent, ce sont des applis qui acceptent de passer sur un sous-répertoire, mais au prix d'une configuration un peu exotique qui risque de sauter à chaque mise-à-jour.
[^] # Re: ?
Posté par groumly . Évalué à 3.
T'as un load balancer qui front plusieurs services et se base sur le header Host pour savoir ou faire suivre la requete.
Ca va typiquement etre le cas dans un envinronement de dev interne ou tu veux pas te faire chier a avoir 1 LB par service..
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: ?
Posté par Zenitram (site web personnel) . Évalué à 4.
Je commence à un perdu : jouer avec des load balancers et ne pas avoir accès à son fichier host (sujet initial), c'est un cas qui existe?
[^] # Re: ?
Posté par groumly . Évalué à 5.
Oui. Les applis natives et les personnes non techniques/qui ont autre chose a faire que de branler le mamouth avec des hostfiles. Genre tu veux montrer un prototype a un product manager ou a ton vp/cto, ca le fait pas du tout de lui filer un qui va resoudre vers tout sauf ce que tu veux.
Rajoutes par dessus que t'as aucun moyen de savoir si tu parles reellement a l'environment auquel tu parles (et paf, tu modifies des donnees en prod au lieu de dev. C'est pas une question de si, c'est une question de quand), et tu te tapes des barres de rires avec chrome qui va garder la resolution de nom d'hote en memoire, mais pas toujours (et du coup, tu sais encore moins ou tes requetes vont).
Les fichiers hosts, c'est l'incarnation du demon. A chaque fois que tu edites ce fichier, dieu bute un dessinateur de chez charlie hebdo.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: ?
Posté par Zenitram (site web personnel) . Évalué à 1.
J'engueule leur développeur respectif.
[^] # Re: ?
Posté par groumly . Évalué à 5.
Faut arreter de monter sur ses grand chevaux 2 minutes.
T'as un service RESTful. Comme t'es un bon gars, tu met des liens vers tes autres resources dans tes reponses, en clair, genre /api/v1/user/1234 te file un lien vers /api/v1/comments/1234 pour voir les commentaires de cet utlisateur (exemple totalement fictif :)).
Ces liens sont relatifs a l'hote, parce que t'as pas envie que ton appli doive savoir sur quel nom d'hote elle est hebergee, et ca, c'est bien (decouple le routage de l'appli).
Paf, tu viens de peter ton appli, ta resource /folder/api/v1/user/1234 te dit d'aller voir /api/machin, et tu l'as dans l'cul lulu (turlututu chapeau pointu). C'est dur de gueuler sur le developeur, parce qu'il a fait ce qu'il fallait, c'est toi qui a deploye ca comme un goret.
Accessoirement, ya des developeurs, tu peux les engueuler tout ce que tu veux, ca resoudra pas ton probleme.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: ?
Posté par Zenitram (site web personnel) . Évalué à 0.
Accessoirement, on peut regarder l'URL appelée et adapter la réponse.
C'est un choix que d'empécher (non volontairement) les gens de poser l'appli où ils veulent/peuvent.
Que le dév ai la flemme / pas le temps, OK, que "il a fait ce qu'il fallait", hum… Désolé, je ne prend pas.
[^] # Re: ?
Posté par groumly . Évalué à 6.
2 choses:
- les url ont une semantique, tu peux pas te permettre de les changer comme tu veux quand tu veux. Une url, c'est standardise, en l'occurence un hote, un path et des query params. T'es libre de penser le contraire, mais la spec parle de path, et pas de prefixe plus path. Accessoirement, bon courage pour faire rentrer ca dans un concept REST ou le path (tout le path) represente l'identite de la resource. On peut aussi citer "cool uris dont change".
- partant de la, le developeur n'a aucune raison de gacher du temps et de l'energie et compliquer son design pour accomoder des pratiques grouik qui vont a l'encontre des specs et des fondements d'http. Surtout quand t'as des outils te permettant de faire les choses proprement plus facilement que de les faire a la rache.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: ?
Posté par claudex . Évalué à 4.
Justement, si tu veux faire des config avec les virtualhost, c'est là que ça devient intéressant (sinon, je ne vois pas la différence avec le réseau local).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: ?
Posté par aiolos . Évalué à 2.
Comme, par exemple, avoir deux certificats différents pour SSL, ou autoriser les accès aux clients authentifiés par des certificats émis par des autorités différentes…
[^] # Re: ?
Posté par SChauveau . Évalué à 5.
Je suppose que cela permet d'accéder à une même IP avec plusieurs noms. il faut savoir que dans une requête HTML (entre autre), le serveur web n'utilise pas l'IP mais le nom pour décider quel site web il soit afficher. Cela permet à plusieurs sites webs de partager la même IP.
Je connais 4 autres façons d'associer rapidement un nom à une IP sans avoir à attendre la propagation mais chacune avec ses avantages et inconvénients.
La première est évidemment d'avoir son propre serveur DNS sur le réseau local pour définir des alias. Si vous êtes chez vous, il est probable que votre 'box internet' puisse faire cela.
La seconde est d'ajouter des entrées dans /etc/hosts (voir man 5 hosts). Il faut être root mais cela marche toujours.
La 3eme est d'utiliser HOSTALIASES (voir man 7 hostname) mais cela ne marche pas toujours bien.
La 4ieme est d'utiliser LD_PRELOAD pour redefinir gethostbyname() et autres fonctions systèmes (l y a plein d'exemples sur le net. Par exemple http://www.wensley.org.uk/c/libdivert.c )
[^] # Re: ?
Posté par SChauveau . Évalué à 3.
Si vous avez le controle d'une zone DNS, une autre possibilité consiste à créer un 'wildcard record' pointant vers l'IP de votre serveur de test. Quelque chose du genre.
*.xxx.mydomain.org 3600 A 101.111.121.131
[^] # Re: ?
Posté par Anonyme . Évalué à 3.
Comme ça, ça permet à n’importe qui de te faire passer pour un pédonazi : « ha bah tiens, la-gallerie-du-pedo.example.com résout ».
[^] # Re: ?
Posté par SlowBrain (site web personnel) . Évalué à 1.
Je ne sais pas chez quel opérateur tu est, et encore moins quel modem tu utilise. Mais de tout les modem sur les quels j'ai eu l'occasion de bricoler, notamment les *box opérateurs, aucun ne propose plus d'option que de juste désactiver les fonctions DNS, mais jamais sans configuration.
Après reste l'option de coller un RPi (ou équivalent) au cul du modem pour lui faire assurer certaines fonctions qui lui son normalement dédié de façon correcte et souple (DNS et DHCP).
[^] # Re: ?
Posté par SChauveau . Évalué à 1.
Je n'étais pas assez clair. Pour les boxes, je parlais juste d'associer un (ou plusieurs) noms à une IP du réseau local. Cela ne résout pas évidemment pas le problème si le serveur en question est externe.
La solution la plus flexible reste évidemment d'installer un serveur DNS sur un RPi ou tout autre machine. Pour ceux qui ne seraient pas trop bidouilleurs, un Synology (et probablement tout les NAS un peu évolués) permet d'installer un serveur DNS local en quelques clics.
[^] # Re: ?
Posté par burps_fr . Évalué à 2.
A noter que gethostbyname est "deprecated".
[^] # Re: ?
Posté par VinDuv . Évalué à 5.
Une autre solution pour avoir plusieurs noms sur une IP, sans modifier quoi que ce soit, est d’utiliser les noms alternatifs pour une IP.
Par exemple, “127.0.0.1”, “127.00.0.1”, “127.1”, “2130706433”, “0x7f000001” vont tous être résolus (par getaddrinfo) vers l’IP 127.0.0.1, mais le nom d’hôte indiqué par le navigateur sera différent.
[^] # Re: ?
Posté par kursus_hc . Évalué à 4.
Merci c'est une excellente astuce, probablement meilleure que celle du journal (bloquée par tous les FAI sérieux).
[^] # Re: ?
Posté par Mildred (site web personnel) . Évalué à 5.
Une autre est d'utiliser 127.0.0.2
# dans le même esprit
Posté par maboiteaspam . Évalué à 3.
https://github.com/zapty/echoipdns
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.