Reprise du message précédent :

 
Une BDD sur NFS on va oublier
Sur glusterfs, je n'ai pas de retour d'expérience la dessus.
Et un dossier sur le host, bah si tu perds ton host, tu n'as plus de bdd

Ya toujours des failles.. Après faire des backups réguliers peut réduire les risques. Et l'avantage du container c'est que tu peux mettre toute la conf dans un répertoire sur le host, comme ça tu n'as plus qu'à redéployer un container avec la même conf, injecter le dump et rulez.

 
Pour une préprod pourquoi pas, pour un site ecommerce qui doit avoir très peu d'indispo, ce n'est top comme solution je trouve

Bah tout comme une BD hors container en fait    

Personne est passé à de l'ECMP & co ?

Puisque tout le monde fait son timide et n'ose me demander des nouvelles de l'avancé de mon incident transformé en soi-disant "Feature Request" de synchronisation du layout clavier entre le client Horizon Windows et l'Agent Linux (RHEL 7.4 et 7.6), je vous en donne : aucune
Entre-temps, mon patch :
- vient de passer le cap de 3000 sessions utilisateurs corrigées depuis le 20/02/2019, donc potentiellement 3000 incidents évités
- a évolué car j'ai détecté que des utilsateurs utilisaient aussi des clients Horizon sous Mac et Linux pour lesquels la synchronisation du layout clavier n'est pas supportée. pourtant, j'imagine que cela devrait être plus simple à implémenter depuis un OS Linux/UNIX côté client vers un Guest OS Linux en transférant juste le code clavier fr, de, uk, us, ... Mais cela ne fait pas partie des paramètres passés du Client vers l'Agent dans le viewagent-debug.log. Dommage, j'aurais vu faire évoluer mon patch pour Linux et MAc tant qu'à faire vu que cela fonctionne parfaitement sous Windows alors que c'est moins simple

Oui centos a 95% quelques debian; qu'on passe sur CentOS ASAP! il parait qu'on a quelques machines sur un truc qui s'appel Wind cheé pas quoi ....

qu'est ce que tu dis???

Y a une raison a pousser Centos plutot que Debian ?
 
A te lire, on a le sentiment que vous avez un pb avec Debian

Personnellement aucun souci avec Debian.  
J'ai moi même poussé vers cette distro dans mon dernier taf. Ensuite j'ai bossé sur du CentOS que j'ai bien aimé également, mais je ne pourrais pas mettre de préférence, les 2 me bottent bien.

L'écosystème redhat ? Je sais pas

 
Pareil. Le truc qui me gave un peu avec Centos c'est cette impossibilité de faire un upgrade de version  

Désolé j'avais répondu à une question de quelqu’un qui demandait la proportion des OS mais je ne vois plus le post ! J'ai bugé!    
 
Pour Debian, ma foi c'est pas qu'on aime pas, mais on préfère Centos...Y'a du mieux et du moins bien dans les deux, notre choix s'est porté sur CentOS, une question de gout  
Nous avons tout de même du Debian pour certaines choses (dont XOA) car OS préféré pour un type de service, Et je ne suis pas "contre" je suis plutôt "contre" Windaube !!!  

 
c'est pourtant possible depuis la 7.x
 
cela dit, je ne vois pas l'intérêt d'une telle fonctionnalité ajd (à la limite pour un poste de travail)
 
 
pour ceux qui veulent un post mortem bien complet sur l'incident cloudflare: https://blog.cloudflare.com/details [...] ly-2-2019/

 
oui mais non, il semblerait que cette fonctionnalité ai été dégagée.
Quel intérêt ? bah mettre ton serveur à jour avec des versions récentes des softs qui tournent dessus

 
je vois qu'un intérêt quand tu te tapes encore du serveur physique et sans aucune gestion de conf, ce qui normalement se faire rare aujourd'hui

 
perso je n'ai quasiment que des serveurs physiques et j'installe mes packages via les outils de la distrib. Ca suffit largement pour la plupart des cas mais pour certains trucs genre un truc un prod depuis quelques années qui tourne un mysql 5.1 bah c'est merdique.

conf mgmt, t'économises du temps quoi qu'il arrive (modulo le temps de formation/mise en place)

 
et tu compile tes softs pour les déployer ?
Pour 2 ou 3 serveurs, ça me semble un peu overkill.

Compiler ?

Intéressant merci, l'analyse poussée sur les regexp, le gars va au bout des choses, respect

bon en fait pour le vieux mysql moisi du collègue, je peux installer les repo de mariadb et faire la migration  

 
j'espère que t'as fait l'inventaire de tes applis qui utilisent des vieux connecteurs sql

Pourquoi faire, comme d'hab t'attends un peu voir ce qui remonte comme erreurs/plaintes

Mais oui c'est comme ça que je fais aussi. On bouge un truc qui a l'air tout vieux, et on attend de vois si ça râle. Si ça râle pas: backup et on vire

on est d'accord.

Aussi

Mes enfants, je viens de déracker un Apple X-Serve bah c'est pas tant beau comme machine

Ça va ya largement pire Les boutons, les loupiottes et la finition alu brossé ça respire la qualité  
 
 
Tout à fait raccord avec le style des mac en alu

C'est même à ça qu'on les reconnaît.

Caremment, très instructif.

 
Bon ben on met des thunes où on peut (Et pas dans le réseau )
Du coup j’ai effectivement utilisé Netmiko et je suis tombé amoureux !  
 
Merci pour la suggestion !

screenscraping = cancer, combien de fois faudra t-il le dire  

Non mais là c'est en prod . Et je me suis rendu compte qu'il y avait de la réplication dans l'affaire... Le slave status sur le premier serveur est en vrac vu que le slave en question n'existe plus et sur le 2e serveur qui tourne encore, le slave status me dit que la synchro est bonne vers le 1er.

Donc si je comprends bien on a un master qui se réplique sur un slave qui était un master mais qui n'a plus de slave  . Je ne suis pas tant familier avec les réplications de db, comment on voit quelle config est en place, master master ou master slave ou truc chose ?

réplication circulaire ?
comment tu peux avoir des réplis pétées en prod sans le savoir ?

Ah oui alors en prod effectivement on touche beaucoup moins

EDIT: après je ne connais pas les systèmes de réplication de DB du coup je peux pas t'aider là dessus.

 
Aaaah mais ça c'est les joies des installations montées à l'arrache et jamais monitorées... et kiki c'est qui récupère ça... \o/
Mais pour le coup je pense qu'il y avait une réplication master-slave à l'époque, que le slave a été éteint et viré du parc, le gars qui a monté cette db n'a pas modifié la config et a installé un autre serveur pour le rajouter comme master ou slave je ne sais pas et voilà pourquoi on se retrouve avec cette installation sur 1.5 patte.
 

 
Vous noterez le nom du user toutafaÿ adéquat pour un environnement de production

Putain user test
Le mot de passe c'est test, ou 1234?

Classique, le test est réussi mais rien n'a été noté ou bien on sait pas comment migrer vers un user un peu plus permanent, flemme de réinstaller, du coup on laisse le user "test" passer en prod vu que ça marche bien comme ça  
La même story que les user "admin" dont tu ne peux pas changer le mot de passe, ou les mots de passe d'usine hardcodés inchangeables car ça va tout péter derrière.  
https://www.wired.com/2011/08/sieme [...] -password/
https://nakedsecurity.sophos.com/20 [...] d-siemens/
C'est pas grave, c'est juste un petit bidule, une centrale nucléaire, un rien du tout quoi  

 
 
Un peu moins vieux (2015), c'est pas connecté à internet alors on ne peut pas l'attaquer, balec de mettre un mot de passe différent  
https://theweek.com/speedreads/5813 [...] -like-1234

pour les noobs de bash https://www.fun-mooc.fr/courses/cou [...] on02/about