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

2024-01-26 Par sujet 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

2024-01-26 Par sujet 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

2024-01-26 Par sujet 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

2024-01-22 Par sujet 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é

2023-09-05 Par sujet 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 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

2023-07-31 Par sujet 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

2023-06-26 Par sujet 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

2023-06-26 Par sujet 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

2023-05-24 Par sujet 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.

2023-05-24 Par sujet 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

2023-03-21 Par sujet Pierre-Henry Muller via frnog
en 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/


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

2023-03-20 Par sujet 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

2023-03-20 Par sujet 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

2023-03-20 Par sujet 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....

2023-01-27 Par sujet 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 ?

2022-12-15 Par sujet 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

2022-07-06 Par sujet 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

2022-07-06 Par sujet 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

2022-07-06 Par sujet 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

2022-03-09 Par sujet 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.