Reprise du message précédent :

python c'est du robuste !
Ça dit papa-maman et ça le fait bien.

Du go c'est plus hype  

Un peu de virtualisation? QEMU/KVM ou Qubes OS ...
Le clustering ? Pacemaker/Corosync et crmsh ... EDIT> et naturellement DRBD
etc.....

 
Oui, c'est la référence aujourd'hui. Chez Netflix par exemple, mais il y a des centaines d'autres use cases trouvable par des très gros du secteur.

En fait ce topic c'est le topic de XaT qui a besoin de conseils non?  

XaT étant le seul à poser des questions, ça y ressemble mais non  
 
Est-ce qu'il y en a parmi vous qui ont une policy BGP plus ou moins dynamique ? Voire carrément 100% dynamique façon SDN, influencée par des mesures X ou critères Y, etc.  
 
Ça m'intéresserait de voir comment c'est mis en place et avec quel(s) outil(s)/matériel/norme/API etc. Si quelqu'un balance une liste de buzzwords que je puisse faire des recherches derrière, ça me va aussi

C'est quoi le but? En cas de coupure sur un site tu ressors ton trafic Internet via un autre site?

Je parle niveau ISP : tu détectes qu'un IXP a du packetloss, tu bascules tout ou partie de ton trafic dynamiquement vers un autre IXP. Voire tu tombe sous un certain seuil de qualité défini, tu shutdown les sessions BGP liées à cet IXP. Lorsque le problème est résolu, on clear l'event et le trafic se rétablit... voire un moyen de détecter que c'est résolu et le trafic revient automagiquement sur le chemin préféré/optimal.
Le tout avec un dashboard sexy et l'alarming qui va bien.
Ce genre de truc

je sais pas si tu trouveras ce genre de solution clé en main pour le moment, je pense que ce genre de truc pour le moment c'est surtout pour les ISP, qui vont avoir une solution maison (que rien ne t'empêche de créer si tu as suffisamment de temps, toutes les briques nécessaires existent, il faut juste du code pour assembler tout ça).

sinon pour les buzzwords, regarde flowspec.

Bah tu peux le faire en CLI avec VyOS.

Un swich de tête qui claque quand t'arrives au taf

 
Je lurke activement à défaut d'avoir de vraies questions.
 
D'ailleurs j'en ai une. Sur quoi on peut se faire la main comme OS Unix qui vaille la peine d'être exploré côté sysadmin ?

Bon, le dernier morceaux qui me gênait avec netdata+prometheus+grafana est réglé : tu peux avoir un modèle en push (et donc dynamique) avec un netdata central, et n'avoir plus que prometheus qui récupère les données de ce nœud central
 
Je ferai un tuto un de ces 4, c'est vraiment top

Debian et CentOS.

Et voilà comment on se farcit un historique Unix/Linux pour éviter de passer pour un con la prochaine fois

Thanks  
 

Tu peux m'en dire un peu plus stp ?

Tu peux y aller sur les questions de noob, no soucy

Unix il a dit

Du xBSD

XaT

Je note pour xBSD. Je vais me faire une VM avec ça

Une vm xbsd ?

Merde j'ai lu de travers...

J'en fais plus depuis des années mais en gros tu peux check des ressources externes, si c'est inaccessible tu peux router ta sortie Internet vers un autre voisin sur ton BGP interne. Dans mon cas on avait 3 sites chacun dans un pays différent, avec des fibres noires en mesh, ça représentait notre iBGP. Et chaque site avait aussi un lien eBGP pour l'accès Internet. De là on pouvait placer des poids pour privilégier la sortie Internet sur un lien plutôt qu'un autre. Que ce soit en cas de coupure d'un lien iBGP ou eBGP on routait le trafic via la triangulation pour ressortir le trafic Internet par un autre pays. Et vu que c'est du BGP tu annonces tes plages d'IP publiques via ton voisinage BGP (les neighbours). Je sais pas si je suis clair, limite un schéma s'impose, mais faudra que je poste ça de chez moi.

 
C'était une façon générique de décrire l'ensemble des versions de BSD existantes ?

yep

Faudra que je refasse un essai différent de Pfsense du coup.
 
Je voulais zieuter un Solaris ou un Aix mais apparemment c'est propri donc ça doit pas être gratos les isos éventuels.
 
Je vais check ça

C'est un peu ça que je voudrais faire Mais de façon holistique depuis un système externe centralisé plus intelligent car il aurait des données plus complètes sur tout l'AS, par exemple en déterminant le bestpath en fonction du RTT ou du packetloss en testant des destinations spécifiques, etc. Raisonner en terme de coupure de lien on fait déjà, on privilégie aussi certaines routes apprises, hiérarchisées suivant le type de peerings où on les apprend (PNI/Public peering/Route server/Transit) ce qui fait qu'on a toujours les routes les plus intéressantes dispo en terme de BP/coût.  
 
Cette hiérarchie est beaucoup efficace et simple à lire que la politique BGP précédente... mais j'aimerais bien savoir si avec la techno d'aujourd'hui on peut déjà aller un cran plus loin, faire un peu plus de fine-tuning et devenir réellement pro-actif vis à vis de la qualité du service livré sur les liens dispo, plutôt qu'une hiérarchie de liens de priorité pré-définie avec des attributs statiques. Rendre le truc dynamique, avec des rankings qui évoluent en permanence, un système BGP organique vivant qui optimise les routes et auto-répare les soucis détectés  
 
Sûrement que des solutions maison existent comme dit Ivy gu La construire chez moi est également possible, la question des "briques nécessaires existent" j'aimerais bien lister ça justement, pour éviter de réinventer la roue dans mon coin  
J'imagine que c'est également un bon moyen de faire une jolie usine à gaz que personne ne maîtrise ou une belle opportunité de se planter over 9000 mais bon, c'est ça l'évolution

Le coup des réseaux qui adaptent le routage en fonction du RTT ça peut vite tourner au Network Outage as a Service aussi, cf EIGRP et ses métriques que personne n'a jamais utilisé parce que le gros risque c'est :
1 - ah tiens, lien A est de mauvaise qualité, mettons le trafic sur lien B plutôt
2 - ah tiens, lien B est de mauvaise qualité mais lien A refonctionne bien (ptet lié au fait qu'on vient d'enlever le trafic de lien A qui sait ) on remet tout sur lien A
3 - goto 1
 
Quand sur la base d'une mesure on déclenche une action qui va avoir un effet sur le résultat de la mesure, on peut avoir des boucles de feedback rigolotes.

A mon avis ce genre de truc c'est soit pour les grosses entreprises qui ont la main d'oeuvre nécessaire pour développer et maintenir le truc en interne, soit les boîtes comme arbor networks qui vendent ce genre de service (qui reste assez cher et qui demande quand mêmes des compétences significatives en réseau)... dans tous les cas faut accepter d'y passer un certain temps, imho faut vraiment bien considérer ce qu'il y a à y gagner par rapport à du BGP classique, je pense que dans beaucoup de cas c'est une fausse bonne idée. La comparaison de ça avec le coût de juste upgrader/diversifier ses liens est à faire dans tous les cas avant de se lancer.

Ah et à part ça le mot clé plus général pour la mesure "nouvelle génération" c'est streaming telemetry (en gros l'inverse du polling SNMP classique, c'est l'équipement qui envoie ses donnée au fur et à mesure qu'elles sont générées).

Yes ça j'ai déjà discuté avec gars d'une boite de streaming qui utilise plusieurs CDN simultanément autour du globe, très malin comme système.
Basé sur la qualité actuelle du streaming (données remontées par le player) et la localisation géographique du player, ça permet d'établir une map de toutes les sources dispo les plus proches (les serveurs des CDN) et de sélectionner la source optimale, ou d'en changer si la qualité se dégrade.

L'algo statistique derrière doit être un beau morceau d'ingénierie

sinon dans le monde MPLS y'a déjà RSVP-TE qui existe et qui pour le coup est déjà pas mal utilisé, mais c'est pour la partie réseau interne.

Bjr je Reviens sur la documentation et le markdown.
 
Un pb récurrent pour nous, c'est la fenêtre d'exploitation des documents.
Elle est souvent courte et les documents rapidement obsolète.
Comment vous gérez ça vous? Et pour ceux qui en utilisent, ac du markdown?

Change control process. Tu modifies en prod que si ça a été documenté.
Sinon bah du CI/CD, infra as code, script qui génèrent la doc à partir de la config etc.

Sinon dans les techos hype du moment ya terraform aussi

 
Faut que la doc soit partie intégrante du process de modification. Que ce soit automatisé ou pas d'ailleurs.
 
Exemple simple d'un changelog en markdown dans notre dépôt GitHub: dans le process de Pull Request, un dev qui fait un changement de code doit aussi écrire le changement dans le fichier CHANGELOG.md, sinon la PR est pas acceptée.
 
Même pour un tout petit changement, comme ici : https://github.com/vatesfr/xen-orch [...] 3435/files
 
À noter la checklist autogénérée dans une PR, tant que tout est pas coché, pas de merge : https://github.com/vatesfr/xen-orchestra/pull/3435
 
 
Bien entendu, c'est un exemple simple et pas « automatisé », c'est ça montre bien que c'est le workflow qui compte, pas que l'outil

 
le plus simple au final, coder le changement de version + autodiscovery.
 
//on a jamais le temps de bien faire la doc en plus du change

Freebsd  

 
Mauvais process alors. La doc c'est aussi important. Automatisée ou pas.

Grave. Surtout quand t'es le seul à maîtriser ton sujet/domaine de compétences.
 
C'est certainement la partie la plus chiante du métier en dehors des utilisateurs

Concernant la popularité de Prometheus : https://twitter.com/jpetazzo/status/1043040357016104965
 
Ça va pas aller en réduisant

 
c'est beau le monde des bisounours.
Maintenant, dans la réalité, les personnes maitrisent rarement tous les impacts de leurs changes et avec la pression actuelle, c'est "urgence urgence urgence".
 
Donc une doc "parfaitement à jour", j'en ai jamais vu.
 
Donc, notamment pour l'infra, je préfère trouver un moyen d'interdire les actions directes sur les infra mais forcer l'usage d'un outil.
+ avoir de l'autodiscover, ça reste bien pour trouver le "shadow IT", Mme michu de la comm qui a ramené sa prise wifi "parce que le câble réseau est trop court pour bouger du bureau", le presta jean-jean qui profite de ses droits d'admin pour l'intégration de son appli pour "télécharger des outils supplémentaires nécessaires à leur tma" qui viennent foutre la grouille.

C'est une approche forcément différente côté infra, tu ne peux pas versionner l'install d'un switch, etc
 
Mais c'est clair que c'est dépendant de "l'urgence" de la situation. S'il faut clairement aller dépanner en urgence le serveur de prod et que t'es déjà la tête dans le guidon, bah tu prends pas le temps de le faire.
 
Si c'est tout le temps l'urgence aussi, c'est le moment de mettre son CV à jour.

 
Mec, tu parles à un CEO d'une Startup qui est dans un marché avec une énorme pression (concurrence commerciale et techno). Donc ta leçon sur les Bisounours, tu peux te la garder et profiter plutôt de ton énergie pour améliorer tes process
 
Je dis pas que chez nous c'est parfait non plus, mais il FAUT intégrer les devs dans la doc, sinon tu payes encore plus cher les conséquences. Concernant l'infra et la gestion de lusers, c'est moins mon domaine aujourd'hui, donc je me permettrai pas de donner des leçons

 
 
Salut,
 
Tu peux utiliser BFD en tout cas pour détecter des pertes.
Sinon, tu peux aussi utiliser les services de https://www.noction.com/
C'est plus orienté pour les grosses infrastructures, mais je préfère le mentionné ici quand même pour info  

Hey les pinguins lover, j'ai une question pour vous, j'suis plutôt habitué à powershell pour faire de scripts, la on me demande de faire un script sur du shell.
 
Vous avez des bonnes sources pour s'initier à ça ? Grosso modo j'pars de 0.
 
La ou je pèche un peu c'est sur la gestion des variables, comment split une string en plusieurs variables & co.

 
Tu veux dire que je parles à un mec qui peut DECIDER et IMPOSER tout ce qui est fait dans sa propre boite ?    
Et qui en plus est EDITEUR de sa propre solution donc sans problématique d'URBANISATION DES APPLIS.
 
A ta différence, je suis chez un client final industriel qui fait qqs milliards de CA.
chez nous, on est est BUYER des solutions, on est pas MAKER.
 
Donc X providers différents, X méthodes différentes de travail, une ENORME difficulté pour imposer des mécanismes de fonctionnement corrects.
Et le métier industriel qui s'en FOUT de la doc technique d'exploitation pas à jour.
 
Les produits sont pas sélectionnés sur la meilleur doc technique :
On en est à sélectionner parfois des produits avec des SLA sans pénalité ...
 
Tu penses réellement que j'ai la capacité de contraindre IBM, SAP, SIEMENS, SALESFORCES alors même que ma direction me suit pas ?
 
On a choisi un ESB/ELT comme bus d'entreprise (Talend).
On n'arrive plus à maitriser les interfaces entre nos applis, les devs ne savent plus : trop dans l'urgence, trop de changements, pas assez de compétence et de maitrise.
 
ils ont pourtant des pull requests, des revues de code et de la doc systématiques avant les passages en prod, ...
 
Mais on parle d'une équipe de 50+ devs, d'interfaces sur toutes les applis de la production, ... avec une dette historique de maitrise des applis existantes.
 
Bref. t'es gentil mais t'es pas le seul à avoir de l'exp et du vécu      
 
j'ai beau avoir de la doc, je préfère limiter au maximum les changements (et putain c'est pas simple).