Joris Dedieu a écrit 1610 commentaires

Peut être y aurait-il moyen avec le modèle de pondérer l'effort en fonction des changements de direction nécessaires

Cela ne peut pas se régler plus simplement en permettant à l'utilisateur de pondérer chaque route / carrefour / trajet en fonction de sa cyclofrienditude. Ça évite de complexifier l'algo outre mesure tout en tenant compte à la marge de l’expérience des utilisateurs. En plus ça rajoute un aspect participatif.

Ça apporte beaucoup en terme de sécurité parce que ça donne, par défaut (sans rien avoir installé d'autre que le serveur ssh) un nom d'utilisateur connu pour faire un bruteforce.

Beaucoup vraiment ? Personnellement je veux être sûr que personne ne pourra se loguer même s'il découvre un nom d'utilisateur au hasard d'une fullpath disclosure ou simplement en faisant le lien entre un serveur et une prénom ou parce qu'un abrutit aura eu la mauvaise idée de créer un utilisateur test / test, admin / admin ou je ne sais encore quelle erreur. Postuler qu'un élément aussi trivial qu'un login soit inconnu est je pense une erreur.

Alors oui, empêcher le Root login complexifie un peu le brut forçage qui soit dit en passant dans la plupart des cas réels que j'ai vu sont juste l'application d'un dictionnaire basique qui ne marchera qu'en cas d'erreur de config (admin/admin, test/test, root / 1234 …).

Une distribution doit proposer de bons réglages de sécurité par défaut: lorsque l'on installe postfix, il n'est pas en mode open relay.

Une autre approche serait sans doute de ne pas lancer systématiquement par défaut, un daemon qu'on installe parfois simplement en dépendance. C'est ce que d'autres font en tout cas.

C'est pour cela que dans Debian la configuration par défaut de sshd permet de se connecter en tant que root :)

Le PermitRootLogin à no est sans doute une bonne pratique notamment pour ne pas avoir plus de privilèges qu'on en a réellement besoin. Ceci dit en terme de sécurité ça n'apporte vraiment pas grand chose.

Si tu veux renforcer la sécurité de ton serveur ssh exige une clé.

http://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/85088528028b88399264dd4c006aeff001bbeb6b

Personnellement je m'en été sortie il y a dix ans avec un bilan de compétences. Il s'agit d'une démarche accompagnée qui vise à faire le point sur ses compétences, ses aptitudes et ses motivations. C'est un droit. Tu peux demander à pole emploi, ils ne peuvent pas te le refuser.

Ce n'est pas toujours une experience positive. Cela dépend énormément de la personne qui t'accompagne. Certaines personnes que je connais ont eu le sentiment d'y perdre leur temps. Pour moi ça a été un moment décisif de ma vie. Cela m'a énormément aidé à faire des choix et en définitive permis de changer d'orientation.

Ce n'est donc pas un conseil mais sache que ça existe et que parfois, ça fonctionne.

Pour l'usage de /usr je ne sais pas trop pourquoi, ils aiment bien mettre des choses dedans (les ports installés, les homes…). On s'habitue.

J'avais lu quelque part qu'historiquement /usr était placé sur une seconde bande plus grande mais moins rapide que celle contenant le noyau et les éléments pour booter.

Ben non virtio n'est pas obligatoire sous KVM.

Sous Xen en HVM non plus. Il utilise QEMU dans ce cas, au même titre que kvm.

L'avantage de Xen est clairement la paravirtalisation qui permet par exemple l'ajout de processeur ou de RAM à chaud et qui à mon avis fournie une bien meilleure montée en charge sur les IO.
Ceci étant dit sans dénigrer KVM.

c'est bien à moi que tu réponds ? en fait je parlais d'une connexion Wifi

En grattant un peu, il doit y avoir d'autres vecteurs. L'IP étant toujours la même, tu dois pouvoir manipuler l'interface en javascript à partir d'une page web quelconque.

C'est pas parce que des homophobes mélangent tous les sujets en accusant que les homos du problème que ça en fait une vérité

Et ça ne fait pas non plus une absence de problème. Depuis l’avènement du divorce, de l'union libre et des familles recomposés, la filiation a été profondément modifiée. C'est un fait qui change beaucoup de choses en terme d'adoption, de succession, de droit de garde … etc … Hors on reste sur des lois se basant sur la famille normée papa / maman, leur labrador et ses petits.

Le manque de courage politique fait que cet item n'est jamais traité. Le PACS l'a soigneusement évité, le mariage pour tous aussi. Je trouve que quitte a se payer une excommunication, la moindre des choses était de s'attaquer au problème de fond (qui comme tu le dis concerne tout le monde) et ne pas traiter les choses une fois de plus par le petit bout de la lorgnette.

Une fois cette question de la filiation réglée, le "mariage pour tous" n'aurait été qu'une formalité.

je ne vois pas en quoi ça devrait être un droit

Avoir accès a sa propre histoire, ne te sembles pas une raison suffisante ?

Dans le cas idéal, bien sûr tous les enfants adoptés, savent d’où ils viennent et dans quelles circonstances leur naissance particulière les a conduit là ou ils sont. Mais c'est loin d'être la règle. On ment aux enfants, on les bats, on les maltraites, on les négliges… La société adulte, si elle ne peut éviter tous les drame peut au moins fixer un cadre qui permet d'en minimiser l'impact. Le droit de savoir qui sont ses parents biologiques me semble juste un moyen d'essayer de faire en sorte que dans le pire des cas, l'amputation ne soit pas forcement définitive.

C'est d'ailleurs ce que je regrette un peu avec cette loi (avec laquelle je suis plutôt d'accord). Un texte préalable sur la filiation m'aurait semblé nécessaire histoire de ne pas tout mélanger.

Les théories de Freud n'ont jamais été démontrée pour la plupart !

Si Freud a été un peu merdique sur ce point (comme tout bon médecin en employant l'expression de "science psychanalytique"), la psychanalyse n'a jamais prétendu être une démarche scientifique. Le sujet d'étude lui même, à savoir la subjectivité est d'ailleurs à l'antithèse de tout ce que la science peut prétendre aborder.
Elle n'est pas non plus du soin. Le problème n’étant pas le symptôme mais la souffrance qu'il génère, il ne s'agit pas de guérir mais de se réapproprier ce qui est soi pour apprendre à vivre avec.

La ou l'approche thérapeutique va viser à donner les moyens au sujet de faire face à sa difficulté : moyens chimiques (medocs), psycho-techniques (relaxation, pensée positive, sophrologie), conditionnement (thérapie comportementale). La psychanalyse cherche avant tout à amener le sujet à inscrire la difficulté dans son histoire. Cela ne la fera pas forcement disparaître mais lui donnera un sens et permettra l'appropriation (c'est ma peur, ma tristesse) et finalement la liberté et le choix. Ce qui explique d'ailleurs qu'elle soit - contrairement à la religion ou à la psychiatrie - toujours bannie par les dictatures quelles quelles soient.

Dans le cadre de cette démarche, la psychanalyse a développé des outils théoriques sur lesquels s’appuyer (typiquement des études de cas - ce qui constitue d'ailleurs la majorité de l’œuvre de Freud). Ces outils, par le regard nouveau qu'ils ont apporté sur la subjectivité, le langage, les interactions sociales ont été un moteur important pour les sciences humaines et en particulier l’anthropologie.

Je te recommande de parcourir "L'histoire de la folie à l'age classique" de Michel Foucault et "Les enfants de Sanchez" d'Oscar Lewis, comme préalable, si tu t’intéresses à la question.

feraient bien de mettre en œuvre les enregistrements de service

Ça n'a visiblement pas l'air si simple que ça. http://lists.w3.org/Archives/Public/ietf-http-wg/2012OctDec/0320.html

Ou imapsync

Il faudrait probablement que je mette en oeuvre un cache d'opcode PHP dessus pour voir ce que cela donne.

Sur du Wordpress, tu peux aussi utiliser Super Cache ou Total Cache. Bien configuré ça réduira sensiblement la latence.

http://codex.wordpress.org/WordPress_Optimization/Caching

Trois choses :

• L'unité au niveau licence n'est pas un objectif majeur en soit. C'est éventuellement un plus.

• DragonFlyBSD essaye de supporter un maximum de compilateurs

• Le C++ doit être évité si possible. Il est avant tout exclus dans la libc et du noyau

• Ce qui compte avant tout c'est la qualité du code, les fonctionnalités, la rapidité. C'est à ce niveau qu'est le débat.

  http://lists.dragonflybsd.org/pipermail/users/2012-October/017562.html

Ici par exemple la façon dont c'est géré sous FreeBSD. Personnellement, ça ne me semble pas monstrueux.

haproxy_reload()
{
        # Check configuration file quietly first
        ${command} -q -c -f ${haproxy_config}
        if [ $? -ne 0 ]; then
                err 1 "Error found in ${haproxy_config} - not reloading current process!"
        fi
        rc_pid=$(check_pidfile ${haproxy_pidfile} ${command})
        if [ $rc_pid ]; then
                if [ $rc_force ]; then
                        ${command} ${haproxy_flags} -st ${rc_pid}
                else
                        ${command} ${haproxy_flags} -sf ${rc_pid}
                fi
        else
                err 1 "No process found.  Maybe $command isn't running?"
        fi
}

Sinon je vois pas, si il est chrooté, sa config l'est aussi non

Bien sûr que non. Il se chroote dans un répertoire vide (typiquement /var/empty). Donc il ne peut pas relire sa config.

je vois pas ce qui empêche de faire ça dans un seul process sans le tuer

Le fait que ce process soit chrooté.

Donc un proxy raisonnablement générique n'a pas vraiment d'autre choix que de redémarrer à chaque changement de config

Par ailleurs un changement de config n'est nécessaire que lorsque ta topologie est modifiée. Pour les opérations courantes comme les maintenances de serveur, tu disposes d'une socket de contrôle te permettant de les réaliser à chaud.

les anciens clients restent avec l'ancienne config

Le temps de finir leur connexion, oui. Pour moi c'est essentiel. Sinon ils se retrouvent avec un "connexion réinitialisé" dans leur navigateur. Ça fait pas très propre. C'est également ce que fait apache quand tu fais un graceful. Le fils ne meure que quand il a fini les requêtes en cours.

Par ailleurs, il est également possible de demander de terminer les sessions immédiatement tout en gardant la sécurité de savoir que le nouveau processus est prêt avant de tuer l'ancien.

Dans ce cas il y a un truc que je ne pige pas : c'est quoi la différence entre un reload et un restart ?

Un reload :
- lancer un nouveau processus
- si failed ne rien faire
- dire à l'ancien de ne plus écouter sur le réseau (les nouveaux clients vont sur le nouveau processus)
- dire à l'ancien de mourrir quand il a fini avec ses clients

Un restart :
- tuer l'ancien processus
- en lancer un nouveau

Systemd ne comprend pas HAProxy qui à une façon particulière de se recharger. On ne parle pas de redemarrer - stop puis start - mais de se recharger de façon transparente pour les clients.

Un gars à proposé un patch qui consiste à conserver un processus qui ne fait rien d'autre qu'attendre que haproxy termine. Cela permet de berner systemd.

• C'est un hack horrible
• Ça montre que systemd pose des problèmes qui n'existaient pas les autres init (ce n'est pas forcement une critique).
• Ça pose la question de savoir (de façon fort trollesque) s'il faut modifier les logiciels pour les adapter à systemd.

J'ai oublié de précisé tellement j'étais mort de rire que ce patch n'est pas de l'auteur. Il s'agit d'une contribution qui pour l'heure n'est pas commitée.

Un daemon unix est sensé recharger sa configuration quand on lui envoie le signal SIGHUP,

En l'occurrence ça n'a pas d'objet ici. HAProxy, ne peut pas recharger sa config. Ce n'est pas un bug c'est un choix, pris en connaissance de cause. On peut toujours critiquer ce choix ou en discuter , mais je ne vois pas en quoi il concerne init.

Quand au chroot, c'est un faux argument, systemd n'a aucun problème avec les daemons chrootés correctement écrits, par exemple: Bind, Postfix, OpenSSH, Avahi, etc… idem quant aux daemons tournant dans un chroot.

Il faut comparer ce qui est comparable. HAProxy a un design a un seul process.

pourquoi ne pas corriger la conception défectueuse de HAProxy

Quelle conception défectueuse ? En quoi le fait d'envoyer des signaux à un process pour déclencher une action (ici s’arrêter proprement) poserait un problème. Comme tout daemon pouvant être chrooté, HAProxy est susceptible de ne pas pouvoir relire sa config. Un reload consiste donc à remplacer le process proprement par un autre en essayant de ne pas droper de clients au passage.

Un peu plus lin dans le man on a :

       - SIGUSR1
              Tells  the daemon to stop all proxies and exit once all sessions
              are closed. It is often referred to as the "soft-stop" signal.

       - SIGTTOU
              Tells the daemon to stop listening to all sockets.  Used  inter-
              nally by -sf and -st.

       - SIGTTIN
              Tells  the  daemon  to  restart listening to all sockets after a
              SIGTTOU. Used internally when there was  a  problem  during  hot
              reconfiguration.

       - SIGINT and SIGTERM
              Both signals can be used to quickly stop the daemon.

       - SIGHUP
              Dumps  the  status  of  all  proxies  and servers into the logs.
              Mostly used for trouble-shooting purposes.

       - SIGQUIT
              Dumps information about memory pools into the logs. Mostly  used
              for debugging purposes.

       - SIGPIPE
              This  signal  is  intercepted  and  ignored  on  systems without
              MSG_NOSIGNAL.

Bref, tu peux utiliser les signaux pour piloter ton daemon. Quel défaut de conception !