[FRsAG] wget et les adresses link-local

2014-09-01 Par sujet Julien Escario

Bonjour,
Je tente de faire aspirer une page sur un serveur en ipv6 avec mon wget. Le 
serveur n'a que du link-local, on est sur un même LAN.


Mais pas moyen de lui enfiler l'adresse :
$ wget http://[fe80::7827:c1ff:fe6c:a351]
--2014-09-01 15:23:42--  http://[fe80::7827:c1ff:fe6c:a351]/
Connecting to fe80::7827:c1ff:fe6c:a351:80... failed: Invalid argument.

$ wget http://[fe80::7827:c1ff:fe6c:a351%eth1]
http://[fe80::7827:c1ff:fe6c:a351%eth1]: Invalid IPv6 numeric address.

$ wget http://[fe80::7827:c1ff:fe6c:a351]%eth1
http://[fe80::7827:c1ff:fe6c:a351]%eth1: Invalid host name.

Une idée ?

Pour donner le problème dans sa globalité : je cherche à mettre un upstream ipv6 
à mon nginx. Ca semble supporté depuis 1.3 environ donc largement. Mais encore 
une fois, avec le link-local pour lequel il faut préciser l'interface quand on 
fait un ping6 par exemple, ça ne passe pas ...


Merci,
Julien
___
Liste de diffusion du FRsAG
http://www.frsag.org/


[FRsAG] Machine Learning: retours d'expérience

2014-09-01 Par sujet Greg
Bonjour,

est-ce que parmi vous certains aurait expérimenté ou mis en place des
architectures de machine learning ? Le domaine est assez vaste, et
intéressant, et je pense qu'un retour d'expérience en environnement
professionnel pourrait intéresser les membres de ce groupe.

Attention, je ne suis pas à la recherche de tuto pour savoir comment
installer Apache Storm, mais de vrais retours d'expériences: par où
commencer, quelles erreurs éviter, dans quel cas utiliser tel ou tel
techno, comment l'intégrer à une architecture existante ...

Un grand merci d'avance aux contributeurs ;)

Greg
___
Liste de diffusion du FRsAG
http://www.frsag.org/


Re: [FRsAG] wget et les adresses link-local

2014-09-01 Par sujet Emmanuel Thierry

Le 1 sept. 2014 à 15:33, Julien Escario a écrit :

> Bonjour,
> Je tente de faire aspirer une page sur un serveur en ipv6 avec mon wget. Le 
> serveur n'a que du link-local, on est sur un même LAN.
> 
> Mais pas moyen de lui enfiler l'adresse :
> $ wget http://[fe80::7827:c1ff:fe6c:a351]
> --2014-09-01 15:23:42--  http://[fe80::7827:c1ff:fe6c:a351]/
> Connecting to fe80::7827:c1ff:fe6c:a351:80... failed: Invalid argument.
> 
> $ wget http://[fe80::7827:c1ff:fe6c:a351%eth1]
> http://[fe80::7827:c1ff:fe6c:a351%eth1]: Invalid IPv6 numeric address.
> 
> $ wget http://[fe80::7827:c1ff:fe6c:a351]%eth1
> http://[fe80::7827:c1ff:fe6c:a351]%eth1: Invalid host name.
> 
> Une idée ?

Si tu peux utiliser curl, oui. ;)

$ curl "http://fe80::dead:beef:cafe:1234%virbr0/";

___
Liste de diffusion du FRsAG
http://www.frsag.org/


Re: [FRsAG] wget et les adresses link-local

2014-09-01 Par sujet Pierre DOLIDON


http://lists.gnu.org/archive/html/bug-wget/2009-06/msg0.html


btw pourquoi ne pas utiliser l'IPv4 entre ton RP et ton upstream ? tu 
compte faire disparaitre IPv4 totalement de ton réseau ?


Sinon autre question, pourquoi te cantonner a ton linklocal ? tes hosts 
IPv6 n'ont pas de global ?


Le 01/09/2014 15:46, Emmanuel Thierry a écrit :

Le 1 sept. 2014 à 15:33, Julien Escario a écrit :


Bonjour,
Je tente de faire aspirer une page sur un serveur en ipv6 avec mon wget. Le 
serveur n'a que du link-local, on est sur un même LAN.

Mais pas moyen de lui enfiler l'adresse :
$ wget http://[fe80::7827:c1ff:fe6c:a351]
--2014-09-01 15:23:42--  http://[fe80::7827:c1ff:fe6c:a351]/
Connecting to fe80::7827:c1ff:fe6c:a351:80... failed: Invalid argument.

$ wget http://[fe80::7827:c1ff:fe6c:a351%eth1]
http://[fe80::7827:c1ff:fe6c:a351%eth1]: Invalid IPv6 numeric address.

$ wget http://[fe80::7827:c1ff:fe6c:a351]%eth1
http://[fe80::7827:c1ff:fe6c:a351]%eth1: Invalid host name.

Une idée ?

Si tu peux utiliser curl, oui. ;)

$ curl "http://fe80::dead:beef:cafe:1234%virbr0/";

___
Liste de diffusion du FRsAG
http://www.frsag.org/


___
Liste de diffusion du FRsAG
http://www.frsag.org/


Re: [FRsAG] wget et les adresses link-local

2014-09-01 Par sujet Julien Escario

Pour revenir sur les différents propositions :
* Echapper les [] ne change rien : c'est la partie interface qui est gênante 
dans le link-local. Typiquement, avec une vraie adresse ipv6 (bon là du 6to4), 
ca marche bien :

$ wget http://[2002:c3c8:d907::1]
--2014-09-01 17:13:49--  http://[2002:c3c8:d907::1]/
Connexion vers 2002:c3c8:d907::1:80...connecté.
requête HTTP transmise, en attente de la réponse...200 OK
Longueur: 1522 (1,5K) [text/html]
Sauvegarde en : «index.html»

* Curl se comporte correctement, un point pour lui mais du coup ça ne résoud pas 
le soucis avec nginx.


* Mon idée est effectivement de faire disparaître totalement ipv4 de mon réseau 
pour les services 'non frontaux' qui n'ont absolument aucun besoin de me bouffer 
des IPv4. Et RFC1918 + vlan, bof, c'est lourd à maintenir dans le temps.


* Utiliser 6to4 : ben c'est encore de l'ipv4 déguisée et ca me rajoute de la 
latence de 8ms entre deux machines branchées sur le même swtich.


Du coup, avoir posé la question m'a fait reformuler ma demande à Google : il 
semblerait que l'utilisation du link-local soit la mauvaise façon de faire ça.


ULA semblant (d'après ce que j'ai lu ici et là) en voie de deprecated, il ne me 
reste qu'à me faire attribuer un subnet natif que je vais firewaller et 
n'utiliser qu'en local.


C'est particulièrement foireux d'un point de vue ipv4 mais commence à prendre du 
sens quand on se place d'un point de vue ipv6. Je n'ai pas encore tous les 
réflexes. Faut déjà revenir à une logique de gaspillage, j'ai du mal.


Julien

Le 01/09/2014 15:33, Julien Escario a écrit :

Bonjour,
Je tente de faire aspirer une page sur un serveur en ipv6 avec mon wget. Le
serveur n'a que du link-local, on est sur un même LAN.

Mais pas moyen de lui enfiler l'adresse :
$ wget http://[fe80::7827:c1ff:fe6c:a351]
--2014-09-01 15:23:42--  http://[fe80::7827:c1ff:fe6c:a351]/
Connecting to fe80::7827:c1ff:fe6c:a351:80... failed: Invalid argument.

$ wget http://[fe80::7827:c1ff:fe6c:a351%eth1]
http://[fe80::7827:c1ff:fe6c:a351%eth1]: Invalid IPv6 numeric address.

$ wget http://[fe80::7827:c1ff:fe6c:a351]%eth1
http://[fe80::7827:c1ff:fe6c:a351]%eth1: Invalid host name.

Une idée ?

Pour donner le problème dans sa globalité : je cherche à mettre un upstream ipv6
à mon nginx. Ca semble supporté depuis 1.3 environ donc largement. Mais encore
une fois, avec le link-local pour lequel il faut préciser l'interface quand on
fait un ping6 par exemple, ça ne passe pas ...

Merci,
Julien
___
Liste de diffusion du FRsAG
http://www.frsag.org/


___
Liste de diffusion du FRsAG
http://www.frsag.org/


Re: [FRsAG] wget et les adresses link-local

2014-09-01 Par sujet Pierre DOLIDON

Le 01/09/2014 17:19, Julien Escario a écrit :

Pour revenir sur les différents propositions :
* Echapper les [] ne change rien : c'est la partie interface qui est 
gênante dans le link-local. Typiquement, avec une vraie adresse ipv6 
(bon là du 6to4), ca marche bien :

$ wget http://[2002:c3c8:d907::1]
--2014-09-01 17:13:49--  http://[2002:c3c8:d907::1]/
Connexion vers 2002:c3c8:d907::1:80...connecté.
requête HTTP transmise, en attente de la réponse...200 OK
Longueur: 1522 (1,5K) [text/html]
Sauvegarde en : «index.html»

* Curl se comporte correctement, un point pour lui mais du coup ça ne 
résoud pas le soucis avec nginx.


* Mon idée est effectivement de faire disparaître totalement ipv4 de 
mon réseau pour les services 'non frontaux' qui n'ont absolument aucun 
besoin de me bouffer des IPv4.


la RFC1918 est si petite que ça pour parler de "bouffer des IPv4" ??? 
(et je comprends pas la nécessité de faire disparaitre IPv4 d'un réseau 
de BACK).



Et RFC1918 + vlan, bof, c'est lourd à maintenir dans le temps.


Mettre tout le monde dans le même subnet sans aucun compartiment c'est 
bien pire d'un point de vue topologie. Alors oui ça exige un peu de 
rigueur et de réf, mais c'est bien plus propre a l'entretient c'est ça 
devient pas la cacophonie sur ton vlan par défaut...




* Utiliser 6to4 : ben c'est encore de l'ipv4 déguisée et ca me rajoute 
de la latence de 8ms entre deux machines branchées sur le même swtich.


Du coup, avoir posé la question m'a fait reformuler ma demande à 
Google : il semblerait que l'utilisation du link-local soit la 
mauvaise façon de faire ça.


ULA semblant (d'après ce que j'ai lu ici et là) en voie de deprecated, 
il ne me reste qu'à me faire attribuer un subnet natif que je vais 
firewaller et n'utiliser qu'en local.


C'est particulièrement foireux d'un point de vue ipv4 mais commence à 
prendre du sens quand on se place d'un point de vue ipv6. Je n'ai pas 
encore tous les réflexes. Faut déjà revenir à une logique de 
gaspillage, j'ai du mal.


Julien

Le 01/09/2014 15:33, Julien Escario a écrit :

Bonjour,
Je tente de faire aspirer une page sur un serveur en ipv6 avec mon 
wget. Le

serveur n'a que du link-local, on est sur un même LAN.

Mais pas moyen de lui enfiler l'adresse :
$ wget http://[fe80::7827:c1ff:fe6c:a351]
--2014-09-01 15:23:42--  http://[fe80::7827:c1ff:fe6c:a351]/
Connecting to fe80::7827:c1ff:fe6c:a351:80... failed: Invalid argument.

$ wget http://[fe80::7827:c1ff:fe6c:a351%eth1]
http://[fe80::7827:c1ff:fe6c:a351%eth1]: Invalid IPv6 numeric address.

$ wget http://[fe80::7827:c1ff:fe6c:a351]%eth1
http://[fe80::7827:c1ff:fe6c:a351]%eth1: Invalid host name.

Une idée ?

Pour donner le problème dans sa globalité : je cherche à mettre un 
upstream ipv6
à mon nginx. Ca semble supporté depuis 1.3 environ donc largement. 
Mais encore
une fois, avec le link-local pour lequel il faut préciser l'interface 
quand on

fait un ping6 par exemple, ça ne passe pas ...

Merci,
Julien
___
Liste de diffusion du FRsAG
http://www.frsag.org/


___
Liste de diffusion du FRsAG
http://www.frsag.org/


___
Liste de diffusion du FRsAG
http://www.frsag.org/


Re: [FRsAG] wget et les adresses link-local

2014-09-01 Par sujet Emmanuel Thierry

Le 1 sept. 2014 à 17:19, Julien Escario a écrit :

> Pour revenir sur les différents propositions :
> * Echapper les [] ne change rien : c'est la partie interface qui est gênante 
> dans le link-local. Typiquement, avec une vraie adresse ipv6 (bon là du 
> 6to4), ca marche bien :
> $ wget http://[2002:c3c8:d907::1]
> --2014-09-01 17:13:49--  http://[2002:c3c8:d907::1]/
> Connexion vers 2002:c3c8:d907::1:80...connecté.
> requête HTTP transmise, en attente de la réponse...200 OK
> Longueur: 1522 (1,5K) [text/html]
> Sauvegarde en : «index.html»
> 
> * Curl se comporte correctement, un point pour lui mais du coup ça ne résoud 
> pas le soucis avec nginx.
> 
> * Mon idée est effectivement de faire disparaître totalement ipv4 de mon 
> réseau pour les services 'non frontaux' qui n'ont absolument aucun besoin de 
> me bouffer des IPv4. Et RFC1918 + vlan, bof, c'est lourd à maintenir dans le 
> temps.
> 
> * Utiliser 6to4 : ben c'est encore de l'ipv4 déguisée et ca me rajoute de la 
> latence de 8ms entre deux machines branchées sur le même swtich.
> 
> Du coup, avoir posé la question m'a fait reformuler ma demande à Google : il 
> semblerait que l'utilisation du link-local soit la mauvaise façon de faire ça.
> 
> ULA semblant (d'après ce que j'ai lu ici et là) en voie de deprecated, il ne 
> me reste qu'à me faire attribuer un subnet natif que je vais firewaller et 
> n'utiliser qu'en local.

Là il va falloir citer parce que ça me parait violemment faux. Et si c'était le 
cas, il n'y aurait pas des drafts en discussion dans le groupe IETF v6ops :
http://tools.ietf.org/html/draft-ietf-v6ops-ula-usage-recommendations-03

L'ULA est tout à fait valide. Si tu peux l'utiliser, alors c'est *la* solution 
à ce problème.

Cordialement
Emmanuel Thierry

> 
> C'est particulièrement foireux d'un point de vue ipv4 mais commence à prendre 
> du sens quand on se place d'un point de vue ipv6. Je n'ai pas encore tous les 
> réflexes. Faut déjà revenir à une logique de gaspillage, j'ai du mal.
> 
> Julien
> 
> Le 01/09/2014 15:33, Julien Escario a écrit :
>> Bonjour,
>> Je tente de faire aspirer une page sur un serveur en ipv6 avec mon wget. Le
>> serveur n'a que du link-local, on est sur un même LAN.
>> 
>> Mais pas moyen de lui enfiler l'adresse :
>> $ wget http://[fe80::7827:c1ff:fe6c:a351]
>> --2014-09-01 15:23:42--  http://[fe80::7827:c1ff:fe6c:a351]/
>> Connecting to fe80::7827:c1ff:fe6c:a351:80... failed: Invalid argument.
>> 
>> $ wget http://[fe80::7827:c1ff:fe6c:a351%eth1]
>> http://[fe80::7827:c1ff:fe6c:a351%eth1]: Invalid IPv6 numeric address.
>> 
>> $ wget http://[fe80::7827:c1ff:fe6c:a351]%eth1
>> http://[fe80::7827:c1ff:fe6c:a351]%eth1: Invalid host name.
>> 
>> Une idée ?
>> 
>> Pour donner le problème dans sa globalité : je cherche à mettre un upstream 
>> ipv6
>> à mon nginx. Ca semble supporté depuis 1.3 environ donc largement. Mais 
>> encore
>> une fois, avec le link-local pour lequel il faut préciser l'interface quand 
>> on
>> fait un ping6 par exemple, ça ne passe pas ...
>> 
>> Merci,
>> Julien
>> ___
>> Liste de diffusion du FRsAG
>> http://www.frsag.org/
> 
> ___
> Liste de diffusion du FRsAG
> http://www.frsag.org/

___
Liste de diffusion du FRsAG
http://www.frsag.org/


Re: [FRsAG] wget et les adresses link-local

2014-09-01 Par sujet Julien Escario

Le 01/09/2014 17:58, Pierre DOLIDON a écrit :

* Mon idée est effectivement de faire disparaître totalement ipv4 de mon
réseau pour les services 'non frontaux' qui n'ont absolument aucun besoin de
me bouffer des IPv4.


la RFC1918 est si petite que ça pour parler de "bouffer des IPv4" ??? (et je
comprends pas la nécessité de faire disparaitre IPv4 d'un réseau de BACK).


Je parlais de bouffer des IP publiques.


Et RFC1918 + vlan, bof, c'est lourd à maintenir dans le temps.


Mettre tout le monde dans le même subnet sans aucun compartiment c'est bien pire
d'un point de vue topologie. Alors oui ça exige un peu de rigueur et de réf,
mais c'est bien plus propre a l'entretient c'est ça devient pas la cacophonie
sur ton vlan par défaut...


Ah, ca y est, on est déjà au moment où on va m'expliquer comment gérer mon cœur 
de réseau ?


Julien


___
Liste de diffusion du FRsAG
http://www.frsag.org/


Re: [FRsAG] wget et les adresses link-local

2014-09-01 Par sujet Julien Escario

Le 01/09/2014 18:17, Emmanuel Thierry a écrit :

ULA semblant (d'après ce que j'ai lu ici et là) en voie de deprecated, il ne me 
reste qu'à me faire attribuer un subnet natif que je vais firewaller et 
n'utiliser qu'en local.


Là il va falloir citer parce que ça me parait violemment faux. Et si c'était le 
cas, il n'y aurait pas des drafts en discussion dans le groupe IETF v6ops :
http://tools.ietf.org/html/draft-ietf-v6ops-ula-usage-recommendations-03

L'ULA est tout à fait valide. Si tu peux l'utiliser, alors c'est *la* solution 
à ce problème.


Ok, my bad, j'ai dû mal comprendre. Je vais me rencarder encore un peu sur ce 
mécanisme qui est effectivement présenté comme le penchant ipv6 du RFC1918 (j'ai 
bien 'penchant' hein, pas équivalent).


Julien
___
Liste de diffusion du FRsAG
http://www.frsag.org/


Re: [FRsAG] wget et les adresses link-local

2014-09-01 Par sujet Emmanuel Thierry

Le 1 sept. 2014 à 18:37, Julien Escario a écrit :

> Le 01/09/2014 18:17, Emmanuel Thierry a écrit :
>>> ULA semblant (d'après ce que j'ai lu ici et là) en voie de deprecated, il 
>>> ne me reste qu'à me faire attribuer un subnet natif que je vais firewaller 
>>> et n'utiliser qu'en local.
>> 
>> Là il va falloir citer parce que ça me parait violemment faux. Et si c'était 
>> le cas, il n'y aurait pas des drafts en discussion dans le groupe IETF v6ops 
>> :
>> http://tools.ietf.org/html/draft-ietf-v6ops-ula-usage-recommendations-03
>> 
>> L'ULA est tout à fait valide. Si tu peux l'utiliser, alors c'est *la* 
>> solution à ce problème.
> 
> Ok, my bad, j'ai dû mal comprendre. Je vais me rencarder encore un peu sur ce 
> mécanisme qui est effectivement présenté comme le penchant ipv6 du RFC1918 
> (j'ai bien 'penchant' hein, pas équivalent).

Au passage si tu veux vraiment respecter stricto-sensus les RFC, il faut que 
l'adresse soit générée aléatoirement :
* http://unique-local-ipv6.com/ (vrai aléatoire)
* https://www.sixxs.net/tools/grh/ula/ (basé sur une adresse MAC, mais bon, 
c'est mieux que rien)

Bon, ça c'est surtout utile si tu comptes un jour fusionner ton réseau ULA avec 
un autre réseau ULA au cours d'une opération de fusion-acquisition ! ;)

Cordialement
Emmanuel Thierry

___
Liste de diffusion du FRsAG
http://www.frsag.org/