Volnai a écrit 552 commentaires

  • [^] # Re: Théorème CAP

    Posté par  . En réponse à la dépêche MongoDB 1.4, prêt pour la production. Évalué à 2.

    MongoDB a choisi Consistency+Partition tolerance

    D'après ce que je comprends de Nosql, la cohérence est de type 'eventually consistency' pas stricte. C'est un peu gonflé de mettre ça comme choix numéro 1.
  • [^] # Re: Théorème CAP

    Posté par  . En réponse à la dépêche MongoDB 1.4, prêt pour la production. Évalué à 3.

    D'après le théoreme, que je ne connaissait pas, le Partition tolérance ce defini comme :

    No set of failures less than total network failure is allowed to cause the system to respond incorrectly ( http://www.julianbrowne.com/article/viewer/brewers-cap-theor(...) )

    On peut faire ça avec les RDBMS classiques il me semble, non ?
  • [^] # Re: Pour vendre

    Posté par  . En réponse au journal "On nous a demandé avec beaucoup d'insistance de voter Hadopi". Évalué à 2.

    On s'étonne que le client n'ai pas envie de prendre la qualité inférieure
    Je pense que la plupart des client visés ne savent même pas qu'un MP3 est de moins bonne qualité qu'un CD. Et qu'a 292kbps écoutés avec un casque pas génial dans le métro, il ne s'en rendent pas compte.
  • [^] # Re: Incontournable

    Posté par  . En réponse à la dépêche OpenSSH v5.4 : Certificat et Révocation. Évalué à 2.

    Bon ok pour H323, mais que penser des rédacteurs de SIP ? la rfc date de 2002. Il pensaient qu'on aller passer en Ipv6 en claquant des doigts ?
  • [^] # Re: Incontournable

    Posté par  . En réponse à la dépêche OpenSSH v5.4 : Certificat et Révocation. Évalué à 1.

    Le NAT est une vrai daube pour les protocole un peu complexe comme le H323 ou le SIP.

    C'est clair, mais il faudrait peut-être aussi s'en prendre à ceux qui ont rédigés ces protocoles qui ne prennent pas en compte les connexions NATés, alors qu'elles sont nombreuses.
    A moins qu'ils ne les ait fait ainsi pour permettre aux sociétés de sécurité de vendre de nouveaux produit qui savent remonter au niveau 7 ?
  • [^] # Re: problème chez Free, ou chez Algérie-Télécom/Anis ?

    Posté par  . En réponse au journal Free ! j'ai rien compris !. Évalué à 1.

    Perso j'ai trois routes vers l'AS33774 toutes passent par l'AS5511

    Il doit t'en manquer, ici j'ai une centaine de prefixes annoncés par 33774, et quelques un ne passent pas par 5511.
  • [^] # Re: Déjà là !

    Posté par  . En réponse au journal Le 26 Janvier prochain. Évalué à 2.

    Je paris que ca sortira en retard
  • [^] # Re: Utilisation abusive de tes votes

    Posté par  . En réponse au journal Consommation de ressources de Windows et Debian. Évalué à 3.

    Un chargé de com' non téchnique sur Linuxfr, il tiendrait combien de secondes ?

    Depuis quelques temps, vu les conneries qu'on peut lire (comme ce journal), je me dit qu'il pourrait tenir pas mal de temps en fait.
  • [^] # Re: Pas un problème

    Posté par  . En réponse au journal MALWARE LINUX. Évalué à 4.

    Mme Michu est au contraire beaucoup plus utilisatrice d'applications tierces que le geek

    Super. En ce qui me concerne madame Michu (tm) (r) (c) elle fait du web, du mail et de l'office. Mme Michu est au contraire beaucoup moins utilisatrice d'applications tierces que le geek.

    facile non ?
  • # ...

    Posté par  . En réponse au journal Sozi : vers un système de présentation alternatif libre. Évalué à 3.

    Ce truc est génialement simple
  • [^] # Re: Touche pas à (mon) grisbi !

    Posté par  . En réponse au journal Avec SPDY, Google souhaite accélérer remplacer/accélérer HTTP. Évalué à -1.

    tu n'y comprends rien, tellement tu es arcbouté sur tout fermer.
    Question de point de vue, du miens c'est toi qui ne comprends rien.

    Du coup, cela ne m'intéresse même plus de débattre avec toi.
    Effectivement je préfére aussi arreter de débattre avec quelqu'un qui ne sais pas regarder depuis la fenetre des autres.
  • [^] # Re: Touche pas à (mon) grisbi !

    Posté par  . En réponse au journal Avec SPDY, Google souhaite accélérer remplacer/accélérer HTTP. Évalué à 0.

    > Qu'est ce qui garanti que seules des personnes autorisées à accéder au réseau de la
    > boite ont accès à ton serveur externe, et donc au tunnel ?

    Auncun


    OK, comprends donc que la boite en face ne veuille pas forcement déporter sa sécurité. Après si le contrat est mal fait, ou qu'ils ne veulent pas payer plus cher pour faire quelque chose de propre, ce n'est pas la faute de la sécurité. Tu as tees objectifs, ils ont les leurs.

    Chez moi, une machine a toujours la même IP.
    C'est ton choix, ce n'est pas celui de la majorité des grandes entreprises pour des raisons evidente de flexibilité. Un utilisateur non admin aura du mal à spoofer.

    Parce que les DSI sont coincés pour ouvrir un port en sortie vers une SEULE ip fixe
    Une seule IP ? Je vais finir par croire que tu bosse dans une boite de 10 personnes !

    Toi, tu es dans ta tour d'ivoire... Tu as l'impression de ne pas avoir pris de risque mais tu m'as tout reporté sur moi pour que notre contrat de collaboration marche
    Vilain procès d'intention, j'essaye juste d'expliquer le point de vue du bord opposé au tiens. Dans les fait, oui, le risque pris par ma boite est plus limité qu'avec un tunnel ssh accessible potentielement au monde entier si ton réseau n'est pas sécurisé. Mission accomplie, par ici les pepettes.

    tu acceptes du SSH sur HTTP...
    j'accepte http, pas ssh et ses port forwarding/reverse tunneling


    Combien de gens dans ta boite commence a utiliser leur iphone ou équivalent dans le cadre du boulot ? Maîtrise-tu ce nouveau réseau ?
    Ca c'est un vrai enjeu d'avenir, mais certaines boites interdisent tout simplement la connexion usb de ce genre d'appareil su un poste d'entreprise.
  • [^] # Re: Touche pas à (mon) grisbi !

    Posté par  . En réponse au journal Avec SPDY, Google souhaite accélérer remplacer/accélérer HTTP. Évalué à 1.

    C'est la réponse classique des DSI quand je dis cela !
    Je suis prêt à devenir un deçaïdeur praissé \o/


    Pour ce problème, il aurait du autoriser la machine interne X a venir faire du SSH sur mon serveur Y.
    Qu'est ce qui garanti que seules des personnes autorisées à accéder au réseau de la boite ont accès à ton serveur externe, et donc au tunnel ?

    Ouvrir vers un nombre finie et limité de machine en sortie quelques protocoles non HTTP, ce n'est pas la mort
    Dans les faits, si c'est un peu la mort :) il faut réserver des IP fixes en pagaille (sauf à utiliser un firewall authentifiant), être sur d'être prévenu quand l'accès n'est plus nécessaire, être réactif parce que 'l'ip fixe de mon serveur perso chez moi à changé, vous pouvez mettre à jour les règles c'est méga urgent', ou encore parce que 'on m'a changé ma machine, vous pouvez remettre mes droit sur le firewall, c'est méga urgent (toujours)' ?
    L'équipe en charge de l'infra à souvent d'autres chats à fouetter que de gérer ces accès qui découlent le plus souvent d'une organisation a l'arrache et pour lesquelles elle se fera taper sur les doigts en cas de problème. oui, je m'ennerve là :)

    A ces gens là je dis, attention à la 3G, vous allez vous amuser avec les ponts ;-)
    C'est pas nouveau, on peut faire des ponts avec le wifi aussi. Il suffit de les bloquer sur le poste de travail lorsqu'il est connecté au réseau filaire, ou les interdire complétement ,suivant ce que l'on veut.
  • [^] # Re: Touche pas à (mon) grisbi !

    Posté par  . En réponse au journal Avec SPDY, Google souhaite accélérer remplacer/accélérer HTTP. Évalué à 1.

    à part une analyse statistique de l'utilisation de la bp je vois pas
    Par exemple, par défaut, la première réponse d'un serveur ssh c'est la banniere de version, qui se detecte facilement (et qui se change aussi facilement, mais ce n'est q'un exemple). Ensuite oui, certaines boites font de l'interception ssl systématique sur leurs proxy (sauf sur les sites pour lequel c'est interdit, tels que les banques).

    rien ne m'empêche sur un serveur externe que je contrôle de mettre un service sur le port 80 qui répond à un bête client qui fait du http pour lui faire exécuter des commandes en interne.
    Il y aura toujours un moyen, plus ou moins évident selon l'architecture en place. Le but est déjà d'éviter les plus triviaux.

    elles ne servent à rien pour une personne déterminée à donner un accès vers l'intérieur
    La sécurité totale n'existe pas (même chez OpenBSD :) , mais la personne en question risque de ce casser les dents sur les premières barrières en place, ce qui permettra de le detecter et de gentiment aller lui expliquer ce qu'il n'est pas sensé faire.

    Le problème en soi n'est même pas le reverse tunnel, c'est le fait de ne plus contrôller le périmétre : qu'est ce qu'on sait de la sécurité du serveur qui monte le reverse ? Peut-être qu'il est cracké et que, sans le savoir, celui qui monte ce tunnel et qui est plein de bonnes intentions donne au passage accès au réseau de l'entreprise à un vil pirate qui n'en demande pas tant...
  • [^] # Re: Touche pas à (mon) grisbi !

    Posté par  . En réponse au journal Avec SPDY, Google souhaite accélérer remplacer/accélérer HTTP. Évalué à 0.

    Pour ça faut être en interne.
    J'ai peut-être mal compris, mais il me semble qu'on parle d'accés ssh en sortie, donc depuis l'interne ?

    corkscrew + accès vers un serveur ssh externe sur le port 443
    Il y a des moyens pour détecter et interdire ça. J'ai déjà vu des gens renvoyés pour ça...

    Là ou je veux en venir, c'est que ça ne sécurise rien du tout.
    OK, on a qu'a laisser les machines en direct faire ce quelles veulent sur internet, c'est sur que ça fera avancer la sécurité. On ne peut pas tout bloquer, ça ne veut pas dire qu'il ne faut rien bloquer.
  • [^] # Re: Touche pas à (mon) grisbi !

    Posté par  . En réponse au journal Avec SPDY, Google souhaite accélérer remplacer/accélérer HTTP. Évalué à -1.

    Avez-vous plus confiance dans le couple Apache+AjaxTerm qu'en OpenSSH ?

    Le problème avec Openssh est qu'il permet trop facilement de faire du reverse tunnelling, et donc de permettre un accès entrant directement sur le réseau de l'entreprise. Certe on peut faire la même chose sur du http, mais ca se detecte , et ce n'est pas parce que qu'on ne peut pas arrêter la peste qu'on ne doit rien faire contre le choléra...

    Quant à n'autoriser que http en sortie, c'est aussi parce que c'est le protocol pour lequel on trouve le plus facilement des proxy avec des fonctions 'avancés' intégrées (filtrage d'url, support d'icap, interception ssl...).
  • [^] # Re: Tout dépend du besoin...

    Posté par  . En réponse au journal De Checkpoint à FreeBSD. Évalué à 1.

    Check poste ? càd ?
    Vérification de conformité, par exemple s'assurer de la présence d'un antivirus à jour avant d'autoriser la connexion. Tout ce qui se cache derrière le beau terme marketting " NAC"

    Je suis pas un spécialiste Checkpoint, mais ça se vend pas que sur des plateformes Nokia, ils le vendent même à installer sur un Windows
    Tout à fait, sur linux et solaris aussi, mais restons sérieux...

    Effectivement, avec de l'OpenVPN par exemple c'est un process par CPU, donc à moins de monter plusieurs VPN et faire du round robin avec relayd, c'est pas out of the box (bien que faire du round robin avec relayd ça soit pas vraiment dur ...)
    Sinon y'a du support de cryptodev pour Via padlock (avec OpenSSL sous OpenBSD j'ai déjà essayé avec des débits à 300Mbits/s, mais j'ai un doute, je sais plus si c'était avec AES128 ou AES256 ou les deux)

    Ok, je ne connais pas, merci pour l'info. 300Mbps en vpn c'est bien, mais la plus petite des IP appliance checkpoint est annoncé au double, faudrait comparer en conditions réelles.

    Malheureusement je doute fortement que ça marche en ayant les machines comme endpoint IPSec ou OpenVPN (ou alors il faut sérieusement bidouiller)
    Ca de toute façon, ça marche toujours très bien sur le papier chez plein de constructeurs...
  • [^] # Re: Tout dépend du besoin...

    Posté par  . En réponse au journal De Checkpoint à FreeBSD. Évalué à 1.

    le checkpoint étant mort et enterré je ne pourrais pas faire de mesure comparative

    C'est tout ce que je demandais. Pour les liens vers freebsd, pf et carp, c'est gentil, merci.
  • [^] # Re: Tout dépend du besoin...

    Posté par  . En réponse au journal De Checkpoint à FreeBSD. Évalué à 0.

    ais que tu cites les reproches (les inconvénients) faits aux solutions propriétaires pour expliquer qu'elles ne correspondent pas aux besoins auxquels elles répondent.

    En fait je suis persuadé qu'il y a un marché pour checkpoint autant que pour PF, tout dépends justement du besoin. C'est pour ça que je demande des infos sur la partie performance, n'ayant jamais migré de l'un à l'autre. Mais l'auteur du journal préfére pointer ma confusion Freebsd/openbsd plutôt que d'essayer de répondre.
  • [^] # Re: Tout dépend du besoin...

    Posté par  . En réponse au journal De Checkpoint à FreeBSD. Évalué à 0.

    Tu sous-entends que des gens ont besoin:
    - de payer des licences,
    - de se faire chier à désactiver des trucs qui les emmerdent et qu'ils ont payé?


    Plus précisement, je dis que si tu achétes quelque chose dont tu n'as pas besoin et que tu est obligé de te taper une migration après, apprends à faire une étude.
  • [^] # Re: Tout dépend du besoin...

    Posté par  . En réponse au journal De Checkpoint à FreeBSD. Évalué à -4.

    Mais c'est parce que j'ai aussi mis PF dans la phrase : Firewall, FreeBSD et PF

    Décidement...

    Si t'as pas envie de lire le journal, t'es pas obligé de poser des questions.
    Si tu veux écrire un journal pour dire que tu ne sais pas utiliser checkpoint, que tu préfére freebsd et que tu ne veux pas répondre à des questions, fais un blog.
  • [^] # Re: Tout dépend du besoin...

    Posté par  . En réponse au journal De Checkpoint à FreeBSD. Évalué à -2.

    Sous OpenBSD je sais pas, j'utilise FreeBSD.

    Au temps pour moi, je pense à PF dès que je vois firewall et bsd dans la même phrase. Mais la question reste valable : Splat supporte le multicoeur, les cartes accélératrice et le mode actif/actif depuis longtemps. Qu'en est-il sous freebsd ?
  • # Tout dépend du besoin...

    Posté par  . En réponse au journal De Checkpoint à FreeBSD. Évalué à 2.

    Le client VPN fourni pas Checkpoint ne fonctionne pas sur les version 64 bits de Vista
    Pourtant il est vendu pour :
    http://www.checkpoint.com/products/endpoint_connect/index.ht(...)
    Bon j'ai pas testé, mais tu as quoi comme alternative pour faire un check du poste et un déploiement de règles locales a la connexion ?

    Basé sur du Linux, mais suffisamment différent pour ne pas être utilisable comme un Linux
    Si tu parles bien d'ipso, c'est basé sur du bsd à l'origine. Et il existe Gnukia pour retrouver un peu du confort Gnu sous ipso


    Avoir deux IP sur la même carte réseau étant possible moyennant quelques bidouilles dans des fichiers de configuration non documentés.
    Jamais essayé, mais dans quel but ? Ipso supportte très bien les interfaces vlans

    Des licences à payer
    Des options de sécurités top-cool qu'on passait notre temps à chercher puis désactiver
    Bref, ça ne correspond pas à ton besoin.

    Concernant les perf, il y a des cartes accélératrices qui fonctionnent correctement sous openbsd ? Déjà qu'il ne sait apparement pas utiliser plusieurs core d'après http://www.openbsd.org/faq/pf/fr/perf.html ...

    Et ca fonctionne bien en mode actif/actif ?
  • # Et la démo ?

    Posté par  . En réponse au journal Auxrames : Outil de gestion d'équipe. Évalué à 7.

    Si tu veux vendre aux deçaïdors préssés, pense à mettre une démo en ligne.
  • [^] # Re: Espion qdisc et/ou Courbe temps-réel d'historique de variable kerne

    Posté par  . En réponse au journal Espion qdisc et/ou Courbe temps-réel d'historique de variable kernel. Évalué à 9.

    Je pense que je n'écrirais plus içi de toute façon.

    C'est pas grave, des clowns on en a déjà plein ici.