Re: [FRnOG] [BIZ] Projet FAI sur DSP RHD57

2017-09-24 Par sujet Olivier FONTÈS 
Hello, 

Peut-être y a-t-il une piste auprès de LDN (Lorraine Data Network) qui
existe depuis 7 ans sur nancy, je ne sais pas ou ils en sont mais il me
semble qu'ils ont déjà un début d'opinion sur le sujet. 

++

---

OLIVIER FONTÈS

Le 2017-09-24 20:35, Xavier Beaudouin a écrit :

> Hello Aurélien,
> 
>> La Moselle est un cas bien particulier et ne fait pas partie du déploiement
>> Altitude Infrastructure (Qui au passage a aussi des tarifs inaccessibles ).
>> Ce marché ne concerne pas la Moselle, puisque c'est Orange qui assurera le
>> déploiement et la commercialisation des plus de 300 000 prises FTTH sur le
>> département. Le réseau RHD57 sera prolongé jusqu'à la frontière 
>> Luxembourgeoise
>> et passera sous concession Orange à l'horizon 2021.
>> 
>> Les prix de gros Orange ne sont pas vraiment accessible en FTTB pour les PME 
>> et
>> le FTTH reste verrouillé (impossible pour un opérateur local de proposer du
>> FTTH).
>> La suite, si on est opérateur, on la connait tous... Comme on peut le voir 
>> dans
>> l'actualité, ce problème est régulièrement remonté à l'ARCEP.
>> Les pannes Orange, on les connait également (non respect des GTR et tout est
>> fait pour ne pas verser de pénalités)
>> 
>> Donc nous avons effectivement un problème de concurrence et nous aurons 
>> encore
>> des problèmes de dépendance à la région Parisienne si on réitère ce type de
>> réflexions.
>> 
>> De part cette analyse, nous souhaitons effectivement proposer une 
>> alternative.
> 
> Est-ce que tu comptes "déborder" dans le 54, parce que pareil quand tu as 
> 8Mbps tu es "content"... (en ADSL, je ne parles pas des prix hallucinant des 
> SDSL...).
> 
> Xavier
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/

signature.asc
Description: OpenPGP digital signature

Re: [FRnOG] [BIZ] Projet FAI sur DSP RHD57

2017-09-24 Par sujet Xavier Beaudouin 
Hello Aurélien,

> La Moselle est un cas bien particulier et ne fait pas partie du déploiement
> Altitude Infrastructure (Qui au passage a aussi des tarifs inaccessibles ).
> Ce marché ne concerne pas la Moselle, puisque c'est Orange qui assurera le
> déploiement et la commercialisation des plus de 300 000 prises FTTH sur le
> département. Le réseau RHD57 sera prolongé jusqu'à la frontière 
> Luxembourgeoise
> et passera sous concession Orange à l'horizon 2021.
> 
> Les prix de gros Orange ne sont pas vraiment accessible en FTTB pour les PME 
> et
> le FTTH reste verrouillé (impossible pour un opérateur local de proposer du
> FTTH).
> La suite, si on est opérateur, on la connait tous... Comme on peut le voir 
> dans
> l'actualité, ce problème est régulièrement remonté à l'ARCEP.
> Les pannes Orange, on les connait également (non respect des GTR et tout est
> fait pour ne pas verser de pénalités)
> 
> Donc nous avons effectivement un problème de concurrence et nous aurons encore
> des problèmes de dépendance à la région Parisienne si on réitère ce type de
> réflexions.
> 
> De part cette analyse, nous souhaitons effectivement proposer une alternative.


Est-ce que tu comptes "déborder" dans le 54, parce que pareil quand tu as 8Mbps 
tu es "content"... (en ADSL, je ne parles pas des prix hallucinant des SDSL...).

Xavier


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

Re: [FRnOG] [BIZ] Refonte infrastructure

2017-09-24 Par sujet Thomas Yoann 
Evidement tu est le bienvenu pour visiter. Je connais les differents arguments 
que tu cite. 
C'est d'ailleur pour ca qu'on a etofee nos offres avec du cloud publique. Et 
notre force est clairement le sur-mesure, un vdc securise par client, mais 
aussi le conseil. Je suis d'accord que si l'on na pas ca en tant que "petit" on 
a aucune chance.


Yoann Thomas 

> Le 24 sept. 2017 à 06:37, Eric Mognat  a écrit :
> 
> tout à fait.
> 
> Je pense que Wallace comme Jean-Yves ou moi ne sommes pas anti
> conteneur mais anti conteneur tels que pratiqué actuellement (images
> obsolètes et tout le toutim) dans de très nombreux cas. En corolaire,
> il me semble qu'une partie de ce problème vient de l'écoute des
> sirènes marqueting du type "regardez comment c'est trop bien le devops
> ... Plus besoin d'avoir qqu'un qui comprends ce qui se passe, "time to
> market" raccourcis (c'est une de mes préférée) et blablabla" et je
> voulais mettre en exergue une dimension parfois trop facilement
> oubliée (pas de manière claire à l'évidence :-)).
> 
> Pour le reste, je suis tout à fait d'accord avec toi sur les apports
> de la techno à de nombreux niveaux y compris en terme de sécurité.
> 
> A+
> 
>> Le 23 septembre 2017 à 08:23, Raphael Mazelier  a écrit :
>> 
>> 
>>> On 22/09/2017 10:07, Wallace wrote:
>>> 
>>> Ça ne solutionne pas le souci majeur de Docker et toute instance
>>> conteneur à savoir que les OS minimalistes dans les images sont
>>> - non sécurisées, c'est équivalent à un debootstrap or ceux qui mettent
>>> en prod des OS sans faire de hardening devraient changer de métier
>>> - rarement mis à jour soit par non mise à jour de l'image par les
>>> mainteneurs d'images officielles ou l'équipe de dev interne soit par non
>>> destroy / recreate d'une instance parce qu'au final ça marche et on a
>>> pas de mise à jour de code à faire dessus...
>>> 
>>> Les conteneurs c'est bien pour faire des instances copies de prod pour
>>> du dev / staging / recette / préprod sans mettre les mêmes moyens
>>> d'infrastructure que la prod.
>>> 
>>> On a vu plusieurs startup faire du full Docker sur quelques serveurs. Un
>>> simple audit de sécu et on passe de l'instance prod à la compta à la dev
>>> et au gitlab juste en ayant scanné les ports locaux des hôtes et en
>>> ayant mis un petit code de redirection de ports ...
>>> Je parle même pas de l'âge des instances qui pour certaines avaient
>>> presque 2 ans ... donc l'OS hôte Docker n'avait jamais été mis à jour,
>>> forcément faudrait arrêter la prod, la dev, le staging, la compta, le
>>> crm, l'erp, le partage de fichier, en gros arrêter la boite. La raison
>>> c'est trop compliqué de mettre en cluster sur des hosteurs de serveurs
>>> dédiés, sans blague.
>>> 
>>> Non sérieusement en prod Docker ou tout conteneur on le conseil
>>> seulement pour faire un groupe d'hôtes qui accueilleraient le même type
>>> d'instances dans une DMZ avec un vrai firewall devant, avec une vrai
>>> politique de mise à jour et avec que des images custom avec un hardening
>>> bien fait mérite d'être en production. Mais rien que maintenir leurs
>>> propres images j'ai vu beaucoup de devops ou dev ne pas vouloir se
>>> lancer là dedans, du coup faire des VM ou baremetal avec un Ansible ou
>>> Puppet permet de concilier l'infrastructure as a code avec les bonnes
>>> pratiques systèmes en production.
>>> 
>>> 
>> 
>> Je ne comprends vraiment pas cet argumentaire anti conteneur niveau
>> sécurité.
>> 
>> Au contraire le l'utilisation de containers dans un environnement type k8s
>> me semble une bonne opportunité niveau sécurité. Cela permet de faire du
>> rolling-update niveau container et niveau host (ce qui est en effet un
>> argument pour ne pas faire d'update). Typiquement tout est éphémère, et tout
>> est constamment mis à jour.
>> 
>> Concernant les images en effet je suis d'accord qu'il faut les faire soit
>> même (c'est même une évidence).
>> 
>> L'autre immense avantage des architectures type k8s ce que l'on expose que
>> ce qui doit être exposé, cela la limite la surface d'attaque externe.
>> Concernant le filtrage interne des projets type calico permette un filtrage
>> très fin (ala SecurityGroup Aws).
>> 
>> Ce qui tu dis peut être c'est que faire du conteneur n'importe comment est
>> dangereux ; oui comme une architecture classique. Bien utilisé cela permet
>> une bien meilleure segmentation (c'est bien un des mantra de la sécurité
>> hein ?).
>> 
>> --
>> Raphael Mazelier
>> 
>> 
>> 
>> 
>> 
>> 
>> ---
>> 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/