Re: [FRnOG] [TECH] Wifi sur campus 2000m²

[Pierre-Henry Muller via frnog]

Email Signature
Le 19/09/2024 à 16:02, Stéphane Rivière a écrit :
Étant un pro de la chose, je plussoie (des quatre mains, en bon 
primate) à tous les conseils de Pierre-Henry.

:D


Ce genre de taff est strictement méthodologique.

Comme souligné par Pierre-Henry, la mesure du bruit existant + une 
archi qui va limiter le bruit et les interférences, c'est juste la base.
Dans cet esprit, la ségrégation 2.4/5.8 qu'il recommande est 
fondamentale. Doit-on rappeler qu'on a 3 canaux non entrelacés en 2.4 ?


Sinon...
Racker du ruckus est un truc de richou ;>
On peut faire très bien pour beaucoup moins cher.

Et (par exemple, y'en a d'autres) Ubuquiti rules...
Des Ubiquiti bien configurés font très bien le job. J'ai néanmoins été 
un peu déçu des BaseStation XG car la différence de puissance entre les 
bornes et les terminaux était trop importante. Et vu que c'est du wifi 5 
il ne faut surtout pas déployer cela dans un environnement wifi 6 ou 7, 
les terminaux préfèrent garder coûte que coûte les bornes plus 
lointaines sur des technologies plus récentes.

Et c'est hyper fiable en plus, même en milieu très marin...


J'ai eu une seule fois un souci d'une mauvaise série où le POE était 
très récalcitrant, il fallait des câbles très épais en AWG. UI a procédé 
à des échanges 3 mois après l'achat le temps de valider le bug.


Sinon en dehors de ces accros, on a toujours été satisfait des 
déploiements, les clients apprécient.



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

Re: [FRnOG] [TECH] Wifi sur campus 2000m²

[Pierre-Henry Muller via frnog]

Mes réponses dans le texte, merci Stéphane de soutenir que le matériel 
ne fait pas tout :)


Email Signature
Le 19/09/2024 à 16:47, Guillaume Khayat a écrit :

Merci de nous partager ces bonnes pratiques.

J’ai quelques questions :


- prévoir son plan de canaux en 5 et 6 Ghz

J’ai lu souvent qu’il fallait faire confiance à l’autoselect des AP, ne 
serait-ce que parce que les AP peuvent ainsi réagir à une évolution du bruit de 
fond du voisinage. Qu’en pensez-vous ?


L'optimisation auto des AP c'est bien quand le voisinage n'est pas trop 
dense et qu'on a peu d'AP. Il vaut mieux faire des mesures du bruit à 
chaque point prévu pour mettre une borne et prendre la décision de la 
configuration à choisir.


Par la suite si les voisins sont en auto, peut-être refaire une passe de 
mesure pour se caler au mieux, voir négocier avec les voisins :P





- mettre au minimum le signal au delà duquel l'AP va demander au client de 
trouver une meilleure borne

On parle de 802.11v ? Y a-t-il vraiment des clients qui en tiennent compte ? 
J’ai lu/entendu que c’était largement ignoré. Si ça ne l’est pas, ne perd pas 
t-on en réactivité sur le roaming ? Est-ce que c’est une décision à prendre en 
fonction du degré de mobilité des clients ?


Là c'est plutôt l'AP va refuser de parler avec les périphériques qui ont 
un signal trop faible. Il me semble que le 802.11v n'est pas déclenché 
obligatoirement, ou alors peut-être que la trame partira et si le 
périphérique l'ignore, l'AP refusera de répondre si le signal n'est pas bon.






On 19 Sep 2024, at 14:14, Pierre-Henry Muller via frnog  wrote:

Bonjour,

Quand vous avez une grande quantité d'AP, peu importe la gamme, il faut 
impérativement :

- faire une étude du bruit de fond des voisins

- prévoir son plan de canaux en 5 et 6 Ghz

- réduire la puissance des AP pour mieux répartir les canaux et éviter qu'un 
signal d'une borne lointaine bave sur la borne la plus proche

- mettre au minimum le signal au delà duquel l'AP va demander au client de 
trouver une meilleure borne

- couper le 2,4Ghz sur tous les AP pour l'activer que de façon précise à 
certain endroit (ça couvrira la zone de plusieurs AP en 5Ghz)

Dans les déploiements déjà réalisés, on peut avoir un AP activé en 2,4Ghz pour 
5 à 8 AP activés 5Ghz. Le but du 2,4Ghz est de porter loin sans être perturbé.

Déjà avec ces configurations vous pourrez voir une amélioration.

Bon courage

Email Signature


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

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

Re: [FRnOG] [TECH] Wifi sur campus 2000m²

[Pierre-Henry Muller via frnog]

Bonjour,

Quand vous avez une grande quantité d'AP, peu importe la gamme, il faut 
impérativement :


- faire une étude du bruit de fond des voisins

- prévoir son plan de canaux en 5 et 6 Ghz

- réduire la puissance des AP pour mieux répartir les canaux et éviter 
qu'un signal d'une borne lointaine bave sur la borne la plus proche


- mettre au minimum le signal au delà duquel l'AP va demander au client 
de trouver une meilleure borne


- couper le 2,4Ghz sur tous les AP pour l'activer que de façon précise à 
certain endroit (ça couvrira la zone de plusieurs AP en 5Ghz)


Dans les déploiements déjà réalisés, on peut avoir un AP activé en 
2,4Ghz pour 5 à 8 AP activés 5Ghz. Le but du 2,4Ghz est de porter loin 
sans être perturbé.


Déjà avec ces configurations vous pourrez voir une amélioration.

Bon courage

Email Signature

Le 19/09/2024 à 10:09, David MAGNIEZ a écrit :

Hello à tous,


On a pas mal de soucis de wifi sur notre campus avec nos bornes Aruba 205/305, 
et ce depuis le début.
Perte de wifi sur certains postes / débit. Pourtant Aruba fait quand même 
référence sur le marché.
J'ai tenté un peu de tout, sans arriver à un truc satisfaisant.

Config : campus isolé de 1900m², paroi placo/beton, plancher beton (1 étage), 
bornes disposées en faux plafond de manière régulière (je ne sais pas si une 
étude avait été faite)

Avez-vous des conseils de marque/modèle, manière de faire, pour renouveler tout 
ça proprement ?
Est-ce que des produits comme Ubiquiti sont suffisamment enterprise-grade pour 
installer ça soit même sans emmerdes ? Peut-être en faisant une étude avant ?

Si non, connaissez vous des spécialistes sur Lille ?

Merci !

David

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

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

Re: [FRnOG] [MISC] Le résolveur DNS public OpenDNS plus accessible depuis la France

[Pierre-Henry Muller via frnog]

Email Signature
Le 28/06/2024 à 19:19, Alarig Le Lay via frnog a écrit :

On Fri 28 Jun 2024 18:16:10 GMT, Stephane Bortzmeyer wrote:

Décision de justice liée à l'Euro 2024, il semble :

https://www.bortzmeyer.org/opendns-quitte-france.html

C’est pas grave, on peut passer sur du DNS avec de l’IA dedans, tout ira
mieux :https://0ms.dev/

Et c’est tellement bien l’IA que ça me dit que je suis à 2 ms du biniou
alors que je suis en 4G dans un TGV.


Du DNS à l'IA?

Je suis déjà trop vieux pour comprendre ou bien c'est du marketing à 
outrance qui ne veut rien dire?


Quand on demande une résolution DNS ce n'est pas pour avoir une 
approximation d'un machine learning non?




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

Re: [FRnOG] [TECH] Arista pour full-table ?

[Pierre-Henry Muller via frnog]

Email Signature
Le 06/06/2024 à 15:56, ic a écrit :

io,


On 6 Jun 2024, at 15:10, David Ponzone  wrote:

J’ai l’impression que c’est les LPM, auquel cas le 7280R est suffisant avec 1M 
IPv4 LPM unicast routes.

1M tu ne vas pas tenir longtemps sachant qu’on approche les 950k…

++ ic
Une vraie full table v4 / v6 c'est vu de notre côté 1 289 926 routes 
aujourd'hui, donc les 1M sont déjà passés.

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

Re: [FRnOG] [MISC] Fin de l’IPv4 en République tchèque

[Pierre-Henry Muller via frnog]

Ce que j'avais déjà exprimé auprès de l'ARCEP en 2020, c'est le risque 
avec la pénurie d'IPv4 que tout nouvel acteur entrant qui voudrait se 
faire une place en tant que service (Cloud, telecom, SaaS autonome, ...) 
qui serait sans doute coincé s'il ne veut pas mettre des millions dans 
le rachat d'IPv4.


Donc ceux qui en ont, n'auront rien à gagner ou à perdre de rester en v4 
ou d'activer v6 en complément et les nouveaux risquent d'être v6 only 
mais perdre une partie de leur audience si les FAI de leurs cibles ne 
sont pas v6 compatible ou que Mme Michu n'a pas cliqué sur l'option 
passé inaperçue.


On se rappelle tous de la position de Leboncoin à une conf FRNOG disant 
qu'il n'y avait aucun intérêt à part des coûts et des problèmes.


Email Signature
Le 26/01/2024 à 14:43, David Ponzone a écrit :

Je pense que la raison est claire:
-fin de la 2G/3G: intérêt financier
-fin cuivre: intérêt financier
-fin IPv4: rien à gagner, à part des emmerdes


Le 26 janv. 2024 à 14:37, Pierre-Henry Muller via frnog  a 
écrit :

Le dual stack ne me dérange pas du tout, on en fait sur tous nos clients depuis 
2010. Et je pense clairement que l'IPv4 sur les réseaux locaux va encore 
perdurer longtemps et finalement il est peut-être plus adapté que le v6 pour du 
local.

Le "malheureusement" est en direction de ceux : ARCOM, Etats, ayatollah qui 
prédisent la fin d'IPv4 ou qui ne veulent pas gérer de dual stack car ça implique double 
supervision. D'ailleurs on est en 2024 et on a toujours des liens ou services IPv6 qui 
tombent sans que personne ne s'en rendent compte.

Par contre pour la 2G/3G, cuivre là c'est pratiquement acté que ça va 
disparaître à l'inverse du POCSAG encore utilisé et pourtant plus vieux.

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

Re: [FRnOG] [MISC] Fin de l’IPv4 en République tchèque

[Pierre-Henry Muller via frnog]

Le dual stack ne me dérange pas du tout, on en fait sur tous nos clients 
depuis 2010. Et je pense clairement que l'IPv4 sur les réseaux locaux va 
encore perdurer longtemps et finalement il est peut-être plus adapté que 
le v6 pour du local.


Le "malheureusement" est en direction de ceux : ARCOM, Etats, ayatollah 
qui prédisent la fin d'IPv4 ou qui ne veulent pas gérer de dual stack 
car ça implique double supervision. D'ailleurs on est en 2024 et on a 
toujours des liens ou services IPv6 qui tombent sans que personne ne 
s'en rendent compte.


Par contre pour la 2G/3G, cuivre là c'est pratiquement acté que ça va 
disparaître à l'inverse du POCSAG encore utilisé et pourtant plus vieux.


Email Signature
Le 26/01/2024 à 13:27, l...@netc.fr a écrit :

bonjour,

j'ai beaucoup de mal à comprendre le "malheureusement"
les technologies arrivent pour améliorer quelque chose déjà en place, 
pas pour remplacer.

on dirait les accros à la data "4/5G" doivent remplacer la 2/3G
heureusement que non, il y a une certaine question de complémentarité, 
ces nouvelles technos arrivent pour accompagner, non remplacer.. 
imaginez la discrimination/exclusion technologique sinon..


c'est comme si on virait le TER pour conserver que le TGV, ou qu'on 
autorisait qu'un seul type de carburant en station essence. Ou encore 
la fin de la télé par l'antenne rateau..




From: Pierre-Henry Muller via frnog 
To: frnog@frnog.org
Subject: Re: [FRnOG] [MISC] Fin de l’IPv4 en République tchèque
Date: 26/01/2024 09:27:46 Europe/Paris

Bref malheureusement IPv4 est là pour durer c'est évident.

Email Signature
Le 26/01/2024 à 09:02, Stéphane Rivière a écrit :
>
>> Par contre ceux qui ont des clients qui échangent des données avec
>> l'administration tchèque peuivent se préparer (et prévenir les
>> clients qu'ils préviennent leurs devs).
>
> On verra alors si les FAI locaux auront fait ce qu'il faut pour que
> tous les michus de tchéquie soient ipv6 'aware'... En 8 ans, ça
> devrait pouvoir se faire.
>
---
Liste de diffusion du FRnOG
http://www.frnog.org/

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

Re: [FRnOG] [MISC] Fin de l’IPv4 en République tchèque

[Pierre-Henry Muller via frnog]

On est clairement plus sur une obligation d'avoir IPv6 d'activé donc 
avoir du dual stack pour tous les éléments étatiques que le retrait d'IPv4.


Cas très simple, si c'est que v6 only, un citoyen qui vit dans un autre 
pays pour différentes raisons (boulot, voyage long, études, retraite) et 
qui doit s'affranchir de déclarations auprès de son pays, s'il n'a pas 
d'IPv6 là où il se trouve il sera bloqué. Alors oui y a des vpn mais le 
citoyen non technique il n'aura d'autre choix que d'aller à son 
embassade pour tenter de trouver une autre solution.


Bref malheureusement IPv4 est là pour durer c'est évident.

Email Signature
Le 26/01/2024 à 09:02, Stéphane Rivière a écrit :


Par contre ceux qui ont des clients qui échangent des données avec 
l'administration tchèque peuivent se préparer (et prévenir les 
clients qu'ils préviennent leurs devs).


On verra alors si les FAI locaux auront fait ce qu'il faut pour que 
tous les michus de tchéquie soient ipv6 'aware'... En 8 ans, ça 
devrait pouvoir se faire.



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

Re: [FRnOG] [TECH] UniFi - pilotage bornes légères UAP-AC-LITE

[Pierre-Henry Muller via frnog]

Petit retour d'expérience, UI ne permet pas le niveau de détail que tu 
demandes.


Le réseau guest avec voucher ou avec portail, ne demande même pas les 
infos obligatoires que son nom / prénom / email, le portail ne peut être 
modifié sur ce point, seule les couleurs et les CGV peuvent être modifiées.


De plus même une dream machine qui fait office de firewall / routeur, 
lorsqu'on active le flux syslog vers un concentrateur, on ne reçoit pas 
le détail du traffic, assignation dhcp et autres infos intéressantes 
mais seulement les logs systèmes de la dream machine et des bornes ...


Bilan on a viré notre wifi guest

Email Signature
Le 22/01/2024 à 11:56, Jérôme Berthier via frnog a écrit :

Le 18/01/2024 à 23:01, David Ponzone a écrit :
Le 18 janv. 2024 à 22:52, Merwan Zenati  a 
écrit :


Hello

En effet les bornes sont managées avec un controller, pour du 
basique, si tu ne veux pas mettre de vrai firewall sur place, une 
cloud key fait amplement l’affaire (sinon tu peux héberger une vm 
Windows/linux avec un controller mais prix de l’instance + 
maintenance + gestion du fw si ip dynamique etc etc etc… prise de 
tête pour la taille)
Ce cloud key est manageable a distance (tu l’adopte dans 
console.ui.com si je dis pas de bêtise) donc c’est top.
Tu couple ça a un 8POE unifi (ou plus selon le besoin et le tour est 
joué)


Concernant ton wifi guest, unifi, c’est simple ! Tu setup ton lan 
guest sans « network », tu crée ton wifi dans « wifi » tu dis « 
c’est du guest » boom il isole lui même chaque périphérique connecté 
automatiquement…
Mais sauf erreur de ma part (j’ai éliminé tous les routeurs UI de la 
liste du possible il y a un moment), dans cette conf, tu n’as pas les 
logs des guests sur 12 mois.
C’est un produit US, donc ils connaissent pas trop nos petites 
contraintes UE (qui sont, il faut le dire, ubuesques).


Merci David pour cette remarque !

En relisant quelques docs et posts sur le forum UniFi, j'ai 
effectivement un gros doute aussi.


L'idée du déploiement est évidemment d'avoir la traçabilité entre le 
client (voucher hotspot) et son usage (terminal / trafic IP).


Il me faut donc la traçabilité :

- des connexions hotspot en pouvant faire le lien entre le 
client/voucher et son terminal (idéalement sur un an).


- du trafic en lien avec le terminal (idéalement le voucher donc le 
client)


Pour croiser tout ça, j'ai donc besoin des logs : sessions portail 
(client/voucher <-> MAC), MAC <-> DHCP, accounting IP (src / dst / 
ports...), translations NAT.


Je pensais que les gateways UniFi et la fonction Hotspot gérée dans 
Network Server permettaient d'avoir ça mais c'est franchement pas clair.


Je crois même comprendre le contraire en lisant le forum Community UniFi.


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

Re: [FRnOG] [TECH] Cable Ethernet avec connecteur RJ45 renforcé

[Pierre-Henry Muller via frnog]

Bonjour,

Je ne connais pas de prise qui puisse résister à des mouvements de 
meubles qui vont casser net les prises murales comme celle du câble. Y a 
bien des prises métals mais le connecteur ne supportera un mouvement 
latéral avec contrainte.


Une première approche serait peut-être de trouver des câbles coudés à 
90° et une prise murale en retrait dans une plinthe par exemple, mais je 
pense que des pincements de câbles vont survenir également entre le mur 
et les meubles.


Sinon déplacer les téléphones sur le bureau des chambres avec prise en 
hauteur, ça se fait beaucoup.



Email Signature
Le 05/09/2023 à 09:08, Olivier Varenne a écrit :

Bonjour

Un de mes client (un hotel) me remonte plusieurs cas de connecteur RJ45 arraché 
par mois.
Le personnel de ménage arrache le connecteur RJ du câble en lui-même en 
déplaçant les tables de chevet ou lit (ou sont posé les téléphones IP)
On parle bien de l'arrachage de câble avec connecteur moulé, pas de câble serti 
maison.

Quelqu'un à un fournisseur qui aurait des câbles dont le connecteur est 
particulièrement renforcé à me conseiller ?
J'ai trouvé des câbles dit « renforcés » mais j'ai un sérieux doute sur leur 
efficacité

Si ça n'existe pas, il me restera plus que la solution poste wifi... mais le 
client va faire la gueule de devoir tout rééquiper.

Cordialement,

[cid:image001.png@01D9DFD8.85C6F980]

Olivier Varenne
Président, R&D et développement
T +33 (0)4 27 04 40 00 | ipconnect.fr

Suivez-nous !
[picto-twitter][picto-youtube][picto-linkedin]
[cid:image005.jpg@01D9DFD8.85C6F980]


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

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

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

[Pierre-Henry Muller via frnog]

Faut-il en déduire qu'aucune administration ne peut acheter de 
prestation / bien en dehors d'entreprises françaises?


Donc y a des boites (CASSOS par ex) qui vont encore plus se rincé sur 
les administrations ce qui va encore plus augmenté leurs budgets, ce 
n'est pas comme cela qu'on fera des économies au niveau de l'état...


C'est du n'importe quoi cette facturation électronique.

Email Signature
Le 31/07/2023 à 16:37, Jules via frnog a écrit :

Salut,

Tu prends la facture du ripe sur toi et tu facture la métropole car tu
peux déposer tes factures sur chorus pro.

Précise-leurs que tu sera obligé de prendre un pourcentage pour combler
le fait que tu va te prendre des impôts/taxes/autre du gouvernement
dessus.

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

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

[Pierre-Henry Muller via frnog]

Email Signature
Le 26/06/2023 à 19:43, Maxime DERCHE a écrit :



Configurer le serveur web pour de l'IPv6 aurait considérablement 
agrandi la surface d'attaques possibles.


C'est exactement à cause de ce genre d'ânerie que je persiste à prôner 
les outils normatifs et notamment le pire d'entre eux, l'analyse de 
risque, même si je considère ces outils dangereux et largement sur-côtés.


J'aimerais bien voir l'analyse de risque qui conclurait à un plus 
grand risque en coupant IPv6.


=> Dans la mesure où IPv6 est activé par défaut partout côté serveur 
dans le noyau et pour tout ce qui existe au niveau 7 depuis des 
années, l'activer dans un vhost HTTP/HTTPS n'agrandit absolument pas 
la surface d'attaque : elle est /déjà/ là, cette surface d'attaque...


Une analyse de risque sérieuse qui désactive IPv6 devrait également 
désactiver IPv4. Le Air Gaped est la seule solution pour retirer le 
risque d'être connecté, pas la version du protocole.


On fait du v6 par défaut depuis 2008, le v4 public est optionnel et le 
v4 privé très fortement limité avec NAT multiple interdits et c'est un 
bonheur à administrer.


Par contre  on a un blocage particulier c'est le réseau utilisateur, les 
clients ont du multi wan de nos jours et on n'a rien trouvé dans les 
possibilités d'IPv6 à part le NAT sortant pour faire du failover entre 
interface WAN. Sans NAT faut attribuer à chaque terminal, deux adresses 
IPv6 de deux subnets différents (des deux FAI) et donc deux routes v6 et 
là ça bloque. Et puis il y a encore pas mal d'équipements qui pour faire 
fonctionner de l'ipv6 obligent à avoir de l'ipv4 (coucou les imprimantes 
Canon et HP). Bref pour les réseaux d'entreprise pour le moment on n'a 
pas trouvé la solution mais côté hébergement / serveurs / réseaux WAN 
tout fonctionne bien. Fini le temps où on mettait un reverse proxy tcp / 
udp devant les Tomcat non compatibles par exemple :D



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

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

[Pierre-Henry Muller via frnog]

Je m'avance pour une raison technique, pour envoyer des emails le 
serveur doit avoir un PTR sur ses IPs or certains Cloud proposent de 
gérer le reverse en IPv4 mais très rarement en IPv6... J'ai bien entendu 
exclu de facto certains qui ne permettent pas le reverse dns en v4 et v6.


Sinon avec des briques open source c'est aussi facile qu'en v4. Certes 
les blacklists ne savent pas gérer v6 mais vu le bordel qu'a mis 
Spamhaus la semaine passée en interdisant à plusieurs Cloud de faire des 
requêtes chez eux sans être authentifié API, ça a conduit à un rejet 
massif d'emails légitime ce qui a conduit beaucoup d'admins mail à virer 
Spamhaus plutôt qu'à récupérer une clef.


Du coup pour moi, le débat sur les blacklists n'a plus lieu d'être 
puisqu'elles sont de moins en moins nécessaires et que l'on fait bien 
mieux avec du Crowdsec / Fail2ban bien réglé.


Sinon en fausse raison comme dans beaucoup d'autres point technique y a 
la flemme et le ça rapportera rien de plus à part des problèmes.


Email Signature
Le 26/06/2023 à 13:57, Louis Poidevin via frnog a écrit :

La vraie si possible. ^^


--- Original Message ---
Le lundi 26 juin 2023 à 13:53, Stephane Bortzmeyer  a écrit :



On Mon, Jun 26, 2023 at 11:50:06AM +,
Louis Poidevin via frnogfr...@frnog.org  wrote

a message of 105 lines which said:


Ma question est donc la suivante : connaissez-vous les raisons pour
lesquelles les entreprises, même les hébergeurs mail, s'en tiennent
à l'IPv4 uniquement ?

Il faut une réponse bienveillante ou bien il faut la vraie ? :-)

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

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

Re: [FRnOG] [MISC] RIPE General Meeting: Billing scheme 2024

[Pierre-Henry Muller via frnog]

A voté.

Pour info le lien pour le vote est envoyé depuis une adresse non RIPE : 
no-re...@mail.assembly-voting.com


Du coup je pensais ne pas l'avoir reçu alors qu'il n'était pas rangé par 
les filtres dans la bal RIPE.


Bon vote

Email Signature
Le 24/05/2023 à 17:02, Clement Cavadore a écrit :

Hello,

On Wed, 2023-05-24 at 16:57 +0200, Paul Rolland (ポール・ロラン) wrote:

Tant qu'on y est... j'ai recu le mail avec le password RIPE NCC, mais
pas le mail de Assembly Voting avec le lien. C'est encore trop tot ?


Effectivement, le vote n'est pas encore ouvert.


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

Re: [FRnOG] [TECH] Attaque massive vers mails inexistants.

[Pierre-Henry Muller via frnog]

Bonjour,

Tous les serveurs SMTP ont différentes périodes avec des bots / scanner 
qui se font plaisir sur des tests en masse.


Dans les faits tu peux mettre un fail2ban / Crowdec, bannir les IPs sur 
des périodes plus longues voir définitivement car ce sont rarement des 
serveurs de tes correspondants ou filtrer geoip les pays que tu 
autorises à te contacter en smtp.


Pour les logs vu que tu es censé garder 1 an de logs légalement pour le 
smtp / imap / pop, quelques scan ne devraient pas te saturer une 
partition car juste le bruit de fond annuel d'un serveur smtp ouvert à 
tout Internet génère pas mal de lignes.


Bon courage

Email Signature
Le 24/05/2023 à 10:53, Guy Larrieu via frnog a écrit :

Bonjour,

Nous recevons actuellement une attaque massive vers des adresses 
inconnues. En gros, des milliers d'IP (probablement des serveurs 
piratés) émettent des millions de mails vers des domaines que nous 
gérons à des adresses inexistantes. Le but semble naturellement de 
constituer un annuaire d'adresses existantes (c'est trop espacé dans 
le temps pour être du DDoS).


On gère l'attaque sans trop de difficulté, le principal problème étant 
la gestion des logs qui débordent un peu, mais on se questionne sur la 
portée de l'attaque, si nous sommes directement ciblés ou si d'autres 
gros services de messagerie rencontrent aussi ce problème actuellement.


Guy.


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

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

Re: [FRnOG] [MISC] Ripe ncc charging scheme 2024

[Pierre-Henry Muller via frnog]

At first sight the fees are not comparable between ARIN and the RIPE 
project.
For the small players who are between /24 and /20 it is maximum 1000$ 
when the calculations on the RIPE side per subnet make the bill rise 
quickly around 4000-6000€ depending on the number...


Email Signature
Le 20/03/2023 à 20:25, Rod Beck a écrit :

I am really confused. Is RIPE charging a lot for IPV6 allocations?

Here's ARIN's fee schedule which is based on the sum of IPV4 and IPV6:

  https://www.arin.net/resources/fees/fee_schedule/
[https://www.arin.net/img/logo-social.png]<https://www.arin.net/resources/fees/fee_schedule/>
Fee Schedule<https://www.arin.net/resources/fees/fee_schedule/>
The ARIN Fee Schedule is a description of the fees ARIN charges to recover 
costs in a fair and equitable manner via appropriate fees to maintain adequate 
funds for the long-term stability of the organization.
www.arin.net



  
[https://lh6.googleusercontent.com/2Lt_FJczBnPSUVs0JtgFSEE6fuziTBUYnu5DNq7DbaHJYMBySeKDNp6ky9fv2ZWitaRolkQMR0HSYAjjdUM-gPjMmFr6UnBhtrqwCia4-yVzmmqhyQtc-ad4xrS_rOVnPbkMDOFfh8OhRQhNA_O0QSw]

Roderick Beck

Global Network Capacity Procurement

Budapest:36-70-605-5144

New Jersey: 908-452-8183

Email:rod.b...@unitedcablecompany.com

www.unitedcablecompany.com<http://www.unitedcablecompany.com/>

   
[https://lh6.googleusercontent.com/9R8wAqKpQlsGGeLxkitsOAGZIQucIAtkshtukANvmidSqz6q6w8bfgw1ayLaQLu77e2px7kf_Z-COzwKMwzoOaamiT8nQTWBY4SE5bJbgHvfBDpHFO2hot6tXqnoWYa3yY2p2l73e70mLuf930n9PKQ]<https://www.instagram.com/unitedcableco/>
  
[https://lh6.googleusercontent.com/hfZwsEtrU6zRgcl2B--cHNIQoviPy66lZXM-SPu-enHxzN4PTw-dn1561xJUY_PwXLBZrbwrbT5e8un3NttT_E4IMFTa65qHiW0AufGmGjEWhkMGr-zQWJ5y20Mp7aBfGzIJtB7U8u12DWutCGFr6go]<https://twitter.com/unitedcableco>
  
[https://lh4.googleusercontent.com/QlM9Q72tZY7lyyTh46fFRX4812LGdtEnBEFfpd4m3ybv2msBvSJCsAwwjCBCeTVniXqGwoqGsmuerW9bZZ_VYsRzJ8gVPxQEWVPa82Rs5ELajVXrNnbFlGgi6SzxOjRHT8QPmtb3UhVs_YRmxQjY3Uo]<https://www.linkedin.com/company/unitedcablecompany/>

[https://lh6.googleusercontent.com/utA6pbJLZJpgC_rlNXfhviBHRjT4pyeShbRvycb8HG3_DFzbMXuo136B2hLqlphCvLhy2ZmnsrHMVAk-1hWpTRr3eDqQzfXT5VYftw_P8fzUbpgbmsVFnZf2WQVTsL97wpeVqRZbMOf7N95Eq4Up-as]<https://unitedcablecompany.com/video>


From:frnog-requ...@frnog.orgon behalf of David 
Ponzone
Sent: Monday, March 20, 2023 4:55 PM
To: Thibaud PERRET
Cc: Clement Cavadore; Pierre-Henry 
Muller;frnog@frnog.org  
Subject: Re: [FRnOG] [MISC] Ripe ncc charging scheme 2024

En fait, dans leur modèle, avoir un /19 IPv6, c’est comme avoir 129 /24 IPv4 
(en terme de coût pour le LIR).
Donc moi, je vais rendre mon /19 et faire du CGNAT.


Le 20 mars 2023 à 16:31, Thibaud PERRET  a écrit :

Bonjour Clément, bonjour à tous,

Les resssources PI ne rentrent pas dans le calcul, contrairement à ce
que tu dis et à ce que certains ont pensé dans un premier temps. Ils
s'agissait en réalité d'une erreur. Seuls les PA rentrent en ligne de
compte comme l'indique  Simon Jan Haytink du RIPE NCC dans le message
suivant 
(https://www.ripe.net/ripe/mail/archives/members-discuss/2023-March/004746.html)
:

Also, a member pointed out an error in the calculator - cell L50 was
calculating total PI rather than ASN assignments as expected. This has
been fixed and the updated calculator is now available to download from
the consultation page:
https://www.ripe.net/participate/mail/member-and-community-consultations/charging-scheme-2024-consultation

Bien à vous,
Thibaud.

On Mon, Mar 20, 2023 at 12:06 PM Clement Cavadore  wrote:

Hello,

Non, pas exactement. Ils ont dans l'idée de réintroduire une
facturation "par catégorie", un peu à l'instar de comment c'était fait
il y a longtemps.

Le calcul de la catégorie dépendant de l'étendue des allocations
IPv4/IPv6, mais également du nombre de ressources sponsorisées (blocs
PI IPv4/IPv6, et ASN).

Une grande discussion autour de cela est en cours sur members-discuss,
et le open house de demain fait partie de cette discussion. En ce qui
me concerne, j'ai déjà exprimé mes inquiétudes et griefs dans l'état
d'esprit de cela. Je pense, par exemple, qu'il est équitable de compter
le span de ce qui est alloué en PA aux LIRs dans une pondération, mais
trouve injuste par exemple, de compter les ressources sponsorisées dans
ce décompte. Et j'estime également que ca "monte trop vite", quand on
compare ce que paieraient des petits LIRs ayant quelques milliers
d'IPv4 en alloc, a des LIR en ayant quelques centaines de milliers
voire quelques millions. Bref, le modèle me parait à revoir :)

... et leur budget (au RIPE NCC) aussi, au passage. Il n'a fait que
croitre, et me parait un peu oversized de nos jours, et ca ne me parait
pas normal qu'on soutienne cette croissance sans rien dire.


Clément

On Mon, 2023-03-20 at 15:50 +0100, David Ponzone wrote:

Re: [FRnOG] [MISC] Ripe ncc charging scheme 2024

[Pierre-Henry Muller via frnog]

Le fait de découper par services va clairement faire le jeu d'augmenter 
tel ou tel service chaque année.


Je pense que ça ira vers une décorrélation de la réalité comme les 
crossco dans les DC, c'est regrettable!


Je ne connais pas leur coûts de fonctionnement mais pour tenir un 
registre de ressources attribuées, ça ne me parait pas nécessiter une 
énorme équipe non plus.


J'ai donc clairement une préférence pour ne pas changer les règles du 
jeu en cours de route.


Email Signature
Le 20/03/2023 à 16:05, Clement Cavadore a écrit :

Hello,

Non, pas exactement. Ils ont dans l'idée de réintroduire une
facturation "par catégorie", un peu à l'instar de comment c'était fait
il y a longtemps.

Le calcul de la catégorie dépendant de l'étendue des allocations
IPv4/IPv6, mais également du nombre de ressources sponsorisées (blocs
PI IPv4/IPv6, et ASN).

Une grande discussion autour de cela est en cours sur members-discuss,
et le open house de demain fait partie de cette discussion. En ce qui
me concerne, j'ai déjà exprimé mes inquiétudes et griefs dans l'état
d'esprit de cela. Je pense, par exemple, qu'il est équitable de compter
le span de ce qui est alloué en PA aux LIRs dans une pondération, mais
trouve injuste par exemple, de compter les ressources sponsorisées dans
ce décompte. Et j'estime également que ca "monte trop vite", quand on
compare ce que paieraient des petits LIRs ayant quelques milliers
d'IPv4 en alloc, a des LIR en ayant quelques centaines de milliers
voire quelques millions. Bref, le modèle me parait à revoir :)

... et leur budget (au RIPE NCC) aussi, au passage. Il n'a fait que
croitre, et me parait un peu oversized de nos jours, et ca ne me parait
pas normal qu'on soutienne cette croissance sans rien dire.


Clément

On Mon, 2023-03-20 at 15:50 +0100, David Ponzone wrote:

Le tableau du cas n°2, facturation par catégorie, c’est moi qui sait
pas lire ou bien ils sont fous ?
On paierait 8000€/an parce qu’on a des IPv6 ?


Le 20 mars 2023 à 15:23, Pierre-Henry Muller via frnog <
frnog@frnog.org> a écrit :

Merci pour le rappel, je n'avais pas encore regardé les changements
qu'ils proposaient.

Pour tout le monde, allez voir ce tableau excel vous allez être
surpris par la variation du montant si ça passe :
https://www.ripe.net/participate/mail/member-and-community-consultations/member-calculator-charging-scheme-2024-v2.xlsx

Je vais m'inscrire pour suivre cela du coup.

Email Signature
Le 20/03/2023 à 13:53, Thomas BRENAC via frnog a écrit :

Petit Rappel:

L’open house pour discuter du schéma de facturation 2024 du ripe
c’est demain mardi à 14:00

‘ faut s inscrire…
Thomas
__

Thomas BRENAC

+33686263575



---
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/

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

Re: [FRnOG] [MISC] Ripe ncc charging scheme 2024

[Pierre-Henry Muller via frnog]

On est bien d'accord qu'il y a un problème !

Si ça passe, je pense que là, c'est la fin de l'ipv6 même pour ceux qui 
ont fait l'effort de le mettre en place.


Il faudra rappeler que l'augmentation des comptes LIR pour gratter des 
subnets v4, quand ça va se consolider, ça ne fait juste que revenir à la 
situation précédente. Mais j'ai comme l'impression qu'ils se sont 
accommodés à ces revenus supplémentaires...


Email Signature
Le 20/03/2023 à 15:50, David Ponzone a écrit :

Le tableau du cas n°2, facturation par catégorie, c’est moi qui sait pas lire 
ou bien ils sont fous ?
On paierait 8000€/an parce qu’on a des IPv6 ?


Le 20 mars 2023 à 15:23, Pierre-Henry Muller via frnog  a 
écrit :

Merci pour le rappel, je n'avais pas encore regardé les changements qu'ils 
proposaient.

Pour tout le monde, allez voir ce tableau excel vous allez être surpris par la 
variation du montant si ça passe 
:https://www.ripe.net/participate/mail/member-and-community-consultations/member-calculator-charging-scheme-2024-v2.xlsx

Je vais m'inscrire pour suivre cela du coup.

Email Signature
Le 20/03/2023 à 13:53, Thomas BRENAC via frnog a écrit :

Petit Rappel:

L’open house pour discuter du schéma de facturation 2024 du ripe c’est demain 
mardi à 14:00

‘ faut s inscrire…
Thomas
__

Thomas BRENAC

+33686263575



---
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] Ripe ncc charging scheme 2024

[Pierre-Henry Muller via frnog]

Merci pour le rappel, je n'avais pas encore regardé les changements 
qu'ils proposaient.


Pour tout le monde, allez voir ce tableau excel vous allez être surpris 
par la variation du montant si ça passe : 
https://www.ripe.net/participate/mail/member-and-community-consultations/member-calculator-charging-scheme-2024-v2.xlsx


Je vais m'inscrire pour suivre cela du coup.

Email Signature
Le 20/03/2023 à 13:53, Thomas BRENAC via frnog a écrit :

Petit Rappel:

L’open house pour discuter du schéma de facturation 2024 du ripe c’est demain 
mardi à 14:00

‘ faut s inscrire…
Thomas
__

Thomas BRENAC

+33686263575



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

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

Re: [FRnOG] [MISC] L'ARCEP m'inquiète....

[Pierre-Henry Muller via frnog]

Déjà que mettre du GSM pour des ascenseurs on perd en disponibilité par 
rapport à une ligne classique, coucou les coupures de courant de quartier.


On augmente le coût pour les copropriétés.

Mais s'il faut mettre du Starlink pour avoir une ligne téléphonique 
c'est overkill!


Il ne faut pas oublier qu'il y a des petits usages qui n'ont pas 
vocation à générer des coûts mensuels démesurés.


Email Signature
Le 27/01/2023 à 16:26, Paul Rolland (ポール・ロラン) a écrit :

Hello,

On Fri, 27 Jan 2023 16:20:57 +0100
David Ponzone  wrote:


  un truc qui couvre 100% des foyers

Euh... rassure-moi, t'es pas en train de parler du telephone classique tel
qu'on le connait tous et de la possiblite d'un ADSL avec, hein ? Parce que
100%... hmmm J'ai qq doutes dans certains coins recules que je connais.

Paul


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

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

Re: [FRnOG] [TECH] Serveur DNS employés ?

[Pierre-Henry Muller via frnog]

Email Signature
Le 14/12/2022 à 10:23, Pascal PETIT a écrit :

il y a 2 questions que je me pose :
   - y a-t-il des gens qui utilisent le DNS pour faire de la tolérance
 de panne avec un TTL très très court et une mise à jour du dns en
 cas de soucis ? (je pense que c'est une très mauvaise idée)


orange.fr, facebook.com 60 secondes

www.google.com, yahoo.fr 300 secondes

Ils sont bien plus nombreux qu'on le pense, même si pour Google c'est à 
mon avis plus une raison de traçabilité.




   - et, en défense contre les TTL trop courts, y a-t-il une durée mini
 que les dns récursifs des FAI imposent ?


Tous ceux qui font du DNS menteur sont ceux qui imposent un TTL minimum.
---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] Re: [TECH] Problème DNS chez Microsoft Outlook

[Pierre-Henry Muller via frnog]

Email Signature

Le 06/07/2022 à 11:50, Stephane Bortzmeyer a écrit :

On Wed, Jul 06, 2022 at 11:34:17AM +0200,
  Pierre-Henry Muller via frnog  wrote
  a message of 201 lines which said:


Même snas EDNS j'ai rien pour obtenir un A ou  :

dig +nodnssec +noedns +bufsize=0 +nocookie
campuscyber-fr.mail.protection.outlook.com

Normal, dig envoie par défaut au résolveur local (qui, lui, gère
probablement EDNS). Il faut utiliser le @ pour demander aux serveurs
faisant autorité.


Sauf que ne sachant pas (sauf avec ton message) quels sont les NS de 
mail.protec... avec une requête dns à d'autres résolveurs, si la panne 
est liée à cela ils ne sont pas prêts d'être à nouveau visible sur le net.




OpenPGP_signature
Description: OpenPGP digital signature

Re: [FRnOG] Re: [TECH] Problème DNS chez Microsoft Outlook

[Pierre-Henry Muller via frnog]

J'ai pas mal d'exemples en mail.protection.outlook.com qui ne marchent 
pas, pour le reste j'ai lu des tweets disant que O365 avait aussi des 
soucis, j'ai pas regardé plus ça ne nous concerne pas.


Même snas EDNS j'ai rien pour obtenir un A ou  :

dig +nodnssec +noedns +bufsize=0 +nocookie 
campuscyber-fr.mail.protection.outlook.com


; <<>> DiG 9.16.30-RH <<>> +nodnssec +noedns +bufsize +nocookie 
campuscyber-fr.mail.protection.outlook.com

;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 53818
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;campuscyber-fr.mail.protection.outlook.com. IN A

Par contre je n'ai pas de réponse pour les NS de mail.

dig +nodnssec +noedns +bufsize=0 +nocookie NS mail.protection.outlook.com

ne renvoie plus rien sur plusieurs dns publique


Email Signature
Le 06/07/2022 à 11:25, Stephane Bortzmeyer a écrit :

On Wed, Jul 06, 2022 at 11:16:49AM +0200,
  Pierre-Henry Muller via frnog  wrote
  a message of 88 lines which said:


Depuis presque une heure, toutes les entrées dns pointant sur outlook.com
sont sans réponse,

Pas tout outlook.com, seulement mail.protection.outlook.com, non ?


Y a plus qu'à attendre du coup.

Ou débrayer EDNS, leurs serveurs à la con ne gèrent pas EDNS.

% dig @ns1-proddns.glbdns.o365filtering.com. NS  mail.protection.outlook.com
...
;; ->>HEADER<<- opcode: QUERY, status: FORMERR, id: 64702

% dig +nodnssec +noedns +bufsize=0 +nocookie 
@ns1-proddns.glbdns.o365filtering.com. NS  mail.protection.outlook.com
...
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52148
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;mail.protection.outlook.com. INNS

;; ANSWER SECTION:
mail.protection.outlook.com. 10 IN NS ns1-proddns.glbdns.o365filtering.com.
mail.protection.outlook.com. 10 IN NS ns2-proddns.glbdns.o365filtering.com.


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


OpenPGP_signature
Description: OpenPGP digital signature

[FRnOG] [TECH] Problème DNS chez Microsoft Outlook

[Pierre-Henry Muller via frnog]

Bonjour,

Depuis presque une heure, toutes les entrées dns pointant sur 
outlook.com sont sans réponse, les cache dns commencent à expirer.


exemple campuscyber-fr.mail.protection.outlook.com ne résout plus.

J'ai fait des tests sur dnschecker.org ça commence à virer au rouge un 
peu partout.


On vient de me dire que O365 est aussi impacté.

Y a plus qu'à attendre du coup.

Email Signature


OpenPGP_signature
Description: OpenPGP digital signature

[FRnOG] [JOBS] Ingénieur F/H Openstack Ceph

[Pierre-Henry Muller via frnog]

Bonjour,

DigDeo est spécialisé en infogérance et hébergement multi-cloud de 
systèmes Linux / Open Source
critiques avec une différenciation sur la cybersécurité et la 
performance depuis 2010.


Nous recherchons un ingénieur femme / homme spécialisé Cloud sur 
Openstack et Ceph. Ce poste

s’effectuera dans le cadre d’un contrat CDI.

Votre rôle

Rattaché à la Direction et l’équipe technique, vous participez au choix 
d’architecture, à la construction et
à la mise en œuvre d’une nouvelle infrastructure Cloud basée sur 
Openstack et Ceph.
La nouvelle architecture physique est déjà installée en datacentre, un 
premier déploiement a eu lieu lors
d’une prestation mais n’a pas été menée à son terme, estimation à 80 % 
terminée. Votre objectif est de
reprendre les éléments déjà effectués, réviser si besoin ce qui a été 
entrepris et terminer le déploiement.
L’architecture est 100 % Infrastructure as Code avec l’utilisation de 
Bifrost pour le déploiement du
baremetal, Ansible Kolla pour le déploiement d’Openstack. Les modules 
Openstack utilisés sont : Nova,
Neutron, Horizon, Cinder, Glance, Octavia, Masakari, Designate, Manilla, 
Tempest, Rally, Gnocchi,
Ceilometer, Cloudkitty. L’infrastructure physique est entièrement 
décrite dans un IRM/IPAM disposant

d’une API.

• Passer en revue le cahier des charges, les choix techniques, les 
actions déjà réalisées

• Repérer et lever les points de blocages du déploiement
• Faire des choix d’amélioration pour terminer de déployer l’infrastructure
• Préparer l’architecture à la mise en production : supervision, relevé 
consommation, hardening

• Effectuer des tests de redondance, tir de performance
• Lier l’authentification sur un cluster Ldap existant dédié à cette 
nouvelle infrastructure

• Former l’équipe système à son utilisation
• Gérer les images / isos des différents OS
• Gérer les flavors des instances, génération CPU, performance disque, 
GPU, ...

• Assister et soutenir les migrations des clients
• Assurer le maintien en condition opérationnelle des environnements 
techniques

• Documenter et coder avec Ansible les actions, changements, évolutions
• Création d’une équipe dédiée à l’exploitation de ce Cloud par recrutement
• Gérer les montées de version d’Openstack et les migrations associées
• Gérer la personnalisation d’Horizon avec le soutien d’UX et développeurs
• Participer aux astreintes niveau 3 sur ce périmètre
• Faire évoluer cette infrastructure vers un Cloud semi-public avec 
l’automatisation de la facturation


Votre profil

De formation minimum bac +3 ou autodidacte avec une solide expérience, 
vous justifiez de plusieurs
années en conception et maintient d’architecture Linux / virtualisation 
et idéalement Openstack.
• Vous justifiez d’une expérience réussie en déploiement et exploitation 
d’Openstack Kolla
• Maîtrise d’Openstack Kolla et des principaux modules : Nova, Neutron, 
Cinder, Swift, Horizon, certification appréciée

• Maîtrise de Linux Debian et le réseau LAN IPv4 / IPv6
• Maîtrise d’Ansible pour l’automatisation de toutes les actions : 
installation, évolutions, maintenance, ...

• Bonne connaissance de Terraform pour mener des tests sur l’architecture
• Vous connaissez le matériel serveur / réseau pour participer au choix 
de l’achat des matériels et à leur suivi lors de l’exploitation
• Vous êtes sensible à la sécurité des systèmes et connaissez les normes 
ISO 27001, HDS
• Vous êtes proactif, faites preuve de curiosité et n’avez pas peur de 
tester des nouveautés
• Vous êtes à l’aise à l’oral et avez de bonnes compétences 
rédactionnelles en français


Contexte

- Vous travaillerez dans un environnement Open Source / Logiciels Libres.
- Vous avez une idée d’amélioration / produit, soutenez-la, fédérez des 
personnes et réalisez là.

- Une bonne journée passe par l’apprentissage de nouvelles connaissances.
- Nous aimons ce que nous faisons et aimons faire le meilleur pour nos 
clients.
- Lieu de travail à Croissy sur Seine / Chatou dans l'ouest parisien, 
proximité transports.

- Intervention en datacenter en Ile de France.
- Évolution du poste si intéressé d'une équipe à créer responsable de 
l'exploitation de cette infrastructure ou

en transverse avec l'exploitation / projets

Avantages

- Ressources Clouds pour expérimenter ou héberger à titre personnel
- Participation 50 % aux transports en commun
- Une bonne table au restaurant d'entreprise avec participation de 50 % 
sur l’addition

- Café, boissons, graines, fruits secs gratuits
- Bonne mutuelle entreprise avec ou sans option famille

Entreprise

Notre équipe a mis en place depuis ses débuts le principe de tout 
automatiser dans son infrastructure
(Infrastructure As A Code). Cette automatisation nous permet 
d’intervenir rapidement sur les demandes
de nos clients tout en garantissant une disponibilité maximale des 
services. Et cela permet une réduction
drastique des erreurs humaines, une optimisation des coûts clients et 
d’avoir l’ensemble de service

constamment à jour.

Re: [FRnOG] Coupure freeix / peer proxad

[Pierre-Henry Muller]

Le 30/08/11 14:42, Fabien Dedenon a écrit :
>
> Dans ce domaine la Free n'est plus le trublion.. dommage en plus ils
> auraient bien participé à faire de la France une belle plaque
> d'échange, mais c'est tellement mieux le reste de l'Europe!
>
Il y a pas mal d'années le Freeix était un point renommé à mon sens,
toutes les hébergeurs où je suis passé ont tout fait ou presque pour
être dessus. Mais depuis 5 ans prendre des longueurs d'onde et aller
peerer à l'Amsix et au Linx est souvent plus bénéfique pour le nombre de
peer potentiels et en profiter pour aller mettre un transit à l'étranger.
Pire cela fait un argument commercial pour les commerciaux pour dire
regardé on est connecté partout en Europe, mais pratiquement pas en
France...




signature.asc
Description: OpenPGP digital signature

Re: [FRnOG] Publication du decret LCEN sur les logs services Internet

[Pierre-Henry Muller]

Le 7 mars 2011 à 09:46, Alexandre Archambault a écrit :
>> 
> 
> En attendant, vous pouvez vous baser pour ce qui est de la tarification du 
> référentiel existant pour la partie téléphonie, car à la base, identifier un 
> abonné / utilisateur par le ND ou par l'IP ou le login, c'est assez proche en 
> terme de requête dans le SI.
> 
> Cf. arrêté du 22 août 2006, codifié à l'article A 43.2 du Code de procédure 
> pénale <http://www.legifrance.gouv.fr/jo_pdf.do?cidTexte=JORFTEXT00268186>
> 
> Sinon, bon courage pour le recouvrement, qui actuellement sur les prestations 
> IP (pour ce qui concerne le judiciaire) frise le 5% compte tenu (i) de 
> l'absence de texte (ii) du faible montant unitaire, car c'est une facture par 
> réquisition, pas (encore) de facturation récapitulative, (iii) du mode 
> opératoire (le mémoire de frais est à envoyer non pas à l'OPJ qui vous 
> requiert, mais au greffe du tribunal de son ressort, qui a d'autres chats à 
> fouetter)


Question sans doute très bête, je ne vois pas où est mentionné l'ordre dans 
lequel doivent être fait les choses.
Rien n'empêche donc une fois la requête arrivée, de facturer en premier la 
prestation et d'attendre le paiement pour livrer
le résultat? Doit bien y avoir un truc pour bloquer cela mais là je ne trouve 
pas dans les différents textes.

--
Pierre-Henry Muller

Re: [FRnOG] Publication du decret LCEN sur les logs services Internet

[Pierre-Henry Muller]

Comme certains l'ont soulignés sur Twitter, quid des One Time Passwords, de 
l'openIP sur un serveur à l'étranger, 
de l'authentification Facebook / Google / ... ou autre entité qui n'aurait même 
pas de bureaux en France?

Pour ce qui est de la conservation des logs je me rappel une conférence FRNOG 
il y a quelques années où
une discussion était partie sur les coûts de stockage. Et une personne avait 
fait une excellente remarque
que les hôtels tiennent un journal de qui est venu dormir chez eux. Bien 
souvent cela se fait sur un livre et
qu'il était admis que ce livre pouvait disparaitre / bruler / noyé et l'hôtel 
n'avais pas de sanction.
Je ne vois là aussi aucune obligation de maintient d'un système hautement 
redondé, on prend donc des disques
sata on archive dessus, on les débranche et si un jour où nous demande quelque 
chose et que les disques
ne sont plus lisibles tant pis?

--
Pierre-Henry Muller



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

Re: [FRnOG] Publication du decret LCEN sur les logs services Internet

[Pierre-Henry Muller]

Le 1 mars 2011 à 12:36, Alexandre Archambault a écrit :

> C'était une question qui revenait régulièrement ici, à savoir qu'est ce que 
> je suis censé loguer en tant que FSI.
> 
> Après 7 années de gestation difficile, le décret LCEN sur les logs services 
> Internet a été publié au JO de ce jour.
> 
> <http://www.legifrance.gouv.fr/affichTexte.do;jsessionid=B751B8F7F3F02CB8342572AD305DECB1.tpdjo15v_3?cidTexte=JORFTEXT23646013&categorieLien=id>
> 
> Attention, c'est d'application immédiate, sans délai préalable pour mettre en 
> place l'usine à gaz qui permettra de tout loger / restituer dans les 
> meilleurs délais alors qu'en face ils ne semblent guère pressés d'en terminer 
> avec le papier.
> 
> --
> Alec,


J'ai envie de dire tout ce temps pour juste ca?

La principale information que j'en retiens c'est que la durée de rétention 
reste à 1 an de notre côté, du leur
ils se permettent de les garder 1 ou 3 ans en fonction du type de donnée.

Pour les mots de passe je confirme qu'on les stocke en l'état.
La question est plutôt doit on garder la clef / hash / whatelse pour le 
déchiffrer. Je connais des applications
qui opèrent des changements de clefs régulièrement pour chiffrer les données de 
paiement en ligne.
A la vue de cet article de loi, je ne vois pas ce qui oblige de garder la dite 
clef puisque ce n'est pas une
information liée à un tiers connecté sur l'infra.

--
Pierre-Henry Muller



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

Re: [FRnOG] Re: [FRnOG] Une idée rigolote pour prévenir les utilisateurs infectés

[Pierre-Henry Muller]

Je suis assez d'accord sur le fait que si mon fai fait cela je change aussi.
Malgré tout sans entrer dans du dpi, une analyse comportementale du flux
serait un bon compromis. L'analyse détecte une anomalie et déclenche un
incident.

Pour remonter l'incident au client, le plugin du navigateur a
l'inconvénient que tout le monde
ne l'installera pas, alors que pratiquement tous les opérateurs
proposent une machinbox, il suffirait alors qu'un bip retentisse pour
signaler l'incident voir de l'afficher sur la box.
Ce message inviterait le client a se rapprocher du support.




signature.asc
Description: OpenPGP digital signature

Re: [FRnOG] Re: [FRnOG] Re: [FRnOG] OVH crée un datacenter

[Pierre-Henry Muller]

> 
> on chauffe les entreprises voisines qui ont besoins de la 
> challeur pour chauffer les produits chimiques avant de les
> melanger. Eux ont vu leur facture EDF diminuer de presque 90%
> et donc au contraire c'est tout sauf "bullshit".
> 
> Octave

Arnaud tu devrais utiliser ta chaleur pour le préchauffage des chaudières de la 
centrale voisine :) ça sera écolo tant qu'ils ne démarrent pas la centrale,
t'auras sans doute une ristourne sur l'élec.

De mon point de vue Arnaud et Octave vous faites du bon boulot, chacun avec une 
approche différente mais au moins vous faites quelque chose de concret
pas comme d'autres qui utilisent vraiment le mot green sans avoir rien réalisé 
de probant.
--
Pierre-Henry Muller



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

Re: [FRnOG] Re: IPv6 Ripeness, et la France alors ?

[Pierre-Henry Muller]

Le 16 juin 2010 à 14:26, Dominique Rousseau a écrit :

> Le Wed, Jun 16, 2010 at 12:15:57PM +0200, Pierre-Henry Muller 
> [wall...@morkitu.org] a écrit:
>> Le soucis c'est vraiment le matériel et les progiciels, autant la
>> plupart des boitiers pros intègrent l'ipv6
>> autant tout ce qui reste bureautique (téléphone ip, imprimante, nas,
>> ...) ne suivent pas.
> 
> C'est pas un obstacle à l'adoption d'ipv6 sur internet, ça.
> Une imprimante ou un NAS, ça cause sur le réseau local, et ça peut
> continuer à n'utiliser qu'ipv4, même après la fin du monde.
> Tous les OS intégrant ipv6 sont dual-stack.
> 

Tout à fait, je réagissait au début de la conversation où il aurait fallu 
montrer l'exemple sur les lans.

Idéalement il serait préférable pour la gestion d'un lan d'avoir qu'une version 
à gérer en cas de recherche d'un problème
on doublerait le temps de recherche, on doublerait les règles d'un firewall, 
les acls sur différents équipements ou logiciels, ...

Je reste quand même persuadé que la bonne méthode pour une nouvelle structure 
est de faire du ipv6 only sur le lan et de gérer
les équipements posant problème avec un 6to4 au cas par cas.
Par contre pour un lan existant et en fonction de sa taille et des ses 
spécificités (progiciels, nb de routeurs et firewalls, vpn avec presta ou 
clients, ...)
ce n'est vraiment pas une mince affaire.
--
Pierre-Henry Muller



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

Re: [FRnOG] Re: IPv6 Ripeness, et la France alors ?

[Pierre-Henry Muller]

Le soucis c'est vraiment le matériel et les progiciels, autant la plupart des 
boitiers pros intègrent l'ipv6
autant tout ce qui reste bureautique (téléphone ip, imprimante, nas, ...) ne 
suivent pas.

Exemple récent d'une imprimante laser en réseau qui ne gère que le v4.

Je ne parle même pas des entreprises qui se connectent mutuellement en vpn et 
où c'est déjà un casse tête à monter
un lien stable entre différentes marques de routeurs.

A mon avis les backbones, les transits, tout ce qui est WAN va devenir ipv6 
mais y a de grandes chances pour que les réseaux entreprises
restent pour longtemps encore en v4.

Ceux qui feront un nouveau réseau en v6 only auront forcément un souci avec la 
dernière imprimante mise sur le réseau ou avec le téléphone IP
à la mode parce qu'il est joli et que le patron le veut.
Et je ne parle même pas des téléphones portable en wifi qui ne gèrent pas du 
tout l'ipv6.

--
Pierre-Henry Muller



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

[FRnOG] baie Dell à donner

[Pierre-Henry Muller]

Bonjour,

Un ami se sépare d'une baie Dell à son travail, je pense que cela peut 
intéresser du monde.
Contactez moi en privé pour les informations.

A bientôt
--
Pierre-Henry Muller



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