À titre informatif on utilise la marque “entretien” sur le Jdh avec ces deux sens : Entretien ou interview d'une personne, entretien dans le sens maintenance d'un matériel/système/logiciel/autre.
Mon article parle de prendre soin de son corps et d'être à son écoute (entretien de son corps), je comprendrai parfaitement si des utilisateurs du Jdh trouvent que cet article n'a pas se place ici. Si c'est le cas merci de me le signaler, je supprimerai l'article.
Avant j'étais (seul) sysadmin dans une PME, j'ai toujours eu la flemme de gérer les fichiers de conf avec git. Il y avait toujours plus urgent/important à faire mais au final c'était un peu hypocrite car clairement c'est ce qu'il y a de mieux pour celui qui reprend le poste derrière.
Dans ton cas un manager ne fait pas correctement son job, il devrait imposer une manière de procéder/travailler.
Je travaille chez un hébergeur web, on est payé pour que les serveurs et leur config soient carrés, normal que ça soit géré correctement.
Pour illustrer notre fonctionnement :
- Une faille assez importante est découverte sur proftpd (https://security-tracker.debian.org/tracker/CVE-2019-12815), on décide de mettre à jour qd le correctif est dispo
- On installe sur qq serveurs (avec le rôle FTP) et en général on attend une journée pour voir si tout se passe bien
- On remarque que les logs “FTP session opened” ne remontent plus, on trouve : “Question: Why are successful logins no longer being logged, after upgrading to ProFTPD 1.3.6, even though I am using the SystemLog directive?
Answer: The default log level was changed from DEBUG to NOTICE in ProFTPD 1.3.6; see Bug#3983. And the "Login successful” log message is logged at the INFO level, which means that it will not be logged by default"
- On ajoute dans le fichier de config “SyslogLevel INFO”
- Le lendemain on installe sur le reste des serveurs
- Dans quelques semaines on fera un git push (sur le dossier/rôle FTP) avec le petit commentaire qui va bien concernant “SyslogLevel INFO”
Tant mieux pour toi si les fichiers de conf sont gérés dans des git… chez nous, hélas, c'est pas le cas malgré que j'ai tenté y quelques temps la mise en place de Rudder et avec ma bande de bidouillers en herbe … impossible, je me suis fait jeter par tout les autres sysadmin….
Il faut aussi des équipes bien matures sur l'IAC et pas des bidouilleurs de fichiers à coup de console interactive…
Ça fait plusieurs fois que je vois des infos sur cet outil surtout chez LinuxFr.org, il s'agit d'une solution française.
Je comprends l'intérêt mais je pense qu'on peut s'en passer. Ça fait partie de ces outils mal positionnés, Ansible et Puppet vont assurer un suivi de la config même si effectivement ce n'est pas exactement de la conformité comme décrit dans l'article.
Quand je lis : “Le server va compiler un nombre d'informations assez importantes, et notamment les différentes règles et techniques pour définir les ordres à envoyer aux agents. Mieux vaut donc prévoir un serveur relativement costaud. 4Go de RAM me parait un minimum si vous compter gérer plus d'une 20aine de serveur”, je me dis que c'est une blague par rapport à Ansible qui fait 90% de ce qu'on a besoin avec quelques fichiers (playbooks) et sans client (avec SSH). Même les quelques captures d'écran me font penser à une usine à gaz, la conformité des serveurs est assurée mais le sysadmin doit avoir en tête toutes les règles, les définir, les modifier.
Souvent en entreprise les fichiers de config (et autres) sont versionnés avec git et séparés en rôle (FTP, HTTP, IMAP…) puis poussés avec Ansible/Puppet/Salt/Others. Ça reste simple, largement suffisant pour la plupart des entreprises et évite de rajouter une couche supplémentaire notamment via cet outil qui donne plus envie de s'en passer que de s'y mettre.
La plupart des points abordés sont exacts, MySQL est assez simple ou même simpliste dans pas mal de cas.
Mais c'est aussi ce qui fait sa force. Il n'y a pas besoin d'un DBA expert pour l'utiliser. MySQL est utilisé massivement pour des applications légères ou simples où il est largement suffisant.
À chaque besoin son outil. Certainement pour faire tourner un système bancaire on ne va pas utiliser MySQL. Mais pour faire un site web, un blog, dans la majorité des cas MySQL est tout à fait suffisant.
Certains points de l'article sont tout de même risibles. Comparer le nombre de rapports de bogues pour MySQL, avec SQLServer. Et bien en fait on ne peut pas avoir accès à ceux de SQLServer, normal c'est proprio ! Pareil pour les CVEs. Microsoft peut patcher sans avertir personne vu que tout est fermé. Impossible de faire ça avec du libre.
Je sens plus la frustrations des DBAs de l'ancien temps (Oracle et SQLServer) forcés de constater que ces solutions sont de moins en moins utilisées. Il est temps d'adopter le libre plutôt que d'essayer de se battre pour son petit bout de gazon !
En effet tu as raison. Seulement beaucoup de personne ne connaissent pas les JWT c'est le pourquoi de l'opposition : pour en parler et les faire connaitre.
Pour moi, les JWT ne sont pas forcément liés à une notion d'authentification ou d'autorisation. C'est un format de données.
Par contre, effectivement, ça permet de déporter certaines données côté client tout en ayant la garantie que ces données sont valides grâce à la clé de signature.
C'est également possible d'utliser une clé pour chiffrer afin de ne pas rendre ces données publiques.
D'autre part, je pense qu'un cookie de session peut tout à faire être un JWT, les deux ne sont pas à opposer à mon avis.
Il va falloir un peu de patience :)
À titre informatif on utilise la marque “entretien” sur le Jdh avec ces deux sens : Entretien ou interview d'une personne, entretien dans le sens maintenance d'un matériel/système/logiciel/autre.
Mon article parle de prendre soin de son corps et d'être à son écoute (entretien de son corps), je comprendrai parfaitement si des utilisateurs du Jdh trouvent que cet article n'a pas se place ici. Si c'est le cas merci de me le signaler, je supprimerai l'article.
Tcho !
Voir aussi cet article sur developpez.com.
Je veux bien un article “Retour sur 3 ans d'utilisation de Manjaro”.
il manque la fin du titre : et repense son fonctionnement pour ne plus se faire gauler
Salute,
Avant j'étais (seul) sysadmin dans une PME, j'ai toujours eu la flemme de gérer les fichiers de conf avec git. Il y avait toujours plus urgent/important à faire mais au final c'était un peu hypocrite car clairement c'est ce qu'il y a de mieux pour celui qui reprend le poste derrière.
Dans ton cas un manager ne fait pas correctement son job, il devrait imposer une manière de procéder/travailler.
Je travaille chez un hébergeur web, on est payé pour que les serveurs et leur config soient carrés, normal que ça soit géré correctement.
Pour illustrer notre fonctionnement :
- Une faille assez importante est découverte sur proftpd (https://security-tracker.debian.org/tracker/CVE-2019-12815), on décide de mettre à jour qd le correctif est dispo
- On installe sur qq serveurs (avec le rôle FTP) et en général on attend une journée pour voir si tout se passe bien
- On remarque que les logs “FTP session opened” ne remontent plus, on trouve : “Question: Why are successful logins no longer being logged, after upgrading to ProFTPD 1.3.6, even though I am using the SystemLog directive? Answer: The default log level was changed from DEBUG to NOTICE in ProFTPD 1.3.6; see Bug#3983. And the "Login successful” log message is logged at the INFO level, which means that it will not be logged by default"
- On ajoute dans le fichier de config “SyslogLevel INFO”
- Le lendemain on installe sur le reste des serveurs
- Dans quelques semaines on fera un git push (sur le dossier/rôle FTP) avec le petit commentaire qui va bien concernant “SyslogLevel INFO”
Tcho !
Tant mieux pour toi si les fichiers de conf sont gérés dans des git… chez nous, hélas, c'est pas le cas malgré que j'ai tenté y quelques temps la mise en place de Rudder et avec ma bande de bidouillers en herbe … impossible, je me suis fait jeter par tout les autres sysadmin….
Il faut aussi des équipes bien matures sur l'IAC et pas des bidouilleurs de fichiers à coup de console interactive…
Ça fait plusieurs fois que je vois des infos sur cet outil surtout chez LinuxFr.org, il s'agit d'une solution française.
Je comprends l'intérêt mais je pense qu'on peut s'en passer. Ça fait partie de ces outils mal positionnés, Ansible et Puppet vont assurer un suivi de la config même si effectivement ce n'est pas exactement de la conformité comme décrit dans l'article.
Quand je lis : “Le server va compiler un nombre d'informations assez importantes, et notamment les différentes règles et techniques pour définir les ordres à envoyer aux agents. Mieux vaut donc prévoir un serveur relativement costaud. 4Go de RAM me parait un minimum si vous compter gérer plus d'une 20aine de serveur”, je me dis que c'est une blague par rapport à Ansible qui fait 90% de ce qu'on a besoin avec quelques fichiers (playbooks) et sans client (avec SSH). Même les quelques captures d'écran me font penser à une usine à gaz, la conformité des serveurs est assurée mais le sysadmin doit avoir en tête toutes les règles, les définir, les modifier.
Souvent en entreprise les fichiers de config (et autres) sont versionnés avec git et séparés en rôle (FTP, HTTP, IMAP…) puis poussés avec Ansible/Puppet/Salt/Others. Ça reste simple, largement suffisant pour la plupart des entreprises et évite de rajouter une couche supplémentaire notamment via cet outil qui donne plus envie de s'en passer que de s'y mettre.
Tcho !
C'est quand même fou qu'il faille passer par ce genre d'astuce pour administrer “facilement” ce qui l'était avant !!! Pfff
s/sectionné/sanctionné ? non ?
La plupart des points abordés sont exacts, MySQL est assez simple ou même simpliste dans pas mal de cas. Mais c'est aussi ce qui fait sa force. Il n'y a pas besoin d'un DBA expert pour l'utiliser. MySQL est utilisé massivement pour des applications légères ou simples où il est largement suffisant.
À chaque besoin son outil. Certainement pour faire tourner un système bancaire on ne va pas utiliser MySQL. Mais pour faire un site web, un blog, dans la majorité des cas MySQL est tout à fait suffisant.
Certains points de l'article sont tout de même risibles. Comparer le nombre de rapports de bogues pour MySQL, avec SQLServer. Et bien en fait on ne peut pas avoir accès à ceux de SQLServer, normal c'est proprio ! Pareil pour les CVEs. Microsoft peut patcher sans avertir personne vu que tout est fermé. Impossible de faire ça avec du libre.
Je sens plus la frustrations des DBAs de l'ancien temps (Oracle et SQLServer) forcés de constater que ces solutions sont de moins en moins utilisées. Il est temps d'adopter le libre plutôt que d'essayer de se battre pour son petit bout de gazon !
On va y arriver, modifié !
Tcho !
Désolé, le site a eu un problème technique, l'article est de nouveau disponible à son lien d'origine https://zestedesavoir.com/tutoriels/3163/variables-scopes-et-closures-en-python/ ledit lien est plus complet que celui qui s'appelle billet, surtout un travail a été fait pour améliorer la pédagogie.
Je suis vraiment désolé pour la pagaille à cause d'un bug du site.
Modifié, Thanks !
Tcho !
Nouveau lien de l'article : https://zestedesavoir.com/billets/2648/variables-scopes-et-closures-en-python-billet/
En effet tu as raison. Seulement beaucoup de personne ne connaissent pas les JWT c'est le pourquoi de l'opposition : pour en parler et les faire connaitre.
Pour moi, les JWT ne sont pas forcément liés à une notion d'authentification ou d'autorisation. C'est un format de données. Par contre, effectivement, ça permet de déporter certaines données côté client tout en ayant la garantie que ces données sont valides grâce à la clé de signature. C'est également possible d'utliser une clé pour chiffrer afin de ne pas rendre ces données publiques. D'autre part, je pense qu'un cookie de session peut tout à faire être un JWT, les deux ne sont pas à opposer à mon avis.
Un bon exemple comme quoi le cloud troque des problèmes pour d'autres :-)
Ça fait bizarre de faire du préchauffage sur lambda pour les garder démarrée. Pourquoi ne pas utiliser EC2 ou EKS ?
Corrigé, merci !
Le lien n'existe pas