[FRnOG] [TECH] RE: Cisco LACP avec Airfiber

[Michel Py]

> Sébastien 65 a écrit :
> Est-ce que parmi vous il y en a qui ont déjà monté un LACP Cisco avec 4 UBNT 
> Airfiber ?
> J'envisage sur un switch Cisco d'avoir deux Airfiber en master et à l'autre 
> bout les slaves connectés sur un
> autre switch Cisco, (de manière aussi à pouvoir gérer une redondance du 
> chemin si un couple de Airfiber tombe)...

Attention à configurer les canaux qu'elles utilisent, auto == interdit. Avec la 
PIRE de merde que tu as, faut en mettre une en haut de la bande et l'autre en 
bas.

Attention aussi à la séparation physique entre tes Airfiber; si tu montes les 
deux l'une juste au dessus de l'autre, elles vont pas aimer que l'une bouffe 
dans l'assiette de l'autre ;-)
Si c'est des Airfiber 5, je te conseille au minimum 2 mètres de séparation 
verticale entre les deux.

Michel.


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

RE: [FRnOG] [TECH] Quagga ou FRRouting ?

[Michel Py]

> Vincent Jardin a écrit :
> Pour RPKI: aucune idée, jamais vu en production. SVP, M. les sys/net-admin,
> on a besoin de vos lumières et retours d'expérience sur FRR sur ce sujet.

J'y travaille, c'est malheureusement pas en haut des priorités mais dès que 
j'ai quelque chose tu seras le premier à savoir.


> Avoir le temps de développer ne veut pas dire qu'on a le temps de mettre en 
> production. L'un a besoin des retours de l'autre.

Il y a un autre truc que je pourrais tester si c'était dispo sur ma plate-forme 
: EIGRP. Ennui de taille : la plate-forme en question c'est pfsense ;-)
J'ai installé le module FRR pour pfsense mais il a pas EIGRP. J'ai mis RIPv2 
(je sais, quelle horreur) pour apprendre les routes internes.

Y'à plusieurs trucs pas clairs sur FRR/pfsense : aucun écran pour configurer 
RIP, routed est dispo comme module (faudrait au moins dire que FRR c'est 
mieux), les routes RIP apprises par routed ne sont pas visibles, les routes RIP 
apprises par FRR le sont mais elles apparaissent comme "Kernel routes".


Que personne vienne me dire que "yàkà" configurer OSPF au lieu de RIPv2. Je 
sais que RIPv2 c'est de la merde, mais j'ai une config spéciale.


Michel.


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

Re: [FRnOG] [TECH] Automation: Ansible et ses alternatives

[Sabri Boukari]

6 mois est une des préconisations que j'ai entendu pas mal de fois par des
consultants dans les réunions d'architecture...
Sinon, je connais trés bien les dates je parle plutôt des choix prises par
les entreprises aujourd'hui.

par ailleurs le couple trés connu entre python et ruby on va dire les 4
pilliers d'automatisation de nos jours ne sont qu'une petite partie de ce
qui existe vraiment et depuis des dizaines d'année mais ces solutions ont
juste eut plus de chance dans le marché.

Perso, j'aime bien utiliser du shell et je maitrise quasiment toutes les
outils mais j'adore le shell même s'il s'agit d'écrire tout mes scripts.
J'avais utiliser "openSVC" en 2014 sur 40K serveur avec toutes la partie
stockage et les serveurs PA-RISC et itanium et ça fonctionnais trés bien.
SVCTools aussi qui est la partie console de OpenSVC, tout ça fonctionne.

Donc, le choix doit juste être fait pour une solution perenne et durable et
surtout bien maitrisé même si le choix nécessite de développer sont propre
usine.
A mon avis, le plus important c'est la pérenneté de la solution et non pas
sont age ou sa beauté


:p désolé pour tout les erreurs d'orthographe... J'écris en QWERTY@


2018-08-14 22:06 GMT+02:00 Jean-Yves LENHOF :

>
>
> Le 14/08/2018 à 15:53, Sabri Boukari a écrit :
> > Dernier petit détail...
> > Salt et plus efficace sur windows vs ansible...
> > pour ansible il y un backend a installé un espece de backdoor qui permet
> la
> > connexion et l'exécution des commandes shell sur windows.
> > comme cygwin
> >
> > Est Salt peut fonctionner en mode agent serveur et en mode standalone,
> d'ou
> > le principe * Master, slave dans salt stack.
> >
> > Ce n'est pas le cas pour ansible.
> > Un mode agent, serveur n'est pas aussi mauvais que ça donc tout dépend du
> > besoin et surtout de l'objectif à long terme.
> > Perso, je n'ai jamais étais convaincu des solus qui vive pendant 6 mois
> et
> > on les rejette aprés
>
> Hello,
>
> 6 mois tu y vas un peu fort
> Ansible existe depuis 2012 (Salt Slack existe depuis 2011 j'ai regardé)
> Perso depuis que j'ai essayé Ansible je ne peux plus m'en passer... et
> le fait que RedHat est mis du pognon pour racheter AnsibleWorks a ajouté
> pas mal de crédibilité à la solution (quelqu'un m'a dit que RedHat avait
> cherché à racheter Puppet il y a qq années, mais cela n'avait pas
> abouti comme chez AnsibleWorks il y avait plusieurs anciens de chez
> RedHat cela a du aider au rapprochement)
>
> Après il existe pas mal de solution alternatives (Puppet, Chef, Juju,
> Salt Slack, CfEngine, cdist, ), à toi de te faire ton idée...
>
> Pourquoi pour moi il est l'un des meilleurs outils :
> - Facilité d'utilisation
> - Communauté importante
> - RedHat
> - Pas mal de modules pour VMWARE, AWS, Azure, GCP
> - Des modules pour le réseau (Cisco, Cumulus, A10, F5, Aruba, DellOs,
> FortiOS, Netscaler, Infoblox)
>
> Le seul moin c'est la scalabilité et la rapidité avec pas mal de
> serveurs (mais j'ai fait tourné des choses sur 1000 serveurs et en
> ajoutant un peu de CPU et RAM sur le controlleur ça fonctionnait même si
> cela mettait un peu de temps à faire le job)  mais ça a l'air de bouger
> en ce moment sur le sujet avec une branche de test pour utiliser des
> thread plutôt que des forks, et l'intégration d'une partie du travail
> fait par l'équipe de Mitogen.
>
> Pour moi c'est l'outil dans sa catégorie (je mets kubernetes à part) qui
> fait le plus actuellement pour s'ouvrir aux autres besoins, et comme je
> suis sur FRNog je lance un troll... je le souligne de plus en plus les
> gens du réseau vont devoir arrêter de vouloir tout gérer à la main, et
> gérer de façon plus industrielle les configurations que ce soit au
> niveau LoadBalancer, Firewall, Switchs, Routeurs, outil de DDI...
>
> JYL
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>



-- 
Boukari Sabri

Cloud DevOps Specialist
*Failure is a Great Teacher*

www.boukari-sabri.org
www.finyx.fr
www.fean.fr

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

Re: [FRnOG] [TECH] Automation: Ansible et ses alternatives

[Sabri Boukari]

Oui, c'est bien ce que disais...
Sinon, Rundeck/Ansible est l'un des milliers d'autres options.

Si le besoin et d'avoir un orchestrateur je suggère Jenkins ou au pire des
cas bamboo pour une solution entreprise...

Mais pour le moment Jenkins et la meilleurs solution intra rumos

2018-08-14 16:30 GMT+02:00 Dominique Rousseau :

> Le Tue, Aug 14, 2018 at 04:17:09PM +0200, Sabri Boukari [
> sabriic...@gmail.com] a écrit:
> > https://everythingshouldbevirtual.com/automation/ansible-using-
> ansible-on-windows-via-cygwin/
>
> Ca, c'est pour utiliser Ansible sur le poste Windows, en utilisant du
> python dans cygwin
>
>
> --
> Dominique Rousseau
> Neuronnexion, Prestataire Internet & Intranet
> 6 rue des Hautes cornes - 8 Amiens
> tel: 03 22 71 61 90 - fax: 03 22 71 61 99 - http://www.neuronnexion.coop
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>



-- 
Boukari Sabri

Cloud DevOps Specialist
*Failure is a Great Teacher*

www.boukari-sabri.org
www.finyx.fr
www.fean.fr

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

Re: [FRnOG] [TECH] Automation: Ansible et ses alternatives

[Guillaume Barrot]

https://github.com/ansible/awx

1) c'est la version upstream de tower
2) c'est gratuit
3) l'API est gratuite aussi

et pour la partie réseau, ce doc est assez clair sur ce qu'il y a et qui
fonctionne (ou plutot sur ce qui ne fonctionne pas, malgré les dires des
fournisseurs).

https://docs.ansible.com/ansible/latest/network/user_guide/platform_index.html

Le mar. 14 août 2018 à 22:07, Jean-Yves LENHOF  a
écrit :

>
>
> Le 14/08/2018 à 15:53, Sabri Boukari a écrit :
> > Dernier petit détail...
> > Salt et plus efficace sur windows vs ansible...
> > pour ansible il y un backend a installé un espece de backdoor qui permet
> la
> > connexion et l'exécution des commandes shell sur windows.
> > comme cygwin
> >
> > Est Salt peut fonctionner en mode agent serveur et en mode standalone,
> d'ou
> > le principe * Master, slave dans salt stack.
> >
> > Ce n'est pas le cas pour ansible.
> > Un mode agent, serveur n'est pas aussi mauvais que ça donc tout dépend du
> > besoin et surtout de l'objectif à long terme.
> > Perso, je n'ai jamais étais convaincu des solus qui vive pendant 6 mois
> et
> > on les rejette aprés
>
> Hello,
>
> 6 mois tu y vas un peu fort
> Ansible existe depuis 2012 (Salt Slack existe depuis 2011 j'ai regardé)
> Perso depuis que j'ai essayé Ansible je ne peux plus m'en passer... et
> le fait que RedHat est mis du pognon pour racheter AnsibleWorks a ajouté
> pas mal de crédibilité à la solution (quelqu'un m'a dit que RedHat avait
> cherché à racheter Puppet il y a qq années, mais cela n'avait pas
> abouti comme chez AnsibleWorks il y avait plusieurs anciens de chez
> RedHat cela a du aider au rapprochement)
>
> Après il existe pas mal de solution alternatives (Puppet, Chef, Juju,
> Salt Slack, CfEngine, cdist, ), à toi de te faire ton idée...
>
> Pourquoi pour moi il est l'un des meilleurs outils :
> - Facilité d'utilisation
> - Communauté importante
> - RedHat
> - Pas mal de modules pour VMWARE, AWS, Azure, GCP
> - Des modules pour le réseau (Cisco, Cumulus, A10, F5, Aruba, DellOs,
> FortiOS, Netscaler, Infoblox)
>
> Le seul moin c'est la scalabilité et la rapidité avec pas mal de
> serveurs (mais j'ai fait tourné des choses sur 1000 serveurs et en
> ajoutant un peu de CPU et RAM sur le controlleur ça fonctionnait même si
> cela mettait un peu de temps à faire le job)  mais ça a l'air de bouger
> en ce moment sur le sujet avec une branche de test pour utiliser des
> thread plutôt que des forks, et l'intégration d'une partie du travail
> fait par l'équipe de Mitogen.
>
> Pour moi c'est l'outil dans sa catégorie (je mets kubernetes à part) qui
> fait le plus actuellement pour s'ouvrir aux autres besoins, et comme je
> suis sur FRNog je lance un troll... je le souligne de plus en plus les
> gens du réseau vont devoir arrêter de vouloir tout gérer à la main, et
> gérer de façon plus industrielle les configurations que ce soit au
> niveau LoadBalancer, Firewall, Switchs, Routeurs, outil de DDI...
>
> JYL
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>


-- 
Cordialement,

Guillaume BARROT

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

Re: [FRnOG] [TECH] Femtocell / Picocell pour les appels d'urgence en zone isolée ?

[Clément BRUGUERA / TSF IT]

Eh merde, je n'étais plus inscrit, ma réponse a été refusée... La voici, 
ci-dessous.


 Message d’origine 
De : "Clément BRUGUERA / TSF IT" 
Envoyé : 14 août 2018 23:21:42 GMT+02:00
À : Jean-Paul chiron , Toussaint OTTAVI 
, "frnog@frnog.org" 
Objet : Re: [FRnOG] [TECH] Femtocell / Picocell pour les appels d'urgence en 
zone isolée ?

Merci Jean-Paul pour ce gros spot de pub pour TSF :-D

Bon...

On va postuler que je connais assez bien la question.

Existe-t-il techniquement: Oui, dispo chez plusieurs fabricants et intégrateurs 
comme Range Networks (entreprise auteure d'OpenBTS), fairwaves (supportant la 
stack Osmocom mais nous on fait marcher aussi OpenBTS dessus), et enfin les 
solutions de yatebts.com. 
Ces solutions proposent des réseaux 2.5G à 4G.

Je ne parlerai pas de la solution Vodafone conçue et intégrée par TSF qui 
n'utilise pas du SDR et qui nécessite le raccordement à un coeur de réseau 
d'opérateur mobile, compatible qui plus est.

Les solutions susmentionnées sont bien opérateur agnostiques, car elles sont 
autonomes. C'est le principe du "All in the box". Elles sont raccordées soit à 
des BSC type osmoBSC/OpenBSC soit directement à des trunks SIP via un Asterisk 
ou FreeSwitch.
Il faut donc prévoir une connection IP avec débit garanti suffisant et des 
jitters et BER convenables.

Que dis la loi : Ben qu'il faut avoir une licence pour exploiter ces 
fréquences, et ces licences coûtent cher (en France mais également dans tous 
les autres pays du monde)... Des milliards !
Il n'y a pas d'exception. L'ANFR peut éventuellement officieusement donner son 
aval pour des tests très limités dans le temps et avec des puissances 
infinitésimales. 

En pratique... Ben... Je ne m'étendrai pas sur le sujet... Mais ça fonctionne 
très bien.

La solution que nous avons est basée sur du hardware SDR UmTRX de fairwaves 
(open hardware) et OpenBTS.
En l'absense de tout réseau, on préférera utiliser de la 2G en 900Mhz Selon la 
zone à couvrir, il faut prévoir une bonne antenne omnidirectionnelle, 
éventuellement un ampli (et le top serait d'avoir en plus un duplexer).

Voilà voilà.

Clément

-- 
Clément BRUGUERA
Head of ICT & Emergencies
Télécoms Sans Frontières

Le 14 août 2018 11:01:23 GMT+02:00, Jean-Paul chiron  
a écrit :
>Le 10/08/2018 à 09:30, Toussaint OTTAVI a écrit :
>> Bonjour,
>Bonjour,
>
>>
>> Un tragique accident survenu récemment dans une zone isolée me ramène
>> au premier plan une idée que j'ai dans la tête depuis longtemps :
>>
>> Existe t-il des solutions techniques de femtocell / picocell,
>> installables par une collectivité locale, qui soient
>> opérateur-agnostiques, et qui permettent d'acheminer uniquement les
>> appels d'urgence (15/18/112) dans une zone de montagne de quelques km
>> carrés, totalement isolée, hors de la zone de couverture des
>> opérateurs mobiles, et hors des plans d'amélioration de type "zone
>> blanche" ?
>C'est ce qu'a mis en œuvre TSF, il me semble :
>https://www.tsfi.org/fr/notre-expertise/instant-network-mini-fondation-vodafone
>
>
>>
>> Si cela n'existe pas en solution commerciale toute faite,
>> connaissez-vous des implémentations libres d'un tel projet, par
>> exemple sur une base OpenBTS ? Dans une telle hypothèse, qu'en dit la
>> réglementation actuelle ?
>En général TSF met ses développements sous licence libre, mais comme
>c'est en partenariat avec vodaphone, je ne sais pas...
>En copie clément qui répondra plus précisément.
>Et J'en profite pour rappeler qu'ils sont toujours à la recherche un
>dev  :
>https://seafile.tsfi.org/f/4a391aa11c/?raw=1
>
>Cordialement.

-- 
Clément BRUGUERA
Head of ICT & Emergencies
Télécoms Sans Frontières


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

Re: [FRnOG] [TECH] Automation: Ansible et ses alternatives

[Jean-Yves LENHOF]

Le 14/08/2018 à 15:53, Sabri Boukari a écrit :
> Dernier petit détail...
> Salt et plus efficace sur windows vs ansible...
> pour ansible il y un backend a installé un espece de backdoor qui permet la
> connexion et l'exécution des commandes shell sur windows.
> comme cygwin
>
> Est Salt peut fonctionner en mode agent serveur et en mode standalone, d'ou
> le principe * Master, slave dans salt stack.
>
> Ce n'est pas le cas pour ansible.
> Un mode agent, serveur n'est pas aussi mauvais que ça donc tout dépend du
> besoin et surtout de l'objectif à long terme.
> Perso, je n'ai jamais étais convaincu des solus qui vive pendant 6 mois et
> on les rejette aprés

Hello,

6 mois tu y vas un peu fort
Ansible existe depuis 2012 (Salt Slack existe depuis 2011 j'ai regardé)
Perso depuis que j'ai essayé Ansible je ne peux plus m'en passer... et
le fait que RedHat est mis du pognon pour racheter AnsibleWorks a ajouté
pas mal de crédibilité à la solution (quelqu'un m'a dit que RedHat avait
cherché à racheter Puppet il y a qq années, mais cela n'avait pas
abouti comme chez AnsibleWorks il y avait plusieurs anciens de chez
RedHat cela a du aider au rapprochement)

Après il existe pas mal de solution alternatives (Puppet, Chef, Juju,
Salt Slack, CfEngine, cdist, ), à toi de te faire ton idée...

Pourquoi pour moi il est l'un des meilleurs outils :
- Facilité d'utilisation
- Communauté importante
- RedHat
- Pas mal de modules pour VMWARE, AWS, Azure, GCP
- Des modules pour le réseau (Cisco, Cumulus, A10, F5, Aruba, DellOs,
FortiOS, Netscaler, Infoblox)

Le seul moin c'est la scalabilité et la rapidité avec pas mal de
serveurs (mais j'ai fait tourné des choses sur 1000 serveurs et en
ajoutant un peu de CPU et RAM sur le controlleur ça fonctionnait même si
cela mettait un peu de temps à faire le job)  mais ça a l'air de bouger
en ce moment sur le sujet avec une branche de test pour utiliser des
thread plutôt que des forks, et l'intégration d'une partie du travail
fait par l'équipe de Mitogen.

Pour moi c'est l'outil dans sa catégorie (je mets kubernetes à part) qui
fait le plus actuellement pour s'ouvrir aux autres besoins, et comme je
suis sur FRNog je lance un troll... je le souligne de plus en plus les
gens du réseau vont devoir arrêter de vouloir tout gérer à la main, et
gérer de façon plus industrielle les configurations que ce soit au
niveau LoadBalancer, Firewall, Switchs, Routeurs, outil de DDI...

JYL


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

RE: [FRnOG] [TECH] Cisco LACP avec Airfiber

[Sébastien 65]

@Hugo
As-tu désactivé le multicast filter sur les Airfiber pour monter correctement 
le LACP ?

@David
Oui j'ai vu, c'est un beau joujou, mais j'ai déjà le matériel donc il faut que 
je l'utilise ;)

De : David Ponzone 
Envoyé : mardi 14 août 2018 15:57:16
À : Sébastien 65
Cc : frnog-t...@frnog.org
Objet : Re: [FRnOG] [TECH] Cisco LACP avec Airfiber

Pourquoi tu t’emmerdes, y a ça:

https://www.ubnt.com/airfiber/airfiber-nxn/

David Ponzone



Le 14 août 2018 à 11:10, Sébastien 65 
mailto:sebastien...@live.fr>> a écrit :

Bonjour la liste,


Est-ce que parmi vous il y en a qui ont déjà monté un LACP Cisco avec 4 UBNT 
Airfiber ?


J'envisage sur un switch Cisco d'avoir deux Airfiber en master et à l'autre 
bout les slaves connectés sur un autre switch Cisco, (de manière aussi à 
pouvoir gérer une redondance du chemin si un couple de Airfiber tombe)...


Est-ce que selon vous cela fonctionnera ?


Bonne journée !

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

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

Re: [FRnOG] [TECH] Femtocell / Picocell pour les appels d'urgence en zone isolée ?

[Stéphane Rivière]

Dans l'armée, au moins, il y a un radio, qui est formé pour çà. Je 


Quand il est encore vivant, oui (ce sont les premières cibles avec les 
cadres)


suppose que dans la GN, il doit y avoir aussi des procédures. Mais chez 


Ils sont très bien organisés.

les pompiers, surtout parmi les volontaires, ce n'est pas le cas. Il 
faut donc que çà soit simple. Ils ont tous des iPhone, ils prennent des 
photos et ils les envoient en 3G. Ils ont un peu de mal à comprendre que 
leur réseau, pourtant censé constituer un "saut technologique", soit 
tellement dépassé, et marche "moins bien" que l'ancien système 
analogique...


Il faut relativiser, ce saut technologique date des années 80 et le 
déploiement GN achevé avant la fin du siècle dernier (en rubis V 1.0 non 
IP).


Ce qui est sûr, c'est que, quand la machine en vol appelle le CODIS, 
elle ne tombe pas forcément sur le CODIS du département. D'où, aux 
débuts, une certaine panique ;-) Depuis, il me semble que le trafic via 


OU, c'est chôô

relais est interdit en vol. J'ai décroché des radiocom pro il y a 10 


N'importe quoi... Donc ils sont en "direct mode", ce qu'ils appellent le 
canal tactique (non relayé)...


ans. Je ne suis donc plus très à la page. Je ne sais pas si c'est un 
réel problème de conception du réseau, ou si c'est juste un problème 


Etrange en effet.
Même remarque. Quand le Dragon est posé sur la DZ, je constate que 
l'équipage veille le réseau avec un portatif, car, je cite, "La radio de 
bord ne fonctionne pas quand l'inverter est coupé". J'en déduis que la 
radio est branchée via une alim 220V sur le réseau 220V du bord :-D Mais 
je ne suis pas allé démonter le tableau de bord pour vérifier ;-) Et 


Certainement du 110V 400 Hz plutôt... Je pensais qu'ils avaient des 
radios sur le réseau 28V CC...
n'a su à ce jour me fournir d'explication plausible... Du coup, la 
Sécurité Civile utilise... un abonnement chez FlightRadar24 pour 
connaître la position en temps réel de ses avions !


Je l'avais entendu celle là, j'y croyais à moitié, maintenant je 
comprend, merci :)


Cela ne me semble pas être une caractéristique Française ;-) En ce 
moment, je tâte du DMR ;-) L'ergonomie de cette chose est tout 
simplement abominable. Comme sur beaucoup de systèmes radio, 


Motorola, chinois de luxe (hytera) ou chinois de base ((bulk, no name, 
etc) ?

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



--
Stéphane Rivière
Ile d'Oléron - France


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

Re: [FRnOG] [TECH] Automation: Ansible et ses alternatives

[Étienne]

On 14/08/18 14:11, Fabien VINCENT (FrNOG) wrote:


Utilisez-vous autre chose ou si vous utilisez Ansible de quelle manière?
J'ai pu voir rapidement qu'il y avait Rudder et Puppet mais j'ai pas
l'impression qu'ils soient aussi puissants.

Merci beaucoup par avance pour vos retours la liste :)


Salt Stack ?

Ici, on utilise Salt et Napalm 
(https://github.com/napalm-automation/napalm-salt).


--
Étienne


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

RE: [FRnOG] [TECH] Onduleur rackable

[Xavier ROCA]

Pour reprendre mon premier post sur le sujet, un bypass externe comme évoqué
aussi par d'autres, c'est le mieux (en manuel).
Maintenance, changement onduleurs 
Ca peut aussi ce mettre en rack Din en 19 pouces :
https://www.thomann.de/fr/adam_hall_sicherungsautomaten_blende.htm?glp=1
id=CjwKCAjw-8nbBRBnEiwAqWt1zRAq2fcrWq92Gyhn9K-_Mz-ZNXfImnDUeTBzRl4fSQdGVxLpe
53WNxoCfK8QAvD_BwE

Et pour les inquiets, on peut mettre deux onduleurs en // sur le bypass
Pour les bricoleurs cela ne coute pas trop un bras (un peu quand même, le
prix des disj)

Le mieux c'est quand même un deuxième switch (mono ou double alim)
Les deux switch sur deux ATS différent s'ils sont mono alim avec deux
circuits d'alim différents.
Et pour un parano deux onduleurs en // sur chaque circuit avec deux GE
derrières.

Si quelqu'un veut le schéma du bypass manuel avec deux onduleurs, j'ai mis
ça :
https://we.tl/rzy0VFXVst

Xavier

-Message d'origine-
De : Michel Py  
Envoyé : vendredi 10 août 2018 23:18
À : Sébastien 65 ; Xavier Beaudouin ;
frnog 
Objet : RE: [FRnOG] [TECH] Onduleur rackable

 Michel Py a écrit :
 Si tu as l'espace, fait du 6509; d'occase çà coute presque rien non
plus.

>>> Xavier Beaudouin a écrit :
>>> Par contre en jus ça suce un max (idem pour les 6800)...

>> Hélas; faut pas être dans une colo qui te facture le jus 4 fois le prix
du marché.
> Ceci dit c'est 10 fois mieux qu'un stack; quand tu es dans ta propre salle
c'est increvable.

> Michel, c'est quoi les avantages que tu y trouve ? 

Ca plante jamais, tout est hot swap, MAJ logiciel pendant que çà tourne qui
marchent vraiment.
J'ai même changé les clocks du bus à chaud. Les seules fois ou j'ai du
rebooter c'est quand j'ai migré de CatOS à IOS ou quand j'ai remplacé mes
SUP2 par des SUP720.

C'est pas un chassis simple à maitriser mais quand tu le connais bien c'est
top; faut s'habituer à avoir plusieurs instances d'IOS (j'ai des chassis
avec 7; 2 SUP avec 2 IOS chacun et plusieurs cartes qui ont leur propre IOS
aussi); faut faire du lab.

Faut avoir la place et le courant; un 6509 çà prend 14 U; quand t'as enlevé
les 2 SUP il te reste que 7 slots. Les alims c'est 6000W et il y a des
cartes qui consomment plus de 500W.
Le bus fait que 80G par slot, donc avec les dernières cartes 16x 10G faut
oversubscribe 2x; faut pas essayer de mettre un térabit dessus.

Jamais vu un complètement en carafe. Les alims crament, les SUPs les
linecards et les bus aussi, mais jamais tout en même temps. J'ai des 6509 en
prod qui on été rebootés que 2 fois en 15 ans.

Michel.


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



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

Re: [FRnOG] [TECH] Automation: Ansible et ses alternatives

[Benjamin]

Bonjour Steeve,

Le couple Ansible / Rundeck répond à ton besoin.

Benjamin

> Le 14 août 2018 à 14:47, Steeve BEAUVAIS - Société Serinya Telecom 
>  a écrit :
> 
> Bonjour,
> 
> Je suis actuellement en train d'étudier Ansible afin d'automatiser
> certaines tâches sur plusieurs types de devices du genre Cisco (IOS et IOS
> XE) Huawei (Campus et CE), KVM et divers serveurs linux.
> 
> Je me suis penché au premier abord sur Ansible. Outils très puissant y'a
> pas à dire, mais le hic (car il y a toujours un hic) c'est l'API dispo sur
> la version tower qui coûte un voire 2 bras.
> Les autres fonctionnalités comme le dashboard etc ne m'intéressent pas,
> uniquement les playbooks et l'API
> 
> Utilisez-vous autre chose ou si vous utilisez Ansible de quelle manière?
> J'ai pu voir rapidement qu'il y avait Rudder et Puppet mais j'ai pas
> l'impression qu'ils soient aussi puissants.
> 
> Merci beaucoup par avance pour vos retours la liste :)
> 
> Cordialement,
> Steeve Beauvais
> 
> 
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

Re: [FRnOG] [TECH] Automation: Ansible et ses alternatives

[Dominique Rousseau]

Le Tue, Aug 14, 2018 at 04:17:09PM +0200, Sabri Boukari [sabriic...@gmail.com] 
a écrit:
> https://everythingshouldbevirtual.com/automation/ansible-using-ansible-on-windows-via-cygwin/

Ca, c'est pour utiliser Ansible sur le poste Windows, en utilisant du
python dans cygwin


-- 
Dominique Rousseau 
Neuronnexion, Prestataire Internet & Intranet
6 rue des Hautes cornes - 8 Amiens
tel: 03 22 71 61 90 - fax: 03 22 71 61 99 - http://www.neuronnexion.coop


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

Re: [FRnOG] [TECH] Automation: Ansible et ses alternatives

[Sabri Boukari]

https://everythingshouldbevirtual.com/automation/ansible-using-ansible-on-windows-via-cygwin/

2018-08-14 15:58 GMT+02:00 Dominique Rousseau :

> Le Tue, Aug 14, 2018 at 03:53:06PM +0200, Sabri Boukari [
> sabriic...@gmail.com] a écrit:
> > Dernier petit détail...
> > Salt et plus efficace sur windows vs ansible...
> > pour ansible il y un backend a installé un espece de backdoor qui permet
> la
> > connexion et l'exécution des commandes shell sur windows.
>
> Euh non, Ansible utilise Powershell pour executer des choses sur
> Windows.
>
>
> --
> Dominique Rousseau
> Neuronnexion, Prestataire Internet & Intranet
> 6 rue des Hautes cornes - 8 Amiens
> tel: 03 22 71 61 90 - fax: 03 22 71 61 99 - http://www.neuronnexion.coop
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>



-- 
Boukari Sabri

Cloud DevOps Specialist
*Failure is a Great Teacher*

www.boukari-sabri.org
www.finyx.fr
www.fean.fr

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

Re: [FRnOG] [TECH] Automation: Ansible et ses alternatives

[Dominique Rousseau]

Le Tue, Aug 14, 2018 at 03:53:06PM +0200, Sabri Boukari [sabriic...@gmail.com] 
a écrit:
> Dernier petit détail...
> Salt et plus efficace sur windows vs ansible...
> pour ansible il y un backend a installé un espece de backdoor qui permet la
> connexion et l'exécution des commandes shell sur windows.

Euh non, Ansible utilise Powershell pour executer des choses sur
Windows.


-- 
Dominique Rousseau 
Neuronnexion, Prestataire Internet & Intranet
6 rue des Hautes cornes - 8 Amiens
tel: 03 22 71 61 90 - fax: 03 22 71 61 99 - http://www.neuronnexion.coop


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

Re: [FRnOG] [TECH] Cisco LACP avec Airfiber

[David Ponzone]

Pourquoi tu t’emmerdes, y a ça:

https://www.ubnt.com/airfiber/airfiber-nxn/

David Ponzone



> Le 14 août 2018 à 11:10, Sébastien 65  a écrit :
> 
> Bonjour la liste,
> 
> 
> Est-ce que parmi vous il y en a qui ont déjà monté un LACP Cisco avec 4 UBNT 
> Airfiber ?
> 
> 
> J'envisage sur un switch Cisco d'avoir deux Airfiber en master et à l'autre 
> bout les slaves connectés sur un autre switch Cisco, (de manière aussi à 
> pouvoir gérer une redondance du chemin si un couple de Airfiber tombe)...
> 
> 
> Est-ce que selon vous cela fonctionnera ?
> 
> 
> Bonne journée !
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/

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

Re: [FRnOG] [TECH] Automation: Ansible et ses alternatives

[Sabri Boukari]

Dernier petit détail...
Salt et plus efficace sur windows vs ansible...
pour ansible il y un backend a installé un espece de backdoor qui permet la
connexion et l'exécution des commandes shell sur windows.
comme cygwin

Est Salt peut fonctionner en mode agent serveur et en mode standalone, d'ou
le principe * Master, slave dans salt stack.

Ce n'est pas le cas pour ansible.
Un mode agent, serveur n'est pas aussi mauvais que ça donc tout dépend du
besoin et surtout de l'objectif à long terme.
Perso, je n'ai jamais étais convaincu des solus qui vive pendant 6 mois et
on les rejette aprés

2018-08-14 15:49 GMT+02:00 Sabri Boukari :

> tu n'aura besoin de python que sur une machine qui exécute ansible, du
> moment ou tu lance une commande a distance c'est comme si tu fait:
>
> ssh user@name " echo 'hello world!' "
>
> ansible doit être installé sur la machine hote et donc besoin de toutes la
> stack python et toutes les framework que tu aurait besoin... Certes, tout
> les équipement ne sont pas compatible ansible ou il faut développer ton
> propre script python pour les atteindre.
> D'ou l'existence de Galaxy
>
> 2018-08-14 15:32 GMT+02:00 FurryJulie :
>
>> Attention aussi, sur certaines séries de Cisco Nexus (j'ai des 3k en 6.0
>> …) qui n'ont pas d'API REST, la plupart des modules nx-os d'Ansible ne sont
>> pas compatibles. Je ne sait pas ce qu'il en est de Salt mais avec Ansible
>> ça demande de faire de la gymnastique assez pénibles dans les rôles …
>> Bref à savoir.
>>
>>
>> On 8/14/18 3:21 PM, err...@free.fr wrote:
>>
>> On 08/14/2018 03:15 PM, Dominique Rousseau wrote:
>> > Le Tue, Aug 14, 2018 at 03:07:41PM +0200, Sabri Boukari [
>> sabriic...@gmail.com] a écrit:
>> > [...]
>> >> Sinon, Salt fonctionne de la méme façon que ansible avec les méme
>> >> caractéristiques et utilise aussi du ssh et le meme framework python
>> *Boto.
>> >> Peut-être méme que salt est beaucoup plus múr et performant sur la
>> partie
>> >> Python et templating Jinja.
>> >>
>> >> Dans salt il y a 5 composant différent et l'architecture et
>> différente, il
>> >> n'est pas fait non plus s'intégrer avec des appliance genre cisco ou
>> huwei,
>> >> juniper ou autre mais uniquement pour des serveurs qui sont un peut
>> plus
>> >> intelligent.
>>
>> > Il y a une difference fondamentale entre SaltStack et Ansible, c'est
>> > qu'Ansible ne necessite pas d'agent installe.
>> > (ce qui a permis de l'etendre aux equipements reseaux qui permettent un
>> > acces SSH)
>>
>>
>>
>> certes, ansible n'a pas besoin d'agent (il parait que salt stack non
>> plus).
>> mais dans tous les cas il faut python installé sur l'équipement, et
>> certains petits routeurs sont trop petits (en place disponible) pour python.
>>
>>
>>
>> > > > --- > Liste de diffusion du FRnOG >
>> http://www.frnog.org/
>>
>
>
>
> --
> Boukari Sabri
>
> Cloud DevOps Specialist
> *Failure is a Great Teacher*
>
> www.boukari-sabri.org
> www.finyx.fr
> www.fean.fr
>



-- 
Boukari Sabri

Cloud DevOps Specialist
*Failure is a Great Teacher*

www.boukari-sabri.org
www.finyx.fr
www.fean.fr

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

Re: [FRnOG] [TECH] Automation: Ansible et ses alternatives

[Sabri Boukari]

tu n'aura besoin de python que sur une machine qui exécute ansible, du
moment ou tu lance une commande a distance c'est comme si tu fait:

ssh user@name " echo 'hello world!' "

ansible doit être installé sur la machine hote et donc besoin de toutes la
stack python et toutes les framework que tu aurait besoin... Certes, tout
les équipement ne sont pas compatible ansible ou il faut développer ton
propre script python pour les atteindre.
D'ou l'existence de Galaxy

2018-08-14 15:32 GMT+02:00 FurryJulie :

> Attention aussi, sur certaines séries de Cisco Nexus (j'ai des 3k en 6.0
> …) qui n'ont pas d'API REST, la plupart des modules nx-os d'Ansible ne sont
> pas compatibles. Je ne sait pas ce qu'il en est de Salt mais avec Ansible
> ça demande de faire de la gymnastique assez pénibles dans les rôles …
> Bref à savoir.
>
>
> On 8/14/18 3:21 PM, err...@free.fr wrote:
>
> On 08/14/2018 03:15 PM, Dominique Rousseau wrote:
> > Le Tue, Aug 14, 2018 at 03:07:41PM +0200, Sabri Boukari [
> sabriic...@gmail.com] a écrit:
> > [...]
> >> Sinon, Salt fonctionne de la méme façon que ansible avec les méme
> >> caractéristiques et utilise aussi du ssh et le meme framework python
> *Boto.
> >> Peut-être méme que salt est beaucoup plus múr et performant sur la
> partie
> >> Python et templating Jinja.
> >>
> >> Dans salt il y a 5 composant différent et l'architecture et différente,
> il
> >> n'est pas fait non plus s'intégrer avec des appliance genre cisco ou
> huwei,
> >> juniper ou autre mais uniquement pour des serveurs qui sont un peut plus
> >> intelligent.
>
> > Il y a une difference fondamentale entre SaltStack et Ansible, c'est
> > qu'Ansible ne necessite pas d'agent installe.
> > (ce qui a permis de l'etendre aux equipements reseaux qui permettent un
> > acces SSH)
>
>
>
> certes, ansible n'a pas besoin d'agent (il parait que salt stack non plus).
> mais dans tous les cas il faut python installé sur l'équipement, et
> certains petits routeurs sont trop petits (en place disponible) pour python.
>
>
>
> > > > --- > Liste de diffusion du FRnOG >
> http://www.frnog.org/
>



-- 
Boukari Sabri

Cloud DevOps Specialist
*Failure is a Great Teacher*

www.boukari-sabri.org
www.finyx.fr
www.fean.fr

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

Re: [FRnOG] [TECH] Femtocell / Picocell pour les appels d'urgence en zone isolée ?

[Toussaint OTTAVI]

Le 14/08/2018 à 12:00, Stéphane Rivière a écrit :
 (j'imagine parfaitement le radio qui vient juste de perdre sa synchro 
en HF et qui doit passer un message dans les 10 secondes).


Dans l'armée, au moins, il y a un radio, qui est formé pour çà. Je 
suppose que dans la GN, il doit y avoir aussi des procédures. Mais chez 
les pompiers, surtout parmi les volontaires, ce n'est pas le cas. Il 
faut donc que çà soit simple. Ils ont tous des iPhone, ils prennent des 
photos et ils les envoient en 3G. Ils ont un peu de mal à comprendre que 
leur réseau, pourtant censé constituer un "saut technologique", soit 
tellement dépassé, et marche "moins bien" que l'ancien système analogique...


? Normalement, chaque relais (ou point d'accès) Antarès à une ID 
numérique... Après qu'en l'air ça soit un 'mess' radio de 'n' balises 
de relais Antarès entendues simulnatément, compte tenu que Tetrapol a 
un nombre très limité de canaux, ça je ne suis pas dans le secret des 
dieux, mais c'est une possibilité...


Ce qui est sûr, c'est que, quand la machine en vol appelle le CODIS, 
elle ne tombe pas forcément sur le CODIS du département. D'où, aux 
débuts, une certaine panique ;-) Depuis, il me semble que le trafic via 
relais est interdit en vol. J'ai décroché des radiocom pro il y a 10 
ans. Je ne suis donc plus très à la page. Je ne sais pas si c'est un 
réel problème de conception du réseau, ou si c'est juste un problème 
d'interface chaise-clavier chez les mecs qui programment les appareils, 
ou chez ceux qui les utilisent ;-)



? pas connectée dès que tu mets le 28 V ?


Même remarque. Quand le Dragon est posé sur la DZ, je constate que 
l'équipage veille le réseau avec un portatif, car, je cite, "La radio de 
bord ne fonctionne pas quand l'inverter est coupé". J'en déduis que la 
radio est branchée via une alim 220V sur le réseau 220V du bord :-D Mais 
je ne suis pas allé démonter le tableau de bord pour vérifier ;-) Et 
comme çà ne passe pas en direct avec les portatifs, c'est le mode 
débrouille : GSM quand çà passe, sinon ils treuillent les secouristes, 
viennent se poser sur la DZ la plus proche, et attendent le temps 
convenu avant de redécoller pour chercher les secouristes... Ou, des 
fois, ils font des boucles pendant des quarts d'heure entiers, en 
bouffant un potentiel kéro astronomique. Juste parce qu'ils n'ont pas de 
bonnes communications...




un Pélican n'a pas d'Antarès car les postes ne sont pas homologués 
pour l'aéronautique...), 


Alors que ces postes sont fabriqués par Airbus (ex EADS defense)...


Et que ce sont des aéronefs militaires, donc à priori avec certaines 
libertés par rapport à l'Aviation Civile ;-) Je n'ai pas compris 
pourquoi les Dragon ont des radios Antarès et pas les Pélican. Personne 
n'a su à ce jour me fournir d'explication plausible... Du coup, la 
Sécurité Civile utilise... un abonnement chez FlightRadar24 pour 
connaître la position en temps réel de ses avions !


Les interfaces radio Thalès ou Tetrapol manquent de simplicité, les 
réseaux ne sont pas homogènes, on est en france quoi. La seule 
consolation (si l'on peut dire) c'est que les systèmes étrangers ne 
sont pas nécessairement plus simples, voire pires (au moins pour les 
matériels milis).


Cela ne me semble pas être une caractéristique Française ;-) En ce 
moment, je tâte du DMR ;-) L'ergonomie de cette chose est tout 
simplement abominable. Comme sur beaucoup de systèmes radio, 
d'ailleurs... Il y a quasiment 20 ans de retard en matière d'IHM et 
d'intégration avec l'informatique. Même mon premier téléphone mobile (un 
Nokia 6110, pour préciser l'époque) avait un système de menus plus clair 
et ergonomique ! Je n'arrive pas à comprendre comment des systèmes 
conçus et vendus aujourd'hui puissent avoir de telles interfaces de 
chiottes. Alors qu'il n'y a rien à inventer, çà existe déjà ;-)




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

Re: [FRnOG] [TECH] Automation: Ansible et ses alternatives

[FurryJulie]

Attention aussi, sur certaines séries de Cisco Nexus (j'ai des 3k en 6.0
…) qui n'ont pas d'API REST, la plupart des modules nx-os d'Ansible ne
sont pas compatibles. Je ne sait pas ce qu'il en est de Salt mais avec
Ansible ça demande de faire de la gymnastique assez pénibles dans les
rôles …
Bref à savoir.


On 8/14/18 3:21 PM, err...@free.fr wrote:
> On 08/14/2018 03:15 PM, Dominique Rousseau wrote:
> > Le Tue, Aug 14, 2018 at 03:07:41PM +0200, Sabri Boukari
> [sabriic...@gmail.com] a écrit:
> > [...]
> >> Sinon, Salt fonctionne de la méme façon que ansible avec les méme
> >> caractéristiques et utilise aussi du ssh et le meme framework
> python *Boto.
> >> Peut-être méme que salt est beaucoup plus múr et performant sur la
> partie
> >> Python et templating Jinja.
> >>
> >> Dans salt il y a 5 composant différent et l'architecture et
> différente, il
> >> n'est pas fait non plus s'intégrer avec des appliance genre cisco
> ou huwei,
> >> juniper ou autre mais uniquement pour des serveurs qui sont un peut
> plus
> >> intelligent.
>
> > Il y a une difference fondamentale entre SaltStack et Ansible, c'est
> > qu'Ansible ne necessite pas d'agent installe.
> > (ce qui a permis de l'etendre aux equipements reseaux qui permettent un
> > acces SSH)
>
>
>
> certes, ansible n'a pas besoin d'agent (il parait que salt stack non
> plus).
> mais dans tous les cas il faut python installé sur l'équipement, et
> certains petits routeurs sont trop petits (en place disponible) pour
> python.
>
>
>
> > > --- > Liste de diffusion du FRnOG >
http://www.frnog.org/


0x3690D22691BB79E1.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

Re: [FRnOG] [TECH] Automation: Ansible et ses alternatives

[Steeve BEAUVAIS - Société Serinya Telecom]

Les tests que j'ai fait pour le moment ne m'ont pas montré la nécessité
d'avoir python installé sur les machines distantes.
J'ai fait des tests avec les modules ios_command et ios_config sur un cisco
888E et y'a pas de python sur ces bébêtes ^^

Cordialement,

[image:
http://www.serinyatelecom.fr/signatures/signature-steeve-beauvais-serinya-telecom.jpg]





Le mar. 14 août 2018 à 15:22,  a écrit :

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> On 08/14/2018 03:15 PM, Dominique Rousseau wrote:
> > Le Tue, Aug 14, 2018 at 03:07:41PM +0200, Sabri Boukari [
> sabriic...@gmail.com] a écrit:
> > [...]
> >> Sinon, Salt fonctionne de la méme façon que ansible avec les méme
> >> caractéristiques et utilise aussi du ssh et le meme framework python
> *Boto.
> >> Peut-être méme que salt est beaucoup plus múr et performant sur la
> partie
> >> Python et templating Jinja.
> >>
> >> Dans salt il y a 5 composant différent et l'architecture et différente,
> il
> >> n'est pas fait non plus s'intégrer avec des appliance genre cisco ou
> huwei,
> >> juniper ou autre mais uniquement pour des serveurs qui sont un peut plus
> >> intelligent.
> >
> > Il y a une difference fondamentale entre SaltStack et Ansible, c'est
> > qu'Ansible ne necessite pas d'agent installe.
> > (ce qui a permis de l'etendre aux equipements reseaux qui permettent un
> > acces SSH)
> >
> >
>
> certes, ansible n'a pas besoin d'agent (il parait que salt stack non plus).
> mais dans tous les cas il faut python installé sur l'équipement, et
> certains petits routeurs sont trop petits (en place disponible) pour python.
>
>
>
> -BEGIN PGP SIGNATURE-
>
> iQIzBAEBCgAdFiEEMXISaGZmF7NpMTZj6OuMS89alfsFAlty11AACgkQ6OuMS89a
> lfvcDg//Tg7X5Oh/8itbkJTKFlfUThvJHXe1lmMtrcSwpo1ct3NOzsgT2xamvbUO
> k61mRGsZwKFC1Mrxy7/B/o5SYJmaXfUetozX/xg6Alhvr2XqTHjWe81LfYlgSx14
> 3R3dP0tiF69MenUx1FG5mA2/Sp0zuB32fmDhrWKwCBMXe46b5qPG5mdDGtdXoubL
> 1CzSsFqtto9DYmiuShlUddVgXSowqLANWKhPTZHaxmULdcuKKCmigH4JBZqu0buf
> u84zo/bloRRBtePrYuLdGZ74rEihjenrFXNpZcc4dGJDIYsTf6AU92xJQy71ATch
> BcOskO24YS6bI8sF1nckGhM89m0i/abfKJ0lHLLG+OxfERiNa/Qjr751mZZLwTlR
> /2MkeNjsa2DgpD7uykW145k+m3NFmnjzd2FajKEAdmWo28rnWzBW5ol833dbusoM
> 2WKdZYZOOMwQOPdYi/XcSYeI7aNRT5txY48DzMiKqzSvoXEtqG7/jTu++9iWYP05
> N6G+Iwv1IYJzo6bQaN/UZ/qLp/Si/wBaMJas/3sTErr3exSHQqnu/v/4m3GQo9kc
> Ef4pJ3mEXdWOgkVEeF/z05T2nkxiOjHcNXHee1UIHOtyI7mpsDd0lZp6Ft6U/E5g
> WojZ3x2bK+KMLqu5pkqY5viiacjOlmsqgTvyJjpIPYu7hyUBis4=
> =6h3C
> -END PGP SIGNATURE-
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

Re: [FRnOG] [TECH] Automation: Ansible et ses alternatives

[err404]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 08/14/2018 03:15 PM, Dominique Rousseau wrote:
> Le Tue, Aug 14, 2018 at 03:07:41PM +0200, Sabri Boukari 
> [sabriic...@gmail.com] a écrit:
> [...]
>> Sinon, Salt fonctionne de la méme façon que ansible avec les méme
>> caractéristiques et utilise aussi du ssh et le meme framework python *Boto.
>> Peut-être méme que salt est beaucoup plus múr et performant sur la partie
>> Python et templating Jinja.
>>
>> Dans salt il y a 5 composant différent et l'architecture et différente, il
>> n'est pas fait non plus s'intégrer avec des appliance genre cisco ou huwei,
>> juniper ou autre mais uniquement pour des serveurs qui sont un peut plus
>> intelligent.
> 
> Il y a une difference fondamentale entre SaltStack et Ansible, c'est
> qu'Ansible ne necessite pas d'agent installe.
> (ce qui a permis de l'etendre aux equipements reseaux qui permettent un
> acces SSH)
> 
> 

certes, ansible n'a pas besoin d'agent (il parait que salt stack non plus).
mais dans tous les cas il faut python installé sur l'équipement, et certains 
petits routeurs sont trop petits (en place disponible) pour python.



-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEMXISaGZmF7NpMTZj6OuMS89alfsFAlty11AACgkQ6OuMS89a
lfvcDg//Tg7X5Oh/8itbkJTKFlfUThvJHXe1lmMtrcSwpo1ct3NOzsgT2xamvbUO
k61mRGsZwKFC1Mrxy7/B/o5SYJmaXfUetozX/xg6Alhvr2XqTHjWe81LfYlgSx14
3R3dP0tiF69MenUx1FG5mA2/Sp0zuB32fmDhrWKwCBMXe46b5qPG5mdDGtdXoubL
1CzSsFqtto9DYmiuShlUddVgXSowqLANWKhPTZHaxmULdcuKKCmigH4JBZqu0buf
u84zo/bloRRBtePrYuLdGZ74rEihjenrFXNpZcc4dGJDIYsTf6AU92xJQy71ATch
BcOskO24YS6bI8sF1nckGhM89m0i/abfKJ0lHLLG+OxfERiNa/Qjr751mZZLwTlR
/2MkeNjsa2DgpD7uykW145k+m3NFmnjzd2FajKEAdmWo28rnWzBW5ol833dbusoM
2WKdZYZOOMwQOPdYi/XcSYeI7aNRT5txY48DzMiKqzSvoXEtqG7/jTu++9iWYP05
N6G+Iwv1IYJzo6bQaN/UZ/qLp/Si/wBaMJas/3sTErr3exSHQqnu/v/4m3GQo9kc
Ef4pJ3mEXdWOgkVEeF/z05T2nkxiOjHcNXHee1UIHOtyI7mpsDd0lZp6Ft6U/E5g
WojZ3x2bK+KMLqu5pkqY5viiacjOlmsqgTvyJjpIPYu7hyUBis4=
=6h3C
-END PGP SIGNATURE-


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

Re: [FRnOG] [TECH] Automation: Ansible et ses alternatives

[Dominique Rousseau]

Le Tue, Aug 14, 2018 at 03:07:41PM +0200, Sabri Boukari [sabriic...@gmail.com] 
a écrit:
[...]
> Sinon, Salt fonctionne de la méme façon que ansible avec les méme
> caractéristiques et utilise aussi du ssh et le meme framework python *Boto.
> Peut-être méme que salt est beaucoup plus múr et performant sur la partie
> Python et templating Jinja.
> 
> Dans salt il y a 5 composant différent et l'architecture et différente, il
> n'est pas fait non plus s'intégrer avec des appliance genre cisco ou huwei,
> juniper ou autre mais uniquement pour des serveurs qui sont un peut plus
> intelligent.

Il y a une difference fondamentale entre SaltStack et Ansible, c'est
qu'Ansible ne necessite pas d'agent installe.
(ce qui a permis de l'etendre aux equipements reseaux qui permettent un
acces SSH)


-- 
Dominique Rousseau 
Neuronnexion, Prestataire Internet & Intranet
6 rue des Hautes cornes - 8 Amiens
tel: 03 22 71 61 90 - fax: 03 22 71 61 99 - http://www.neuronnexion.coop


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

Re: [FRnOG] [TECH] Automation: Ansible et ses alternatives

[Sabri Boukari]

Ouim vous pouvez jeter un coup d'oeil sur salt.

et voici l'equivalent à galaxy mais en mode officiel chez salt:
https://docs.saltstack.com/en/latest/topics/development/conventions/formulas.html

c'est free aussi

2018-08-14 15:11 GMT+02:00 Fabien VINCENT (FrNOG) :

> Le 2018-08-14 14:47, Steeve BEAUVAIS - Société Serinya Telecom a écrit :
>
> > Bonjour,
> >
> > Je suis actuellement en train d'étudier Ansible afin d'automatiser
> > certaines tâches sur plusieurs types de devices du genre Cisco (IOS et
> IOS
> > XE) Huawei (Campus et CE), KVM et divers serveurs linux.
> >
> > Je me suis penché au premier abord sur Ansible. Outils très puissant y'a
> > pas à dire, mais le hic (car il y a toujours un hic) c'est l'API dispo
> sur
> > la version tower qui coûte un voire 2 bras.
> > Les autres fonctionnalités comme le dashboard etc ne m'intéressent pas,
> > uniquement les playbooks et l'API
> >
> > Utilisez-vous autre chose ou si vous utilisez Ansible de quelle manière?
> > J'ai pu voir rapidement qu'il y avait Rudder et Puppet mais j'ai pas
> > l'impression qu'ils soient aussi puissants.
> >
> > Merci beaucoup par avance pour vos retours la liste :)
> >
> > Cordialement,
> > Steeve Beauvais
> >
> > 
> >
> > ---
> > Liste de diffusion du FRnOG
> > http://www.frnog.org/
>
> Salt Stack ?
>
> --
> FABIEN VINCENT
> _@beufanet_
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>



-- 
Boukari Sabri

Cloud DevOps Specialist
*Failure is a Great Teacher*

www.boukari-sabri.org
www.finyx.fr
www.fean.fr

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

Re: [FRnOG] [TECH] Automation: Ansible et ses alternatives

[Fabien VINCENT (FrNOG)]

Le 2018-08-14 14:47, Steeve BEAUVAIS - Société Serinya Telecom a écrit :

> Bonjour,
> 
> Je suis actuellement en train d'étudier Ansible afin d'automatiser
> certaines tâches sur plusieurs types de devices du genre Cisco (IOS et IOS
> XE) Huawei (Campus et CE), KVM et divers serveurs linux.
> 
> Je me suis penché au premier abord sur Ansible. Outils très puissant y'a
> pas à dire, mais le hic (car il y a toujours un hic) c'est l'API dispo sur
> la version tower qui coûte un voire 2 bras.
> Les autres fonctionnalités comme le dashboard etc ne m'intéressent pas,
> uniquement les playbooks et l'API
> 
> Utilisez-vous autre chose ou si vous utilisez Ansible de quelle manière?
> J'ai pu voir rapidement qu'il y avait Rudder et Puppet mais j'ai pas
> l'impression qu'ils soient aussi puissants.
> 
> Merci beaucoup par avance pour vos retours la liste :)
> 
> Cordialement,
> Steeve Beauvais
> 
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/

Salt Stack ?

-- 
FABIEN VINCENT 
_@beufanet_
---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Automation: Ansible et ses alternatives

[Sabri Boukari]

Bonjour,
L'avantage de ansible c'est sont fonctionnement.
Methode SSH, le ansible Galaxy pour la partie playbook et les appliance.

Sinon, il y a semaphore je pense et awx qui sont équivalent à Tower en mode
openSource et Tower lui même est gratuit openSource.
Mais je ne connais pas vraiment la limite, si c'est juste le support qui
est payant.

Sinon, Salt fonctionne de la méme façon que ansible avec les méme
caractéristiques et utilise aussi du ssh et le meme framework python *Boto.
Peut-être méme que salt est beaucoup plus múr et performant sur la partie
Python et templating Jinja.

Dans salt il y a 5 composant différent et l'architecture et différente, il
n'est pas fait non plus s'intégrer avec des appliance genre cisco ou huwei,
juniper ou autre mais uniquement pour des serveurs qui sont un peut plus
intelligent.

Donc, si votre choix se pose sur le support des appliances. Pour le moment
aucun concurrent ầ Ansible, si pour l'exploitation de l'API vous n'avez pas
besoin de Tower, Awx ou semaphore non plus.

Bonne chance,

2018-08-14 14:47 GMT+02:00 Steeve BEAUVAIS - Société Serinya Telecom <
steeve.beauv...@serinyatelecom.fr>:

> Bonjour,
>
> Je suis actuellement en train d'étudier Ansible afin d'automatiser
> certaines tâches sur plusieurs types de devices du genre Cisco (IOS et IOS
> XE) Huawei (Campus et CE), KVM et divers serveurs linux.
>
> Je me suis penché au premier abord sur Ansible. Outils très puissant y'a
> pas à dire, mais le hic (car il y a toujours un hic) c'est l'API dispo sur
> la version tower qui coûte un voire 2 bras.
> Les autres fonctionnalités comme le dashboard etc ne m'intéressent pas,
> uniquement les playbooks et l'API
>
> Utilisez-vous autre chose ou si vous utilisez Ansible de quelle manière?
> J'ai pu voir rapidement qu'il y avait Rudder et Puppet mais j'ai pas
> l'impression qu'ils soient aussi puissants.
>
> Merci beaucoup par avance pour vos retours la liste :)
>
> Cordialement,
> Steeve Beauvais
>
>
> 
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>



-- 
Boukari Sabri

Cloud DevOps Specialist
*Failure is a Great Teacher*

www.boukari-sabri.org
www.finyx.fr
www.fean.fr

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

[FRnOG] [TECH] Automation: Ansible et ses alternatives

[Steeve BEAUVAIS - Société Serinya Telecom]

Bonjour,

Je suis actuellement en train d'étudier Ansible afin d'automatiser
certaines tâches sur plusieurs types de devices du genre Cisco (IOS et IOS
XE) Huawei (Campus et CE), KVM et divers serveurs linux.

Je me suis penché au premier abord sur Ansible. Outils très puissant y'a
pas à dire, mais le hic (car il y a toujours un hic) c'est l'API dispo sur
la version tower qui coûte un voire 2 bras.
Les autres fonctionnalités comme le dashboard etc ne m'intéressent pas,
uniquement les playbooks et l'API

Utilisez-vous autre chose ou si vous utilisez Ansible de quelle manière?
J'ai pu voir rapidement qu'il y avait Rudder et Puppet mais j'ai pas
l'impression qu'ils soient aussi puissants.

Merci beaucoup par avance pour vos retours la liste :)

Cordialement,
Steeve Beauvais




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

Re: [FRnOG] [TECH] Cisco LACP avec Airfiber

[Hugo - Flemnet]

Hello,

Avec des switchs HP, un couple de AirFiber et un couple d'équipements laser 
sonabeam, ça fonctionne depuis plusieurs années chez nous, en LACP évidement.

A priori pas de difficulté technique particulière qui ferait que ça 
fonctionnerait pas !

Hugo

> On 14 Aug 2018, at 12:10, Sébastien 65  wrote:
> 
> Bonjour la liste,
> 
> 
> Est-ce que parmi vous il y en a qui ont déjà monté un LACP Cisco avec 4 UBNT 
> Airfiber ?
> 
> 
> J'envisage sur un switch Cisco d'avoir deux Airfiber en master et à l'autre 
> bout les slaves connectés sur un autre switch Cisco, (de manière aussi à 
> pouvoir gérer une redondance du chemin si un couple de Airfiber tombe)...
> 
> 
> Est-ce que selon vous cela fonctionnera ?
> 
> 
> Bonne journée !
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

[FRnOG] [TECH] Cisco LACP avec Airfiber

[Sébastien 65]

Bonjour la liste,


Est-ce que parmi vous il y en a qui ont déjà monté un LACP Cisco avec 4 UBNT 
Airfiber ?


J'envisage sur un switch Cisco d'avoir deux Airfiber en master et à l'autre 
bout les slaves connectés sur un autre switch Cisco, (de manière aussi à 
pouvoir gérer une redondance du chemin si un couple de Airfiber tombe)...


Est-ce que selon vous cela fonctionnera ?


Bonne journée !

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

Re: [FRnOG] [TECH] Femtocell / Picocell pour les appels d'urgence en zone isolée ?

[Stéphane Rivière]

La question n'est pas de savoir s'ils ont ladite passerelle, mais si les 
gens arrivent à s'en servir facilement en conditions opérationnelles. Un 
officier qui arrive sur zone doit pouvoir contacter immédiatement tous 
ses moyens de secours engagés. Pareil pour un nouvel engin ou un hélico 
qui arrive sur zone et qui doit pouvoir contacter le COS. Juste en 
appuyant sur un bouton. Sans avoir besoin d'un diplôme d'ingénieur 
télécom. 


Très juste.

Dans un autre registre, je me marre (ou pas) quand je me rappelle (c'est 
pas nouveau, mais bientôt 30 ans) les procédures radio pour les postes à 
saut de fréquences milis en HF ou VHF (j'imagine parfaitement le radio 
qui vient juste de perdre sa synchro en HF et qui doit passer un message 
dans les 10 secondes).


(un hélico en vol ne peut pas utiliser les relais Antarès, car il déclenche les relais de l'autre coté 
de la Méditerranée; 


? Normalement, chaque relais (ou point d'accès) Antarès à une ID 
numérique... Après qu'en l'air ça soit un 'mess' radio de 'n' balises de 
relais Antarès entendues simulnatément, compte tenu que Tetrapol a un 
nombre très limité de canaux, ça je ne suis pas dans le secret des 
dieux, mais c'est une possibilité...


un hélico au sol ne peut pas utiliser la radio de 
bord car elle est connectée au réseau "inverter", qui n'est alimenté que 
lorsque les turbines tournent; 


? pas connectée dès que tu mets le 28 V ?

un Pélican n'a pas d'Antarès car les postes ne sont pas homologués pour l'aéronautique...), 


Alors que ces postes sont fabriqués par Airbus (ex EADS defense)...

Tout çà, c'est autant d'efficacité en moins pour le secours proprement 

.../...

moins avec ceux des hauts fonctionnaires de l'Etat qui les valident...


Je plussoie ta conclusion.

Les interfaces radio Thalès ou Tetrapol manquent de simplicité, les 
réseaux ne sont pas homogènes, on est en france quoi. La seule 
consolation (si l'on peut dire) c'est que les systèmes étrangers ne sont 
pas nécessairement plus simples, voire pires (au moins pour les 
matériels milis).


--
Stéphane Rivière
Ile d'Oléron - France


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

Re: [FRnOG] [TECH] Femtocell / Picocell pour les appels d'urgence en zone isolée ?

[Toussaint OTTAVI]

Le 14/08/2018 à 11:01, Jean-Paul chiron a écrit :

C'est ce qu'a mis en œuvre TSF, il me semble :
https://www.tsfi.org/fr/notre-expertise/instant-network-mini-fondation-vodafone


Merci, je vais regarder


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

Re: [FRnOG] [TECH] Femtocell / Picocell : solutions commerciales existantes ?

[Toussaint OTTAVI]

Le 14/08/2018 à 11:16, Richard Klein a écrit :
Les solutions operateurs de ce type coûte un bras et je pense que pour 
un budget d'une zone picocell opérateur le projets openbts de quelques 
watts et quelques openbts avec des faisceaux hertzien inter openbts te 
coûtera juste une main!


Je suis d'accord. Mais ce n'est pas mon bras ;-) Une solution opérateur 
possède un avantage sur OpenBTS : elle est légale. Ce qui, pour une 
collectivité, peut avoir son importance ;-)


J'aimerais avoir quelques exemples de solutions commerciales "picocell", 
ainsi que, si possible, des exemples d'implémentation.


Merci d'avance.


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

Re: [FRnOG] [TECH] Femtocell / Picocell : solutions commerciales existantes ?

[Richard Klein]

Les solutions operateurs de ce type coûte un bras et je pense que pour un
budget d'une zone picocell opérateur le projets openbts de quelques watts
et quelques openbts avec des faisceaux hertzien inter openbts te coûtera
juste une main!

Le mar. 14 août 2018 à 10:29, Toussaint OTTAVI  a
écrit :

>
> Le 10/08/2018 à 09:30, Toussaint OTTAVI a écrit :
> > Existe t-il des solutions techniques de femtocell / picocell,
> > installables par une collectivité locale, qui soient
> > opérateur-agnostiques, et qui permettent d'acheminer uniquement les
> > appels d'urgence (15/18/112) dans une zone de montagne de quelques km
> > carrés, totalement isolée, hors de la zone de couverture des
> > opérateurs mobiles, et hors des plans d'amélioration de type "zone
> > blanche" ?
>
> Bon, vu que cela ne semble pas exister, et qu'il ne semble pas exister
> non plus d'expérimentation en ce sens, une autre approche peut être
> d'étudier l'installation (aux frais de la collectivité) d'une solution
> picocell commerciale d'un opérateur mobile.
>
> Qu'existe t-il en ce sens sur le marché, sur le principe de la femtocell
> gratuite, mais avec des une couverture et des performances correctes en
> extérieur ?
>
> Je connais une solution chez OBS ("Couverture Site"), mais il s'agit
> apparemment de bornes intérieures, dans l'optique de couvrir un entrepôt
> par exemple. Et il faut un uplink dédié (fibre ou SDSL) chez
> l'opérateur. Est-ce que çà existe en version "outdoor" pour une zone
> géographique plus étendue, et avec un uplink libre ?
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

Re: [FRnOG] [TECH] Femtocell / Picocell pour les appels d'urgence en zone isolée ?

[Jean-Paul chiron]

Le 10/08/2018 à 09:30, Toussaint OTTAVI a écrit :
> Bonjour,
Bonjour,

>
> Un tragique accident survenu récemment dans une zone isolée me ramène
> au premier plan une idée que j'ai dans la tête depuis longtemps :
>
> Existe t-il des solutions techniques de femtocell / picocell,
> installables par une collectivité locale, qui soient
> opérateur-agnostiques, et qui permettent d'acheminer uniquement les
> appels d'urgence (15/18/112) dans une zone de montagne de quelques km
> carrés, totalement isolée, hors de la zone de couverture des
> opérateurs mobiles, et hors des plans d'amélioration de type "zone
> blanche" ?
C'est ce qu'a mis en œuvre TSF, il me semble :
https://www.tsfi.org/fr/notre-expertise/instant-network-mini-fondation-vodafone


>
> Si cela n'existe pas en solution commerciale toute faite,
> connaissez-vous des implémentations libres d'un tel projet, par
> exemple sur une base OpenBTS ? Dans une telle hypothèse, qu'en dit la
> réglementation actuelle ?
En général TSF met ses développements sous licence libre, mais comme
c'est en partenariat avec vodaphone, je ne sais pas...
En copie clément qui répondra plus précisément.
Et J'en profite pour rappeler qu'ils sont toujours à la recherche un dev  :
https://seafile.tsfi.org/f/4a391aa11c/?raw=1

Cordialement.

-- 
Jean-Paul CHIRON - Chargé de mission numérique
logiciel libre / jeux vidéo / image
Délégation numérique - Conseil régional Nouvelle-Aquitaine
Hôtel de Région - 14, rue François de Sourdis
33077 Bordeaux - France
Tel: +33 (0)5 57 57 83 49
Port : +33 (0)6 27 65 46 35  
E-Mail: jean-paul.chi...@nouvelle-aquitaine.fr
Web : https://developpement-numerique.fr/


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

Re: [FRnOG] [TECH] Femtocell / Picocell : solutions commerciales existantes ?

[Toussaint OTTAVI]

Le 10/08/2018 à 09:30, Toussaint OTTAVI a écrit :
Existe t-il des solutions techniques de femtocell / picocell, 
installables par une collectivité locale, qui soient 
opérateur-agnostiques, et qui permettent d'acheminer uniquement les 
appels d'urgence (15/18/112) dans une zone de montagne de quelques km 
carrés, totalement isolée, hors de la zone de couverture des 
opérateurs mobiles, et hors des plans d'amélioration de type "zone 
blanche" ? 


Bon, vu que cela ne semble pas exister, et qu'il ne semble pas exister 
non plus d'expérimentation en ce sens, une autre approche peut être 
d'étudier l'installation (aux frais de la collectivité) d'une solution 
picocell commerciale d'un opérateur mobile.


Qu'existe t-il en ce sens sur le marché, sur le principe de la femtocell 
gratuite, mais avec des une couverture et des performances correctes en 
extérieur ?


Je connais une solution chez OBS ("Couverture Site"), mais il s'agit 
apparemment de bornes intérieures, dans l'optique de couvrir un entrepôt 
par exemple. Et il faut un uplink dédié (fibre ou SDSL) chez 
l'opérateur. Est-ce que çà existe en version "outdoor" pour une zone 
géographique plus étendue, et avec un uplink libre ?



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

Re: [FRnOG] [TECH] Femtocell / Picocell pour les appels d'urgence en zone isolée ?

[Toussaint OTTAVI]

Le 11/08/2018 à 08:55, Stéphane Rivière a écrit :
Normalement (sic), la GN a des passerelles tetrapol 380 MHz pour 
acropol (PN) et antarès (pompiers) qui eux, sont sur la même bande, le 
même réseau tetrapol et donc sont interopérables... Étonnant que les 
hélicos GN n'aient pas cette passerelle 70/380... 


La question n'est pas de savoir s'ils ont ladite passerelle, mais si les 
gens arrivent à s'en servir facilement en conditions opérationnelles. Un 
officier qui arrive sur zone doit pouvoir contacter immédiatement tous 
ses moyens de secours engagés. Pareil pour un nouvel engin ou un hélico 
qui arrive sur zone et qui doit pouvoir contacter le COS. Juste en 
appuyant sur un bouton. Sans avoir besoin d'un diplôme d'ingénieur 
télécom. Actuellement, entre les différences de matériel (Acropol 380, 
Acropol 70, VHF analogique 80, VHF 150, VHF aéro AM), les problèmes de 
couverture et les aberrations techniques (un hélico en vol ne peut pas 
utiliser les relais Antarès, car il déclenche les relais de l'autre coté 
de la Méditerranée; un hélico au sol ne peut pas utiliser la radio de 
bord car elle est connectée au réseau "inverter", qui n'est alimenté que 
lorsque les turbines tournent; un Pélican n'a pas d'Antarès car les 
postes ne sont pas homologués pour l'aéronautique...), cela donne un 
joyeux bazar, où les différents intervenants ont le plus grand mal à 
communiquer entre eux et avec leurs officiers pendant les premières 
minutes ou heures d'intervention, qui sont souvent critiques.


Tout çà, c'est autant d'efficacité en moins pour le secours proprement 
dit... Certes, l'humain fait en ce domaine un travail exceptionnel. Mais 
la radio, qui doit à la base être un outil pour faciliter la 
communication et simplifier le travail de l'homme, s'avère au final être 
un frein et une contrainte physique et psychologique supplémentaire pour 
les secouristes. Un officier qui doit gérer seul un secours complexe 
avec trois radios et un GSM pour seulement deux oreilles, en sort 
complètement lessivé ! C'est plus qu'une vocation qu'il faut pour faire 
ce job !


Et on ne parle même pas de comparaison des salaires avec les ingénieurs 
de Matra / Nortel / EADS qui conçoivent ces technologies, ni encore 
moins avec ceux des hauts fonctionnaires de l'Etat qui les valident...





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