Beau‚ ce n'est pas forcément utile ou agréable ou dans le cas qui nous occupe ici maintenable.
A mon avis ce qui caractérise le beau c'est justement lorsqu'il y a quelque chose qui dépasse les qualités fonctionnelles du produit. Si tu prends par exemple le code de apache 1.3, il etait loin d'être maintenable et souffrait de problèmes de design important. A vrai dire c'était une série de hacks avec des ifdef spaghetti dans tous les sens. Mais finalement cela en faisait un morceau tellement essentiel du l'histoire de l'informatique qu'il avait une beauté certaine.
En le lisant, tu pouvais découvrir l'évolution des systèmes, leur parenté‚ leurs manques. Les tentatives diverses pour avoir des ipc efficaces‚ des codages de caractères insoupsonnés‚ des hacks pour résoudre toutes sorte de problème qui ont émaillés l'histoire du web.
Bref tu te retrouves devant des morceaux de codes qui te font voyager dans le temps‚ devant l'intention de programmeurs désarmés face a des problèmes nouveaux et qui finalement imaginent des solutions pas si éloignées des outils actuels …
Un tel code est une horreur a maintenir et a de grosses limites en efficacité. Pourtant il reste d'une beauté émouvante et a mon avis difficilement contestable.
Il faut peut-être être plus nuancé. Pour un soft qui a ponctuellement besoin de connaître l'ip d'une machine à un instant t, nss est tout à fait satisfaisant et ne pas l'utiliser tient du bug.
Pour un logiciel qui traite massivement du DNS, comme un serveur smtp (plusieurs requêtes par mail), alors la libc n'est clairement pas satisfaisante.
NSS ne donne pas suffisamment d'information (MX, DKIM, TTL, interrogation d'un serveur spécifique pour les RBL …).
resolver(3) (qui au passage ne lit pas, me semble-t-il le fichier hosts - à confirmer) n'est pas réputé pour sa performance, comparé aux librairies venant de unbound par exmple
Le fichier hosts et la résolution DNS sont deux choses distinctes.
La résolution DNS, comme son nom l'indique sert à chercher des informations sur les serveurs de nom renseignés dans /etc/resolv.conf.
Le fichier hosts est l'un des fichiers de configuration de la base de données système hosts qui fait partie du sous système nss (au même titre que les bases de données passwd, group, services …)
D'ailleurs en supposant que tu es mis toto.com dans ton fichier /etc/hosts tu peux observer que tu n'as pas le même résultat en faisant getent hosts toto.com et dig +short toto.com.
La base de données hosts est souvent configuré de façon à ce que si une entrée n'est pas dans le fichier hosts, elle soit retrouvée par le resolver de la libc (res_query). Mais cela n'a rien d'obligatoire.
Bref la base de données hosts n'est pas la résolution DNS et inversement.
Il n'est pas rare que pour des raisons de performances des softs utilisent un resolver différent que celui de la libc. Notamment pour ce qui concerne les mails, très gourmands en requêtes dns. Dans certains cas, les appels à nss ne sont pas satisfaisants. Les programmes ont tout à fait le droit d'effectuer des requêtes plus complexes (MX, SPF, DKIM …). Ils peuvent également gérer leur propre cache et dans ce cas, ils ont besoin d'avoir toutes les infos.
Par exemple, imagine que ton serveur de mail fasse juste un appel à nss pour résoudre son smarthost.
Il doit faire un appel à chaque mail car il ne connaît pas la durée de validité de l'enregistrement.
S'il ne le fait pas il est plus rapide mais il se prive d'un éventuel round robin DNS.
Alors que si il fait une requête DNS, il a la totalité du résultat avec toutes les ips possibles et l'information du TTL qui lui permet de gérer sa mise en cache des informations.
…
Ceci mis à part :
1 - la resolution dns dans postfix se configure finement :
smtp_host_lookup=native devrait t'aider par exemple
2 - le fichier hosts ne sert pas à tricher mais à donner les IP d’hôtes qui n'ont pas de résolution DNS (nommer les liens locaux par exemple).
3 - Si tu veux tricher, la bonne méthode est q'utiliser un resolver qui sait le faire tel que unbound.
Oui sauf que pour une bonne partie des sites à bloquer tu vas tomber sur des IPs qui changent sans arrêt type cdn dont tu n'auras jamais la liste exhaustive.
C'est plutôt du côté MySQL que je devrais chercher non ?
A partir de 5.5 tu peux mettre log_warning à 2 pour avoir cette info dans les logs. En dessous c'est mort à moins d'activer les log généraux (qui vous tout logguer y compris les requêtes).
Bonjour,
Il est probable qu'un script ait de mauvaises informations de connexion. Dans le cas du php, tu actives le error_reporting et tu place log_error à On. Ainsi tu auras dans les logs d'erreur du serveur web des "access denied" et le script d'origine
A ma connaissance DRBD permet de faire du RAID-1 like (le disque "paire" est activé en cas de failure du disque actif)
DRBD fait de la réplication au niveau bloc. Avec un système de fichier tel que GFS2, tu peux monter un cluster actif/actif. C'est la solution généralement retenue pour mettre en place le setup dont tu parles.
Gluster semble etre la solution j ai trouvé ca:
Gluster est conçu pour les clusters de stockage. Ce cas d'usage fonctionne peut-être par effet de bord mais ce n'est pas la destination première du projet.
l'Arabie Saoudite, au Qatar et aux Émirats Arabes Unis
Il y a ceux la mais aussi ben Ali, Kadhafi‚ Saddam Hussein et tous les autres, que nous avons armés‚ légitimité s mordicus‚ souvent contre leurs peuples ‚ créant ainsi les conditions du chaos.
Ce qui se passe aujourd'hui se prépare depuis les années 70. Pense a l'État d'urgence en Égypte (1981 - 2013) ou encore a la terreur algérienne des années 90.
la guerre en question n'a pas été commencée par l'Occident
Si l'islamisme est si populaire, c'est que les mosquées se sont imposées dans les pays dits Arabes comme des lieux d'opposition, de solidarité et de parole. Pendant ce temps nous soutenions, nous les Occidentaux ou la Russie pour des raisons plus ou moins avouables, les régimes infects du Moyen-Orient et d'Afrique du Nord, qui sont des émanations de la décolonisation et de la guerre froide. Nous avons maintenus mordicus nos grand amis au détriment des peuples. Là dessus, les EU ont créés les conditions du chaos en Irak en détruisant l'appareil d'État sans préparation préalable. Les frappes ciblés et les printemps arabes ont finis de semer la gouaille un peu partout.
Alors qui a commencé cette guerre ? Je ne saurais pour ma part le dire, même si j'aurais tendance à penser que nous n'y sommes pas pour rien.
Ce qui est sûr, c'est que si au lieu d'aller tremper notre cul sur les plages de nos grands amis et de fourbir les armes à des décennies de répression et d'écrasement des peuples, nous avions menés une politique conforme à nos principes, en soutenant activement les mouvements pour la liberté et la démocratie, en offrant un asile sans complexe aux opposants politiques, en offrant des bourses aux étudiants, bref en soutenant correctement les opposants qui depuis les années 70 se battent dans le monde Arabes contre des régimes répressifs et corrompus, et surtout en arrêtant d'armer leurs bourreaux nous n'en serions certainement pas là.
Est-il trop tard ? Sans doute. Pourtant, le Liban et paradoxalement l'Iran sont sans doute les pays les plus porteurs d'espoir dans la région. Dans ces deux pays, la jeunesse en pète et rêve de liberté, de paix et de démocratie. Saurons nous les soutenir ? Saurons nous soutenir vraiment l'opposition Syrienne quitte a nous passer du gaz Russe ? Saurons nous accompagner activement les démocrates Tunisiens, Algériens quitte à finir de livrer aux Chinois notre influence en Afrique du Nord ? La paix à un prix. Celui de sacrifier des intérêts économiques immédiats a nos principes au lieu de prostituer cette République dont nous aimons tant nous gargariser à nos client et amis. Quand on voit ce que donnent tant au plan économique qu'au plan diplomatique 50 années de compromission systématique, on est quand même en droit de se dire que ce ne serai, finalement, pas une si mauvaise idée.
Maintenant, on peut toujours faire l'union sacré contre les Barbares et y sacrifier nos libertés, les État Unis, qui au passage ne reconnaissent pas la CPI, en tête
Comprend pas pourquoi tu aurais besoin d’un système spécial pour ça.
Justement pour éviter d'avoir a maintenir ce que tu appelles les scripts maîtres ou autres makefile.
Ce n'est pas a proprement parlé un besoin. C'est exactement comme la double exécution que tu peux tout a fait gérer dans ton script avec un flag quelconque. C'est juste le petit truc en plus qui te simplifie grandement la vie.
Cad, les dépendances sur les jobs ? Activé un premier job quand le 2eme se termine ?
C'est plus ou moins l'idée. Lorsque tu as besoin d'effectuer des traitements lourds sur des données‚ le fait de disposer d'un scheduler capable de traiter les dépendances entre les jobs permet de simplifier grandement l'écriture des scripts de traitement. Par simplifier j'entends rendre plus robuste.
Par exemples sur une séquence classique telle que : vérifier qu'on est en maintenance, dumper des bases‚ aller récupérer des données via un web service‚ consolider la base selon les données reçues‚ extraire les statistiques‚ tout archiver et remettre en route avant la fin de ta fenêtre de maintenance … Tu as de nombreux cas d'échec possible de nombreux trucs qui peuvent foirer. Tu te retrouves donc facilement a maintenir des scripts gigantesque ne serai-ce que pour gérer tous les cas d'erreur.
Si ton scheduler gère les dépendances type ne lance cette tâche que si celle ci a réussi‚ lance celle la si telle aitre a echouée‚ alors tu peux te contenter de scripts simples faisant une chose et une seule. Facile a écrire et a maintenir.
Je ne suis pas sûr que la possibilité d'avoir plusieurs formes encourage la lecture. De toute façon comme tout ce qui concerne le temps ça fait facilement des nœuds au cerveau à la moitié de la planète.
Je n'ai pas testé systemd comme scheduler. Mais pour moi, ce n'est certainement pas la syntaxe qui en fera un meilleur logiciel que cron. Par contre, s'il est possible gérer des dépendances entre les jobs, d'éviter qu'un script ne se lance tant qu'il est en cours d’exécution, de tuer une tâche qui prends trop de temps … là j'y trouverai un sérieux remplaçant.
Tout d'abord, il ne faut pas oublier que Varnish seul est également une option. Il fait également répartiteur de charge. Il a besoin de la libgcc pour compiler sa conf. Je ne trouve pas que ce soit vraiment un problème. Quelqu'un qui peut uploder et compiler un exploit, pouvant également uploader un binaire statique.
Pour répondre à ta question, je dirais que tout dépend avant tout de celui que tu connais le mieux et du temps que tu es prêt à passer pour apprendre.
Nginx offre de nombreuses possibilités en particulier parce qu'il est scriptable en lua et qu'il dispose de nombreux modules. CloudFlare par exemple l'utilise massivement. Mais il faut souvent le patcher pour ceci ou pour cela. Par exemple support du verbe PURGE.
Varnish est très performant niveau cache, en particulier grâce à la possibilité de pousser une conf dynamiquement et d'utiliser les ESI.
Haproxy offre des possibilités en terme de répartition de charge et de gestion des connexions que les autres n'ont clairement pas.
Bref a mon avis, ce qui est important est de très bien connaitre les softs que tu met en oeuvre. Donc celui avec lequel tu as le plus d'affinité conviendra très bien.
Je pensais partir sur une solution simple et je suis arrivé PostgreSQL + Memcached + Django + uWSGI + Nginx + Varnish (et peut-être HAProxy à venir).
Utiliser un logiciel bien adapté pour chaque tâche est souvent plus simple qu'un gros serveur qui fait tout.
Des fois je me dis que cela ressemble plus à de l'alchimie qu'à une science ! ;-)
Rien n’empêche de piloter son travail par des tests. C'est une démarche encore bien rare au niveau de l'administration système en général et de l’hébergement web en particulier.
La première question à se poser est celle de savoir comment je détermine si mon application fonctionne. Quels sont les scenarii de visite ? quels sont les temps souhaités d'affichage des différentes pages ? quel est le nombre de visiteurs attendu ? quel est le volume maximal de données attendu ?
A partir de ces données tu dois écrire au moins deux types de tests :
des scenarii de visite pour les tests de charge
des sondes applicatives pour le fonctionnement en production
La bonne exécution des tests ne comprend pas seulement leur réussite, mais leur réussite dans le temps impartie.
A partir de là si tu travailles en preprod avec des données abondantes, tu es blindé.
En second point, l'analyse des logs doit être systématique. Chaque erreur doit être comprise, reproduite et corrigée.
Enfin, il faut prévoir tous les cas de panne. Qu'est-ce que je fais en cas du :
failure d'un composant logiciel (serveur qui segfault, noeuds qui tombent en cascade).
bug applicatif plantant l'appli (requête magique qui fait péter python …)
dépassement du type de visiteur (au fait tu sais quoi, on passe à la télé …)
Chaque cas, doit faire l'objet à minima d'une procédure au mieux d'un traitement automatisé.
La même démarche doit s'appliquer à la sécurité.
Maintenant comme je te le disais, dans le monde du web, les gens voulant travailler ainsi sont bien rares ou on une taille telle que cela se justifie pleinement. Dans la plupart des cas, il faut se démerder au pifomètre sans même quelqu'un qui connait le code et dans se cas, effectivement, il vaut mieux avoir du métier.
Sauf que ça veut dire que l'utilisateur n'a pas à toucher un seul fichier de conf. Pour un admin système, ce n'est pas vraiment un problème, pour un type qui n'a jamais fait ça, c'est un avantage
Si c'est un vrai problème. Quand le type se fera (et ça arrivera) défoncer son wordpress et que l'admin sys passera des heures à essayer de lui expliquer pourquoi il faut qu'il vire le plugin machin qui l'oblige à avoir 12 versions de wordpress de retard.
Faire croire qu'on peut héberger sérieusement une application web sans que personne, ni chez l'hébergeur, ni chez le webmaster, ni chez l'éditeur n'assure une expertise applicative sérieuse est juste une immense supercherie. A un moment ou a un autre, face à un problème de sécurité, de performances, un plantage, il faut quelqu'un pour mettre le nez dans le code.
[^] # Re: Une précision
Posté par Joris Dedieu (site web personnel) . En réponse à la dépêche Une faille nommée « shellshock ». Évalué à 3.
deux choses par ailleurs.
Le shell système par défaut sous FreeBSD n'est pas tcsh mais sh. (tcsh est le shell de root tout pareil que dash / bash sous debian).
Avec haproxy
reqdeny ()\ {dans les frontends permet de bloquer les tentatives d'exploit.[^] # Re: Plutôt beauté du design
Posté par Joris Dedieu (site web personnel) . En réponse au journal "beauté du code". Évalué à 6.
Beau‚ ce n'est pas forcément utile ou agréable ou dans le cas qui nous occupe ici maintenable.
A mon avis ce qui caractérise le beau c'est justement lorsqu'il y a quelque chose qui dépasse les qualités fonctionnelles du produit. Si tu prends par exemple le code de apache 1.3, il etait loin d'être maintenable et souffrait de problèmes de design important. A vrai dire c'était une série de hacks avec des ifdef spaghetti dans tous les sens. Mais finalement cela en faisait un morceau tellement essentiel du l'histoire de l'informatique qu'il avait une beauté certaine.
En le lisant, tu pouvais découvrir l'évolution des systèmes, leur parenté‚ leurs manques. Les tentatives diverses pour avoir des ipc efficaces‚ des codages de caractères insoupsonnés‚ des hacks pour résoudre toutes sorte de problème qui ont émaillés l'histoire du web.
Bref tu te retrouves devant des morceaux de codes qui te font voyager dans le temps‚ devant l'intention de programmeurs désarmés face a des problèmes nouveaux et qui finalement imaginent des solutions pas si éloignées des outils actuels …
Un tel code est une horreur a maintenir et a de grosses limites en efficacité. Pourtant il reste d'une beauté émouvante et a mon avis difficilement contestable.
[^] # Re: Demande aux développeurs
Posté par Joris Dedieu (site web personnel) . En réponse au message Fichier /etc/hosts non pris en compte par les logiciels. Évalué à 3. Dernière modification le 26 septembre 2014 à 15:00.
Il faut peut-être être plus nuancé. Pour un soft qui a ponctuellement besoin de connaître l'ip d'une machine à un instant t, nss est tout à fait satisfaisant et ne pas l'utiliser tient du bug.
Pour un logiciel qui traite massivement du DNS, comme un serveur smtp (plusieurs requêtes par mail), alors la libc n'est clairement pas satisfaisante.
NSS ne donne pas suffisamment d'information (MX, DKIM, TTL, interrogation d'un serveur spécifique pour les RBL …).
resolver(3) (qui au passage ne lit pas, me semble-t-il le fichier hosts - à confirmer) n'est pas réputé pour sa performance, comparé aux librairies venant de unbound par exmple
# Le fichier hosts
Posté par Joris Dedieu (site web personnel) . En réponse au message Fichier /etc/hosts non pris en compte par les logiciels. Évalué à 5. Dernière modification le 26 septembre 2014 à 14:49.
Le fichier hosts et la résolution DNS sont deux choses distinctes.
La résolution DNS, comme son nom l'indique sert à chercher des informations sur les serveurs de nom renseignés dans /etc/resolv.conf.
Le fichier hosts est l'un des fichiers de configuration de la base de données système hosts qui fait partie du sous système nss (au même titre que les bases de données passwd, group, services …)
D'ailleurs en supposant que tu es mis toto.com dans ton fichier /etc/hosts tu peux observer que tu n'as pas le même résultat en faisant
getent hosts toto.cometdig +short toto.com.La base de données hosts est souvent configuré de façon à ce que si une entrée n'est pas dans le fichier hosts, elle soit retrouvée par le resolver de la libc (res_query). Mais cela n'a rien d'obligatoire.
Bref la base de données hosts n'est pas la résolution DNS et inversement.
Il n'est pas rare que pour des raisons de performances des softs utilisent un resolver différent que celui de la libc. Notamment pour ce qui concerne les mails, très gourmands en requêtes dns. Dans certains cas, les appels à nss ne sont pas satisfaisants. Les programmes ont tout à fait le droit d'effectuer des requêtes plus complexes (MX, SPF, DKIM …). Ils peuvent également gérer leur propre cache et dans ce cas, ils ont besoin d'avoir toutes les infos.
Par exemple, imagine que ton serveur de mail fasse juste un appel à nss pour résoudre son smarthost.
Alors que si il fait une requête DNS, il a la totalité du résultat avec toutes les ips possibles et l'information du TTL qui lui permet de gérer sa mise en cache des informations.
…
Ceci mis à part :
1 - la resolution dns dans postfix se configure finement :
smtp_host_lookup=native devrait t'aider par exemple
2 - le fichier hosts ne sert pas à tricher mais à donner les IP d’hôtes qui n'ont pas de résolution DNS (nommer les liens locaux par exemple).
3 - Si tu veux tricher, la bonne méthode est q'utiliser un resolver qui sait le faire tel que unbound.
# umount
Posté par Joris Dedieu (site web personnel) . En réponse au journal Mettez du Debian et du ArchBSD dans votre FreeBSD : mkjl.sh. Évalué à 10.
umount marche mais ton devfs est monté deux fois. A mon avis tu peux faire plus propre sur ce coup là :)
# Bravo
Posté par Joris Dedieu (site web personnel) . En réponse au journal Installation GNU/Linux avec un SSD en plus.... Évalué à 10. Dernière modification le 21 septembre 2014 à 19:52.
Bravo pour ton journal. Il est clair, agréable à lire, intéressant.
Bravo pour la démarche. Pour avoir fait le même genre de choses durant quelques temps, j'ai vite perdu patience à essayer d'être michu compliant.
Bravo pour l'idée du SSD. Elle est juste simple et … juste
[^] # Re: tu as pensé aux ACLs dans squid ?
Posté par Joris Dedieu (site web personnel) . En réponse au message Bloquer certains sites en https avec Squid/SquidGuard. Évalué à 2.
Oui sauf que pour une bonne partie des sites à bloquer tu vas tomber sur des IPs qui changent sans arrêt type cdn dont tu n'auras jamais la liste exhaustive.
[^] # Re: logs php
Posté par Joris Dedieu (site web personnel) . En réponse au message Connexion impossible à un serveur MySQL. Évalué à 2.
A partir de 5.5 tu peux mettre log_warning à 2 pour avoir cette info dans les logs. En dessous c'est mort à moins d'activer les log généraux (qui vous tout logguer y compris les requêtes).
[^] # Re: tu as pensé aux ACLs dans squid ?
Posté par Joris Dedieu (site web personnel) . En réponse au message Bloquer certains sites en https avec Squid/SquidGuard. Évalué à 2.
En https le header Host: est passé après l'établissement de la la connexion chiffrée.
# logs php
Posté par Joris Dedieu (site web personnel) . En réponse au message Connexion impossible à un serveur MySQL. Évalué à 4.
Bonjour,
Il est probable qu'un script ait de mauvaises informations de connexion. Dans le cas du php, tu actives le error_reporting et tu place log_error à On. Ainsi tu auras dans les logs d'erreur du serveur web des "access denied" et le script d'origine
[^] # Re: Solutions
Posté par Joris Dedieu (site web personnel) . En réponse au message FAI: Renater, comment éviter la restriction des protocoles ?. Évalué à 3.
Plus simple, tu trouves un gentil serveur. Tu configures ssh pour qu'il écoute sur le port 443 et tu te fais un proxy socks
[^] # Re: Gluster remplit sa fonction
Posté par Joris Dedieu (site web personnel) . En réponse au message Gluster, des explications svp. Évalué à 3.
DRBD fait de la réplication au niveau bloc. Avec un système de fichier tel que GFS2, tu peux monter un cluster actif/actif. C'est la solution généralement retenue pour mettre en place le setup dont tu parles.
Gluster est conçu pour les clusters de stockage. Ce cas d'usage fonctionne peut-être par effet de bord mais ce n'est pas la destination première du projet.
[^] # Re: Guerre contre le terrorisme
Posté par Joris Dedieu (site web personnel) . En réponse au journal "Le filtrage administratif, encore, vraiment ?" par Benjamin Bayart. Évalué à 3.
Il y a ceux la mais aussi ben Ali, Kadhafi‚ Saddam Hussein et tous les autres, que nous avons armés‚ légitimité s mordicus‚ souvent contre leurs peuples ‚ créant ainsi les conditions du chaos.
Ce qui se passe aujourd'hui se prépare depuis les années 70. Pense a l'État d'urgence en Égypte (1981 - 2013) ou encore a la terreur algérienne des années 90.
[^] # Re: Guerre contre le terrorisme
Posté par Joris Dedieu (site web personnel) . En réponse au journal "Le filtrage administratif, encore, vraiment ?" par Benjamin Bayart. Évalué à 10. Dernière modification le 16 septembre 2014 à 13:01.
Si l'islamisme est si populaire, c'est que les mosquées se sont imposées dans les pays dits Arabes comme des lieux d'opposition, de solidarité et de parole. Pendant ce temps nous soutenions, nous les Occidentaux ou la Russie pour des raisons plus ou moins avouables, les régimes infects du Moyen-Orient et d'Afrique du Nord, qui sont des émanations de la décolonisation et de la guerre froide. Nous avons maintenus mordicus nos grand amis au détriment des peuples. Là dessus, les EU ont créés les conditions du chaos en Irak en détruisant l'appareil d'État sans préparation préalable. Les frappes ciblés et les printemps arabes ont finis de semer la gouaille un peu partout.
Alors qui a commencé cette guerre ? Je ne saurais pour ma part le dire, même si j'aurais tendance à penser que nous n'y sommes pas pour rien.
Ce qui est sûr, c'est que si au lieu d'aller tremper notre cul sur les plages de nos grands amis et de fourbir les armes à des décennies de répression et d'écrasement des peuples, nous avions menés une politique conforme à nos principes, en soutenant activement les mouvements pour la liberté et la démocratie, en offrant un asile sans complexe aux opposants politiques, en offrant des bourses aux étudiants, bref en soutenant correctement les opposants qui depuis les années 70 se battent dans le monde Arabes contre des régimes répressifs et corrompus, et surtout en arrêtant d'armer leurs bourreaux nous n'en serions certainement pas là.
Est-il trop tard ? Sans doute. Pourtant, le Liban et paradoxalement l'Iran sont sans doute les pays les plus porteurs d'espoir dans la région. Dans ces deux pays, la jeunesse en pète et rêve de liberté, de paix et de démocratie. Saurons nous les soutenir ? Saurons nous soutenir vraiment l'opposition Syrienne quitte a nous passer du gaz Russe ? Saurons nous accompagner activement les démocrates Tunisiens, Algériens quitte à finir de livrer aux Chinois notre influence en Afrique du Nord ? La paix à un prix. Celui de sacrifier des intérêts économiques immédiats a nos principes au lieu de prostituer cette République dont nous aimons tant nous gargariser à nos client et amis. Quand on voit ce que donnent tant au plan économique qu'au plan diplomatique 50 années de compromission systématique, on est quand même en droit de se dire que ce ne serai, finalement, pas une si mauvaise idée.
Maintenant, on peut toujours faire l'union sacré contre les Barbares et y sacrifier nos libertés, les État Unis, qui au passage ne reconnaissent pas la CPI, en tête
# Tu as oublié de rebooter
Posté par Joris Dedieu (site web personnel) . En réponse au journal Faire coexister plusieurs versions de la Glibc. Évalué à 2.
https://linuxfr.org/sondages/faut-il-rebooter-apr%C3%A9s-avoir-d%C3%A9sinstall%C3%A9-la-glibc
[^] # Re: "Au final, ce sont les fanboys qui ont dû être bien déçus…"
Posté par Joris Dedieu (site web personnel) . En réponse au journal Et comme prévu, ça a fait... pffffuit. Évalué à 3.
Ce n'est pas le cas de la rougeole qui était une cause importante de mortalité infantile.
[^] # Re: troll velu avec systemd
Posté par Joris Dedieu (site web personnel) . En réponse au journal Sur systemd, btrfs & co. Évalué à 4.
Justement pour éviter d'avoir a maintenir ce que tu appelles les scripts maîtres ou autres makefile.
Ce n'est pas a proprement parlé un besoin. C'est exactement comme la double exécution que tu peux tout a fait gérer dans ton script avec un flag quelconque. C'est juste le petit truc en plus qui te simplifie grandement la vie.
[^] # Re: troll velu avec systemd
Posté par Joris Dedieu (site web personnel) . En réponse au journal Sur systemd, btrfs & co. Évalué à 3.
C'est plus ou moins l'idée. Lorsque tu as besoin d'effectuer des traitements lourds sur des données‚ le fait de disposer d'un scheduler capable de traiter les dépendances entre les jobs permet de simplifier grandement l'écriture des scripts de traitement. Par simplifier j'entends rendre plus robuste.
Par exemples sur une séquence classique telle que : vérifier qu'on est en maintenance, dumper des bases‚ aller récupérer des données via un web service‚ consolider la base selon les données reçues‚ extraire les statistiques‚ tout archiver et remettre en route avant la fin de ta fenêtre de maintenance … Tu as de nombreux cas d'échec possible de nombreux trucs qui peuvent foirer. Tu te retrouves donc facilement a maintenir des scripts gigantesque ne serai-ce que pour gérer tous les cas d'erreur.
Si ton scheduler gère les dépendances type ne lance cette tâche que si celle ci a réussi‚ lance celle la si telle aitre a echouée‚ alors tu peux te contenter de scripts simples faisant une chose et une seule. Facile a écrire et a maintenir.
[^] # Re: troll velu avec systemd
Posté par Joris Dedieu (site web personnel) . En réponse au journal Sur systemd, btrfs & co. Évalué à 1.
Je n'ai jamais été suffisamment intime avec windows pour m'en rendre compte
[^] # Re: troll velu avec systemd
Posté par Joris Dedieu (site web personnel) . En réponse au journal Sur systemd, btrfs & co. Évalué à 3.
Et avec systemd, tu dis ça comment ?
Tue *-*-* 10:00/5:00???ou encore
Tue, 10:00/5(si j'en crois le man en tout cas)Je ne suis pas sûr que la possibilité d'avoir plusieurs formes encourage la lecture. De toute façon comme tout ce qui concerne le temps ça fait facilement des nœuds au cerveau à la moitié de la planète.
Je n'ai pas testé systemd comme scheduler. Mais pour moi, ce n'est certainement pas la syntaxe qui en fera un meilleur logiciel que cron. Par contre, s'il est possible gérer des dépendances entre les jobs, d'éviter qu'un script ne se lance tant qu'il est en cours d’exécution, de tuer une tâche qui prends trop de temps … là j'y trouverai un sérieux remplaçant.
[^] # Re: LUKS
Posté par Joris Dedieu (site web personnel) . En réponse au journal Réinstallation d'un Eee PC 901 avec une distribution récente. Évalué à 10.
Tu dois penser à LVM
[^] # Re: Nginx ou HAProxy + Varnish
Posté par Joris Dedieu (site web personnel) . En réponse à la dépêche HAProxy 1.5. Évalué à 6.
Tout d'abord, il ne faut pas oublier que Varnish seul est également une option. Il fait également répartiteur de charge. Il a besoin de la libgcc pour compiler sa conf. Je ne trouve pas que ce soit vraiment un problème. Quelqu'un qui peut uploder et compiler un exploit, pouvant également uploader un binaire statique.
Pour répondre à ta question, je dirais que tout dépend avant tout de celui que tu connais le mieux et du temps que tu es prêt à passer pour apprendre.
Nginx offre de nombreuses possibilités en particulier parce qu'il est scriptable en lua et qu'il dispose de nombreux modules. CloudFlare par exemple l'utilise massivement. Mais il faut souvent le patcher pour ceci ou pour cela. Par exemple support du verbe PURGE.
Varnish est très performant niveau cache, en particulier grâce à la possibilité de pousser une conf dynamiquement et d'utiliser les ESI.
Haproxy offre des possibilités en terme de répartition de charge et de gestion des connexions que les autres n'ont clairement pas.
Bref a mon avis, ce qui est important est de très bien connaitre les softs que tu met en oeuvre. Donc celui avec lequel tu as le plus d'affinité conviendra très bien.
[^] # Re: HAProxy + Nginx + Varnish + Webserver
Posté par Joris Dedieu (site web personnel) . En réponse à la dépêche HAProxy 1.5. Évalué à 5.
Utiliser un logiciel bien adapté pour chaque tâche est souvent plus simple qu'un gros serveur qui fait tout.
Rien n’empêche de piloter son travail par des tests. C'est une démarche encore bien rare au niveau de l'administration système en général et de l’hébergement web en particulier.
La première question à se poser est celle de savoir comment je détermine si mon application fonctionne. Quels sont les scenarii de visite ? quels sont les temps souhaités d'affichage des différentes pages ? quel est le nombre de visiteurs attendu ? quel est le volume maximal de données attendu ?
A partir de ces données tu dois écrire au moins deux types de tests :
La bonne exécution des tests ne comprend pas seulement leur réussite, mais leur réussite dans le temps impartie.
A partir de là si tu travailles en preprod avec des données abondantes, tu es blindé.
En second point, l'analyse des logs doit être systématique. Chaque erreur doit être comprise, reproduite et corrigée.
Enfin, il faut prévoir tous les cas de panne. Qu'est-ce que je fais en cas du :
Chaque cas, doit faire l'objet à minima d'une procédure au mieux d'un traitement automatisé.
La même démarche doit s'appliquer à la sécurité.
Maintenant comme je te le disais, dans le monde du web, les gens voulant travailler ainsi sont bien rares ou on une taille telle que cela se justifie pleinement. Dans la plupart des cas, il faut se démerder au pifomètre sans même quelqu'un qui connait le code et dans se cas, effectivement, il vaut mieux avoir du métier.
[^] # Re: age : 20 years
Posté par Joris Dedieu (site web personnel) . En réponse au journal L'arbre des ports de FreeBSD a vingt ans. Évalué à 10.
3615 FreeBSD
[^] # Re: Blague?
Posté par Joris Dedieu (site web personnel) . En réponse au journal asp.NET vNext, MVC 6, Entity Framework 7, Roslyn, Microsoft continue à libérer ses technologies .... Évalué à 3.
Si c'est un vrai problème. Quand le type se fera (et ça arrivera) défoncer son wordpress et que l'admin sys passera des heures à essayer de lui expliquer pourquoi il faut qu'il vire le plugin machin qui l'oblige à avoir 12 versions de wordpress de retard.
Faire croire qu'on peut héberger sérieusement une application web sans que personne, ni chez l'hébergeur, ni chez le webmaster, ni chez l'éditeur n'assure une expertise applicative sérieuse est juste une immense supercherie. A un moment ou a un autre, face à un problème de sécurité, de performances, un plantage, il faut quelqu'un pour mettre le nez dans le code.