Joris Dedieu a écrit 1614 commentaires

Alors, oui le port côté client est choisi de manière aléatoire sauf cas TRES spécifique (que je n'ai jamais vu en pratique dans des softs "sérieux" même si les lib le permettent).

ntpd

j'avais deux serveurs dédiés chez OVH, et un jour ils ont annoncé la mise en place de mesure anti-dos.
Lorsque ce fut "activé", la communication SSH entre mes deux serveurs à été perturbée.

Finalement, s'ils t'avaient juste mis en blackhole‚ le résultat aurait été le même. On se demande bien pourquoi ils se font chier a détecter et mitiger les DOS quand il suffit de couper le client en attendant que cela passe …

A mon boulot, on est en train de faire la peau a ce type de redirections. Et ce pour la simple raison qu'elles ne marchent globalement plus.

Plusieurs raisons a cela :

• lorsque le destinataire final clique sur ceci est un spam‚ c'est toi qui est vu comme spammer.

• tu vas forcément a l'encontre des politiques spf. Autrement dit tu envoie des mails en utilisant des noms de domaines qui ne t'autorisent pas a le faire.

• le destinataire final‚ souvent chez yahoo‚ hotmail‚ orange‚ va forcément recevoir par ton intermédiaire des mails from yahoo‚ hotmail orange. Ce qui sera considéré comme suspect par ledit fournisseur a raison.

Moralité, si dans le détail, les .forward interdomaine marchent encore, globalement, ce n'est plus le cas. Si tes mails passent le filtre ovh, tu auras bien des cas ou ils seront refusés, voir droppés. Cela risque de te mettre en délicatesse avec tes clients qui naturellement vont se retourner vers toi pour comprendre pourquoi cela ne marche plus et pour lesquels tu ne pourra pas faire grand chose.

A mon avis vu l'usage aujourd'hui la seule bonne solution est de délivrer tes mails localement. La plus part des fournisseurs de webmail proposent aujourd'hui des fonctionnalités de type fetchmail, prévues justement pour ce type de cas.

Un bon indicateur en général est l'utilisation du swap (avec la commande free par exemple). Qui te laissera voir si ta machine manque de mémoire vive. Tu peux alors trouver les process consommateurs en regardant la mémoire résidente (RES) dans htop/top …

L'autre chose à voir est si le noyau te dis des choses (dmesg), erreurs de disque, kernel oups, connexion qui bagotte (link up / link down) …

Enfin tu peux regarder du côté réseau. Faire par exemple une capture avec wireshark et voir s'il y a des pertes de paquets.

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.

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.

# Populate pacman keyring inside the jail
jail -c path=/usr/jails/$hostname mount.devfs command=/usr/bin/pacman-key --init
jail -c path=/usr/jails/$hostname mount.devfs command=/usr/bin/pacman-key --populate archbsd
# Clean
# umount is invoked 2 times or it won't work
umount /usr/jails/$hostname/dev
umount /usr/jails/$hostname/dev

umount marche mais ton devfs est monté deux fois. A mon avis tu peux faire plus propre sur ce coup là :)

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

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).

et simplement utiliser les ACLs de squid pour interdire ces domaines et laisser passer les autres ?

En https le header Host: est passé après l'établissement de la la connexion chiffrée.

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

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

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

https://linuxfr.org/sondages/faut-il-rebooter-apr%C3%A9s-avoir-d%C3%A9sinstall%C3%A9-la-glibc

Et oui enfant ce sont des maladies benignes

Ce n'est pas le cas de la rougeole qui était une cause importante de mortalité infantile.

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.

Tu te rends compte que tu viens de décrire ce que fait le planificateur de tâches Windows depuis plus d'une décennie ?

Je n'ai jamais été suffisamment intime avec windows pour m'en rendre compte

*/5 10 * * 2 /usr/local/bin/yourjob

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.

Tu dois penser à LVM