Il est fort probable que tu n'auras aucun problèmes sérieux.
En pratique tu auras les mêmes droits d'accès aux fichiers que le compte utilisé pour la connection ssh.
Par défaut, les uid et gid des fichiers seront préservés mais ils ne seront pas utilisés pour déterminer les droits d'accès.
En pratique, cela signifie que si l'uid de ton utilisateur ssh est 1005 sur le serveur alors les fichiers sembleront appartenir à l'utilisateur 1005 sur le client.
Certains programmes qui testent les UID & GID des fichiers avant d'y accéder peuvent être perturbés mais c'est assez rare.
Sur quasiment toutes les machines auxquelles j'ai accès, je recompile emacs moi même.
Cela prend un petit quart d'heure et cela m'assure que mon .emacs fonctionnera partout.
J'aime assez et en particulier la version Mono que je vais probablement essayer quelques temps pour mes terminaux et mes éditeurs de textes.
Par contre, après avoir copié les fontes dans mon dossier~/.fonts, j'ai remarqué qu'il n'y avait pas de différence entre Regular et Medium aussi bien pour FiraSans que pour FiraMono. Sur la page web Medium est censé être un peu plus gras que Regular.
En retirant les fichiers 'medium', j'obtiens effectivement une version un peu moins 'grasse' pour Regular et, à mon avis, plus agréable. Il semble donc y avoir un petit bug soit dans Fira Medium soit dans fontconfig.
Cela commençait bien mais les 3 dernières phrase piquent vraiment trop les yeux :-)
"code server" -> "code serveur"
"reste à source fermé" -> "reste fermé" (car 'code' et 'source' sont synonymes dans ce contexte)
"à peu être" -> "a peut-être"
"mais avec un" -> "mais utiliser un"
"des hauts placé" -> "des personnes haut placées"
Malheureusement, les personnes ayant une réelle motivation pour subtiliser votre clef USB sont généralement des proches (famille, collègue, …) ayant un accès relativement facile à la-dite clef.
Il faudrait voir les détails de l'attaque permettant de réduire le niveau de sécurité mais je suppose qu'il s'agit de modifier le fichier de configuration '.encfs.xml' présent à la racine du dossier chiffré. Si c'est le cas, une simple vérification du hash de ce fichier pourrait suffire à détecter un problème. On pourrait aussi faire en sorte que ce fichier ne soit pas stocké sur la clef ou qu'il soit lui même chiffré.
Si la machine est compromise alors que EncFS est est cours de fonctionnement alors les données ne sont évidemment pas protégées puisque l'attaquant pourra se faire passer pour toi et accéder à tes fichiers.
Si la machine se fait voler et que l'attaquant n'a accès qu'aux données présentes sur le disque dur alors tout va bien.
Par contre, ce qui semble être décrit ici est que si l'attaquant a accès aux fichiers chiffrés et est capable de les modifier alors il pourra baisser la sécurité des accès ultérieurs.
On peut imaginer le scénario suivant.
A utilise EncFS pour chiffrer des données sur une clef USB.
B parvient à dérober la clef USB dans la poche de A.
B ne peut pas déchiffrer le contenu de la clef mais il peut baisser le niveau de sécurité de EncFS.
B remet la clef USB dans la poche de A.
A utilise EncFS sur sa clef USB et met a jour certains fichiers.
B dérobe de nouveau la clef USB et peut alors facilement déchiffrer les nouveaux fichiers crées par A.
Pour la plupart des cas d'utilisations classiques où EncFS ne sert qu'a protéger des données en cas de vol de la machine, il me semble en effet qu'il n'y a pas de problèmes.
Par contre il faudra y regarder de plus près si tout ou une partie des fichiers chiffrés est accessible publiquement ou est stockée sur un serveur peu sécurisé (un serveur web mutualisé par exemple). Il faudrait voir ce que signifie exactement "read/write access to encrypted data". Est ce la partie chiffrée ou la partie en clair?
C'est une bonne idée. Je n'ai pas le temps de jouer avec (nouveau job avec déménagement) mais cela pourrait être utile.
Ta commande gg-translate ne semble gérer que le langage destination avec l'option -t de goslate.py mais il serait bien de pouvoir aussi spécifier le langage source avec l'option -s.
Idéalement, il faudrait aussi pouvoir prédéfinir des alias pour les paires source & destination.
Nul besoin d'infrarouge pour les digicodes. L'usure des touches est en général suffisant. De plus, les digicodes sont quasiment tous 1418, 1515, 3945 ou 1806.
Amusant! Cette fois ci, la complainte est qe Systemd décide de ne pas intégrer une fonctionnalité déjà existante.
Fait un petit apt-get install readahead et tu auras ton readahead comme dans le bon vieux temps.
Il n'y a pas de conspiration; Aucun plan diabolique pour obtenir des utilisateurs à tout prix.
The .network files are read from the files located in the system network directory /lib/systemd/network, the
volatile runtime network directory /run/systemd/network and the local administration network directory
/etc/systemd/network. All configuration files are collectively sorted and processed in lexical order,
regardless of the directories in which they live. However, files with identical filenames replace each other.
Files in /etc have the highest priority, files in /run take precedence over files with the same name in /lib.
This can be used to override a system-supplied configuration file with a local file if needed; a symlink in
/etc with the same name as a configuration file in /lib, pointing to /dev/null, disables the configuration
file entirely.
Donc si comprend bien l'idée sous-jacente l'ordre de priorité est /etc/systemd/network pour la configuration manuelle
puis /run/systemd/network pour les configurations automatiques temporaires (du genre NetworkManager. /run est généralement un ramdisk) puis /lib/systemd/network pour des configurations par défaut (du genre DHCP sur tout les ports ethernet)
En fait c'est une configuration assez futée. J'ai toujours été agacé par les outils qui écrasent les fichiers de configuration dans /etc/.
En effet. Les SSD ont un 'seek time' quasiment nul mais ils sont généralement optimisés pour des accès par grand blocks de 2Mo ou plus. Je ne sais pas si readahead peut en tirer partie surtout que les mecanismes de wear-leveling complexifies probablement les choses. Cela se mesure.
Es tu certain qu'il ne fait pas tourner NetworkManager ou le script /etc/init.d/networking de SysV? c'est que ma Debian Jessy fait actuellement,
Si il utilise systemd-networkd alors la configuration de chaque interface devrait être dans un fichier .network.
Ils peuvent se trouver dans plusieurs endroits: voir 'man systemd.network'. Je ne serais pas surpris que le système configure DHCP par défaut sur toutes les prises Ethernet.
Je n'ai pas encore essayé d'activer systemd-networkd sur ma Jessie. La configuration n'a pas l'air difficile mais je comprend comment on peut activer et désactiver individuellement les interfaces réseaux. Je n'ai pas l'impression que l'on puisse encore utiliser ifup & ifdown. Est ce que les '.network' sont aussi des units qui peuvent être gérées par systemctl? Je n'ai fait que parcourir très brièvement les docs.
« The [Guix] developers appear motivated toward a solid release to showcase the GNU System. I never got far enough to install Xorg. »
et aussi celui la que je trouve assez ironique:
« why there are people who, rather than improving grub or lilo, waste their time writing a bootloader from scratch? »
La distinction entre list-units et list-unit-files est expliquée dans la documentation;
The list-units command only displays units that systemd has attempted to parse and load into memory. Since systemd will only read units that it thinks it needs, this will not necessarily include all of the available units on the system.
En gros, chaque unit est décrite par un fichier mais systemd ne charge que ceux dont il a besoin. list-units indique donc les units qui ont été chargés par systemd depuis le début alors list-unit-files les donne tous.
Une analogie un peu foireuse avec sysv est que list-units donne les services utilisés dans le runlevel actuel alors que list-unit-files donne tout les services disponibles dans /etc/init.d/ (mais c'est approximatif car un unit non activé pour le runlevel actuel peut quand même être chargé (mais pas démarré) par systemd si il est référencé par un autre unit).
Concernant le grand nombre d'units, le problème est que tous ne sont pas des services dans le sens de sysv. Par exemple, chaque mount est un unit et il y a aussi des 'target' qui correspondent à des ensembles d'units comparable au runlevel de sys).
Pour ne voir que les services, il faut passer l'option -t service ou utiliser le pattern '*.service'
Ce n'est pas le sens que je voulais donner. Désolé si c'est ce qui apparaît.
Il me semble que le problème de ton journal est que tu décris systemd par rapport à ce que tu avais l'habitude de faire avec sysv. C'est compréhensible mais beaucoup de choses ne marchent évidemment plus donc ton journal ne peut que donner une vision négative de systemd même si ce n'était pas ton intention.
Le fait que les distributions conservent une couche de compatibilité avec sysv n'améliore pas la situation car les utilisateurs, moi compris, ont plutôt tendance à se tourner vers les interfaces qu'ils connaissent et qui deviennent progressivement obsolètes. J'expérimente actuellement systemd sous Debian. Cela fonctionne bien mais quasiment tout sysv est encore présent (/etc/init.d , /etc/inittab, …) et je serais bien incapable de dire ce qui est encore utilisé.
J'ai aussi passé quelques minutes à explorer systemd récemment.
Je trouve aussi que le nombre d'entrées fourni par systemctl list-units est un peu trop grand pour être lisible. C'est surtout parce que les services sont des
'units' parmi d'autres. Il faut filtrer.
Par exemple, pour voir uniquement les services actifs
systemctl list-unit -t service
Pour voir tout les services
systemctl list-unit -t service -a
Il est aussi possible de spécifier un pattern
systemctl list-units '*lvm*'
Pour inspecter la définition d'un service on pourra utiliser la commande cat
systemctl cat ssh.service
Il est clair que systemd n'a pas été fait pour être entièrement bidouillable à la main comme pouvait l'être SysV. Cela reste généralement possible mais ce n'est pas convivial et quasiment tout est censé se faire via systemctl.
Comme souvent en programmation, le problème réside souvent dans le fait d'abuser d'un concept que dans le concept lui même.
Le goto est par exemple très utile pour coder efficacement certains automates d'états en C.
Il peut également être très pratique pour la gestion d'erreur en C là ou dans un code similaire en C++ on utilisera plutôt une exception dans un try-catch.
Le problème n'est pas le goto mais le code spaghetti.
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.
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: Oui
Posté par SChauveau . En réponse au journal SSHFS est un vrai système de fichiers en réseau. Évalué à 3.
Il est fort probable que tu n'auras aucun problèmes sérieux.
En pratique tu auras les mêmes droits d'accès aux fichiers que le compte utilisé pour la connection ssh.
Par défaut, les uid et gid des fichiers seront préservés mais ils ne seront pas utilisés pour déterminer les droits d'accès.
En pratique, cela signifie que si l'uid de ton utilisateur ssh est 1005 sur le serveur alors les fichiers sembleront appartenir à l'utilisateur 1005 sur le client.
Certains programmes qui testent les UID & GID des fichiers avant d'y accéder peuvent être perturbés mais c'est assez rare.
[^] # Re: Oui
Posté par SChauveau . En réponse au journal SSHFS est un vrai système de fichiers en réseau. Évalué à 3.
sshfs propose plusieurs possibilités pour traduire les user/group.
Voir les options -o idmap, uidfile, gidfile, nomap=ignore, uid et gid
[^] # Re: flyspell
Posté par SChauveau . En réponse au journal Améliorer la correction orthographique et grammaticale sous Emacs. Évalué à 3.
Sur quasiment toutes les machines auxquelles j'ai accès, je recompile emacs moi même.
Cela prend un petit quart d'heure et cela m'assure que mon .emacs fonctionnera partout.
[^] # Re: flyspell
Posté par SChauveau . En réponse au journal Améliorer la correction orthographique et grammaticale sous Emacs. Évalué à 1.
Bizarre.
Cela fait bien longtemps que j'ai retiré toutes les configurations UTF-8 de mon .emacs. C'est fait par défaut.
# Regular et Medium
Posté par SChauveau . En réponse au journal Fonte de caractère de Firefox OS. Évalué à 1.
J'aime assez et en particulier la version Mono que je vais probablement essayer quelques temps pour mes terminaux et mes éditeurs de textes.
Par contre, après avoir copié les fontes dans mon dossier~/.fonts, j'ai remarqué qu'il n'y avait pas de différence entre Regular et Medium aussi bien pour FiraSans que pour FiraMono. Sur la page web Medium est censé être un peu plus gras que Regular.
En retirant les fichiers 'medium', j'obtiens effectivement une version un peu moins 'grasse' pour Regular et, à mon avis, plus agréable. Il semble donc y avoir un petit bug soit dans Fira Medium soit dans fontconfig.
PS: je suis sur Linux Mint 17 Xfce4
# corrections
Posté par SChauveau . En réponse au journal Stop FUD ! . Évalué à 3.
Cela commençait bien mais les 3 dernières phrase piquent vraiment trop les yeux :-)
"code server" -> "code serveur"
"reste à source fermé" -> "reste fermé" (car 'code' et 'source' sont synonymes dans ce contexte)
"à peu être" -> "a peut-être"
"mais avec un" -> "mais utiliser un"
"des hauts placé" -> "des personnes haut placées"
[^] # Re: faut deja un acces aux données
Posté par SChauveau . En réponse au journal Encfs déclaré relativement peu sûr. Évalué à 4.
Malheureusement, les personnes ayant une réelle motivation pour subtiliser votre clef USB sont généralement des proches (famille, collègue, …) ayant un accès relativement facile à la-dite clef.
Il faudrait voir les détails de l'attaque permettant de réduire le niveau de sécurité mais je suppose qu'il s'agit de modifier le fichier de configuration '.encfs.xml' présent à la racine du dossier chiffré. Si c'est le cas, une simple vérification du hash de ce fichier pourrait suffire à détecter un problème. On pourrait aussi faire en sorte que ce fichier ne soit pas stocké sur la clef ou qu'il soit lui même chiffré.
[^] # Re: faut deja un acces aux données
Posté par SChauveau . En réponse au journal Encfs déclaré relativement peu sûr. Évalué à 6.
Il y a compromis et compromis.
Si la machine est compromise alors que EncFS est est cours de fonctionnement alors les données ne sont évidemment pas protégées puisque l'attaquant pourra se faire passer pour toi et accéder à tes fichiers.
Si la machine se fait voler et que l'attaquant n'a accès qu'aux données présentes sur le disque dur alors tout va bien.
Par contre, ce qui semble être décrit ici est que si l'attaquant a accès aux fichiers chiffrés et est capable de les modifier alors il pourra baisser la sécurité des accès ultérieurs.
On peut imaginer le scénario suivant.
A utilise EncFS pour chiffrer des données sur une clef USB.
B parvient à dérober la clef USB dans la poche de A.
B ne peut pas déchiffrer le contenu de la clef mais il peut baisser le niveau de sécurité de EncFS.
B remet la clef USB dans la poche de A.
A utilise EncFS sur sa clef USB et met a jour certains fichiers.
B dérobe de nouveau la clef USB et peut alors facilement déchiffrer les nouveaux fichiers crées par A.
[^] # Re: faut deja un acces aux données
Posté par SChauveau . En réponse au journal Encfs déclaré relativement peu sûr. Évalué à 3.
Pour la plupart des cas d'utilisations classiques où EncFS ne sert qu'a protéger des données en cas de vol de la machine, il me semble en effet qu'il n'y a pas de problèmes.
Par contre il faudra y regarder de plus près si tout ou une partie des fichiers chiffrés est accessible publiquement ou est stockée sur un serveur peu sécurisé (un serveur web mutualisé par exemple). Il faudrait voir ce que signifie exactement "read/write access to encrypted data". Est ce la partie chiffrée ou la partie en clair?
# Intéressant
Posté par SChauveau . En réponse au journal Google translate sans quitter votre emacs. Évalué à 2.
C'est une bonne idée. Je n'ai pas le temps de jouer avec (nouveau job avec déménagement) mais cela pourrait être utile.
Ta commande gg-translate ne semble gérer que le langage destination avec l'option -t de goslate.py mais il serait bien de pouvoir aussi spécifier le langage source avec l'option -s.
Idéalement, il faudrait aussi pouvoir prédéfinir des alias pour les paires source & destination.
[^] # Re: vous reprendrez bien des chips
Posté par SChauveau . En réponse à la dépêche Pour plus de sécurité au bureau, évitez les chips (ou alors, chuchotez) !. Évalué à 2.
Nul besoin d'infrarouge pour les digicodes. L'usure des touches est en général suffisant. De plus, les digicodes sont quasiment tous 1418, 1515, 3945 ou 1806.
[^] # Re: Encore une victime de Lennart
Posté par SChauveau . En réponse au journal systemd: je me lance. Évalué à -2.
Amusant! Cette fois ci, la complainte est qe Systemd décide de ne pas intégrer une fonctionnalité déjà existante.
Fait un petit apt-get install readahead et tu auras ton readahead comme dans le bon vieux temps.
Il n'y a pas de conspiration; Aucun plan diabolique pour obtenir des utilisateurs à tout prix.
[^] # Re: ...
Posté par SChauveau . En réponse au journal systemd: je me lance. Évalué à 7.
Dans man serviced.network
Donc si comprend bien l'idée sous-jacente l'ordre de priorité est /etc/systemd/network pour la configuration manuelle
puis /run/systemd/network pour les configurations automatiques temporaires (du genre NetworkManager. /run est généralement un ramdisk) puis /lib/systemd/network pour des configurations par défaut (du genre DHCP sur tout les ports ethernet)
En fait c'est une configuration assez futée. J'ai toujours été agacé par les outils qui écrasent les fichiers de configuration dans /etc/.
[^] # Re: L'argument kitu
Posté par SChauveau . En réponse au journal systemd: je me lance. Évalué à 2.
En effet. Les SSD ont un 'seek time' quasiment nul mais ils sont généralement optimisés pour des accès par grand blocks de 2Mo ou plus. Je ne sais pas si readahead peut en tirer partie surtout que les mecanismes de wear-leveling complexifies probablement les choses. Cela se mesure.
[^] # Re: L'argument kitu
Posté par SChauveau . En réponse au journal systemd: je me lance. Évalué à 3.
Comparer les vitesses de boot c'est un peu comme comparer la taille de sa … :-)
Sérieusement, il y a tellement de facteurs qui peuvent affecter la vitesse de boot que cela n'a généralement aucun sens.
Si vous voulez être constructif, passez un coup de bootchart et postez le résultat (si possible après avoir actualisé readahead).
[^] # Re: ...
Posté par SChauveau . En réponse au journal systemd: je me lance. Évalué à 2.
Es tu certain qu'il ne fait pas tourner NetworkManager ou le script /etc/init.d/networking de SysV? c'est que ma Debian Jessy fait actuellement,
Si il utilise systemd-networkd alors la configuration de chaque interface devrait être dans un fichier .network.
Ils peuvent se trouver dans plusieurs endroits: voir 'man systemd.network'. Je ne serais pas surpris que le système configure DHCP par défaut sur toutes les prises Ethernet.
Je n'ai pas encore essayé d'activer systemd-networkd sur ma Jessie. La configuration n'a pas l'air difficile mais je comprend comment on peut activer et désactiver individuellement les interfaces réseaux. Je n'ai pas l'impression que l'on puisse encore utiliser ifup & ifdown. Est ce que les '.network' sont aussi des units qui peuvent être gérées par systemctl? Je n'ai fait que parcourir très brièvement les docs.
[^] # Re: deVUan
Posté par SChauveau . En réponse à la dépêche Devuan un fork de Debian qui va (peut-être) chambouler notre petit monde. Évalué à 3.
D'un autre coté, la 2nde ligne de www.devuan.org mentionne "the Veteran Unix Admin collective"
Personnellement il me semblait que devuan était simplement juste une forme écrite de 'Dev One'.
[^] # Re: Trop gros, passeras pas !
Posté par SChauveau . En réponse à la dépêche Devuan un fork de Debian qui va (peut-être) chambouler notre petit monde. Évalué à 2.
« The [Guix] developers appear motivated toward a solid release to showcase the GNU System. I never got far enough to install Xorg. »
et aussi celui la que je trouve assez ironique:
« why there are people who, rather than improving grub or lilo, waste their time writing a bootloader from scratch? »
[^] # Re: systemctl list-unit-etc.
Posté par SChauveau . En réponse au journal systemd: je me lance. Évalué à 3.
La distinction entre list-units et list-unit-files est expliquée dans la documentation;
The list-units command only displays units that systemd has attempted to parse and load into memory. Since systemd will only read units that it thinks it needs, this will not necessarily include all of the available units on the system.
En gros, chaque unit est décrite par un fichier mais systemd ne charge que ceux dont il a besoin. list-units indique donc les units qui ont été chargés par systemd depuis le début alors list-unit-files les donne tous.
Une analogie un peu foireuse avec sysv est que list-units donne les services utilisés dans le runlevel actuel alors que list-unit-files donne tout les services disponibles dans /etc/init.d/ (mais c'est approximatif car un unit non activé pour le runlevel actuel peut quand même être chargé (mais pas démarré) par systemd si il est référencé par un autre unit).
Concernant le grand nombre d'units, le problème est que tous ne sont pas des services dans le sens de sysv. Par exemple, chaque mount est un unit et il y a aussi des 'target' qui correspondent à des ensembles d'units comparable au runlevel de sys).
Pour ne voir que les services, il faut passer l'option -t service ou utiliser le pattern '*.service'
[^] # Re: .
Posté par SChauveau . En réponse au journal systemd: je me lance. Évalué à 10.
Il me semble que le problème de ton journal est que tu décris systemd par rapport à ce que tu avais l'habitude de faire avec sysv. C'est compréhensible mais beaucoup de choses ne marchent évidemment plus donc ton journal ne peut que donner une vision négative de systemd même si ce n'était pas ton intention.
Le fait que les distributions conservent une couche de compatibilité avec sysv n'améliore pas la situation car les utilisateurs, moi compris, ont plutôt tendance à se tourner vers les interfaces qu'ils connaissent et qui deviennent progressivement obsolètes. J'expérimente actuellement systemd sous Debian. Cela fonctionne bien mais quasiment tout sysv est encore présent (/etc/init.d , /etc/inittab, …) et je serais bien incapable de dire ce qui est encore utilisé.
# services
Posté par SChauveau . En réponse au journal systemd: je me lance. Évalué à 10.
J'ai aussi passé quelques minutes à explorer systemd récemment.
Je trouve aussi que le nombre d'entrées fourni par systemctl list-units est un peu trop grand pour être lisible. C'est surtout parce que les services sont des
'units' parmi d'autres. Il faut filtrer.
Par exemple, pour voir uniquement les services actifs
Pour voir tout les services
Il est aussi possible de spécifier un pattern
Pour inspecter la définition d'un service on pourra utiliser la commande cat
Il est clair que systemd n'a pas été fait pour être entièrement bidouillable à la main comme pouvait l'être SysV. Cela reste généralement possible mais ce n'est pas convivial et quasiment tout est censé se faire via systemctl.
[^] # Re: Debian + Desktop + Steam = Ubuntu
Posté par SChauveau . En réponse au journal ArchLinux : serait-il venu le temps de passer à autre chose ?. Évalué à 3.
Essaye Mint. C'est comme Ubuntu mais sans l’arrière goût.
[^] # Re: ...
Posté par SChauveau . En réponse au journal SySVinit considered harmful ?. Évalué à 10.
Comme souvent en programmation, le problème réside souvent dans le fait d'abuser d'un concept que dans le concept lui même.
Le goto est par exemple très utile pour coder efficacement certains automates d'états en C.
Il peut également être très pratique pour la gestion d'erreur en C là ou dans un code similaire en C++ on utilisera plutôt une exception dans un try-catch.
Le problème n'est pas le goto mais le code spaghetti.
[^] # Re: ?
Posté par SChauveau . En réponse au journal xip.io pour une infinité de domaines gratos !. É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 SChauveau . En réponse au journal xip.io pour une infinité de domaines gratos !. É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