Re: [FRnOG] [TECH] MTP Gender change

[Léo El Amri via frnog]

Ça semble pouvoir se faire à la mano avec deux punaises limées.

On 25/03/2024 17:53, David Ponzone wrote:

Je viens de le regarder mais faut l’outil vendu par Fibertronics je crois.

Sérieusement, c’est quoi cette norme de merde, le MTP, qui est pas capable de 
préciser systématiquement si chaque extrémité est mâle ou femelle.
Pas trouvé une doc correcte sur le sujet.


Le 25 mars 2024 à 17:49, Paul Rolland (ポール・ロラン)  a écrit :

Hello,

On Mon, 25 Mar 2024 17:26:32 +0100
Armel Chargé-Chauvet // frekences via frnog  wrote:


Nope, trop facile :)


DYI ? https://www.youtube.com/watch?v=NDJbp1y9p4A

Paul


---
Liste de diffusion du FRnOG
http://www.frnog.org/



---
Liste de diffusion du FRnOG
http://www.frnog.org/



---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] Obligation (ou pas) de maintenance des lignes

[Léo El Amri via frnog]

On 23/02/2024 16:55, David Ponzone wrote:

T’as pas vraiment répondu à ma question: est-ce que tu as vu ce repointage 
télécommandé par eux ?


Je ne suis pas au courant d'un éventuel repointage. Personellement je 
n'ai rien remarqué (pour mon usage, c'est la connexion de la maison). Je 
viens de sortir vérifier l'orientation de l'antenne, et il semble 
qu'elle "regarde" plus à l'ouest qu'avant (avant étant la dernière fois 
que je l'ai observée, il doit y avoir 6 ou 7 semaines).


Tu as des liens vers l'info comme quoi ils auraient réorienté des antennes ?


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] Obligation (ou pas) de maintenance des lignes

[Léo El Amri via frnog]

On 23/02/2024 11:39, Julien LIVENAIS via frnog wrote:

Le 23/02/2024 à 09:57, Daniel Caillibaud a écrit :
Mon FAI est SFR (ils ont eu un an d'exclusivité sur la fibre), qui m'a 
envoyé un tech mardi pour

constater que ça marchait pas, et depuis, rien…

Existe t-il vraiement un cas ou un opérateur d'infrastructure a une 
exclusivité commerciale sur le réseau FTTH qu'il a déployé ?
A ma connaissance, c'est une légende urbaine. Si quelqu'un a des 
éléments, je suis preneur !


Légende urbaines maintes fois "débunkée" dans cette liste. Il y a 
confusion avec le délais obligatoire que doit laisser l'OI au marché 
entre l'annonce de disponibilité du génie civil et la première vente. 
Enfin, un truc comme ça.



---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Les cabinets comptables & la cyber

[Léo El Amri via frnog]

On 19/02/2024 17:04, Vincent Duvernet wrote:

Bonjour,

J'avais déjà eu le cas il y a quelques temps avec un groupe Japonais mais là, 
ça fait 2 clients FR avec la même approche (visiblement par 2 cabinets 
différents).
Leur commissaire aux comptes demande une évaluation des risques cyber'.

On se tape des questions plus ou moins débiles / mal traduites du type :

- Une solution antivirus est-elle installée sur chaque poste de l'entreprise ? 
Est-elle mise à jour régulièrement ?
- La porte vers internet a-t-elle un pare-feu configuré ? Quels protocoles sont 
filtrés/interdits ? (ICMP, TCP, UDP,) [éviter nmap, SSH ou RDP .]

Et d'autres plus sensibles :
- Quels sont les sous-réseaux, leur IP et leur fonction ?
- Quels sont les outils (logiciels) mis en place pour la connexion à distance 
pour le télétravail ?

Là franchement, ça me hérisse le poil.
Est-ce que c'est juste moi qui suis trop old school pour ne pas vouloir divulguer des 
informations à un tiers de "semi-confiance" potentiellement exploitables pour 
une attaque ?


Quels sont vos retours sur la question ?


Je ne sais pas ce que dit le droit international, mais pour moi il est 
hors de question de fournir un plan de mon réseau interne. Communiquer 
grossièrement quelles sont les mesures de sécurité mises en place, 
quelles sont les méthodes d'accès aux données pour les collaborateurs, 
ou comment on gère les droits d'accès en interne, pas de problème. Mais 
donner le détail de _quel_ anti-virus est installé, c'est trop. La 
sécurité par l'obscurité n'a jamais protégé personne, mais faut pas 
déconner quand même. Ils n'ont pas besoin de savoir tout ça. Il me 
semble que même les banques françaises ne demandent pas ça à leurs 
prestataires.



---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] 240/4 strikes back

[Léo El Amri via frnog]

On 13/02/2024 04:35, Maximus . wrote:

Non, je ne fais pas de "l’internet". Je ne travaille pas chez des opérateurs 
tiers 1 2 3 4...
Je travaille juste dans le SI d’une entreprise, et je suis inscrit à titre 
perso sur cette liste pour avoir des news sur ce qu’il se passe.
Mon job aujourd’hui, c’est juste de faire en sorte que les machines 
communiquent entre elles et avec internet.
On s’est intéressé à l’IPv6 car ça proposait un truc intéressant, la 
disparition du NAT. Et vu le nombre de serveurs, ce n’est pas toujours simple 
les VIP IPv4.

On n'est pas des surdoués à développer et maintenir un linux qui permet de 
faire exactement ce que je veux. Donc on utilise un routeur qui nous aide avec 
du clic-clic.
Et on fait un peu de CLI pour les fonctions qui ne sont pas dispo, mais on 
n’est pas capable de plus.
Pour conf de la délégation, jusqu’à récemment, y’avait rien en clic-clic. Donc 
sur les sites avec 1 accès principal, et 1 backup, ça fonctionne, du NAT en v6.


Entendu. Bien sûr, c'est pardonnable si tu ne fais pas de l'Internet, 
encore plus si tu es admin-sys, on est souvent le dernier maillon de la 
chaine. Ça reste quand même l'affaire de tout le corps de métier, à mon 
avis (voir la discussion parallèle sur l'enseignement de l'IPv6 en France).



Pour les ULA, je ne sais si vous ne l’avez pas remarqué, mais un PC Windows 
adressé en ULA va préférer utiliser la couche IPv4. Quelle utilité de faire de 
l’IPv6 alors ?
Tests réalisés y’a déjà un petit moment, ça a peut-être changé aujourd’hui. Si 
c’est le cas, je serais heureux de l’apprendre.


C'est une regrettable conséquence de la RFC 6724. C'est un problème qui 
est apparu en 2012 et qui n'était pas là avant. Une sacrée régression. 
Ceci-dit, si tu contrôle les machines de ton parc, tu peux parfaitement 
modifier les règles de sélection d'adresse pour placer les ULA avant les 
IPv4. Je ne connais pas Windows, mais je ne serais pas surpris que ça 
soit modifiable facilement avec une GPO (peut-être même en clic-clic, 
mais je ne suis pas sûr).



Pour le choix du WAN qui dépends de l’hôte source, c’est juste qu’on ne fait 
pas de routage asymétrique. On n'est pas propriétaire de nos IP, pas d’AS, pas 
de BGP.
Si un PC avec une IPv6 de l’opérateur 1 sort sur le réseau de l’opérateur 2, 2 
options :
- l’opérateur détruit le paquet, car c’est pas du tout ce que le client est 
sensé avoir ;
- l’opérateur laisse passer, mais sur le chemin retour, le paquet arrive par 
l’accès de l’autre opérateur, et on a dit pas de routage asymétrique, donc 
détruit.


Il ne faut surtout pas faire ça. D'ailleurs tout bon FAI devrait 
interdire d'émettre des IPs dont il n'est pas responsable (et donc qu'il 
n'anonce pas), donc ça ne devrait même pas fonctionner.


La solution à ça est la même que pour l'IPv4, pas de magie : c'est le 
NAT (mais attention, tous les NATs ne se valent pas).



À ma connaissance, je ne vois pas comment fonctionne cette histoire de NAT 1:1 
sur Fortigate. Si c’est ça qu’il faut faire, je vais me renseigner pour voir 
comment configurer ça.
Mais vu la fin de la ligne, ou alors je n’ai pas compris, ça n’a pas l’air 
d’être la bonne solution.


La balle dans le pied c'est si on avait choisi le NAT IPv4-esque. Ce que 
j'appelle "NAT 1:1" c'est le NTPv6 : sur tous les préfixes du réseau 
(ceux du WAN (normalement des GUA), et celui du LAN (un ULA dans notre 
cas)), la partie hôte de l'adresse est la même. Ainsi le NAT est 
entièrement sans état et a simplement besoin de connaître la valeur et 
la taille de chaque préfixe.



Je profite juste de la discussion pour faire évoluer mes connaissances, par 
exemple avec l’histoire de NAT 1:1.


Et je te félicite !


De mon point de vue aujourd’hui, si on peut faire fonctionner la double-stack, 
sans avoir à inventer la roue, car l’IPv6 est censé être l’adressage du futur, 
on essaye.
Si ce n’est pas possible d’avoir les mêmes fonctionnalités, ben tant pis...


Je suis bien d'accord. Mais il ne faut pas dire que ça ne marche pas. Je 
trouve aussi que le dual-stack est très difficile à mettre en place, là 
où un réseau IPv4 simple ou un réseau IPv6 avec NAT64 et DNS64 sont bien 
plus simples à mettre en place. Mais, tu dois le deviner, le réseau 
uniquement IPv6 c'est pas possible, ne serait-ce que à cause des 
imprimantes (:



Car l’IPv4 est encore obligatoire. Aux Antilles, certains opérateurs ne 
proposent même pas l’IPv6. La 5G est là, mais pas l’IPv6. Et pas le petit 
opérateur local, c’est chez l’agrume (opérateur national Français, la filiale 
Antilles).
Si vous voulez les captures d’écrans, y’en a pour 5 minutes.
Même constat sur les abonnements maison. Chez l’agrume, y’a de l’IPv6, mais pas 
les autres.


Ça on est bien d'accord que c'est pas normal. Eux, ils font de 
l'Internet, et ils n'ont aucune excuse.


- Léo


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] 240/4 strikes back

[Léo El Amri via frnog]

Merci Philippe de rectifier les âneries qui ont été dites. À chaque fois 
qu'on parle d'IPv6 c'est pareil : "l'IPv6 fait pas ceci que l'IPv4 
fait", "le protocole ne supporte pas telle configuration", "ouïn ouïn 
mon routeur clic-clic ne supporte pas ce que je veux faire, c'est de la 
faute à IPv6".


Les gars, vous faites vraiment de l'Internet ?



Maximus nous dit:
> Dans notre cas, y’a 1 gros problème pour passer en IPv6
> Sur le site on a 2 opérateurs, chacun donne 1 /48.
> Comment je fait pour adresser ?
>
> En IPv4, suivant l’accès internet utilisé, ça sera naté par l’IP de 
l’interface utilisé pour soritr.


Et en IPv6 tu choisirais un préfixe ULA pour ton réseau interne et tu 
utiliserais NPTv6 en bordure.


IPv6 n'est pas moins bien qu'IPv4 sur ce point.

Maximus nous dit:
> Mais en IPv6, si j’adresse avec le /48 de l’opérateur 1, comment je 
fais pour sortir par l’opérateur 2 ?

> Du nat ?

Depuis quand le choix du WAN dépend de l'adresse IP de l'hôte source ?

Si dans ta configuration multi-WAN tu as choisi de déléguer le préfixe 
fournit par un de tes fournisseurs d'accès, alors oui tu vas devoir NAT. 
Tu peux NAT 1:1 ou bien choisir une configuration plus IPv4-esque. Libre 
à toi de te tirer une balle dans le pied si tu le souhaite.


Sur ce point IPv6 est pareil qu'IPv4.

Maximus nous dit:
> Oh le nat évoqué en IPv6, de l’urticaire se déclenche chez certains ;)

Jorropo nous dit:
> La réponse des puristes c'est tu à ton propre /48 et tu fait du BGP 
avec tes deux opérateurs.
> Sa peut être beaucoup plus de travail et coût, si le NAT fonctionne 
pour toi, utilise le NAT et osef les puristes.


La solution décrite pas Jorropo serait la solution idéale, mais tout le 
monde n'a pas accès à un bloc, ni aux possibilités de faire du BGP 
soi-même. En effet c'est cher, et de ce point de vue, IPv6 est même 
beaucoup moins coûteux en temps que IPv4. Un NAT 1:1 en NPT et c'est 
réglé, tu n'auras plus jamais affaire à ton NAT.


Les puristes anti-NAT sont aussi cons que ceux qui défendent l'IPv4 pour 
des raisons techniques.


David Ponzone nous dit:
> Ou sinon, tu fais en sorte que:
> -en temps normal, tous les PC obtiennent leur IP en DHCPv6 (ou autre, 
y a 2 ou 3 moyens non ? *grin*) du /48 de l’opérateur 1
> -en failover, tous les PC ont un renew de leur IP dans le /48 de 
l’opérateur 2

>
> Si IPv6 sait pas faire ça, c’est que c’est pas fini comme produit.
> Tu t’en sors quand même en utilisant des leases très courtes.

Le DHCPv6 n'est pas fait pour ça. Le NPTv6 ou bien un NAT sont bien 
mieux indiqués.


Jérôme Marteaux nous dit:
> Tu pointe les cas bien moisis d'ipv6, en plus d'être incompatible 
ipv6 ne copie pas les modes de fonctionnement bien compris et efficaces 
d'ipv4.
> Pour adresser un périphérique il y a n méthodes possibles dont 1 
seule qui ressemble à ipv4: DHCPv6.
> Côté ISP l'adressage des CPE c'est carrément différent, rien n'est 
transposable:

> - le mec qui avait compris ipv4 peut tout ré-apprendre;
> - l'équipementier qui avait implémenté ipv4 peut tout refaire;
> - le SI qui savait gérer ipv4 peut tout refaire.
> En général on essaye de valoriser l'acquis pour progresser, il n'y a 
pas eu cette réflexion sur IPv6, ça ne m'étonne pas qu'IPv6 soit un échec.


Incompatible avec quoi ? Quels modes de fonctionnements de l'IPv4 est-ce 
que l'IPv6 ne supporte pas ? Pourquoi est-ce que tu te plains d'avoir 
trop de choix, si tu aimes le DHCPv6, fais du DHCPv6.


Tout ré-apprendre c'est le métier de l'informatique. Si les pionniers de 
l'IT ont pu le faire, il n'y a pas de raison qu'on y arrive pas nous non 
plus. Si tu ne veux pas apprendre, il faut changer de métier.


L'équipementier qui avait implémenté l'IPv4 peut continuer de le faire 
(et de bien le faire) tout en sortant une nouvelle ligne de produits. Tu 
pointes un truc très juste : l'IPv6 c'est pas l'IPv4. Il faut arrêter 
d'essayer de les comparer en 1:1.


IPv6 n'est pas né ex-nihilo. Il s'appuie beaucoup sur l'IPv4. On peut 
tout à fait capitaliser sur nos connaissances de l'IPv4, il est 
illusoire de penser que nos connaissances de l'IPv4 sont rendues 
obsolètes par l'IPv6.


Jérôme Marteaux nous dit:
> Mais pour au final quelle valeur ajoutée ? Est-ce que ça a servi à 
quelque chose qu'IPv4 ne permettait pas ?


Si tu aimes le NAT alors en effet, IPv6 n'a rien apporté, excepté :
* une taille d'adresse si grande que ça résout le problème de collision 
d'adresses entre deux réseau privés
* une méthode d'adressage sans état qui permet aux hôtes de réseaux de 
toute taille d'avoir facilement des adresses

* le multicast intégré (et sans effort)
* des règles de traitement allégées (une seule extension à 
obligatoirement interpréter), ce qui le rend en théorie plus rapide que 
l'IPv4

* des options par noeud

Eh bien en fait il semblerait que l'IPv6 ait apporté des trucs, rien que 
dans sa RFC cœur.



---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] 240/4 strikes back

[Léo El Amri via frnog]

On 12/02/2024 09:27, Philippe ASTIER via frnog wrote:

"Obligatoirement" ? C'est une contrainte technique ? Je ne connais pas très 
bien la pile 3GPP, mais j'imaginais ça bien moins corrélé à l'IP que ça.


Pas technique, réglementaire. Cela dit, la stack 3GPP a poussé le support du 
dual-stack assez « tôt »  (plus de 10 ans maintenant), dès la 4G, avec une 
incitation plus forte en 5G.

L’ARCEP, le 21 novembre 2019, a publié l’obligation pour les opérateurs de 
réseau mobile de rendre leur réseau IPv6 compatibles avant le 31 décembre 2020. 
(S’ils voulaient faire de la 5G dans la bande 3,4-3,8 GHz).


Merci pour l'explication !


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] 240/4 strikes back

[Léo El Amri via frnog]

On 11/02/2024 19:54, Philippe ASTIER via frnog wrote:

Tout opérateur 5G est obligatoirement en IPv6, et ça inclut Free.


"Obligatoirement" ? C'est une contrainte technique ? Je ne connais pas 
très bien la pile 3GPP, mais j'imaginais ça bien moins corrélé à l'IP 
que ça.



---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [TECH] [FRnOG] [MISC] Erreur HTTP 408

[Léo El Amri via frnog]

On 24/12/2023 13:12, Stéphane Rivière wrote:

[...]



Pour confirmer la forme de l'installation :

* On a des cartes industrielles (C) (basées sur microprocesseur PIC) 
raccordées à un modem 4G. Ces cartes ont un client HTTP.


* On a un serveur HTTP (S) codé en Ada (ailleurs que sur les cartes).

* On a un reverse-proxy HTTP (P) Nginx (ailleurs que sur les cartes).

* On a une machine (H) quelque-part sur le VPN, qui est capable de faire 
tourner tshark.


* Tout ce beau monde communique sur un VPN basé sur OpenVPN.

Le client HTTP sur les cartes réalisent des requêtes HTTP vers le 
reverse-proxy HTTP, on a donc le schéma "réseau" suivant :


 |=[ Tunnel OpenVPN ]=|
[Client HTTP] ---> [Reverse-proxy HTTP]
 ||

Ta première capture tshark a été réalisée sur la machine H avec Firefox 
en guise de client, et a écouté l'interface OpenVPN.


Ta deuxième capture tshark a aussi été réalisée sur la machine H, mais 
en écoute seulement, aussi sur l'interface OpenVPN.


J'ai extrapolé des trucs, est-ce que c'est quand même bon ?



Pour moi, sans pouvoir voir les données, la deuxième capture ne révèle 
pas de problème au niveau TCP, si ce n'est l'étrange fragmentation, mais 
ce n'est pas si surprenant pour de l'embarqué. À ce stade, je dirais que 
le problème se trouve au niveau du payload TCP, il faudrait que tu 
affiches les données pour en savoir plus. En tous cas, du SYN au FIN, la 
communication semble normale.


Je ne connais pas tshark, et je ne comprend pas d'où vient l'affichage 
du début de requête GET. Est-ce qu'il affiche ça parce que le serveur a 
ACK ce morceau ? Ce n'est pas cohérent avec la quantité de données 
acknowledged par le serveur de toute façon. J'imagine que s'il ne 
l'affiche pas comme étant une requête HTTP, c'est que le flux est mal formé.


- Léo


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Provider mail pour collectivités

[Léo El Amri via frnog]

On 27/10/2023 10:25, Martin wrote:

Je cherche donc une solution qui soit accessibles aux collectivités. Et par
là j'entends qui permette une facturation par Chorus Pro pour ce que j'en
sais. Si en plus elle est respectueuse de la vie privée des administrés qui
nous envoient des mails, c'est parfait. Evidemment on va en profiter pour
faire u mail 2.0 en remplaçant mairie@wanadoo.fr à mai...@xxx.fr.


Témoignage anecdotique :

Ma petite commune (moins de 1500 habitants) a franchi le pas cette année 
en passant de wanadoo.fr à un nom de domaine et une boite de courriel 
chez OVH. Je ne m'en suis pas occupé, pour le moment ils en sont contents.



---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Rayon de courbure FO mono vs. multi

[Léo El Amri via frnog]

On 16/10/2023 19:03, Émile Touron wrote:

Son argument est que la multimode résiste mieux aux rayons de courbure
forts, et que les chemins de câble pour accéder aux caméras disposent
souvent d'angles assez serrés. Avec de la mono, dit-il, dans certains cas
on n'aurait pas de signal.


Absence de preuve n'est pas preuve d'absence, mais je n'ai jamais 
constaté de différence sur le terrain. Comme tout câble, le rayon de 
courbure dépend de plusieurs facteurs. Le procédé de fabrication d'une 
fibre est le même, que ce soit pour la monomode ou la multimode, seul 
l'enrichissement du dépôt change. Vu les diamètres en jeu, tant que la 
gaine n'est pas écrasée dans la courbure, il y a très peu de chance que 
l'âme ait souffert. Il faudrait vérifier les spécifications de votre 
câble. Personnellement sans trop me soucier des datasheet, j'ai toujours 
respecté la règle du "huit fois le diamètre du câble" sans que ça ne 
pose de problème observable. Dans le cas d'une fibre, cette règle 
autorise presque les angles francs à 90 degrés.


Je classe ça dans les légendes urbaines jusqu'à preuve du contraire.


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] problème PDU : courant de fuite

[Léo El Amri via frnog]

On 09/10/2023 19:18, fr...@r0m5.eu wrote:

J'en arrive aux questions :
- 1 mA de courant de fuite par alim de switch vous paraît-il cohérent ? 
Nous savons testé avec une autre marque, nous sommes plutôt aux 
alentours de 0,5mA.


Ça me semble énorme dans les deux cas. Comment est-ce que vous avez 
mesuré le courant de fuite sur vos alims ? Est-ce que tu as testé les 
alimentations seules ? Si non, est-ce que tu as vérifié si ce n'est pas 
le switch ou les câbles/équipements qui y sont branchés qui posent 
problème ?


- des différentiels 30mA sont-ils à votre connaissance utilisés en 
datacenter ? un différentiel pour chacune des deux sources d'alim 
redondées d'une baie ? J'aurai tendance à penser que oui pour la 
protection des personnes mais dans un job précédent nous remplissions 
bien nos baies dans nos datacenters parisiens et nous n'avons jamais à 
ma connaissance eu de problème de différentiel qui saute.


Les différentiels 30mA sont obligatoires dans le tertiaire à partir du 
moment où des personnes peuvent intervenir à proximité de la BT (c'est 
normé par la NF C 15-100 et imposé par je ne sais quelle loi).


Pour des questions de résilience, on adopte souvent une sélectivité fine 
dans son installation électrique, un différentiel par source 
d'alimentation ne me surprend pas, au contraire, ça me semble être une 
bonne pratique.



---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH]Gestion du cycle de vide de développement applicatif en environnement cloud privé

[Léo El Amri via frnog]

Bonjour Eugène,

On a bien reçu ton message, mais j'imagine que c'est un peu hors-scope 
dans la FRnOG.


Mon avis sur la question (en tant que développeur - quelqu'un qui 
conçoit un logiciel (pas juste qui le programme, on appellerait ça un 
programmeur sinon)), c'est que tu montres par toi-même que tout ça est 
incompréhensible tant qu'on ne définit pas les termes qu'on emploie au 
cas par cas. Pendant un temps on disait que les DevOps était la capacité 
d'un "développeur" à faire de l'administration système, puis petit à 
petit c'est devenu l'automatisation de processus de développement (tests 
automatisés, vérification de la qualité de code, etc.). Pour ces 
questions de vocabulaire flou, je ne peux pas réagir sur les 
"anti-patterns" du DevOps. Ils peuvent être vrai ou faux en fonction de 
la définition du mot.


Le "Platform Engineering" ne change rien au problème, ça sera, à mon 
avis, encore une expression utilisée à tort et à travers.


On m'a souvent mit l'étiquette DevOps (je ne sais pas pourquoi) et je 
n'ai jamais fait de "cloud" à proprement parlé, chose qui était plutôt 
réservées à des équipes d'administration système (ceux qui gèrent des 
hyperviseurs de VMs ou du K8S en entreprise, par exemple). Ce à presque 
toute taille d'entreprise (les toutes petites ne peuvent pas se 
permettre d'avoir des salariés dédiés à certaines tâches, mais les 
autres semblent le pouvoir).


En sachant que je ne suis pas admin réseau :

Je ne pense pas que les administrateurs réseau soient spécifiquement 
concernés par la question du "platform engineering".


Pour faire du GitOps, il faut pouvoir définir ton infra par du texte, ce 
qui n'est pas toujours possible. Ce n'est pas une solution miracle, tout 
comme ne le sont pas le DevOps, le SecOps et autres DevNetSecOps++.


Pour moi, faire travailler un ensemble de gens spécialisés chacun dans 
un domaine, avec un outil commun et une méthode de définition d'infra 
commune, c'est sympa mais pas toujours possible. Ça s'appelle l'IaaS, et 
on ne le retrouve pas forcément dans tous les cloud, et dans ceux qui le 
pratiquent ça ne se retrouve pas à tous les niveaux.


Pour le reste, ce que j'ai constaté en tant qu'acteur externe aux 
équipes réseau, c'est que c'est bien souvent séparés et que les équipes 
réseau n'utilisent pas les outils des équipes système, qui n'utilisent 
pas les outils des équipes développement logiciel.


La seule fois où j'ai vu un système commun pour tout le monde (dans une 
boite du CAC40), c'était lourd et tout le monde s'en plaignait.


Je pense que la clef dans tout ça, serait que les admin-sys restent 
experts de leur domaine, que les admins-réseau restent experts de leur 
domaine, et que les développeurs soit pluridisciplinaires et aient des 
connaissances de base sur le système et sur le réseau.


Je trouve que les objets définis de base dans K8S offrent un découpage 
assez raisonnable des différentes responsabilités au sein d'une SI.


- Léo

On 06/09/2023 16:35, Eugène Ngontang wrote:

Hello,

Mon mail a été bloqué par l'équipe de modération ou alors il est totalement
hors scope pour tout le monde?
Ou bien il vaut mieux le formaliser sous forme de survey?

Cordialement,
Eugène NG

Le mer. 23 août 2023 à 03:11, Eugène Ngontang  a
écrit :


Hello tout le monde.

Je reviens sur le sujet du DevNetOps, cette fois sous le prisme de la
gestion du cycle de vie de développement logiciel (SDLC) en environnement
cloud privé, mettant à contribution les équipes réseaux et système.

En effet, je vais me permettre de rappeler que le DevNetOps ou NetOps ou
encore NetDevOps, est l'application des pratiques DevOps aux opérations
réseaux. Plus simplement  ça vise principalement l'automatisation des
opérations réseaux.

Ainsi tout comme le DevOps a ouvert la porte aux anti-patterns, le
DevNetOps a sûrement fait pareil.  Quelques exemple d'anti-patterns :

- Le DevOps coincé entre les Dev et les Ops
- le NoOps des Dev qui n’ont pas besoin d’Ops
- le DevOps est un outil
- le SysOps ou le NetOps dont on a juste changé le nom en DevOps,
- L’Ops intégré dans l’équipe Dev,
- …

C'est pour palier à tous ces écarts que l'on parle beaucoup plus du
Platform Engineering (buzzword de 2023), dont le but n'est pas de
substituer au DevOps, mais de l'implémenter correctement.

Cependant la tendance est toujours d'aborder ces concepts xOps avec une
vision cloud (public cloud) native, ce que je trouve personnellement très
limitant. Alors ma question ou alors mes questions, dont les réponses
dépendront bien sûr des entreprises/organisations et uses cases. :

- Quid du platform engineering pour les gurus du réseau ?

- Est ce que vous vous contentez d'automatiser et orchestrer
exclusivement les flux de provisioning/déploiement réseau en traitant le
réseau comme un produit, une application avec son propre SDLC?

- Est ce que vous fournissez plutôt des landing zones : *backbone

Re: [FRnOG] [BIZ] Déstockage Sniffing -> Surveillance qualité réseau électrique

[Léo El Amri via frnog]

On 18/09/2023 16:02, Toussaint OTTAVI wrote:


Le 18/09/2023 à 12:01, Nicolas Vuillermet a écrit :
Après, j'imagine qu'il faut d'abord qualifier le bruit avec un 
analyseur de spectre pour savoir si le filtre est dans la bonne gamme... 


Il y a quelques semaines, pas pour les mêmes raisons, je m'interrogeais 
sur un dispositif automatisable de surveillance de qualité des réseaux 
électriques. Un truc qui fait des mesures en permanence et les envoie 
dans un InfluxDB / Grafana. Dans mon cas, il s'agissait de caractériser 
des baisses de tension, ou micro-coupures, beaucoup plus fréquentes que 
la normale sur une zone géographique donnée. La surveillance des 
harmoniques, que ce soit du CPL de m..., des onduleurs défaillants, le 
voisin radioamateur :-) çà n'est pas non plus dénuée d'intérêt. A la 
fois pour identifier les "perturbateurs", mais aussi les conséquences 
potentielles sur les "perturbés".


Par contre, je n'ai rien trouvé de tout fait (à part l'analyseur de 
spectre R qui coûte 10 fois le prix du matos à protéger, et encore, il 
faut rajouter un Raspberry Pi si on veut publier les résultats en MQTT).


Je pensais donc me bricoler un truc, mais je me heurte au capteur à 
utiliser, et surtout au fait que çà soit relié au secteur.
Pour mesurer la tension et la fréquence, çà va, ce ne sera pas trop 
compliqué, et surtout sans risques, derrière un transfo abaisseur calibré.
Par contre, pour mesurer des harmoniques sur le 220V, c'est moins 
évident... Derrière un transfo abaisseur, çà risque d'atténuer sévère.
A la rigueur, il faudrait un oscillo numérique bon marché capable de 
visualiser une onde secteur à 220V. Ensuite, un ESP8266 WiFi pour 
l'isolation galvanique, un peu de FFT, et çà pourrait le faire.


Quelqu'un a déjà fait çà ? Ou a des idées ?


J'en ai pas, mais ça fait plusieurs mois que je veux faire ça aussi. Je 
veux bien quelques plans ou quelques sources, si tu en as, du capteur de 
tension et de fréquence pour du monophasé.



---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] [France Inter] Les ratés de la fibre

[Léo El Amri via frnog]

On 12/09/2023 11:09, Toussaint OTTAVI wrote:


Le 12/09/2023 à 10:57, Léo El Amri via frnog a écrit :
Quand le gestionnaire de réseau de déplacera pour raccorder un abonné 
et se rendra compte que c'est déjà fait, alors que ça n'est pas 
enregistré chez eux, plusieurs fois, ils va se poser des questions sur 
qui câble sans son accord.


Le technicien va forcément se déplacer, il va forcément devoir trouver 
un plot au PM et brasser vers le PBO. Dans le PBO, il n'aura que la 
soudure à faire (le reste étant déjà fait). Donc, c'est du 
gagnant-gagnant pour tout le monde. Et, si ledit tech fait son job 
correctement,  la ligne sera correctement répertoriée.




Si il est question de tirer un câble optique du DTIo jusqu'à la chambre 
en bordure de propriété, alors oui, "n'importe-qui" peut le faire sans 
aucune autorisation, en effet, quasiment tout le monde est gagnant (sauf 
peut-être l'abonné, pour qui cette installation aurait été gratuite s'il 
avait laissé son opérateur faire).


Tirer jusqu'au PB, est aussi probablement faisable sans que ça ne gêne 
personne, mais ça reste probablement illégal.


J'ai 5 DTIo à poser dans une ancienne ferme séparée en appartements, je 
tirerai 4 câbles jusqu'à la chambre en bordure de propriété, et un câble 
jusqu'au PB, on verra ce qu'on me dit (je suis desservi par un RIP de 
l'Agrume dans la diagonale du vide).



---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] [France Inter] Les ratés de la fibre

[Léo El Amri via frnog]

On 12/09/2023 10:34, Toussaint OTTAVI wrote:


Le 12/09/2023 à 09:39, Léo El Amri via frnog a écrit :
Dans la plupart des cas, les fourreaux ou poteaux ne sont pas 
accessibles librement. Il faudrait que chaque artisan ait obtenu 
l'accord de l'exploitant ou du responsable d'infrastructure pour poser 
des câbles.


Ah bon, il faut demander l'autorisation à quelqu'un ? :-D :-D :-D

Les grossistes en matériel électrique vendent des bobines de fibre avec 
le PTO déjà soudé. N'importe quel électricien qui travaille proprement 
pourra faire le job. Dans la mesure où cela permet d'éviter un éventuel 
échec, je ne vois pas qui s'en plaindra. Ni le sous-traitant, qui n'aura 
que la soudure à faire, ni l'opérateur commercial, puisqu'il n'en saura 
probablement jamais rien :-)


Quand le gestionnaire de réseau de déplacera pour raccorder un abonné et 
se rendra compte que c'est déjà fait, alors que ça n'est pas enregistré 
chez eux, plusieurs fois, ils va se poser des questions sur qui câble 
sans son accord. En vérité, je pense que ça leur posera problème quand 
même. En tous cas, j'éspère !



---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] [France Inter] Les ratés de la fibre

[Léo El Amri via frnog]

On 12/09/2023 09:21, Toussaint OTTAVI wrote:

Le 12/09/2023 à 00:06, br...@skiwebcenter.fr a écrit :
Sur le résidentiel, la meilleure solution est sans doute de trouver un 
bon artisan qui va faire une pose "propre" jusqu'au PBO le plus proche.


Dans la plupart des cas, les fourreaux ou poteaux ne sont pas 
accessibles librement. Il faudrait que chaque artisan ait obtenu 
l'accord de l'exploitant ou du responsable d'infrastructure pour poser 
des câbles. Et vu combien le processus semble automatisé et le rigide du 
côté des 4 gros, je vois pas comment ça peut marcher. Même la zone à 
faible densité de ma campagne est couverte par Orange plutôt que par un RIP.


Si c'est une bonne idée sur le papier, ça a l'air d'être un cauchemar 
juridique, et il existe si peu d'artisan de la fibre que j'ai du mal à 
voir comment mettre ça en place concrètement.



---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Distance MINIMUM pour utilisation fibre monomode et sfp 10G

[Léo El Amri via frnog]

On 26/08/2023 08:36, Guillaume Roux wrote:

Bonjour à tous,

Existe-t-il une documentation claire sur les contrindications à l’utilisation 
de fibre monomode et 10G sur des courtes distances.
J’ai beau rappeler à mes collègues qu’en DC il n’y a que de la mono même pour 
de l’inter baie ou entre équipement intra baie on continue de me parler 
éblouissement et atténuateur et donc maintien de la multimode.

Et si je trouve moult documents sur débits max et longueur max, je trouve assez 
peu de chose sur la longueur minimum pour ne pas avoir besoin d’atténuateur.

Merci d’avance aux experts fibres pour leur partage d’info.

Guillaume


Avertissement : je n'avais jamais touché à de la fibre télécom avant le 
mois dernier, et je n'en ai installé qu'une seule pour mon homelab, mais 
j'ai fait plein de recherches à cette occasion, et j'ai fait appel à de 
vieilles connaissances acquises lors de mes cours de physique optique.


Je ne connais rien à la fibre en application télécom, mais dans la fibre 
de façon générale ça se calcule avec l'atténuation par unité de longueur 
et le nombre de raccords sur le chemin. Il se trouve que (sur le 
terrain, pas en laboratoire) les fibres "multimode" ont une plus forte 
atténuation par unité de distance que les fibres "monomode".


Il doit bien exister une "règle empirique", que tu dois connaître, sur 
l'affaiblissement aux raccords. Pour le reste j'ai l'impression que ça 
dépend beaucoup de l'équipement utilisé. Au niveau des modules SPF, je 
n'ai pas trouvé de "logique" sur les puissances d'émission/réception. 
J'en ai déduit que c'est du cas par cas. Personnellement je me suis 
simplement assuré que la puissance à la réception n'était pas supérieure 
à la valeur maximale admise par mon récepteur. Les modules SPF pour 
lesquels j'ai lu la fiche technique supportaient tous au moins leur 
puissance d'émission en réception. Dans mon cas j'ai juste eu à 
installer un atténuateur de 3dB parce que mon SFP Juniper émettait plus 
fort que ce que pouvait recevoir mon SFP Mikrotik.


Bref. La distance en DC étant négligeable, ce n'est qu'une question de 
comptabilité de matériel. Je ne vois pas trop ce que viennent faire des 
atténuateurs dans une infra pro, puisqu'on devrait s'attendre à voir 
exactement les mêmes modèles de SPF au bout des câbles dans la plupart 
des cas. Les cas où ce n'est pas possible (routeurs de marques 
différentes avec vendor-lock par exemple), je vois mal comment ça peut 
être autre-chose qu'une configuration sur-mesure. Il faudra sortir son 
cerveau.


En tous cas j'aimerais aussi une réponse à cette question.


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [FRNOG][MISC] Facturation RIPE et Chorus Pro

[Léo El Amri via frnog]

La seule vraie réponse ici. Merci Damien.

Pour les intéressés, voici l'ordonnace qui (ne) précise (pas vraiment) 
quelles sont les entités concernées : 
https://www.legifrance.gouv.fr/jorf/id/JORFTEXT29140226


Il faut lire entre les lignes, si la domiciliation des entreprises ne 
compte pas, c'est parce que seules les entreprises françaises y sont 
soumises (les formes de société listées étant françaises).


Bien entendu, il est aussi possible de se placer en tant que mandataire 
pour la réalisation du paiement, je pense que ça doit être possible 
auprès du RIPE, mais ça serait utile seulement si la compta de 
l'administration est trop rigide. L'avantage de cette solution est 
qu'elle est sans frais (parfaitement optionnels), autres que ceux de la 
réalisation du mandat, qui, soyons honnêtes, ne dépasse pas 1h de travail.


Cordialement,
Léo

On 31/07/2023 18:04, Damien DUJARDIN wrote:

Bonjour à tous,

Chorus Pro ne concerne que les fournisseurs français. Le RIPE ayant son
siège aux Pays-Bas, aucun problème pour facturer à l'ancienne.

Certaines administrations n'aiment pas ça, mais c'est parfaitement légal.

Chez nous on a l'habitude, ça passe tout seul au service comptable.

Là ou ça se complique c'est quand une grosse multinationale facture depuis
un siège à l'étranger, mais en utilisant une adresse d'une entité (parfois
fictive) en France.  Ou comment faire appliquer la loi Chorus Pro à des
polonais ou des japonais qui ne parlent pas anglais



Le lun. 31 juil. 2023 à 17:47, Marc Abel  a écrit :


Bonjour,

Jusqu'à ce jour on a réussi à régler nos factures RIPE directement.

Notez qu'on paye d'un côté la partie HT au RIPE-NCC et de l'autre la TVA
française (à l'état je suppose).

Comme la facture n'arrive pas dans le SI facturation il faut la
récupérer et l'y injecter (merci aux collègues qui font ça).

Le souci vient du délai trop court donné par le RIPE-NCC pour régler la
facture versus nos délais d'instruction et ceux du payeur qui effectue
le virement in fine.

Marc ABEL pour CD93

Le 31/07/2023 à 15:12, Olivier Pruneyrac a écrit :

Bonjour,

Nous intervenons pour accompagner une métropole dans sa déclaration en

tant que LIR auprès du RIPE.

A ce titre la métropole se demande comment la facturation pourra avoir

lieu compte tenu de l'obligation de passer par Chorus Pro pour facturer une
administration française.

Le RIPE ne peut pas utiliser Chorus Pro.

Une administration française LIR abonnée à frnog pourrait-elle nous

indiquer comment elle réalise l'enregistrement de la facturation RIPE ?
Passe elle par un intermédiaire pour cela ?


Merci d'avance

Cordialement

Olivier Pruneyrac
06 26 65 68 43




---
Liste de diffusion du FRnOG
http://www.frnog.org/

[MISC] Triangulation ou trilatération ? (WAS: [FRnOG][MISC] [Émeutes] Interdiction des réseaux sociaux ?)

[Léo El Amri via frnog]

Bonjour la liste,

Dans le cas de la géolocalisation dans un réseau de téléphonie 
cellulaire, est-il question de triangulation ou de trilatération ?


Réponse : De la trilatération.

Pareil pour le GPS, le WiFi RTT et n'importe quelle autre technologie 
qui utilise trois points ou plus aux coordonnées relatives connues, et 
une distance entre ces points et le point dont on cherche la localisation.


Et vous, le saviez-vous ? Si non, pourquoi appeliez-vous la 
trilatération "triangulation" ?


Pour ma part, ce qui explique pourquoi je n'ai jamais questionné le 
terme, c'est que des professionnels de la radio m'ont appris ça quand 
j'étais au Lycée en l'appelant "triangulation". Et ils mettaient le même 
mot sur la technique de triangulation et celle de trilatération. 
Pourtant ces techniques sont utilisées dans des situations et pour des 
besoins complètement différentes. Ce n'est que ce week-end, en 
travaillant sur un projet avec un ami, que j'ai découvert que ça 
s'appelle la "trilatération" et non la "triangulation".


--
Léo


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Mise en œuvre d'IPv6 dans les infrastructures mail

[Léo El Amri via frnog]

On 26/06/2023 22:18, Laurent Barme wrote:

Le 26/06/2023 à 21:23, Léo El Amri via frnog a écrit :
Je ne comprend pas très bien comment c'est possible. Est-ce qu'on 
parle d'un serveur HTTP ? Si oui, est-ce que "le serveur non contacté" 
est derrière un reverse-proxy ? 
Il s'agit bien sûr d'un serveur HTTP (…non de domaine…). Il n'y avait 
pas de "reverse-proxy" (et je vois pas trop ce que cela vient faire ici).


Alors du coup je n'ai rien compris à l'architecture. Il n'y a pas de 
concept d'erreur TLS dans un navigateur si le serveur ne répond pas.


Si non comment est-ce que le client peut avoir une erreur TLS si le 
serveur n'est jamais atteint ?
Le serveur n'est jamais atteint car il n'écoutait pas sur une IPv6. 
L'erreur de certificat est manifestement un bug (et une fausse piste qui 
m'a fait perdre du temps). Voici mon hypothèse : l'OS résout le nom de 
domaine en IPv6, le navigateur ne parvient pas à obtenir le certificat 
SSL pour cette IPv6 (pas de réponse du serveur) affiche une erreur TLS 
au lieu d'essayer de passer par l'IPv4 à moins que l'OS refuse de 
fournir une IPv4 puisqu'il a trouvé une IPv6 pour le nom de domaine.


Je ne connais aucun navigateur avec ce comportement, mais soit.
Déjà, l'OS résout le nom de domaine pour les familles d'adresse 
demandées par l'application. Si cette dernière ne supporte pas happy 
eyeballs, il y a de fortes chances qu'elle tente la première réponse 
qu'elle a obtenu. Admettons que ce soit une adresse IPv6. Si le 
navigateur essaye de se connecter en TLS sur l'adresse IP retournée par 
l'OS, mais que personne ne répond en face, l'application n'a même pas 
l'occasion de négocier du TLS, donc il ne devrait même pas y avoir 
d'erreur de certificat TLS. Enfin, l'OS n'a pas la responsabilité de se 
connecter sous une autre adresse IP, c'est l'application qui décide ça, 
et si elle est naïve, il y a de fortes chances qu'elle ne retente rien, 
et qu'elle affiche que le site est indisponible.
Si l'application montre un autre comportement que celui-ci, c'est 
qu'elle est sérieusement cassée.


(Par OS je sous-entend iOS ou Android)

depuis un mobile via la 4G (quelque soit le navigateur utilisé) alors 
qu'il fonctionne bien par ailleurs ! Depuis le même mobile, toujours 
en 4G, un autre site sur le même serveur fonctionne pourtant sans 
souci. Le blocage se produit sur le réseau Orange et Bouygues mais 
pas sur Free ni en WiFi (via une ADSL).


La cause était une IPv6 aussi définie pour le nom de domaine alors 
que le serveur n’était pas configuré pour accepter les connexions 
IPv6. Comme Orange et Bouygues privilégient manifestement l'IPv6 
quand il y en a une déclarée… évidemment ça coince.


Pour moi c'est un problème logiciel : Le happy eyeballs n'a pas été 
utilisé.
Ok le "happy eyeballs" n'a manifestement pas été utilisé mais il est 
impossible d'intervenir au niveau du logiciel/OS des visiteurs d'un site.


Je rappelle que ce sous-fil de discussion (désolé Louis pour la 
digression) part de mon témoignage à propos d'une intervention à faire 
impérativement sur le logiciel d'après une réponse de Bertrand.


Je suis d'avis de ne pas supporter les logiciels cassés dans une 
certaine mesure. Là on est dans cette "certaine mesure". Les standards 
existaient avant les implémentations dans la nature (un bon contre 
exemple est IRC). Essayer de supporter ces logiciels défectueux ce 
serait comme lorsqu'on essayait de continuer de supporter IE5 en 2010. 
On voit l'impact que ça a eu sur le "web". Sauf que là on a même pas 
l'excuse de "c'est l'application la plus utilisée du monde".


La solution aura été de simplement supprimer l'entrée  de la zone 
DNS pour le nom de domaine. Configurer le serveur web pour de l'IPv6 
aurait considérablement agrandi la surface d'attaques possibles.


Et un problème humain ! Si le serveur n'accepte pas l'IPv6, 
l'administrateur n'aurait jamais du renseigner de  dans la zone !


Tout à fait ; c'est toujours un problème humain si on remonte 
suffisamment la pile. D'ailleurs si l'humain n'avait pas inventé l'IPv6… 
:-))


C'est vrai, mais il ne faut pas abuser. Et là on parle de LA personne 
qui est sensée être le plus au courant de l'environnement qu'elle 
configure. En plus si le serveur est déjà utilisé pour d'autres sites et 
que les zones DNS de ces autres sites n'ont pas d'IPv6, ça met la puce à 
l'oreille.



---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Mise en œuvre d'IPv6 dans les infrastructures mail

[Léo El Amri via frnog]

On 26/06/2023 18:48, Laurent Barme wrote:


Le 26/06/2023 à 17:38, Bertrand FRUCHET via frnog a écrit :

Bonjour la liste,

C'est pas l'IPv6 qu'il faut désactiver, c'est le logiciel qu'il faut 
changer quand vous avez des dysfonctionnements.


Ce n'est pas toujours le logiciel qu'il suffit de changer. Voici un 
retour d'expérience comme exemple :


Les symptômes étaient sibyllins : un nouveau site sur un nouveau nom de 
domaine se prend une erreur SSL d'emblée (le serveur n'est même pas 
sollicité)


Je ne comprend pas très bien comment c'est possible. Est-ce qu'on parle 
d'un serveur HTTP ? Si oui, est-ce que "le serveur non contacté" est 
derrière un reverse-proxy ? Si non comment est-ce que le client peut 
avoir une erreur TLS si le serveur n'est jamais atteint ?


depuis un mobile via la 4G (quelque soit le navigateur 
utilisé) alors qu'il fonctionne bien par ailleurs ! Depuis le même 
mobile, toujours en 4G, un autre site sur le même serveur fonctionne 
pourtant sans souci. Le blocage se produit sur le réseau Orange et 
Bouygues mais pas sur Free ni en WiFi (via une ADSL).


La cause était une IPv6 aussi définie pour le nom de domaine alors que 
le serveur n’était pas configuré pour accepter les connexions IPv6. 
Comme Orange et Bouygues privilégient manifestement l'IPv6 quand il y en 
a une déclarée… évidemment ça coince.


Pour moi c'est un problème logiciel : Le happy eyeballs n'a pas été utilisé.

La solution aura été de simplement supprimer l'entrée  de la zone 
DNS pour le nom de domaine. Configurer le serveur web pour de l'IPv6 
aurait considérablement agrandi la surface d'attaques possibles.


Et un problème humain ! Si le serveur n'accepte pas l'IPv6, 
l'administrateur n'aurait jamais du renseigner de  dans la zone !



---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] Re: [TECH] Mise en œuvre d'IPv6 dans les infrastructures mail

[Léo El Amri via frnog]

On 26/06/2023 19:06, Laurent Barme wrote:


Le 26/06/2023 à 18:50, Léo El Amri via frnog a écrit :

On 26/06/2023 18:32, Laurent Barme wrote:



…


Il ne me semble pas déraisonnable de bloquer des /64 (ou /56 voir /48 
si on est vraiment pas content). Par contre je ne vois pas où est le 
danger. Si c'est une question de taille de table de blocage, tu ne 
peux de toute façon pas bloquer moins qu'un /64 dans un bloc IPv6, 
entre autre en raison du point suivant (les extensions de "vie privée" 
IPv6).


2^64 > 2^32 ; même en bloquant par /64, ça en fait potentiellement un 
peu plus quand même question taille de table de blocage.


En effet, c'est possible. Mais je pense que ça dépend moins du nombre 
d'adresses disponibles que du nombre d'attaquants actifs. Un /64 en IPv6 
c'est souvent l'équivalent d'un /32 en IPv4. Le problème de taille de la 
table de blocage se pose SI les attaquants ont accès à plus de /64 IPv6 
qu'ils n'auraient accès à des /32 IPv4. Et dans ce cas, en effet, il 
faudrait faire des règles de blocages intelligentes ou carrément faire 
du DPI. Je n'ai jamais été exposé à ces problèmes donc je ne me rend pas 
compte de la "chance" que ça arrive. Mais des solutions existent, donc 
la (grande) taille de l’espace d'adressage me semble être un argument 
peu recevable pour justifier de ne pas utiliser l'IPv6.


Pour ce qui concerne la menace que je perçois pour la vie privée 
c'est lié à l'identification plus précise de l'utilisateur dont le 
poste n'est pas (un peu) masqué par une IP publique partagée.


Il me semble que jusqu'à très très récemment, la plupart des 
équipements dans une "maison" étaient tous derrière une unique IPv4 
publique. Et je ne vois pas en quoi les extensions de vie privée de 
l'IPv6 (pour le SLAAC), qui émulent plus ou moins le même niveau de 
"""protection""" que le type de NAT IPv4 sus-mentionné, ne répondent 
pas au besoin. On peut certes mieux identifier une machine sur une 
session donnée, mais, pour Windows en tous cas, au prochain 
redémarrage l'adresse IPv6 aura changé. Je ne pense pas qu'on puisse 
faire mieux au niveau de la couche IP.
Tu as raison mais la ré-attribution d'une IPv6 par poste ça peut être 
désactivé, le NAT non. De plus, si entre deux redémarrage sous Windows, 
l'IPv6 reste constante alors, le port du NAT change à chaque nouvelle 
requête.


Pour moi, si le comportement par défaut ne respecte pas la vie-privée, 
c'est un problème logiciel. À l'époque de la RFC 4941 on aurait pu dire 
que c'est un problème humain (de configuration), mais désormais la 
recommandation de NE PAS faire de cette option un comportement pas 
défaut a été retiré (RFC 8981). Linux est un assez mauvais élève par 
défaut, mais les solutions user-land sont très bonnes. Windows est 
curieusement un bon élève par défaut : activé et changement toutes les 
24h ou à chaque redémarrage.


Si l'utilisateur veut désactiver les options de "vie privée", qu'on le 
laisse faire !



---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] Re: [TECH] Mise en œuvre d'IPv6 dans les infrastructures mail

[Léo El Amri via frnog]

On 26/06/2023 18:32, Laurent Barme wrote:


Le 26/06/2023 à 18:07, Léo El Amri via frnog a écrit :

On 26/06/2023 17:23, Laurent Barme wrote:
l'IPv6 est [...] un danger potentiel pour la sécurité et une menace 
pour la vie privée.


Comment ? Pourquoi ?

(On est pas vendredi, je demande vraiment)

Il n'y a pas de "vendredi" pour moi (je bosse tous les jours).


Merci :)

Si tu as des archives, tu peux retrouver la discussion suite à mon 
message sur le sujet le 26/04/21 08:45. Tiens, cela fait moins 
de 10 ans, Denis n'est pas encore complétement sorti de son hibernation 
:-).


Elles sont parties en cold-storage, et les archives en ligne ne semblent 
pas remonter si loin :/


Sinon, pour le danger potentiel c'est lié pour moi au nombre d'IP qu'il 
faudrait bloquer. En ce sens, l'échange cité ci-dessus m'a permis de 
prendre sereinement la décision de bloquer les IPv6 par /64.


Il ne me semble pas déraisonnable de bloquer des /64 (ou /56 voir /48 si 
on est vraiment pas content). Par contre je ne vois pas où est le 
danger. Si c'est une question de taille de table de blocage, tu ne peux 
de toute façon pas bloquer moins qu'un /64 dans un bloc IPv6, entre 
autre en raison du point suivant (les extensions de "vie privée" IPv6).


Pour ce qui concerne la menace que je perçois pour la vie privée c'est 
lié à l'identification plus précise de l'utilisateur dont le poste n'est 
pas (un peu) masqué par une IP publique partagée.


Il me semble que jusqu'à très très récemment, la plupart des équipements 
dans une "maison" étaient tous derrière une unique IPv4 publique. Et je 
ne vois pas en quoi les extensions de vie privée de l'IPv6 (pour le 
SLAAC), qui émulent plus ou moins le même niveau de """protection""" que 
le type de NAT IPv4 sus-mentionné, ne répondent pas au besoin. On peut 
certes mieux identifier une machine sur une session donnée, mais, pour 
Windows en tous cas, au prochain redémarrage l'adresse IPv6 aura changé. 
Je ne pense pas qu'on puisse faire mieux au niveau de la couche IP.



---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] Re: [TECH] Mise en œuvre d'IPv6 dans les infrastructures mail

[Léo El Amri via frnog]

On 26/06/2023 17:23, Laurent Barme wrote:

Stephane (Borrtzmeyer) est prescripteur et pas acteur


Si Bortzmeyer n'est pas acteur, que faut-il faire pour l'être ?

Est-ce que moi je le suis ? En tant que simple consommateur d'Internet 
(je n'ai pas d'AS ni de réseau publique) est-ce que activer l'IPv6 sur 
mes machines hébergées "dans le cloud", configurer mes quelques réseaux 
privés correctement pour que ça "juste marche(TM)" en IPv6 et développer 
la compatibilité des applications (lorsque c'est nécessaire) ne fait pas 
de moi un acteur ? Est-ce qu'il faut forcément être un AS pour prétendre 
au titre d'acteur ? Si oui, je ne comprend pas comment l'Internet tout 
court a pu exister (notons que je n'étais pas né). L'échelle était 
certes plus petite qu'aujourd'hui, mais si à l'époque on a réussi en 
partant de rien, je ne vois pas comment aujourd'hui on ne pourrait pas 
réussir en partant de quelque-chose de similaire. Les APIs sur nos OS 
sont déjà prêtes (même si ça reste un peu le bordel pour certains), il 
nous manque juste le réseau.


Et puis il faut rester cohérent sur les critiques qu'on fait à l'IPv6. 
Si c'est un problème d'inertie, pourquoi est-ce que Google y arrive et 
pas les PMEs (ou "artisans") ? Si c'est une question de moyens, pourquoi 
Twitter n'y arrive pas, mais que Ungleich y arrive ? Et si c'est une 
question de lacunes, comment ça se fait que des réseaux (privés) 
dual-stack comme pur-IPv6 existent et tournent correctement ?
Si ce n'est ni une question d'inertie, ni une question de taille, ni une 
question de moyens, ni une question technique, qu'est-ce qu'il reste ? 
Le facteur humain ? Je ne veux pas en arriver à ce "point godwin de 
l'IPv6" un peu facile, mais franchement je vois pas ce que ça peut être 
d'autre que "la flemme".


Je veux bien qu'on ait des problèmes d'IPv6 ; rien qu'à mon échelle j'en 
ai rencontré une pelletée. Je blame en partie Linux et en partie les 
applications que j'utilise, mais surtout je me blame moi pour ne pas 
avoir pris le temps de considérer l'IPv6 comme ce que c'est : Un 
protocole différent, qui demande à ré-apprendre une partie du réseau, et 
qui, par sa nouveauté (si on peut encore dire ça) est encore mal intégré 
dans nos écosystèmes techniques.


Enfin, je ne comprend pas ceux pour qui l'IPv6 donne de l'urticaire 
alors que le NAT ne leur en donne pas.


My-2ct-qui-valent-moins-que-2ct


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] Re: [TECH] Mise en œuvre d'IPv6 dans les infrastructures mail

[Léo El Amri via frnog]

On 26/06/2023 17:23, Laurent Barme wrote:

l'IPv6 est [...] un danger potentiel pour la sécurité et une menace pour la vie 
privée.


Comment ? Pourquoi ?

(On est pas vendredi, je demande vraiment)


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] Pire que Sogetrel.....

[Léo El Amri via frnog]

On 20/06/2023 23:07, Spyou wrote:

Le 19/06/2023 à 10:35, David Ponzone a écrit :

On a trouvé, ça s’appelle SOLUTIONS30.

On a jamais vu des guignolos pareils, et devinez-quoi, c’est le 
sous-traitant Number1 de l’agrume (sur le FTTH) dans certains coins.


Bon, après, ça sert à rien de le dénoncer puisque on a pas le choix 
mais peut-être qu’à force de voir leur nom dans des commentaires 
négatifs, ils vont finir par réagir.

Peut-être même qu’ils sont sur la liste…

Le problème: essentiellement des annulations de RDV FTTH (clients pro) 
à la dernière minute (plus de 50% des cas)
La question: est-ce qu’il y a autant d’annulations sur des clients pro 
Orange directs….



Je préfère encore 80% d'annulation que les sous-traitants de chez nous 
qui montent à pieds joints sur les tiroirs optiques pour brancher leurs 
jarretières.


J'ai perdu une vidéo d'une intervention de Sogetrel à un NRA/NRO Orange 
près duquel ils tiraient de la fibre aérienne en jetant des boucles de 
câble par dessus les poteaux pour essayer de faire s'accorcher ledit 
câble aux supports cuivre existants.

Ça mieux s'ils avaient annulé eux aussi.


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] Gandi, c'est fini...

[Léo El Amri via frnog]

On 18/06/2023 22:38, David Ponzone wrote:

Coop alors que n’importe qui ici peut se monter un mailcow en 15 min ?
Je me demande si c’est pas un peu overkill.


Pour le moment ce qui a été proposé c'est de lancer un service NDD + 
mailbox qui marche et qui soit vraiment NoBullshit (Désolé Gandi mais 
vous avez perdu le droit d'utiliser ce slogan).


Sauf que c'est accompagné de beaucoup de problèmes déjà évoqués, dont le 
plus gros, à mon avis, qui est qu'on s'adresse à des clients 
non-techniques qui vont solliciter le support pour rien (et qui coûtera 
probablement le plus cher, de loin).


Sinon on peut lancer un service uniquement NDD, avec serveur de noms 
primaire fournit quand même, mais dans ce cas il y a peu de chances de 
trouver des clients puisque les seuls intéressés seraient des individus 
tech, ou des sociétés qui ont besoin de sous-traiter cette activité 
(genre les boites d'hébergement mutualisé, ou simplement les 
sous-traitants d'autres boites qui ne font pas de web). Sauf que 
derrière tu dois payer 4000 USD par an à l'ICANN et négocier avec tous 
les registry du monde (et ça je sais pas combien ça coûte) (ou alors se 
concentrer sur juste quelques TLDs, mais ça ne résout pas le problème de 
la masse critique requise pour amortir les coups de matraque de l'ICANN 
et des TLDs).


Donc soit on fait un truc qui existe déjà et qui n'apporte rien (d'autre 
que l'éthique) au marché, soit on fait un truc de niche qui risque fort 
de ne pas marcher.


En attendant, il y a l'OpenNIC Project (https://www.opennic.org/)...

PS : Même si l'idée 2 marche pas, ça m'intéresse d'essayer


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] Gandi, c'est fini...

[Léo El Amri via frnog]

On 16/06/2023 18:02, Noryungi wrote:

Laisse tomber tout de suite cette histoire de chatbot.


Mais le reste ça te va ?!


Le 16/06/2023 à 15:01, Victor UETTWILLER a écrit :

En soit, la meilleur idée serait d'ouvrir ce service avec une société
qui faisait de la presta de NDD avec Gandi et qui part. Faire une sorte
de réunion de société mécontent de l'augmentation fulgurante des prix de
Gandi.


Niveau code, l'abonnement Chat-GPT 4 coûte dans les $24/mois non ? Ça va
pas revenir bien cher.

Niveau doc, il y a tout ce qu'il faut déjà en ligne, là encore j'ai
pété, et on se fait une base standard.

Niveau support, pour le chatbot j'aimerais bien tenter d'entrainer un
guanaco 65B pour ça, mais il y en a pour 25k€ de matos minimum et 2kW
donc c'est peut-être une fausse bonne idée. On n'a qu'à faire un
offshore en Tunisie (ils sont en dèche) si vous savez pas gérer vous-même.



---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] Gandi, c'est fini...

[Léo El Amri via frnog]

C'est vendredi chez DuckDuckGo apparemment... 
https://duckduckgo.com/?q=powermail=h_=web


PS : En fait j'ai testé la recherche en français, et ça apparait en 
premier résultat dans ce cas. Donc c'est un PEBKAC.


On 14/06/2023 17:46, David Ponzone wrote:

Euhh, https://www.powermail.fr <https://www.powermail.fr/> non ?

C’est vendredi ? :)


Le 14 juin 2023 à 17:42, Léo El Amri via frnog  a écrit :

On 14/06/2023 16:52, Bertrand FRUCHET via frnog wrote:

- les mails chez Powermail ( un "petit" très efficace car spécialisé dans cette 
activité)


Est-ce qu'il est possible d'avoir un pointeur vers ce "Powermail" ?



---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] Gandi, c'est fini...

[Léo El Amri via frnog]

On 14/06/2023 16:52, Bertrand FRUCHET via frnog wrote:
- les mails chez Powermail ( un "petit" très efficace car spécialisé 
dans cette activité)


Est-ce qu'il est possible d'avoir un pointeur vers ce "Powermail" ?


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] Gandi, c'est fini...

[Léo El Amri via frnog]

On 14/06/2023 14:34, Arnaud Launay wrote:

Le Wed, Jun 14, 2023 at 01:48:30PM +0200, David Touitou a écrit:

Ceux qui ne sont pas chez Gandi, où êtes-vous ?


Bookmyname. Une bonne interface années 90, parfaitement fonctionnelle, il 
existe une
API, les tarifs sont raisonnables. Pour les fonctionnalités avancées, pas sûr: 
c'est
un registrar, pas un FSI.


PI, BookMyName est le nom commercial de vente de NDD de Online 
(maintenant "Scaleway").


Je n'ai jamais été client NDD chez eux depuis la création de Scaleway, 
mais je pense qu'il y a plus de fonctionnalités sur l'interface de 
Scaleway (https://www.scaleway.com/fr/domains-and-dns/) que sur 
l'interface de BookMyName.



---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [MISC] [FRnOG] [ALERT] Incident elec Netcenter Vénissieux

[Léo El Amri via frnog]

On 09/06/2023 18:42, julien soula wrote:

On Fri, Jun 09, 2023 at 06:05:58PM +0200, Léo El Amri via frnog wrote:

[.../...]
Je me souviens qu'il existait aussi un truc similaire à IPFS mais pour du
calcul plutôt que pour du stockage, utilisé par un projet de recherche
scientifique sur le pliage des protéines et qui avait le mot "Mesh" dans le
nom il me semble, est-ce que quelqu'un voit ce que c'est ?


folding@home ? (mais y a pas "Mesh" pour le coup)

a+,


Merci ! Ça ne me dit rien, mais grace à ça je crois que j'ai retrouvé ce 
dont je parlais. Je crois que c'est World Community Grid [1]. Par contre 
il n'y a ni projet de pliage de protéine (ou alors il y a eu un 
"sponsoring" pendant quelques temps), ni "Mesh" dans le nom. Mais comme 
ça date d'il a plus de 15 ans maintenant, ma mémoire doit me faire défaut.


Enfin, là où je voulais en venir, c'est que avec IPFS combiné à un 
système comme WCG (en plus générique), on a du DC-less qui répond à 
presque tous les besoins non-réseau.


Reste que les télécoms pourront difficilement se passer des DC, en tous 
cas en France, tant qu'on aura pas pris des mesures drastiques de 
décentralisation de l'architecture du réseau, comme nous en discutions 
sur la liste il y a quelques mois.


[1] : https://www.worldcommunitygrid.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [MISC] [FRnOG] [ALERT] Incident elec Netcenter Vénissieux

[Léo El Amri via frnog]

On 09/06/2023 17:49, David Ponzone wrote:

Y a du Cloud qui est pas dans un DC ?

Ou alors il faut pratiquer le multi-cloud, en s’assurant de pas dépendre des 
mêmes DC.


Le 9 juin 2023 à 17:45, Léo El Amri via frnog  a écrit :

On 09/06/2023 17:36, Renaud wrote:

On 09/06/2023 17:05, Stéphane Rivière wrote:

[../..]

Quand on voit que même Google se vautre suite à un seul incident dans
un seul DC, il y a de quoi être circonspect...

+1 Personne n'est à l'abri. Enfin, on peut imaginer que, désormais, les
onduleurs et les batteries au "fond du jardin", comme les GE, ça va
devenir la règle...
[../..]


Vivement le datacenterless, il y a un business model d'avenir là-dessus!

J'aurais juré que ça existait déjà et que ça s'appellait "Le Cloud".


En tant que """développeur""", vu comment on me le vend, je croyais que 
c'était magique et qu'il n'y avait pas d'ordinateur derrière "Le Cloud".


Pardon je pensais qu'on était trolldi.

Plus sérieusement : Je constate que le multi-cloud ou multi-DC est déjà 
une pratique assez courante, en m'appuyant sur ma propre expérience chez 
des clients. Ils avaient pourtant soit voué un culte à l'Amazone du 
Service de la Toile, soit vendu leur âme au grand Azure, mais la 
disponibilité était une caractéristique recherchée lorsqu'elle n'était 
pas déjà vendue clef en main.


Et depuis que je bosse (2015), il a toujours été question de réplication 
sur des lieux différents en ce qui concerne le stockage (et ça pour le 
coup c'est assez bien supporté par tous les cloud grand-publique que je 
connais (GCP, AWS, Azure et Hetzner).


Pour finir, le DC-less est déjà un peu ce que propose IPFS[1] et autres. 
Avec ces trucs là, la planète entière devient un DC plus ou moins résilient.


Je me souviens qu'il existait aussi un truc similaire à IPFS mais pour 
du calcul plutôt que pour du stockage, utilisé par un projet de 
recherche scientifique sur le pliage des protéines et qui avait le mot 
"Mesh" dans le nom il me semble, est-ce que quelqu'un voit ce que c'est ?


[1] : https://ipfs.tech/


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [MISC] RE: [FRnOG] [ALERT] Incident elec Netcenter Vénissieux

[Léo El Amri via frnog]

On 09/06/2023 17:36, Renaud wrote:

On 09/06/2023 17:05, Stéphane Rivière wrote:

[../..]

Quand on voit que même Google se vautre suite à un seul incident dans
un seul DC, il y a de quoi être circonspect...

+1 Personne n'est à l'abri. Enfin, on peut imaginer que, désormais, les
onduleurs et les batteries au "fond du jardin", comme les GE, ça va
devenir la règle...
[../..]


Vivement le datacenterless, il y a un business model d'avenir là-dessus!


J'aurais juré que ça existait déjà et que ça s'appellait "Le Cloud".


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] Re: [ALERT] Nombreuses coupures de fibres optiques en France

[Léo El Amri via frnog]

On 29/04/2022 09:16, Toussaint OTTAVI wrote:

Le 29/04/2022 à 08:27, David Ponzone a écrit :


(et niveau empreinte CO2 non plus probablement).


Là, par contre, je ne vois pas comment un paquet qui fait 
Ajaccio-Ajaccio pourrait consommer plus de CO2 que le même paquet qui 
monte à Paris, fait un petit tour sur le périph' optique, puis 
redescend. J'ai même eu des cas où çà passait... par la Nouvelle-Zélande 
!


On est vendredi, mais je prend ça au premier degrés quand même, car 
c'est un sujet très intéressant. Est-ce qu'il y a eu des études sur 
l'impact écologique des télécommunications terrestres (cuivre ou fibre) ?


D'un point de vue purement écologique :

Je vois la centralisation comme un point positif, pour la mutualisation 
des ressources et la possibilité de ne pas trop surdimensionner les 
capacités (quand tout passe par un point, c'est plus facile de 
dimensionner pour 100% de capacité plutôt que quand tu n'es pas sûr de 
par quel chemin vont passer tes paquets).


Par contre je ne vois pas en quoi un paquet consommerait plus ou moins 
en fonction de la distance. Traverser 200km ou 1km, ça devrait 
revenir au même, théoriquement. Physiquement et techniquement on a 
forcément des noeuds sur notre chemin, et chaque noeud consomme un peu, 
que ce soit un simple répéteur de signal ou un routeur. Dites moi si je 
me trompe. Si je ne me trompe pas, alors on peut réduire le problème à : 
"une route avec plus de noeuds consommera plus qu'une route avec moins 
de noeuds, quelle que soit sa distance physique".


Et dans ce cas, je me pose une question à laquelle je n'ai pas de 
réponse : à quoi ressemblerait un maillage plus fin ?


Je n'ai certes pas de réponse à cette question, mais je me dis quand 
même que pour passer à un maillage plus fin, il suffit d'interconnecter 
d'avantage les noeuds, sans avoir nécessairement besoin d'en ajouter. 
Est-ce naïf ?


Et, pour "l'efficience", est-ce qu'on ne pourrait pas conserver des 
longues lignes de cuivre/fibre qui permettent de "court-circuiter" une 
série de plus petites routes ? (à la façon dont fonctionne le réseau 
routier ? Pour faire un Paris -> Lyon, si on veut être efficace, on ne 
passe pas par des départementales)


Enfin, mais ça c'est tellement une évidence que je ne devrais même pas 
le dire. Avoir plus de matériel est moins "écologique" qu'avoir moins de 
matériel (impact écologique de la fabrication, toussa toussa). Et poser 
un câble, qu'il soit en cuivre ou en fibre, est coûteux en énergie, et 
demande de traverser des écosystèmes, c'est à prendre en compte dans le 
calcul de l'impact écologique.


--
- Léo


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] Tiens, STARLINK is out.

[Léo El Amri via frnog]

On 06/04/2022 08:31, Rémy Grünblatt wrote:
Sur le sujet, autant mettre le lien vers la décision elle même: 
http://www.conseil-etat.fr/fr/arianeweb/CE/decision/2022-04-05/455321


Pour résumer...

Ce qui a été retenu par les chambres du Conseil d'État, c'est que 
l'ARCEP n'a pas respecté le V de l'article L31-1 [1]. Sauf qu'ils ne 
disent pas en quoi l'ARCEP de l'a pas respecté. Comme l'a dit Stéphane 
Rivière, est-ce qu'on considère que ça a une incidence importante parce 
que le service de Starlink marche beaucoup mieux que les offres ADSL à 
la campagne ?


Si c'est juste ça, il suffit à l'ARCEP de réaliser une consultation 
publique, et dans deux mois Starlink ré-obtient ses autorisations. J'ai 
bien suivi ?


Pendant ce temps, si Starlink maintient son service, est-ce que l'État 
va gaspiller des resources pour aller chercher quelques k€ d'amende dans 
un pays étranger ? Je ne dis pas qu'il ne faut pas le faire pour la 
forme. Mais grossièrement ça ressemble à une grosse mascarade. Est-ce 
qu'on a sollicité le publique quand l'électricité s'est démocratisée ? 
Est-ce qu'on a sollicité le publique quand les micro-ondes sont devenus 
des équipements indispensables des cuisines modernes ? Est-ce qu'on a 
sollicité le publique quand on a construit des trottoirs dans des 
villages paumés et peu fŕequentés de Haute-Loire ? (Bon, ça en vrai 
c'est possible, j'imagine que personne a dit non tellement l'idée était 
absurde de base)


[1]: https://www.legifrance.gouv.fr/codes/article_lc/LEGIARTI43545201

--
Léo


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] Tiens, STARLINK is out.

[Léo El Amri via frnog]

On 06/04/2022 07:56, Yoann QUERET wrote:


On 06/04/2022 07:37, Mickael Monsieur wrote:

On sait si starlink a déjà cessé d’émettre ?


J'ai un accès Starlink en Haute-Savoie qui fonctionne toujours


Et j'en ai un en Haute-Loire qui fonctionne encore pour le moment.

et je me 
posais la question des conséquences de ce retrait des autorisations et 
des échéances..


Ca me semble difficile de couper le service en France uniquement. 
Peut-être en fonction du lieu d'installation ?


Ça me semble pas si difficile, les sanctions vont tomber sur StarLink si 
elle continue d'émettre alors qu'elle n'a plus l'autorisation. Quid de 
notre situation légale en tant qu'usagers ? Est-ce qu'on va payer aussi 
si on continue d'utiliser notre parabole propriétaire aux paramètres 
mystiques ? Est-ce qu'on peut prétendre qu'on ne sait pas ce qu'on fait ?


--
Léo


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] Re: [MISC] IPv6 - Posséder son adresse

[Léo El Amri]

On 20/03/2022 13:00, Daniel via frnog wrote:


Le 20/03/2022 à 12:54, Stephane Bortzmeyer a écrit :

On Sat, Mar 19, 2022 at 04:50:13PM +0100,
  Matic Vari  wrote
  a message of 16 lines which said:


Une petite question naïve, j’avoue ne pas avoir fouillé trop sur le
site du RIPE, mais est-ce qu'un particulier pourrait posséder son
adresse IPv6 [1]?

Un exemple de quelqu'un qui l'a fait :

https://blog.ataxya.net/un-as-chez-soi-cest-possible/

Mais, bon, lisez quand même les bémols soulevés ici, à juste titre.

Je l'ai fait et n'ai rencontré aucun bémol.



Pareil.

Et la partie la plus importante à mon avis, le côté pratique, est 
manquant: Comment tu montes tes tunnels, avec quels protocols, quels 
transitaires, où les trouves-tu, combien ça coute, etc ? Payer pour 
avoir son AS et ses IPs c'est bien, mais il y a forcément aussi un coût 
au peering. Non ?



---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] [JOBS] [Grenoble] Administrateur(trice) système et réseau (CDI)

[Léo Berry]

Bonjour,

Dans le cadre de notre développement, nous recherchons actuellement
un(e) administrateur(trice) système et réseau pour intégrer le pôle
hébergement de l'entreprise.

Poste et missions

Sous la responsabilité du Responsable d'exploitation, vous évoluerez au
sein de l’équipe Admin-sys.

Vous aurez à mener des missions tel que:

Des travaux d'ingénierie système dans un environnement Linux/Debian,
automatisation avec Puppet et des cluster HA avec Ganeti.
La maintenance opérationnelle de l'infrastructure répartie sur 2 sites
physiques et des services hébergés: clusters et machines virtuelles
dédiés, sites et applicatifs Web, bases de données, système de
messagerie, serveurs vocaux.
Des travaux d'ingénierie réseau avec du routage BGP, OSPF, des switchs
Cisco.
Support niveau 2 et 3


Profil recherché

Nous recherchons une personne motivée et passionnée par la perspective
de gérer une infrastructure sur toute la chaine depuis la fibre optique
jusqu'au déploiement de l'application.

Expérience significative de 3 à 5 ans dans l'administration de système
Linux.
Formation supérieure (Bac+3/+5) avec une forte composante système et réseau.
À l'aise sur de la programmation orientée système/réseau et du scripting
avec des langages comme Python et Bash.
Avoir pratiqué des outils de déploiement et d'automatisation comme
Puppet, Chef ou Ansible.
Être contributeur actif ou avoir une expérience avancée sur la
distribution Debian serait un gros plus.
Des notions sur d'autres langages hébergés sur nos services comme PHP
serait un plus.
Une expérience sur des architectures basées sur des conteneurs comme
Docker serait un plus
Une expérience sur l'intégration continue d'application web serait un plus

Type de contrat

CDI à pourvoir immédiatement.
Rémunération en fonction de l’expérience
Avantages : Mutuelle, chèques déjeuners, chèques vacances,
intéressement, participation, et bien sûr l’objectif de devenir associé.
Accessoirement beaucoup de vie d’entreprises avec des sorties tous les 3
mois alliant cohésion d’équipe et plaisir de la table… On en dira pas
plus ici ;-)

L'entreprise

Mezcalito est une agence de communication digitale au format SCOP qui a
fait le choix affirmé depuis sa création d’avoir un véritable pôle
hébergement.
Nous sommes une équipe jeune et dynamique et travaillons dans un cadre
agréable situé au centre de Grenoble coté parc de la Caserne de Bonne.
En tant que SCOP le bien être des salariés est primordial et n’est pas
une vue de l’esprit. Ici tout est fait pour que tout le monde soit
content de venir travailler.

Chez Mezcalito c’est Work Hard and Have Fun !

https://www.mezcalito.fr/manufacture-digitale/

N'hésitez pas à transmettre votre CV à l'adresse : cont...@mezcalito.fr.

Cordialement,

-- 



Léo Berry
Administrateur Systèmes et Réseaux
32 allée Henri Frenay / 38000 Grenoble
04 76 01 03 91 / https://www.mezcalito.fr




---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Retours d'expériences KVM IP

[Léo]

Le 23 novembre 2016 à 19:27, Arnaud Launay <a...@launay.org> a écrit :
>
> Le Wed, Nov 23, 2016 at 07:01:24PM +0100, David Ponzone a écrit:
> > Je pense qu’on parle de KVM souris/clavier/VGA depuis toute à
> > l’heure, ou c’est moi qui ai besoin de sommeil ? :)
>
> Ca marche avec un Unix avec une console sur ttyS, mais non: c'est
> moi qui ait besoin de sommeil, ça ne répondra effectivement pas
> au besoin de l'OP...
>
> Ils peuvent faire pas mal de trucs, mais pas de
> clavier/souris/VGA, en effet.
>
> En passant, l'IPMI de la dernière génération de cartes mères
> SuperMicro a une fonctionnalité "console over HTML5" qui juste
> marche, et qui n'a plus besoin de java. Par contre, pas possible
> de monter une iso virtuelle.
>
> Arnaud.

Et si le KVM sait faire serveur VNC, il doit être possible de placer
noVNC (https://kanaka.github.io/noVNC/) devant. Seul un navigateur
récent (HTML5+WebSockets) est requis pour accéder à
écran/clavier/souris ensuite. Ça marche plutôt bien, je m'en sers pour
mettre à disposition des postes virtuels.

Léo


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] #Brexit et conséquences

[Léo]

Le 24 juin 2016 à 12:19, Jérôme Nicolle  a écrit :

> Plop,
>
> Contre toute attente [1], les résultats du référendum au Royaume-Uni
> sont en faveurs du Brexit.
>
> OSEF ? Pas tant que ça. Pour deux raisons :
>
> - Le carré magique
>
> Ça n'a du échapper à personne, mais les plus grosses place de marché
> européennes en terme de réseau sont Francfort, Amsterdam, Londres et
> Paris (bon dernier des quatre [2], on se demande pourquoi).
>
> Les infrastructures historiques ne bougeront pas. LINX n'a pas l'air
> plus inquiet que ça, quoi que ce n'est peut-être qu'une posture. On en
> saura plus au prochain Euro-IX[3] en novembre.
>
> Par contre, il y a des infras là ou il y a du business pour les
> rentabiliser. Et là…
>
> - Les migrants
>
> Avec la sortie de la Grande Bretagne de l'Union Européenne, un bon
> nombre d'acteurs (de l'Internet ou d'autres industries) vont devoir
> s'établir sur le continent pour continuer à opérer sur le marché européen.
>
> La tendance est observable depuis quelques mois dans certaines activités
> gravitant autour du FRnOG, et devrait s'accentuer.
>
> Où peuvent se délocaliser nos amis financiers et startups anglaises ?
> Paris ? C'est moins cher que Londres, mais un peu loin même en train.
> Amsterdam ? Pour le coup c'est cher et loin. Bruxelles ? Un peu
> provocant vu les bons sentiments de la majorité anglaise à son égard. Et
> Lille ?
>
> La région Hauts-de-France à une grande expérience de la gestion de
> l'immigration [4] et se montre très accueillante envers les anglais [5].
> Il y a du foncier (lire : des champs), du jus (Gravelnes), du staff
> (OVH a bien tout présélectionné, voir sur GitHub[6]), des réseaux, des
> bureaux au dessus de la gare qui met Londres à 80 minutes…
>
>
>
> Tout ça pour dire : Business as Usual, 'faut en profiter, et autant se
> placer du bon coté [7].
>
>
> 
>
> [1]
>
> http://www.boursorama.com/actualites/brexit-pourquoi-une-telle-conviction-du-maintien-sur-les-marches-et-chez-les-bookmakers-3f1e75f7bd26cad2f7bd611540e1c114
>
> [2] https://en.wikipedia.org/wiki/List_of_Internet_exchange_points_by_size
>
> [3] https://www.euro-ix.net/news-and-events/euro-ix-forum/
>
> [4]
>
> http://www.franceinfo.fr/emission/l-interview-politique/2015-2016/migrants-calais-pour-xavier-bertrand-il-faut-mettre-hors-d-etat-de-nuire-les-no-borders
>
> [5]
>
> http://www.lejdd.fr/Politique/Migrants-Xavier-Bertrand-aux-Anglais-Il-ne-faut-pas-abuser-de-notre-patience-744896
>
> [6] https://github.com/search?utf8=%E2%9C%93=ovh
>
> [7] https://vimeo.com/4810412
>
> --
> Jérôme Nicolle
> 06 19 31 27 14
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>


Dans la même veine, quid des services hébergés là-bas ? Le RU faisant
partie de l'UE, il était possible d'y héberger des données personnelles des
ressortissants européens sans autre formalité que la déclaration CNIL
habituelle.
Bref, ça présage peut-être un mouvement aussi de ce côté, même si je ne
doute pas que nos politiciens se dépêcheront (ou pas, quand on voit le
Privacy Shield) de mettre en place un accord adéquat… qui se fera
certainement plomber par la CJUE comme le Safe Harbor (et, bientôt, le
Privacy Shield, parce que fondamentalement les choses n'ont pas changé).

---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] [JOBS]

[Léo Dugué]

Bonjour,

Actuellement en première année de BTS SIO (services informatiques
aux organisations - option réseaux)  je suis à la recherche d'un stage
pratique en entreprise en région parisienne. Ce stage est non rémunéré et a
pour but de valider ma première année d'études, d'une durée d'un mois et
demi, mi mai à fin juin, cette expérience doit me permettre d'observer
le fonctionnement d'un service informatique, réseau ou développement ,
pour compléter la formation théorique.

Si vous pensez pouvoir m’accueillir dans votre entreprise, vous pouvez me
contacter entre autres au numéro indiqué.
Ne pouvant pas le mettre en pièce jointe, je vous ferai parvenir mon cv
ainsi que mes coordonnées complètes sur demande.

Merci par avance,

Léo Dugué - 06.38.99.04.30

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] Re: [ALERT] Problème sur la racine du DNS

[Léo]

Le 1 décembre 2015 21:02, Suixo <su...@securem.eu> a écrit :
> Le 01/12/2015 19:18, Léo a écrit :
>> Est-ce que quelques gars avec de gros tuyau ne pourraient simplement
>> pas s'adresser à des résolveurs malencontreusement ouverts placés un
>> peu partout autour du globe et leur demandant des TLD inexistants,
>> obligeant les résolveurs à interroger les serveurs racine ?
>
> Qu'on m'arrête si je me plante, mais :
> * si tu envoies 1000 requêtes par seconde à un résolveur ouvert (qui autorise 
> les requêtes récursives, donc), qui lui va les transmettre aux serveurs 
> racines
> * alors tu ne produis sur le serveur (racine) cible que 1000 requêtes par 
> seconde
> * à condition de bien randomiser tes requêtes pour ne pas que le serveur 
> récursif fasse de mise en cache
> * et du coup autant envoyer directement tes requêtes aux serveurs racine
>
> Je fais l'hypothèse que ton gros tuyau te permet de tuyauter jusqu'aux 
> serveurs racines, et que passer par un réflecteur (résolveur ouvert) ne te 
> fait pas gagner en bande passante.

Dans le scénario que je mentionne, le but n'est pas d'avoir une
amplification, mais simplement de pouvoir viser plus de serveurs
racine différents à partir d'un unique point géographique, pour lequel
l'anycast l'aurait toujours emmené sur les mêmes machines. Et oui,
pour obliger à interroger les racines à chaque requête, ça implique
d'avoir un TLD différent par requête. Mais avec quasi 63 octets
disponibles, tu as largement de quoi voir venir…

>
> Un cas classique d'utilisation de ces serveurs, par contre, est quand tu 
> spoofe l'adresse source (et que tu mets l'IP de ta cible), en interrogeant 
> par exemple un domaine que tu contrôle pour des enregistrements TXT très 
> gros. Du coup tu envoies des (petites) requêtes TXT spoofées, et le serveur 
> récursif (qui cache ces gros résultats) va renvoyer les (grosses) réponses 
> vers la cible. Et paf, amplification et potentiellement DoS.
>
> J'ai bon ?
> J'imagine que les gourous du DNS pourront me corriger :)
>
> Mickaël
>
> PS: J'aurais bien aimé avoir l'avis d'un Bortzmeyer sur ces commentaires 
> https://news.ycombinator.com/item?id=10655075
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] Re: [ALERT] Problème sur la racine du DNS

[Léo]

Le 30 novembre 2015 17:55, Michel Py
<mic...@arneill-py.sacramento.ca.us> a écrit :
>> Pascal PETIT a écrit :
>> C'est impressionnant car pour écrouler un serveur anycasté, il faut que 
>> l'attaque vienne
>> de sources suffisamments variées pour voir toutes les "instances" du serveur.
>
> C'est généralement le cas des DDOS. Ce n'est pas 1 type avec un gros tuyau 
> qui attaque un serveur de jeux, mais des dizaines de milliers de PC 
> contaminés par un merdiciel, distribués dans le monde entier. Le premier D 
> dans Ddos.
>
> Quelqu'un a des détails sur l'attaque ? Basée sur PPS ?
>
> Michel.

Est-ce que quelques gars avec de gros tuyau ne pourraient simplement
pas s'adresser à des résolveurs malencontreusement ouverts placés un
peu partout autour du globe et leur demandant des TLD inexistants,
obligeant les résolveurs à interroger les serveurs racine ?

Léo


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Stockage des données en cas de sinistre important

[Léo]

Le 7 octobre 2015 19:05, Denis Fondras <xx...@ledeuns.net> a écrit :
>> Si la sauvegarde n'a pas une durée de vie suffisamment longue pour
>> qu'on puisse craindre une évolution soudaine de la cryptanalyse qui
>> mettrait en danger les données confiées au fournisseur, le cloud est
>>
>
> C'est quoi la durée de vie d'une sauvegarde ?
>

Réponse de normand : ça dépend… du plan de sauvegarde. Si le plan
définit une sauvegarde complète chaque semaine, gardée quatre
semaines, puis une par mois sélectionnée pour être conservée six mois…

Si je comprends bien la question qui a initié le fil, on est plus dans
de la sauvegarde pour reconstruire un service/une infra en cas de
crash dû à un pépin environnemental que dans de l'archivage à long
terme.

Léo


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Stockage des données en cas de sinistre important

[Léo]

Le 7 octobre 2015 14:22, Vincent Duvernet (Nolmë Informatique)
<vincent.duver...@nolme.com> a écrit :
[...]
> (et non, les clouds public façon Dropbox ne sont pas toujours des
> alternatives soit à cause de la confidentialité, soit du prix pour le
> stockage nécessaire, soit pour Monsieur NSA…)
>
> (et non, je ne pense pas être trop parano ;p)
>
>
>
> Vincent
>

Bonjour la liste,

Je pense qu'en matière de sauvegarde, les clouds de stockage publics
ne sont pas une solution à écarter, si on fait bien les choses, à
savoir un bon chiffrement chez soi avant envoi. Il y a tout de même un
certain nombre d'avantages : coûts de pur stockage généralement peu
élevés (hubic : 50 EUR/an pour 10 To), la maintenance du support de
stockage et de son évolution technologique est faite par le
fournisseur, etc.

Si la sauvegarde n'a pas une durée de vie suffisamment longue pour
qu'on puisse craindre une évolution soudaine de la cryptanalyse qui
mettrait en danger les données confiées au fournisseur, le cloud est
une solution plutôt intéressante. Les seuls véritables points
d'attention sont la nécessité de disposer d'une connexion à internet
pour récupérer la sauvegarde, et la sauvegarde des clés de chiffrement
chez vous.

Une solution tout-en-un : http://www.tarsnap.com/ (avec stockage
Amazon). Mais je ne suis pas certain que cette solution ait été
auditée, donc vous voudrez peut-être le faire vous-même avec vos
outils.

Léo


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] Re: [MISC] Décret concernant le blocage des sites web

[Léo]

Bonsoir à tous,

Question du vendredi : le service de communication au public en ligne
n'étant pas nécessairement un site web (mais par exemple une
mailing-list ou encore un salon de discussion IRC), comment appliquer
l'article 3 du décret qui semble imposer que les utilisateurs bloqués
soient redirigés vers une page d'information ?


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Etude WAF hébergeur

[Léo]

Bonjour,

Il faut voir ici le WAF comme un serveur frontal à une application, il
ne s'agit pas d'inspection du trafic de navigation des utilisateurs
d'une entreprise (ça pourrait, mais il y a d'autres solutions dédiées
à cet usage). En fait, un WAF s'appelait simplement reverse-proxy
(filtrant), avant que le marketing passe par là (bon, en théorie, ça
devait effectivement fonctionner à l'image d'un firewall L4, mais en
pratique, je n'ai jamais vu que le mode de fonctionnement en RP).

Donc oui, le WAF se place en rupture de session TLS. C'est son
certificat (au nom de l'application protégée) qui est présenté au
client final (s'il n'y a pas d'autre élément interceptant le trafic
sur la route).

Le 26 janvier 2015 10:03, Nathan Anthonypillai
nathan.anthonypil...@gmail.com a écrit :
 Salut,

 Déchiffrer du TLS (SSL, c'est tabou, on en viendra tous à bout), c'est
 toujours une entreprise risquée. Il n'y a (à ma connaissance) pas d'option
 éthiquement acceptable dans ce domaine, à moins d'avoir le consentement
 informé de toutes les parties concernées.

Attention, l'application web dispose toujours des informations en
clair, simplement la session TLS s'arrête sur un nouveau composant de
l'infra d'hébergement. On peut remettre une couche TLS entre le WAF/RP
et le serveur applicatif final, ceci dit.


 Donc soit le WAF a la clé privée du serveur et peut le
 déchiffrer/rechiffrer à la volée,


 Ce n'est pertinent que dans les cas où la communication est chiffrée avec
 la clé publique du serveur derrière le WAF.
 Tu compromets donc le sécurité des communications de TOUTES les machines
 contactant le serveur de façon chiffrée.
 Dans ce cas autant se faire directement passer pour le serveur destination
 interne dès le début (ça sera plus facile au niveau de la gestion des clés).


 ou le WAF possède un serveur SSL (celui
 que le client voit) il décrypte les informations et les renvoient au
 travers d'une connexion sécurisée ou non.


 Là, le WAF se fait passer (MITM) pour le serveur destination externe (e.g.
 mabanqueenligne.com) en présentant une *fausse* clé publique.
 *Attention* : si l'entité en charge du certificat X.509 du serveur
 destination externe emploie un mécanisme d'audit (i.e. Google + Chrome)
 gare aux répercussions, car il va vite se rendre compte qu'une entité non
 autorisée se fait passer pour lui.

En général, on prend le second choix. Le premier est utilisé quand le
WAF reçoit une copie des flux (placé en observation, pas en
interception), ce qui peut être utile notamment pour le calibrage des
règles de détection au plus juste d'une application.



 Sachant que si on opte pour la première solution cela voudrait dire que
 le WAF possède toutes les clées SSL des clients derrières, personnellement
 je suis pas bien fan de l'idée ( votre opinion? )


C'est bien comme ça que ça marche, donc oui, le WAF devenant la tête
de pont de l'application, c'est bien lui qui présente les certificats.


 Si les utilisateurs finaux sont d'accords, ça peut passer, mais il me
 semble qu'il y a tout de même certaines communications qu'on ne doit pas
 déchiffrer (à vérifier), à moins d'être habilité de ce pouvoir par le
 législateur (no troll intended).

 Cordialement,
 Nathan ANTHONYPILLAI


Sur les différents produits que j'ai pu apercevoir de près ou de loin,
je pense à :
— apache en RP avec mod_security,
— DenyAll/rWeb
— nginx en RP avec le module Naxsi (https://github.com/nbs-system/naxsi)

Ma préférence va vers le dernier pour sa facilité de configuration (un
système de scoring à la manière des antispams).

Léo


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [BIZ] Société pour tests d'intrusion sur accès Internet

[Léo]

Il y a Lexsi, aussi.

LH.

Le 27 octobre 2014 21:07, Hugues Craipeau h.craip...@laposte.net a écrit :
 Pour ma part :
 Oppida
 NES
 Orange Consulting
 --
 Hugues

 Le 27/10/2014 18:01, Denis Alligand a écrit :

 Le 27 octobre 2014 17:28, Julien Schafer j.scha...@actilogie.com a écrit
 :

 Bonjour la liste

 Un de nos clients recherche une entreprise spécialisée dans les tests de
 ce type.


 Moi j ai déjà fait appel à ces gens la:

 Herve Shauer Consultant
 certilience
 intrinsec


 Denis

 ---
 Liste de diffusion du FRnOG
 http://www.frnog.org/



 ---
 Liste de diffusion du FRnOG
 http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] Le troll du vendredi par Michel

[Léo]

Il me semble que le fournisseur d'accès n'est pas tenu de vérifier
l'identité... n'est-ce pas ce que proposait no-log avec ses accès rtc
? (bon, les infos datent un peu)

2011/6/18 Rémi Bouhl remibo...@gmail.com:
 Tiens, je viens d'en trouver un pas mal: une page d' authentification qui
 demande un nom et un prénom.

 Apparemment, geek 42 est un état civil valide :)

 Rémi.
 ---
 Liste de diffusion du FRnOG
 http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] Re: HADOPI : voici la surveillance de l'e-mail

[Léo]

Pourquoi acheter des machines aussi chères pour faire ça ? Un eeepc
701, moins de 200€ maintenant, et BT3 tourne dessus comme un charme ;)

Le 29 avril 2009 16:38, arkiel ark...@free.fr a écrit :
 elle refuse toujours de booter sur mon macbook alu :'(
 d'ailleurs si quelqu'un a trouvé un lien qui permet de la faire tourner
 dessus, depuis des mois je cherche sans succès :/

 Charles a écrit :

 Je viens justement d'en acheter une nouvelle pour coller BT3 dessus...
 simplement pour m'assurer que mes voisins ne se connectent pas sur mon point
 d'accès wi-fi... et à l'occasion, tester le leur, par politesse, hein !

 ---
 Liste de diffusion du FRnOG
 http://www.frnog.org/

 ---
 Liste de diffusion du FRnOG
 http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] TaBox

[Léo]

Avec des amis de DUT info, on s'était penchés sur le sujet... on avait
finalement pensé à proposer des EEEBox, ça consomme 20W maxi, et il
existe une version linux avec de meilleures caractéristiques que la
version windows. Ensuite, on installe dessus une ditrib qui va bien,
on configure, et on clone. Pour la distro, on avait pensé à CentOS.
Mettre apache, postfix, dovecot, etc n'est pas bien compliqué.

Puis finalement, ça ne s'est pas fait. On est quand même 4 à
s'auto-héberger derrière nos lignes adsl.

L'écueil majeur reste la configuration de la machinbox qu'il y a en
amont pour qu'elle donne un ip fixe au serveur, et pour rediriger les
ports dessus. Les gens savent pas faire ça.

Léopold
---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] Filtrage coeur de réseau : l'Australie en phase de test

[Léo]

Bonjour Christophe,

J'ai assisté mercredi dernier au tutorial DNAC à Paris, présenté par
Guy Pujolle (fort intéresant, soit dit en passant). Il a consacré une
partie de son exposé au filtrage, et a annoncé une chose terrible :
les ISP, d'ici 2-3 ans, vont intégrer les dispositifs de filtrage
applicatif directement dans leur machinbox. Si ça ne s'est pas fait
jusqu'ici, c'est parce que le prix des sondes (qui repèrent le trafic)
était encore exhorbitant ; ces sondes fonctionnant à la manière des
antivirus, c'est-à-dire avec des signatures de flux par application.

L'intérêt ? Pouvoir proposer de la qualité de service aux petits
oignons à l'abonné, moyennant un supplément.
Bien entendu, les ISP sont obéïssants, ils vont aussi filtrer ce que
le gouvernement demande de filtrer. Puis ce qui l'arrange aussi.
L'abonné ne maîtrise en rien le filtre contenu dans la box qui est un
point de passage obligatoire.

Second intérêt pour les opérateurs, en mettant le filtrage à la
périphérie de leur réseau, ils n'ont donc plus à le mettre au centre,
là où l'on sait qu'il sera inefficace, et les coûts seront supportés
(évidemment) par la location de la box (généralement intégrée et non
dissociable de l'abonnement).

Il semble toutefois que Free soit le seul ISP à vouloir garder un
réseau neutre, sans filtrage. Mais bon, avec la réglementation qui
s'annonce, on imagine qu'il n'aura pas le choix.

J'espère que ça t'aidera, même si ça n'a rien à voir avec l'australie ;)

Léopold

Re: [FRnOG] Question sur le poppage fibre FT/Free/Noos

[Léo Goehrs]

Bonjour, 

Je confirme que des solution existent a Levallois, nous sommes en train de 
faire un construction de fibres grace a Completel, eux meme en partenariat avec 
Numericable. 
Mais il est vrai, que les abonnements a pas cher en fibre sont bien souvent 
ciblé vers les particuliers. Une connection FE a Levallois va couter dans les 
2k€ / mois (hors transit, juste de transport), mais c'est en effet du garanti, 
transparent aux vlans, ... Bref, du professionel quoi. 

Cordialement 

Léo Goehrs 



- Original Message - 
From: Benjamin Pradayrol [EMAIL PROTECTED] 
To: frnog@frnog.org 
Sent: Friday, October 31, 2008 6:29:51 AM GMT +00:00 Casablanca / Monrovia 
Subject: Re: [FRnOG] Question sur le poppage fibre FT/Free/Noos 


Bonjour Julien, 

A priori, il y a d'autres solutions que celle que vous évoquez, mais ce sont 
des solutions professionnelles (le budget annuel n'est pas le même, mais le 
service est garanti). 
Car à Levallois, bien des entreprises ont des accès fibrés. 

Reste à savoir quel est votre budget. 

Cdt, 

BP 

Le 30/10/08, Julien BREVIERE  [EMAIL PROTECTED]  a écrit : 


Bonjour, 

s'il y a des gens de FT, Free ou Noos sur cette liste, 
pourraient-ils m'indiquer comment faire pour faire installer le boitier 
immeuble 
de la fibre dans un immeuble de bureau que nous louons entièrement... 
afin que nous ou des sociétés qui dependent de nous puisse passez commande de 
raccordements abonnés. 

Cela, du moins par le circuit classique, semble assez bloqué ... on me réponds 
(en tout cas chez FT) : votre immeuble n'est pas ciblé, impossible de faire 
en sorte 
qu'il le soit et/ou d'avoir une idée sur la date ou il le sera ... Free semble 
payant pour l'immeuble et noos semble tout simplement ne pas couvrir la zone 
(Levallois-Perret). 

Bref .. nous comptions pouvoir, pour plusieurs sociétés filiales/partenaires 
de l'immeuble (7 niveaux sur 3700 m²) opter pour des offres fibres chez l'un ou 
l'autre de ces 3 opérateurs en tant que liaisons principales et/ou de secours 
et cela semble tout bonnement impossible et ce pour une durée encore 
indeterminée. 

Evidemment l'idéal pour moi c'est que ce soit possible d'ici à la fin de 
l'année 
mais on peut toujours rêver... 

Merci de me dire s'il est indéniable que ma seule alternative est l'adsl 
classique 
(pour une solution de secours à moindre coût, meme si moindre support) ou du un 
peu 
plus pro du type SDSL ou autre. 

Je comprends que les immeubles avec des logements (foyers) soient privilégiés 
de 
par leur nombre potentiel d'abonnés plus important, mais n'y a-t-il pas, même 
moyennant 
finance de forcer un peu les choses ? 

cordialement, 


=== 
Julien BREVIERE 
Net'Veille/L'Ecripapiers System Administrator 
mailto: [EMAIL PROTECTED] 

Tél.: +33 1 41 05 43 03 
Fax.: +33 1 46 17 09 28 
=== 
PGP key :  http://mercury.ecp-net.com/pubkey.julien_breviere_root.asc  


-- 
Ce message a été vérifié par MailScanner 
pour des VIRUS ou des SPAM et rien de 
suspect n'a été trouvé. 
-- 
This message was verified by MailScanner 
against VIRUS or SPAM presence and nothing 
suspect was found. 
-- 

--- 
Liste de diffusion du FRnOG 
http://www.frnog.org/ 

Re: [FRnOG] Info sur carte Foundry J-BxGMR4

[Léo Goehrs]

Je dirais bien:

RTFM

mais bon, pour faire simple, oui, en IPV4, et aussi du BGP4+ en v6

Bon, seule limitation, le manager fait pas de Café.

Léo

- Mail Original -
De: Philippe DUCHEIN [EMAIL PROTECTED]
À: frnog frnog@frnog.org
Envoyé: Mercredi 13 Août 2008 14:14:23 GMT +01:00 Amsterdam / Berlin / Berne / 
Rome / Stockholm / Vienne
Objet: [FRnOG] Info sur carte Foundry J-BxGMR4

Bonjour,
je recherche une petit info bien simple sur une carte de management sur 
BigIron B4000
il s'agit de la J-BxGMR4. Je voulais savoir si on peut faire nativement 
avec du BGP ?

Merci
---
Liste de diffusion du FRnOG
http://www.frnog.org/

RE: [FRnOG] Question batis rack.

[Léo Goehrs]

Les plateaux standards peuvent fonctionner,  il faut juste des ecrous cage 
adaptés.

Léo

-Message d'origine-
De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de Philippe 
Mackowiak
Envoyé : jeudi 27 septembre 2007 10:18
À : frnog@FRnOG.org
Objet : [FRnOG] Question batis rack.


Bonjour,

Une fois n'est pas coutume, pas de pb de BGP, de saturation de
liens, mais une bonne veille question bien terre à terre:

Quelqu'un connaît-il un fournisseur de plateaux ou profilés
pour des batis-rack 19.
Les montants avant/arrière sont à trous pour vis, donc pas 
possible d'utiliser des rails à crochets ou des écrous-cage.

Merci pour les infos.

PM.
---
Liste de diffusion du FRnOG
http://www.frnog.org/

---
Liste de diffusion du FRnOG
http://www.frnog.org/

RE: [FRnOG] Question Rack 19 optique

[Léo Goehrs]

Tu aurais pu me demander, je sais ou en trouver, et j'en ai dans toutes mes 
baies :)

Tu eux aller voir impec cables  à  Sannois

Léo

-Message d'origine-
De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de Greg VILLAIN
Envoyé : mercredi 26 septembre 2007 13:43
À : Jerome Fleury
Cc : frnog@frnog.org
Objet : Re: [FRnOG] Question Rack 19 optique


On Sep 26, 2007, at 1:35 PM, Jerome Fleury wrote:

 Greg VILLAIN wrote:
 Bonjour à tous,

 Une fois n'est pas coûtume, Google n'est pas mon ami.
 Pas moyen de trouver de vendeur pour un device très simple, ni  
 même de trouver la dénomination commune de ce bidule...
 Il s'agit d'un rack 19 1U qui est fait pour accueillir des corps  
 de traversées, et qui donc, une fois les corps de traversée  
 introduit, fait office de panneau de distribution optique (LC dans  
 mon cas).
 Voilà, je sais pas si c'est bien clair, mais en gros je voudrais  
 bien connaître:
 - le nom standard de ce truc là
 - où je peux en acheter

 C'est ca que tu cherches ?

 http://www.blackbox.co.uk/solutions/display.asp? 
 cs=dvhid=1doc=jpe004ftx=Infrastructure%20Cablingsx=Fibre%20Optic 
 %20Panels%20and%20Adaptors

Tout pile poile exactement ! Par contre, je pige toujours pas comment  
ça m'a pas traversé l'esprit d'aller voir chez blackbox...
Merci à tous !

Greg VILLAIN


---
Liste de diffusion du FRnOG
http://www.frnog.org/

---
Liste de diffusion du FRnOG
http://www.frnog.org/

RE: [FRnOG] question d'architecture

[Léo Goehrs]

Sauf que ces sujets ont déjà été abordés à de maintes reprises sur cette liste. 
Je pense qu'une lecture des archives en premier pourrais se révéler bénéfique.

Cordialement

Léo Goehrs
Alionis

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of gu!llaume
Sent: vendredi 6 juillet 2007 13:57
To: frnog@frnog.org
Subject: Re: [FRnOG] question d'architecture

Marc Oliera a écrit :

 Salut Marc,

 je ne pense pas que tu sois hors charte, bien au contraire, mais
 peut-être pourrais-tu nous préciser l'origine de tes questions
 (professionnelle ou recherche) et le but (rapport, construction d'un
 réseau opérateur, etc.)

 A+


 Le but est plus etude de cas donc rapport.
 Je me pose simplement la question sur les problématiques que peut
 rencontrer une équipe technique lorsqu'il monte un réseau d'oprateur
 IP de moyen envergure et comment elles sont résolu...

 Je suis encore étudiant et passionné, comme tous les noobs :) je suis
 friant de savoir...

J'avoue etre aussi interesse. Je suis admin systemes/reseaux dans une
SSLL, et la partie WAN m'est encore plutot floue.
Notamment les aspects de routage dynamique, de redondance, ...

Je vais suivre le thread :-)
---
Liste de diffusion du FRnOG
http://www.frnog.org/

---
Liste de diffusion du FRnOG
http://www.frnog.org/

RE: [FRnOG] Wanadoo / Orange SMTP

[Léo Goehrs]

Le problème ne viens pas de la décision, mais de l'absence de communication et 
egallement de l'absence de solution pour bypasser ce verouillage.

Léo Goehrs

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Antoine Musso
Sent: mercredi 27 juin 2007 11:43
To: frnog@frnog.org
Subject: Re: [FRnOG] Wanadoo / Orange SMTP

Léo Goehrs a écrit :
 Wanadoo / Orange pour notre plus grand bonheur viens de suivre Free 
 sur le blocage du SMTP sortant mais en moins bien puisque le blocage 
 n'est pas desactivable. Pour contourner le problème, selon Wanadoo, il 
 faut passer en IP Fixe.

Bonjour,

Une bonne nouvelle pour la lutte contre les PC zombies. Peut être aurais
  je un peu moins de virus et autres publicités pour la petite pillule bleu 
dans ma boîte perso.

cheers,

--
Antoine MUSSO
DISIT/PROD/QFO/OUT
mailto:[EMAIL PROTECTED]
tél. 02 40 12 73 62
---
Liste de diffusion du FRnOG
http://www.frnog.org/

RE: [FRnOG] Wanadoo / Orange SMTP

[Léo Goehrs]

Tu m'expliques la solution sous mac avec Eudora ?

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Benjamin 
Malynovytch
Sent: mercredi 27 juin 2007 16:23
To: frnog@frnog.org
Subject: RE: [FRnOG] Wanadoo / Orange SMTP

 l'absence de solution pour bypasser ce verouillage

Pourquoi ne mettez-vous pas en place une redirection de port sur vos
serveurs SMTP ?
Rien, ne vous empêche de laisser le 25 ouvert normalement et de rediriger le
8025 par exemple vers le 25 local. Du coup, vous n'êtes plus affectés par
les restrictions des ISP.

J'ai mis en place cette solution depuis que Free a mis en place son blocage.
Les clients ont juste à changer le port du SMTP dans la config de leur
client de messagerie (options avancées). Très peu s'en sont plaint. Voir
même, la plupart étaient heureux qu'il existe de petits prestataires qui
bossent avec leur tête et règlent les problème que les gros qui ne
raisonnent avec leur porte-monaie ont générés sans se préoccuper de ce qu'il
pourrait advenir.

Cordialement,

Benjamin.


---
Liste de diffusion du FRnOG
http://www.frnog.org/

---
Liste de diffusion du FRnOG
http://www.frnog.org/

RE: [FRnOG] Wanadoo / Orange SMTP

[Léo Goehrs]

Est-ce qu'un fournisseur d'accès a le droit de filtrer les ports de son client 
dans les CGV ? Sinon, on pourrait aller plus loin et carrément interdire 
certains site, et bientôt mettre un proxy global comme au viet-nam.

Imaginez que Wanadoo interdise l'accès aux pages persos de free. Ce n'est que 
le premier pas mais un filtrage global me semble une bien bien mauvaise idée 
qui va a l'encontre du principe de l'Internet.

Si encore il y avait un contrôle individuel, on pourrait considérer cela comme 
un progrès pour protéger l'utilisateur. La, on force les utilisateurs et c'est, 
il me semble une atteinte a la liberté et donc une régression.

Bref, je suis contre et j'espère que ceux qui souhaiterons aller dans ce sens 
le feront en réfléchissant un peu plus.

Cordialement

Léo Goehrs

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Vincent Gillet - 
Opentransit
Sent: mercredi 27 juin 2007 18:40
To: frnog@frnog.org
Subject: Re: [FRnOG] Wanadoo / Orange SMTP

[EMAIL PROTECTED] disait :

 Le 27 juin 07 à 16:50, Will van Gulik a écrit :
 
 Et vu la clientele ciblé (le end-user et son pc zombie), ils ne  
 proposent pas de solution pour detourner le problème.

Etant donné que personne de Orange Mail ne répond, je vais tacher
de donner les infos que j'ai (en espérant ne pas me faire taper sur les
doigs, mais je considere qu'il n'y a rien de secret là dedans ...).

Cela évite aux gens compétents en SMTP de cherche l'erreur ou
devancer le probleme.

 Chez FT par contre, je ne suis pas certain qu'il y ait ce genre de  
 gestion de conf individualisée pour chaque Livebox. Ca ne  
 m'étonnerait pas tant que ça que le filtrage se fasse plus loin sur  
 les équipements réseaux.
 Ce qui est évidemment beaucoup moins élégant, et ingérable si chacun  
 commence à demander une exception. :)---

Le filtrage dans la livebox a été écarté car tout le monde n'est pas en
livebox.

Ce filtrage est en cours de mise en place sur les BAS. Il est déployé
par région. Cela commence cette semaine et se terminera en aout.
Un pilote a été nemé quelques mois sur un BAS. Il est concluant.

Les gens du SAV ont été informé il me semble.

Pas possible de mettre en place des exceptions car le filtrage est
global au BAS, non lié à la session de l'utilisateur.

1/ Ne rien me reprocher sur le mechanisme ni la méthode de mise en
   place. Je n'en suis pas responsable
2/ Je n'ai pas plus d'info que cela.
3/ A titre perso, je trouve que cette mise en place est une bonne chose
   pour la lutte anti-spam.

Vincent.
---
Liste de diffusion du FRnOG
http://www.frnog.org/

---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] RE: [FRnOG] Re: [FRnOG] FW: [FRnOG] Co ntent Delivery Network (CDN) à la francaise

[Léo Goehrs]

Quoi qu'il arrive, ce sera toujours l'utilisateur final qui supportera les 
couts. La répartition de ce que l'Utilisateur va payer est en train de changer. 
Auparavant, les FAI faisaient payer assez cher pour pouvoir maintenir leur 
infra. Ils se sont livrés une guerre sans précédent pour faire baisser les prix 
sans pour autant baisser les couts (augmentation de la BP, ajout de la 
téléphonie, de la télévision).

Les fournisseurs de contenu pouvaient alors distribuer du contenu et se 
rémunérer maigrement sur la pub. Aujourd'hui, devant le manque de moyen 
engendré par la guerre des prix, les operateurs veulent gagner de l'argent aux 
deux bouts. 

Il ne faut pas oublier que l'Internet est  un grand réseau et que les 
utilisateurs savent ce qu'ils veulent et ils n'accepteront pas de ce voir 
refuser l'accès a un contenu. De plus, l'Internet permet aussi a des 
entreprises de ce mettre en avant et de faire de l'autopromo.

Les CDN sont une bonne idée mais il n'est pas forcement utile de les mettre au 
sein des ISP. Le CDN qui a ses serveurs à proximité (qq milliers de km max) 
permet déjà d'améliorer sensiblement la qualité du service. Les points 
d'échanges régionaux sont la pour ca, non ?

Cordialement

Léo Goehrs
Alionis
---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] RE: [FRnOG] FW: [FRnOG] Co ntent Delivery Ne twork (CDN) à la francaise

[Léo Goehrs]

 L'ennui, c'est que le FAI voit les couts de ses 
 fibres, de ses routeurs, de ses dslam, et dit ah 
 ben c'est moi qui supporte 80% du trajet, pas 
 normal que l'autre en face paie pas

N'oublions pas que le transport (pour le créateur du contenu), c'a n'a un 
intérêt que tres limité et que bien souvent, le prix de création du contenu 
coute très cher aussi. 
Il faudrait donc évaluer toute la chaine, à savoir:

+ Couts de Creation et de mise en ligne
+ Maintiens du service, modération, creation de nouveaux contenus
+ Couts d'hebergement de la solution
+ Couts d'acheminements

L'hébergeur dans cette topologie, à une place vraiment mineure. Il n'a que les 
moyens que lui donne son client. Si Les hébergeurs devaient payer plus cher, 
alors ils répercuteraient inévitablement les couts sur leurs clients et ces 
derniers rendraient leur contenu payant à leur tour.

L'intérêt a la base de l'Internet était, a mon sens, de payer assez cher sa 
connexion ADSL mais que cette dernière permette d'accéder à *tous* les contenus 
disponibles sur la toile sans restrictions et sans couts additionnels.

Cordialement

Léo Goehrs
Alionis


---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] RE: [FRnOG] Re: [FRnOG] RE: [FRn OG] FW: [FRnOG] Co ntent Deliver y Network (CDN) à la francaise

[Léo Goehrs]

Raphael Maunier Wrote
Ben oui, on appelle ca, revoir son business model :)
Le tout gratuit, ca a aussi un cout.

Le système consistant a dire: 
+ Le Client paye un abonnement au FAI pour que ce dernier assure le transport
+ Le fournisseur de contenu affiche de la pub et fait payer le clients pour 
certains services a valeurs ajoutés

Me semble cohérent. Il reviens donc au FAI d'adapter ses couts et surtout ses 
tarifs pour gagner de l'argent sur le transport. Une tarification différente en 
fonction de la localisation géographique ne serait pas choquante.

On est en train de rendre responsable les Fournisseurs de contenu de 
l'explosion des debits. Ce ne sont pas eux qui ont proposé 20Mb pour 29,90 € !
Les fournisseurs de contenu et les internautes veulent juste pouvoir utiliser 
la bande passante mise a disposition par les FAI.

A Titre d'info, aux USA, 
Comcast, 6 Mbs, 19,99$
Comcast 8Mb: 57,95$

Bellsouth: 256kbs, 24,95$
Bellsouth: 1.5 Mbs, 32,95$
Bellsouth: 3Mbs, 37$
Bellsouth: 6Mbs, 47$

Les FAI proposent des débits qu'ils ne peuvent tenir, ce n'est pas aux autres 
d'en payer le prix.

Cordialement

Léo Goehrs
Alionis
   



.+-yם*'v�Q�ᡶ��0~�肊